A melhor descrição que eu já ouvi que fez sentido do método de limitação inerente do TCP foi um podcast recente do Security Now . Para citar Steve Gibson:
Portanto, por acordo universal, o TCP sendo esse protocolo muito inteligente, faz algo chamado "início lento". Geralmente, é dada permissão para enviar um certo número de pacotes sem reconhecimento. Então, a ideia é, vamos colocar as coisas em movimento aqui. E normalmente esse número é dois. E assim, quando o TCP é iniciado, ele pode enviar dois pacotes, um após o outro. Sem que o primeiro seja reconhecido, ele enviará o segundo. Mas então espera. E a regra para a limitação é permitir que o número de pacotes não reconhecidos aumente em um para cada reconhecimento que recebermos.
Então, vamos pensar sobre isso. Permitimos que o número de pacotes não reconhecidos seja aumentado em um para cada reconhecimento que recebermos. Então, primeiro enviamos dois pacotes conforme o início acordado. Eles são reconhecidos. Portanto, temos nosso primeiro reconhecimento. Estávamos nos permitindo enviar dois. Agora, com o recebimento dessa primeira confirmação, aumentamos isso de um para três. Agora, podemos enviar mais três pacotes sem nenhum reconhecimento adicional. Quando um reconhecimento volta por tudo o que enviamos antes, aumentamos para quatro. Isso é conhecido como "janela de congestionamento". Não é uma janela que é enviada na linha, ou seja, não é como a janela de recebimento, que é 16 bits do cabeçalho TCP que nos diz quantos dados podemos enviar adiante. Este é - é uma janela. Isto'
Se continuarmos aumentando o número de pacotes não reconhecidos, podemos enviar um a cada vez que recebermos uma confirmação, em algum momento atingiremos um limite. E a beleza desse sistema é que, quando começarmos a tentar enviar pacotes mais rapidamente do que o link mais fraco, literalmente, entre roteadores, em algum momento, encontraremos o ponto em que o link mais fraco será quebrado. Ele descarta os pacotes que estamos tentando enviar porque estamos tentando enviá-los muito rápido. Portanto, os reconhecimentos do outro lado param porque os dados não estão mais chegando.
E o que o TCP faz é, se ele não recebeu - e isso varia de estratégia. Com o tempo, a estratégia e a estratégia real de prevenção de congestionamentos variaram bastante. Existem nomes como Tahoe e Reno, e muitos outros que você verá se pesquisar no Google e na Wikipedia, que especificam exatamente qual é o comportamento. Mas a ideia é que, quando o remetente percebe que seus dados não estão mais sendo recebidos porque faltam reconhecimentos, reduz sua taxa de envio rapidamente. Normalmente, ele divide ao meio. Então, ele aumenta drasticamente e volta a aumentá-lo.
Então, basicamente, o que isso significa é que a perda de pacotes é a função de sinalização para "Não podemos enviar os dados com mais rapidez" e que os remetentes TCP em cada extremidade de uma conexão, em toda a Internet, são sempre meio que - eles ' estão tentando ir mais rápido que a velocidade máxima disponível entre os dois pontos de extremidade, ou seja, o link mais fraco, onde quer que esteja, e eles estão sempre empurrando-o para o limite. Portanto, dado que há um ponto em algum lugar mais fraco do que a capacidade deles de enviar pacotes, eles o encontrarão porque bombearão os pacotes. Enquanto houver dados a serem enviados e eles tiverem uma conexão de largura de banda alta, o remetente aumentará a taxa de envio, ou seja, o número de pacotes pendentes, os pacotes que podem estar disponíveis em tempo real como agradecimentos volte, agressivamente continua movendo esse número para cima até empurrá-lo muito longe. Depois recua muito e depois avança novamente.
Portanto, é isso que realmente está acontecendo entre as conexões TCP que, provavelmente, não sei qual porcentagem, mas a maior porcentagem de tráfego na Internet é através de conexões TCP. Todos os nossos sistemas operacionais no kernel, na chamada pilha TCP, possuem esses contadores. E quando estamos enviando um arquivo, quando estamos carregando um arquivo grande ou recebendo uma página da web, o servidor do outro lado está fazendo a mesma coisa. Ele está empurrando, em uma base de conexão individual, o maior número de pacotes que ainda não foram reconhecidos, aumentando a taxa de pacotes até atingir o ponto em que começa a falhar ou gaguejar. Depois, ele recua, para permitir que as coisas se recuperem e, em seguida, começa a trabalhar novamente.
E isso acaba sendo uma espécie de sistema de auto-estrangulamento que, dadas as restrições, quero dizer, realmente parece meio desagradável e grosseiro ".