Пусть у Айгуль и Жаната имеются «заместители» — Майя и Алимхан, которые выполняют их обязанности, когда Айгуль и Жанат уезжают на каникулы. Поскольку Майя и Алимхан не являются старшими детьми в семьях, они не всегда выполняют поручения вовремя и, более того, иногда теряют письма. Таким образом, услуги, предоставляемые Майей и Алимханом, отличаются от услуг, предоставляемых Айгуль и Жанатом. Аналогично, в компьютерных сетях могут существовать несколько протоколов транспортного уровня, каждый из которых обладает собственными службами, предоставляющими услуги приложениям.
Услуги Айгуль и Жаната в значительной степени зависят от услуг, предоставляемых почтовой службой. Например, если почтовая служба не обеспечивает доставку писем между домами в течение определенного срока (например, трех дней), то Айгуль и Жанат не могут дать своим младшим братьям и сестрам никаких гарантий по поводу времени получения адресованных им писем. Аналогично службы сетевого уровня накладывают ограничения на возможности служб транспортного уровня. Если протокол сетевого уровня не гарантирует величину задержки или скорости передачи данных между хостами, протокол транспортного уровня не может обеспечить соответствующую задержку или скорость передачи данных между процессами.
Транспортный уровень в Интернете
Как уже неоднократно отмечалось, в Интернете (а точнее, в любой компьютерной сети, поддерживающей протокол TCP/IP) существуют два протокола транспортного уровня. Протокол UDP (User Datagram Protocol — протокол пользовательских дейтаграмм) предоставляет приложениям службу ненадежной передачи данных без установления логического соединения. ПротоколTCP (Transmission Control Protocol — протокол управления передачей), напротив, предоставляет службу надежной передачи данных с установлением логического соединения. Создавая новое приложение, разработчик должен выбрать один из двух протоколов транспортного уровня для своего продукта.
Для упрощения терминологии в контексте Интернета мы будем называть единицы обмена (PDU) транспортного уровня сегментами. Заметим, что в публикациях, посвященных Интернету (например, в документах RFC), сегментами, как правило, называют единицы обмена протокола TCP, при этом термин «дейтаграмма» используется для обозначения единиц обмена протокола UDP.
Перед тем как продолжить разговор о протоколах TCP и UDP, необходимо сказать несколько слов о сетевом уровне Интернета. В Интернете на сетевом уровне используется единственный протокол IP (Internet Protocol — Интернет-протокол). Протокол IP обеспечивает логическое соединение между хостами и предоставляет транспортному уровню услуги с доставкой «по возможности», или «с максимальными усилиями». Это означает, что IP пытается осуществить успешную доставку сегментов от отправителя до получателя, однако не дает никаких гарантий. Отсутствие гарантий распространяется не только на сам факт доставки сегментов, но и на сохранение порядка следования сегментов, а также на отсутствие искажений в доставленной информации. Говорят, что протокол IP предоставляет ненадежную службу. Каждый хост сети имеет не менее одного адреса сетевого уровня, часто называемого IP-адресом.
Кратко рассмотрев модель обслуживания протокола IP, займемся обобщением наших знаний о службах протоколов UDP и TCP. Основной задачей UDP и TCP является обеспечение обмена данными между процессами, выполняющимися на оконечных системах, при помощи службы обмена данными между оконечными системами, предоставляемой протоколом сетевого уровня. Такое «продолжение» соединения между оконечными системами до уровня процессов называется мультиплексированием и демультиплексированием на транспортном уровне. Протоколы UDP и TCP также обеспечивают отсутствие искажений данных при передаче, включая в свои заголовки поля обнаружения ошибок. Заметим, что протокол UDP предоставляет минимальный набор служб транспортного уровня: службы обмена данными между процессами и контроля ошибок. Как и протокол IP, UDP обеспечивает ненадежную передачу данных, не предоставляя гарантий доставки и отсутствия ошибок. Подробное описание UDP будет приведено в разделе «Протокол UDP — передача без установления соединения» этой главы.
Протокол TCP обладает более широким набором служб по сравнению с UDP. Прежде всего TCP обеспечивает надежную передачу данных. При помощи средств контроля переполнения, порядковых номеров, квитанций и таймеров (которые рассматриваются позже) TCP гарантирует, что вся переданная информация будет получена в правильном порядке и без искажений. Таким образом, протокол TCP, используя службу ненадежной передачи данных между оконечными системами протокола IP, обеспечивает надежную передачу данных между процессами. Контроль перегрузки является одной из функций TCP, которую трудно отнести к услуге, предоставляемой приложению; скорее, контроль перегрузки помогает повысить качество обслуживания всех пользователей сети. Цель контролирования перегрузки — предотвращение слишком интенсивного трафика между парами оконечных систем, вызывающего перегрузку линий связи и маршрутизаторов. Фактически действие механизма контроля перегрузки заключается в разделении пропускной способности линии связи поровну между всеми TCP-соединениями. В свою очередь, такое разделение обеспечивается регулированием скорости передачи каждой оконечной системой. Протокол UDP не контролирует трафик, а следовательно, приложение, использующее UDP, может осуществлять передачу данных с любой скоростью в течение сколь угодно долгого времени.
Мультиплексирование и демультиплексирование
Сетевой уровень принимающей оконечной системы передает полученные сегменты транспортному уровню, а транспортный уровень передает данные, содержащиеся в сегментах, процессам, которым они предназначены. Рассмотрим простой пример.
Предположим, что вы находитесь за своим персональным компьютером и загружаете web-страницы; при этом на компьютере одновременно открыты два Telnet-сеанса и один FTP-сеанс. Таким образом, данные, поступающие из Интернета, могут быть адресованы одному из четырех процессов: FTP-процессу, HTTP-процессу, одному из двух Telnet-процессов. Протокол транспортного уровня должен определить, какому процессу предназначается каждый принятый сегмент Данных. Рассмотрим, каким образом это происходит.

