1

В потоковом потоке HTTP потоки файлов разделены на фрагменты фиксированного размера для потоковой передачи. Зачем это рационально? Как это лучше, чем наличие одного файла и использование смещений для извлечения различных кусков.Зачем сегментировать файлы в куски для потоковой передачи HTTP?

Мои грубые идеи на данный момент.

Разделение файлов на несколько фрагментов уменьшает время поиска файла во время потоковой передачи.

Из того, что я понимаю, файл хранится как постоянный связанный список на жестком диске. Это даже верно для современных файловых систем (например, NTFS, ext3) или они используют более сложную структуру данных, например, сбалансированное дерево или хеш-карты для индексации блоков файла? Какова сложность времени выполнения поиска (используя seekp, tellp и т. Д.) В файле?

+0

Это сообщение, могло быть Вам полезно: http://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection –

ответ

0

HDD не является предметом рассмотрения. Это делается для упрощения на уровне сети/CDN, а также клиентской логики. HTTP - это протокол запроса/ответа. Это плохо справляется с длинными потоками. Его также не мультиплексирует. Чтобы использовать несколько сокетов, вы должны сделать отдельные запросы. Требование, чтобы клиент узнал о структуре мух и смог преобразовать строку поиска в смещение байта, является сложным. Особенно для переменных битрейтов. Но если вы знаете, что у видео есть 100 сегментов (файлов), и вы стремитесь к 50%, его действительно легко узнать, какой файл вам нужен. И, наконец, как должен кешировать уровень с запросом диапазона? загрузить весь файл из источника или просто запросить данные по мере необходимости и «сшить» файл обратно вместе локально? В любом случае для уровня кэширования потребуется эта логика. Дополнительная логика возникает за счет меньшего количества запросов в секунду.

Смежные вопросы