我想了解一个拥有大量用户群的网络服务，以便我知道如何处理我正忙着的项目。
我所做的以下陈述可能不正确，但仍然会引出我想问的问题......
请考虑Skype和TeamViewer客户端。似乎两者都保持对各自服务器的持久网络连接。他们使用这些持久连接来启动其他连接。如果客户端在NAT后面，则通过打孔来创建其中一些连接。然后将它们用于直接的点对点通信。
现在根据http://expandedramblings.com/index.php/skype-statistics/，有3亿用户使用Skype，每天有490万活跃用户。我认为这490万用户中的大部分用户很可能会在一天中的大部分时间内运行他们的客户端应用程序。这是与任何给定时间打开的Skype服务器的大量连接。
所以我的问题;这是可行的还是至少可以接受的？我的意思是，在空闲时没有打开网络连接会更好，特别是当有多个连接一次打开服务器时？我能想到的唯一原因是它是正确进行打孔的唯一方法。从技术上讲，这是如何在服务器端实现的？
答案 0 :(得分：1)
这是可行的还是至少可以接受的？
可以肯定的是，你已经提到了两个流行的应用程序，所以它在实践中是非常可行的。
至于可接受的，开始没有互联网权限（例如IETF）曾经说过，即使流量很低，也不能接受长期连接。
此外，唯一重要的组件是保持连接/流状态的网络元素。这些肯定是端点和所谓的中间件，如NAT和防火墙。对于客户端，这只是一个连接，服务器通常由应用程序开发人员（他们做出这个选择）自行调整，所以对于这些，这是可以接受的。对于中间盒来说，它很简单：它们别无选择，它们的设计只适用于所有类型的流程，包括长期持久连接。
我的意思是，在空闲时没有打开网络连接会更好，尤其是当有多个连接一次打开服务器时？
完全没有。首先，这可能是多少＆＃39;因为您需要在每个控制平面呼叫之前建立完整连接，所以速度较慢。如果您的RTT很大或者服务器执行某些复杂的连接代理/重定向以实现负载平衡/本地化，这一点尤为明显。
除此之外，这在历史上会使大量用户难以接听来电。许多ISP通过防火墙阻止/阻止来自互联网的未知传入连接。类似地，如果您位于不支持UPnP或PCP的NAT设备后面，则无法打开端口来监听您的公共IP地址。所以除了打孔之外你还需要它。
我能想到的唯一原因是它是唯一的方法 适当地做打孔。从技术上讲，这是如何实现的 服务器端？
从技术上讲，只要NAT设备保持完整的<src-ip,src-port,dest-ip,dest-port,protocol>（经典的5元组）流匹配，就无法进行适当的打孔。然后你可以做的最好的事情是打孔＆＃39;在同行之间建立代理。
打孔依赖的是NAT流查找仅查看<src-ip,src-port,protocol>上游和<dest-ip,dest-port,protocol>下游进行转换。在这种情况下，两个客户端只是建立与服务器的连接，它们的IP和端口被转换，服务器将其传递给另一个客户端。另一个客户端现在可以开始向已翻译的<ip,port>组合发送数据包，这应该可以正常工作，因为NAT会忽略服务器的IP /端口。但即使特定的NAT会像这样工作，一些安全设备（例如状态防火墙）也可能会检测到会话，并且无论如何都会丢弃它。
现在你宁愿使用UPnP来打开一个端口来监听你的公共IP，如果支持它会容易得多。