ReverseHTTP 到底是什么，它为什么有用？答案

【问题标题】：What on earth is ReverseHTTP and why would it be useful?ReverseHTTP 到底是什么，它为什么有用？
【发布时间】：2010-07-01 03:04:36
【问题描述】：

reversehttp.net 几乎无法立即了解什么是 reversehttp 以及如何最好地利用它，这使得该工具似乎很难实际实现。在什么样的环境下，这可能是理想的实时网络数据情况，什么时候不工作，哪些浏览器支持这种方法，具体是什么？

是什么让 reversehttp 与其他 PUSH 实现不同？

感谢任何可以提供帮助并且首先听说过并且知道它是什么的人。

【问题讨论】：

标签： javascript ajax real-time

【解决方案1】：

反向 HTTP 是客户端保持与 Web 服务器的开放连接的一种方式，以便 Web 服务器可以将更新推送到客户端（而不是客户端不断地请求更新）。

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

目前，如果您有任何更新，客户会定期询问 Twitter。如果没有，那是一个浪费的请求。

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

反向 HTTP 的工作原理是在与服务器通信的浏览器中运行 Web 服务器。

有类似的技术可以以更安全、更可靠的方式实现相同的目标。 Microsoft.NET 将这些类型的服务实现为 WCF 中的双工绑定服务，方法是在建立客户端和服务器之间的连接后保持打开状态（而不是在客户端上运行单独的服务器）。还有一种叫做 Comet 的技术可以实现同样的功能。

【讨论】：

这解释了 PUSH，而不是 reversehttp 本身。
通常所说的PUSH其实还是需要网页浏览器来轮询的。如果用户以这种方式感知它，它通常被称为推送。但是，这实际上是技术层面的推动。

【解决方案2】：

我查看了您链接到的反向 HTTP 的来源。实现由两部分组成：

HTTP 中继。这个托管在网站reversehttp.net 上。它只是等待对某个 URL（生成的那个）的请求并将其转发到一个通道（参见 2）。然后它在另一个通道上等待（参见 2），并将其转发给请求者。
HTTP JavaScript 服务器。 “客户端服务器”使用 Ajax 轮询任何传入请求的“服务器服务器”。然后，当您在“服务器服务器”上请求 url 并将其转发到频道时，它将被发送到“客户端服务器”。然后，客户端服务器将从第 1 步的请求中解析出原始 HTTP 请求，创建一个应答（HTTP 应答）。这个答案将被发送回“服务器服务器”，最终在将实际回复发送回请求者的通道中。

它根本不是在客户端上托管一个真正的 HTTP 服务器。这需要一个开放的 80 端口，而大多数人没有。如果您在 NAT 或防火墙后面，如果配置得当，它会以任何方式被阻止。

我想使用长轮询或 Comet 比使用它更好。在客户端解析 HTTP 头的开销相当繁琐。

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

【讨论】：

【解决方案3】：

只是浏览页面：我的理解是，网络浏览器不是轮询更新和拉任何新数据，而是网络服务器推送新数据当它可用时在客户端上。

对于需要快速响应任何新数据的应用程序，这将消除大量由重复轮询引起的流量。

【讨论】：

谢谢，我需要重新表述我的问题。我了解 Comet 和其他人造实时 Web 数据机制，但与 WebSockets、Long Polling 等其他方法相比，它是如何工作的。
@Tom：回应您的编辑，是什么让您认为它有什么独特之处？它与其他解决方案或多或少相同有什么问题吗？
不，没有。但是从我收集到的内容来看，有一个主要区别，那就是让用户和服务器同时扮演客户端和服务器的角色，本质上是双向的（但它是 HTTP，所以不是真的）。我想知道的是这种错觉是如何实现的，它的效果是什么（即兼容性）。
读来，一点也不像是幻觉。客户端基本上运行一个迷你网络服务器，当它需要推送数据时，服务器会向它发出 HTTP 请求。
这对我来说似乎很像一种错觉，因为浏览器是客户端，而不是 Web 服务器（这是有充分理由的，但现在是语义）。如果浏览器真的是服务器，那么从技术上讲，我不能让一个浏览器向另一个浏览器发出请求，初始传输后不需要服务器吗？

【解决方案4】：

通过查看一些演示（例如this one），它看起来像是构建在标准彗星风格的界面之上。该实现只是将自己作为一个完整的 HTTP 服务器呈现给客户端。

因此，在您的 javascript 中，“看起来”您正在托管一个响应“http://reversehttp.net/demo12345/”请求的网络服务器，但实际上，请求是通过彗星请求从“真实”网络服务器传送到javascript 客户端在浏览器中运行并再次返回。

当这样描述时，它似乎效率很低，但是当您考虑到在大多数情况下，客户端和服务器都将在同一台计算机上运行（因此只有两台计算机相互通信），那么主要是效率低下消失。

【讨论】：