o que é TCP Half Open Connection e TCP half closed connection

Estou tentando entender qual é a diferença entre TCP Half Open Connection e TCP Half Closed Connection, alguém pode dizer exatamente o que são?

Esta postagem se expande em conexões semi fechadas. Para conexões semi-abertas, consulte a descrição correta do KContreau.

O que são conexões semi fechadas? Ou: Não é um bug - é um recurso!

Toda conexão TCP consiste em duas meias-conexões que são fechadas independentemente uma da outra. Portanto, se uma extremidade envia um FIN, a outra extremidade fica livre para apenas ACK que FIN (em vez de FIN + ACK), que sinaliza ao final de envio FIN que ainda possui dados para enviar. Portanto, ambas as extremidades acabam em um estado estável de transferência de dados, além de ESTABLISHED - ou seja, FIN_WAIT_2 (para o recebimento) e CLOSE_WAIT (para o envio). Diz-se que essa conexão está meio fechada e o TCP é realmente projetado para suportar esses cenários; portanto, as conexões meio fechadas são um recurso do TCP.

A história da conexão meio fechada

Embora a RFC 793 apenas descreva o mecanismo bruto sem mencionar o termo "semifechado", a RFC 1122 detalha esse assunto na seção 4.2.2.13. Você pode se perguntar quem diabos precisa desse recurso. Os designers do TCP também implementaram o TCP / IP para o sistema Unix e, como todo usuário Unix, adoraram o redirecionamento de E / S. De acordo com W. Stevens (TCP / IP ilustrado, Seção 18.5), o desejo de redirecionar I / O TCP streams foi a motivação para introduzir o recurso. Ele permite que o FIN aceite o papel ou seja traduzido como EOF. Portanto, é basicamente um recurso que permite criar casualmente uma interação imediata no estilo de solicitação / resposta na camada do aplicativo, onde o FIN sinaliza "fim da solicitação".

Quando o TCP estabelece uma conexão, ele é considerado garantido, pois ocorre um handshake:

1. O computador iniciante envia a solicitação de conexão, enviando um SYN
2. O computador respondente concede a solicitação, respondendo com um SYN-ACK
3. O computador iniciante envia uma confirmação, respondendo com um ACK

Nesse ponto, a conexão é estabelecida e os dados começam a fluir. Por outro lado, um pacote UDP não é garantido e é enviado apenas na esperança de chegar lá.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Oficialmente, de acordo com as RFCs, uma conexão TCP semi-aberta ocorre quando um lado da conexão estabelecida falha e não envia uma notificação de que a conexão estava terminando. Este não é o uso comum hoje.

Extraoficialmente, se pode se referir a uma conexão embrionária, que é uma conexão no processo de estabelecimento.

http://en.wikipedia.org/wiki/Embryonic_connection

Meio fechado é o oposto dessa definição não oficial. É um estado em algum lugar no meio em que os computadores estão derrubando a conexão estabelecida.

Os outros caras fizeram um trabalho bastante decente ao descrever o que realmente são conexões semi-abertas e semi-fechadas , mas a idéia de conexões semi-abertas também é frequentemente pesquisada no contexto de um problema ser deles.

Existem argumentos na internet sobre o que a terminologia "semi-aberta" ou "semi-fechada" deve representar, mas, no que me diz respeito, a terminologia é apenas semântica. Alguns dizem que as conexões "semi-abertas" são um "problema", enquanto "semi-fechadas" são um recurso de design que permite fechar o fluxo de envio fechando o fluxo de envio antes que o download do arquivo termine em um estado semi-fechado ( como os outros usuários descritos).

No entanto, em relação ao outro ... o "problema": é necessário um handshake de 3 vias para abrir uma conexão TCP e um handshake de 4 vias para fechá-la.

O TCP tem uma vulnerabilidade, pois o pacote FIN final enviado a um cliente pode ser potencialmente descartado por roteadores / redes, resultando em uma conexão que está meio aberta quando a intenção real era fechar completamente a conexão. Essas abordagens e similares têm sido tipos populares de ataques de negação de serviço, pois não exigem muita largura de banda, mas potencialmente consomem identificadores, soquetes e threads valiosos, dependendo da implementação do servidor, mas também podem ocorrer no mundo real com frequência crescente, graças às nossas sem fio operadoras sem fio.

Os sistemas operacionais fizeram tentativas de combater ataques DDoS pela metade, limitando o número de conexões semi-abertas / fechadas que podem estar presentes no sistema operacional em um determinado momento e introduzindo períodos máximos de tempo em que as conexões podem permanecer em um estado semi-aberto / fechado. A última vez que verifiquei, pessoalmente, no entanto, o prazo no Windows era bastante alto (2 dias, se bem me lembro).

