Para a alfabetização de problemas de engenharia TCP, primeiro veja isto [ Explicação detalhada do status das conexões TCP e solução de problemas_tcp connection intermitente_hguisu's blog-CSDN blog ]
Núcleo: O pré-requisito para o TCP garantir a confiabilidade é que o link possa ser mantido normalmente e se o link for desconectado por vários motivos. O link será redefinido e os negócios anteriormente transportados exigem que a parte comercial garanta confiabilidade e consistência; além disso, com base nisso, o TCP garante apenas a confiabilidade e a consistência da camada de transporte, e a camada superior também precisa de garantias de negócios.
- O protocolo TCP é um protocolo confiável, mas em aplicações práticas, o aplicativo ainda precisa lidar com alguns detalhes para garantir que os dados possam ser transmitidos conforme o esperado. Alguns serviços podem precisar implementar seu próprio mecanismo de confiabilidade acima do nível TCP, como implementar um mecanismo de confirmação de mensagem na camada de aplicativo para garantir que cada mensagem seja recebida corretamente. Por que? Como fazer isso?
O protocolo TCP é de fato um protocolo confiável, que fornece muitas funções para garantir a transmissão confiável de dados, como número de sequência, número de confirmação, mecanismo de retransmissão, etc. No entanto, em aplicações práticas, devido à complexidade e imprevisibilidade do ambiente de rede, o protocolo TCP não pode garantir totalmente a transmissão confiável de dados. As razões específicas são as seguintes:
1. O TCP garante apenas a confiabilidade das mensagens na camada de transporte, não a confiabilidade das mensagens na camada de aplicação (por exemplo, a mensagem chega na camada de transporte, mas não foi entregue ao negócio neste momento e o processo inesperadamente sai ou o serviço trava devido a vários motivos, como memória repentina ou plenitude da CPU), não recebeu a mensagem).
2. Quando a conexão TCP é desconectada devido a uma anormalidade, como desconexão da rede ou falha de energia, o serviço será inválido quando a conexão for restaurada. Imagine se a empresa não retransmitisse o pacote de dados neste momento, ele não seria perdido?
3. Quando houver congestionamento ou perda de pacotes na rede, o protocolo TCP iniciará o mecanismo de retransmissão para garantir a transmissão confiável dos dados. No entanto, o protocolo TCP não conhece o modo de transmissão de dados que o aplicativo espera. Por exemplo, o aplicativo pode esperar transmissão de dados em tempo real e o mecanismo de retransmissão pode causar atraso na transmissão de dados, afetando assim o desempenho do aplicativo.
A implementação de seu próprio mecanismo de confiabilidade na camada de aplicativo pode tornar o programa aplicativo mais flexível e confiável, e também pode ser otimizado e personalizado de acordo com os requisitos especiais do programa aplicativo. Os métodos específicos incluem: usar o mecanismo KeepAlive do TCP ou o mecanismo de pulsação de negociação para formular políticas de acordo com os cenários de negócios.
-
Os pacotes enviados pelo tcp podem passar por diferentes rotas, como combinar os pacotes e entregá-los no receptor
No protocolo TCP, os dados são divididos em vários pacotes de dados para transmissão e cada pacote de dados tem um número de sequência e uma soma de verificação. A extremidade receptora usa essas informações para confirmar a integridade e a ordem dos pacotes de dados e mesclá-los nos dados completos fluxo é entregue ao aplicativo.
Quando os pacotes TCP passam por rotas diferentes, podem ocorrer fora de ordem, perda, repetição, etc. Para solucionar esses problemas, o protocolo TCP utiliza alguns mecanismos para garantir a confiabilidade e a ordem da transmissão dos dados, como:
-
Número de sequência: Cada pacote TCP possui um número de sequência, que é usado para identificar a posição do pacote no fluxo de dados. O receptor verifica os números de sequência para confirmar a ordem dos pacotes e os mescla em um fluxo de dados completo na ordem correta.
-
Resposta de confirmação: quando a extremidade receptora recebe um pacote de dados TCP, ele enviará uma resposta de confirmação à extremidade transmissora, informando à extremidade transmissora que o pacote de dados foi recebido com sucesso. Se o remetente não receber uma confirmação, ele reenviará o pacote de dados até que o destinatário envie uma confirmação.
-
Janela deslizante: O protocolo TCP usa um mecanismo de janela deslizante para controlar a velocidade na qual o remetente envia pacotes de dados e a velocidade na qual o receptor recebe pacotes de dados. A extremidade emissora ajusta o tamanho da janela deslizante de acordo com a resposta de confirmação retornada pela extremidade receptora para controlar a velocidade de envio; a extremidade receptora ajusta o tamanho da janela deslizante de acordo com seu próprio poder de processamento e tamanho do cache para controlar a velocidade de recepção
-
- Como entender a perda de pacotes TCP [ Os pacotes não serão perdidos se o TCP for usado? _哔哩哔哩_bilibili ]
1. Vários motivos levam à desconexão do TCP ou instabilidade da rede, atraso alto pode causar perda de pacote ( referindo-se à situação em que os pacotes de dados são perdidos durante a transmissão da rede, mas o protocolo TCP passará pelo mecanismo de retransmissão e mecanismo de verificação para garantir a transmissão confiável de dados. )
2. (Essencialmente não o pacote perdido pelo TCP em si não é chamado de perda de pacote) O TCP apenas garante a confiabilidade da mensagem na camada de transporte, não a confiabilidade da mensagem na camada de aplicativo (por exemplo: a mensagem chegou ao transporte camada, mas não foi entregue à empresa neste momento e, de repente, a memória ou a CPU está cheia ou a bateria acabou e outros motivos fazem com que o processo seja encerrado inesperadamente e nenhuma mensagem seja recebida).
O protocolo TCP é um protocolo de transmissão confiável, que garante a confiabilidade da transmissão de dados por meio de vários mecanismos. No protocolo TCP, quando o remetente envia dados, ele divide os dados em vários pacotes e atribui um número de sequência a cada pacote. Depois de receber o pacote de dados, o receptor enviará uma resposta ACK ao remetente para confirmar que o pacote de dados foi recebido. Se o remetente não receber uma resposta ACK dentro de um determinado período de tempo, o pacote de dados será considerado perdido e um mecanismo de retransmissão será acionado.
Portanto, quando o remetente TCP enviar dados, se o pacote de dados for perdido, o mecanismo de retransmissão será acionado até que o destinatário receba os dados e envie uma resposta ACK. Mesmo que ocorra perda de pacotes durante a transmissão pela rede, o protocolo TCP garantirá uma transmissão de dados confiável por meio do mecanismo de retransmissão.
No protocolo TCP, o receptor também tomará algumas medidas para garantir a transmissão confiável dos dados. Por exemplo, quando o receptor recebe um pacote de dados, ele verifica a soma de verificação do pacote de dados para garantir que o pacote de dados não tenha sido adulterado. Caso seja encontrado algum erro no pacote de dados, ele enviará uma resposta NACK ao remetente, solicitando o reenvio do pacote de dados.
Portanto, a chamada perda de pacotes do TCP refere-se à perda de pacotes de dados durante a transmissão da rede, mas o protocolo TCP garantirá a transmissão confiável de dados por meio do mecanismo de retransmissão e do mecanismo de verificação. No protocolo TCP, tanto o remetente quanto o destinatário tomarão algumas medidas para garantir a transmissão confiável de dados.
- fundo de ack de negócios
Não ACK, os dados TCPestão fora de controle após serem transmitidos. Se houver uma desconexão ou desconexão de rede neste momento, é fácil causar perda de mensagem e não pode ser rastreado. Portanto, adicionamos uma resposta para cada solicitação para resolver o problema de não conseguir monitorar ACKa transmissão da mensagem.
Devido à imprevisibilidade e complexidade do ambiente de rede, o protocolo TCP não pode evitar completamente a perda ou dano de dados.Portanto, em aplicações práticas, as empresas geralmente precisam usar ACK (mensagens de confirmação) para garantir a transmissão confiável de dados.
Quando o remetente envia dados, o destinatário precisa enviar uma mensagem de confirmação ACK ao remetente para informar ao remetente que os dados foram recebidos corretamente. Se o remetente não receber a mensagem de confirmação do ACK dentro de um determinado período de tempo, ele pensará que os dados foram perdidos ou há outros problemas e precisa ser retransmitido. Portanto, a mensagem de confirmação do ACK pode ajudar o remetente a descobrir a tempo a perda ou dano de dados, fortalecendo assim a transmissão confiável de dados.
Além disso, a mensagem de confirmação de ACK de necessidades de negócios também pode ser usada para resolver problemas como atraso de rede. Se os dados forem atrasados durante a transmissão, a mensagem de confirmação ACK pode ajudar o remetente a encontrar e retransmitir os dados a tempo, evitando assim a perda e o atraso dos dados.
Em suma, além do protocolo TCP, o negócio precisa usar a mensagem de confirmação ACK para garantir a transmissão confiável de dados, de modo a garantir o funcionamento normal do negócio.
- O princípio das falhas de downlink de serviço e as razões para mensagens de downlink fora de ordem
- Armazenamento distribuído do lado do servidor, as mensagens da mesma sessão estão no mesmo cluster, mas podem ser distribuídas em máquinas diferentes. Situações anormais podem ocorrer fora de ordem e vazias, então o SDK precisa lidar com isso completamente.
- A última mensagem recebida após o cliente ser desconectado é x, e quando o cliente reconectar, a mensagem recebida pode ser x+n (muitas mensagens não foram recebidas com sucesso durante o processo de desconexão), e a mensagem está vazia neste momento.
- O princípio central do bloqueio de cabeça de fila TCP e por que o QUIC é usado
O bloqueio de cabeça de linha se reflete principalmente em dois pontos:
1. Devido à janela deslizante, quando o lado receptor está muito congestionado na rede ou o buffer é insuficiente, o tamanho da janela é ajustado, fazendo com que o lado emissor bloqueie o envio de dados.
2. Quando o congestionamento da rede ou jitter no final do envio é grave, por exemplo, quando a janela deslizante envia um determinado pacote e o retransmite ao longo do tempo, os pacotes atrás da fila da janela serão bloqueados no buffer do final do envio até o anterior os pacotes de dados foram enviados com sucesso. Enviar, causando o bloqueio do remetente.
Os problemas acima são os problemas mais sérios enfrentados por conexões longas. Em uma solicitação de conexão TCP normal, devido à confiabilidade e consistência do protocolo TCP, em um ambiente de rede fraco e em um cenário com alta taxa de perda de pacotes, o tempo de atraso da mensagem será muito grande. Mesmo que a rede retome a transmissão normal de dados, isso atrasos na entrega dos pacotes de dados subsequentes que chegam à camada de negócios.
Para o QUIC, por utilizar UDP, os problemas acima não ocorrerão de forma alguma, e sua ocupação de banda aumentará em relação ao TCP, sendo totalmente viável melhorar o desempenho em tempo real de mensagens com um determinado consumo de banda. Além disso, em comparação com o controle de fluxo TCP, o QUIC realiza o controle de fluxo nos níveis de conexão e fluxo, respectivamente. Para obter detalhes, consulte [ princípio QUIC e use_quic retransmission_John_ToDebug's blog-CSDN's blog ]
- Lógica de ACK em massa
- É para reduzir a pressão da mensagem de confirmação em tempo real do uplink no único link TCP mars (afetando o desempenho em tempo real de outras mensagens de prioridade mais alta no link atual)
- Reduza a pressão do servidor
- Uma única porta pode transportar vários links tcp longos
Uma única porta pode transportar milhares de conexões TCP ao mesmo tempo, dependendo da configuração de hardware do servidor, configurações do sistema operacional, largura de banda da rede e outros fatores.
Em aplicações práticas, você pode otimizar o desempenho do servidor ajustando as configurações de rede do servidor, ajustando os parâmetros do sistema operacional, etc., de modo a aumentar o número de conexões TCP que podem ser transportadas por uma única porta. Por exemplo, os parâmetros do protocolo TCP/IP podem ser ajustados para otimizar a eficiência do uso da largura de banda da rede, ou métodos multi-thread ou multi-processo podem ser usados para processar solicitações de conexão e assim por diante.
Além disso, para aplicativos de alta simultaneidade, a tecnologia de balanceamento de carga também pode ser usada para compartilhar a carga do servidor, aumentando assim ainda mais o número de conexões TCP que uma única porta pode transportar.
TCPPor que conexões longas precisam de multiplexação por divisão de tempo?
Se o cliente criar uma TCPconexão longa para cada negócio, à medida que o número de negócios aumenta, conexões cada vez mais longas precisam ser mantidas. Para algumas empresas, algumas mensagens podem não ser transmitidas em um dia, mas conexões longas devem ser mantidas o tempo todo. Essas conexões longas consomem muita energia, tráfego, largura de banda, memória etc., o que é muito hostil para os dispositivos como telefones celulares, para resolver esse tipo de problema, desenvolvemos a tecnologia de multiplexação por divisão de tempo de conexão longa TCP, ou seja, vários serviços coexistem em uma conexão longa TCP ao mesmo tempo, os serviços são transparentes entre si , e os dados não interferem uns com os outros
- Garantia de confiabilidade de mensagem de uplink
A mensagem de uplink refere-se à mensagem enviada do cliente para o servidor. Para a mensagem de uplink, mantemos SDKum buffer de envio internamente. Antes que a mensagem seja enviada para o servidor, a mensagem será salva no buffer. Para cada mensagem, nós need ACKA mensagem é excluída do buffer somente após o ou exceder o ciclo de vida da mensagem.Se o timeout ou a desconexão não receber uma resposta do servidor, SDKela será retransmitida periodicamente.
Com a retransmissão de mensagens, deve haver desduplicação de mensagens, caso contrário, pode causar duplicação de mensagens. Para evitar o problema de duplicação de mensagens, nosso cliente manterá SDKum número de série crescente monotonicamente, através do qual Heavy. Após o servidor receber uma nova mensagem, ele registrará o número de sequência da mensagem. Ao receber novamente uma mensagem com um número de sequência menor ou igual a ele, ele a considerará uma mensagem duplicada e a descartará diretamente para garantir que o mensagem não se repete.
O resultado do envio de cada mensagem upstream será retornado para a camada de negócios. Quando a mensagem não for enviada, a camada de negócios pode decidir se a retransmite ou toma outras medidas corretivas de acordo com suas próprias necessidades, de modo a garantir totalmente o confiabilidade da mensagem upstream.
A mensagem de downlink refere-se à mensagem encaminhada pelo servidor ao cliente. Para esse tipo de mensagem, projetamos um IDmecanismo para uma sequência ordenada local dentro da sessão. A sessão aqui se refere a uma sala de bate-papo, um grupo de bate-papos individuais, etc., em uma sessão Números de série incrementais e independentes serão gerados na sessão de grupo, e os números de série entre as sessões não têm nada a ver um com o outro. Este método pode melhorar muito o desempenho do servidor que envia números, mas os números de série emitidos pelo servidor não aumentam continuamente e há saltos. , para resolver esse problema, projetamos uma estrutura semelhante a uma lista vinculada unidirecional. Em comparação com a lista vinculada tradicional, essa lista vinculada está na ordem inversa. Cada mensagem na sessão salva uma pré-encomenda, esta mensagem SeqId, SeqIdmensagem única global Id(para rastreamento de mensagens). Quando o cliente receber a primeira mensagem na sessão, ele gravará a mensagem. SeqIdQuando receber uma nova mensagem na sessão, ele detectará a nova mensagem SeqId. Se a nova mensagem for SeqIdmenor ou igual à última mensagem recebida SeqId, isso prova que a mensagem é repetida, caso contrário, verifique a pré-encomenda da nova mensagem SeqId, se a pré-encomenda da nova mensagem for consistente SeqIdcom a última mensagem recebida SeqId, comprove que as duas mensagens são contínuas e envie diretamente a mensagem Retorne ao camada de negócios. Se forem inconsistentes, significa que há um intervalo entre as duas mensagens. Nesse momento, o cliente demorará um pouco. Se o intervalo entre as duas mensagens não puder ser preenchido, o cliente irá ativamente ao servidor para puxar o lacuna entre as duas mensagens. conteúdo para garantir que as mensagens sejam ordenadas e não perdidas.
Após a desconexão e reconexão, o cliente também enviará SeqIdas últimas informações recebidas de cada sessão para o servidor, e o servidor combinará as informações transmitidas pelo cliente com SeqIda situação atual de cada sessão para enviar as mensagens perdidas durante a desconexão do cliente. para garantir que a mensagem não seja perdida durante a desconexão do cliente.
-
Os benefícios de usar várias conexões TCP longas em uma única conexão TCP longa
-
Melhorar o desempenho simultâneo: o uso de várias conexões TCP longas pode permitir que o cliente estabeleça várias conexões com o servidor ao mesmo tempo, melhorando assim os recursos de processamento simultâneo. Isso é muito útil para cenários de alta simultaneidade, como servidores web, filas de mensagens, etc.
-
Reduzir o atraso: o uso de várias conexões TCP longas pode evitar o problema de bloqueio de cabeçalho em uma única conexão TCP longa, reduzindo assim o atraso. Em uma única conexão TCP longa, se a solicitação anterior demorar muito para ser processada, as solicitações subsequentes serão bloqueadas, aumentando assim o atraso geral. O uso de várias conexões TCP longas pode dispersar as solicitações em várias conexões, evitando problemas de bloqueio de cabeçalho de linha e, assim, reduzindo os atrasos.
-
Melhorar a confiabilidade: o uso de várias conexões TCP longas pode melhorar a confiabilidade do sistema. Se uma única conexão TCP longa falhar, todo o sistema ficará indisponível. O uso de várias conexões TCP longas pode dispersar solicitações em várias conexões, mesmo que uma das conexões falhe, isso não afetará a disponibilidade de todo o sistema.
-
Deve-se notar que o uso de várias conexões TCP persistentes também trará alguns problemas, como aumentar a carga no servidor e aumentar o uso da largura de banda da rede. Portanto, em aplicações práticas, compensações e escolhas precisam ser feitas de acordo com situações específicas.
perguntas e respostas
P: Os recursos da Internet são certos
R: Sim, os recursos de rede são limitados e o uso de várias conexões TCP longas também ocupará determinados recursos de rede. Portanto, em aplicações práticas, compensações e escolhas precisam ser feitas de acordo com situações específicas.
Se múltiplas conexões TCP persistentes forem usadas ao mesmo tempo, isso pode causar congestionamento de rede e competição de recursos, reduzindo assim o desempenho e a confiabilidade do sistema. Além disso, se várias conexões TCP longas forem usadas e o volume de dados de cada conexão for pequeno, a sobrecarga de estabelecer e fechar conexões pode exceder a sobrecarga de transmissão de dados, desperdiçando recursos de rede.
Portanto, em aplicações práticas, compensações e escolhas precisam ser feitas de acordo com situações específicas. Se você precisar melhorar o desempenho simultâneo e a confiabilidade do sistema, considere o uso de várias conexões TCP longas; se os recursos de rede forem limitados, considere o uso de uma única conexão TCP longa e use outros métodos para melhorar o desempenho e a confiabilidade do sistema, como usar um pool de conexão, otimizar o processo de processamento de solicitações, etc.
P: O congestionamento de cada link TCP é independente?
R: Sim, cada link TCP é independente e o controle de congestionamento entre eles é independente um do outro.
Quando a rede estiver congestionada, o protocolo TCP ajustará a taxa de envio de dados de acordo com o grau de congestionamento da rede e a taxa de transmissão de dados. Se um link TCP estiver congestionado, o protocolo TCP reduzirá a taxa de envio do link para evitar mais congestionamento. Neste momento, a taxa de envio de outros links TCP não será afetada e eles ainda poderão continuar enviando dados na taxa máxima.
Deve-se observar que, embora cada link TCP seja independente, eles compartilham o mesmo recurso de rede. Portanto, quando a rede está congestionada, todos os links TCP podem ser afetados, resultando em maior atraso na transmissão, maior taxa de perda de pacotes e outros problemas. Para evitar essa situação, algumas medidas precisam ser tomadas para otimizar a utilização dos recursos da rede, como usar algoritmos de controle de congestionamento, definir a taxa de envio de dados de forma razoável e assim por diante.
P: Quando a rede está congestionada, todos os links tcp não deveriam estar congestionados?
R: Sim, quando a rede está congestionada, todos os links TCP podem ser afetados, resultando em maior atraso na transmissão, maior taxa de perda de pacotes e outros problemas. Portanto, quando a rede está congestionada, todos os links TCP podem estar congestionados.
O protocolo TCP ajustará a taxa de envio de dados de acordo com o grau de congestionamento da rede e a taxa de transmissão de dados. Quando a rede estiver congestionada, o protocolo TCP reduzirá a taxa de envio para evitar o agravamento do congestionamento. Como cada link TCP é independente, o protocolo TCP executa o controle de congestionamento em cada link para evitar o congestionamento do link.
Deve-se observar que, quando a rede está congestionada, todos os links TCP compartilham o mesmo recurso de rede. Portanto, quando a rede está congestionada, todos os links TCP podem ser afetados. Para evitar essa situação, algumas medidas precisam ser tomadas para otimizar a utilização dos recursos da rede, como usar algoritmos de controle de congestionamento, definir a taxa de envio de dados de forma razoável e assim por diante.
P: O que acontece quando o link tcp a está congestionado, mas o link tcp b não está congestionado?
R: No caso de congestionamento da rede, cada link TCP pode estar congestionado. No entanto, como as características de transmissão e as características dos dados transmitidos de cada enlace TCP podem ser diferentes, em situações reais, pode haver situações em que um enlace TCP esteja congestionado enquanto o outro enlace TCP não esteja congestionado.
Por exemplo, suponha que os links TCP A e B transmitam diferentes quantidades de dados, o link A transmita uma quantidade maior de dados e o link B transmita uma quantidade menor de dados. Quando a rede está levemente congestionada, o link A pode estar congestionado, mas o link B pode não ser afetado. Neste momento, o protocolo TCP controlará o congestionamento do link A e reduzirá sua taxa de envio, de forma a evitar maior agravamento do congestionamento. A taxa de envio do link B não é afetada porque não está congestionada.
Deve-se observar que, quando a rede está muito congestionada, todos os links TCP podem ser afetados, resultando em aumento do atraso de transmissão e aumento da taxa de perda de pacotes. Portanto, em aplicações práticas, algumas medidas precisam ser tomadas para otimizar a utilização dos recursos da rede, como usar algoritmos de controle de congestionamento, definir a taxa de envio de dados de maneira razoável e assim por diante.
P: O TCP não recebeu a confirmação do ponto após enviar os dados e, após várias tentativas, descartará o pacote de dados atual e continuará a enviar a próxima mensagem?
R: Depois que o TCP enviar os dados, se não tiver recebido a resposta ACK do peer e ainda não tiver recebido a resposta ACK após várias tentativas, o protocolo TCP considerará que o pacote de dados foi perdido e acionará o mecanismo de retransmissão . O protocolo TCP realizará várias retransmissões.Se ainda assim várias retransmissões falharem, o envio do pacote de dados será abandonado e a próxima mensagem continuará a ser enviada.
No protocolo TCP, quando o remetente enviar dados, ele aguardará a resposta ACK do destinatário. Se nenhuma resposta ACK for recebida dentro de um determinado período de tempo, os dados serão reenviados. Se nenhum ACK for recebido após várias retransmissões, o envio do pacote de dados será abandonado e a próxima mensagem será enviada. Isso garante uma transmissão de dados confiável e evita problemas como congestionamento de rede e carga excessiva.
Q: Depois que o TCP enviar os dados, se não tiver recebido a resposta ACK do par e ainda não tiver recebido a resposta ACK após várias tentativas, o protocolo TCP considerará o pacote de dados como perdido e acionará o mecanismo de retransmissão. O protocolo TCP realizará várias retransmissões.Se ainda assim várias retransmissões falharem, o envio do pacote de dados será abandonado e a próxima mensagem continuará a ser enviada. Neste caso, pode haver furos nos dados que chegam na extremidade receptora
R: Sim, quando o remetente TCP envia dados, se o pacote de dados for perdido, o mecanismo de retransmissão será acionado até que o destinatário receba os dados e envie uma resposta ACK. Se o remetente não receber uma resposta ACK após várias retransmissões, ele desistirá de enviar o pacote de dados e continuará enviando a próxima mensagem. Nesse caso, o receptor pode receber mensagens vazias.
Quando ocorre uma falha de mensagem no protocolo TCP, o receptor pode usar o mecanismo de janela deslizante do protocolo TCP para lidar com isso. O mecanismo de janela deslizante pode controlar o espaço de buffer do receptor para garantir que o receptor receba apenas pacotes de dados ordenados e pode armazenar em buffer um certo número de pacotes de dados para recepção subsequente. Além disso, o protocolo TCP também pode usar números de sequência para garantir a ordem dos pacotes de dados e garantir que o receptor receba os pacotes de dados na ordem correta.
Se o remetente ainda não receber uma resposta ACK após várias retransmissões, pode ser devido a falha na rede ou o destinatário encerrou a conexão. Nesse caso, o remetente pode optar por restabelecer a conexão ou desistir de enviar o pacote de dados de acordo com a situação específica.