Antes de VOS 17.1, 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 espera se llenaba, 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 solicitud de conexión, suponiendo que la cola de espera no esté llena, la pila STCP envía inmediatamente una respuesta aceptando la conexión. A continuación, la conexión se coloca en la cola de espera. Una vez que la cola de espera se llena, no se envía respuesta a las solicitudes de conexión posteriores. Cuando la aplicación del servidor llama a aceptar, se elimina la conexión que se encuentra al principio de la cola de espera. Este comportamiento es ahora similar al de las pilas TCP en la mayoría de los demás sistemas operativos.
En circunstancias normales, este cambio en la dinámica no provocará ningún cambio apreciable en el comportamiento de 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, es posible que las conexiones permanezcan en la cola de retrasos durante un tiempo prolongado. En estas circunstancias, es posible que se observen algunos comportamientos interesantes.
La siguiente tabla ofrece un resumen de lo que ocurre cuando se coloca una solicitud de conexión en la cola de espera en función de las acciones del cliente. El cliente puede no hacer nada, esperar a que la aplicación del servidor envíe datos, enviar datos o cerrar la conexión con un indicador FIN (final) (cierre normal) o un indicador RST (reinicio) (cierre anormal). Las primeras cuatro columnas se comportan como cabría esperar. La aplicación del servidor llama a accept para obtener un socket de la cola de espera y, a continuación, llama a recv y se bloquea si no hay datos u obtiene datos y/o una indicación de fin de archivo, dependiendo de lo que haya en el socket. Son las últimas cuatro columnas las que hay que examinar más detenidamente.
| No hay nada en el enchufe. | Datos en el socket | FIN en el zócalo | Datos en el socket/
FIN en el zócalo |
Datos en el socket/
FIN en el zócalo/ El socket del cliente ha desaparecido. |
FIN en el zócalo/
El socket del cliente ha desaparecido. |
Datos en el socket/
Restablecer enviado |
Restablecer enviar | ||
| Aceptar | Toma de devoluciones | Toma de devoluciones | Toma de devoluciones | Toma de devoluciones | Toma de devoluciones | Toma de devoluciones | Colgados | Colgados | |
| Primera recepción | Colgados | Datos de devoluciones | Devuelve EOF | Datos de devoluciones | Error de restablecimiento de devoluciones | Devuelve EOF | |||
| Segundo recibo | Colgados | Devuelve EOF |
Datos en el socket / FIN en el socket / Socket del cliente desaparecido
En este escenario, el cliente ha enviado algunos datos y ha cerrado la conexión. La versión 17.1 de STCP confirmará todos los datos que se han enviado, pero no confirmará el FIN hasta que los datos de la cola de recepción se hayan entregado a la aplicación. Como resultado, el FIN del cliente se retransmitirá hasta que expire el temporizador de retransmisión del cliente. Una aplicación cliente bien escrita esperará a que la aplicación servidor cierre su lado de la conexión, de modo que cuando el FIN expire, se notificará un error al cliente. Sin embargo, si la aplicación cliente simplemente cierra el socket sin esperar una indicación del servidor, no sabrá que los datos que envió pueden haberse perdido.
Cuando la aplicación del servidor llama a aceptar un paquete de reconocimiento duplicado, se envía el reconocimiento de los datos, pero no el FIN. Dado que el cliente ha cerrado su socket, responde con un restablecimiento. El restablecimiento borra el socket en el lado del servidor. La aplicación del servidor obtendrá un error de restablecimiento en la primera o segunda llamada a recv, dependiendo del tiempo transcurrido entre la llamada a accept y la llamada a la primera recv. Si ese tiempo es menor que el tiempo 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 establecido una conexión y que se ha abortado.
FIN en el socket / Socket del cliente desaparecido
Esto difiere del escenario anterior en que no hay datos en el socket. 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, incluido su cierre, dará como resultado un restablecimiento, ya que el cliente ya no tiene el socket correspondiente.
Datos en el socket / Restablecimiento enviado
Aquí, el cliente envía algunos datos y, a continuación, envía un restablecimiento. Puede haber muchas razones para el restablecimiento; una de las más comunes es que la aplicación cierre el socket y la pila TCP envíe un restablecimiento inmediatamente o lo envíe después de no obtener una confirmación para el paquete FIN. Esto es similar al primer escenario, pero la pila TCP del cliente envía un restablecimiento antes de cerrar su socket, en lugar de simplemente cerrar el socket. Una vez más, una aplicación cliente bien escrita considerará esto como un error; una aplicación no tan bien escrita no lo considerará como tal.
El socket del servidor se cierra y todos los datos se descartan cuando se recibe el reinicio, por lo que la aplicación del servidor ni siquiera ve una indicación de que se haya establecido una conexión; simplemente se queda esperando otra conexión.
Restablecimiento enviado
Una vez más, el restablecimiento elimina eficazmente el socket de la cola de espera, por lo que la aceptación no lo ve y espera otra solicitud de conexión.
Entonces, ¿qué significa todo esto realmente? En primer lugar, las aplicaciones cliente ahora pueden obtener una respuesta de conexión más rápida, pero es posible que tengan que esperar más tiempo para recibir cualquier tipo de banner o mensaje a nivel de aplicación. Es posible que sea necesario ajustar al alza los tiempos de espera para este banner/mensaje. En segundo lugar, las aplicaciones servidor deben estar preparadas para gestionar un error de la llamada recv inmediatamente después de realizar 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 respuesta deben estar programadas para confirmar que la aplicación del servidor ha cerrado correctamente la conexión, o corren el riesgo de perder datos sin saberlo. Una vez más, esta posibilidad siempre ha existido y no es exclusiva de STCP, pero ahora la probabilidad es ligeramente mayor.