¿Cómo puedo formular la latencia de comunicación en TCP / IP?

Tengo dificultades para derivar un modelo / ecuación matemática para estimar la latencia de ida y vuelta entre dos nodos que se comunican mediante TCP / IP. Los nodos están intercambiando datos basados ​​en el protocolo HTTP. En este modelo, los factores más importantes para estudiar son la distancia física entre dos nodos en la red, el número de saltos intermedios, el ancho de banda, el retraso de procesamiento en cada salto. Busqué en la web pero no pude encontrar nada en este sentido, más bien encontré algo sobre las redes de conmutación de circuitos y el protocolo UDP. ¿Puedo personalizarlos para que quepan en TCP?

Este es un proceso muy complicado, por lo que es extremadamente difícil formular una ecuación que pueda ser útil para predecir con precisión los RTT. En el mejor de los casos, diría que podría crear un modelo que use un montón de promedios para cada etapa, que podría ajustar si "conoce mejor" para una situación particular es lo más cercano posible. Esto es algo que estoy estudiando actualmente para poder decirte lo que sé hasta ahora (desde cero, comenzando en la capa física):

• Vea mis preguntas sobre Electronics SE; Retraso de codificación de Ethernet y la relación con la clasificación de frecuencia del cable y la velocidad de la electricidad (¿propagación de señal?) A través del cobre para el retraso de las comunicaciones . Como usaría velocidades estandarizadas (100Mbps, 1Gbps, 10Gbps, etc.), no trate la fibra o el cobre de manera diferente. El "retraso" en los dos es casi igual, pero el cobre no puede llevar una señal tan lejos, obviamente. Tengo esta pregunta en el sitio de Physics SE, de la cual sí sé la respuesta ahora. Solo necesito encontrar el tiempo para corregirlo, así que vigílelo si está interesado (publicaré algunas preguntas más relacionadas con el uso de fibra de telecomunicaciones para las cuales ahora sé la respuesta cuando tenga la oportunidad )

• Los dispositivos agregarán mucho más retraso al final de un enlace. No hay una forma estándar de decir "oh 2 interruptores a lo largo de una ruta es retraso Xms, 4 interruptores es 2 * Xms, 2 enrutadores es Yms ... etc". Suponiendo que está usando, por ejemplo, 1Gpbs y los dispositivos en la ruta hacia adelante a velocidad de línea, sabemos que es 1000000000bps, por lo que la interfaz física se ejecuta a una velocidad de codificación fija (que va desde 1 nanosegundo por bit hasta el máximo de esquema de codificación de símbolos en uso es, como 10b )

• Hay tres tipos principales de retraso (en la capa física) que debe tener en cuenta y tener en cuenta; Demora de serialización, demora de codificación, demora de propagación (y demora de procesamiento, demora de colas, demora de codificación y decodificación, pero estas están por encima de la capa física, ¡pero es necesario mencionarlas!). Estos están razonablemente bien documentados en Internet, VoIP: un análisis en profundidad , Diapositiva 13 aquí , cargas en Google Scholar y muchos más.

• A medida que avanzamos en la pila de protocolos, trabajaría suponiendo que el MAC de destino está en la tabla de cámaras de cada conmutador, y en la capa IP, el MAC de destino en las tablas ARP. El retraso adicional inducido por estos procesos de descubrimiento solo se produce para el primer paquete en un flujo, por lo que pueden evitarse aumentando los tiempos de espera y enviando ARP gratuitos, etc.

• A medida que llegue a la capa de aplicación, esto se volverá realmente difícil porque esto depende del servidor (por ejemplo) que procese la solicitud, que estará sujeto a un retraso de interrupción. El número de interrupciones requeridas para procesar la solicitud y los cambios de contexto debido a la carga es impredecible.

Me gustaría mucho ayudarlo con su pregunta, lamentablemente esto es todo para lo que tengo tiempo en este momento. Actualizaré esta respuesta tal vez más tarde esta noche o mañana, quería publicar lo que tengo hasta ahora.

Mientras tanto, la mayoría de las personas tienden a trabajar con la cifra para el retraso en una capa física de cobre / fibra de alrededor de 0.6 * c (C = velocidad de la luz). Además, debe pensar en el intercambio de ACK de TCP en cada paquete X, que difiere si está usando SACK, por ejemplo, y si está usando tramas gigantes y / o un tamaño MSS más grande (¡ahora también se debe tener en cuenta MTU!) , si está enviando más ACK intermedios (si el volumen de datos transferidos le interesa). También debe tener en cuenta el infame Producto de retraso de ancho de banda y no cometer la estúpida interpretación errónea que hice de esa página. Empecé a hacer varias calculadoras de datos simples (y muy feas) aquí. De nuevo un trabajo en progreso, intentaré actualizarlos pronto. Planeo agregar una calculadora similar a lo que está tratando de hacer. También he hecho algunas calculadoras de luz y fibra si estás interesado, ¡pero de nuevo, no hay tiempo !, todavía no he podido subirlas. Intentaré ASAP para actualizar esta respuesta un poco más, en los próximos días.

