¿Con qué frecuencia se viola la garantía de pedido de TCP en la práctica para implementaciones comunes de TCP?

Algunas implementaciones de host solían generar rutinariamente paquetes TCP fuera de servicio en algunas circunstancias (desafortunadamente no puedo encontrar los detalles y mi memoria falla, pero creo que el caso que tengo en mente es Linux).

Las redes pueden hacer que los paquetes TCP se entreguen fuera de servicio debido, al menos, a:

• balanceo de carga por paquete sobre múltiples enlaces
• la memoria caché de flujo caduca para el ECMP por flujo (por ejemplo, porque el enrutador está bajo carga) y el siguiente paquete tiene una ruta diferente seleccionada (por ejemplo, debido a la distribución aleatoria de los flujos a las rutas de ECMP)
• oscilaciones de mejor ruta en protocolos de enrutamiento
• Una ruta que falla y se cambia a una nueva ruta, entre las llegadas de paquetes

En resumen, es de esperar una entrega desordenada de paquetes TCP, particularmente en redes más grandes y dinámicas como Internet.

Actualización: Interpreté erróneamente la pregunta sobre la entrega de paquetes por la red al host (es decir, la llegada de paquetes), donde la pregunta realmente es sobre la entrega por parte del host de los datos contenidos a las aplicaciones. Es decir, hay 2 puntos para considerar el pedido de entrega.

Para ser claro:

• La red ofrece 0 garantías de pedido. Esto es inherente a las redes conmutadas por paquete, como las basadas en IP. Por lo tanto, los paquetes pueden llegar al host de destino en cualquier orden.
• TCP, por otro lado, como un servicio en capas sobre IP, * hace * garantías de pedido a las aplicaciones que lo utilizan. TCP existe para proporcionar un flujo de datos ordenado y confiable entre 2 aplicaciones. Los datos regulares * siempre * se entregan en orden a las aplicaciones, como un flujo de bytes, si se entregan.

Tenga en cuenta que TCP también admite el envío de datos “Urgentes” (o fuera de banda), que no está ordenado, y no tiene garantías de pedido en relación con el flujo principal de datos, es decir, es un canal lateral. Casi nada usa datos urgentes de TCP que conozco (ni parece que Internet lo haga).

Aunque otros pueden hablar sobre problemas con implementaciones específicas, dos paquetes TCP enviados en orden desde el mismo host al mismo destino en la misma conexión deben entregarse en orden. El host receptor siempre puede almacenar los mensajes en el búfer hasta que no haya huecos antes de entregar hacia arriba a la aplicación (y si el búfer se llena, puede cerrar la conexión y no violar ninguna condición de seguridad).

Si considera las API comunes a través de las cuales se utiliza TCP, realmente no tendría mucho sentido que los bytes se entreguen fuera de servicio. La lectura de bytes de un socket contiene datos implícitos sobre el orden de los bytes (es decir, el orden en que se leen desde el socket), pero si existiera la posibilidad de entrega fuera de orden, la API tendría que proporcionar información explícita sobre El orden de bytes. Una API orientada a paquetes (como la que se usa comúnmente con UDP) es una forma apropiada de hacer esto.