“不分割"的好处在于:在TCP数据包? [英] Benefits of "Don't Fragment" on TCP Packets?
问题描述
我们的一位客户在从我们的应用程序(在他们的PC上)向服务器(不同的地理位置)提交数据时遇到了麻烦.当发送低于1100字节的数据包时，一切正常，但是在此之上，我们看到TCP每隔几秒钟重新传输一次数据包，并且没有任何响应.我们用于测试的数据包约为1400个字节(但小于1472个字节).我可以将1472字节的ICMP ping发送到www.google.com并获得响应(因此，这不是他们的路由器/前几跳).
我发现我们的应用程序为这些数据包设置了DF标志，并且我相信一台通往服务器的路由器的MTU小于/等于1100，并且丢弃了该数据包.
这会影响5000个客户端中的1个，但是由于每个人的路由都不同，所以这是预期的.
数据是SOAP信封，我们希望能返回SOAP响应.我无法证明我们为什么这样做，而执行此操作的代码是由以前的开发人员编写的.
所以... 在TCP数据包上为应用程序数据设置DF标志是否有好处或理由?
我可以想到网络诊断应用程序需要它的原因，但在我们所处的情况下不需要(我们希望数据到达终结点，无论是零散的还是不零散的).我们的一位系统管理员表示，使用SSL可能与我们有关，但是据我所知，SSL就像是一个流，而不论是否有碎片，只要在流的最后重建，就没有问题.
如果没有充分的理由，我将更改我们应用程序的行为.
先谢谢了.
DF标志通常在承载TCP段的IP数据包上设置.
这是因为TCP连接可以动态更改其段大小以匹配路径MTU，并且当每个TCP段都包含在一个IP数据包中时，可以实现更好的总体性能.
因此，TCP数据包设置了DF标志，如果中间路由器由于数据包太大而不得不丢弃该数据包，则应该会导致返回ICMP Fragmentation Needed数据包.然后，发送方TCP将减少其对连接的路径MTU(最大传输单元)的估计，并在较小的段中重新发送.如果未设置DF，则发送方TCP永远不会知道它发送的段太大.此过程称为PMTU-D(路径MTU发现").
如果"ICMP碎片所需"数据包没有通过，则说明您正在处理损坏的网络.理想的第一步是识别配置错误的设备并进行纠正.但是，如果无法解决问题，则可以在应用程序中添加一个配置旋钮，告诉它使用setsockopt()设置TCP_MAXSEG套接字选项. (设备配置错误的典型示例是由经验不足的网络管理员配置的路由器或防火墙，以丢弃 all ICMP，但并未意识到TCP PMTU-D需要分片所需的数据包.)
One of our customers is having trouble submitting data from our application (on their PC) to a server (different geographical location). When sending packets under 1100 bytes everything works fine, but above this we see TCP retransmitting the packet every few seconds and getting no response. The packets we are using for testing are about 1400 bytes (but less than 1472). I can send an ICMP ping to www.google.com that is 1472 bytes and get a response (so it's not their router/first few hops).
I found that our application sets the DF flag for these packets, and I believe a router along the way to the server has an MTU less than/equal to 1100 and dropping the packet.
This affects 1 client in 5000, but since everybody's routes will be different this is expected.
The data is a SOAP envelope and we expect a SOAP response back. I can't justify WHY we do it, the code to do this was written by a previous developer.
So... Are there any benefits OR justification to setting the DF flag on TCP packets for application data?
I can think of reasons it is needed for network diagnostics applications but not in our situation (we want the data to get to the endpoint, fragmented or not). One of our sysadmins said that it might have something to do with us using SSL, but as far as I know SSL is like a stream and regardless of fragmentation, as long as the stream is rebuilt at the end, there's no problem.
If there's no good justification I will be changing the behaviour of our application.
Thanks in advance.
The DF flag is typically set on IP packets carrying TCP segments.
This is because a TCP connection can dynamically change its segment size to match the path MTU, and better overall performance is achieved when the TCP segments are each carried in one IP packet.
So TCP packets have the DF flag set, which should cause an ICMP Fragmentation Needed packet to be returned if an intermediate router has to discard a packet because it's too large. The sending TCP will then reduce its estimate of the connection's Path MTU (Maximum Transmission Unit) and re-send in smaller segments. If DF wasn't set, the sending TCP would never know that it was sending segments that are too large. This process is called PMTU-D ("Path MTU Discovery").
If the ICMP Fragmentation Needed packets aren't getting through, then you're dealing with a broken network. Ideally the first step would be to identify the misconfigured device and have it corrected; however, if that doesn't work out then you add a configuration knob to your application that tells it to set the TCP_MAXSEG socket option with setsockopt(). (A typical example of a misconfigured device is a router or firewall that's been configured by an inexperienced network administrator to drop all ICMP, not realising that Fragmentation Needed packets are required by TCP PMTU-D).
这篇关于“不分割"的好处在于:在TCP数据包?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
