Глобальные_02

SLIP

Первым стандартом де-факто, позволяющим соединенным последовательной линией связи устройствам работать по протоколам TCP/IP, был протокол SLIP (Serial Line IP), созданный в начале 80-х годов и в 1984 г. встроенный Риком Адамсом (Rick Adams) в операционную систему 4.2 Berkley Unix. Позднее SLIP был поддержан в других версиях Unix и реализован в программном обеспечении для ПК.

Популярность протокола SLIP объясняется тем, что он дал возможность подключаться к сети Internet посредством стандартного порта RS232, имеющегося в большинстве компьютеров. В настоящее время SLIP широко используется в основном на домашних компьютерах, подключенных к последовательным линиям, которые имеют пропускную способность от 1200 бит/с до 19,2 Кбит/с. Для того чтобы распознать границы пакетов IP2, передаваемых по последовательной линии связи, и отделить один пакет от другого, протокол SLIP предусматривает использование специального символа END, значение которого в шестнадцатеричном представлении3 равно C0. Применение специального символа может породить конфликт: если байт пересылаемых данных тождественен символу END, то он будет ошибочно определен как признак конца пакета. Чтобы предотвратить такую ситуацию, байт данных со значением, равным значению символа END, заменяется составной двухбайтовой последовательностью, состоящей из специального символа ESC (DB) и кода DC. (Применяемый в протоколе SLIP символ ESC, не равный символу ESC в кодировке ASCII, будем обозначать SLIP ESC.) Если же байт данных имеет тот же код, что и символ SLIP ESC, то он заменяется двухбайтовой последовательностью, состоящей из собственно символа SLIP ESC и кода DD. После последнего байта пакета передается символ END.

Механизм формирования составных последовательностей показан на рис.1. Здесь приведены стандартный пакет IP, один байт которого тождественен символу END, а другой — символу SLIP ESC, и соответствующий ему пакет SLIP, который больше на 4 байта. Хотя в спецификации протокола SLIP не определена максимальная длина передаваемого пакета, реальный размер пакета IP не должен превышать 1006 байтов. Данное ограничение связано с первой реализацией протокола SLIP в соответствующем драйвере для Berkley Unix, и его соблюдение необходимо для поддержки совместимости разных реализаций SLIP.

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

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

один из двух транспортных протоколов (UDP или TCP) проверяет целостность всех данных по контрольным суммам. Но, несмотря на это, для повышения эффективности работы протоколу SLIP не помешало бы иметь собственный механизм (пусть даже простейший) коррекции ошибок.

Низкая пропускная способность последовательных линий связи вынуждает сокращать время передачи пакетов, уменьшая объем содержащейся в них служебной информации. Эта задача решается с помощью протокола Compressed SLIP (CSLIP), поддерживающего сжатие заголовков пакетов. Появление CSLIP объясняется тем фактом, что при использовании программ типа Telnet, Rlogin и других для пересылки одного байта данных требуется переслать 20-байтовый заголовок пакета IP и 20-байтовый заголовок пакета TCP (итого 40 байтов). Спецификация CSLIP обеспечивает сжатие 40-байтового заголовка до 3—5 байтов. На сегодняшний момент большинство реализаций протокола SLIP поддерживают спецификацию CSLIP.

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

Использование протокола SLIP предполагает выполнение ряда условий:

1.Каждый партнер обмена должен знать IP-адрес своего адресата, так как не существует метода обмена такого рода информацией.

2.SLIP в отличии от Ethernet не использует контрольных сумм, поэтому обнаружение и коррекция ошибок целиком ложится на программное обеспечение верхних уровней.

3.Так как кадр SLIP не имеет поля тип, его нельзя использовать, в отличии от кадров Ethernet, для реализации других протоколов методом инкапсуляции.

Впервые протокол SLIP был применен в 1984 году в 4.2BSD. Скорость передачи информации при использовании протокола SLIP не превышает 19.2кб/с, что обычно достаточно для интерактивного обмена в рамках протоколов telnet или RLOGIN. Максимальный размер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт, что обеспечивает разумный компромисс между значением задержки отклика (~256мс.) и эффективностью использования канала (~98% для CSLIP). При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка в IP-дейтограмме и 20 байт TCP-заголовка. Если мы учтем издержки формирования SLIP-кадра, накладные расходы превосходят 40 байт. Частично этот недостаток устранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной Джекобсоном в 1990 году). В CSLIP заголовок сокращается до 3-5байт (против 40 в SLIP). Эта версия протокола способна поддерживать до 16 TCP-соединений на каждом из концов последовательного канала.

