Я обслуживаю mp3 с минималистичным сервером nginx. В своих файлах журналов я вижу множество запросов, в частности от AppleCoreMedia, а иногда и от юзерагентов Android, которые наводняют сервер короткими запросами. Иногда они просят загрузить один и тот же частичный контент в течение очень долгого времени; иногда больше часа. Например:
"GET /somefile.mp3 HTTP/1.1" 206 33041 "AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 like 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 like 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 like Mac OS X; en_us)" [...]
Я тоже получаю много, но не так много:
"-" 400 0 "-" "-" 400 0 "-"
IP-адреса всегда поступают от клиентов, которые начинают загрузку вскоре после этого запроса, обычно у них примерно тот же UserAgent, что и в первом примере. выделенный текст Я включил ограничение сервера и количество подключений в nginx, чтобы хоть немного ограничить огромное количество записей журнала с эквивалентных IP-адресов.
Когда я увидел такое же поведение на предыдущем сервере, который использовал Apache, возникла проблема с производительностью. Я установил nginx на лучший сервер, а затем переместил сайт. Когда Apache не мог эффективно обрабатывать больше подключений от растущего числа клиентов, этот сервер был отключен. У уже подключенных клиентов не было проблем с пропускной способностью, и я не знаю, использовали ли уже подключенные клиенты более одного подключения одновременно.
Пожалуйста, скажите мне:
Я слышал, как люди говорят, что их пропускная способность мобильной связи намного выше, чем они могли себе представить. Я думаю, что такое поведение клиента может объяснить это. И это стоит нам большей пропускной способности.
iOS будет делать запросы диапазона для видео / аудиоконтента, в том числе при воспроизведении через <video> и <audio> HTML5 теги, и они прервутся, как только их будет достаточно для прослушивания пользователем. Это хорошо - он будет загружать их только по мере необходимости, поэтому, если кто-то не слушает / не смотрит все это, вы не тратите пропускную способность, отправляя весь файл.
Сначала второй выпуск:
"-" 400 0 "-"
Обычно это означает, что клиент открыл Keep-Alive соединение, но затем отключилось после получения ответа на свой предыдущий запрос. Поскольку веб-сервер чего-то ожидал, он регистрирует неверный запрос (HTTP 400). В основном они безвредны.
Теперь, в чем проблема с iPhone, загружающим частичное содержимое? Это просто файлы журнала слишком большие? Вы можете отключить ведение журнала для определенных запросов с помощью директив nginx. Если это вызывает проблема производительности, или если клиенты не могут получить доступ к ресурсам, возможно, вам стоит начать беспокоиться. Но вы не упомянули ни то, ни другое.
(Все это говорит о странном поведении iPhone; он тратит впустую как сетевые ресурсы, так и время автономной работы, чего у мобильных устройств не хватает.)