Каковы подробные шаги модели OSI при подключении к веб-сайту?

Question

Каковы подробные действия по подключению к веб-сайту, например домашней странице superuser.com, с использованием только что подключенного компьютера (http и ничего не кэшируется)? Что на самом деле происходит в фоновом режиме для создания последнего бита, который отправляется через Ethernet?

Я понимаю, что, например, DNS-запрос выполняется для разрешения полного доменного имени на IP-адрес (уровень 7) или трехстороннее рукопожатие для установления соединения (уровень 4). Но как это происходит, пока бит строится? Содержат ли различные слои те данные, которые будут частью последнего бита, в то время как они сами отправляют запросы / данные через Ethernet для сбора соответствующей информации / установления соединений и т.д.? Как это работает?

Когда обсуждается модель OSI или модель TCP/IP, вещи обычно представляются в виде данных, которые последовательно строятся и передаются по уровням до тех пор, пока они не будут отосланы как бит, но я не смог найти более подробное объяснение что касается деталей, связанных с каждым аспектом, в простом примере, как подключение к веб-сайту.

Answer 1

В наши дни приложения используют абстрактные высокоуровневые библиотеки для работы с сетью, поэтому большая часть этого выполняется ОС автоматически. Чем ниже OSI, тем более он автоматичен и тем меньше кодеров это волнует. Поскольку ваш вопрос касается структур данных и уровней, вы все равно больше заботитесь о верхних уровнях, так как нижние - больше электротехники, встроенного программного обеспечения и драйверов, чем что-либо еще. на этом уровне это просто биты или электрические сигналы.

Уровень приложений делает намного больше, чем очевидно в модели OSI, поэтому первое, что вы должны понять, это то, что уровень приложений управляет всем. Фактическая работа по созданию структур данных на уровнях 3 и 4 выполняется методами (запрограммированными функциями), которые работают на этих уровнях, но прикладной уровень координирует каждую операцию и передает в каждый метод необходимые параметры, поэтому слои не они не "хранят" свои данные как таковые, и вещи не обязательно "передаются" на последующий уровень (хотя в некоторых случаях они в буквальном смысле слова). Вместо этого думайте об этом как о наборе вызовов функций, которые определяют задачу, так что вывод одной функции является вводом для другой. Дело в том, что локус контроля всегда находится на прикладном уровне.

Итак, как я сказал в своем комментарии, большинство современных приложений используют вариант стандарта API Berkley Sockets. Эта библиотека содержит методы, которые работают на уровнях OSI7, 4, 3 и подключается к API OS OS.

1. Приложение будет вызывать Sockets.Socket(type) для создания нового порта, и возвращается номер нового порта. Это функция layer4.

2. Приложение спросит ОС, какой у нее IP-адрес, и затем вызовет Sockets.Bind(newPort, localIPAddr, addrLen) чтобы присоединить новый сокет к IP-интерфейсу. Это функция layer3.

3. Приложение будет вызывать Sockets.Connect(newPort, remoteAddrandPort, addrlen) чтобы инициировать соединение через TCP Трехстороннее рукопожатие.

4. После того, как все это завершено, приложение может использовать Sockets.Send() и Sockets.Recv() для чтения и записи из и в сокет, как если бы это был поток ввода-вывода. Внутренне, Send()/Recv() вызывают частные методы, определенные в библиотеке сокетов, которые инкапсулируют данные на каждом уровне, используя выходные данные предыдущей структуры в качестве входных данных для следующего нижнего уровня, пока не сообщат локальному стеку IP отправлять пакет. В большинстве случаев приложения знают или не заботятся о чем-либо ниже уровня 3, а когда они действительно заботятся о слоях 3 или 4, то только для обеспечения допустимых значений параметров.

Приложение также отвечает за последовательность команд протокола. например, чтобы подключиться к суперпользователю, приложение должно взаимодействовать в последовательностях команд HTTP.

Чтобы получить страницу по умолчанию здесь на superuser.com, браузер должен построить последовательность:

GET / \HTTP/1.1;

Приложение может просто записать эту строку в порт, и она будет автоматически инкапсулирована в сегмент TCP, IP-пакет и кадр 802.11n и преобразована аппаратным способом в электрический сигнал.

Приложение может читать из сетевого потока ввода-вывода, чтобы получить ответ, подобный

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model ....

