uPNP/IGD 相对于 SOCKS 的优势?

发布于 2024-07-15 22:15:25 字数 503 浏览 10 评论 0原文

我很好奇为什么它更普遍。 它有更好的 API 吗?

我记得很久以前,当我第一次了解 NAT(我用它来共享拨号 14.4kbps 调制解调器)时,我以为有一天每个家庭都会有一个包含 NAT 的路由器,但“显然”还需要一个 SOCKS 进程来能够打开监听端口。 当宽带开始出现时,很高兴看到 NAT 作为一个常见功能,我认为 SOCKS 将是一个额外的功能,并慢慢变得越来越普遍......但什么也没有! 我必须手动转发端口。 然后出现了uPNP,但是很少有“严肃”的应用程序支持它,主要是P2P共享、游戏和一些IM。

我还没有看到任何家庭路由器包含 SOCKS(当然,除了基于 Linux 的固件升级)。 有人知道为什么吗?

编辑:

正如 Vartec 所指出的,UPnP 是一个零配置和服务发现,而不是代理服务。 现在我知道我指的是 IGD 协议,即家庭路由器中存在的 NAT 遍历服务,并通过 UPnP 发现。 所以,我的问题更合适的是“为什么 IGD/UPnP 而不是 SOCKS?”

I'm curious why is it more pervasive. Does it has a better API?

I remember long ago when i first learned about NAT (i used it for sharing a dialup 14.4kbps modem), i thought that someday every home would have a router with NAT included, but it would "obviously" need also a SOCKS process to be able to open listening ports. When broadband started appearing, it was nice to see NAT as a common feature, and I supposed that SOCKS would be an extra, and slowly become more and more common... but nothing! i had to manually forward ports. then appeared that uPNP, but very few 'serious' applications support it, mostly P2P sharing, games, and some IM.

I still haven't seen any home router to include SOCKS (apart from Linux-based firmware upgrades, of course). does anybody know why??

edit:

as Vartec noted, UPnP is a zeroconf and service discovery, not proxy service. now i know that what i'm referring to is IGD protocol, the NAT traversal service present in home routers, and discovered via UPnP. so, my question would more properly be "Why IGD/UPnP instead of SOCKS?"

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

锦爱 2024-07-22 22:15:25

与 UPnP 相比,SOCKS 有局限性。 一般来说,SOCKS 需要在每个客户端上进行配置,并且对应用程序不透明(Windows 上默认不安装/启用系统范围的套接字 SOCKSification),而 NAT 即使没有 UPnP,也大多透明地工作,并且无需为传出 TCP 套接字进行任何额外的客户端配置和传出 UDP。

带有 UPnP 的 NAT 还比 SOCKS 更好地支持服务器 TCP 套接字:SOCKS 只能通过其 BIND 请求接受单个连接,这对于在 FTP 等协议中接收单个 TCP 连接是可以的,但对于运行需要接受多个连接的服务器来说毫无用处。来自许多客户的联系。 SOCKS 4 在 BIND 请求上也有 2 分钟的超时,但服务器通常无法知道下一个客户端何时尝试连接。

低级 TCP 设置(例如 TCP Nagle、流量类别)也无法跨 SOCKS 代理工作,但它们可以通过 NAT 工作。

SOCKS has limitations compared to UPnP. Generally SOCKS requires configuration on each client and isn't transparent to applications (system-wide socket SOCKSification isn't installed/enabled by default on Windows), while NAT even without UPnP mostly works transparently and without any additional client configuration for outgoing TCP sockets and outgoing UDP.

NAT with UPnP also supports server TCP sockets better than SOCKS: SOCKS can only accept a single connection with its BIND request, which is okay for receiving a single TCP connection in a protocol like FTP, but useless for running a server that needs to accept many connections from many clients. SOCKS 4 also had a 2 minute timeout on the BIND request, but a server generally cannot know when the next client will try to connect.

Low-level TCP settings (eg. TCP Nagle, traffic class) also don't work across the SOCKS proxy, but they work through a NAT.

南冥有猫 2024-07-22 22:15:25

据我所知,UPnP 是本地网络中设备的零配置发现类型协议,而 SOCKS 是隧道代理服务器。 他们完全不同,实际上我看不出他们有什么共同点。

As far as I know, UPnP is zeroconf discovery type of protocol for devices in local networks, while SOCKS is tunnel-proxy server. They are completely different, actually I don't see anything, that they would have in common.

菊凝晚露 2024-07-22 22:15:25

这是两个不同的东西,socks是一种协议,允许您通过代理服务器路由tcp和udp(socks v5),它用于传出连接,路由器与此没有任何关系(除了它们也充当代理)

upnp 的 IGD 是一个“api”,允许您告诉路由器您想要打开一个端口并将其转发到计算机,这是用于传入连接的。我的 linksys 默认启用了 upnp,还有一个我知道的应用程序使用它是 msn Messenger(可能仅用于文件传输)

these are two different things, socks is a protocol that allows you to route tcp and udp (socks v5) through a proxy server and it's for outgoing connections, routers dont have anything to do with this (except they are acting as a proxy too)

the IGD of upnp is an 'api' that allows you to tell your router that you want to open a port and foward it to a computer, this is for incoming connections.. my linksys came with upnp enabled by default and one app i know to use this is msn messenger (maybe only for file transfers)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文