7

私はcodeplexバージョン1.1のc＃Webサーバーを使用しています。Accept-Rangeヘッダーを実装しましたが、機能します。ただし、wireshark（バージョン1.4.1（/trunk-1.4のSVN Rev 34476））を使用してトラフィックをキャッチすると、次のように表示されます。

GET /movies/i_am_legend%20dvd/main.m4v HTTP/1.1
Host: 10.100.1.199:8081
Accept: */*
Range: bytes=0-1
Accept-Encoding: identity
Connection: keep-alive
User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl)
X-Playback-Session-Id: 9CED81CC-BFAE-4CF6-A477-0EA62B2C652F

HTTP/1.1 206 PartialContent
Content-Range: bytes 0-1/652965648
Accept-Ranges: bytes
ETag: "0daA8D4/wgt4MFvxdNIPLw=="
Date: Wed, 13 Jun 2012 09:10:18 GMT
Content-Length: 2
Content-Type: video/x-m4v
Server: Tiny WebServer
Connection: keep-alive

..  << 2 bytes data

GET /movies/i_am_legend%20dvd/main.m4v HTTP/1.1
Host: 10.100.1.199:8081
Accept: */*
Range: bytes=0-652965647
Accept-Encoding: identity
Connection: keep-alive
User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl)
X-Playback-Session-Id: 9CED81CC-BFAE-4CF6-A477-0EA62B2C652F

HTTP/1.1 206 PartialContent
Content-Range: bytes 0-652965647/652965648
Accept-Ranges: bytes
ETag: "0daA8D4/wgt4MFvxdNIPLw=="
Date: Wed, 13 Jun 2012 09:10:18 GMT
Content-Length: 652965648
Content-Type: video/x-m4v
Server: Tiny WebServer
Connection: keep-alive

Webサーバーはファイル全体（> 600MB）を送信しようとしますが、wiresharkは会話全体が159774バイトであることを示しています。IISで同じことを行うと、同様のヘッダーが表示されます

GET /ipod/main.m4v HTTP/1.1
Host: 10.100.1.199
User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl)
Accept: */*
Range: bytes=0-1
Accept-Encoding: identity
X-Playback-Session-Id: C5BBF91D-78AB-42BA-ACE0-D74AB9D845CE
Connection: keep-alive

HTTP/1.1 206 Partial Content
Content-Type: video/x-m4v
Last-Modified: Mon, 11 Jun 2012 10:33:41 GMT
Accept-Ranges: bytes
ETag: "7243cabbd47cd1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 13 Jun 2012 09:21:03 GMT
Content-Length: 2
Content-Range: bytes 0-1/652965648

..  << 2 bytes of data

GET /ipod/main.m4v HTTP/1.1
Host: 10.100.1.199
User-Agent: AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; nl_nl)
Accept: */*
Range: bytes=0-652965647
Accept-Encoding: identity
X-Playback-Session-Id: C5BBF91D-78AB-42BA-ACE0-D74AB9D845CE
Connection: keep-alive

HTTP/1.1 206 Partial Content
Content-Type: video/x-m4v
Last-Modified: Mon, 11 Jun 2012 10:33:41 GMT
Accept-Ranges: bytes
ETag: "7243cabbd47cd1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 13 Jun 2012 09:21:03 GMT
Content-Length: 652965648
Content-Range: bytes 0-652965647/652965648

Wiresharkは、会話全体が175615バイトであることを示しています。

Accept-Rangeヘッダーの詳細を検索しましたが、これまでのところ、サーバーが要求された範囲を送信する必要があることがわかりました。しかし、一度に巨大なファイルを要求するために範囲要求を使用することを意図していたとは信じられません。

私のウェブサーバーは、ファイル全体を送信しようとしますが、このようなより大きな範囲で新しい範囲リクエストが届きます（リクエストヘッダーからコピーされたRangeヘッダーのみ。（@ time ...）はWiresharkの時間