Затем браузер снимает 200 (значение, указывающее, что команда HTTP сработала, а разметка следует) и отображает страницу.

Таким образом, я не совсем удовлетворен этим ответом, потому что мне потребовались годы и годы как на создание сетей, так и на программирование, чтобы получить целостную мысленную картину того, как все это работает в реальности (в отличие от крайне абстрактного OSI), и я знаю, что Есть, по крайней мере, 3 различные точки зрения, которые вы можете рассмотреть, глядя на сетевое подключение. В этом случае обработка сигналов прямо, и похоже, что вы уже изучаете перспективы сетевых специалистов, так что, надеюсь, эта перспектива поможет вам лучше понять, где теория встречается с реальностью.

Редактировать:

Да, и поскольку вы упомянули DNS, большинство приложений используют методы Sockets getaddrinfo/getnameinfo для выполнения быстрого запроса DNS, принимая в качестве входных данных полное доменное имя. Эти методы внутренне создают, bind(), connect(), инкапсулируют дейтаграмму UDP (обратите внимание, что DNS обычно выполняется через UDP, хотя большинство систем можно настроить на использование TCP вместо этого) и отправляют его, прослушивают ответ, анализируют его в структура, и вернуть его в приложение все одним вызовом. это довольно аккуратно. Фактически, теперь, когда я думаю об этом, это воплощение того, что означает Инкапсуляция.

Answer 2

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

Но как это происходит, пока бит строится?

Вы предложили свой ответ со следующим вопросом.

Содержат ли различные слои те данные, которые будут частью последнего бита, в то время как они сами отправляют запросы / данные через Ethernet для сбора соответствующей информации / установления соединений и т.д.?

Да.

Как это работает?

Пользователь сообщил веб-браузеру, что информация требуется с веб-сайта. Когда пользователь вводит этот адрес в адресную строку, сеть еще не задействована; Модель OSI считает, что это уровень OSI Model 7: Application Layer.

Веб-браузер указал, что небезопасная связь в порядке. (Если бы безопасность была необходима, HTTPS был бы сделан. Тем не менее, HTTP будет работать для обеспечения небезопасной связи.) Таким образом, HTTP - это то, как должно происходить взаимодействие (Уровень представления, Уровень 6, все еще обычно обрабатываемый приложением). HTTP не использует EBCDEC; для связи будет использоваться ASCII (еще одна деталь, относящаяся к уровню представления, OSI Model Layer 6.)

Надежное общение должно происходить. Мы будем использовать сеанс, поэтому разговор будет происходить через HTTP-соединение, которое может включать несколько пакетов. Идея такого подключения - это Session Layer (OSI Model Layer 5).

Транспортная связь позволяет нескольким разговорам (таким как множественные одновременные передачи данных) происходить на одном и том же IP-адресе. Когда есть входящие или исходящие данные, эти разговоры отслеживаются с помощью нескольких номеров "портов". Веб-браузер указывает, что он хочет общаться с TCP-портом 80 www.superuser.com. Указание номера порта входит в область Транспортного уровня (OSI MOdel Layer 4).

Приложение (веб-браузер) взаимодействует с «сетевым стеком TCP/IP», который обычно встроен в операционную систему (в наши дни ... во времена Windows 3.1 вам может понадобиться установить "Trumpet Winsock", стек сторонних производителей, либо используйте стек Microsoft, который можно установить вместе с MS Internet Explorer для Win 3.1).

Сетевой стек понимает, что "www.superuser.com" является сетевым именем. Таким образом, используется код резолвера. Это имя не находится в кэше "Resolution Name" ("resolver"), и при попытке найти его в "файле hosts" имя не отображается. Таким образом, DNS-запрос будет отправлен.

Ах, да, в вашем вопросе упоминались "http" и "DNS", поэтому этот ответ становится немного сложнее, если рассматривать как связь DNS, так и связь HTTP. Сначала мы рассмотрим связь с DNS, потому что именно это произойдет до того, как уровень 3 модели OSI будет иметь какое-либо отношение к любому трафику HTTP.

Решатель начинает процесс установления связи DNS. Компьютер получит ответ в виде дейтаграммы DNS (порт UDP 53, транспортный уровень, уровень 4).

