Протоколы обмена данными по последовательным линиям связи SLIP и CSLIP.


Основное отличие протоколов SLIP и PPP от рассмотренных выше протоколов – это то, что они поддерживают связь "точка-точка", когда сетевой кабель используется для передачи информации только между двумя компьютерами (или другим сетевым оборудованием), соединенным этим кабелем. Такое соединение характерно при подключении к Internet по телефонной линии, при соединении локальных сетей между собой по выделенным или коммутируемым линиям, а также в сетях X.25, Frame Relay и ATM (см. далее в лекциях). Существует большое количество протоколов канального уровня для соединения "точка-точка", однако здесь мы ограничимся рассмотрением только SLIP и PPP.

SLIP (Serial Line IP) – протокол канального уровня, который позволяет использовать последовательную линию передачи данных (телефонную линию) для связи с другими компьютерами по протоколу IP (протокол сетевого уровня). SLIP появился достаточно давно, для связи между Unix – компьютерами по телефонным линиям и, в настоящее время, является устаревшим, т.к. не позволяет использовать протоколы сетевого уровня, отличные от IP, не позволяет согласовывать IP – адреса сторон и имеет слабую схему аутентификации (подтверждения личности) пользователя, заключающуюся в пересылке по сети имени и пароля пользователя. Таким образом, имя и пароль (даже зашифрованный) могут быть перехвачены и повторно использованы злоумышленником, или он может просто дождаться, пока пользователь пройдет аутентификацию, а затем отключить его и самому подключится от имени пользователя. Поэтому, большинство провайдеров Internet для подключения к своим машинам используют протокол PPP.

Протокол канального уровня PPP (Point to Point Protocol – протокол точка-точка) позволяет использовать не только протокол IP, но также и другие протоколы сетевого уровня (IPX, AppleTalk и др.). Достигается это за счет того, что в каждом кадре сообщения хранится не только 16-битная контрольная сумма, но и поле, задающее тип сетевого протокола. Протокол PPP также поддерживает сжатие заголовков IP-пакетов по методу Ван Джакобсона (VJ-сжатие), а также позволяет согласовать максимальный размер передаваемых дейтаграмм, IP-адреса сторон и др. Аутентификация в протоколе PPP является двусторонней, т.е. каждая из сторон может потребовать аутентификации другой. Процедура аутентификации проходит по одной из двух схем:

а) PAP (Password Authentication Protocol) – в начале соединения на сервер посылается имя пользователя и

(возможно зашифрованный) пароль.

б) CHAP (Challenge Handshake Authentication Protocol) – в начале соединения сервер посылает клиенту случайный запрос (challenge). Клиент шифрует свой пароль, используя однонаправленную хэш-функцию (функция у которой по значению Y невозможно определить X) и запрос, в качестве ключа шифрования. Зашифрованный отклик (response) передается серверу, который, имея в своей базе данных пароль клиента, выполняет те же операции и, если полученный от клиента отклик совпадает с вычисленным сервером, то аутентификация считается успешной. Таким образом, пароль по линиям связи не передается. Даже если отклик клиента и будет перехвачен, то в следующий раз использовать его не удастся, т.к. запрос сервера будет другим. Определить же пароль на основании отклика – невозможно, т.к. хэш-функция шифрует данные только "в одну сторону". Для предотвращения вмешательства в соединение уже после прохождения клиентом аутентификации, в схеме CHAP сервер регулярно посылает испытательные запросы через равные промежутки времени. При отсутствии отклика или неверном отклике соединение прерывается.

Модель OSI. Верхние уровни

Пользователи Интернета, работающие через поставщиков услуг Интернета, представляют очень существенный сегмент сети. Прием и передача данных ведется при помощи модема, подключенного через последовательный порт компьютера к обычной телефонной линии. Для работы с сетью через модем используется один из двух существующих протоколов для работы по последовательным линиям связи: PPP или SLIP. Для того чтобы писать сетевые приложения, необходимо хорошо представлять себе ключевые моменты и различия между ними. Необходимо также иметь представление о производном от SLIP-протоколе, который называется SLIP с компрессией (обеспечивающий сжатие данных). В данной статье рассматриваются вопросы, связанные с первым протоколом - SLIP и его модификацией CSLIP (описаны в документах RFC 1055 и RFC 1144).

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

Соединение по протоколу SLIP

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

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

Известно, что каждый уровень стека протоколов TCP/IP инкапсулирует (вставляет) данные в том формате, в котором они требуются для передачи окружающим уровням. При "путешествии" данных через стек протоколов TCP/IP они последовательно окружаются дополнительной информацией (инкапсулируются) для следующего на пути уровня. Для того чтобы послать IP-датаграмму через сетевой уровень, вышележащий уровень соединения должен соответствующим образом инкапсулировать данные, оформить их в кадр, как того требует стандарт сетевого уровня протокола TCP/IP. Например, уровень соединения для сети Ethernet инкапсулирует данные в кадр Ethernet. Для сети token-ring, соответственно, это будут кадры стандарта token-ring.

Стандарты передачи данных по последовательному каналу связи, SLIP и CSLIP просто определяют другой способ инкапсуляции. SLIP и CSLIP подготавливают данные для передачи по последовательному каналу (обычно это интерфейс RS-232) в Интернет. Протокол РРР также инкапсулирует данные для этой же цели. Однако РРР использует более сложный метод инкапсуляции и интерфейс с Интернетом, нежели SLIP. Однако канал передачи для них всех по-прежнему последовательный и двухточечный. Логически, SLIP и РРР находятся между последовательным портом компьютера и его программным стеком TCP/IP.

