Один день из жизни запроса веб-страницы

Jul 16, 2019 16:18





Когда Боб только подключает ноутбук к сети, он еще ничего не может сделать (даже загрузить веб-страницу), пока у него нет IP-адреса. Соответственно, первым делом ноутбук Боба должен запустить протокол DHCP для получения с локального DHCP-сервера не только IP- адреса, но и другой информации:

1. Операционная система на ноутбуке Боба создает сообщение с запросом DHCP (см. раздел 4.4.2) и записывает это сообщение в UDP-сегмент (см. раздел 3.3). В качестве порта получателя указывается порт 67 (DHCP-сервер), а порт отправителя имеет номер 68 (DHCP-клиент). После этого UDP-сегмент записывается в IP дейтаграмму (раздел 4.4.1) с широковещательным IP-адресом получателя (255.255.255.255). IP-адрес отправителя будет равен 0.0.0.0, так как у ноутбука Боба еще нет IP-адреса.

2. IP-дейтаграмма, содержащая сообщение с запросом DHCP, затем помещается в Ethernet-кадр (раздел 5.4.2). Ethernet-кадр обладает MAC- адресами назначения FF:FF:FF:FF:FF:FF, поэтому кадр будет широковещательно передаваться всем устройствам, подключенным к коммутатору (остается надеяться, что среди этих устройств окажется и DHCP-сервер). Исходный MAC-адрес кадра совпадает с адресом ноутбука Боба, 00:16:D3:23:68:8A.

3. Широковещательный Ethernet-кадр, содержащий DHCP-запрос - это первый кадр, отправленный ноутбуком Боба на Ethernet-коммутатор. Коммутатор широковещательно передает этот входящий кадр на все свои выходные порты, в том числе на порт, подключенный к маршрутизатору.



4. Маршрутизатор получает широковещательный Ethernet-кадр с DHCP- запросом на интерфейс с MAC-адресом 00:22:6B:45:1F:1B, после чего IP-дейтаграмма извлекается из Ethernet-кадра. Широковещательный IP-адрес назначения дейтаграммы указывает, что IP- дейтаграмма должна быть обработана на данном узле более высокоуровневыми протоколами, поэтому полезная нагрузка дейтаграммы (UDP-сегмент) демультиплексируется (раздел 3.2) вплоть до UDP, а сообщение с запросом DHCP извлекается из UDP-сегмента. Итак, теперь у DHCP-сервера есть сообщение с запросом DHCP.

5. Предположим, что DHCP-сервер, работающий на маршрутизаторе, может выделять адреса из блока CIDR (раздел 4.4.2) 68.85.2.0/24. Таким образом, в данном примере все IP-адреса университета будут относиться к блоку адресов провайдера Comcast. Далее допустим, что DHCP-сервер выделяет ноутбуку Боба адрес 65.85.2.101. DHCP-сервер создает сообщение DHCP ACK (раздел 4.4.2), в котором содержится этот IP-адрес, а также следующая информация: IP- адрес DNS-сервера (68.87.71.226), IP-адрес шлюзового маршрутизатора, задаваемого по умолчанию (68.85.2.1) и, наконец, блок подсети (65.85.2.0/24), он же - «маска сети». DHCP-сообщение записывается в UDP-сегмент, который заключается в IP-дейтаграмму, а она, в свою очередь - в Ethernet-кадр. Ethernet-кадр располагает исходным MAC-адресом (это адрес интерфейса маршрутизатора, соединяюще- го маршрутизатор с домашней сетью - 00:22:6B:45:1F:1B) и конечным MAC-адресом (это адрес ноутбука Боба 00:16:D3:23:68:8A).

6. Ethernet-кадр, содержащий сообщение DHCP ACK (одноадресно), передается маршрутизатором на коммутатор. Поскольку коммутатор является самообучающимся (раздел 5.4.3), а ранее получил Ethernet-кадр (с DHCP-запросом) с ноутбука Боба, коммутатору уже известно, что кадр, идущий на адрес 00:16:D3:23:68:8A, нужно просто передать на выходной порт, ведущий к ноутбуку Боба.

7. Ноутбук Боба получает сообщение DHCP ACK, извлекает IP- дейтаграмму из Ethernet-кадра, затем UDP-сегмент из IP-дейтаграммы, после чего - сообщение DHCP ACK из UDP-сегмента. Затем DHCP- клиент с ноутбука Боба записывает его IP-адрес, а также IP- адрес его DNS-сервера. Кроме того, он заносит адрес в свою IP- таблицу маршрутизации (раздел 4.1). Ноутбук Боба будет отсылать на за- данный по умолчанию шлюз все дейтаграммы, чей адрес назначения находится вне его подсети 68.85.2.0/24. На данном этапе ноутбук Боба уже инициализировал свои сетевые компоненты и готов об- рабатывать операции выборки веб-страниц. Обратите внимание: из четырех этапов работы с DHCP, описанных в главе 4, необходимыми являются только первые два.

