Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364139
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62791)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21319)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21692)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8692)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3462)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20644)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Реферат: «Сетевой межузловой протокол ppp история возникновения, область применения, основные команды, перспективы»

Название: «Сетевой межузловой протокол ppp история возникновения, область применения, основные команды, перспективы»
Раздел: Остальные рефераты
Тип: реферат Добавлен 16:10:54 30 августа 2011 Похожие работы
Просмотров: 168 Комментариев: 11 Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать

«МОСКОВСКАЯ ГОСУДАРСТВЕННАЯ АКАДЕМИЯ

ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ»

Реферат по теме

«Сетевой межузловой протокол PPP - история возникновения, область применения, основные команды, перспективы»

Предмет: Сети ЭВМ и телекоммуникации

Выполнил:

Принял: Баканов В.М.

Москва

2009

Содержание

Введение 2

Компоненты PPP 4

Протоколы SLIP и CSLIP 13

Выводы и перспективы развития 16

Введение

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

DLL (Data link layer - канальный уровень) осуществляет:

- обмен между взаимодействующими станциями служебными пакетами, подтверждающими готовность к передаче данных (инициализация);

- обмен между взаимодействующими станциями служебной информацией, подтверждающей правильность соединения (идентификация);

- выделение в последовательности передаваемых битов границ знаков (синхронизация);

- формирование кадров (сегментация);

- обеспечение прозрачности соединения для вышерасположенного уровня;

- обеспечение одинаковой скорости передачи и приема (управление потоком);

- контроль ошибок и запрос повторной передачи;

- обработку сбойных ситуаций;

- разрыв логического соединения (завершение работы канала);

- контроль за состоянием канала (управление каналом).

Канальный уровень подразделяется на 2 подуровня — нижний подуровень MAC (Media Access Control - управления доступом к среде передачи) регулирует доступ к разделяемой физической среде передачи и верхний подуровень LLC (Logical Link Control - управления логической связью) обеспечивает обслуживание сетевого уровня, на этом уровне работают коммутаторы, мосты.

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

Протоколы канального уровня модели OSI:

STP, ARCnet, ATM, DTM, SLIP, SMDS, Ethernet, FDDI, Frame Relay, LocalTalk, Token ring, StarLan, L2F, L2TP, PPTP, PPP, PPPoE, PROFIBUS

Протокол PPP

В конце 1980 гг. Internet, крупная международная сеть, соединяющая множество исследовательских организаций, университетов и коммерческих концернов, начала испытывать резкий рост числа главных вычислительных машин, обеспечивающих TCP/IP . Преобладающая часть этих главных вычислительных машин была подсоединена к локальным сетям (LAN) различных типов, причем наиболее популярной была Ethernet. Большая часть других главных вычислительных машин соединялись через глобальные сети (WAN), такие как общедоступные сети передачи данных (PDN) типа Х.25. Сравнительно небольшое число главных вычислительных машин были подключены к каналам связи с непосредственным (двухточечным) соединением (т.е. к последовательным каналами связи). Однако каналы связи с непосредственным соединением принадлежат к числу старейших методов передачи информации, и почти каждая главная вычислительная машина поддерживает непосредственные соединения. Например, асинхронные интерфейсы RS-232-С встречаются фактически повсюду.

Одной из причин малого числа каналов связи IP с непосредственным соединением было отсутствие стандартного протокола формирования пакета данных Internet. Протокол Point-to-Point Protocol (PPP) (Протокол канала связи с непосредственным соединением) предназначался для решения этой проблемы. Помимо решения проблемы формирования стандартных пакетов данных Internet IP в каналах с непосредственным соединением, РРР также должен был решить другие проблемы, в том числе присвоение и управление адресами IP, асинхронное (старт/стоп) и синхронное бит-ориентированное формирование пакета данных, мультиплексирование протокола сети, конфигурация канала связи, проверка качества канала связи, обнаружение ошибок и согласование варианта для таких способностей, как согласование адреса сетевого уровня и согласование компрессии информации. РРР решает эти вопросы путем обеспечения расширяемого Протокола Управления Каналом (Link Control Protocol) (LCP) и семейства Протоколов Управления Сетью (Network Control Protocols) (NCP) , которые позволяют согласовывать факультативные параметры конфигурации и различные возможности. Сегодня PPP, помимо IP, обеспечивает также и другие протоколы, в том числе IPX и DECnet .