Что такое SLIP?

Протоколы семейства TCP/IP могут работать, пользуясь широким спектром разнообразных сетевых технологий. Большинство сетевых технологий требуют применения четко определенной структуры кадра данных. Институт электрической и электронной инженерии (IEEE), основанный в 1963 году и имеющий в своем составе более 300 000 членов, описал набор различных стандартов, облегчающих производителям ПО и оборудования разработку и применение совместимых друг с другом стандартов по передаче данных, в том числе и в локальных компьютерных сетях. Как и большинство создающих стандарты организаций, IEEE нумерует исходящие документы. Группа стандартов IEEE 802 посвящена локальным компьютерным сетям. Например, стандарт IEEE 802.1 посвящен методам управления сетью, IEEE 802.3 и IEEE 802.5 описывают физические уровни для сетей Ethernet и token-ring, IEEE 802.2 содержит спецификацию уровня соединения для сетей типа Ehternet, token ring и ряда других технологий.

Преобразование (инкапсуляция) данных для передачи по последовательным каналам связи описано в документе под названием RFC 1055, "A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP", Rornkey, 1988. RFC 1055 не является официальным стандартом Интернета. Он описывает стандарт де-факто. Это значит, что, хотя сообщество Интернет и не рассматривает RFC 1055 в качестве стандарта, любой желающий, чтобы его программное обеспечение обладало совместимостью с уже существующими методами передачи, должен воспользоваться рекомендациями документа в своей работе.

SLIP - это протокол инкапсуляции IP-пакетов в кадры, пригодные для передачи по последовательному каналу связи. SLIP не предоставляет возможности адресовать данные, обозначать типы кадров, корректировать или определять повреждение данных, а также сжимать пакеты. Отсутствие этих возможностей делает протокол чрезвычайно простым в реализации и, следовательно, популярным. Несмотря на популярность, фирмы и производители программного обеспечения редко используют SLIP в качестве стандартного протокола, так как он не является официальным стандартом Интернета. Как правило, в качестве такого стандарта применяется РРР. Протокол РРР - это действительно стандарт Интернета, обладающий теми же свойствами по передаче данных в последовательном двухточечном канале, что и SLIP.

Инкапсуляция данных SLIP

Каждый протокол обладает свойством инкапсулировать данные. SLIP здесь не является исключением. Он использует специальные символы для ограничения кадра данных в последовательном канале. SLIP определяет следующие два символа, служащие для этой цели: End и Esc. Символом End служит символ с кодом ASCII 192 (ОхСО), символом Esc - символ с кодом 219 (OxDB). Компьютер с протоколом SLIP передает символ End в конце каждого пакета данных. Символ Esc используется для обозначения данных, имеющих тот же номер, что и символы Esc и End внутри пакета данных. В том, что для Esc и End выбрали именно указанные коды, нет особого скрытого смысла. Просто они были выбраны, и все. Поэтому почти наверняка в потоке данных пользователя будут встречаться как символы Esc, так и End. Когда это происходит, SLIP использует Esc, чтобы сообщить приемнику, что следующий символ с кодом End на самом деле не является концом кадра. Например, когда в пакете данных попадается байт с номером ОхСО (код символа End), SLIP подставляет двухбайтную Esc-последовательность Esc OxDC. Если байт имеет код самого символа Esc, SLIP вставляет двухбайтную Esc-последовательность Esc OxDD.

Реализация SLIP на принимающей стороне совершает противоположные действия, чтобы правильно разобрать поступающий пакет данных. Если в последовательности встречается символ Esc, SLIP сразу же смотрит на следующий за Esc символ и в зависимости от его номера так или иначе интерпретирует принятую последовательность. Например, если следующий за Esc символ имеет код OxDC, SLIP заменяет два символа на один с кодом ОхСО. Если принято сочетание Esc OxDD, оно заменяется на байт с кодом OxDB. Когда SLIP видит, что пришедший байт имеет код End и перед ним нет байта с кодом Esc, это значит, что достигнут конец кадра. Далее, SLIP передает все полученные до этого данные вышележащему сетевому уровню в качестве IP-пакета.

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

Как мы уже отметили выше, вставка символа End перед началом кадра позволяет принимающей стороне избавиться от любого шума на линии связи. Однако такими мерами все способности SLIP определить и тем более исправить ошибки данных исчерпываются. SLIP возлагает задачу по определению и исправлению пакетов данных и сообщений полностью на вышележащие протоколы, то есть на сетевой и транспортный уровни TCP/IP. Протокол IP требует присутствия и проверки контрольной суммы в заголовке пакета, поэтому SLIP вполне может не обращать внимания на возможное повреждение данных - эту работу за него сделает протокол IP, который проверит пакет и отбросит его в случае повреждения. TCP-протокол таким же образом проверит контрольную сумму своего заголовка и сегмента данных и в случае повреждения поступит с пакетом надлежащим образом. Итак, мы видим, что, поскольку вышележащие протоколы и так проверяют состояние и целостность данных, нет никакой необходимости вводить дополнительный контроль данных на уровне протокола SLIP.

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

Недостатки SLIP

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

Каждый раз после установления SLIP-соединения компьютер превращается в полноправный хост Интернета со своим собственным IP-адресом. Таким образом, становится возможным обслуживать и других пользователей Интернета. Поскольку ваш поставщик услуг Интернета может применять динамическое присвоение адреса (из диапазона, имеющегося у него), при каждом новом соединении ваш компьютер будет получать новый IP-адрес. Следовательно, другие компьютеры в сети будут вынуждены искать вас каждый раз под неизвестно каким адресом.

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

