Next: Создание сети с человеческим Up: Работа Internet: организацияструктура, Previous: Эталонная модель OSI

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

Пересылка битов происходит на физическом уровне эталонной модели ISO/OSI. Увы, здесь всякая попытка краткого и доступного описания обречена на провал. Требуется введение огромного количества специальных терминов, понятий, описаний процессов на физическом уровне и т.д. И потом, существует столь великое разнообразие приёмо-передатчиков и передающих сред, -- трудно даже и обозреть этот океан технологий. Для понимания работы сетей этого и не требуется. Считайте, что просто имеется труба, по которой из конца в конец перекачиваются биты. Именно биты, безо всякого деления на какие-либо группы (байты, декады и т.п.). Причём эта труба может быть худой, т.е. биты по пути могут теряться, информация может искажаться.

В качестве физической среды передачи могут использоваться любые средства физического мира. Формально для этого подходит даже сигнализация флажками (семафор) и кострами. Конечно, реально применяются только наиболее быстрые методы передачи информации. В современных компьютерных сетях используются телефонные, радио и радио-релейные линии, спутниковые каналы связи, опто-волоконные кабели и т.д. Наиболее доступными, а потому и наиболее популярными являются телефонные линии. Мы в таблице 3.1 перечислили некоторые их типы, может вам будет интересно.

Вообще говоря, по стандарту ISO организацией структурированной передачи, т.е. передачей более сложно структурированных данных (массивов битов), например посимвольной передачей, занимается канальный уровень, пользуясь для этого возможностями физического уровня. В Internet неким аналогом компоненты канального уровня могут служить транспортные средства её подсетей (Ethernet, X.25, и т.д.) и используемых линий связи, например, модемные средства. Internet имеет специальные протоколы (SLIP, PPP, ARP, и т.д.), с помощью которых она подстраивает под себя (или сама подстраивается?) различные средства канального уровня. Такие протоколы обычно занимаются только разбиением битового потока на символы и кадры и передачей полученных данных на следующий уровень. Обеспечением надёжности передачи они себя не утруждают.

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

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

Но увы! Картина эта неверна и приводит ко многим заблуждениям относительно работы Internet, ко множеству недоразумений. Телефонная сеть -- это так называемая сеть с коммутацией линий, т.е. когда вы делаете вызов, устанавливается связь и всё время сеанса связи имеется физическое соединение с абонентом. При этом вам выделяется часть сети, которая для других уже не доступна, даже если вы молча дышите в трубку, а другие абоненты хотели бы поговорить по действительно неотложному делу. Это приводит к нерациональному использованию очень дорогих ресурсов -- линий связи. Internet же является сетью с коммутацией пакетов, что принципиально отличается от сети с коммутацией каналов.

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

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

По линии связи, например по проводу, можно переслать биты только из одного его конца в другой. Internet же умудряется аккуратно передавать данные в различные точки, разбросанные по всему миру. Как она это делает? Забота об этом возложена на сетевой уровень эталонной модели ISO/OSI. В Internet соответствующий уровень называется межсетевым -- internetwork -- откуда, собственно, и происходит само название сети Internet.

Различные части Internet -- составляющие сети -- соединяются между собой посредством компьютеров, которые называются узлами; так Сеть связывается воедино. Составляющие сети могут быть самыми разными: Ethernet, Token Ring, сети на телефонных линиях, X.25, пакетные радиосети и т.д. Для связи расположенных далеко друг от друга составляющих сетей используются самые разные линие связи, чаще всего -- выделенные линии.

Давайте вспомним про почтовую аналогию. Выделенные линии и локальные сети суть аналоги железных дорог, самолётов почты и почтовых отделений, почтальонов. Посредством их почта передвигается по сети. Узлы -- аналоги почтовых отделений, где принимается решение, как далее пересылать (``пакеты'') по сети, точно так же, как почтовый узел намечает дальнейший путь почтового конверта отправления, например письма. Отделения или узлы совсем не обязаны иметь прямые связи со всеми остальными. Этого для работы сети совсем не нужно. Сообщения пересылаются по цепочке посредством множества узлов.

Когда вы решите отправить конверт из Долгопрудного (Московская область) в Уфу (Башкирия), конечно же, почта не станет нанимать самолёт, который полетит из ближайшего к Долгопрудному аэропорта (Шереметьево) в Уфу, просто местное почтовое отделение отправит послание на некую подстанцию в нужном направлении, та в свою очередь, дальше в направлении пункта назначения -- на следующую подстанцию; таким образом письмо станет последовательно приближаться к пункту назначения, пока не достигнет почтового отделения, в ведении которого находится нужный жилой объект и которое доставит сообщение получателю.

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

