UDP代理实现
[英]UDP Proxy implementation
问题描述
I am trying to build a simple TCP and UDP proxies. 
我正在尝试构建一个简单的TCP和UDP代理。 No problem with the TCP proxy, however the UDP is a little more complex to handle. TCP代理没问题，但是UDP处理起来有点复杂。 The classic proxy scenario would be like this. 经典的代理方案就是这样。
- Listen for incoming packets from clients 侦听来自客户端的传入数据包
- When packet is received send it to destination (server) 收到数据包后，将其发送到目的地（服务器）
- Listen for possible response packets from server 侦听来自服务器的可能的响应数据包
- Send response packets back to the clients 将响应数据包发送回客户端
Ok this should be simple. 好的，这应该很简单。 But when trying to implement this using Synapse or Indy I have a problem. 但是，当尝试使用Synapse或Indy实现此功能时，我遇到了问题。 when I receive a packet from a client, I make an internal UDP client, to forward the packet to the destination. 当我从客户端收到数据包时，我将创建一个内部UDP客户端，以将数据包转发到目标。 Then I have to listen to the possible responses from the destination. 然后，我必须听听目的地的可能回应。 Now the question is what is the best implementation for this? 现在的问题是什么是最佳的实现方案？ There is no single request / response like in TCP. 没有像TCP这样的单个请求/响应。 Destination can response with multiple answers over time, or does not respond at all. 随着时间的推移，目标可以响应多个答案，或者根本不响应。 If I continue to listen for response over one client packet, then I will miss other future packets from this or other clients. 如果我继续侦听一个客户端数据包的响应，那么将来我将错过来自此客户端或其他客户端的其他数据包。
I am looking for a good design to this problem. 我正在为这个问题寻找一个好的设计。 Here is a sample communication for the reference. 这是示例通信，以供参考。 Note the multiple responses from the destination at one point 请注意来自目的地的多个响应
- 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
EDIT: 编辑：
For the record. 作为记录。 Maybe the UDP proxy is just to messy to implement, for it to be usable. UDP代理可能只是杂乱地实现，以使其无法使用。 This is a strong probability, while theoretically it is certainly doable. 这是一个很大的可能性，但是从理论上讲它确实是可行的。 But I will try just for the fun of it. 但我会尽力而为。 If I get a stable working solution, then even better. 如果我能找到稳定的工作解决方案，那就更好了。 Otherwise I will learn something new and admit defeat. 否则，我会学到新的东西并承认失败。
In no way I am trying to be stubborn and going with my head through the wall. 我决不会固执，不愿将头穿过墙壁。 I am still hoping somebody has a good idea :) 我仍然希望有人有一个好主意:)
2 个解决方案
解决方案1
1 2011-03-23 10:56:50
It's not just proxies that have this problem with UDP - network devices such as stateful firewalls and NAT devices run into it too. UDP出现问题的不仅是代理服务器-状态防火墙和NAT设备之类的网络设备也会运行到UDP。
The typical way that it's dealt with is to have a timeout. 处理它的典型方法是超时。 Once no UDP traffic between the proxied client and server has been observed for the length of the timeout, the "connection" is torn down. 一旦在超时时间内未观察到代理客户端与服务器之间的UDP通信，“连接”将被断开。 When traffic is seen, the timeout is reset. 看到流量时，将重置超时。
Also, having one current proxied connection shouldn't prevent another one from being opened simultaneously - your proxy should be able to handle that. 同样，拥有一个当前的代理连接也不应阻止同时打开另一个-您的代理应该能够处理该连接。
解决方案2
0 2011-03-23 10:12:10
A typical UDP client-server communication might look like this: 典型的UDP客户端-服务器通信可能如下所示：
- Client sends UDP packet to port 1000 客户端将UDP数据包发送到端口1000
- Server receives packet and sends back response to port 1001 (or port 1000!) 服务器接收数据包并将响应发送回端口1001（或端口1000！）。
Your proxy should simply listen to packets on both port 1000 and 1001. When a packet gets in on port 1000, send it to port 1000 on the server. 您的代理应该只侦听端口1000和1001上的数据包。当数据包进入端口1000时，将其发送到服务器上的端口1000。 When a packet arrives on port 1001, it's from the server and needs to be sent on port 1001 to the appropriate client. 当数据包到达端口1001时，它来自服务器，需要通过端口1001发送到适当的客户端。 This is pretty much where the fun ends. 这几乎就是乐趣结束的地方。 UDP offers nothing in terms of session or connection management: It all depends on the specific UDP protocol you're trying to proxy. UDP在会话或连接管理方面一无所获：这完全取决于您要代理的特定UDP协议。 If you received UDP packets from 2 different clients, and you receive a "response" packet from the server, there's nothing in UDP itself to tell you where to forward that packet. 如果您从2个不同的客户端接收到UDP数据包，并且从服务器收到了“响应”数据包，则UDP本身没有任何内容可告诉您将数据包转发到何处。 Protocols built on top of UDP might or might not have some way of maintaining state. 建立在UDP之上的协议可能有某种保持状态的方法，也可能没有。
A generic solution is not possible, you get to read the RFCs, and you get to implement specific helpers for each and every UDP protocol you want to support. 通用的解决方案是不可能的，您需要阅读RFC，并为要支持的每个UDP协议实现特定的帮助程序。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.