Não, o TCP aplica um mecanismo de "janela deslizante" para reduzir o número de confirmações necessárias.
Uma boa visualização e explicação: link
Se um programa tcp A enviar dois pacotes de dados para outro programa TCP B, pacote 1: número sequencial de 1000 a 2000; pacote 2: número de seq. 2000 a 3000.
Geralmente, B deve responder com 2 ACKs, um para confirmar o pacote 1 e outro para o pacote 2. Agora, se apenas o segundo ACK for recebido por A, o A ainda aguardará o primeiro ACK ou não?
Eu sei que o TCP é um protocl fluxo de byte orientado. então A não deve esperar pelo primeiro ACK, certo? Em teoria, é assim, que tal a pilha TCP real implementada?
BTW, eu tenho uma pergunta especial. Se A enviar para B um ACK para com ack seq number 3001 (isto é para confirmar o pacote 2). Mas alguém no meio modifica o número de confirmação para 2501, isto é, B reconhece metade do pacote TCP. Então A retransmitirá de byte que corresponde a seq 2000 ou 2501?
O TCP apresentará números de sequência, não pacotes. Assim, mesmo sem "alguém no meio", o Programa A pode reconhecer apenas uma fração de um pacote recebido (ou seja, o soquete não tem espaço de buffer suficiente para todo o pacote). No seu exemplo, 2501 será retransmitido por Programa B.
O TCP também suporta Ack seletivo, de modo que apenas um segmento ausente (no espaço numérico de seq) precisa ser transmitido
B oferece uma 'janela' (de espaço em buffer) para A em sua confirmação. Um não precisa esperar por uma confirmação específica antes de enviar os pacotes subsequentes, desde que não exceda a janela atual do B .
Advertência: Muito simplificada, tanto no interesse da brevidade quanto devido à minha compreensão um tanto limitada do protocolo. RFC: 813 - ESTRATÉGIA DE WINDOW E RECONHECIMENTO EM TCP fala sobre essa mesma técnica.
Tags networking tcp