在发送方和接收方捕获的不同 tcp 数据包 [英] different tcp packets captured on sender and receiver

查看:87
本文介绍了在发送方和接收方捕获的不同 tcp 数据包的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用 tcpdump/wireshark 来捕获 tcp 数据包,同时 tcp 客户端将数据发送到 tcp 服务器.客户端只需在一次send()"调用中向服务器发送 4096 个字节.我在两侧得到不同的 tcp 数据包,发送方的两个数据包在接收方似乎被压缩",这与我对 tcp 协议的理解相冲突,我在这个问题上坚持了几天,真的需要一些帮助.

I am using tcpdump/wireshark to capture tcp packets while tcp client sending data to tcp server. The client simply sends 4096 bytes to server in one "send()" call. And I get different tcp packets on two sides, two packets on the sender side seem to be "compacted" on the receiver side, this conflicts with how i understand the tcp protocol and I stuck on this issue for a few days and really need some help.

请注意以下数据包中的数据包长度:

Please notice the packet length in following packets:

客户端(发送方)发送 2 个数据包 0Xbcac (4) 和 0xbcae (5),总共发送 2896 + 1200 = 4096 个字节.

client (sender) sends 2 packets 0Xbcac (4) and 0xbcae (5), sends 2896 + 1200 = 4096 bytes in all.

(0xbcac) 4  14:31:33.838305 192.168.91.194  192.168.91.193  TCP 2962    59750 > 9877 [ACK] Seq=1 Ack=1 Win=14720 **Len=2896** TSval=260728 TSecr=3464603    0
(0xbcae) 5  14:31:33.838427 192.168.91.194  192.168.91.193  TCP 1266    59750 > 9877 [PSH, ACK] Seq=2897 Ack=1 Win=14720 **Len=1200** TSval=260728 TSecr=3464603    0

但是在服务器端(接收端),只呈现了一个数据包,ip.id=0xbcac,长度=4096(receiver.packet.0xbcac = sender.packet.0xbcac + 0xbcae):

However on the server (receiver) side, only one packet is presented, with ip.id=0xbcac and length = 4096 (receiver.packet.0xbcac = sender.packet.0xbcac + 0xbcae):

(0xbcac) 4  14:31:33.286296 192.168.91.194  192.168.91.193  TCP 4162    59750 > 9877 [PSH, ACK] Seq=1 Ack=1 Win=14720 **Len=4096** TSval=260728 TSecr=3464603   0

我知道 tcp 是一种流协议,发送的数据可以根据 MSS(或 MTU)划分为数据包,但我猜划分发生在数据包发送到 NIC 之前,因此在捕获之前.我也知道数据包 0xbcae 中的 PSH 标志导致将数据从缓冲区写入 NIC,但这无法解释压缩"数据包.我也尝试在客户端在一次发送"调用中发送 999999 个字节,数据被分成小包并发送,但仍然与服务器端捕获的数据包不匹配.最后我禁用了tcp nagle,得到了相同的结果,并排除了这个原因.

I'm aware that tcp is a stream protocol and data sent can be divided into packets according to MSS (or MTU), but i guess the division happens before packets are sent to NIC, thus before captured. I'm also aware that the PSH flag in packet 0xbcae lead to writing data from buffer to NIC, but that cannot explain the "compacted" packet. Also I tried in client to send 999999 bytes in one "send" call and the data are divided into small packets and sent, but still mismatch the packets captured on server side. At last I disable tcp nagle, get the same result, and ruled out that reason.

所以我的问题是我遇到的不匹配正常吗?如果是,是什么原因造成的?如果没有,我在局域网中使用 ubuntu 12.04 和 ubuntu 13.10,这个压缩"数据包的可能原因是什么?

So my question is the mismatching i encountered normal? If it is, what caused this? If not, i'm using ubuntu 12.04 and ubuntu 13.10 in LAN, and what is the possible reason to this "compacted" packet?

在此先感谢您的帮助!

推荐答案

发送端的两个数据包在接收端好像被压缩"了侧面

two packets on the sender side seem to be "compacted" on the receiver side

看起来像是通用接收卸载或大型接收卸载的情况.长话短说,接收网卡会在到达内核之前执行一些智能操作并合并段,从而提高性能.

It looks like a case of generic receive offload or large receive offload. Long story short, the receiving network card does some smart stuff and coalesces segments before they hit the kernel, which improves performance.

要检查是否是这种情况,您可以尝试使用以下方法禁用它:

To check if this is the case you can try to disable it using:

$ ethtool -K eth0 gro off
$ ethtool -K eth0 lro off

在发送端会发生一些互补的事情:tcp 分段卸载或通用分段卸载.

Something complementary happens on the sending side: tcp segmentation offload or generic segmentation offload.

禁用这些后不要忘记重新启用它们:它们会显着提高性能.

After disabling these don't forget to reenable them: they seriously improve performance.

这篇关于在发送方和接收方捕获的不同 tcp 数据包的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