опросы производительности.

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

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

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

В следующих разделах мы рассмотрим следующие пять аспектов производи­тельности сети.

1. Причины снижения производительности.

2. Измерение производительности сети.

3. Проектирование производительных систем.

4. Быстрая обработка TPDU-модулей.

5. Протоколы для будущих высокопроизводительных сетей.

Нам потребуется ввести название для единиц данных, которыми обменивают­ся транспортные сущности. Термин «сегмент», применяемый в протоколе TCP, в лучшем случае запутывает и никогда не используется в этом смысле за преде­лами мира TCP. Соответствующие ATM-термины — CS-PDU (протокольная единица обмена подуровня конвергенции), SAR-PDU и CPCS-PDU — применя­ются только в сетях ATM. Термин «пакет» относится к сетевому уровню, а сооб­щения применяются на прикладном уровне. За отсутствием стандартного терми­на мы будем продолжать называть единицы данных, которыми обмениваются транспортные сущности, TPDU-модулями. Когда будет иметься в виду TPDU- модуль вместе с пакетом, мы будем использовать в качестве обобщающего тер­мина понятие «пакет», например: «Центральный процессор должен быть доста­точно быстрым, чтобы успевать обрабатывать приходящие пакеты в режиме ре­ального времени». При этом будет иметься в виду как пакет сетевого уровня, так и помещенный в него TPDU-модуль.

Всемирная архитектура.Всемирная паутина (WWW, World Wide Web) — это архитектура, являющаяся основой для доступа к связанным между собой документам, находящимся на мил­лионах машин по всему Интернету. За 10 лет своего существования из средства распространения информации на тему физики высоких энергий она преврати­лась в приложение, о котором миллионы людей с разными интересами думают, что это и есть «Интернет». Огромная популярность этого приложения стала следствием цветного графического интерфейса, благодаря которому даже нович­ки не встречают затруднений при его использовании. Кроме того, Всемирная пау­тина предоставляет огромное количество информации практически по любому вопросу, от африканских муравьедов до яшмового фарфора.

Всемирная паутина была создана в 1989 году в Европейском центре ядерных исследований CERN (Conseil Еигорёеп pour la Recherche Nucleaire) в Швейца­рии. В этом центре есть несколько ускорителей, на которых большие группы ученых из разных европейских стран занимаются исследованиями в области фи­зики элементарных частиц. В эти команды исследователей часто входят ученые из пяти-шести и более стран. Эксперименты очень сложны, для их планирования и создания оборудования требуется несколько лет. Программа Web (паутина) появилась в результате необходимости обеспечить совместную работу находя­щихся в разных странах больших групп ученых, которым нужно было пользо­ваться постоянно меняющимися отчетами о работе, чертежами, рисунками, фо­тографиями и другими документами.

Изначальное предложение, создать паутину из связанных друг с другом доку­ментов пришло от физика центра CERN Тима Бернерс-Ли (Tim Berners-Lee) в марте 1989 года. Первый (текстовый) прототип заработал спустя 18 месяцев. В декабре 1991 году на конференции Hypertext'91 в Сан-Антонио в штате Техас была произведена публичная демонстрация.

Эта демонстрация, сопровождаемая широкой рекламой, привлекла внимание других ученых. Марк Андрессен (Marc Andreessen) в университете Иллинойса начал разработку первого графического браузера, Mosaic. Программа увидела свет в феврале 1993 года и стала настолько популярной, что год спустя ее автор Марк Андрессен решил сформировать собственную компанию Netscape Communications Corp., чьей целью была разработка клиентов, серверов и другого программного обеспечения для веб-приложений. Когда в 1995 году корпорация Netscape полу­чила известность, инвесторы, полагая, очевидно, что появилась еще одна корпора­ция типа Microsoft, заплатили за пакет ее акций 1,5 млрд. долларов. Это было тем более удивительно, что номенклатура продукции компании состояла всего из од­ного наименования, компания имела устойчивый пассивный баланс, а в своих проспектах корпорация Netscape объявила, что в обозримом будущем не рассчи­тывает на получение прибыли. В течение последующих трех лет между Netscape Navigator и Internet Explorer от Microsoft развернулась настоящая «война брау­зеров». Разработчики с той и с другой стороны в безумном порыве пытались на­пичкать свои программы как можно большим числом функций (а следовательно, и ошибок) и в этом превзойти соперника. В 1998 году America Online купила корпорацию Netscape Communications за 4,2 млрд долларов, положив таким образом конец весьма непродолжительному независимому существованию ком­пании.

