¿Qué recursos (libros, páginas web, etc.) recomendaría que:
- explicar las causas de la latencia en redes TCP/IP sobre Ethernet;
- mencione herramientas para buscar cosas que causen latencia (por ejemplo, ciertas entradas en
netstat -s); - sugiera formas de modificar la pila TCP de Linux para reducir la latencia de TCP (Nagle, buffers de socket, etc.).
Lo más cercano que conozco eseste documento, pero es bastante breve.
Alternativamente, puedes responder las preguntas anteriores directamente.
editarPara ser claros, la pregunta no es sólo sobre la latencia "anormal", sino sobre la latencia en general. Además, se trata específicamente de TCP/IP sobre Ethernet y no de otros protocolos (incluso si tienen mejores características de latencia).
Respuesta1
En lo que respecta a los ajustes del kernel para la latencia, uno destaca:
echo 1 > /proc/sys/net/ipv4/tcp_low_latency
Desde eldocumentación:
Si se establece, la pila TCP toma decisiones que prefieren una latencia más baja en lugar de un rendimiento más alto. De forma predeterminada, esta opción no está configurada, lo que significa que se prefiere un mayor rendimiento. Un ejemplo de una aplicación donde se debería cambiar este valor predeterminado sería un clúster informático de Beowulf. Predeterminado: 0
También puede desactivar el algoritmo de Nagle en su aplicación (que almacenará en búfer la salida TCP hasta el tamaño máximo del segmento) con algo como:
#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>
int optval = 1;
int mysock;
void main() {
void errmsg(char *msg) {perror(msg);exit(1);}
if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
errmsg("setsock failed");
}
if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
errmsg("setsock failed");
}
/* Some more code here ... */
close(mysock);
}
El "opuesto" de esta opción es TCP_CORK, que "re-Nagle" paquetes. Sin embargo, tenga cuidado, ya que TCP_NODELAYes posible que no siempre haga lo que espera y, en algunos casos, puede afectar el rendimiento. Por ejemplo, si envía datos en masa, querrá maximizar el rendimiento por paquete, así que configure TCP_CORK. Si tiene una aplicación que requiere interactividad inmediata (o donde la respuesta es mucho mayor que la solicitud, anulando la sobrecarga), use TCP _NODELAY. Por otra parte, este comportamiento es específico de Linux y es probable que BSD sea diferente, por lo queadministrador de advertencias.
Asegúrese de realizar pruebas exhaustivas con su aplicación e infraestructura.
Respuesta2
En mi experiencia, la mayor causa deanormalLa latencia en redes de alta velocidad que de otro modo estarían en buen estado son las ventanas TCP (RFC1323, sección 2) fallas, con un segundo lugar estrechamente relacionado en fallas relacionadas con TCP Delayed Acks (RFC1122 sección 4.2.3.2). Ambos métodos son mejoras de TCP para un mejor manejo de redes de alta velocidad. Cuando se rompen, las velocidades caen a niveles muy lentos. Las fallas en estos casos afectan las transferencias grandes (piense en flujos de respaldo), donde el tráfico pequeño extremadamente transaccional (la transferencia de datos promedio está por debajo del tamaño de MTU y hay MUCHAS ida y vuelta) se verá menos afectado por estas.
Nuevamente, he visto los mayores problemas con estos dos temas cuando dos pilas TCP/IP diferentes están hablando. Como Windows/Linux, 2.4-Linux/2.6-Linux, Windows/NetWare, Linux/BSD. Me gusta me gusta funciona muy, muy bien. Microsoft reescribió la pila TCP/IP de Windows en Server 2008, lo que introdujo problemas de interoperabilidad de Linux que no existían con Server 2003 (creo que están solucionados, pero no estoy 100% seguro de ello).
Los desacuerdos sobre el método exacto de acuses de recibo diferidos o selectivos pueden llevar a casos como este:
192.168.128.5 -> 192.168.128.20: carga útil 1500b, SEQ 1562 192.168.128.5 -> 192.168.128.20: carga útil 1500b, SEQ 9524 [pase de 200 ms] 192.168.128.20 -> 192.168.128.5: ACK 1562 192.168.128.5 -> 192.168.128.20: carga útil de 1500b, SEQ 12025 192.168.128.5 -> 192.168.128.20: carga útil de 1500b, SEQ 13824 [pase de 200 ms] 192.168.128.20 -> 192.168.128.5: ACK 12025
El rendimiento disminuye debido a todos los tiempos de espera de 200 ms (Windows tiene por defecto un temporizador de respuesta retrasada de 200 ms). En este caso, ambas partes de la conversación no pudieron manejar la confirmación retardada de TCP.
Las fallas de ventanas TCP son más difíciles de notar porque su impacto puede ser menos obvio. En casos extremos, la ventana falla por completo y obtienes paquete->ack->paquete->ack->paquete->ack, que es realmente lento cuando se transfiere algo significativamente mayor que aproximadamente 10 KB y ampliará cualquierlatencia fundamentalen el enlace. El modo más difícil de detectar es cuando ambas partes están renegociando continuamente el tamaño de su ventana y una de las partes (el remitente) no respeta la negociación, lo que requiere manejar algunos paquetes antes de que los datos puedan continuar pasando. Este tipo de falla aparece con luces rojas parpadeantes en los rastros de Wireshark, pero se manifiesta como un rendimiento inferior al esperado.
Como mencioné, lo anterior tiende a afectar las grandes transferencias. El tráfico como la transmisión de video o las transmisiones de respaldo pueden ser realmente captados por ellos, así como la descarga simple de archivos muy grandes (como archivos ISO de distribución de Linux). Da la casualidad de que TCP Windowing se diseñó como una forma de solucionar problemas fundamentales de latencia, ya que permite la canalización de datos; no tiene que esperar el tiempo de ida y vuelta para cada paquete enviado; simplemente puede enviar un bloque grande y esperar un único ACK antes de enviar más.
Dicho esto, ciertos patrones de red no se benefician de estas soluciones. Las transferencias pequeñas y altamente transaccionales, como las generadas por bases de datos, son las que más sufrennormallatencia en la línea. Si el RTT es alto, estas cargas de trabajo se verán muy afectadas, mientras que las grandes cargas de trabajo de streaming se verán mucho menos afectadas.
Respuesta3
Hay muchas respuestas para esta pregunta.
Recuerde cómo funciona TCP. El cliente envía SYN, el servidor responde SYN/ACK y el cliente responde ACK. Una vez que el servidor ha recibido el ACK, ahora puede enviar datos. Esto significa que debe esperar 2 veces el tiempo de ida y vuelta (RTT) para enviar el primer bit de datos significativos. Si tiene 500 ms de RTT, obtendrá un retraso de 1 segundo desde el principio. Si las sesiones son de corta duración pero numerosas, esto creará mucha latencia.
Una vez establecida la sesión, el servidor envía unidades de datos que deben ser reconocidas por el cliente. El servidor solo puede enviar una cantidad limitada de datos en estado salvaje antes de requerir el reconocimiento de la primera unidad de datos. Esto también puede crear latencia. Si se pierde una unidad de datos, debe retomar la transmisión desde allí y, por lo tanto, crear una latencia adicional.
A nivel de IP, hay fragmentación (aunque hoy en día es bastante raro). Si envía tramas de 1501 bytes y el otro lado solo admite una MTU de 1500, enviará un paquete IP adicional solo para ese último bit de datos. Esto se puede solucionar utilizando marcos Jumbo.
La mejor manera de aumentar el rendimiento de TCP/IP es reducir la latencia tanto como sea posible y evitar errores de transmisión tanto como sea posible. No conozco ningún ajuste en el kernel, pero estoy seguro de que alguien lo hará.
Respuesta4
Probablemente no sea la respuesta que estás buscando: la principal causa de latencia en una WAN es la velocidad de la luz (¡es demasiado lenta!). Además, los enlaces saturados con un gran búfer en el camino tienden a obtener una latencia impresionante.