9939
Комментарий:
|
11272
|
Удаления помечены так. | Добавления помечены так. |
Строка 24: | Строка 24: |
### Дальше идет кусок про более высокие уровни + про отношения между уровнями. Это нужно будет отнести в другой раздел. |
|
Строка 28: | Строка 30: |
## === Независимость уровней TCP/IP === ## не забыть и это тоже. ## |
|
Строка 30: | Строка 36: |
Вот мы решили передать данные, скармливаем их программе, например, ftp-клиенту, он оформляет некоторым образом их соответствии с протоколом ftp. Далее движемся вниз по уровням. В тот момент, когда возникает необходимость осуществить ftp-обмен, этот массив режется на фрагменты в соответствии с требованиями tcp. Каждый фрагмент передается вниз, на уровень tcp и заворачивается там в tcp-пакет -- к нему добавляются служебные данные, специфичные для tcp. На этом дело не останавливается. Допустим, по правилам маршрутизации нашего сетевого уровня выяснилось, что следующий компьютер --- это один из наших соседей. Тогда каждый из tcp-пакетов режется на куски того размера, который диктует нам уровень ip, и передается ему вниз, где каждый кусок заворачивается в ip-пакет, в котором содержатся еще служебные данные, характерные для ip. И снова повторяется эта операция --- разрезания и заворачивания частей в пакеты более низкого уровня, в данном случае, например, ethernet-фреймы. | Инкапсуляция протоколов выражается в том, что данные, требуемые для передачи в рамках работы протокола некоторого уровня инкапсулируются в пакеты протокола более низкого уровня. |
Строка 32: | Строка 38: |
Таким образом, происходит инкапсуляция пакетов от протоколов верхнего уровня в пакеты протоколов более низких уровня. | Например, пусть у нас работает FTP-клиент. Будучи сам на прикладном уровне, он приготовил FTP-специфический массив данных, например, большой файл и собирается его передать, воспользовавшись услугами нижнего, транспортного уровня (допустим, TCP). Для передачи по TCP этот массив должен быть разбит на фрагменты определенного размера. Каждый такой фрагмент инкапсулируется в TCP-пакет и снабжается дополнительной служебной информацией, характерной для протокола TCP. На этом дело не останавливается. Для передачи каждого TCP-пакета средствами IP он должен быть, в свою очередь разбит на фрагменты определенного размера (характерного для IP). Каждый из этих фрагментов инкапсулируется в IP-пакет и снабжается своей служебной информацией, на этот раз характерной для протокола IP. Допустим, по правилам маршрутизации выяснилось, что нам нужно передать этот пакет нашему ближайшему соседу по сети. Операция повторяется снова --- IP-пакет разбивается и инкапсулируется в несколько пакетов физического уровня, например, ethernet-фреймов. |
Строка 34: | Строка 41: |
После фактической передачи происходит обратное путешествие: этот фарш восстанавливается обратно: из нескольких eth-фреймов получаем ip-пакет, узнаём, допустим, что его надо отправтиь дальше, запаковываем и отправляем обратно. И так до целевой машины, котрая из нескольких ip-пакетов соберёт tcp-пакет и обработает его на уровне tcp и, возможно выше. | После передачи фреймов по физическому каналу происходит обратное преобразование: из "фарша" восстанавливается "корова": протокол физического уровня Ethernet составляет из нескольких своих фреймов некоторый набор данных, который передает на уровень выше. Протокол IP в этом наборе данных узнаёт IP-пакет и интерпретирует служебную информацию, в частности IP-адрес. Предположим, по правилам маршрутизации IP-пакет надо отправить следующему соседу. Тогда он снова передаётся на физический уровень, где инкапсулируется в несколько фреймах, и т.д. Если IP-протокол решит, что именно эта машина является получателем, то он из нескольких IP-пакетов соберёт некоторый набор данных, и передает его на уровень TCP, который узнает в этом наборе TCP-пакет и обработает его подобающим образом. |
Физический и канальный уровни
Исследуем сеть на физическом уровене. Пусть у нас сеть 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 |
25 |
1 |
1 |
1 |
|
1 |
02.07.2008 |