Обслуживание mp3-файлов на мобильных устройствах приводит к загрузке nginx с частичными запросами

Question

Обслуживание mp3-файлов на мобильных устройствах приводит к загрузке nginx с частичными запросами

Я обслуживаю mp3 с минималистичным сервером nginx. Что я вижу в своих файлах журналов, так это то, что есть много запросов, в частности от 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 не смог обработать больше соединений от растущего числа клиентов, этот сервер был удален. У уже подключенных клиентов не было проблем с пропускной способностью, и я не знаю, использовали ли уже подключенные клиенты более одного подключения одновременно.

Пожалуйста, скажите мне:

Являются ли клиенты, которые, кажется, застряли при загрузке Bad Thing™

Я слышал, что люди говорят, что их пропускная способность мобильной связи была намного выше, чем они могли объяснить. Я думаю, что этот тип поведения клиента может объяснить это. И стоит нам больше пропускной способности тоже.

Какие современные альтернативы существуют для обработки данных такого типа лучше, чем простой HTTP?
Полезные общие сведения для тех, кто только что пришел в эту область прямо из конца 90-х годов.:-)

2

http streaming mobile-devices mp3

Источник

drumfire 20 сен '12 в 20:39

2 ответа

Другие вопросы по тегам http streaming mobile-devices mp3

ceejayoz 20 сен '12 в 21:00 2012-09-20 21:00 · Answer 1 · 2012-09-20 21:00

iOS будет выполнять запросы диапазона для видео / аудио контента, в том числе, если воспроизводится через <video> а также <audio> HTML5-теги, и они будут прерваны, как только их будет достаточно для того, чтобы пользователь некоторое время слушал Это хорошая вещь - она будет извлекать их только по мере необходимости, поэтому, если кто-то не слушает / не смотрит все это, вы не тратите пропускную способность, отправляя весь файл.

Michael Hampton 20 сен '12 в 20:47 2012-09-20 20:47 · Answer 2 · 2012-09-20 20:47

Второй номер первый:

"-" 400 0 "-"

Обычно это означает, что клиент открыл Keep-Alive соединение, но затем отключается после получения ответа на свой предыдущий запрос. Поскольку веб-сервер чего-то ожидал, он регистрирует неверный запрос (HTTP 400). Это в основном безвредны.

Теперь, что проблема с айфонами, загружающими частичный контент? Это просто большие файлы журнала? Вы можете отключить ведение журнала для конкретных запросов, используя директивы nginx. Если это вызывает проблемы с производительностью, или если клиенты не могут получить доступ к ресурсам, то, возможно, вам следует начать беспокоиться. Но вы явно не упомянули ни одного из них.

(Все это говорит о том, что это странное поведение iPhone; оно тратит как сетевые ресурсы, так и время автономной работы, чего не хватает мобильным устройствам.)