На каждой почтовой подстанции определяется следующая подстанция, куда будет далее направлена корреспонденция, т.е. намечается дальнейший путь (маршрут) -- этот процесс называется маршрутизацией. Для осуществления маршрутизации каждая подстанция имеет таблицу, где адресу пункта назначения (или индексу) соответствует указание почтовой подстанции, куда следует посылать далее этот конверт (бандероль, ...). Их сетевые аналоги называются таблицами маршрутизации. Эти таблицы рассылаются почтовым подстанциям централизовано соответствующим почтовым подразделением. Время от времени рассылаются предписания по изменению и дополнению этих таблиц.

В отличие от обычной почты, в Internet таблицы маршрутизации составляются децентрализовано, -- этим занимаются сами узлы, осуществляющие маршрутизацию, -- они называются маршрутизаторами. Как и любые другие действия, составление и модификация таблиц маршрутизации (этот процесс является частью маршрутизации и называется так же) в Internet определяются соответствующими правилами -- протоколами ICMP (Internet Control Message Protocol), RIP (Routeing Information Protocol: RFC 1058, 1721-1724) и OSPF (Open Shortest Path First: RFC 1583-1585).

А откуда сеть знает, куда назначен ваш пакет данных? От вас. Если вы хотите отправить письмо и хотите, чтобы ваше письмо достигло места назначения, вы не можете просто кинуть листочек бумаги в ящик. Вам следует уложить его в стандартный конверт и написать на нём не ``на деревню дедушке'', как Ванька Жуков, а адрес получателя в стандартной форме. Только тогда почта сможет правильно обработать ваше письмо и доставить его по назначению.

Аналогично в Internet имеется набор правил по обращению с IP-пакетами, зафиксированные в соответствующих стандартах -- протоколах. Протокол Internet (IP) берёт на себя заботы по адресации и доставке. Он гарантирует, что все служебные узлы, находящиеся на пути дальнейшего следования ваших данных, знают, что делать. Согласно нашей аналогии, протокол Internet работает также как правила обработки почтового конверта. В начало каждого вашего послания помещается заголовок, несущий информацию об адресате и его сети -- на почтовом конверте надписывается почтовый индекс, адрес, получатель. Чтобы определить, куда доставить пакет данных, этой информации достаточно, как доставить -- это уже заботы сетевого уровня.

Здесь следует хотя бы в общих чертах поговорить об адресации в Internet.

  Адрес в Internet состоит из 4 байт*. При записи байты отделяются друг от друга точками: 123.45.67.89 или 3.33.33.3. (Не пугайтесь, запоминать эти цифры вам не придётся !)

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

Числовой адрес компьютера в Internet аналогичен почтовому индексу отделения связи. Первые цифры индекса говорят о регионе (например, 45 -- это Башкирия, 141 -- Подмосковье и т.д.), последние две цифры -- номер почтового отделения в городе, области или районе. Промежуточные цифры могут относиться как к региону, так и к отделению, в зависимости от территориального деления и вида населённого пункта. Аналогично существует несколько типов адресов Internet (типы: A, B, C, D, E), которые по-разному делят адрес на поля номера сети и номера узла, от типа такого деления зависит количество возможных различных сетей и машин в таких сетях.

Локальные сети в своей работе используют свои собственные адреса, абсолютно независимые от Internet. Так как окончательная доставка данных на компьютер-получатель, если тот включён в Internet в составе локальной сети, осуществляется средствами самой локальной сети, то требуется способ отыскания локально-сетевого адреса компьютера по его IP-адресу. Для определения, где в локальной сети находится компьютер с данным числовым IP-адресом, локальные сети используют специальные протоколы, учитывающие специфику этих сетей. Например, Ethernet для отыскания Ethernet-адреса по IP-адресу компьютера, находящегося в данной сети, использует протокол ARP -- Address Resolution Protocol -- протокол разрешения (в смысле различения) адресов.

