¿Qué es la conexión TCP medio abierta y la conexión TCP medio cerrada?

Estoy tratando de entender cuál es la diferencia entre la conexión TCP medio abierta y la conexión TCP medio cerrada. ¿Alguien puede decir qué son exactamente?

Esta publicación se expande en conexiones semicerradas. Para conexiones medio abiertas, consulte la descripción correcta de KContreau.

¿Qué son las conexiones semicerradas? O: No es un error, ¡es una característica!

Cada conexión TCP consta de dos medias conexiones que están cerradas independientemente una de la otra. Entonces, si un extremo envía un FIN, entonces el otro extremo es libre de ACUSE que FIN (en lugar de FIN + ACK-ing), lo que indica al extremo que envía FIN que todavía tiene datos para enviar. Por lo tanto, ambos extremos terminan en un estado de transferencia de datos estable que no sea ESTABLECIDO, es decir, FIN_WAIT_2 (para el extremo receptor) y CLOSE_WAIT (para el extremo emisor). Dicha conexión se dice que está medio cerrada y TCP está realmente diseñado para admitir esos escenarios, por lo que las conexiones medio cerradas son una característica de TCP.

La historia de la conexión medio cerrada

Mientras que el RFC 793 solo describe el mecanismo en bruto sin siquiera mencionar el término "medio cerrado", el RFC 1122 explica este asunto en la sección 4.2.2.13. Quizás te preguntes quién demonios necesita esa característica. Los diseñadores de TCP también implementaron el TCP / IP para el sistema Unix y, como todos los usuarios de Unix, adoraron la redirección de E / S. Según W. Stevens (TCP / IP ilustrado, Sección 18.5), el deseo de redirigir los flujos TCP de E / S fue la motivación para introducir la función. Permite al FIN tomar el rol de o ser traducido como EOF. Por lo tanto, es básicamente una característica que le permite crear casualmente una interacción improvisada de estilo de solicitud / respuesta en la capa de aplicación, donde FIN señala "fin de solicitud".

Cuando TCP establece una conexión, se considera garantizado ya que se produce un apretón de manos:

1. La computadora iniciadora envía la solicitud de conexión, enviando un SYN
2. La computadora que responde otorga la solicitud, respondiendo con un SYN-ACK
3. La computadora iniciadora envía un acuse de recibo, respondiendo con un ACK

En ese punto, se establece la conexión y los datos comienzan a fluir. Por el contrario, un paquete UDP no está garantizado y solo se envía con la esperanza de que llegue allí.

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

Oficialmente, de acuerdo con los RFC, una conexión TCP medio abierta es cuando un lado de la conexión establecida se ha bloqueado y no envió una notificación de que la conexión estaba finalizando. Este no es el uso común hoy en día.

Extraoficialmente, puede referirse a una conexión embrionaria, que es una conexión en el proceso de establecimiento.

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

Medio cerrado es lo contrario de esa definición no oficial. Es un estado en algún lugar en el medio donde las computadoras están rompiendo la conexión establecida.

Los otros muchachos hicieron un trabajo bastante decente al describir qué son realmente las conexiones medio abiertas y medio cerradas , pero la idea de las conexiones medio abiertas también se busca a menudo en el contexto de que sean un PROBLEMA.

Hay argumentos en Internet sobre lo que la terminología "medio abierto" o "medio cerrado" debería representar, pero en lo que a mí respecta, la terminología es simplemente semántica. Algunos dicen que las conexiones "medio abiertas" son un "problema", mientras que "medio cerrado" son una característica de diseño que le permite cerrar su flujo de envío cerrando el flujo de envío antes de que finalice la descarga de su archivo en un estado medio cerrado ( como los otros usuarios describieron).

Sin embargo, con respecto al otro ... el "problema": se necesita un protocolo de enlace de 3 vías para abrir una conexión TCP y un protocolo de enlace de 4 vías para cerrarla.

TCP tiene una vulnerabilidad en el sentido de que el paquete FIN final enviado a un cliente puede ser descartado por los enrutadores / redes, lo que da como resultado una conexión que está medio abierta cuando la intención real era cerrar completamente la conexión. Este y otros enfoques similares han sido tipos populares de ataques de denegación de servicio, ya que no requieren una gran cantidad de ancho de banda, pero potencialmente absorben identificadores, enchufes e hilos valiosos dependiendo de la implementación del servidor, pero también pueden ocurrir en el mundo real. con frecuencia creciente gracias a nuestros operadores inalámbricos de mala calidad.

Los sistemas operativos han intentado luchar contra los ataques DDoS medio abiertos al limitar el número de conexiones medio abiertas / cerradas que pueden estar presentes en el sistema operativo en un momento dado e introduciendo períodos máximos de tiempo que las conexiones pueden permanecer en un Estado medio abierto / cerrado. La última vez que revisé, personalmente, sin embargo, el límite de tiempo en Windows fue bastante alto (2 días, si recuerdo).

