一，计算机网络体系结构

对于同一台设备上的进程间的通信有很多种方式，但是比如管道，消息队列，共享内存，信号等，而对于不同设备上的进程间的通信就需要网络通信，而设备是多样的，所以要兼容多种多样的设备就协商除了一套通用的网络协议。

网络是一个复杂的系统，如何组织和实现这个复杂的复杂的网络功能？可采用层次化方式实现。将网络复杂的功能分层功能明确的层次，每一层实现了其中一个或一组功能，本层协议实体相互交互执行本层的协议动作，实现本层功能并通过接口为上层提供更好的服务。

这样可以使网络结构更加的清晰，便于标示网络组件以及描述其相互关系，而且改变某一层服务的实现不影响系统中的其他层次更易于维护和系统升级。

所以国际标准化组织（ISO）制定了开发系统互连基本参考模型(OSI)，但是由于在其制定出该标准之前TCP/IP已经在市场上得到了广泛的应用和其协议本身实现起来的复杂性和某些层次划分的不太合理性导致TCP/IP就常常被称为事实上的国际标准。

在学习计算机网络时通常采用两种协议折中的办法综合OSI和TCP/IP的优点，采用五层协议的体系结构。

1，TCP/IP网络模型

应用层应用层是体系结构中的最高层。应用层的任务是通过应用进程间的交互来完成特定应用。应用层协议定义的是应用进程间通信和交互的规则。这里的进程就是指主机中正在运行的程序。对于不同的网络应用需要由不同的应用层协议。在互联网中的应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP协议，支持电子邮件的SMTP协议等。应用层交互的数据单元称为报文（message）

传输层传输层的任务就是负责向两台主机中进程之间的通信提供通用的数据传输服务。应用层进程利用该服务传送应用层保温。所谓“通用的”，是指并不针对某个特定网络应用，而是多种语言可以使用同一个传输层服务。由于一台主机可以同时运行多个进程，因此传输层有复用和解复用功能。复用就是多个应用进程可同时使用下面运输层的服务，解复用和复用相反，是传输层把收到的信息分别交付上面应用层中的相应进程。

传输层主要使用以下两种协议：

• 传输控制协议（TCP）：提供面向连接的，可靠的数据传输服务，其数据传输的单位是报文段（segment）。

• 用户数据报协议（UDP）：提供无连接的，尽最大努力的数据传输服务（不澳洲数据传输的可靠性），其数据传输的单位是用户数据报。

网络层网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把传输层产生的报文段或者用户数据报封装成分组或者包进行传送。

网络层的另一个任务就是选择合适的路由，使源主机传输层所传下来的分组，能够通过网络中的路由器找到目的主机

数据链路层两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层协议。在两个相邻节点之间传送数据时，链路层将网络层交下来的IP数据报组装成帧（framing），每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制等）。

在接收数据时，控制信息使接收端能够指导一个帧从哪个比特开始哪个比特结束。这样，链路层在收到一个帧后就可以提取数据部分，上交给网络层。

控制信息还使接收端能够检测到所收到的帧中有无差错，如果发现有差错数据链路层就简单地丢弃这个出了差错地帧，以免在网络中传送下去白白浪费网络资源。如果需要改正数据链路层传输时出现地差错（这就是说链路层不仅需要检错还需要改错），那么就需要采用可靠地传输协议来纠正出现地差错。

物理层在物理层上所传输地数据的单位是比特。发送方发送1，0时，接收方应当收到1，0，而不是0，1，因此物理层要考虑用多大的电压代表1或者0，以及接收方如何识别发送方所发送的比特。物理层还要确定连接电缆的插头应当有多少根引脚以及各引脚应如何连接。

2，ISO/OSI七层模型

表示层表示出提供各种用于应用层数据的编码和转化功能，确保一个系统的应用层发送的数据能被另一个系统应用层识别。如果必要，该层可提供一个标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和解密也是表示层可提供的数据转换功能之一。

在项目开发中，为了方面数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

会话层会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。数据交换的同步，检查点，恢复。

网络模型

TCP/IP数据封装

