Protocolo TCP-handshake e acenando

 

Conheça o protocolo TCP

O TCP é chamado de "Transmission Control Protocol", que é um protocolo na camada de transporte que controla a transmissão de dados em detalhes. 
Características:

• Orientado a bytes
• Seguro e confiável
• Orientado a conexão

Formato de segmento de protocolo TCP

• Número da porta de origem e número da porta de destino: Aqui é o mesmo que o UDP, cada dado deve saber de qual processo chegar a qual processo.
• Número de série de 32 bits e número de série de confirmação de 32 bits: O número de série e o sinal de confirmação aqui podem ser entendidos como informações que dois processos de comunicação respondem entre si ao enviar e receber dados. Por exemplo, o processo A começa a enviar dados para o processo B a partir do número de sequência 1000 e envia cinco dados. Então, quando B receber a resposta de dados, o número de sequência de confirmação de A aqui deve ser de 1006, se não for 1006, por exemplo, 1003, significa que 1004, 1005 pacote de dados B não foi recebido, portanto, A inicia o mecanismo de retransmissão . Isso garante a confiabilidade dos dados e também é uma das características do TCP. O número de série é o número que o processo envia a mensagem e a confirmação é o número que se espera que o processo de destino retorne. Faça uma comparação para verificar se o pacote de dados chega.
• Comprimento do cabeçalho TCP de 4 bits: O comprimento do cabeçalho TCP de 4 bits aqui pode ser entendido como quatro bits, representando o comprimento, e o valor representado pelos quatro bits multiplicado por quatro é o comprimento do cabeçalho TCP. Pode ser visto na figura que o comprimento mínimo do cabeçalho é 20 bytes, o que significa que o tamanho do cabeçalho TCP de quatro bits aqui é 0101 por padrão. E o comprimento do cabeçalho TCP não pode exceder 15 * 4 = 60 bytes.
• Sinalizador de 6 bits: RG URG: se o ponteiro de emergência é válido ② ACK: se o número de confirmação é válido ③ PSH: solicita que o aplicativo receptor leia imediatamente os dados do buffer TCP ④ RST: a outra parte solicita o restabelecimento da conexão, chamamos o logotipo RST Redefinir segmento ⑤ SYN: solicitação para estabelecer uma conexão, chamamos o identificador SYN que carrega o segmento de sincronização FIN: notifica a outra parte que o terminal local está fechado, chamamos o segmento terminal de transporte FIN
• Tamanho da janela de 16 bits: o tamanho da janela aqui pode ser visto como um sinal, indicando o tamanho do espaço restante no buffer TCP. Desempenhar um papel de controle de fluxo. Se 16 estiver cheio, a janela não poderá receber dados. Os dados que chegarem depois serão perdidos.
• Soma de verificação de 16 bits: a soma de verificação aqui é preenchida pelo remetente, verificação CRC. Se a verificação falhar quando o terminal receptor verificar os dados, considera-se que há um problema com os dados. A soma de verificação aqui não apenas verifica o cabeçalho TCP, mas também a parte dos dados.
• Ponteiro de emergência de 16 bits: identifica qual parte dos dados são de emergência.

  Processo de conexão

  Sabemos que o protocolo TCP é orientado à conexão, o que significa que ele só pode ser usado depois que o cliente e o servidor tiverem se conectado com sucesso. Então, qual é o processo de conexão entre o cliente e o servidor? Em termos simples, são três handshakes e quatro wave waves.A idéia principal é que o cliente precise de três handshakes para conectar-se ao servidor e quatro wave wave para desconectar após a conclusão da comunicação.

• Aperto de mão três

 

O cliente e o servidor fizeram alguns preparativos preliminares antes de apertar as mãos. O servidor primeiro aloca um descritor, depois preenche a estrutura sockaddr_in, vincula o descritor de arquivo criado e a porta do servidor e, em seguida, escuta para fazer com que o descritor de arquivo se torne um descritor de escuta e, finalmente, bloqueia para aceitar a espera do cliente. Conecte. O cliente é relativamente simples, aloca descritores de arquivos, preenche a estrutura sockaddr_in e finalmente se conecta para solicitar a conexão do servidor até que o servidor responda.

