Для чего служат порты транспортного уровня

Для чего служат порты транспортного уровня

Как упоминалось в самом начале, на транспортном уровне присутствуют два протокола – TCP и UDP. TCP используется для гарантированной передачи данных, в то время как UDP используется для передачи потоковых данных.

Функции TCP

Использование портов

TCP и UDP используют порты, которые в свою очередь, делятся на зарезервированные порты и динамические:

Таблица 5.1 Список зарезервированных портов

Чтобы лучше понять, что такое порты и как их “едят”, разберем пример соединений с использованием портов.

Наверно, самое часто используемое приложение – браузер. Часто мы открываем несколько “вкладок” с одним и тем же сайтом, и у каждой вкладки должно быть отличие, по которому компьютер сможет определить какой вкладке предназначены приходящие данные.

Рисунок 5.1 Передача данных с использованием портов

Компьютер Андрея запросил с веб-сервера три веб-страницы (открыл три “вкладки” в браузере). На рисунке 5.1, Веб-сервер отправляет пакеты с одинаковыми заголовками (в заголовках одинаковые IP адреса), но заголовки сегментов различаются ( обратите внимание на порт отправителя (S_PORT) и порт получателя (D_PORT)). Изначально компьютер Андрея привязал к каждому соединению определенный порт, который был определен случайным образом из динамически распределяемого диапазона (от 49152 по 65535), а обратился он на зарезервированный порт 80 (HTTP). Так происходит со всеми передаваемыми данными, к каждому приложению присваивается определенный порт/порты, таким образом данные получает то приложение, которому они предназначены. Еще можно схематично представить наш пример.

Рисунок 5.2 Схематичное представление соединений

Сегментация

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

