巨型帧

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上的这些功能开放的部分。

 

功能ON

然后，感觉关闭的部分只需要TSO和GRO。

 

捕包细节

 

---

执行了下面两个命令

 

 

命令

---

修改之后，发现这部分的流量最大为1514
重新理解下原来的部分，就是MTU为1500是指链路层的数据为1500，加上链路层的数据，14
结果就是1514.

 

 

修改后包长

---

2017/12/31
对于Windows下，可以通过关闭大型数据传送负载这个功能（设备管理器，网卡驱动部分）
具体的讲述看这个网页：http://blog.nsfocus.net/network-packets-analysis-nic-offload/