В 1994 году CERN и Массачусетский технологический институт (M.I.T., Massa­chusetts Institute of Technologies) подписали соглашение об основании WWW- консорциума (World Wide Web Consortium, иногда применяется сокращение W3C) — организации, цель которой заключалась в дальнейшем развитии прило­жения Web, стандартизации протоколов и поощрении взаимодействия между от­дельными сайтами. Бернерс-Ли стал директором консорциума. Хотя о Всемир­ной паутине уже написано очень много книг, лучшее место, где вы можете полу­чить самую свежую информацию о ней, это сама Всемирная паутина.

Представление об архитектуре

С точки зрения пользователя Всемирная паутина состоит из огромного собрания документов, расположенных по всему миру. Документы обычно называют для краткости просто страницами. Каждая страница может содержать ссылки (указа­тели) на другие связанные с ней страницы в любой точке мира. Пользователи мо­гут следовать по ссылке (например, просто щелкнув на ней мышью), при этом страница, на которую указывает ссылка, загружается и появляется в окне браузера. Этот процесс можно повторять бесконечно. Идея страниц, связанных между собой гиперссылками (гипертекст), была впервые пророчески предложена в 1945 году, задолго до появления Интернета, Ванневаром Бушем (Vannevar Bush), профес­сором из Массачусетского университета, занимавшимся электротехникой.

Страницы просматриваются специальной программой, называемой браузером. Самыми популярными браузерами являются программы Internet Explorer и Netsca­pe. Браузер предоставляет пользователю запрашиваемую страницу, интерпрети­рует ее текст и содержащиеся в нем команды форматирования для вывода стра­ницы на экран. Как и большинство веб-страниц, страница, показанная на рис. 7.6, а начинается с заголовка, содержит некоторую информацию и заканчивается адре­сом электронной почты организации, отвечающей за состояние этой страницы. Строки текста, представляющие собой ссылки на другие страницы, называются га- перссылками. Они обычно выделяются либо подчеркиванием, либо другим цветом, либо и тем и другим. Чтобы перейти по ссылке, пользователь перемещает указатель мыши в вьщеленную область, при этом меняется форма указателя, и щелкает на ней. Хотя существуют и текстовые браузеры, как, например, Lynx, они не так популярны, как графические, поэтому мы сконцентрируем наше внимание на последних. Сле­дует заметить, что также разрабатываются браузеры, управляемые голосом.

ачество обслуживания.

Последовательность пакетов, передающихся от источника к приемнику, называ­ется потоком. При этом в сетях, ориентированных на соединение, все пакеты по­тока следуют по одному и тому же маршруту, а в сетях без установления соединения они могут идти разными путями. Каждому потоку требуются определенные усло­вия, которые можно охарактеризовать следующими четырьмя основными пара­метрами: надежность, задержка, флуктуация и пропускная способность. Все вме­сте они формируют то, что называется качеством обслуживания (QoS — Quality of Service), необходимым потоку. Первые четыре приложения предъявляют высокие требования к надежности. Некорректная доставка битов должна быть исключена. Обычно это достигается подсчетом контрольной суммы для каждого пакета и ее проверкой у получателя.

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

Приложения, занимающиеся передачей файлов, включая электронную почту и видео, не чувствительны к задержкам. Даже если все пакеты будут доставляться с задержкой в несколько секунд, ничего страшного не произойдет. Однако ин­терактивные приложения — например, обеспечивающие веб-доступ или удален­ный доступ, — к задержкам более критичны. Что касается приложений, работаю­щих в реальном масштабе времени, их требования к задержкам очень строги. Если при телефонном разговоре все слова собеседников будут приходить с задержкой ровно 2,000 с, пользователи сочтут такую связь неприемлемой. С другой сторо­ны, проигрывание видео- или аудиофайлов, хранящихся на сервере, допускает наличие некоторой задержки.

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

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

 