Когда Боб вводит в браузер адрес www.google.com, начинается длинная цепочка событий. Ее конечный результат - отображение главной страницы Google в браузере. Браузер с ноутбука Боба начинает этот процесс, создав TCP-сокет (раздел 2.7), который будет использоваться для отправки HTTP-запроса (раздел 2.2) на сайт www.google.com. Что- бы создать этот сокет, ноутбуку Боба потребуется узнать IP-адрес www. google.com. В разделе 2.5 мы изучили, что для такого преобразования доменного имени в IP-адрес используется протокол DNS.

8. Для этого операционная система на ноутбуке Боба создает сообщение с запросом DNS (раздел 2.5.3), помещая строку «www.google. com» в тот раздел DNS-сообщения, где содержится запрос. Затем это DNS-сообщение записывается в UDP-сегмент с портом назначения 53 (это DNS-сервер). После этого данный UDP-сегмент помещается в IP-дейтаграмму, имеющую IP-адрес получателя 68.87.71.226 (это адрес DNS-сервера, который мы приняли в возвращенном сообщении DHCP ACK на этапе 5) и IP-адрес отправителя 68.85.2.101

9. После этого ноутбук Боба помещает дейтаграмму, содержащую сообщение с запросом DNS, в Ethernet-кадр. Этот кадр будет отправлен (адресован на сетевом уровне) на шлюзовой маршрутизатор сети того университета, где учится Боб. Однако, хотя ноутбуку Боба и известен IP-адрес шлюзового маршрутизатора университета (65.85.2.1) - эта информация была получена в сообщении DHCP ACK на этапе 5, описанном выше, ему не известен MAC-адрес этого шлюза. Чтобы получить MAC-адрес шлюзового маршрутизатора, на ноутбуке Боба понадобится задействовать протокол ARP (раздел 5.4.1).

10. Ноутбук Боба создает сообщение с запросом ARP, где указывается целевой IP-адрес 68.85.2.1 (адрес шлюзового маршрутизатора). ARP-сообщение помещается в Ethernet-кадр с широковещательным адресом получателя (FF:FF:FF:FF:FF:FF), после чего ноутбук отправляет Ethernet-кадр на коммутатор, который, в свою очередь, доставляет этот кадр на все подключенные к нему устройства, в том числе на шлюзовой маршрутизатор.

11. Шлюзовой маршрутизатор получает кадр с сообщением c ARP- запросом на интерфейс, ведущий в него из университетской сети, и определяет, что целевой IP-адрес 68.85.2.1 в ARP-сообщении совпадает с IP-адресом его интерфейса. После этого шлюзовой маршрутизатор подготавливает ARP-ответ, указывая, что его MAC-адрес 00:22:6B:45:1F:1B соответствует IP-адресу 68.85.2.1. Сообщение с ARP-ответом записывается в Ethernet-кадр с адресом получателя (это ноутбук Боба). После этого кадр отправляется на коммутатор, который доставляет его на ноутбук Боба.

12. Ноутбук Боба получает кадр с ответным ARP-сообщением и извлекает MAC-адрес шлюзового маршрутизатора (00:22:6B:45:1F:1B) из этого сообщения.

13. Теперь ноутбук Боба (наконец-то!) может отправить Ethernet-кадр с DNS-запросом на MAC-адрес шлюзового маршрутизатора. Обратите внимание: IP-дейтаграмма в этом кадре имеет IP-адрес получателя 68.87.71.226 (это адрес DNS-сервера), тогда как адрес получателя кадра - 00:22:6B:45:1F:1B (это шлюзовой маршрутизатор). Ноутбук Боба отправляет кадр на коммутатор, который, в свою очередь, доставляет этот кадр на шлюзовой маршрутизатор.

14. Шлюзовой маршрутизатор получает кадр и извлекает из него IP-дейтаграмму, содержащую DNS-запрос. Маршрутизатор уточняет адрес назначения этой дейтаграммы (68.87.71.226) и определяет по своей таблице маршрутизации, что дейтаграмма должна быть отправлена на маршрутизатор сети Comcast, который изображен на рис. 5.32 левее всех. IP-дейтаграмма помещается в кадре канального уровня для перемещения по каналу, который связывает университетский маршрутизатор с маршрутизатором Comcast, изображенным на рис. 5.32 левее всех. Кадр отправляется по этому каналу.

15. Вышеупомянутый маршрутизатор из сети Comcast получает кадр, извлекает IP-дейтаграмму, проверяет ее адрес получателя (68.87.71.226), а потом по своей таблице маршрутизации определяет выходной интерфейс, через который этот кадр должен быть отправлен на DNS-сервер. Таблица маршрутизации была заполнена при помощи протокола внутридоменной маршрутизации сети Comcast (это может быть протокол RIP, OSPF или IS-IS, см. раздел 4.6), а также с применением протокола BGP, обеспечивающего междоменную маршрутизацию в Интернете.