Рис. 6.2а. Мультиплексирование и демультиплексирование на транспортном уровне
Процесс, представляющий собой часть приложения, имеет собственный сокет, или «дверь», через которую осуществляется обмен данными с другими процессами. Таким образом, как показано на рис. 6.2а, транспортный уровень фактически передает данные не процессу, а сокету.
Поскольку принимающий хост может иметь несколько сокетов одновременно, каждый сокет имеет уникальный идентификатор. Формат идентификатора, как мы увидим позже, зависит от того, к какому протоколу принадлежит сокет, к TCP или к UDP.
Теперь рассмотрим, каким образом принятые сегменты транспортного уровня направляются в соответствующие сокеты. Для этой цели каждый сегмент содержит набор специальных полей. Транспортный уровень принимающего хоста анализирует содержимое этих полей, идентифицирует сокет, которому предназначен сегмент, и передает ему данные сегмента. Процедура вручения данных сокету носит название демультиплексирования. Сбор фрагментов данных, поступающих на транспортный уровень хоста-отправителя из различных сокетов, создание сегментов путем присоединения заголовка (который используется при демультиплексировании) к каждому фрагменту и передача сегментов сетевому уровню называется мультиплексированием. Транспортный уровень среднего хоста на рисунке должен демультиплексировать сегменты, поступающие от сетевого уровня в адрес процессов Р1 и Р2; это достигается путем направления данных, содержащихся в сегментах, в сокеты соответствующих процессов. Кроме того, транспортный уровень среднего хоста собирает данные, поступающие из сокетов процессов P1 и Р2, формирует сегменты и передает их сетевому уровню.
Процедура приема данных протоколами TCP и UDP, поступающих от нескольких различных прикладных служб, называется мультиплексированием. Обратная процедура – процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между набором высокоуровневых служб – называется демультиплексированием (рис. 6.2б).

Рис. 6.2б Мультиплексирование и демультиплексирование на транспортном уровне.
Протоколы TCP и UDP ведут для каждого приложения две очереди: очередь пакетов, поступающих к данному приложению из сети, и очередь пакетов, отправляемых данным приложением в сеть. Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для однозначной идентификации портов им присваивают номера. Номера портов используются для адресации приложений.
Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т. п., то за ними закрепляются стандартные, назначенные номера, также называемые хорошо-известными (популярными) (well-known) номерами портов. Так, номер 21 закреплен за службой удаленного доступа к файлам FTP, а 23 – за службой удаленного управления telnet. Назначенные номера являются уникальными в пределах Интернета и назначаются приложениям централизованно из диапазона от 0 до 1023.
Узнав о роли мультиплексирования и демультиплексирования на транспортном уровне, обратимся к их практической реализации на оконечных системах. Как мы знаем, мультиплексирование на транспортном уровне требует наличия у сокетов уникальных идентификаторов, а у сегментов — специальных полей, содержащих номера сокетов, которым они предназначены. Как показано на рис. 6.3, сегменты транспортного уровня содержат поле номера порта отправителя и поле номера порта получателя (в сегментах протоколов UDP и TCP имеются также другие поля, о которых будет рассказано в следующих разделах этой главы).
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |


