我正在尝试为我自己的远程桌面应用程序寻找仅适用于 Windows（XP 以上）的最佳网络解决方案，并且我有以下要求：
- 首先，应用程序应该可以在默认操作系统网络配置下运行，不需要进一步的代理（或其他任何配置）配置
- 必须具备防火墙意识（也具备一些基本配置）
- 它应该通过 NAT 工作（通信双方可能都在 NAT 后面）
您会建议我采用什么概念？ 您会如何开发（从网络角度）远程桌面应用程序？ 哪种协议和端口可能是最佳选择？
我非常确定端口 80 上的 HTTP 可能满足上述条件，但我觉得它对于远程桌面应用程序来说效率不高。对于我的实现来说，最好使用我自己的基于 TCP 的协议（最好位于某个安全层后面），但我认为这不会穿过防火墙。
最佳候选人寻找我SSH，但我猜它会被许多防火墙默认阻止，还是我错了？
抱歉，这个问题有点儿不专业（而且有点主观），我对网络这方面不太熟悉。
我用的是Synapse 库以供实施。
答案1
80 上的 HTTP 不符合您的限制。事实上，没有什么能满足您的限制：默认操作系统配置已完全锁定，NAT 中没有为端口转发打洞。您可能能够使用 uPnP 控制打开路由器上的相应端口，但这假设您的程序运行在能够执行此操作的级别。
如果您正在为远程桌面进行直接替换（似乎并非如此，但我还是要提一下），您仍然会遇到相同的问题。远程桌面在启用时通常会在本地 Windows 防火墙策略中添加一个例外，并在路由器中手动输入一个漏洞。
哦，当然，企业 NAT 必须手动配置才能允许你的程序。如果双方都是企业 NAT，那就没办法了。
选择 3389 会让您有机会搭载远程桌面防火墙中可能打开的开口，但当然，打开这些开口是因为远程桌面通常在那里运行。
选择分配给特定服务的任何端口都是一件坏事™，因为 a) 人们期望在那里找到该服务并且 b) 它可能实际上已经在那里了。
这让我想到了最后一点：为什么不使用远程桌面？这是一个功能齐全的协议，在这里它可能是最容易避免重复劳动的方法。