Información independiente
sobre fibra, móvil y ADSL

hosting en interdominios

Regístrate Identifícate
432

Google propone un pequeño cambio en el protocolo TCP que aumentaría un 12% la velocidad de internet

ventanalatencias.png

Google propone modificar la configuración de uno de los principales protocolos sobre el que se sustenta Internet, para adaptarlo a la velocidad de las conexiones de banda ancha actuales. Se trata de un cambio simple, sin ningún coste y que en las pruebas realizadas mejora hasta un 12% la velocidad de navegación en la web.

Uno de los objetivos prioritarios de Google en la actualidad es, además de su cada vez mayor número de servicios, que Internet mejore en cuanto a su rendimiento. La propuesta que van a llevar al organismo estandarizador IETF (Internet Engineering Task Force) es una investigación que gira entorno a ampliar la ventana de congestión inicial al empezar una comunicación empleando el protocolo TCP, con vistas a incrementar la velocidad de navegación al conseguir una rebaja de la latencia.

Pero para entender un poco esto, quizás sea necesario definir muy brevemente, y sin intentar entrar en muchos tecnicismos, qué es esta ventana y para qué sirve.

La ventana TCP

Cuando se establece una conexión entre dos puntos de la red, ambos extremos se comunican la cantidad de datos que pueden enviar y recibir a la vez. Este valor, denominado ventana TCP, es inicialmente de unos 4 KB y va aumentando exponencialmente a medida que transcurre la trasmisión, hasta que una de las partes se congestiona. Cada vez que un extremo recibe una cantidad de información igual al tamaño de la ventana, envía un paquete ACK a la otro para acusar recibo. La otra parte dejará de enviar nuevos datos hasta que no reciba esta confirmación. Pasado un tiempo, si no recibe el paquete ACK, reenviará los datos al entender que se han perdido.

Aumentando el tamaño de la ventana a 15 KB

Actualmente esta ventana se inicializa típicamente en unos 4 KB aproximadamente, y Google quiere elevar esta cifra hasta los 15 KB.

Al incrementar el tamaño mínimo de datos esperados, la comunicación puede ser más rápida ya que, imaginad este supuesto: tenemos que descargar un fichero de 10 KB. Actualmente, al inicializar en 4 KB esta ventana, se enviarían primeramente 4 KB, el receptor tendría que notificar que no ha habido errores, para que luego, con la ventana ya por ejemplo multiplicada por 2 (8 KB), cabrían perfectamente los 6 KB restantes de datos, que volverán a ser notificados para luego finalizar la conexión.

Con un tamaño de ventana de 15 KB como el propuesto por Google, únicamente habría hecho falta un ciclo, ya que todos los datos se habrían enviado en primera instancia.

384 KB, el tamaño medio de una página web

Actualmente el tamaño medio de una página web es de 384 KB, pero se compone por varios elementos (texto, imágenes...), requiriendo normalmente una conexión por cada uno de estos elementos, que individualmente en el 90% de los casos no llegan a estos 15 KB. Lo que hacen los navegadores es enviar varias peticiones en paralelo al servidor para evitar el problema de este "arranque lento", aunque no es eficiente.

Google ha simulado este cambio empleando sus servidores de búsqueda, o para los servicios Maps o iGoogle, en dos contextos distintos. Uno estaba basado en una velocidad de conexión media de 1,2 Mbps y con una presencia testimonial de velocidades por debajo de 256 kbps, que define bastante bien las conexiones fijas. Otro escenario era con un 20% de conexiones por debajo de los 100 kbps y una media de 500 kbps, más adecuado a entornos móviles.

Los resultados arrojan, como principal ventaja, repercusiones positivas en la latencia de las conexiones TCP, mejorando en ambos supuestos de velocidad, aunque algo más en las conexiones más rápidas (11,7% de media contra un 8,7%). Como se ve en la gráfica, el menor valor de latencia se conseguía para una ventana igual a 16 paquetes Ethernet (1500 Bytes cada uno), aunque el que mejor se comportaba en otras pruebas era el de diez paquetes (los ya mencionados 15 KB).

