☰

tcpdumpの長さの決定内容と方法

tag-icon • tag-icon tcpdump
tcpdumpの長さの決定内容と方法

私のアプリケーションが行うことは、kafkaからデータを読み込み、HTTP経由で他のサービスにアクセスすることです。私はある箱から出るトラフィックが他の箱よりも遅いことを発見しました。この発信IPのtcpdumpとこのボックスのログを分析しました。

09:24:20.625288 IP (tos 0x0, ttl 64, id 16107, offset 0, flags [DF], proto TCP (6), length 7292)
    localIP.57854 > externalIp.http: Flags [.], cksum 0x03fb (incorrect -> 0x614e), seq 52963:60203, ack 464, win 2518, options [nop,nop,TS val 205440553 ecr 262205407], length 7240: HTTP
09:24:20.640851 IP (tos 0x0, ttl 64, id 16112, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0xb2a7), seq 60203:63099, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.640897 IP (tos 0x0, ttl 64, id 16114, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0x46c8), seq 63099:65995, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.640930 IP (tos 0x0, ttl 64, id 16116, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0xedd7), seq 65995:68891, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.640940 IP (tos 0x0, ttl 64, id 16118, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0x22df), seq 68891:71787, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.640973 IP (tos 0x0, ttl 64, id 16120, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0x7fad), seq 71787:74683, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.641016 IP (tos 0x0, ttl 64, id 16122, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0x19e9), seq 74683:77579, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.641027 IP (tos 0x0, ttl 64, id 16124, offset 0, flags [DF], proto TCP (6), length 2948)
    localIP.57854 > externalIp.http: Flags [.], cksum 0xf302 (incorrect -> 0xc26d), seq 77579:80475, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205422], length 2896: HTTP
09:24:20.644138 IP (tos 0x0, ttl 64, id 16132, offset 0, flags [DF], proto TCP (6), length 2223)
    localIP.57854 > externalIp.http: Flags [P.], cksum 0xf02d (incorrect -> 0x6078), seq 89163:91334, ack 464, win 2518, options [nop,nop,TS val 205440557 ecr 262205425], length 2171: HTTP
09:24:20.660631 IP (tos 0x0, ttl 64, id 16134, offset 0, flags [DF], proto TCP (6), length 775)
    localIP.57854 > externalIp.http: Flags [P.], cksum 0xea85 (incorrect -> 0x14c9), seq 90611:91334, ack 464, win 2518, options [nop,nop,TS val 205440562 ecr 262205426], length 723: HTTP

また、他のボックスには以下が表示されます。

09:26:53.610483 IP (tos 0x0, ttl 64, id 27441, offset 0, flags [DF], proto TCP (6), length 14532)
    localIP.50978 > externalIp.http: Flags [.], cksum 0xcb4f (incorrect -> 0x3b5c), seq 151537:166017, ack 1390, win 1444, options [nop,nop,TS val 1613152807 ecr 262243666], length 14480: HTTP
09:26:53.610609 IP (tos 0x0, ttl 64, id 27451, offset 0, flags [DF], proto TCP (6), length 16713)
    localIP.50978 > externalIp.http: Flags [P.], cksum 0xd3d4 (incorrect -> 0xed92), seq 166017:182678, ack 1390, win 1444, options [nop,nop,TS val 1613152807 ecr 262243668], length 16661: HTTP
09:26:53.632437 IP (tos 0x0, ttl 64, id 53481, offset 0, flags [DF], proto TCP (6), length 52)
    localIP.51054 > externalIp.http: Flags [.], cksum 0x92bf (incorrect -> 0x5bcc), ack 464, win 1444, options [nop,nop,TS val 1613152812 ecr 262243674], length 0
09:26:53.638408 IP (tos 0x0, ttl 64, id 2460, offset 0, flags [DF], proto TCP (6), length 11636)
    localIP.50892 > externalIp.http: Flags [.], cksum 0xbfff (incorrect -> 0x9468), seq 91408:102992, ack 927, win 1444, options [nop,nop,TS val 1613152814 ecr 262243675], length 11584: HTTP, length: 11584

フィールドの長さには大きな違いがあります。最初のケースでは非常に小さいが、後者の場合は大きく、データ全体が非常に高速に送信されます。この長さフィールドはどのように決定され、どの要因がこれに影響しますか？

答え1

観察された長さの違いは、TCP分割オフロードによるものです。ほとんどの最新のネットワークカードは、パケットを断片化するときのCPU使用率を減らすためにハードウェアでこの機能をサポートしています。tcpdump断片化が発生する前にパケットを監視するので、設定されたパケットよりはるかに大きいパケットを見ることができますMTU（回線の実際のパケットは依然としてMTUサイズによって制限されます）。

ethtoolを使用して、NICのTCP分割オフロードを確認できます（例：eth0デバイスの確認）。

# ethtool -k  eth0 |grep 'tcp-segmentation-offload'
tcp-segmentation-offload: on

以下を使用して無効にできます。ethtool -K tso off

TSOが有効な場合に表示される送信データの例（最大64k - TCP制限）

15:08:22.451667 IP 192.168.230.9.43736 > 192.168.157.102.22: Flags [.], seq 32023713:32088873, ack 19886, win 340, options [nop,nop,TS val 3241810413 ecr 3874669422], length 65160
15:08:22.452203 IP 192.168.230.9.43736 > 192.168.157.102.22: Flags [.], seq 32088873:32154033, ack 19886, win 340, options [nop,nop,TS val 3241810413 ecr 3874669423], length 65160

TSOが無効になると、長さはMTU（ここでは1500）によって制限されます。

15:09:43.181882 IP 192.168.230.9.43738 > 192.168.157.102.22: Flags [.], seq 9881:11329, ack 4206, win 319, options [nop,nop,TS val 3241830596 ecr 3874750153], length 1448
15:09:43.181886 IP 192.168.230.9.43738 > 192.168.157.102.22: Flags [.], seq 11329:12777, ack 4206, win 319, options [nop,nop,TS val 3241830596 ecr 3874750153], length 1448

ペイロードの可変長は、NICがマージされるセグメントの数によって異なります。これは、その時点でサーバーのNICリソースとトラフィックによって異なります。

答え2

~から手動tcpdump

The general format of a TCP protocol line is:  
    src > dst: Flags [tcpflags], seq data-seqno, ack ackno, 
               win window, urg urgent, options [opts], length len   
Src and dst are the source and destination IP addresses and ports.
[...] Len is the length of payload data.

TCPでは、ペイロードデータはバイト単位で表されます。 （100％はわかりませんが、ファイルのtcpdumpソースにあります。）print-tcp.c長さフィールドのコメントにはバイトという用語だけが使用されており、アプリケーションが使用するデータであるTCPデータグラム内の実際のデータであることがわかります。

Kafkaは、送信されるメッセージの量によって帯域幅が異なるバイトストリームを送信できるメッセージングアプリケーションです。

この場合、フラグを読み取ることができるので（断片化されていない）、パケットにTCP断片化はありませんが[DF]問題ではありません。 TCPデータのうち、有用なデータの長さはlenght""バイトです。
サイズの選択方法は、TCPスタック（おそらくオペレーティングシステムによって異なります）と転送する必要があるデータ量によって異なります。
違いますがまったく問題ありません。 TCPは、100バイトのみを送信する必要があるときに65,365バイトを送信しないほど柔軟です。

関連情報