[Rede de Computadores] Explicação detalhada do TCP

Prefácio

Aprendemos sobre o protocolo da camada de transporte Udp anteriormente. Hoje aprenderemos sobre o Tcp. O Tcp é mais complexo que o Udp, mas é confiável. Muitos cenários exigem essa confiabilidade.

Formato de segmento de protocolo TCP

Apenas do ponto de vista do formato, o TCP é muito mais complexo que o Udp, então como os cabeçalhos e as cargas do TCP devem ser separados?

Primeiro, os primeiros 20 bytes do cabeçalho devem ser corrigidos. Primeiro extraímos os primeiros 20 bytes e encontramos o comprimento do cabeçalho de 4 dígitos. Em
seguida, o comprimento do cabeçalho * 4 -20 para ver se há opções.
Finalmente, depois de ler o bytes das opções, o resto são dados.

Confiabilidade TCP

Um grande número de perdas de pacotes, fora de ordem, duplicação, falha de verificação, transmissão lenta e falhas de rede são manifestações de falta de confiabilidade. É precisamente porque a distância de transmissão se torna maior que causa tantos problemas de confiabilidade. Para resolvê-los problemas. TCP introduziu o sistema de resposta .

Se C enviar um dado para S, C considerará que seus dados foram enviados para S somente quando S responder a C. Se a resposta não for recebida após esperar por um período de tempo, C considerará que os dados que enviou foi enviado para S. Se perdido, uma retransmissão de tempo limite será acionada.

Para melhorar a eficiência do envio, várias mensagens TCP são transmitidas simultaneamente, o que faz com que os dados que chegam ao extremo oposto fiquem fora de ordem. Fora de ordem é exatamente o que queremos fazer com confiabilidade, então as mensagens TCP são destinado a ser numerado .

fluxo de bytes orientado

A camada de aplicação copia os dados para o buffer de envio TCP e divide todo o buffer de envio em unidades uint8. Portanto, o buffer de envio é naturalmente numerado (subscrito do array).

mecanismo de resposta

Sabemos acima que o TCP requer uma resposta e um número. A resposta é na verdade uma mensagem TCP carregando um campo ACK, e o número de sequência de 32 bits é o que chamamos de número. O peer precisa nos responder com um ACK para isso. número sequencial.

Por exemplo: A extremidade C envia uma mensagem de 32 bits com um número de sequência 10 e a extremidade S retornará uma mensagem de confirmação de 32 bits com um número de sequência 11.

Número de sequência de envio: o número da mensagem atual.
Número de sequência de confirmação: Indica que todas as mensagens anteriores foram recebidas e devem ser enviadas a partir deste número de sequência.

Como a mensagem TCP possui um mecanismo de resposta piggyback, ou seja, quando S envia um ACK, ela também possui informações que deseja enviar para C. Portanto, deve ser projetada como dois campos independentes e não pode ser multiplexada entre si.

Retransmissão de tempo limite

Duas possibilidades de perda de dados:
1. Os dados são realmente perdidos no meio do caminho
2. Os dados não são perdidos, mas o ACK é perdido no meio do caminho.

No primeiro caso, devemos retransmitir os dados, o que exige que o TCP seja capaz de salvar temporariamente os dados para suportar a retransmissão.
No segundo caso, você pode consultar outros ACKs, pois se apenas o ACK for perdido, os números de sequência de confirmação dos outros ACKs não serão alterados.

Tempo de espera: Cada plataforma é diferente. No Linux, é baseado em 500ms e ajustado dinamicamente de forma n*500.

controle de fluxo

O TCP possui um buffer de recebimento e um buffer de envio, que também são full-duplex, mas desde que o buffer tenha um tamanho, imagine este cenário:

C envia a mensagem para S, mas o buffer de recepção de S não pode acomodá-la. Nesse caso, S só pode descartar os pacotes descartados sem responder. Depois de um tempo, C retransmitirá os pacotes.

Se você olhar mais de perto, verá que isso é muito ineficiente. A mensagem viaja até o host oposto, mas é descartada porque o extremo oposto não pode recebê-la. Para resolver esse problema, as mensagens TCP possuem um campo chamado de tamanho da janela de 16 bits . , este campo é preenchido com o tamanho do seu próprio buffer de recebimento. Quando a outra parte receber a mensagem, ela verá esse tamanho e ajustará (aumentará ou diminuirá) a velocidade e o tamanho dos dados enviados com base neste tamanho.

Detecção de janela:
ambas as extremidades enviarão regularmente mensagens TCP sem dados para a outra parte para perguntar sobre as capacidades de recepção da outra parte e ajustar a velocidade e o tamanho dos dados enviados (este processo é bidirecional)

Janela deslizante (importante)

Para o protocolo TCP, a confiabilidade é a principal questão de pesquisa, mas a eficiência também é uma questão que o TCP precisa considerar.

O remetente só poderá enviar simultaneamente se a outra parte puder recebê-lo.

1. Situação geral

Um buffer de envio é dividido em três áreas por uma janela deslizante.

