Работа на уровне DNS и OSI

Я хотел бы прояснить сомнение, которое преследует меня после изучения DNS.

Я кратко напишу это как вопрос . «Пользователь смотрел видео на YouTube, и внезапно отказал DNS-сервер, который использовал пользователь (основной и альтернативный DNS)». С точки зрения DNS я могу понять, что пользователь должен иметь возможность продолжать смотреть YouTube, поскольку DNS уже разрешен. Но на самом деле происходит следующее: видео с YouTube перестает воспроизводиться после того, как буферизованное видео воспроизводится, и YouTube больше не воспроизводится.

Не могли бы вы объяснить мне, как это работает на уровне OSI?

-2
задан 12 September 2020 в 15:15
3 ответа

Что касается модели OSI, HTTP не является вершиной DNS, но оба являются независимыми протоколами прикладного уровня , имеющими собственные стеки моделей OSI под ними. Они могут использовать одни и те же кабели и сетевое соединение, но помимо этого они получают данные с разных IP-адресов, используя отдельные TCP / UDP-соединения.

DNS & HTTP in OSI & TCP/IP models

Несмотря на то, что HTTP работает независимо от DNS после кэширования имени хоста, эти детали реализации современные сервисы, использующие протокол HTTP, усложняют задачу. В особенности глобальные и популярные потоковые сервисы, такие как YouTube, просто не могут обслуживать контент с одного сервера или IP-адреса, а требуют сети распространения контента (CDN) с несколькими серверами, разделяющими нагрузку.

Когда вы смотрите видео. с YouTube вы фактически не загружаете буферизованный видеопоток с www.youtube.com , а используете дополнительные запросы к именам хостов, например r2 --- sn-xap5-ixaz.googlevideo.com . Используя инструменты разработчика, вы можете увидеть, что это довольно маленькие фрагменты, которые запрашиваются постоянно:

Chrome developer tools showing /videoplayback queries

  • У этих имен хостов довольно короткий 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-запросов.

2
ответ дан 4 January 2021 в 10:28

Я не думаю, что многоуровневость OSI действительно является фактором для этого вопроса.

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

Я скорее ожидаю, что это эти предположения на самом деле неприменимы в вашем нетривиальном сценарии реального мира с проигрывателем Youtube в браузере. То есть, я ожидаю, что либо необходимые данные DNS фактически не кэшируются (достаточно долго?), Либо во время воспроизведения ищутся новые / дополнительные имена.

Вы можете отслеживать то, что делает ваш браузер (консоль разработчика? ) и состояние кеша, чтобы выяснить этот конкретный сценарий.

1
ответ дан 4 January 2021 в 10:28

Ваше утверждение, что IP-адрес кэшируется компьютером, неверно (почти всегда). IP-адрес может меняться динамически, и пользователь может изменить IP-адрес в середине просмотра Youtube. Компьютеры начинают кэшировать IP, чтобы разрешить небольшую проблему с DNS. Но если DNS-сервер не работает долгое время (30 секунд? Больше? Я не знаю), когда сеанс почти завершен, выполняется новый DNS-запрос. И DNS не ответит, клиент перестанет общаться. В прошлом году был начат новый RFC DNS для продолжения работы в этом случае, но на самом деле он еще не развернут.

0
ответ дан 4 January 2021 в 10:28

Теги

Похожие вопросы