На свете есть много компьютеров, в которых в одно и то же время может исполняться несколько различных сетевых протоколов. Например, компьютеры фирмы DEC могут совмещать TCP/IP и DECnet. Разумеется, работая с двумя протоколами сразу, вы захотите, чтобы они жили вместе на одном и том же проводе, соединяющем вас с внешним миром. Такая задача проста, пока вы применяете Ethernet в качестве сетевой среды. Фреймы Ethernet имеют соответствующие поля, где указывается тип передающегося пакета, однако как только вы попытаетесь перейти на SLIP, обнаружится, что у кадра SLIP такое поле отсутствует, а, следовательно, он может передать данные только для одного IP протокола.

Сети Ethernet передают информацию со скоростью до 10 миллионов бит в секунду. Соединение SLIP может работать на скоростном модеме, но даже при этом обеспечивать скорость только 19200 бит в секунду. Другими словами, Ethernet быстрее SLIP более, чем в пятьсот раз. Для увеличения производительности SLIP-соединения вы можете сжимать передаваемые по модему данные, что уменьшает необходимый трафик сети и позволяет передать больше информации за меньшее время. Предположим, требуется передать файл размером в 100 Кбайт (100х1024 байт) по модему на скорости 1200 бод. Для этого потребуется около 14 минут:
100 х 1024 = 102400 байт
102400 байт / 120 байт в секунду = 853 секунды 853 секунды / 60 секунд в минуте = 14 минут

Если передаваемые данные предварительно сжать в соотношении 1:4, объем уменьшится до 25 Кбайт. Время, нужное для передачи, сократится до четырех минут. Новые модемы используют встроенную технологию сжатия данных. Некоторые программные протоколы также используют сжатие данных при работе. Информация в заголовках пакетов TCP и IP, которая меняется редко, может быть эффективно устранена с применением простейших алгоритмов сжатия данных, когда передаются только изменяющиеся части заголовков. RFC 1055, описывающий протокол SLIP, не описывает, однако, никакого алгоритма компрессии. В следующем разделе вы познакомитесь с реализацией протокола CSLIP, обладающего возможностью сжимать заголовки TCP/IP для увеличения производительности.

Протокол SLIP со сжатием (CSLIP)

Алгоритм SLIP со сжатием заголовков данных, увеличивающий производительность сети, рассматривается в документе под названием RFC 1144, "Сжатие заголовков TCP/IP на низкоскоростных последовательных соединениях" (Compressing TCP/IP Headers for Low-Speed Serial Links, Jacobson, 1990).

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

Предпосылки к появлению CSLIP

Чтобы понять, почему сжатие заголовков пакетов столь эффективно, давайте рассмотрим некоторые типичные сетевые задачи;

Интерактивный вход в удаленный компьютер (Telnet);

Интерактивная передача файлов (FTP);

Электронная почта с использованием Simple Mail Transfer Protocol (SMTP);

Чтение и передача новостей с использованием Network News Transfer Protocol (NNTP).

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

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

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

Обыкновенно IP-заголовки имеют длину в 20 байт, заголовок TCP имеет длину также в 20 байт. Отсюда следует, что сеанс Telnet создает пакеты данных длиной в 40 байт заголовков для каждого переданного символа в один байт. Для понимания принципа работы CSLIP нужно усвоить два различных, но тесно связанных понятия: эффективность линии и интерактивная реакция системы. Эффективность линии - это коэффициент, равный длине заголовка TCP/IP-пакета, деленной на длину заголовка плюс длину данных пользователя в этом пакете. Мы сейчас вычислим эффективность линии для сеанса Telnet.

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

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

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

Неинтерактивная передача пакетов также может влиять на интерактивную реакцию системы. Например, чтобы передача неинтерактивных пакетов обладала эффективностью более 90 процентов при длине TCP/IP-заголовков в 40 байт, необходимо сохранять максимальную длину пакета (MTU) в диапазоне от 500 до 1000 байт. Предположим далее, что ваше соединение SLIP имеет MTU 1024 байт при скорости модема 9600 бод. При этом, один пакет в одну сторону будет передаваться приблизительно в течение секунды. Любой интерактивный сеанс будет при этом ждать окончания передачи неинтерактивного пакета.

Влияние аппаратных средств

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

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

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

Чтобы определить, какая из сторон в соединении требует большей полосы, производители модемов считают, что одной из сторон всегда является человек, и именно она требует наибольшей полосы. Модем, однако, должен самостоятельно догадаться об этом. За отправную точку берется скорость в 300 бит в секунду. Большинство людей не могут печатать со скоростью, превышающей указанную. К сожалению, ситуация меняется, как только мы начинаем передавать пакеты TCP/IP с заголовками из сорока байт на каждый введенный символ. Скорость увеличивается в соотношении 40:1 и заставляет модем часто менять полосы в противоположных направлениях. IP-пакет размером в 41 байт состоит из 328 бит, что выходит за пределы, предписанные для узнавания человека модемом. При покупке модема следует обращать внимание на такие тонкости, как поддерживаемые типы сжатия данных и другие возможности по передаче данных. Покупка хорошего в этих отношениях модема позволит вам значительно увеличить производительность сетевого соединения.

Цели проектирования