Коммутация на уровне передачи данныхУ многих организаций имеется по несколько локальных сетей, которые необхо­димо объединять между собой. Локальные сети могут быть объединены с помо­щью специальных устройств, называемых мостами, которые работают на уровне передачи данных. Они анализируют адреса, содержащиеся в кадрах этого уровня, и в соответствии с ними осуществляют маршрутизацию. Поскольку мосты не ис­следуют сами данные, передающиеся в кадрах, то они одинаково хорошо справля­ются с пакетами IPv4 (используемыми сейчас в Интернете), IPv6 (которые будут использоваться в Интернете позже), AppleTalk, ATM, OSI и многими другими. В отличие от мостов, маршрутизаторы анализируют адреса пакетов и работают, основываясь на этой информации. Хотя кажется, что можно провести очень чет­кое разделение между мостами и маршрутизаторами, некоторые современные раз­работки, такие как коммутируемый Ethernet, несколько замутили воду, как мы увидим далее. В следующих разделах мы рассмотрим мосты и коммутаторы, осо­бое внимание обратив на те из них, которые связывают различные типы ЛВС се­ рии 802. Подробную информацию о мостах, коммутаторах и т. п. можно найти у (Perlman, 2000).Прежде чем перейти к обсуждению мостов, стоит рассмотреть несколько час­то встречающихся ситуаций, в которых они используются. Перечислим шесть причин, по которым в организации может появиться несколько локальных сетей.Во-первых, у многих университетов и отделов корпораций есть свои локаль­ные сети, соединяющие персональные компьютеры, рабочие станции и серверы. Поскольку цели различных факультетов или отделов различны, то и объедине­ние в локальные сети часто происходит по факультетам и отделам, которым не очень интересно, как построена сеть у соседей. Однако рано или поздно им тре­буется взаимодействие, поэтому появляется необходимость в мостах. В данном примере несколько отдельных локальных сетей образовалось вследствие авто­номности их владельцев.Во-вторых, организации могут размещаться в нескольких зданиях, значитель­но удаленных друг от друга. Может оказаться дешевле создать несколько отдель­ных локальных сетей и затем соединить их с помощью мостов и лазерных линий связи, вместо того чтобы протягивать коаксиальный кабель по всей территории.В-третьих, иногда бывает необходимо логически разделить одну локальную сеть на несколько, чтобы снизить нагрузку. Так, например, во многих универси­тетах в сети объединены тысячи рабочих станций, на которых работают студен­ты и сотрудники. Файлы обычно хранятся на файл-серверах и загружаются на машины пользователей по мере необходимости. Огромные масштабы не позво­ляют объединить все эти рабочие станции в одну локальную сеть, так как для этого потребовалась бы слишком высокая суммарная пропускная способность. Вместо этого формируются несколько локальных сетей, соединенных мостами, как показано на рис. 4.35. В каждую локальную сеть входят несколько рабочих станций и свой файловый сервер, поэтому основной трафик ограничивается рамками локальной сети и не нагружает магистраль.

Конфиденциальность электронной переписки

Наш первый пример, система PGP (Pretty Good Privacy — довольно хорошая конфиденциальность), создана всего одним человеком, Филом Циммерманом (Phil Zimmermann, 1995а, 1995b). Циммерман является сторонником безопасно­сти в сетях, и его девиз таков: «Если конфиденциальность объявлена вне закона, значит, пользоваться ею будут только нарушители закона». Выпущенная в 1991 году система PGP представляет собой полный пакет для электронной почты, обеспе­чивающий конфиденциальность, аутентификацию, цифровые подписи и сжатие. Все это делается в легкой и удобной форме. Более того, полный пакет, включаю­щий все исходные тексты программ, свободно распространяется через Интернет. Благодаря своему качеству, цене (нулевой) и простоте установки на различных платформах, включая UNIX, Linux, Windows и Mac OS, в настоящее время систе­ма PGP получила широкое распространение.

PGP кодирует данные с помощью блочного шифра IDEA (International Data Encryption Algorithm — международный алгоритм шифрования данных), ис­пользующего 128-разрядные ключи. Он был изобретен в Швейцарии в те време­на, когда DES уже считался устаревшим, a AES еще не был придуман. Концеп­туально IDEA похож на DES/AES: производится смешивание разрядов в серии, однако детали реализации функций отличают его от DES и AES. Управление ключами происходит с помощью RSA, а для задач обеспечения целостности дан­ных применяется MD5. Все эти методы мы обсуждали ранее.

В противоположность системе PGP, целиком созданной одним человеком, систе­ма РЕМ (Privacy Enhanced Mail — почта повышенной секретности) является официальным стандартом Интернета и описана в четырех RFC: с RFC 1421 по RFC 1424. Система РЕМ обладает примерно тем же набором функций, что и сис­тема PGP: секретность и аутентификация для систем электронной почты стан­дарта RFC 822. Тем не менее, она имеет несколько отличий от системы PGP в ме­тодах и технологии.

Сообщения, посылаемые с помощью системы РЕМ, сначала преобразуются в каноническую форму, удовлетворяющую особому набору правил, касающихся использования пробелов, табуляторов, символов возврата каретки и перевода стро­ки. Затем с помощью алгоритма MD2 или MD5 вычисляется хэш-код сообщения. Потом конкатенация хэш-кода и сообщения шифруются при помощи алгорит­ма DES. В свете обсуждавшихся недостатков 56-разрядного ключа выбор имен­но этой системы шифрования, несомненно, вызывает большие подозрения. За­тем зашифрованное сообщение преобразуется в кодировку base64 и передается получателю.

Как и в PGP, каждое сообщение шифруется одноразовым ключом, передавае­мым вместе с сообщением. Ключ может быть защищен либо алгоритмом RSA, либо тройным применением системы DES в режиме EDE.

