通过代理的http上的rtsp

通过代理的http上的rtsp,http,networking,proxy,streaming,rtsp,Http,Networking,Proxy,Streaming,Rtsp,我正在尝试使用代理通过HTTP获取RTSP流。真正的客户端的行为似乎有点繁忙:它同时尝试所有可能的端口、方法和协议。唯一应该工作的是HTTP通过端口80。这样的请求确实已发出,并在服务器上接收。以下是代理将请求发送到服务器时的外观: 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: n

我正在尝试使用代理通过HTTP获取RTSP流。真正的客户端的行为似乎有点繁忙:它同时尝试所有可能的端口、方法和协议。唯一应该工作的是HTTP通过端口80。这样的请求确实已发出,并在服务器上接收。以下是代理将请求发送到服务器时的外观:

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 00)-仅此而已。服务器在这一点上对客户端有什么期望吗?如果有,是什么?这种操作模式有效吗

关于这个问题的更多信息:显然,通过RealPlayer内置的HTTP使用RTSP的预期机制如下:

  • 尝试连接到以下端口:80、8080、554、7070。 (还可以通过在端口80上发出GET命令,直接下载该文件,只是为了方便起见)
  • 对于上述每个端口,创建2个连接
  • 将GET请求发送到url的其中一个连接
    ?1=“1”,其中
    是新创建的GUID。向该请求添加一个名为X-Actual-URL的头,其中包含原始RTSP URL
  • 将另一个连接上的POST请求发送到具有上述GUID的URL,作为请求正文的一部分。发送32767字节的内容长度标头,以防止代理过早关闭连接
  • 开始通过POST请求向服务器发出命令,并作为get响应的一部分获取相应的RTSP流
  • 奇怪的事情(如果上面还不够奇怪的话)是,例如,它可以与Squid一起工作,但是如果您使用端口3128或8080中的任何一个,它都不能工作!不知何故,客户端使用它所连接的端口来决定请求的顺序或取消请求的时间,但无论如何,令人难以置信的是,它使用代理端口9090、3129、8081,而不是3128或8080

    更新#2:'这是RealPlayer的来源,并解释了上述行为。但仍然没有解决办法

    更新#3:好的,鉴于上述情况,48 02 00的神奇值是明确的:48=='h'代表
    HTTP_响应
    ,下一个02是以下数据的长度,下一个02称为
    POST_NOT_RECEIVED
    (意味着POST请求在对应GET请求的一秒钟内没有到达服务器)

    更新#4:这种行为(即具有巨大内容长度的POST请求)也是WebEx使用的ActiveX(可能还有许多其他需要打开服务器通道的web应用)的特征

  • 查看发出相同的请求但绕过代理(例如,使用Netcat重播您在上面发布的请求)是否会导致在响应正文中传输超过四个字节
  • 查看代理正在接收哪些TCP数据包,例如,通过侦听TCP数据包 运行代理的机器上的流量,例如,使用Wireshark

  • 首先,您可能想阅读以下内容:

    其次,HTTP请求(GET和POST)需要格式化,以便正确地代理它们。我见过一些代理坚持缓存过多的POST请求,阻止它到达服务器。这些代理是有缺陷的,但你对此无能为力,我无法解决这个问题。我在反病毒软件中看到过这种情况,该软件试图对来自浏览器的POST请求进行透明代理,以扫描它们,查找诸如社会安全号码之类的私人信息。你可能遇到了同样的问题

    你有没有可能使用McAfee的防病毒软件

    另外,似乎Real发明了自己做同样事情的方法,但基本设计非常相似——获取下游链接,发布上游链接,并使用一些神奇的cookie(在本例中为GUID)将两者连接在服务器上。无论哪种方式,帖子都应该到达服务器,而在您的情况下,似乎没有


    顺便说一句,既然问题似乎在于POST请求没有通过代理,那么除了GET之外,还可以发布该请求吗?

    服务器的HTTP 200 OK响应有效吗?!我的服务器以前的响应与您的服务器类似,但RealPlayer在打开GET和POST连接后停止响应。然后,我在响应的主体中添加了4802000和Content-Length:4属性,它成功了。。。也许您需要修改HTTP OK响应,并在收到POST连接后发送,而不是在此之前。