Redes de Computadores --- TCP e UDP

1. UDP

1.1 Formato do cabeçalho UDP

• número da porta de origem : número da porta do remetente
• Número da porta de destino : número da porta do receptor
• Comprimento UDP : a soma do comprimento de todo o cabeçalho UDP e o comprimento dos dados
• Checksum : Detecta se há algum erro no pacote de dados UDP durante a transmissão e descarta o erro.

1.2 Recursos do UDP

1. Sem conexão
   : Saber o IP e o número da porta da outra parte pode transmitir sem estabelecer uma conexão.

2. Transmissão não confiável
   Não há mecanismo de segurança, após o remetente enviar os dados, mesmo que a rede esteja congestionada ou haja perda de pacotes durante a transmissão, o UDP não será responsável pela retransmissão.

3. Orientado a datagrama
   : O comprimento da mensagem que a camada de aplicação entrega ao UDP, o UDP a envia como está, não divide nem mescla.

4. 
   UDP full- duplexsocket pode ler e escrever, que é full-duplex

5. No protocolo UDP de tamanho limitado
   , o cabeçalho tem um comprimento máximo de 16 bits, o que equivale a um máximo de 64 K bits de dados transmitidos por um UDP (incluindo o cabeçalho UDP)

2. TCP

2.1 formato de cabeçalho TCP

• número da porta de origem : número da porta do remetente

• Número da porta de destino : número da porta do receptor

• Número de série : A localização dos dados enviados. Cada vez que os dados são enviados, o tamanho do número de bytes dos dados é acumulado.

• Acknowledgement Reply Number : O número de sequência dos dados que devem ser recebidos em seguida.

• Comprimento do cabeçalho : Indica quantos bits de 32 bits (quantos 4 bytes existem) no cabeçalho TCP; portanto, o comprimento máximo do cabeçalho TCP é 15 * 4 = 60

• Reservado : Para expansão futura, seu comprimento é de 4 bits. Geralmente definido como 0. Mesmo que o pacote recebido não seja 0 neste campo, ele não será descartado

• Bit de controle : Cada bit é CWR, ECE, URG, ACK, PSH, RST, SYN, FIN da esquerda para a direita.
  
  ECE: Quando é 1, significa que a rede está congestionada
  . URG: Quando é 1, significa que o pacote precisa de processamento urgente. Data,
  ACK: Quando for 1, o campo da resposta de confirmação torna-se válido
  PSH: Quando for 1, os dados recebidos precisam ser enviados imediatamente para o protocolo de aplicação superior, quando for 0, ele não precisa ser enviado imediatamente, mas armazenado em cache
  RST primeiro: Quando for 1, significa que a conexão com o TCP deve ser desconectada à força quando houver uma anormalidade na conexão. Quando o segmento de reset
  SYN: for 1, significa que uma conexão é desejada. O sinalizador SYN é chamado de segmento de sincronização
  FIN: quando é 1, significa que não Haverá mais dados para enviar e espero desconectar. O segmento marcado com FIN é o fim do segmento

• Tamanho da janela : Indica o tamanho dos dados (bytes de 8 bits) que podem ser recebidos da posição apontada pelo número de confirmação no mesmo cabeçalho TCP.

• Checksum: : O objetivo é detectar quaisquer alterações nos cabeçalhos e dados TCP entre o remetente e o destinatário. Se o receptor detecta um erro de checksum, o segmento TCP é simplesmente descartado.

• Ponteiro urgente : válido quando o bit de controle URG é 1

2.2 Recursos do TCP

1. conectado
2. transmissão confiável
3. fluxo de bytes
4. duplex completo

2.3 Número de série e resposta de confirmação (melhorando a confiabilidade)

No TCP, quando o remetente envia um dado para o host, o destinatário retorna uma notificação de mensagem recebida, chamada de confirmação (ACK).
Por exemplo, quando Xiaoming conversa com Xiaoqiang,

Xiaoming-> Xiaoqiang: Vai jogar amanhã?
Xiaoming<- Xiaoqiang: Entendi!
Xiaoming<- Xiaoqiang: Amanhã não tem hora.
Xiaoming-> Xiaoqiang: Recebido!

