O tópico de retransmissão foi amplamente documentado em toda a rede e na literatura relevante, portanto, para o caso de uma retransmissão devido a expiração de tempo limite de segmento, estou apenas citando um documento da Novell com alguns exemplos de captura de pacotes :
O TCP implementa confiabilidade enviando uma confirmação para os segmentos de dados recebidos. [...] [T] o emissor é forçado a retransmitir todos os segmentos após a perda do segmento ser detectada por um tempo limite de retransmissão.
[...]
A Figura 3 descreve um traçado TCP em que bytes em ordem até o número de sequência de 2028597920 são recebidos corretamente, momento em que há uma perda de segmento. Inconsciente da perda, o remetente continua a enviar dados até 2028605220, momento em que retransmite o segmento perdido e todo o canal de dados até 2028605220 novamente. Isso resulta na retransmissão de cinco pacotes que foram recebidos com sucesso.
Retransmissãotípicaedrenagemdotubo.
UsandooesquemadeConfirmaçãoSeletiva,umreceptorpodereconhecerseletivamenteossegmentosqueforamrecebidosapósaperda.Oremetenteprecisaapenasretransmitirossegmentosperdidos.Essessegmentosoupacotesperdidostambémsãoreferidoscomo"buracos" no fluxo de dados.
Se você está vendo apenas as características de retransmissão rápida / recuperação rápida de acordo com a RFC 2581 , o comportamento de retransmissão seria um pouco diferente. HOST B iria emitir ACKs duplicados de acordo com o seu valor indicando para HOST A que um segmento necessita de retransmissão. E é claro que também receberia e armazenaria os segmentos subsequentes até o tamanho de sua janela de recebimento - é assim que o mecanismo de reordenamento de segmentos funciona. Após a recepção do segmento em falta, o mecanismo de reordenação seria capaz de montar o fluxo e a pilha de HOST B ACK o último segmento recebido (157).