- Así como NetworkManager puede interpretar una breve inestabilidad de la conexión como “sin red”, parte del software confía más en su propia evaluación del estado que en la recuperación de TCP, pero eso puede ser riesgoso en redes reales
- Las creencias de que “los datos enviados llegan”, “ambos lados eventualmente se ponen de acuerdo sobre los bytes entregados” y “eso puede garantizarse con protocolos de aplicación como HTTP o SMTP” se rompen en ciertas situaciones
- Si la conexión se corta mientras se procesa un ACK, el emisor no puede saber si el segmento fue recibido, y esta limitación no puede resolverse solo con un único stream TCP entre dos partes, como en el problema de los dos generales
- SMTP también trata este problema en RFC 1047 y RFC 2821, y cuando la responsabilidad de entrega cambia de manos existe una zona ambigua donde una falla de conexión puede causar envíos duplicados u omisiones
- Si se descartan las redes extrañas como excepciones o se ignoran detalles de funcionamiento como el algoritmo de Nagle, el control de congestión o el bloqueo de ICMP, es fácil interpretar mal las fallas reales
El problema de dar por sentado el estado de la red antes que TCP
- Un usuario de NetworkManager sufrió en el pasado inestabilidad en la conexión inalámbrica en entornos de roaming entre residencia y campus, y experimentó situaciones donde una pequeña pérdida de paquetes hacía que todo el sistema recibiera el estado de “sin red”
- En ese momento era probable que la red volviera pronto, y la recuperación de TCP habitual, aunque viniera acompañada de un fuerte aumento de latencia, podía seguir siendo transparente para la aplicación
- Este caso se conecta con el problema de que aplicaciones o componentes del sistema interpretan demasiado rápido como falla una interrupción temporal que TCP sí puede manejar
Creencias comunes pero equivocadas sobre TCP
- Las siguientes afirmaciones aparecen con frecuencia al hablar de TCP, pero cada una es, al menos en algunos casos, falsa
- Como TCP es confiable, todos los datos enviados llegan al otro lado
- TCP es mayormente confiable
- Aunque TCP no proporcione confiabilidad en un sentido completo, el emisor y el receptor eventualmente se ponen de acuerdo con exactitud sobre qué bytes fueron transmitidos
- Si se construyen protocolos de aplicación orientados a mensajes como HTTP o SMTP sobre TCP, se pueden obtener esas garantías
- Existe algo llamado paquete TCP
- No existe algo llamado paquete TCP
- Si no se puede conectar a un host remoto conocido, entonces uno está offline
- El algoritmo de Nagle es bueno
- El algoritmo de Nagle es malo
- No hace falta prestar atención al algoritmo de Nagle
- Basta con pensar en TCP como un pipe bidireccional de Unix que atraviesa la red
- Si la red es transparente para TCP, también lo es para IP
- Si la red es transparente para HTTP/1.1, también lo es para TCP
- Las redes extrañas que no son transparentes a protocolos estándar son excepcionales y se pueden ignorar
- TCP está implementado sobre IP
Por qué es difícil acordar con exactitud los bytes entregados
- Los puntos 1 al 4 anteriores, relacionados con la confiabilidad de TCP, están conectados con el problema de los dos generales
- Si la conexión se interrumpe mientras un ACK todavía está siendo procesado, el emisor no tiene forma de confirmar si ese segmento fue recibido
- Esta limitación no desaparece aunque se apilen capas más complejas sobre TCP
- Sobre un único stream TCP entre dos partes no puede construirse esa garantía, y para lograrla se necesita un enfoque similar a Paxos o Raft y al menos 3 nodos
- El mismo tipo de problema aplica no solo a TCP, sino también a servicios de dos partes basados en UDP o IP
La zona gris de la responsabilidad de entrega que deja ver SMTP
- SMTP hace que este problema se vea con claridad porque es un servicio donde ambos lados deben preocuparse explícitamente por si el mensaje fue recibido
- RFC 1047 trata este problema desde la perspectiva de SMTP, y RFC 2821 establece que las implementaciones deben seguir la recomendación central de RFC 1047
- En el ejemplo de SMTP, se distinguen los siguientes estados
- Se puede llegar a un punto en el que ambas partes acuerdan que el correo electrónico fue transmitido del cliente al servidor
- También se puede llegar a un punto en el que ambas partes acuerdan que el servidor asumió la responsabilidad de entregar el correo electrónico
- Pero antes de eso necesariamente se pasa por un estado ambiguo en el que no está claro quién tiene en ese momento la responsabilidad de entrega del correo electrónico
- Si la conexión se corta en ese estado ambiguo, el correo puede duplicarse o perderse
- La especificación de SMTP define qué lado debe preferir duplicar el correo, pero no está claro cuánto se ha probado eso en implementaciones reales
- El objetivo de Paxos y Raft no es tanto alcanzar el estado final en sí, sino evitar este tipo de estado ambiguo
Los límites del conocimiento que quedan en un acuerdo entre dos partes
- Un comentario sostiene que incluso en un enlace no confiable pero no malicioso, dos partes pueden acordar sobre cierto conjunto de bytes que “fueron entregados y ambos saben que eso ocurrió”
- En la discusión complementaria, se resume que una de las partes puede saber que el conjunto acordado incluye al menos los primeros N bytes, pero no puede saber que el conjunto acordado es exactamente los primeros N bytes
- Por lo tanto, puede existir un conjunto de bytes “entregados con certeza y conocido por ambas partes”, pero después de eso queda una zona gris en la que emisor y receptor no pueden fijar con certeza el estado de conocimiento del otro
- Si se pasa por alto esta diferencia, es fácil que aparezcan fallas extrañas en sistemas distribuidos
Las trampas de las redes reales y las capas inferiores
- La creencia de que “las redes extrañas que no son transparentes a protocolos estándar se pueden ignorar” ha causado problemas muchas veces
- Buffer bloat se presenta como un caso en el que los routers rompen los mecanismos de control de congestión
- También pueden ser problemáticas las redes que bloquean ICMP o descartan tráfico cuyo significado no entienden
- La creencia de que “no hace falta entender el control de congestión” también se acerca a una mala comprensión de TCP
- Un subejemplo es la idea de que “si no se obtiene la velocidad deseada, basta con abrir varias conexiones TCP”
Aún no hay comentarios.