计算机网络面试题汇总（快拿去背吧）

三次握手 四次挥手

三握四挥是计算机网络中可以说是最高频的考点了

三次握手

第一次握手： 建立连接的时候，客户端A向客户端B发送SYN包，并且进入SUN_SEND状态 等B服务器B确认
第二次握手： 服务器B收到A发送的SYN包，确认A发送的SYN包，然后向A发送一个SYN+ACK包 而且B进入SYN_RECV状态
第三次握手： 服务器A收到ACK_SYN包，然后向B发送ACK包 并且客户端A和B都进入RSTABLISHED状态

三次握手完成

为什么是三次呢？不是两次或者是四次

这时我们就需要仔细分析一下
1.第一次握手，客户端发送网络包，服务器端收到了，
服务器端得出结论：客户端的发送没毛病，服务器端自己的接收没毛病

2.第二次握手 服务器端发送包，客户端接收包
这样客户端就能得出结论，首先服务器端发送没毛病 客户端自己接收没毛病
然后客户端可能会想到，既然服务器端能给我发送包 说明第一次我给服务器端发送的消息他收到了
所以客户端又得到结论 自己的发送没毛病 服务器端接收没毛病
（此时客户端这里得出了：自己发送接收没毛病，服务器发送接收没毛病
服务器端仅仅知道客户端发送没毛病，自己接收没毛病，所以要进行下一项）

3.第三次握手 客户端发送包，服务器端接收包
这样服务器端得出结论 客户端收到了自己第二次发的包 所以他知道自己的发送没毛病 客户端接收没毛病

此时客户端和服务器端都确保了自己以及对方的接收和发送的能力 即可进行正常通信！

举个例子

假如一次地震中有两个人受伤了 但是他两的听觉和声带都没有损坏 但是他两又不能确定自己的听觉和声带有没有损坏
于是一个人大喊了一声 有人吗 这时候另一个人听到了 （第一次发送）于是第二个人确定 第一个人的声带没问题 并且自己的听觉没问题
然后第二个人大喊了一声：有人 你受伤了吗？ （第二次发送）
这个时候第一个人听到了，于是第一个人得到结论 第二个人声带没问题 自己听觉没问题
而且由于第二个人是回答自己的 所以它还可以知道自己声带没问题 对方听觉没问题
这个时候 第一个人知道了 自己声带 听觉 没问题 对方声带 听觉没问题
第二个人只知道自己听觉没问题，对方声带没问题 暂时无法确定自己的声带和对方的听觉 所以就需要第三次传输

然后第一个人为了和对方继续沟通 获得生还的可能 大喊：我没事 你呢？（第三次发送）
第二个人听到之后 非常激动 因为他确定自己的声带 和听觉都没问题 对方也一样
他两可以无障碍的正常沟通 ！！！

上边就是我举的例子 希望可以加深大家对他的理解

四次挥手

1.客户端发送一个FIN，用来关闭客户端到服务器的数据传送，此后客户端进入FIN_WAIT_1状态。
2.服务器收到FIN后，进入CLOSE_WAIT状态。正常情况下会发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），
3.服务器发送一个FIN，用来关闭服务器到客户端的数据传送，服务器进入LAST_ACK状态。
客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务器，确认序号为收到序号+1，服务器进入CLOSED状态，完成四次挥手。
四次挥手结束

为什么是四次挥手

1.Tcp连接是双向传输的对等的模式，就是说双方都可以同时想对方发送或者接收数据
当有一方向要关闭连接的时候，会告知对方，我要关闭连接了
2.这时候对方会回一个ACK，此时一个方向关闭连接，但是另一个方向仍然可以继续传输数据
也就是说服务端收到客户端的FIN标志，知道客户端想要断开连接
但是服务端如果还想继续发送数据，就等发完所有数据之后，发送一个FIN标志关闭此方向上的连接

3.客户端发送了FIN连接释放报文之后，服务器收到了这个报文，进入close_wait状态
这个状态为了服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送FIN连接释放报文

流量控制

什么是流量控制？

防止发送方发送太快，耗尽接收方资源，从而使得接收方来不及处理

流量控制的一些知识点

接收端抑制发送端的依据：接收端缓冲区的大小
流量控制的目标是接收端，怕接收端来不及处理
流量控制的机制是丢包

怎么实现流量控制？

滑动窗口

类似于窗口一样的东西，用来告诉发送端可以发送数据的大小或者是窗口标记了接收端缓冲区的大小

