http - 通过代理的 rtsp over http

Question

我正在尝试使用代理通过 HTTP 获取 RTSP 流。 Real 客户端的行为似乎有点紧张:它会同时尝试所有可能的端口、方法和协议(protocol)。唯一应该工作的是通过端口 80 的 HTTP GET。这样的请求确实发出，并在服务器上接收。以下是请求由代理发送到服务器时的样子:

GET /SmpDsBhgRl83c52ef2-d0f4-41ac-bada-93e5350f67d1?1="1" HTTP/1.0\r\n
Connection: Keep-Alive\r\n
Host: 10.194.5.162:80\r\n
Pragma: no-cache\r\n
User-Agent: RealPlayer G2\r\n
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n
Accept: application/x-rtsp-tunnelled, */*\r\n
ClientID: WinNT_5.1_6.0.14.806_RealPlayer_R41UKD_en-GB_686\r\n
X-Actual-URL: rtsp://10.194.5.162:554/01.mp3\r\n
\r\n

这是服务器的响应:

HTTP/1.0 200 OK\r\n
Server: RMServer 1.0\r\n
Expires: Mon, 18 May 1974 00:00:00 GMT\r\n
Pragma: no-cache\r\n
x-server-ipaddress: 10.194.5.162\r\n
Content-type: audio/x-pn-realaudio\r\n
\r\n

此时从服务器又收到了 4 个字节(它们的值为 48 02 02 00)——就是这样，仅此而已。此时服务器是否期望从客户端得到任何东西，如果是——什么？这种操作模式是否有效？

有关此问题的更多信息:显然，RealPlayer 内置的通过 HTTP 使用 RTSP 的预期机制如下:

1. 尝试连接到以下端口:80、8080、554、7070。(也可以尝试通过在端口 80 上发出 GET http://hostname:port/mediafilename 来直接下载文件，只是为了好玩)
2. 为上述每个端口创建 2 个连接。
3. 向 url http://hostname:port/SmpDsBhgRl 的连接之一发送 GET 请求<guid> ?1="1"，其中 <guid>是的，是新创建的 GUID。向此请求添加一个名为 X-Actual-URL 的 header ，其中包含原始 RTSP URL。
4. 在另一个连接上发送一个 POST 请求到 URL http://hostname:port/SmpDsBhgRl将上面的 GUID 作为请求正文的一部分。发送 32767 字节的 Content-Length header ，以防止代理过早关闭连接。
5. 开始通过 POST 请求向服务器发出命令，并获取相应的 RTSP 流作为 GET 响应的一部分。

奇怪的是(如果以上内容还不够奇怪的话)例如，它可以与 Squid 一起使用，但如果您使用端口 3128 或 8080 中的任何一个，它就不行!不知何故，客户端使用它连接的端口来决定请求的顺序或何时应该取消请求，但无论如何，尽管很难相信，它与代理端口 9090、3129、8081 一起工作，但是不适用于 3128 或 8080。

更新 #2:Here是带有上述行为解释的 RealPlayer 的来源。仍然没有解决方案。

更新 #3:好的，根据上述内容，48 02 02 00 的神奇值很明确:48 == 'h' 用于 HTTP_RESPONSE ，接下来的02就是后面数据的长度，接下来的02叫做POST_NOT_RECEIVED (意味着 POST 请求没有在相应 GET 请求的一秒内到达服务器)。

更新 #4:这种行为(即具有巨大 Content-Length 的 POST 请求)也是 WebEx 使用的 ActiveX 的特征(可能还有许多其他需要开放服务器 channel 的 Web 应用程序)。

Answer 1

首先，您可能需要阅读以下内容:

http://developer.apple.com/quicktime/icefloe/dispatch028.html

其次，需要对 HTTP 请求(GET 和 POST)进行格式化，以便它们得到正确的代理。我见过坚持缓存过多 POST 请求的代理，阻止它到达服务器。这些代理是有问题的，但你对此无能为力，我也无法解决这个问题。大多数情况下，我在防病毒软件中看到过这种情况，这些软件试图对来自浏览器的 POST 请求进行透明代理，以扫描它们以获取社会安全号码等私有(private)信息。您可能遇到了同样的问题。

您有没有使用 McAfee 的防病毒软件？

此外，似乎 Real 发明了自己的方法来做同样的事情，但基本设计非常相似 - GET 用于下游链接，POST 用于上游，带有一些魔法 cookie(在本例中为 GUID)在服务器上将两者捆绑在一起。无论哪种方式，POST 都应该到达服务器，而在您的情况下似乎没有。

顺便说一下，既然问题似乎是 POST 请求没有通过代理，那么除了 GET 之外，如何发布该请求？