Essa condição é agravada ainda mais pela natureza opcional dos keep-alives do TCP, que, se totalmente implementados, pretendem ser uma solução em nível de protocolo (em oposição ao nível do aplicativo) para detectar conexões mortas / zumbis. Porém, quando o TCP foi projetado, a largura de banda era consideravelmente mais preciosa do que é agora, e havia preocupações de que os temporizadores obrigatórios para manter o funcionamento do TCP ficassem muito "faladores". Portanto, os keep-alives são opcionais, geralmente não utilizados, e não garantidos para serem transmitidos pelos roteadores de acordo com a RFC1122. Portanto ... mesmo se você ativar o keep-alives na camada TCP na tentativa de detectar / manipular o cenário, poderá descobrir que, à medida que seu tráfego viaja pelo mundo, alguns roteadores estão descartando os pacotes keep-alive ... criando potencialmente OUTRO cenário raro para testar.

As conexões semi-abertas representam um desafio de engenharia para os codificadores que escrevem servidores baseados em TCP, principalmente porque eles podem aparecer acidentalmente de forma aleatória, durante períodos de alta carga ... e normalmente em servidores de produção ... e podem ser difícil perceber nas etapas de teste Alpha / Beta. Na minha experiência, descobri que eles ocorrem em talvez 1 em 40.000 conexões em servidores que lidam com 2,5 milhões de conexões / dia, mas esses números variam dependendo das condições de tráfego e das condições de cada segmento da Internet entre o servidor e o cliente. .

Como engenheiro, pode ser difícil rastrear problemas que ocorrem com pouca frequência e apenas em servidores implantados ao vivo, por isso é importante tentar simular esse estado raro de conexão ao escrever o código do servidor TCP para analisar como o servidor reagirá quando confrontados com esta situação. Se o servidor TCP usar um número estático de threads de trabalho, por exemplo, você poderá encontrar todos eles consumidos por conexões zumbi ao implantar na produção, por exemplo. Se as conexões exigirem muita memória de trabalho, o resultado final poderá parecer semelhante a um vazamento de memória. etc etc.

Sem uma solução de manutenção 100% viável, o TCP deixa para a camada do usuário determinar como as conexões semi-abertas / fechadas são tratadas; portanto, seu código precisa ter um plano / mecanismo para detectar, esgotar o tempo limite e limpar. aumentar os recursos quando essa condição ocorrer ... ou seja, assumindo que este é um protocolo que você inventou e não um dos muitos (ruins) padrões abertos que os programadores normalmente usam. Claro que estou me referindo a protocolos como o HTTP, que são executados exclusivamente por TCP. Esses protocolos são extremamente superestimados na opinião deste programador.

Reconhecendo os pontos fracos do TCP e sua infeliz popularidade na transmissão de tráfego HTTP / Web, empresas inteligentes procuraram um substituto. Por exemplo, o Google experimentou um protocolo chamado QUIC, que transmite HTTP por UDP. Há também um protocolo aberto chamado TSCP. Nenhum desses protocolos teve ampla adoção no entanto.

Como regra, eu construo todos os meus próprios servidores para conversar exclusivamente com meu próprio protocolo baseado em UDP. O UDP é mais complicado do que você imagina, e sinto que estou sempre ajustando para que seja mais rápido, mais inteligente, com menor latência e menor congestionamento ... mas pelo menos não preciso mais lidar com conexões semiabertas; )

Melhor explicação da terminação de conexão TCP

No processo de handshake de 3 vias do TCP, estudamos como a conexão é estabelecida entre cliente e servidor no TCP (Transmission Control Protocol) usando segmentos de bits SYN. Neste artigo, estudaremos como o TCP fecha a conexão entre o Cliente e o Servidor. Aqui também precisamos enviar segmentos de bits para o servidor cujo bit FIN está definido como 1.

11

Como o mecanismo funciona no TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

mais sobre: https://www.geeksforgeeks.org/tcp-connection-termination/

A conexão semifechada é um processo estabelecido quando uma extremidade do servidor e o Cliente pretendem finalizar a conexão. O TCP é um processo orientado à conexão, portanto, cada soquete é aberto para um aplicativo específico. No TCP, não há pressão para encerrar o aplicativo. Assim, o processo orientado à conexão prolonga a terminação com sinais de espera. isso é chamado como meio fechado no TCP (conexão)