¿Por qué el tamaño de mi ventana TCP llega a cero cuando uso VIM a través de VPN?

¿Por qué el tamaño de mi ventana TCP llega a cero cuando uso VIM a través de VPN?

Utilizo una computadora portátil Mac OS a través de una red doméstica inalámbrica típica (es decir, de mala calidad) y me conecto al trabajo a través de una VPN. Entro al escritorio Linux (ubuntu) que tengo en mi oficina en el trabajo. (Cuando digo "I ssh": hago clic en un botón que me dice que va a usar 'ssh' y se abre una ventana "Terminal" que inicia sesión en mi escritorio).

Con frecuencia (hasta unas cuantas veces al día), cuando uso 'vim', 'vim' dejará de responder y, uno o dos minutos después, la conexión a mi escritorio se interrumpirá y Terminal me dirá que la conexión está interrumpida. . Con frecuencia tengo varias ventanas de Terminal abiertas en mi escritorio a la vez, y solo se romperá la ventana de Terminal donde estoy usando 'vim'. Las otras ventanas permanecen conectadas y utilizables.

Recientemente estuve usando tcpdump para rastrear los paquetes que van y vienen, y capturé un rastro donde mi sesión de vim se colgó y salió. Un par de minutos antes de la interrupción, llegaron paquetes de mi escritorio con tamaños de ventana cada vez más reducidos hasta que llegamos a cero y la conexión se cortó un poco más tarde.

Casi podía entender esto porque, digamos, ingresé al modo de inserción y comencé a escribir caracteres mientras el escritorio estaba colgado y había llenado la ventana escribiendo mientras mi escritorio estaba arruinado. El tamaño inicial de la ventana era de alrededor de 12.500 y cada carácter que escribo parece generar un paquete de 48 bytes, por lo que alrededor de 250 caracteres podrían llenar un búfer tcp.

Sin embargo, cuando vim se bloquea, es más como si hiciera un avance de página (control-f), luego ingresara al modo de inserción y luego comenzara a escribir algunos caracteres. Se repiten mis comandos y caracteres, lo que indica que vim está recibiendo y procesando los caracteres.

No tengo claro dónde se encuentra el búfer tpc entre el socket y 'vim'. Presumiblemente, un controlador tty en realidad está recogiendo caracteres del búfer tcp, haciéndome eco de ellos, entregándolos a vim y devolviéndome la salida de vim. Pero todas estas acciones sacarían bytes del búfer tcp y el tamaño de la ventana no llegaría a cero.

¿Qué es lo que no entiendo acerca de cómo funciona la pila de software, por qué el tamaño de mi ventana llegaría a cero y cómo puedo solucionar el problema?

Preguntas adicionales:

1) ¿Por qué mi escritorio establece el tamaño de la ventana en alrededor de 12.500 en lugar de alrededor de 64K?

2) Cuando uso tcpdump en Mac, no obtengo ningún resultado si uso las expresiones "hostname", "host ipaddress" o "port 22" (donde 'hostname' y 'ipaddress' se reemplazan con el nombre o la dirección IP de mi escritorio). Si no especifico una de estas expresiones, obtengo muchos resultados, y el resultado contiene claramente el nombre de host, la dirección IP o el puerto que había especificado en la línea de comando. ¿Hay algo especial en Mac donde tcpdump no funciona? ¿Existe una forma estándar de estropear la línea de comando y estoy confundido acerca de lo que le estoy pidiendo a tcpdump que haga?

gracias, cs

Respuesta1

En primer lugar, el tamaño de la ventana TCP no es un búfer, es un umbral de reconocimiento. El nodo que recibe tráfico solo enviará un paquete ACK cada x paquetes. En una red confiable, este número debe ser lo más grande posible para el rendimiento; la desventaja es que si se pierden algunos datos, se debe retransmitir toda la ventana... Esto generalmente hace que la pila TCP reduzca el tamaño de la ventana de manera incremental para evitar tener que retransmitir tantos datos en caso de una futura pérdida de paquetes. Hay un componente relacionado con la memoria disponible (búferes de recepción), pero en los sistemas modernos esto es prácticamente irrelevante.Wikipedia

Es probable que la causa subyacente de este problema sea una mala conexión de red. Las VPN frecuentemente pueden tener una alta latencia y/o pérdida de paquetes, al igual que las redes inalámbricas. Como experimento, ¿el problema mejora o se resuelve si se conecta a través de una línea fija en lugar de una conexión inalámbrica?

información relacionada