Antes de la VOS 17.1, el STCP no aceptaba una solicitud de conexión TCP a menos que la aplicación del servidor hubiera llamado a la función de aceptación. Las solicitudes de conexión se colocaban en una cola de espera, pero no se enviaba ninguna respuesta hasta que una llamada de aceptación eliminaba la solicitud de la cola de espera. Una vez que la cola de atrasos se llenaba, el STCP enviaba un restablecimiento en respuesta a una solicitud de conexión.
A partir de la versión 17.1 la dinámica de las conexiones TCP ha cambiado. Ahora cuando llega una petición de conexión, asumiendo que la cola de espera no se ha llenado, la pila STCP enviará inmediatamente una respuesta aceptando la conexión. La conexión se coloca entonces en la cola de espera. Una vez que la cola de espera llena las peticiones de conexión posteriores no se envía una respuesta. Cuando las llamadas de la aplicación del servidor aceptan la conexión en la parte delantera de la cola de espera se elimina. Este comportamiento es ahora similar a la forma en que se comportan las pilas de TCP en la mayoría de los otros sistemas operativos.
En circunstancias normales, este cambio en la dinámica no provocará ningún cambio notable en la forma en que se comportan las aplicaciones del servidor o del cliente. Sin embargo, si la aplicación del servidor se ralentiza o las conexiones llegan más rápido de lo esperado, las conexiones pueden permanecer en la cola de registro posterior durante un tiempo prolongado. En estas circunstancias, se pueden observar algunos comportamientos interesantes.
La siguiente tabla ofrece un resumen de lo que sucede cuando una solicitud de conexión se coloca en la cola de espera en función de las acciones del cliente. El cliente no puede hacer nada, esperando que la aplicación del servidor envíe datos, puede enviar datos y/o puede cerrar la conexión con un indicador FIN (final) (cierre normal) o RST (restablecimiento) (cierre anormal). Las primeras 4 columnas se comportan como se espera. Las llamadas de la aplicación del servidor aceptan obtener un socket de la cola de atrasos, luego llama a recv y o bien se cuelga si no hay datos, o bien obtiene datos y/o una indicación de fin de archivo, dependiendo de lo que haya en el socket. Son las últimas 4 columnas las que necesitan ser miradas más de cerca.
| Nada en el enchufe | Los datos en el enchufe | FIN en el enchufe | Los datos en el enchufe/
FIN en el enchufe |
Los datos en el enchufe/
FIN en el enchufe/ El enchufe del cliente no está |
FIN en el enchufe/
El enchufe del cliente no está |
Los datos en el enchufe/
Reinicio enviado |
Reiniciar Enviar | ||
| Acepta | Enchufe de retorno | Enchufe de retorno | Enchufe de retorno | Enchufe de retorno | Enchufe de retorno | Enchufe de retorno | Cuelga | Cuelga | |
| Primera recv. | Cuelga | Devuelve los datos | Devuelve EOF | Devuelve los datos | Devuelve el error de restablecimiento | Devuelve EOF | |||
| Segundo Recv | Cuelga | Devuelve EOF |
Datos en el enchufe / FIN en el enchufe / enchufe del cliente desaparecido
En este escenario el cliente ha enviado algunos datos y ha cerrado la conexión. La versión 17.1 del STCP acusará recibo de todos los datos enviados pero no acusará recibo del FIN hasta que los datos de la cola de recepción hayan sido entregados a la aplicación. Como resultado, el FIN del cliente será retransmitido hasta que el temporizador de retransmisión del cliente caduque. Una aplicación cliente bien escrita esperará a que la aplicación del servidor cierre su lado de la conexión para que cuando el FIN se agote el cliente sea notificado de un error. Sin embargo, si la aplicación cliente sólo cierra el socket sin esperar una indicación del servidor, no sabrá que los datos que envió pueden haberse perdido.
Cuando las llamadas de la aplicación del servidor aceptan un paquete de acuse de recibo duplicado, se envía el acuse de recibo de los datos pero no el FIN. Dado que el cliente ha roto su enchufe, responde con un restablecimiento. El reinicio borra el socket del lado del servidor. La aplicación del servidor obtendrá un error de reinicio en la primera o la segunda llamada para recuperar, dependiendo del tiempo entre la llamada para aceptar y la llamada a la primera recuperación. Si ese tiempo es más rápido que el que se tarda en obtener y procesar el paquete de restablecimiento del cliente, la aplicación del servidor verá los datos. En cualquier caso, la aplicación del servidor sabrá que se ha realizado una conexión y que ha sido abortada.
FIN en el enchufe / enchufe del cliente desaparecido
Esto difiere del escenario anterior en que no hay datos en el zócalo. Cuando no hay datos se reconoce el FIN. El accept devuelve el socket y el recv devuelve un EOF indicando que ha recibido el FIN. Cualquier intento de escribir en el socket, incluyendo el cierre del mismo, resultará en la devolución de un reinicio porque el cliente ya no tiene el socket correspondiente.
Datos en el zócalo / Reajuste enviado
Aquí el cliente envía algunos datos y luego envía un restablecimiento. Puede haber muchas razones para el reinicio; una de las más comunes es que la aplicación cierre el socket y la pila TCP envíe un reinicio inmediatamente o que envíe un reinicio después de no obtener un acuse de recibo del paquete FIN. Esto es similar al primer escenario, pero la pila TCP del cliente envía un reinicio antes de derribar su socket en lugar de simplemente derribar el socket. De nuevo, una aplicación cliente bien escrita verá esto como un error; una aplicación no tan bien escrita no verá un error.
El zócalo del servidor es derribado y todos los datos son descartados cuando se recibe el restablecimiento, por lo que la aplicación del servidor ni siquiera ve una indicación de que se ha establecido una conexión; sólo se cuelga esperando otra conexión.
Reinicio enviado
Una vez más, el restablecimiento elimina efectivamente el enchufe de la cola de espera para que el aceptador no lo vea y espere otra solicitud de conexión.
Entonces, ¿qué significa todo esto realmente? En primer lugar, las aplicaciones cliente pueden ahora obtener una respuesta de conexión más rápida pero pueden tener que esperar más tiempo para cualquier tipo de banner o mensaje a nivel de aplicación. Cualquier tiempo de espera para este banner/mensaje puede necesitar ser ajustado hacia arriba. Segundo, las aplicaciones del servidor tienen que estar preparadas para manejar un error de la llamada de recuperación inmediatamente después de hacer una aceptación. Esto siempre ha sido una posibilidad, pero ahora la probabilidad es mayor. Por último, las aplicaciones cliente que envían datos al servidor y no esperan ningún tipo de mensaje de vuelta deben ser escritas para confirmar que la aplicación del servidor ha cerrado correctamente la conexión o se arriesga a perder datos sin saberlo. Una vez más, esta posibilidad siempre ha existido y no es exclusiva de STCP, pero la probabilidad es ahora ligeramente mayor.