为什么浏览器不允许您打开常规连接而不是 Ajax 或 Comet？
如果你想在浏览器和服务器之间打开双向连接，唯一的选择是轮询（锤击服务器），或者使用 comet（很粗糙并且容易断开连接）。
为什么浏览器不让您打开普通 TCP 连接？ 没有这种能力有什么实际好处吗？
If you want to open a two-way connection between the browser and server, the only choice is to poll (hammer the server), or use comet (crufty and prone to disconnects).
Why don't browsers just let you open up a plain TCP connection? Is there any practical benefit to not having this ability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
底层协议HTTP基本上是半双工通信协议，也是无状态的，不支持全双工通信。 然而，随着 HTML 5 websockets 的出现，事情将会发生改变。 Websockets 是 HTML 5 规范中正在考虑的一个新标准。 一旦规范最终确定并且所有浏览器供应商都适应了标准，您就可以使用 websockets 通过浏览器本身建立专用的 TCP 连接。
我们还必须记住，HTTP 基本上是为了传递文档和数据而设计的。 在地理上分散的团队之间共享信息，它本身并不是一种通信协议。
话虽如此，已经有公司构建了一些消息网关来使您能够实现全双工通信。
The underlying protocol HTTP is basically a half duplex communication protocol which is stateless as well and does not supports full duplex communication. However, with HTML 5 websockets things are going to change. Websockets is a new standard which is being considered in HTML 5 specification. Once the specifications have been finalized and all the browser vendors have adapted the standards you can possibly use websockets to establish a dedicated TCP connection through browsers itself.
We must also keep in mind that HTTP was basically designed to deliver documents & share information between the geographically distributed teams and it was not intended to be a communication protocol as such.
Having said that, there are already companies which have built some messaging gateways to enable you to implement full duplex communication.
鉴于此功能可以通过 Flash 有效地使用，因此没有真正的安全原理 - 但现在没有浏览器希望成为第一个实现这样的非标准扩展的浏览器。 此外，没有简单的方法来处理线程，这可能会使套接字的使用变得相当尴尬。
Given that this functionality is effectively available through flash, there's no real security rationale - but these days no browser wants to be the first to implement a non-standard extension like that. Moreover, there's no easy way to do threads, which could make using a socket rather awkward.
防火墙。 非 HTTP 流量通常会被防火墙阻止，因此打开随机 TCP 端口进行通信通常会失败。
Firewalls. Non-HTTP traffic is often blocked by firewalls, so opening up a random TCP port for communication will often fail.
您的问题的答案基本上是否定的，无法在浏览器中打开客户端和服务器之间的双向连接没有任何明显的优势。 无法做到这一点的原因很简单，这不是 Web 浏览器的意图，因为 Web 浏览器是为轮询/检索文档而开发的。 随着富互联网应用程序的出现，拥有这样的功能已经变得令人向往，但以前这从来都不是浏览器的目标。 目前，存在一个空白需要通过最终协议或现有协议的实现来填补，该协议将管理浏览器和服务器之间的双向通信。 现有技术可以在不同程度上模拟这种行为（AJAX、Comet 等），或者可以通过嵌入对象（Java、Flash、IE 中的 ActiveX 控件）来实现，但这些只是围绕虚空的路径，而不是桥梁它。
我们只需等待（或采取行动）标准的编写和实施即可。 很可能，实施实际上会首先出现，我们将遇到一大堆新的跨浏览器兼容性问题:)哦，前沿！
The answer to your question is essentially no, there is no tangible advantage to not being able to open a two-way connection between client and server in a browser. The reason it can't be done is simply that this was not the intention of web browsers, which were developed to poll/retrieve documents. With the advent of Rich Internet Applications, it has become desirable to have such functionality, but previously this had never been the goal of a browser. Currently there is a void to be filled by an eventual protocol or implementation of an existing protocol which will govern two-way communication between a browser and the server. There are existing techniques used to simulate this behavior to different degrees (AJAX, Comet, etc.) or it can be accomplished with embedded objects (Java, Flash, ActiveX Controls in IE) but these are simply paths around the void, not bridges over it.
We will simply have to wait (or act) for the standard to be written and the implementation to follow. More than likely, the implementation will actually come first, and we will have a fistfull of new cross-browser compatibility issues to enjoy :) Oh, the bleeding edge!
多年来，为了提供更丰富的体验，网络的许多方面或元素都被劫持了。 Comet 只是一个例子，其中利用长期连接来允许服务器端推送。 最初，网页只是文本的超链接文档，而不是我们今天经常看到的丰富的应用程序。 对最初想法的攻击和滥用将会继续，直到有一天这些事情变得更加标准化。
Over the years so many aspects or elements of the web have been hijacked in order to deliver richer experiences. Comet is but one example, where long lived connections were exploited in order to allow server side push. Originally web pages were just meant to be hyperlinked documnts of text and not the rich applications we often see today. Hacks and abuses of what the original thought intended will continue, until one day these things become more standardised.