Explicação detalhada dos recursos do protocolo TCP

Recursos do protocolo TCP

O protocolo TCP tem as características de conexão, transmissão confiável, fluxo de bytes orientado e full-duplex

Formato do segmento do protocolo TCP

Mensagem TCP = cabeçalho TCP (cabeçalho) + carga TCP

• Número da porta de origem/destino: Indica de qual processo os dados vêm e para qual processo eles vão;
• Número de série de 32 bits/número de confirmação de 32 bits: para distinção detalhada de vários conjuntos de dados
• Comprimento do cabeçalho de 4 bits: descreva o comprimento específico do cabeçalho TCP (o comprimento do cabeçalho TCP é variável, o comprimento do cabeçalho UDP não é variável, fixo em 8 bytes)

Nota : A unidade de comprimento do cabeçalho de 4 bits não é um byte, mas 4 bytes, portanto, o comprimento máximo do cabeçalho TCP é 15 * 4 = 60 bytes

• 6 bits reservados: para consideração de expansão futura

Para protocolos de rede, a expansão e a atualização são muito caras. Quando o TCP introduzir algumas novas funções no futuro, esses campos de bits reservados poderão ser usados

• 6 bits de bandeira
  • URG: Se o ponteiro urgente é válido
  • ACK: Se o número de confirmação é válido
  • PSH: Avisa o aplicativo final de recebimento para ler os dados do buffer TCP imediatamente
  • RST: A outra parte solicita o restabelecimento da conexão; chamamos o segmento que carrega o sinalizador RST de segmento de reinicialização
  • SYN: Solicitação para estabelecer uma conexão; chamamos o identificador SYN de segmento de sincronização
  • FIN: notifica a outra parte que a extremidade local está prestes a ser fechada. Chamamos o segmento final carregando a bandeira FIN
• Tamanho da janela de 16 bits:
• Soma de verificação de 16 bits: a mesma função da soma de verificação UDP: ambos verificam se a transmissão de dados está correta, mas não podem garantir a segurança dos dados
• Ponteiro urgente de 16 bits: identifica qual parte dos dados são dados urgentes;
• Opção: A parte antes da opção tem um comprimento fixo (20 bytes) (fórmula: comprimento da opção = comprimento do cabeçalho - 20 bytes)

Se o valor do comprimento do cabeçalho for 5, significa que todo o comprimento do cabeçalho TCP é de 20 bytes (5x4 bytes) (equivalente a nenhuma opção)
Se o valor do comprimento do cabeçalho for 15, significa que todo o comprimento do cabeçalho TCP é de 60 bytes (15x4 bytes) (opção equivalente a 40 bytes)

princípio TCP

Resposta de confirmação (mecanismo de segurança)

Exemplo de imagem:
A envia uma mensagem para B, e B retornará uma mensagem de confirmação (ACK) após recebê-la. Neste momento, após A receber a confirmação, ele sabe que os dados recém-enviados foram recebidos com sucesso por B.

Considere um diagrama de exemplo de situação mais complexa
:
Devido à possibilidade de "último a chegar, primeiro a chegar" na rede, a ordem de recebimento das mensagens pode ser variável e torna-se "Ir para comer?: Não é bom", "Ir para estudar ?: "Ok", que é inconsistente com o significado original.

A fim de resolver o problema do último envio, primeiro a chegar, ambos os dados transmitidos e a mensagem de resposta são numerados.
Imagem de exemplo:
Desta forma, o número de série pode ser usado para distinguir quais dados a mensagem de resposta atual é para

Julgar se uma mensagem é uma mensagem de resposta depende do sinalizador ACK em seu cabeçalho.Se o sinalizador ACK for 1, é uma mensagem de resposta e, se for 0, não é.

De fato, como o TCP é orientado a bytes, o número de sequência do TCP também está de acordo combyteenumerar

Os números de sequência dos bytes TCP são acumulados sequencialmente, e o número de sequência preenchido no cabeçalho de cada datagrama TCP precisa apenas escrever o número de sequência do primeiro byte dos dados TCP.
O TCP conhece o número de série do primeiro byte e, de acordo com o comprimento da mensagem TCP, é fácil saber o número de série de cada byte.

O valor do número de sequência de confirmação é o número de sequência do último byte dos dados recebidos + 1

Por exemplo: o significado do número de sequência de confirmação 1001
:
1. Todos os dados <1001 foram confirmados recebidos.
2. A deve continuar a enviar do número de série 1001 (B pede a A os dados de 1001)

Resumo: capacidade de transmissão confiável do TCP,principalatravésMecanismo de resposta de reconhecimentogarantir, atravésmensagem de resposta（ACK), para que o remetente saiba claramente se a transmissão foi bem-sucedida e introduza ainda onúmero de sérieeConfirme o número de série, para diferenciação detalhada de vários conjuntos de dados