В отличие от SLIP- протокола РРР может работать через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA RS-423 и CCITT V.35). Протокол PPP достаточно неприхотлив и может работать без управляющих сигналов модемов (таких, как Request to Send, Clear to Send, Data Carrier Detect и Data Terminal Ready). Единственным абсолютным требованием, которое предъявляет РРР, является требование обеспечения дублированных схем (либо специально назначенных, либо переключаемых), которые могут работать как в синхронном, так и в асинхронном последовательном по битам режиме, прозрачном для блоков данных канального уровня РРР. РРР не предъявляет каких-либо ограничений, касающихся скорости передачи информации, кроме тех, которые определяются конкретным примененным интерфейсом DTE/DCE.

Компоненты PPP

РРР обеспечивает метод передачи дейтаграмм через последовательные каналы связи с непосредственным соединением. Он содержит три основных компонента:

- Метод формирования дейтаграмм для передачи по последовательным каналам. РРР использует протокол High-level Data Link Control (HDLC) (Протокол управления каналом передачи данных высокого уровня) в качестве базиса для формирования дейтаграмм при прохождении через каналы с непосредственным соединением.

- Расширяемый протокол LCP (Link Control Protocol) для организации, выбора конфигурации и проверки соединения канала передачи данных.

- Семейство протоколов NCP (Network Control Protocols) для организации и выбора конфигурации различных протоколов сетевого уровня. РРР предназначен для обеспечения одновременного пользования множеством протоколов сетевого уровня.

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

Протокол управления каналом LCP

Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E (b01111110). За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 1. Кадр PPP может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).

Рис. 1 Формат кадра в протоколе PPP

Поле адрес всегда содержит байт 0xFF . Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол PPP в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.

Таблица 1. Стандартизованные DLL-номера протоколов для PPP (поле протокол )

DLL-код протокола (шестнадцатеричный)

Наименование протокола

0001

Протокол заполнения (padding)

0003-001F

Зарезервировано

0021

IP-протокол

0023

Сетевой уровень OSI

0025

Xerox NS IDP

0027

Decnet фаза IV

0029

Appletalk

002B

Novell IPX

002D

Компрессированный TCP/IP протокол Ван Джекобсона

002F

Не компрессированный TCP/IP протокол Ван Джекобсона

0031

PDU мостов

0033

Потоковый протокол (ST-II)

0035

Banyan Vines

0039

Appletalk EDDP

003B

Appletalk Smartbuffered

003D

Multi-link

003F

Кадры Netbios

0041

Cisco Systems

0043

Ascom Timeplex

0047

Удаленная локальная сеть DCA

0049

Транспортный протокол для последовательных данных (PPP-SDTP)

004B

SNA через 802.2

004D

SNA

004F

Сжатие заголовков IPv6

007D

Зарезервировано (Управл. ESC) [RFC1661]

00FD

1-ый вариант компрессии

0201

Пакеты отклика 802.1d

0203

IBM BPDU базовой маршрутизации

8021

Управляющий протокол Интернет (IPCP)

8023

Управляющий протокол сетевого уровня OSI

8025

Управляющий протокол Xerox NS IDP

8027

Управляющий протокол Decnet фаза VI

8029

Управляющий протокол Appletalk

802B

Управляющий протокол Novell IPX

8031

Бридж NCP

8033

Потоковый управляющий протокол

8035

Управляющий протокол Banyan Vines

803D

Многосвязный управляющий протокол

803F

Управляющий протокол кадров NetBIOS

8041

Управляющий протокол Cisco

8043

Ascom Timeplex

8045

Управляющий протокол Fujitsu LBLB

8047

Управляющий протокол удаленных локальных сетей DCA (RLNCP)

8049

Управляющий протокол передачи последовательных данных (PPP-SDCP)

Управляющий протокол для передачи sna поверх 802.2

804D

Управляющий протокол SNA

804F

Управляющий протокол сжатия заголовков IPv6

80FD

Управляющий протокол сжатия

C021

Канальный управляющий протокол

C023

Протокол аутентификации паролей

C025

Сообщение о состоянии канала

C081

Управляющий протокол для работы с контейнерами

Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - Bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от Cxxx до Exxx соответствуют управляющим протоколам (например, LCP).

Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.