Следующим изобретением IETF в области обеспечения конфиденциальности элект­ронной почты стала система под названием S/MIME (Secure/MIME — защищенный MIME). Она описывается в RFC с 2632 по 2643. Подобно РЕМ, она обеспечивает аутентификацию, целостность данных, секретность и проверку подлинности ин­формации. Обладает неплохой гибкостью, поддерживает разнообразные крипто­графические алгоритмы. По названию можно догадаться, что S/MIME тесно свя­зана с MIME в том смысле, что позволяет защищать любые типы сообщений. Определено множество новых заголовков MIME, например, для цифровых под­писей.

Группа IETF определенно извлекла какие-то уроки из опьпа РЕМ. В S/MIME нет жесткой иерархии сертификатов, отсутствует единый центр управления. Вместо этого пользователи могут работать с набором доверительных якорей. До тех пор, пока сертификат может быть проверен по доверительному якорю, он считается корректным. Система S/MIME использует стандартные алгоритмы и протоколы, которые мы уже рассматривали, поэтому на этом мы закончим ее об­суждение. Более подробную информацию вы найдете в RFC.

 

риптография.

Слово критшрафии происходит от греческих слов, означающих «скрьпное пись­мо». У криптографии долгая и красочная история, насчитывающая несколько ты­сяч лет. В данном разделе мы всего лишь кратко упомянем некоторые отдельные моменты в качестве введения к последующей информации. Желающим ознако­миться с полной историей криптографии рекомендуется (Kahn, 1995). Для полу­чения всестороннего представления о текущем положении дел см. (Kaufman и др., 2002). С математическими аспектами криптографии можно познакомиться, прочитав книгу (Stinson, 2002). Менее формальным (с математической точки зрения) языком ведется изложение в (Burnett и Paine, 2001).

С профессиональной точки зрения понятия «шифр» и «код» отличаются друг от друга. Шифр представляет собой посимвольное или побитовое преобразова­ние, не зависящее от лингвистической структуры сообщения. Код, напротив, за­меняет целое слово другим словом или символом. Коды в настоящее время не используются, хотя история у них, конечно, славная. Наилучшим считается код, использовавшийся американскими войсками в Тихом океане во время второй Мировой войны. Просто-напросто для ведения секретных переговоров исполь­зовались носители языка индейцев навахо, словами из которого обозначались военные термины. Например, слово чаи-дагахи-найл-цайди (буквально — убийца черепах) означало противотанковое оружие. Язык навахо тоновый (для различе­ния смысла используется повышение или понижение тона), весьма сложный, не имеет письменной формы. Но самое большое его достоинство заключалось в том, что ни один японец не имел о нем ни малейшего представления.

В сентябре 1945 года Уния Сан-Диего так описывала этот код: «В течение трех лет, где бы ни высаживались военные моряки, уши японцев различали лишь странный булькающий шум, перемежающийся с другими звуками. Все это напо­минало клич тибетского монаха или звук опустошаемой бутылки с горячей во­дой». Японцы так и не смогли взломать этот код, и многие носители языка ин­дейцев навахо были удостоены высоких воинских наград за отличную службу и смелость. Тот факт, что США смогли расшифровать японский код, а японцы так и не узнали язык навахо, сыграл важную роль в американской победе в Тихом океане. Основы криптографии

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

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

ультимедиа.

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

Несмотря на такое довольно понятное определение, многие, говоря «мульти­медиа», имеют в виду только чисто звуковую информацию, например интернет- телефонию или интернет-радио. Строго говоря, они не правы. Более удачным термином в данном случае является словосочетание потоковая информация (strea­ming media), однако мы, поддавшись стадному инстинкту, все же будем имено­вать аудиоданные, передающиеся в реальном масштабе времени, «мультимедиа». В следующих разделах мы узнаем, как компьютер обрабатывает звук и видео и как он сжимает такого рода данные. Затем мы рассмотрим некоторые сетевые технологии, связанные с мультимедиа. Довольно понятно и в хорошем объе­ме (три тома) взаимодействие сетевых и мультимедийных технологий описано в (Steinmetz и Nahrstedt, 2002; Steinmetz и Nahrstedt, 2003а; Steinmetz и Nahr- stedt, 2003b).

Основы цифровой обработки звука

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

Человеческое ухо способно слышать сигналы в диапазоне частот от 20 до 20 000 Гц, хотя некоторые животные, например собаки, могут слышать и более высокие частоты. Громкость, воспринимаемая ухом, изменяется логарифмиче­ски по отношению к частоте, поэтому сила звука обычно измеряется в логариф­мах отношения амплитуд.

Человеческое ухо удивительно чувствительно к изменениям звука, длящимся всего несколько миллисекунд. Глаз, напротив, не в состоянии заметить такие кратковременные изменения. Таким образом, флуктуация (джиггер) в несколь­ко миллисекунд при передаче мультимедиа влияет в большей степени на качест­во звука, чем на качество изображения.

 

