Compartir a través de

Problemas específicos de TCP/IP

  • Artículo

Algunas técnicas de programación se encuentran en problemas de rendimiento que están vinculados a la implementación de TCP/IP. Estos problemas de rendimiento no sugieren que TCP/IP sea ineficaz o un cuello de botella de rendimiento; en su lugar, estos problemas se ven cuando no se comprenden las operaciones TCP/IP.

Los siguientes problemas identifican escenarios comunes en los que la combinación de opciones de desarrollo de aplicaciones de red y operación TCP/IP da lugar a un rendimiento deficiente.

  • Aplicaciones pesadas de conexión.

    Algunas aplicaciones crean una nueva conexión TCP para cada transacción. El establecimiento de la conexión TCP tarda tiempo, contribuye a rtT adicionales y está sujeto a un inicio lento. Además, las conexiones cerradas están sujetas a TIME-WAIT, que consume recursos del sistema.

    Las aplicaciones de conexión intensiva suelen ser en gran medida porque son fáciles de crear; probar y controlar errores es muy sencillo. La detección de errores en una conexión persistente puede tardar mucho código y esfuerzo y, por lo tanto, a veces no se completa.

    Solucione esta situación mediante la reutilización de la conexión TCP. Esto puede provocar la serialización a través de la conexión TCP a menos que las transacciones se multiplexen a través de varias conexiones. Si se adopta este enfoque, se debe limitar el número de conexiones a dos y se requieren marcos de capa de aplicación y control avanzado de errores.

  • Búferes de envío de longitud cero y envíos de bloqueo.

    Desactivar el almacenamiento en búfer mediante la función setsockopt para establecer el búfer de envío (SO_SNDBUF) en cero es similar a desactivar el almacenamiento en caché del disco. Al establecer el búfer de envío en cero y emitir envíos de bloqueo, una aplicación tiene una probabilidad de cincuenta por ciento de alcanzar una confirmación retrasada de 200 milisegundos.

    No desactive el almacenamiento en búfer de envío a menos que haya considerado el impacto en todos los entornos de red. Una excepción: los datos de streaming que usan E/S superpuestas deben establecer el búfer de envío en cero.

  • Modelo de programación Send-Send-Receive.

    Estructurar una aplicación para realizar send-send-receive aumenta las posibilidades de encontrar el algoritmo nagle, lo que provoca un retraso de RTT+200 ms. El algoritmo nagle puede encontrarse si el último envío es menor que el tamaño máximo de segmento TCP (MSS, el máximo de datos en un solo datagrama). MSS puede ser un valor muy grande (64K en IPv4 e incluso mayor en IPv6), por lo que no cuente con un MSS normalmente pequeño. Una mejor opción es combinar los dos envíos en un solo envío mediante la función WSASend o memcpy .

  • Gran número de conexiones simultáneas.

    Las conexiones simultáneas no deben superar dos, excepto en las aplicaciones de propósito especial. Si se superan dos conexiones simultáneas, se desperdician recursos. Una buena regla es tener hasta cuatro conexiones de corta duración o dos conexiones persistentes por destino.

Comportamiento de la aplicación

Aplicaciones de Windows Sockets de alto rendimiento

Algoritmo nagle