DNS-сервер находится на компьютере. Мы будем притворяться, будто это на удаленном компьютере. Так что это будет связано с установлением связи с IP-адресом другого компьютера. Таким образом, будет использоваться IP-пакет (то есть сетевой уровень, уровень модели OSI 3). Ради интереса, скажем, это пакет IPv4 (нет причин, почему бы и нет). (На самом деле, я начал писать это как IPv6 ... Я решил вернуться к IPv4 для более коротких примеров адресов. Но вместо этого можно сделать IPv6.)

Давайте представим, что компьютер - это маршрутизатор. Основываясь на IP-адресе 3-го уровня, мы не хотим идти по маршруту, который отправит трафик наверх в спальню подростка. Мы хотим взять маршрут, который пойдет в Интернет. Этот пакет IPv4 может быть отправлен по беспроводной сети или по проводной сети. Мы решим использовать адрес IPv4, который использует проводную сеть.

Поскольку DNS-сервер находится в другой подсети, нам необходимо отправить трафик на шлюз. Поскольку у меня нет более конкретного маршрута (например, в спальню подростка), я буду использовать "шлюз по умолчанию", который используется всякий раз, когда нет более конкретной доступной опции. Знание того, какой способ отправки трафика является "маршрутизацией", является основной особенностью уровня 3.