A área à esquerda: dados que foram enviados e confirmados - podem ser sobrescritos.
A área do meio: podem ser enviados diretamente (limite de tamanho), mas nenhuma resposta foi recebida.
A área à direita: a área de dados que ainda não foi enviado.

O tamanho da janela deslizante deve estar relacionado à capacidade de recepção da outra parte.

1.5. Como entender as janelas deslizantes

2. Circunstâncias especiais

1. A janela deslizante só pode se mover para a direita, porque os dados à esquerda não têm significado.

2. A essência de aumentar ou diminuir é ajustar a extremidade do vinho, que depende do tamanho da janela da outra parte. A janela deslizante está flutuando.

3. Torna-se 0, indicando que a outra parte não pode receber dados (realizar detecção e notificação de janela)

4. As respostas também devem chegar em ordem.
Número da resposta: winstart = seq;
tamanho da janela de resposta: winend = winstart + win;

5. Problema de perda

a. O primeiro foi perdido.
Retransmitir e reeditar.

b. O do meio foi perdido.
Deslize para a direita e ele se tornará o primeiro.

c. Se o último for perdido,
ele também se tornará o mais à esquerda.

Retransmissão rápida: (retransmissão em alta velocidade)
Quando uma mensagem é perdida e três confirmações idênticas são recebidas consecutivamente, ela será retransmitida imediatamente.

O limite inferior de retransmissão: retransmissão de tempo limite
O limite superior de retransmissão: retransmissão rápida

controle de congestão

Se houver um problema com a rede, o TCP também implementa o controle de políticas.

A perda de pacotes também é a mesma, e há uma diferença entre menos perdas e mais perdas.Se a perda de pacotes continuar, é um problema de rede.

Quando um grande número de pacotes é perdido, a estratégia de envio do remetente é esperar e enviar novamente! !

Se a rede estiver paralisada, todos os hosts retransmitirão novamente, o que tornará a rede paralisada mais difícil de ser recuperada.Portanto, a estratégia que adotamos é reduzir a quantidade de transmissão caso seja encontrado congestionamento na rede. Em geral, os dois requisitos a seguir devem ser atendidos:

1. Certifique-se de que o congestionamento da rede não aumente.
2. Quando a recuperação da rede melhorar, restaure as comunicações da rede o mais rápido possível.

TCP introduz um mecanismo de início lento :

Quando ocorre congestionamento da rede, o remetente deve basicamente saber a gravidade do congestionamento da rede e detectar o status da rede.

Janela de congestionamento
Necessidade de medir as condições da rede - Janela de congestionamento

O status da rede muda de tempos em tempos, para medir o status de saúde da rede, ou seja, o tamanho da janela de congestionamento deve mudar.

因此发送方的滑动窗口 = min(16位窗口大小，网络的拥塞窗口)

A taxa de crescimento da janela de congestionamento é exponencial: um início lento significa lento na fase inicial e muito rápido na fase posterior.

1. Existe um limite para início lento.
2. Quando a janela de congestionamento excede esse limite, ela não cresce mais exponencialmente, mas linearmente.
3. Cada vez que atinge o tempo limite e é retransmitido, o limite de início lento (ssthresh) se tornará metade do valor original. Ao mesmo tempo, a janela de congestionamento é definida como 1 (multiplicativamente reduzida)

resposta atrasada

Uma resposta ACK é retornada imediatamente e o tamanho da janela retornado pode ser menor.

Ao anunciar um ganho maior para a outra parte, a outra parte pode melhorar a eficiência da transmissão com maior probabilidade. Dê à camada superior mais tempo para ler, leia o mais rápido possível durante esse período e leia mais.

resposta nas costas

ACK pega carona.

Bit de bandeira

• A natureza das bandeiras

Um bit binário para identificar diferentes tipos de mensagens

• Por que existe uma bandeira?

Bandeiras diferentes fornecem serviços diferentes.

Posição específica da bandeira

ACK: Mensagem de resposta de confirmação, que pode transportar dados (resposta piggyback)
SYN: Mensagem de solicitação de conexão (handshake de três vias)
FIN: Mensagem de desconexão de conexão (quatro ondas)
PSH: Solicita à camada de aplicação da outra parte para recuperar os dados do buffer assim que possível Ir ( 多路转接)
RST: Diga à outra parte para reconectar (a conexão foi redefinida)
URG: Chegada em ordem, mas queremos entrar na fila? (Dados Urgentes) Ponteiro urgente de 16 bits, deslocamento de dados urgentes na carga útil. Os dados urgentes (dados fora de banda) têm apenas um byte. (Baixar caso de cancelamento) Opção MSG_OOB de recvfrom.

três apertos de mão

• 1. O que é conexão?
  Deve haver várias conexões estabelecidas em um sistema operacional e o sistema operacional deve gerenciar essas conexões.
  Manter conexões é caro e deve consumir recursos de CPU e memória.

