应用程序如何在互联网上监听本地网络？
我想知道像 Skype（一种流行的聊天客户端）这样的应用程序如何在具有一个路由器的本地网络中工作，它如何侦听特定端口？
例如：= 在一个网络中，A和B是两台运行skype的机器，两者的网关都是G1，
现在A和B如何在G1的互联网上拥有相同的IP，但是他们如何确保它们在不同的端口上侦听？他们如何向路由器 G1 请求唯一端口。
我想在linux上做一个简单的文本聊天服务器。如何在两个不同网络中的两台不同计算机之间建立连接？
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
解决您的问题的方法是在网络中的某个位置设置转发服务器。
不同的程序使用不同的方式相互连接。但每个聊天服务器（包括 Skype）都有一个服务器，用于转发有关子网 IP/端口可用性的数据或信息。
有两种类型的客户端：“倾听”客户端和“被动”客户端。监听客户端可以通过路由器端口转发直接访问互联网，而“被动”客户端必须使用额外的技巧来获取外部数据、连接外部服务器或其他端口来监听。
关键是，不是客户端相互连接，而是它们连接到服务器，然后服务器连接回它们以验证它们是否可用，并且，如果其中至少一个没有防火墙，则指示另一个连接到第一个第一，将自己排除在进一步的沟通之外。如果两者都设有防火墙，则必须通过自身转发消息。
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
主机发现
手动发现，客户端 A 知道客户端 B 是谁
通过广播 UDP 发现，许多游戏使用 LAN 玩。客户端将数据包发送到其子网的广播地址。同行可以选择接收此广播并做出响应。缺点是这仅限于当前子网。更通用的 INADDR_BROADCAST (255.255.255.255) 适用于本地链路上的所有子网，但它无法路由，因此无法通过互联网工作（这是 DHCP 自动配置使用的）。
通过中央（Rendezvous）服务器发现。每个单独的客户端都知道服务器的地址，服务器将它们告知彼此。 IRC、VoIP、IM 和大多数“点对点”网络都使用此技术。
沟通
在完成初步发现后，您希望能够互相交谈。在互联网上，这可能会变得棘手。现在大多数人都有自己的路由器并位于 NAT 后面，因此不可能直接连接。
使用 Rendezvous 服务器，您可以使用服务器本身相互通信。客户端 A 告诉服务器要说什么，服务器又告诉客户端 B，因为两个客户端都有到服务器的出站连接。
客户端可以在没有服务器代理的情况下相互通信。这需要 DMZ、端口转发或 UPnP。 DMZ 基本上会将所有端口上的所有传入连接转发到给定的本地 IP。端口转发仅将某些端口转发到本地 IP。 UPnP 更高级一点，客户端请求路由器临时将端口转发给它，然后您通过集合服务器告诉另一个客户端连接的位置。
聊天应用程序实现 解决
您的问题的最简单的解决方案很可能是使用所有客户端都知道的中央服务器，它代理主机发现以及客户端之间可能的通信。如果您希望客户端直接通信，您可以只代理主机发现，然后让 DMz、手动端口转发或 UPnP 完成其余工作。
另一种解决方案是通过上面讨论的 NAT 遍历技术进行直接通信，并进行手动主机发现。
另一种解决方案是使用公共网络服务器并“滥用”其插入内容以相互聊天的能力。
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
您需要一个中央UDP Rendezvous 服务器。
从客户端到服务器的初始连接后，即使有防火墙，UDP 客户端也可以被重定向以直接相互通信。
诀窍是从内部打开 UDP 连接。
替代文本 http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
传统NAT服务器将源地址和端口替换为NAT服务器外部接口的地址和随机端口号。这对于 HTTP 和 SMTP 等简单协议效果很好，但对于需要 NAT 服务器外部接口上的多个响应端口的更复杂协议可能会产生问题。如果没有 NAT 编辑器和类似软件修复的帮助，NAT 服务器也不知道存储在应用层标头的数据部分中的信息。
Windows XP 对这些问题的解决方案是 NAT Traversal，它可以自动允许启用 UPnP 的 NAT 客户端应用程序与 UPnP NAT 设备进行通信。 NAT 遍历提供了允许 UPnP 客户端了解 NAT 服务器的公共 IP 地址并为 UPnP NAT 客户端应用程序协商动态分配的端口映射的方法。
NAT 穿越功能可以内置到任何硬件设备或软件应用程序中。通常会给 NAT 设备带来麻烦但在启用 UPnP 时运行良好的应用程序包括：
多人网络游戏
音视频通讯
终端服务客户端和服务器
点对点文件共享应用程序
当这些应用程序支持 UPnP 时，通过 Windows XP ICS 进行访问使它们能够无缝工作。
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
除非 A 和 B 实际上“监听”对传出请求的响应，否则您的路由器将需要进行配置以将相关端口号转发到相关主机。这不是您可以在代码中请求的内容，而是您需要在路由器本身上配置的内容。
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.