| B.1. Классификация сетевых протоколов | ||
|---|---|---|
 | Приложение B. Некоторые сведения о стеке протоколов TCP/IP |  |
| B.1. Классификация сетевых протоколов | ||
|---|---|---|
| | Приложение B. Некоторые сведения о стеке протоколов TCP/IP | |
Для классификации сетевых протоколов применяют так называемую эталонную семиуровневую модель OSI (см. [url://wiki-OSI-ru]).
Сетевая модель OSI (англ. Open Systems Interconnection Reference Model — модель взаимодействия открытых систем) — абстрактная модель для сетевых коммуникаций и разработки сетевых протоколов.
Модель разбивает сетевые протоколы на семь уровней:
Физический уровень предназначен непосредственно для передачи сигнала. В протоколах физического уровня описывается, например, как должен быть устроен провод (витая пара) для того, чтобы он гарантированно пропускал сигнал в стандарте Ethernet 100base-TX: толщина отдельных жил, их сопротивление, частота обвива, минимально расстояние от провода до силового кабеля, максисмальное количество витков в бухте и минимальный радиус бухты, длина провода от ретранслятора до ретранслятора количество соединений типа шнур-розерка, способ разводки жил в разъёме RJ45.
На физическом уровне работают концентраторы и репитеры (они же ретрансляторы). Назначение репитеров состоит в том, чтобы усиливать сигнал. Они нужны в том случае, если надо передать сигнал дальше чем это предусмотрено в стандарте. Концентратор (так же известный как hub) нужен для того, чтобы не только усиливать сигнал, но и передавать его из одного провода в несколько других, таким образом, хаб нужен для объединения нескольких устройств Ethernet в сегмент.
На канальном уровне происходит упаковка сигналов в кадры (frames). Действует контроль ошибок. В заголовке кадра присутствует информация об адресате в виде его аппаратного адреса (MAC-адрес).
На данном уровне работают коммутаторы (switch), мосты (bridge) и, конечно, собственно Ethernet-адаптеры (сетевые карты).
Заметим, что раз на данном уровне появилось понятие адреса,
следовательно должна существовать маршрутизация. Канальная
маршрутизация выполнена на аппаратном уровне. Коммутатор знает
какой адрес за каким портом (разъёмом RJ45) находится и высылает
кадр через данный порт. Если кадр адресован на специальный
аппаратный адрес ff:ff:ff:ff:ff:ff,
то он доставляется всем адресатам (т.н. широковещательный адрес).
Если сеть собрана не на коммутаторах, а на концентраторах (т.е. не на switch'ах, а на hub'ах; для такой сети есть меткое жаргонное выражение «похабная сеть»), все кадры доставляются всем. Такая организация плоха не только с точки зрения безопасности, но, главным образом, с точки зрения производительности. Если два устройства Ethernet одновременно посылают в сегмент кадры, то произойдёт коллизия — оба кадра пропадут. Будет выполнена повторная отправка кадров. Для того, чтобы коллизия не повторилась, повторная отправка происходит с задержкой на случайный промежуток времени. Чем больше устройств в сети, тем выше вероятность коллизии. Про устройства, которые могут войти в подобный конфликт, говорят, что они находятся в одном «домене коллизий». Таким образом, главное преимущество switch'ей перед hub'ами состоит в том, что они дробят сеть на множество незначительных доменов коллизий, тем самым существенно повышая производительность сети.
По поводу безопасности следует сказать следующее: сеть устроенная на hub'ах, позволяет всем слушать всех. В такой сети любой сетевой интерфейс может принять кадр предназначенный не ему и, тем самым, подслушать важную информацию. Иногда администраторы используют hub'ы в сети с диагностической целью (в последнее время найти hub не так то просто, так как они фактически сняты с производства и повсеместно заменяются на switch'и). Однако, было бы ошибкой думать, что использование switch'ей является гарантией отсутствия подслушивания в сети. Во-первых, MAC'адрес легко подделать програмным образом, во-вторых в системе, где работает протокол ARP (см. ниже) можно «подсунуть» свой MAC-адрес вместо адреса машины, трафик с которой интересует атакующего, и осуществить атаку типа man in the middle. (См. http://www.monkey.org/~dugsong/dsniff/faq.html)
Для мониторинга заголовков канального уровня в программе
tcpdump(1) предусмотрена опция
-e. (См. Раздел 6.11, «Демонстрация основных навыков работы с утилитой
tcpdump(1)»).
На данном уровне функционируют протоколы IP, IPv6, ARP, RARP и некоторые другие, однако нас здесь будут интересовать лишь эти четыре.
Протокол ARP предназначен для того, чтобы преобразовывать адреса IP в MAC адреса. Таким образом, его предназначение состоит в том, чтобы обеспечить взаимодействие между сетевым и канальным уровнями, причём не любого сетевого протокола, а именно IP (не IPv6).
Когда у хоста появляется необходимость передать кадр с одного сетевого интерфейса на другой сетевой интерфейс другого хоста, он сверяется со своей маршрутной таблицей (алгоритм работы с маршрутной таблицей описан далее) и решает находится ли хост назначения поблизости, то есть непосредственно в зоне досягаемости, или между ними есть роутер (маршрутизатор). В первом случае надо направить кадр непосредственно на сетевой интерфейс получателя, во втором на данный роутер, который в свою очередь будет сам решать задачу о том, куда ему направить данный Ethernet кадр. В обоих случаях надо превратить IP адрес в аппаратный MAC адрес, только в первом случае это будет IP назначения, а во втором IP маршрутизатора.
Для того, чтобы узнать MAC адрес по IP хост должен послать
широковещательный запрос на MAC-адрес ff:ff:ff:ff:ff:ff. Данный запрос
«слышат» все сетевые интерфейсы данного сегмента и
тот интерфейс, которому соответствует данный IP адрес должен
ответить, т.е. выслать свой MAC адрес:
![[*]](images/button-yellow.png)
B.1.1. Физический уровень OSI
# tcpdump -i rl0 -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
14:53:52.850637 arp who-has 192.168.25.158 tell 192.168.25.1
14:53:52.850695 arp reply 192.168.25.158 is-at 00:50:22:b0:7f:39
В приведённом примере машина 192.168.25.1 выясняла аппаратный
адрес машины 192.168.25.158.
Чтобы система не делала ARP запросы при каждой попытке отправить кадр, заводится некоторый ARP кеш, в котором находятся записи соответствия между IP адресами и MAC адресами. Обычно время жизни записи в этом кеше — 2 минуты. Даже в сильно нагруженной сети ARP запросы в норме совершаются 1 или 2 раза в секунду. Таким образом, сам по себе протокол ARP не нагружает систему, однако он уязвим с точки зрения безопасности: запрос ARP «слышат» все машины, в том числе и предполагаемый злоумышленник (конечно, если ему удалось проникнуть в сегмент сети), ничто не мешает злоумышленнику сформировать ложный ответ и, таким образом, перехватить трафик. Для борьбы с этим видом атаки существует множество разных способов, в том числе, можно использовать статические ARP таблицы и попросить сетевой интерфейс отключить у себя ARP протокол и не делать ARP запросов, а так же не отвечать на них.
Reverse ARP, обратный ARP протокол служит для того, чтобы по имеющемуся MAC адресу узнать IP адрес. Этот протокол используется в бездисковых машинах, загружающихся по сети. Первым делом такая машина должна узнать свой IP адрес, и параметры сети, чтобы она могла обратиться по сети, допустим к TFTP серверу, с которого она будет скачивать загрузочную запись. Единтсвенное, что знает о себе эта машина — её MAC адрес. Она посылает в сеть широковещательный запрос с поиском RARP сервера и спрашивает у него, какой IP адрес будет ей соответствовать, если у неё вот такой MAC адрес. Это не тоже самое, что DHCP, хотя смысл похожий.
Протокол IP предназначен для передачи по сети пакетов IP. В соответствии с данным протоколом, на основании маршрутной таблицы, выбирается сетевой интерфейс через который должны передаваться данные, затем осуществляется ARP запрос (см. выше) и выясняется MAC адрес назначения, из пакета формируется кадр, а далее работает канальный уровень модели OSI.
Маршрутная таблица, это таблица в ядре, в которой сказано через какой интерфейс надо посылать пакеты в ту или иную сеть, а так же, надо ли высылать пакеты непосредственно хосту получателю или их надо передать через следующий маршрутизатор, т.е. чей MAC адрес надо использовать, конечного хоста или следующего маршрутизатора. Всё это подробно освящается в Раздел 6.1.2.1, «Таблица маршрутизации».
Протокол IP предназначен для передачи пакетов, задача формирования пакетов, контроль ошибок, в функции протокола IP не входят. Это прерогатива более высокоуровневых протоколов, таких как TCP, UDP, ICMP.
В Раздел 6.11, «Демонстрация основных навыков работы с утилитой tcpdump(1)» приводится листинг программы tcpdump(1) с перехватом двух ICMP пакетов. На этом примере подробно описано из чего состоит заголовок пакета IP.
Задачи протокола IPv6 те же, что и у IP, однако механизм их реализации иной. В частности протокол ARP не используется протоколом IPv6, его функции IPv6 берёт на себя сам, производя запросы Router Solicition. Протокол подробно описан в Раздел 6.10, «Понимание теории адресации IPV6».
На транспортном уровне нас будут интересовать в первую очередь протоколы ICMP, UDP и TCP.
Протокол ICMP служит для передачи служебных сообщений. Протокол описан в [RFC-792]. Существует перевод данного RFC на руский язык: [RFC-792-ru].
Таблица B.1. Типы сообщений ICMP
| Код | Описание | |
|---|---|---|
| 0 | Echo Reply | ответ на запрос эхо |
| 3 | Destination Unreachable | адресат недостижим |
| 4 | Source Quench | приостановка отправителя |
| 5 | Redirect | переадресация |
| 8 | Echo | эхо-запрос |
| 11 | Time Exceeded | превышение контрольного времени |
| 12 | Parameter Problem | проблемы с параметрами |
| 13 | Timestamp | штамп времени |
| 14 | Timestamp Reply | ответ на запрос штампа времени |
| 15 | Information Request | запрос информации |
| 16 | Information Reply | ответ на запрос информации |
| Примечание: в некоторых других, более поздних RFC могут быть добавлены дополнительные коды ICMP. Например в RFC 950 добавлены сообщения Address Mask Request (код 17) и Address Mask Reply (код 18) | ||
Название протокола ICMP расшифровывается как Internet Control Message Protocol, таким образом, протокол претендует на то, чтобы контролировать за функционированием Интернета. Примером может быть сообщение ICMP redirect. Пусть есть сеть в которой есть три машины A, B и C. Машина C является роутером (маршрутизатором), но у машины A в качестве маршрутизатора по каким-то причинам прописана машина B. В этом случае, когда машина A попробует связаться с внешним миром (например с машиной D), она обратится к машине B, а та вернёт ей ICMP redirect сообщение, с тем чтобы на адрес D машина A ходила напрямую через C. Таким образом, в данном случае, сообщения ICMP влияют на внутренние таблицы маршрутизации.
Наиболее изветсные сообщения ICMP, это пожалуй echo request и echo reply. Обычно они используются в целях тестирования. В Раздел 6.4.2, «traceroute(1)» рассказывается как программа traceroute(8) с их помощью определяет маршрут от точки до точки.
Протокол UDP служит для передачи данных без коррекции ошибок. Есть целый класс данных в которых скорость передачи данных намного важнее качества. Например потоковое видео и аудио. Клиент переживёт потерю несколких букв, но замедление потока непростит. Другой пример — система DNS. Серверы DNS обслуживают десятки тысяч запросов в секунду. Гарантированная доставка в таких условиях просто невозможна, так как контроль ошибок очень ресурсоёмок (см. ниже, описание протокола TCP).
В задачу протокола UDP входит разбиение потока данных на пакеты. Каждый пакет имеет заголовок в котором указаны IP (или IPv6) адреса источника и назначения и порты источника и назначения. Номера портов идентифицируют программы на хосте источнике и на хосте назначения между которыми осуществляется передача данных.
Протокол UDP действует по принципу «выстрелил и забыл». Он не только не гарантирует доставку пакетов, но даже не гарантирует, что доставленные пакеты придут в том же порядке, в котором они были высланы. Тем не менее, в надёжных сетях во имя роста производительности можно в некоторых приложениях использовать протокол UDP. Одно время сетевая файловая система NFS была основана на протоколе UDP, а контроль ошибок осуществлялся на более высоких уровнях OSI. Однако в настоящий момент от этой практики отказались.
И наконец, протокол TCP отличается от протокола UDP тем, что в нём действует механизм контроля ошибок. Для реализации этого механизма в заголовок добавлено дополнительное поле с флагами TCP. (Это не единственное усложнение в сравнении с UDP, но нас будет интересовать именно оно.) Каждый пакет TCP подтверждается пакетом с флагом ACK (acknowledgement). Один пакет с флагом ACK может подтверждать получение нескольких пакетов. В протоколе оговорена сложная процедура подтверждений, которые происходят при открытии и закрытии соединения.
Ниже приведена структура пакета TCP. В начале пакета идёт заголовок в котором указаны адреса и порты источника и назначения пакета, флаги TCP (в таблице указаны сокращённо по первой букве) и прочая служебная информация, затем собственно данные.
Таблица B.2. Формат TCP заголовка
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | a | b | c | d | e | f | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | a | b | c | d | e | f |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Source Port | Destination Port | ||||||||||||||||||||||||||||||
| Sequence Number | |||||||||||||||||||||||||||||||
| Acknowledgment Number | |||||||||||||||||||||||||||||||
| Data Offset | Reserved | W | E | U | A | P | R | S | F | Window | |||||||||||||||||||||
| Checksum | Urgent Pointer | ||||||||||||||||||||||||||||||
| Options | Padding | ||||||||||||||||||||||||||||||
| ... | |||||||||||||||||||||||||||||||
| Data | |||||||||||||||||||||||||||||||
Таблица B.3. Флаги TCP
| Флаг | Описание | |
|---|---|---|
| W | CWR | отправитель информирует получателя о замедлении пересылки (см. [RFC-3168]) |
| E | ECE | уведомление о перегрузке (см. Раздел C.2.2.4.2.5, «Явное уведомление о перегрузке (ECN)») |
| U | URG | поле срочного указателя задействовано |
| A | ACK | поле подтверждения задействовано |
| P | PSH | функция проталкивания |
| R | RST | перезагрузка данного соединения |
| S | SYN | синхронизация номеров очереди |
| F | FIN | нет больше данных для передачи |
Соединение TCP, в отличие от UDP, поддерживает понятие «сеанса связи». Это означает, что данные могут идти от источника к получателю одним потоком. Протокол гарантирует контроль ошибок. Данные не могут теряться или повторяться или обгонять друг друга. Для реализации этого требовния организуется ответный трафик от получателя к отправителю, в котором получатель отчитывается о том, какие пакеты он получил и сообщает их контрольные суммы. Для этого высылаются пакеты с выставленным флагом ACK.
Приведённая схема иллюстрирует однонаправленный поток данных. Т.е. даже для однонаправленного потока данных требуется передача пакетов в обе стороны. Между тем, большинство соединений TCP двунаправленны, так как протоколы уровня приложений (HTTP, SMTP и т.п.) передают данные в обе стороны. Так, если браузер должен скачать некоторый ресурс, то со стороны браузера посылается запрос GET <имя ресурса>, а со стороны сервера собственно ресурс. Рассмотрим как открывается такое двунаправленное соединение.
Сперва одна из сторон, будем называть её «клиент» посылает другой строне («серверу») пакет с выставленным флагом SYN. Это своего рода заявка на открытие соединения.
Сервер должен подтвердить получение этого пакета и выслать в ответ пакет с выставленным флагом ACK. Но поскольку соединение должно быть двунаправленным, он должен тоже выслать клиенту пакет с заявкой на открытие соединения, т.е. с флагом SYN. Эти два пакета, с флагами ACK и SYN могут быть объединены в один пакет.
Клиент получил от сервера пакет SYN, теперь он должен его подтвердить, и он высылает серверу пакет ACK подтверждающий открытие соединения от сервера к клиенту.
Итак, клиент и сервер обменялись тремя пакетами: 1) клиент сделал заявку на открытие соединения от клиента к серверу; 2) сервер подтвердил открытие этого соединения и сделал заявку на открытие соединения от сервера к клиенту; 3) клиент подтвердил открытие соединения от сервера к клиенту. Данная процедура обмена тремя пакетами называется процедурой «тройного рукопожатия» (threeway handshaking).
Клиент | | Сервер
|--------SYN-------->|
|<-----ACK,SYN-------|
|--------ACK-------->|
|....................|
|------------------->|
|------------------->|
|------------------->|
|<-------ACK---------|
|....................|
Проведём следующий эксперимент: запустим программу tcpdump(1) и будем с её помощью фильтровать пакеты которыми наша машина обменивается с хостом 213.180.204.8 (ya.ru), а в это время в браузере откроем страницу http://ya.ru.
#tcpdump -i rl0 -n host 213.180.204.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
16:57:19.343549 IP 192.168.25.158.65083 > 213.108.204.8.80: S 2721116495:2721116495(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 707044109 0,sackOK,eol>
16:57:19.344320 IP 213.108.204.8.80 > 192.168.25.158.65083: S 576822871:576822871(0) ack 2721116496 win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 117290804 707044109,nop,nop,sackOK>
16:57:19.344402 IP 192.168.25.158.65083 > 213.108.204.8.80: . ack 1 win 65535 <nop,nop,timestamp 707044110 117290804>
16:57:19.346082 IP 192.168.25.158.65083 > 213.108.204.8.80: P 1:466(465) ack 1 win 65535 <nop,nop,timestamp 707044111 117290804>
16:57:19.347377 IP 213.108.204.8.80 > 192.168.25.158.65083: P 1:206(205) ack 466 win 33304 <nop,nop,timestamp 117290804 707044111>
16:57:19.347441 IP 213.108.204.8.80 > 192.168.25.158.65083: F 206:206(0) ack 466 win 33304 <nop,nop,timestamp 117290804 707044111>
16:57:19.347527 IP 192.168.25.158.65083 > 213.108.204.8.80: . ack 207 win 65535 <nop,nop,timestamp 707044113 117290804>
16:57:19.516256 IP 192.168.25.158.65083 > 213.108.204.8.80: F 466:466(0) ack 207 win 65535 <nop,nop,timestamp 707044282 117290804>
16:57:19.517433 IP 213.108.204.8.80 > 192.168.25.158.65083: . ack 467 win 33303 <nop,nop,timestamp 117290821 707044282>
Первые три пакета, которые мы тут наблюдаем как раз и относятся к процедуре тройного рукопожатия. Видно, что первый пакет имел флаг SYN (на это указывает заглавная буква S в распечатке), второй тоже имел флаг SYN и впридачу флаг ACK. Третий пакет не имел никаких флагов кроме ACK.
Следующие два пакета (4-й и 5-й) в нашей распечатке это пакеты ответственные за передачу данных по протоколу HTTP. В первом из них клиент выслал запрос http-ресурса командой протокола HTTP GET. Так как весь запрос уложился в один пакет, то в этом пакете был выставлен флаг PSH (push). Этот флаг ставится для того, чтобы заставить сервер отправить все накопившиеся пакеты приложению которое их ожидает (т.е. веб-серверу). В ответ сервер высылает страницу html. Эта страница так же поместилась в один пакет, и потому в нём тоже установлен флаг PSH.
Наконец последние четыре пакета соответствуют процедуре закрытия соединения TCP и будут рассмотрены ниже.
Соединение TCP, как уже говорилось выше, двунаправленное, поэтому оно закрывается отдельно клиентом и сервером. Таким образом порождается 4 пакета: 1) сервер посылает уведомление о закрытии канала от сервера к клиенту, пакет с флагом FIN; 2) клиент подтверждает его получение пакетом с флагом ACK; 3) клиент высылает пакет FIN — уведомление о закрытии канала от клиента к серверу; 4) сервер подтверждает его получение. Иногда пакеты 2 и 3 объединяются, подобно тому, как это происходит при тройном рукопожатии.
После того как хост выслал пакет с флагом FIN он больше не имеет право высылать данные через этот же сокет.
Почему же клиент не высылает пакет FIN в том же пакете, в котором он высылает флаг ACK? Потому что закрытие каналов — независимая процедура. Она осуществляется в тот момент когда приложение (браузер или вебсервер) совершит вызов функции close(2). В принципе, после того как соединение со стороны сервера к клиенту закрылось и пребывает в таком полузакрытом состоянии, клиент ещё может продолжать передавать какие-то данные на сервер.
Клиент | | Сервер
|....................|
|<-------FIN---------|
|--------ACK-------->|
|....................|
|--------FIN-------->|
|<-------ACK---------|
| |
В данной процедуре имеется некоторая проблема: когда клиент получил последний пакет с флагом ACK подтверждающий получение пакета с флагом FIN сервером, он ничего серверу не высылает. Как же сервер узнает, что клиент получил его пакет ACK? Чтобы не впасть в порочный круг и не высылать до бесконечности подтверждения на подтверждения, в протоколе TCP избран следующий алгоритм: существует некоторая абстрактная величина, называемая «предельная задержка сегмента» (MSL maximum segment lifetime). Этот параметр характеризует предполагаемый максимально возможный срок пребывания сегмента в сети до того, как он будет где-либо отброшен. В [RFC-793] рекомендовано значение MSL равное 2 минутам. На практике это время зависит от конкретной реализации операционой системы и может быть и меньше. Сервер после отправки пакета ACK ждёт удвоенное время MSL и если за это время он не получил повторного пакета FIN, то он считает, что его пакет ACK благополучно добрался до клиента и закрывает сокет.
В процессе обмена данными по протоколу TCP сокеты на хостах с обеих сторон соединения пребывают в некоторых состояниях. Названия этих состояний для типичного сеанса связи приведены ниже. Более подробно о них можно узнать в [Stevens-2003-ru]. Выяснить какие сокеты открыты в настоящий момент и в каком они находятся состоянии можно при помощи команды netstat(1), о чём подробно рассказано в Раздел 6.1.2.3, «Работающие интернет сервисы и открытые сокеты».
Клиент | | Сервер
| |
|--------SYN-------->|
SYN_SENT | | SYN_RCVD
|<-----SYN,ACK-------|
ESTABLISHED | |
|--------ACK-------->|
| | ESTABLISHED
|....................|
| |
|--------FIN-------->|
FIN_WAIT_1 | | CLOSE_WAIT
|<-------ACK---------|
FIN_WAIT_2 | |
|....................|
| |
|<-------FIN---------|
TIME_WAIT | | LAST_ACK
|--------ACK-------->|
....... | | CLOSED
| |
CLOSED | |
| |
Обратите внимание, состояние TIME_WAIT, как уже отмечалось, длится удвоенное время MSL, т.е. до 4 минут. В это состояние попадает только та сторона, которая выполняет активное закрытие соединения. На приведённой диаграмме это клиент, а в распечатке tcpdump(1) в примере с вебсервером, это был сервер. В ситуации, когда активное закрытие выполняет сервер (а для вебсервера это именно так) может накапливаться большое количество незакрытых сокетов. Рано или поздно для перегруженных вебсерверов это может превратиться в серъёзную беду. По этой причине большинство современных операционных систем в данном месте не соответствуют RFC. FreeBSD пребывает в состоянии TIME_WAIT в течение одной минуты.
Таблица B.4. Состояния TCP (по [RFC-793])
| Состояние | Описание |
|---|---|
| LISTEN | Ожидание запроса на соединение с любого адреса и любого порта |
| SYN-SENT | Послан запрос на открытие соединение, ожидается ответ |
| SYN-RECEIVED | Получен запрос на открытие соединения, послано подтверждение на него и ответный запрос на открытие соединения, ожидается ответ (см. ниже про «тройное рукопожатие») |
| ESTABLISHED | Соединение открыто, по нему могут передаваться данные |
| FIN-WAIT-1 | Удалённому хосту послан запрос на закрытие соединения, ожидается ответ |
| FIN-WAIT-2 | Ожидается запрос на закрытие соединения от удалённого хоста |
| CLOSE-WAIT | ожидается запрос на закрытие соединения от локального пользователя, т.е. со стороны удалённого хоста соединение закрыто, а с нашей стороны ещё нет |
| CLOSING | ожидается получение подтверждения на посланный удалённому хосту запрос на закрытие канала (при одновременном закрытии) |
| LAST-ACK | удалённому хосту послан запрос на закрытие соединения ожидается получение подтверждения получения этого запроса |
| TIME-WAIT | Таймаут выдерживаемый для того, чтобы убедиться, что удалённый хост получил подтверждение на закрытие соединения. |
| CLOSED | Соединение закрыто |
Разделение на данные три уровня не входят в модель TCP/IP. Стек протоколов TCP/IP подразумевает, что над транспортным уровнем сразу находится уровень приложения. Что же до эталонной модели OSI подразумевается, что на сеансовом уровне должны работать протоколы отвечающие за поддержание сеанса связи между источником и получателем; уровень представления ответственнен за кодирование и декодирование данных, в том числе за шифрование; а уровень приложения это собственно программы использующие сеть для коммуникации.
На уровне приложения работают такие протоколы как SMTP, HTTP, FTP и другие. Ввиду обширности этой темы мы рассмотрим лишь некоторые из них и не здесь, а далее в отдельных разделах.
| |  | |
| Приложение B. Некоторые сведения о стеке протоколов TCP/IP |  | Приложение C. Пакетный фильтр OpenBSD — pf(4) |
HIVE: All information for read only. Please respect copyright! |