• 2. Por que três vezes?
  Durante o processo de handshake de três vias, os sistemas operacionais de ambas as partes completam o TCP de forma independente
  . conectar: ​​acionar a conexão e aguardar a conclusão.
  aceitar: aguardar a conclusão do estabelecimento e obter a conexão.

  Para o cliente, desde que o último ACK seja enviado, o link é considerado estabelecido.
  Para o servidor, somente após receber o último ACK, o servidor consome recursos para construir.

  Portanto, a essência do handshake triplo é que o servidor recebeu o último ACK. Se nenhum ACK for recebido, os dois estabelecem inconsistências cognitivas.Neste momento, o cliente envia uma mensagem ao servidor, e o servidor responderá com um RST para reiniciar a conexão.

  • Se houver dois handshakes, enquanto o SYN+ACK for emitido, os recursos serão desperdiçados. Facilmente SYN洪水攻击. Observe que o próprio TCP não considera a solução de problemas de segurança, mas o TCP não pode ter falhas de segurança! Portanto, as inundações do SYN precisam ser evitadas.
  • Se houver mais de 3 handshakes, o último problema de ACK ainda não pode ser resolvido. Se for um handshake de número par, o servidor arcará com o risco do último ACK e o cliente arcará com o risco dos handshakes de números ímpares . O lado do servidor armazena uma grande quantidade de dados e exceções são inevitáveis, mas dois ou mesmo apertos de mão são inadequados.
  • Os benefícios do handshake de três vias:
    1. Não há lacunas óbvias. Se ocorrer uma exceção, o custo é transferido para o cliente.
    2. Verifique se o canal de comunicação entre ambas as partes é tranquilo. É o custo mínimo para verificar suave (full duplex) (receber e enviar)

• 3. Mudança de status
  SYN_SENT:
  SYN_RCVD é enviado de forma síncrona:
  ESTABLiSH é recebido de forma síncrona: estabelecimento concluído

acenar quatro vezes

Acenar quatro vezes é o custo mínimo para ambas as partes estabelecerem um consenso sobre conexão e desconexão! Ambas as partes devem concordar (nenhuma delas envia mensagem)!

Mudanças de status:

Quando o cliente sai e o servidor não chama close, o servidor entra no estado CLOSE_WAIT e o servidor entra no estado FIN_WAIT2.

Depois de um tempo, o FIN_WAIT2 do cliente desaparece e o servidor ainda está no estado CLOSE_WAIT. Portanto, para o lado do servidor, desligue o descritor de arquivo!

Após chamar close, o servidor entra imediatamente no estado LAST_ACK e envia FIN para o peer. Se o peer tiver sido fechado, o servidor também será desconectado após várias retransmissões.

A parte que se desconecta ativamente precisa entrar no estado TIME_WAIT. Se quiser reiniciar imediatamente, falhará. O motivo é que a conexão subjacente ainda está no estado TIME_WAIT.

• 1. Por que inserir TIME_WAIT

  O protocolo TCP estipula que a parte que se desconecta ativamente deve esperar dois tempos de MSL (o tempo máximo que uma mensagem pode existir na rede).

  • 1. Deixe os pacotes da rede se dissiparem o mais rápido possível para evitar qualquer impacto em novas conexões.
  • 2. Certifique-se de que o último ACK seja recebido pela outra parte. Caso a outra parte não receba o último ACK, enviará outro FIN.

• 2. Se o servidor não quiser esperar

  //设置地址可以复用，令服务器立马重启
  setsockopt(int sockfd,int level,int optname,const void* optval,socklen_t optlen)
  参数：
  sockfd：套接字
  level：当前在哪一层（SOL_SOCKET）
  optname：（SO_REUSEADDR | SO_REUSEPORT）
  optval:1
  optlen:len
  

Problema com saco pegajoso

O TCP não possui o campo de comprimento da mensagem no UDP. Não sabemos a fronteira entre os dois dados. Esse problema é o problema de fixação de pacotes.

Solução: Esclareça o limite entre os dois pacotes (a ser preenchido pela camada superior).

Exceções TCP

Encerramento do processo/reinicialização da máquina: o encerramento do processo liberará o descritor de arquivo e ainda enviará FIN, assim como o desligamento normal (o sistema operacional recicla todos os recursos relacionados)

A máquina está desligada/o cabo de rede está desconectado: O par pensa que a conexão ainda está lá. Quando a extremidade receptora executa uma operação de gravação e descobre que a conexão não está mais lá, ela será reiniciada. O servidor envia um sinal de keep-alive temporizador, e o final do envio também pode ser redefinido.

O segundo parâmetro de escuta

Defina o segundo parâmetro como 1 para conectar-se ao servidor, após um determinado nível insira SYN_RECV, ou seja, só pode haver dois links estabelecidos.

O protocolo TCP precisa manter uma fila de conexão completa na camada inferior. O comprimento máximo é: segundo parâmetro + 1

Não haverá conexões com a fila semiconectada e o tempo será muito descontínuo.

A fila de conexão completa não pode ser muito longa nem estar vazia. O comprimento de uma conexão completa não é o comprimento processado pelo servidor, mas um local de "fila".

1. Ele consumirá muitos recursos do sistema operacional. É melhor usá-lo no servidor.
2. A espera final é muito longa.