OSI и ее протоколы. Часть 4
Напомню нашим читателям, что в предыдущих номерах мы коснулись краткого описания протоколов прикладного уровня сетевой модели OSI (см. КГ №№ 5, 6, 8). Следующим уровнем, который следует после сеансового, является транспортный.
Транспортный уровень — 4-й уровень модели OSI — предназначен для доставки данных без ошибок и потерь, дублирования этих данных в той последовательности, как они были переданы. Блоки данных при этом разделяются на фрагменты, размер которых зависит от протокола: короткие объединяются в один, длинные разбиваются на более мелкие фрагменты. Протоколы данного уровня работают по принципу point to point — точка-точка (чтобы хоть как-то представить процесс такой передачи, уместно вспомнить шину PCI Express, которая также организована по принципу point to point).
TCP
История TCP уходит своими корнями далеко, вглубь 70-х. Созданию TCP обязано Агентство по Внедрению Научно-исследовательских Проектов Передовой технологии при Министерстве обороны (DARPA). В то время DARPA и другие правительственные организации отчетливо представляли себе, какие потенциальные возможности скрыты в технологии сети с коммутацией пакетов. Перед исследователями была поставлена задача добиться высокоустойчивой на случай атомной войны работы гетерогенных систем. DARPA финансировала исследования, проводимые Стэнфордским университетом и компаниями Bolt, Beranek и Newman (BBN) с целью создания ряда протоколов связи, отвечающих поставленным требованиям. Результатом этих работ по разработке, завершенных в конце 1970 гг., был комплект интернет-протоколов, одним из которых, собственно, и является TCP (Transmission Control Protocol).
Заглядывая во времена создания протокола, все же нельзя не отметить, что, несмотря на все удобство и нынешнюю популярность TCP/IP, с точки зрения безопасности протокол далеко не идеален. TCP представляет собой транспортный механизм, организующий поток данных с предварительной установкой соединения. В отличие от UDP (см. далее), TCP гарантирует, что приложение получит данные точно в таком же виде, в каком они были отправлены. В основе работы протокола лежат принципы пакетной передачи данных. Делая небольшое отступление от темы, хотелось бы сказать пару слов, почему же, собственно, пакетной передачи данных… А все дело в том, что именно пакетная передача данных является вариантом экономичной и рациональной передачи данных: представьте себе, если бы данные передавались не пакетами, а сплошным потоком — результатом такой передачи явились бы частые разрывы, низкая отказоустойчивость и т.д., и т.п. Для проверки целостности пакетов протокол TCP использует их контрольные суммы. Данное обстоятельство освобождает процессы прикладного уровня от необходимости "включения" тайм-аутов и повторных передач.
Наиболее типичными прикладными процессами, использующими TCP, являются FTP и telnet. Кроме того, на базе TCP работают SMTP, HTTP, X-window, RCP и некоторые другие протоколы. Прикладные процессы (приложения) (реализованные на вышеперечисленных, а также на других протоколах) взаимодействуют с TCP-модулем через порты. Каждому такому приложению соответствует свой номер порта. Когда прикладной процесс начинает использовать TCP, модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP обмениваются информацией о состоянии соединения т.н. виртуального канала. Канал является дуплексным: данные одновременно передаются в обоих направлениях. В то время как один прикладной процесс записывает данные в TCP-порт (далее они проходят по сети), другой читает их из своего TCP-порта. TCP-протокол всегда требует подтверждения приема/передачи. Для обеспечения надежной доставки используются тайм-ауты и повторные сеансы передачи данных. Отправителю все же разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще не подтвержденных данных. Количество байт, которое можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обоих концах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.
UDP
UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — представляет собой сетевой протокол для передачи данных в сетях IP. UDP является одним из самых простых протоколов транспортного уровня модели OSI. В отличие от TCP, UDP не гарантирует доставку пакета, поэтому аббревиатуру иногда расшифровывают как "Unreliable Datagram Protocol" ("протокол ненадежных датаграмм"). Следующее обстоятельство позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым не требуется большая пропускная способность линий связи либо требуется малое время доставки данных. В отличие от TCP, UDP используется для широковещательной и многоадресной рассылки. Протокол UDP предоставляет прикладным программам возможность отправлять сообщения другим приложениям, используя минимальное количество параметров протокола. Примерами сетевых приложений, использующих UDP, являются NFS (Network File System — сетевая файловая система) и SNMP (Simple Network Management Protocol — простой протокол управления сетью). Несомненное преимущество протокола UDP заключается в том, что он требует минимум установок и параметров для соединения двух процессов между собой. Как и в случае TCP, взаимодействие между прикладными процессами и модулем UDP осуществляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги другим прикладным процессам (сервер), ожидает поступления сообщений в порт, специально выделенный для этих услуг.
RTP
Протокол RTP (Real-Time Protocol) работает на транспортном уровне поверх протокола UDP и используется при передаче трафика реального времени. Для того, чтобы понять всю исключительную значимость и "полезность" данного протокола, необходимо отметить следующее: как известно, в процессе транспортировки в сетях возможна потеря пакетов и изменение их порядка, а также вариация времени доставки. Все эти возможные изменения на практике варьируются в достаточно широких пределах. Так, мультимедиаконтент накладывает достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями современного Интернета и был разработан протокол RTP. При передаче данных протокол RTP сохраняет в своем заголовке данные, необходимые для восстановления звука или видеоизображения в приемном узле, а также другие необходимые данные: данные о типе кодирования информации (JPEG, MPEG и т.п.) и т.п. В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также
интерполировать потерянные пакеты.
SCTP
SCTP (от англ. Stream Control Transmission Protocol — "протокол передачи с управлением потоком") — сетевой протокол транспортного уровня в сетях TCP/IP, описанный в RFC 2960. Назначение SCTP аналогично TCP и UDP, однако есть и отличия. Основные из них связаны с поддержкой в SCTP т.н. "многодомности" (multihoming) и частичного упорядочивания. Многодомность позволяет SCTP-хосту устанавливать "сеанс" с другим SCTP-хостом с помощью нескольких интерфейсов, каждый из которых идентифицируется отдельным IP-адресом. Частичное же упорядочивание дает SCTP возможность осуществлять упорядоченную доставку одной или нескольких связанных последовательностей сообщений, пересылаемых между двумя хостами. Благодаря этому SCTP может оказаться особенно полезен в тех приложениях, где необходима надежная доставка и быстрая обработка множества не связанных между собой потоков данных. SCTP поддерживает ряд функций, унаследованных от TCP и других протоколов, которые предлагают дополнительную
функциональность.
SCTP был создан в рамках проекта, начатого рабочей группой IETF Signaling Transport и посвященного разработке специализированного транспортного протокола для решений, связанных с передачей голоса по IP-сетям (VoIP-телефония). Как и TCP, протокол SCTP предлагает приложениям, взаимодействующим по IP-сети, ориентированную на соединения типа point to point (точка/точка) транспортную службу с гарантированной доставкой. Новый протокол унаследовал многие функции, разработанные для TCP, в том числе возможности контроля перегрузки и восстановления утерянных пакетов. Получается, что любое приложение, работающее по протоколу TCP, можно перевести на SCTP без потери функциональности.
Продолжение следует
Олег Бойцев, Boyscout_zone@mail.ru
Транспортный уровень — 4-й уровень модели OSI — предназначен для доставки данных без ошибок и потерь, дублирования этих данных в той последовательности, как они были переданы. Блоки данных при этом разделяются на фрагменты, размер которых зависит от протокола: короткие объединяются в один, длинные разбиваются на более мелкие фрагменты. Протоколы данного уровня работают по принципу point to point — точка-точка (чтобы хоть как-то представить процесс такой передачи, уместно вспомнить шину PCI Express, которая также организована по принципу point to point).
TCP
История TCP уходит своими корнями далеко, вглубь 70-х. Созданию TCP обязано Агентство по Внедрению Научно-исследовательских Проектов Передовой технологии при Министерстве обороны (DARPA). В то время DARPA и другие правительственные организации отчетливо представляли себе, какие потенциальные возможности скрыты в технологии сети с коммутацией пакетов. Перед исследователями была поставлена задача добиться высокоустойчивой на случай атомной войны работы гетерогенных систем. DARPA финансировала исследования, проводимые Стэнфордским университетом и компаниями Bolt, Beranek и Newman (BBN) с целью создания ряда протоколов связи, отвечающих поставленным требованиям. Результатом этих работ по разработке, завершенных в конце 1970 гг., был комплект интернет-протоколов, одним из которых, собственно, и является TCP (Transmission Control Protocol).
Заглядывая во времена создания протокола, все же нельзя не отметить, что, несмотря на все удобство и нынешнюю популярность TCP/IP, с точки зрения безопасности протокол далеко не идеален. TCP представляет собой транспортный механизм, организующий поток данных с предварительной установкой соединения. В отличие от UDP (см. далее), TCP гарантирует, что приложение получит данные точно в таком же виде, в каком они были отправлены. В основе работы протокола лежат принципы пакетной передачи данных. Делая небольшое отступление от темы, хотелось бы сказать пару слов, почему же, собственно, пакетной передачи данных… А все дело в том, что именно пакетная передача данных является вариантом экономичной и рациональной передачи данных: представьте себе, если бы данные передавались не пакетами, а сплошным потоком — результатом такой передачи явились бы частые разрывы, низкая отказоустойчивость и т.д., и т.п. Для проверки целостности пакетов протокол TCP использует их контрольные суммы. Данное обстоятельство освобождает процессы прикладного уровня от необходимости "включения" тайм-аутов и повторных передач.
Наиболее типичными прикладными процессами, использующими TCP, являются FTP и telnet. Кроме того, на базе TCP работают SMTP, HTTP, X-window, RCP и некоторые другие протоколы. Прикладные процессы (приложения) (реализованные на вышеперечисленных, а также на других протоколах) взаимодействуют с TCP-модулем через порты. Каждому такому приложению соответствует свой номер порта. Когда прикладной процесс начинает использовать TCP, модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP обмениваются информацией о состоянии соединения т.н. виртуального канала. Канал является дуплексным: данные одновременно передаются в обоих направлениях. В то время как один прикладной процесс записывает данные в TCP-порт (далее они проходят по сети), другой читает их из своего TCP-порта. TCP-протокол всегда требует подтверждения приема/передачи. Для обеспечения надежной доставки используются тайм-ауты и повторные сеансы передачи данных. Отправителю все же разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще не подтвержденных данных. Количество байт, которое можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обоих концах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.
UDP
UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — представляет собой сетевой протокол для передачи данных в сетях IP. UDP является одним из самых простых протоколов транспортного уровня модели OSI. В отличие от TCP, UDP не гарантирует доставку пакета, поэтому аббревиатуру иногда расшифровывают как "Unreliable Datagram Protocol" ("протокол ненадежных датаграмм"). Следующее обстоятельство позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым не требуется большая пропускная способность линий связи либо требуется малое время доставки данных. В отличие от TCP, UDP используется для широковещательной и многоадресной рассылки. Протокол UDP предоставляет прикладным программам возможность отправлять сообщения другим приложениям, используя минимальное количество параметров протокола. Примерами сетевых приложений, использующих UDP, являются NFS (Network File System — сетевая файловая система) и SNMP (Simple Network Management Protocol — простой протокол управления сетью). Несомненное преимущество протокола UDP заключается в том, что он требует минимум установок и параметров для соединения двух процессов между собой. Как и в случае TCP, взаимодействие между прикладными процессами и модулем UDP осуществляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги другим прикладным процессам (сервер), ожидает поступления сообщений в порт, специально выделенный для этих услуг.
RTP
Протокол RTP (Real-Time Protocol) работает на транспортном уровне поверх протокола UDP и используется при передаче трафика реального времени. Для того, чтобы понять всю исключительную значимость и "полезность" данного протокола, необходимо отметить следующее: как известно, в процессе транспортировки в сетях возможна потеря пакетов и изменение их порядка, а также вариация времени доставки. Все эти возможные изменения на практике варьируются в достаточно широких пределах. Так, мультимедиаконтент накладывает достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями современного Интернета и был разработан протокол RTP. При передаче данных протокол RTP сохраняет в своем заголовке данные, необходимые для восстановления звука или видеоизображения в приемном узле, а также другие необходимые данные: данные о типе кодирования информации (JPEG, MPEG и т.п.) и т.п. В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также
интерполировать потерянные пакеты.
SCTP
SCTP (от англ. Stream Control Transmission Protocol — "протокол передачи с управлением потоком") — сетевой протокол транспортного уровня в сетях TCP/IP, описанный в RFC 2960. Назначение SCTP аналогично TCP и UDP, однако есть и отличия. Основные из них связаны с поддержкой в SCTP т.н. "многодомности" (multihoming) и частичного упорядочивания. Многодомность позволяет SCTP-хосту устанавливать "сеанс" с другим SCTP-хостом с помощью нескольких интерфейсов, каждый из которых идентифицируется отдельным IP-адресом. Частичное же упорядочивание дает SCTP возможность осуществлять упорядоченную доставку одной или нескольких связанных последовательностей сообщений, пересылаемых между двумя хостами. Благодаря этому SCTP может оказаться особенно полезен в тех приложениях, где необходима надежная доставка и быстрая обработка множества не связанных между собой потоков данных. SCTP поддерживает ряд функций, унаследованных от TCP и других протоколов, которые предлагают дополнительную
функциональность.
SCTP был создан в рамках проекта, начатого рабочей группой IETF Signaling Transport и посвященного разработке специализированного транспортного протокола для решений, связанных с передачей голоса по IP-сетям (VoIP-телефония). Как и TCP, протокол SCTP предлагает приложениям, взаимодействующим по IP-сети, ориентированную на соединения типа point to point (точка/точка) транспортную службу с гарантированной доставкой. Новый протокол унаследовал многие функции, разработанные для TCP, в том числе возможности контроля перегрузки и восстановления утерянных пакетов. Получается, что любое приложение, работающее по протоколу TCP, можно перевести на SCTP без потери функциональности.
Продолжение следует
Олег Бойцев, Boyscout_zone@mail.ru
Компьютерная газета. Статья была опубликована в номере 09 за 2007 год в рубрике сети
