O que e como o comprimento é determinado no tcpdump

Question

O que e como o comprimento é determinado no tcpdump

#1 resposta do (0 votos)
#2 resposta do (0 votos)

3

O que meu aplicativo faz é ler os dados do kafka e acessar outro serviço via HTTP. Eu estava vendo o tráfego de saída mais lento em uma caixa, comparado a outros. Eu analisei o tcpdump para esse IP de saída, registra a partir desta caixa:

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

Enquanto, ao mesmo tempo, na outra caixa, vejo o seguinte:

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

Eu vejo grande diferença no campo: comprimento, enquanto no primeiro caso é muito pequeno, enquanto no caso posterior ele é grande e os dados inteiros estão sendo transferidos muito rapidamente. Como esse campo de comprimento é determinado, que fator impacta isso?

tcpdump

por Saurabh 06.10.2018 / 06:17

2 respostas

Tags tcpdump

ping 192.168.0.1 | awk '{print $ 1}' [duplicado] Fedora 28: Gerar ticket do kerberos no login

score 0 · Answer 1

Do manual de 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.

No TCP, os dados da carga útil são expressos em bytes, (não tenho 100% de certeza, mas nas fontes do tcpdump no arquivo print-tcp.c você pode ver que apenas o termo bytes é usado no comentário em relação ao campo de comprimento), e são os dados reais dentro do seu datagrama TCP, os dados que seu aplicativo usará.

O Kafka é um aplicativo de mensagens e provavelmente envia um fluxo de bytes variando em banda larga usado com a quantidade de mensagens a enviar.

Embora seu pacote não seja fragmentado por TCP neste caso, como podemos ler o sinalizador [DF] (não fragmentar), não importa. os dados úteis dentro de seus dados TCP são " lenght " bytes longos.
A escolha do tamanho depende da sua pilha TCP (provavelmente o seu sistema operacional é responsável por isso) e quantos dados ele precisa enviar. Isso varia e não é um problema de todo o TCP é flexível o suficiente para não enviar 65.365 bytes quando precisar enviar 100 bytes.

score 0 · Answer 2

A diferença no comprimento observada é devido ao descarregamento da segmentação TCP. A maioria das placas de rede mais recentes suporta esse recurso no hardware, para reduzir o uso da CPU na segmentação de pacotes. tcpdump está observando os pacotes antes que a segmentação ocorra, portanto, ele vê os pacotes bem maiores do que o configurado MTU (o pacote real no fio ainda seria limitado por MTU size)

Você pode verificar o descarregamento de segmentação tcp para sua NIC, usando o ethtool (Por exemplo, para verificar o dispositivo eth0)

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

Pode ser desativado usando ethtool -K tso off

Exemplo de dados de saída vistos com o TSO ativado (Máximo atingindo até 64k - limite de 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

com o TSO desativado, o comprimento é limitado pelo MTU (aqui é 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

O comprimento variável da carga útil é devido ao número de segmentos mesclados pela NIC. Pode variar com base nos recursos da NIC & tráfego no momento no servidor.