6

プロキシを使用して HTTP 経由で RTSP ストリームを取得しようとしています。リアル クライアントの動作は少し多忙のようです。考えられるすべてのポート、メソッド、およびプロトコルを一度に試します。ポート 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。
  2. 上記のポートごとに、2 つの接続を作成します。
  3. URL http://hostname:port/SmpDsBhgRl<guid> ?1="1"への接続の 1 つに GET 要求を送信します。ここ<guid>で、はい、新しく作成された GUID です。このリクエストに、元の RTSP URL を含む X-Actual-URL というヘッダーを追加します。
  4. 要求の本文の一部として上記の GUID を使用して、他の接続で URL http://hostname:port/SmpDsBhgRlに POST 要求を送信します。プロキシが途中で接続を閉じるのを防ぐために、32767 バイトの Content-Length ヘッダーを送信します。
  5. POST リクエストを通じてサーバーへのコマンドの発行を開始し、対応する RTSP ストリームを GET レスポンスの一部として取得します。

たとえば、Squid では動作しますが、ポート 3128 または 8080 のいずれかを使用すると動作しません! どういうわけか、クライアントは接続先のポートを使用して、リクエストの順序やリクエストをいつキャンセルするかを決定しますが、とにかく、信じがたいことですが、プロキシポート 9090、3129、8081 で動作しますが、 3128 または 8080 ではありません。

更新 #2: RealPlayer のソースと上記の動作の説明を次に示します。それでも解決策はありません。

更新 #3: OK、上記に照らして、48 02 02 00 のマジック値は明らかです: 48 == 'h' はHTTP_RESPONSE、次の 02 は次のデータの長さ、次の 02 は呼び出されますPOST_NOT_RECEIVED( POST リクエストが、対応する GET リクエストから 1 秒以内にサーバーに到達しなかったことを意味します)。

更新 #4: この動作 (つまり、巨大な Content-Length を持つ POST 要求) は、WebEx (および、サーバーへのオープン チャネルを必要とする他の多くの Web アプリ) で使用される ActiveX の特徴でもあります。

4

2 に答える 2

3

まず、これを読みたいと思うかもしれません：

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

次に、HTTP 要求 (GET と POST の両方) を適切にプロキシできるようにフォーマットする必要があります。POST リクエストを大量にキャッシュし、サーバーに到達できないようにしているプロキシを見たことがあります。これらのプロキシにはバグがありますが、それについてできることは何もなく、私はその問題を回避できませんでした。ほとんどの場合、ブラウザから送信される POST リクエストを透過的にプロキシして、社会保障番号などの個人情報をスキャンしようとするウイルス対策ソフトウェアでこれを見てきました。同じ問題が発生している可能性があります。

もしかして、マカフィーのアンチウイルスを使っていませんか？

また、Real は同じことを行う独自の方法を発明したようですが、基本的な設計は非常に似ています。ダウンストリーム リンクには GET、アップストリーム リンクには POST を使用し、リンクを関連付けるためのマジック クッキー (この場合は GUID) を使用します。サーバー上で2つ一緒に。いずれにせよ、POST はサーバーに到達するはずですが、あなたの場合はそうではないようです。

ところで、問題は POST リクエストがプロキシを経由しないことにあるようですので、GET に加えて、そのリクエストを投稿してみてはどうでしょうか。

于 2008-11-05T17:11:42.073 に答える
0
  1. 同じリクエストを発行するが、プロキシをバイパスする (たとえば、Netcat を使用して上で投稿したリクエストを再生する) と、応答本文で 4 バイト以上がストリーミングされるかどうかを確認します。
  2. プロキシが受信している TCP パケットを確認します。たとえば、Wireshark を使用して、プロキシを実行しているマシンの TCP トラフィックを盗聴します。
于 2008-11-03T22:41:45.000 に答える