我正在尝试建立一个简单的TCP和UDP代理。TCP代理没有问题，但是UDP有点复杂。经典的代理场景是这样的。
1.侦听来自客户端的传入数据包
1.收到数据包后，将其发送到目标（服务器）
1.侦听来自服务器的可能响应数据包
1.将响应数据包发送回客户端
好的，这应该很简单。但是当我尝试使用Synapse或Indy来实现它时，我遇到了一个问题。当我从客户端接收到一个数据包时，我创建了一个内部UDP客户端，将数据包转发到目的地。然后我必须监听来自目的地的可能响应。现在的问题是什么是最好的实现呢？不存在像TCP那样的单一请求/响应。目标可能在一段时间内响应多个应答，或者根本不响应。如果继续侦听一个客户端数据包的响应，则将错过来自此客户端或其他客户端的其他未来数据包。
我正在寻找一个很好的设计来解决这个问题。这里有一个示例通信作为参考。注意在一个点上来自目的地的多个响应
- bind UDP port 40222 on interface 0.0.0.0
- ready
- add 127.0.0.1:4569
127.0.0.1:4569 -> 192.168.90.10:4569
c3 ef 00 00 00 00 00 03 00 00 06 01 0b 02 00 02 ................
02 0a 37 30 30 35 35 35 31 32 31 32 04 0d 4e 6f ..7005551212..No
74 20 41 76 61 69 6c 61 62 6c 65 09 04 00 00 00 t Available.....
08 08 04 00 00 00 08 06 06 31 36 31 34 30 31 01 .........161401.
08 34 31 33 31 33 39 34 37 0d 08 34 31 33 31 33 .41313947..41313
39 34 37 947
192.168.90.10:4569 -> 127.0.0.1:4569
a9 e7 43 ef 00 00 00 09 00 01 06 08 0e 02 00 03 ..C.............
0f 09 34 31 38 32 32 31 37 38 33 06 06 31 36 31 ..418221783..161
34 30 31 401
127.0.0.1:4569 -> 192.168.90.10:4569
c3 ef 29 e7 00 00 00 4f 01 01 06 09 10 20 39 36 ..)....O..... 96
64 66 37 31 32 38 61 62 35 39 39 37 65 36 37 36 df7128ab5997e676
65 62 38 63 61 30 33 39 38 66 33 34 30 65 eb8ca0398f340e
192.168.90.10:4569 -> 127.0.0.1:4569
a9 e7 43 ef 00 00 00 56 01 02 06 07 09 04 00 00 ..C....V........
00 08 ..
127.0.0.1:4569 -> 192.168.90.10:4569
c3 ef 29 e7 00 00 00 56 02 02 06 04 ..)....V....
192.168.90.10:4569 -> 127.0.0.1:4569
a9 e7 43 ef 00 00 02 85 02 02 04 0e ..C.........
192.168.90.10:4569 -> 127.0.0.1:4569
a9 e7 43 ef 00 00 02 96 03 02 02 08 54 54 54 54 ..C.........TTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTT
127.0.0.1:4569 -> 192.168.90.10:4569
c3 ef 29 e7 00 00 02 96 02 04 06 04 ..).........
192.168.90.10:4569 -> 127.0.0.1:4569
29 e7 02 aa 54 54 54 54 54 54 54 54 54 54 54 54 )...TTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 TTTT
192.168.90.10:4569 -> 127.0.0.1:4569
29 e7 02 be 54 54 54 54 54 54 54 54 54 54 54 54 )...TTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 TTTT
192.168.90.10:4569 -> 127.0.0.1:4569
29 e7 02 d2 54 54 54 54 54 54 54 54 54 54 54 54 )...TTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 TTTT
192.168.90.10:4569 -> 127.0.0.1:4569
29 e7 02 e6 54 54 54 54 54 54 54 54 54 54 54 54 )...TTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 TTTT
192.168.90.10:4569 -> 127.0.0.1:4569
29 e7 02 fa 54 54 54 54 54 54 54 54 54 54 54 54 )...TTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT
54 54 54 54 TTTT编辑：
为了记录在案。也许UDP代理只是实现起来太麻烦了，它是可用的。这是一个很大的可能性，虽然理论上它肯定是可行的。但我会尝试只是为了好玩。如果我得到一个稳定的工作解决方案，那么甚至更好。否则我会学习新的东西，承认失败。
我绝不是想要固执，把头穿过墙。我仍然希望有人有一个好主意：）
2条答案
按热度按时间bpzcxfmw1#
不只是代理存在UDP问题-网络设备（如状态防火墙和NAT设备）也会遇到此问题。
通常的处理方法是设置超时。一旦在超时时间内没有观察到被代理的客户端和服务器之间的UDP流量，“连接”就会被断开。当观察到流量时，超时就会被重置。
此外，拥有一个当前代理连接不应该阻止另一个连接同时打开--您的代理应该能够处理这个问题。
tyg4sfes2#
典型的UDP客户端-服务器通信可能如下所示：
您的代理应该只监听端口1000和1001上的数据包。当数据包从端口1000进入时，将其发送到服务器上的端口1000。当数据包到达端口1001时，它来自服务器，需要通过端口1001发送到适当的客户机。UDP在会话或连接管理方面不提供任何功能：这完全取决于您尝试代理的特定UDP协议。如果您从两个不同的客户端接收到UDP数据包，并且从服务器接收到“响应”数据包，那么UDP本身并没有告诉您将该数据包转发到哪里。建立在UDP之上的协议可能有也可能没有某种方式来维护状态。
通用的解决方案是不可能的，您需要阅读RFC，并且需要为您想要支持的每个UDP协议实现特定的助手。