TCP报文头（首部）详解

????????本篇文章基于?RFC 9293: Transmission Control Protocol (TCP)?对TCP报头进行讲解，部分内容会与旧版本有些许区别。

????????TCP协议传输的数据单元是报文段，一个报文段由TCP首部（报文头）和TCP数据两部分组成，其中TCP首部尤其重要，首部用于控制(新建、断开)连接、流量和拥塞等。TCP首部的固定长度是20B，最大长度是60B，其中可变选项长度最长为40B(4B×10)。

?字段解释：

• 源端口（Source Port）：占用 2 Byte，标识发送方应用程序使用的端口号；
• 目的端口（Destination Port）：占用 2 Byte，标识发送方应用程序的目标端口号，也就是接收方应用程序的端口号；
• 序号（Seq，Sequence Number）：占用 4 Byte，范围是[0, 2^32)，标识TCP报文段中的第一个字节数据的序列号，用于保证传输数据的可靠性和顺序性。TCP是一个面向字节流的传输控制协议，且支持全双工通信，所以为了保证发送方和接收方都能独立进行传输，两端通信时都必须得知道各自分别发送和接收了多少个字节数据（不含TCP首部），以及接收到数据后如何进行读取、拼接组合。TCP发送方用Seq字段告知接收方自建立连接以来我方已累计（不包含本报文段）已发送了Seq-1个字节数据，本次传输的报文数据第一个字节序列号是Seq，而接收方在成功接收完一段或多段数据后可以根据Seq的大小顺序对数据进行拼接组合，并且用Ack字段告知发送方我方已成功接收了Ack-1个字节数据，期望下次接收的报文段是从Ack序号开始。【为什么都要减1呢？因为TCP成功建立连接后Seq和Ack都会置为1，所以Seq和Ack的起始值都是1。第N次发送数据时的 Seq?= Seq初始值1 + 第1次发送的字节长度 + ··· + 第N-1次发送的数据字节长度，也就是第N次发送数据时的 Seq?= 第N-1次发送数据时的 Seq + 第N-1次发送的数据字节长度】。请注意，TCP建立连接和断开连接时Seq和Ack跟TCP报文数据长度无关。当Seq到达2^32-1（4GB内容.....）后又会从0重新开始。
• 确认号（Ack，Acknowledgment Number）：占用 4 Byte，标识接收方期望收到下一个报文段的序列号是Ack，也可以理解成接收方已成功接收了Ack-1个字节数据。只有标志位ACK为1时确认号才有效。接收方在成功接收完数据后需要给发送方一个确认，告诉发送方已收到某个报文段（事实上，接收方往往是在成功接收了多条报文段后才发送一次Ack）。

• 数据偏移（Data Offset）：占用 4 bit，标识TCP报文段中报文数据的起始位置距离报文段开始位置有多远，也就是TCP的首部长度是多少，单位是32bit（4字节）。从下图可以看到TCP首部长度 Header Length 为 0101，转换成十进制是5，4Byte × 5 = 20 Byte。而TCP首部固定长度是20Byte，可变长度是40 Byte，最长是60 Byte，所以数据偏移值最小是5，最大是15，[0101, 1111]。

