Información incorrecta sobre TCP en la que creen los programadores

NetworkManager o networkd

• NetworkManager o networkd

  • El usuario explica por qué cambió a una gestión basada en wpa_supplicant
  • Presenta una lista de creencias erróneas sobre TCP
  • Aborda los malentendidos sobre la confiabilidad de TCP

• Lista de creencias erróneas sobre TCP

  • TCP siempre es confiable
  • TCP es confiable la mayor parte del tiempo
  • TCP no es confiable, pero el emisor y el receptor eventualmente se pondrán de acuerdo sobre los bytes transmitidos
  • Si se construye un protocolo orientado a mensajes sobre TCP, se puede garantizar la confiabilidad
  • Existe algo llamado paquete TCP
  • No existe algo llamado paquete TCP
  • Si falla la conexión con un host remoto, significa que está desconectado
  • El algoritmo de Nagle es bueno
  • El algoritmo de Nagle es malo
  • No hace falta preocuparse por el algoritmo de Nagle
  • TCP maneja la red de forma transparente
  • 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 que no son transparentes para los protocolos estándar son excepcionales
  • TCP está implementado sobre IP

• Explicación

  • Si la conexión se corta mientras un ACK está pendiente, el emisor no puede saber si el segmento fue recibido
  • Se necesitan algoritmos como Paxos o Raft, y se requieren al menos tres nodos
  • Este problema también ocurre en protocolos como SMTP

• Opinión adicional

  • Dos partes pueden llegar a un acuerdo a través de un enlace incierto
  • Pueden ponerse de acuerdo sobre un subconjunto de los bytes transmitidos
  • El conjunto de bytes acordados puede ser 0, y puede aumentar
  • No se necesita Paxos

• Discusión adicional

  • No se puede conocer el rango exacto del conjunto de bytes acordados
  • Las creencias erróneas sobre la transparencia de la red causan problemas
  • Hay redes que bloquean ICMP o descartan paquetes que no entienden
  • Se necesita conocimiento sobre control de congestión

Resumen de GN⁺

• Este artículo trata sobre creencias erróneas acerca de la confiabilidad de TCP e incluye una discusión sobre la elección de herramientas de administración de red
• Explica que los problemas de confiabilidad de TCP requieren algoritmos complejos como Paxos
• Enfatiza que las creencias erróneas sobre la transparencia de la red pueden causar problemas reales
• Presenta varios factores que deben considerarse al elegir herramientas de administración de red

[GN⁺]

Opiniones en Hacker News

• El formato de "falsehoods programmers believe" no es claro y genera confusión

  • No se entiende la discusión sobre si existen o no los paquetes TCP
  • Es un contenido que provoca confusión filosófica

• Sorprende que la conexión se mantenga incluso si desconectas y vuelves a conectar el cable Ethernet

  • TCP está diseñado para seguir funcionando incluso si cae una bomba

• Se puede garantizar entrega "at most once" o "at least once", pero no se puede garantizar entrega "exactly once"

  • Muchos desarrolladores junior piensan que si no hay garantía de entrega "exactly once", entonces es un bug

• Si la conexión se corta mientras un ACK sigue outstanding, el emisor no puede saber si el segmento fue recibido

  • TCP proporciona una tubería bidireccional, y la garantía de entrega exacta es responsabilidad de la aplicación
  • Si una solicitud HTTP se interrumpe antes de recibir respuesta, el emisor debe asumir que la solicitud no llegó al servidor y reintentarlo con una conexión nueva

• Se preguntan si nunca han oído hablar de los códigos de corrección de errores

  • Los frames de TCP o Ethernet incluyen bytes de FEC
  • HTTP sobre TLS usa frames de datos cifrados, y si hay pérdida de datos, no se pueden recibir
  • Gran parte del internet moderno se basa en este paradigma

• Cuando usas tu propio hardware dentro de un centro de datos, puedes ignorar los detalles de bajo nivel

  • El límite de ancho de banda, el límite de RPS de paquetes y la latencia siguen siendo importantes

• Este artículo no es un texto terminado, y el título del envío en HN puede llevar a malentendidos

• Hace recordar un problema que intentaban resolver al trabajar en VKontakte

  • Enviabas un mensaje en el metro, llegaba al servidor, pero la señal se cortaba antes de que llegara la respuesta
  • El cliente lo interpretaba como un fallo en el envío del mensaje y reintentaba
  • Lo resolvieron usando un "ID aleatorio" generado por el cliente
  • Telegram envía todas las respuestas no confirmadas durante la conexión anterior cuando el cliente vuelve a conectarse al servidor

• Mucha gente no entiende que TCP no es una llamada de función

  • Recientemente salió un nuevo limitador de velocidad de TCP en muy mal estado
  • La mayoría de los contenedores probablemente estén sufriendo problemas de Bufferbloat