Почему нам нужны IP-адреса для общения в пределах локального сетевого сегмента?

Поскольку MAC-адреса могут использоваться только в пределах локального сетевого сегмента, мы используем IP-адреса для связи с другими сегментами через маршрутизаторы. Тем временем, для местных целей используется ARP для преобразования IP-адресов в MAC-адреса, а затем в разговоре используются MAC-адреса.

Это заставляет меня задуматься, почему мы вообще используем IP-адреса в локальной сети. Учитывая сценарий, в котором все системы находятся в одном подсети, можно сказать, что IP-адреса тогда избыточны, поскольку системы действительно используют только MAC-адреса для маршрутизации коммуникаций друг с другом.

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

Короче говоря, нет… вам не нужны IP-адреса для подключения машин в одной сети. Есть несколько примеров протоколов, таких как IPX или протоколы Banyan.

Проблема использования аппаратных адресов лучше всего описывается так:

Представьте на мгновение, что компьютеры — это люди в комнате… (все приклеены к одному месту и не могут двигаться) Если Боб хочет поговорить с Сьюзи… он кричит: “Эй, Сюзи”… и Сюзи отвечает… и начинается разговор. Здорово, правда? Конечно… в малом масштабе это работает довольно хорошо и на самом деле используется регулярно в некоторых сетевых протоколах между двумя (или несколькими) устройствами. (Многие протоколы высокой пропускной способности используют неприборные IP протоколы, потому что они намного “проще” и тщательно подогнаны под задачу.) Интернет (в том виде, как мы его знаем сегодня) — это не просто два… или несколько человек, говорящих друг с другом напрямую. Интернет — это буквально МИЛЛИАРДЫ устройств. Если бы все они были помещены в одну “комнату” (сетевой сегмент)… Представьте, что произойдет, если Боб захочет поговорить с Сюзи. Боб закричит: “Эй, Сюзи!”… и голос Боба потеряется в толпе. (Построить комнату, чтобы поместить МИЛЛИАРДЫ людей, тоже нелепо.)

По этой причине сети сегментируются на “меньшие комнаты”, которые позволяют людям, находящимся в одном сегменте (комнате), напрямую общаться друг с другом, но людям вне комнаты необходим какой-то маршрутизатор, чтобы передавать сообщения от одной комнаты к другой. Но огромное количество комнат означает, что вам нужна какая-то схема адресации, чтобы различные маршрутизаторы посередине знали, как доставить сообщение от Боба к Сюзи. С помощью протокола IP каждому “помещению” назначается подсеть, и маршрутизаторы получают инструкции, как передавать сообщение из одной комнаты в следующую. Например, если адрес Боба 1.1.1.1, а адрес Сюзи 2.2.2.2, и подсеть Боба 1.1.1.0/24 (что означает, что первые 3 байта его адреса должны совпадать, чтобы это было в его комнате), Боб должен передать свое сообщение маршрутизатору, чтобы оно могло быть передано в “комнату” Сюзи. Боб знает, что его маршрутизатор — это 1.1.1.2, поэтому он передает сообщение маршрутизатору, а маршрутизатор передает его другим маршрутизаторам посередине, пока сообщение не будет передано маршрутизатору Сюзи по адресу 2.2.2.1, который передает сообщение непосредственно Сюзи… и Сюзи может отправить ответ обратно Бобу тем же способом.

Компьютеры в одной и той же подсети на самом деле общаются друг с другом напрямую, используя MAC-адреса. Все начинается с того, что отправляется запрос ARP (ARP = Протокол Разрешения Адресов), что означает, что он кричит: “У кого есть адрес X.X.X.X?”… и тот, у кого есть этот адрес, отвечает, и с этого момента они продолжают говорить друг с другом напрямую.

(Я могу продолжить эту аналогию и объяснить гораздо больше о том, как работает Интернет, если вам действительно интересно.)

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

Более того, MAC-адреса специфичны для Ethernet, и хотя сейчас это де-факто метод инкапсуляции уровня 2, это не всегда было так, и вы никогда не знаете, не появится ли что-то лучше в будущем.

