Recientemente pasé el feriado bancario de Pascua con mis padres, que viven en una zona muy rural en el Reino Unido. Tienen una conexión a Internet ADSL (terrible), que se ejecuta en varios kilómetros de cobre poco fiable y se interrumpe periódicamente cuando los agricultores cercanos invierten sus tractores en las líneas telefónicas.
Me di cuenta de que su enrutador soltaba repetidamente el pptpapretón de manos y lo renegociaba, interrumpiendo la conexión de manera efectiva. Esto fue frustrante. Entonces, en un intento por evitar volverme loco, le dije que duplicara el margen mínimo aceptable de SNR y el apretón de manos para velocidades más bajas:
$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password:
> sh
BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
# adsl configure --snr 200; exit
Connection closed by foreign host.
Esto mejoró las cosas, y la cosa consiguió una tubería (algo) estable, aunque increíblemente lenta, hacia el mundo exterior:
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...
Aproximadamente en este punto, la vida real intervino y luego pasé varias horas jugando con gatos, mirando gifs de gatos en mi teléfono, en realidad hablando con mi familia , etc. Olvidé que había dejado este proceso de ping en funcionamiento y volví sobre Un día después para golpear ctrl-c.
Las estadísticas resumidas mostradas me conmovieron:
--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms
Como puede ver, el tiempo de respuesta máximo registrado para un paquete ICMP que realiza un pequeño salto transatlántico al servidor DNS de Google es 3600577.732 ms . Eso es casi exactamente una hora , y ciertamente mucho más tiempo que el tiempo de pingespera predeterminado.
¿Cómo puede ser esto? ¿ Es exacto? ¿Qué enrutador retendrá felizmente un paquete durante sesenta minutos antes de enviarlo en su camino? ¿Por qué no se dejó caer este paquete? ¿Es el resultado de un desbordamiento del contador de paquetes de 8 bits combinado con grandes latencias?
Finalmente, me interesaría saber si hay algún código de conducta en el Reino Unido que indique que se espera que las conexiones ADSL de los consumidores tengan menos latencia y una mejor gestión del tráfico que las RFC 1149 y RFC 2549 ;-).
fuente
pingcódigo fuente (de ~ l 761) puedo ver que las zonas horarias se ignoran en el cálculo posterior (gettimeofday(nv, NULL)devuelve microsegundos de época). ¡Realmente tomó una hora!Respuestas:
El paquete ICMP y la respuesta para el ping tienen una longitud de 32 bytes, por lo que parece que para un ping de una hora cada byte tardaba casi un minuto en transmitirse.
Esto solo se explica por un recuento de reintentos de error muy generoso (¿estás haciendo?), Junto con un enrutador muy lento y una espera o reintentos dolorosos para cada byte transmitido.
El Protocolo de Internet (IP) transmite datos por datagramas e intenta no enviar los parciales. Una vez que se inicia la transmisión, esperará por defecto 200 milisegundos para que se agreguen más bytes al datagrama. Pasado ese tiempo, el software / firmware enviará lo que tenga como un datagrama. En el caso del tiempo de ping de una hora, la carga útil del paquete puede haber sido tan pequeña como un byte. Mientras los datos aún estuvieran llegando, la conexión no será terminada por las dos partes participantes.
Lo que puedes hacer :
Puede ser bastante complicado localizar un conmutador problemático, como puede ser con la compañía telefónica, pero el ISP también puede tener sus propios conmutadores. Normalmente, un problema con un interruptor es de área amplia, lo que ayuda a localizar el interruptor que funciona mal. Pero en una zona rural donde no hay demasiados suscriptores que usan ese interruptor, esto podría pasar desapercibido. Si algunos vecinos usan el mismo ISP, intente averiguar cómo es su conexión.
fuente
Veo este caso muy relacionado con la gestión de la congestión de datos, aunque uno muy mal gestionado por el motivo que sea. Según tengo entendido, hay un búfer de paquetes a lo largo del sistema de transmisión, administrado con moderación, lo que causa esta anomalía en los paquetes de solicitud / respuesta de eco ICMP.
Por lo tanto, la combinación de tener una política de gestión de congestión incorrecta con una sesión de ping abierta durante horas puede resultar en un escenario tan extraño.
Más información sobre el manejo de la congestión aquí .
fuente