• 保留（Reserved）：占用 3 bit，预留给未来使用的一组控制位，目前该值设置为0。TCP首部的数据偏移(首部长度)、保留位和标志位公用16 bit，也就是2 byte，其中数据偏移独占4 bit，保留位和标志位一共可分配12 bit，如果我们把保留位Reserved也当成一个预留的或空白的标志位，那么完全可以理解成TCP最多可分配12个标志位，目前（rfc9293版）已明确的标志位共有8个，还有1个处于实验阶段的标志位AE，一共是9个标志位，每个标志位占用1 bit，剩余的3 bit由Reserved占用。
• 标志位（Flags）：也叫控制位，每一个标志位占用 1 bit。目前已有9个标志位，包括AE、CWR、ECE、URG、ACK、PSH、RST、SYN和FIN，值为0或1，用于控制TCP的拥塞、连接的建立、管理和关闭等。
  1. AE（Accurate ECN）：处于试验期的标志位。外文资料也比较少，看了半天也不知道是用来干嘛的，暂且搁置吧。
  2. CWR（Congestion Window Reduce）：拥塞窗口减半标志，发送端通过降低“cwnd”和“ssthresh”来应对网络拥塞。CWR和ECE都是用来控制网络拥塞的，而CWR是用来响应ECE的，所以在了解CWR作用之前，我们得先搞懂ECE是用来干嘛的。Explicit Congestion Notification，翻译过来就是“显式拥塞通知”，简写ECN。数据报在发送方发出后可能要经过多个路由器才能到达接收方，如果中间某个路由器根据算法结果判断出自身发生了拥塞，就会在报文的IP首部设置CE标志(ECE)，接收方在接收到这段报文后，发现IP头设置了CE标志，表明数据发送途中网络有拥塞，得赶紧把这个消息告诉发送方，不然可能要丢包。接收方在后续返回给发送方的每一条ACK报文都会设置ECN-Echo(ECE)为1，用于告知发送方从贵方到我方的网络有拥塞。而发送方在接收到对方返回的ECE报文后，得知网络有拥塞，就会将拥塞窗口“cwnd”减半，并降低慢启动阈值“ssthresh”，之后再发送CWR报文给接收方，接收方收到CWR报文后表明发送方也采取相应措施来应对网络拥塞，随后便不再发送ECE报文。请注意，数据重传时，TCP报头中不会设置CWR标志位。
  3. ECE（ECN-Echo）：用于通知对方，从对方到我方的网络有拥塞。如果发送方收到ECN-Echo (ECE) ACK包(即TCP报头中设置了ECN-Echo标志的ACK包)，则发送方知道在从发送方到接收方的路径上遇到了网络拥塞。
  4. URG（Urgent）：标识是否为紧急报文，配合紧急指针（urgent pointer）一起使用，值为0或1 。当标志位URG为1时，表明该报文段有紧急数据需要尽快发送（发送端此时不会把报文数据写入到缓冲区，而是直接发送给应用层），即使对端窗口大小此时为0系统也要以高优先级发送该段报文，紧急数据会放在TCP报文段数据部分的最前端，紧急指针用于标识紧急数据在TCP报文段数据部分的结束位置，紧急数据之后的字节内容依然是普通数据。
  5. ACK（Acknowledgment）：标识确认应答是否有效，配合确认号（Ack，Acknowledgment Number）一起使用，值为0或1 。当标志位ACK为1时，确认号Ack才有效。除了最初建立连接时发送的SYN报文段之外，其它情况下发送的报文段ACK都为1。
  6. PSH（Push）：标识是否立即把报文数据推送给应用层，值为0或1。如果TCP接收方接收到PSH为1的报文段，应尽快把这段报文数据从接收缓冲区中读出并立即推送给应用层，不必等到缓冲区写满后再推送。常用于请求方发送完一个新请求后希望立即得到对端的响应。

     

  7. RST（Reset）：标识是否重置连接，值为0或1 。当RST为1时，表明TCP连接发生错误，需要先强制断开连接，再重新建立新的连接，称之为复位TCP连接，这种报文也称之为复位报文段。
  8. SYN（Synchronize）：该标志位用于在建立连接时同步Seq和Ack的初始值，仅在建立连接时使用。TCP三次握手中，第一次握手时，客户端先发送“SYN=1，ACK=0”的报文段，表示请求建立，第二次握手时，如果服务端同意建立连接就返回“SYN=1，ACK=1”的报文段。我们把含有SYN标志位的报文称为同步报文段。
  9. FIN（Finish）：该标志位用于断开/释放连接，仅在断开连接时使用。当通信结束后需要断开连接时，主动要求断开连接的一方会发送“FIN=1，ACK=1”的报文段给对端，告知对端通信已结束希望断开连接，对端接收后会相应地返回“ACK=1”的报文段，至此连接会彻底关闭。我们把含有FIN标志位的报文称为结束报文段。

     

• 窗口（Window）：占用 2 Byte（16bit），表示TCP接收方当前可用的最大缓冲区(Receive Buffer)大小，常配合Options字段中的Window Scale一起使用，用于实现滑动窗口机制，对流量进行控制（接收方通过Window告知发送方我方剩余的接收缓冲区还剩这么多，发送发会根据Window大小灵活调整发送速率，从而避免网络拥塞并确保通信的稳定性）。请注意，Window大小值有时候并不代表当前的实际可用窗口大小，因为Window共占用16位，最大值是2^16-1，也就是64K(65535)，在当前的网络高带宽情况下，64K显然已无法满足大部分的网络通信，所以后来就在TCP的Options字段中新增了Window Scale对窗口进行放大，Window Scale代表的是一个向左的位移值(Shift count)，最大值是14。二进制数据每增加一位1，其换算指数都会加1，所以实际窗口大小最大允许值应该是 2^(16+14) -1 = 2^30 - 1，长达1Gb。TCP在建立连接时的前两次握手过程中，双方都会用Window Scale来向对端声明我方的窗口放大因子并缓存对端的窗口放大因子，后期通信过程中不再声明，仅发送Window，双方会用对方的Window和Window Scale来计算实际的窗口大小，并根据实际窗口大小调整发送速率（如果窗口为0，发送方会定期进行窗口探测）。用图说话

  

