Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Ciertas 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 entienden las operaciones TCP/IP.
Los siguientes problemas identifican escenarios comunes en los que la combinación de las opciones de operación TCP/IP y desarrollo de aplicaciones de red da lugar a un rendimiento deficiente.
Aplicaciones pesadas de conexión.
Algunas aplicaciones crean instancias de 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 pesadas de conexión son habituales en gran medida porque son fáciles de crear; la prueba y el control de 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 toma 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 el setockopt función 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.
Send-Send-Receive modelo de programación.
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, los datos máximos en un único datagrama). MSS puede ser un valor muy grande (64K en IPv4 e incluso mayor en IPv6), por lo que no cuenta 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 aplicaciones de propósito especial. Si se superan dos conexiones simultáneas, se desperdician los recursos. Una buena regla es tener hasta cuatro conexiones de corta duración o dos conexiones persistentes por destino.
Temas relacionados