Коротко об ARP. Сначала об Ethernet. Работа Ethernet напоминает разговор нескольких вежливых людей в тёмной комнате (имена людей различны!). Если Пафнутий хочет пообщаться с Ясдондуктой, он ждёт, пока кончит тот, кто говорит в данный момент, и начинает:``Ясдондукта! Это Пафнутий (говорит). А не пойти бы тебе со мной на хоккей?''. Ясдондукта отвечает ему аналогично, когда закончится текущий разговор. Если двое начинают говорить одновременно, они замолкают и пытаются начать снова через некоторое случайное время. В Ethernet имеется возможность вести широковещательные передачи. Аналог в описанной тёмной комнате:``Слушайте все! Это Ясдондукта....''

  Теперь собственно об ARP. Допустим, Пафнутию нужно узнать, кто в этой тёмной комнате носит фамилию Забегайло. Он ждёт удобного момента и говорит:``Слушайте все! Это Пафнутий. Кто тут Забегайло?'', а Забегайло ему отвечает (тоже дождавшись тишины):``Пафнутий! Это Патермуфий. Это я есть Забегайло.'' Теперь подставьте вместо ``Забегайло'' конкретный IP-адрес, а вместо имён -- Ethernet-адреса, получите схему работы ARP. Само описание ARP можно прочитать в RFC 826, 917, 925, 1027.

Мы говорили о пересылке данных. Продолжим.

На объёмы информации, пересылаемой в Internet, не накладывается никаких ограничений, но на сетевом уровне по ряду причин (особенно, -- практических, из-за ограничений оборудования, соображений оперативности) информация, пересылаемая по сетям IP, делится на части (по границам байтов), раскладываемые в отдельные пакеты. Объём информации внутри пакета обычно составляет от 1 до 1500 байт. Это препятствует монополизации линий связи каким-либо пользователем и блокировке работы всех остальных, предоставляет всем примерно равные права и возможности.

Это же способствует повышению эффективности использования линий связи. Если во время телефонного разговора вы молча сопите в трубочку, то линия связи используется фактически впустую (если только, на другом конце не находится некто, кто просто балдеет от вашего сопения). А в IP-сетях (точнее -- во всех сетях коммутации пакетов), если вы молчите, никому до того никакого дела нет -- линия связи постоянно загружена, по ней вперемешку одновременно пересылаются пакеты тысяч пользователей, поэтому ваше молчание лишь ускоряет передачу данных других абонентов. Это же сильно снижает финансовую нагрузку на каждого отдельного пользователя. Поэтому же, чем больше людей одновременно работает в сети, тем медленнее сеть обслуживает каждого из них. Следует подчеркнуть, что работа в таких случаях может замедляться, но блокироваться -- никогда!

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

Вернёмся к нашей аналогии. Почта пересылает каждое ваше письмо независимо от других ваших почтовых отправлений. Точно так же в Internet каждый IP-пакет пересылается отдельно, независимо от других, таким образом, IP-пакет является самостоятельным сообщением. Это типичная дейтаграмма, т.е. протокол IP является дейтаграммным протоколом. Это совершенно не укладывается в эталонную модель ISO/OSI, в рамках которой уже сетевой уровень способен работать по методу виртуальных каналов.

Одно из основных достоинств Internet является прямым продолжением этого ``недостатка'' (несоответствия эталонной модели) -- это достоинство состоит в том, что в принципе протокола IP самого по себе уже вполне достаточно для работы. Как только данные помещаются в оболочку IP, сеть имеет всю необходимую информацию для передачи их с исходного компьютера получателю. Эта достаточность является гарантией того, что любой компьютер, неважно каков он (Apple, PDP, VAX, IBM, Sun, Cray и т.д.), умеющий работать с IP, может включиться в Internet. Именно эта открытость и демократичность и привела к фантастической популярности Internet, к её экспоненциальному росту.

Следует, однако, заметить, что работать вручную непосредственно с IP совершенно неудобно. Конечно, обладая старой БЭСМ-овской закалкой или просто достаточной аскетичностью, умом и упорством, можно сделать немало, но такая работа напоминает нам суровые времена доперсональной компьютерной эры, когда пользователь всячески угождал ЭВМ, укрощая свои тело, дух и эстетические чувства. О пользователях никто и не собирался думать, потому что машинное время стоило во много раз дороже человеческого.

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