Рис. 2. Алгоритм установления соединения PPP

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

В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.2). Формат LCP-пакета показан на рис. 3.

Рис. 3. Формат заголовка LCP-пакета

Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код , посылается пакет-отклик “отклонение кода”. Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются.

В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВМ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.

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

Значение кода поля типа

Назначение опции

0

Зарезервировано

1

Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят)

3

Authentication-Protocol (протокол аутентификации)

4

Quality-Protocol (протокол качества)

5

Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи)

6

Protocol-Field-Compression

7

Address-and-Control-Field-Compression

Три класса LCP-пакетов

Существует три класса LCP-пакетов:

1. Пакеты конфигурации канала, которые используются при формировании виртуального канала (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject) .

2. Пакеты закрытия канала (Terminate-Request и Terminate-Ack).

3. Пакеты поддержания, которые служат для управления и отладки (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332). Формат пакета IPCP показан на рис. 4.

Тип

1 байт

Длина

1 байт

Протокол сжатия IP

2 байта

Данные

Рис. 4. Формат пакета IPCP. Младшие биты слева.

Поле тип содержит 2, в поле длина заносится число байт в пакете (≥4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип =3, длина =6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес.

Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код . Значения этих кодов приведены в таблице 2.

Таблица 2 Значения поля код LCP-заголовка

Код

Тип пакета

1

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

Configure-Request

2

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

Configure-Ack

3

Не подтверждение конфигурации

Configure-Nak

4

Отклонение конфигурации

Configure-Reject

5

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

Terminate-Request

6

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

Terminate-Ack

7

Отклонение кода

Code-Reject

8*

Отклонение протокола

Protocol-Reject

9*

Запрос отклика

Echo-Request

10*

Эхо-отклик

Echo-Reply

11*

Запрос отмены

Discard-Request

12*

Идентификация

13*

Остающееся время

14**

Запрос сброса

15**

Отклик на запрос сброса

*) Только LCP;

**) Только CCP

Для случая запроса Discard-Request между полями длина и данные помещается 4-байтовое поле Magic-Number (магическое число).

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

Подключение нескольких параллельных каналов (MP)

Формат MP-пакета представлен на рис. 5.

Рис. 5. Формат MР-пакета

Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение поля увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал.

При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:

· Никакого асинхронного управления кодированием символов

· Запрет использования магических чисел

· Запрещено мониторирование качества канала

· Сжатие полей адреса, протокола и управления

· Никаких составных кадров

· Запрет заполнения с самоописанием (Self-Describing-Padding)

Рис. 6. Пример Multilink-конфигурации

Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на рис. 6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP. Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).

Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2.

Протоколы SLIP и CSLIP

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

Популярность протокола SLIP объясняется тем, что он дал возможность подключаться к сети Internet посредством стандартного порта RS232, имеющегося в большинстве компьютеров. В настоящее время SLIP широко используется в основном на домашних компьютерах, подключенных к последовательным линиям, которые имеют пропускную способность от 1200 бит/с до 19,2 Кбит/с.

Ограничения

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

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

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

· Либо вышележащие протоколы, например, в стеке TCP/IP протокол IP проводит тестирование целостности пакета по заголовку IP, а один из двух транспортных протоколов (UDP или TCP) проверяет целостность всех данных по контрольным суммам. Однако в протоколе UDP не обязательно использование контрольных сумм, поэтому совместное использование UDP и SLIP нежелательно.

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

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

Отсутствие этих возможностей делает протокол SLIP очень простым в реализации и, следовательно, популярным.

Compressed SLIP

Низкая пропускная способность последовательных линий вынуждает сокращать время передачи пакетов, уменьшая объем содержащейся в них служебной информации. Эта задача решается с помощью протокола Compressed SLIP , поддерживающего сжатие заголовков пакетов. Этот протокол был создан в Lawrence Berkeley Labs (LBL) Ван Якобсоном, как способ повысить эффективность последовательной передачи и уровень сервиса прикладных программ, использующих TCP/IP на медленных линиях. Появление CSLIP объясняется тем, что при использовании программ типа telnet, rlogin и других для пересылки одного байта данных требуется переслать 20-байтовый заголовок пакета IP и 20-байтовый заголовок пакета TCP . Спецификация CSLIP обеспечивает сжатие 40 байтов заголовка до 3-5 байтов.

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

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