Довольно просто, делать то же самое для людей внутри вашего сетевого сегмента гораздо проще и требует очень мало дополнительных затрат, чем за пределами вашего сетевого сегмента.

Некоторые другие возможные причины

• Вам может понадобиться использовать IP для помощи в запоминании, что-то вроде “маршрутизатор заканчивается на .1“
• Вам может понадобиться запустить две сети на одном сегменте, которые не будут обмениваться данными (вы можете сделать это с IP через подсети)
• MAC-адреса не так легко запомнить.

В теории, нет причин, почему мы не могли бы просто использовать MAC-адреса Ethernet для общения на сегменте LAN.

На самом деле, как кто-то упомянул выше, это и есть способ: ваш ноутбук отправляет запрос ARP, говоря: “Я 11:22:33:aa:bb:cc, мой IP 10.10.10.20 – у кого 10.10.10.10?”, ваш NAS отвечает: “Я x.x.x.10 и мой MAC-адрес aa:bb:cc:11:22:33!”. Последующие пакеты между вашим ноутбуком и NAS будут иметь соответствующий MAC-адрес в заголовке Ethernet-рамы.

Итак, почему я говорю “в теории”?

Ну, на практике стандарт Ethernet предоставляет механизм, с помощью которого устройства могут находить друг друга на сетевом сегменте; это полезно, потому что это означает, что устройства, которые не участвуют в сетевом разговоре, не должны его слушать, и что коммутаторы могут отслеживать, к какому физическому порту подключено каждое устройство. Это уменьшает количество сетевых шумов в сегменте и увеличивает общую пропускную способность сети.

К сожалению, есть много отличных возможностей, которые предоставляет стек TCP/IP, чего не обеспечивает Ethernet, и на то есть веские причины. Эти отсутствующие функции должны были бы быть реализованы разработчиками каждого сетевого приложения, что является огромной работой, когда в каждой современной операционной системе есть, по крайней мере, стек TCP/IPv4, а также, вероятнее всего, стек IPv6.

Существует также простой факт, что простые сети часто не остаются простыми — рано или поздно вы захотите подключить свою LAN к интернету или другой LAN; IP маршрутизируемый, а MAC-адреса — нет.

Самая убедительная причина для меня — это взаимодействие. Конечно, вы можете сделать исключение для локальной сетевой связи, устранив уровень 3. Но кто получит выгоду от этого исключения?

Например, если вы хостите веб-страницу где-то в своей локальной сети и хотите просмотреть эту страницу из той же сети. Что должно произойти?

Сначала вы вводите доменное имя “server.example.com” в адресной строке. Затем вы (т.е. браузер) делаете DNS-запрос, чтобы разрешить это доменное имя в IP-адрес. В конечном итоге этот DNS-запрос попадает на DNS-сервер, который хостит “example.com”. И что дальше?

DNS-сервер не вернет MAC-адрес (я имею в виду, как он вообще узнает, что клиент и сервер находятся в одной сети)?

Таким образом, он должен вернуть IP-адрес. И тогда, Та-дам! мы вернулись к уровню 3.

Одним аспектом, который еще не был упомянут: хотя в теории сетевая карта действительно получает все пакеты, адресованные к ее MAC (и широковещательные… и она получает больше, если находится в режиме прослушивания…), на практике в основном только пакеты, содержащие фрагменты IP (TCP, UDP), отправляются в пользовательские приложения на основе номера порта (что в основном является последней частью информации о маршрутизации). Если вы смелый программист, вы, вероятно, можете сказать своей ОС отправлять все пакеты в ваше приложение и фильтровать их самостоятельно (как это делает Wireshark). Но пользовательский стек программного обеспечения на самом деле не предназначен для разработки приложений, использующих только пакеты уровня 2, и операционные системы не оптимизированы для такого стиля. Это было бы также очень неэффективно, если бы тысячи процессов получали копии всех рамок Ethernet, чтобы понять, интересны они их содержимым или нет.