UDP 和 TCP 数据包从一个路由器到下一个路由器的传输是在 IP 层完成的，并且完全基于该层的信息。这意味着，UDP 和 TCP 之间没有区别，在这两种情况下，路径、拥塞或路由器故障的改变都可能导致数据包丢失、重复或重新排序。

但是，与UDP相反，TCP可以通过确认数据包和重传未确认数据包来处理由于每个数据包中的序列号而导致的重复和重新排序以及数据包丢失。但是这种修复只在通信的端点进行。

其实对方说的有一定道理，虽然大部分是假的。

是真的吗（TCP 连接中的数据包遵循既定路径）？

是的，一般来说，TCP 流中的所有数据包都将遵循相同的路径通过网络——即使存在“菱形”网络，同一流中的所有数据包也将沿菱形的同一侧路由。然而，如果菱形的那一侧出现故障，TCP 流将超时，这不是真的——在这种情况下，它将被重新路由并且它的路径将改变。

为什么交换机会给 TCP 连接这种特殊待遇？

在这里，我将回答为什么交换机和路由器总是尝试沿着“菱形”的同一侧在流中发送数据包，希望能深入了解您的对话者从哪里获得了他们对情况的（有缺陷的）理解。简短的回答是“性能”。

背景：虽然 TCP 确实可以成功处理重新排序的数据包，但在实践中重新排序往往会导致严重的性能问题。例如，如果另一端看到数据包的顺序为“1 2 4 3”，当它看到数据包4时，它会注意到它还没有看到数据包3，并请求另一端重新发送——然后它会接收数据包 3 两次（最初发送的一次加上重新发送的一次）。这会导致带宽浪费（通过不必要地发送两次数据包），并且还会降低连接性能，因为发送方会假设它认为它已经看到的“数据包丢失”是由于拥塞造成的，因此它会减慢发送速度。

因此，大多数质量交换机和路由器会采取相当多的长度来避免数据包重新排序，并且作为其中的一部分，将尝试沿同一路径发送来自同一 TCP 流的所有数据包（以防一条路径的延迟比另一条路径长）。

与其他人所说的相反，即使对于核心路由器也会发生这种情况。如果有多条链路进行负载平衡，路由器将尝试通过同一链路发送来自同一 TCP 流的数据包。虽然这似乎需要跟踪大量的状态，但实际上它可以在不跟踪所有流的情况下完成：路由器获取流的标识符（源/目标 IP 地址，有时还有源/目标端口） ，并将它们组合（散列它们）成一个数字。该编号用于选择在哪个链路上发送数据包。（要举例说明某个供应商实施此功能的情况，请搜索ip cef load-sharing algorithm。）

它不会使网络总体上不那么可靠吗？

是的，当然会，如果网络完全按照您的对话者所描述的那样做 - 所以他们不会那样做。其他人谈到的路径被丢弃的行为以及使用该路径超时的 TCP 连接的行为并不典型：尽管可能将某些产品配置为这样的行为，但通常 TCP 和 UDP 都将开始使用替代方案直接走路线。

当一个链接出现故障时，哈希值将在剩余的链接中重新分配。这将导致 TCP 流改变它们的路径——有时可能会导致一些重新排序——但这通常是可以接受的，因为它偶尔会发生，而不是在每个数据包上发生。

其他相关资料

讨论最初是关于处理 TCP 和 UDP 数据包之间的区别。

事实上，上述所有处理也是为 UDP 数据包完成的：也就是说，来自同一“连接”的 UDP 数据包通常也将始终遵循相同的路径。这是可取的，因为 UDP 数据包通常用于实时媒体流，例如电话 - 如果您的许多语音数据包无序到达，这可能会导致糟糕的音频质量（因为对于电话呼叫而言，大缓冲是非常不受欢迎的，因此接收到的通常会丢弃无序到达的数据包）。

你是对的，不是和你说话的人。

TCP在“客户端”和“服务器”之间建立连接，两者之间的任何东西都只是路径。它不关心流量如何到达那里，只关心它确实到达那里（使用内置的序列号、确认和拥塞避免功能）。在您的菱形示例中，您通过两个中间路由器进行负载共享，您可以只有一个主路径和一个备用路径等。没关系，只要存在 IP 可达性，TCP 就可以处理丢失。