计算机网络知识点复盘（一）

本文主要复盘一些笔试面试中有问到的计网知识点：

一、TCP的三次握手和四次挥手过程？

（一）三次握手过程：

（1）一次握手：客户端首先发送带有 SYN 标志的数据包给服务端
（2）二次握手：服务端发送带有 SYN / ACK 标志的数据包给客户端
（3）三次握手：客户端发送带有带有 ACK 标志的数据包给服务端

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

（1）为什么要三次握手？
答：为了建立可靠的连接。三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

（2）为什么要传回 SYN？
答：接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号。

（3）传了 SYN，为什么还要传 ACK？
答：双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

（二）四次挥手过程

（1）客户端发送一个 FIN，用来关闭客户端到服务器的数据传送
（2）服务器收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加1
（3）服务器关闭与客户端的连接，发送一个FIN给客户端
（4）客户端发回 ACK 报文确认，并将确认序号设置为收到序号加1

（1）为什么客户端最后还要等待2MSL？
答：1）保证客户端发送的最后一个ACK报文能够到达服务器。因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
2）防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

（2）如果已经建立了连接，但是客户端突然出现故障了怎么办？
答：TCP还设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

二、HTTPS加密的过程？

HTTPS是HTTP的通信接口部分采用SSL和TLS协议代替的协议。

共享密钥加密：加密和解密同用一个密钥的加密方式
公开密钥加密：使用一对非对称的密钥。一把私有密钥，一把公有密钥，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。

HTTPS采用的是共享密钥加密和公开密钥加密两者并用的混合加密机制。

HTTPS的通信过程如下：

步骤1：客户端通过发送Client Hello报文开始SSL通信（这里是在TCP的三次握手已经完成的基础上进行的）。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法及密钥长度等）。

步骤2：服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤3：之后服务器发送Certificate报文。报文中包含公开密钥证书。

步骤4：最后服务器发送Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。

步骤5：SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。

步骤6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤8：服务器同样发送Change Cipher Spec报文。

步骤9：服务器同样发送Finshed报文。

步骤10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。

步骤11：应用层协议通信，即发送HTTP响应。

步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。上图做客一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

在以上流程中，应用层发送数据时会附加一种叫做MAC的报文摘要。MAC能够查知报文是否遭到篡改从，从而保护报文的完整性。

三、对比HTTP1，HTTP2的新特性？

（一）HTTP1的缺点：

（1）高延迟，页面加载速度降低

网络延迟问题主要由于队头阻塞，导致带宽无法被充分利用。队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。

（2）无状态特性导致HTTP头部大

由于报文Header一般会携带"User Agent"、“Cookie”、"Accept"等许多固定的头字段，多达几百字节甚至上千字节，但Body却经常只有几十字节（比如GET请求、 204/301/304响应），成了不折不扣的“大头儿子”。Header里携带的内容过大，在一定程度上增加了传输的成本。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费。

（3）明文传输带来的不安全性

HTTP/1.1在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。

（4）不支持服务器推送消息

（二）HTTP2的新特性：

（1）二进制传输

HTTP2传输数据量减少是因为以二进制方式传输和Header 压缩。

HTTP2 在 应用层和传输层之间增加一个二进制分帧层，采用二进制格式传输数据，而非HTTP/1.x 里纯文本形式的报文 ，二进制协议解析起来更高效。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

它把TCP协议的部分特性挪到了应用层，把原来的"Header+Body"的消息"打散"为数个小片的二进制"帧"(Frame),用 “headers"帧存放头数据、“data” 帧存放实体数据。HTTP2数据分帧后"Header+Body"的报文结构就完全消失了，协议看到的只是一个个的"碎片”。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

（2）Header 压缩

HTTP2并没有使用传统的压缩算法，而是开发了专门的"HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。

首部压缩可以使得头部帧可以最大程度复用，减少头部的大小，有利于减少内存和流量。

（3）多路复用

多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，可以只通过一个 TCP 连接就可以传输所有的请求数据。

（4）服务器推送

一般HTTP请求都是由客户端发起，服务器收到请求进行返回。但是HTTP 2.0 可以使服务器主动返回资源给客户端用户。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这样就可以提高了性能。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

（5）流量控制

HTTP 2.0 “流” 的流量控制最终的目标是在不改变协议的情况之下允许采用多种流量控制算法。

流量控制特点：

• 流量基于HTTP连接的每一跳进行，非端到端控制
• 流量基于窗口更新帧进行，接收方可广播准备接收字节数甚至对整个连接要接收的字节数
• 流量控制有方向性，接收方可以根据自身情况进行控制窗口大小
• 流量控制可以由接收方禁用，包括个别流和整个连接
• 只有DATA帧服从流量控制，其他类型帧不会消耗控制窗口的空间