• 校验和（Checksum）：占用 2?Byte，接收方校验接收的数据是否与发送的数据完全一致，用于保证数据的完整性和准确性。Checksum是一个强制字段，发送方必须生成并发送它，接收方必须检查它。数据在传输过程可能会出错，所以TCP发送方在发送数据前会先根据伪首部、报文段首部和报文段数据计算校验和值，并将最终得到的值写入Checksum字段。而接收方在收到此报文段后，会根据伪首部、报文段首部和报文段数据再次计算校验和值，如果结果是0，说明数据一致，否则丢弃数据并报告发送方重传这段数据。

TCP发送方计算校验和过程：

? ? ? ? 1.先将TCP报文段首部中的Checksum字段置为0，因为Checksum本身也要参与计算；

????????2.将伪首部、TCP报文段首部和TCP报文段数据连在一起并分成若干个16位的位串，看是否是偶数个字节（所有数据是否对齐），如果不是则在右侧填充一个全为0的8位位串（填充段仅用于计算校验和值，不会传输给接收方），将每个16位位串看成一个二进制数；

????????3.对这些16位的二进制数进行1的补码和运算(one's complement sum)，如果最高位有进位应循环进到最低位，累加的结果再取反码即得到校验和；

? ? ? ? 4.将校验写入TCP报文首部的Checksum字段。

TCP接收方检查校验和过程：

????????1.接收方将伪首部、TCP报文段首部和TCP报文段数据按发送方同样的方式（不包含发送方的第1步操作）进行1的补码和运算，累加的结果再取反码。

????????2.校验，如果上步的结果为0，表示传输正确；否则，说明传输有差错。?

• 紧急指针（Urgent Pointer）：占用 2?Byte，也称紧急偏移，用于标识紧急数据在TCP报文段数据部分的结束位置/正的偏移量。只有当标志位URG为1时该参数才有效。紧急数据是放在TCP报文段数据部分的最前端，紧急指针用于标识紧急数据在TCP报文段数据部分的结束位置，紧急数据之后的字节内容依然是普通数据。
• 选项（Options）：占用 0~40 Byte，可选字段，用于传输TCP报文的附加信息，Options所有选项也都包含在校验和中。仅当 Data Offset?> 5 时Options才会出现，size(Options) = (Data Offset?- 5)×32，每个option的长度必须是8bit的整倍数（最短1个字节），且Options总长度也必须是32bit(4字节)的整倍数。如果某个option的长度不够4字节，那么就用“No-Operation（占用1字节）”来补充位数(都是补高位)，缺几个字节就补几个“No-Operation”。请注意，当整个选项列表的结束位置无法与TCP报头尾部对齐时，TCP会在整个选项(all options, not each option)列表的尾部填充“End of Option List”选项。综上可知，size包含了补位和填充的数据长度。一个option由Kind、Length和Data三部分组成，其中Length和Data是选填参数，Length表示的是当前这个option的总长度，它包含Kind、Length和Data三者总共占用的位数。

常用option如下表：

Kind	Length	Meaning	Reference
0	-	End of Option List	RFC9293	仅用于填充整个选项列表尾部。
1	-	No-Operation，NOP	RFC9293	补位选项。
2	4	Maximum Segment Size，MSS	RFC9293	最大报文段长度，具体限制的是TCP报文段中数据部分的长度。
3	3	Window Scale	RFC7323	窗口放大因子
4	2	SACK Permitted	RFC2018	标识是否支持SACK，只有在建立连接时SYN报段使用。
5	N	Selective Acknowledgment，SACK	RFC2018	选择性确认，用于数据重传机制。接收方可通过SACK参数告知发送方我方收到了不连续的数据块（Ack=200，SACK=200-400），发送方可根据此信息检查哪部分数据丢失（对方收到200字节数据，接收到的是200-400段，说明0-199段丢失了）并重传这段数据。
8	10	Timestamps	RFC7323	时间戳

完整的options list请参阅：Transmission Control Protocol (TCP) Parameters/tcp-parameters-1?

---

参考文章

????????RFC 9293: Transmission Control Protocol (TCP)?

????????Transmission Control Protocol (TCP) Parameters? ?TCP所有字段、标志位和参数在这里都能找到！

????????RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP

????????draft-ietf-tcpm-accurate-ecn-28 - More Accurate Explicit Congestion Notification (ECN) Feedback in TCP????????Accurate ECN

????????draft-kuehlewind-tcpm-accurate-ecn-05 - More Accurate ECN Feedback in TCP? ? ? ? ? ? ? ? ?Accurate ECN

????????RFC 2018: TCP Selective Acknowledgment Options? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Options：SACK

????????RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP? ? ? ? ?Options：SACK

????????RFC 7323: TCP Extensions for High Performance? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Optinos：Window Scale、Timestamps