Retransmissão de tempo limite (mecanismo de segurança)

Ao discutir a resposta de confirmação acima, discutimos apenas a situação de transmissão suave e não discutimos a situação de problemas de transmissão (como perda de pacote).
A seguir estão as duas situações de perda de pacote

Caso 1: Perda de Dados

• Depois que o host A envia dados para B, os dados podem não chegar ao host B devido ao congestionamento da rede e outros motivos;
• Se o host A não receber uma confirmação de B dentro de um determinado intervalo de tempo, ele retransmitirá

O segundo caso: perda de ACK

O segundo caso retransmite dados, o que pode fazer com que o host B receba muitos dados duplicados. O TCP irá deduplicá-los e reorganizá-los.

O TCP possui um espaço de armazenamento como um "buffer de recebimento" (um segmento de memória no kernel do sistema operacional do receptor) e cada objeto de soquete TCP possui um buffer de recebimento.
O host B recebe os dados do host A. Na verdade, a placa de rede de B lê os dados e os coloca no buffer de recebimento do soquete correspondente de B. O programa de aplicativo subsequente usa getInputStream e usa read para ler de os dados do buffer de recebimento.
O TCP usa esse buffer de recebimento, de acordo com os dadosnúmero de sérieIdentifique se há duplicação de dados e, em caso afirmativo, descarte os dados subsequentes e reordene os dados recebidos.

resumo: Devido à existência do mecanismo de desduplicação e reordenamento (ambos dependem do número de série do cabeçalho TCP), o remetente irá retransmitir os dados desde que verifique que o ACK não chega a tempo.

A transmissão confiável do TCP é refletida pela resposta de confirmação + retransmissão de tempo limite.
Entre eles, a resposta de confirmação descreve a situação de transmissão suave e
a retransmissão de timeout descreve a situação de problemas de transmissão.

Gerenciamento de Conexão (Mecanismo de Segurança) (Perguntas Frequentes da Entrevista)

Em circunstâncias normais, o TCP precisa passar por três apertos de mão para estabelecer uma conexão e acenar quatro vezes para desconectar

três apertos de mão

Vários estados na fase de estabelecimento da conexão:
1.OUVIR:
Ouvir a solicitação de estabelecimento de conexão da outra parte, indicando que o servidor está pronto, podendo o cliente estabelecer conexão a qualquer momento, o que equivale a ligar o celular, com sinal bom, podendo atender a de outras pessoas chamadas a qualquer momento.

2. SYN_SEND: Pertence à conexão de solicitação, e o segmento enviado neste momento não pode transportar dados .
3. SYN_RECEIVE: Recebeu uma solicitação de estabelecimento de conexão da outra parte.

4.ESTABELECIDO:
A conexão é estabelecida e, em seguida, a comunicação normal pode ser realizada, o que equivale a fazer uma chamada e a outra parte é conectada. Quando o cliente está neste estado, o segmento ACK enviado pode transportar dados,

O chamado aperto de mão de três vias é essencialmente uma interação de "quatro vias".
As duas partes na comunicação iniciam uma solicitação de "estabelecimento de conexão" para a outra parte e, ao mesmo tempo, cada uma responde à outra parte com um ACK. As duas interações no meio podem ser combinadas em uma interação, formando assim um "aperto de mão triplo".

Pergunta 1: Por que as duas interações no meio devem ser mescladas?
Resposta: Está relacionado ao descomissionamento de pacotes, pois custa mais decompor um pacote duas vezes do que decompor um pacote uma vez.

Pergunta dois:Se for um handshake bidirecional, a conexão pode ser estabelecida?
Resposta: Não.
O primeiro handshake: o cliente envia um pacote de rede e o servidor o recebe.
O servidor pode saber que a capacidade de envio do cliente e a capacidade de recebimento do servidor estão normais.
O segundo handshake: o servidor envia um pacote de rede e o cliente o recebe.
O cliente pode saber que os recursos de envio e recebimento do cliente são normais. Os recursos de envio e recebimento do servidor são normais. Mas, neste momento, o servidor não sabe se sua capacidade de envio é normal.
O terceiro handshake: o cliente envia o pacote de rede novamente e o servidor o recebe.
O servidor sabe que os recursos de envio e recebimento do cliente são normais. Os recursos de envio e recebimento do servidor são normais.
Portanto, um handshake triplo é necessário para confirmar se os recursos de recebimento e envio de ambas as partes estão normais.

O significado do aperto de mão de três vias:
1. Deixe que as partes da comunicação estabeleçam seu "reconhecimento" uma da outra.
2. Verifique se as capacidades de envio e recebimento das partes da comunicação são normais.
3. Durante o processo de handshake, as duas partes precisam negociar alguns parâmetros importantes para concluir sincronização de dados.
fase de estabelecimento da conexão

