syn / ack confusão no número de sequência

Question

Eu estava olhando para algum tráfego aleatório no wireshark e me deparei com isso (usando números seq / ack relativos):

    1. myIP          -> 74.125.227.96  [SYN]        seq=0
    2. 74.125.227.96 -> myIP           [SYN/ACK]    seq=0     ack=1
    3. myIP          -> 74.125.227.96  [ACK]        seq=1     ack=1
    4. myIP          -> 74.125.227.96  [ACK]        seq=1     ack=1     len=14600
    5. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=2921
    6. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=5841
    7. myIP          -> 74.125.227.96  [ACK]        seq=14601 ack=1     len=8760
    8. 74.125.227.96 -> myIP           [ACK]        seq=1     ack=8761 
    9. myIP          -> 74.125.227.96  [ACK]        seq=23361 ack=1     len=4380
    etc...

Eu estava usando o link como um recurso e parece seq = ack anterior e ack + = previous seq + len / flags (por favor me corrija se eu estiver errado). Mas o que está acontecendo nas linhas 4-7? O pacote está sendo fragmentado ou algo assim? Os números seq / ack não parecem somar para mim, então onde estou indo errado?

    

Answer 1

Numeração de Seqüências TCP

Há algumas coisas para lembrar ao decodificar rastreamentos TCP ...

1. Os números de sequência TCP são direcionais (ou seja, se alguém me enviar uma carga útil, não aumentarei meu número de sequência com base nos bytes recebidos)
2. Os números de sequência TCP apontam para o cabeçalho da carga útil de um pacote

No entanto, esses pontos sozinhos não levam em conta os ACKs perdidos para os números 5841-14600 entre os pacotes 6 e 7. Meu melhor palpite (e isso é tudo que eu realmente posso fazer neste momento) é que você pode ter descartado ACK pacotes em algum lugar entre o NIC e o wireshark. Você pode dizer quando isso acontece se você vir mensagens como esta (de uma sessão linux xterm ou ssh) ...

19431 packets captured
38863 packets received by filter
572 packets dropped by kernel  <----------------
7 packets dropped by interface <----------------

Soluções para dropshark packet drops

• Reduza o tamanho dos pacotes que o wireshark examina (100 bytes por pacote é normalmente mais do que suficiente)
• Desativar pesquisas de DNS e rolagem de captura ao vivo (a captura de buffer de disco é mais eficiente)

• No linux você pode consertar estas gotas ajustando os buffers no NIC e entre o kernel e a libpcap ^{Nota 1} ...

  ethtool -G eth0 rx 768

  sysctl -w net.core.netdev_max_backlog=30000

• Se você está no Windows, isso ajuda a dar ao wireshark mais espaço no buffer (a opção -B CLI) quando você o chama ...

Nota 1. YMMV, configurações de buffer são específicas para o seu sistema ... brinque com elas até que você não veja pacotes de mensagens descartadas

    

Answer 2

Talvez fragmentação. Talvez outra sessão para o servidor. Portas eq? O Wireshark pode selecionar todos os pacotes em uma sessão tcp da interface (selecionando no menu rcm no pacote)