二，HTTP协议

HTTP协议定义了浏览器（即万维网客户进程）怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度，HTTP属于应用层协议，它是万维网能够可靠地交换文件的重要基础。

每个万维网网点都有一个服务器进程，它不断地监视TCP的端口80，以便发现是否有浏览器向它发出连接建立请求。一旦监听到连接建立请求并建立TCP连接之后，浏览器就向万维网服务其发出浏览某个页面的请求，服务器接着就返回所请求的页面作为响应。最后TCP连接就被释放了。在浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则。这些格式和规则就是超文本传送协议HTTP。

万维网的工作过程

1，HTTP基本知识

1.1，http是什么

见上

1.2，http常见字段

HTTP Request Header常见的请求头:

• Accept:浏览器能够处理的内容类型

• Accept-Charset:浏览器能够显示的字符集

• Accept-Encoding:浏览器能够处理的压缩编码

• Accept-Language:浏览器当前设置的语言

• Connection:浏览器与服务器之间连接的类型。

• Cookie:当前页面设置的任何Cookie

• Host:发出请求的页面所在的域. Referer:发出请求的页面的URL

• User-Agent:浏览器的用户代理字符串

HTTP Responses Header常见的响应头:

• Date:表示消息发送的时间，时间的描述格式由rfc822定义

• server:服务器名称

• Connection:浏览器与服务器之间连接的类型

• Cache-Control:控制HTTP缓存

• content-type:表示后面的文档属于什么MIME类型

常见的Content-Type 属性值有以下四种:

• application/x-www-form-urlencoded:浏览器的原生form 表单，如果不设置enctype属性，那么最终就会以 application/x-www-form-urlencoded方式提交数据。该种方式提交的数据放在body里面，数据按照key1=val1&key2=val2的方式进行编码，key和val都进行了URL转码。

• multipart/form-data:该种方式也是一个常见的POST提交方式，通常表单上传文件时使用该种方式。

• application/json:服务器消息主体是序列化后的JSON字符串。

• text/xml:该种方式主要用来提交XML格式的数据。

1.3，常见的请求方法

get和post区别

• 应用场景:GET请求是一个幂等的请求，一般Get请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。

• 是否缓存:因为两者应用场景不同，浏览器一般会对Get请求缓存，但很少对Post请求缓存。

• 发送的报文格式:Get请求的报文中实体部分为空，Post请求的报文中实体部分一般为向服务器发送的数据。

• 安全性:Get请求可以将请求的参数放入url中向服务器发送，这样的做法相对于Post 请求来说是不太安全的，因为请求的url会被保留在历史记录中。

• 请求长度:浏览器由于对url长度的限制，所以会影响get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC规定的。

• 参数类型: post 的参数传递支持更多的数据类型。

post和put的区别

• PUT请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。(可以理解为时更新数据)

• POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。(可以理解为是创建数据)

1.4，状态码

• 「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会有 body 数 据。

• 「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

• 「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽ 是其中的⼀部分，也是服务器处理成功的状态。

• 「301 Moved Permanently」表示永久᯿定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次访问。

• 「302 Found」表示临时᯿定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。

• 「304 Not Modified」不具有跳转的含义，表示资源未修改，᯿定向已存在的缓冲⽂件，也称缓存᯿定向，⽤于缓 存控制。

• 「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。

• 「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。

• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端

• 「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。

• 「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。

• 「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器 发⽣了错误。

• 「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后᯿试”的意 思。

1.5 OPTIONS请求方法的使用场景

OPTIONS是除了GET和POST之外的其中—种HTTP请求方法。

OPTIONS方法是用于请求获得由Request-URI 标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS请求方法的主要用途有两个:

• 获取服务器支持的所有HTTP请求方法;

• 用来检查访问权限。例如:在进行CORS跨域资源共享时，对于复杂请求，就是使用OPTIONS方法发送嗅探请求，以判断是否有对指定资源的访问权限。

1.6 GET方法URL长度限制的原因