2.4 Mecanismo de tempo limite de retransmissão (melhorando a confiabilidade)

Na situação agora, a perda de pacote pode ocorrer: ① O remetente perde pacotes. ② O
tempo limite de retransmissão de perda de pacote de resposta de confirmação refere-se ao intervalo de tempo específico para aguardar a chegada da resposta de confirmação antes de retransmitir os dados. Os dados serão reenviados após receber a confirmação.

No entanto, os dados não serão retransmitidos indefinidamente. Após um certo número de vezes, se ainda não houver resposta de confirmação, será julgado que ocorreu uma anormalidade na rede ou no host peer e a conexão será fechada à força.

Por exemplo: A probabilidade de perda de pacotes é 10%
A perda do primeiro pacote 10%
A perda do segundo pacote 10% * 10% = 1%
A perda do terceiro pacote 10% * 10% * 10% = 0,1%
Muitos tempos de perda de pacotes, a probabilidade é muito pequena, é outro problema.

2.5 Gerenciamento de conexão:

As conexões TCP podem ser gerenciadas usando os campos de controle do cabeçalho TCP.O estabelecimento e desconexão de uma conexão requer que pelo menos 7 pacotes sejam enviados e recebidos para completar o processo normal (três handshakes, quatro ondas).

Aperto de mão de três vias TCP

TCP acenou quatro vezes

2.6 Janela deslizante (melhorando a eficiência)

A fim de resolver (TCP envia em uma unidade de segmento. Tal desempenho de comunicação é bastante reduzido.) Este problema, uma janela é introduzida.

• O tamanho da janela refere-se ao valor máximo que pode continuar a enviar dados sem esperar por uma confirmação.
• O tamanho da janela acima é de 4 segmentos
• Para manter essa janela deslizante, o kernel do sistema operacional precisa abrir um buffer de envio para registrar quais dados estão
  sem resposta no momento; somente os dados que foram reconhecidos podem ser excluídos do buffer;
  

Caso 1: Pacote chega, ACK é perdido

Nesse caso, os dados já atingiram o ponto final e não há necessidade de retransmiti-los. Conforme mostrado na figura

Pode-se ver aqui que mesmo que o ACK de 1001 seja perdido, o ACK de 2001 seja recebido e o ACK de 3001 seja recebido posteriormente, ele saberá que os dados foram recebidos e não será afetado.

Caso 2: Pacote Perdido

Se o host emissor receber a mesma confirmação três vezes seguidas , ele retransmitirá os dados correspondentes. Esse mecanismo é mais eficiente que o gerenciamento de tempo limite e é chamado de controle de retransmissão de alta velocidade

2.7 Controle de fluxo (melhorando a confiabilidade)

A velocidade na qual o receptor pode processar os dados é limitada. Se o remetente enviar muito rápido, o buffer do destinatário está cheio e, se o
remetente continuar enviando, causará perda de pacotes, o que causará uma série de reações em cadeia, como perda e retransmissão de pacotes.
Para evitar esse fenômeno, o TCP fornece um mecanismo que permite ao emissor controlar a quantidade de dados enviados de acordo com a capacidade real de recepção do receptor. Isso é controle de fluxo.

2.8 Controle de congestionamento (melhorando a confiabilidade)

Quando a rede está congestionada, se uma grande quantidade de dados for enviada de repente, é muito provável que toda a rede fique paralisada.
Para evitar esse problema, o TCP controla a quantidade de dados enviados por um valor derivado de um algoritmo chamado slow start no início da comunicação.

Quando a rede estiver tranquila, aumente gradualmente a taxa de envio.
Quando houver perda de pacotes na rede, reduza imediatamente a taxa de envio.

• Um processo conceitual é introduzido aqui como a janela de congestionamento
• Ao iniciar o envio, defina o tamanho da janela de congestionamento como 1;
• Cada vez que uma resposta ACK é recebida, a janela de congestionamento é incrementada em 1;
• Toda vez que um pacote é enviado, a janela de congestionamento é comparada com o tamanho da janela informada pelo host receptor, e o valor menor é considerado como a janela real enviada.真实窗口大小 = min(流量窗口,拥塞窗口)