Современная архитектура модемов позволяет сократить потребность в скорости передачи нажатий клавиш до 300 бит в секунду и даже меньше. Если мы рассматриваем десятибитовую последовательность на один символ (восемь бит данных плюс старт- и стоп-биты), 300 бит в секунду образуют полосу пропускания в 30 байт данных в секунду. Обычная скорость печати на клавиатуре составляет 5 символов в секунду. Таким образом, для передачи заголовков остается 25 байт (30 - 5) при условии сохранения выбранной максимальной полосы пропускания в 300 бит в секунду. Другими словами, на один передаваемый символ допустимо передать еще и пятибайтовый заголовок. Кроме того, такая передача сохраняет хорошую интерактивность системы, так как пауза между нажатием и получением эха у нас не превысит 200 миллисекунд при скорости 4096 бит в секунду.

Реализация SLIP

В RFC 1144 обсуждаются методы, служащие для сокращения необходимой длины передаваемых заголовков с 40 байт на пакет до всего лишь трех-пяти. Джекобсон показывает, что на протяжении TCP-соединения около половины информации заголовка остается неизменной. Протокол CSLIP требует, чтобы после установки TCP-соединения хостами, они хранили у себя копии последнего принятого и переданного пакетов, и в дальнейшем, храня у себя номер текущего соединения, просто передает изменения в заголовках, позволяя собирать реальный заголовок на основе имеющейся неизменной части и принятого изменения.

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

Далее, CSLIP не передает поле IP заголовка "Общая длина пакета" (Total Length), получая его вместо этого от сетевого уровня соединения и сокращая длину еще как минимум на два байта. В заголовке IP-пакета остается только поле контрольной суммы заголовка, однако нет никакой необходимости передавать контрольную сумму отсутствующих данных. Вместо передачи контрольной суммы заголовка CSLIP вычисляет ее на месте, в отличие от SLIP, который по-прежнему вынужден передавать контрольную сумму по каналу связи. Мы убираем контрольную сумму заголовка - и получаем еще два байта экономии.

В результате остается еще 16 байт в заголовке пакета, которые могут изменяться на протяжении сеанса TCP/IP. Разумеется, они изменяются не постоянно, а лишь иногда. В RFC 1144 отмечается, что, скажем, протокол FTP изменяет только идентификаторы пакетов (ID), номер последовательности и контрольную сумму в направлении от передатчика к приемнику. Идентификатор пакета, пакет-подтверждение, контрольная сумма и, возможно, окно передачи - вот что обычно изменяется по направлению от приемника к передатчику. Передатчик CSLIP всегда хранит копию последнего посланного пакета у себя. Таким образом, он знает, какие именно изменения произошли в следующем по счету пакете для передачи. Если передатчик шлет только изменившиеся байты, средний размер заголовка пакета становится равным примерно десяти байтам. Зная, каким образом изменяются поля в заголовке, можно достичь еще большего сокращения его размера.

Идентификатор пакета изменяется, как правило, на единицу при передаче каждого нового пакета. Что это значит? Что разность двух идентификаторов можно закодировать небольшим положительным целым числом, меньшим, чем 256 (один байт). Как правило, это число равно единице. Далее, для передатчика номер последовательности текущего пакета будет числом, полученным от сложения этого номера у предыдущего пакета с длиной предыдущего пакета. Максимальная длина IP-пакета равна 64000 байт, значит, изменение номера последовательности между двумя пакетами никогда не превысит двух байт. На этом этапе, посылая вместо реальных полей только их изменения, CSLIP экономит нам еще от трех до четырех байт дополнительно.

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

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