PPP

Протокол PPP (Point-to-Point Protocol) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:

-Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.

-Протокол LCP для установления, конфигурирования и тестирования информационных каналов

-Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.

PPPработает поверх протокола управления каналом передачи данных верхнего уровня (High-Level Data Link Control - HDLC) и состоит из двух главных протоколов.

При установлении PPP-соединения сначала используется Протокол управления соединением (Link Control Protocol - LCP). В этом протоколе определены функции настройки и тестирования соединения. В качестве одной из составляющих LCP или как отдельная "фаза" может быть проведена идентификация (AUTH). Затем, для согласования определенных вариантов настроек и параметров, PPP применяет протокол управления сетью (Network Control Protocol - NCP), используемый протоколом L_3. Протокол управления IP (IP Control Protocol - IPCP), являющийся разновидностью NCP, применяется для согласования различных IP-параметров, таких как IP-адреса, сжатие данных и т. д. PDU (Protocol Data Unit - блок данных протокола) протокола PPP использует фрейм HDLC как описано в ISO 3309-1979 (с исправлениями, внесенными в ISO 3309-1984/PDAD1). Описание протокола HDLC выходит за рамки этой книги, поэтому мы ограничимся только тем, что покажем формат фрейма HDLC и его взаимосвязь с PPP. На приведенном ниже рисунке показана структура такого кадра.

Флаг является константной величиной HDLC и равен 01111110 (0х79), биты поля адреса устанавливаются в 1 (0хFF), что адресам всех станций. PPP не использует адреса отдельных станций, поскольку это протокол для связи двух машин. Поле управления устанавливается равным идентификатору ненумерованной информации (unnumbered information) HDLC. Его значение - 00000011 (0х03).

Поле протокола используется для идентификации PDU, передаваемого в поле данных фрейма. Значения этого поля назначаются Интернетом, причем значения, начинающиеся с 0, задают сетевой протокол, находящийся в поле данных. Значения, начинающиеся с 8, задают протокол управления, используемый для согласования протоколов, которые будут использоваться. Самые последние данные о номерах протоколов можно найти в недавних RFC ("Assigned Numbers") "Назначенные номера".

Номер протокола LCP равен 0хC021, а остальное место в поле информации предназначено для поля кода. В случае LCP значение поля кода определяет сообщения Запрос-Настройки (Configure-Request), ПодтверждениеНастройки (Ack-Request) и т. д. Поле идентификатора используется для сопоставления и координации сообщений запросов с соответствующими ответами. Поле длины задает длину (в байтах) содержимого поля информации, исключая номер протокола. И наконец, остаток поля информации предназначен для необязательных данных. Это поле кодируется двумя или тремя значениями: 1) тип-длина-данные; 2) тип-длина. Эти необязательные данные используются PPP-узлами для извещения друг друга о своих возможностях и запроса информации. Позже мы это обсудим более подробно.

LCP.

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

После того как установлено соединение, конфигурация протокола позволяет двум станциям договориться/настроить протокол, который будет использоваться на сетевом уровне. Это осуществляется при помощи соответствующего протокола управления сетью (Network Control Protocol - NCP). Какой конкретный протокол будет здесь применен, зависит от того, какое из семейств NCP использовано в данной реализации. На LCP также лежит ответственность за завершение соединения. Конкретная процедура завершения соединения оставлена на усмотрение разработчиков. За исключением того случая, когда внешняя проблема вызвала разрыв связи, соединение обычно завершается протоколом верхнего уровня или самим пользователем.

Рассмотрим пример использования протокола PPP. На приведенном ниже рисунке показан примеры того, как PPP может быть использован для обеспечения операций по конфигурированию сети. Маршрутизаторы, узлы и т. д. обмениваются PPP-фреймами для определения того, какой протокол сетевого уровня поддерживается обеими станциями.

Вданном примере два компьютера договариваются об использовании IP

иего OSI-двойника, ISO 8473, CLNP (Connectionless Network Protocol). Сначала используются методы протокола LCP для установления и тестирования соединения. Затем вызывается NCP для согласования, какой сетевой протокол (и соответствующие процедуры) будут использоваться между двумя машинами. После того, как это согласование завершено, начинается обмен данными. В любой момент времени любой участник соединения может разорвать канал связи.

Фазовая диаграмма PPP.

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