El único punto negativo de este cambio propuesto por el gigante de Internet es el incremento del número de retransmisiones necesarias porque se hayan producido fallos en las comunicaciones, aunque no parece nada preocupante, ya que en un supuesto de conexiones rápidas de los clientes empeora una media de un 0,02% y en conexiones lentas un 0,17%.

Páginas más rápidas

En definitiva, Google espera que este cambio pueda llegar a ser debatido en el IETF pues han comprobado que aumentando el volumen inicial de datos en las conexiones TCP mejora principalmente la latencia de la navegación web sin apenas contrapartidas, lo que significa que las páginas cargarían más rápido.

De este modo, el protocolo se pondría al día respecto a las velocidades actuales que podemos conseguir de conexión a Internet, pero lo mejor que tiene esta modificación respecto a otras propuestas presentadas por otras empresas buscando el mismo objetivo, es que es mucho más simple y barato de implementar, ya que la esencia de la norma original se mantiene, alterando únicamente un parámetro.

Ya hablando de futuro, el objetivo a largo plazo de Google sería eliminar este valor inicial de la ventana para servir a conexiones más rápidas y a páginas web más "pesadas".

Si queréis leer más detenidamente el paper de Google, seguid este enlace [en inglés].

Los comentarios más recientes se muestran primero. Haz click sobre un comentario para desplegar/plegar.
        • BocaDePez BocaDePez
          6

          Por mi que se siga estirando. El día que implemente ipv6…

          Por mi que se siga estirando. El día que implemente ipv6 volveremos a las ip fijas y a la ip asociada a "alguien".

          Ya me imagino a Google y demás haciendo estadísticas con las IPs sin necesidad de que la gente se registre ...

          • Sí, esa es una de las cosas que tampoco me gustan a mí, pero…

            Sí, esa es una de las cosas que tampoco me gustan a mí, pero es que no vamos a poder negarnos.

            Respecto a la privacidad sería ideal vivir en redes "locales" de cada ISP, pero entonces llegarían los famosos proxies, y... claro, eso tampoco es lo mejor.

            • BocaDePez BocaDePez
              6

              Pero eso lo dijeron por lo del calendario maya, si se acaba…

              Pero eso lo dijeron por lo del calendario maya, si se acaba el mundo se acaba ipv4 ... lógico por otra parte.

  • BocaDePez BocaDePez
    6

    Joe, este tema que conozco en profundidad (trabajo de…

    Joe, este tema que conozco en profundidad (trabajo de administrador de redes) me hace darme cuenta de lo que le gusta a la gente hablar sin tener ni puñetera idea de lo que habla.

    Desde uno que dice que lo apliquen también a UDP (que no tiene ventena de transmiión), hasta otro que propone sustituir el TCP por el UDP (dios!), pasando por otro que dice que ampliando la ventana se penalizan las conexiones de pequeño tamaño (como si la ventana hubiera que llenarla antes de enviar el acuse de recibo).

    Lo que me reafirma en mi convencimiento de que no te puedes fiar de lo que leas en Internet de un tema que no conozcas. Si acaso sólo te puedes fiar de ciertos sitios de confianza y aún allí sólo de lo que escriba el dueño del sitio, no de los comentarios de la gente.

    Por favor, no sentenciar, afirmar, proponer, ni criticar si no tenéis una mínima idea de lo que va el tema. Si no se sabe, es muy bueno PREGUNTAR, pero no sentar cátedra.

    • BocaDePez BocaDePez
      6

      Que va, es que aquí saben mucho más que los ingenieros de…

      Que va, es que aquí saben mucho más que los ingenieros de Google

  • BocaDePez BocaDePez
    6

    Joer, para esto no hay que cambiar ningun protocolo... Al…

    Joer, para esto no hay que cambiar ningun protocolo... Al menos en los sistemas operativos de verdad esta opción es configurable:

    proj.sunet.se/E2E/tcptune.html

    No solo eso, sino que hace mucho que ha sido propuesto oficialmente como estandard:

    www.rfc-editor.org/rfc/rfc3390.txt

    Y si se ha desechado, por algo será. Hay que tener en cuenta que solo tiene sentido en enlaces fiables y con gran ancho de banda, y este no es siempre el caso.

    Vaya titular más sensacionalista...

  • Me parece fantástico que se pueda mejorar el rendimiento de…

    Me parece fantástico que se pueda mejorar el rendimiento de las conexiones a Internet por un coste cercano a cero.

    Está claro que TCP/IP necesita un lavado de cara para mejorar la eficiencia de las lineas de banda ancha, y aunque esto afecte negativamente a otras aplicaciones, se entiende que será un mal menor o insignificante comparado con la mejora que ofrecerá en navegación web.

  • 0

    Esto para paginas web tiene sentido, pero por ejemplo para…

    Esto para paginas web tiene sentido, pero por ejemplo para los administradores que tienen que conectarse a Unix via telnet/ssh no, ya que entonces penaliza mucho la conexiones, o los TPV's de datos, o cajeros automaticos.

    Las transmisiones de muy pocos datos existen y son muy numerosas, lo que no quita para que ciertos programas como los navegadores les vendria mucho mejor tener ventanas más grandes.

    • BocaDePez BocaDePez
      18

      La ventana no obliga a transmitir una cantidad de…

      La ventana no obliga a transmitir una cantidad de informacion, es decir no "pierdes" ancho de banda por utilizar una ventana mas grande con datos mas pequeños

    • BocaDePez BocaDePez
      0

      Otra alternativa seria adaptarlo de forma dinámica en función…

      Otra alternativa seria adaptarlo de forma dinámica en función del protocolo, me explico, si abres una ventana con el protocolo HTTP lo aumentas hasta 15kb y si utilizas SSH lo puedes abrir en 4kb. Es algo que podría probarse.

      • BocaDePez BocaDePez
        6

        Hombre si son transmisiones tan pequeñas, no pierden tanto…

        Hombre si son transmisiones tan pequeñas, no pierden tanto tiempo. Y si son muchas, se podrian juntar. Digo sin saber.

        Por otro lado, si comparamos la cantidad de unas y de otras, seguro que las peticiones de mas de 4 kb son la mañoria de muchisimo. El beneficio supero con creces.

        Saludos, ito

    • BocaDePez BocaDePez
      6

      El problema con 4k es el mismo que hay o habra con 15k.…

      El problema con 4k es el mismo que hay o habra con 15k. Imaginad que enviais 16k, hacen falta dos ventanas. Ademas, el tema no es la ventana sino el volumen de datos que se mueve, y por supuesto si la velocida dde conexion "mejora" aumentando la ventana de transmision, la gente vera una ligera mejora (se supone que es para eso esto), y por lo tanto cargaran mas las webs o lo que sea, y volveremos a estar en las mismas.

      Que se dejen de retocar protocolos, etc... de hacer meros parches. Que propongan un protocolo compatible hacia atras con TCP/IP pero que tenga las nuevas mejoras... y punto. Pero claro para eso hay que investigar y gastarse perras.

      Por cierto, ¿ tambien van a aplicar esto al UDP ? Porque a mi mas que una web tarde en cargar 10.5 segundos en lugar de 10, como que no me preocupa demasiado, pero si tener unas altas latencias cuando juego o hago video conferencia. De todas formas, ya sabemos que la ventana no afecta demasiado a esto...

  • no creo que a las operadoras les interese "bailar el agua" de…

    no creo que a las operadoras les interese "bailar el agua" de google... ya estan artitas de la saturacion de red gracias a ellos, pues aunque google tenga razon de la mejora, dudo que la apliquen en una primera instancia...

    • Los operadores no tendrían que tocar nada, más bien…

      Los operadores no tendrían que tocar nada, más bien Microsoft, Apple y cualquier otro desarrollador de OSs, cambiando los parámetros de la pila TCP/IP.

      Vamos, es lo que he entendido yo.

1