
- •1. Обзор протоколов обмена данными по телефонным линиям
- •2. Контроль четности
- •3. Стартовые и стоповые биты
- •4. Боды и биты в секунду
- •5. Соединение по протоколу slip
- •7. Что такое slip?
- •7. Инкапсуляция данных slip
- •10. Недостатки slip
- •11. Отсутствие возможности адресации
- •14. Протокол slip со сжатием (cslip)
- •15. Предпосылки к появлению cslip
- •16. Влияние аппаратных средств
- •17. Цели проектирования
- •18. Реализация slip
- •19. Протокол Point-to-Point (ррр)
- •20. Инкапсуляция данных ррр
- •21. Кадр данных ррр
- •22. Тип кадра данных в ррр
- •23. Инкапсуляция ррр по сравнению со slip
- •24. Функции по управлению соединением
- •25. Фаза установления соединения
- •27. Фаза управления сетью
- •28. Фаза прекращения соединения
- •29. Протокол управления соединением
- •30. Пакеты lcp
- •31. Структура пакетов конфигурации соединения lcp
- •32. Структура пакетов окончания сеанса lcp
- •33. Структура пакетов управления соединением lcp
- •34.Варианты конфигурации соединения lcp
- •35. Максимальная длина принимаемого блока
- •36. Конфигурация протокола авторизации доступа
- •37. Конфигурация протокола управления качеством
- •38. Магическое число
- •39. Сжатия данных поля протокола
- •40. Конфигурация сжатия полей адреса и управления
- •41. Что такое протокол управления сетью ip?
- •42. Чем ipcp отличается от lcp?
- •43. Варианты конфигурации протокола iрср
- •44. Конфигурация протокола сжатия ip
- •45. Конфигурация ip-адреса
- •46. Резюме
18. Реализация 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.