• Quando o TCP inicia, o limite de início lento é igual ao valor máximo da janela;
• Em cada retransmissão de tempo limite, o limite de início lento se tornará metade do valor original e a janela de congestionamento será redefinida para 1;

2.9 Resposta atrasada (melhorando a eficiência)

Se o host que recebe os dados responde com uma confirmação imediatamente todas as vezes, ele pode retornar uma janela menor, porque o buffer está cheio logo após o recebimento dos dados.

Quando um receptor recebe a notificação desta pequena janela, ele enviará dados com ela como limite superior, reduzindo assim a utilização da rede
, por isso é introduzido um método, ou seja, não retorna uma resposta de confirmação imediatamente após o recebimento dos dados. , mas um mecanismo que atrasa por um período de tempo.

Na transferência de arquivos TCP, a maioria deles retorna uma confirmação a cada dois segmentos de dados.

2.10 Pegando carona (melhorando a eficiência)

Com base na resposta atrasada, descobrimos que, em muitos casos, o servidor cliente também é "um envio e um recebimento" na camada de aplicação. Isso significa que o cliente disse "Como você está" para o servidor, e o servidor também retornará um "Tudo bem, obrigado" para o cliente;
então ACK pode pegar uma carona neste momento, juntamente com a resposta do servidor "Tudo bem, obrigado" de volta ao cliente

Na comunicação, os dados de confirmação e recebimento do TCP podem ser enviados em um único pacote ,

devido a esta situação, quatro ondas de mãos podem se tornar três vezes.

2.11 Orientado para fluxo de bytes (problema de pacote fixo)

A solução para o problema do pacote pegajoso:

1. Defina o "terminador"/"delimitador" para os dados da camada do aplicativo

2. Defina o "comprimento" para os dados da camada do aplicativo

2.12 Situação anormal (mecanismo de batimento cardíaco)

1. Rescisão do processo

A finalização do processo libera o descritor de arquivo e o FIN ainda pode ser enviado. Não é diferente de um desligamento normal

2. Reinício da máquina

É o mesmo que o caso em que o processo é encerrado. (Talvez quatro ondas não sejam concluídas)

3. A máquina está desligada / o cabo de rede está desconectado

1. É o receptor que perde energia.
   Neste momento, o remetente ainda está enviando dados. Neste momento, obviamente, acionará uma retransmissão de timeout. Após várias retransmissões, ele tentará redefinir a conexão
   e, em seguida, o remetente desistirá a conexão e atribuir a conexão ao correspondente de recursos recuperados

2. É o remetente que perde a energia.
   Neste momento, a outra parte está tentando receber dados, mas não pode receber nenhum dado. Neste momento, o mecanismo "heartbeat packet" é adotado.
   De vez em quando, envie um pacote PING para a outra parte e esperar que a outra parte devolva um pacote PONG~
   Se o pacote PING foi enviado, não é PONG há muito tempo e não pode ser repetido várias vezes, considera-se que a outra parte festa desligou.

3. Perguntas da entrevista

1. Como obter uma transmissão confiável baseada no protocolo UDP?

1. Implemente o mecanismo de resposta de confirmação. Depois que cada dado é recebido, um ACK deve ser realimentado (o aplicativo define um pacote de ACK por si só)
2. Perceba o número de série/confirme o número de série e implemente a desduplicação
3. Implemente a retransmissão de tempo limite.
4. Implemente o gerenciamento de conexões
5. Para melhorar a eficiência, implemente uma janela deslizante
6. Para limitar a janela deslizante, implemente controle de fluxo/controle de congestionamento
7. Perceba resposta atrasada, resposta de piggyback, mecanismo de batimentos cardíacos...

2. Que tipo de cenários são adequados para usar TCP e que tipo de cenários são adequados para usar UDP

1. Se a confiabilidade for necessária -> prefira TCP
2. Se o único datagrama transmitido for longo (mais de 64k) -> prefira TCP
3. Se você prestar atenção especial à eficiência -> dê prioridade ao UDP
4. Se a transmissão for necessária -> UDP é o preferido