2017/04/17
这个问题,其实严重影响到我分类的这个过程。
我着重从报文长度来设计。
而且,其实这部分的内容就是因为两个报文之间的间隔时间太短了。
反正就是,我不管是在什么环境下测试,都必须将这个问题注意到。
平时用Wireshark进行抓包的时候,会出现一些很长的包,明显高于我原本理解的那个MTU什么的。我以为只是TCP重组之后,弄出来的一个全新的报文。
但是今天抓到的这部分流量就比较尴尬。
(分别是HTTPS和SSH)
不管是发出还是接受都会有这种现象。
https://segmentfault.com/q/1010000007900761
http://packetbomb.com/how-can-the-packet-size-be-greater-than-the-mtu/
https://ask.wireshark.org/questions/24699/tcp-packet-length-was-much-greater-than-mtu
https://zh.wikipedia.org/wiki/%E5%B7%A8%E5%9E%8B%E5%B8%A7
(巨型帧)
http://blog.sina.com.cn/s/blog_93b45b0f0101pfwp.html
这些内容都是,因为网卡做了一些加速的措施。比如GRO或者什么TSO等等。
都是为了能够大块大块的在协议栈和网卡之间传输数据。
可能就是,这部分的流量来的很快,都挤压在了这个网卡的地方,既然来了,就一块给了。
主要,我想知道的是,我这部分,要不要将这个功能关闭。
2017/4/21
所以,以后如果继续捕包做实验的话,可以将这项功能关闭。
主要要看看,到底关闭几个功能。
TSO?!GSO?!
2017/04/23
具体的GSO与TSO的功能:
http://shutdownsky.blog.51cto.com/1026347/1441761
查看了241上的这些功能开放的部分。
然后,感觉关闭的部分只需要TSO和GRO。
执行了下面两个命令
修改之后,发现这部分的流量最大为1514
重新理解下原来的部分,就是MTU为1500是指链路层的数据为1500,加上链路层的数据,14
结果就是1514.
2017/12/31
对于Windows下,可以通过关闭大型数据传送负载这个功能(设备管理器,网卡驱动部分)
具体的讲述看这个网页:http://blog.nsfocus.net/network-packets-analysis-nic-offload/