我知道像 Skype 这样的 p2p 软件正在为此使用 UDP 打孔。但是，如果其中一个客户端是需要从另一个客户端（TCP 连接而不是 UDP）下载文件的 Web 浏览器怎么办？这种情况有什么技术吗？
我可以拥有一个可以与客户端结婚的中间公共服务器，但我无法承受这些客户端之间的所有流量都通过该服务器。公共服务器只能建立客户端之间的连接，就像 Skype 一样，仅此而已。这必须通过 TCP（更准确地说，HTTP）来让下载客户端成为 Web 浏览器。
不得要求两个客户端在其路由器中设置任何东西或类似的东西。
我打算用 C/C++ 编写这个代码，但我想知道这个想法是否可行。
我之前写了一个关于 P2P 大致如何工作的非常综合的粗略答案，并讨论了各种协议和相应的开源库。你可以在这里阅读。
P2P 的可靠性最终取决于您从客户端编码角度和服务配置（即信令服务器和中继）两个方面投资多少。您可以在没有防火墙支持的情况下满足 UDP 的简单 NAT 穿越。也许再努力一点，您就会获得 TCP 连接。而且您可以“一路走来”并拥有具有 HTTPS 侦听器的中继，以供最难穿越的防火墙后面的客户端使用。
至于你关于防火墙的问题的答案。取决于防火墙的配置方式。许多防火墙只是具有安全性的美化 NAT，可将流量限制到某些端口并阻止未经请求的传入连接。其他的则非常严格，只允许通过代理进行 HTTP/HTTPS 流量。
如果无法直接连接，视频会议应用程序最终将退回到通过 PC 配置的代理服务器模拟 HTTPS 连接到远程中继服务器的端口 443（或 80）。（在某些情况下，远程客户端会尝试监听端口 80 或端口 443，以便直接连接）。
您完全正确地假设让所有客户端都通过中继将是昂贵的维护。如果您的目标是 100% 连接，无论客户端使用哪种类型的防火墙，都必须存在一些中继解决方案。如果您不支持中继解决方案，您可以投入大量资金让直接连接可靠地工作，并且只阻止一小部分客户端。
希望这可以帮助。
PeerConnection是WebRTC的一部分，它在现代浏览器中解决了这个问题。
在引擎盖下，它使用ICE，它是用于 NAT 打孔的RFC 。
对于较旧的浏览器，可以使用 Flash 中的 P2P 支持。