对于每一个发送的数据段，都要一个ACK确认应答，收到ACK才能发送下一个数据段
这样做有缺点：性能比较差，尤其是数据往返时间长的时候

使用滑动窗口就可以一次性发送多条数据 从而提高性能

注意：

1.接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK来通知发送端
2.窗口大小字段越大，网络的吞吐量越大
3.窗口大小指的是无需等待确认应答就可以继续发送数据的最大值
4.操作系统为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有哪些数据没有应答，只有确认应答的数据 才能从缓冲区删去
5.接收端一旦发现缓冲区快满了，就会将窗口设置成为一个更小的值通知给发送端，发送端收到这个值后，就会减慢发送速度
6.如果接收端发现自己的缓冲区快满了，就会将窗口设置为0，此时就不会再发送数据（需要长期发送一个窗口探测数据段，使得接收端把窗口大小告诉发送端）

优点：

可以更加高效可靠的发送大量的数据

拥塞控制

什么是拥塞控制

防止发送方发送太快，网络来不及处理，导致网络拥堵

加法增加

执行拥塞避免算法之后 收到所有报文段确认之后，那这个拥塞窗口增加一定的大小，使得拥塞窗口缓慢增大，防止网络过早出现拥塞

乘法减少

出现一次超时（一次网络拥塞）就把慢开始门限制值设置为当前拥塞窗口值的一半
（当网络出现频繁拥塞的时候，窗口值就会下降的很快，以大大减少注入网络的分组数）

流量控制虽然可以高效可靠的传送大量的数据，但是如果刚开始就发送大量的数据
很可能产生拥堵的现象

拥塞控制产生的表现：丢包 延时边长

流量控制和拥塞控制的异同

相同点：

现象都是丢包
实现机制 都是让发送发发送的速率减慢，发的少一点

不同点：

丢包的位置不同：
流量控制丢包是在接收端上
拥塞控制丢包实在路由器上

作用的对象不同：
流量控制对象时接收方，怕发送方发送条块，接收方来不及处理
拥塞控制对象时网络，怕发送太快 造成网络拥堵，造成网络拥塞，使得网络来不及处理

联系

拥塞控制：
拥塞控制通常是表示一个全局性的过程，
他会涉及到网络中所有的主机所有的路由器和降低网络传输性能的全部因素

流量控制：
流量控制发生在发送端和接收端之间，仅仅是点到点之间的控制

UDP可靠化

为什么UDP要可靠化？

TCP基于公平性的可靠通信协议，但是在一些苛刻的网络条件下TCP可能不能保证正常的通信，要么成本过高
之所以在UDP上做可靠保证，就是为了保证通信的时延和质量的条件下，降低成本
实质上实现UDP的可靠化就是在UDP的基础上尽量实现TCP

UDP想要实现可靠，首先要在接收方收到UDP的包之后回复确认包
发送方实现丢包重传：收不到确认包的时候，重新发送，每个包都有递增序号，接收方发现中间丢包就重新发送请求
如果网络太差频繁丢包，防止越丢包，越重传的恶性循环，要有个发送窗口的机制，发送窗口的大小根据网络情况调整

这样我们就可以理解为在应用层实现了TCP

粘包拆包的产生以及解决

原因：

1.发送的数据大于TCP发送缓冲区剩余的空间大小，将发生拆包
2.发送的数据大于最大报文长度，发生拆包
3.发送的数据小于TCP发送缓冲区的大小，TCP多次写入缓冲区 然后一次发送出去，发生粘包
4.接收数据端的应用层没有及时的读取接收缓冲区的数据，发生粘包

解决

1.**消息定长：**发送端每个数据包封装为固定长度（不够用0补充）
这样接收端每次接收缓冲区中读取固定长度的数据就自然把每个数据包分开
2.**设置消息边界：**服务端从网络流中按消息边界分离出消息内容，在包尾增加回车换行符进行分割
3.**将消息分为消息头和消息体：**消息头中包含表示消息总长度的字段

TCP的超时重传机制

TCP是一种面相连接的传输，他保证可靠传输的一个基本原理就是发送一个数据之后，开启一个定时器
如果在这个时间内没有收到刚刚发送数据的ACK确认报文，就对该报文进行重传
如果一直失败，尝试一定次数之后，放弃并发送一个复位信号

所以这个定时器的实现和关键
如果这个定时器过小，那么部分报文可能遇到网络拥堵的情况，或者是延迟过大的情况，这样就会频繁重传
如果定时器过大的话，那么发送端需要等待过长的时间才能发现数据丢失，影响网络的传输效率
造成的表象就是后端系统相应时间过长甚至超时

