建议的 TCP-MSS 的值通常为 1380~1460 字节。具体数值取决于应用程序、网络环境和设备配置等因素。例如，如果是在 VPN 场景中使用，可以将 MSS 设置成 1350，因为 VPN 会在数据包上添加额外的头部信息。在实际应用中，我们可以通过不断测试和优化，确定最合适的 MSS 值。
MTU是一个老概念了，是属于以太网数据链路层的概念，而MSS是新的概念，由于MTU和MSS概念都十分重要，且容易混淆，为了讨论清晰，单独拎一章节来讨论它们俩。
首先我们要说明下讨论前提，本文基于以太网协议、IP协议版本使用的是IPv4版本讨论 。
概括来讲，MTU是以太网数据链路层中约定的数据载荷部分最大长度，数据不超过它时就无需分片。
MSS是传输层的概念，由于数据往往很大，会超出MTU，所以我们之前在网络层中学习过IP分片的知识，将很大的数据载荷分割为多个分片发送出去。
TCP为了IP层不用分片主动将数据包切割为MSS大小。
一个等式可见他两关系匪浅： MSS = MTU - IP header头大小 - TCP 头大小
MTU全称是Maximum Transmission Unit，即最大传输单元。
在学习数据链路层时，我们学习过以太网协议，以太网定义了一个叫做帧的概念，一个帧中包含如下信息：
此外，我们学习了帧的大小，其中帧头大小为：
1. 接收方和发送方的 MAC 地址分别占用 6 个字节；
2. 第 3 层的协议用 2 个字节编码；
3. CRC 用 4 个字节编码。
6 x 2 + 2 + 4 = 18。
因此以太网的帧头一共有 18 个字节，并且以太网中还规定了最小帧长和最大帧长：
以太网帧的最小尺寸是 64 字节，那么一帧中最少报文长度为46字节。
以太网帧的最大尺寸是 1518 字节，那么一帧中中最大报文长度为1500字节。
其中1500字节往往就是以太网的MTU值了，传输的数据小于它时，就无需切片。
太大的数据就需要切分，就像一个超级大包裹需要切分为若干个小包裹才方便托运。
假设传输100KB的数据，则需要切分为多少个帧进行传输呢？
100KB=100*1024B，由于帧中最大的报文长度是1500B，那么100KB/1500B≈68.27，显然需要69个以太网帧才能承载。
一台机器上，不同网卡的MTU也不一样，比如我的一台虚拟机上的网卡MTU为：
容易想到，一个包从发送端传输到接收端，中间要跨越很多个网络，每条链路的MTU都可能不一样，就像开车，有的时候可以经过宽敞的四车道，有的时候不得不行驶于乡间小路，这个通信过程中最小的MTU称为路径MTU（Path MTU）。
比如第一段链路MTU为1200字节，第二段链路MTU为800字节，第三段链路MTU为1500字节，那么路径MTU就是最小的800字节。
路径 MTU 就跟木桶效应是一个道理，木桶的盛水量由最短的那条短板决定，路径MTU也是由通信链条中最小的MTU决定。
基本原理十分简单，当一方发送了超过MTU的数据包后，对方会返回一个ICMP错误包，告知发送方包太大需要分片，并且告知发送方下一个分片的大小按照比如MTU=1200来计算，由于MTU取小者，那么A就需要随之调整MTU为1200字节：
下面我们实际抓包验证下，不过在验证前，我们需要重新认识下ping命令。
我们之前学习过了 ping命令，其原理是基于ICMP协议，而ICMP协议实际上是封装在IP数据中的，首部为8字节长度 ，关于ICMP我们已经讨论过，这里不再赘述。
ping后面是可以跟着一些参数满足我们的一些测试用例的，我们将使用到的命令是：
ping 192.168.56.102 -l 1472 -f -n 1
如何查看后续参数的含义呢，我们在windows上的窗口界面输入：
ping -help
-l 1472表示发送的数据包大小，单位是字节；
-n表示只发送一个请求，因为windows下默认会自动发送四个数据包请求；
-f表示不分片，实际上就是IPv4固定首部中的标志位中的DF字段：
标志位中间位即第2位记为DF（Don't Fragment），意思是原数据报能否分片。
当值为1时，表示该数据报不允许分片，当值为0时，表示该数据报允许分片。
我们下面分别执行两条命令，来看下神奇情况的发生：
可以看到，我们前后发出了两个ping请求，第一次携带1472字节数据，第二次携带1473字节数据，并且都设置了DF为1即不允许分片。
仅仅相差一个字节，为什么在结果上出现了天壤之别呢？
首先 ICMP首部固定为8字节 ， IP首部固定部分是20字节 ，我们这里没有额外部分，加上 1472字节的数据 ，正好就是以太网帧中最大1500字节大小，即8+20+1472=1500字节。
对本次ping的抓包结果如下：
不然理解，第一次请求正好是1500字节，没有超过MTU限制，所以可以传输成功，而第二次超出了一个字节，又不允许分片，因此传输失败。
对于第二种情况，如果ping命令后面不携带-f参数，也是可以ping成功的，只是在路上会被切分为两个包。
我们继续来抓包证明自己的想法，去掉-f选项，允许分片，执行命令：
ping 192.168.56.102 -l 1473 -n 1
我们看到了 fragmented ip protocol 字眼，中文意思是分段ip协议，说明 1473字节 的数据被分片了，我们且来看第一个分片报文详情：
继续看下一个报文详情：
也可以注意到一个细节，第二个报文段中不包含ICMP首部。此外可以注意到wireshark上显示的包length为35长度，之前不是说过至少是60字节的吗？(加上FCS校验应该是64字节)
实际上，如果数据部分小于以太网帧需要的最小的46字节时，就会在以太网层自动填充0，使得数据达到46字节，从而达到最小64字节的帧长度要求。而这里显示35字节大概率是因为wireshark捕获的时候还未进行填充，从而显示出了这个异常的长度包（对于这一点如果有错误还请指正）。
MSS的英文全称叫Max Segment Size，是TCP最大段大小。
在建立TCP连接的同时，也可以确定发送数据包的单位，我们称为MSS， 这个MSS正好是IP中不会被分片处理的最大数据长度 。
TCP在传送大量数据时，是以MSS的大小将数据进行分割发送的，重发时也是以MSS为单位。
MSS是在三次握手的时候，在两端主机之间被计算得出，两端主机在发出建立连接的请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应的MSS的大小，然后在两者之间选择一个较小的值投入使用。
从以上描述中可以看出来：
MSS = MTU - IP header头大小 - TCP 头大小
这样一个 MSS 的数据恰好能装进一个 MTU 而不用分片。
在我们熟悉的以太网中，TCP的MSS最大值是：以太网MSS=1500(MTU)-20(IP首部长度)-20(TCP首部大小)=1460字节
好了，理论介绍完毕，下面我们来看下实际抓包。
我的虚拟机上安装了一个nginx，端口使用的是熟知端口号80，我在本地客户端通过curl命令访问nginx的服务：
从下图抓包中可以看到， MSS的值是在三次握手的SYN报文中商量出来的 ，可以看到互相说明自己允许的最大段大小都是1460字节，那么MSS的值就可以取为1460。
在以太网协议中，一般情况下MTU是1500字节，MSS为1460字节(相差20字节的IP首部+20字节的TCP首部)，不过以上是基于IPv4协议讨论的，在IPv6中，IP首部长度是40字节，那么MSS一般就是1440字节了。
MSS选项只能出现在SYN报文中，为此SYN报文TCP头部里包含了 12字节的选项（Options）字段 ，可以清晰看到里面有一个MSS选项，所以本次的TCP的握手报文中的TCP首部长度为32字节，即20字节的固定首部加12字节的可变首部，整体为4字节的整数倍。
传输层篇-MTU和MSS
https://mp.weixin.qq.com/s/ZMV2izeYkBIqjPhsv_-wdw
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）