Quando o cliente solicita a resposta do servidor por meio da conexão, envia um segmento de mensagem de sincronização, ou seja, uma solicitação SYN, ao servidor e aguarda a resposta do servidor após o envio. Se o servidor receber o segmento de sincronização SYN, ele enviará uma resposta ACK ao cliente, o que significa que recebeu o segmento de sincronização enviado pelo cliente.Ao mesmo tempo, o servidor também enviará um segmento de sincronização SYN para solicitar a solicitação do cliente. Responda. Após receber o segmento de sincronização SYN, o cliente também enviará uma resposta ACK para responder ao servidor. Este processo é o processo de três handshake.

Dessa maneira, a conexão entre o cliente e o servidor é ambos, ambos precisam enviar uma solicitação e ambos precisam responder. Visto na figura, SYN_SENT é o status da conexão solicitada e SYN_RCVD é o status da conexão em espera. Após o êxito do handshake de três vias, o servidor e o cliente entrarão no estado ESTABELECIDO, ou seja, a conexão TCP for bem-sucedida.Neste momento, os dados podem ser transmitidos.

Durante esse processo, se a solicitação SYN do cliente for perdida, o servidor não responderá e o cliente terá um tempo de espera.Quando o tempo de espera chegar e nenhuma resposta ACK for recebida, o cliente iniciará outra solicitação. Se várias solicitações não forem bem-sucedidas, o cliente poderá determinar que a rede está anormal e não solicitará novamente. Da mesma forma, depois que o servidor receber a solicitação SYN do cliente, ele também enviará uma resposta ACK e uma solicitação SYN. Se o cliente não responder ao ACK do servidor, o servidor também será reenviado até que seja julgado que a rede está anormal. Portanto, se algum dos três handshake estiver faltando, a conexão não será bem-sucedida e a comunicação não será possível. Portanto, o handshake de três vias também é uma maneira de garantir a confiabilidade do TCP.

Qual é o objetivo do handshake de três vias?
Resposta: O entendimento pessoal é fácil de entender, é sincronizar o número de série e o número de confirmação das duas partes e trocar as informações de tamanho da janela tcp.
Por que precisamos de dois handshake para concluir a solução, mas três vezes?
Resposta: O handshake de três vias é necessário para impedir que o segmento de solicitação de conexão inválida seja repentinamente transmitido ao servidor, o que causará um erro.

Acene quatro vezes

Depois que a transmissão de dados entre o cliente e o servidor for concluída, o cliente não terá nenhuma solicitação; portanto, neste momento, close é chamado para fechar o descritor de arquivo e o estado FIN_WAIT_1 é inserido, e o segmento de mensagem final FIN é enviado ao servidor. Aguarde a resposta do servidor. Quando o servidor recebe o segmento final FIN aqui, desta vez, o servidor entra no estado CLOSE_WAIT. E responda ao cliente para enviar o ACK. Quando o cliente recebe a resposta ACK do servidor, entra no estado FIN_WAIT_2. Quando o servidor fecha, ele envia um segmento final FIN ao cliente. Digite o estado LAST_ACK no momento. No momento, quando o cliente recebe o FIN enviado pelo servidor, ele responde ao servidor com um ACK e o cliente entra no estado TIME_WAIT.Depois que o TIME_WAIT termina, entra em CLOSED e se desconecta com êxito. Quando o servidor recebe o último ACK do cliente, ele entra no estado FECHADO. Desconectado com sucesso.

Status CLOSE_WAIT e LAST_ACK

Durante o handshake de três vias, o servidor pode enviar SYN e ACK ao mesmo tempo, mas por que o FIN e o ACK enviados pelo servidor são enviados separadamente? ? Este é realmente o caso. 

Primeiro de tudo, o sinal FIN é enviado por causa da chamada de fechamento. Quando o cliente chama close, ele envia um segmento final FIN e entra no estado FIN_WAIT_1. No entanto, o segmento de usuário no servidor é realmente imperceptível para esse segmento.O kernel processará esse segmento por si só, o que significa que o kernel responderá com um ACK. Esse processo não é determinado pelo código do usuário.O FIN do servidor é enviado pelo código do usuário chamando close, portanto o kernel e o servidor não necessariamente processam essas informações ao mesmo tempo. Portanto, FIN e ACK não são necessariamente enviados ao mesmo tempo. Nota: Isso não é necessariamente aqui! ! ! No entanto, o SYN é enviado diretamente pelo kernel durante o handshake de três vias, para que isso possa alcançar uma transmissão síncrona.

