NAT和MTU的问题抓包分享

爱卫生

如题：NAT和MTU的问题抓包分享。附件内容包括：
NAT(MTU＝1434，ping，正常＝ok，1426＝ok，1427，1500＝no ok).cap
NAT(MTU＝1434，打不开网页过程).cap                             
NAT(MTU＝1500，ping，正常＝ok，1426＝ok，1427，1500＝no ok).cap
NAT(MTU＝1500，打不开网页过程).cap                             
   

emhmily

请教个问题: 前面三个我都能理解,但第4种,MTU==1500时打不开网页是么原因啊?

爱卫生

emhmily 发表于 2012-7-3 14:38
请教个问题: 前面三个我都能理解,但第4种,MTU==1500时打不开网页是么原因啊?

不是很记得了。应该是少算了一层包头超过了接口IP MTU。但不记得具体的场景了。

emhmily

爱卫生 发表于 2012-7-4 19:12
不是很记得了。应该是少算了一层包头超过了接口IP MTU。但不记得具体的场景了。

由附件可知，
1：从客户端的情况来看，它的MSS是1414，它发送的MSS是1460，但其发送的GET请求仅有363（TCP负载）字节，即便加上ppp的头（注意到了这个是PPP+IP的情况），也远远没有达到1500字节，所以是可以成功发送；
2：从服务端的情况来看，它的MSS是1460，它发送的MSS是1414，无论如何，其发送的响应响应的长度为：
(payload+TCP_header+IP_header+ppp_frame_header_and_end == 1414+20+20+8 == 1462 < 1500)，客户端也应该能够收到。

矛盾之处：
客户端在发送http的GET请求后，没有收到任何响应。有点类似于客户端所在网络将超过1500的数据包被丢弃了。
我想知道的是，为何没有收到任何响应？如果是因为单包大小行成的帧大于1500，请详述下为何会有这样的包。

爱卫生

emhmily 发表于 2012-7-5 10:28
由附件可知，
1：从客户端的情况来看，它的MSS是1414，它发送的MSS是1460，但其发送的GET请求仅有363（T ...

感觉是比较诡异。说下我的理解。这个包里应该还少了3个报文，如果没少，那应该就是被服务器端丢弃了。控制面的Get请求怎么也不会超过TCP MSS的，除非是有payload下来。#9号包是对#7号Get报文的响应，但序列号居然是2819，这代表之前应该还有3个报文发给用户的，这3个报文的序列号应该分别是1+1414+1414。第一个1应该是对GET的ACK，后面两个应该就是传送具体的tcp payload了，这时候就要分段了。但IP MTU如果设置为1500的话，应该感觉没问题的。因为IP MTU只算IP包头及之上的部分，就是IP 20+TCP 20+1414=1454字节就可以了。所以，应该是能正常打开的感觉。

附一个正常的报文供参考。

emhmily

嗯！我的理解与你的相同，还有一点也比较诡异的是，为什么#9号报文的后没有一个ACK==1（以告之对方，出现了丢包）的报文出现呢？即使网络造成的了丢包，也不至于客户端把应有的响应也丢了吧？
算了，不想这个问题了。但愿有高人能为我们解惑。