TCP Retransmission Behavior
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
9/8/2008
TCP inicia um timer de retransmissão quando cada segmento é entregue para baixo para IP de saída. Se nenhuma confirmação foi recebida para os dados em um determinado segmento antes que o timer expire, o segmento será retransmitido. Para solicitações conexão nova, o timer de retransmissão é inicializado para 3 segundos (controláveis usando o TcpInitialRtt Por-adaptador Registro parâmetro), e a solicitação (SYN) é reenviada up to o valor especificado em TcpMaxConnectRetransmissions (o usar como padrão para Windows Embedded CE é duas vezes). Nas conexões existentes, o número de retransmissões é controlado pelos TcpMaxDataRetransmissions parâmetro Registro (Por padrão cinco). O tempo limite de retransmissão é ajustado de forma instantânea para coincidir com as características da conexão, usando cálculos Smoothed Round Trip Time (SRTT) conforme descrito no papel do Van Jacobson Congestion Avoidance e controle. O timer para um determinado segmento é dobrado após cada retransmissão de segmento. Usando esse algoritmo, TCP ajusta próprio para o atraso normal de uma conexão. TCP conexões através de links de alto atraso demorar muito mais para tempo limite daqueles através de links Low-Delay.
Observação
Aumentar um dos parâmetros de Registro TcpMaxDataRetransmissions Ou TcpMaxConnectRetransmissions Por um aproximadamente dobra a tempo limite de retransmissão total período.Se for necessário configurar os tempos limite maior, esses parâmetros devem ser aumentados muito gradualmente.
O seguinte rastrear rede mostra o algoritmo de retransmissão para dois hosts conectados pela Ethernet na mesma sub-rede. Foi um transferência de arquivo FTP em andamento quando a hospedar recebimento foi desconectado a partir de rede. Como o SRTT para esta conexão foi muito pequeno, a primeira retransmissão foi enviada após cerca de metade segundo. O timer, em seguida, foi duplicado para cada um das retransmissões que seguido. Após o quinto retransmissão, o timer novamente foi dobrado. Se nenhuma confirmação foi recebida antes ele expirou, a conexão foi interrompida.
delta source ip dest ip pro flags description
0.000 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
0.521 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
1.001 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
2.003 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
4.007 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
8.130 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760
Há algumas circunstâncias sob as quais TCP retransmite dados prior to o tempo que o timer de retransmissão expira. The most comum dessas ocorre devido a Retransmitir rápida. Quando um destinatário que ofereça suporte a retransmissão rápida recebe dados com uma seqüência número além de atual esperado um, ele pressupõe que alguns dados foi descartados. Para ajudar a tornar o remetente ciente deste evento, o receptor envia imediatamente uma ACK, com o Conjunto número ACK para número de seqüência que ele estava esperando. Ele continua fazer isso para cada segmento TCP adicional que chega contendo dados subsequent to os dados faltando na de entrada transmitir. Quando o remetente começa a receber um stream of ACKs que são confirmando o mesmo número seqüência e esse número seqüência for anterior a atual número seqüência que está sendo enviado, ele pode inferir que um segmento (ou mais) devem ter sido descartado. Remetentes que suporte o rápido retransmitir algoritmo imediatamente reenviar o segmento que o receptor está esperando para preencher na lacuna nos dados, sem esperar que o timer de retransmissão para expirar para esse segmento. Esta otimização melhora bastante desempenho em um ocupado ambiente rede.
Por padrão, Windows Embedded CE reenvia um segmento se ele recebe três ACKs para o mesmo número seqüência e esse número seqüência lags o atual um. Isso é controláveis com o TcpMaxDupAcks parâmetro Registro. Para obter mais informações sobre como Windows Embedded CE confirma segmentos que não têm o número seqüência mais recente, consulte TCP de confirmação seletiva.