Одной из причин малого числа каналов связи IP с непосредственным соединением было отсутствие стандартного протокола формирования пакета данных Internet. Протокол PPP предназначался для решения этой проблемы. Помимо решения проблемы формирования стандартных пакетов данных Internet IP в каналах с непосредственным соединением, РРР также должен был решить другие проблемы, в том числе присвоение и управление адресами IP, асинхронное (старт/стоп) и синхронное бит-ориентированное формирование пакета данных, мультиплексирование протокола сети, конфигурация канала связи, проверка качества канала связи, обнаружение ошибок и согласование варианта для таких способностей, как согласование адреса сетевого уровня и согласование компрессии информации. РРР решает эти вопросы путем обеспечения расширяемого протокола управления каналом (LCP) и семейства протоколов управления сетью (NCP) , которые позволяют согласовывать факультативные параметры конфигурации и различные возможности. Сегодня PPP , помимо IP , обеспечивает также и другие протоколы, в том числе IPX и DECnet .

В отличие от SLIP протокола РРР может работать через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA RS-423 и CCITT V.35). Протокол PPP достаточно неприхотлив и может работать без управляющих сигналов модемов (таких, как Request to Send, Clear to Send, Data Carrier Detect и Data Terminal Ready). Единственным абсолютным требованием, которое предъявляет РРР, является требование обеспечения дублированных схем (либо специально назначенных, либо переключаемых), которые могут работать как в синхронном, так и в асинхронном последовательном по битам режиме, прозрачном для блоков данных канального уровня РРР. РРР не предъявляет каких-либо ограничений, касающихся скорости передачи информации, кроме тех, которые определяются конкретным примененным интерфейсом DTE/DCE.

Выводы и перспективы развития

В общем и целом по сравнению с протоколом SLIP протокол PPP является значительно более развитым инструментом для работы на последовательных линиях и имеет следующие преимущества:

· возможность одновременной работы по различным сетевым протоколам, а не только по IP;

· проверка целостности данных путем подсчета контрольной суммы;

· поддержка динамического обмена адресами IP;

· возможность сжатия заголовков пакетов IP и TCP с помощью алгоритмов, разработанных Ван Якобсоном (Van Jacobson); механизм похож на реализованный в протоколе CSLIP.

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

Хотя SLIP и PPP - прекрасные средства доступа к Web-серверу, в некоторых случаях переход на режим удаленного управления является лучшим решением.

PPPoE (Point-to-point protocol over Ethernet) — это туннелирующий протокол, который позволяет инкапсулировать IP, или другие протоколы, которые наслаиваются на PPP, через соединения Ethernet, но с программными возможностями PPP соединений, и поэтому используется для соединения с Ethernet-машиной и устанавливает соединение точка-точка, которое используется для транспортировки IP-пакетов, работающее с возможностями PPP.

Это позволяет применять традиционное PPP-ориентированное ПО для настройки соединения, которое использует не последовательный канал, а пакетно-ориентированную сеть (как Ethernet), чтобы организовать классическое соединение с логином, паролем для Интернет-соединений. Также, IP-адрес по другую сторону соединения назначается только когда PPPoE соединение открыто, позволяя динамическое переиспользование IP адресов.

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

Список литературы

1. http://book.itep.ru - Семенов Ю.А. "Протоколы и ресурсы Интернет"

2. http://www.ccc.ru/

3. http://ru.wikipedia.org/

4. http://lib.ru/unixhelp/slip.txt

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Привет студентам) если возникают трудности с любой работой (от реферата и контрольных до диплома), можете обратиться на FAST-REFERAT.RU , я там обычно заказываю, все качественно и в срок) в любом случае попробуйте, за спрос денег не берут)
Olya16:42:31 01 сентября 2019
.
.16:42:30 01 сентября 2019
.
.16:42:29 01 сентября 2019
.
.16:42:28 01 сентября 2019
.
.16:42:27 01 сентября 2019

Смотреть все комментарии (11)
Работы, похожие на Реферат: «Сетевой межузловой протокол ppp история возникновения, область применения, основные команды, перспективы»

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

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



Результаты(258743)
Комментарии (3486)
Copyright © 2005-2020 BestReferat.ru support@bestreferat.ru реклама на сайте

Рейтинг@Mail.ru