Для данного объяснения достаточно такой упрощенной фазовой диаграммы. Кроме того, PPP хорошо описывается при помощи конечного автомата (RFC 1661, раздел 4), который иллюстрирует события между состояниями PPP. Но мы не будем в данном случае вдаваться в такие подробности.

Нет связи (нет физического соединения).

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

Фаза установления связи.

Протокол управления соединением (LCP) используется для установления канала связи посредством обмена конфигурационными пакетами. Эта фаза считается завершенной и связь установленной, когда пакет ПодтверждениеКонфигурации был послан и принят. Получение пакета Запрос-Конфигурации вызывает возврат в фазу установления связи из фаз протокола сетевого уровня или идентификации.

Фаза идентификации.

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

Фаза протокола сетевого уровня.

В этой фазе каждый протокол сетевого уровня (такой как IP, IPX или AppleTalk) настраивается отдельно при помощи соответствующего протокола управления сетью (NCP). После того, как NCP перешел в состояние установленного (открытого) соединения, PPP будет передавать соответствующие пакеты протокола сетевого уровня. Любые пакеты протокола сетевого уровня, полученные, когда соответствующий NCP не находится в состоянии открытого соединения, должны быть отвергнуты. В этой фазе поток данных по каналу связи может состоять из пакетов как LCP, так и NCP и протокола сетевого уровня.

Фаза завершения соединения.

Для окончания связи в LCP используются пакеты завершения связи. Когда соединение закрывается, PPP извещает протоколы сетевого уровня с тем, чтобы они могли предпринять соответствующие действия. Обычно после того, как произошел обмен пакетами завершения связи, физический уровень запрашивается о разъединении.

Пакеты LCP.

Пакеты настройки соединения используются для установки и настройки соединения (Запрос-Конфигурации, Подтверждение-Конфигурации, ОтказКонфигурации и Ошибка-Конфигурации). Пакеты завершения соединения используются для завершения связи (Запрос-Завершения и ПодтверждениеЗавершения). Пакеты поддержки соединения используются для поддержки и отладки связи (Отказ-Кода, Отказ-Протокола, Эхо-Запрос, Эхо-Ответ и Отвергнуть-Запрос).

Каждая настройка конфигурации имеет значение по умолчанию. Таким образом гарантируется, что LCP-пакеты будут распознаны даже в том случае, когда одна из сторон будет по ошибке считать соединение уже открытым. Только один LCP-пакет может быть помещен в поле информации PPP, а поле протокола должно быть в этом случае равно 0хC021 (LCP). Формат пакета протокола управления соединением :

Поле кода - определяет тип LCP-пакета, на текущий момент может иметь следующие значения:

1 Запрос конфигурации

2 Подтверждение конфигурации

3 Отказ конфигурации

4 Ошибка конфигурации

5 Запрос завершения

6 Подтверждение завершения

7 Отказ кода

8 Отказ протокола

9 Эхо запрос

10 Эхо ответ

11 Отвергнуть запрос

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

длину и данные.

Данные - формат поля данных определяется значением в поле кода. Рассмотрим краткое описание каждого из возможных LCP-пакетов. Запрос конфигурации - если реализация желает открыть соединение, то

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

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

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

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

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

Отказ кода. Получение LCP-пакета с неидентифицированным полем кода говорит о том, что другая сторона использует другую версию. Сообщение об этом и несет пакет Отказ-Кода.

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

Эхо запрос и Эхо ответ. В LCP включены пакеты Эхо-Запрос и ЭхоОтвет для того, чтобы иметь механизм обратной связи на уровне канала передачи данных в целях проверки соединения в обоих направлениях. Это нужно при отладке, проверке качества соединения, определении производительности и множестве других задач.

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

За последние несколько лет были разработаны протоколы, дополняющие средства обеспечения безопасности PPP.

RFC 2276 Transport Lavel Security Protocol (TLS)

RFC 1968 PPP Encryption Control Protocol (ECP)

RFC 2287 PPP Extensible Authentication Protocol (EAP)

RFC 2419 PPP DES Encryption Protocol, Version 2 (DESE-bis) RFC 2420 PPP Triple-DES Encryption Protocol (3DESE)

Таким образом протокол PPP был значительно улучшен путем добавления нескольких протоколов обеспечения безопасности. Эти протоколы, являясь расширением протокола PPP, используют заданный в спецификации PPP синтаксис сообщения, например номера протоколов и кодов, используемых в соответствующих полях. Вдобавок VPN-шлюзы в своих системах безопасности часто используют основанные на DES протоколы.