• Надо научиться пересылать большие, чем 1500 символов, массивы информации. Если этого не сделать, сеть будет напоминать почту, которая пересылает только открытки и отказывается от пересылки писем, не говоря уже о чём-либо большем. Если бы почта была такой, мы бы лишились увлекательнейшего литературного жанра -- эпистолярного. Да и с практической точки зрения она не представляла бы большого интереса.
• Надо обеспечить надёжность пересылки информации. Как вы сами прекрасно знаете, связь не отличается безгрешностью. Случаются и неудачи. Почта любит терять письма. Сеть тоже, бывает, теряет пакеты или искажает в пути информацию в них. Вы бы хотели, чтобы Internet была похожа на почту? Никто этого не хочет, поэтому надо научить Internet с честью выходить из таких затруднительных положений.
• Пакеты могут приходить в последовательности, отличной от исходной. Пара писем, отправленных друг за другом на днях, не всегда приходит к получателю в том же порядке. Это имеет место в любых сетях коммутации пакетов с большим числом узлов. То же верно и для Internet. Поэтому следует сообразить некий механизм для восстановления исходной последовательности.

Подробнее о самом IP читайте в RFC 760, 781, 791, 815 ... См. также IPng или IPv6.

Transmission Control Protocol -- это протокол, который используется для обеспечения услуг по надёжной упорядоченной доставке данных. Это протокол транспортного уровня эталонной модели ISO/OSI.

Протокол TCP тесно завязан на IP и выполняет в Internet очень важную транспортную функцию, и именно поэтому часто технологию, основанную на IP, называют не просто технологией IP, а TCP/IP. TCP/IP -- это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется internet*.

Термин ``TCP/IP'' обычно обозначает всё, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы TCP, UDP, ICMP, telnet, FTP и многие другие. Иерархия протоколов семейства TCP/IP показана* на рисунке 3.2 (стр. X).

 
Рисунок: Иерархия протоколов семейства IP

TCP предоставляет более высоким уровням транспортную услугу -- так называемое TCP-соединение, являющееся разновидностью виртуального канала.

Виртуальный канал -- это просто такая волшебная трубочка. То, что кладётся в неё с одной стороны волшебным образом появляется в целости и сохранности на другом конце, причём, именно в таком порядке, каком всё входило в неё на исходном конце. И эта трубочка обладает удивительным свойством: она может пересылать одновременно в двух направлениях. Сейчас мы всё это волшебство рассмотрим внимательно и увидим, конечно, что ничего волшебного там нет, а всё очень просто.

Протокол TCP занимается пересылкой больших объёмов информации, используя для этого возможности протокола IP. Как это делается? Вполне здраво можно рассмотреть следующую ситуацию. Нужно переслать книгу по почте, но та принимает только письма и ничего более? Что делать? Очевидный метод*: просто разодрать её на страницы и отправить их отдельными конвертами. Получатель, руководствуясь номерами страниц, легко сможет книгу восстановить. Этим простым и естественным методом и пользуется TCP.

TCP-модуль делит информацию, которую надо переслать, на несколько частей приемлемого размера. Нумерует каждую часть, чтобы позже восстановить порядок. Чтобы пересылать эту нумерацию вместе с данными, он обкладывает каждый такой фрагмент своей обложкой -- конвертом, который содержит служебную информацию. Это и есть TCP-конверт. Далее он передаёт этот получившийся TCP-пакет модулю сетевого уровня -- IP-модулю, который помещает каждый переданный ему сверху блок данных (TCP-пакет) в отдельный IP-конверт, указывает на нём, куда и кому (какому модулю транспортного уровня) его нужно передавать, -- получается IP-пакет, с которым сеть уже умеет обращаться. Откуда IP-модуль узнает, какой сетевой адрес следует указывать на IP-конверте? Этот адрес ему сообщает TCP-модуль.

Что делает с информацией при пересылке ``простым и естественным'' способом отправитель, схематично показано на рисунке 3.3.

 
Pucyнoк: Передача данных в многоуровневой модели

Немного об аналогиях этой схемы. Отдельные листы книги -- это аналог TCP-пакетов: на них в колонтитуле указано, из какой они книги, а также имеется информация об их положении в исходной последовательности (номера страниц). Большие конверты, в которые укладываются отдельные листы (каждый лист -- в отдельный конверт), -- это аналоги IP-пакетов: они содержат полную адресную информацию (адреса получателя и отправителя). Маленькие конверты -- это аналоги пакетов локальных сетей, используемых в качестве среды передачи (например, Ethernet): на них указана полная адресная информация локальной сети. IP-пакеты для пересылки упаковываются в пакеты, используемые самой средой передачи данных. При этом, если IP-пакет не помещается в отдельный пакет локальной сети, он разбивается на несколько частей подходящего размера. Точнее не просто разбивается, а разделяется на несколько IP-пакетов. IP-пакет несёт информацию, необходимую для отслеживания подобных случаев ``разборки'' IP-пакета и обратной его ``сборки''. Далее для простоты картины будем считать, что разборки и обратной сборки нет.

