|
发表于 2008-6-22 23:35:31
|
显示全部楼层
在实际应用的时候,NAT 后的服务器,无论是 TCP 还是 UDP 都有相同的局限:监听等待连接的端口都必须在 NAT 中设置了 Port forward。
现实的问题是,TCP 和 UDP 程序在协议层往往选择了不同方式,导致其在 NAT 后的表现不同。
对于 TCP 程序,因为 accept 很容易返回一个新的 descriptor,所有与这个 client 的通信都在这个 descriptor 上,因此程序逻辑编写很简单。 因此,多数的 TCP 服务器,数据通信使用的端口就是监听端口。这样 NAT 只要设置了这个端口的映射,就没有问题了。
对于 UDP 程序,因为没有连接的概念。因此,程序员只能有两个选择:
第一是自己在 UDP 上实现类似 TCP 的连接,针对每个远端的 IP+端口, 维护一个表,把收到的包按照远端的 IP 地址和端口,分发给相应的对象进行处理。这种方式,在 NAT 后的特性和 TCP 是一致的。
第二是每一个新的连接请求创建一个新的服务端口,然后通知客户端随后的数据通信在这个新的端口上进行。这样的话,因为和 TCP 一样每个客户有一个单独的 descriptor,不需要自己去分发数据包,因此编程逻辑上简洁很多,很多 UDP 服务程序都愿意采用这种方式。出于可靠连接的考虑,程序需要使用的端口数要远大于可能的并发连接数,原因和 TCP 需要实现 2 分钟的 Timewait 类似。但是因为新创建的端口数很多,在 NAT 上很难设置映射。因此,远端的程序就无法连接到这个新创建的端口。因此,这种模式的服务器一般不宜在 NAT 后面使用。 |
|