（6）请求优先级

客户端可以通过在打开流的HEADERS帧中包含优先次序信息来为一个新流指定优先级。在其它任意时间，可以使用PRIORITY帧来改变流的优先级。每个流都可以带有一个31bit的优先值：0表示最高优先级；2的31次方-1表示最低优先级

（三）HTTP2的缺点：

• TCP 以及 TCP+TLS建立连接的延时

HTTP/2都是使用TCP协议来传输的，而如果使用HTTPS的话，还需要使用TLS协议进行安全传输，而使用TLS也需要一个握手过程，这样就需要有两个握手延迟过程。

• TCP的队头阻塞并没有彻底解决

TCP为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，HTTP/2出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该TCP连接中的所有请求。

（四）HTTP3的新特性

虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，主要是底层支撑的 TCP 协议造成的。

HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。

因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。

Google 已经意识到了这些问题，于是搞了一个基于 UDP 协议的“QUIC”协议，让HTTP跑在QUIC上而不是TCP上。而这个“HTTP over QUIC”就是HTTP/3。它在HTTP/2的基础上又实现了质的飞跃，真正“完美”地解决了“队头阻塞”问题。

• 实现了类似TCP的流量控制、传输可靠性的功能。
• 实现了快速握手功能
• 集成了TLS加密功能
• 多路复用，彻底解决TCP中队头阻塞的问题

四、TCP与UDP的区别？

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。

使用场景： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。

使用场景： 一般用于文件传输、发送和接收邮件、远程登录等场景。

五、TCP 协议如何保证可靠传输？

• （1）应用数据被分割成 TCP 认为最适合发送的数据块。

• （2）TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

• （3）校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

• （4）TCP 的接收端会丢弃重复的数据。

• （5）流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）

• （6）拥塞控制： 当网络拥塞时，减少数据的发送。

• （7）ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

• （8）超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

六、在浏览器中输入url地址 ——> 显示主页的过程

总体来说分为以下几个过程：
（1）DNS解析
（2）TCP连接
（3）发送HTTP请求
（4）服务器处理请求并返回HTTP报文
（5）浏览器解析渲染页面
（6）连接结束

具体可以参考下面这篇文章：
https://segmentfault.com/a/1190000006879700

七、常见状态码？

301状态码：代表永久性转移(Permanently Moved)
使用场景：
1）域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
2）在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。
3）空间服务器不稳定，换空间的时候。

302状态码：代表暂时性转移(Temporarily Moved )

tip：尽量使用301状态码进行转移提示
302 重定向和网址劫持（URL hijacking）
从网址A 做一个302 重定向到网址B 时，主机服务器的隐含意思是网址A 随时有可能改主意，重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下，当收到302重定向时，一般只要去抓取目标网址就可以了，也就是说网址B。如果搜索引擎在遇到302 转向时，百分之百的都抓取目标网址B 的话，就不用担心网址URL 劫持了。问题就在于，有的时候搜索引擎，尤其是Google，并不能总是抓取目标网址。比如说，有的时候A 网址很短，但是它做了一个302重定向到B网址，而B网址是一个很长的乱七八糟的URL网址，甚至还有可能包含一些问号之类的参数。很自然的，A网址更加用户友好，而B网址既难看，又不用户友好。这时Google很有可能会仍然显示网址A。由于搜索引擎排名算法只是程序而不是人，在遇到302重定向的时候，并不能像人一样的去准确判定哪一个网址更适当，这就造成了网址URL劫持的可能性。也就是说，一个不道德的人在他自己的网址A做一个302重定向到你的网址B，出于某种原因， Google搜索结果所显示的仍然是网址A，但是所用的网页内容却是你的网址B上的内容，这种情况就叫做网址URL 劫持。你辛辛苦苦所写的内容就这样被别人偷走了。302重定向所造成的网址URL劫持现象，已经存在一段时间了。不过到目前为止，似乎也没有什么更好的解决方法。

八、Cookie的作用是什么?和Session有什么区别？

（1）Cookie 一般用来保存用户信息， 比如：
①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
③登录一次网站后访问网站其他页面不需要重新登录。

Session 的主要作用就是通过服务端记录用户的状态。
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

（2）Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

本文参考来源：

两张动图-彻底明白TCP的三次握手与四次挥手
JavaGuide面试突击版
解读HTTP/2与HTTP/3 的新特性（推荐）