Итак, отправитель передал IP-пакеты в Сеть. Доставка получателю -- забота сетевого уровня.

При собственно пересылке по Сети эти фрагменты (IP-пакеты) перемежаются с другими аналогичными от других пользователей, поэтому пересылка получается достаточно дешёвой. IP-пакеты пересылаются независимо друг от друга и потихоньку (за пару-тройку десятых секунды (0,2-0,3с)), а то и быстрее, доходят до получателя.

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

В действительности, это слегка утрированный взгляд на TCP. В реальности пакеты не только теряются, но и могут искажаться при передаче из-за наличия помех на линиях связи. TCP решает и эту проблему. Для этого он пользуется системой кодов, исправляющих ошибки. Существует целая наука о таких кодировках. Простейшим примером такового служит код с добавлением к каждому пакету контрольной суммы (и к каждому байту бита проверки на чётность). При помещении в TCP-конверт вычисляется контрольная сумма, которая записывается в TCP-заголовок. Если при приёме заново вычисленная сумма не совпадает с той, что указана на конверте, значит что-то тут не то, -- где-то в пути имели место искажения, так что надо переслать этот пакет по-новой, что и делается.

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

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

Таким образом, протокол TCP обеспечивает гарантированную доставку с установлением логического соединения в виде байтовых потоков. Он освобождает прикладные процессы от необходимости использовать ожидания и повторные передачи для обеспечения надёжности. Наиболее типичными прикладными процессами, использующими TCP, являются ftp, telnet и e-mail. Кроме того, TCP использует система X-Windows (стандартный многооконный графический интерфейс), ``r-команды''.

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

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

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

Для ясности и полноты картины, необходимо сделать здесь важное замечание: модуль TCP разбивает поток байтов на фрагменты, не сохраняя при этом границ между записями. То есть, если один прикладной процесс помещает 3 блока данных в TCP-порт, то совсем не обязательно, что другой прикладной процесс на другом конце виртуального канала получит из своего TCP-порта именно 3 блока данных, причём именно таких (по разбиению), что были переданы с другого конца. Вся информация будет получена исправно и с сохранением порядка передачи, но она может уже быть разбита по другому и на иное количество частей. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.

Для наглядности продемонстрируем процесс передачи данных каким-нибудь приложением, пользующимся транспортными средствами TCP. Не теряя общности, можно для определённости предполагать, что в качестве среды передачи используется локальная сеть Ethernet.

Хотим вывести вас из одного широко распространённого заблуждения. Рады за вас, если вам это не требуется.

Многим почему-то кажется, что Ethernet и Novell Netware -- близнецы братья. Они ошибаются! Первое -- это технология физического и канального уровней, а второе -- сетевого и выше. Это совершенно разные вещи.

Ethernet может использоваться любыми технологиями сетевого уровня: DECnet, Novell, TCP/IP... Более того, они могут использоваться одновременно в одной и той же локальной сети независимо друг от друга! Трафики этих сетей будут абсолютно независимы и друг с другом взаимодействовать не будут. Надеемся, мы смогли вас просветить. Вернёмся к нашим баранам.

 
Pucyнoк: Схема обработки данных, производимой отправителем

На рисунке 3.4 вы видите, что творится с данными при их отправке по TCP-каналу. Маленькие прямоугольнички с надписями TCP, IP и Eth, подклеенные к началам блоков данных, суть протокольные заголовки соответственно TCP, IP и Ethernet. Маленькое уточнение: TCP и IP всю свою служебную информацию помещают в заголовок, а Ethernet часть своей информации помещает в заголовок, а контрольную сумму -- в конец пакета, именно эта контрольная сумма (check summ) представлена на рисунке прямоугольничком с надписью chk.

На конце отправителя ситуация очевидна. Теперь получившиеся Ethernet-пакеты пересылаются по физическому уровню сети Ethernet. При этом возможны сбои в работе сети, часть пакетов может потеряться, часть может где-то (например, в мостах) ненароком задержаться, и ``гулять'' по сети дольше других, информация в пакетах может исказиться. То, что придёт на другой конец Ethernet-линии будет представлять мешанину из того, что было послано.