Se o código do servidor não for fechado, significa que o segmento final FIN não foi enviado. Portanto, o servidor conectado permanece no estado CLOSE_WAIT por um longo tempo, que impacto isso terá? 
O servidor permanece no estado CLOSE_WAIT por um longo tempo, o que significa que o descritor de arquivo alocado não foi fechado e retornado. Então, se existir um grande número de CLOSE_WAIT, isso causará um vazamento de recursos. Pode não haver descritores de arquivo alocáveis ​​no final, o que tornará alguns clientes incapazes de se conectar, resultando em um impacto inestimável.

TEMPO DE ESPERA

Depois que o cliente envia a resposta ACK pela última vez, ele entra no estado TIME_WAIT e o que o cliente está fazendo nesse estado? 
A resposta é esperar! Depois que o cliente finalmente envia a resposta ACK, ele entra no estado TIME_WAIT, para evitar que a última resposta ACK seja perdida. Aqui, o estado TIME_WAIT aguardará 2MSL.

A unidade MSL aqui é Vida Máxima do Segmento, que significa o tempo máximo de sobrevivência de uma mensagem.O tempo de sobrevivência aqui refere-se a todo o processo desde a ocorrência de uma mensagem até sua recepção.O tempo desse processo é MSL. 
No Linux, você pode usar cat / proc / sys / net / ipv4 / tcp_fin_timeout para visualizar o valor do MSL. 

Depois que o cliente envia a resposta ACK pela última vez, por que esperar 2MSL?

Isso é para garantir que a última mensagem ACK chegue. Como o cliente entra no estado TIME_WAIT após o envio da última resposta ACK, se a mensagem ACK for perdida, o servidor descobrirá que não recebeu uma resposta ACK após aguardar um MSL e, em seguida, reenviará uma mensagem FIN. O tempo dessa resposta ACK mais o tempo do FIN retransmitido é exatamente 2MSL. Se o cliente não receber a mensagem FIN após aguardar 2MSL, significa que o servidor recebeu a mensagem ACK enviada pelo cliente, que desconecta a conexão. 

Aqui você pode ver que, após a saída do cliente, ele entra no estado TIME_WAIT.

Em outras palavras, em TIME_WAIT, a conexão TCP entre o cliente e o servidor ainda existe. 
Em alguns casos, o servidor também pode solicitar a desconexão.O primeiro entra no FIN_WAIT_1; nesse caso, o servidor entra no estado TIME_WAIT. Então, qual é o problema neste estado?

Aqui, encerramos o servidor e descobrimos que o servidor entrou no estado TIME_WAIT. No momento, o servidor foi reiniciado novamente e descobriu que não podia ser iniciado. No momento, a ligação do número da porta falhou devido à falha ao iniciar. Por que isso?

De fato, isso ocorre porque no estado TIME_WAIT, a conexão TCP ainda existe, portanto o número da porta agora ainda está vinculado. Quando o servidor foi iniciado novamente, o número da porta no momento não foi liberado. Portanto, apenas solicita que a ligação tenha falhado.

Se o servidor precisar lidar com um grande número de conexões do cliente, o tempo de sobrevivência de cada conexão é muito curto, mas há um grande número de solicitações do cliente por segundo. Nesse momento, se o servidor fechar ativamente a conexão, um grande número de conexões TIME_WAIT será gerado. Devido à nossa grande demanda, isso resultará em um grande número de conexões TIME_WAIT, resultando em portas de servidor insuficientes para lidar com novas conexões. Como resolver esse tempo?

No momento, a função setsockopt (listenfd, SOL_SOCKET, SO_REUSEADDR e & opt, sizeof (opt) pode ser usada para solucionar esse problema. A função dessa função é permitir a criação de vários descritores de soquete com o mesmo número de porta, mas com endereços IP diferentes. Basta ligar entre bind ().