Протокол PPP способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты ConfigureRequest, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, EchoRequest, Echo-Reply и Discard-Request).

ISDN

Технология ISDN, представляет собой сочетание двух родственных технологий: коммуникаций и современных распределенных вычислений. Технология коммуникаций (в основном телефонная связь) развивалась в ответ на необходимость общения между людьми на больших расстояниях. Создатели телефона разработали технологию телефонии, позволяющую передавать речь на большое расстояние и воспроизводить ее в точке приема. Спустя немногим более 100 лет телефонная технология привела к созданию современной всемирной телефонной сета, которой мы более или менее успешно пользуемся сегодня. Развитие компьютерных технологий стало ответом на необходимость

вобработке и хранении больших объемов информации. Проблема хранения и распространения информации всегда волновала человечество - со времен наскальных рисунков до сегодняшних систем корпоративных вычислений. В настоящее время ее решением стала разработка и совершенствование все более гибкой и мощной компьютерной технологии. Всего за 40 лет она стремительно эволюционировала от больших ЭВМ на электронных лампах с пакетной обработкой заданий до современных локальных (LAN) и глобальных (WAN) сетей, поддерживающих новейшие распределенные системы

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

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

вкомпьютерной среде аналоговая передача не применялась. Компьютеры всегда использовали цифровую информацию и команды.

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

линией. Со стремительным ростом популярности телефонного сервиса стали появляться базовые компоненты, составляющие сегодня международную телефонную сеть. Первым дополнением телефонной сети стали центральные телефонные узлы или центральные АТС (СО - Central Office), обеспечивающие коммутацию со всеми телефонными линиями в данном географическом районе. Все телефонные системы и конечные пользователи были связаны с АТС абонентскими линиями (subscriber loop), а звонок поступал на АТС, которая обеспечивала соединение с принимающим абонентом. Сначала эти соединения осуществлялись вручную операторами, вставлявшими шнуры в соответствующие гнезда коммутационных панелей и устанавливавших тем самым прямую связь между абонентами. На следующем этапе АТС были соединены друг с другом магистральными каналами связи, а несколько АТС связывались промежуточными (тандемными) телефонными узлами. Такой узел содержал тандемный коммутатор, обслуживающий магистральные линии и маршрутизирующий (посылающий по определенному маршруту) звонки между АТС. Тандемные коммутаторы снизили стоимость телефонных разговоров, обеспечивая соединения между АТС, не требующие выделенной телефонной линии. С 1984 г. США были разделены на 161 область локального доступа и передачи (LATA - local access and transport area ), состоящие из местных линий связи (local loop), АТС и тандемных коммутаторов. Междугородные звонки между областями локального доступа и внутри них обслуживаются соответствующими коммуникационными компаниями. Коммутаторы АТС или тандемные коммутаторы передают звонки между LATA точно так же, как они передают и коммутируют звонки между АТС. Все это кажется немного сложным (что во многих отношениях соответствует истине), но суть в том, что в США любой звонок между вызывающим и принимающим абонентами обслуживают не менее шести участников: две локальные абонентские линии, две области локального доступа (LATA) и одна-две коммуникационные компании, т.е. их взаимодействие обеспечивает функционирование IATA. Логически все это выглядит как сложная и всеохватывающая «коммуникационная паутина».

В компьютерах для управления локальными устройствами и для коммуникаций через локальные шины всегда использовались методы цифровой передачи сигналов. Разработка локальных сетей породила несколько более сложную форму цифровых коммуникаций - коммуникации между компьютерами. Локальные сети позволили реализовать новые мощные приложения и найти новое применение компьютерной технологии. Многие отраслевые эксперты считают, что развитие технологии локальных сетей стало важным шагом, способствующим расширению применения компьютеров, и основой для соединения их в глобальные сети. Распространение глобальных сетей привело к крупномасштабному использованию телефонных сетей для соединения удаленных друг от друга машин (компьютеров). Узлы глобальной сети можно связать не только локальными кабелями, но и с помощью телефонных линий. Обычно это требует преобразования цифровых сигналов компьютера в аналоговые сигналы, передаваемые телефонными системами, а затем обратного их преобразования на приемном конце в цифровую форму. Такое преобразование - модуляция и демодуляция - осуществляется модемами. Хотя оно вызывает ощутимые задержки и увеличение непроизводительных потерь в сети, преимущества глобальных сетей делают такое преобразование необходимым и практичным. Расширение использования телефонных линий для передачи данных породило новые варианты применения телефонного