Протокол SLIP (Serial Line Internet Protocol). Технология TCP/IP позволяет организовать межсетевое взаимодействие, используя различные физические и канальные протоколы обмена данными (IEEE 802.3 - ethernet, IEEE 802.5 - token ring, X.25 и т.п.). При этом, без обмена данными по телœефонным линиям связи с использованием обычных модемов популярность Internet была бы значительно ниже. Большинство пользователœей Сети используют свой домашний телœефон в качестве окна в мир компьютерных сетей, подключая компьютер через модем к модемному пулу компании, предоставляющей IP-услуги или к своему рабочему компьютеру. Наиболее простым способом, обеспечивающим полный IP-сервис, является подключение через последовательный порт персонального компьютера по протоколу SLIP. Согласно RFC-1055, впервые SLIP был включен в качестве средства доступа к IP-сети в пакет фирмы 3COM - UNET. В 1984 году Рик Адамс(Rick Adams) реализовал SLIP для BSD 4.2, и таким образом SLIP стал достоянием всœего IP-сообщества. Обычно, данный протокол применяют как на выделœенных, так и на коммутируемых линиях связи со скоростями от 1200 до 19200 бит в секунду. В случае если модемы позволяют больше, то скорость можно "поднять", т.к. современные персональные компьютеры позволяют передавать данные в порт со скоростью 115200 битов за секунду. При этом, при определœении скорости обмена данными следует принимать во внимание, что при передаче данных по физической линии данные подвергаются преобразованиям: компрессия и защита от ошибок на линии. Такое преобразование заставляет определять меньшую скорость на линии, чем скорость порта. Следует отметить, что среди условно-свободно распространяемых программных IP-стеков (FreeWare), Trumpet Winsock, к примеру, обязательно включена поддержка SLIP-коммуникаций. Такие операционные системы, как FreeBSD, Linux, NetBSD, которые можно свободно скопировать и установить на своем персональном компьютере, или HP-UX, которая поставляется вместе с рабочими станциями Hewlett Packard, имеют в своем арсенале программные средства типа sliplogin (FreeBSD) или slp (HP-UX), обеспечивающими работу компьютера в качестве SLIP-сервера для удаленных пользователœей, подключающихся к IP-сети по телœефону. В протоколе SLIP нет определœения понятия "SLIP-сервер", но реальная жизнь вносит коррективы в стандарты. В контексте нашего изложения "SLIP-клиент" - это компьютер инициирующий физическое соединœение, а "SLIP-сервер" - это машина, постоянно включенная в IP-сеть. В главе, посвященной организации IP-сетей и подключению удаленных компьютеров, будет подробно рассказано о различных способах подключения по SLIP-протоколу, в связи с этим не останавливаясь на деталях такого подключения перейдем к обсуждению самого протокола SLIP. В отличии от Ethernet, SLIP не "заворачивает" IP-пакет в свою обертку, а "нарезает" его на "кусочки". При этом делает это довольно примитивно. SLIP-пакет начинается символом ESC (восьмеричное 333 или десятичное 219) и кончается символом END (восьмеричное 300 или десятичное 192). В случае если внутри пакета встречаются эти символы, то они заменяются двухбайтовыми последовательностями ESC-END (333 334) и ESC-ESC (333 335). Стандарт не определяет размер SLIP-пакета͵ в связи с этим любой SLIP-интерфейс имеет специальное поле, в котором пользователь должен указать эту длину. При этом, в стандарте есть указание на то, что BSD SLIP драйвер поддерживает пакеты длиной 1006 байт, в связи с этим "современные" реализации SLIP-программ должны поддерживать эту длину пакетов. SLIP-модуль не анализирует поток данных и не выделяет какую-либо информацию в данном потоке. Он просто "нарезает" ее на "кусочки", каждый из которых начинается символом ESC, а кончается символом END. Из приведенного выше описания понятно, что SLIP не позволяет выполнять какие-либо действия, связанные с адресами, т.к. в структуре пакета не предусмотрено поле адреса и его специальная обработка. Компьютеры, взаимодействующие по SLIP, обязаны знать свои IP-адреса заранее. SLIP не позволяет различать пакеты по типу протокола, к примеру, IP или DECnet. Вообще-то, при работе по SLIP предполагается использование только IP (Serial Line IP всœе-таки), но простота пакета должна быть соблазнительной и для других протоколов. В SLIP нет информации, позволяющей корректировать ошибки линии связи. Коррекция ошибок возлагается на протоколы транспортного уровня - TCP, UDP. В стандартном SLIP не предусмотрена компрессия данных, но существуют варианты протокола с такой компрессией. По поводу компрессии следует заметить следующее: большинство современных модемов, поддерживающих стандарты V.42bis и MNP5, осуществляют аппаратную компрессию. При этом практика работы по нашим обычным телœефонным каналам показывает, что лучше отказаться от этой компрессии и работать только с автоматической коррекцией ошибок, к примеру MNP4 или V.42. Вообще говоря, каждый должен подобрать тот режим, который наиболее устойчив в конкретных условиях работы телœефонной сети (вплоть до времени года, и частоты аварий на теплотрассах).

Соединœения типа "точка-точка" - протокол PPP (Point to Point Protocol) . PPP - это более молодой протокол, нежели SLIP. При этом, назначение у него то же самое - управление передачей данных по выделœенным или коммутируемым линиям связи. Согласно RFC-1661, PPP обеспечивает стандартный метод взаимодействия двух узлов сети. Предполагается, что обеспечивается двунаправленная одновременная передача данных. Как и в SLIP, данные "нарезаются" на фрагменты, которые называются пакетами. Пакеты передаются от узла к узлу упорядоченно. В отличии от SLIP, PPP позволяет одновременно передавать по линии связи пакеты различных протоколов. Вместе с тем, PPP предполагает процесс автоконфигурации обоих взаимодействующих сторон. Собственно говоря, PPP состоит из трех частей: механизма инкапсуляции (encapsulation), протокола управления соединœением (link control protocol) и семейства протоколов управления сетью (network control protocols). При обсуждении способов транспортировки данных при межсетевом обмене часто применяется инкапсуляция, к примеру, инкапсуляция IP в X.25. С инкапсуляцией TCP в IP мы уже встречались. Инкапсуляция обеспечивает мультиплексирование различных сетевых протоколов (протоколов межсетевого обмена, к примеру IP) через один канал передачи данных. Инкапсуляция PPP устроенна достаточно эффективно, к примеру для передачи HDLC фрейма требуется всœего 8 дополнительных байтов (8 октетов, согласно терминологии PPP). При других способах разбиения информации на фреймы число дополнительных байтов должна быть сведено до 4 или даже 2. Для обеспечения быстрой обработки информации граница PPP пакета должна быть кратна 32 битам. При крайне важно сти в конец пакета для выравнивания на 32-битовую границу добавляется "балласт". Вообще говоря, понятие инкапсуляции в терминах PPP - это не только добавление служебной информации к транспортируемой информации, но, в случае если это крайне важно, и разбиение этой информации на более мелкие фрагменты. Под датаграммой в PPP понимают информационную единицу сетевого уровня, применительно к IP - IP-пакет. Под фреймом понимают информационную единицу канального уровня (согласно модели OSI). Фрейм состоит из заголовка и хвоста͵ между которыми содержатся данные. Датаграмма должна быть инкапсулирована в один или несколько фреймов. Пакетом называют информационную единицу обмена между модулями сетевого и канального уровня. Обычно, каждому пакету ставится в соответствие один фрейм, за исключением тех случаев, когда канальный уровень требует еще большей фрагментации данных или, напротив - объединяет пакеты для более эффективной передачи.

