Http range header請求整個文件

我正在使用codeplex 1.1版中的c# webserver。我已經實現了Accept-Range頭文件，它確實有效。然而，當我使用Wireshark（版本1.4.1（SVN版本34476從/trunk-1.4））來捕捉流量，我看到以下內容：Http range header請求整個文件

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-範圍頭，到目前爲止，我只能找到服務器必須發送請求的範圍。但我不能相信這是爲了一次使用範圍請求來請求一個巨大的文件。

我的網絡服務器試圖發送整個文件，因爲它已被請求，但我看到新的範圍請求進來這樣更大的範圍（只有範圍頭從請求頭複製。 ..）是Wireshark

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

讀this我曾嘗試完畢後發送一個較短的範圍內，每當我得到整個文件的範圍請求的時間。但後來它不會在所有的工作。

我想知道：

是整個文件的範圍要求是某種iOS中的bug（4.3.3帶有看到它爲好）我本來期望Range: bytes=0-1和重播像Range: bytes=0-65535/652965648
後我可以採用某種優雅地否認這一點大請求並告訴我的要求，我可以一次提供最大尺寸？（我沒有在RFC中找到這個）
IIS是否在一定數量的字節之後簡單地中止這個請求？

編輯：對於編號3：不是IIS，但瀏覽器似乎只是簡單地中止（和關閉）連接。之後提出新的請求。我無法想象範圍請求是爲了請求整個文件或文件的巨大部分。

編輯：在iOS7它似乎已經改變了。第一個範圍請求仍然是相同的（字節0-1）。之後，我會看到上面提到的2或3個範圍請求，其中最後一個請求持續傳輸較長時間的字節。但是仍然有多個請求完成。

來源

2012-06-13 bart s

我[觀察類似的行爲]（http://stackoverflow.com/questions/12637728/http-byte-range-protocol-client-behaviour-on-ipad-iphone），對我來說，它看起來像這樣iPad/iPhone問題。 – mindas

@mindas確實是你;重新面對同樣的事情。由於我使用的網絡服務器的結構，我沒有多少選擇，需要重新拋出異常來停止處理範圍請求。幸運的是，我只有1個客戶端連接在同一時間（但它也適用於2或3）。我希望你會得到一些有用的答案。 –

我們在測試中看到的是safari詢問前兩個字節（範圍0-1），然後它要求整個文件並立即關閉連接，然後它要求*最後幾百KB文件*（我懷疑它包含重要的元數據，Chrome會按照這種方式做同樣的事情），然後開始以小塊開始請求文件。我懷疑確切的模式會因視頻格式而異。 –

是整個文件的範圍要求是在iOS的某種錯誤的（與4.3.3看到它）我本來期望範圍：字節= 0-1和重播像後範圍：bytes = 0-65535/652965648

我不知道它是否是一個bug。但是，我可以想到媒體播放器在一個請求中請求整個文件的原因。通過這種方式，媒體播放器獲得數據流，從中可以從頭到尾讀取所有數據。

只要媒體播放器從流中讀取足夠的數據，它就可以開始播放媒體文件。然後它選擇在媒體播放時應該在背景中緩衝多少數據。可能有幾種不同的方法：

急切緩衝整個媒體文件。當帶寬很便宜時（用戶不付費或爲數據傳輸支付統一費率），這是一個很好的策略。假定用戶將希望看到/收聽整個媒體文件。
懶惰的緩衝只是爲了避免滯後。當帶寬昂貴時（用戶按字節支付），這是一個很好的策略。

在理想的設置中，媒體播放器不需要緩衝任何東西，而是實時播放媒體時解碼數據流。但是，這將要求底層網絡頻道將保持超級穩定，並始終以所需的速度傳輸數據。

事實並非如此，因此媒體播放器會選擇緩衝幾秒鐘或幾分鐘。

需要注意的是無論選擇何種策略，它仍然是有意義的媒體播放器來請求整個資源在單個請求中是很重要的。

然而，範圍請求是當媒體播放器重要：

的連接被中斷（因任何原因）。
用戶在媒體中跳躍前進。（例如，想要看什麼是電影中的10分鐘）

媒體播放器然後可以關閉它最初打開的數據流併發送所需位置的範圍請求。

我可以採用某種優雅地否認這個大的請求，並告知要求，我可以一次提供一個最大尺寸是多少？

不，你不能。範圍請求由客戶端/瀏覽器和已聲明其支持範圍請求（通過Accept-Ranges標頭）的服務器發起，必須服從客戶端並以其請求的任何範圍做出響應。

但是，您可以做的是使用Transfer-Encoding: chunked標頭髮送數據。這將使你的服務器能夠控制它應該傳輸多大的數據塊。但是，它仍然通過單個HTTP連接完成。

來源

2014-09-24 12:58:41

感謝廣泛的反應。我會將其標記爲答案。 –

Http range header請求整個文件

回答

相關問題