实际上HTTP协议规范并没有对get方法请求的ur长度进行限制，这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。由于IE浏览器对URL长度的允许值是最小的，所以开发过程中，只要URL不超过2083字节，那么在所有浏览器中工作都不会有问题。

GET的长度值= URL(2083)-（你的Domain+Path) -2(2是get请求中?=两个字符的长度)

下面看一下主流浏览器对get方法中url的长度限制范围:

• Microsoft Internet Explorer (Browser):IE浏览器对URL的最大限制为2083个字符，如果超过这个数字，提交按钮没有任何反应。

• Firefox (Browser):对于Firefox浏览器URL的长度限制为65,536个字符。. Safari(Browser): URL最大长度限制为80,000个字符。

• Opera(Browser):URL最大长度限制为190,000个字符。. Google (chrome): URL最大长度限制为8182个字符。

主流的服务器对get方法中url的长度限制范围:

• .Apache (Server):能接受最大url长度为8192个字符。

• Microsoft Internet Information Server(IlS):能接受最大url的长度为16384个字符。

根据上面的数据，可以知道,get方法中的URL长度最长不超过2083个字符，这样所有的浏览器和服务器都可能正常工作。

1.7 当在浏览器中输入Google.com并且按下回车之后发生了什么?

• (1）解析URL:首先会对URL进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查URL中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

• (2）缓存判断:浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。

• (3）DNS解析:下一步首先需要获取的是输入的URL 中的域名的IP地址，首先会判断本地是否有该域名的IP地址的缓存，如果有则使用，如果没有则向本地DNS服务器发起请求。本地DNS服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的IP地址后，本地DNS服务器再将这个IP地址返回给请求的用户。用户向本地DNS服务器发起请求属于递归请求，本地DNS 服务器向各级域名服务器发起请求属于迭代请求。

• (4）获取MAC地址:当浏览器得到IP地址后，数据传输还需要知道目的主机MAC地址，因为应用层下发数据给传输层，TCP协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的IP地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的MAC地址，本机的MAC地址作为源MAC地址，目的MAC地址需要分情况处理。通过将IP地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用APR协议获取到目的主机的MAC地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过ARP协议来获取网关的MAC地址，此时目的主机的MAC地址应该为网关的地址。

• (5)TCP三次握手:下面是TCP建立连接的三次握手的过程，首先客户端向服务器发送一个SYN连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。

• (6)HTTPS握手:如果使用的是HTTPS协议，在通信前还存在TLS的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成—把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

• (7）返回数据:当页面请求发送到服务器端后，服务器端会返回一个html文件作为响应，浏览器接收到响应后，开始对 html文件进行解析，开始页面的渲染过程。

• (8）页面渲染:浏览器首先会根据 html文件构建DOM树，根据解析到的css文件构建CSSOM树，如果遇到script标签，则判端是否含有defer或者async属性，要不然script的加载和执行会造成页面的渲染的阻塞。当DOM树和CSSOM树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的UI接口对页面进行绘制。这个时候整个页面就显示出来了。

• (9)TCP四次挥手∶最后一步是TCP断开连接的四次挥手过程。若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放TCP链接。然后会发送ACK包，并进入CLOSE_WAIT状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入LAST-ACK状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入TIME-WAIT状态。该状态会持续2MSL(最大段生存期，指报文段在网络中生存的时间，超时会被抛弃)时间，若该时间段内没有服务端的重发请求的话，就进入CLOSED 状态。当服务端收到确认应答后，也便进入CLOSED状态。

1.8 对keep—alive的理解

HTTP1.0中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时,Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。其使用方法如下:

• HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive)，所以要想连接得到保持，必须手动配置发送connection: keep-alive字段。若想断开keep-alive连接，需发送Connection:close 字段;

• HTTP1.1规定了默认保持长连接，数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送Connection: close首部字段。

Keep-Alive的建立过程:

• 客户端向服务器在发送请求报文同时在首部添加发送Connection字段

• 服务器收到请求并处理Connection字段

• 服务器回送Connection:Keep-Alive字段给客户端

• 客户端接收到Connection字段

• Keep-Alive连接建立成功

服务端自动断开过程（也就是没有keep-alive) :

• 客户端向服务器只是发送内容报文(不包含Connection字段)

• 服务器收到请求并处理

• 服务器返回客户端请求的资源并关闭连接

• 客户端接收资源，发现没有Connection字段，断开连接

客户端请求断开连接过程:

• 客户端向服务器发送Connection:close字段

• 服务器收到请求并处理connection字段

• 服务器回送响应资源并断开连接

• 客户端接收资源并断开连接

开启Keep-Alive的优点:

• 较少的CPU和内存的使用(由于同时打开的连接的减少了)

• 允许请求和应答的HTTP管线化;

• 降低拥塞控制(TCP连接减少了);

• 减少了后续请求的延迟（无需再进行握手);

• 报告错误无需关闭TCP连;

开启Keep-Alive的缺点:

• 长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

1.9 URL有哪些组成部分

以下面的URL为例: http://www.aspxfans.com:8080/news/index.asp?boardID=5&lD=24618&page=1#name

从上面的URL可以看出，一个完整的URL包括以下几部分:

• 协议部分:该URL的协议部分为“http: ”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符;

• 域名部分:该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用

• 端口部分:跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口(HTTP协议默认端口是80，HTTPS协议默认端口是443);

• 虚拟目录部分:从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”;

• 文件名部分:从域名后的最后一个“/”开始到“?”为止，是文件名部分，如果没有“?”,则是从域名 后的最后一个“1”开始到“#”为止，是文件部分，如果没有“?”和“#”，那么从域白口以取口l“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名;

• 锚部分:从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分;

• 参数部分:从“?”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardIlD=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

1.10 与缓存相关的HTTP请求头有哪些强缓存:

• Expires

• Cache-Control 协商缓存:

• Etag、lf-None-Match

• Last-Modified、lf-Modified-Since

1.11 端口号的作用

一台主机(对应一个IP地址)可以提供很多服务，比如web服务，ftp服务等。如果只有一个IP，就无法区分不同的网络服务，所以采用”IP＋端口号”来区分不同的服务。

2，HTTP1.0、HTTP1.1、HTTP2.0和HTTP3.0

2.1，HTTP1.0和HTTP1.1之间的区别

• 连接方面，1.0默认使用非持久连接，而1.1默认使用持久连接。1.1通过使用持久连接来使多个http请求复用同一个TCP连接，以此来避免使用非持久连接时每次都需要建立连接的时延。

• 资源请求方面，1.0存在一些浪费带宽的现象，例如客户端知识需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1则在请求头中引入了range头域，它允许只请求资源的某个部分，即返回码是206，这样就方便了开发者自由选择以便充分利用带宽和连接。

• 缓存方面，在 http1.0中主要使用header里的lf-Modified-Since、Expires 来做为缓存判断的标准,http1.1则引入了更多的缓存控制策略，例如Etag、lf-Unmodified-Since、lf-Match、lf-None-Match等更多可供选择的缓存头来控制缓存策略。

• http1.1中新增了host字段，用来指定服务器的域名。http1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。因此有了host字段，这样就可以将请求发往到同一台服务器上的不同网站。

• http1.1相对于http1.0还新增了很多请求方法，如PUT、HEAD、OPTIONS等。

2.2，HTTP1.1和HTTP2.0区别

• 二进制协议:HTTP/2是一个二进制协议。在 HTTP/1.1版中，报文的头信息必须是文本(ASCII编码)，数据体可以是文本，也可以是二进制。HTTP/2则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。帧的概念是它实现多路复用的基础。

• 多路复用:HTTP/2实现了多路复用，HTTP/2仍然复用TCP连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序―一发送，这样就避免了"队头堵塞"的问题。

• 队头阻塞是由HTTP 基本的“请求–应答”模型所导致的。HTTP规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着—起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

• 数据流:HTTP/2使用了数据流的概念，因为HTTP/2的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流ID，用来区分它属于哪个数据流。

• 头信息压缩:HTTP/2实现了头信息压缩，由于HTTP 1.1协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用gzip或compress压缩后再发送;另一方面，客户端和服务器同时维护―张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。

• 服务器推送:HTTP/2允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是http2下服务器主动推送的是静态资源，和WebSocket以及使用SSE等方式向客户端发送即时数据的推送是不同的。

2.3，HTTP3.0和HTTP2.0区别

• 协议不同：HTTP2是基于TCP协议实现的，HTTP3基于UDP实现

• HTTP3新增了QUIC协议来实现可靠性的传输

• 握手次数HTTP2是基于HTTPS实现的，建立连接需要进行TCP3次握手，然后再进行TLS3次握手，共六次握手，HTTP3只需要QUIC的3次握手

• IO多路复用，如:在⼀个连接中，服务器收到了客户端 A 和 B 的两个请求，但是发现在处理 A 的过程中⾮常耗时，索性就先回应 A 已经处理好的部分，再接着回应 B 请求，最后再回应 A 请求剩下的部分。HTTP/2 可以在⼀个连接中并发多个请求或回应。

3，HTTP和HTTPS区别

3.1 HTTP 与 HTTPS 有哪些区别？

• 1. HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

• 2. HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之 后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

• 3. HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。

• 4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

3.2 HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明⽂传输，所以安全上存在以下三个⻛险：

• 窃听⻛险，⽐如通信链路上可以获取通信内容，⽤户号容易没。

• 篡改⻛险，⽐如强制植⼊垃圾⼴告，视觉污染，⽤户眼容易瞎。

• 冒充⻛险，⽐如冒充淘宝⽹站，⽤户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL/TLS 协议，可以很好的解决了上述的⻛险：

• 信息加密：交互信息⽆法被窃取，但你的号会因为「⾃身忘记」账号⽽没。

• 校验机制：⽆法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾⼴告。

• 身份证书：证明淘宝是真的淘宝⽹，但你的钱还是会因为「剁⼿」⽽没。

3.3 HTTPS 是如何解决上⾯的三个⻛险的？

• 混合加密的⽅式实现信息的机密性，解决了窃听的⻛险。

• 摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整性，解决了 篡改的⻛险。

• 将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。

混合加密：

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：

• 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。

• 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据

采⽤「混合加密」的⽅式的原因：

• 对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换。

• ⾮对称加密使⽤两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。

摘要算法：摘要算法⽤来实现完整性，能够为数据⽣成独⼀⽆⼆的「指纹」，⽤于校验数据的完整性，解决了篡改的⻛险。

客户端在发送明⽂之前会通过摘要算法算出明⽂的「指纹」，发送的时候把「指纹 + 明⽂」⼀同加密成密⽂后，发 送给服务器，服务器解密后，⽤相同的摘要算法算出发送过来的明⽂，通过⽐较客户端携带的「指纹」和当前算出 的「指纹」做⽐较，若「指纹」相同，说明数据是完整的。

数字证书客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密⽂后，⽤⾃⼰的私钥解密。

这就存在些问题，如何保证公钥不被篡改和信任度？ 所以这⾥就需要借助第三⽅权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证 机构颁发）中，只要证书是可信的，公钥就是可信的。

通过数字证书的⽅式保证服务器公钥的身份，解决冒充的⻛险

3.4 HTTPS 是如何建⽴连接的？其间交互了什么？

SSL/TLS 协议基本流程

• 客户端向服务器索要并验证服务器的公钥。

• 双⽅协商⽣产「会话秘钥」。

• 双⽅采⽤「会话秘钥」进⾏加密通信。

前两步也就是 SSL/TLS 的建⽴过程，也就是握⼿阶段 SSL/TLS 的「握⼿阶段」涉及四次通信，可⻅下图：

3.5 SSL/TLS 协议建⽴的详细流程：

1. ClientHello ⾸先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。 在这⼀步，客户端主要向服务器发送以下信息：

• （1）客户端⽀持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

• （2）客户端⽣产的随机数（ Client Random ），后⾯⽤于⽣产「会话秘钥」。

• （3）客户端⽀持的密码套件列表，如 RSA 加密算法

1. SeverHello 服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：

• （1）确认 SSL/ TLS 协议版本，如果浏览器不⽀持，则关闭加密通信。

• （2）服务器⽣产的随机数（ Server Random ），后⾯⽤于⽣产「会话秘钥」。

• （3）确认的密码套件列表，如 RSA 加密算法。

• （4）服务器的数字证书。

3.客户端回应 客户端收到服务器的回应之后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使⽤它加密报⽂，向服务器发送如下信息：

• （1）⼀个随机数（ pre-master key ）。该随机数会被服务器公钥加密。

• （2）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

• （3）客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘 要，⽤来供服务端校验。 上⾯第⼀项的随机数是整个握⼿阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就⽤双⽅协 商的加密算法，各⾃⽣成本次通信的「会话秘钥」。

1. 服务器的最后回应 服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘 钥」。然后，向客户端发⽣最后的信息：

• （1）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

• （2）服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘 要，⽤来供客户端校验。 ⾄此，整个 SSL/TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使⽤普通的 HTTP 协议，只不过⽤「会话秘钥」加密内容。

三，DNS

1.DNS协议是什么

概念:DNS是域名系统(Domain Name System)的缩写，提供的是一种主机名到IP地址的转换服务，就是我们常说的域名系统。它是一个由分层的DNS服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

作用:将域名解析为IP地址，客户端向DNS服务器(DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的IP地址。

2.DNS同时使用TCP和UDP协议?

DNS占用53号端口，同时使用TCP和UDP协议。

• (1）在区域传输的时候使用TCP协议

• - 辅域名服务器会定时（一般3小时)向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。

• - TCP是一种可靠连接，保证了数据的准确性。

• (2）在域名解析的时候使用UDP协议

• - 客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

3.DNS完整的查询过程DNS服务器解析域名的过程:

• 首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步

• 将请求发送给本地DNS服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步

• 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址

• 本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下—级的权威域名服务器的地址

• 本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果。本地DNS服务器将返回结果保存在缓存中，便于下次使用

- 本地DNS服务器将返回结果返回给浏览器

比如要查询www.baidu.com的IP地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的DNS 服务器中，本地DNS服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责.com的顶级域名服务器的IР地址的列表。然后本地DNS服务器再向其中一个负责.com的顶级域名服务器发送一个请求，负责.com的顶级域名服务器返回负责.baidu的权威域名服务器的IP地址列表。然后本地DNS服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的IP地址列表。

4.送代查询与递归查询

实际上，DNS解析是一个包含迭代查询和递归查询的过程。

• 递归查询指的是查询请求发出后，域名版芳器代为问下一以以口服力的久山月小，A果。使用递归查询，用户只需要发出一次查询请求。

• 迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出多次的查询请求。 一般我们向本地DNS服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地DNS服务器返回给我们最终的请求结果。而本地 DNS服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地DNS服务器自己进行。

5.DNS 记录和报文

DNS服务器中以资源记录的形式存储信息，每一个DNS响应报文一般包含多条资源记录。一条资源记录的具体的格式为

(Name，Value，Type，TTL）

其中TTL是资源记录的生存时间，它定义了资源记录能够被其他的DNS 服务器缓存多长时间。

常用的一共有四种Type 的值，分别是A、NS、CNAME和MX，不同Type的值，对应资源记录代表的意义不同:·如果Type = A，则Name 是主机名，Value是主机名对应的IP地址。因此一条记录为A的资源记录，提供了标准的主机名到IP地址的映射。

• 如果Type = NS，则 Name是个域名，Value是负责该域名的DNS服务器的主机名。这个记录主要用于DNS链式查询时，返回下—级需要查询的DNS服务器的信息。

• 如果Type = CNAME，则 Name为别名，Value为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名对应的规范主机名，从而告诉查询主机去查询这个主机名的IP地址。主机别名主要是为了通过给一些复杂的主机名提供一个便于记忆的简单的别名。

• 如果Type = MX，则 Name为一个邮件服务器的别名，Value为邮件服务器的规范主机名。它的作用和CNAME是一样的，都是为了解决规范主机名不利于记忆的缺点。