重传定时器

下面两种情况是可能发生的
1.如果在定时器截止时间到之前，收到了报文段的确认，则撤销该计时器
2.如果收到报文段确认之前，计时器截止时间到，那么重传此报文段，并将计时器复位

坚持计时器

先考虑一个场景：
发送端向接收端发送数据包直到接收窗口填满，然后接收窗口告诉发送方接收窗口填满了，请停止发送数据
此时的状态称为“零窗口状态”
发送端和接收端此时窗口大小均为0，直到接收TCP发送确认并宣布一个非零的窗口的大小，但是这个确认会丢失

TCP的发送是不需要确认发送的，如果确认丢失了，就收TCP并不知道，他认为它的工作已经结束了
并等待着发送端继续发送更多的报文段，但是发送端在等待对方确认
这样就产生了死锁，双方都在等待对方

所以就需要坚持计时器
当发送TCP收到窗口大小为0的确认的时候，启动坚持计时器，当坚持计时器到期限的时候，发送TCP发送一个特殊的报文段
探测报文,这个报文段只有一个字节的数据，他有一个序号，但是它的序号不需要确认，
探测报文段提醒接收段，确认丢失，必须重传
坚持计时器的值设置为重传时间的数值，，但是如果没有收到接收端来的响应，
则再发送一个探测报文，并将坚持计时器的值加倍以及复位
发送端继续发送探测报文段 直至这个值增大到最大值为止
之后每过最大值 发送一个探测报文 直至窗口重新打开

保活计时器

防止两个tcp之间的连接出现长时间的空闲
假定客户端建立了服务器的连接，发送了一些数据，然后保持静默
也许客户端发生故障，在这种情况下，这个连接将永远处理打开状态

设置保活计时器每当服务器收到客户的信息，就将计时器复位
如果服务器过了计时器的极限，还没有收到客户端的信息
他就发送探测报文段
如果发送了10个探测报文段还没有反应
就假定客户端发生故障，中止该连接，不会采用四次挥手，直接硬性中断客户端的TCP连接

TCP如何保证可靠传输的

检验和

通过检验和的方式，接收端可以检测出来数据时候有差错和异常，假如产生差错就会直接丢弃TCP段
重新发送，TCP在计算检验和的时候，会在TCP首部加上一个12字节的伪首部，检验和共计算三次
TCP首部，TCP数据，TCP伪首部

序列号、确认应答

这个机制类似于问答的形式，比如上课老师问你：听明白了吗？
假如你么有隔一段时间回应，或者是说明白或者不明白，老师就会重新讲一遍
计算机机制也是这样的，
发送端发送信息给接收端，接收端回应一个包，这个包就是答包

只要发送端有一个包传输，接收端没有回应确认包（ACK），都会重发，
或者接收端的应答包，发送端没有收到也会重发数据，这就保障了数据的完整性

超时重传机制（上边已经细说了）

最大消息长度

在建立TCP的时候，双方约定一个最大的长度，作为发送的单位，重传的时候也是以这个单位来进行重传
理想的情况就是该长度的数据刚好不被网络层分块

我们可以理解为双方先约定，后决定，之后进行

滑动窗口控制

我们上边提高超时重传的机制存在效率低下的问题
发送一个包到发送下一个包要经过一段时间才可以，
所以我们要想办法实现，如果不用等待确认包就可以发送下一个数据包呢？
这就是滑动窗口解决的问题

窗口的大小就是在无需等待确认包的情况下，发送端还能发送最大数据量，
这个机制实现就是使用了大量的缓冲区，通过对多个段进行确认应答的功能。
通过下一次的确认可以判断接收端是否接收到数据
如果接收到数据，就将其从缓冲区中删除

拥塞控制

滑动窗口解决了两台主机之间因为传送速率的丢包的问题
在一方面保证了TCP数据传输的可靠性
如果网络拥堵 此时继续发送数据会加重网络负担
这时候发送的数据段很可能超过了最大生存时间没有达到接收方
产生丢包问题

因此TCP引入慢启动机制，先发出少量数据，探探路，然后再决定以多少的速度传输

发送开始定义拥塞窗口为1，每次收到一个ACK就加一，
每次发送数据的时候，发送窗口取拥塞窗口和接收端接收窗口最小值

先按指数增长，到达一个阈值按线性增长
如果遭遇拥堵 立即设置为1，重新开始 新的阈值为原来的一半