Протоколы коллективного доступа

Чистая система ALOHA

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

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

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

Дискретная система ALOHA

В 1972 г. Роберте (Roberts) опубликовал описание метода, позволяющего удво­ить производительность систем ALOHA (Roberts, 1972). Его предложение за­ключалось в разделении времени на дискретные интервалы, соответствующие времени одного кадра. При таком подходе пользователи должны согласиться с определенными временными ограничениями. Одним из способов достижения синхронизации является установка специальной станции, испускающей синхро­низирующий сигнал в начале каждого интервала.

В системе Робертса, известной под названием дискретная ALOHA, в отличие от чистой системы ALOHA Абрамсона, компьютер не может начинать передачу сразу после нажатия пользователем клавиши Enter. Вместо этого он должен дож­даться начала нового такта. Таким образом, непрерывная чистая система ALOHA превращается в дискретную. Поскольку опасный временной интервал теперь становится в два раза короче, вероятность отсутствия передачи по каналу за тот же интервал времени, в течение которого передается тестовый кадр, равна е~ . В результате получаем:

S=Ge~.

 

Протоколы скользящего окна

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

Более прогрессивной идеей представляется использование одного канала для передачи данных в обоих направлениях. В конце концов, ведь в протоколах 2 и 3 кадры уже передавались по каналу в двух направлениях, а обратный канал обла­дает той же пропускной способностью, что и прямой. В такой модели кадры с данными от машины А для машины В перемешиваются с кадрами подтвержде­ний от А к В. Получатель может отличить кадр с данными от кадра с подтвер­ждением по специальному полю kind заголовка кадра.

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

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

Однако при совмещении передачи прямых и обратных пакетов в протоколе появляются новые проблемы. Как долго должен уровень передачи данных ждать пакета, с которым следует переслать подтверждение? Если уровень передачи дан­ных будет ждать дольше, чем отправитель, то последний пошлет кадр повторно, что неприемлемо. Если бы уровень передачи данных мог предсказывать буду­щее, он бы знал, ждать ему пакета или отправлять подтверждение отдельным ка­дром. Это, конечно, невозможно, поэтому следует установить еще один интервал ожидания (меньший, чем интервал ожидания отправителя), по истечении кото­рого подтверждение отправляется отдельным кадром. Если же сетевой уровень

успеет передать уровню передачи данных пакет, то подтверждение будет отосла­но вместе с этим пакетом в одном кадре.

Следующие три протокола являются двунаправленными и принадлежат к клас­су протоколов скользящего окна (sliding window). Как будет показано далее, они отличаются друг от друга эффективностью, сложностью и требованиями к размерам буфера. Во всех протоколах скользящего окна каждый исходящий кадр содержит порядковый номер (варьирующийся от 0 до некоего максимума). Поскольку на этот номер обычно отводится поле размером п бит, максимальное значение номера составляет 2" — 1. В протоколах скользящего окна с ожиданием обычно на это поле отводится всего один бит, что ограничивает порядковый но­мер значениями 0 и 1, однако в более сложных версиях может использоваться произвольное значение п.

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

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

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

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

Сеть Ethernet

Итак, мы в целом закончили обсуждение общих вопросов, касающихся протоко­лов распределения канала. Пришло время перейти к практическим приложени­ям, в частности, к локальным сетям. Как уже было сказано в разделе «Ethernet» (глава 1), 1НЖН: в свое время разработал серию стандартов IEEE 802, описывающих локальные и региональные сети. Некоторые стандарты выжили, некоторые — нет (см. табл. 1.4). Люди, верящие в реинкарнацию, считают, что одним из членов Ассоциации стандартов IEEE является вновь родившийся Чарльз Дарвин, отбра­ковывающий слабые технологии. В общем-то, действительно выжили сильней­шие. Наиболее важны стандарты 802.3 (Ethernet) и 802.11 (беспроводные ЛВС). О 802.15 (Bluetooth) и 802.16 (беспроводные региональные сети) говорить всерь­ез пока не приходится. Впрочем, в пятом издании этой книги, вероятно, можно будет найти соответствующий анализ. В стандартах 802.3 и 802.11 физические уровни и уровни управления доступом к среде (MAC) различаются. Однако уже подуровни управления логическим соединением (LLC, определен стандартом 802.2) схожи, что позволяет организовать единое сопряжение с сетевым уровнем.

Мы уже представили в общих чертах Ethernet в разделе «Ethernet» (глава 1) и больше не будем повторять этот материал. Вместо этого мы сразу обратимся к рассмотрению таких технических деталей построения сетей Ethernet, как прото­колы, а также новые технологии высокоскоростной (гигабитной) сети Ethernet. Так как Ethernet и IEEE 802.3 — это одно и то же (за исключением двух неболь­ших деталей, которые мы вкратце обсудим), то многие используют оба названия. Мы тоже будем говорить то «Ethernet», то «IEEE 802.3».

 

