El protocolo de enlace TCP toma un RTT completo (tiempo de ida y vuelta). RTT es el tiempo que tarda un paquete en llegar del remitente al receptor y viceversa. Un RTT es una gran cantidad de tiempo para el tráfico ‘de corta duración’ y ‘sensible al tiempo’, como el tráfico web; navegación web en el navegador como visitar un sitio web. El rendimiento se degrada aún más si el retardo de propagación es muy alto (por ejemplo, un enlace entre una estación terrestre y un satélite) o si la red móvil es muy lenta. Un RTT no degrada (significativamente) el rendimiento del ‘tráfico elástico’ (como las transferencias de archivos) porque la sobrecarga de un RTT es bastante pequeña en relación con la duración de toda la conexión.
Supongamos que 1 RTT = 86 ms. esto significa que si un usuario está visitando www.xyz.com y se utilizan 86 ms simplemente para establecer la conexión con el servidor de XYZ . Cada vez que el usuario quiera visitar el mismo servidor, se desperdiciarán 86 ms de la misma manera. Este RTT no es un gran problema cuando hay transferencia de archivos o actualizaciones de aplicaciones porque este proceso generalmente toma minutos u horas, unos pocos milisegundos no son nada frente a minutos.
¿Qué es TFO?
TFO significa TCP Fast Open . Es una solución de capa de transporte para evitar un RTT completo entre el cliente y el servidor. Evita el protocolo de enlace TCP-3 para conexiones repetidas. TFO es propuesto por un equipo de Google y descrito en RFC 7413.
En una conexión TCP normal, un RTT se desperdicia en los establecimientos de conexión y luego, a partir del tercer paquete, comienza la comunicación real. TFO dice que el cliente puede enviar requests GET en el primer paquete sin desperdiciar 1 RTT. Pero hay algunas condiciones para hacerlo:
1. No debe ser una conexión ‘nueva’
TFO funciona solo para conexiones repetidas debido al requisito de una cookie criptográfica. Por primera vez, cuando el cliente interactúa con el servidor, debe realizar un protocolo de enlace de 3 vías. En ese apretón de manos, el servidor comparte una cookie criptográfica con el cliente. Para la próxima conexión en adelante, el cliente simplemente lleva a cuestas la solicitud GET y la cookie en el propio paquete SYN. Luego, el servidor autentica al cliente mediante una cookie, acepta la solicitud de conexión y envía los datos en el paquete ACK.
2. La cantidad total de datos superpuestos con el paquete SYN debe estar dentro de los límites especificados.
¿Cuál es el límite especificado? Se puede incorporar un total de 1460 bytes en el paquete para IPv4. Por lo tanto, el tamaño de un segmento se convierte en 1460 B.
3. Solo se pueden enviar ciertos tipos de requests HTTP usando TFO
Se admite la solicitud GET . TFO no admite requests POST porque si permite escribir operaciones en el servidor, los piratas informáticos pueden realizar actividades maliciosas que pueden causar daños graves al servidor.
Funcionamiento de LOF:
Tanto el cliente como el servidor TCP deben ser compatibles con TFO para poder usarlo. Ahora surge la pregunta ¿cómo se informan el cliente y el servidor que son compatibles con TFO? La respuesta está en el encabezado TCP.
El campo ‘Opciones’ en el encabezado TCP se usa para TFO.
- El Cliente TCP lo usa para solicitar una Cookie TFO
- El servidor TCP lo usa para enviar una cookie TFO
En el campo de opciones, la variable Tipo almacena un valor de 32 para la cookie. La longitud de la cookie es de 16 bytes. Cuando un cliente envía el paquete SYN al servidor, establece el Tipo = 32 en el campo de opciones. Cuando el servidor ve el tipo de valor igual a 32, entiende que el cliente admite TFO y requests de cookies. El servidor genera una cookie única y la cifra utilizando la dirección IP del cliente para que cada cliente tenga una cookie única. En las opciones archivadas el servidor envía la cookie al cliente.
Entonces, usando el campo de opciones, el cliente y el servidor se informan mutuamente que admiten TFO y comparten cookies.
¿TFO admite requests GET condicionales?
Debe soportar GET condicional. Las requests GET son básicamente operaciones de solo lectura. Por lo tanto, deben ser permitidos por LOF. No debe ser visto en términos de la demora de tiempo. Las requests GET condicionales se envían básicamente desde el servidor local al servidor central cuando los datos en el servidor local están obsoletos y no se pueden entregar al cliente. En ese caso, los datos nuevos se obtienen del servidor central y se almacenan en caché en el servidor local para atender a los clientes locales.
Línea de comandos de Linux:
Jugando con TFO en el Kernel de Linux usando algunos comandos:
Comprobación de la configuración predeterminada de TFO en el kernel de Linux
$ sysctl net.ipv4.tcp_fastopen
Salida esperada (significa que TFO está habilitado en el Cliente):
$ net.ipv4.tcp_fastopen = 1
Habilitación de TFO si su máquina es un servidor
$ sudo sysctl -w net.ipv4.tcp_fastopen=2
Rendimiento esperado:
$ net.ipv4.tcp_fastopen = 2
Habilitación de TFO si su máquina es tanto un Cliente como un Servidor
$ sudo sysctl -w net.ipv4.tcp_fastopen=3
Rendimiento esperado
$ net.ipv4.tcp_fastopen = 3
Deshabilitar TFO
$ sudo sysctl -w net.ipv4.tcp_fastopen=0
Rendimiento esperado
$ net.ipv4.tcp_fastopen = 0
Publicación traducida automáticamente
Artículo escrito por pintusaini y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA