究竟什么是reverseHTTP,为什么它会有用?

反向HTTP是客户端与Web服务器保持开放连接的一种方式,这样Web服务器就可以将更新推送到客户端(而不是客户端不断地要求更新)。

以你的经典Twitter客户端为例。

目前,客户端会定期询问Twitter是否有任何更新。如果不是,那就是一个浪费的请求。

使用反向HTTP等技术,一旦你建立了与Twitter的连接,Twitter将能够在更新发生时向你发送更新,从而节省你和Twitter的一些带宽、开销和一点工作量。

反向HTTP通过在服务器通信的浏览器中运行Web服务器来工作。

有类似的技术以更安全、更安全的方式实现了相同的目标。Microsoft.NET通过在客户机和服务器之间建立连接后保持打开(而不是在客户机上运行单独的服务器),在WCF中将这些服务作为双工绑定服务来实现。还有一种技术叫做彗星,它允许同样的事情发生。

只是浏览网页:我的阅读是,而不是,比方说,一个网页浏览器的更新和 牵引 任何新数据,而是Web服务器 推 当客户机上的新数据可用时。

对于需要对任何新数据作出快速响应的应用程序,这将消除重复轮询造成的大量流量。

我已经查看了您链接到的反向HTTP的来源。实施包括两部分:

1. HTTP中继。这个在网站上托管 reversehttp.net . 它只需等待对某个URL(生成的URL)的请求,然后将其转发到一个通道(参见2)。然后它在另一个通道上等待(参见2),并将其转发给请求者。

2. HTTP JavaScript服务器。“客户机服务器”使用Ajax对“服务器服务器服务器”进行轮询,查看是否有任何传入请求。然后,当您在“服务器服务器”上请求了URL,并且它被转发到一个通道时,它将被发送到“客户机服务器”。然后,客户机服务器将在步骤1解析来自请求的原始HTTP请求,创建一个应答(HTTP应答)。这个答案将被发送回“服务器服务器”,该服务器最终位于将实际答复发送回请求者的通道中。

它根本没有在客户机上托管真正的HTTP服务器。这需要一个开放端口80,而大多数人没有。如果你在一个NAT或防火墙后面,如果配置良好,它将以任何方式被阻塞。

我想使用长轮询或Comet比使用这个更好。在客户机上解析HTTP头的开销相当麻烦。

规范描述了一种中继HTTP请求的方法。这将通过设置 Content-Type 向“服务器服务器”发送的任何请求的头 message/http . 我认为有更好的解决方案来代理或中继HTTP请求,不管怎样,只要改变 Host 要中继到的字段,添加一个特殊字段,该字段包含对原始发送方及其遍历路径的一些引用,并将修改后的HTTP请求发送到下一个服务器。然后,接收者简单地将请求发送回来,接收者查找特殊字段,弹出其来源,并在链中进一步传递回复。

从一些演示(例如 this one )看起来像是建的 在顶部 一个标准的Comet风格的界面。实现只是向客户机展示了一个完整的HTTP服务器。

所以在您的javascript中,它“看起来像”您正在托管一个响应请求的Web服务器。 http://reversehttp.net/demo12345/ 但实际上,请求是通过Comet请求从“真正的”Web服务器向在浏览器中运行的javascript客户机进行隧道式传输的,然后再返回。

当这样描述时,它看起来相当低效,但是当您考虑到在大多数情况下,客户机和服务器都将运行在同一台计算机上(因此,只有两台计算机互相交谈过),那么低效性大部分就消失了。