Esta condición se ve agravada aún más por la naturaleza opcional de TCP keep-alives, que si se implementara por completo estaría destinada como una solución de nivel de protocolo (a diferencia del nivel de aplicación) para detectar conexiones muertas / zombies. Pero, cuando se diseñó TCP, el ancho de banda era considerablemente más valioso de lo que es ahora, y existía la preocupación de que los temporizadores de mantenimiento de vida para TCP serían demasiado "habladores". Por lo tanto, los dispositivos de mantenimiento son opcionales, no se usan generalmente y no se garantiza que sean transmitidos por enrutadores de acuerdo con RFC1122. Por lo tanto ... incluso si habilita la función Keep-Alives en la capa TCP en un intento de detectar / manejar el escenario, puede encontrar que a medida que su tráfico viaja por todo el mundo, algunos enrutadores dejan caer los paquetes Keep-Live ... creando potencialmente OTRO escenario raro para probar.

Las conexiones entreabiertas representan un desafío de ingeniería para los codificadores que escriben servidores basados ​​en TCP, particularmente, porque pueden aparecer involuntariamente al azar, en momentos de alta carga ... y generalmente en servidores de producción ... y pueden ser difícil de notar en las etapas de prueba Alpha / Beta. En mi experiencia, descubrí que ocurren en aproximadamente 1 de cada 40,000 conexiones en servidores que manejan 2.5 millones de conexiones / día, pero esos números variarán dependiendo de las condiciones de tráfico y las condiciones de tráfico de cada tramo de Internet entre su servidor y el cliente .

Como ingeniero, puede ser difícil rastrear problemas que ocurren con poca frecuencia y solo en servidores implementados en vivo, por lo que es importante tratar de simular este raro estado de conexión al escribir el código del servidor TCP para analizar cómo reaccionará su servidor cuando ante esta situación Si su servidor TCP usa un número estático de subprocesos de trabajo, por ejemplo, puede encontrarlos consumidos por conexiones zombies cuando se implementa en producción, por ejemplo. Si las conexiones requieren mucha memoria de trabajo, entonces el resultado final podría parecer similar a una pérdida de memoria. etcétera etcétera.

Sin una solución 100% viable para mantener vivo, TCP lo deja en la capa de usuario para determinar cómo se manejan las conexiones medio abiertas / cerradas, por lo que su código debe tener un plan / mecanismo para detectar, agotar el tiempo y limpiar. aumentar los recursos cuando se produce esta condición ... es decir ... suponiendo que este es un protocolo que usted inventó y no uno de los muchos (malos) estándares abiertos que los programadores suelen utilizar. Por supuesto, me refiero a protocolos como HTTP, que se ejecutan exclusivamente a través de TCP. Estos protocolos están extremadamente sobrevalorados en opinión de este programador.

Al reconocer las debilidades de TCP y su desafortunada popularidad para transmitir el tráfico HTTP / Web, las compañías inteligentes han tratado de buscar un reemplazo. Por ejemplo, Google experimentó con un protocolo llamado QUIC, que transmite HTTP a través de UDP. También hay un protocolo abierto llamado TSCP. Sin embargo, ninguno de esos protocolos ha sido ampliamente adoptado.

Como regla, construyo todos mis propios servidores para hablar exclusivamente en mi propio protocolo basado en UDP. Sin embargo, UDP es más complicado de lo que piensas, y siento que siempre lo estoy ajustando para que sea más rápido, más inteligente, de menor latencia, de menor congestión ... pero al menos ya no tengo que lidiar con conexiones entreabiertas; )

La mejor explicación de la terminación de la conexión TCP

En TCP 3-way Handshake Process, estudiamos cómo se establece la conexión entre el cliente y el servidor en el Protocolo de Control de Transmisión (TCP) utilizando segmentos de bit SYN. En este artículo estudiaremos cómo TCP cierra la conexión entre el Cliente y el Servidor. Aquí también tendremos que enviar segmentos de bits al servidor cuyo bit FIN se establece en 1.

11

Cómo funciona el mecanismo en 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.

más sobre: https://www.geeksforgeeks.org/tcp-connection-termination/

La conexión semicerrada es un proceso que se establece cuando un extremo del servidor y el Cliente tienen la intención de terminar la conexión. TCP es un proceso orientado a la conexión, por lo tanto, cada socket se abre para una aplicación particular. En TCP no hay presión para finalizar la aplicación. Por lo tanto, el proceso orientado a la conexión prolonga la terminación con señales de espera. esto se llama medio cerrado en TCP (conexión)