Допустим, для этой связи будет использоваться проводная сеть. IP-пакет должен попасть на DNS-сервер (8.8.8.8, уровень 3), но таблица маршрутизации указывает, что такие соединения маршрутизируются через адрес шлюза в 198.51.100.1 (уровень 3). (Кстати, 198.51.100.1 - это не то, что вы должны использовать в реальной сети, но мне разрешено использовать его для этого примера, потому что я следую RFC 5737 разделу 3

Мы можем связаться с 198.51.100.1 с помощью фрейма Ethernet. Кэш ARP (эквивалент IPv4 для NDP IPv6) не содержит подробностей, поэтому нам потребуется кадр ARP WHO-HAS (эквивалентный обнаружению соседа IPv6), чтобы определить, куда должен быть отправлен кадр Ethernet. Это обнаружение соседей отправляет широковещательную рассылку Ethernet на FF-FF-FF-FF-FF-FF (IPv6 может использовать многоадресную рассылку как часть NDP), чтобы выяснить, кто имеет этот Ethernet-адрес. Когда ответ получен, информация попадает в кэш (кэш ARP ... если бы мы использовали IPv6, это был бы кэш NDP).

Теперь мы можем отправить кадр Ethernet в систему по адресу 192.168.0.1. Таким образом, «Сетевой стек TCP/IP» помещает дейтаграмму UDP в IP-пакет, который перейдет на IP-адрес 8.8.8.8, и инкапсулирует его в кадр Ethernet, который идет к 01-23-45-67-89-AB. , Этот кадр Ethernet отправляется на уровне 2.

Сетевой стек TCP/IP отправляет этот кадр Ethernet на уровне 2, обмениваясь данными с драйвером сетевой карты (который может связываться с Ethernet). Однако сетевой стек TCP/IP забывает о битах в этой дейтаграмме UDP. В конце концов, UDP ненадежен. Сетевой стек TCP/IP не выполняется с помощью HTTP-запроса, поскольку "распознаватель" все еще ожидает ответа на основе "исходного" сетевого адреса исходящего пакета UDP. Но сетевой стек TCP/IP не хранит копии битов, которые были ненадежно отправлены в этой дейтаграмме UDP. (Если UDP-датаграмма будет потеряна, я полагаю, что "преобразователь", вероятно, потерпит неудачу, и тогда веб-браузер может решить повторить попытку. В любом случае, часть "повторных попыток" не обрабатывается ненадежной частью заботы о дейтаграмме UDP.)

Драйвер Ethernet висит на пакете достаточно долго, чтобы гарантировать, что пакет не будет поврежден никакими коллизиями Ethernet на уровне модели OSI 1. Как только Ethernet передается без проблем, сетевой драйвер забывает об этом.

Шлюз по умолчанию получает кадр Ethernet. Поскольку это маршрутизатор, он перенаправляет трафик, а это значит, что ему нужно немного посмотреть на IP-пакеты, которые не адресованы ему самому. Я считаю это "беспорядочным". Маршрутизатор проверяет, куда должен идти трафик, и выполняет аналогичный процесс, чтобы передать трафик другому маршрутизатору. Пакет IP модифицируется уменьшением TTL на 1, и маршрутизатор использует уровень 2 для передачи трафика следующему маршрутизатору. Этот процесс повторяется через столько маршрутизаторов, сколько необходимо, и это должно работать нормально, пока уровень TTL не достигнет низкого уровня, и в этом случае ответ ICMP "TTL Exceeded" вернется. Для простоты остальная часть этого примера будет притворяться, что этого не произошло.

Позже, возможно, после многих тысяч миллисекунд, которые занимают миллионы мегагерц процессорного времени, сетевой драйвер (на компьютере с веб-браузером) замечает соединение Ethernet. Этот кадр Ethernet имеет MAC-адрес назначения (OSI Model Layer 2), который принадлежит этому компьютеру с веб-браузером. Кадр имеет поле протокола, которое говорит, что это IP-пакет; в частности, термин «IP-пакет» взят из старого стандарта и означает пакет IPv4 (OSI Model Layer 3). Поскольку адрес назначения соответствует этому компьютеру, компьютеру не нужно проверять, есть ли какое-либо программное обеспечение, работающее в "случайном режиме". Таким образом, сетевой драйвер отправляет его в сетевой стек TCP/IP. Пакет IP в конечном итоге содержит дейтаграмму UDP (уровень модели 4 OSI) от DNS-сервера. Таким образом, сетевой стек TCP/IP проверяет список открытых портов (что можно увидеть, выполнив команду «netstat -na» в Unix или Microsoft Windows). Список открытых портов проверяется на наличие порта "LISTENING", и выясняется, что распознаватель ищет ответ. Таким образом, сетевой стек TCP/IP отправляет эту дейтаграмму UDP в распознаватель.

Теперь, когда распознаватель выяснил, что www.superuser.com - 203.0.113.50 (например, разрешено в разделе 3 RFC 5737), сетевой стек TCP/IP может свободно создавать сегмент TCP, который будет содержать IP-пакет. это идет к 203.0.113.50. Первый IP-пакет разговора на самом деле не содержит какой-либо интересной полезной нагрузки и является лишь частью трехстороннего TCP-рукопожатия. После ответа часть обработки TCP сетевого стека TCP/IP отправит сегмент TCP внутри IP-пакета. Этот процесс очень похож на обработку дейтаграммы UDP, за исключением того, что когда сетевой стек TCP/IP принимает IP-пакет, содержащий сегмент TCP, и отправляет эти пакеты в сетевой драйвер (для обработки кадра Ethernet), TCP/ Стек IP-сети запоминает все содержимое этого TCP-пакета, пока пакет не будет подтвержден в ответном TCP-сегменте. Если пакет TCP будет потерян при передаче, в конечном итоге удаленный конец будет жаловаться или таймер истечения завершится, и пакет TCP/IP отправит другой сегмент TCP с дубликатом существенной полезной нагрузки. Эта попытка "повторить" - вот почему TCP называется "надежным".

На этот раз вместо ожидания дейтаграммы UDP, содержащей трафик DNS, который отправляется в распознаватель, сетевой стек TCP/IP ожидает ответа TCP. Какой-то случайный порт, например порт 12345, используется в качестве "исходного порта" первоначального запроса.

Исходящий сегмент TCP содержит запрос "GET", который является частью HTTP-сообщения, отправляемого веб-браузером.

Теперь давайте перенесемся через обработку IP-пакета (и кадра Ethernet).

После получения запроса веб-сервером веб-сервер отправит данные в веб-браузер. Это может произойти как несколько сегментов TCP. Веб-сервер запоминает содержимое каждого отправляемого им сегмента TCP, пока этот сегмент TCP не будет подтвержден компьютером, на котором запущен веб-браузер.

Когда компьютер с веб-браузером получает информацию от веб-сервера, он замечает кадры Ethernet (уровень 2 OSI), которые содержат IP-пакеты (уровень 3 OSI), которые содержат сегменты TCP (уровень 4 OSI), которые поступают из порта 80 TCP (на веб-браузер) к локальному TCP-порту, который прослушивает (например, 12345, упомянутый ранее). Сетевой стек TCP/IP поймет, что должен перейти в веб-браузер.

Веб-браузер обрабатывает информацию из соединения (уровень 5, сеанс), понимает, что трафик незашифрован (уровень 6, презентация), и не делает адресную строку красной (как если бы возникла проблема с безопасностью HTTPS), Выбор цвета адресной строки - это проблема "пользовательского интерфейса", которая считается частью уровня 7 7-уровневой модели OSI.