quais são os valores válidos de 'ack'?

Question

ter um problema com um fornecedor que alega a causa de um problema é um valor 'ack' inválido nos dados tcp. Estou usando java, então não escrevi essa camada. Eu usei snoop para capturar o tráfego no fio e estou usando wireshark para exibir os dados. Eis aqui o que está acontecendo. Depois de receber uma mensagem com vários pacotes (5), vejo uma resposta multi-pack (3). O primeiro pacote na resposta tem um valor para 'ack' diferente do valor 'ack' nos outros dois pacotes. O fornecedor afirma que esses dados são suspeitos. Eu forneci dados de amostra abaixo. Eu não sou um especialista em TCP, então não sei se isso é um problema ou não. Eu tentei encontrar algo em valores de ack válidos e parece-me que o valor deve ser 80018, mas isso não significa que o 78345 está errado. Eu encontrei isso na web e parece se aplicar, mas não tenho certeza: "o valor de ack de qualquer segmento de dados é considerado válido desde que não reconheça os dados antes do próximo segmento a ser enviado". Obrigado pela ajuda. Meu entendimento é que o fornecedor escreveu sua própria camada de tcp.

    source seq     ack    len   time
    me     10734   75465  190   yyyymmdd 09:18:21.785757
    vendor 75465   10924  0     yyyymmdd 09:18:21.789319
    vendor 75465   10924  1440  yyyymmdd 09:18:34.196661
    vendor 76905   10924  1440  yyyymmdd 09:18:34.196762
    vendor 78345   10924  1440  yyyymmdd 09:18:34.196901
    vendor 79785   10924  233   yyyymmdd 09:18:34.196915
    me     10924   78345  0     yyyymmdd 09:18:34.196968
    me     10924   80018  0     yyyymmdd 09:18:34.197102
    me     10924   80018  197   yyyymmdd 09:18:34.579479

    

Answer 1

link diz

Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.

Isso sugere que o primeiro pacote de resposta está confirmando o recebimento dos três primeiros pacotes do fornecedor (seq 76905 + len 1440 = 78345)

O segundo pacote de resposta confirma o recebimento do quarto e quinto pacotes do fornecedor (seq 79785 + len 233 = 80018)

O terceiro pacote de resposta indica que nenhum dado adicional foi recebido de fornecedor (mesmo ack) e contém uma carga útil de 197 bytes.

Isso parece certo para mim.

Se seus dados são toda a conversação, o ack inicial estaria errado, já que deveria ack o primeiro pacote do fornecedor com um ack de 75465 (seq 75465 + 1 = 75466).

Aqui está uma sequência que capturei com o wireshark. Primeiro, vemos o handshake de três vias, depois a transmissão de um pedido HTTP get seguido por uma resposta HTTP

Source    Flags      Seq      Ack     Len  
client    SYN          0        -       0  
server    SYN,ACK      0        1       0  
client    ACK          1        1       0  
client    -            1        1     429     Get ...
server    ACK          1      430       0  
server    -            1      430    1456     HTML response
server    -         1457      430    1456  
client    ACK        430     2913       0  
...   

Os números de sequência e ack são relativos (para o número inicial escolhido aleatoriamente de cada extremidade)

O uso de uma única conexão para uma sequência de solicitações é uma otimização comum. Ele foi adicionado ao HTTP na versão 1.1 e conhecido como conexões persistentes . Configurar e derrubar conexões TCP tem um custo.

    

Answer 2

Resumidamente, o campo ACK é usado para indicar o próximo número de seqüência que um receptor espera receber de um remetente. Ou seja, o número de sequência do último segmento recebido + comprimento desse segmento. (Existem alguns outros usos relacionados a perdas / retransmissões, mas deixaremos isso de lado por enquanto).

O TCP é projetado para que vários segmentos possam ser reconhecidos em uma única resposta. Isso permite uma utilização mais eficiente dos links de alta latência. Veja RFC1122 e RFC2581 , em particular as seções sobre agradecimentos atrasados.

Em termos de sua pergunta específica: uma pilha TCP sempre terá algum nível de intercalação; isto é, mesmo que o pacote final (seq 79785) tivesse sido colocado no buffer de recebimento, ele pode não ter sido processado no tempo permitido antes que um ACK tivesse que ser enviado de volta para a outra extremidade da conexão. Os cabeçalhos que você forneceu parecem descrever uma conversa TCP completamente normal para mim. A explicação do seu fornecedor parece duvidosa, na melhor das hipóteses.