HTML5 Audio Player делает несколько запросов GET при загрузке. Зачем?

Я работаю над плагином jquery, который использует аудиоплеер HTML5() для воспроизведения mp3. Я заметил, что в разных браузерах несколько запросов GET были сделаны для того же файла MP3, когда был загружен аудиоплеер.

Я создал простой автономный HTML файл, чтобы проверить это.

<html>
<head></head>

<body>
    <audio controls src="http://localhost:5000/files/one.mp3" type="audio/mp3"></audio>
<body>  
<html>

При открытии страницы в OS X Safari 5.0.1 я видел следующие журналы с моего веб-сервера (3 запроса GET):

>> Thin web server (v1.2.7 codename No Hup)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:5000, CTRL+C to stop
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0022
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0012
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0010

Обратите внимание, что запросы предназначены для "GET/one.mp3", а не "GET/files/one.mp3", потому что мой тонкий веб-сервер отключен от префикса/файлов.

При открытии одного и того же файла HTML в OS X Chrome я увидел 2 запроса GET для /one.mp3.

При открытии одного и того же файла HTML в OS X Opera я увидел 1 запрос GET для /one.mp3.

В чем причина множественных запросов GET для отдельных файлов? Полоса пропускания на моем сервере ограничена, и я подключаю соединения со скоростью 75 КБ/с (это HTTP-соединение, а не пользователь). Мое беспокойство заключается в том, что Safari делает 3 HTTP-подключения для загрузки (потока) одного mp3 файла, что уменьшит количество одновременных пользователей, которые может обрабатывать мой сервер.

Разве это что-то меня беспокоит с точки зрения производительности/пропускной способности? Кроме того, мне любопытно, почему некоторые браузеры делают несколько запросов для одного и того же файла, а другие нет.

Ответы

Ответ 1

Возможно ли, что Safari делает дополнительные запросы для извлечения метаданных? Попробуйте разные значения атрибута preload, чтобы узнать, не имеет значения:

  • preload = "none" - данные не предварительно загружены (не должны видеть GET)
  • preload = "metadata" - базовые метаданные, такие как длительность, скорость передачи, частота дискретизации и т.д., предварительно загружены (должны видеть один GET)
  • preload = "auto" - весь файл предварительно загружен (может видеть несколько GET)

Для полного описания этого атрибута см. http://dev.w3.org/html5/spec/Overview.html#attr-media-preload.

Ответ 2

В случае Firefox три запроса сделаны для аудио. Это поддержка регионов воспроизведения и поиск медиафайлов, которые еще не загружены. Он по существу загружает файл и определяет его продолжительность в трех кусках. В качестве объяснения было дано следующее, когда это поведение было сообщено Mozilla как ошибка:

  • Первый GET считывает первый фрагмент файла ogg. Из этого мы можем обеспечить его действительный ogg и т.д. Загруженные данные должны кэшироваться Firefox.
  • Второй GET: К сожалению, файлы Ogg не содержат их продолжительности, поэтому мы завершаем первоначальную загрузку, и мы ищем конец файла Ogg и читаем бит данных для извлечения продолжительности времени для носителя.
  • Третий GET: после того, как мы установили продолжительность медиа, мы возобновим загрузку медиа. Нам не нужно повторно загружать данные, которые уже кэшируются, поэтому мы возобновляем работу с того места, где была остановлена ​​предыдущая загрузка.

Хотя это объяснение применимо только к Firefox, вы можете предположить, что подобные методы также используются браузерами webkit.

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