gpt4 book ai didi

Http 范围 header 请求整个文件

转载 作者:可可西里 更新时间:2023-11-01 15:17:42 25 4
gpt4 key购买 nike

我正在使用 c# webserver来自 codeplex 1.1 版。我已经实现了 Accept-Range header 并且它确实有效。但是,当我使用 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

网络服务器将尝试发送整个文件(>600MB),wireshark 显示整个对话为 159774 字节。如果我对 IIS 做同样的事情,我会得到类似的 header

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 headers的信息,目前我只能发现服务器必须发送请求的范围。但我不敢相信这是为了使用范围请求一次请求一个巨大的文件。

我的网络服务器尝试发送整个文件,因为它已被请求,但我看到新的范围请求以更大的范围出现,就像这样(只有从请求 header 复制的范围 header 。(@time .. .)是wireshark的时间

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

看完this每当我收到整个文件的范围请求时,我都试图发送一个较短的范围。但它根本不起作用。

我想知道:

  1. 整个文件的范围请求是否是 iOS 中的某种错误(在 4.3.3 中也看到过)我本以为 Range: bytes=0-1 并且在重播之后类似于 Range: bytes=0-65535/652965648
  2. 我能否以某种方式优雅地拒绝这个大请求并告诉请求者我可以一次提供最大尺寸? (我没有在 RFC 中找到这个)
  3. IIS 是否只是在特定字节数后中止此请求?

编辑:对于数字 3:不是 IIS,但浏览器似乎只是中止(并关闭)连接。之后提出新的要求。我无法想象范围请求是为了请求整个文件或文件的巨大部分。

编辑:在 iOS7 中它似乎已经改变。第一个范围请求仍然相同(字节 0-1)。之后,我看到如上所述的 2 或 3 个范围请求,其中最后一个请求在较长时间内继续传输字节。但是仍然有多个请求完成。

最佳答案

  1. Is the range request for the entire file is some kind of bug in iOS (seen it with 4.3.3 as well) I would have expected Range: bytes=0-1 and after the replay something like Range: bytes=0-65535/652965648

不知道是不是bug。但是,我可以想到媒体播放器在一个请求中请求整个文件的原因。通过这种方式,媒体播放器获得一个数据流,它可以从中从头到尾读取所有数据。

一旦媒体播放器从流中读取了足够的数据,它就可以开始播放媒体文件。然后,它会选择在播放媒体时在后台缓冲多少数据。对此可能有几种不同的方法:

  • 急切地缓冲整个媒体文件。当带宽便宜时(用户不为数据传输支付或支付统一费率),这是一个很好的策略。假设用户想要查看/收听整个媒体文件。

  • 惰性缓冲刚好足以避免滞后。当带宽昂贵(用户按字节付费)时,这是一个很好的策略。

    在理想的设置中,媒体播放器根本不需要缓冲任何内容,而是在实时播放媒体时解码流中的数据。但是,这需要底层网络 channel 非常稳定,并始终以所需的速度传输数据。

    事实并非如此,因此媒体播放器会选择提前缓冲几秒或几分钟。

重要的是要注意,无论选择何种策略,媒体播放器在单个请求中请求整个资源仍然有意义。

但是,在以下情况下,范围请求对媒体播放器至关重要:

  • 连接中止(出于任何原因)。
  • 用户在媒体中跳到前面。 (例如,想看看 10 分钟的电影)

然后媒体播放器可以关闭它最初打开的数据流,并发送所需位置的范围请求。

  1. Can I somehow gracefully deny this large request and tell the requested that I can deliver a maximum size at once?

不,你不能。范围请求由客户端/浏览器发起,并且声明它支持范围请求(通过 Accept-Ranges header )的服务器必须服从客户端并响应它请求的任何范围。

然而,您可以做的是发送带有 Transfer-Encoding: chunked header 的数据。这将使您的服务器能够控制它应传输的数据 block 的大小。但是,它仍然是通过单个 HTTP 连接完成的。

关于Http 范围 header 请求整个文件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11013551/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com