java - iPad/iPhone 上的 HTTP 字节范围协议(protocol)客户端行为

Question

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

我发现不同 HTTP 客户端之间存在一些特殊差异，想知道我是否遗漏了什么。我在测试中使用了大于 2G 的 mp4 视频文件，并使用 Wireshark 捕获数据包。大致情况如下:

• 三星 Galaxy SII:

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

  • 每个后续 block 都在相同 HTTP 响应 的范围内提供服务。没有发送新的 HTTP 请求(除非视频被快速转发到某个位置)。为此流式处理代码块非常简单，它显示为 RandomAccessFile input并写入 OutputStream output通过byte[] buffer :

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

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

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

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

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

问题:

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

Answer 1

IIRC，“broken pipe”只是指另一端在关闭其读取端后接收到数据。

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

"Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64 kbps audio-only HTTP Live stream."

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

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

Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.

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

或者，不关心。如果它是 iDevice(这似乎没有改变 HTTP 行为那么可怕)，您可以进行 U-A 嗅探并忽略异常。异常开销几乎可以忽略不计，并且可能远低于将其打印到日志的开销。每秒 100 个异常算不了什么。如果您不确定，请分析它。

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