TCP协议详解 一文读懂TCP协议段格式|每日热闻

文章目录

(相关资料图)

TCP协议段格式TCP原理确认应答机制超时重传机制连接管理机制三次握手：四次挥手： 滑动窗口如果出现丢包，如何进行重传？ 流量控制拥塞控制延迟应答捎带应答 粘包问题TCP异常情况 TCP，即Transmission Control Protocol，传输控制协议，对数据的传输进行详细的控制。

TCP协议段格式

源/目的端口号：表示数据从哪个进程来，到那个进程去。 源端口号表示报文的发送端口，源端口号和源IP地址组合起来可以表示报文的发送地址。 目的端口表示报文的接收端口，目的端口和目的IP地址组合起来可以表示报文的接收地址。 TCP协议就是根据IP协议的基础上传输的，TCP报文中的源端口号+源IP，与TCP报文中的目的端口号+目的IP一起，组合起来唯一性的确定一条TCP连接。 序号（Sequence Number）：TCP传输过程中，在发送端出的字节流中，传输报文中的数据部分的每一个字节都有它的编号。序号（Sequence Number）占32位，发起方发送数据时，都需要标记序号。 在数据传输过程中，TCP协议通过序号（Sequence Number）对上层提供有序的数据流。发送端可以用序号来跟踪发送的数据量；接收端可以用序号识别出重复接收到的TCP包，从而丢弃重复包；对于乱序的数据包，接收端也可以依靠序号对其进行排序。 序号会根据SYN是否为1，表示不同的意思： 当SYN为1时，当前为建立连接阶段； 当SYN为0是，数据传输正式开始。 确认序号（Acknowledgment Number）：确认序号标识了报文接收端期望接收的字节序列。如果设置了ACK控制位，确认序号的值表示一个准备接收的包的序列号，注意，它所指向的是准备接收的包，也就是下一个期望接收的包的序列号。 4位TCP报头长度：表示TCP头部有多少个32位bit（4字节）；所以TCP头部最大长度为 15 * 4 = 60字节。 6位标志位：

URG：紧急指针是否有效；ACK：确认号是否有效，ACK置 1 ，代表起到了确认作用，需要填写确认序列号（下一次期望收到第一个字节的序列号）；PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走；RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段；SYN：请求建立连接，我们把携带SYN标识的成为同步报文段；FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。

窗口大小：长度为16位，共2个字节。此字段用来进行流量控制。流量控制的单位为字节数，这个值是本端期望一次接收的字节数。 １６位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题，此处的检验和不光包含TCP首部，也包含TCP数据部分。 16位紧急指针：标识那部分数据是紧急数据。

TCP原理

TCP对数据传输提供的管控机制，主要体现在两个方面：安全、效率。 这些机制和多线程的设计原则类似：保证数据传输的安全前提下，尽可能地提高传续效率。

确认应答机制

TCP将每个字节的数据进行了编号，即序列号。 每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了那些数据，下一次你从哪里开始给我发。

超时重传机制

主机A给主机B发送了数据之后，可能会因为网络拥堵等原因，数据无法发送到B，如果A在一个特定的时间间隔内没有收到B发来的确认应答，就会重新发送。 当然，A没有收到确认应答，也可能是ACK丢了。因此，主机B会收到很多重复数据，可以利用序列号做到去重的效果。 那么超时时间如何确定？

TCP为了保证无论在任何环境下都能比较高效地通信，因此会动态计算这个最大超时时间。

连接管理机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

三次握手：

第一次握手：客户端进入SYN_SENT状态，发送一个SYN帧来主动打开传输通道，该帧的SYN标志位被设置为1，同时会带上Client分配好的SN序列号，该SN是根据时间产生的一个随机值。第二次握手：服务端在收到SYN帧之后，会进入SYN_RCVD状态，同时返回SYN+ACK帧给客户端，主要目的在于通知客户端，服务端已经收到SYN消息，现在需要进行确认。 服务端发出的SYN+ACK帧的ACK标志位被设置为1，其确认序号ASN值被设置为客户端的SN+1；SYN+ACK帧的SYN标志位被设置为1，SN值为服务端生成的SN序号。第三次握手：客户端在收到服务端的第二次握手的SYN+ACK确认帧之后，首先将自己的状态会从SYN_SENT变成ESTABLISHED，表示自己方向的连接通道已经建立成功，客户端可以发送数据给服务端了。然后，客户端发ACK帧给服务端，该ACK帧的ACK标志位被设置为1，其确认序号ASN值被设置为服务端的SN序列号+1。服务端收到客户端的ACK之后，会从SYN_RCVD状态变成ESTABLISHED状态，至此，TCP全双工连接建立完成。

四次挥手：

第一次挥手：主动断开方向对方发送一个FIN结束请求报文，此报文的FIN位被设置为1，发送完成后，主动断开方进入FIN_WAIT_1状态，这表示主动断开方没有业务数据要发送给对方，准备关闭SOCKET连接了。第二次挥手：正常情况下，在收到了主动断开方发送的FIN断开请求报文后，被动断开方会发送一个ACK响应报文，之后，被动断开方就进入了CLOSE-WAIT（关闭等待）状态，TCP协议服务会通知高层的应用进程，对方向本地方向的连接已经关闭，对方已经没有数据要发送了，若本地还要发送数据给对方，对方依然会接受。被动断开方的CLOSE-WAIT（关闭等待）还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。第三次挥手：在发送完成ACK报文后，被动断开方还可以继续完成业务数据的发送，待剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后，被动断开方进入LAST_ACK状态。第四次挥手：主动断开方收在到FIN+ACK断开响应报文后，还需要进行最后的确认，向被动断开方发送一个ACK确认报文，然后，自己就进入TIME_WAIT状态，等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方，在等待完成2MSL的时间后，如果期间没有收到其他报文，则证明对方已正常关闭，主动断开方的连接最终关闭。 被动断开方在收到主动断开方的最后的ACK报文以后，最终关闭了连接。

TCP状态转换汇总：

滑动窗口

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。 既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

如果出现丢包，如何进行重传？

情况一：数据包已经抵达，ACK被丢了

情况二：数据包就直接丢了

流量控制

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

接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息。

拥塞控制

TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。慢启动，只是初始时慢，增长的很快

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞; 当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降; 拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

每隔N个包就要应答一次，或者超过最大应答时间也要应答一次。 N一般取2，超时时间取200ms。 窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

捎带应答

粘包问题

对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；对于变长的包，还可以在包和包之间使用明确的分隔符。

TCP异常情况

进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。 机器重启：和进程终止的情况相同。 机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对 方不在，也会把连接释放。

另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。 例如QQ，在QQ断线之后，也会定期尝试重新连接。

TCP ： 可靠、有连接、面向字节流