11272
Комментарий:
|
11483
|
Удаления помечены так. | Добавления помечены так. |
Строка 18: | Строка 18: |
После {{{brd}}} указан еще один MAC-адрес --- это так называемый broadcast (широковещательный) адрес. Он используется для того, чтобы послать некоторый фрейм сразу всем адаптерам, подключенным к данной среде. У {{{lo}}} его по понятным причинам нет, а у {{{eth0}}} он состоит из все единичек в двоичном представлении. | После {{{brd}}} указан еще один MAC-адрес --- это так называемый broadcast (широковещательный) адрес. Он используется для того, чтобы послать некоторый фрейм сразу всем адаптерам, подключенным к данной среде. У {{{lo}}} его по понятным причинам нет, а у {{{eth0}}} он состоит из все единиц в двоичном представлении. |
Строка 20: | Строка 20: |
Сравнение mac-адреса получателя фрейма и mac-адреса сетевого адаптера делается на аппаратном уровне, поэтому операционная система, которая общается с адаптером со своей стороны, даже не узнает, что какие-то фреймы он отбросил как чужие. | Сравнение mac-адреса получателя фрейма и mac-адреса сетевого адаптера производится на аппаратном уровне, поэтому чужие пакеты адаптер может отбросить самостоятельн, и операционная система об этом даже не узнает. |
Строка 44: | Строка 44: |
В некоторых случаях может быть так, что ip-пакеты собираются до tcp, чтобы решить, что делать дальше. Это налдо всегда иметь в виду. | ## Следующий абзац требует расшифровки в буквальном смысле. В аудиозаписи было бы яно. |
Строка 46: | Строка 46: |
Главное, что известно: фактически по сети передаётся существенно больше данных, чем запланировано на верхнем уровне. | В некоторых случаях может быть так, что ip-пакеты собираются до tcp, чтобы решить, что делать дальше. Это надо всегда иметь в виду. Инкапсуляция протколов приводит к накладным расходам: фактически по сети передаётся существенно больше данных, чем было запланировано к передаче на прикладном уровне. |
Строка 53: | Строка 56: |
|| 25 || 1 || 1 || 1 || || 1 || PavelSutyrin || 02.07.2008 || | || 30 || 1 || 1 || 1 || || 1 || PavelSutyrin || 02.07.2008 || |
Физический и канальный уровни
Исследуем сеть на физическом уровене. Пусть у нас сеть 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
Видно два интерфейса, lo, и eth0. В Linux-машине, даже если нет физических сетевых адаптеров, один сетевой интерфейс есть всегда (впрочем, если может и не быть, в том случае, когда поддержка сети не включена в ядро) --- это так называемый loopback, обратная петля. Через него можно подключиться к этой же самой машине. Это удобно, например, для отладки программ, работающих с сетью, когда самой сети под рукой нет. Традиционно интерфейсы называются ethN, где N -- номер, и нумеруются с 0, т.е. eth0, eth1, и т.п.
После link/loopback и link/ether указаны MAC-адреса интерфейсов. MAC-адрес --- это 6 байт, которые записываются в шестнадцатеричном виде через :. Видно, что у интерфейса lo его нет (нулевой), а у eth0 --- вполне определенный. Физическим сетевым адаптерам этот адрес присваивается производителем. Первые три байта составляют код производителя, оставшиеся три байта --- код сетевого адаптера. Современные адаптеры позволяют его изменять, но этого делать не рекомендуется.
После brd указан еще один MAC-адрес --- это так называемый broadcast (широковещательный) адрес. Он используется для того, чтобы послать некоторый фрейм сразу всем адаптерам, подключенным к данной среде. У lo его по понятным причинам нет, а у eth0 он состоит из все единиц в двоичном представлении.
Сравнение mac-адреса получателя фрейма и mac-адреса сетевого адаптера производится на аппаратном уровне, поэтому чужие пакеты адаптер может отбросить самостоятельн, и операционная система об этом даже не узнает.
В некоторых случаях бывает полезно перевести адаптер в так называемый promiscuous (неразборчивый) режим. В этом случае адаптер будет принимать все пакеты, которые пробегают мимо него, в частности, чужие. Вообще говоря, именно таким спсобом сканируют чужой траффик и выковыривают пароли... Допустим, Вы вчера посидели в аське, а завтра в аське сидит Петька. Есть, впрочем, метод выявляения таких шпионов: пишется программа, которая генерит немыслимое количество фреймов, которые предназначены никому. Адаптеры в обычном режиме их спокойно проигнорирут, а вот если в сети есть узел, адаптер которого прослушивает весь траффик, то характеристики его заметно изменятся, он будет хуже отвечать на пинг, и т.п.
Родилось определение, что локальная сеть --- это множество узлов, которые видят друг друга в рамках одной среды передачи данных. А то спорят все, какая локальная, какая не локальная.
Далее поднимаемся на уровень сетевой. Тут мы должны выполнить две задачи: перенумеровать все компьютеры в интернете, чтобы отличать их друг от друга, и организовать маршрутизацию данных от одного компьютера к другому, т.к. вообще говоря, между отправителем и получателем данные могут идти по нескольким СПД.
Инкапсуляция протоколов 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, чтобы решить, что делать дальше. Это надо всегда иметь в виду.
Инкапсуляция протколов приводит к накладным расходам: фактически по сети передаётся существенно больше данных, чем было запланировано к передаче на прикладном уровне.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
30 |
1 |
1 |
1 |
|
1 |
02.07.2008 |