Возможно, вы спросите, откуда сеть Ethernet узнает кому доставлять послания? Мы это уже выяснили в разговоре о сетевом уровне (см. стр. X). Поднявшись на следующий уровень, мы можем и должны вообще забыть о том, как работают уровни ниже данного. Это сильно упрощает работу. В этой простоте -- сила многоуровневой схемы ISO/OSI.

Теперь смотрите на рисунок 3.5. Там вы видите, что происходит с данными по их получении на другом конце.

 
Pucyнoк: Схема обработки данных, производимой получателем

Видите, пакет с блоком ``И !'' между IP-уровнем и TCP-уровнем перескакивает в конец последовательности. Этим мы хотели показать, что возможно перемешивание порядка пакетов даже на уровне IP. Хотя, вообще говоря, такое поведение этого пакета можно объяснить и по другому: просто TCP-уровень обнаружил искажение информации пакета и затребовал повторной пересылки этого блока данных.

Итак, восстановление целостности информации и её порядка происходит на TCP-уровне. TCP, однако, не сохраняет границ тех блоков, которые ему были спущены сверху -- это хорошо видно при сравнении рисунков: отправитель передал TCP-модулю блоки ``ДЭВИ! '', ``ГДЕ'', `` БАРАНЫ ?'', а его коллега-получатель получил блоки ``ДЭВ'', `` И! '', ``ГДЕ'', `` БА'', ``РАН'', ``Ы ?''.

Итак, TCP эмулирует* выделенную линию связи двух пользователей. Гарантирует неизменность передаваемой информации. Что входит на одном конце, выйдет с другого. Хотя в действительности никакая прямая линия отправителю и получателю в безраздельное владение не выделяется (другие пользователи могут пользовать те же узлы и каналы связи в сети в промежутках между пакетами этих двух), но извне это, практически, именно так и выглядит.

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

Имеется другой стандартный протокол транспортного уровня, который не отягощён такими накладными расходами. Этот протокол называется UDP -- User Datagram Protocol -- протокол пользовательских дейтаграмм. Он используется вместо TCP. Здесь данные помещаются не в TCP, а в UDP-конверт, который также помещается в IP-конверт. Этот протокол реализует дейтаграммный способ передачи данных. Хотя IP-пакет есть дейтаграмма, он по своему уровню не пригоден для прямого использования в прикладных процессах, например, хотя бы из соображений соответствия передачи эталонной модели ISO/OSI.

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

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

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

Предположим, что вы пишете программу, которая просматривает базу данных с телефонными номерами где-нибудь в другом месте сети. Совершенно незачем устанавливать TCP связь, чтобы передать 33 или около того символов в каждом направлении. Вы можете просто уложить имя в UDP-пакет, запаковать это в IP-пакет и послать. На другом конце прикладная программа получит пакет, прочитает имя, посмотрит телефонный номер, положит его в другой UDP-пакет и отправит обратно. Что произойдёт, если пакет по пути потеряется? Ваша программа должна действовать так: если она ждёт ответа слишком долго и становится ясно, что пакет затерялся, она должна повторить свой запрос, т.е. послать ещё раз то же самое. Так обеспечивается надёжность передачи при использовании протокола UDP.

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

Альтернатива TCP-UDP позволяет программисту гибко и рационально использовать предоставленные ресурсы, исходя из своих возможностей и потребностей. Если нужна надёжная доставка, то лучше может быть TCP. Если нужна доставка дейтаграмм, то -- UDP. Если нужна эффективная доставка по длинному и ненадёжному каналу передачи данных, то лучше использовать TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, лучше всего будет UDP. Если потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Прикладные программы, конечно, могут устранять некоторые недостатки выбранного транспортного средства. Например, если вы выбрали UDP, а вам необходима надёжность, то ваша прикладная программа должна обеспечить её сама, как описано выше: требовать подтверждения, пересылки утерянных или увечных пакетов и т.д. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять метки в поток байтов так, чтобы можно было различить записи.

До сих пор мы ничего не сказали о том, возможно ли создание и одновременное использование нескольких виртуальных каналов. Естественно, было бы удобно, если бы транспортная компонента (TCP и UDP) могла предоставлять услуги по доставке данных сразу многим процессам более высокого уровня.

