minhas informações de contato
Correspondência[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
O protocolo TCP possui as características de conexão, transmissão confiável, orientação a fluxo de bytes, full-duplex, etc.
figura 1
A figura acima é a estrutura do cabeçalho TCP.
(1) A porta de origem e a porta de destino não precisam ser muito introduzidas. São os programas usados para indicar o terminal de envio e o terminal de recebimento.
(2) O número de sequência e o número de sequência de confirmação são usados para o mecanismo de resposta de confirmação no TCP introduzido posteriormente.
(3) Os 4 bits na parte de deslocamento de dados são realmente usados para indicar o comprimento do cabeçalho TCP aqui. Por causa dos 4 bits, o número máximo representado é 15, mas como a unidade é de 4 bytes, o comprimento máximo do. O cabeçalho TCP tem 60 bytes.
(4) Todos sabemos que o comprimento máximo dos pacotes de dados UDP é de 64kb, o que é muito limitado, portanto, para evitar esta situação, são fornecidos 6 bits reservados no cabeçalho TCP, que podem ser utilizados se a função TCP for expandida posteriormente. Representado usando bits reservados.
(5) O identificador inglês de 6 bytes está relacionado ao mecanismo TCP introduzido posteriormente e não será introduzido aqui.
(6) A soma de verificação tem a mesma função que a soma de verificação no UDP e também é usada para verificar se os dados foram alterados durante o processo de transmissão.
(7) A janela será discutida posteriormente quando o mecanismo for introduzido.
(8) O ponteiro de emergência será introduzido posteriormente.
(9) Entre as opções estão algumas opções opcionais/opcionais.
O protocolo TCP tem que resolver um problema muito importante – transmissão confiável. A chamada transmissão confiável não significa que o remetente possa enviar 100% os dados ao destinatário, mas fará o possível para que o remetente saiba se o destinatário sabe.
Figura 2
Conforme mostrado na Figura 2, toda vez que você envia uma mensagem para a deusa, a deusa enviará uma mensagem de volta para você. Este é o caso no TCP. O cliente envia um pacote de dados e o servidor. retornar um pacote de dados de resposta. Neste momento, os dados de resposta O sinalizador ACK do pacote na Figura 1 será definido como 1.
imagem 3
Conforme mostrado na Figura 3, quando enviamos várias mensagens para a deusa, porque a deusa responde às mensagens em velocidades diferentes, é fácil ficarmos confusos. Vamos pensar que a deusa concorda em ser minha namorada. a deusa diz para se perder. Esta é a Internet. O problema do último a chegar, primeiro a ser servido, existe objetivamente na China. Obviamente, enviando vários pacotes de dados para o cliente, e o cliente respondendo a vários pacotes de dados de resposta, também precisamos distinguir qual resposta corresponde a qual pacote de dados foi enviado. Este problema pode ser resolvido usando o número de sequência e o número de sequência de confirmação na Figura 1. .
Cada pacote de dados enviado possui um número de sequência, mas não há um número de sequência de confirmação, ou o campo do número de sequência de confirmação é inválido. O ACK do pacote de dados que responde a ele é 1. Neste momento, o campo do número de sequência de confirmação é válido. e o número de sequência e resposta do pacote de dados enviado Os números de sequência de confirmação dos pacotes de dados são correspondentes, de modo que pode ser distinguido quem respondeu a quem, e o problema do último a chegar, primeiro a ser servido acima mencionado na rede pode ser resolvido .
O número de sequência do pacote de dados TCP real é numerado de acordo com os bytes. Cada byte receberá um número de sequência. O valor do número de sequência no cabeçalho TCP é o número do primeiro byte na carga útil, por exemplo, o número. do primeiro byte na parte da carga útil Um número de byte é 1 e o comprimento da carga útil é 1000 bytes, então o número de sequência de confirmação no cabeçalho do pacote de dados de resposta é 1001. Isso ocorre porque o número de sequência de confirmação do pacote de dados é 1001. o pacote de dados de resposta correspondente ao pacote de dados é definido como O número do último byte da carga útil é aumentado em 1. Na verdade, isso é mais fácil de entender. Retornar 1001 significa que a carga útil de 1000 bytes enviada foi recebida e o. dados após 1001 são solicitados, conforme mostrado na Figura 4.
Figura 4
Para pacotes de dados subsequentes enviados, o número de sequência é incrementado, mas uma coisa a observar é que, embora seja incrementado, o número de sequência não começa em 0 ou 1.
A transmissão confiável pode ser alcançada principalmente com base no mecanismo de “resposta de confirmação”. Ele pode informar ao remetente, por meio da mensagem de resposta, se tudo está indo bem e se ocorre perda de pacotes. O que deve ser feito se ocorrer perda de pacotes (os dados são descartados durante o processo de transmissão e não podem chegar ao extremo oposto, um evento aleatório objetivo)?
A retransmissão de tempo limite é usada para lidar com problemas de perda de pacotes na rede.
Existem basicamente duas situações aqui:
(1) Pacotes de dados transmitidos são perdidos
Neste momento, B não enviará um pacote de resposta se não receber o pacote de dados de A. Quando o evento que A está esperando exceder um determinado limite, ele determinará que ocorreu um problema de perda de pacote e retransmitirá o pacote de dados.
(2) O pacote de dados de resposta foi perdido
Quando A não recebe o pacote de dados de resposta, ele ainda retransmite um pacote de dados, mas neste momento B recebeu um pacote de dados. Com a retransmissão do pacote de dados, ele receberá dois pacotes de dados idênticos. , especialmente para questões como transferências, onde ocorrerão transferências repetidas.
Para os problemas acima, o receptor TCP desduplicará os dados recebidos de acordo com o número de sequência. A camada TCP não se preocupa com o problema de duplicação. A chave é que a camada de aplicação não pode ler dados duplicados, não importa quantas vezes sejam retransmitidos, deve-se garantir que apenas uma cópia dos dados seja lida pela camada de aplicação.
No kernel do sistema operacional receptor, existe uma estrutura de dados - o buffer de recebimento. Essa estrutura de dados é semelhante à fila de bloqueio de prioridade. Quando B recebe o pacote de dados e passa pelas camadas até a camada de transporte, haverá uma. fila de bloqueio para colocar os dados. Insira-os e a fila determinará se os dados existem com base no número de sequência do pacote de dados. Se existir (existência significa que o mesmo pacote de dados foi recebido e lido uma vez pelo. camada de aplicação), ele será descartado diretamente. Outro ponto do buffer de recebimento é que ele pode resolver o problema do último a chegar, primeiro a ser servido na rede. Os dados enviados serão classificados de acordo com o número de sequência e depois consumidos pelo programa da camada de aplicação em ordem.
Conforme mostrado na figura acima, os dados que chegam ao buffer de recebimento serão classificados de acordo com o número de sequência. Isso não apenas resolve o problema de último enviado, primeiro a chegar, mas também resolve o problema de recebimento de pacotes de dados duplicados. desta vez, se o pacote de dados retransmitido for recebido com o número de sequência 500, ele será descartado diretamente, pois o número de sequência mínimo do buffer de recebimento é 1000, o que significa que 500 já foi lido pelo programa aplicativo.
A perda de pacotes em si é um evento de pequena probabilidade. Quando o número de perdas de pacotes aumenta, a rede se tornará um grande problema. À medida que o número de retransmissões aumenta, o intervalo de tempo entre as retransmissões continua a aumentar, porque mais retransmissões indicam que há um problema com a rede e retransmissões frequentes consumirão recursos. Quando o número de retransmissões atingir um limite, uma mensagem de reinicialização será enviada com o bit do sinalizador RST definido como 1 para limpar o status intermediário de ambas as extremidades. Se a mensagem de reinicialização não for respondida, a conexão em ambas as extremidades será excluída.
A retransmissão de tempo limite é um complemento à resposta de confirmação.
Figura 5
Estabelecer uma conexão significa que ambas as partes comunicantes salvam as informações da outra extremidade. A conclusão específica requer três interações de rede, conforme mostrado na Figura 5.
A primeira vez do handshake triplo deve ser iniciada pelo cliente. Quem inicia o handshake triplo é o cliente. O processo específico é mostrado na Figura 5. Primeiro, o cliente envia um pacote SYN, ou seja, o sinalizador SYN no cabeçalho é definido como 1. Em seguida, o servidor retorna um pacote de resposta. Os sinalizadores ACK e SYN do pacote de resposta são. ambos definidos como 1, porque ACK e SYN Os pacotes de dados com bits de flag são enviados pelo kernel do sistema operacional ao mesmo tempo, para que possam ser enviados juntos para melhorar o desempenho. Finalmente, o cliente envia um pacote de resposta ao servidor e o handshake triplo é concluído. Os pacotes de dados transmitidos durante esse processo não contêm dados comerciais.
O significado do aperto de mão triplo:
(1) Lançar pedras para pedir informações
Confirme se o link de comunicação está tranquilo
(2) Negociar alguns parâmetros importantes
Por exemplo, o número de sequência do pacote de dados transmitido
(3) Confirme as capacidades de recebimento e envio de ambas as partes
Por que três apertos de mão? Quatro apertos de mão ou dois apertos de mão estão bem?
Embora o handshake de quatro vias não afete as funções normais, ele reduzirá o desempenho. O handshake de duas vias não pode confirmar totalmente as capacidades de recebimento e envio do servidor.
Além disso, há mais dois estados importantes envolvidos aqui. O primeiro é o estado de escuta, o que significa que o servidor ligou a porta neste momento e está aguardando o envio do pacote SYN pelo cliente. fácil de entender e significa que o handshake de três vias é concluído. O estado após a conexão ser estabelecida.
Ao contrário do handshake de três vias, que só pode ser iniciado primeiro pelo cliente, tanto o servidor quanto o cliente podem iniciar o handshake de quatro vias.
Figura 6
O processo específico de acenar quatro vezes é mostrado na Figura 6. Quando o método socket.close() é chamado no código do cliente ou quando o processo termina, uma mensagem FIN final será enviada ao servidor. Mensagem ACK de volta, mas terá que esperar até o código do servidor Somente após chamar um código como socket.close() a mensagem FIN final pode ser enviada ao cliente. Depois disso, o cliente envia uma mensagem ACK ao servidor, e o processo é concluído acenando quatro vezes.
O ACK e o FIN no meio aqui não podem ser combinados, porque o ACK é enviado pelo kernel do sistema, então ele será enviado imediatamente quando o servidor receber a mensagem FIN, mas a mensagem FIN terá que esperar até que o código do lado do servidor executa o soquete. Ele pode ser enviado após close() e há uma diferença de tempo entre os dois. Mas existe uma forma de combinar os dois. Em circunstâncias especiais, o ACK pode ser enviado com atraso, para que possa ser enviado junto com o FIN.
Além disso, existem dois estados envolvidos nos quatro processos de ondulação. O primeiro é o estado close_wait. Este estado é o estado em que o receptor se encontra após receber a mensagem FIN do remetente. que a parte precisa esperar após receber o FIN enviado pelo destinatário e depois enviar um ACK ao destinatário. A conexão não pode ser desconectada imediatamente porque é necessário evitar que o último ACK enviado pelo remetente ao destinatário seja perdido e. o receptor retransmitindo o FIN Para garantir que o remetente ainda possa receber este FIN, o tempo neste estado é geralmente 2MSI (MSI: o tempo máximo para transmissão de dados em ambas as extremidades), que geralmente é de 2 minutos.
Se um grande número de close_wait for encontrado no receptor, significa que o método close() foi esquecido. Se um grande número de time_wait for encontrado no servidor, significa que o servidor acionou um grande número de desconexão TCP ativa. operações.
O TCP precisa garantir uma transmissão confiável, mas ao mesmo tempo também deseja concluir a transmissão de dados da maneira mais eficiente possível. A janela deslizante é um mecanismo para melhorar a eficiência. Na verdade, essa é uma forma de compensar, pois para garantir a confiabilidade, o TCP sacrifica muito o desempenho. Não importa como você deslize a janela, a velocidade de transmissão de dados não pode ser mais rápida que o UDP.
Figura 7
Conforme mostrado na Figura 7, este é o processo de transmissão de dados, mas o processo de envio de um pacote de dados e recebimento de um pacote de dados de resposta ainda é relativamente lento.
Figura 8
Conforme mostrado na Figura 8, isso ocorre após a introdução do mecanismo de janela deslizante. Em vez de enviar um pacote de dados, mas vários pacotes de dados por vez, o tempo de espera dos pacotes de dados de resposta retornados se sobrepõe. Sem esperar pelo ACK, a quantidade de dados enviados em lotes é o tamanho da janela.
Figura 9
O processo de janela deslizante é mostrado na Figura 9. Suponha que o tamanho da janela seja de 4 grupos. Quando um grupo receber ACK, novos dados serão enviados para complementá-lo, o que equivale a um processo deslizante. Se o remetente receber o ACK de 3001, significa que os dados de 1001 a 3001 foram recebidos, portanto a janela pode mover dois espaços para a direita.
O que fazer se ocorrer perda de pacotes na janela deslizante Existem duas situações:
(1) O pacote de dados enviado é perdido
Se um determinado grupo de datagramas enviados for perdido, embora você envie muitos grupos de dados ao receptor em lotes, o número de sequência de confirmação do ACK recebido ainda será o do grupo perdido até que o remetente retransmita o datagrama. Por exemplo, os datagramas 1001 ~ 2000 na imagem acima são perdidos. Mesmo que vários conjuntos de dados sejam transmitidos posteriormente, o ACK de 1001 será retornado até que o remetente o retransmita e o receptor o receba, e então responda com o ACK de 7001. .
(2) A resposta ACK foi perdida
Se o ACK de resposta for perdido, você não precisa se preocupar com isso, pois você pode apenas esperar até que o ACK de outros grupos de dados seja retornado. Por exemplo, se o ACK de 1001 na imagem acima for perdido, ele será perdido. não importa. O remetente do próximo ACK de 2001 os recebeu. Os dados anteriores foram recebidos e o mesmo acontece se o ACK dos dados subsequentes for perdido.
O processamento de perda de pacotes mencionado acima ainda é muito eficiente. Se o pacote de dados for perdido, basta preencher a lacuna e retransmitir os dados. Se o ACK for perdido, simplesmente ignore-o. Tal operação é chamada de retransmissão rápida.
A retransmissão de tempo limite e a retransmissão rápida são estratégias diferentes adotadas em ambientes diferentes. Se o seu TCP transmitir dados poucos e pouco frequentes, a retransmissão de tempo limite será acionada. Se o seu TCP precisar transmitir uma grande quantidade de dados em um curto período de tempo, a janela deslizante será acionada. ser acionado. Retransmissão rápida, retransmissão rápida é equivalente à variante de retransmissão de tempo limite sob a janela deslizante.
Conforme mencionado anteriormente sobre a janela deslizante, o tamanho da janela é variável. Você pode controlar a velocidade de envio do remetente alterando o tamanho da janela, mais dados são enviados por unidade de tempo e maior será a eficiência. Quanto menor a janela, mais dados são enviados por unidade de tempo. Quanto menos dados houver, menos eficiente será. Normalmente, é claro, esperamos que a eficiência seja a mais alta possível, mas o pré-requisito para alta eficiência é garantir a confiabilidade. Se o remetente enviar muito rápido e o destinatário não conseguir lidar com isso, poderá ocorrer perda de pacotes. is O receptor informa ao remetente que a velocidade de envio é muito rápida. Isso é "controle de fluxo".
Conforme mostrado na figura acima, conforme mencionado anteriormente, existe um buffer de recepção de estrutura de dados no kernel, e o receptor retornará o tamanho do espaço livre no buffer de recepção como o tamanho da janela. O cabeçalho TCP anterior possui um campo de tamanho de janela de 16 bits que usa ACK para salvar e retornar essas informações. O campo de tamanho de janela só terá efeito em ACK.
Conforme mostrado na figura acima, o ACK retornará o tamanho da janela para atingir o objetivo de controle de fluxo. Quando o tamanho da janela retornar a 0, o remetente enviará periodicamente mensagens de sondagem que não contêm dados de negócios para acionar o ACK para saber o. status do buffer. Existe algum espaço livre.
O controle de congestionamento é muito semelhante ao controle de fluxo, ambos os mecanismos são combinados com janelas deslizantes.
Conforme mostrado na figura acima, os links da rede são muito complexos e qualquer nó no link pode restringir a velocidade do remetente. A ideia do controle de congestionamento é tratá-lo como um todo, por mais complexa que seja sua estrutura intermediária, e então encontrar o tamanho de janela mais adequado por meio de experimentos.
A figura acima é um processo de controle de congestionamento. Primeiro tente com um tamanho de janela relativamente pequeno (início lento), porque você não conhece a situação de congestionamento da rede. Depois disso, o tamanho da janela aumentará exponencialmente e quando atingir. um certo limite, ele começará a crescer linearmente e, quando a janela crescer até certo ponto, ocorrerá perda de pacotes. Nesse momento, a janela será imediatamente reduzida.
(1) Encolher diretamente para o fundo, retornar ao início do início lento e, em seguida, repetir o processo anterior (já abandonado)
(2) Diminuir pela metade e depois aumentar linearmente (o método real usado)
O controle de congestionamento consiste em usar experimentos para encontrar um tamanho de janela adequado. Se houver muita perda de pacotes, reduza o tamanho da janela. Se não houver perda de pacotes, aumente o tamanho da janela.
Resposta atrasada, como o nome sugere, significa esperar um pouco antes de retornar o ACK. Na verdade, isso também envolve a questão do tamanho da janela, pois a resposta atrasada do ACK dará ao receptor mais tempo para consumir os dados no buffer de recebimento, aumentando assim. o tamanho do buffer livre, o tamanho da janela retornado pelo ACK aumenta e o remetente pode enviar mais dados em lotes.
Existem dois métodos de resposta atrasada:
(1) Especifique o atraso de acordo com um determinado tempo
(2) De acordo com a quantidade de dados recebidos
As duas estratégias acima são usadas em combinação.
As respostas sobrepostas já apareceram antes, como um mecanismo usado para melhorar a eficiência da transmissão. Este é o caso em que ACK e SYN são retornados usando o mesmo pacote de dados no handshake triplo. Há também uma situação semelhante à das Quatro Ondas. Como o ACK e o FIN são enviados em momentos diferentes, as respostas nas costas não podem ser feitas. No entanto, com a resposta atrasada, o ACK não precisa ser enviado ao remetente tão rapidamente. podem ser combinadas com os dois FINs As transmissões secundárias são combinadas em uma única transmissão por meio do piggybacking nas respostas.
Orientado a fluxo de bytes é um mecanismo do TCP. Um problema que precisa ser observado aqui é o problema de aderência de pacotes. Esse problema é causado pela incapacidade de distinguir os limites entre os diferentes pacotes de dados da camada de aplicativo. fluxo de bytes, o servidor pode ler vários bytes e também pode ler um byte, o que pode facilmente causar esse problema.
Existem duas soluções para o problema do saco pegajoso acima:
(1) Use separadores
Qualquer símbolo pode ser usado desde que não exista no pacote de solicitação
(2) Combine o comprimento do pacote de dados
No entanto, na maioria dos casos, os programadores Java não usam TCP diretamente. Em vez disso, eles usam protocolos prontos, como http, ou implementam comunicação de rede com base em ferramentas como protobuffer ou dubbo. Perdido.
(1) Em ambas as extremidades da comunicação, o processo travou em uma extremidade.
O sistema operacional completa quatro ondas e agita o PCB.
(2) Um determinado host é desligado (processo normal)
A primeira possibilidade é que o sistema operacional tenha completado quatro ondas. A segunda possibilidade é que o receptor não tenha resposta ACK após enviar o FIN. Ele retransmite várias vezes e depois exclui unilateralmente a conexão. que desliga, pois todos estão desligados. As informações armazenadas (memória) desaparecem naturalmente.
(3) A fonte de alimentação de um determinado host está desligada.
Quando o host desligado for um servidor, o pacote de dados enviado pelo cliente será retransmitido sem ACK. Se nenhum resultado for obtido após múltiplas retransmissões, a conexão será excluída.
Quando o host desligado é um cliente e o servidor não recebe um pacote de dados há muito tempo, ele enviará periodicamente um pacote de pulsação sem carga útil, apenas para acionar um ACK. Se o cliente estiver normal, ele retornará. um ACK, caso contrário não o receberá. Se nenhuma resposta for recebida do cliente após ser enviado várias vezes seguidas, mas não houver resposta, pode-se considerar que o cliente está inativo e as informações de conexão são excluídas.
Além disso, embora o TCP implemente pacotes de pulsação, o ciclo é longo. Geralmente, leva alguns minutos para descobrir que o cliente está inativo nesse pacote de pulsação. No desenvolvimento real, os pacotes de pulsação na camada de aplicação serão implementados, com frequência mais alta e período mais curto (os pacotes de pulsação de segundo nível/milissegundo são enviados). . Uma vez que o dispositivo trava, você pode encontrar o problema rapidamente.
(4) O cabo de rede está desconectado
Essencialmente, é o terceiro caso. Se o remetente não receber o ACK, ele atingirá o tempo limite e retransmitirá, depois enviará o RST e, em seguida, excluirá a conexão unilateralmente. Se o destinatário não receber o pacote de dados, ele enviará um pacote de pulsação. . Se não receber o ACK, ele simplesmente enviará um pacote de pulsação com informações de exclusão.
Existem dois bits de sinalização na estrutura do cabeçalho TCP que não são mencionados, nomeadamente PSH e URG, que solicitam que a outra parte retorne uma resposta o mais rápido possível. O URG está associado ao campo de ponteiro de emergência do cabeçalho do pacote TCP e é usado em conjunto para controlar a transmissão de dados fora de banda do TCP.
A transmissão de dados fora de banda significa que, além dos dados comerciais, existem alguns pacotes de dados especiais usados para controlar o mecanismo de funcionamento do próprio TCP.
Ele se dedica à pesquisa de tecnologia há mais de 30 anos e é proficiente em diversas linguagens como java, linux, javascript, php, css, etc. estação de documentação do desenvolvedor para compartilhar alguns problemas no desenvolvimento de tecnologia para referência futura.
Correspondência[email protected]