Я хотел бы прояснить сомнение, которое преследует меня после изучения DNS.
Я кратко напишу это как вопрос . «Пользователь смотрел видео на YouTube, и внезапно отказал DNS-сервер, который использовал пользователь (основной и альтернативный DNS)». С точки зрения DNS я могу понять, что пользователь должен иметь возможность продолжать смотреть YouTube, поскольку DNS уже разрешен. Но на самом деле происходит следующее: видео с YouTube перестает воспроизводиться после того, как буферизованное видео воспроизводится, и YouTube больше не воспроизводится.
Не могли бы вы объяснить мне, как это работает на уровне OSI?
Что касается модели OSI, HTTP не является вершиной DNS, но оба являются независимыми протоколами прикладного уровня , имеющими собственные стеки моделей OSI под ними. Они могут использовать одни и те же кабели и сетевое соединение, но помимо этого они получают данные с разных IP-адресов, используя отдельные TCP / UDP-соединения.
Несмотря на то, что HTTP работает независимо от DNS после кэширования имени хоста, эти детали реализации современные сервисы, использующие протокол HTTP, усложняют задачу. В особенности глобальные и популярные потоковые сервисы, такие как YouTube, просто не могут обслуживать контент с одного сервера или IP-адреса, а требуют сети распространения контента (CDN) с несколькими серверами, разделяющими нагрузку.
Когда вы смотрите видео. с YouTube вы фактически не загружаете буферизованный видеопоток с www.youtube.com
, а используете дополнительные запросы к именам хостов, например r2 --- sn-xap5-ixaz.googlevideo.com
. Используя инструменты разработчика, вы можете увидеть, что это довольно маленькие фрагменты, которые запрашиваются постоянно:
У этих имен хостов довольно короткий TTL, составляющий 5-15 минут. После истечения срока действия этого кеша потребуется дополнительный DNS-запрос. Однако это неплохой выбор, поскольку CDN должна быть в состоянии адаптироваться к изменениям спроса.
Из ipconfig / displaydns
:
r2 --- sn-xap5-ixaz. googlevideo.com
----------------------------------------
Запишите имя. . . . . : r2---sn-xap5-ixaz.googlevideo.com
Тип записи . . . . . : 5
Время жить . . . . : 587
Длина данных. . . . . : 8
Раздел . . . . . . . : Ответ
Запись CNAME. . . . : r2.sn-xap5-ixaz.googlevideo.com
Запишите имя. . . . . : r2.sn-xap5-ixaz.googlevideo.com
Тип записи . . . . . : 1
Время жить . . . . : 587
Длина данных. . . . . : 4
Раздел . . . . . . . : Ответ
Запись (Хост). . . : 193.229.108.205
По тем же причинам время от времени серверная часть изменяется, что также требует дополнительных DNS-запросов.
Я не думаю, что многоуровневость OSI действительно является фактором для этого вопроса.
Предположения, изложенные в вопросе, кажутся в основном правильными для тривиального сценария с кешем.
То есть, при условии, что соответствующие данные DNS уже кэшированы, и то же имя продолжает запрашиваться, не имеет значения, что теоретический новый поиск DNS не будет работать, поскольку поиск не производится.
Я скорее ожидаю, что это эти предположения на самом деле неприменимы в вашем нетривиальном сценарии реального мира с проигрывателем Youtube в браузере. То есть, я ожидаю, что либо необходимые данные DNS фактически не кэшируются (достаточно долго?), Либо во время воспроизведения ищутся новые / дополнительные имена.
Вы можете отслеживать то, что делает ваш браузер (консоль разработчика? ) и состояние кеша, чтобы выяснить этот конкретный сценарий.
Ваше утверждение, что IP-адрес кэшируется компьютером, неверно (почти всегда). IP-адрес может меняться динамически, и пользователь может изменить IP-адрес в середине просмотра Youtube. Компьютеры начинают кэшировать IP, чтобы разрешить небольшую проблему с DNS. Но если DNS-сервер не работает долгое время (30 секунд? Больше? Я не знаю), когда сеанс почти завершен, выполняется новый DNS-запрос. И DNS не ответит, клиент перестанет общаться. В прошлом году был начат новый RFC DNS для продолжения работы в этом случае, но на самом деле он еще не развернут.