Служба имен доменов DNS

Хотя программы теоретически могут обращаться к хостам, почтовым ящикам и другим ресурсам по их сетевым адресам (например, IP), пользователям за­поминать их тяжело. Кроме того, отправка электронной почты на адрес Tanya® 128.111.24.41 будет означать, что в случае переезда сервера таниного про­вайдера или организации на новое место с новым IP-адресом придется изменить ее адрес e-mail. Для отделения имен машин от их адресов было решено использо­вать текстовые ASCII-имена. Поэтому танин адрес более привычно выглядит в таком виде: Tanya@art.ucsb.edu. Тем не менее, сеть сама по себе понимает только численные адреса, поэтому нужен механизм преобразования ASCII-строк в сете­вые адреса. В следующих разделах мы изучим, как производится это отображе­ние в Интернете.

Когда-то давно в сети ARPANET соответствие между текстовыми и двоичны­ми адресами просто записывалось в файле hosts.txt, в котором перечислялись все хосты и их IP-адреса. Каждую ночь все хосты получали этот файл с сайта, на ко­тором он хранился. В сети, состоящей из нескольких сотен больших машин, ра­ботающих под управлением системы с разделением времени, такой подход рабо­тал вполне приемлемо.

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

Суть системы DNS заключается в иерархической схеме имен, основанной на доменах, и распределенной базе данных, реализующей эту схему имен. В первую очередь эта система используется для преобразования имен хостов и пунктов на­значения электронной почты в IP-адреса, но также может использоваться и в других целях. Определение системы DNS дано в RFC 1034 и 1035.

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

Транспортные протоколы Интернета: TCP

Основы TCP

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

Протокол TCP описан в RFC 793. Со временем были обнаружены различные ошибки и неточности, и по некоторым пунктам требования были изменены. Под­робное описание этих уточнений и исправлений дается в RFC 1122. Расширения протокола приведены в RFC 1323.

Каждая машина, поддерживающая протокол TCP, обладает транспортной сущ­ностью TCP, являющейся либо библиотечной процедурой, либо пользователь­ским процессом, либо частью ядра системы. В любом случае, транспортная сущ­ность управляет TCP-потоками и интерфейсом с IP-уровнем. ТСР-сущность принимает от локальных процессов пользовательские потоки данных, разбивает их на куски, не превосходящие 64 Кбайт (на практике это число обычно равно 1460 байтам данных, что позволяет поместить их в один кадр Ethernet с заголов­ками IP и TCP), и посылает их в виде отдельных IP-дейтаграмм. Когда 1Р-дейта- граммы с TCP-данными прибывают на машину, они передаются ТСР-сущности, которая восстанавливает исходный байтовый поток. Для простоты мы иногда будем употреблять «ТСР» для обозначения транспортной сущности TCP (части программного обеспечения) или протокола TCP (набора правил). Из контекста будет понятно, что имеется в виду. Например, в выражении «Пользователь пере­дает данные ТСР» подразумевается, естественно, транспортная сущность TCP.

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

 

Управляемые носители информации

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

Магнитные носители

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

в которых высокая пропускная способность или цена за бит являются ключевы­ми факторами.

Витая пара

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

коаксиальный кабель

Другим распространенным средством передачи данных является коаксиальный кабель. Он лучше экранирован, чем витая пара, поэтому может обеспечить пере­дачу данных на более дальние расстояния с более высокими скоростями. Широко применяются два типа кабелей. Один из них, 50-омный, обычно используется для передачи исключительно цифровых данных. Другой тип кабеля, 75-омный, часто применяется для передачи аналоговой информации, а также в кабельном телевидении. В основе такого разделения лежат скорее исторические, нежели тех­нические факторы.

Волоконная оптика

Быстрое развитие компьютерных технологий вызывает чувство гордости у мно­гих представителей этой индустрии. Первый персональный компьютер фирмы IBM, созданный в 1981 году, работал с тактовой частотой 4,77 МГц. Спустя 20 лет этот показатель вырос до 2 ГГц. Прирост множителя составил 20 за декаду. Не так уж плохо.

 

Цифровые подписи

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

Проблема разработки замены рукописной подписи довольно сложна. По су­ществу, требуется система, с помощью которой одна сторона могла бы послать другой стороне «подписанное» сообщение так, чтобы:

• получатель мог проверить объявленную личность отправителя;

+ отправитель не мог позднее отрицать содержимое сообщения;

4- получатель не мог позднее изменить подписанное сообщение.

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

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

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

 

Широкополосные беспроводные сети

