TCP协议中payload设置方式？

Posted 2021-04-15 车小胖谈网络

原因是这样的，我使用wireshark抓包时发现连续的HTTP协议没有http头，像这样：

后来我发现：length为1514的报文TCP标志位PSH都为0，最后一个长度为980的报文PSH为1。我认为这大概是TCP将应用层传来的大文件分批发送。（PSH作用我明白）

TCP payload长度为1460 bytes(也就是说TCP把HTTP协议分成每份长度为1460 bytes)。

这个1460是怎么设定的？是否与Window size有关？为什么要设置成1460 bytes？

正文

TCP报文一次性最大运输的货物量(Payload)，大体可以这么来计算：

 

  IP报文头长度  +  TCP报文头长度  +  Payload长度  ≤ MTU

 

即左边的三者之和，要小于等于右边MTU的长度，其中：

 

Internet 路由器接口标准MTU = 1500

IP报文头长度 = 20

TCP报文头长度 = 20

 

所以

 

Payload长度≤ MTU – IP报文头长度 – TCP报文头长度

                    ≤ 1500 -20 -20

                    ≤ 1460

 

TCP为了提高传输效率，通常会使用最大上限1460字节来传输应用层数据，如http，除非http待传输数据小于1460。

 

题主最后一组http数据只有980字节，小于1460，那么就有多少算多少。

 

 

但是TCP没有那么简单，所以还需要考虑得更多一点。

 

TCP报文通常有3部分组成：IP Header + TCP Header + Payload

 

但是，当前主流操作系统的TCP/IP协议栈，为了提高传输性能，通常还会使用 TCP Option选项。

 

 

一个例子

 

客户端在TCP握手连接，告诉服务器自己支持以下三个option:

(1)   Maximum Segment Size

(2)   SACK Permitted

(3)   Timestamp

 

服务器接收到该报文，却有不同的意见，服务器只支持这三者中的：

 

(1)   Maximum Segment Size

 

如下图所示

 

 

 

Option，翻译成中文是选项。所谓选项，不是强制标准，对方如果不支持或不理解，完全可以忽略。

 

在这里服务器并没有打算支持选项2 ，3, 所以双方共同支持双方的交集，即选项1。

 

Maximum Segment Size

MSS的存在是为了通信双方交换各自TCP Payload最大传输长度，这个长度上限一般为1460，即上文计算的方法。

 

如果双方的MSS不一样，将选择较小的MSS值，作为接下来通信Payload的长度上限。

 

 

假如服务器支持选项2，“Timestamp”，那么TCP报文将会包含4部分：

 

IP Header + TCP Header + TCP Option +Payload

 

 

这里的TCP Option为“Timestamp”，长度为 10字节，看看 Payload最大可以传输多少字节？

 

IP Header + TCP Header + TCP Option +Payload ≤ 1500

 

IP Header + TCP Header + Timestamp +Payload ≤ 1500

 

Payload ≤ 1500 - IP Header -TCP Header – Timestamp

              ≤ 1500 -20 -20 -10

              ≤ 1450

 

简而言之，没有携带option的TCP报文，最大可以支持1460字节的Payload长度。

一旦携带option，由于option需要占用空间，留给payload的空间将会相应减少，具体减少的空间等于option占用的空间。

 

Payload长度和Window Size有关系吗？

有一点点关系。

 

如果把Payload 1460看成一个标准的集装箱，Window Size可以看作双方的仓库大小，用于临时堆放对方运过来的集装箱，在集装箱被客户运走之前，一直会呆在TCP仓库里。

 

为了更高效地利用仓库，最理想的方法就是，仓库的大小是集装箱的整数倍，这样就不会产生零星的空间。

 

零星的空间一直无法使用，因为不够容纳一个标准集装箱，势必会造成仓库空间的浪费。

空间浪费只是直接后果，还有一个间接后果，更加严重。

 

假设接收方的仓库空间还有200字节，于是通过window size update消息告诉发送方。

 

发送方心急火燎发200字节，那么一个标准1460报文，将会分成8个小报文发送，这样的传输效率会非常低下。

 

为了避免这种低效传输场景，TCP协议有了新的严格规定：

 

如果 window size < MSS , 不允许更新自己的window。

上文用通俗语言表达为，一旦接收方的仓库空间小于一个标准集装箱，window size update = 0 , 即善意欺骗对方，仓库已经用完，不允许再发货物过来。

 

以上是从接收方入手，万一接收方没有遵守规定，那就让发送方严格执行另外一个规定。

 

发送方一旦发现对方的window size < MSS，理解为对方的仓库已经占满(剩余空间不足以容纳一个标准集装箱)，不会发送任何集装箱。

 

欢迎读者朋友们在评论区讨论这个问题，谢谢。