无奈被怼了，赶紧梳理一下自己关于tcp和udp所了解的内容
TCP
TCP是面向连接的传输层协议，可以提供可保的传输服务。而且，TCP提供面向流的全双工通信。
TCP在发送数据前需要经过三次握手建立TCP连接，在建立连接的两端都维护这一个发送缓冲区和接受缓冲区，所以TCP可以实现全双工通信。
TCP报文段首部协议格式
为了方便后面讨论，附上《计算机网络第七版谢希仁》中关于TCP报文段首部协议格式的描述图片。
TCP可靠传输
传输层将数据交给IP层（网际层/网络层）进行传送。IP层只能提供尽最大努力将数据送达的服务，即不可靠的服务。
所以，TCP协议需要保证数据的可靠性。
首部校验和
首部校验和对应TCP首部协议格式中的校验和字段，占两个字节。由发送端在发送时计算校验和，由接收端进行校验。若校验不通过则丢弃该报文段。
注意在计算校验和时需要在TCP协议头前面加上12个字节的IP伪首部。
--------------------------------------------------------
| source address (4byte) |
--------------------------------------------------------
| dest address (4byte) |
--------------------------------------------------------
| zeros (1byte) | protocol (1byte) | tcp length (2byte) |
--------------------------------------------------------
校验和的计算方式在RFC 793中有明确描述。如下
Checksum: 16 bits
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text. If a
segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes. The pad is not
transmitted as part of the segment. While computing the checksum,
the checksum field itself is replaced with zeros.
我在20年的实现过该计算校验和的算法，附上链接
https://blog.csdn.net/weixin_42555551/article/details/106714478?spm=1001.2014.3001.5501
序列号和确认号（确认应答机制）
TCP首部协议格式有序列号和确认号两个字段，发送端会给每个报文段分配一个序列号。当发送端接收到该报文段，会通过序列号通知发送端接受成功。
重传
主要有两种方式，超时重传和快速重传
超时重传
超时重传，发送端在报文段发送的时候，会设定一个计时器，在计时器结束之前没有收到接收端的ACK报文，就认为产生了丢包，发送端重发这个报文段。
丢包的情况可以分为两种，①发送端发送的报文段丢包；②接收端发送的ACK报文丢包。
超时重传需要设置一个RTO（retransmission timeout）重传时间（超时时间）。RTO的设置要略大于RTT（round-trip time）往返时间，即报文段从发送端到接收端，再到发送端的一个往返时间。
起初RTO略大于RTT，当一个报文段超时一次，就会将RTO翻倍。
快速重传
快速重传，当接收端收到比预期序列号大的情况下，就向发送端发送一个冗余ACK指明下一个期望收到的序列号报文段。
应用情况，当发送端的报文端丢包时，接收端没有收到该报文段，但是收到的后续的报文段。
但是，此时出现一个问题。每次发送端接收到ACK报文才发送下一个报文段，未免效率太低下了。所以引入了滑动窗口。
滑动窗口
实质上是一块缓冲区，发送端会连续发送多个报文段，未收到确认的报文段都会存储在缓冲区里，当发送端接受到确认报文，就从缓冲区中将该报文清除。
这时候就会引发一个问题，假设发送缓冲区有序列号为x-3、x-2、x-1、x、x+1、x+2、x+3的报文段，发送端没有收到x-3、x-2、x-1的ACK，却收到了x的ACK。此时就引发了一些列问题。
于是又引入了另一个机制，
累计确认机制，当接收端连续接收到了序列号x-3、x-2、x-1、x的报文段，接收端就会发送x+1的ACK，表示x+1之前的报文段都确认，接收端下次期望接受x+1。
这时候接收端接收到x+1ACK，表示x-3至x都已确认，发送端滑动窗口移动（不考录滑动窗口大小变化），x+1、x+2、X+3、x+4、x+5、x+6、x+7
对于接收端，假设接收端没有收到x，但是收到了x+1，则启动快速重传，接收端发送xACK表示期望下一个接受x。当x+1前面的报文段全部接受后，接收端滑动窗口移动。
流量控制
流浪控制，主要是通过控制发送方的发送速率来实现，发送方的发送速率又由发送方发送缓冲区滑动窗口的大小决定。接收方在ACK报文中窗口字段设置自己接受缓冲区滑动窗口大小，来决定发送缓冲区滑动窗口大小。
拥塞控制
首先，区别流量控制和拥塞控制的区别。流量控制是为了让接收端来得及接受；拥塞控制是根据网络环境状态改变发送端的速率，降低网络环境的拥塞情况。
因此引入了拥塞窗口，此时，发送端发送缓冲区滑动窗口（发送窗口）大小=接受端接受缓冲区滑动窗口（接受窗口）大小+拥塞窗口大小
当网络环境出现拥塞后，拥塞窗口变小
网络环境没有拥塞，拥塞窗口变大
TCP拥塞控制采用下面四种算法
(1)慢启动。起初并不清楚网络环境状态，将拥塞窗口设为1，当没接收到一次ACK，就将拥塞窗口翻倍。当然，拥塞窗口的大小不能无线增大，当拥塞窗口的大小达到慢启动的阈值后，慢启动停止，采用拥塞避免。
(2)拥塞避免。没接收到一次ACK，将拥塞窗口大小加1。若发生超时重传，则将慢启动的阈值设为拥塞窗口大小的一半；拥塞控制窗口设为1。
(3)快重传。当发送端接受到连续三个相同的ACK报文时，重传接收端需要的报文，而不等待重传计时器超时。
(4)快恢复。当发送端接收到连续三个相同的ACK报文时，将慢启动阈值减半，拥塞窗口设为慢启动阈值，然后进入拥塞避免。核心思想是为了保证网络中的报文端数量恒定，即确认几个，发送几个。
UDP
UDP是无连接的，面向报文的，尽最大努力交付。
UDP将应用层的数据原封不动的封装交给IP层。当应用数据过长或过短都影响IP层的效率，需要应用程序控制UDP数据的大小。
UDP没有拥塞控制。支持一对多。发送效率高。
UDP首部只有8个字节。TCP首部为20个字节。
附上《计算机网络第七版谢希仁》中UDP用户数据报首部格式