Например, вы хотите передать видео файл размером 200Кбайт. Видео не будет передаваться одним целым файлом, оно будет разбито на сегменты, после чего по сети будут передаваться около 137 сегментов (200 000/1460

Установление соединений

Устанавливаются соединения в 3 сообщения, рисунок 5.3.

Рисунок 5.3 Установка соединения TCP

После этих трех сообщений соединение считается установленным, и клиент отправляет запрос на получение данных с сервера.

Завершаются соединения в четыре сегмента, здесь этот процесс рассмотрен не будет.

Восстановление после ошибок

На рисунке 5.4 изображена передача сегментов, и 3-й сегмент не приходит получателю. Введем некоторое пояснение, SEQ, помимо номера сегмента, обозначает количество переданных байт, например, первый сегмент 1400 байт, второй сегмент имеет такой же размер, но номер его 2800, он означает, что при получении этого сегмента будет передано уже 2800 байт. Вернемся к нашему примеру, веб-сервер передает не сразу все сегменты, а по частям, ожидая подтверждения каждой части. Так например, если бы передача прошла успешно, веб сервер бы получил ACK=7000. В нашем примере 3-й сегмент потерялся, поэтому клиент отправляет подтверждение ACK=4200 (как бы спрашивая у сервера, “Где сегмент №4200?”), а сервер это будет трактовать как сегмент с номером 4200 был потерян, и веб-сервер отправляет его еще раз. Вот так и осуществляется восстановление данных после ошибок.

Управление потоком с использованием окон

Максимальная единица передаваемых данных (MTU)

Если вы нашли в тексте ошибку, выделите текст и нажмите Ctrl + Enter

ID: 113 Created: Oct 19, 2016 Modified Oct 07, 2019

Источник

Транспортный уровень в OSI и TCP подробный разбор с примерами

Транспортный уровень это 4 уровень в модели взаимодействия открытых систем и 3 уровень в модели TCP/IP.

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

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

Задачи транспортного уровня (ТУ)

Задача транспортного уровня это передача данных между процессами на разных хостах. На транспортном уровне необходимо обеспечить адресацию. Нам нужно знать для какого процесса назначен тот или иной пакет. Важной задачей ТУ является обеспечение надежности передачи данных. ТУ может предоставлять надежность более высокую, чем надежность сети которая используется для передачи данных. С другой стороны ТУ может и не предоставлять дополнительный уровень надежности, все зависит от требований конкретного приложения.

Модель OSI

Полностью модель взаимодействия открытых систем выглядит так, как показано на рисунке ниже.

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

Важной особенностью транспортного уровня является прямое взаимодействие с транспортным уровнем на другом компьютере.

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

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

Адресации. Порты

Для адресации на транспортном уровне используются порты. Это просто число от 1 до 65 535. Номера у процессов на одном хосте не должны повторяться, иначе мы не сможем понять к какому конкретно процессу отправить пришедший пакет.

Записываются порты, следующим образом 192.168.1.3 :80. Выделенные жирным это IP-адрес, а 80 — это порт. Чтобы в интернете подключиться к какому-нибудь сервису и к службе необходимо указать ip адрес и соответствующий порт.

Типы портов

Если мы хотим подключиться к какому-нибудь сервису в интернете нам нужно знать не только ip адрес, но и порт. Поэтому договорились, что популярные сервисы будут работать на одних и тех же портах. Эти порты называются хорошо или широко известные порты 1-1024.

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

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

Использование, как хорошо известных портов, так и зарегистрированных это просто договоренность. Например Web сервер может работать не только на 80 порту, но и на любом другом. Часто используется support номер 88 или 8080. При этом, когда вы подключаетесь к такому веб-серверу Вы должны указать порт на котором он работает.

Динамические порты назначаются операционной системой клиентом. Клиенту, точно также, как и серверу необходим не только ip адрес, но и порт. В случае с клиентом номер порта не имеет принципиального значения, так как клиент отправляет запрос серверу и сервер в запросе увидит, как ip адрес клиента, так и его порт. Поэтому, операционная система назначает клиентам порты автоматически из диапазона динамических портов.

IP-адреса и порты

Рассмотрим пример сетевого взаимодействия с использованием ip адресов и портов. Есть сервер на котором работает web сервер на порту №80. И есть клиент, который хочет подключиться к этому веб серверу.

Клиент открывает браузер, операционная система автоматически назначает ему порт 50298. Браузер выполняет соединение с веб сервером, запрашивает веб страницу. Web сервер отправляет ему эту страницу.

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

Надежность на транспортном уровне

Важной особенностью ТУ является то, что он может обеспечить более высокую надежность, чем сеть которая используется для передачи данных. В настоящее время это эффективно на практике, потому что используются надежные каналы связи, ошибки в этих КС происходят редко. Поэтому можно строить сеть ненадежную, которая будет стоить дешево, а ошибки, так как они возникают редко, можно исправлять программно на хостах транспортного уровня.

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

Протоколы транспортного уровня TCP/IP

В стеке протоколов tcp на ТУ используется два протокола TCP и UDP. Tcp это протокол, который обеспечивает надежность доставки. Он обеспечивает гарантию доставки и гарантию порядка следования сообщений. Протокол udp не гарантирует доставку данных, но зато работает быстрее, чем протокол tcp.

Заключение

Для взаимодействия с ТУ используется интерфейс сокетов. Многие сетевые приложения взаимодействуют с ТУ. Хотя сейчас все более популярными становятся разработка сетевых приложений, которые взаимодействуют не с транспортным, а с прикладным уровнем.

Источник

Тема 4. Информационное и программное обеспечение сетей

Оглавление

Цель темы — сформировать представление о принципах работы и реализации в стеке TCP/IP транспортных и служебных протоколов передачи информационных данных через сеть. Реализуются эти протоколы программными средствами операционных систем.

В результате изучения темы студенты должны усвоить:

4.1. Протоколы транспортного уровня UDP и TCP

Основная задача транспортного уровня заключается в передаче данных между парой прикладных процессов, выполняющихся в сети. Протоколы транспортного уровня UDP и TCP функционируют только на конечных узлах сети, выступая посредниками между сетевыми приложениями и самой сетью.

Следует дать пояснение терминам «процесс» и «приложение»: процесс в компьютере создается операционной системой после запуска на выполнение прикладного приложения.

4.1.1. Общие принципы работы протоколов UDP и TCP

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

Поскольку к одному транспортному протоколу могут обращаться множество прикладных процессов, то вводится условная адресация этих процессов в виде так называемых портов — точек доступа прикладных процессов к транспортному уровню. Номер порта однозначно определяет приложение в пределах одного компьютера, а набор из IP-адреса компьютера и номера порта, который называют сокетом, однозначно определяет приложение в составной сети. В обозначении сокета IP-адрес и номер порта разделяются двоеточием. Пример обозначения сокета: 10.112.0.2:80.

Не следует путать порт транспортного протокола с портом (интерфейсом) компьютера. Порт транспортного уровня — это фактически адрес буфера памяти, через который происходит взаимодействие прикладного процесса с транспортным протоколом. Так как используется 16-битная адресация к этим буферам памяти, то возможные номера адресов (портов) транспортного протокола ограничены числами от 0 до 65 535.

Существует два способа присвоения порта приложению — централизованный и локальный (динамический). Для централизованного способа используются номера портов от 0 до 1023, а для локального — все остальные: 1024—65 535.

Если процессы, запущенные на компьютере, представляют известные сетевые службы, например HTTP, DNS, FTP и т. п., то за ними закрепляются стандартные номера портов, которые еще называют хорошо известными номерами портов. Такое централизованное присвоение сетевым службам номеров портов выполняется организацией Internet Assigned Numbers Authority (IANA) и публикуется в Интернете. Например, номер 21 портов протокола TCP закреплен за службой файлового обмена FTP, а номер 80 — за службой HTTP.

Локально номера портов выделяются операционной системой компьютера тем сетевым приложениям, которые не имеют широкого распространения. Операционная система компьютера ведет учет занятых и свободных номеров портов. Так как при локальном (динамическом) распределении номеров портов закрепление портов за приложениями происходит только на время работы этого приложения, то при следующем запуске этого приложения ему может быть выделен другой номер порта из диапазона номеров 1024—65 535.

Следует отметить, что как у протокола UDP, так и у протокола TCP отдельный набор номеров портов от 0 до 65 535, т. е., говоря о номере порта, следует указывать и протокол — TCP или UDP. Следовательно, в компьютере одновременно может использоваться по два номера порта — один для протокола TCP, другой — для протокола UDP.

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

Транспортный протокол забирает сообщение из порта частями фиксированной длины, называемыми сегментами. Максимальная длина сегмента зависит от максимальной величины поля данных пакета IP, которая в свою очередь определяется параметром MTU используемой сетевой технологии.

Протоколы UDP и TCP для каждого номера порта ведут две очереди: очередь сегментов, поступающих в данный порт их сети, и очередь сегментов, отправляемых из данного порта в сеть. Процедура приема сегментов данных из портов различных прикладных процессов называется мультиплексированием. Обратная процедура распределения транспортным протоколом (UDP или TCP) сегментов данных, поступающих от сетевого уровня, между процессами, идентифицированными номерами портов, называется демультиплексированием.

Рис. 4.1 иллюстрирует процедуры мультиплексирования и демультиплексирования данных протоколами TCP и UDP.

Рис. 4.1. Мультиплексирование и демультиплексирование данных на транспортом уровне

Прикладной процесс, например, службы DNS посылает сетевое сообщение — поток данных в выделенный ему порт TCP 53 (порт для него — это адрес буфера памяти). Протокол TCP по очереди обращается ко всем открытым портам TCP и выбирает из них очередные сегменты данных сообщений — так реализуется мультиплексирование. Протокол TCP формирует заголовки сегментов TCP и направляет эти сегменты протоколу IP, который упаковывает их в IP пакет и отправляет в сеть.

Аналогично функционирует и протокол UDP, обслуживая свои процессы через собственные порты.

В заголовках принимаемых IP-пакетов указывается протокол верхнего уровня, поэтому IP-протокол однозначно определяет, какому протоколу следует отдать очередной пакет данных.

4.1.2. Протокол пользовательских дейтаграмм UDP

Протокол UDP (User Datagram Protocol) только дополняет IP-протокол адресом прикладного процесса и возможностью проверки правильности передачи сегмента данных. Это дейтаграммный (без предварительного установления соединения) и поэтому потенциально ненадежный протокол. В нем отсутствуют механизмы контроля за достижением сегментов узла назначения. При использовании прикладным приложением транспортного протокола UDP это приложение должно самостоятельно осуществлять проверку целостности передачи сообщений и выполнять их повторный запрос в случае отсутствия отдельных сегментов.

Заголовок UDP сегмента состоит из 8 байт и имеет структуру, представленную на рис. 4.2.

№ порта источника

(2 байта)

№ порта назначения

(2 байта)

Длина сегмента UDP

(2 байта)

Контрольная сумма

(2 байта)

Рис. 4.2. Структура заголовка сегмента UDP

Поле длины сегмента содержит общее количество байт сегмента вместе с заголовком.

Поле контрольной суммы позволяет проверить точность передачи данных в сегменте. Следует напомнить, что в протоколе IP проверяется на наличие ошибок только заголовок пакета, а поле данных, в котором находится сегмент транспортного протокола, не проверяется. При обнаружении ошибки в сегменте протокол UDP поступает аналогично протоколу IP — отбрасывает принятый сегмент данных.

Поскольку в протоколе UDP отсутствует обратная связь, то в заголовке сегмента UDP допустимо отсутствие номера порта источника. Контрольная сумма тоже является необязательным параметром. В случае отсутствия этих данных вместо них в заголовке передаются последовательности нулей соответствующей длины.

4.1.3. Протокол надежной доставки сообщений TCP

Протокол TCP (Transmission Control Protocol) не только дополняет IP-протокол адресом прикладного процесса (номером порта) и возможностью проверки правильности передачи сегмента данных, но и обеспечивает надежную доставку сообщений, т. к. передача данных осуществляется через логическое соединение.

Логическое соединение TCP — это договоренность о параметрах процедуры передачи данных между двумя прикладными процессами сети посредством протокола TCP. Ключевым моментом логического соединения является квитирование (подтверждение) приема переданных данных посредством отправки квитанций.

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

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

Структура сегмента TCP представлена на рис. 4.3.

Рис. 4.3. Структура сегмента TCP

Сегмент TCP состоит из заголовка и поля данных. Заголовок сегмента имеет размер не менее 20 байт и содержит следующие поля:

4.1.4. Метод скользящего окна

В протоколе TCP в рамках установленного логического соединения правильность передачи данных должна подтверждаться квитанцией получателя. В протоколе TCP используется частный случай квитирования — метод скользящего окна (sliding window).

В этом методе для повышения коэффициента использования линии передачи источнику разрешается передать некоторое количество сегментов данных подряд в непрерывном режиме — в максимально возможном для источника темпе, без получения на эти сегменты положительных квитанций от получателя. Объем данных, которые разрешается передавать таким образом, называется размером окна.

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

Рис. 4.4. Скользящее окно в протоколе TCP

Поток байтов, передаваемых прикладным процессом, протокол TCP последовательно нумерует и «нарезает» на сегменты, которые отправляет получателю. При установлении соединения, а затем и в ходе передачи данных обе стороны, выступая в роли получателя, посылают друг другу так называемые окна приема (параметр WIN). Каждая сторона, получив окно приема, понимает, сколько байтов ей разрешается отправить с момента получения последней квитанции.

В передаваемом потоке на рис. 4.4 получена квитанция с номером N в поле ACK, которая означает, что все предыдущие байты потока безошибочно приняты противоположной стороной и можно передавать следующие байты потока, начиная с номера N. Одновременно получено значение окна W, которое указывает, что передавать можно не один сегмент, а столько, сколько переносят байты с номера N до номера, не превышающего N+W.

Поскольку в протоколе TCP каждая сторона выступает и как отправитель, и как получатель данных, то у каждой стороны есть пара буферов памяти: один — для хранения принятых сегментов, другой — для передаваемых сегментов.

Таким образом, посылая окно приема, обе стороны регулируют поток байтов в свою сторону, исходя из возможностей и загруженности своего буфера приема. Размер окна может меняться в рамках даже одного соединения — его текущее значение указывается в заголовке каждого сегмента TCP.

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

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

4.1.5. Алгоритм установления логического соединения TCP

Установление соединения TCP выполняется в следующей последовательности:

На рис. 4.5 представлена процедура обмена служебными сообщениями TCP при установлении логического соединения.

Рис. 4.5. Обмен сообщениями TCP при установлении соединения

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

Первое TCP-сообщение не содержит сегмента данных, а является запросом на установление соединения, поэтому бит SYN=1. Нулевое значение бита ASК говорит, что сторона-инициатор еще ничего не принимала, поэтому квитанции в данном TCP-сообщении пока нет.

Другая сторона в ответ на это предложение высылает тоже служебное TCP сообщение, но уже с предложением передавать данные, начиная с первого байта (ASК=1) и указывает свое окно приема (WIN).

Сторона-инициатор отправляет первый сегмент данных, предлагает передавать данные в свою сторону (ASК=1) и указывает размер своего окна приема.

4.1.6. Преобразование сетевых адресов: технология NAT

Технология NAT (Network Address Translation — преобразование сетевых адресов) широко используется с целью подмены частных IP-адресов (из таких диапазонов, как 10.х.x.x, 192.168.x.x, 172.16.x.x —172.31.х.х) компьютеров локальных сетей публичным IP-адресом, разрешенным в глобальной сети Интернет.

Основная причина растущей популярности технологии NAT связана со все более обостряющимся дефицитом адресов протокола IPv4. Средство общего доступа к подключению Интернета в операционных системах Windows XP, а также многие шлюзы Интернета активно используют NAT, особенно для подключения к широкополосным сетям, например через DSL или кабельные модемы.

На рис. 4.6 приведен пример использования технологии NAT для выхода в Интернет компьютеров локальной сети 10.0.0.0/24 под одним IP-адресом 157.55.1.10.

Рис. 4.6. Пример использования технологии NAT для локальной сети

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

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

Когда прикладной процесс передает данные через соединение, частный IP-адрес клиента (IP-адрес источника) и клиентский порт (порт источника) вставляются в пакет в поля параметров источника. Поля параметров пункта назначения будут содержать IP-адрес и порт процесса-назначения. Поскольку пункт назначения пакета находится вне локальной сети, клиент направляет его в основной шлюз. В данном сценарии роль основного шлюза играет устройство NAT.

Устройство NAT перехватывает исходящий пакет и производит сопоставление порта, используя IP-адрес назначения в сети Интернет, порт назначения, внешний IP-адрес устройства NAT, внешний порт, сетевой протокол, а также внутренние IP-адрес и порт клиента локальной сети.

Устройство NAT ведет таблицу сопоставлений портов и сохраняет созданное сопоставление в этой таблице. Внешние IP-адрес и порт — это общие IP-адрес и порт, которые будут использоваться в текущем сеансе передачи данных вместо внутренних IP-адреса и порта клиента.

Затем устройство NAT «транслирует» пакет, преобразуя в пакете поля источника: внутренние (Internal) IP-адрес и порт клиента заменяются внешними (External) IP-адресом и портом устройства NAT.

Преобразованный пакет пересылается по внешней сети и в итоге попадает на узел назначения (Remote host). Пример работы устройства NAT представлен на рис. 4.7.

Рис. 4.7. Пример преобразования исходящего пакета

Внешний удаленный узел сети Интернет будет направлять ответные пакеты на внешние IP-адрес и порт устройства NAT, указывая в полях источника свои собственные IP-адрес и порт.

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

Затем NAT отправляет пакет клиенту по внутренней сети. Однако если NAT не находит подходящего сопоставления портов, входящий пакет отвергается и соединение разрывается.

Благодаря устройству NAT клиент получает возможность передавать данные в глобальной среде Интернета, используя лишь частный IP-адрес; ни от приложения, ни от клиента не требуется никаких дополнительных усилий. В данном случае механизм NAT оказывается прозрачным по отношению к клиенту и к серверному приложению — все работает просто и четко.

Однако не все сетевые приложения пользуются протоколами, способными взаимодействовать с NAT.

4.2. Протокол обмена управляющими сообщениями ICMP

4.2.1. Назначение протокола ICMP

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми маршрутизатор столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

Таким образом, несмотря на то, что протокол ICMP для передачи своих сообщений пользуется услугами протокола IP (как транспортные протоколы), он в стеке протоколов TCP/IP находится на одном уровне с протоколом IP — уровне межсетевого взаимодействия. Такое положение протокола ICMP определяется тем, что он работает, как и протокол IP, на всех узлах составной сети.

4.2.2. Формат сообщений протокола ICMP

На рис. 4.8 представлена структура IP-пакета, содержащего сообщение ICMP.

Рис. 4.8. Структура IP-пакета с сообщением ICMP

Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, т. к. все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений.

Возможные значения поля типа сообщения представлены в табл. 4.1.

Источник