Range: bytes=2162688-652965647 (@ time == 1.646204)
Range: bytes=4980736-652965647 (@ time == 2.754322)
Range: bytes=6356992-652965647 (@ time == 2.922479)

これを読んだ後、ファイル全体の範囲要求を受け取るたびに、より短い範囲を送信しようとしました。しかし、それではまったく機能しません。

私が知りたいのですが：

  1. ファイル全体の範囲要求はiOSのある種のバグですか（4.3.3でも見られます）私は予想Range: bytes=0-1していましたが、リプレイ後は次のようになりますRange: bytes=0-65535/652965648
  2. どういうわけか、この大きなリクエストを優雅に拒否し、一度に最大サイズを配信できることをリクエストに伝えることはできますか？（私はRFCでこれを見つけませんでした）
  3. IISは、特定のバイト数の後にこの要求を単に中止しますか？

編集：番号3の場合：IISではありませんが、ブラウザは単に接続を中止（および終了）しているようです。その後、新しいリクエストを行います。Range Requestが、ファイル全体またはファイルの巨大な部分を要求することを意図していたとは想像できません。

編集：iOS7では変更されたようです。最初の範囲要求は同じです（バイト0〜1）。その後、上記のように2つまたは3つの範囲要求が表示され、最後の要求がより長い期間バイトを転送し続けます。ただし、それでも複数の要求が行われます。

4

1 に答える 1

5
  1. ファイル全体の範囲要求は、iOS の何らかのバグです (4.3.3 でも見られます)。 652965648

バグかどうかはわかりません。ただし、メディア プレーヤーが 1 回の要求でファイル全体を要求する理由は考えられます。このようにして、メディア プレーヤーはデータ ストリームを取得し、そこからすべてのデータを最初から最後まで読み取ることができます。

メディア プレーヤーがストリームから十分なデータを読み取るとすぐに、メディア ファイルの再生を開始できます。次に、メディアの再生中にバックグラウンドでバッファするデータ量を選択します。これには、いくつかの異なるアプローチが考えられます。

  • メディア ファイル全体を積極的にバッファリングします。これは、帯域幅が安価な場合 (ユーザーがデータ転送に料金を支払っていないか、定額料金を支払っていない場合) に適した戦略です。ユーザーがメディア ファイル全体を見たり聞いたりすることを想定しています。

  • 遅延を回避するのに十分なだけ遅延バッファリングします。これは、帯域幅が高価な場合 (ユーザーがバイト単位で支払っている場合) に適した戦略です。

    理想的なセットアップでは、メディア プレーヤーは何もバッファリングする必要がなく、代わりにリアルタイムでメディアを再生しながらストリームからデータをデコードします。ただし、それには、基盤となるネットワーク チャネルが非常に安定しており、常に必要なペースでデータを転送する必要があります。

    これは当てはまらないため、メディア プレーヤーは数秒または数分先にバッファリングすることを選択します。

どの戦略が選択されても、メディア プレーヤーが 1 回のリクエストでリソース全体をリクエストすることは理にかなっている可能性があることに注意することが重要です。

ただし、範囲要求は、次の場合にメディア プレーヤーにとって不可欠です。

  • 接続は (何らかの理由で) 中止されます。
  • ユーザーはメディアを飛び越えます。(たとえば、映画の 10 分後を見たい)

その後、メディア プレーヤーは、最初に開いたデータ ストリームを閉じて、目的の位置の範囲要求を送信できます。

  1. この大規模なリクエストをうまく拒否し、一度に最大サイズを配信できることをリクエストに伝えることはできますか?

いいえ、あなたがすることはできません。範囲要求はクライアント/ブラウザによって開始され、(Accept-Rangesヘッダーを介して) 範囲要求をサポートすることを表明したサーバーは、クライアントに従い、要求した範囲で応答する必要があります。

ただし、できることは、Transfer-Encoding: chunkedヘッダー付きのデータを送信することです。これにより、サーバーは送信するデータのチャンクの大きさを制御できます。ただし、これは依然として単一の HTTP 接続で行われます。

于 2014-09-24T12:58:41.930 に答える