Что-то мы засиделись в помещении. Выйдем на улицу и посмотрим — может бьпь, там тоже есть какие-нибудь интересные сети? А там действительно что-то есть, и в основном мы увидим то, что называется «последней милей». Во многих странах телефонная система в какой-то момент перестала быть жестко управляе­мой, и появилось множество фирм, предлагающих локальные услуги голосовой связи и интернет-услуги.

Предложений действительно много. Проблема только в том, что прокладка волоконно-оптического кабеля, коаксиала или даже витой пары пятой категории к миллионам абонентов обходится очень дорого. Что же делать?

Ответ одновременно и прост, и сложен. Нужны широкополосные беспровод­ные сети. Установить одну большую антенну на горке где-нибудь рядом с насе­ленным пунктом и расставить на крышах домов абонентов приемные антенны горадо проще и дешевле, чем рыть траншеи и протягивать кабель. Таким обра­зом, конкурирующие операторы связи оказались крайне заинтересованы в раз­витии многомегабитных беспроводных систем связи, реализующих услуги голо­совой коммуникации, доступа к Интернету, видео по заказу и т. д. Как было продемонстрировано на рис. 2.27, очень неплохо с задачей справляется система LMDS. Однако еще до недавних пор каждый оператор стремился использовать ивою собственную систему. Отсутствие стандартов означало, что аппаратное и программное обеспечение не могли бьпь запущены в массовое производство. Это, в свою очередь, приводило к установке неоправданно высоких цен при низ­кой популярности.

Наконец светлые головы, работающие в данной отрасли, поняли, что именно стандартизация широкополосных беспроводных сетей является главным камнем преткновения. По традиции, сформировать комитет для разработки стандарта |5ыло поручено IEEE. В комитет 802.16 вошли представители крупнейших фирм i)_t научных организаций. Работа была начата в июле 1999 года, а официальный результат был представлен в апреле 2002 года. Название стандарта таково: ^лЭфирный интерфейс стационарных широкополосных беспроводных систем доступа». Тем не менее, большинство предпочитает использовать более короткое название: беспроводные региональные сети, или беспроводные местные линии. Мы считаем, что все эти названия равноценны и взаимозаменяемы. - Подобно некоторым другим стандартам из серии 802, стандарт 802.16 постро­ен с использованием идей модели OSI. Здесь можно найти и уровни, и подуров­ни, используется схожая терминология, сервисные примитивы и т. п. К сожале­нию, как и OSI, стандарт 802.16 страдает громоздкостью. В последующих разделах мы приведем краткое описание основных его свойств, но такое исследо­вание является далеко не полным, в нем опущены многие детали.

 

 

Электронная почта

Электронная почта, или e-mail, как называют ее многочисленные любители, существует уже более двух десятилетий. До 1990 года она использовалась пре­имущественно в научных организациях. В 90-е годы она получила широкую из­вестность, и с тех пор количество отправляемых с помощью электронной почты писем стало расти экспоненциально. Среднее число сообщений, посылаемых еже­дневно, скоро во много раз превзошло число писем, отправляемых с помощью обычной, бумажной почты.

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

В электронной почте люди обожают использовать особый жаргон и сокраще­ния, такие как BTW (By The Way - между прочим), ROTFL (Rolling On The Floor Laughing — катаюсь по полу от смеха), IMHO (In My Humble Opinion — по моему скромному мнению) и т. д. Кроме того, чрезвычайно популярны так называемые смайлики, или эмотиконы. Самые интересные из них представлены в табл. 7.2. Чтобы понять, в чем состоит их смысл, бывает полезно повернуть книгу на 90° по часовой стрелке (или голову — на 90° против часовой стрелки). Существует брошюра (Sanderson и Dougherty, 1993), в которой перечислено свы­ше 650 смайликов.

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

1. Было очень неудобно отсылать сообщения группе получателей. Эта возмож­ность часто требовалась менеджерам для рассылки уведомлений своим под­чиненным.

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

3. Отправитель сообщения никогда не знал, дошло ли его сообщение до адре­сата.

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

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

6. Было невозможно создавать и посылать сообщения, содержащие смесь тек­ста, изображений (рисунков, факсов, фото) и звука.

Со временем, когда накопился опьп работы, были предложены более слож­ные системы электронной почты. В 1982 году предложения по работе с электрон­ной почтой, выдвинутые администрацией сети ARPANET, были опубликованы в виде RFC 821 (протокол передачи) и RFC 822 (формат сообщений). Подверг­шись минимальным изменениям, нашедшим отражение в RFC 2821 и 2822, они фактически стали стандартами Интернета, однако все равно, говоря об электрон­ной почте Интернета, многие ссылаются на RFC 822.

