Google, además de comprar empresas y desarrollar nuevos servicios, dedica muchos de sus esfuerzos a la investigación, sobretodo aquella encaminada a aportar mejoras al funcionamiento general de la red. Una de esas investigaciones ha dado sus frutos y presenta una sencilla modificación del protocolo TCP que mejora sustancialmente la velocidad de la red.
De manera general, la investigación propone modificar el tamaño de la ventana TCP, que suele ser de 4 KB. Desde Google se propone modificarlo a 15 KB, ya que han comprobado que el tamaño medio de los elementos de una página web es menor a esa cifra pero mayor de 4 KB.
Con el sistema de 4KB se debe enviar un paquete ACK como confirmación de que se han recibido los paquetes que componen cada una de las partes que forman elementos mayores a esta cantidad. Aunque el sistema actual permite variar el tamaño, la limitación de la primera conexión a 4 KB suele traer consigo envíos y confirmaciones que con el cambio propuesto por Google se llegarían a evitar.
Según la investigación presentada, el aumento de rendimiento en velocidad, con las conexiónes actuales, podría verse aumentado hasta un 12%, mejorando además la latencia de la navegación web. Las pruebas han incluido velocidades estándar tanto de conexiones fijas como móviles.
La única pega que presenta este sistema es que en caso de producirse un error en esa primera conexión, el paquete a reenviar debería ser mayor al que se está enviando actualmente, aunque según se expone en el estudio, con el sistema propuesto el número de retransmisiones innecesarias aumentaría el tráfico un 0,02% en las conexiones estándar y en conexiones lentas un 0,17%.
Google ha enviado esta mejora al IETF, organismo encargado de la estandarización de los protocolos y espera que se revisada, ya que supone una mejoría sin tener que hacer grandes modificaciones en el protocolo TCP, principal novedad respecto a las propuestas llegadas desde otras empresas.
En el paper de la investigación pueden comprobarse con cifras los datos de las pruebas realizadas con los distintos tamaños y las diferentes tasas de conexión. De todas maneras desde Google se deja entrever que en un futuro podría resultar interesante eliminar la limitación de tamaño del paquete inicial y que se adaptará según las necesidades de la información a enviar y la conexión existente.
Vía | Bandaancha
Enlace | Informe de Google
Comentarios
1 Comentario moderado
10Imagino que con una simple actualización del sistema que modificará ese dato en el protocolo bastaría.
n
brillante
No tiene mucho sentido lo explicado en ciertas partes de la noticia, parece haber desconocimiento del funcionamiento del protocolo TCP.
Google lo único que está solicitando es el incremento de la ventana de congestión inicial, ventana que actualmente se inicia a X KB.
Esta ventana únicamente indica el número de paquetes (en bytes) que puede enviar sin obtener confirmación, si un paquete se pierde no se debe de retransmitir toda la ventana, si no hacer uso del sistema de errores que se tenga (go back N o el que se utiliza actualmente, retransmisión selectiva).
Es decir, la perdida de un paquete no implica, para nada, la necesidad de transmitir la ventana, puesto que la ventana no son paquetes, la ventana es el número de bytes que se pueden enviar (normalmente múltiplo del tamaño de un paquete).
¿Que busca Google con este "estándar"? Simplemente que al iniciar la conexión en vez de enviar 4 KB (por ejemplo 4 paquetes de 1 KB, si suponemos que el MSS de 1 paquete TCP es 1 KB) se puedan enviar 15 KB (15 paquetes desde el principio).
¿Y si se pierde el paquete 5 y el resto confirman con retransmisión selectiva? Pues los 14 ACK's recibidos incrementaran en 14 paquetes la ventana de congestión (podemos enviar ahora 14 + 14 paquetes) y retransmitiremos el paquete perdido. Sin embargo el algoritmo de congestión modificará el tamaño de la ventana de congestión (en una implementación sencilla poniendolo a su tamaño inicial (slow start / congestion avoidance) y en otros casos haciendo otras cosas menos drásticas (fast retransmit / fast recovery).
No te entendí absolutamente nada.
+1 XDDDD
Bueno. Intentando entender el paper de Google, la cosa es como tu dices, pero hay un par de datos adicionales que no me quedan claros...
Si se amplía la ventana, se generará una mayor carga sobre el router, que tendrá que soportar una mayor número de ventanas concurrentes (al durar más, no podría desprenderse de ellas tan rapidamente).
Si se pierden paquetes, como tu dices; solo habría que reenviarlos; pero los RTTs requeridos para ello alargarían la ventana por aún más tiempo; y te expondrían a un "timeout".
¿Ando muy perdido? :D
No estudié telecomunicaciones, y estas cuestiones de protocolos son muy complicacadas (vamos, que no entiendo una goma!), pero me quedé con la sensación de que si tu conexión funciona en condiciones (ruido, latencia, etc), el cambio hará que todo funcione mejor; pero si tienes una conexión deficiente (como en mí pais), las cosas funcionarán mucho peor.
-- editado por última vez a las 05:12
Yo tampoco, pero el chaval parece que sabe... :)
Y eso que ese es el primer paso... Google esta implementando todo un nuevo protocolo de transferencia llamado SPDY, realmente es un paso gigantesco para la internet y seria excelente que se implemente muy rapidamente
Creo que solamente funciona con chrome, asi que no gracias.
¿Puedes aportar alguna fuente que verifique tu afirmación?
Saludos.
Llevamos ¿15? años (y los que quedan...) de transición de IPv4 a IPv6, dudo que cualquier cambio en un estándar pueda hacerse tan fácil.
Muy interesante lo que propone Google, lo único que ya sabemos como van estas cosas y por la cantidad de gente que tiene que pasar esto para que se apruebe y acabe llegando a algo, por no hablar de que nunca se acaba imponiendo lo que es mejor.
Para explicarlo de otra forma, la transmisión por ventana deslizante consiste en que el emisor y el receptor acuerdan un tamaño de ventana que son los paquetes que el emisor puede enviar sin esperar confirmación del receptor, el receptor confirma que estos paquetes se han recibido correctamente enviando un ACK. Según el protocolo actual el tamaño inicial es de 4KB y si el receptor responde con ACK para todos los paquetes de la ventana, en la siguiente transmisión esa ventana aumenta. Google propone aumentar ese tamaño de ventana inicial dado que las conexiones actuales son mejores y se supone que esos 4KB se transmiten sin problemas, aparte de que la mayoría de transmisiones actuales supera esos 4KB.
+1 Una respuesta breve y completa ;)
Bueno, de ser necesario los usuarios de Linux tendríamos el cambio hecho en minutos u horas, pero los de windows tedrnáin que esperar quién sabe cuánto. Si cuando Microsoft descubre un error de seguridad en su sistema que podría hacer que sus clientes pierdan muchísimo, prefiere callárselo y esperar meses o hasta años para repararlo, no se qué prioridad darían a un cambio que constituye sólo una mejora de prestaciones.
Sería más probable que lo guardaran para una siguiente versión del sistema operativo. Así podrían promocionar su nuevo sistema como que "mejora la experiencia de internet".
Ya decia yo que era imposible leer 15 comentarios sin que alguno haya mencionado a Microsoft... parece que algunos Linuxeros son medios fanfarrones.
Asi es amigo no podia faltar el amargadito que piensa que todo en el mundo de la tecnologia es malo por culpa de microsoft, gente cerrada del cerebro ni modos, hay que convivir con ellos
Amigo esta mal redactada la primera parte de tu post deberia ser asi:
Google, además de comprar empresas y ( esto esta de mas: desarrollar nuevos servicios), dedica muchos de los esfuerzos de otros a la investigación, sobretodo aquella encaminada a aportar mejoras al funcionamiento general la propia compañia para beneficio economico.
Asi si estaria muy bien redactado jajajajaja.
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect