问题更新：除了下面的问题，似乎我们使用Linux PLPMTUD机制的客户端/服务器应用程序获得了太大的路径MTU。有没有人看过这个，即实际路径MTU是1500，但是getockopt w TCP_MAXSEG返回端点的MTU：s，在我们的例子中是3000？我试过用ethtool转换GRO，GSO和TSO，但错误仍然存在。普通ping只能设法推送1472字节或更小的数据包。另外值得一提的是PLPMTUD适用于较小的MTU：s。例如，在1500 MTU的w端点和中间路由器的一个接口设置为例如1200 MTU，内核TCP探测并报告正确的TCP_MAXSEG（1200 - 报头）。
我在应用程序中使用符合Linux RFC4821的分组层路径MTU发现。基本上，客户端在TCP套接字上执行setsockopt：
setsockopt（fd，SOL_IP，IP_MTU_DISCOVER，＆amp; sopt，sizeof（sopt）） 选项值设置为IP_PMTUDISC_PROBE。 setsockopt不会返回错误。
客户端向丢弃服务器发送大型tcp数据包，路径MTU由Linux内核校准 - tcpdump显示发送DF位设置的tcp数据包，数据包大小不同，直到内核知道路径MTU。但是，要使其在另一个方向上工作（侦听服务器接受：来自客户端的连接，发送数据和从服务器到客户端的方向校准PMTU）我必须为tcp路径mtu发现设置全局选项，/ proc / sys / NET /支持IPv4 / tcp_mtu_probing。如果不这样做，服务器将愚蠢地继续发送过大的数据包，这些数据包会被没有ICMP发送回的中间路由器丢弃。两个端点的MTU设置为3000，而中间跃点的MTU设置为1500.
我希望有人知道出了什么问题。如果需要更多信息，请告诉我并编辑问题。 Linux内核4.2.0和3.19.0都存在问题，两者都是库存Kubuntu LTS内核。 （86 / x86-64的）
我在所有accept：ed套接字上设置了相同的套接字选项服务器端，然后以反方向发送数据。
答案 0 :(得分：0)
FWIW，我找到了问题的解决方法/解决方案，会做更多的测试，但很快会在这里描述我的发现，以防它帮助其他人。
无法在每个套接字上设置路径mtu发现的问题是固定的，强制性的，通过在程序执行期间在系统范围内启用它，然后再次禁用。
第二个问题，即getsockopt TCP_MAXSEG返回的错误路径mtu，通过等待发送的TCP数据的TCP ACK，也使用getsockopt（tcp_info.tcpi_unacked）来修复。这样，我可以确定在获得TCP_MAXSEG之前探测已经完成。
最后，在2015年3月，有一个补丁集用于改进与主线Linux内核合并的路径mtu探测精度。没有这些补丁，探测非常不精确。 Patchset是4.1.y系列内核及其后续版本的一部分。