Протоколы SLIP и PPP - понятие и виды. Классификация и особенности категории "Протоколы SLIP и PPP" 2017, 2018.

  • - Протоколы Интернет

    Что касается протоколов, в Интернете используются несколько типов протоколов, появлявшихся с течением времени и развитием компьютерных технологий. К ним относятся Протокол TCP/IT (1974) o TCP (Transmission Control Protocol) Файл делится на пакеты размером не более 1,5 КБ Пакеты передаются... .


  • - Базовые протоколы Интернет

  • - Базовые протоколы Интернет

    Адресация в Интернет Для каждого компьютера в Интернет устанавливаются два уникальных адреса: цифровой IP-адрес и доменный адрес. Оба эти адреса могут применяться равноценно. Цифровой адрес удобен для обработки на компьютере, а доменный адрес – для... .


  • - Назначение КС. Глобальные и локальные КС. Определения и возможности Интернета, протоколы и услуги Интернета.

    Локальная сеть – сеть, объединяющая ПК, размещенные на ограниченной территории и функционирующая на единых программных принципах. Появление ЛВС позволило значительно повысить эффективность применения ВТ за счет более рационального использования аппаратных,...

  • Мы ранее рассматривали вхождение в сети через локальный интерфейс Ethernet. Рассмотрим использование в сети телефонной линии. Существует соответственное программное обеспечение.

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

    В качестве стандартных программ управляющих передачей через телефонные линии использует два протокола SLIP и PPP.

    SLIP-протокол

    SLIP (Serial Line IP) –.протокол последовательной передачи данных. Протокол SLIP позволяет компьютеру использовать IP в осуществлении связи в сети через телефонные линии и модемы, а также непосредственно через интерфейс RS-232.

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

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

    Символ SLIP END – соответствующий байту с децимальным кодом 192, который маркирует конец датаграммы. Когда принимающий SLIP получает байт с таким кодом, он определяет, что это конец датаграммы и передаёт её IP уровню.

    Символ SLIP ESC – соответствующий байту с децимальным кодом 219. этот символ предназначен для исключения из последовательности SLIP-управляющих символов. Если передающий SLIP распознаёт в выводимой информации байт со значением эквивалентным SLIP END, то он преобразует этот символ в двух байтовую последовательность байт. Эти 2-х байтные последовательности, он преобразовывает их обратно в однобайтовые значения.

    Протокол SLIP очень простой. Он не организует проверки правильности передачи, не умеет управлять параметрами соединения и т.д., что сильно ограничивает его применимость.

    Протокол PPP

    Учитывая недостатки SLIP, был разработан протокол PPP – the point-to-point protocol. Этот протокол разработан группой IETF (Internet Engineering Task Force) как часть стека TCP/IP для передачи кадров информации по последовательным глобальным каналам. Протокол PPP стал фактическим стандартом для глобальных линий связи при соединении удаленных клиентов с серверами и для образования соединений между маршрутизаторами в корпоративной сети. Протокол PPP разрабатывался с целью передачи данных для широкого круга сетевых протоколов. Протокол PPP более надёжный протокол, чем SLIP, но и более трудоёмкий в исполнении.

    При разработке протокола PPP за основу был взят формат кадров HDLC и дополнен собственными полями. Поля протокола PPP вложены в поле данных кадра HDLC. Позже были разработаны стандарты, использующие вложение кадра PPP в кадры frame relay и других протоколов глобальных сетей.

    PPP протокол является 3-х-уровневым протоколом, включающим в себя:

    Data link layer protocol – уровень пересылки данных использует простую модификацию версии HDLC – протокола (High-level Data Link Control). HDLC – это международный стандарт для надёжной передачи данных через синхронную, последовательную линию связи, т.е. протокол PPP может гарантировать надёжную доставку сообщений, через различные типы последовательных линий.

    Link Control Protocol – протокол управления связью. Производит управляющую информацию для последовательной линии. Он используется для установления соединения, конфигурирования параметров соединения, проверки качества соединения, и для закрытия соединения.

    Network Control Protocol – протокол управления сетью – производит конфигурацию и управляющую информацию для протоколов сетевого уровня.

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

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

    Переговорное принятие параметров соединения . В корпоративной сети конечные системы часто отличаются размерами буферов для временного хранения пакетов, ограничениями на размер пакета, списком поддерживаемых протоколов сетевого уровня. Физическая линия, связывающая конечные устройства, может варьироваться от низкоскоростной аналоговой линии до высокоскоростной цифровой линии с различными уровнями качества обслуживания. Чтобы справиться со всеми возможными ситуациями, в протоколе РРР имеется набор стандартных установок, действующих по умолчанию и учитывающих все стандартные конфигурации. При установлении соединения два взаимодействующих устройства для нахождения взаимопонимания пытаются сначала использовать эти установки. Каждый конечный узел описывает свои возможности и требования. Затем на основании этой информации принимаются параметры соединения, устраивающие обе стороны, в которые входят форматы инкапсуляции данных, размеры пакетов, качество линии и процедура аутентификации. Протокол, в соответствии с которым принимаются параметры соединения, называется протоколом управления связью (Link Control Protocol, LCP) . Протокол, который позволяет конечным узлам договориться о том, какие сетевые протоколы будут передаваться в установленном соединении, называется протоколом управления сетевым уровнем (Network Control Protocol, NCP) . Внутри одного РРР - соединения могут передаваться потоки данных различных сетевых протоколов. Одним из важных параметров РРР - соединения является режим аутентификации. Для целей аутентификации РРР предлагает по умолчанию протокол РАР (Password Authentication Protocol), передающий пароль по линии связи в открытом виде, или протокол CHAP (Challenge Handshake Authentication Protocol), не передающий пароль по линии связи и поэтому обеспечивающий большую безопасность сети. Пользователям также разрешается добавлять и новые алгоритмы аутентификации. Дисциплина выбора алгоритмов компрессии заголовка и данных аналогична.

    Протокол DNS

    7.6.1 Описание протокола DNS

    В первые годы Internet имел небольшое число узлов. До 1980 года в сети ARPANET входило несколько сотен компьютеров. Соответствие между их именами и IP-адресами хранились в текстовом файле hosts.txt, но он хранился на компьютере Информационного центра сети в Стэнфордском исследовательском институте г. Мейло-Парк в Калифорнии (SRI-NIC – Stanford Research Institute’s Network Inform Center).

    Другие компьютеры подключенные к сети ARPANET, по мере необходимости копировали этот файл с компьютера SRI-NIC. Обновление происходило один два раза в неделю. С ростом числа машин стали возникать проблемы:

    Файл hosts.txt стал слишком большим;

    Обновление необходимо проводить несколько раз в день;

    Весь трафик сети, связанный с разрешением имён, проходил через SRI-NIC, и поддержка файла hosts.txt стала узким местом всей сети;

    Файл hosts.txt использовал линейное пространство имён.

    Эти и другие проблемы заставили руководство ARPANET искать механизм замены файла hosts.txt. В результате была создана доменная система имён – DNS.

    DNS – это метод назначения имён путём передачи сетевым группам ответственности за их подмножество имён.

    Каждый уровень этой системы называется доменом. Домены в именах отделяются друг от друга точками.

    Пример: admin.isp.nsc.ru. или cyber.neic.nsk.ru.

    Первым в имени стоит название рабочей машины – реального компьютера с IP-адресом.

    Затем в имени стоит имя группы (например: neic –имя института, либо имя группы, которая поддерживает множество имён машин).

    Группа входит в более крупное объединение (например: nsc – Сибирское отделение, nsk – г.Новосибирск).

    Объединение является частью национальной сети (например: ru, su – Россия, de – Германия, pl – Польша и т.д.).

    Для США наименование страны опускается, там самыми крупными объединениями является сети образовательных (.edu), коммерческих (.com), государственных (.gov), военных (.mil), других (.org) и сетевых (.net) ресурсов.

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

    DNS – представляет собой иерархическую распределённую систему управления базой данных, основанная на архитектуре “клиент-сервер”. Назначение базы данных DNS – преобразование имён компьютеров в IP-адреса. Клиенты DNS называются определителями, а серверы – серверами имён.

    Информация об этих серверах должна хранится на DNS-серверах зоны более высокого уровня, включающей домен этой зоны.

    Серверы имён разделяются на основной и резервный.

    Основной сервер имён получает данные для зоны из локальных файлов. Модификация зоны – добавление (удаление) доменов или узлов – выполняется на уровне основного сервера.

    Резервные серверы имён получают данные о зонах от основного сервера. Передача информации о зоне называется передачей зоны.

    Сервер определяется как основной и резервный на уровне зоны. Поэтому каждый сервер может быть как основным так и резервным.

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

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

    DNS-сервер имеет два файла, содержащих базу имён:

    файл прямой зоны;

    файл обратной зоны.

    Файл прямой зоны – named.hosts используется для преобразования имён машин в IP-адреса.

    Строка того файла содержит имя мащины и ее IP-адрес:

    admin.isp.nsc.ru IN A 194.226.178.182

    Файл обратной зоны named.rev (*.rev) преобразует IP-адрес в имя машины. Строка файла обратной зоны содержит IP-адрес машины и ее имя:

    194.226.178.182 IN PTR admin.isp.nsc.ru

    7.7 Протокол RIP – маршрутизации

    Протокол маршрутной информации. RIP (routing information protocol) – относится к широко известному классу протоколов маршрутизации, основанных на алгоритме Беллмана-Форда. Этот протокол базируется на так называемых алгоритмах векторных расстояний.

    Маршрутизация – это средство определения оптимального пути между двумя узлами в Internet. Без маршрутизации трафик был бы ограничен простой физической сетью.

    Существует три наиболее общих маршрутных конфигураций:

    минимальная маршрутизация – используется, когда сеть полностью изолирована от других TCP/IP сетей. Таблица минимальной маршрутизации создаётся вручную, администратором в процессе конфигурирования сети;

    статическая конфигурация – используется, когда сеть имеет ограниченное число шлюзов к другим TCP/IP сетям. Таблица статической маршрутизации создаётся вручную системным администратором с помощью команды route. Таблица статической маршрутизации используется, если в структуре сети нет изменений;

    динамическая маршрутизация – используется, когда в сети имеется больше, чем один маршрут к какой-либо другой машине.

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

    Информация о маршрутах между хостами не зависимо, каким образом она определялась – администратором вручную или протоколом маршрутизации и хранится в таблице маршрутов.

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

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

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

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

    длина равняется= (длина пути, сообщённая соседом A) + (длина пути до соседа A).

    Рассмотрим принцип формирования таблиц маршрутов. Пусть дана сеть, показанная на рисунке 7.7.

    Рис.7.7. Пример структуры сети

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

    Маршрутизатор A.

    Маршрутизатор B.

    Маршрутизатор C.

    Рис.7.8. Таблицы маршрутов

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

    Так после первой итерации обменов маршрутизатор А получит данные от маршрутизатора В и скорректирует метрику до сети D. Маршрутизатор С получит данные от маршрутизатора D и скорректирует метрику до сети T.

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

    Алгоритм Беллмана-Форда предусматривает диагностику обрыва линии. Если сосед соседу долго не отвечает, линии назначается метрика равная бесконечности – ∞.

    Протокол RIP имеет следующие недостатки:

    использование фиксированных метрик;

    трудности в использовании в больших сетях, так как при расширении сети увеличивается количество изменения топологии, что требует более частой передачи маршрутной информации;

    таблицы маршрутизации не учитывает возникающую загрузку каналов.

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

    В настоящее время введён протокол маршрутизации нового поколения OSPF (open shortest path first).

    Помимо основной функции – маршрутизации он оперативно распределяет график между равноценными маршрутами.

    Составление таблиц маршрутизации может выполняться алгоритмом Беллмана-Форда. А механизм сбора и использования маршрутной информации отличается от RIP.

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

    Если возникает изменение, то осуществляется рассылка информации методом лавинной маршрутизации.

    7.8 NFS – сетевая файловая система

    NFS – позволяет директориям и файлам быть распределёнными по сети.

    Исходно NFS была разработана фирмой SON Microsystem. В настоящее время используется во всех UNIX – подобных ОС и в других не UNIX – подобных.

    Через NFS пользователи и программы получают доступ к файлам, размещённым на удалённых компьютерах.

    NFS имеет следующие достоинства:

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

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

    NFS позволяет пользователям использовать семейство UNIX-команд, для управления удалёнными файлами. Например, для копирования файла из одной PC в другую нет необходимости использовать FTP, а можно использовать команду cp (copy).

    Существует две стороны NFS – одна сторона – клиент и другая – сервер.

    Клиент NFS – это система, которая использует удалённые директории так, как, если они были частью их собственной локальной файловой системы.

    Сервер NFS – это системы, которая делает директории доступными для использования.

    Присоединение удалённой директории к локальной файловой системе (функции клиента) называется примонтированием (mounting) директории.

    Предоставление директории для удалённого доступа (сервер - функции) называется экспортированием (exporting) директории.

    Часто ОС загружает в одной машине и сервер – функции, и клиент – функции.

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

    7.8.1 Монтирование файловой системы

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

    Монтирование файловой системы производится системным вызовом mount. В качестве аргументов передаются:

    тип монтируемой файловой системы;

    имя каталога, к которому подключается FS;

    флаги (например, доступ к FS только для чтения);

    дополнительные данные (вид зависит от реализации конкретной FS).

    После монтирования файловая система может быть адресована по имени точки монтирования.

    #mount –r oberon: / / USR / local.

    #mount –t NFS oberon: / / USR / local

    7.8.2 Блокирование доступа к файлу

    NFS разрешает (в соответствии с архитектурой UNIX) нескольким процессам одновременный доступ к файлу для чтения и записи.

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

    Для блокирования заданного диапазона байтов файла или записи файла служит системный вызов fcntl() и библиотечнаяфункция lockf() для блокировки всего файла на запись для чтения.

    struct flock lock;

    // заполним структуру lock для блокирования всего файла на запись

    lock.l_type = F_RDLCK

    // заблокируем файл для записи

    fcntl (fd, SETLKW, & lock);

    // запишем данные в файл

    write (fd, record, sizeof (record));

    // снимем блокирование

    lock l_type = F_UNLCK;

    Протокол HDLC

    HDLC - протокол высокоуровнего управления каналом передачи данных, является опубликованным ISO стандартом и базовым для построения других протоколов канального уровня (SDLC , LAP , LAPB , LAPD , LAPX и LLC ). Он реализует механизм управления потоком посредством непрерывного ARQ (скользящее окно) и имеет необязательные возможности (опции), поддерживающие полудуплексную и полнодуплексную передачу, одноточечную и многоточечную конфигурации, а так же коммутируемые и некоммутируемые каналы.

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

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

    Протокол SLIP (Serial Line IP , RFC -1055) - это простейший способ инкапсуляции IP-дейтограмм для последовательных каналов связи.

    Этот протокол стал популярным благодаря возможностям подключения домашних персональных машин к сети Интернет через порт RS -232, который соединен с модемом. IP -дейтограмма в случае SLIP должна завершаться специальным символом 0xC0 называемым конец. Во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Октет 0xDB выполняет в SLIP функцию ESC -символа. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD.

    Использование протокола 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 -соединений на каждом из концов последовательного канала. Многие современные SLIP -драйверы поддерживают и CSLIP .

    Протокол PPP (Point-to-Point Protocol)

    Одной из причин малого числа каналов связи IP с непосредственным соединением было отсутствие стандартного протокола формирования пакета данных Internet. Протокол Point-to-Point Protocol (PPP) (Протокол канала связи с непосредственным соединением) предназначался для решения этой проблемы.

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

    РРР решает эти вопросы путем обеспечения расширяемого Протокола Управления Каналом (Link Control Protocol) (LCP) и семейства Протоколов Управления Сетью (Network Control Protocols) (NCP) , которые позволяют согласовывать факультативные параметры конфигурации и различные возможности.

    Сегодня PPP , помимо IP , обеспечивает также и другие протоколы, в том числе IPX и DECne .

    В отличие от 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 .





    

    2024 © gtavrl.ru.