iPad/iPhone 上的 HTTP 字节范围协议客户端行为

Question

我正在测试支持HTTP byte range requests 的HTTP servlet implementation (kindly shared by BalusC)。

我发现不同 HTTP 客户端之间存在一些特殊差异，我想知道我是否没有遗漏任何内容。我在测试中使用了 >2G 的 mp4 视频文件，并且正在使用 Wireshark 捕获数据包。大致是这样的：

• 三星 Galaxy SII：

  • 对文件的HTTP GET请求来了，要求字节范围[0; <almost the end of the file>]
  • 服务器响应，开始流式传输文件

  • 每个后续块都在相同的 HTTP 响应的范围内提供服务。不会发送新的 HTTP 请求（除非视频被快速转发到某个位置）。流式代码块非常简单，它读取RandomAccessFile input并通过byte[] buffer写入OutputStream output：

    while ((read = input.read(buffer)) > 0) {
        output.write(buffer, 0, read);
    }
    

• iPad 1
  • 对文件的HTTP GET请求来了，要求字节范围[0; <almost the end of the file>]
  • 服务器响应，开始流式传输文件
  • iPad 获得一两个块，然后单方面决定停止从服务器接受字节，并为文件的下一个块发出 单独的GET 请求。新的范围边界是例如[100, almost the end of the file]。视频显示正常。
  • 循环从第 2 步开始再次重复。左边界始终向文件末尾移动。

我没有调查连接到底是如何终止的。可能是 iPad 停止发送 TCP ACK 数据包，我想这并不重要。

我的问题是，对于每个终止的连接，我都会收到 java.net.SocketException: Broken pipe 异常。这不仅会污染日志（这是一个小问题/可解决的问题），而且我相信这会损害性能，因为引发异常非常昂贵。观看简单视频时，异常率约为 1 个异常/秒，但如果服务器有 100 个并发用户，那么 JVM 可能会花费大量时间来计算堆栈跟踪而不是实际工作。

我还在使用 iOS 6 的 iPhone 上对此进行了测试，并且能够观察到与 iPad 1 相同的行为。重申一下，这不会发生在三星 Android 或我尝试过的任何桌面浏览器上，包括桌面 Mac 上的 Safari。

问题：

• 这是 iPad/iPhone 的已知错误/功能吗？
• 有解决办法吗？

Answer 1

IIRC，“断管”只是表示对方在关闭读取端后收到数据。

我能想到的最合理的事情是，它试图不浪费大量带宽下载从未被观看过的视频（也许他们已经与运营商达成一致，我怀疑这是 "live streaming" restriction 背后的原因：

“通过蜂窝网络传输超过 10 分钟的视频流内容必须使用 HTTP Live Streaming 并包含基线 64 kbps 纯音频 HTTP Live 流。”

限制下载的唯一其他简单方法是停止 read()ing 并等待接收窗口填满，但这并不总是容易做到（例如，NSURLConnection 真的不会让这变得容易)。

如果你非常幸运，客户端会关闭它的写端（这样服务器就会read()EOF）并等待一会儿，然后再关闭它的读端。在这种情况下，可能可以安全地假设客户端不再需要下载的其余部分。 RFC 2616 有点模糊（似乎忘记了只能在一个方向上关闭套接字），但提到了“优雅关闭”（according to Microsoft 涉及关闭写入端并从读取端完成读取，直到超时通过） ，但也说

服务器不应在传输响应的过程中关闭连接，除非怀疑网络或客户端故障。

因此，如果您知道它是一个 iDevice 并且您读取了 EOF，那么服务器关闭套接字可能是安全的，前提是您已经彻底测试它不会破坏任何东西——根据 User-Agent 改变 HTTP 行为似乎是个糟糕的主意。

或者，不要在意。您可以进行 U-A 嗅探，如果它是 iDevice 则忽略异常（这似乎不如更改 HTTP 行为可怕）。异常开销几乎可以肯定可以忽略不计，并且可能远低于将其打印到日志的开销。每秒 100 个异常不算什么。如果您不确定，请对其进行概要分析。

你也可以file a bug with Apple，但随着这些事情的发展，它不是particularly dubious network behaviour。

Answer 2

在 iPhone 上进行流式传输时，您需要发送 Accept Ranges 标头。这可能会导致您的问题。看看这个帖子

MP4 plays when accessed directly, but not when read through PHP, on iOS

Answer 3

首先，

花费大量时间计算堆栈跟踪

如果您不打算调用 get/printStackTrace()，则不会计算。把它关掉或抓住它并避开它。

我也有同样的问题，但我也没有消失。好吧，这些确实是愚蠢的选择，但是您可以使用负载平衡器来接受连接并将其重定向到您的服务器 tomcat 或 glassfish，无论您使用什么。当我开始在 AWS 上使用 ELB 时，我观察到了这种缺乏断管行为。 NGINX 或 Apache 可以为您做一些前沿通信。

我这么说是因为即使是操作系统也可能是 JVM 没有收到正确的 TCP 通信关闭的原因，因为操作系统上的 JVM 实现。

Answer 4

回到我们共同的发现。看看苹果网站上的this discussion。现在看来，这个问题已经导致 iOS6 在流式传输时消耗过多数据的问题。

（使用荷兰语但完全相同的问题报告了here。Android 执行 1 个请求，iOS 执行多个请求）

是时候用 iOS6.0.1 重新测试这些东西，看看它们是否确实修复了范围请求问题。

刚刚在我的 iPod Touch 第 5 代 - iOS6.0.1 上进行了测试：范围请求仍在请求 0-1，然后是几次 0-full 文件，然后是更小的范围。但是看起来还是很乱