UDP与TCP高频面试题

1，特点与区别

UDP(用户数据报协议)：无连接，不可靠（没有超时重发，收到数据不用恢复确认，导致无序丢包），快，面向数据报（对应用程序传下来的报文不合并也不拆分，只添加UDP首部），没有拥塞控制，支持1:1,1:n,n:1,n:n。
TCP(传输控制协议)：面向连接，可靠，慢，面向字节流（对应用程序传下来的报文看成字节流，组织成大小不等的数据块），有流量控制，拥塞控制，提供全双工通信，支持1:1。

2，TCP的三次握手和四次挥手

-----> 见我的另一篇文章

3， TCP短连接和长连接区别与应用场景

短连接：完成一次读写后就可以关闭了，管理简单，不需要额外控制手段；【web网站的http服务，客户端数量级太大，服务器端资源占用是个问题，所以需要短连接】
长连接：完成一次读写后他们的连接不会主动关闭，后续读写操作可以继续使用这个连接；【多用于操作频繁，点对点的通信，数据库的连接】

4，两个PC通过TCP发送文件的数据封装过程（数据解封）

传输层：文件被分成多个数据段，每个数据段加上TCP首部（主要包括目的端口和源端口），变成TCP报文段；
网络层：每个报文段加上IP数据包首部（主要包括目的IP，源IP），变成数据包；
数据链路层：数据包加上目标MAC与源MAC，变成数据帧；
物理层：将帧变成比特流。

5，TCP粘包（粘段更确切？），拆包

注：UDP面向数据报，UDP首部用16bit来标识报文长度，因此在应用层能将不同的报文区分开，从而避免粘包与拆包问题。
TCP面向字节流，在应用层和传输层之间交互是大小不同的数据块，TCP报文段首部没有标识报文长度的字段。
原因：
1，待发送数据大于TCP发送缓冲区剩余空间大小，将发生拆包；
2，待发送数据大于MSS，TCP在传输前将进行拆包；
3，要发送的数据小于TCP发送缓冲区，TCP将缓冲区中多个数据一次性发出，将会粘包；
4，接收端的数据层没有及时读取缓冲区中的数据（流量控制/拥塞控制），将会发生粘包；
解决办法：
1，消息定长：发送端将数据包封装固定长度（不够补0），这样接收端读取固定长度的数据即可；
2，设置消息边界：在包尾增加换行符等特殊标志进行分割，如FTP协议；
3，增加标识报文段长度的字段；

6，TCP可靠传输

实现技术：超时重传（往返时间：RTT）

7，TCP滑动窗口

窗口是缓存的一部分，用来暂存数据流，发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己窗口的大小，发送方根据这个值和其他信息设置自己窗口大小。
如果发送窗口左侧的字节已经发送且收到了确认，那么就将窗口向右滑动直到窗口左边第一个字节不是“已发送且确认”的状态。接收窗口类似，接收窗口只会对窗口内最后一个按序到达的字节进行确认，（5,6,7,9,8。只会对7确认）。发送方收到确认就知道这个字节前的都已被接收。

8，流量控制

控制发送方发送速率，保证接收方来得及接收。
解决方案：
接收方发送的确认报文里的窗口字段可以控制发送窗口的大小，从而影响发送效率，将窗口字段设为0，则发送方不能发送数据，实际上为防止这死锁问题发生，发送端会定时发送一个叫做窗口探测的数据段，此数据段仅包含一个字节来获取最新的窗口大小信息。

9，拥塞控制

控制发送方发送速率，降低整个网络的拥塞程度（网络出现拥塞，分组将会丢失，此时发送方会重新发送，进而加剧网络拥塞）
解决方案：（慢开始，拥塞避免，快重传，快恢复）

慢开始与拥塞避免
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。

快重传与快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。
在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

10，定时器

1，超时重发定时器
每发送一个报文段就会启动重传定时器，如果在定时器时间到后还没收到对该报文段的确认，就重传该报文段，并将重传定时器复位。如果在定时器时间内收到确认则撤销该报文段的重传定时器。
2，保活定时器
检测TCP连接是否还正常连接。服务器端为了资源需要定时清理掉断开的TCP连接，每收到一个数据后就重置定时器，如果定时器超过2h，就会发送一个检测报文给客户端，如果连续10个检测报文(间隔几秒)都没收到回复，则终止连接。
3，坚持定时器
当发送窗口大小成为0时，发送方会启动定时器，时间到时会发送窗口检测报文。
4，2MSL定时器
在四次挥手中，主动断开方在发出最后一次确认后（最后一次挥手），会进入time_wait状态，这时候会启动定时器，时间到时会进入close状态，作用是在断开TCP连接前，确保发送的最后一个ACK报文能到达对方（ACK包丢失的话，被断开连接方会重发Fin报文），并防止新建的TCP连接错误识别因为网络延迟导致的旧数据（2MSL是数据包能生存的最长时间）。