acenou quatro vezes

O handshake de quatro vias é muito semelhante ao handshake de três vias: ambas as partes na comunicação iniciam uma solicitação de desconexão uma para a outra e, em seguida, respondem uma à outra.

Vários estados na fase de estabelecimento da conexão :
1. FIN_WAIT_1: Quando o cliente chama ativamente close, ele envia o segmento final (FIN) para o servidor e entra FIN_WAIT_1 ao mesmo tempo;

2.CLOSE_WAIT: (aparece empassivaA parte que iniciou a desconexão)
Quando o cliente fecha ativamente a conexão (chamando close), o servidor receberá o segmento final (FIN) e o servidor retornará o segmento de confirmação (ACK) e entrará em CLOSE_WAIT;3. FIN_WAIT_2: O cliente
recebe Quando o servidor confirmar (ACK) o segmento final, digite FIN_WAIT_2 e
comece a aguardar o segmento final (FIN) do servidor;
4. LAST_ACK: Após inserir CLOSE_WAIT, significa que o servidor está pronto para fechar a conexão (o dados anteriores precisam ser processados); Quando o servidor realmente chamar close para fechar a conexão, ele enviará um FIN para o cliente. Nesse momento, o servidor entra no estado LAST_ACK e aguarda a chegada do último ACK (esse ACK é a confirmação do cliente de que recebeu o FIN)

5. TIME_WAIT: (Aparece na parte que inicia a desconexão)
Supondo que o cliente desconecta ativamente, quando o cliente entra no estado TIME_WAIT, equivale a acenar quatro vezes e o cliente recebe a mensagem do servidor Terminar o segmento (FIN ), insira TIME_WAIT e emita LAST_ACK;

[TIME_WAIT -> CLOSED] O cliente aguardará um tempo de 2MSL (duração máxima do pacote) antes de entrar no estado FECHADO.

6. O servidor recebe o ACK para FIN, fecha completamente a conexão e entra no estado FECHADO

O significado de TIME_WAIT: O handshake de quatro vias é igual ao handshake de três vias, e também haverá perda de pacotes. Quando o servidor não receber o último ACK, ele realizará uma operação de retransmissão. Portanto, o estado TIME_WAIT é usado para um determinado período de tempo para lidar com a perda do último pacote ACK, neste caso, após receber o FIN retransmitido pelo servidor, o cliente pode responder com ACK pelo FIN retransmitido.

Questão 1: Por que as duas interações j no meio do aperto de mão de três vias podem ser mescladas, mas não os quatro apertos de mão?
Responder:

• O processo de interação de três vias do handshake de três vias é concluído no kernel puro.Após o kernel do sistema do servidor receber o SYN, ele enviará imediatamente o ACK e o SYN ao mesmo tempo, para que possam ser mesclados.
• O início do FIN na onda de quatro ondas não é controlado pelo kernel, mas o FIN é acionado pelo aplicativo chamando o método close do soquete (ou o processo sai), e o ACK é controlado pelo kernel. FIN enviado pelo remetente é recebido Depois disso, o ACK será retornado imediatamente, e geralmente há uma diferença de horário entre os dois, portanto, eles não podem ser mesclados.

Pergunta 2: Pense bem, por que o tempo de TIME_WAIT é 2MSL?
MSL é o tempo de vida máximo de uma mensagem TCP, portanto, se TIME_WAIT persistir por 2MSL,
pode garantir que os segmentos de mensagem não recebidos ou atrasados ​​em ambas as direções de transmissão tenham desaparecido (caso contrário, o servidor será reiniciado imediatamente e poderá receber mensagens dos dados atrasados ​​superiores de um processo, mas é provável que esses dados estejam errados);
ao mesmo tempo, também é teoricamente garantido que a última mensagem chegue de forma confiável (supondo que o último ACK seja perdido, o servidor reenviará um FIN. Nesse momento, embora o processo do cliente tenha desaparecido, mas a conexão TCP ainda esteja lá e o LAST_ACK ainda possa ser reenviado);

Pergunta 3: Há um grande número de estados CLOSE_WAIT no servidor, qual é o motivo?
Resposta: O servidor não fechou o soquete corretamente, fazendo com que as quatro ondas de mão não fossem concluídas corretamente. Isso é um bug. Basta adicionar o fechamento correspondente para resolver o problema

Janela deslizante (mecanismo de eficiência)

A estratégia de resposta de confirmação discutida acima requer uma resposta de confirmação ACK para cada segmento de dados enviado. Depois de receber o ACK, o próximo segmento de dados é enviado. Fazer isso piora o desempenho.