16. Наконец, IP-дейтаграмма, содержащая DNS-запрос, прибывает на DNS-сервер. DNS-сервер извлекает сообщение с DNS-запросом, ищет в своей базе данных DNS адрес www.google.com (раздел 2.5), после чего находит запись DNS-ресурса, содержащую IP-адрес (64.233.169.105) сайта www.google.com (предполагается, что эта запись уже кэширована на DNS-сервере). Как вы помните, эти кэшированные данные берутся с авторитетного DNS-сервера (раздел 2.5.2), отвечающего за сайт google.com. Сервер формирует ответное DNS- сообщение, в котором содержится отображение данного хост-имени на соответствующий IP-адрес, и помещает это ответное сообщение в UDP-сегмент. Сегмент, находящийся в IP-дейтаграмме, адресуется на ноутбук Боба (68.85.2.101). Эта дейтаграмма будет отправлена обратно в сеть Comcast, а оттуда далее, через Ethernet-коммутатор на ноутбук Боба.

17. Ноутбук Боба извлекает IP-адрес сервера www.google.com из DNS- сообщения. Наконец, проделав всю эту огромную работу, ноутбук Боба готов подключиться к серверу www.google.com!

18. Теперь, когда ноутбук Боба обладает IP-адресом www.google.com, он может создать TCP-сокет (раздел 2.7), который будет использоваться для отправки сообщения HTTP GET (раздел 2.2.3) на сайт www. google.com. Когда Боб создает TCP-сокет, протокол TCP в ноутбуке Боба сперва должен выполнить тройное рукопожатие (раздел 3.5.6) с протоколом TCP на www.google.com. Поэтому для начала ноутбук Боба создает сегмент TCP SYN с портом назначения 80 (для HTTP), помещает TCP-сегмент в IP-дейтаграмме, задавая IP-адрес получателя 64.233.169.105 (www.google.com). Эта дейтаграмма помещается в кадр с MAC-адресом получателя 00:22:6B:45:1F:1B (шлюзовой маршрутизатор). После всех этих операций кадр отправляется на коммутатор.

19. Маршрутизаторы из университетской сети, сети Comcast и сети Google шлют дейтаграмму с пакетом TCP SYN на адрес www.google. com. Для этого используются таблицы маршрутизации каждого из них, как описано выше в шагах 14-16. Как вы помните, записи в таблицах маршрутизации, управляющие перемещением пакетов по междоменным связям между сетями Comcast и Google, формируются протоколом BGP (раздел 4.6.3).

20. Наконец, дейтаграмма с пакетом TCP SYN прибывает на www. google.com. Там сообщение TCP SYN извлекается из дейтаграммы и демультиплексируется на нужный сокет, ассоциированный с портом 80. Специальный сокет соединения (раздел. 2.7) создается для установления соединения между HTTP-сервером Google и ноутбуком Боба по протоколу TCP. Генерируется сегмент TCP SYNACK (раздел 3.5.6), затем этот сегмент помещается в дейтаграмме, адресо- ванной на ноутбук Боба, и, наконец, заключается в кадре канального уровня, подходящем для передачи по каналу, соединяющему www. google.com и его первый транзитный маршрутизатор.

21. Дейтаграмма, содержащая сегмент TCP SYNACK, направляется через сети Google, Comcast и университета, в итоге оказываясь на сетевой Ethernet-карте ноутбука Боба. Дейтаграмма демультиплексируется в операционной системе на TCP-сокет, созданный в шаге 18, и этот сокет переходит в соединенное состояние.

22. Когда сокет на ноутбуке Боба (наконец-то!) готов отправлять байты на www.google.com, браузер на ноутбуке создает сообщение с запросом HTTP GET (раздел 2.2.3), содержащее адрес URL, откуда требуется взять данные. Затем сообщение HTTP GET записывается на сокет, причем запрос GET становится полезным содержимым TCP- сегмента. TCP-сегмент помещается в дейтаграмму, отправляется и доставляется на сайт www.google.com, как описано в шагах 18-20 выше.

23. HTTP-сервер по адресу www.google.com считывает сообщение HTTP GET с TCP-сокета, создает HTTP-ответ (раздел 2.2), помещает контент запрошенной веб-страницы в тело ответного HTTP-сообщения, после чего отправляет это сообщение на TCP-сокет.

24. Дейтаграмма, содержащая HTTP-ответ, направляется через сети Google, Comcast и университетскую сеть, после чего прибывает на ноутбук Боба. Браузер на ноутбуке считывает HTTP-сообщение с сокета, извлекает html-код веб-страницы из тела HTTP-ответа и (наконец-то!) отображает веб-страницу.

Previous post Next post
Up