operações de protocoloTCP podem ser divididas em três fases. O estabelecimento da ligação é um processo de aperto de mão em várias fases que estabelece uma ligação antes de entrar na fase de transferência de dados. Após a conclusão da transferência de dados, a terminação da ligação fecha a ligação e liberta todos os recursos atribuídos.
Uma ligação TCP é gerida por um sistema operacional através de um recurso que representa o ponto final local para as comunicações, a tomada de Internet. Durante a vida útil de uma ligação TCP, o ponto final local sofre uma série de alterações de estado:
| State | Endpoint | Description |
|---|---|---|
| LISTEN | Servidor | Esperar por um pedido de ligação de qualquer terminal TCP remotoponto. |
| SYN-SENT | Client | Esperar por um pedido de ligação correspondente depois de ter enviado um pedido de ligação. |
| SYN-RECEIVED | Servidor | A aguardar um pedido de confirmação de ligação depois de ter recebido e enviado um pedido de ligação. |
| ESTABELECIDO | Servidor e cliente | Uma ligação aberta, os dados recebidos podem ser entregues ao utilizador. O estado normal para a fase de transferência de dados da ligação. |
| Servidor e cliente | A aguardar um pedido de terminação de ligação do TCP remoto, ou um reconhecimento do pedido de terminação de ligação previamente enviado. | |
| FIN-WAIT-2 | Servidor e cliente | Esperar por um pedido de terminação de ligação do TCP remoto. |
| CLOSE-WAIT | Servidor e cliente | Esperar por um pedido de terminação de ligação do utilizador local. |
| CLOSE-WAIT | Servidor e cliente | A aguardar um pedido de confirmação de terminação de ligação a partir do TCP remoto. |
| LAST-ACK | Servidor e cliente | A aguardar uma confirmação do pedido de terminação de ligação previamente enviado ao TCP remoto (que inclui uma confirmação do seu pedido de terminação de ligação). |
| TIME-WAIT | Servidor ou cliente | Esperar por tempo suficiente para ter a certeza de que o TCP remoto recebeu o aviso de recepção do seu pedido de terminação de ligação. |
| CLOSED | Servidor e cliente | Sem estado de ligação. |
Estabelecimento de ligaçãoEdit
Antes de um cliente tentar ligar-se a um servidor, o servidor deve primeiro ligar-se e ouvir numa porta para o abrir para ligações: a isto chama-se uma abertura passiva. Uma vez estabelecida a abertura passiva, um cliente pode estabelecer uma ligação iniciando uma abertura activa usando o aperto de mão de três vias (ou 3 passos):
- SYN: A abertura activa é realizada pelo cliente que envia um SYN para o servidor. O cliente define o número de sequência do segmento para um valor aleatório A.
- SYN-ACK: Em resposta, o servidor responde com um SYN-ACK. O número de reconhecimento é definido para mais um do que o número sequencial recebido, isto é, A+1, e o número sequencial que o servidor escolhe para o pacote é outro número aleatório, B.
- ACK: Finalmente, o cliente envia um ACK de volta para o servidor. O número de sequência é definido para o valor de reconhecimento recebido, isto é, A+1, e o número de reconhecimento é definido para mais um do que o número de sequência recebido, isto é, B+1.
P>Passos 1 e 2 estabelecem e reconhecem o número de sequência para uma direcção. Os passos 2 e 3 estabelecem e confirmam o número de sequência para a outra direcção. Após a conclusão destes passos, tanto o cliente como o servidor receberam confirmações e é estabelecida uma comunicação full-duplex.
Terminação da ligaçãoEdit
A fase de terminação da ligação utiliza um aperto de mão de quatro vias, com cada lado da ligação terminando independentemente. Quando um terminal deseja interromper a sua metade da ligação, transmite um pacote FIN, que a outra extremidade reconhece com um ACK. Portanto, uma desmontagem típica requer um par de segmentos FIN e ACK de cada ponto terminal TCP. Após o lado que enviou o primeiro FIN ter respondido com o ACK final, espera por um tempo limite antes de finalmente fechar a ligação, durante o qual a porta local não está disponível para novas ligações; isto evita confusão devido ao atraso na entrega de pacotes durante as ligações subsequentes.
Uma ligação pode ser “semi-aberta”, caso em que um lado terminou o seu fim, mas o outro não. O lado que terminou já não pode enviar quaisquer dados para a ligação, mas o outro lado pode. O lado que terminou deve continuar a ler os dados até que o outro lado também termine.
É também possível terminar a ligação através de um aperto de mão de 3 vias, quando o anfitrião A envia uma resposta FIN e o anfitrião B com uma FIN & ACK (combina apenas 2 passos num) e o anfitrião A responde com uma ACK.
alguns sistemas operativos, tais como Linux e H-UX, implementam uma sequência de fecho half-duplex na pilha TCP. Se o anfitrião fechar activamente uma ligação, enquanto ainda tiver disponíveis dados de entrada não lidos, o anfitrião envia o sinal RST (perdendo quaisquer dados recebidos) em vez de FIN. Isto assegura a uma aplicação TCP que o processo remoto tenha lido todos os dados transmitidos, esperando pelo sinal FIN, antes de fechar activamente a ligação. O processo remoto não consegue distinguir entre um sinal RST para abortar a ligação e a perda de dados. Ambos causam à pilha remota a perda de todos os dados recebidos.
algumas aplicações que utilizam o protocolo TCP abrir/fechar o aperto de mão podem encontrar o problema do RST no fecho activo. Como exemplo:
s = connect(remote);send(s, data);close(s);
Para um fluxo de programa como o acima descrito, uma pilha TCP/IP como a descrita acima não garante que todos os dados cheguem à outra aplicação se os dados não lidos tiverem chegado a este fim.
Utilização de recursosEditar
A maior parte das implementações atribui uma entrada numa tabela que mapeia uma sessão a um processo de sistema operativo em execução. Como os pacotes TCP não incluem um identificador de sessão, ambos os pontos finais identificam a sessão usando o endereço e a porta do cliente. Sempre que um pacote é recebido, a implementação TCP deve efectuar uma pesquisa sobre esta tabela para encontrar o processo de destino. Cada entrada na tabela é conhecida como um Bloco de Controlo de Transmissão ou TCB. Contém informação sobre os pontos finais (IP e porta), estado da ligação, dados em execução sobre os pacotes que estão a ser trocados e buffers para enviar e receber dados.
O número de sessões no lado do servidor é limitado apenas pela memória e pode crescer à medida que novas ligações chegam, mas o cliente deve atribuir uma porta aleatória antes de enviar o primeiro SYN para o servidor. Esta porta permanece atribuída durante toda a conversa, e limita efectivamente o número de conexões de saída de cada um dos endereços IP do cliente. Se uma aplicação não conseguir fechar correctamente as ligações não requeridas, um cliente pode ficar sem recursos e tornar-se incapaz de estabelecer novas ligações TCP, mesmo a partir de outras aplicações.
ambos os pontos terminais devem também atribuir espaço para pacotes não reconhecidos e dados recebidos (mas não lidos).
Transferência de dadosEditar
O Protocolo de Controlo de Transmissão difere em várias características chave do Protocolo de Datagrama de Utilizador:
- Transferência de dados ordenada: o anfitrião de destino rearranja segmentos de acordo com um número de sequência
- Retransmissão de pacotes perdidos: qualquer fluxo cumulativo não reconhecido é retransmitido
- Transferência de dados sem erros
- Controlo de fluxo: limita a taxa que um remetente transfere dados para garantir uma entrega fiável. O receptor indica continuamente ao remetente a quantidade de dados que podem ser recebidos (controlados pela janela deslizante). Quando o buffer do receptor preenche, o próximo aviso de recepção contém um 0 no tamanho da janela, para parar a transferência e permitir que os dados no buffer sejam processados.
- Controlo de contigestão
Transmissão fiávelEditar
TCP utiliza um número de sequência para identificar cada byte de dados. O número sequencial identifica a ordem dos bytes enviados de cada computador para que os dados possam ser reconstruídos em ordem, independentemente de qualquer reordenamento de pacotes, ou perda de pacotes que possam ocorrer durante a transmissão. O número de sequência do primeiro byte é escolhido pelo transmissor para o primeiro pacote, que é sinalizado SYN. Este número pode ser arbitrário, e deve, de facto, ser imprevisível para se defender contra ataques de predição de sequência TCP.
Acknowledgements (ACKs) são enviados com um número de sequência pelo receptor dos dados para dizer ao remetente que os dados foram recebidos para o byte especificado. As ACKs não implicam que os dados tenham sido entregues ao pedido. Apenas significam que é agora da responsabilidade do receptor entregar os dados.
Religibilidade é alcançada pelo remetente detectando os dados perdidos e retransmitindo-os. O TCP utiliza duas técnicas primárias para identificar a perda. Timeout de retransmissão (abreviado como RTO) e reconhecimento cumulativo duplicado (DupAcks).
Retransmissão baseada em DupackEdit
Se um único segmento (digamos segmento 100) num fluxo for perdido, então o receptor não pode reconhecer pacotes acima do não. 100, porque utiliza ACKs cumulativos. Assim, o receptor reconhece novamente o pacote 99 aquando da recepção de outro pacote de dados. Este reconhecimento duplicado é utilizado como sinal de perda de pacotes. Ou seja, se o remetente receber três confirmações duplicadas, retransmite o último pacote não reconhecido. É utilizado um limiar de três porque a rede pode reordenar segmentos causando reconhecimentos duplicados. Este limiar foi demonstrado para evitar retransmissões espúrias devido à reordenação. Por vezes são utilizados reconhecimentos selectivos (SACKs) para fornecer feedback explícito sobre os segmentos que foram recebidos. Isto melhora muito a capacidade do TCP de retransmitir os segmentos certos.
Retransmissão baseada no tempoEditar
Quando um remetente transmite um segmento, inicia um temporizador com uma estimativa conservadora da hora de chegada do aviso de recepção. O segmento é retransmitido se o temporizador expirar, com um novo limiar de timeout de duas vezes o valor anterior, resultando num comportamento de backoff exponencial. Tipicamente, o valor inicial do temporizador é suavizado RTT + max ( G , 4 × variação RTT ) {\i1}+++++(G , 4 vezes {\i1}variação RTT do texto
, onde G {\i1}displaystyle G
é a granularidade do relógio. Isto protege contra o tráfego excessivo de transmissão devido a actores defeituosos ou maliciosos, tais como atacantes de negação de serviço de homem no meio.
Detecção de errosEditar
Números de sequência permitem aos receptores descartar pacotes duplicados e reordenar adequadamente os pacotes. Os reconhecimentos permitem aos remetentes determinar quando retransmitir pacotes perdidos.
Para assegurar a correcção, é incluído um campo de soma de controlo; ver a secção de cálculo da soma de controlo para detalhes sobre a soma de controlo. A soma de controlo TCP é uma verificação fraca pelos padrões modernos. As camadas de ligação de dados com elevadas taxas de erros de bit podem exigir capacidades adicionais de correcção/detecção de erros de ligação. A soma de verificação fraca é parcialmente compensada pela utilização comum de um CRC ou melhor verificação de integridade na camada 2, abaixo tanto do TCP como do IP, tal como é utilizado em PPP ou na moldura Ethernet. Contudo, isto não significa que a soma de verificação TCP de 16 bits seja redundante: notavelmente, a introdução de erros em pacotes entre lúpulos protegidos por CRC é comum, mas a soma de verificação TCP de ponta a ponta de 16 bits captura a maioria destes erros simples. Este é o princípio end-to-end no trabalho.
Flow controlEdit
TCP utiliza um protocolo de controlo de fluxo end-to-end para evitar que o remetente envie dados demasiado depressa para que o receptor TCP os receba e processe de forma fiável. Ter um mecanismo de controlo de fluxo é essencial num ambiente em que máquinas de diversas velocidades de rede comunicam. Por exemplo, se um PC envia dados para um smartphone que está lentamente a processar dados recebidos, o smartphone deve regular o fluxo de dados para não ser sobrecarregado.
TCP utiliza um protocolo de controlo de fluxo de janela deslizante. Em cada segmento TCP, o receptor especifica no campo da janela de recepção a quantidade de dados recebidos adicionalmente (em bytes) que está disposto a guardar para a ligação. O anfitrião emissor só pode enviar até essa quantidade de dados antes de ter de esperar por um reconhecimento e actualização da janela do anfitrião receptor.
Quando um receptor anuncia uma janela de tamanho 0, o remetente pára de enviar dados e inicia o temporizador persistente. O temporizador persistente é utilizado para proteger o TCP de uma situação de impasse que possa surgir se uma actualização subsequente do tamanho da janela do receptor for perdida, e o remetente não pode enviar mais dados até receber uma nova actualização do tamanho da janela do receptor. Quando o temporizador persistente expira, o remetente TCP tenta a recuperação enviando um pequeno pacote para que o receptor responda enviando outro aviso de recepção contendo o novo tamanho de janela.
Se um receptor estiver a processar dados recebidos em pequenos incrementos, pode anunciar repetidamente uma pequena janela de recepção. Isto é referido como a síndrome da janela tola, uma vez que é ineficiente enviar apenas alguns bytes de dados num segmento TCP, dada a sobrecarga relativamente grande do cabeçalho TCP.
Controlo de congestionamentoEditar
O último aspecto principal do TCP é o controlo de congestionamento. O TCP usa uma série de mecanismos para alcançar um alto desempenho e evitar o colapso do congestionamento, onde o desempenho da rede pode cair por várias ordens de magnitude. Estes mecanismos controlam a taxa de entrada de dados na rede, mantendo o fluxo de dados abaixo de uma taxa que provocaria o colapso. Também produzem uma distribuição justa entre os fluxos de dados, aproximadamente no intervalo máximo-minuto.
Conhecimento dos dados enviados, ou falta de reconhecimento, são utilizados pelos remetentes para inferir as condições da rede entre o emissor e o receptor do TCP. Juntamente com os temporizadores, os remetentes e receptores de TCP podem alterar o comportamento do fluxo de dados. Isto é mais geralmente referido como controlo de congestionamento e/ou prevenção de congestionamento da rede.
Aplicações modernas de TCP contêm quatro algoritmos interligados: arranque lento, prevenção de congestionamento, retransmissão rápida, e recuperação rápida (RFC 5681).
Além disso, os remetentes empregam um timeout de retransmissão (RTO) que se baseia no tempo estimado de ida e volta (ou RTT) entre o remetente e o receptor, bem como a variação neste tempo de ida e volta. O comportamento deste temporizador é especificado no RFC 6298. Há subtilezas na estimativa do RTT. Por exemplo, os remetentes devem ter cuidado ao calcularem amostras RTT para pacotes retransmitidos; tipicamente utilizam o Algoritmo de Karn ou carimbos de tempo TCP (ver RFC 1323). Estas amostras individuais de RTT são então calculadas em média ao longo do tempo para criar um Tempo de Viagem Redonda Suavizada (SRTT) usando o algoritmo de Jacobson. Este valor de SRTT é o que é finalmente utilizado como estimativa do tempo de ida e volta.
Aumentar o TCP para lidar de forma fiável com perdas, minimizar erros, gerir congestionamentos e avançar rapidamente em ambientes de muito alta velocidade são áreas de investigação e desenvolvimento de padrões em curso. Como resultado, há uma série de variações do algoritmo TCP para evitar o congestionamento.
Tamanho máximo do segmentoEditar
O tamanho máximo do segmento (MSS) é a maior quantidade de dados, especificados em bytes, que o TCP está disposto a receber num único segmento. Para um melhor desempenho, o MSS deve ser definido suficientemente pequeno para evitar a fragmentação IP, o que pode levar à perda de pacotes e a retransmissões excessivas. Para tentar conseguir isto, normalmente o MSS é anunciado por cada lado utilizando a opção MSS quando a ligação TCP é estabelecida, caso em que é derivado do tamanho máximo da unidade de transmissão (MTU) da camada de ligação de dados das redes às quais o remetente e o receptor estão directamente ligados. Além disso, os remetentes de TCP podem utilizar o caminho de descoberta da MTU para inferir o MTU mínimo ao longo do caminho da rede entre o emissor e o receptor, e utilizá-lo para ajustar dinamicamente o MSS para evitar a fragmentação do IP dentro da rede.
anúncio do MSS também é frequentemente chamado “negociação do MSS”. A rigor, o MSS não é “negociado” entre o originador e o receptor, porque isso implicaria que tanto o originador como o receptor negociariam e acordariam um único e unificado MSS que se aplica a todas as comunicações em ambos os sentidos da ligação. De facto, são permitidos dois valores de MSS completamente independentes para as duas direcções de fluxo de dados numa ligação TCP. Esta situação pode surgir, por exemplo, se um dos dispositivos participantes numa ligação tiver uma quantidade extremamente limitada de memória reservada (talvez até menor do que a MTU do Caminho Descoberto em geral) para processar segmentos TCP de entrada.
Reconhecimento selectivoEditar
Confiar apenas no esquema de reconhecimento cumulativo empregado pelo protocolo TCP original pode levar a ineficiências quando os pacotes são perdidos. Por exemplo, suponha que os bytes com número de sequência de 1.000 a 10.999 são enviados em 10 segmentos TCP diferentes de igual tamanho, e o segundo segmento (números de sequência de 2.000 a 2.999) é perdido durante a transmissão. Num protocolo de reconhecimento puramente cumulativo, o receptor só pode enviar um valor ACK cumulativo de 2.000 (o número de sequência imediatamente após o último número de sequência dos dados recebidos) e não pode dizer que recebeu bytes de 3.000 a 10.999 com sucesso. Assim, o remetente pode então ter de reenviar todos os dados começando pelo número de sequência 2.000.
Para aliviar esta questão, o TCP emprega a opção de reconhecimento selectivo (SACK), definida em 1996 no RFC 2018, que permite ao receptor reconhecer blocos descontínuos de pacotes que foram recebidos correctamente, para além do número de sequência imediatamente a seguir ao último número de sequência do último byte contíguo recebido sucessivamente, como no reconhecimento TCP básico. O aviso de recepção pode especificar um número de blocos SACK, em que cada bloco SACK é transmitido pela borda esquerda do bloco (o primeiro número sequencial do bloco) e pela borda direita do bloco (o número sequencial imediatamente a seguir ao último número sequencial do bloco), sendo um bloco um intervalo contíguo que o receptor recebeu correctamente. No exemplo acima, o receptor enviaria um segmento ACK com um valor acumulado ACK de 2.000 e um cabeçalho de opção SACK com números de sequência 3.000 e 11.000. O remetente retransmitiria assim apenas o segundo segmento com números de sequência de 2.000 a 2.999,
Um remetente TCP pode interpretar uma entrega de segmento fora de ordem como um segmento perdido. Se o fizer, o remetente TCP retransmitirá o segmento anterior ao pacote fora de ordem e diminuirá a sua taxa de entrega de dados para essa ligação. A opção SACK duplicado, uma extensão da opção SACK que foi definida em Maio de 2000 no RFC 2883, resolve este problema. O receptor TCP envia um D-ACK para indicar que não se perderam segmentos, e o emissor TCP pode então restabelecer a taxa de transmissão mais elevada.
A opção SACK não é obrigatória, e só entra em funcionamento se ambas as partes a suportarem. Isto é negociado quando uma ligação é estabelecida. SACK utiliza uma opção de cabeçalho TCP (ver estrutura de segmento TCP para detalhes). A utilização de SACK tornou-se generalizada – todas as pilhas TCP populares suportam-na. O reconhecimento selectivo é também utilizado no Stream Control Transmission Protocol (SCTP).
Window scalingEdit
Para uma utilização mais eficiente de redes de alta largura de banda, pode ser utilizado um tamanho de janela TCP maior. O campo de tamanho de janela TCP controla o fluxo de dados e o seu valor é limitado a entre 2 e 65.535 bytes.
Desde que o campo de tamanho não possa ser expandido, é utilizado um factor de escala. A opção de escala da janela TCP, tal como definida no RFC 1323, é uma opção utilizada para aumentar o tamanho máximo da janela de 65.535 bytes para 1 gigabyte. A escala até tamanhos de janela maiores é uma parte do que é necessário para a sintonia TCP.
A opção de escala de janela é usada apenas durante o aperto de mão TCP de 3 vias. O valor da escala de janela representa o número de bits a deslocar para a esquerda o campo de tamanho de janela de 16 bits. O valor da escala de janela pode ser definido de 0 (sem deslocamento) a 14 para cada direcção independentemente. Ambos os lados devem enviar a opção nos seus segmentos SYN para permitir a escala de janela em qualquer direcção.
alguns routers e firewalls de pacotes reescrevem o factor de escala de janela durante uma transmissão. Isto faz com que os lados de envio e recepção assumam diferentes tamanhos de janela TCP. O resultado é um tráfego não estável que pode ser muito lento. O problema é visível em alguns sítios por trás de um router defeituoso.
TCP timestampsEdit
TCP timestamps, definidos no RFC 1323 em 1992, podem ajudar o TCP a determinar em que ordem os pacotes foram enviados.TCP timestamps não estão normalmente alinhados com o relógio do sistema e começam com algum valor aleatório. Muitos sistemas operacionais irão incrementar o carimbo da hora para cada milissegundo decorrido; no entanto, o RFC apenas declara que os carimbos devem ser proporcionais.
Existem dois campos de carimbo da hora:
um valor de carimbo da hora de 4 bytes do remetente (o meu carimbo da hora) um valor de carimbo da hora de resposta de 4 bytes (o carimbo da hora mais recente recebido de si).
Carimbos de data/hora do TCP são utilizados num algoritmo conhecido como protecção contra números de sequência embrulhados, ou PAWS (ver RFC 1323 para detalhes). PAWS é utilizado quando a janela de recepção atravessa a fronteira do número de sequência envolvente. No caso em que um pacote foi potencialmente retransmitido, responde à pergunta: “Este número de sequência está nos primeiros 4 GB ou no segundo?” E o timestamp é utilizado para quebrar o empate.
Também, o algoritmo de detecção Eifel (RFC 3522) utiliza timestamps TCP para determinar se estão a ocorrer retransmissões porque os pacotes estão perdidos ou simplesmente fora de ordem.
As estatísticas recentes mostram que o nível de adopção do timestamp estagnou, em ~40%, devido ao suporte de queda do servidor Windows desde o Windows Server 2008.
TCP timestamps estão activados por defeito No kernel Linux, e desactivados por defeito no Windows Server 2008, 2012 e 2016.
Dados fora da bandaEditar
É possível interromper ou abortar o fluxo em fila de espera em vez de esperar que o fluxo termine. Isto é feito especificando os dados como urgentes. Isto diz ao programa receptor para o processar imediatamente, juntamente com o resto dos dados urgentes. Quando terminado, o TCP informa a aplicação e volta à fila de espera do fluxo. Um exemplo é quando o TCP é utilizado para uma sessão de login remoto, o utilizador pode enviar uma sequência de teclado que interrompe ou aborta o programa no outro extremo. Estes sinais são mais frequentemente necessários quando um programa na máquina remota não funciona correctamente. Os sinais devem ser enviados sem esperar que o programa termine a sua transferência actual.
TCP dados fora da banda não foi concebido para a Internet moderna. O ponteiro urgente apenas altera o processamento no anfitrião remoto e não acelera qualquer processamento na própria rede. Quando chega ao anfitrião remoto há duas interpretações ligeiramente diferentes do protocolo, o que significa que apenas bytes únicos de dados OOB são fiáveis. Isto pressupõe que é de todo fiável, pois é um dos elementos de protocolo menos utilizados e tende a ser mal implementado.
Forçar a entrega de dadosEdit
Normalmente, o TCP espera 200 ms para enviar um pacote completo de dados (o Algoritmo de Nagle tenta agrupar pequenas mensagens num único pacote). Esta espera cria pequenos, mas potencialmente graves atrasos se repetida constantemente durante uma transferência de ficheiro. Por exemplo, um bloco de envio típico seria 4 KB, um MSS típico é 1460, pelo que 2 pacotes saem numa Ethernet de 10 Mbit/s levando ~1,2 ms cada um seguido de um terceiro carregando o restante 1176 após uma pausa de 197 ms porque o TCP está à espera de um buffer completo.
No caso do telnet, cada toque de tecla do utilizador é ecoado de volta pelo servidor antes de o utilizador o poder ver no ecrã. Este atraso tornar-se-ia muito irritante.
Configurando a opção de socket TCP_NODELAY anula o atraso de envio padrão de 200 ms. Os programas de aplicação utilizam esta opção de socket para forçar a saída a ser enviada depois de escrever um caracter ou linha de caracteres.
O RFC define o PSH push bit como “uma mensagem para a pilha TCP receptora para enviar estes dados imediatamente até à aplicação receptora”. Não há forma de o indicar ou controlar no espaço do utilizador utilizando tomadas Berkeley e é controlado apenas pela pilha de protocolo.