Linux环境下TCP与TCP的网络接口优化

Question

我正在将一个遗留的嵌入式应用程序移植到Linux上。此应用程序使用专有协议通过TCP连接与远程服务器通信。除了特定于应用程序的消息外，该协议还实现了允许TCP和UDP流量通过TCP套接字进行隧道化的消息，以便应用程序能够为第三方客户端(例如嵌入式web服务器)服务。实际上，这是一个定制的VPN解决方案。

由于原始应用程序运行在一个裸金属系统上，因此别无选择，只能将所有附加服务作为应用程序的一部分来实现。

作为移植工作的一部分，我决定使用Linux内核提供的TUN/TAP驱动程序，并将所有封装的TCP和UDP帧路由到TUN接口。然而，这会导致在TCP 带来了与之相关的所有问题上运行TCP。最初的实现没有这个问题，因为隧道没有封装完整的TCIP/IP堆栈。

所以我的问题是，是否可以配置TUN接口，使运行在其中的TCP/IP堆栈不执行任何队列和重传？还是被我继承的定制实现困住了？我只知道TCP在TCP上的重传问题。还有什么其他问题我需要知道这样的解决方案吗？

Answer 1

这是个棘手的局面。我希望您最终能够用更好的设计来替换整个应用程序。

在TUN/TAP级别上，您可以做的事情不多，因为堆栈中的层太低，无法理解重传。

但是，您可以为issue实现做一些事情，以最大限度地缓解重传问题。请注意，我还没有必要自己实现这样的事情，所以可能有一些问题我还没有意识到。不过，我可以从理论上解释这些想法是如何运作的。

问题是，一旦外部TCP连接丢失任何单个数据包，接收端将被阻塞，直到丢失的数据包被重新传输。这将导致内部分组被延迟，这可以被内层检测为分组丢失，从而导致内部层上的重传，这也将不必要地消耗额外带宽。

接收端的

关于如何处理这个问题，我最好的想法是调整接收端，以便部分绕过内核TCP堆栈。您仍然使用内核TCP实现来设置TCP连接，就像在正常情况下一样。但是在接收端，您实际上并不使用从TCP套接字接收到的数据。相反，您将有一个线程或进程，它不断地从TCP套接字读取并丢弃所有接收到的数据。

为了让数据包传递到TUN/TAP接口，您使用了一个原始套接字，该套接字将接收线路上看到的TCP段。这个过程可以在内核中使用过滤器，只看到它关心的数据包，如果内核不能准确地进行过滤，则忽略任何多余的数据包。您的进程必须对TCP重新组装本身做足够的工作，以便提取内部数据包，然后将其传递到TUN/TAP接口。

这里重要的是，当外部数据包丢失时，受其影响的内部数据包将丢失或延迟。您的流程可以在丢失数据包之后继续重新组装数据包，以便提取内部数据包并将其传递给TUN/TAP接口。内部TCP堆栈仍然可以重传几个数据包，但不像外部TCP连接停止时那样多。

有几个注意事项要指出，哪些可能是显而易见的，哪些可能不是显而易见的：

• 如果接收窗口或拥塞窗口填满发送端的TCP，则发送端将停止运行。您无法阻止这种情况，但可以通过确保外部TCP连接支持选择性确认(SACK)来降低风险。
• 根据隧道协议的具体情况，在丢失数据包之后，可能很难甚至不可能准确地识别数据包边界。如果这是您需要实现的协议的情况，您可能会倒霉。我建议修改协议，但我知道这不是你的选择。

发送端的

能够在接收端工作是不够的，因为在发送方的另一个方向是数据包。当数据包丢失时，不能阻止外部TCP连接在接收器上停止运行。

相反，你最好的选择是尽量避免内部连接上不必要的重传。如果可能，可以在内部TCP连接上调整重传计时器。在内部TCP连接重新传输数据包之前，您需要等待至少2次往返时间。

完全禁用内部TCP连接上的重传将不是一个好主意，因为数据包可能在隧道之前或之后丢失，在这种情况下，外部TCP连接将无法重新传输。

一种理论上的可能性，但可能要实现的很多工作是，您使用上面提到的原始套接字来窥探ACK数据包。这样你就可以推断出哪些内部包还在飞行。然后，必须根据飞行中的数据包检查每个内部TCP数据包，如果它是外部TCP连接尚未确认的数据包的重传，则您可以通过内部TCP连接悄然放弃重传。

忽略了问题

目前的应用程序很可能没有这样做。它可能只是做TCP通过TCP部分，并希望最好的。如果到目前为止，这对您来说不是一个问题，那么如果您用相同协议的新实现来替换连接的一端，它可能不会是一个问题。

因此，只要尝试一个已知的次优协议，并且只修复它，如果您发现它会导致真正的问题，它可能会更有效率。当然，这取决于部署重新实现后遇到问题的后果。