Neste momento, o mecanismo de janela deslizante é usado para melhorar o desempenho .
Operações específicas : enviar em lotes, aguardar em lotes e usar um tempo de espera para aguardar vários ACKs de um conjunto de dados, o que reduz essencialmente o tempo consumido pela espera de ACKs para respostas de confirmação.

tamanho da janela: O valor máximo que pode continuar a enviar dados sem esperar por uma resposta de confirmação, o tamanho da janela na figura acima é 4000;

• Ao enviar os quatro primeiros segmentos, você não precisa esperar nenhum ACK, basta enviar diretamente;
• Após receber o primeiro ACK, a janela deslizante retrocede e continua enviando os dados do quinto segmento, e assim sucessivamente;

O seguinte é uma discussão dos dois casos de perda de pacotes
Situação 1: O pacote de dados chegou, mas o ACK foi perdido.

Nesse caso, não importa se parte do ACK foi perdida, pois pode ser confirmada pelo ACK subseqüente;

Caso 2: O pacote de dados é perdido diretamente.

• Quando um segmento de uma mensagem é perdido, o remetente sempre receberá ACK como 1001, que serve para lembrar ao remetente que os dados de 1001-2000 não foram recebidos e os dados correspondentes de 1001-2000 devem ser reenviados.
• Neste momento, depois que a extremidade receptora recebe 1001, o ACK retornado novamente é 7001 (porque 2001 - 7000). A extremidade receptora realmente o recebeu antes e o colocou no buffer de recebimento.

O mecanismo acima também é chamado de "mecanismo de retransmissão rápida".

Controle de Fluxo (Mecanismo de Segurança)

O controle de fluxo é um mecanismo para intervir no tamanho da janela de envio

Pergunta 1: Por que controlar o tamanho da janela?

• A janela é muito grande e consome muitos recursos do sistema
• . A janela é muito grande e a confiabilidade não pode ser garantida sem esperar por uma confirmação.
• .Considerar as capacidades de processamento do receptor

Questão 2: No formato de segmento do protocolo TCP, o tamanho da janela de 16 bits significa que o tamanho máximo da janela é 64kb?
Resposta: Não, o TCP introduz o fator de expansão da janela M na parte opcional, de modo que o tamanho real da janela seja o valor do campo da janela deslocado para a esquerda por M.

O trabalho do controle de fluxo é coordenar a taxa de envio do remetente de acordo com a capacidade de processamento do destinatário (verificando o tamanho restante do buffer de aceitação do destinatário).

A extremidade de envio envia dados para a extremidade de recebimento e a extremidade de recebimento verifica o tamanho restante de seu buffer de recebimento e retorna esse valor para a extremidade de envio por meio da mensagem ACK, e a extremidade de envio confirmará o tamanho da janela para a próxima rodada de enviando de acordo com este número.
Quando o tamanho da janela for 0, o remetente suspenderá o envio. Durante o processo de espera de suspensão do envio, o destinatário enviará periodicamente uma mensagem de detecção de janela. Essa mensagem não contém dados comerciais específicos, apenas para acionar o reconhecimento e consultar o tamanho da janela .

Nota: O tamanho da janela é o conceito do "remetente", que é informado ao remetente através do campo tamanho da janela no cabeçalho ACK do receptor.

Controle de congestionamento (mecanismo de segurança)

O controle de fluxo considera a capacidade de processamento do receptor, e o controle de congestionamento descrito a seguir é considerar a capacidade de processamento dos nós intermediários durante o processo de transmissão. Os dois determinam em conjunto o tamanho da janela do emissor (o menor valor dos dois)

O controle de congestionamento, em essência, é encontrar gradualmente um tamanho de janela apropriado por meio de experimentos.

• O tamanho da janela é de 1 unidade na rodada 0, e os dados são enviados em uma velocidade muito lenta.Se a transmissão for suave, o tamanho da janela será dobrado.
• No estágio inicial, como a janela inicial é relativamente pequena, o tamanho da janela dobrará (crescimento exponencial) sem perda de pacotes a cada rodada.
• Quando a taxa de crescimento atinge o limite, o crescimento exponencial neste momento é transformado em crescimento linear (desde que não haja perda de pacotes).
• Quando ocorre perda de pacotes durante a transmissão, significa que a taxa de envio está próxima do limite da rede neste momento, então reduza o tamanho da janela para um valor pequeno (repita o processo acima de crescimento exponencial e crescimento linear) A janela de congestionamento é não é um valor fixo
  , mas está sempre mudando dinamicamente.

O TCP é um protocolo muito complexo, não apenas os recursos mencionados acima! ! ! Se você quiser saber mais sobre os recursos do TCP, leia o documento padrão RFC.