Комментарии 21
Мемоизация функций
Это скорее всего называется cache aside.
Не рассмотрены:
— кэширование DNS ответов на клиенте и на промежуточных серверах.
— keep-alive соединения от клиента к серверу (не совсем кэширование но принцип похож — повторное использование соединения вместо создания нового соединения).
— кэширование дескрипторов открытых файлов для случая когда сервер отдает много статики с диска.
— кэширование выдачи stat().
— кэширование дерева директорий на диске
— кэширование информации о клиентском хосте и о параметрах канала от клиента до сервера (так называемый hostcache).
— кэширование контента после сжатия (gzip).
Возможно Вы знаете ответ на очень интересующий меня вопрос. Если полгорода вдруг решили посмотреть одно и тоже на Youtube, протянется к каждому прибору своя ниточка с ближайшего DNS сервера или пакеты где-то на промежуточных серверах будут кэшится и потом оттуда раздаваться?
Заранее признателен за ответ.
Заранее признателен за ответ.
Промежуточные сервера у провайдеров обычно кэшируют ответы. Причем продолжительность жизни ответа в кэше может быть как больше так и меньше TTL, настроенного на авторитативном сервере. Такое положение вещей создает определенную боль при переезде сайтов с одного хостинга на другой и при прочих подобных мероприятиях.
А как в данном случае связан ролик с youtube который смотрит полгорода и DNS? И я не очень уловил, что в ответе pae174 не устроило.
В целом ситуация будет такая. У youtube.com TTL = 30 минут. Т.е. величина средняя и вероятность запроса на разрешение имени высокая. Но учитывая популярность youtube можно сказать, что в DNS кэше провайдера нужная информация будет (именно кэширование инфы, а не конкретных пакетов) и резолвинг произойдет крайне быстро. Поэтому на уровне DNS можно считать, что задержки не будет.
Далее попадаем на уровень уже самого ролика. Если у провайдера кэширующие сервера есть (а обычно это так и есть), то ролик упадет в кэш конкретного провайдера. После чего будет уже быстро раздаваться клиентам этого провайдера. Очень популярный ролик вероятно упадет в кэш провайдеров всего города. Кроме того есть и другие уровни кэша, чуть выше. Это кэш на магистрали. Еще есть Google Global Cache который могут себе ставить провайдеры.
Надеюсь ответил на все пункты понятно.
P.S. А почему интересует данный вопрос?
В целом ситуация будет такая. У youtube.com TTL = 30 минут. Т.е. величина средняя и вероятность запроса на разрешение имени высокая. Но учитывая популярность youtube можно сказать, что в DNS кэше провайдера нужная информация будет (именно кэширование инфы, а не конкретных пакетов) и резолвинг произойдет крайне быстро. Поэтому на уровне DNS можно считать, что задержки не будет.
Далее попадаем на уровень уже самого ролика. Если у провайдера кэширующие сервера есть (а обычно это так и есть), то ролик упадет в кэш конкретного провайдера. После чего будет уже быстро раздаваться клиентам этого провайдера. Очень популярный ролик вероятно упадет в кэш провайдеров всего города. Кроме того есть и другие уровни кэша, чуть выше. Это кэш на магистрали. Еще есть Google Global Cache который могут себе ставить провайдеры.
Надеюсь ответил на все пункты понятно.
P.S. А почему интересует данный вопрос?
Спасибо за ответ. В теории я это себе как-то так и представлял. Но описанная схема хорошо подходит под кэширование по HTTP протоколу. Боюсь, в стрименге всё происходит по другому. Там другие протоколы. Я заметил, что качество картинки при просмотре Youtube и подобных ресурсов со временем подстраивается под пропускную возможность канала. Т.е. какой-то из серверов начинает отправлять другие пакеты, чем в начале просмотра, а в процессе ситуация может снова поменяться.
Если это делает кэш-сервер, то на нём должно лежать много вариантов одного ролика, грубо говоря. Не хочу Вас обидеть, но картина наверное намного сложнее, чем Вы описали. Не хочу Вас напрягать, но был бы признателен за ссылку на детальное описание этих процессов.
Ну а интересно мне это потому, что хочется понять, как работают приборы, которые нас окружают.
Если это делает кэш-сервер, то на нём должно лежать много вариантов одного ролика, грубо говоря. Не хочу Вас обидеть, но картина наверное намного сложнее, чем Вы описали. Не хочу Вас напрягать, но был бы признателен за ссылку на детальное описание этих процессов.
Ну а интересно мне это потому, что хочется понять, как работают приборы, которые нас окружают.
По сути стримминг от от статического контента отличается мало. Большой статический файл на клиент уходит кусками и там уже склеивается. Стрим летит на клиент примерно так же, но в отличие от статики клеится на клиенте на лету + важен порядок кусков.
Не совсем так. Инициатор соединения клиент, а не сервер. Он и определяет требуемый ему range. А сервер уже отдает ровно то, что от него просят.
Не совсем так. На нем много кусков многих роликов. Варианта «вот ролик Х в наборе качества Z, W» обычно нет. Хотя конечно при желании склеить куски одного потока в единственный файл можно.
Такого описания не может быть в принципе, т.к. какая стратегия применяется кэш сервером зависит собственно от деталей реализации конкретного кэш сервера. И для детального понимания нужно просто читать документацию на конкретное используемое ПО.
Т.е. какой-то из серверов начинает отправлять другие пакеты
Не совсем так. Инициатор соединения клиент, а не сервер. Он и определяет требуемый ему range. А сервер уже отдает ровно то, что от него просят.
Если это делает кэш-сервер, то на нём должно лежать много вариантов одного ролика
Не совсем так. На нем много кусков многих роликов. Варианта «вот ролик Х в наборе качества Z, W» обычно нет. Хотя конечно при желании склеить куски одного потока в единственный файл можно.
признателен за ссылку на детальное описание этих процессов
Такого описания не может быть в принципе, т.к. какая стратегия применяется кэш сервером зависит собственно от деталей реализации конкретного кэш сервера. И для детального понимания нужно просто читать документацию на конкретное используемое ПО.
Спасибо за Ваше терпение, но позволю с двумя последними пунктами не согласиться.
Я часто наблюдаю, что качество показываемого видео на глазах меняется. Это значит, я думаю, клиент (app) в телевизоре начинает получать контент (наверное типа mp4) с фреймами другого разрешения. А это, в Вашей терминологии кусок N «ролика Х в качестве Z».
Описание должно быть, поскольку создатели серверной инфраструктуры и разработчики клиентов по показу стриминга должны были выработать общий стандарт.
«Будем искать», как говаривал Семён Семёныч.
Варианта «вот ролик Х в наборе качества Z, W» обычно нет
Я часто наблюдаю, что качество показываемого видео на глазах меняется. Это значит, я думаю, клиент (app) в телевизоре начинает получать контент (наверное типа mp4) с фреймами другого разрешения. А это, в Вашей терминологии кусок N «ролика Х в качестве Z».
Такого описания не может быть в принципе,
Описание должно быть, поскольку создатели серверной инфраструктуры и разработчики клиентов по показу стриминга должны были выработать общий стандарт.
«Будем искать», как говаривал Семён Семёныч.
с фреймами другого разрешения
Ну мы же начали с ютуба, так? Так. И там не «с фреймами другого разрешения». Потому что адекватный гугл понимает, что такой поток кэшировать сложнее, чем блоки явно заданные конкретными url.
клиентов по показу стриминга должны были выработать общий стандарт.
Стандарты есть. Например долгоживущий RTSP. Только на практике все сиииильно и на порядок сложнее, чем некий общий стандарт. Рекомендую поискать статьи/видео от Макса Лапшина.
Так же есть webm. Гугл.
Для меня, который ничего из этого не знал (даже используемых терминов), полезно.
Этот кэш используется, когда в ответе сервера содержатся правильно настроенные HTTP-заголовки, указывающие браузеру на то, когда и на какое время он может кэшировать ответ сервера.
Это единственное, что можно сделать своими руками, если используешь чужую инфраструктуру. Вот про это хотелось бы узнать побольше: стандарты, инструменты, best practices.
Был бы очень признателен за ссылки.
Спасибо. Много полезных деталей во второй статье этой серии. В ней я вроде бы нашёл подтверждение своему давнему подозрению, что в мире HTTPS кэширование за пределами сервера не происходит. Учитывая тренд всё делать через HTTPS, про кэширование можно забыть, получается. А что думают специалисты в этой области?
что в мире HTTPS кэширование за пределами сервера не происходит.
Это не так. Потому что кэширование на клиенте как было и осталось. В FF в этом легко убедится посмотрев содержимое кэша:
about:cache?storage=disk&context=в котором видно много Https ресурсов.
в мире HTTPS кэширование за пределами сервера не происходит
Происходит если кэширующий прокси терминирует TLS соединение. Так работает Cloud Flare по крайней мере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кэширование и производительность веб-приложений