当前位置：首页 > news >正文

TCP、流量控制、滑动窗口、拥塞控制等

news 来源：原创 2025/5/23 7:55:25

传输控制协议（TCP，TransmissionControl Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP协议段格式为：

源/目的端口号：表示数据是从哪个进程来，到哪个进程去。

4位首部长度：表示该TCP报头有多少字节，最大为15×4=60字节，最小为标准长度是20字节。

16位校验和：发送端填充，CRC校验；接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。

6个标志位：

URG: 紧急指针是否有效(当URG置1时，说明发送的数据中有需要尽快处理的数据，这时去16位紧急指针看，该位置存的是在有效载荷中的偏移量，即能找到紧急数据的起始位置)

ACK: 确认号是否有效

PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走(当接收方的接收缓冲区满时，发送方不能再发数据，那么发送方会轮询发送不携带数据的报文来确认对方的接收缓冲区是否有空间，这时就将PSH置1)

RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段(假如开始的时候客户端和服务器端的连接是正常的，突然服务器重启了，这时服务端就认为和客户端断开了连接，但是客户端还认为连接是正常的，那么就会正常向服务器发起请求，而服务器收到客户端的请求发现自己并没有与该客户端连接，就会设置RST为1，要求客户端重新三次握手建立连接)

SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段(进行三次握手时置1)

FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段(进行四次挥手时置1)

在网络传输时，由于传输的距离很长，就导致了不可靠问题的出现，如：丢包、乱序、重复等；所以我们需要一定的措施来保证传输的可靠性。

1. 确认应答(ACK)机制：

我们认为，当发送的数据包，只有收到了对方的确认应答，才算可靠；但是双方通信，一定存在最新的数据，没有应答 --- 最新消息一般无法保证可靠性；所以只存在相对的可靠性，没有绝对的可靠。

TCP将每个字节的数据都进行了编号，即为序列号，发送端会告诉接收端自己发送的数据的编号，而接收端收到后也会给发送端响应一个带有确认序号的ACK报文，表示自己已经收到了该序号前的所有数据，下次从哪里开始发。举个例子：

假设接收端响应的确认序号是1001；即表示已经收到了1001前所有的(注意是：连续的)报文，下次发送从1001开始发。这样发送端就可以知道自己发送的数据到底成功没有。

2. 超时重传机制：

分两种情况：

(1) 数据没有发送成功：主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；

(2) 数据发送成功：主机A未收到B发来的确认应答，也可能是因为ACK丢失了；那么同样主机A会重发数据，这时主机B收到后会重新响应ACK；不过这样主机B就收到了很多的重发报文，但是由于序列号的存在，也可以很容易的做到去重的效果。

三次握手：

三次握手是由客户端connect时发起的：

第一次握手：TCP客户端向服务器发出连接请求报文，这是报文首部中的SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT 同步已发送状态

第二次握手：TCP服务器收到请求报文后，如果同意连接，则会向客户端发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了 SYN-RCVD 同步收到状态

第三次握手：TCP客户端收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED已建立连接状态。

四次挥手：

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态；以客户端主动关闭，服务器被动关闭为例：

第一次挥手：客户端发出连接释放报文，停止发送数据。释放连接报文首部，FIN=1，其序列号为seq=x（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态

第二次挥手：服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=x+1，此时，服务端就进入了CLOSE-WAIT 关闭等待状态

第三次挥手：客户端接收到服务器端的确认请求后，客户端就会进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文（FIN=1，seq=y），服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=y+1，此时，客户端就进入了TIME-WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL后（最长报文寿命），客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成

为什么客户端要等待2MSL？
主要原因是为了保证客户端最后发送的那个ACK报文能到到服务器，因为这个ACK报文可能丢失。

流量控制：

接收端处理数据的速度是有限的；如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)。

所以在报头中的16位窗口大小就是为了进行流量控制，双方通信时，会实时的交换自己的接收缓冲区剩余空间大小，从而实现让对方发送数据的多少控制。因为在通信前要发起三次握手，所以最初的大小在三次握手时就可以得到，然后后续就能正常通信。

滑动窗口：

可以将发送缓冲区抽象看成上面的四部分，图中画的是线性的，其实实际是环形的，对于已发送并且收到应答的数据删除其实就是覆盖操作，直接再写入即可。

窗口的起始和结束位置；TCP_WIN是对方的接收能力；只有当收到对方的确认应答报文后，滑动窗口的start才会右移，否则不动，因为发送完数据后，该数据还有可能丢失，到时会引发超时重传操作，对可能丢失的数据应该暂时保存起来，这些数据就保存在发送缓冲区。

这里还有一个知识是快速重传：

因为在发送数据时不是串行的过程，并不是发送一个，收到确认报文后再发送下一个，这样的效率很慢，实际上是发送端可以发送很多数据包，比如一下发送了4个数据包，序号分别是1000、2000、3000、4000；然后服务端就会给发送端响应确认报文，如果都收到，则服务端会响应4个报文，确认序号分别的1001、2001、3001、4001；这时如果中间某些丢失了，但是只要发送端收到了4001这个报文，就可以确认刚刚发送的全部成功了，因为确认序号的定义是，该序号前所有连续的都收到了，所以表达的意思是4001前的全部收到了。但是假如发送端发送的中间某一个丢包了，也不用担心，假设是2000的丢包了，那么其他后面的3个都收到了，服务端的响应报文的确认序号也只会是1001；那么当连续收到3个以上相同的确认报文时，这时就认为有报文丢失了，就会引发快速重传。