Мы уже намекали, что в Internet прикладные процессы осуществляют доступ к услугам транспортного уровня в различных точках, называемых портами. Порт в данном случае -- чистая абстракция, весь смысл которой заключён в её номере. Номер порта указывается среди прочей служебной информации в заголовке пакета транспортного уровня. Именно по этому номеру порта модуль (процесс) транспортного уровня различает данные разных процессов прикладного уровня.

Информация, помещённая каким-либо прикладным процессом в порт с номером N на компьютере отправителя, будет передана транспортной компоненте адресата, которая выдаст его получателю прикладного уровня в порт с указанным номером K. Таким образом, номера портов определяют не только получателя, но и отправителя.

Например, на компьютере одновременно могут работать telnet, ftp, e-mail потому, что они используют различные TCP-порты. Одновременно с ними может работать ещё и множество приложений, использующих разные UDP-порты, к примеру, NFS, TFTP, DNS.

  Дадим краткие разъяснения к рисунку 3.2 заинтересовавшимся. На этом рисунке представлены для примера следующие протоколы из великого семейства IP:

TCP

См. RFC 793, 962, 1072, 1078, 1185, 1323, 1644, 1693 и т.д.

UDP

См. RFC 768, 1240 и т.д.

FTP

протокол пересылки файлов. С помощью этого протокола организовывается пересылка файлов по Cети. Технические подробности можно узнать из RFC-документации, а именно: RFC 468, 478, 959, 1579, 1635, 1639.

telnet

протокол эмуляции терминала удалённой машины. С помощью этого протокола организовываются сеансы работы на удалённых машинах сети -- эмулируется терминал далёкого компьютера. NIC просто изобилует информацией в виде RFC-документов по этому протоколу. Вот лишь некоторые из этих документов: RFC 854, 764, 818, 1184, 1408, 1411, 1412, 1416, 1572.

SMTP

протокол пересылки простой почты -- протокол, обеспечивающий работу e-mail. См. техническую документацию в RFC 788, 821, 822, 1123, 1651, 1733.

TFTP

протокол простейшей (тривиальной) пересылки файлов. Осуществляет пересылку файлов дейтаграммными средствами UDP. См. RFC 1350.

DNS

протокол доменной (региональной) системы имён -- протокол запросов на преобразование имён из доменной формы в машинную -- числовую. См. RFC 883, 974, 1101, 1183, 1611, 1612, 1706 и т.д.

Служба времени

служба синхронизации разнесённых в сети часов. Это протокол сетевого времени -- NTP. См. RFC 956-958, 1129, 1165, 1305 и т.д.

RIP

информационный протокол маршрутизации. Используется для поддержания достоверной информации о состоянии сети, необходимой для маршрутизации. Описан в RFC 1058, 1721-1724.

GGP

протокол ``шлюз -- шлюз'' -- межшлюзовый протокол. Этот протокол использовался в объединённой сети Internet -- ARPAnet. Ныне представляет чисто исторический интерес. См. RFC 823.

HMP

протокол мониторинга хоста -- протокол непрерывного слежения (контроля) за хостом (сетевым рабочим компьютером). См. RFC 869.

EGP

внешний межшлюзовый протокол. Этот протокол используется при взаимодействии отдельных шлюзов различных автономных систем (AS), осуществляемом с целью обмена маршрутной информацией. См. RFC 827, 888, 890, 904, 911, 1092;

ICMP

протокол межсетевых управляющих сообщений -- сетевой протокол, предоставляющий процессам в сети возможность предпочтительного выбора в своём множестве маршрутов пересылки и других подобных вещей. Хотя он пользуется транспортными услугами IP, в действительности, ICMP является важной частью IP, именно поэтому мы его так выделили на рисунке. См. документы RFC 777, 792, 1256.

Как вы сами понимаете, протоколы IGP, GGP и ICMP транспортными не являются. Эти протоколы являются служебными -- они обеспечивают работу сетевого уровня. Без них IP был бы не дееспосбен. Таким образом, если исходить из их функционального предназначения, эти протоколы следовало бы отнести к межестевому уровню, т.е. поставить в один ряд с IP. Но наша схема показывает только ``кто на ком ездит''. IGP, GGP и ICMP базируются на IP, поэтому мы их и поставили выше.

Транспортными являются только протоколы TCP и UDP, -- именно они организуют транспортные услуги, которыми пользуются все протоколы более высокого уровня.