Изменения в «PspoClasses/080702/03Ethernet»

Физический и канальный уровни

Исследуем сеть на физическом уровене. Рассмотрим сеть Ethernet. Увидеть имеющиеся в системе сетевые интерфейсы можно воспользовавшись командами ip link или ip l.

Пример

[root@demo ~]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:27:50:7a:b1 brd ff:ff:ff:ff:ff:ff

В данном примере в системе есть 2 интерфейса:lo и eth0.

Даже в отсутствие физических сетевых адаптеров,в Linux имеется один сетевой интерфейс -- так называемый loopback (обратная петля). Этот интерфейс предоставляет возможность подключения к самому себе. Подобное может быть удобно, например, при отладке работающих с сетью программ в условиях отсутствия сети из нескольких компьютеров.

Традиционно интерфейсы Ethernet-адаптеров именуются ethN: eth0, eth1, и т.п.

После строк link/loopback и link/ether в результатах команды ip link указаны MAC-адреса соответствующих интерфейсов. MAC-адрес состоит из 6 байт. Обычно записывается в шестнадцатеричном виде, байты отделяются :.

У интерфейса lo(обратной петли) MAC-адрес нулевой.

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

После строки brd указан еще один MAC-адрес --- это так называемый broadcast (широковещательный) адрес. Он используется для того, чтобы послать некоторый фрейм сразу всем адаптерам, подключенным к данной среде. У lo его по понятным причинам нет, а у eth0 он состоит из все единиц в двоичном представлении.

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

В некоторых случаях бывает полезно перевести адаптер в так называемый promiscuous (неразборчивый) режим. В этом случае адаптер будет принимать для операционной системы все пакеты, которые передаются по сети, в частности те, которые не адресованы ему (и не широковещательные). Вообще говоря, именно таким спсобом сканируют чужой траффик и из него выделяют разного рода пароли. Есть, впрочем, и метод выявляения таких шпионов: пишется программа, которая генерирует большое количество фреймов, которые адресованы несуществующим получателям. Адаптеры, работающие в обычном режиме, их незаметно проигнорирут, а если в сети есть система, адаптер которой прослушивает весь траффик, то её наблюдаемые свойства изменятся: она станет хуже отвечать на пинг, и т.п.

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

Сетевой уровень

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

1. Однозначно идентифицировать все компьютеры в глобальной сети, чтобы их адресовать и отличать друг от друга,
2. Организовать маршрутизацию данных от одного компьютера к другому через некоторое количество промежуточных узлов.

Инкапсуляция протоколов TCP/IP

Инкапсуляция протоколов выражается в том, что данные, требуемые для передачи в рамках работы протокола некоторого уровня инкапсулируются в пакеты протокола более низкого уровня.

Например, пусть у нас работает FTP-клиент. Будучи сам на прикладном уровне, он приготовил FTP-специфический массив данных, например, большой файл и собирается его передать, воспользовавшись услугами нижнего, транспортного уровня (допустим, TCP). Для передачи по TCP этот массив должен быть разбит на фрагменты определенного размера. Каждый такой фрагмент инкапсулируется в TCP-пакет и снабжается дополнительной служебной информацией, характерной для протокола TCP. На этом дело не останавливается. Для передачи каждого TCP-пакета средствами IP он должен быть, в свою очередь разбит на фрагменты определенного размера (характерного для IP). Каждый из этих фрагментов инкапсулируется в IP-пакет и снабжается своей служебной информацией, на этот раз характерной для протокола IP. Допустим, по правилам маршрутизации выяснилось, что нам нужно передать этот пакет нашему ближайшему соседу по сети. Операция повторяется снова --- IP-пакет разбивается и инкапсулируется в несколько пакетов физического уровня, например, ethernet-фреймов.

После передачи фреймов по физическому каналу происходит обратное преобразование: из "фарша" восстанавливается "корова": протокол физического уровня Ethernet составляет из нескольких своих фреймов некоторый набор данных, который передает на уровень выше. Протокол IP в этом наборе данных узнаёт IP-пакет и интерпретирует служебную информацию, в частности IP-адрес. Предположим, по правилам маршрутизации IP-пакет надо отправить следующему соседу. Тогда он снова передаётся на физический уровень, где инкапсулируется в несколько фреймах, и т.д. Если IP-протокол решит, что именно эта машина является получателем, то он из нескольких IP-пакетов соберёт некоторый набор данных, и передает его на уровень TCP, который узнает в этом наборе TCP-пакет и обработает его подобающим образом.

В некоторых случаях может быть так, что ip-пакеты собираются до tcp, чтобы решить, что делать дальше. Это надо всегда иметь в виду.

Инкапсуляция протколов приводит к накладным расходам: фактически по сети передаётся существенно больше данных, чем было запланировано прикладном уровне.

Сведения о ресурсах