ter um problema com um fornecedor que afirma que a causa do problema é um valor 'ack' inválido nos dados tcp. Estou usando java, então não escrevi essa camada. Usei o snoop para capturar o tráfego na rede e estou usando o wireshark para exibir os dados. Eis aqui o que está acontecendo. Depois de receber uma mensagem multi-packet(5), vejo uma resposta multi-pack(3). O primeiro pacote na resposta tem um valor para 'ack' que é diferente do valor 'ack' nos outros dois pacotes. O fornecedor afirma que esses dados são suspeitos. Forneci dados de amostra abaixo. Não sou especialista em TCP, então não sei se isso é um problema ou não. Tentei encontrar algo sobre valores de confirmação válidos e me parece que o valor deveria ser 80018, mas isso não significa que 78345 esteja errado. Encontrei isso na web e parece se aplicar, mas não tenho certeza: "o valor de confirmação 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 TCP.
fonte seq ack len time
eu 10734 75465 190 aaaammdd 09:18:21.785757
fornecedor 75465 10924 0 aaaammdd 09:18:21.789319
fornecedor 75465 10924 1440 aaaammdd 09:18:34.196661
fornecedor 76905 10924 1440 aaaammdd 09:18:34.196762
fornecedor 78345 10924 1440 aaaammdd 09:18:34.196901
fornecedor 79785 10924 233 aaaammdd 09:18:34.196915
eu 10924 78345 0 aaaammdd 09:18:34.196968
eu 10924 80018 0 aaaammdd 09:18:34.197102
eu 10924 80018 197 aaaammdd 09:18:34.579479
Responder1
http://en.wikipedia.org/wiki/Transmission_Control_Protocoldiz
Número de confirmação (32 bits) – se o sinalizador ACK estiver definido, o valor deste campo será o próximo número de sequência que o receptor está esperando. Isso confirma o recebimento de todos os bytes anteriores (se houver). O primeiro ACK enviado por cada extremidade reconhece o próprio número de sequência inicial da outra extremidade, mas nenhum dado.
Isto sugere que o primeiro pacote de resposta está confirmando o recebimento dos três primeiros pacotes dofornecedor(seq 76905 + lente 1440 = 78345)
O segundo pacote de resposta confirma o recebimento do 4º e 5º pacotes dofornecedor(seq 79785 + lente 233 = 80018)
O terceiro pacote de resposta indica que nenhum outro dado foi recebido dofornecedor(mesmo ack) e contém uma carga útil de 197 bytes.
Isso parece bom para mim.
Se seus dados forem toda a conversa, a confirmação inicial estaria errada, pois deveria confirmar o primeiro pacote defornecedorcom um reconhecimento 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 uma solicitação HTTP get seguida por uma resposta HTTP
Sinalizadores de origem Seq Ack Len cliente SYN 0 - 0 servidor SYN,ACK 0 1 0 cliente ACK 1 1 0 cliente - 1 1 429 Obtenha ... servidor ACK 1 430 0 servidor - 1 430 1456 resposta HTML servidor - 1457 430 1456 cliente ACK 430 2913 0 ...
Os números de sequência e confirmação são relativos (ao número inicial escolhido aleatoriamente de cada extremidade)
Usar uma única conexão para uma sequência de solicitações é uma otimização comum. Foi adicionado ao HTTP na versão 1.1 e conhecido comoconexões persistentes. Configurar e desativar conexões TCP tem um custo.
Responder2
Resumidamente, o campo ACK é usado para indicar o próximo número de sequê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 ao tratamento de perdas/retransmissões, mas vamos deixá-los de fora por enquanto).
O TCP foi projetado para que vários segmentos possam ser reconhecidos em uma única resposta. Isso permite uma utilização mais eficiente de links de alta latência. VerRFC1122eRFC2581, em particular as seções sobre reconhecimentos tardios.
Em termos da sua pergunta específica: uma pilha TCP sempre terá algum nível de intercalação; isto é, mesmo que o pacote final (seq 79785) tenha sido colocado no buffer de recebimento, ele pode não ter sido processado no tempo permitido antes que um ACK fosse enviado de volta para a outra extremidade da conexão. Os cabeçalhos que você forneceu parecem representar uma conversa TCP completamente normal para mim. A explicação do seu fornecedor parece, na melhor das hipóteses, duvidosa.