PD: ¡Olvidé mencionar QoS! Si QoS está en juego en cualquier parte del camino, ¡será realmente difícil calcular el RTT!

(Quiero señalar que otros han publicado excelentes respuestas sobre cómo funcionan los retrasos y otros y qué los causa. Pero el OP preguntó sobre el modelado; un modelo básico es simple y solo debe insertar números de ejemplo. Si desea saber por qué los retrasos son lo que son, luego vea las respuestas de todos los demás: ^)

La latencia de la red es simplemente el tiempo de tránsito desde un punto final al otro punto final, que abarca N saltos entre ellos .

Entonces tienes N segmentos (saltos) con N-1 nodos intermedios. Cada nodo tiene un retraso (el efecto acumulativo de varias cosas en ese nodo, como el retraso de la cola, los retrasos de procesamiento, etc.), y cada segmento tiene un retraso de tránsito. En general son 2N - 1 variables independientes. Entonces es seg1 + nodo1 + seg2 ... + nodo (N-1) + segN Un salto, es solo = seg1, dos esperanzas es seg1 + nodo1 + seg2, etc.

Luego tienes que definir qué son todas esas piezas. Por lo tanto, puede construir una red modelo con una red CATV, un enlace satelital, un enlace de fibra óptica, un ethernet, etc. Para cada una de esas tecnologías, debe buscar información de ejemplo.

Los retrasos en el tránsito serían aproximadamente el tamaño de los datos dividido por la velocidad de transmisión del segmento. Si necesita un modelo más preciso, debe agregar el retraso del tiempo de vuelo, aproximadamente la longitud del segmento, dividido por la velocidad del flujo de datos (aproximadamente la velocidad de la luz). Esto ES IMPORTANTE si tiene un enlace satelital involucrado; La subida y bajada del satélite geosíncrono es significativa.

Los retrasos en cada nodo que tendrá que estimar en función de qué equipo está colocando en su modelo.

Si desea la latencia de la aplicación (por ejemplo, el retraso hasta el inicio del flujo de datos de una transferencia FTP), entonces acumula contando cuántas veces entra en juego la latencia de su red. Por ejemplo, un protocolo de enlace TCP de 3 vías agrega el triple de la latencia de la red, y así sucesivamente a lo que ve la aplicación.

Puede estimar la latencia de ida y vuelta tomando una captura de paquetes a cada lado, luego mida el retraso entre las solicitudes que salen de la máquina monitoreada y las respuestas que regresan. Por ejemplo, si marca el momento en que se envió un SYN a la máquina remota, luego marcó el momento en que entró la respuesta SYN + ACK, la diferencia le daría una muy buena aproximación de la latencia TCP de ida y vuelta.

Tenga en cuenta que esto será mayor que la latencia real de la red, y cuánto mayor dependerá de la carga de cada máquina.

El retraso entre dos hosts dependerá de varios factores:

• Retardo de propagación
• Demora de serialización
• Retraso de espera / almacenamiento en búfer

La demora de propagación es el tiempo que les toma físicamente a los paquetes viajar entre dos ubicaciones. La velocidad de la luz en fibra es de alrededor de 200000 km / s. Suecia, donde vivo, tiene alrededor de 1570 km, por lo que serían 7,85 ms, pero en realidad es más porque esa es la distancia a través de la vista de las aves.

El retraso de serialización es la cantidad de tiempo que se necesita para seralizar el paquete a través del medio físico, es decir, las interfaces en el dispositivo de red. Si tiene una conexión de 2 Mbit y está enviando un paquete de 1500 bytes que serían 6 ms para serializar el paquete (12000/2000000).

La demora de espera / almacenamiento en búfer es la cantidad de tiempo que el paquete tiene que permanecer en una cola / búfer antes de enviarse a la interfaz. Dependiendo de la velocidad en la interfaz y de cómo se usan los buffers, esto podría ser el siguiente, nada o un retraso significativo.

Entonces habría algún retraso en los hosts para generar los paquetes y para que la aplicación los maneje. Hay aplicaciones para medir el retraso HTTP. La gente no acepta mucho retraso en los sitios web antes de renunciar a ellos, por lo que es un factor importante.