计算机网络高频面试题-TCP/UDP
一、TCP和UDP区别是什么
答：TCP 和 UDP协议都是传输层的
1、TCP面向连接的；UDP是无连接的，即发送数据之前不需要建立连接。
2、TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序列到达; 而UDP尽最大努力交付，不保证可靠交付。
3、TCP面向字节流（粘包问题），实际上是TCP把数据看成一连串的无结构的字节流；UDP是面向报文的；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。（对实时通话等）
4、每一条TCP连接只能是点到点的；UDP一对一，一对多，多对一和多对多的交互通信。
5、TCP首部开销20字节，UDP首部开销更小，只有8个字节。
小结：TCP可靠传输通过：序列号、确认应答、超时重传、流量控制、拥塞控制等方式实现了可靠传输。
TCP头部
TCP是如何保证可靠传输
1.应用数据被分割成TCP认为最适合的数据块
2.TCP给发送的每一个包进行编号，接受方对数据包进行排序，把有序数据传送给应用层。
3.校验和：TCP将保持它的首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中发送的任何变化。
如果收到端的校验有差错，服务端将丢弃这个报文段和不确认收到此报文段。
4.TCP的接收端会丢弃重复的数据
5.流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端 发送接收端缓冲区能接纳的数据。
当接收方来不及处理发送方的数据，能提示发送方降低速率，防止包丢失。TCP使用流量控制协议是可变大小的滑动窗口协议（TCP利用滑动窗口实现流量控制）
6.拥塞控制：当网络拥塞时，减少数据的发送，四种算法（慢开始，快重传，快恢复，拥塞避免）
7.ARQ（automatic Repeat-reQuest，ARQ）协议：为了实现可靠传输，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
如果过了一段时间，还是没有收到ACK确认，说明没有发送成功，需要重新发送，知道收到确认后，才会发送下一组分组。
8.超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到的这个报文段，如果不能及时收到一个确认，将重发这个报文段。
二、TCP的三次握手和四次挥手
三次握手
1、客户端、服务端首先都处于CLOSED状态。服务端打开某个服务后会主动监听某个端口，处于LISTEN状态
2、客户端 请求服务器会随机初始化序号，将此序号置于TCP首部的【序号】字段中，同时把SYN标志位置置为1
表示SYN报文。接着把一个SYN报文发送给服务端，向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN-SEND状态
3、服务端收到客户端的SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入TCP首部的【序号中】其次把TCP首部的【确认应答号】字段填入
client_isn+1，接着置SYN=1，ACK=1。最后把该报文发送给客户端，该报文也不包含应用层数据，之后服务端处于SYN-RECEIVED。
4、客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先硬蛋报文TCP首部ACK标志位1，其次确认应答号server_isn+1，最后把报文发送给服务端，这次报文可以
携带客户到服务端的数据，之后处于ESTABLISHED状态
5、服务端收到应答报文后，也进入了ESTABLISHED状态。
四次握手
1、客户端打算关闭连接，此时发送一个TCP首部FIN标志位被置为1的报文，也即FIN报文，之后客户端进FIN_WAIT_1状态
2、服务端收到该报文，就向客户端发送ACK应答报文，接着进入CLOSED_WAIT状态。
3、客户端收到服务端ACK应答报文后，之后进入FIN_WAIT_2状态
4、等待服务端处理完数据后，也向客户端发送FIN报文，之后服务端进入LAST_ACK状态。
5、客户端收到服务端的FIN报文后，回一个ACK应答报文进入TIME_WAIT状态
6、服务端收到ACK应答报文后，进入CLOSED状态，至此关闭服务端
7、客户端在经过2MSL一段时间后，自动进入CLOSED状态，至此客户端关闭连接。
追问：为什么不能是两次握手，或者四次握手的原因：
两次：无法防止历史连接的建立，会造成双方自愿的浪费，也无法可靠的同步双方序列号。
四次：三次握手理论上可以建立更少的连接，四次握手更多会增大开销，浪费计算机资源。
为什么TIME_WAIT等待的时间是2MSL？
MSL：报文最大生存时间，它是任何报文在网络上的存在的最长时间，超过这个时间报文会被丢弃。
TIME_WAIT等待2MSL 网络中可能存在来自发送方的数据包，当这些发送方的数据报备接收方处理后又会在向对方发送响应，所以一来一回是2MSL。 2倍的MSL时间
2MSL的时间客户端接受到FIN后发送ACK开始计时，如果TIME-WAIT时间内，因为客户端ACK没有传输到服务端，服务端会又发送FIN报文，客户端接受到了重发的FIN报文，那么2MSL时间重新计时。
LINUX中一般2MSL为60秒，一个MSL未30秒。
追问：为什么需要TIME_WAIT
防止相同的【四元组】的【旧】数据被收到；
保证【被动关闭连接】的一方能被正确的关闭，即保证最后的ACK能被被动关闭放收到，从而帮助其远程关闭。
追问：为什么要四次挥手
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。
只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手。
追问：TIME_WAIT过多的危害
1、内存资源占用过多 浪费
2、端口的占用，一个TCP连接至少消耗一个端口。
发送窗口=Min{接受窗口rwnd，拥塞窗口cwnd}
接受窗口：接收方根据接受缓存设置的值，并告知给发送方，反应接收方的容量
拥塞窗口：发送方根据自己估算的网络拥塞而设置的窗口值，反映网络当前的容量。
拥塞控制的算法：
1、慢开始（从0开始指数上升）：
2、拥塞避免（到达一定的门限阈值，使用加法增大）：
3、拥塞发生快速重传、收到冗余校验3次）：
4、快恢复（如图2不会从0开始，直接从cwnd的一半开始）：
TCP缺点：
1、因为是基于操作系统内核中实现的，只能使用它不能修改它。
2、TCP建立的连接有延迟，包括（HTTPS基于它）
3、TCP存在队头阻塞问题，必须保证有序，要是无序，是读取不到后面的，比如收到了12，3未收到，即使收到了456也不能打开456.
4、基于TCP传输协议的Http协议，由于通过四元组（源IP,源端口，目的IP，目的端口）确定一条TCP连接。
4G切换到wifi场景就会出现卡顿。 IP地址变化了等会重新连接。
如何基于UDP实现可靠传输
解决上述四个痛点：
1、QUIC实现可靠传输
1.1基于UDP实现可靠传输协议，那么就要在应用层下功夫，也就是要设计好协议头部字段。
1.2HTTP/3举例子，UDP报文头部与HTTP消息之间共有3层头部
1.3通过一下几个方面实现可靠传输
1.4QUIC实现可靠传输
QUIC使用的packet number单调递增，保证了RTT RTO计算准确一点，失败重传会导致RTT RTO不精确。
QUIC不会让数据包像TCP一样必须有序确认，QUIC支持乱序确认，当Packet NumberN 丢失后，只要有新的数据包确认就可以向右滑动。
1.3 QUIC Frame Header
QUIC解决TCP队头阻塞问题
TCP队头阻塞问题：1、发送窗口的队头阻塞 2、接收窗口的队头阻塞
发送窗口的队头阻塞：TCP发送出去的是数据都是按序确认的，只有在数据按顺U型确认后，发送窗口才会往前发送
接收窗口的队头阻塞：接收方收到了1，2序号的数据包，但是没有收到3，即使收到了45,也不能获取。
1.4QUIC做流量控制
1、Stream：每个 Stream 都有独立的滑动窗口，所以每个 Stream 都可以做流量控制，防止单个 Stream 消耗连接（Connection）的全部接收缓冲。
2、Connection流量控制：限制连接中所有 Stream 相加起来的总字节数，防止发送方超过连接的缓冲容量。
1.5拥塞控制的改进
1.6 QUIC更快的建立连接：
但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
1.7迁移功能
4G变wifi的时候，意味着IP变了，但是QUIC没有用四元组，通过绑定连接，通过连接id来标记通信的两个断点。无缝衔接。只要上下文没变，连接id tls等。
总结：QUIC解决了TCP的痛点并且保证了UDP可靠传输。