В 1984 году консультативный комитет по международной телефонии и теле­графу (CCITT) впервые представил стандарт Х.400. После двух десятков лет борьбы электронная почта, основанная на стандарте RFC 822, получила широкое применение, тогда как системы, базирующиеся на стандарте Х.400, практически исчезли. Получилось так, что система, созданная горсткой аспирантов-компью- терщиков, смогла превзойти официальный международный стандарт, имевший серьезную поддержку всех управлений почтово-телеграфной и телефонной свя­зи во всем мире, многих правительств и значительной части компьютерной про­мышленности. Все это напоминает библейскую историю о Давиде и Голиафе.

Причина успеха стандарта RFC 822 кроется не столько в его достоинствах, сколько в недостатках стандарта Х.400. Последний был настолько плохо проду­ман и так сложен, что никто просто не мог его нормально реализовать. Большин­ство организаций предпочли простую, но работающую систему электронной поч­ты, основанную на RFC 822, возможно, действительно замечательной, но нерабо­тающей системе, в основе которой был стандарт Х.400. Может быть, это ког- да-нибудь послужит кому-нибудь уроком. Итак, далее в нашем обсуждении мы сконцентрируемся на используемых в Интернете системах электронной почты

Элементарные протоколы передачи данных

Знакомство с протоколами мы начнем с рассмотрения трех протоколов возрас­тающей сложности. Симулятор этих и следующих протоколов заинтересованные читатели могут найти на веб-сайте (см. предисловие). Прежде чем приступить к изучению протоколов, полезно высказать некоторые допущения, лежащие в ос­нове данной модели связи. Для начала мы предполагаем, что на физическом уров­не, уровне передачи данных и сетевом уровне находятся независимые процессы, общающиеся с помощью передачи друг другу сообщений. Во многих случаях процессы физического уровня и уровня передачи данных будут работать на про­цессоре внутри специальной сетевой микросхемы ввода-вывода, а процесс сете­вого уровня — на центральном процессоре. Однако другие варианты реализации также возможны (например, три процесса внутри одной микросхемы ввода-выво- да; физический уровень и уровень передачи данных, вызываемые как процедуры процессом сетевого уровня, и т. д.). В любом случае, представление трех уровней в виде отдельных процессов будет служить поддержанию концептуальной чисто­ты обсуждения, а также подчеркнет независимость уровней.

Другим ключевым допущением будет то, что машина А хочет послать на ма­шину В длинный поток данных, используя надежный ориентированный на со­единение сервис. Позднее мы рассмотрим случай, при котором одновременно машина В также хочет послать данные на машину А. Предполагается, что у ма­шины А имеется бесконечный источник данных, готовых к отправке, и что ей никогда не требуется ждать готовности данных. Когда уровень передачи данных машины А запрашивает данные, сетевой уровень всегда готов их ему предоста­вить. (Это ограничение также будет потом отброшено.)

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

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

Получив пакет, уровень передачи данных формирует из пакета кадры, добав­ляя заголовок и концевик пакета передачи данных (см. рис. 3.1). Таким образом, кадр состоит из внедренного пакета, некоторой служебной информации (в заго­ловке) и контрольной суммы (в концевике). Затем кадр передается уровню пере­дачи данных принимающей машины. Мы будем предполагать наличие соответст­вующих библиотечных процедур, например, to_physical Jayer для отправки кадра и fromphysicaNayer для получения кадра Передающая аппаратура вычисляет и добавляет контрольную сумму (создавая концевик), так что уровень передачи данных может не беспокоиться об этом. Например, может использоваться алго­ритм циклических кодов, обсуждавшийся в предыдущем разделе.

Вначале получатель ничего не должен делать. Он просто сидит без дела, ожи­дая, что что-то произойдет. В приводимых в данной главе примерах протоколов ожидание событий уровнем передачи данных обозначается вызовом процедуры =—wait_for_event(&event). Эта процедура возвращает управление, только когда что- то происходит (например, прибывает кадр). При этом переменная event сообщает, что именно случилось. Наборы возможных событий отличаются в разных прото­колах и поэтому будут описываться для каждого протокола отдельно. Следует заметить, что в действительности уровень передачи данных не находится в холо­стом цикле ожидания событий, как мы предположили, а получает прерывание, когда это событие происходит. При этом он приостанавливает свои текущие про­цессы и обрабатывает пришедший кадр. Тем не менее, для простоты мы проигно­рируем эти детали и предположим, что уровень передачи данных все свое время посвящает работе с одним каналом.

Когда приемная машина получает кадр, аппаратура вычисляет его контрольную сумму. Если она неверна (то есть при передаче возникли ошибки), то уровень передачи данных получает соответствующую информацию (event = cksum err). Если кадр прибывает в целости, уровню передачи данных об этом также сообща­ется (euew£=frame_arrival), после чего он может получить этот кадр у физическо­го уровня с помощью процедуры from_physical_layer.