Como parte de la ambición de Google por ofrecer servicios cada vez más veloces e intuitivos, el gigante de las búsquedas ha propuesto una serie de cambios en TCP, el Protocolo de Control de Transmisión orientado a conexiones fiables que es base de navegadores y otros protocolos de aplicación como HTTP o FTP.

Cuando se envían datos a través de una conexión TCP, la recepción debe ser reconocida por el extremo receptor antes de que el emisor pueda seguir enviando paquetes. El tiempo necesario para recibir un “acuse de recibo” se rige por el tiempo de ida y vuelta (RTT), que en conexiones con gran ancho de banda y alta latencia es demasiado elevado. Esto significa que tanto equipos cliente como servidores pueden llegar a gastar la mayor parte de su tiempo esperando una señal, en lugar de enviar los paquetes, y eso es precisamente lo que Google pretende: limitar el número de viajes de ida y vuelta requeridos.

En primer lugar, un equipo necesita enviar inicialmente tres paquetes antes de establecer una conexión. La compañía de Mountain View quiere aumentar esta cifra a diez. Con este número de paquetes, un navegador podría ofrecer una petición HTTP a un servidor a tiempo, antes de que se detenga el proceso.

En segundo lugar, las conexiones TCP requieren de un cierto volumen de negociación entre cliente y servidor, lo que requiere inexcusablemente un viaje ida y vuelta antes de que los datos pueden ser enviados. A cambio Google propone modificar el protocolo para que algunos datos pueden ser enviados durante la propia negociación, de modo que el servidor ya los tendría a mano y podría empezar a procesarlos de inmediato.

En tercer lugar, TCP espera un tiempo determinado (el RTO, o tiempo de retransmisión) para recibir la confirmación de la recepción. Si el RTO expira, se asume que los paquetes se han perdido, una medida que asegura que el remitente no se quedará esperando una confirmación que nunca va a llegar antes de volver a intentarlo. Aunque el RTO varía en función de las condiciones de la red, el tiempo de espera suele ser de unos tres segundos. A Google le parecen demasiados, y le gustaría fijar el valor por defecto en sólo un segundo.

Finalmente, Google quiere utilizar un nuevo algoritmo para ajustar el modo en que las conexiones TCP reaccionan a la pérdida de paquetes. Uno de los motivos para que falle la conexión es la congestión de las redes y, al interpretarlo así, el protocolo reacciona automáticamente reduciendo la velocidad a la que se envían los datos. El buscador afirma que esto penaliza a los usuarios y frena demasiado la carga de páginas, y asegura que su alternativa es mejor.

Otros cambios menores se refiren a un mejor sistema para recuperar información en redes móviles, tal y como explica Webmonkey.