☰

为移动设备提供 mp3 会导致 nginx 出现大量部分请求

tag-icon • tag-icon http streaming mobile-devices mp3
为移动设备提供 mp3 会导致 nginx 出现大量部分请求

我使用一个极简的 nginx 服务器提供 mp3。我在日志文件中看到，有很多请求，特别是来自 AppleCoreMedia 的请求，有时来自 Android 用户代理的请求，这些请求会向服务器发送大量短请求。有时他们会在很长时间内不断请求下载相同的部分内容；有时会超过一个小时。例如：

“GET /somefile.mp3 HTTP/1.1” 206 33041 “AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 类似 Mac OS X; en_us)”
“GET /somefile.mp3 HTTP/1.1” 206 33041 “AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 类似 Mac OS X; en_us)”
“GET /somefile.mp3 HTTP/1.1” 206 33041 “AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 类似 Mac OS X; en_us)”
[...]

我也收到了很多这样的邮件，但是没有那么多：

“-”400 0“-”
“-”400 0“-”

IP 地址总是来自在请求后不久开始下载的客户端，通常它们具有与第一个示例中大致相同的 UserAgent。 强调文字 我已经在 nginx 中启用了服务器限制和连接限制，以至少在一定程度上限制来自等效 IP 的大量日志条目。

当我在之前使用 Apache 的服务器上看到同样的行为时，出现了性能问题。我在更好的服务器上安装了 nginx，然后移动了网站。当 Apache 无法有效处理来自不断增加的客户端的更多连接时，该服务器就瘫痪了。已经连接的客户端没有带宽问题，我不知道已经连接的客户端是否同时使用多个连接。

请告诉我：

  • 客户端在下载时卡住是一件坏事吗？

我听说有人说他们的移动带宽使用量远远高于他们所能承受的水平。我认为这种类型的客户行为可以解释这一点。而且也消耗了我们更多的带宽。

  • 有哪些最新的替代方案可以比纯 HTTP 更好地处理此类数据？
  • 对于 90 年代末刚刚进入该领域的人来说，这是很有用的一般见解。:-)

答案1

先说第二期：

"-" 400 0 "-"

这通常意味着客户端打开了一个Keep-Alive连接，但在收到对其上一个请求的响应后断开了连接。由于 Web 服务器正在等待某些东西，因此它会记录一个错误请求 (HTTP 400)。这些大多是无害的。

那么，iPhone 下载部分内容的问题是什么呢？只是日志文件很大? 您可以使用 nginx 指令关闭特定请求的日志记录。如果它导致性能问题或者如果客户端无法访问资源，那么也许您应该开始担心。但您没有明确提到其中任何一个。

（尽管如此，这对于 iPhone 来说是一种奇怪的行为；它既浪费网络资源又浪费电池寿命，而这两者都是移动设备所缺乏的。）

答案2

iOS 会对视频/音频内容进行范围请求，包括通过 HTML5 标签播放的内容<video>，<audio>一旦内容足够用户听一段时间，它们就会中止。这是一件好事 - 它只会根据需要获取它们，因此如果有人没有听/看完整个内容，您就不会浪费带宽发送整个文件。

相关内容