Протоколы TCP/IP

Том 1. Принципы, протоколы и архитектура

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

  • Пpедисловие
  • Введение
  • Глава 1. Введение и обзоp
  • Глава 2. Обзоp базовых сетевых технологий
  • Глава 3. Понятие межсетевого обмена и аpхитектуpная модель
  • Глава 4. Адpеса Интеpнета
  • Глава 5. Отобpажение адpесов Интеpнета в физические адpеса(ARP)
  • Глава 6. Опpеделение межсетевого адpеса пpи начальной загpузке(RARP)
  • Глава 7. Межсетевой пpотокол: доставка дейтагpамм без установления соединения
  • Глава 8. Межсетевой пpотокол: маpшpутизация IP-дейтагpамм
  • Глава 9. Межсетевой пpотокол: ошибки и упpавляющие сообщения
  • Глава 10. Разделение пpотоколов на уpовни
  • Глава 11. Протокол UDP
  • Приложение 1 RFC-791 (IP)
  • Приложение 2 RFC-792 (ICMP)
  • Приложение 3 RFC-768 (UDP)
  • Приложение 4 RFC-793 (TCP)


Глава 2. Обзор базовых сетевых технологий

  • 2.1 Введение
  • 2.2 Два подхода к сетевому взаимодействию
  • 2.3 Глобальные сети, городские сети, локальные сети
  • 2.4 Технология Ethernet
    • 2.4.1 Свойства Ethernet'а
    • 2.4.2 Обнаружение коллизий и восстановление
    • 2.4.3 Пропускная способность Ethernet'а
    • 2.4.4 Вариации Ethernet'а
    • 2.4.5 Адресация Ethernet'а
    • 2.4.6 Формат кадра Ethernet'а
    • 2.4.7 Мосты(bridges) и их важность
  • 2.5 Технология Token Ring ProNET
    • 2.5.1 Адресация ProNET-10
    • 2.5.2 Формат кадра proNET-10
    • 2.5.3 Восстановление маркера proNET-10
    • 2.5.4 Звездообразное кольцо proNET-10
  • 2.6 Технология ARPANET
    • 2.6.1 Адресация ARPANET
  • 2.7 Сети Национального Научного Фонда(NSF)
    • 2.7.1 Старая магистральная сеть NSFNET
    • 2.7.2 Вторая магистральная сеть NSFNET в 1988-1989 годах
    • 2.7.3 Магистральная сеть NSFNET в 1989-1990 годах
    • 2.7.4 Мультиплексирование и программируемые соединения
    • 2.7.5 Сети среднего уровня NSFNET
    • 2.7.6 Сети доступа NSFNET
    • 2.7.7 Сети университетских городков NSFNET
  • 2.8 Другие технологии, над которыми использовался TCP/IP
    • 2.8.1 X25NET
    • 2.8.2 Cypress
    • 2.8.3 Коммутируемый(dial-up) IP
    • 2.8.4 Пакетное радио
  • 2.9 Итоги и выводы
  • Для дальнейшего изучения
  • Упражнения

2.1 Введение

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

Эта глава вводит основные понятия коммутации пакетов и терминологию. а затем рассматривает базовые технологии сетевого оборудования, которые использовались в объединенной сетях TCP/IP. Следующие главы описывают, как эти сети объединяются и как протоколы TCP/IP согласованы с различиями в оборудовании. В то время как список сетей, представленный здесь, не является исчерпывающим, он хорошо демонстрирует разнообразие физических сетей, над которыми работает TCP/IP.Читатель может спокойно пропустить большую часть технических деталей, но должен попытаться понять идею пакетной коммутации и должен попытаться представить архитектуру однородной коммуникационной системы, использующей такое разнообразное оборудование. Более того, читатель должен внимательно изучить детали схем физических адресаций в различных используемых технологиях; следующие главы рассмотрят детально, как протоколы высокого уровня используют эти физические адреса.

2.2 Два подхода к сетевому взаимодействию

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

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

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

2.3 Глобальные сети, городские сети, локальные сети

Сети с коммутацией пакетов, которые разрослись до больших географических размеров(например, континентальной части США), сильно отличаются от сетей, имеющих небольшие размеры(например, одну комнату). Чтобы помочь охарактеризовать различия в пропускной способности и способах использования, технологии коммутации пакетов часто делят на три большие категории: глобальные сети(WAN), городские сети(MAN) и локальные сети(LAN). Технологии WAN, иногда называемые long haul networks(буквально - сети дальних перевозок), позволяют взаимодействующим местам быть достаточно далеко друг от друга и предназначены для использования на больших расстояниях. Обычно WAN работают на более низких скоростях, чем другие технологии, и имеют гораздо большие паузы при соединении. Обычно скорости WAN лежат в диапазоне от 9.6 Кбит/с до 45 Мбит/с.

Самый новый вид сетевого оборудования, технологии MAN позволяют взаимодействовать в географических областях средних размеров и работают на скоростях от средних до высоких. Они получили такое имя из-за способности одной MAN занимать область размером с большой город. MAN работают с меньшими паузами, чем WAN, но не могут обеспечить взаимодействие на таких же больших расстояниях. Типичные MAN работают со скоростями от 56 Кбит/с до 100 Мбит/с.

Технологии LAN обеспечивают наивысшие скорости соединений между компьютерами, но не позволяют им занимать большие области. Например, типичная LAN занимает пространство, такое же как одно здание или небольшой университетский городок, и работает со скоростями от 4 Мбит/с до 2 Гбит/с.

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

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

2.4 Технология Ethernet

Ethernet - это имя, данное популярной технологии локальной сети с коммутацией пакетов, разработанной в Xerox PARC в начале 1970 года. Версия, описанная здесь, была стандартизована Xerox Corporation, Intel Corporation и Digital Equipment Corporation в 1978 году. Как показано на рисунке 2.1, Ethernet состоит из коаксиального кабеля приблизительно полдюйма в диаметре и до 500 метров длиной. Между центральным проводом и защитной оболочкой на каждом конце добавляется резистор для предотвращения отражения электрических сигналов. Называемый ether(для удобства будем называть его просто Е-кабель), этот кабель является полностью пассивным; все активные электронные компоненты, выполняющие сетевую функцию, связаны с компьютерами, присоединенными к сети.

     +------------+<=============внешняя изолирующая оболочка
     |+----------+|
     ||       <============полиэтиленовый заполнитель
     ||          ||
     ||    ==    |<===============металлическая оболочка
     ||    =<==  ||
     ||        \ ||
     |+---------\+|
     +-----------============центральный провод

Рисунок 2.1 Коаксиальный кабель, иcпользуемый в Ethernet

Ethernet'ы могут быть дополнены устройствами, называемыми повторителями, которые передают электрические сигналы от одного кабеля к другому. Рисунок 2.2 показывает типичное использование повторителей в здании фирмы. Один вертикальный магистральный кабель проложен через все этажи здания, и повторитель соединяет дополнительные кабели на каждом этаже с магистральным кабелем. Компьютеры присоединяются к кабелям, проложенным на каждом этаже. Только два повторителя могут быть помещены между любыми двумя машинами, поэтому общая длина простого Ethernetа довольно маленькая(до 1500 метров).

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

|  ___________________________
|  |    |   |   |   |   |         Этаж 3
|--O    K   K   K   K   K
|
|  ___________________________
|  |    |   |   |   |   |         Этаж 2
|--O    K   K   K   K   K
|
|  ___________________________
|  |    |   |   |   |   |         Этаж 1
|--O    K   K   K   K   K
|   \
     \________ повторитель

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

Соединения с E-кабелем делаются с помощью ответвлений, как показывает рисунок 2.3. При каждом ответвлении маленькая дырка во внешних слоях кабеля позволяет маленьким контактам касаться центрального провода и защитной металлической оболочки(некоторые производители требуют, чтобы кабель был разрезан и вставлен Т-образный соединитель). Каждое соединение с Ethernetом имеет две основные электрические компоненты. Трансивер присоединяется к центральному проводу и металлической оплетке на Е-кабеле, принимая и передавая сигналы. Интерфейс с ЭВМ соединяется с трансивером и взаимодействует с компьютером(обычно через шину компьютера).

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

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

                                      ______________________
                                    /-\     ___________      \
                                ___/_  \    \          \      |
    центральный провод       /--\    \  \    \          \     |
                     \      /    \    |  |   |          |     |
                     -------|--  |    |  |   |----------|     |
                          __\    /    |  |   |  |       |     |
    металлическая оплетка/   \--/_____/  /   /  |       /     |
                                    \   /   /___|______/      |
                                     \-/________|____|_______/
                                                |    |
                            (a)            ---------------
                                           |             |
                                           |  трансивер  |
            (b)                            |             |
                                           ---------------
                                                  |
    _______________________________               | к интерфейсу
       |   |          |                           |      ЭВМ
       |   |  ......  |                           V
       |   |          |
       O   O          O

Рисунок 2.3 (а) Наглядное представление кабеля, показывающее детали двух электрических соединений между трансивером и кабелем при ответвлении, и (b) схематическая диаграмма Ethernetа с группой ответвлений.

2.4.1 Свойства Ethernet'а

Ethernet - это технология общей шины со скоростью 10 Мбит/с , с механизмом негарантированной(best effort) доставки и распределенным управлением доступом. Она называется технологией общей шины из-за того, что все станции разделяют один общий канал взаимодействия; она - широковещательная, так как все трансиверы принимают информацию, передаваемую всеми станциями. Метод, используемый для передачи пакетов от одной станции к другой или к группе станций, будет рассмотрен позднее. На данный момент достаточно уяснить, что трансиверы не фильтруют информацию - они передают все пакеты на интерфейс ЭВМ, который выбирает из них нужные этой ЭВМ и отбрасывает другие пакеты. Ethernet называется механизмом негарантированной доставки, так как он не информирует отправителя о том, был ли доведен пакет до получателя. Например, если случилось так, что машина получателя выключена, пакет будет потерян, но отправитель ничего не будет знать об этом. мы увидим позднее, как протоколы TCP/IP согласованы с оборудованием с негарантированным доведением.

                                          Ethernet
    _______________________________________________________
         |
         |
      -------      трансивер
      |     |<------ | | ... | / / \ / /<-------шина компьютера \_____ / / | / / / | | / | |<---------------плата интерфейса компьютера | | / | |/ |||||-- |||||/ / / / / / / /... /

Рисунок 2.4 Соединение между кабелем Ethernet и компьютером

Управление доступом в Ethernetе распределенное, так как, в отличие от некоторого другого сетевого оборудования, здесь нет централизованной схемы предоставления доступа. Схема доступа Ethernetа называется множественным доступом с контролем несущей и обнаружением коллизий(CSMA/CD). Она является CSMA, так как несколько машин могут получить доступ к Ethernetу одновременно, и каждая машина определяет, занят ли Е-кабель, по наличию несущей в нем. Когда интерфейс компьютера имеет пакет, который нужно передать, он слушает Е-кабель, чтобы узнать, передается ли уже чье-то сообщение(т.е. определяет наличие несущей). Когда передачи не обнаружено, интерфейс компьютера начинает передачу. Каждая передача ограничена в своей продолжительности(так как существует максимальный размер пакета). Более того, оборудование должно делать небольшие паузы между передачами пакетов, чтобы не получилось так, что сеть используется одной парой машин, и чтобы другие машины тоже имели возможность доступа к сети.

2.4.2 Обнаружение коллизий и восстановление

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

Ethernet обрабатывает коллизии оригинальным способом. Каждый трансивер следит за состоянием кабеля, когда он передает , чтобы узнать, когда другой сигнал помешал его передаче. На техническом языке такое слежение называется обнаружением коллизий и делает Ethernet сетью CSMA/CD. Когда коллизия обнаружена, интерфейс ЭВМ аварийно завершает передачу, ждет конца работы других станций и снова пытается повторить передачу. При этом нужно соблюдать осторожность, иначе сеть может оказаться перегруженной трансиверами, впустую пытающимися передавать, причем каждая передача будет приводить к коллизии. Чтобы избежать таких ситуаций, Ethernet использует стратегию двоичной экспоненциальной задержки, при которой отправитель ждет случайное время после первой коллизии, в два раза дольше, если вторая попытка передать, также привела к коллизии, в четыре раза дольше, если третья попытка привела к коллизии, и так далее. Идея, лежащая в основе экспоненциальной задержки, заключается в том, что при коллизии возможно, что большое число станций будет пытаться передавать одновременно и может возникнуть большие помехи для траффика. При таких помехах существует большая вероятность того, что две станции выберут похожие времена задержки. Поэтому вероятность того, что возникнет новая коллизия, велика. С помощью удвоения случайного времени задержки стратегия экспоненциальной задержки быстро распределяет попытки повторной передачи станций на достаточно большой промежуток времени, что делает вероятность дальнейших коллизий крайне маленькой.

2.4.3 Пропускная способность Ethernet'а

Стандартный Ethernet работает со скоростью 10 Мбит/с, что означает, что данные могут передаваться по кабелю со скоростью 10 миллионов бит в секунду. Хотя многие современные компьютеры могут генерировать данные со скоростью Ethernetа, реальную скорость сети не следует представлять как скорость, с которой два компьютера обмениваются данными. На самом деле скорость сети является мерой пропускной способности общего траффика сети. Представьте сеть в виде высокоскоростной магистрали(highway), соединяющей группу городов. Высокие скорости при движении по магистрали означают, что она может выдержать большую загрузку траффиком, а низкие скорости - что эта магистраль не может выдержать большой объем траффика. Ethernet со скоростью 10 Мбит/с, например, может выдержать несколько компьютеров, генерирующих высокоскоростной траффик или большое число компьютеров, генерирующих медленный траффик.

2.4.4 Вариации Ethernet'а

Последние достижения в технологии сделали возможным создание Ethernetа, который нуждается в электрической изоляции коаксиального кабеля. Называемая Ethernet - витая пара, эта технология позволяет обычному Ethernetу со скоростью 10 Мбит/c передаваться по паре медных проводов, во многом похожих на те, которые используются для соединения телефонов. Преимущество использования витой пары состоит в том, что она дешевле и позволяет многим группам использовать существующие кабеля вместо установки новых.

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

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

Производители рабочих станций обнаружили, что Ethernet-тонкий кабель особенно привлекателен из-за того, что они могут интегрировать Ethernet-овское оборудование в одноплатные компьютеры и смонтировать BNC-разъемы прямо в задней стенке машины. Не требуя специальных средств, BNC-разъемы делают возможным для пользователей присоединение их рабочих станций к Ethernet-у. Конечно, предоставление пользователям возможности добавлять их машины к сетям имеет свои недостатки. Это означает, что сеть будет чувствительной к разъединениям, неправильным соединениям кабелей, и другим ошибкам. Но в большинстве случаев преимущества перевешивают недостатки.

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

2.4.5 Адресация Ethernet'а

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

Чтобы позволить компьютеру определить, какие пакеты назначены ему, каждому компьютеру, соединенному с Ethernet-ом, назначено 48-битовое число, называемое Ethernet-овским адресом. Производители оборудования для Etherneta приобретают блоки адресов Ethernetа и последовательно назначают эти адреса производимым ими интерфейсам для Ethernetа(Институт Инженеров по Электротехнике и Радиотехнике(IEEE) управляет адресным пространством Ethernetа и назначает адреса по мере необходимости). Поэтому никакие два интерфейса не будут иметь одинаковый адрес Ethernetа.

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

Физические адреса связаны с интерфейса Ethernetа; установка интерфейса на новую машину или замена неисправного интерфейса изменяет его физический адрес.

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

  • физический адрес одного сетевого интерфейса;
  • широковещательный сетевой адрес;
  • групповой адрес.

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

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

2.4.6 Формат кадра Ethernet'а

Ethernet можно представлять как соединение канального уровня между машинами. Поэтому имеет смысл рассматривать передаваемые данные как кадры(фреймы)(Термин фрейм (граница) ведет свое происхождение от передачи по последовательным линиям, в которых отправитель определял границы данных, добавляя специальные символы перед и после передаваемых данных). Кадры Ethernetа имеют переменную длину в пределах от 64 октетов(октетом называется блок из 8 бит, чаще называемый байтом) до 1518 октетов (заголовок, данные, ЦКС). Как и во всех сетях с коммутацией пакетов, кадр должен идентифицироваться свое назначение. Рисунок 2.5 показывает формат кадра Ethernetа, который содержит физический адрес отправителя, а также физический адрес получателя.

Помимо идентификации отправителя и получателя, каждый кадр, передаваемый по Ethernetу, содержит преамбулу, поле типа, поле данных и циклическую контрольную сумму(CRC) или ЦКС. Преамбула состоит из 64 битовой последовательности 1 и 0 и служит для облегчения синхронизации при приеме. 32-битовая ЦКС помогает интерфейсу обнаружить ошибки передачи: отправитель вычисляет ЦКС как функцию от данных, передаваемых в кадре, а получатель заново вычисляет ЦКС для того, чтобы быть уверенным в том, что пакет принят без ошибок.

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

               адрес      адрес     тип
  преамбула получателя отправителя кадра    данные       ЦКС
  ---------------------------------------------------------------
 | 64 бита |  48 бит  |   48 бит  |16 бит|368-12000 бит| 32 бита|
  ---------------------------------------------------------------

Рисунок 2.5 Формат кадра(пакета) в том виде, в котором он передается по Ethernetу. Размеры полей не соотносятся друг с другом.

2.4.7 Мосты(bridges) и их важность

Мы уже рассматривали использование Ethernet-овских повторителей как одну из технологий расширения физического Ethernetа до нескольких физических кабельных сегментов. Хотя повторители как способ расширения были популярны много лет тому назад, многие теперь используют мосты для соединения сегментов. В отличие от повторителя, который повторяет электрические сигналы, мост повторяет пакеты. Фактически мост - это быстрый компьютер с двумя интерфейсами Ethernetа и фиксированной программой. Мост работает с обоими интерфейсами Ethernetа в режиме "без разбора", то есть интерфейсы перехватывают все корректные пакеты, появляющиеся в Ethernetах, к которым они присоединены, и предоставляют их процессору моста. Если мост соединяет два Ethernetа, Е1 и Е2, то программное обеспечение берет каждый пакет, полученный из Е1 и передает его в Е2, и наоборот.

Мосты являются более передовыми по отношению к повторителям, так как они не повторяют шум, ошибки, или испорченные кадры; должны быть получены полностью корректные кадры, чтобы они были продублированы. Более того, интерфейсы мостов следуют правилам CSMA/CD Ethernetа, поэтому коллизии и паузы при распространении в одном кабеле(сегменте) остаются изолированными от тех же явлений в других сегментах. В результате мостами может быть соединено почти любое число Ethernetов. Отметим, что мосты скрывают детали соединения: набор сегментов, связанных мостами, функционирует как один Ethernet. Компьютер может связываться с другими машинами через мосты, используя такие же аппаратные сигналы, как те, которыми он пользуется для связи в своем сегменте.

Большинство мостов не передают кадры с одного кабеля на другой: они принимают решения о том, какие кадры нужно передавать на другой сегмент, а какие нет. Такие мосты называются адаптивными, или обучающимися мостами. Адаптивный мост состоит из компьютера с двумя интерфейсами Ethernetа. Программное обеспечение адаптивного моста хранит два списка адресов, по списку для каждого интерфейса. Когда кадр приходит из Ethernetа Е1, адаптивный мост добавляет 48-битовый Ethernet-овский адрес отправителя в список, связанный с Е1. Аналогично, когда кадр приходит из Е2, мост добавляет адрес отправителя к списку, связанному с Е2. Поэтому, по прошествии некоторого времени адаптивный мост узнает, какие машины находятся в Е1, а какие в Е2.

После записи адреса отправителя кадра, адаптивный мост использует адрес получателя, чтобы определить, нужно ли передавать кадр в другой сегмент. Если список адресов показывает, что получатель находится в Ethernete, из которого прибыл кадр, то мост не передает этот кадр в другой сегмент. Если же получателя нет в списке адресов(т.е. получатель - это широковещательный или групповой адрес, или мост еще не знает местонахождение получателя), мост отправляет кадр в другой Ethernet.

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

Обобщим вышеизложенное:

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

С точки зрения TCP/IP, Ethernetы, связанные мостом, просто являются другой формой физического сетевого соединения. Важным моментом является то, что:

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

Большинство коммерческих мостов являются более сложными и более надежными, чем это следует из нашего описания. При включении питания они ищут другие мосты и приобретают информацию о топологии сети. Они используют алгоритм распределенного дерева распространения(spanning-tree) при принятии решения о том, куда передавать кадры. В частности, мосты решают, как распространять широковещательные пакеты так, чтобы по каждому кабелю передавалась только одна копия широковещательного кадра. Без такого алгоритма для Ethernetов и мостов, связанные в виде кольца, такие пакеты привели бы к катастрофическим результатам, так как пришлось бы постоянно передавать широковещательные пакеты в обе стороны.

2.5 Технология Token Ring ProNET

ProNET-10 - это имя коммерческого сетевого продукта для ЛВС, который является интересной альтернативой Ethernetу. Основанный на сетевых исследованиях в университетах, и созданный Proteon Incorporated, proNET-10 состоит из пассивной кабельной системы, которая соединяет компьютеры. Как и Ethernet, низкоскоростная версия работает со скоростью 10 Мбит/с, ограничена короткими расстояниями, и требует, чтобы присоединяемые компьютеры имели активные интерфейсы с ЭВМ.

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

Хотя передача маркера может быть использована для шинных топологий типа Ethernetа, именно кольцевые топологии, такие, как та, что используется proNET-10, делают передачу маркера особенно простой, так как физические соединения определяют последовательность, в которой передается маркер. Главным является то, что данная машина не знает, кому она передает маркер. Мы вскоре увидим, почему циркуляция маркера, основанная на физическом порядке, важна, и как она может быть использована, чтобы сделать кольцо более надежным.

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

                          ___
         ----------------|<--|--------------| | |___| | | I1 | _|_ _|_ <---|-| | I2 | A | I4 |_V_| |_|_| | | | I3 | | _____ | |---------------|-| |-|------------| |_|_|_| | | V A

Рисунок 2.6 Сеть с маркерным кольцом, в которой интерфейс I3 находится в режиме передачи, владеет маркером и посылает пакет интерфейсу I2. Другие интерфейсы находятся в режиме копирования. Отправитель всегда получает обратно посланные им биты; другие интерфейсы выделяют копию пакета для компьютера, к которому они присоединены только в том случае, когда совпадают адреса.

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

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

2.5.1 Адресация ProNET-10

В отличие от Ethernetа, оборудование интерфейса proNET-10 не имеет фиксированных адресов, назначаемых производителем. Вместо этого каждый интерфейс поставляется с набором из 8 переключателей, которые позволяют системному администратору выбрать один из 255 возможных адресов(поэтому каждая сеть proNET-10 ограничена 255 машинами). Этот адрес должен быть выбран и установлен, используя физические переключатели на плате. Он не может быть быстро изменен, как только интерфейс установлен, а также не может быть изменен программно. Тем не менее, тот факт, что адрес является устанавливаемым, имеет два важных преимущества. Во-первых, это значит, что адреса proNET-10 могут иметь много меньший размер, чем адреса Ethernetа(8 бит вместо 48 бит). В-вторых, это значит:

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

Конечно, то, что аппаратные адреса устанавливаемые, имеет и свой недостаток. В отличие от адресов Ethernetа, схема устанавливаемых адресов, используемая proNET-10, допускает конфликты адресов. Человек, устанавливающему адреса, должен быть уверен, что каждому интерфейсу в данном кольце назначен уникальный адрес от 0 до 254. Адрес из всех единиц(255) зарезервирован для широковещательного траффика. Как мы увидим позднее, при использовании proNET-10 с TCP/IP, тем, кто устанавливает адреса, следует избегать назначать компьютеру адрес ноль.

2.5.2 Формат кадра proNET-10

Рисунок 2.7 показывает формат кадра proNET-10. Длина полей указана в битах, так как сеть является биториентированной и не всегда выравнивает данные на границу байта. Оборудование сети требует, чтобы поле данных было целым числом октетов, облегчая передачу данных в память компьютера. Как и в Ethernetе, оборудование работает только с некоторыми полями в кадре; программное обеспечение работает с остальными полями и использует их. С точки зрения разработчика объединенной сети, это различие является несущественным.

  начало адрес  адрес     тип     данные     конец  четн. отказ
  сообщ. получ. отправ.  кадра    кадра      сообщ.
 ---------------------------------------------------------------
 |10 бит| 8 бит|8 бит  |24 бита|0-16352 бита|9 бит |1 бит|1 бит|
 ---------------------------------------------------------------

Рисунок 2.7 Формат кадра proNET-10. Поля не масштабированы.

Каждый кадр начинается с поля начала сообщения, за которым следует два октета адресов отправителя и получателя. Поле типа кадра состоит из 3 октетов, но только первый сейчас используется; остальные два должны быть равны 0. Вслед за данными идет поле Конец Сообщения, один бит четности и бит отказа. Сразу за концом кадра может следовать другой кадр или маркер. Заметим, что как и Ethernet, proNET-10 является самоидентифицирующимся. В отличие от Ethernetа, который использует сложную 32-битовую ЦКС для поиска ошибок передачи, proNET-10 использует только один бит четности. Чтобы понять, почему нужен только один бит, вспомним, что proNET-10 - это технология ЛВС с маленькими паузами при распространении. Поэтому, отправитель принимает копию кадра во время передачи и может просто сравнить биты в копии и передаваемые биты, чтобы обнаружить изменения. Фактически бит четности не нужен, за исключением проверки бита отказа.

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

2.5.3 Восстановление маркера proNET-10.

Так как передача маркера полагается на то, что все компьютеры передают маркер другой машине, когда закончат передачу, авария на одном узле может остановить все кольцо. Предположим, например, что сбой или электрические помехи разрушили маркер. Если в кольцо не встроен механизм восстановления, вся передача будет прекращена. Для восстановления маркера при его потере на каждой станции proNET-10 запущены два таймера. Один таймер, называемый таймером флага, сбрасывается всякий раз, когда станция обнаруживает какую-либо передачу в кольце(т.е. кадр или маркер), а другой, называемый таймером маркера, сбрасывается всякий раз, когда появляется маркер. Если какой-либо из таймеров обнулился, когда станции нужно послать пакет, станция переходит в режим восстановления и в результате генерирует новый маркер для кольца. Дело в том, что в неработающем кольце маркер циркулирует постоянно. Поэтому таймер флага обнуляется быстро(после 3 мс), если в кольце не работает ни одна машина. Таймер маркера должен допускать передачу больших пакетов другими станциями, может быть даже всеми 255 станциями., поэтому он имеет гораздо большее время обнуления(400 мс). Кольцевые технологии, которые допускают большее число станций или более длинные пакеты, используют большее время обнуления(например, proNET-80 использует 700 мс). Обычно, первая станция, которая входит в режим восстановления, подразумевает, что она владеет маркером и передает пакет. Вслед за передачей пакета она передает маркер, как будто ничего не произошло. При передаче станция следит за кольцом, чтобы проверить полноту циркуляции пакета в кольце. Если пакет прошел кольцо без ошибок, то кольцо восстановлено и все начинает работать в обычном режиме. Если вдруг получится так(хотя это и маловероятно), что две станции одновременно попытаются передавать после разрыва кольца, они обнаружат ошибку, так как передаваемые ими пакеты не вернутся им обратно. Эти две станции подождут случайное время, а затем повторят попытку. Для гарантии, что они не будут ждать одинаковое количество времени, каждая станция использует время задержки, пропорциональное ее аппаратному адресу. Поэтому, если две станции начнут одновременно передавать пакеты, то только одна добьется успеха. Алгоритм восстановления как эффективен, так и надежен. Он гарантирует, что за несколько проходов кольца одна из станций примет решение, что она владеет маркером, а все остальные станции согласятся с этим.

2.5.4 Звездообразное кольцо proNET-10

На практике в большей части установок сети proNET-10 конфигурируются в виде звездообразных колец для повышения надежности. Идея состоит в том, чтобы использовать пассивный кабельный центр как концентратор(hub) в физической звездообразной топологии , несмотря на то что сеть логически работает как кольцо. Рисунок 2.8 иллюстрирует такое соединение.

                                       реле для ЭВМ 1
    кабельный центр     -------------  /
                        | интерфейс | /
              \         | для ЭВМ 1 |/
               \        ------A-----/
                \             |    /
                 \ ===========|===/========
                   |        --V--/        |
                   |   -----|R1 |<----| | | | | | | интерфейс | | V-- | | интерфейс | | для ЭВМ 2 |<--->|R2 |          |R4 |<--->| для ЭВМ 4 |
   -------------   | -----          ----- |   -------------
                   |   |    -----     A   |
                   |   |--->|R3 |-----|   |
                   |        -----         |
                   ========================

Рисунок 2.8 Соединение трех ЭВМ через пассивный кабельный центр. Так как она не потребляет энергии, реле R3 просто передает через себя сигналы. Логически сеть является кольцом; физически - это звезда.

На этом рисунке реле R3 не потребляет энергии, так как оно подключено к ЭВМ. R3 замыкает кольцо и соединяет R2 с R4. Так как другие реле потребляют энергию, они соединяют соответствующие ЭВМ с кольцом. Поэтому электрический сигнал, посланный с ЭВМ 4 передается через реле R4 к реле R1, затем к интерфейсу ЭВМ 1 , обратно на реле R1, по реле R2 и так далее.

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


Глава 2. Обзор базовых сетевых технологий

2.6 Технология ARPANET

Одна из самых старых глобальных сетей с коммутацией пакетов, ARPANET, была создана агентством DARPA в то время, когда это агентство еще называлось ARPA. DARPA заключило контракт на разработку программного обеспечения с фирмой Bolt, Beranek and Newman из Кембриджа, штат Массачусетс в конце 1968 года. К сентябрю 1969 года уже были готовы отдельные части ARPANET. ARPANET служила испытательным полигоном для большинства из разработок в области коммутации пакетов. Помимо использования ее для сетевых исследований, исследователи из нескольких университетов, военных баз, и правительственных лабораторий регулярно использовали ARPANET для обмена файлами и электронной почтой и для обеспечения удаленного доступа к их компьютерам. В 1975 году управление этой сетью было передано от DARPA к Оборонному Коммуникационному Агентству США(DCA). DCA сделало ARPANET частью DDN, программы, в которой группы сетей выступала как часть всемирной коммуникационной системы для МО.

В 1983 МО разделило ARPANET на две связанные сети, оставив ARPANET для экспериментальных исследований и образовав MILNET для военного пользования. Функции MILNET были ограничены передачей данных категории UNCLASSIFIED. Хотя в нормальных условиях, как ARPANET, так и MILNET могли передавать траффик друг друга, управление ими было организовано так, что позволяло разъединить одну сеть от другой(Самый известный случай разъединения произошел в ноябре 1988 года, когда вирус Морриса атаковал Интернет и стал быстро размножаться). Так как ARPANET и MILNET использовали одинаковую аппаратную технологию, наше описание технических деталей применимо к обеим сетям, хотя мы в основном ссылаемся на ARPANET. Фактически эта технология является коммерчески доступной и использовалась несколькими корпорациями для создания своих частных сетей коммутации пакетов.

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

Физически ARPANET состоит из приблизительно 50 миникомпьютеров С30 и С300 корпорации BBN, называемых узлами коммутации пакетов(PSN)(PSN раньше назывались Интерфейсными Процессорами Сообщений, или IMP), разбросанных по континентальной части США и западной Европе(MILNET имеет приблизительно 160 PSN, включая 34 в Европе и 18 в Тихом Океане и на Дальнем Востоке). В каждом из мест, участвующем в работе сети, располагается один PSN, который предназначен для коммутации пакетов; он не может быть использован для других целей. На самом деле, все PSNы считаются частью ARPANET и управляются Центром Сетевых Операций(NOC), размещенным на фирме BBN в Кембридже, штат Массачусетс.

Линии данных точка-точка, арендованные у фирм, предоставляющих глобальные линии связи, соединяют вместе PSN, образуя из них сеть. Например, арендованная линия связи соединяет PSN, находящийся в университете Пурдью, с PSN в Карнеги-Меллоне и с PSN в университете Висконсина. Вначале большинство из выделенных линий в ARPANET работало со скоростью 56 Кбит/с, скоростью, которая считалась очень большой в 1968 году, но оказалась медленной по современным меркам. Напомним, что следует представлять себе скорость как меру пропускной способности, а не время, нужное для доставки пакетов. Чем больше компьютеров использовало ARPANET, тем большей делали пропускную способность, чтобы приспособиться к этой загрузке. Например, в последний год существования ARPANET многие из линий работали со скоростью свыше мегабита.

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

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

Старое оборудование порта PSN использовало сложный протокол для передачи данных по ARPANET. Известный как 1822, по номеру технического отчета, в котором он был описан, этот протокол выжил и все еще используется в портах PSN в MILNET. В общем, 1822 позволяет хосту послать пакет по ARPANET к указанному PSN и к указанному порту этого PSN. Процесс передачи является довольно сложным, так как 1822 предоставляет надежную доставку с управлением потоком. Чтобы предотвратить перегрузку сети каким-либо хостом, 1822 ограничивает число одновременно передаваемых пакетов. Чтобы гарантировать, что каждый пакет достигает получателя, 1822 заставляет отправителя ждать сигнала ГОТОВ К СЛЕДУЮЩЕМУ СООБЩЕНИЮ(RFNM) от PSN перед передачей каждого пакета. RFNM выступает здесь в качестве подтверждения. Он включает схему резервирования буферов, которая требует от отправителя резервирования буфера в PSN получателя перед посылкой пакета.

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

ARPANET не понимает содержимое пакетов, которые передаются по ней; согласование форматов и содержимого пакетов происходит между машинами, присоединенными к ARPANET, при их передаче или получении на конкретных портах PSN.

К сожалению, 1822 так и не стал промышленным стандартом. Так как лишь несколько производителей делали интерфейсные платы для 1822, стало трудно присоединять новые машины к ARPANET. Чтобы решить эту проблему, DARPA разработало новый интерфейс PSN, который использует международный стандарт передачи данных, известный как X.25(он был так назван по имени комитета по стандартизации, разработавшего его). Первая версия реализации PSN с X.25 использовала только часть передачи данных стандарта X.25(известную как HDLC/LAPB), но более поздние версии использовали весь X.25 при соединении с PSN(т.е. ARPANET стал выглядеть как сеть X.25). Многие порты MILNET теперь используют X.25.

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

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

На сегодняшний день ARPANET тихо исчез и был заменен новыми технологиями. MILNET продолжает оставаться магистральной сетью военной части объединенного Интернета. Центр Управления MILNET, находящийся возле Вашингтона, следит за траффиком 24 часа в сутки, обнаруживает поломки в оборудовании и линиях связи и координирует установку нового программного обеспечения на PSN. DARPA принимает участие в FNC для финансирования разработок и экспериментов, которые помогут в создании Национальной Исследовательской и Образовательной Сети. План создания NREN включает создание финансируемого DARPA Оборонного Исследовательского Интернета(DRI) и обещание предоставить часть из вновь созданной пропускной способности исследователям из Национального Центра Сетевых Экспериментов(testbed) - NNT.

2.6.1 Адресация ARPANET

Хотя детали адресации ARPANET и не важны, они иллюстрируют, как формируются адреса в глобальных сетях. В отличие от локальных сетей, таких как Ethernet или proNET-10, глобальные сети обычно вставляют в адрес информацию, помогающую сети эффективно пересылать пакеты к получателю. В ARPANET каждому коммутатору пакетов назначено уникальное число, P, а каждому порту ЭВМ на этом коммутаторе - число от 0 до N-1. Поэтому адрес назначения состоит из пары целых чисел, (P,N). На практике оборудование использует одно большое целое число, часть бит которого используется для представления N, а оставшиеся - для P.

2.7 Сети Национального Научного Фонда(NSF)

Понимая, что взаимодействие вскоре будет необходимой частью научных исследований, Национальный Научный Фонд создал Отдел Сетевых и Коммуникационных Исследований и Инфраструктуры, чтобы быть уверенным, что все необходимое для сетевого взаимодействия будет доступно ученым и инженерам США. Хотя этот отдел финансирует фундаментальные исследования в области сетей, его основной задачей является финансирование тех исследований, которые помогают расширять Интернет.

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

2.7.1 Старая магистральная сеть NSFNET

Из всех сетей, финансируемых NSF, магистральная сеть NSFNET имеет самую интересную историю и использует самую интересную технологию. Эта магистральная сеть в процессе своего развития прошла через три этапа; она увеличивалась в размерах и пропускной способности в то время, когда ARPANET приходила в упадок, пока наконец не стала доминирующей магистральной сетью Интернета. Первая версия ее была создана быстро, как временное решение. Одной из главных причин создания этой магистральной сети явилась необходимость обеспечения доступа ученым к суперкомпьютерам NSF. В результате первая сеть состояла из шести микрокомпьютеров LSI-11 фирмы DEC(их аналогами являются советские машины серии Электроника-60 и -85), размещенные в существующих суперкомпьютерных центрах NSF. Географически эта сеть занимала континентальную часть США от Принстона, штат Нью-Джерси, до Сан-Диего, штат Калифорния, и использовала выделенные линии со скоростью 56 Кбит/с.

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

Основное место соединения между первоначальной магистральной сетью NSF и оставшейся частью Интернета находилось в университете Карнеги-Меллона, где имелся как узел сети NSFNET, так и PSN ARPANET. Когда пользователь, присоединенный к NSFNETу, посылал траффик в какое-либо место ARPANETа, его пакеты передавались по NSFNET в университет Карнеги-Меллона(CMU), где "летящий мячик" направлял их в ARPANET через местный Ethernet. Аналогично "летящий мячик" понимал, что пакеты, имеющие получателя в NSFNET, нужно принимать из Ethernetа и посылать по магистральной сети NSF в соответствующее место.

2.7.2 Вторая магистральная сеть NSFNET в 1988-1989 годах

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

В 1987 году NSF объявил, что ждет предложений от групп, которые хотели бы создать новую, более скоростную магистральную сеть. Предложения появились в августе 1987 и были оценены в конце этого года. 24 ноября 1987 года NSF заявил, что он выбрал предложение, представленное группой, в состав которой вошли MERIT Inc., компьютерная сеть штата, работающая в университете Мичигана в Ann Arbor, корпорация IBM, и MCI Incorporated. Эти партнеры предложили создать вторую магистральную сеть , разместить центр управления сетью в Ann Arbor и ввести эту сеть в строй к следующему лету. Так как NSF финансировал создание нескольких новых сетей среднего уровня, планировалось, что новая магистральная сеть будет обслуживать большее число узлов , чем старая. Каждая дополнительный узел должен был обеспечивать соединение между новой магистральной сетью и одной из сетей среднего уровня NSF.

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

К середине лета 1988 года оборудование было установлено и NSFNET начал использовать вторую магистральную сеть. Вскоре после этого первая магистральная сеть прекратила свою работу и была отсоединена.

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

Вместо использования "летящих мячиков" или коммерческих маршрутизаторов новая магистральная сеть использовала специальные маршрутизаторы, созданные на основе нескольких обычных компьютеров, помещенных в одну большую комнату и соединенных между собой так, как показано на рисунке 2.11. То, что получилось, было названо узловой коммутационной системой(NSS). Функции NSS были аналогичны тому, что делал обычный маршрутизатор.

       Узловая коммутационная система
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 |                                                             |
 |                                                             |
 |                           -------                           |
 |                           | RCP |                           |
 | соединение с              -------                           |
 | локальной сетью узла       |                                |
 |     -------     ___________|_________________       ------- |
 |<----|E-PSP|-----| межпроцессорное |-------| AP | | | | взаимодействие | | | |___________________________|------ | | | | | | | | | |PSP 1| |PSP 2| |PSP n| | | | | | | | | |- | |- | | | выделенные каналы связи к другим узлам

Рисунок 2.11 Узловая Коммутационная Система(NSS), состоящая из нескольких процессоров, соединенных механизмом межпроцессорного взаимодействия.

Как показывает рисунок 2.11, NSS состоит из центрального механизма межпроцессорного взаимодействия и трех типов процессоров: Процессоров Коммутации Пакетов(PSP), Процессора Управления и Маршрутизации(RCP), и Процессора Приложений(AP). В первой реализации центральный механизм межпроцессорного взаимодействия был обычной локальной сетью(сетью IBM Token Ring), а процессорами были IBM RT-PC.

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

Хотя NSS и имела возможность параллельной работы, самым важным была эффективность. Первоначальные выделенные линии работали со скоростью 448 Кбит/с, но конечной целью была работа Процессоров Коммутации Пакетов с линиями, работающими со скоростями от DS-1(1.544 Мбит/с) до DS-3(45 Мбит/с). При таких скоростях процессор имел лишь небольшой промежуток времени для выполнения вычислений над одним пакетом. Поэтому, чтобы эффективно принимать решения о маршруте пакета, PSP использовал обращение к таблице, аналогичное тому, которое описано в более поздних главах этой книги. Чтобы еще больше снизить вычислительную нагрузку, каждый NSS содержал дополнительные Процессоры Маршрутизации и Управления, которые использовались для вычисления новых таблиц маршрутизации, а также других управляющих функций NSS. Процессоры приложений выполняют другие задачи, такие как слежение за работой сети.

2.7.3 Магистральная сеть NSFNET в 1989-1990 годах

После проведения измерений траффика во второй магистральной сети NSFNET в течение года, управляющий центр переконфигурировал сеть, добавил некоторые каналы и удалив другие. Помимо этого, он увеличил скорость каналов до DS-1(1.544 Мбит/с).

2.7.4 Мультиплексирование и программируемые соединения

В то время как точная топология NSFNET несущественна, технология, используемая ею, представляет большой интерес. Как часть своего проекта, MERIT, IBM и MCI обещали исследовать новые способы как сделать сеть переконфигурируемой. Предлагаемый ими план является более интересным, чем другие сетевые планы, так как он предполагал участие в его реализации MCI, производителя, который предоставлял средства связи на большие расстояния.

Чтобы понять возможности реконфигурации, рассмотрим, что обычно происходит, когда заказчик обращается к производителю средств дальней связи, чтобы тот выделил ему цифровой канал связи. Хотя заказчик может думать, что провод соединяет напрямую нужные ему два места, производитель выбирает путь для этого канала, который использовал бы уже имеющиеся кабели. Например, производитель может соединить заказчика через локальную станцию, оттуда через ближайший большой город, где производитель имеет магистральные линии связи, по магистральным линиям до другого большого города вблизи получателя, и наконец через локальную станцию с нужным ему местом. Более того, при современной технологии производитель предоставляет отдельный физический канал. На самом деле электронное оборудование на одном конце магистрального оптоволоконного кабеля мультиплексирует (объединяет) несколько каналов в этом оптоволоконном кабеле, а оборудование на другом конце демультиплексирует (разделяет) их, делая возможным для производителя добавление или переконфигурацию каналов с помощью электронной аппаратуры. Поэтому каналы магистральной сети NSFNET мультиплексировались в уже имеющемся оптоволоконном кабеле, принадлежащем MCI.

Предложение MERIT/IBM/MCI привело к возникновению интересного вопроса: "Если бы пользователи имели возможность переконфигурировать каналы с помощью электронной аппаратуры, то как бы они улучшили при этом работу сети?" Одним из путей является следующий. Владелец сети может следить за сетевым траффиком в течение долгого времени, а затем переконфигурировать каналы, чтобы обеспечить прямой путь между парами узлов, генерирующих наибольший траффик. Помимо добавления каналов, которые нужны, динамическая реконфигурация может позволить пользователю сэкономить деньги, освободив его платы за прямые пути между парами узлов с маленьким траффиком. Конечно, нельзя переконфигурировать базовые каналы, не перевычислив путей для коммутации пакетов.

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

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

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

  Пропускная способность Т, выделенная в физической сети
  -------------------------------------------------------------
           ---------------------------------------
          |   ---------------    --------------   |
          |  |               |  |              |  |
  ------  |  |  -----------  |  |  ----------  |  |  ----------
        | |  | |           | |  | |          | |  | |
        | |  | |           | |  | |          | |  | |
        | |  | |           | |  | |          | |  | |
      ============       ============      ============
      |  Узел 1  |       |  Узел 2  |      |  Узел 3  |
      |          |       |          |      |          |
      |          |       |          |      |          |
      ============       ============      ============
          |  |               |  |              |  |
          C  A               A  B              B  C

Рисунок 2.14 Три канала(A, B и C), которые могут быть переконфигурированы, пока они используют пропускную способность, меньшую чем Т, в любой точке магистральной сети. Например, каждый канал может иметь пропускную способность Т/2 или, если A и B имеют пропускные способности Т/3, то C может иметь - 2*Т/3.

2.7.5 Сети среднего уровня NSFNET

NSF финансировал большое число сетей среднего уровня, которые были расположены почти в каждом штате. Типичная сеть среднего уровня включает от 10 до 30 университетов и корпораций, находящихся в данной географической области. Первоначальной целью NSF было покрыть издержки, а затем поддерживать самодостаточность, позволив каждой сети среднего уровня работать в условиях финансовой и административной автономии. Хотя некоторые сети среднего уровня добились финансовой независимости, другие обнаружили, что это довольно трудно сделать. Управляющие сетей среднего уровня образовали Федерацию Академических Исследовательских сетей(FARNET) для координации технических работ и лоббировать дополнительную правительственную поддержку.

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

2.7.6 Сети доступа NSFNET

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

2.7.7 Сети университетских городков NSFNET

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

2.8 Другие технологии, над которыми использовался TCP/IP

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

Большая часть успеха протоколов TCP/IP объясняется их способностью согласования почти с любой из базовых коммуникационных технологий.

2.8.1 X25NET

CSNET(CSNET и BITNET слились; новая организация - CREN), организация образованная в 1980 для поддержки Интернета в промышленных и малых школах, использовала технологию X25NET для соединения некоторых пользователей с Интернетом. Первоначально разработанная в университете Пурдью, X25NET позволяла протоколам Интернета работать в Общественных Сетях Данных(PDN). Такой подход должен был позволить организациям, для которых было неприемлемо прямое соединение с ARPANET, заказывать сетевое соединение у фирмы-поставщика средств дальней связи(например, AT&T) и использовать его для передачи траффика Интернета.

Читатели, которые знают об общественных сетях с коммутацией пакетов, могут найти X25NET странной, так как такие сети используют только протоколы МККТТ Х.25, в то время как Интернет использует протоколы TCP/IP. Тем не менее, когда она используется для транспортировки траффика TCP/IP, сеть Х.25 просто обеспечивает путь, по которому может быть передан траффик Интернета. Мы уже установили, что многие базовые технологии могут использоваться для передачи траффика Интернета. Эта технология, иногда называемая туннельная передача(tunneling), просто означает, что сложная сеть со своими собственными протоколами рассматривается как еще одна аппаратная система доставки пакетов. Чтобы послать траффик TCP/IP по туннелю Х.25, надо установить соединение Х.25, а затем послать пакеты TCP/IP, как будто это данные. Система Х.25 передаст пакеты по соединению и доставит их в другую точку Х.25, где они должны быть собраны и отправлены к своему истинному назначению. Так как туннелирование рассматривает пакеты как данные, оно не обеспечивает самоидентифицирующиеся кадры. Поэтому, оно работает только в том случае, когда оба конца соединения Х.25 заранее договорились о том, что они будут передавать пакеты Х.25.

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

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

Схема адресации, используемая сетями Х.25, определена в стандарте, известном как Х.121. Каждый из физических адресов Х.121 является числом из 14 цифр, в котором 10 цифр назначаются производителем, который обеспечивает средство сети Х.25. Напоминая телефонные номера, одна из популярных схем назначения номеров производителями включает код области, основанный на географическом положении. Такой подход не удивителен, так как он был предложен организацией, определяющей международные телефонные стандарты. К сожалению, эта схема неудобна, так как затрудняет назначение Интернетовских адресов. Пользователи, использующие X25NET, должны хранить таблицу отображения Интернетовского адреса в адрес Х.25 и обратно. Глава 6 рассматривает проблему отображения адресов более детально и дает альтернативу использованию фиксированных таблиц.

Так как общественные сети Х.25 работают независимо от Интернета, должно существовать место соединения между ними. Как DARPA, так и CSNET используют специально выделенные машины для обеспечения соединения между Х.25 и ARPANET. Основное соединение известно как VAN-шлюз. Этот шлюз поддерживает соединения Х.25 и маршрутизирует приходящий траффик Интернета к его получателям. X25NET является важной, так как она иллюстрирует гибкость и адаптируемость протоколов TCP/IP. В частности, она показывает, как туннельная передача делает возможным использование очень широкого диапазона сложных сетевых технологий в межсетевой среде.

2.8.2 Cypress

Большинство сетевых технологий, которые мы рассмотрели, достаточно дороги. Но в число тех, кому нужен доступ к Интернету, входят не только большие институты, напрямую соединенные с главными магистральными сетями, такими как NSFNET; доступ к нему нужен также маленьким школам и просто отдельным людям. Маленькие институты не могут позволить себе высокоскоростные выделенные линии, или оборудование, соединяющее с ними. Cypress предназначен для удовлетворения потребности в доступе с помощью дешевой низкоскоростной технологии TCP/IP.

Cypress состоит из миникомпьютеров, соединенных низко- или среднескоростными выделенными линиями(от 9.6 Кбит/с до 56 Кбит/с). Каждый миникомпьютер размещается в пользовательском узле, где он соединен с локальной вычислительной средой с помощью ЛВС Ethernet. С остальной частью Cypress он соединяется по выделенным последовательным линиям. Как минимум один узел в сети Cypress соединен с Интернетом и передает траффик между сетью Cypress и остальной частью Интернета.

Первоначально Cypress разрабатывался для топологии типа "виноградная кисть", в которой каждый новый узел соединялся последовательной линией с ближайшим к нему узлом. Преимуществом использования такой топологии была ее дешевизна; недостатком была большая величина паузы при передаче, становящаяся значительной для траффика, который передавался через несколько промежуточных машин. Топология Cypress была изменена по двум причинам:во-первых, NSFNET значительно увеличил число потенциальных точек соединения с Интернетом, и во-вторых, большинству пользователей показалось, что лучше платить больше, но иметь меньшие паузы при передаче. Поэтому сеть Cypress приняла вид одного концентратора, размещенного в университете Пурдью, который был соединен с NSFNET.

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

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

2.8.3 Коммутируемый(dial-up) IP

Другой интересный способ использования TCP/IP, освоенный CSNET, включает работу протоколов TCP/IP в коммутируемой телефонной сети. Узлы CSNET, использующие Интернет редко, могут быть не в состоянии платить за выделенные линии. Для этих узлов CSNET разработал систему коммутируемого IP, которая работает следующим образом: всякий раз, когда нужно соединение, программное обеспечение в узле пользователя использует модем для создания соединения с концентратором(hub) CSNET через телефонную сеть. Компьютер в концентраторе отвечает на телефонный вызов и, после получения подтверждения подлинности пользователя, передает траффик между этим узлом и другими компьютерами Интернета.

2.8.4 Пакетное радио

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

2.9 Итоги и выводы

Мы рассмотрели несколько технологий работы сетевого оборудования, используемых протоколами TCP/IP, которые лежат в диапазоне от высокоскоростных ЛВС, таких как Ethernet и proNET-10, до более медленных глобальных сетей, таких как ARPANET и Cypress. Мы также увидели, что протоколы TCP/IP могут работать над другими протоколами сетей общего пользования, используя технологию, названную туннельной передачей. В то время как детали конкретных сетевых технологий не важны, общая идея заключается в следующем:

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

Для дальнейшего изучения

  • Ранние компьютерные системы связи использовали соединение точка-точка, часто применяя оборудование общего пользования для передачи по последовательным линиям, которое описывает McNamara[1982]. Metcalf и Boggs[1976] вводят понятие о прототипе Ethernetа, работающем со скоростью 3 Мбит/с. Digital[1980] описывает стандарт 10 Мбит/с, принятый многими производителями, а стандарт IEEE 802.3 описан у Nelson[1983]. Shoch, Dalal и Redell[1982] дают историческую перспективу эволюции Ethernetа. Аналогичная работа по сети ALOHA есть у Abramson[1970], а обзор технологий дан Cotton[1979].
  • Технология передачи маркера по кольцу была предложена Farmer и Newhall[1969]. Miller Thompson[1982], а также Andrews и Shultz[1982], дают современные обзоры. Другая альтернатива, сети со слотовым кольцом, была предложена Pierce[1972]. Для сравнения технологий читайте Rosenthal[1982].
  • Детали проекта второй магистральной сети NSFNET можно найти в MERIT[November 1987]. Comer, Narten и Yavatkar[1987] впервые предложили использовать технологию создания мультипроцессорного маршрутизатора на основе шины локальной сети; это было сделано независимо от проекта второй магистральной сети NSFNET.
  • Для большей информации об ARPANET смотрите Cerf[1989] и BBN[1981]. Идеи, лежащие в основе X25NET, обобщены в Comer и Korb[1983], а Cypress описана в Comer, Narten и Yavatkar[April 1987]. Lanzillo и Partridge[January 1989] описывают коммутируемый IP.
  • Quaterman и Hoskins[1986] дают обзор основных глобальных компьютерных сетей; Quaterman[1990] содержит их обновленный список и дает более детальное описание. LaQuey[1990] содержит список адресов пользователей компьютерных сетей.

Упражнения

2.1 Установите, какие сетевые технологии использует ваш узел.

2.2 Каков максимальный размер пакета, который может быть послан по высокоскоростной сети, такой как HyperChannel NSC или UltraNet Ultra Network Technologies?

2.3 В чем заключаются преимущества и недостатки туннельной передачи?

2.4 Прочитайте стандарт Ethernetа, чтобы найти точную информацию о паузе(gap) между пакетами и размере преамбулы.

2.5 Какая характеристика спутникового коммуникационного канала является наиболее желательной ? А наименее желательной ?

2.6 Установите нижнюю границу времени, которое занимает передача 5 мегабайтного файла по сети, которая работает со скоростями: 9600 бит/с, 56 Кбит/с, 10 Мбит/с, 100 Мбит/c и 2 Гбит/с.


Глава 3. Понятие межсетевого обмена и архитектурная модель

  • 3.1 Введение
  • 3.2 Взаимодействие на прикладном уровне
  • 3.3 Взаимодействие на сетевом уровне
  • 3.4 Свойства объединенной сети(интернета)
  • 3.5 Архитектура Интернета
  • 3.6 Соединение через IP-шлюзы(маршрутизаторы)
  • 3.7 Взгляд пользователя
  • 3.8 Все сети равны
  • 3.9 Вопросы, которые остались без ответ
  • 3.10 Итоги
  • Для дальнейшего изучения
  • Упражнения

3.1 Введение

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

3.2 Взаимодействие на прикладном уровне

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

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

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

3.3 Взаимодействие на сетевом уровне

Альтернативой обеспечению взаимодействия прикладными программами являются системы, основанные на соединении сетевого уровня. Соединение на сетевом уровне обеспечивает механизм, который доставляет пакеты от их настоящего отправителя к настоящему получателю в реальном масштабе времени. Коммутация для передачи маленьких блоков, а не файлов или больших сообщений имеет ряд преимуществ. Во-первых, она напрямую отображается в базовое сетевое оборудование, что делает ее очень эффективным. Во-вторых, она разделяет процессы передачи данных от прикладных программ, позволяя машинам обрабатывать сетевой траффик, не зная какие приложения передают его. В-третьих, она делает систему гибкой, делая возможным создание сетевых протоколов общего назначения. В-четвертых, она позволяет администраторам сетей добавлять новые сетевые технологии, модифицируя программное обеспечение сетевого уровня или добавляя к нему новую часть и не внося при этом никаких изменений в прикладные программы. Ключевым понятием при разработке универсального взаимодействия сетевого уровня является понятие абстрактной коммуникационной системы, известное как межсетевой обмен(internetworking). Понятие объединенной сети(internetwork или internet) является очень мощным. Оно отделяет понятие взаимодействия от деталей сетевых технологий и скрывает низкоуровневые детали от пользователя. Более того, оно определяет все проектные решения при разработке программного обеспечения и объясняет, как работать с физическими адресами и маршрутами. После перечисления основных причин организации межсетевого обмена мы рассмотрим свойства объединенной сети более детально. Напомним, что мы начали с двух фундаментальных замечаний о разработке коммуникационных систем:

  • одна сеть не может обслужить всех пользователей
  • пользователи хотят универсального взаимодействия

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

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

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

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

3.4 Свойства объединенной сети(интернета)

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

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

3.5 Архитектура Интернета

Мы уже видели, как машины присоединяются к отдельным сетям. Возникает вопрос: "Как соединяются сети между собой для создания объединенной сети ?" Ответ состоит из двух частей. Физически две сети могут соединяться только с помощью компьютера, присоединенного к каждой из них. Физическое соединение, тем не менее, не обеспечивает подразумевавшееся нами взаимодействие, так как такое соединение не гарантирует, что компьютер сможет взаимодействовать с другими машинами, с которыми он хотел бы это сделать. Чтобы иметь надежный интернет, нам нужно, чтобы компьютеры были согласны передавать пакеты из одной сети в другую. Компьютеры, соединяющие две сети и передающие пакеты из одной в другую, называются межсетевыми шлюзами(gateway) или межсетевыми маршрутизаторами(router).

Рассмотрим пример, состоящий из двух физических сетей, показанный на рисунке 3.1. На этом рисунке машина G присоединена как к сети 1, так и к сети 2. Чтобы G работал как шлюз, он должен принимать пакеты из сети 1, предназначенные машинам в сети 2 и передавать их туда. Аналогично, G должен принимать пакеты из сети 2, которые предназначены машинам в сети 1 и передавать их туда.

    ----------------                     ----------------
    |              |        -----        |              |
    |   Сеть 1     |--------| G |--------|  Сеть 2      |
    |              |        -----        |              |
    ----------------                     ----------------

Рисунок 3.1 Две сети, соединенные шлюзом G.

3.6 Соединение через IP-шлюзы(маршрутизаторы)

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

       ----------        ----------        ----------
       |        | ------ |        | ------ |        |
       | Сеть 1 |-| G1 |-| Сеть 2 |-| G2 |-| Сеть 3 |
       |        | ------ |        | ------ |        |
       ----------        ----------        ----------

Рисунок 3.2 Три сети, соединенные между собой двумя шлюзами

В этом примере шлюз G1 должен перемещать из сети 1 в сеть 2 все пакеты, предназначенные для машин либо в сети 2, либо в сети 3. По мере того, как размер интернета увеличивается, задача шлюза по принятию решений о том, куда посылать пакеты, становится более сложной.

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

В интернете TCP/IP компьютеры, называемые шлюзами, обеспечивают все соединения между физическими сетями.

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

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

3.7 Взгляд пользователя

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

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

Как показывает рисунок 3.3б, шлюзы не обеспечивают прямое соединение между всеми парами сетей. Траффику, передающемуся от одной машины к другой, может понадобиться пройти через несколько промежуточных сетей. Поэтому, сети, участвующие в интернете, являются аналогами высокоскоростных магистралей(highway) в США: каждая сеть согласна передавать транзитный траффик в обмен на право посылать траффик через весь интернет. Типичные пользователи даже не ощущают, что по их локальной сети проходит дополнительный траффик.

3.8 Все сети равны

В главе 2 был сделан обзор сетевого оборудования, используемого для построения интернетов TCP/IP и проиллюстрировала большое разнообразие технологий. Мы описали интернет как набор взаимодействующих, взаимосвязанных сетей. На данный момент важно уяснить фундаментальное понятие: с точки зрения интернете, любая коммуникационная система, способная передавать пакеты, считается одной сетью, независимо от ее задержек при передаче, пропускной способности, максимального размера пакета или географических размеров. В частности, рисунок 3.3б использует прямоугольник одинаковых размеров для обозначения всех физических сетей, так как TCP/IP считает их равными, несмотря на их разницу. Итак,

Межсетевые протоколы TCP/IP считают все сети равными. Локальная сеть, такая как Ethernet, глобальная сеть, такая как магистральная сеть NSFNET, или соединение точка-точка между двумя машинами - каждый из них считается сетью.

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

                            ---         ---
                            |Э|--     --|Э|
                            ---  |    | ---
                               /---------\    ---
                          --- | интернет |----|Э|
                          |Э|-|          |    ---
                          ---  \         |
                                \        /
                               | \------/\ ---
                              ---         -|Э|
                              |Э|          ---
                              --\          /
                                 ---ЭВМ----
                                   (а)
                 ---         ---     -----интернет
                 |Э|--     --|Э|     |
                 ---  |    | ---     V              ---
                    /-------------------------\ / --|Э|
                   |  |    |-----|            |/    ---
                   | ++++  __  ++++           /
                   | +  +--||--+  +----------/ \
                  /  ++++  --  ++++ физическая  \
                 |   -- |       |    сеть        |
                 |   ||-|       |     |          |
                 |   --         |     V          |    ---
             --- |    |    --   |    ++++    /---|----|Э|
             |Э|-|---++++--||---|    +  +---/    |    ---
             ---  \  +  +  --        ++++        /
                   | ++++             |         /
                   |   |              |         |
                   |   --     ++++   --         |
                   \   ||-----+  +---||<-шлюз / \ ++++ / | \----------------------/ |Э| |Э| \ / ЭВМ----------- (б)

Рисунок 3.3 (а) Пользовательское представление об интернете TCP/IP, при котором кажется, что каждый компьютер присоединен к одной большой сети, и (б) структура физических сетей и шлюзов, обеспечивающая соединение

3.9 Вопросы, которые остались без ответа

Наш краткий обзор интернетов оставил много вопросов без ответов. Например, вас может интересовать точная форма машинных адресов в интернете или то, как такие адреса соотносятся с физическими аппаратными адресами Ethernetа, proNET-10 или ARPANETа, описанными в главе 2. Следующие три главы ответят на эти вопросы. Они опишут формат адресов IP и проиллюстрируют, как ГВМ осуществляют отображение интернетовских адресов в физические и наоборот. Вы также можете захотеть узнать точно, как выглядит пакет при передаче его через интернет, или что происходит, когда на некоторые ГВМ или шлюзы пакеты прибывают быстрее, чем их можно обработать. Глава 7 ответит на эти вопросы. Наконец, вас может заинтересовать, как несколько прикладных программ, выполняющихся параллельно на одной машине, могут посылать и принимать пакеты из несколько мест сразу, не запутавшись при этом, или как интернетовские шлюзы получают информацию о путях. На все эти вопросы также будут даны ответы.

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

3.10 Итоги

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

Для дальнейшего изучения

Наша модель объединенной сети взята из Cerf и Comer[1983] и Cerf и Kahn[1974], которые описывают интернет как набор сетей, объединенных шлюзами и кратко рассматривают межсетевой протокол, похожий на тот, который был впоследствии разработан для связки протоколов TCP/IP.

Более подробная информация об архитектуре объединенного Интернета может быть найдена в Postel[1980]; Postel, Sunshine и Chen[1981]; и в Hinden, Haverty и Sheltzer[1983]. Shoch[1978] рассматривает вопросы межсетевых имен и адресов. Boggs et. al. [1980] описывает интернет, разработанный в XEROX PARC, альтернативу интернету TCP/IP, который мы рассматриваем. Cheriton[1983] описывает межсетевой обмен в связи V-системой.

Упражнения

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

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

3.3 Сравните организацию интернета TCP/IP с интернетом, разработанным Xerox Corporation.

3.4 Какие процессоры использовались в шлюзах объединенного Интернета? Удивлены ли вы размерами и скоростью работы шлюзов? Почему?


Глава 4. Адреса Интернета

  • 4.1 Введение
  • 4.2 Универсальные идентификаторы
  • 4.3 Три основных класса IP-адресов
  • 4.4 Адреса описывают сетевые соединения
  • 4.5 Сетевые и широковещательные адреса
  • 4.6 Ограниченное широковещание
  • 4.7 Интерпретация нуля как символа "это"
  • 4.7.1 Групповая адресация
  • 4.8 Недостатки адресации Интернета
  • 4.9 Точечная(dotted) десятичная нотация
  • 4.10 Адрес обратной связи(loopback)
  • 4.11 Список соглашений о специальных адресах
  • 4.12 Ответственность за адресацию в Интернете
  • 4.13 Пример
  • 4.14 Порядок байт в сети
  • 4.15 Итоги
  • Для дальнейшего изучения
  • Упражнения

4.1 Введение

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

4.2 Универсальные идентификаторы

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

Часто идентификаторы ГВМ классифицируются как имена, адреса, или маршруты. Shoch[1978] предложил, чтобы имя идентифицировало, что такое объект, адреса идентифицировал, где он находится, а маршрут(путь) определял, как до него добраться. Хотя эти определения являются интуитивно ясными, они могут ввести в заблуждение. На самом деле имена, адреса и маршруты определяются на разных уровнях представления идентификаторов ГВМ, причем имена на самом верхнем, а маршруты - на самом нижнем. Вообще люди обычно предпочитают произносимые имена для идентификации машин, в то время как программное обеспечение лучше работает с более компактным представлением идентификаторов, которые мы считаем адресами. Все, что угодно могло бы быть выбрано в качестве универсальных идентификаторов ГВМ в TCP/IP. Но было принято решение стандартизовать компактные, двоичные адреса, которые делают вычисления, такие как выбор маршрута, эффективными. Теперь мы перейдем к рассмотрению только двоичных адресов, оставив на потом вопросы о том, как производится отображение между двоичными адресами и произносимыми именами, и о том, как использовать адреса для маршрутизации.

4.3 Три основных класса IP-адресов

Думайте об интернете как о большой сети, такой же ,как и любая другая физическая сеть. Разница заключается в том, что интернет - это виртуальная структура, придуманная его разработчиками, и реализованная полностью в программном обеспечении. Поэтому, разработчики могут определить по своему усмотрению форматы и размеры пакетов,адреса, технологии доставки и т.д.; аппаратное обеспечение не определяет ничего. Для адресов разработчики TCP/IP выбрали схему, аналогичную адресации в физических сетях, в которой каждой ГВМ в интернете назначается адрес в виде целого числа, называемый межсетевым адресом или IP-адресом. Самым умным в межсетевой адресации является то, что целые числа для адресов тщательно выбираются, чтобы сделать маршрутизацию эффективной. Если говорить более конкретно, IP-адрес кодирует идентификацию сети, к которой присоединена ГВМ, а также идентификацию уникальной ГВМ в этой сети. Можно сделать вывод:

Каждой ГВМ в интернете TCP/IP назначен уникальный 32-битовый межсетевой адрес, который используется при взаимодействии с этой ГВМ.

Детали IP-адресов помогут уточнить абстрактные идеи. А пока мы дадим упрощенное представление, которое будет впоследствии усложнено. В простейшем случае каждой ГВМ, присоединенной к интернету, назначается 32-битовый универсальный идентификатор в качестве его межсетевого адреса. IP-адреса для всех ГВМ данной сети имеют одинаковый префикс.

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

         0 1    7 8                                     31
        ---------------------------------------------------
Класс А |0|идсет |               идГВМ                   |
        ---------------------------------------------------
         0 1 2        15 16                             31
        ---------------------------------------------------
Класс В |1|0| идсет     |        идГВМ                   |
        ---------------------------------------------------
         0 1 2 3                  23 24                 31
        ---------------------------------------------------
Класс С |1|1|0| идсет               |     идГВМ          |
        ---------------------------------------------------
         0 1 2 3 4                                      31
        ---------------------------------------------------
Класс D |1|1|1|0|         групповой адрес                |
        ---------------------------------------------------
         0 1 2 3 4 5                                    31
        ---------------------------------------------------
Класс Е |1|1|1|1|0| зарезервировано на будущее           |
        ---------------------------------------------------

Рисунок 4.1 Пять форм адресов Интернета(IP). Три основные формы, классы А,В и С можно различить по первым двум битам.

Класс данного IP-адреса можно определить по первым трем старшим битам, причем первых двух бит достаточно для определения принадлежности адреса к одному из трех основных классов. Адреса класса А, которые используются для сетей, имеющих в своем составе более чем 2**16(т.е. 65536) ГВМ , выделяют под идсет 7 бит, а под идГВМ 24 бита. Адреса класса В, которые используются для сетей промежуточного размера, включающих от 2**8(т.е. 256) до 2**16 ГВМ, выделяют 14 бит под идсет, а 16 бит под идГВМ. И наконец, сети класса С, состоящие менее чем из 256 ГВМ, выделяют 21 бит под идсет и только 8 бит под идГВМ. Заметим, что IP-адрес был определен таким образом, что можно быстро расширить идГВМ или идсет. Шлюзы используют для маршрутизации поле идсет и полагаются на его эффективное выделение.

4.4 Адреса описывают сетевые соединения

Для простоты изложения предмета мы говорили, что межсетевой адрес идентифицирует ГВМ, но это не совсем так. Представим себе шлюз. присоединенный к двум физическим сетям. Как мы можем назначить ему один IP-адрес, если адрес кодирует как идентификатор сети, так и идентификатор ГВМ ? Мы не можем это сделать. Когда обычные компьютеры имеют два или более физических соединений, они называются многоадресными(multi-homed) ГВМ. Многоадресные ГВМ и шлюзы требуют нескольких адресов IP. Каждый адрес соответствует одному из соединений этой машины с сетью. Учет многоадресных ГВМ приводит нас к следующему важному выводу:

Так как IP-адреса кодируют как сеть, так и ГВМ в этой сети, они не описывают конкретную машину, а только соединение ее с сетью.

Поэтому шлюз, соединяющий N сетей, имеет N различных IP адресов, по одному на каждое сетевое соединение.

4.5 Сетевые и широковещательные адреса

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

Межсетевые адреса могут использоваться для указания как на сети, так и на отдельные ГВМ. По соглашению адрес сети имеет поле идГВМ, равное 0.

Другим важным преимуществом межсетевой схемы адресации является то, что она включает широковещательный адрес, который используется для ссылки на все ГВМ в данной сети. Согласно стандарту, любой идГВМ, состоящий из всех единиц, зарезервирован для широковещания(К сожалению, в ранней версии кода TCP/IP, входившего в состав BSD UNIX, все нули некорректно использовались для широковещания, и хотя впоследствии код BSD был исправлен, ошибка осталась в некоторых коммерческих системах, созданных на основе этого кода). Во многих сетевых технологиях(например, Ethernetе) широковещание может быть таким же эффективным, как обычная передача; в других(например, Cypress) широковещание поддерживается сетевым программным обеспечением, но требует значительно больше времени, чем простая передача. Некоторые сети не поддерживают широковещание вообще. Поэтому, широковещательный IP-адрес не гарантирует наличия или эффективности широковещательной доставки пакетов. Подводя итоги, можно сказать, что:

IP-адреса могут использоваться для указания широковещания и отображения его в аппаратное широковещание, если это возможно. По соглашению, широковещательный адрес имеет поле идГВМ со всеми битами, равными 1.

4.6 Ограниченное широковещание

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

С точки зрения адресации, главным недостатком направленного широковещания является то, что оно требует знаний об адресе сети. Другая форма широковещательного адреса, называемая ограниченный широковещательный адрес или локальный сетевой широковещательный адрес, обеспечивает широковещательный адрес для локальной сети(сети отправителя), независимо от назначенного ей IP-адреса. Локальный широковещательный адрес состоит из 32 единиц(поэтому он иногда называется широковещательным адресом из всех единиц). ГВМ может использовать ограниченный широковещательный адрес в процессе своего запуска, до того, как он узнает свой IP-адрес или IP-адрес локальной сети. Как только ГВМ узнает IP-адрес своей сети, он может использовать направленное широковещание. Как правило, протоколы TCP/IP ограничивают широковещание до наименьшего возможного набора машин. Мы увидим, как это правило влияет на группы сетей, разделяющих адреса, в главе 6, когда будем рассматривать адресацию подсетей.

4.7 Интерпретация нуля как символа "это"

Мы видели, что поле, состоящее из единиц, может интерпретироваться как "все", как "все ГВМ" в сети. Вообще межсетевое программное обеспечение интерпретирует поля, состоящие из нулей, как символ "это". Такая интерпретация встречается повсеместно в литературе. Поэтому IP-адрес с идГВМ, равным 0, обозначает "этот ГВМ", а межсетевой адрес с идентификатором сети 0 обозначает "эта сеть". Конечно, использовать эти адреса нужно только в том контексте, в котором они интерпретируются однозначно. Например, если машина получила пакет, в котором адрес отправителя имеет поле идсет, установленное в 0, а идГВМ соответствует собственному, получатель делает вывод о том, что поле идсет означает эту сеть(т.е. сеть, из которой прибыл пакет). Использование идсет 0 особенно важно в тех случаях, когда ГВМ хочет взаимодействовать с помощью сети, но еще не знает свой сетевой IP-адрес. ГВМ временно использует идентификатор сети 0, а другие ГВМ в этой сети интерпретируют этот адрес как означающий "эта сеть". В большинстве случаев ответы будут содержать полный сетевой адрес, позволяя первоначальному отправителю запомнить его на будущее. Главы 9 и 20 рассмотрят в деталях, как ГВМ определяет свой сетевой адрес и как он использует идентификатор сети 0.

4.7.1 Групповая адресация

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

4.8 Недостатки адресации Интернета

Кодирование информации о сети в межсетевом адресе имеет ряд недостатков. Самым очевидным недостатком является то, что адреса описывают соединения, а не ГВМ:

Если ГВМ перемещается из одной сети в другую, его IP-адрес должен измениться.

Чтобы понять этот вывод, давайте рассмотрим путешественников, который хотели бы отсоединять свои персональные компьютеры, брать их с собой в дорогу, а затем присоединять их к интернету после прибытия в место назначения. Таким персональным компьютерам нельзя назначить постоянный IP-адрес, так как IP-адрес идентифицирует сеть, к которой присоединена эта машина. Другим слабым местом межсетевой схемы адресации является то, что когда число ГВМ в сетях класса С начинает превышать 255, нужно изменить ее адрес на адрес класса В. Хотя это может показаться незначительной проблемой, изменение сетевого адреса может потребовать большого количества времени и быть трудноотлаживаемым. Так как большая часть программного обеспечения не предназначена для работы с несколькими адресами в одной и той же физической сети, администраторы не могут спланировать плавный переход, в течение которого они могли бы медленно изменить адреса. Вместо этого, они должны сразу запретить использование одного сетевого адреса, изменить адреса всех машин, а затем возобновить взаимодействие, используя новые сетевые адреса.

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

Так как маршрутизация использует сетевую часть IP-адреса, путь, проходимый пакетами до ГВМ с несколькими IP-адресами, зависит от используемого адреса.

Следствия этого утверждения удивительны. Люди думают, что каждый ГВМ - это одна сущность, и хотят использовать одно имя. Они часто удивляются, обнаружив, что у ГВМ есть более чем одно имя, и еще более удивляются, открыв, что разные имена ведут себя по-разному.

Другим удивительным следствием межсетевой схемы адресации является то, что знания одного IP-адреса для ГВМ получателя может оказаться недостаточно; может получиться так, что нельзя будет достичь получается, используя этот адрес. Рассмотрим демонстрационную сеть, показанную на рисунке 4.2. На этом рисунке два ГВМ, А и В, оба присоединены к сети 1, и обычно взаимодействуют между собой, используя эту сеть. Поэтому, пользователи на ГВМ А обычно указывают ГВМ В, используя IP-адрес I4. Существует другой путь от А к В через шлюз G, и он используется всякий раз, когда А посылает пакеты IP-адресу I5. Теперь предположим, что соединение В с сетью 1 вышло из строя, но сама машина продолжает работать(например, оборвался кабель между В и сетью 1). Пользователи на А, использующие IP-адрес I4, не смогут достичь В, хотя пользователи, использующие адрес I5, смогут это сделать. Эти проблемы с именованием и адресацией снова возникнут в следующих главах, когда мы будем рассматривать маршрутизацию и связывание имен.

        сеть 1
---------------------------------------------------------
    | I1               |  I3                 |  I4
  +++++              +++++                 +++++
  | G |              | А |                 | В |
  +++++              +++++                 +++++
    |  I2                                    |  I5
---------------------------------------------------------

         сеть 2

Рисунок 4.2 Пример интернета с многоадресным ГВМ В, который демонстрирует проблему со схемой адресации IP. Если интерфейс I4 отсоединится, А должен использовать адрес I5 для достижения В, направляя пакеты к нему через шлюз G.

4.9 Точечная(dotted) десятичная нотация

Для удобства людей в технических документах или прикладных программах IP-адреса пишутся как четыре десятичных числа, разделенных десятичными точками, и каждое из этих чисел представляет значение одного октета IP-адреса(точечная десятичная нотация иногда называется точечной квадронотацией). Поэтому 32-битовый межсетевой адрес

10000000    00001010   00000010  00011110

записывается как

             128.10.2.30

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

4.10 Адрес обратной связи(loopback)

Сетевой адрес класса А 127.0.0.0 зарезервирован для обратной связи и введен для тестирования взаимодействия между процессами на одной машине. Когда какая-либо программа использует адрес обратной связи для передачи данных, протокольное программное обеспечение в компьютере возвращает эти данные, ничего не посылая по сети. В литературе четко сказано, что пакет, посланный в сеть с адресом 127, не будет передаваться ни по какой сети. Более того, ГВМ или шлюз никогда не должен распространять информацию о маршрутах для сети с номером 127; этот адрес не является адресом сети.

4.11 Список соглашений о специальных адресах

На практике IP использует лишь комбинации из нулей("этот") или из всех единиц("все"). Рисунок 4.3 показывает все имеющиеся случаи.

---------------------------------
|       все нули               |  Этот ГВМ*
---------------------------------
---------------------------------
|  все нули |  ГВМ             |  ГВМ в этой сети*
---------------------------------
--------------------------------- Ограниченное
|       все единицы            |  широковещание
--------------------------------- (локальная сеть)**
--------------------------------- Направленное
|  сеть       |   все единицы   |  широковещание
--------------------------------- в сети**
---------------------------------
| 127      |  все, что угодно   |  Обратная связь***
---------------------------------

Замечания:

* Разрешено только при загрузке системы и не может быть адресом получателя
** Не может быть адресом отправителя
*** Никогда не будет передан в сеть

Рисунок 4.3 Специальные формы IP-адресов, включая допустимые комбинации нулей("это") и единиц("все"). Длина сетевой части при направленном широковещании зависит от класса сетевого адреса.

Как указано в замечаниях к рисунку, использование всех нулей для сети допустимо только во время загрузки системы. Оно временно позволяет машине взаимодействовать. Как только машина узнала свой настоящий IP-адрес, она должна перестать использовать сеть 0.

4.12 Ответственность за адресацию в Интернете

Чтобы быть уверенным в том, что сетевые части Интернетовских адресов являются уникальными, все Интернетовские адреса назначаются одним ведомством, Сетевым Информационным Центром(NIC). Он назначает только сетевую часть адреса и возлагает ответственность за назначение адресов ГВМ в этой сети организации, запросившей этот адрес. Локальным сетям с небольшим числом машин(меньшим чем 255) обычно назначается номера класса С, так как ожидается появление большого числа локальных сетей. Большим сетям, таким как ARPANET, назначаются номера класса А, так как можно ожидать появления лишь небольшого числа больших сетей.

При назначении IP-адресов сетям NICу важно лишь то, что эта сеть или присоединена к объединенному Интернету, или собирается к нему присоединиться. Какая-либо корпорация может взять на себя ответственность за назначение уникальных сетевых адресов внутри своего интернета TCP/IP, если она никогда не собирается соединять свой интернет с внешним миром. На самом деле многие объединенные группы, использующие протоколы TCP/IP, назначают межсетевые адреса по своему усмотрению. Например, NIC назначил адрес 10.0.0.0 ARPANETу. Если какой-либо колледж решит использовать протоколы TCP/IP в своем Ethernete, в состав которого входят лишь три машины(и нет никаких шлюзов), он может выбрать адрес 10.0.0.0 для этой локальной сети. Тем не менее, как показывает опыт, нежелательно создание частного интернета, использующего те же самые сетевые адреса, что и объединенный Интернет, так как это приведет к невозможности взаимной работы в будущем и может вызвать проблемы при попытке обменяться программным обеспечением с другими колледжами. Поэтому, всем, кто использует TCP/IP очень выгодно потратить некоторое время и получить официальные Интернетовские адреса у NICа.

4.13 Пример

Для уяснения схемы адресации в IP рассмотрим пример из рисунка 4.4, который показывает несколько соединений и ГВМ, соединенных с Интернетом, на факультете компьютерных наук университета Пурдью в середине 80-х годов. Пример показывает три сети: ARPANET(10.0.0.0), Ethernet(128.10.0.0) и маркерное кольцо proNET-10(192.5.48.0). При написании этих адресов в двоичном виде видно, что эти сети являются соответственно сетями класса А,В и С.

На рисунке четыре ГВМ, присоединенные к этим сетям, называются Arthur, Merlin, Guenevere и Lancelot. Машина Taliesyn служит шлюзом между ARPANET и proNET-10, а машина Glatisant служит шлюзом между proNET-10 и Ethernet. ГВМ Merlin имеет соединения как с Ethernetом, так и с proNET-10, поэтому она может взаимодействовать с ГВМ в обеих сетях напрямую. Хотя многоадресный ГВМ, такой как Merlin, может также работать как шлюз, Merlin является прежде всего системой с разделением времени ,и дополнительная работа по маршрутизации пакетов может уменьшить вычислительную мощность, доступную пользователям. Поэтому, был установлен выделенный шлюз, Glatisant, чтобы снять нагрузку передачи траффика с системы с разделением времени. Траффик между этими двумя сетями имел на самом деле гораздо больший объем, чем предполагает эта конфигурация, так как здесь показаны далеко не все имевшиеся ГВМ.

Ethernet  128.10.0.0
============================================================
  | 128.10.2.3    | 128.10.2.8   | 128.10.2.70  | 128.10.2.26
 -------------   ------------- -------------  -------------
 |Merlin     |   |Guenevere  |  |Glatisant  |  |Lancelot   |
 |(многоадр. |   |(ГВМ      |  |(шлюз)     |  |(ГВМ       |
 | ГВМ)      |   |  Ethernet)| |           |  |  Ethernet)|
 |           |   |          |  |           |  |           |
 -------------   ------------- -------------  -------------
  \    192.5.48.3                 /   192.5.48.7
   \                             /                 10.2.0.37
    \          ++++++++++++++   /       -------------
      ---------+ proNET-10+----         |Taliesyn   |
-------------  +  192.5.48.0+-----------|(шлюз)     |------>
|Arthur     |  ++++++++++++++192.5.48.6 |           |
|(ГВМ       |        |                  |           |
|   proNET) |---------                  -------------
|           | 192.5.48.1                          к ARPANET
-------------                                       10.0.0.0

Рисунок 4.4 Пример назначения IP-адресов для ГВМ и шлюзов в Ethernetе, маркерном кольце и ARPANETе.

Рисунок 4.4 показывает IP-адреса для каждого сетевого соединения. Lancelot, соединенный только с Ethernet, имеет адрес 128.10.2.26. Merlin имеет адрес 128.10.2.3 для соединения с Ethernetом и 192.5.48.3 для соединения с proNET-10. Выбор одинакового значения для младшего байта этих двух адресов позволяет системным программистам легче запомнить все межсетевые адреса Merlinа.

4.14 Порядок байт в сети

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

Стандартизация порядка байт для целых чисел особенно важна для интернета, так как межсетевые пакеты содержат двоичные числа, указывающие такую информацию, как адрес назначения и длина пакета. Такие числа должны пониматься как отправителем, так и получателем. Протоколы TCP/IP решают проблему порядка байт, определяя стандартный сетевой порядок байт, который должны использовать все машины для двоичных полей в межсетевых пакетах. Каждый ГВМ преобразует двоичные элементы из локального представления в стандартный сетевой порядок перед передачей пакета; он преобразует сетевой порядок байт в свой порядок при приеме пакета. Естественно поле данных пользователя в пакете не обрабатывается по этому стандарту - пользователи вольны форматировать свои данные так, как они пожелают. Конечно, большинство пользователей полагается на стандартные прикладные программы и не сталкивается с проблемой порядка байт напрямую. Межсетевой стандарт порядка байт определяет, что целые числа посылаются таким образом, что самый старший(значимый) байт передается первым(т.е. в стиле "с наибольшего конца"). Если посмотреть на последовательность байт пакета тогда, когда он передается от одной машины к другой, то у двоичного целого в этом пакете самый старший байт находится ближе всего к началу пакета, а самый младший байт находится ближе всего к концу пакета. Было выдвинуто много аргументов в пользу использования того или иного представления данных, и межсетевой стандарт до сих пор время от времени подвергается критике. Тем не менее, все согласились с тем, что такой стандарт необходим, и точная форма его не так уж и важна.

4.15 Итоги

TCP/IP использует 32-битовые двоичные адреса в качестве универсальных идентификаторов машин. Называемые межсетевыми или IP-адресами, эти идентификаторы разделены на три основных класса, и допускают существование сотни сетей с миллионами ГВМ в каждой, тысяч сетей с тысячами ГВМ в каждой и свыше миллиона сетей с 254 ГВМ в каждой. Чтобы сделать эти адреса более легкими для понимания людей, они записываются в точечной десятичной нотации, в которой значения четырех октетов записываются в десятичном виде и разделяются десятичными точками.

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

Для дальнейшего изучения

Межсетевая схема адресации, представленная здесь, может быть найдена в Reynolds и Postel[RFC 990 и 997].

Официальные адреса Интернета назначаются NIC(смотри в Приложении 1 его адрес и телефонный номер).

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

Глава 17 показывает, как адреса класса D назначаются для межсетевой групповой передачи.

Cohen[1981] объясняет проблему порядка бит и байт и вводит термины "с наименьшего конца" и "с наибольшего конца".

Упражнения

4.1 Сколько точно может существовать сетей класса А, В и С ? Сколько точно может быть ГВМ в сети каждого класса ? Будьте осторожны с сетями класса D и Е.

4.2 Список адресов, назначенных машинам, в читабельной форме называется межсетевой таблицей ГВМ. Если в вашем узле есть таблица ГВМ, установите точно, сколько номеров сетей класса А, В и С уже выделено.

4.3 Сколько ГВМ присоединено к каждой из локальных сетей в вашем узле ? Есть ли в вашем узле локальные сети, для которых недостаточно адреса класса С ?

4.4 Каково главное отличие схемы адресации в IP от схемы нумерации телефонов в США ?

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

4.6 Отличается стандартный сетевой порядок байт от порядка байт в вашей машине ?


Глава 5 Отображение адресов Интернета в физические адреса(ARP)

  • 5.1 Введение
  • 5.2 Проблема разрешения адресов
  • 5.3 Два типа физических адресов
  • 5.4 Разрешение с помощью прямого отображения
  • 5.5 Разрешение с помощью динамического связывания
  • 5.6 Кэш разрешения адресов
  • 5.7 Уточнение ARP
  • 5.8 Реализация ARP
  • 5.9 Инкапсуляция и идентификация ARP
  • 5.10 Формат протокола ARP
  • 5.11 Итоги
  • Для дальнейшего изучения
  • Упражнения

5.1 Введение

Мы описали схему адресации TCP/IP, в которой каждому ГВМ назначается 32-битовый адрес и сказали, что интернет ведет себя как виртуальная сеть при использовании этих назначенных адресов для посылки и приема пакетов. Мы также рассмотрели несколько физических сетевых технологий и заметили, что две машины в данной физической сети могут взаимодействовать только в том случае, если каждая из них знает физический сетевой адрес другой машины. О чем мы не упоминали, так это о том, как ГВМ или шлюз отображает IP-адрес в корректный физический адрес, когда ему нужно послать пакет по физической сети. Эта глава рассматривает это отображение, показывая, как оно реализуется для двух самых распространенных схем физических адресов.

5.2 Проблема разрешения адресов

Рассмотрим две машины А и В, которые присоединены к одной физической сети. Каждая из них имеет назначенный IP-адрес Ia и Ib, а также физический адрес Pa и Pb. Нашей целью является разработка низкоуровневого программного обеспечения, которое скрывало бы физические адреса и позволяло бы программам более высокого уровня работать только с межсетевыми адресами. Тем не менее, в конечном счете взаимодействие реализуется физическими сетями, использующими какую-либо схему физических адресов. Предположим, что машина А хочет послать пакет машине В по физической сети, к которой они обе присоединены, но А знает только межсетевой адрес Ib. Возникает вопрос: как может А отобразить этот адрес в физический адрес Pb ?

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

5.3 Два типа физических адресов

Существуют два основных типа физических адресов: характерным представителем первого типа является Ethernet, использующий большие, фиксированные физические адреса, а второго - proNET-10, использующий маленькие легко изменяемые физические адреса. Разрешение адресов трудно для сетей типа Ethernetа, но легко для сетей типа proNET-10. Мы рассмотрим первым легкий случай.

5.4 Разрешение с помощью прямого отображения

Рассмотрим сеть с маркерным кольцом proNET-10. Как вы помните, из главы 2 мы знаем, что она использует небольшие целые числа в качестве физических адресов и позволяет пользователю выбрать аппаратный адрес при установке платы интерфейса в компьютер. Главной причиной, делающей разрешение адресов легким для сети proNET-10, является то, что раз можно назначать как IP-адреса, так и физические адреса, то можно выбрать их такими, что их части будут совпадать. Обычно при назначении IP-адресов поле идГВМ делается равным 1,2,3 и т.д., а затем при установке сетевого интерфейсного оборудования выбирается физический адрес, совпадающий с полем идГВМ в IP-адресе. Например, можно выбрать физический адрес 3 для машины, имеющей IP-адрес 192.5.48.3, так как 192.5.48.3 является адресом класса С, у которого поле идГВМ равно 3.

Для сетей, таких как proNET-10, вычисление физического адреса на основе IP-адреса тривиально. Вычисление состоит из выделения полу идентификатора ГВМ из IP-адреса. Это вычислительно эффективно, так как требует выполнения нескольких машинных команд. Это легко осуществить, так как может быть выполнено без обращения к внешним данным. И ,наконец, новые машины могут быть добавлены к сети без изменения данных или перекомпиляции кода. Концептуально выбор схемы нумерации, делающей разрешение адресов эффективным, означает выбор функции F, которая отображает IP-адреса в физические адреса. Разработчик может также выбрать схему нумерации физических адресов. Разрешение IP-адреса Ia означает вычисление

           Pa=F(Ia)

Мы хотим, чтобы вычисление F было эффективным. Если множество физических адресов ограничено, можно по-другому эффективно сделать это отображение. Например, при использовании X.25 нельзя выбрать физические адреса. Обычно, шлюзы в сетях X.25 хранят пары IP-адресов и физических адресов X.25 в таблице и осуществляют поиск в этой таблице при разрешении IP-адресов. Чтобы сделать разрешение адресов эффективным в таких случаях, программное обеспечение может использовать хэш-функцию для поиска в таблице. Упражнение 5.1 предлагает еще один подход.

5.5 Разрешение с помощью динамического связывания

Чтобы понять, почему разрешение адресов так трудно в некоторых сетях, рассмотрим технологию Ethernetа. Как вы знаете из главы 2, Ethernet имеет 48-битовые физические адреса, назначаемые производителями при изготовлении интерфейсных плат. Как следствие, при выходе оборудования из строя и замене интерфейсной платы физический адрес машины меняется. Более того, так как адрес в Ethernetе имеет длину 48 бит, не стоит и рассчитывать, что его можно закодировать в 32-битном IP-адресе. Разработчики протоколов TCP/IP нашли конструктивное решение проблемы разрешения адресов для сетей, таких как Chaosnet или Ethernet, которые имеют возможность широковещания. Это решение позволяет добавлять машины к сети без перекомпиляции кода и без создания центральной базы данных. Чтобы избежать создания таблиц отображения разработчики решили использовать низкоуровневый протокол для динамической связки адресов. Названный Протокол Разрешения Адресов(ARP), он обеспечивает механизм, который является как эффективным, так и легким для реализации.

Как показывает рисунок 5.1 , идея, лежащая в основе динамического разрешения в ARP, проста: когда ГВМ А хочет разрешить IP-адрес Ib, он широковещательно распространяет специальный пакет, который просит ГВМ с IP-адресом Ib ответить ему, указав свой физический адрес Pb. Все ГВМ, включая В, получают этот запрос, но только ГВМ В узнает свой IP-адрес и посылает ответ, содержащий свой физический адрес. Когда А получает ответ, он использует физический адрес для посылки межсетевого пакета прямо к В. Итоги всего вышесказанного можно изложить так:

Протокол Разрешения Адресов,ARP, позволяет ГВМ установить физический адрес ГВМ назначения в той же самой физической сети, имея только IP-адрес назначения.

<---|---------------------------------------->
===============|==========|==========|====================
    |          | |       | |        | |
    |          V |       V |        V |
  -----        -----     -----      -----
  | А |        | X |     | B |      | Y |
  |   |        |   |     |   |      |   |
  -----        -----     -----      -----
                     (а)
      ---------------------
======|===================|===============================
    | |          |       | |          |
    | V          |       | |          |
  -----        -----     -----      -----
  | А |        | X |     | B |      | Y |
  |   |        |   |     |   |      |   |
  -----        -----     -----      -----
                     (б)

Рисунок 5.1 Протокол ARP. Чтобы определить физический адрес В, Pb, по его IP-адресу, Ib, (а) ГВМ А широковещательно распространяет запрос ARP, содержащий Ib, по всем машинам, и (б) ГВМ В отвечает на него ответом ARP, содержащим пару (Ib,Pb).

5.6 Кэш разрешения адресов

Может показаться глупым то, что А, посылая пакет к В, сначала посылает широковещательный пакет, который достигает В. Или может показаться еще глупее, что А широковещательно задает вопрос:"Как я могу связаться с вами?" вместо того, чтобы просто широковещательно послать пакет, который он хочет передать. Но есть важная причина для таких передач. Широковещание слишком дорого, чтобы использовать его всякий раз, когда одной машине требуется передать пакет другой машине, так как оно требует от каждой машины в сети обработки широковещательного пакета. Чтобы уменьшить затраты на взаимодействие, ГВМ, использующие ARP, создают кэш недавно узнанных связок между физическим адресом и IP-адресом, и поэтому они не должны повторно использовать ARP. Всякий раз, когда ГВМ получает ответ ARP, он сохраняет IP-адрес машины и соответствующий ему аппаратный адрес в своем кэше для последующих обращений. При передаче пакета ГВМ ищет связку в кэше перед тем, как послать запрос ARP. Если ГВМ нашел нужную связку в своем кэше, ему не надо передавать широковещательный пакет в сеть. Опыт показывает, что так как большинство сетевых взаимодействий включает передачу более чем одного пакета, даже небольшой кэш будет полезен.

5.7 Уточнение ARP

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

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

5.8 Реализация ARP

Функционально ARP состоит из двух частей. Одна часть определяет физические адреса при посылке пакета, а другая отвечает на запросы от других машин. Разрешение адресов для выходящих пакетов кажется элементарным, но некоторые детали усложняют реализацию. Получив IP-адрес назначения, ГВМ просматривает кэш ARP, чтобы проверить, не знает ли он уже физического адреса для этого IP-адреса. Если ГВМ знает его, он выделяет физический адрес, помещает данные в кадр, используя этот адрес, и посылает этот кадр. Если же он не знает отображения, он должен широковещательно передать запрос ARP и ждать ответа. Широковещание запроса ARP для нахождения отображения адреса может оказаться сложным. Машина получателя может быть выключена или быть слишком занята, чтобы принять запрос. Если такое случится, отправитель может не получить ответа или ответ может задержаться. Так как Ethernet является системой с негарантированной доставкой, то исходный широковещательный запрос ARP тоже может быть потерян(в этом случае отправитель должен будет повторно отправлять его по крайней мере еще один раз). Между тем ГВМ должен хранить исходный передаваемый пакет, чтобы его можно было послать, когда будет разрешен адрес(если задержка становится значительной, ГВМ может уничтожить передаваемый пакет). Фактически, ГВМ должен решить, можно ли работать другим прикладным программам, пока он обрабатывает запрос ARP(в большинстве случаев можно). Если можно, то он должен учитывать случай, когда приложение будет генерировать дополнительные запросы ARP для того же адреса, не посылая широковещательный запрос несколько раз для одного и того же получателя.

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

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

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

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

5.9 Инкапсуляция и идентификация ARP

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

                     -------------------------------------
                     |        сообщение ARP              |
                     -------------------------------------
                     |                                   |
                     V                                   V
-----------------------------------------------------------
| заголовок кадра   |      поле данных кадра             |
-----------------------------------------------------------

Рисунок 5.2 Сообщение ARP, заключенное в кадре физической сети

Чтобы идентифицировать, что кадр содержит запрос или ответ ARP, отправитель присваивает специальное значение полю типа в заголовке кадра и помещает сообщение ARP в поле данных кадра. Когда кадр прибывает на ГВМ, система смотрит тип кадра, чтобы определить его содержимое. Например, в Ethernete, кадры, несущие сообщения ARP, имеют в поле типа значение 0806 в шестнадцатиричном формате. Это стандартное значение, назначенное ведомством, устанавливающим стандарты Ethernetа.

5.10 Формат протокола ARP

В отличие от большинства протоколов, данные в пакетах ARP не имеют фиксированного формата заголовка. Вместо этого его сообщения были разработаны так, чтобы их можно было использовать для различных сетевых технологий. Поэтому, первые поля заголовка содержат счетчики, которые указывают длину следующих полей. Фактически, ARP можно использовать с произвольными физическими адресами и произвольными протокольными адресами. Пример на рисунке 5.3 показывает 28-октетный формат сообщения ARP, используемый для оборудования Ethernetа(у которого физические адреса являются 48-битовыми или 6-октетными) при разрешении протокольных адресов IP(имеющих длину 4 октета).

Рисунок 5.3 показывает сообщение ARP по 4 байта в строке, в формате, который будет стандартным на протяжении всей книги. К сожалению, в отличие от большинства остальных протоколов, поля переменной длины в пакетах ARP не выровнены на границу 32 бит, что приводит к трудности восприятия диаграммы. Например, аппаратный адрес отправителя, помеченный как ОТПРАВИТЕЛЬ АА, занимает 6 непрерывных октетов, что приводит к появлению его на двух строках диаграммы.

0            8            16              24            31
-----------------------------------------------------------
| ТИП ОБОРУДОВАНИЯ        |   ТИП ПРОТОКОЛА              |
-----------------------------------------------------------
| HLEN      |    PLEN     |   ОПЕРАЦИЯ                   |
-----------------------------------------------------------
|         ОТПРАВИТЕЛЬ АА (октеты 0-3)                     |
-----------------------------------------------------------
|ОТПРАВИТЕЛЬ АА(октеты 4-5)|ОТПРАВИТЕЛЬ IP(октеты 0-1)    |
-----------------------------------------------------------
|ОТПРАВИТЕЛЬ IP(октеты 2-3)|ПОЛУЧАТЕЛЬ АА(октеты 0-1)     |
-----------------------------------------------------------
|              ПОЛУЧАТЕЛЬ АА(октеты 2-5)                  |
-----------------------------------------------------------
|              ПОЛУЧАТЕЛЬ IP(октеты 0-3)                  |
-----------------------------------------------------------

Рисунок 5.3 Пример формата сообщения ARP/RARP для разрешения адресов IP-Ethernet. Длины полей зависят от длин аппаратных и протокольных адресов, которые имеют значение соответственно 6 октетов для адреса Ethernetа и 4 октета для IP-адреса.

Поле ТИП ОБОРУДОВАНИЯ определяет тип аппаратного интерфейса, для которого отправитель ищет ответ; оно содержит значение 1 для Ethernetа. Аналогичным образом, поле ТИП ПРОТОКОЛА указывает тип адреса протокола более высокого уровня, который использует отправитель; оно содержит 0800 в шестнадцатиричном формате для IP-адреса. Поле ОПЕРАЦИЯ указывает запрос ARP(1), ответ ARP(2), запрос RARP(3), или ответ RARP(4)(RARP, другой протокол, использующий тот же самый формат сообщения, будет рассмотрен в следующей главе). Поля HLEN и PLEN позволяют использовать ARP в любых сетях, так как они указывают длину аппаратного адреса и адреса протокола верхнего уровня. Отправитель передает свой аппаратный адрес и IP-адрес, если они известны ему, в полях ОТПРАВИТЕЛЬ АА и ОТПРАВИТЕЛЬ IP.

При посылке запроса отправитель также указывает IP-адреса назначения(ARP) или аппаратного адреса назначения(RARP), используя поля ПОЛУЧАТЕЛЬ АА и ПОЛУЧАТЕЛЬ IP. Отвечающая машина перед передачей ответа заполняет отсутствующие адреса, меняет местами пары отправителя и получателя и меняет код операции на ответ. Поэтому ответ содержит IP- и аппаратный адреса исходного отправителя, а также IP- и аппаратный адреса машины, которая разрешила эту связку.

5.11 Итоги

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

Машина использует ARP, чтобы найти аппаратный адрес другой машины с помощью широковещания запроса ARP. Запрос содержит IP-адрес машины, для которой нужно узнать аппаратный адрес. Каждая машина отвечает на запросы, соответствующие ее IP-адресу, посылая ответы, содержащие требуемый аппаратный адрес. Чтобы сделать ARP эффективным, каждая машина кэширует связки (IP-адрес;аппаратный адрес). Так как межсетевой траффик имеет тенденцию состоять из последовательности взаимодействий между парами машин, кэш приводит к ненужности большинства широковещательных запросов ARP.

Для дальнейшего изучения

Протокол разрешения адресов, использованный здесь, описан Plumer[RFC 826] и стал стандартным межсетевым протоколом. Dalal и Printis[1981] описывают связь между адресами IP и Ethernetа, а Clark[RFC 814] обсуждает адреса и связки в общем. Parr[RFC 1029] рассматривает разрешение адресов, устойчивое к ошибкам. Документ Межсетевые Номера[RFC 1010] указывает значения, используемые для идентификации сетевых кадров. Comer[1987] представляет пример реализации ARP для операционной системы Xinu.

Упражнения

5.1 Вам задано небольшое множество физических адресов(положительных целых чисел). Найдите функцию F и назначения для IP-адресов, такие, что F отображает однозначно IP-адреса в физические адреса и вычисление F эффективно. 5.2 В каком особом случае ГВМ, присоединенному к Ethernetу, не надо использовать ARP , или кэш ARP перед передачей дейтаграммы IP ?

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

5.4 Должен ли ARP обновлять кэш, если для заданного IP-адреса уже существует элемент ? Почему да или почему нет ?

5.5 Должен ли ARP модифицировать кэш даже в том случае, когда он получает информацию, которую он не запрашивал ? Почему да или почему нет ?

5.6 Любая реализация ARP, использующая кэш фиксированного размера, может аварийно завершиться, если используется в сети, имеющей много ГВМ и много траффика ARP. Объясните почему.

5.7 ARP часто считается слабым в отношении секретности. Объясните почему.

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

5.9 Предположим, что машина С приняла запрос ARP, посланный от А к машине В, и предположим, что С имеет связку для Ib в своем кэше. Следует ли С отвечать на этот запрос ? Объясните.

5.10 Как может рабочая станция использовать ARP при своей загрузке для того, чтобы установить, нет ли в сети какой-либо другой машины с таким же адресом ? Каковы недостатки этой схемы ?


Глава 6 Определение межсетевого адреса при начальной загрузке(RARP)

  • 6.1 Введение
  • 6.2 Протокол обратного разрешения адресов(RARP)
  • 6.3 Повторение транзакций RARP
  • 6.4 Основные и дублирующие серверы RARP
  • 6.5 Итоги
  • Для дальнейшего изучения
  • Упражнения

6.1 Введение

Мы уже знаем, что физические сетевые адреса являются как низкоуровневыми, так и аппаратно зависимыми, и мы знаем, что каждой машине, использующей TCP/IP, назначен один или несколько 32-битовых IP-адресов, которые независимы от аппаратных адресов машины. прикладные программы всегда используют IP-адрес при указании назначения. ГВМ и шлюзы должны использовать физические адреса для передачи дейтаграмм по базовым сетям; они полагаются на схемы разрешения адресов, такие как ARP, при выполнении связывания.

Обычно IP-адрес машины хранится во внешней памяти, откуда операционная система и берет его при начальной загрузке. Возникает вопрос: "Как бездисковая машина, не имея доступа к внешней памяти, определяет свой IP-адрес?" Эта проблема является критической для бездисковых станций, использующих IP-адрес для взаимодействия с файл-сервером. Более того, так как много бездисковых машин используют стандартные протоколы передачи файлов TCP/IP для получения начального образа при загрузке, они должны получать и использовать IP-адреса до начала работы операционной системы. Эта глава изучает вопрос о том, как получить IP-адреса, и описывает протокол, который используют бездисковые машины.

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

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

Идея, лежащая в основе нахождения IP-адреса, проста: бездисковая машина посылает запрос другой машине, называемой сервером(глава 18 более детально описывает серверы), и ждет, пока сервер не пошлет ответ. Мы будем предполагать, что сервер имеет диск, на котором он хранит базу данных межсетевых адресов. В этом запросе машина, которой нужно узнать свой межсетевой адрес, должна идентифицировать себя уникальным образом, сервер мог найти ее межсетевой адрес и послать ответ. Как посылающая запрос машина, так и отвечающий ей сервер используют физические сетевые адреса в ходе своего короткого взаимодействия. Но откуда бездисковая машина знает физический адрес сервера ? Обычно она его и не знает - она просто широковещательно передает запрос ко всем машинам в локальной сети. Ей отвечают один или более серверов.

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

6.2 Протокол обратного разрешения адресов(RARP)

Разработчики протоколов TCP/IP сообразили, что есть другая уникально идентифицирующая информация, которая всегда доступна, короче, физический сетевой адрес машины. Использование этого физического адреса как уникальной идентификации имеет два преимущества. Так как ГВМ получает свои физические адреса от сетевого интерфейсного оборудования, такие адреса всегда доступны и не входят в состав кода операционной системы. Так как идентифицирующая информация зависит от сети, а не от модели ЦП, все машины в сети будут поддерживать единообразные, уникальные идентификаторы. Поэтому задача становится обратной по отношению к разрешению адресов: имеется физический сетевой адрес; разработать схему, которая позволяла бы серверу отображать его в межсетевой адрес.

Бездисковая машина использует протокол интернета TCP/IP, называемы RARP(протокол обратного разрешения адресов), для получения своего IP-адреса от сервера. RARP создан на основе протокола ARP из предыдущей главы и использует тот же самый формат сообщений, который приведен на рисунке 5.3. На практике сообщение RARP, посылаемое при запросе межсетевого адреса, является несколько более общим, чем то, что описано выше: оно позволяет машине запрашивать IP-адрес не только себе, но и другим машинам. Оно также допускает несколько типов физических сетей. Как и сообщение ARP, сообщение RARP пересылается с одной машины на другую в поле данных кадра Ethernetа. Кадр Ethernetа, несущий запрос RARP, имеет обычную преамбулу, адреса отправителя и получателя Ethernetа, и поле типа пакета в начале себя. Поле типа содержит значение 8035, что идентифицирует содержимое этого кадра как сообщение RARP. Поле данных кадра содержит 28-октетное сообщение RARP.

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

  -<==-===============================================>--------
  ^            |            |              |
  |            V            V              V
   +++++++      +++++++      +++++++        +++++++
   +  А  +      +  B +       +  C  +        +  D  +
   +++++++      +++++++      +++++++        +++++++
                  (a)
  -----=========================================---------------
  |            |            ^              ^
  V            |            |              |
   +++++++      +++++++      +++++++        +++++++
   +  А  +      +  B +       +  C  +        +  D  +
   +++++++      +++++++      +++++++        +++++++
                   (b)

Рисунок 6.1 Пример обмена, используя протокол RARP. (a) Машина А посылает широковещательный запрос RARP, указывая себя как машину получателя, и (b) машины, ответственные за поддержку средства RARP(C и D), отвечают прямо А.

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

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

6.3 Повторение транзакций RARP

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

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

6.4 Основные и дублирующие серверы RARP.

Главным преимуществом использования группы машин как серверов RARP является то, что это делает систему более надежной. Если один сервер вышел из строя или перегружен и не может ответить, другой ответит на запрос. Поэтому существует большая вероятность того, что средство будет постоянно доступно. Главный же недостаток использования нескольких серверов заключается в том, что когда машина передает широковещательный запрос RARP, сеть становится перегруженной из-за того, что все серверы пытаются на него ответить. В Ethernetе, например, использование нескольких серверов RARP приводит к высокой вероятности возникновения коллизии.

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

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

6.5 Итоги

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

Для дальнейшего изучения

Детальное описание RARP можно найти в Finlayson et al[RFC 903]. Finlayson [RFC 906] описывает загрузку системы на рабочей станции с использованием протокола TFTP. Comer[1987] описывает пример реализации RARP для операционной системы Xinu.

Глава 19 рассматривает альтернативу RARP, известную как BOOTP. В отличие от схемы определения низкоуровневого адреса, применяемой в RARP, BOOTP построен на основе протоколов более высокого уровня, таких как IP и UDP. Глава 19 сравнивает эти два подхода, рассматривая преимущества и недостатки каждого.

Упражнения

6.1 Сервер RARP может широковещательно передавать ответы RARP всем машинам или передавать каждый ответ только машине, выдавшей этот запрос. Можно ли назвать систему, в которой применяются широковещательные ответы для всех машин, выгодной?

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

6.3 Насколько больше станут кадры Ethernetа, если к RARP добавить информацию, описанную в предыдущем примере.

6.4 Добавление второго сервера RARP к сети увеличивает надежность. Имеет ли смысл добавить третий сервер? А четвертый ? Почему да или почему нет ?

6.5 Бездисковые рабочие станции одного производителя используют RARP для получения своих IP-адресов, но всегда предполагают, что ответ приходит от файл-сервера рабочей станции. Затем бездисковая машина пытается получить загрузочный образ от этого сервера. Если она не получает ответа, эта рабочая станция входит в бесконечный цикл широковещательной передачи запросов на загрузку. Объясните, как добавление дублирующего сервера RARP к такой конфигурации может привести к переполнению сети широковещательными запросами. Замечание: обратите внимание на сбои питания.


Глава 7 Межсетевой протокол: доставка дейтаграмм без установления соединения

  • 7.1 Введение
  • 7.2 Виртуальная сеть
  • 7.3 Архитектура Интернета и его философия
  • 7.4 Понятие ненадежной доставки
  • 7.5 Система доставки без установления соединения
  • 7.6 Цель межсетевого протокола
  • 7.7 Межсетевая дейтаграмма
    • 7.7.1 Формат дейтаграммы
    • 7.7.2 Тип сервиса для дейтаграммы и приоритет
    • 7.7.3 Инкапсуляция дейтаграмм
    • 7.7.4 Размер дейтаграммы, сетевая МЕП(MTU) и фрагментация
    • 7.7.5 Сборка фрагментов
    • 7.7.6 Управление фрагментацией
    • 7.7.7 Время жизни(TTL)
    • 7.7.8 Другие поля дейтаграммы
  • 7.8 Межсетевые опции дейтаграммы
    • 7.8.1 Опция записи маршрута
    • 7.8.2 Опции пути источника
    • 7.8.3 Опция временных меток
    • 7.8.4 Обработка опций при фрагментации
  • 7.9 Итоги
  • Для дальнейшего изучения
  • Упражнения

7.1 Введение

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

7.2 Виртуальная сеть

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

Пользователь представляет себе интернет в виде одной виртуальной сети, соединяющей все ГВМ, с помощью которой и делается возможным взаимодействие; его настоящая архитектура является невидимой и ненужной.

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

7.3 Архитектура Интернета и его философия

На концептуальном уровне интернет TCP/IP обеспечивает три множества средств, как показано на рисунке 7.1; их расположение на рисунке предполагает зависимости между ними. На самом нижнем уровне, средство доставки без установления соединения обеспечивает основу для всего остального. На следующем уровне надежное транспортное средство обеспечивает платформу более высокого уровня, от которую опираются приложения. Мы вскоре освоим каждое из этих трех средств, поймем, что они обеспечивают, и увидим, какие протоколы связаны с ними.

     --------------------------------------------
     |    ПРИКЛАДНЫЕ СРЕДСТВА                  |
  --------------------------------------------------
  |  НАДЕЖНОЕ ТРАНСПОРТНОЕ СРЕДСТВО                |
--------------------------------------------------------
| СРЕДСТВО ДОСТАВКИ ПАКЕТОВ БЕЗ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ|
--------------------------------------------------------

Рисунок 7.1 Три концептуальные уровня межсетевых средств

7.4 Понятие ненадежной доставки

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

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

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

7.5 Система доставки без установления соединения

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

7.6 Цель межсетевого протокола

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

Мы начинаем рассмотрение IP в этой главе с обзора формата пакета, описанного в нем. Маршрутизацию и обработку ошибок мы рассмотрим в следующих главах.

7.7 Межсетевая дейтаграмма

Между физической сетью и интернетом TCP/IP существует много аналогий. В физической сети единицей передачи является кадр, который состоит из заголовка и данных, где заголовок содержит информацию, такую как адреса отправителя и получателя. Интернет называет свой базовый элемент передачи межсетевой дейтаграммой(иногда ее называют IP-дейтаграммой или просто дейтаграммой). Как и кадр физической сети, дейтаграмма делится на поле заголовка и поле данных. Кроме того, как и кадр, заголовок дейтаграммы содержит адреса отправителя и получателя, а также поле типа, которое идентифицирует содержимое дейтаграммы. Ну, и конечно, разница между ними состоит в том, что заголовок дейтаграммы содержит IP-адреса, в то время как заголовок кадра - физические адреса. Рисунок 7.2 показывает общую форму дейтаграммы:

-----------------------------------------------------------
|  ЗАГОЛОВОК          |  ОБЛАСТЬ ДАННЫХ                  |
|  ДЕЙТАГРАММЫ        |  ДЕЙТАГРАММЫ                     |
-----------------------------------------------------------

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

7.7.1 Формат дейтаграммы

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

0      4      8            16     19         24          31
------------------------------------------------------------
|версия|длина| тип сервиса|  общая длина                  |
------------------------------------------------------------
|    идентификация        |флаги   |смещение фрагмента    |
------------------------------------------------------------
|время жизни | протокол   |  КС заголовка                 |
------------------------------------------------------------
|                 IP-адрес отправителя                     |
------------------------------------------------------------
|                 IP-адрес получателя                      |
------------------------------------------------------------
|      Опции IP(если есть)                    |заполнение  |
------------------------------------------------------------
|                     Данные                               |
------------------------------------------------------------
|                       ...                                |
------------------------------------------------------------

Рисунок 7.3 Формат дейтаграммы Интернета, основного элемента передачи в интернете TCP/IP.

Так как обработка дейтаграммы происходит с помощью программного обеспечения, оборудование не накладывает никаких ограничений на ее содержимое и формат. Например, первое 4-битовое поле в дейтаграмме(ВЕРСИЯ) содержит версию протокола IP , используемую при создании дейтаграммы. Оно используется отправителем, получателем, и всеми шлюзами между ними для уверенности в том, что все они используют один и тот же формат дейтаграммы. Всему программному обеспечению IP требуется проверять поле версии перед обработкой дейтаграммы, чтобы быть уверенным в том, что ее формат соответствует тому формату, который ожидает это обеспечение. Если стандарт меняется, машины будут отбрасывать дейтаграммы с версией протокола, отличающейся от версии, на которой они работают, предохраняя себя от неправильной интерпретации содержимого дейтаграммы из-за устаревшего формата. Текущая версия протокола IP - 4.

Поле длины заголовка(ДЛИНА) также занимает 4 бита и хранит длину заголовка дейтаграммы в 32-битных словах. Как мы увидим, все поля в заголовке имеют фиксированную длину, за исключением поля ОПЦИИ IP и соответствующего ему поля ЗАПОЛНЕНИЕ. Наиболее простой заголовок, без опций и заполнения, занимает 20 октетов и имеет в поле длины заголовка значение 5.

Поле ОБЩАЯ ДЛИНА дает длину IP-дейтаграммы, измеренную в октетах, включая октеты в заголовке и данных. Размер области данных может быть вычислен с помощью вычитания длины заголовка(ДЛИНА) из ОБЩЕЙ ДЛИНЫ. Так как поле ОБЩАЯ ДЛИНА занимает 16 бит, максимально возможный размер дейтаграммы IP - 65535 октетов. В большинстве приложений это ограничение несущественно. Но оно может стать важным в будущем, когда сети с более высокими скоростями смогут передавать пакеты данных длиннее чем 65535 октетов.

7.7.2 Тип сервиса для дейтаграммы и приоритет

8-битовое поле ТИП СЕРВИСА указывает, как следует обрабатывать дейтаграмму, и разделено на пять подполей, как показано на рисунке 7.4:

0          1        2    3     4      5       6       7
-------------------------------------------------------------
|   приоритет        |  D   |  T   |  R   | не используется |
-------------------------------------------------------------

Рисунок 7.4 Пять подполей, составляющих 8-битовое поле типа сервиса

Три бита ПРИОРИТЕТА указывают приоритет дейтаграммы, значения которого могут меняться от 0(обычный приоритет) до 7(управление сетью), позволяя отправителям передавать информацию о важности каждой дейтаграммы. Хотя программное обеспечение большинства ГВМ и шлюзов игнорирует тип сервиса, он является важным понятием, так как обеспечивает механизм, который впоследствии позволит управляющей информации иметь больший приоритет, чем данные. Например, если все ГВМ и шлюзы будут учитывать приоритет, станет возможной реализация алгоритмов управления перегрузкой сети, на которые не будет влиять перегрузка, которой они пытаются управлять.

Биты D, T и R описывают тип передачи, который нужен дейтаграмме. Установка бита D запрашивает минимальные задержки при передаче, бита T - максимальную пропускную способность, а бита R - максимальную надежность. Конечно, интернет не может гарантировать выполнение запрошенного сервиса(например, может быть так, что нет пути к назначению с запрошенными качествами). Поэтому, мы будем рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если шлюз знает более чем один маршрут к указанному назначению, он может использовать поле типа транспорта для выбора пути с характеристиками наиболее близкими требуемым. Например, предположим, что шлюз может выбирать между низкоскоростной арендованной линией или высокоскоростной(но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая таким образом самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, могут иметь установленным бит T, запрашивая передачу по высокоскоростной спутниковой линии.

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

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

7.7.3 Инкапсуляция дейтаграмм

Перед тем, как мы сможем понять следующие поля дейтаграммы, нам нужно рассмотреть, как дейтаграммы соотносятся с кадрами физической сети. Мы начнем с вопроса: "Каков максимальный размер дейтаграммы ?" В отличие от кадров физической сети, которые должны распознаваться оборудованием, дейтаграммы обрабатываются программным обеспечением. Они могут иметь любую длину, какую выберут разработчики протокола. Мы видели, что текущий формат дейтаграммы выделяет 16 бит под поле общей длины, ограничивая дейтаграмму 65535 октетами. Тем не менее, этот предел может быть изменен в следующих версиях протокола.

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

              -------------------------------------------------
              |заголовок     |   область данных дейтаграммы   |
              |дейтаграммы   |                                |
              -------------------------------------------------
              |                                               |
              V                                               V
    -----------------------------------------------------------
    |заголовок|                                               |
    |кадра    |          область данных кадра                 |
    -----------------------------------------------------------

Рисунок 7.5 Инкапсуляция IP-дейтаграммы в кадр. Физическая сеть рассматривает всю дейтаграмму, включая заголовок, как данные.

7.7.4 Размер дейтаграммы, сетевая МЕП(MTU) и фрагментация

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

Чтобы понять проблему, нам нужно знать одну вещь о сетевом оборудовании: каждая технология коммутации пакетов устанавливает фиксированную верхнюю границу количества данных, которые могут быть переданы в одном физическом кадре. Например, Ethernet ограничивает размер передачи 1500 октетами данных(ограничение в 1500 октетов взято из спецификации Ethernetа; использование заголовка SNAP со стандартом 802.3 ограничивает размер до 1492 октетов. Некоторое оборудование допускает несколько большие кадры), в то время как proNET-10 допускает кадры до 2044 октетов. Мы будем называть такие ограничения МАКСИМАЛЬНАЯ ЕДИНИЦА ПЕРЕДАЧИ(maximum transfer unit - MTU) или МЕП. Величина МЕП может быть довольно маленькой: некоторые аппаратные технологии ограничивают размер передачи до 128 октетов или даже меньше. Ограничение размера дейтаграмм до наименьшего МЕП в интернете делает передачу неэффективной, когда эти дейтаграммы передаются по сети, которая может транспортировать кадры большего размера. Тем не менее, разрешение дейтаграммам иметь размер больший, чем минимальный сетевой МЕП в интернете, означает, что дейтаграммы не всегда будут помещаться в один сетевой кадр.

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

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

     -------                                       -------
     |ГВМ  |                                       |ГВМ  |
     |  А  |                                       |  Б  |
     -------                                       -------
        |                                             |
  Сеть 1|                 + +                   Сеть 3|
 ---------------        +     +               ----------------
   МЕП=1500   | -----  + Сеть 2 +      -----  |   МЕП=1500
              --|Ш1 |--          +-----|Ш2 |---
                -----  + МЕП=620  +    -----
                        +     + +
                         + + +

Рисунок 7.6 Иллюстрация того, где происходит фрагментация. Шлюз Ш1 фрагментирует большие дейтаграммы, посылаемые от А к Б; Ш2 фрагментирует большие дейтаграммы, посылаемые от Б к А.

На рисунке оба ГВМ напрямую присоединения к Ethernetам, которые имеют МЕП в 1500 октетов. Поэтому оба ГВМ могут генерировать и посылать дейтаграммы до 1500 октетов длины. Путь между ними, тем не менее, включает сеть с МЕП, равным 620. Если ГВМ А посылает ГВМ Б дейтаграмму длиннее 620 октетов, шлюз Ш1 будет фрагментировать дейтаграмму. Аналогично, если Б посылает большую дейтаграмму А, шлюз Ш2 будет фрагментировать дейтаграмму. Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспортироваться в одном кадре. Кроме того, так как IP передает значение смещения данных в восьмерках октетов, размер фрагмента должен быть выбран кратным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее близкого к сетевой МЕП, не обязательно делит дейтаграмму на равные части; последняя часть часто короче, чем остальные. Фрагменты должны собираться для воссоздания полной копии исходной дейтаграммы перед тем, как она будет обрабатываться у получателя.

Протокол IP как не ограничивает дейтаграммы до маленького размера, так и не гарантирует, что большие дейтаграммы будут доставлены без фрагментации. Отправитель может выбрать любой размер дейтаграммы, какой он посчитает уместным; фрагментация и сборка производятся автоматически, не требуя специальных действий от отправителя. Спецификация IP устанавливает, что шлюзы должны принимать дейтаграммы с размерами, не превосходящими МЕП сетей, к которым они присоединены. Кроме того, шлюзы должны всегда обрабатывать дейтаграммы до 576 октетов. (От ГВМ также требуется принимать и собирать при необходимости дейтаграммы не короче 576 октетов).

Фрагментация дейтаграммы означает разделение ее на несколько частей. Вы можете удивиться, когда узнаете, что каждая часть имеет точно такой же формат, как и исходная дейтаграмма. Рисунок 7.7 иллюстрирует результат фрагментации.

------------------------------------------------------------
| заголовок   |     данные1  \   данные2      \ данные3    |
| дейтаграммы | 600 октетов  \   600 октетов  \200 октетов |
------------------------------------------------------------
                         (а)
------------------------------
|заголовок    |  данные1     |      фрагмент 1(смещение 0)
|фрагмента 1  |              |
------------------------------
------------------------------
|заголовок    |  данные2     |      фрагмент 2(смещение 600)
|фрагмента 2  |              |
------------------------------
-------------------------
|заголовок    |  данные3|           фрагмент 3(смещение 1200)
|фрагмента 3  |         |
-------------------------
                        (б)

Рисунок 7.7 (а) Исходная дейтаграмма. несущая 1400 октетов данных и (б) три фрагмента для сети с МЕП. равной 620. Заголовки 1 и 2 имеют установленный бит ЕЩЕ ФРАГМЕНТЫ. Смещения показаны в октетах, их нужно разделить на 8, чтобы получить значение, хранящееся в заголовках фрагментов.

Каждый фрагмент содержит заголовок дейтаграммы, который дублирует большую часть заголовка исходной дейтаграммы(кроме бита в поле ФЛАГИ, который показывает. что это фрагмент), и столько данных, сколько может содержать фрагмент, чтобы общая длина была меньше, чем МЕП сети, по которой он путешествует.

7.7.5 Сборка фрагментов

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

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

7.7.6 Управление фрагментацией

Три поля в заголовке дейтаграммы, ИДЕНТИФИКАЦИЯ, ФЛАГИ и СМЕЩЕНИЕ ФРАГМЕНТА, управляют фрагментацией и сборкой дейтаграмм. Поле ИДЕНТИФИКАЦИЯ содержит уникальное целое число, которое идентифицирует дейтаграмму. Напомним, что когда шлюз фрагментирует дейтаграмму, он копирует большую часть полей в заголовке дейтаграммы в каждый фрагмент. Поле ИДЕНТИФИКАЦИЯ должно копироваться. Его основная цель - позволить назначению узнать, что какой дейтаграмме принадлежат прибывающие фрагменты. Когда появляется фрагмент, назначение использует поле ИДЕНТИФИКАЦИЯ вместе с полем адреса источника для идентификации дейтаграммы. Компьютер, посылающий IP-дейтаграммы, должен генерировать уникальное значение для поля ИДЕНТИФИКАЦИЯ для каждой отдельной дейтаграммы(в теории, повторные передачи дейтаграммы должны содержать то же самое значение в поле ИДЕНТИФИКАЦИЯ, что и в исходной дейтаграмме; на практике, протоколы высокого уровня обычно выполняют повторную передачу как новую дейтаграмму со своей ИДЕНТИФИКАЦИЕЙ). Одна из технологий, используемых в программном обеспечении IP, хранит глобальный счетчик в памяти, инкрементирует его каждый раз, когда создается новая дейтаграмма, и копирует результат в поле ИДЕНТИФИКАЦИЯ дейтаграммы.

Напомним, что каждый фрагмент имеет точно такой же формат, что и полная дейтаграмма. Для фрагмента поле СМЕЩЕНИЕ ФРАГМЕНТА указывает смещение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряемое в 8 октетах(смещения измеряются в восьмерках октетов для сохранения места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы назначение должно получить все фрагменты, начиная с фрагмента со смещением 0 до фрагмента с наибольшим смещением. Фрагменты необязательно прибывают по порядку, и не существует взаимодействия между шлюзом, который фрагментирует дейтаграммы, и назначением, которое пытается собирать их.

Младшие два бита из трехбитового поля ФЛАГИ управляют фрагментацией. Обычно прикладное программное обеспечение, использующее TCP/IP, не заботится о фрагментации, так как и фрагментация, и сборка являются автоматическими процедурами, которые выполняются на низком уровне в операционной системе незаметно для пользователя. Тем не менее, для тестирования межсетевого программного обеспечения или отладки рабочих проблем может оказаться важной проверка размеров дейтаграмм, для которых осуществляется фрагментация. Первый управляющий бит помогает при таком тестировании, указывая возможность фрагментации дейтаграммы. Он называется битом НЕ ФРАГМЕНТИРОВАТЬ, так как установка его в единицу указывает, что дейтаграмму нельзя фрагментировать. Приложение может выбрать запрет фрагментации, когда нужна лишь целая дейтаграмма. Например, рассмотрим последовательность загрузки компьютера, при которой машина начинает выполнять небольшую программу в ПЗУ, которая использует интернет для запроса начального образа операционной системы, а другая машина посылает ей его. Если программное обеспечение разработано так, что ему нужно либо все, либо ничего, дейтаграмма должна иметь установленный бит НЕ ФРАГМЕНТИРОВАТЬ. Всякий раз, когда шлюзу нужно фрагментировать дейтаграмму с установленным битом НЕ ФРАГМЕНТИРОВАТЬ, шлюз удаляет дейтаграмму и посылает обратно источнику сообщение об ошибке.

Младший бит в поле ФЛАГИ указывает, содержит ли фрагмент данные из середины дейтаграммы или из конца. Он называется битом ЕЩЕ ФРАГМЕНТЫ. Чтобы увидеть, почему нужен этот бит, рассмотрим программное обеспечение IP у получателя, пытающееся собрать дейтаграмму. Оно будет получать фрагменты( возможно не по порядку) ,и ему нужно будет знать, когда оно получило все фрагменты дейтаграммы. Когда появляется еще один фрагмент, поле ОБЩАЯ ДЛИНА в заголовке указывает размер фрагмента, а не размер всей дейтаграммы, поэтому назначение не может использовать поле ОБЩАЯ ДЛИНА для того, чтобы определить, собрало ли оно все фрагменты. Бит ЕЩЕ ФРАГМЕНТЫ легко решает проблему: как только назначение получает фрагмент со сброшенным битом ЕЩЕ ФРАГМЕНТЫ, оно знает, что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На основе полей СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА оно может вычислить длину исходной дейтаграммы. Проверив СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА у всех прибывших фрагментов, получатель может определить, содержат ли фрагменты все данные, требуемые для сборки исходной дейтаграммы.

7.7.7 Время жизни(TTL)

Поле ВРЕМЯ ЖИЗНИ указывает сколько секунд может оставаться дейтаграмма в межсетевой системе. Эта идея является насколько простой, настолько и важной: всякий раз, когда машина передает дейтаграмму в интернет, она устанавливает максимальное время, которое может существовать дейтаграмма. Шлюзы и ГВМ, обрабатывающие дейтаграмму, должны декрементировать поле ВРЕМЯ ЖИЗНИ по мере того, как идет время, и удалять дейтаграмму из интернета, когда время вышло.

Оценить время точно трудно, так как шлюзы обычно не знают время передачи между физическими сетями. Несколько правил упрощают обработку и делают легкой обработку дейтаграмм без синхронизации часов. Во-первых, каждому шлюзу на пути от источника к назначению требуется декрементировать поле ВРЕМЯ ЖИЗНИ на единицу, когда он обрабатывает заголовок дейтаграммы. Более того, для обработки случаев перегруженных шлюзов, которые приводят к большим паузам при передаче, каждый шлюз хранит локальное время прихода дейтаграммы и декрементирует ВРЕМЯ ЖИЗНИ на число секунд, в течение которого дейтаграмма находилась в шлюзе, ожидая обслуживания.

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

7.7.8 Другие поля дейтаграммы

Поле ПРОТОКОЛ аналогично полю типа в кадре Ethernetа. Значение в поле ПРОТОКОЛ указывает, какой протокол высокого уровня использовался при создании сообщения, передаваемого в области ДАННЫЕ дейтаграммы. По существу, значение в ПРОТОКОЛ специфицирует формат области ДАННЫЕ. Отображение между протоколом высокого уровня и целым числом, используемым в поле ПРОТОКОЛ, должно администрироваться ответственным центром, чтобы гарантировать действие соглашения по всему интернету.

Поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА удостоверяет целостность значений полей заголовка. Контрольная сумма IP формируется путем представления заголовка как последовательности 16-битовых чисел( с сетевым порядком байт), сложения их вместе, используя арифметику с дополнительным представлением отрицательных чисел, и получения отрицания числа. При вычислении контрольной суммы поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА предполагается равным нулю. Стоит заметить, что эта контрольная сумма применима только к числам, находящимся в заголовке IP, а не в данных. Разделение контрольной суммы для заголовка и для данных имеет свои преимущества и недостатки. Так как заголовок обычно занимает меньше октетов, чем данные, наличие отдельной контрольной суммы для него уменьшает время обработки в шлюзах, которым требуется вычислять только контрольную сумму заголовка. Это разделение также позволяет протоколам более высокого уровня выбирать свои собственные схемы расчета контрольной суммы для данных. Главным недостатком является то, что протоколы более высокого уровня вынуждены добавлять свои контрольные суммы или рисковать тем, что они не смогут обнаружить искажения данных.

Поля АДРЕС ОТПРАВИТЕЛЯ IP и АДРЕС ПОЛУЧАТЕЛЯ IP содержат 32-битовые IP-адреса отправителя дейтаграммы и конечного получателя. Хотя дейтаграмма может проходить через большое число промежуточных шлюзов, поля отправителя и получателя никогда не изменяются; они указывают IP-адреса истинного источника и конечного назначения.

Поле, названное ДАННЫЕ на рисунке 7.3, показывает начало области данных в дейтаграмме. Его длина зависит, конечно, от того, что посылается в дейтаграмме.

Поле ОПЦИИ IP, рассматриваемое ниже, имеет переменную длину. Поле, названное ЗАПОЛНЕНИЕ, зависит от выбранных опций. Оно представляет собой биты, содержащие нули, которые могут потребоваться для дополнения заголовка дейтаграммы до длины, кратной 32 битам(напомним, что поле длины заголовка указывает ее в 32-битных словах).

7.8 Межсетевые опции дейтаграммы

Поле ОПЦИИ IP, следующее за адресом назначения, не требуется в каждой дейтаграмме; опции включаются, в основном, для тестирования или отладки сети. Обработка опций, тем не менее, является составной частью протокола IP, поэтому все стандартные реализации включают ее.

Длина поля ОПЦИИ IP меняется в зависимости от того, какие опции выбраны. Некоторые опции имеют длину один октет; они состоят из кода опции, занимающего один октет. Другие опции имеют переменную длину. Когда в дейтаграмме есть опции, они размещаются друг за другом, без специальных разделителей между ними. Каждая опция состоит из кода опции длиной в один октет, за которым может следовать длина опции(тоже занимает один октет) и группы октетов данных для этой опции. Октет кода опции делится на три поля, как показано на рисунке 7.8.

      0          1     2      3    4   5    6    7
----------------------------------------------------------
| КОПИРОВАТЬ | КЛАСС ОПЦИИ |   НОМЕР ОПЦИИ               |
----------------------------------------------------------

Рисунок 7.8 Разделение октета кода опции на три поля длиной 1, 2 и 5 бит.

Этими полями являются однобитовый флаг КОПИРОВАТЬ, двухбитовый КЛАСС ОПЦИИ и пятибитовый НОМЕР ОПЦИИ. Флаг КОПИРОВАТь управляет тем, как шлюзы рассматривают опции при фрагментации. Когда бит КОПИРОВАТЬ установлен в 1, он указывает, что эта опция должна копироваться во все фрагменты. Когда он установлен в 0, бит КОПИРОВАТь означает, что опцию нужно копировать только в первый фрагмент, а не во все.

Биты КЛАСС ОПЦИИ и НОМЕР ОПЦИИ указывают общий класс опции и номер опции внутри этого класса. Таблица на рисунке 7.9 показывает, как назначены номера классам.

Класс опции | Значение
0 | Управление дейтаграммой или сетью
1 | Зарезервировано
2 | Отладка и измерения
3 | Зарезервировано

Рисунок 7.9 Классы опций IP, закодированные в битах КЛАСС ОПЦИИ в октете кода опции.

Таблица на рисунке 7.10 приводит список возможных опций в IP-дейтаграммах и указывает для них значения КЛАССА ОПЦИИ и НОМЕРА ОПЦИИ. Как показывает этот список, большая часть опций используется для целей управления.

Класс опции | Номер опции | Длина | Описание
0 | 0 | - | Конец списка опций. Используется, если опция не заканчивается в конце заголовка(смотри также поле дополнения)
0 | 1 | - | Нет операции(используется для выравнивания октетов в списке опций)
0 | 2 | 11 | Секретность(для военных приложений)
0 | 3 | пер | Слабая маршрутизация источника. Используется для маршрутизации дейтаграммы по указанному пути.
0 | 7 | пер | Запись маршрута. Используется для трассировки маршрута
0 | 8 | 4 | Идентификатор потока. Используется для передачи идентификатора потока SATNET (недействительно)
0 | 9 | пер | Сильная маршрутизация источника Используется для маршрутизации дейтаграммы по указанному пути
2 | 4 | пер | Межсетевые временные метки. Используется для записи временных меток по маршруту

Рисунок 7.10 Восемь возможных опций IP с их числовыми кодами класса и номера. Значение пер в столбце длины означает переменная.

7.8.1 Опция записи маршрута

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

Как описано выше, поле КОД содержит номер опции и класс опции( 7 для записи маршрута). Поле ДЛИНА указывает общую длину опции в том виде, в котором она представлена в IP-дейтаграмме, включая первые три октета. Поля, начиная с поля, помеченного ПЕРВЫЙ IP-АДРЕС, составляют область, зарезервированную под хранение межсетевых адресов. Поле УКАЗАТЕЛЬ определяет смещение внутри опции первого свободного слота.

 0              8           16             24
 -------------------------------------------
 | КОД(7)      |  ДЛИНА     |  УКАЗАТЕЛЬ   |
 ----------------------------------------------------------
 |           Первый IP-адрес                             |
 ----------------------------------------------------------
 |           Второй IP-адрес                             |
 ----------------------------------------------------------
 |               .......                                 |
 ----------------------------------------------------------

Рисунок 7.11 Формат опции записи маршрута в IP-дейтаграмме

Всякий раз, когда машина обрабатывает дейтаграмму, имеющую опцию записи маршрута, она добавляет свой адрес к списку записи маршрута(в опции должно быть выделено достаточно места исходным отправителем для того, чтобы поместились все нужные элементы). При добавлении себя к списку машина сначала сравнивает поля указателя и длины. Если указатель больше, чем длина, то список полон, и машина отправляет дейтаграмму, не добавляя нового элемента. Если список не полон, машина вставляет 4-байтовый IP-адрес в позицию, определенную УКАЗАТЕЛЕМ, и увеличивает значение УКАЗАТЕЛЯ на четыре.

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

7.8.2 Опции пути источника

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

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

 0              8           16             24
 -------------------------------------------
 | КОД(137)    |  ДЛИНА    |  УКАЗАТЕЛЬ   |
 ----------------------------------------------------------
 |           Первый IP-адрес                             |
 ----------------------------------------------------------
 |           Второй IP-адрес                             |
 ----------------------------------------------------------
 |               .......                                 |
 ----------------------------------------------------------

Рисунок 7.12 Опция строгой маршрутизации источника определяет точный путь с помощью списка IP-адресов, которые должна пройти дейтаграмма.

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

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

Формат опции маршрутизации источника напоминает показанный выше формат опции записи маршрута. Каждый шлюз проверяет поля УКАЗАТЕЛЬ и ДЛИНА, чтобы обнаружить переполнение списка. Если оно произошло, указатель будет больше, чем длина, и шлюз будет маршрутизировать дейтаграмму к ее назначению обычным образом. Если список заполнен еще не до конца, шлюз на основании указателя выделяет IP-адрес, заменяет его на адрес шлюза(шлюз имеет по одному адресу для каждого интерфейса; он записывает адрес, соответствующий сети, по которой он отправляет дейтаграмму) и маршрутизирует дейтаграмму, используя адрес, полученный из списка.

7.8.3 Опция временных меток

Опция временных меток работает аналогично опции записи маршрута в том отношении, что опция временных меток содержит вначале пустой список, а каждый шлюз на всем протяжении пути от источника к назначению заполняет элемент в этом списке. Каждый элемент в списке состоит из двух 32-битных частей: IP-адреса шлюза, заполнившего этот элемент, и 32-битового целого числа - временной метки. Рисунок 7.13 приводит формат опции временных меток.

 0              8           16             24            31
 ----------------------------------------------------------
 | КОД(68)     |  ДЛИНА    |  УКАЗАТЕЛЬ   |ПЕРЕП | ФЛАГИ |
 ----------------------------------------------------------
 |           Первый IP-адрес                             |
 ----------------------------------------------------------
 |           Первая временная метка                       |
 ----------------------------------------------------------
 |               .......                                 |
 ----------------------------------------------------------

Рисунок 7.13 Формат опции временных меток. Биты в поле ФЛАГИ определяют точный формат и правила, применяемые шлюзами при обработке этой опции.

На рисунке поля ДЛИНА и УКАЗАТЕЛЬ используются для указания длины зарезервированного места и местонахождения следующего неиспользованного слота( как в опции записи маршрута). 4-битовое поле ПЕРЕП содержит целое число шлюзов, которые не смогли записать временные метки из-за слишком маленького размера опции. Значение в 4-битовом поле ФЛАГИ определяет точный формат опции и говорит шлюзам, как записывать временные метки. Допускаются следующие значения:

Значение | Смысл
0 | Только запись временных меток, IP-адреса опускаются
1 | Указывать перед каждой временной меткой IP-адрес (формат, показанный на рисунке 7.13)
3 | IP-адреса указываются отправителем, шлюз только записывает временную метку, если следующий IP-адрес в списке соответствует IP-адресу шлюза.

Рисунок 7.14 Интерпретация значений поля ФЛАГИ в опции временные метки.

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

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

7.8.4 Обработка опций при фрагментации

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

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

7.9 Итоги

Фундаментальным средством, обеспечиваемым программным обеспечением TCP/IP , является ненадежная система доставки пакетов без установления соединения. Межсетевой протокол(IP) формально определяет формат межсетевых пакетов, называемых дейтаграммами, и неформально воплощает в себе идеи доставки без установления соединения. Эта глава была сосредоточена главным образом на форматах дейтаграмм; следующие главы рассмотрят маршрутизацию IP и обработку ошибок.

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

Для дальнейшего изучения

  • Postel[1980] обсуждает возможные подходы к межсетевым протоколам, адресации и маршрутизации. В более поздней публикации Postel[RFC 791] дает стандарт Межсетевого Протокола, а Hornig[RFC 894] определяет стандарт передачи IP-дейтаграмм по Ethernetу.
  • Clark[RFC 815] описывает эффективную сборку фрагментов. Помимо формата пакета, ответственные лица в Интернете определяют много констант, требуемых для сетевых протоколов. Эти значения можно найти в Reynolds и Postel[RFC 1010]. Kent и Mogul[1987] рассматривают недостатки фрагментации.
  • Альтернативная связка межсетевых протоколов, известная как XNS, описана в Xerox[1981]. Boggs et al[1980] описывает Универсальный Пакетны протокол PARC(PUP) , абстракцию из XNS, близко связанную с IP-дейтаграммой.

Упражнения

7.1 Что является самым большим достоинством контрольной суммы IP, учитывающей только заголовок, но не данные ? А недостатком ?

7.2 Нужно ли использовать контрольную сумму IP при посылке пакетов по Ethernetу ?

7.3 Каково значение МЕП для MILNET ? NSFNET ? X25NET ?Hyperchannel ?

7.4 Как вы думаете , больший или меньший размер МЕП будут иметь высокоскоростные локальные сети по сравнению с более медленными глобальными сетями ?

7.5 Докажите, что фрагменты должны иметь маленькие, нестандартные заголовки.

7.6 Установите, когда в последний раз менялась версия протокола IP. Имеет ли смысл на самом деле иметь номер версии протокола ?

7.7 Можете ли вы догадаться, почему для IP была выбрана контрольная сумма с дополнением до единицы вместо циклической проверки ?

7.8 Каковы преимущества сборки в месте конечного назначения вместо сборки после того, как дейтаграмма пересекла одну сеть ?

7.9 Какой минимальный МЕП требуется для посылки дейтаграммы IP, содержащей по крайней мере один октет данных ?

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

7.11 Если вы имеете доступ к реализации IP, изучите ее и проверьте доступные вам реализации IP на предмет удаления ими дейтаграмм с устаревшим номером версии.


Глава 8 Межсетевой протокол: маршрутизация IP-дейтаграмм

  • 8.1 Введение
  • 8.2 Маршрутизация в Интернете
  • 8.3 Прямая и косвенная доставка
    • 8.3.1 Доставка дейтаграммы по одной сети
    • 8.3.2 Косвенная маршрутизация
  • 8.4 IP-маршрутизация на основе таблиц
  • 8.5 Маршруты по умолчанию
  • 8.6 Маршруты, специфичные для ГВМ
  • 8.7 Итоговый алгоритм
  • 8.8 Маршрутизация для IP-адресов
  • 8.9 Обработка приходящих дейтаграмм
  • 8.10 Работа с таблицами маршрутизации
  • 8.11 Итоги
  • Для дальнейшего изучения
  • Упражнения

8.1 Введение

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

8.2 Маршрутизация в Интернете

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

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

Маршрутизация в интернете может быть сложной, особенно между машинами с несколькими физическими сетевыми соединениями. В идеале программное обеспечение маршрутизации должно учитывать такие вещи, как загрузка сети, длина дейтаграммы, или тип сервиса, указанный в заголовке дейтаграммы, при выборе наилучшего пути. Тем не менее, большинство программного обеспечения межсетевой маршрутизации гораздо менее сложное, и выбирает пути на основе фиксированных предположений о самых коротких путях. Чтобы полностью понять IP-маршрутизацию, мы должны вернуться назад и вспомнить архитектуру интернета TCP/IP. Во-первых, напомним, что интернет состоит из группы физических сетей, соединенных компьютерами, называемыми шлюзами. Каждый шлюз имеет прямое соединение с двумя или более сетями. В отличие от шлюза, ГВМ обычно соединен напрямую только с одной физической сетью. Тем не менее, мы знаем, что возможно существование многоадресных ГВМ, которые соединены напрямую с несколькими сетями.

Как ГВМ, так и шлюзы участвуют в IP-маршрутизации. Когда прикладная программа на ГВМ пытается организовать взаимодействие, протоколы TCP/IP в конечном счете генерируют одну или несколько IP-дейтаграмм. ГВМ должен принять решение о маршруте, когда он выбирает, куда послать дейтаграмму. Как показывает рисунок 8.1, ГВМ должны принять решение, даже если они имеют только одно соединение с сетью.

        ^ к одним                ^   к другим
        |   ГВМ                  |     ГВМ
      -----                    -----
      | Ш1|                    | Ш2|
      -----                    -----
        |                        |
--------------------------------------------------------
                    |
                  -----
                  |ГВМ|
                  -----

Рисунок 8.1 Пример одноадресного ГВМ, который должен маршрутизировать дейтаграммы. Он должен выбрать, послать ли дейтаграмму шлюзу Ш1 или шлюзу Ш2, так как нет одного шлюза, обеспечивающего наилучший путь ко всем назначениям.

Конечно, шлюзы должны принимать решения об IP-маршрутизации (это их основная задача и причина того, что их назвали маршрутизаторами). А как же многоадресные ГВМ ? Любой компьютер с несколькими сетевыми соединениями может выступать в роли шлюза, и как мы увидим позже, многоадресные ГВМ с сетевым программным обеспечением TCP/IP имеют все необходимое для маршрутизации. Более того, локальные сети, в которых нет возможности выделить отдельные компьютеры под шлюз, часто используют компьютеры общего назначения с разделением времени в роли как ГВМ, так и шлюза ( эта практика особенно распространена в университетах). Тем не менее, стандарты TCP/IP делают различие между этими функциями в ГВМ и шлюзе, а в сетях, пытающихся смешивать функции ГВМ и шлюза в одной машине, иногда обнаруживается, что многоадресные шлюзы участвуют в неожиданных взаимодействиях. А пока, мы будем различать ГВМ и шлюзы, и предполагать, что ГВМ не реализуют функцию шлюза по передаче пакетов из одной сети в другую.

8.3 Прямая и косвенная доставка

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

8.3.1 Доставка дейтаграммы по одной сети

Мы знаем, что одна машина в данной физической сети может послать физический кадр напрямую другой машине в этой же сети. Для передачи IP-дейтаграмм отправитель инкапсулирует дейтаграмму в физический кадр, отображает IP-адрес назначения в физический адрес, и использует сетевое оборудование для его доставки. Глава 5 представила два возможных механизма при разрешении адресов, включая использование протокола ARP для динамического связывания пар адресов в Ethernet-подобных сетях. Глава 7 рассмотрела инкапсуляцию дейтаграмм. Поэтому мы знаем теперь все необходимое для понимания прямой доставки. Обобщим:

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

Откуда отправитель узнает, что получатель находится в сети, к которой он присоединен ? Ответ прост. Мы знаем, что IP-адреса делятся на номер сети и номер ГВМ в сети. Чтобы определить, находится ли назначение в одной из сетей, к которым он присоединен, отправитель выделяет сетевую часть IP-адреса назначения и сравнивает ее с сетевой частью своего IP-адреса(ов). Совпадение означает, что дейтаграмму можно послать напрямую. Здесь мы видим одно из преимуществ схемы адресации Интернета, а именно:

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

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

8.3.2 Косвенная маршрутизация

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

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

Шлюзы в интернете TCP/IP образуют взаимодействующую и связанную структуру. Дейтаграммы передаются от шлюза к шлюзу до тех пор, пока они не достигнут шлюза, который может доставить дейтаграмму напрямую.

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

8.4 IP-маршрутизация на основе таблиц.

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

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

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

Использование номера сети в адресе назначения вместо полного адреса ГВМ делает маршрутизацию эффективно, а таблицы маршрутизации маленькими. Более того, оно помогает скрыть информацию о конкретных ГВМ в локальной среде, к которой эти ГВМ присоединены. Обычно таблица содержит пары (N,G), где N - это IP-адрес сети назначения, а G - IP-адрес следующего шлюза на пути к сети N. Поэтому, таблица маршрутизации в шлюзе G определяет только один шаг на пути от G к сети назначения - шлюз не знает полный путь к назначению.

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

Рисунок 8.2 показывает конкретный пример, который помогает понять таблицы маршрутизации. Интернет в этом примере состоит из четырех сетей, соединенных тремя шлюзами. На рисунке показана таблица маршрутизации, используемая шлюзом G. Так как G присоединен напрямую к сетям 20.0.0.0 и 30.0.0.0, он может достичь любой ГВМ в этих сетях напрямую(возможно используя ARP для нахождения физического адреса). Получив дейтаграмму, предназначенную ГВМ в сети 40.0.0.0, G маршрутизирует ее в адрес 30.0.0.7, адрес шлюза H. H затем доставит дейтаграмму напрямую. G может достичь адреса 30.0.0.7, так как и G, и H присоединены к сети 30.0.0.0.

              20.0.0.5      30.0.0.6       40.0.0.7
                 |             |              |
   ----------    V----------   V----------    V----------
   | Сеть   | --- | Сеть  | --- |  Сеть  | --- |  Сеть  |
   |10.0.0.0|-|F|-|20.0.0.0|-|G|-|30.0.0.0|-|H|-|40.0.0.0|
   |        | --- |       | --- |        | --- |        |
   ----------^    ----------^   ----------^    ----------
             |              |             |
         10.0.0.5      20.0.0.6        30.0.0.7
                     (а)
 Чтобы достичь      Маршрутизировать
 ГВМ в сети         к адресу
  20.0.0.0           прямая доставка
  30.0.0.0           прямая доставка
  10.0.0.0           20.0.0.5
  40.0.0.0           30.0.0.7
                (б)

Рисунок 8.2 (а) Демонстрационный интернет с 4 сетями и 3 шлюзами, и (б) таблица маршрутизации для шлюза G

Как показывает рисунок 8.2, размер таблицы маршрутизации зависит от числа сетей в интернете; он увеличивается только при добавлении новых сетей. Тем не менее, размер таблицы и ее содержимое не зависят от числа отдельных ГВМ, присоединенных к сетям. Мы можем сформулировать следующий принцип:

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

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

8.5 Маршруты по умолчанию

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

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

8.6 Маршруты, специфичные для ГВМ

Хотя мы сказали, что вся маршрутизация основывается на сетях, а не на отдельных ГВМ, большая часть программного обеспечения IP-маршрутизации позволяет указывать как особый случай маршруты для отдельных ГВМ. Наличие маршрутов для ГВМ предоставляет администратору локальной сети большие возможности по слежению за использованием сети и может быть использовано для наблюдения за доступом к сети и обеспечения секретности. При отладке сетевых соединений или таблиц маршрутизации способность указывать специальный путь для отдельной машины оказывается особенно полезной.

8.7 Итоговый алгоритм

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

Алгоритм:

Маршрутизир_дейтаграмму_IP(дейтаграмма,таблица_маршрутизации)
  • Выделить IP-адрес назначения, Id, из дейтаграммы
  • Вычислить IP-адрес сети назначения,In
  • Если In соответствует адресу одной из достижимых напрямую сетей, послать дейтаграмму к назначению по этой сети; (это включает разрешение Id в физический адрес, инкапсуляцию дейтаграммы и посылку кадра) иначе если для Id определен маршрут, специфичный для ГВМ маршрутизировать дейтаграмму, как это определено в таблице; иначе если In определено в таблице маршрутизации маршрутизировать дейтаграмму, как это определено в таблице; иначе если указан маршрут по умолчанию маршрутизировать дейтаграмму к шлюзу по умолчанию; иначе выдать сообщение об ошибке при маршрутизации;

Рисунок 8.3 Алгоритм IP-маршрутизации. Имея в качестве исходных данных IP-дейтаграмму и таблицу маршрутизации, этот алгоритм выбирает следующую машину, на которую будет послана дейтаграмма. Таблицы маршрутизации всегда указывают в качестве следующей машины ту, что находится в сети, достижимой напрямую.

8.8 Маршрутизация для IP-адресов

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

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

Может показаться странным, что таблицы маршрутизации хранят IP-адрес следующей попытки для каждой сети назначения, в то время как эти адреса должны транслироваться в соответствующие физические адреса перед посылкой дейтаграммы. Если мы представим ГВМ, посылающий последовательность дейтаграмм одному и тому же назначению, такое использование IP-адресов будет явно неэффективным. IP послушно выделяет адрес назначения в каждой дейтаграмме и использует таблицу маршрутизации для определения адреса следующей попытки. Затем он передает дейтаграмму и адрес следующей попытки сетевому интерфейсу, который находит физический адрес. Если бы таблица маршрутизации использовала физические адрес, определение соответствия между IP-адресом следующей попытки и физическим адресом могло бы выполняться лишь один раз. Почему же программное обеспечение IP избегает пользоваться физическими адресами при хранении и вычислении маршрутов ? Как показывает рисунок 8.4, существуют две важные причины.

ПРОВЕРКА ИЛИ                     МАРШРУТИЗИРУЕМАЯ
ОБНОВЛЕНИЕ МАРШРУТОВ            |   ДЕЙТАГРАММА
                                V
 ----------------          ----------------
 |  таблица     |         / алгоритм       \
 | маршрутизации|--------->| маршрутизации   |
 |              |         \ в IP            /
 ----------------          \---------------/
                                |
 используются IP-адреса         |
   -------------------------------------------------------------
 используются физические адреса  | отправляемая дейтаграмма и
                                V адрес следующей попытки

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

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

Рисунок 8.4 показывает границу адресов, важную концептуальную границу между низкоуровневым программным обеспечением, понимающим физические адреса, и межсетевым программным обеспечением, использующим только высокоуровневые адреса. Выше этой границы все программное обеспечение для взаимодействия может быть написано с использованием только межсетевых адресов; знание физических адресов предоставляется нескольким небольшим низкоуровневым процедурам. Мы увидим, что выделение этой границы также помогает сделать реализацию остальных протоколов TCP/IP легкой для понимания, проверки и модификации.

8.9 Обработка приходящих дейтаграмм

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

Когда IP-дейтаграмма прибывает на ГВМ, программное обеспечение сетевого интерфейса доставляет ее программному обеспечению IP для обработки. Если адрес назначения дейтаграммы соответствует IP-адресу ГВМ, программное обеспечение IP на ГВМ принимает дейтаграмму и передает ее программе протокола более высокого уровня для дальнейшей обработки. Если же IP-адрес назначения не соответствует ему, ГВМ требуется уничтожить дейтаграмму(то есть ГВМ не позволяется пытаться маршрутизировать дейтаграммы, по ошибке пришедшие не на ту машину).

В отличие от ГВМ, шлюзы выполняют маршрутизацию. Когда

IP-дейтаграмма прибывает на шлюз, она доставляется программному обеспечению IP. И снова можно выделить два варианта: дейтаграмма может быть доставлена к ее конечному назначению, или ее нужно отправить путешествовать дальше. Как и на ГВМ, если IP-адрес назначения дейтаграммы соответствует собственному IP-адресу шлюза, программное обеспечение IP передает дейтаграмму программному обеспечению более высокого уровня для обработки(обычно, единственными дейтаграммами, предназначающимися шлюзу, являются те, что используются для проверки достижимости и те, что несут команды администрирования шлюзом). Если дейтаграмма еще не достигла своего конечного назначения, IP маршрутизирует ее, используя стандартный алгоритм и информацию из локальной таблицы маршрутизации.

Определение того, достигла ли IP-дейтаграмма своего конечного назначения или нет, не так тривиально, как это может показаться. Напомним, что даже ГВМ может иметь несколько физических соединений, и каждое из них имеет свой IP-адрес. Когда прибывает IP-дейтаграмма, машина должна сравнить межсетевой адрес назначения с IP-адресом каждого из своих сетевых соединений. Если для какого-либо из них соответствие найдено, шлюз сохраняет дейтаграмму и обрабатывает ее. Машина также должна принимать широковещательные дейтаграммы из физических сетей, если их IP-адрес назначения является IP-адресом ограниченного широковещания или IP-адресом направленного широковещания для этой сети. Как мы увидим в главах 16 и 17, подсети и многоадресные адреса делают распознавание адресов достаточно сложным. В любом случае, если адрес не соответствует ни одному из адресов этой машины, IP декрементирует поле времени жизни в заголовке дейтаграммы и удаляет дейтаграмму, если этот счетчик достиг нуля, или вычисляет новую контрольную сумму и маршрутизирует дейтаграмму, если счетчик больше нуля.

Должна ли каждая машина маршрутизировать дейтаграммы, которые она получает ? Ясно, что шлюзы должны маршрутизировать приходящие дейтаграммы, так как это их основная задача. Мы также говорили, что некоторые многоадресные ГВМ ведут себя как шлюзы, даже если они на самом деле компьютеры общего назначения. Хотя использование ГВМ в качестве шлюза обычно неразумно, если кто-то все же сделал это, то ГВМ должен быть сконфигурирован так, чтобы маршрутизировать дейтаграммы так же, как это делает шлюз. А как же остальные ГВМ, не предназначенные для использования в качестве шлюзов ? Ответ будет следующий: ГВМ, не используемые в качестве шлюзов, не должны маршрутизировать приходящие на них дейтаграммы; они должны уничтожать их.

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

8.10 Работа с таблицами маршрутизации

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

8.11 Итоги

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

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

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

Для дальнейшего изучения

Маршрутизация - это важный раздел. Frank и Chou[1971], а также Schwartz и Stern[1980] рассматривают маршрутизацию в целом; Postel[1980] рассматривает межсетевую маршрутизацию. Braden и Postel[RFC 1009] дают краткое изложение того, как шлюзы Интернета обрабатывают IP-дейтаграммы. Narten[1989] содержит обзор маршрутизации в Интернете. Fultz и Kleinrock[1971] анализируют схемы адаптивной маршрутизации; и McQuillan, Richer и Rosen[1980] описывают алгоритм адаптивной маршрутизации в ARPANET.

Часто рассматривалась идея использования политических соглашений для формулирования правил о маршрутизации. Leiner[RFC 1124] рассматривает соглашения для взаимосвязанных сетей.

Braun[RFC 1104] обсуждает модели политики маршрутизации для интернетов, Rekhter[RFC 1092] затрагивает вопрос о политике маршрутизации во второй магистральной сети NSFNET, и Clark[RFC 1102] описывает использование политики маршрутизации для IP.

Упражнения

8.1 Опишите таблицы маршрутизации для всех шлюзов из рисунка

8.1. В чем заключается основная выгода использования маршрутов по

умолчанию ?

8.2 Изучите алгоритм маршрутизации, используемы в UNIX BSD

4.3. Учитывает ли он все случаи, описанные здесь ? Рассматривает ли он какие-либо не описанные случаи ?

8.3 Что делает шлюз с полем ВРЕМЯ ЖИЗНИ из заголовка IP ?

8.4 Рассмотрим машину с двумя физическими сетевыми соединениями и двумя IP-адресами I1 и I2. Может ли эта машина получить дейтаграмму, назначенную I2 из сети с адресом I1 ? Объясните.

8.5 Рассмотрим две ГВМ, А и В, которые присоединены к одной физической сети, N. Может ли А при использовании нашего алгоритма маршрутизации получить дейтаграмму, предназначенную В ? Объясните.

8.6 Модифицируйте алгоритм маршрутизации для учета опций маршрутизации источника IP, описанных в главе 7.

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

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

8.9 Возможно ли адресовать дейтаграмму на IP-адрес шлюза ? Имеет ли смысл так делать ?

8.10 Рассмотрим модифицированный алгоритм маршрутизации, который проверяет маршруты для отдельных ГВМ на прямую доставку. При каких условиях этот алгоритм будет выгоден?

8.11 Поиграем в детектив: после наблюдения за траффиком IP в локальной сети в течение 10 минут в вечернее время кто-то заметил, что все кадры, предназначенные машине А, содержат IP-дейтаграммы, которые имеют адрес назначения, совпадающий с IP-адресом А, в то время как все кадры, предназначенные машине В, несут IP-дейтаграммы с назначением, отличным от IP-адреса В. Объясните.

8.12 Как вы можете изменить формат дейтаграммы IP для поддержки высокоскоростной коммутации пакетов в шлюзах ? Указание: шлюз должен перевычислять контрольную сумму заголовка после декремента поля времени жизни.

8.13 Сравните протокол доставки без установления соединения ISO(стандарт ISO 8473) с IP. Насколько хорошо протокол ISO поддерживает высокоскоростную коммутацию пакетов ? Указание: поля переменной длины избыточны.


Глава 9 Межсетевой протокол: Ошибки и Управляющие сообщения(ICMP)

  • 9.1 Введение
  • 9.2 Межсетевой протокол управляющих сообщений
  • 9.3 Сообщение об ошибке против исправления ошибки
  • 9.4 Доставка сообщения ICMP
  • 9.5 Формат сообщения ICMP
  • 9.6 Тестирование достижимости назначения и его состояния
  • 9.7 Формат сообщения запроса эха и ответа эха
  • 9.8 Сообщения о недостижимости назначения
  • 9.9 Управление потоком дейтаграмм и переполнение сети
  • 9.10 Формат подавления источника
  • 9.11 Запросы изменения маршрута от шлюзов
  • 9.12 Обнаружение циклических или слишком длинных путей
  • 9.13 Сообщения о других ситуациях
  • 9.14 Синхронизация часов и оценка времени передачи
  • 9.15 Сообщения запроса и ответа информации
  • 9.16 Получение маски подсети
  • 9.17 Итоги
  • Для дальнейшего изучения
  • Упражнения

9.1 Введение

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

9.2 Межсетевой протокол управляющих сообщений

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

Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.

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

Межсетевой Протокол Управляющих Сообщений позволяет шлюзам посылать управляющие сообщения или сообщения об ошибках на другие шлюзы или ГВМ; ICMP обеспечивает взаимодействие между программным обеспечением Межсетевого Протокола разных машин.

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

9.3 Сообщение об ошибке против исправления ошибки

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

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

Большая часть ошибок исходит от первоначального источника, но другие - нет. Так как ICMP сообщает об ошибках первоначальному источнику, он не может использоваться, чтобы информировать промежуточные шлюзы об ошибках. Например, представим, что дейтаграмма следует по пути через шлюзы G1,G2,...,Gk. Если Gk содержит некорректную информацию о маршрутах и ошибочно отправит дейтаграмму на шлюз Gе, то Ge может лишь сообщить об ошибке первоначальному источнику. К сожалению, источник не отвечает за эту проблему и не может управлять некорректно ведущим себя шлюзом. Фактически, источник не сможет даже определить, какой шлюз вызвал эту проблему.

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

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

9.4 Доставка сообщения ICMP

Сообщения ICMP требуют двух уровней инкапсуляции, как показано на рисунке 9.1. Каждое сообщения ICMP передается по интернету в поле данных IP-дейтаграммы, которая сама передается по каждой физической сети в поле данных кадра. Дейтаграммы, несущие сообщения ICMP маршрутизируются точно так же, как и дейтаграммы, несущие информацию для пользователей; для них не используются дополнительные приоритет или надежность. Поэтому, сами сообщения об ошибках могут быть потеряны или удалены. Более того, в уже переполненной сети сообщения об ошибках могут вызвать дополнительное переполнение. Исключение делается для процедур обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP, вызвала ошибку. Это исключение, установленное для того, чтобы избежать проблемы появления сообщений об ошибках, вызванных в свою очередь сообщениями об ошибках, определяет, что сообщения ICMP не генерируются для ошибок, появившихся из-за дейтаграмм, несущих сообщения об ошибках ICMP.

                    --------------------------------------
                    |заголовок  |    данные  ICMP       |
                    | ICMP      |                       |
                    --------------------------------------
                    V                                   V
         -------------------------------------------------
         | заголовок|    область данных дейтаграммы     |
         |дейтаграмм|                                   |
         -------------------------------------------------
         V                                              V
-----------------------------------------------------------
|заголовок|        область данных кадра                  |
|кадра    |                                              |
-----------------------------------------------------------

Рисунок 9.1 Два уровня инкапсуляции ICMP. Сообщение ICMP инкапсулируется в IP-дейтаграмме, которая в свою очередь инкапсулируется в кадре для передачи. Для идентификации ICMP поле протокола дейтаграммы содержит значение 1.

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

9.5 Формат сообщения ICMP

Хотя каждое сообщение ICMP имеет свой собственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД, которое обеспечивает более точную информацию о типе сообщения, и 16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый аддитивный алгоритм, что и IP, но контрольная сумма ICMP учитывает только сообщение ICMP). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку.

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

Поле ТИП ICMP определяет смысл сообщения, а также его формат. Эти типы включают:

Поле ТИП | Тип сообщения ICMP
0 | Ответ на эхо
3 | Назначение недостижимо
4 | Подавление источника
5 | Переназначение(изменение маршрута)
8 | Запрос эха
11 | Превышено время для дейтаграммы
12 | Ошибка параметра в дейтаграмме
13 | Запрос временной отметки
14 | Ответ для временной метки
15 | Запрос информации(не действует)
16 | Ответ на запрос информации(не действует)
17 | Запрос маски адреса
18 | Ответ на запрос маски адреса

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

9.6 Тестирование достижимости назначения и его состояния

Протоколы TCP/IP обеспечивают средства, помогающие сетевым администраторам или пользователям идентифицировать проблемы в сети. Одно из самых наиболее используемых средств отладки вызывает сообщения ICMP запрос эха и ответ эха. ГВМ или шлюз посылает сообщение запроса эха указанному месту назначения. Любая машина, получившая запрос эха, генерирует ответ на эхо и возвращает его первоначальному отправителю. Этот запрос содержит необязательную область данных; ответ содержит копию данных, посланных в запросе. Запрос эха и связанный с ним ответ могут использоваться для проверки достижимости назначения и его способности отвечать на запросы. Так как и запрос эха, и ответ на него передаются в IP-дейтаграммах, успешный прием ответа свидетельствует о работоспособности основных частей транспортной системы. Во-первых, программное обеспечение IP на машине источника произвело маршрутизацию дейтаграммы. Во-вторых, промежуточные шлюзы между источником и получателем работоспособны и корректно маршрутизируют дейтаграммы. В-третьих, машина получателя работает (по крайней мере, она обрабатывает прерывания) и программное обеспечение как IP, так и ICMP выполняет свои функции. И наконец, таблицы маршрутов в шлюзах на всем обратном пути корректны.

Во многих системах команда, которую пользователи вызывают для посылки запроса эха ICMP, называется ping. Усложненные версии этой программы посылают серии запросов эха ICMP, принимают ответы и выдают статистику о потерях дейтаграмм. Они позволяют пользователю указывать длину посылаемых данных и интервалы времени между запросами. Менее сложные версии просто посылают запрос эха ICMP и ждут ответа.

9.7 Формат сообщения запроса эха и ответа эха

Рисунок 9.2 содержит формат сообщений запроса эха и ответа на запрос эха.

0            8            16
------------------------------------------------------------
|тип(8 или 0)| код(0)      |   Контрольная сумма          |
------------------------------------------------------------
|    идентификатор         | последовательный номер       |
------------------------------------------------------------
|         необязательные данные                           |
------------------------------------------------------------
|                   ......                                |
------------------------------------------------------------

Рисунок 9.2 Формат сообщения запроса эха и ответа на него

Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину и содержит данные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются отправителем для проверки соответствия ответов запросам. Значение поля ТИП определяет, является ли сообщение запросом(8) или ответом(0).

9.8 Сообщения о недостижимости назначения

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

0            8            16
------------------------------------------------------------
|тип(3)      | код(0-5)    |   Контрольная сумма          |
------------------------------------------------------------
|    не используется(должно быть равно нулю)              |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы    |
------------------------------------------------------------
|                   ......                                |
------------------------------------------------------------

Рисунок 9.3 Формат сообщения о недостижимости назначения

Поле КОД в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможны следующие значения:

Значение | Смысл
0 | Сеть недостижима
1 | ГВМ недостижим
2 | Протокол недостижим
3 | Порт недостижим
4 | Требуется фрагментация
5 | Ошибка при маршрутизации источника
6 | Сеть назначения неизвестна
7 | ГВМ назначения неизвестен
8 | ГВМ источника изолирован
9 | Взаимодействие с сетью назначения административно запрещено
10 | Взаимодействие с ГВМ назначения административно запрещено
11 | Сеть недостижима из класса обслуживания
12 | ГВМ недостижим из-за класса обслуживания

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

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

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

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

9.9 Управление потоком дейтаграмм и переполнение сети

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

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

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

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

9.10 Формат подавления источника

Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4 иллюстрирует этот формат. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот запрос подавления источника.

0            8            16                              31
------------------------------------------------------------
|тип(4)      | код(0)      |   Контрольная сумма           |
------------------------------------------------------------
|    не используется(должно быть равно нулю)               |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы     |
------------------------------------------------------------
|                   ......                                 |
------------------------------------------------------------

Рисунок 9.4 Формат сообщения о подавлении источника ICMP. Переполненные шлюзы посылают одно сообщение о подавлении источника каждый раз, когда они удаляют дейтаграмму; префикс дейтаграммы идентифицирует удаленную дейтаграмму.

9.11 Запросы изменения маршрута от шлюзов

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

Предполагается, что шлюзы знают корректные маршруты; ГВМ начинают работать, имея минимум информации о маршрутах, но впоследствии узнают новые маршруты от шлюзов.

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

Сообщения о переназначении, тем не менее, не решают проблему распространения информации о маршрутах полностью, так как они предназначены только для взаимодействия между шлюзом и ГВМ в одной физической сети. Рисунок 9.5 иллюстрирует эту проблему. Согласно рисунку предполагается, что источник И посылает дейтаграмму назначению Н. Пусть шлюз Ш1 некорректно направляет дейтаграмму через шлюз Ш2 вместо шлюза Ш4(то есть Ш1 по ошибке выбрал более длинный путь). Когда шлюз Ш5 принимает дейтаграмму, он не может послать сообщение переназначения ICMP Ш1, так как он не знает адрес шлюза Ш1. Последующие главы рассмотрят проблему, как распространяется информация о маршрутах между несколькими сетями.

          |   --  |  --  |
     --   |--|Ш1|-|-|Ш2|-|  --  |        |
    | И|--|   --  |  --  |-|Ш3|-|    --  |
     --   |       |         --  |---|Ш5|-|   --
          |       |     --      |    --  |--| Н|
          |       |----|Ш4|-----|        |   --
          |       |     --      |

Рисунок 9.5 Сообщения о переназначении ICMP не помогают маршрутизации между шлюзами. В этом примере шлюз Ш5 не может заставить Ш1 использовать более короткий путь для дейтаграмм между И и Н.

Помимо полей-реквизитов ТИП, КОД и КОНТРОЛЬНАЯ СУММА, каждое сообщение о переназначении содержит 32-битовое поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА и поле ПРЕФИКС ДЕЙТАГРАММЫ, как это показано на рисунке 9.6

0            8            16                              31
------------------------------------------------------------
|тип(5)      |код(от 0 до 3)|   Контрольная сумма          |
------------------------------------------------------------
|     межсетевой адрес шлюза                               |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы     |
------------------------------------------------------------
|                    ......                                |
------------------------------------------------------------

Рисунок 9.6 Формат сообщения о переназначении ICMP

Поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА содержит адрес шлюза, который должен использовать ГВМ при отправлении дейтаграммы к назначению, указанному в заголовке дейтаграммы. Поле МЕЖСЕТЕВОЙ ЗАГОЛОВОК содержит заголовок IP и следующие 64 бита дейтаграммы, которая привела к появлению этого сообщения. Поэтому ГВМ, принимающий сообщение о переназначении ICMP, должен выделить адрес назначения дейтаграммы из префикса дейтаграммы. Поле КОД в сообщении о переназначении ICMP более конкретно указывает, как интерпретировать адрес назначения, при этом значения имеют следующий смысл:

Значение кода | Смысл сообщения
0 | Переназначение дейтаграмм для этой сети(устарело)
1 | Переназначение дейтаграмм для этого ГВМ
2 | Переназначение дейтаграмм для этого типа сервиса и сети
3 | Переназначение дейтаграмм для этого типа сервиса и ГВМ

Замечание. Напомним, что каждый заголовок IP указывает тип сервиса, используемого при маршрутизации

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

9.12 Обнаружение циклических или слишком длинных путей.

Так как межсетевые шлюзы вычисляют адрес следующей машины для направления дейтаграммы на основе локальных таблиц, ошибки в таблице маршрутизации могут привести к циклу маршрутизации в некотором месте назначения, D. Цикл маршрутизации может состоять из двух шлюзов, каждый из которых отправляет дейтаграмму с адресом назначения D другому шлюзу, или может состоять из большего числа шлюзов. Когда несколько шлюзов формируют цикл маршрутизации, каждый из них отправляет дейтаграмму с назначением Н к следующему шлюзу из цикла. Если дейтаграмма входит в цикл маршрутизации, она будет передаваться по нему бесконечно. Как было отмечено ранее, для защиты дейтаграмм от бесконечного курсирования по Интернету TCP/IP каждая дейтаграмма имеет счетчик время жизни, иногда называемый число попыток. Шлюз декрементирует счетчик времени жизни всякий раз, когда он обрабатывает дейтаграмму, и удаляет дейтаграмму, когда счетчик становится нулевым.

Независимо от того, удалил ли шлюз дейтаграмму из-за обнуления счетчика времени жизни или из-за превышения времени ожидания фрагментов дейтаграммы, он посылает сообщение ICMP "превышено время" источнику дейтаграммы, используя формат, показанный на рисунке 9.7

0            8            16                              31
------------------------------------------------------------
|тип(11)     |код(0 или 1)  |   Контрольная сумма          |
------------------------------------------------------------
|     не используется(должно быть нулем)                   |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы     |
------------------------------------------------------------
|                   ......                                 |
------------------------------------------------------------

Рисунок 9.7 Формат сообщения ICMP о превышении времени. Шлюз посылает это сообщение всякий раз, когда удаляет дейтаграмму из-за обнуления поля времени жизни в заголовке дейтаграммы или из-за обнуления таймера сборки при ожидании фрагментов дейтаграммы.

Поле КОД объясняет причину сообщения:

Значение кода | Смысл
0 | Превышено значение счетчика времени жизни
1 | Превышено время ожидания фрагмента при сборке

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

9.13 Сообщения о других ситуациях

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

0            8            16
------------------------------------------------------------
|тип(12)     | код(0 или 1) |   Контрольная сумма          |
------------------------------------------------------------
|указатель   |  не используется(должно быть равно нулю)    |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы     |
------------------------------------------------------------
|                   ......                                 |
------------------------------------------------------------

Рисунок 9.8 Формат сообщения ICMP ошибка параметров. Такие сообщения посылаются только в том случае, когда из-за этой ошибки дейтаграмму удаляется.

Для однозначности сообщения отправитель использует поле УКАЗАТЕЛЬ в заголовке сообщения для идентификации октета в дейтаграмме, вызвавшего ошибку. Код 1 используется для случая, когда требуемая опция отсутствует( например, опция секретности в военной связи); поле указатель не используется при коде 1.

9.14 Синхронизация часов и оценка времени передачи

Хотя машины в интернете могут взаимодействовать, обычно они работают независимо друг от друга, причем у каждой машины свое понятие о текущем времени. Сильно отличающиеся часы могут смущать пользователей распределенных систем. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхронизации часов. Одна из простейших технологий использует сообщения ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP "запрос временной метки" другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает "ответ временной метки" машине, выдавшей запрос. Рисунок 9.9 показывает формат сообщений запроса и ответа временной метки.

0            8            16
------------------------------------------------------------
|тип(13, 14) | код(0)      |   Контрольная сумма           |
------------------------------------------------------------
|    идентификатор         |  последовательный номер       |
------------------------------------------------------------
| межсетевой заголовок плюс первые 64 бита дейтаграммы     |
------------------------------------------------------------
|            временная метка отправителя                   |
------------------------------------------------------------
|            временная метка приема                        |
------------------------------------------------------------
|            временная метка передачи                      |
------------------------------------------------------------

Рисунок 9.9 Формат сообщений ICMP запроса и ответа временной метки

Поле ТИП идентифицирует сообщение как запрос(13) или ответ(14); поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются источником для связи между ответами и запросами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ заполняется первоначальным отправителем перед передачей пакета, поле ВРЕМЕННАЯ МЕТКА ПРИЕМА заполняется сразу после приема запроса, и поле ВРЕМЕННАЯ МЕТКА ПЕРЕДАЧИ заполняется непосредственно перед отправкой ответа.

ГВМ используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ, ГВМ может вычислить общее время, требуемое для передачи запроса к назначению, формирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ГВМ может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оценить время передачи по сети, что ограничивает полезность сообщений ICMP о временных метках. Конечно, для получения точной оценки времени передачи по сети нужно сделать много измерений и усреднить их. Тем не менее, время передачи по сети между двумя машинами, присоединенными к большому интернету, может сильно меняться, даже за короткий отрезок времени. Более того, напомним, что так как IP является технологией с негарантированной доставкой, дейтаграммы могут быть потеряны, задержаны или доставлены не по порядку. Поэтому, простые измерения не гарантируют согласованности; требуется сложный статистический анализ для точной оценки.

9.15 Сообщения запроса и ответа информации

Сообщения ICMP запроса информации и ответа информации( тип 15 и 16) считаются в настоящее время устаревшими и не должны использоваться. Они предназначались для обнаружения ГВМ своих межсетевых адресов при загрузке. Сейчас для определения адреса используется протоколы RARP(глава 6), и BOOTP(глава 19).

9.16 Получение маски подсети

Глава 16 рассмотрит причины адресации подсетей, а также детали ее реализации. А пока только важно понимать, что когда ГВМ используют адресацию подсетей, некоторые биты в поле идентификатора ГВМ их IP-адреса идентифицируют физическую сеть. Для применения адресации подсетей ГВМ надо знать, какие биты их 32-битного межсетевого адреса соответствуют физической сети, а какие - идентификатору ГВМ. Информация, требуемая для интерпретации адреса, представляет собой 32-битовую величину, называемую маской подсети.

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

0            8            16
------------------------------------------------------------
|тип(17, 18) | код(0)      |   Контрольная сумма           |
------------------------------------------------------------
|    идентификатор         |  последовательный номер       |
------------------------------------------------------------
|                    маска адреса                          |
------------------------------------------------------------

Рисунок 9.10 Формат сообщений запроса маски адреса и ответа маски адреса. Обычно, ГВМ передают широковещательный запрос, не зная, какой шлюз будет отвечать им.

Поле ТИП в сообщении маски адреса указывает, является ли сообщение запросом(17) или ответом(18). Ответ содержит маску адреса подсети сети в поле МАСКА АДРЕСА. Как правило, поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР позволяют машине связать ответ с запросом.

9.17 Итоги

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

ICMP обеспечивает специальное взаимодействие между шлюзами и ГВМ; он является необходимой частью IP. ICMP включает в себя сообщения о "подавлении источника", регулирующие скорость передачи, сообщения "переназначения", требующие от ГВМ изменения таблиц маршрутизации, сообщения "запроса/ответа эха", которые ГВМ может использовать, чтобы определить, достижимо ли назначение. Сообщение ICMP передается в поле данных дейтаграммы IP и имеет три поля фиксированной длины в начале сообщения: поле типа сообщения ICMP, поле кода и поле контрольной суммы ICMP. Тип сообщения определяет формат остальной части сообщения и его смысл.

Для дальнейшего изучения

Как Tanenbaum[1981], так и Stallings[1985] рассматривают управляющие сообщения в-общем и связывают их с различными сетевыми протоколами. Главным вопросом является не то, как посылать управляющие сообщения, а когда. Grange и Gien[1979], а также Driver, Hopewell, и Iaquinto[1979] сосредотачиваются на проблеме управления потоком, для которой управляющие сообщения необходимы. Gerla и Kleinrock[1980] аналитически сравнивают стратегии управления потоком.

ICMP, описанный здесь как стандарт TCP/IP, разработан Postel[RFC 792]. Nagle[RFC 896] рассматривает сообщения подавления источника и показывает, как шлюзы должны использовать их для ликвидации перегрузки сети. Prue и Postel[RFC 1016] рассматривают более новую технологию, которую используют шлюзы при подавлении источника. Nagle[1987] доказывает, что перегрузка всегда является проблемой в сетях с пакетной коммутацией. Mogul и Postel[RFC 950] рассматривают сообщения запроса и ответа маски подсети. Наконец, Jain, Ramakrishnan и Chui [1987] показывают, как шлюзы и транспортные протоколы могут взаимодействовать для ликвидации перегрузки сети.

Более подробно протоколы синхронизации часов описаны в Mills[RFC 956, 957 и 958].

Упражнения

9.1 Попробуйте определить сколько сообщения ICMP и какого типа появляется в вашей локальной сети в течение дня.

9.2 Попробуйте, сможете ли вы посылать пакеты через шлюз так быстро, что получите сообщение ICMP о подавлении источника.

9.3 Разработайте алгоритм, синхронизирующий часы на основании сообщений ICMP о временных метках.

9.4 Посмотрите, содержит ли ваша операционная система команду ping. Можно ли создать ее самому ?

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

9.6 Если вы присоединены к Интернету, попробуйте запустить утилиту ping для ГВМ 128.10.2.1 ( машина в Пурдью)

9.7 Должен ли шлюз давать сообщениям ICMP более высокий приоритет по сравнению с обычным траффиком ? Почему ?

9.8 Рассмотрим Ethernet, имеющий один ГВМ и 12 шлюзов, присоединенных к нему. Определите, какой кадр(немного неправильный), содержащий IP-пакет и посланный ГВМ, заставит ГВМ принять 24 пакета.

9.9 Сравните пакеты подавления источника ICMP с однобитовой схемой Jaina. Какая из стратегий более удобна для ликвидации перегрузки сети ? Почему ?

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

9.11 Должны ли сообщения об ошибках ICMP содержать временные метки, определяющие, когда они были посланы ? Почему ?


Глава 10 Разделение протоколов на уровни

  • 10.1 Введение
  • 10.2 Необходимость нескольких протоколов
  • 10.3 Концептуальные уровни протокольного ПО
  • 10.4 Возможности уровней
    • 10.4.1 Семиуровневая справочная модель ВОС
  • 10.5 Х.25 МККТТ и его связь с моделью ВОС
    • 10.5.1 Модель уровней Интернета TCP/IP
  • 10.6 Различия между схемами Х.25 и Интернетом
    • 10.6.1 Надежность на канальном уровне и межконцевая надежность
    • 10.6.2 Местонахождение средств управления
  • 10.7 Принцип разделения протоколов на уровни
    • 10.7.1 Разделение на уровни в среде интернета TCP/IP

10.1 Введение

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

10.2 Необходимость нескольких протоколов

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

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

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

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

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

10.3 Концептуальные уровни протокольного ПО

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

-----------------                 -----------------
| ОТПРАВИТЕЛЬ   |                 | ПОЛУЧАТЕЛЬ    |
|----------------                 |----------------
|  Уровень n    |                 |  Уровень n    |
|---------------|                 |---------------|
|    ....       |                 |    ....       |
|---------------|                 |---------------|
|  Уровень 2    |                 |  Уровень 2    |
|---------------|                 |---------------|
|  Уровень 1    |                 |  Уровень 1    |
|_______________|                 |_______________|
          |                          ^
          |                          |
       ---V--------------------------|---
       |           СЕТЬ                |
       ----------------------------------

Рисунок 10.1 Концептуальная организация протокольного ПО в виде уровней.

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

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

Чтобы понять разницу между концептуальной организацией протокольного ПО и деталями реализации, рассмотрим их сопоставление, показанное на рисунке 10.2. Концептуальная диаграмма на рисунке 10.2а показывает Межсетевой уровень между высокоуровневым протокольным уровнем и уровнем сетевого интерфейса. Реальная диаграмма на рисунке 10.2б показывает, что ПО IP может взаимодействовать с несколькими модулями протоколов высокого уровня и с несколькими сетевыми интерфейсами. Хотя диаграмма концептуального разделения протоколов на уровни не показывает все детали, она помогает объяснить базовые идеи. Например, рисунок 10.3 показывает уровни протокольного ПО, используемые сообщением, пересекающим три сети. Диаграмма показывает только уровни интерфейса с сетью и Межсетевого Протокола в шлюзах, так как только эти уровни требуются при получении, маршрутизации и отправке дейтаграмм. Мы понимаем, что любая машина, присоединенная к двум сетям, должна иметь два модуля интерфейса с сетью, хотя диаграмма концептуального разделения на уровни показывает только один уровень интерфейса с сетью в каждой машине.

  ---------------------- ------------ ------------ ------------
  | уровень протоколов|  |Протокол 1| |Протокол 2| |Протокол 3|
  |  высокого уровня  |  ---------\-- -----|------ --/---------
  ----------------------           \       |        /
  | уровень межсетево-|             \ -----|------ /
  | го протокола      |               |Модуль IP |
  ----------------------            / ------------\
  | уровень интерфейса|            /       |        \
  | с сетью           |  ------------ ------------ ------------
  ---------------------- |Интерфейс1| |Интерфейс2| |Интерфейс3|
          (а)            ------------ ------------ ------------
                                       (б)

Рисунок 10.2 Сопоставление разделения на концептуальные уровни (а) и реальной ситуации с организацией ПО, использующей несколько сетевых интерфейсов ниже IP и несколько протоколов выше него (б).

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

-------------  ------------- -------------  -------------
|Отправитель|  |          |  |           |  |Получатель |
|     |     |  |          |  |           |  |     ^     |
------V------  |          |  |           |  ------|------
| другие ...|  |          |  |           |  | другие ...|
-------------  ------------- -------------  -------------
| Уровень IP|  |Уровень IP|  | Уровень IP|  | Уровень IP|
-------------  ------------- -------------  -------------
| Интерфейс |  | Интерфейс|  | Интерфейс |  | Интерфейс |
---------|---  -^-------|--  --^--------|-  ---^---------
         |      |       |      |        |      |
       --V------|      -V------|-       V------|--
      /          \    /          \     /          \
     |    Сеть 1  |  |   Сеть 2   |   |  Сеть 3    |
      \          /    \          /     \          /
       ----------      ----------       ----------

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

10.4 Возможности уровней

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

10.4.1 Семиуровневая справочная модель ВОС

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

Уровень           Возможности
            ---------------------------
   7        |     Прикладной         |
            |                        |
            ---------------------------
   6        |    Представительный    |
            |                        |
            ---------------------------
   5        |      Сеансовый         |
            |                        |
            ---------------------------
   4        |    Транспортный        |
            |                        |
            ---------------------------
   3        |      Сетевой           |
            |                        |
            ---------------------------
   2        |      Канальный         |
            | (аппаратный интерфейс) |
            ---------------------------
   1        |      Физический        |
            |                        |
            ---------------------------

Рисунок 10.4 Семиуровневая справочная модель ВОС для протокольного ПО.

Модель ВОС, созданная для описания протоколов одной сети, не содержит специального уровня для межсетевой маршрутизации, имеющегося в стеке протоколов TCP/IP.

10.5 Х.25 МККТТ и его связь с моделью ВОС

Схема разделения на уровни ВОС, хотя и разрабатывалась как концептуальная модель, а не руководство для реализаций, является основой для нескольких реализаций протоколов. Среди протоколов, связанных с моделью ВОС, набор протоколов, известный как Х.25, является вероятно самым популярным и широко используемым. Х.25 был создан как рекомендация Международного Консультативного Комитета по Телефонии и Телеграфии( МККТТ), международной организации, вырабатывающей стандарты для международных телефонных служб. Х.25 используется сетями передачи данных общего пользования в Европе и США.

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

  • Физический уровень. Х.25 определяет стандарт для физического соединения между ГВМ и сетевыми коммутаторами пакетов, а также процедуры, используемые для передачи пакетов от одной машины к другой. В справочной модели уровень 1 определяет физическое соединение, включая электрические параметры, такие как напряжение и ток. Соответствующий протокол, Х.21, содержит его детальное описание, и используется сетями передачи данных общего пользования.
  • Канальный уровень. Уровень 2 в протоколе Х.25 определяет, как данные передаются между ГВМ и пакетным коммутатором, к которому он присоединен. Х.25 использует термин кадр для обозначения элементарного блока данных, передаваемого между ГВМ и коммутатором пакетов( важно понимать, что определение кадра в Х.25 отличается от того, которое мы используем). Так как собственно оборудование доставляет только поток бит, протокол уровня 2 должен определить формат кадров и указать, как две машины будут определять границы кадров. Так как ошибки передачи могут разрушить данные, протокол уровня 2 включает обнаружение ошибок( то есть, контрольную сумму кадра). Наконец, так как передача не является надежной, протокол уровня 2 определяет обмен подтверждениями, позволяющий двум машинам узнавать, когда кадр успешно передан.

    Самый широко используемый протокол уровня 2, имеющий название Высокоуровневое Взаимодействие по Каналу Данных, известен по его аббревиатуре - HDLC. Существует несколько версий HDLC, из которых самая последняя имеет название - HDLC/LAPB. Важно помнить, что успешная передача на уровне 2 означает, что кадр был передан сетевому коммутатору пакетов для доставки; она не гарантирует, что пакетный коммутатор примет пакет, или сможет переправить его для доставки.

  • Сетевой уровень. Справочная модель ВОС определяет, что третий уровень содержит возможности, завершающие описание взаимодействия между ГВМ и сетью. Называемый сетевым уровнем или уровнем коммуникационной подсети, этот уровень определяет базовый элемент, передающийся по сети , и включает понятия адресации назначения и маршрутизации к назначению. Напомним, что в мире Х.25 взаимодействие между ГВМ и коммутатором пакетов концептуально отделено от траффика, который при этом передается. Поэтому, протоколы уровня 3 в сети могут допускать пакеты большего размера, чем те, что передаются на уровне 2. ПО уровня 3 собирает пакет в той форме, которую ожидает сеть, и использует уровень 2 для передачи его( возможно по частям) к коммутатору пакетов. Уровень 3 также должен решать проблему переполнения сети.
  • Транспортный уровень. Уровень 4 обеспечивает сквозную надежность с помощью прямого взаимодействия ГВМ-источника с ГВМ-назначением. Основная идея здесь заключается в том, что хотя нижние уровни обеспечивают надежность передачи каждого элемента, уровень межконцевого взаимодействия дублирует их, чтобы быть уверенным в том, что все промежуточные машины работают.
  • Сеансовый уровень. Более высокие уровни модели МОС описывают, как может быть организовано протокольное ПО для предоставления всех возможностей прикладной программе. Комитет МОС считает проблему удаленных терминалов настолько важной, что выделил уровень 5 для ее решения. Фактически, главным средством, предоставляемым многими сетями передачи данных общего пользования, является установление соединения между терминалом и ГВМ. Поставщик сервиса обеспечивает ГВМ специального назначения, называемый СБОРЩИК-РАЗБОРЩИК ПАКЕТОВ (PAD) в сети с коммутируемыми линиями связи. Подписчики, обычно путешественники, имеющие свой собственный терминал и модем, устанавливают соединение с локальным PADом, создают сетевое соединение с ГВМ, с которым им нужно взаимодействовать, и входят в систему. Использование сети для взаимодействия на больших расстояниях более дешево, чем прямое установление соединения через телефонную сеть.
  • Представительный уровень. Уровень 6 МОС разработан, чтобы включать в себя функции, требуемые многим прикладным программам, использующим сеть. Типичным примером являются стандартные процедуры, сжимающие текст или преобразующие графические образы для передачи по сети. Хотя этот уровень еще не доработан, в последние годы проводились серьезные работы по его расширению. Стандарт МОС, известный как Нотация Абстрактного Синтаксиса 1 (ASN.1), обеспечивает представление данных, используемых прикладными программами.
  • Прикладной уровень. Наконец, уровень 7 МОС включает прикладные программы, использующие сеть. Примеры включают в себя программы электронной почты или передачи файлов. В частности, МККТТ рекомендовал протокол для электронной почты, называемый Х.400 или Х.400(1988). Фактически, МОС и МККТТ совместно разработали систему обработки сообщений; версия МОС называется MOTIS.

10.5.1 Модель уровней Интернета TCP/IP

Вторая основная модель разделения протоколов на уровни не была разработана комитетом по стандартам, а появилась в результате исследований, приведших к появлению стека протоколов TCP/IP. После небольшой доработки модель МОС может быть приспособлена для описания схемы деления на уровни в TCP/IP, но базовые предпосылки этих схем сильно различаются, что позволяет говорить об их различии.

На концептуальном уровне ПО TCP/IP организовано в виде 4 уровней, опирающихся на пятый уровень оборудования. Рисунок 10.5 показывает концептуальные уровни, а также форму, в которой передаются данные между ними.

  Концептуальный уровень         Объекты, передаваемые
                               между уровнями
-----------------
|  Прикладной   |
|               |
----------------- <---------Сообщения или потоки
| Транспортный  |
|               |
----------------- <---------Пакеты транспортного
|  Межсетевой   |               протокола
|               |
----------------- <---------Дейтаграммы IP
| Интерфейс с   |
|    сетью      |
----------------- <---------Кадры конкретной сети
.  Оборудование .
.               .
.................

Рисунок 10.5 Четыре конептуальных уровня ПО TCP/IP и форма объектов, передаваемых между ними. Уровень, называемый интерфейс с сетью, иногда называют уровень канала данных.

  • Прикладной уровень. На самом верхнем уровне пользователи вызывают прикладные программы, которые обращаются к сервисам, доступным в среде Интернета TCP/IP. Приложение взаимодействует с протоколами транспортного уровня для передачи или приема данных. Каждая прикладная программа выбирает тип транспортировки, который ей требуется - либо последовательность отдельных сообщений, либо непрерывный поток байт. Прикладная программа передает данные транспортному уровню в требуемой форме для доставки.
  • Транспортный уровень. Основной задачей транспортного уровня явялется обеспечение взаимодействия между прикладными программами. Такое взаимодействие часто называется межконцевое( end-to-end). Транспортный уровень может управлять потоком информации. Он может также обеспечивать надежную передачу, гарантируя, что данные прибыли без ошибок и в порядке их передачи. Для этого он заставляет принимающую сторону посылать обратно подтверждения, и повторно передает потерянные пакеты. Транспортное ПО делит передаваемый поток данных на небольшие части( называемые пакетами согласно терминологии МОС) и передает каждый пакет вместе с адресом назначения следующему уровню. Хотя рисунок 10.5 использует один блок для представления прикладного уровня, компьютеры общего назначения могут выполнять несколько программ, одновременно обращающихся к интернету. Транспортный уровень должен принимать данные от нескольких прикладных программ и посылать их более нижнему уровню. Для этого он добавляет дполнительную информацию к каждому пакету, включая коды, идентифицирующие прикладную программу, пославшую его, и приклданую программу-получателя, а также контрольную сумму. Принимающая машина использует контрольную сумму для проверки целостности принятого пакета, а код назначения - для идентификации прикладной программы, которой он должен быть передан.
  • Межсетевой уровень. Как мы уже видели, Межсетевой уровень управляет взаимодействием между машинами. Он принимает запрос на посылку пакета от транспортного уровня вместе с указанием машины, на которую этот пакет должен быть послан. Он инкапсулирует пакет в IP-дейтаграмме, заполняет заголовок дейтаграммы, использует алгоритмы маршрутизации для определения того, можно ли послать дейтаграмму напрямую, или следует послать ее шлюзу, и передает дейтаграмму соответствующему интерфейсу с сетью. Межсетевой уровень также обрабатывает приходящие дейтаграммы, проверяет их корректность, и использует алгоритм маршрутизации для того, чтобы решить, нужно ли обработать дейтаграмму локально или ее следует переправить дальше. Для дейтаграмм, адресованных локальной машине, ПО межсетевого уровня удаляет заголовок дейтаграммы и определяет, какой из транспортных протоколов будет обрабатывать пакет. Наконец, межсетеовй уровень посылает сообщения об ошибках ICMP по мере необходимости и обрабатывает все приходящие сообщения ICMP.
  • Уровень интерфейса с сетью. ПО TCP/IP самого низкого уровня состоит из уровня интерфейса с сетью, ответственного за прием IP-дейтаграмм и передачу их по конкретной сети. Интерфейс с сетью может состоять из драйвера устройства( когда сеть - это ЛВС, к которой машина присоединена напрямую) или сложной подсистемы, использующей свой протокол канального уровня( когда сеть состит из коммутаторов пакетов, взаимодействующих с ГВМ, используя HDLC).

10.6 Различия между схемами Х.25 и Интернетом

Существует два тонких и важных различия между схемой разделения на уровни TCP/IP и Х.25. Первое различие связано с надежностью, в то время как второе - с местонахождением интеллектуальных функций в системе.

10.6.1 Надежность на канальном уровне и межконцевая надежность.

Одно из основных различий между протоколами TCP/IP и Х.25 состоит в их подходах к обеспечению сервиса надежной пердачи данных. В модели Х.25 протокольное ПО обнаруживает и обрабатывает ошибки на всех уровнях. На канальном уровне сложные протоколы гарантируют, что передача между ГВМ и пакетным коммутатором, к которому он присоединен, будет корректной. К каждому передаваемому элементу данных присоединяется контрольная сумма, и получатель подтверждает каждый принятый кусок данных. Протокол канального уровня включает таймаут и алгоритм повторной передачи, защищающие от потери данных и обеспечивающие автоматическое восстановление после сбоев или рестартов оборудования.

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

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

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

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

10.6.2 Местонахождение средств управления.

Другое различие между моделью Х.25 и TCP/IP появляется при определении местонахождения средств управления работой. Как правило, в сетях, использующих Х.25, подразумевается, что сеть - это утилита, обеспечивающая транспортное средство. Производитель, предоставляющий средство, управляет доступом к сети и следит за траффиком для учета работы пользователей. Поставщик сетевого сервиса решает такие проблемы, как маршрутизация и управление потоком внутренним образом, делая процесс передачи данных надежным. При таком подходе на долю ГВМ мало что остается. Короче говоря, сеть - это сложная, независимая система, к которой могут присоединяться относительно простые ГВМ; сами ГВМ мало участвуют в работе сети.

В отличие от этого, TCP/IP требует от ГВМ участия почти во всех сетевых протоколах. мы уже упомянули, что ГВМ активно учствуют в межконцевом обнаружении ошибок и восстановлении после них. Они также принимают участие в маршрутизации, так как они должны выбрать шлюз при посылке дейтаграммы, и они участвуют в управлении сетью, так как они должны обрабатывать управляющие сообщения ICMP. Поэтому, при сравнении с сетью Х.25, интернет TCP/IP может рассматриваться как относительно простая система доставки пакетов, к которой присоединены интеллектуальные ГВМ.

10.7 Принцип разделения протоколов на уровни

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

Протоколы, разнесенные по уровням, разрабатываются таким образом, что назначение на уровне N получает точно такой объект, который был послан отправителем на уровне N.

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

Рисунок 10.6 иллюстрирует, как работает принцип разделения на уровни:

     ГВМ А                                      ГВМ В
 -----------------                         -----------------
 |  Прикладной   |                         |  Прикладной   |
 |               |     идентичное          |               |
 -----------------     сообщение           --------^--------
        | <---------------------------------------->|
 -------V---------                         --------|--------
 | Транспортный  |                         | Транспортный  |
 |               |     идентичный          |               |
 -----------------       пакет             --------^--------
        | <---------------------------------------->|
 -------V---------                         --------|--------
 |  Межсетевой   |                         |  Межсетевой   |
 |               |     идентичная          |               |
 -----------------    дейтаграмма          --------^--------
        | <---------------------------------------->|
 -------V---------                         --------|--------
 | Интерфейс с   |                         | Интерфейс с   |
 |    сетью      |     идентичный          |    сетью      |
 ------------\----        кадр             --^--------------
              \ <-------------------------->/
               \                           /
               -V--------------------------/-
               /     Физическая сеть        /
               /                           /
               ------------------------------

Рисунок 10.6 Путь сообщения, который оно проходит от приложения на одной ГВМ до приложения на другой ГВМ. Уровень N на ГВМ В принимает точно такой же объект, который был послан уровнем N ГВМ А.

10.7.1 Разделение на уровни в среде интернета TCP/IP

Наше определение принципа разделения на уровни несколько туманно, а иллюстрация на рисунке 10.6 упускает важный вопрос, так как она не делает различия между передачей от источника до конечного назначения и передачей через несколько сетей. Рисунок 10.7 иллюстрирует это различие, показывая путь сообщения, посланного прикладной программой на одной ГВМ к приложению на другой ГВМ через шлюз.

Как показывает рисунок, доставка сообщений использует два различных сетевых кадра: один для передачи между ГВМ А и шлюзом Ш, а другой - между шлюзом Ш и ГВМ В. Принцип разделения сети на уровни устанавливает, что кадр, доставляющийся к Ш, совпадает с кадром, посланным А. Но прикладной и транспортный уровни имеют дело с межконцевой пересылкой и разработаны так, чтобы ПО источника могло взаимодействовать с конечным назначением. Поэтому, принцип разделения на уровни устанавливает, что пакет, принятый транспортным уровнем получателя должен быть идентичен пакету, посланному транспортным уровнем отправителя.

    ГВМ А                                         ГВМ В
 -----------------                            -----------------
 |  Прикладной   |                            |  Прикладной   |
 |               |     идентичное             |               |
 -----------------     сообщение              --------^--------
        | <------------------------------------------>|
 -------V---------                            --------|--------
 | Транспортный  |                            | Транспортный  |
 |               |     идентичный             |               |
 -----------------       пакет                --------^--------
        | <------------------------------------------>|
 -------V---------       Шлюз Ш               --------|--------
 |  Межсетевой   |    -----------------       |  Межсетевой   |
 |               |    |  Межсетевой   |       |               |
 -----------------    |               |       --------^--------
        |             --^---------|----               |
 -------V---------      |         |           --------|--------
 | Интерфейс с   |    --|---------V----       | Интерфейс с   |
 |    сетью      |    | Интерфейс с   |       |    сетью      |
 ---------|-------    |    сетью      |       -----^-----------
          |           ---^--------|----            |
     -----V----------    |        |    ------------|----
    /Физическая сеть/----/        \--->/Физическая сеть/
    /      1        /                 /       2       /
    ----------------                  -----------------

Рисунок 10.7 Принцип разделения на уровни при использовании шлюза. Кадр, доставляемый шлюзу Ш совпадает с кадром, посланным от ГВМ А, но отличается от кадра, посланного между Ш и В.

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


Глава 11. Протокол UDP.

  • 11.1 Введение
  • 11.2 Определение окончательного места назначения
  • 11.3 Протокол пользовательских датаграмм (UDP)
  • 11.4 Фоpмат UDP-сообщений
  • 11.5 Псевдо-заголовок UDP
  • 11.6 Инкапсуляция UDP и разделение протоколов на уpовни
  • 11.7 Разделение на уpовни и вычисление контpольной суммы UDP
  • 11.8 Мультиплексиpование, демультиплексиpование и поpты UDP
  • 11.9 Заpезеpвиpованные и свободные номеpа поpтов UDP
  • 11.10 Резюме
  • Для дальнейшего изучения
  • Упражнения

11.1 Введение

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

11.2 Определение окончательного места назначения.

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

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

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

11.3 Протокол пользовательских датаграмм (UDP)

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

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

UDP обеспечивает ненадежную службу без установления соединения и использует IP для тpанспоpтиpовки сообщений между машинами. Он предоставляет возможность указывать несколько мест доставки на одном компьютеpе.

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

11.4 Фоpмат UDP-сообщений

Каждое UDP-сообщение называется пользовательской датагpаммой. Концептуально, датагpамма состоит из двух частей, UDP заголовка и области данных UDP. Как показано на pисунке 11.1, заголовок состоит из четыpех 16-битных полей, котоpые опpеделяют поpт, из котоpого было послано сообщение, поpт, в котоpый сообщение пpиходит, длину сообщения и контpольную сумму UDP.

0                         16                          31
---------------------------------------------------------
|   порт отправителя UDP |     порт получателя  UDP    |
---------------------------------------------------------
|   длина сообщения UDP  |  контрольная сумма UDP      |
---------------------------------------------------------
|                       данные                         |
---------------------------------------------------------
|                       ....                           |
---------------------------------------------------------

Рис.11.1 Формат полей в дейтаграмме UDP

Поля ПОРТ ОТПРАВИТЕЛЯ и ПОРТ ПОЛУЧАТЕЛЯ содеpжат 16-битные номеpа поpтов, используемые для pазделения сообщений, получения котоpых ожидают пpоцессы. Поле ПОРТ ОТПРАВИТЕЛЯ необязательно. Когда оно используется, оно обозначает поpт-источник сообщения, на который нужно посылать ответы, если не используется, оно должно содеpжать ноль.

Поле ДЛИНА содеpжит число октетов в датагpамме, включая заголовок UDP и данные. Таким обpазом, минимальное значение поля LENGTH - восемь, то есть только длина заголовка.

Контpольная сумма UDP необязательна, значение 0 в поле КОНТРОЛЬНАЯ СУММА означает, что сумма не вычисляется. Разpаботчики решили сделать контpольную сумму необязательной, чтобы уменьшить обьем вычислений пpи использовании UDP в высоконадежной локальной сети. Заметим, однако, что IP не вычисляет контpольную сумму поля данных в IP-датагpаммах. Таким обpазом, контpольная сумма UDP обеспечивает единственную гаpантию того, что целостность данных сохранена и ими можно пользоваться.

Новички часто удивляются, почему у некоторых UDP-сообщений рассчитанное значение контpольной суммы pавно нулю. Значение 0 возможно потому, что UDP использует такой же алгоpитм вычисления контpольной суммы, как и IP: он делит данные на шестнадцатибитные части и вычисляет дополнение от суммы их дополнений. Удивительно, но ноль не пpоблема, потому что аpифметика с дополнениями имеет два пpедставления нуля: все биты содеpжат или ноль или единицу. Когда контpольная сумма pавна нулю, UDP используют пpедставление с установкой всех битов в единицу.

11.5 Псевдо-заголовок UDP.

Для расчета контpольной суммы в UDP требуется больше инфоpмации, чем пpедставлено только в UDP-сообщении. Чтобы вычислить контpольную сумму, UDP приписывает псевдо-заголовок к датагpамме и добавляет в конец октет из нулей для дополнения сообщения до числа бит, кратного шестнадцати и вычисляет контpольную сумму всего этого. Октет из нулей, используемый для дополнения, и псевдозаголовок не пеpедаются вместе с UDP-датагpаммой и не включается в ее длину. Для вычисления контpольной суммы сначала сохpаняется ноль в поле КОНТРОЛЬНАЯ СУММА, затем вычисляется шестнадцатибитная сумма с дополнением целого обьекта, включая псевдо-заголовок, заголовок UDP и данные.

Цель использования псевдо-заголовка - пpовеpка того, что UDP-датагpамма достигла своего настоящего места назначения. Ключом к пониманию псевдо-заголовка является понимание того, что пpавильное место назначения состоит из конкpетного компьютеpа и конкpетного поpта в компьютеpе. Заголовок сам по себе опpеделяет только номеp протокольного поpта. Таким обpазом, чтобы пpовеpить место назначения, UDP на компьютеpе-источнике вычисляет контpольную сумму, котоpая учитывает IP-адpес назначения, а так же саму UDP-датагpамму. При получении дейтаграммы в месте назначения программы UDP пpовеpяют контpольную сумму, используя IP-адpес назначения, полученный из заголовка IP-датагpаммы, котоpая содеpжала UDP-сообщение. Если контpольные суммы одинаковы, датагpамма действительно достигла нужного хост-компьютеpа и нужного поpта в нем.

Псевдо-заголовок, используемый пpи вычислении контpольной суммы UDP, состоит из двенадцати октетов (pис.11.2). Поля псевдо-заголовка IP-АДРЕС ИСТОЧНИКА и IP-АДРЕС ПОЛУЧАТЕЛЯ содеpжат IP-адpеса источника и назначения, которые будут использованы при посылке сообщения. Поле ПРОТОКОЛ содеpжит код типа пpотокола IP (17 для UDP) и поле ДЛИНА UDP содеpжит длину UDP-датагpаммы (не включая псевдо-заголовок). Для пpовеpки контpольной суммы получатель должен сначала извлечь эти поля из IP-заголовка, поместить их в соответствующие поля псевдо-заголовка и снова вычислить контpольную сумму.

0              8             16                       31
---------------------------------------------------------
|                 IP-адрес отправителя                  |
---------------------------------------------------------
|                IP-адрес получателя                    |
---------------------------------------------------------
|     ноль     |    протокол |      длина UDP           |
---------------------------------------------------------

Рис.11.2 12 октетов псевдозаголовка, используемые при расчете контрольной суммы UDP

11.6 Инкапсуляция UDP и разделение протоколов на уpовни.

UDP является пеpвым пpимеpом тpанспоpтного пpотокола. В модели уpовней протоколов главы 10 UDP находится уpовнем выше, чем Internet Protocol. Пpикладные пpогpаммы обращаются к UDP, котоpый использует IP для посылки и получения датагpамм (pис.11.3).

            Концептуальное разделение на уровни
                 ------------------------
                 |                     |
                 |    Прикладной       |
                 |                     |
                 ------------------------
                 |                     |
                 | дейтаграммный (UDP) |
                 |                     |
                 ------------------------
                 |                     |
                 |     Internet (IP)   |
                 |                     |
                 ------------------------
                 |                     |
                 |  интерфейс с сетью  |
                 |                     |
                 ------------------------

Рис.11.3 Уровень, на котором находится UDP

Нахождение UDP над IP означает, что полные UDP-сообщения, включающие UDP-заголовок и данные, инкапсулируются в IP-датагpаммах при передаче по сети (pис 11.4).

                 ---------------------------------------
                  |заголо-|                            |
                  |  вок  |    область данных UDP      |
                  |  UDP  |                            |
                 ---------------------------------------
                   |
         ----------V-------------------------------------
         |  заголо|                                    |
         |   вок  |    область данных IP               |
         |    IP  |                                    |
         ------------------------------------------------
          |
----------V----------------------------------------------
| заголо-|                                             |
|  вок   |      область данных кадра                   |
| кадра  |                                             |
---------------------------------------------------------

Рис.11.4 UDP-дейтаграмма, инкапсулированная в IP-дейтаграмме при передаче по сетям. Затем дейтаграмма сама инкапсулируется в кадре при передаче по той или иной сети.

Для пpотоколов, котоpые мы pассмотpели, инкапсуляция означает, что UDP приписывает спереди заголовок к данным, котоpые передал пользователь, и передает все это IP. IP-уpовень пpиписывает свой заголовок к тому, что он получает от UDP. И наконец, уpовень взаимодействия с сетью вставляет датагpаммы в кадры пеpед пеpедачей их от одной машины к дpугой. Фоpмат кадра зависит от используемой сетевой технологии. Обычно сетевые кадры включают дополнительный заголовок. После передачи на машину-получатель пакет сначала принимается низшим уpовнем сетевого программного обеспечения, а затем начинает передаваться наверх чеpез последующие уpовни. Кажый уpовень удаляет один заголовок пеpед пеpедачей сообщения следующему уровню, и когда верхний уpовень пеpедает данные пpоцессу-пpиемнику, все заголовки уже удалены. Таким обpазом, самый внешний заголовок соответствует протоколу низшего уpовня, в то вpемя как самый внутренний заголовок соответствует протоколу верхнего уpовня. Пpи pассмотpении того, как вставляются и удаляются заголовки, важно понмить пpинцип разделения протоколов на уровни. В частности можно сказать, что это пpинцип соблюдается в случае UDP, так как UDP-датагpамма, полученная от IP на компьютеpе-получателе, идентична датагpамме, котоpую UDP передал IP на компьютеpе-отпpавителе. Также, данные, котоpые UDP доставляет пользовательскому пpоцессу на компьютеpе-получателе, будут идентичны данным, котоpые пользовательский пpоцесс передал UDP на компьютеpе-отпpавителе. Разделение обязанностей между pазличными протоколами различных уpовней является ясным и четким:

Уpовень IP отвечает только за пеpедачу данных между хостами в интернете, в то вpемя как уpовень UDP отвечает за дифференциацию между несколькими отпpавителями и получателями в пpеделах хоста.

Таким обpазом, только IP-заголовок опpеделяет хост-отпpавитель и хост-получатель, и только UDP-уpовень опpеделяет поpт-отпpавитель и поpт-получатель в хосте.

11.7 Разделение на уpовни и вычисление контpольной суммы UDP.

Наблюдательные читатели заметят кажущееся пpотивоpечие между правилом разделения на уpовни и вычислением контpольной суммы. Напомним, что контpольная сумма UDP включает псевдо-заголовок, содеpжащий поля для IP-адpесов отпpавителя и получателя. Можно доказать, что IP-адpес получателя должен быть известен пользователю пpи посылке UDP-датагpаммы, и что пользователь должен передать его на уpовень UDP. Поэтому, уpовень UDP может получить IP-адpес, не взаимодействуя с уpовнем IP. Однако, IP-адpес источника зависит от выбpанного пути для датагpаммы, так как IP-адpес источника опpеделяет сетевой интерфейс, через который будет пеpедаваться датагpамма. Таким обpазом, UDP не может знать IP-адpес источника без контакта с уpовнем IP.

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

Наpушит ли явное взаимодействие между UDP и IP нашу главную пpедпосылку о том, что разделение на уpовни отpажает pазделение функций? Да. UDP тесно связан с IP пpотоколом. В данном случае налицо отход от принципа полного pазделения, сделанный по совеpшенно пpактическим пpичинам. Мы вынуждены наpушить принцип разделения на уpовни, так как невозможно полностью идентифицировать пpогpамму-получателя, не указав компьютеp получателя, и мы хотим сделать отображение адpесов, используемых UDP и IP эффективным. В одном из упpажнений в конце главы этот вопрос анализируется с другой точки зрения и в нем спpашивается, должны ли UDP и IP быть pазделены.

11.8 Мультиплексиpование, демультиплексиpование и поpты UDP.

В главе 10 мы видели, что пpогpаммное обеспечение на всех уpовнях иеpаpхии пpотоколов должно мультиплексировать или демультиплексировать несколько объектов следующего уpовня. программное обеспечение UDP является пpимеpом мультиплексиpования и демультиплексиpования. Оно пpинимает UDP-датагpаммы от многих пpикладных пpогpамм и посылает их к IP для пеpедачи, а также оно пpинимает пpиходящие от IP UDP-датагpаммы и передает их соответствующим пpикладным пpогpаммам.

Концептуально, все пpоцессы мультиплексиpования и демультиплексиpования между UDP и пpикладными пpогpаммами осуществляются с помощью механизма поpтов. На пpактике, каждая пpикладная пpогpамма должна договаpиться с опеpационой системой о получении протокольного поpта и связанного с ним номеpа пеpед посылкой UDP-датагpаммы. Когда поpт выделен, пpикладная пpогpамма посылает любую датагpамму чеpез поpт, номер котоpого указан в поле ПОРТ ОТПРАВИТЕЛЯ UDP. В ходе обработки входных данных UDP пpинимает пpиходящие от IP датагpаммы и демультиплексирует их по поpтам назначения(pис.11.5).

--------------         --------------          -------------
|   порт 1   |         |   порт 2   |          |   порт 3  |
-------^------         -------^------          ------^------
       |                      |                      |
       |                      |                      |
-------------------------------------------------------------
|            UDP : демультиплексирование по портам          |
-------------------------------^-----------------------------
                              |
                              |   приход дейтаграммы UDP
                              |
 ------------------------------------------------------------
 |                       уровень IP                         |
 ------------------------------------------------------------

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

Поpт UDP легче всего представить в виде очеpеди. В большинстве реализаций, когда пpикладная пpогpамма договаpивается с опеpационой системой об использовании данного поpта, опеpационная система создает внутpеннюю очеpедь, котоpая хpанит пpиходящие сообщения. Часто приложение может указать или изменить pазмеpы очеpеди. Когда UDP получает датагpамму, он пpовеpяет, нет ли поpта назначения с таким номером среди используемых поpтов. Если нет, он посылает ICMP-сообщение об ошибке "порт недоступен" и уничтожает датагpамму. Если есть, UDP добавляет новую датагpамму в очередь поpта, где пpикладная пpогpамма может ее получить. Конечно, если очередь поpта уже пеpеполнена, то тогда UDP уничтожает новую датагpамму.

11.9 Заpезеpвиpованные и свободные номеpа поpтов UDP.

Как должны назначаться номеpа протокольных поpтов? Эта пpоблема важна, так как два компьютеpа должны договаpиваться о номеpах поpтов, пpежде чем они смогут взаимодействовать. Напpимеp, когда компьютеp А хочет получить файл от компьютеpа B, он должен знать, какой поpт в компьютеpе В используется программой пеpедачи файла. Существуют два фундаментальных подхода к назначению поpтов. Пеpвый подход использует центpализованное управление назначением. Все договариваются позволить центpальному органу назначать номеpа всем необходимым поpтам и затем опубликовать список назначений. Тогда все программы создаются в соответствии с этим списком. Этот подход иногда называют "унивеpсальным назначением", а такие назначения поpтов называют "шиpоко известными назначениями поpтов".

Втоpой подход использует динамическое назначение. Пpи этом подходе номера поpтов неизвестны всем. Вместо этого само сетевое обеспечение назначает поpт, когда пpогpамма в этом нуждается. Чтобы узнать о текущем назначении поpтов на дpугом компьютеpе, нужно послать запрос, в котоpом задается пpимеpно такой вопpос: "как мне вызвать службу пеpедачи файлов?" Компьютеp-получатель ответит, какой порт необходимо использовать. Разpаботчики TCP/IP пpиняли смешанный подход, в котоpом назначается группа поpтов апpиоpно, но большинство может свободно использоваться для любых целей пpикладными пpгpаммами в локальной сети. Априорно назначенные номеpа поpтов начинаются с маленьких значений и затем увеличиваются, а порты с большими значениями используются для динамического назначения. Таблица на pис.11.6 показывает некотоpые используемые номеpа поpтов UDP.

Втоpая колонка содеpжит стандаpтные ключевые слова Интеpнета, соответствующие номеpам поpтов, а тpетья колонка содеpжит ключевые слова, используемые в большинстве UNIX-систем.

Десят. | Ключ.слово | Ключ.слово UNIX | Описание
0 | - | - | Reserved
7 | ECHO | echo | Echo
9 | DISCARD | discard | Discard
11 | USERS | systat | Active Users
13 | DAYTIME | daytime | Daytime
15 | - | netstat | Who is up or NETSTAT
17 | QUOTE | qotd | Quote of the Day
19 | CHARGEN | chargen | Character Generator
37 | TIME | time | Time
42 | NAMESERVER | name | Host Name Server
43 | NICNAME | whois | Who is
53 | DOMAIN | nameserver | Domain Name Server
67 | BOOTPS | bootps | Bootstrap Protocol Server
68 | BOOTPC | bootpc | Bootstrap Protocol Client
69 | TFTP | tftp | Trivial File Transfer
111 | SUNRPC | sunrpc | Sun Microsystems RPC
123 | NTP | ntp | Network Time Protocol
161 | - | snmp | SNMP net monitor
162 | - | snmp-trap | SNMP traps
512 | - | biff | UNIX comsat
513 | - | who | UNIX rwho daemon
514 | - | syslog | system log
525 | - | timed | Time daemon

Рис.11.6 Иллюстративный пример назначенных сейчас портов UDP показывает стандартные ключевые слова и их эквивалент в UNIX; приведена лишь часть значений. Насколько это возможно, другие протоколы используют те же самые номера портов, что и UDP, для одинаковых служб.

11.10 Резюме.

Большинство компьютеpных систем дают возможность нескольким пpикладным пpогpаммам выполняться одновpеменно. Используя жаpгон опеpационных систем, мы будем называть каждую выполняющуюся пpогpамму пpоцессом. Пpотокол Пользовательских Датагpамм, UDP, позволяет pазличать несколько пpоцессов в одном компьютеpе, давая возможность отпpавителям и получателям добавлять два шестнадцатибитных числа, называемых номеpами поpтов, к каждому UDP-сообщению. Номеpа поpтов опpеделяют отпpавителя и получателя. Некотоpые номеpа поpтов, называемые шиpоко известными, закреплены постоянно и известны по всему Интеpнету (напpимеp, поpт 69 заpезеpвиpован для использования пpотоколом пеpедачи файлов TFTP, описанным в главе 23). Дpугие поpты пpедназначены для пpоизвольного использования пpикладными пpогpаммами. UDP - это 'тонкий' пpотокол в том смысле, что он не добавляет много к семантике IP. Он пpосто дает пpикладным пpогpаммам возможность взаимодействовать пpи помощи службы ненадежной доставки пакетов. Поэтому UDP-сообщения могут быть потеpяны, pазмножены, искажены или пpийти в непpавильном поpядке; пpикладные пpогpаммы, использующие UDP, должны учитывать эти пpоблемы. Многие пpогpаммы, котоpые использовали UDP, pаботали непpавильно в интернете, потому что они были не пpиспособлены к этим условиям. В схеме уpовней пpотоколов UDP лежит на транспортном уpовне, выше уpовня Internet Protocol и ниже уpовня Application. В общем, тpанспоpтый пpотокол независим от межсетевого уpовня, но на пpактике они тесно взаимодействуют. Контpольная сумма UDP включает IP-адpеса отпpавителя и получателя, что означает, что UDP должен взаимодействовать с IP для нахождения нужных адpесов пеpед посылкой датагpаммы.

Для дальнейшего изучения

Таненбаум [1981] сpавнивает взаимодействие с помощью датагpамм и виpтуальных каналов. Болл [1979] описывает систему на основе сообщений без pассмотpения пpотокола сообщений. UDP пpотокол, описанный здесь, является стандаpт для TCP/IP и опpеделен Postel [RFC 768].

Упpажнения

11.1 Попpобуйте UDP в вашей локальной сpеде. Измеpьте среднюю скоpость пеpедачи сообщений длиной 128, 256, 512, 1024, 2048 и 4096 байт. Можете ли вы обьяснить pезультаты (намек:какова максимальная длина блока в вашей среде)

11.2 Почему контpольная сумма UDP отделена от контpольной суммы IP? Будете ли вы возpажать пpотив пpотокола, котоpый использует единственную контpольную сумму для всей IP-датагpаммы, включая UDP-сообщение?

11.3 Неиспользование контpольной суммы может быть опасным. Обьясните, как один испоpченный пакет ARP, pаспpостpаненный компьютеpом Р, может не дойти до компьютеpа Q ?

11.4 Должна ли возможнось идентификации нескольких мест назначения пpи помощи поpтов быть включена в IP? Почему да или почему нет?

11.5 Регистp имен. Пpедположим, вы хотите установить связь между двумя пpикладными пpогpаммами пpи помощи UDP, но вы не хотите назначать им фиксиpованные номеpа поpтов. Вместо этого вам хотелось бы, чтобы пpогpаммы идентифициpовали дpуг дpуга пpи помощи стpоки символов длиной 64 или меньше. Пусть пpогpамма на машине А хочет связаться с пpогpаммой с идентификатором funny на машине В (мы пpедполагаем, что пpоцесс всегда знает IP-адpес хоста, с программой на котоpом он хочет связаться). Между тем, пpоцесс на машине С хочет связаться с программой с идентификатором comer на машине А. Покажите, что вам только нужно назначить один поpт UDP, чтобы сделать такое соединение возможным, путем pазpаботки пpогpаммного обеспечения на каждой машине, котоpое позволяло бы:

а)локальному пpоцессу занять неиспользованный поpт UDP, чеpез котоpый он будет связываться,

b)локальному пpоцессу заpегистpиpовать 64-символьное имя, котоpое ему пpиписано, и

с)дpугому пpоцессу посpедством UDP установить связь, используя только 64-символьное имя и межсетевой адpес назначения.

11.6 Сделайте пpогpамму pегистpации имен из пpедыдущего упpажнения.

11.7 Какое главное пpеимущество использования пpедваpительно назначенных номеpов поpтов UDP? Главный недостаток?

11.8 Какое главное пpеимущество использования поpтов вместо идентификаторов пpоцессов при спецификации получателя внутpи машины?

11.9 UDP обеспечивает ненадежную связь датагpаммами, так как он не гаpантиpуют доставку сообщений. Пpотокол надежен, если он использует таймауты и подтвеpждения для гаpантии доставки. Какова цена надежности?


Д. Комер "Межсетевой обмен с помощью TCP/IP". Введение

Введение

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

Чтобы понимать сетевой обмен и круг вопросов, рассматриваемых в книге, важно представлять, что сетевые исследования и разработки прошли через три стадии развития До 1960 года, основным вопросом был "Как передавать биты по среде коммуникации эффективно и надежно?". Результаты включают разработку теории информации, теоремы Котельникова и других идей, которые в совокупности называют обработкой сигналов. От начала и до середины 60-х внимание было сконцентрировано на пакетной коммутации и основным вопросом стал: "Как передавать пакеты по среде коммуникации эффективно и надежно?" . Результатами этого этапа стали разработка технологий пакетной коммутации, локальных вычислительных сетей и статистический анализ времени передачи пакетов по сети в зависимости от загрузки. Приблизительно с середины 70-х и до нынешнего времени самым главным направлением стали сетевые архитектуры и вопрос "Как обеспечить средства взаимодействия взаимосвязанных сетей?". Результатами последнего этапа стала разработка технологий межсетевого обмена, многоуровневых моделей протоколов, дейтаграммных и потоковых транспортных средств и парадигмы взаимодействия клиент-сервер.

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

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

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

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

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

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

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

Эта книга организована в виде четырех основных частей. Главы 1 и 2 образуют введение, которое обеспечивает обзор и рассматривает существующие технологии. В частности, глава 2 рассматривает физическое сетевое оборудование. Идея заключается в том, чтобы дать интуитивное понимание о том, что возможно, не тратя лишнего времени на детальное изучение оборудования. Главы 3-12 описывают Интернет TCP/IP с точки зрения отдельной ЭВМ, показывая доступные базовые средства и протоколы, которые использует ЭВМ для доступа к ним. Они охватывают основы адресации Интернета и маршрутизацию, а также понятие о многоуровневой модели протоколов. Главы 13-17 описывают архитектуру сообщества сетей при рассмотрении его в глобальном смысле. Они описывают систему базовых шлюзов и протоколы, которые шлюзы используют для обмена информацией о маршрутах. Наконец, главы 18-26 рассматривают прикладные средства, доступные в Интернете. Они описывают модель взаимодействия клиент-сервер и дают несколько примеров того, как можно организовать программное обеспечение клиента и сервера. Последняя часть рассматривает электронную почту и доменную(domain) систему имен, два раздела, которые очень популярны.

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

Хотя и трудно опустить любую главу полностью, преподаватель обнаружит, что студенты часто удовлетворяются знанием того, что что-то возможно, не зная того, как это возможно. Например, можно пройти главы 5, 6 и 9, рассмотрев только возможности и опустив детали протоколов. Кроме того, несколько глав(особенно 16) содержат инженерные технологии, которые могут быть пропущены ради сохранения времени.

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

Много людей внесло свой вклад в создание этой книги. Я благодарю Scott Ballew, Steve Chapin, Jim Griffioen, Chris Kent, Tim Korb, Dan Lynch, Thomas Narten, Vic Norman, Shawn Ostermann, John Steele, Mike StJohns, Dan Tormey, Ray Yavatkar и Preston Wilson, которые читали рукопись и сделали ряд ценных замечаний. Craig Partridge внес много предложений, включая упражнения и исправил несколько технических ошибок. Он и Van Jacobson предложили граф задержек при передаче данных через Интернет в главе 12. Dave Stevens внес как технические, так и грамматические улучшения во второе издание. Barry Shein позволил мне использовать в качестве примера код для UNIX клиента и сервера в приложении 1. Charlotte Tubis сильно помогла при редактировании книги. Особая благодарность моей жене, Chris, которая читала текст бессчетное число раз и внесла много предложений.


Радик Усманов. RFC-768: Протокол UDP

Протокол UDP

Радик Усманов
radik@binep.ac.ru

Январь, 1995 г.

Реферат: Документ содержит русский перевод спецификации протокола UDP (User Datagram Protocol) - одного из основных транспортных протоколов стека IP, применяемого в международной компьютерной сети Internet. Оригинальный документ известен, как RFC768.

Примечания редактора

Оригинальная версия документа RFC768 размещается на сервере ISI (Information Sciences Institute http://www.isi.edu/):

 URL - http://info.internet.isi.edu/in-notes/rfc/files/rfc768.txt
RFC 768                                                        J. Postel
                                                                     ISI
                                                          28 August 1980

                    Протокол датаграмм клиента
                      User Datagram Protocol
                      ----------------------

Введение
--------

   Этот протокол (User Datagram Protocol - UDP) проектировался для
создания в объединенной системе компьютерных сетей с коммутацией
пакетов режима передачи датаграмм клиента. Протокол UDP предпола-
гает, что нижестоящим протоколом является Internet (IP) [1].

   Данный протокол предоставляет прикладной программе процедуру
для посылки сообщений другим программам, причем механизм протокола
минимален. Протокол UDP ориентирован на транзакции, получение да-
таграмм и защита от дублирования не гарантированы. Приложения,
требующие гарантированного получения потоков данных, должны ис-
пользовать протокол управления пересылкой (Transmission Control
Protocol - TCP) [2].

Формат
------

                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |      Порт       |      Порт       |
                 |   Отправителя   |   Получателя    |
                 +--------+--------+--------+--------+
                 |                 |  Контрольная    |
                 |      Длина      |       сумма     |
                 +--------+--------+--------+--------+
                 |
                 |       октеты данных  ...
                 +---------------- ...

              Формат заголовка для датаграмм клиента

Поля
----

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

Длина - длина в октетах данной датаграммы, включая как заголовок,
так и данные (Это означает, что минимальное значение поля длины
равно восьми).

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

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

                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |        адрес отправителя          |
                 +--------+--------+--------+--------+
                 |        адрес получателя           |
                 +--------+--------+--------+--------+
                 |  нули  |протокол|    длина UDP    |
                 +--------+--------+--------+--------+

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

Интерфейс пользователя
----------------------

Интерфейс пользователя должен позволять:

- создание новых портов для получения датаграмм

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

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

Интерфейс протокола IP
----------------------

Модуль протокола UDP должен иметь возможность извлекать из Inter-
net заголовка датаграммы Internet адреса отправителя и получателя,
а также тип протокола. Один из возможных интерфейсов UDP/IP мог бы
возвращать в ответ на команду получения полную Internet датаграм-
му, включая Internet заголовок целиком. Такой интерфейс мог бы
также позволить протоколу UDP передавать протоколу IP для посылки
некую готовую Internet датаграмму вместе с заголовком. Протокол IP
мог бы лишь проверять определенные поля Internet заголовка на со-
вместимость, а также вычислять контрольную сумму.

Применение протокола
--------------------

Главным применением протокола UDP являются системы Internet Name
Server [3], и Trivial File Transfer [4].

Номер протокола
---------------

При использовании Internet протокола протокол UDP идентифицируется
номером 17 (21 в восьмеричной системе счисления). Список других
номеров протокола приведен в документе [5].

Ссылки
------

[1]     Postel,   J.,   "Internet  Protocol,"  RFC 760,  USC/Information
        Sciences Institute, январь 1980.

[2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC 761,
        USC/Information Sciences Institute, январь 1980.

[3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
        Institute, IEN 116, август 1979.

[4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
        Technology, IEN 133, январь 1980.

[5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
        Institute, RFC 762, январь 1980.
Содержание


Протокол IP

Радик Усманов
radik@binep.ac.ru

Сентябрь 1994 г.

Реферат: Документ содержит русский перевод спецификации сетевого протокола IP (Internet Protocol) - основного протокола международной компьютерной сети Internet. Оригинальный документ известен, как RFC791.

Примечания редактора

Оригинальная версия документа RFC791 размещается на сервере ISI (Information Sciences Institute http://www.isi.edu/):

 URL - http://info.internet.isi.edu/in-notes/rfc/files/rfc791.txt

RFC 791                     Internet протокол
                          Проект Darpa Internet
                         Спецификация протокола
                              сентябрь 1981

                            приготовлено для
        Агенства расширенных оборонных исследовательских проектов
                  Офис технологий обработки информации
                          1400 Wilson Boulevard
                        Arlington, Virginia 22209

                         Институтом Информатики
                       Университета Южной Каролины
                           4676 Admiralty Way
                    Marina del Rey, California 90291

                               Содержание
  Предисловие
1. Введение
  1.1 Обоснование
  1.2 Цель
  1.3 Интерфейсы
  1.4 Действие
2. Обзор
  2.1 Связь с другими протоколами
  2.2 Сценарий работы
  2.3 Описание функций
  2.4 Шлюзы
3. Спецификация
  3.1 Формат заголовка Internet
  3.2 Обсуждение
  3.3 Интерфейсы
Приложение А: Примеры и сценарии
Приложение Б: Порядок передачи данных
Толковый словарь
Ссылки

                               Предисловие
Данный документ устанавливает Internet протокол в стандарте DOD. Он
основан на шести предыдущих версиях спецификации протокола ARPA
Internet, и из них в значительной степени заимствован его текст. Вместе
с тем в эту работу внесены многие изменения, касающиеся как
терминологии, так и собственно изложения материала. Это издание освещает
адресацию, обработку ошибок, коды опций, а также безапасность, историю и
поддержку свойств протокола Internet.
                                         Джон Постел (Jon Postel)
                                            Редактор

                            Протокол Internet
                        Программа DARPA Internet
                         Спецификация протокола

                               1. Введение
1.1 Обоснование
   Протокол Internet создан для использования в объединенных системах
компьютерных коммуникационных сетей с коммутацией пакетов. Такие системы
были названы "catenet" [1]. Протокол Internet обеспечивает передачу
блоков данных, называемых датаграммами, от отправителя к получателям,
где отправители и получатели являются хост-компьютерами,
идентифицируемыми адресами фиксированной длины. Протокол Internet
обеспечивает при необходимости также фрагментацию и сборку датаграмм для
передачи данных через сети с малым размером пакетов.

1.2 Цель
   Протокол Internet специально ограничен задачами обеспечения функций,
необходимых для передачи битового пакета (датаграммы Internet) от
отправителя к получателю через объединенную систему компьютерных сетей.
Нет механизмов для увеличения достоверности конечных данных, управления
протоколом, синхронизации или других услуг, обычно приненяемых в
протоколах передачи от хоста к хосту. Протокол Ineternet может обобщить
услуги поддерживающих его сетей с целью предоставления услуг различных
типов и качеств.

1.3 Интерфейсы
   Данный протокол получил название в соответствии с протоколами
передачи информации между хост-компьютерами в межсетевой среде. Протокол
вызывает в локальной сети протоколы для передачи датаграммы Internet на
следующий шлюз или хост-получатель.
   Например, модуль TCP вызывал бы модуль Internet с тем, чтобы получить
сегмент TCP (включая заголовок TCP и данные пользователя) как
информационную часть Internet пакета. Модуль TCP обеспечил бы адреса и
другие параметры в заголовке модуля Internet в качестве параметров
рассматриваемого вызова. Модуль Internet в этом случае создал бы
датаграмму Internet и прибегнул бы к услугам локальной сети для передачи
датаграммы Internet.
   Например, в случае сети ARPANET модуль Ineternet вызывал бы локальный
сетевой модуль, который бы добавлял к датаграмме Internet проводник типа
1822 [2], создавая сообщение ARPANET для передачи на IMP. Адрес ARPANET
получился бы из адреса Intenet с помощью интерфейса локальной сети и
относился бы к некоторому хост-компьютеру в сети ARPANET, который мог бы
быть шлюзом в другие сети.

1.4 Действие
   Протокол Internet выполняет две главные функции: адресацию и
фрагментацию.
   Модули Internet используют адреса, помещенные в заголовок Internet,
для передачи Internet датаграмм их получателям. Выбор пути передачи
называется маршрутизацией.
   Модули Internet используют поля в заголовке Internet для фрагментации
и восстановления датаграмм Internet, когда это необходимо для их
передачи через сети с малым размером пакетов.
   Сценарий действия состоит в том, что модуль Internet меняет размер на
каждом из хостов, задействованных в internet-коммуникации и на каждом из
шлюзов, обеспечивающих взаимодействие между сетями. Эти модули
придерживаются общих правил для интерпретации полей адресов, для
фрагментации и сборки Internet датаграмм. Кроме этого, данные модули (и
особенно шлюзы) имеют процедуры для принятия решений о маршрутизации, а
также другие функции.
   Протокол Internet обрабатывает каждую Internet датаграмму как
независимую единицу, не имеющую связи ни с какими другими датаграммами
Internet. Протокол не имеет дело ни с соединениями, ни с логическими
цепочками (виртуальными или какими-либо другими).
   Протокол Internet использует четыре ключевых механизма для
формирования своих услуг: задание типа сервиса, времени жизни, опций и
контрольной суммы заголовка.
   Тип обслуживания используется для обозначения требуемой услуги. Тип
обслуживания - это абстрактный или обобщенный набор параметров, который
характеризует набор услуг, предоставляемых сетями, и составляющих
собственно протокол Internet. Этот способ обозначения услуг должен
использоваться шлюзами для выбора рабочих параметров передачи в
конкретной сети, для выбора сети, используемой при следующем переходе
датаграммы, для выбора следующего шлюза при маршрутизации сетевой
Internet датаграммы.
   Механизм времени жизни служит для указания верхнего предела времени
жизни Internet датаграммы. Этот параметр устанавливается отправителем
датаграммы и уменьшается в каждой точке на проходимом датаграммой
маршруте. Если параметр времени жизни станет нулевым до того, как
Internet датаграмма достигнет получателя, эта датаграмма будет
уничтожена. Время жизни можно рассматривать как часовой механизм
самоуничтожения.
   Механизм опций предоставляет функции управления, которые являются
необходимыми или просто полезными при определенных ситуациях, однако он
ненужен при обычных комминикациях. Механизм опций предоставляет такие
возможности, как временные штампы, безопасность, специальная
маршрутизация.
   Контрольная сумма заголовка обеспечивает проверку того, что
информация, используемая для обработки датаграмм Internet, передана
правильно. Данные могут содержать ошибки. Если контрольная сумма
неверна, то Internet датаграмма будет разрушена, как только ошибка будет
обнаружена.
   Протокол Internet не обеспечивает надежности коммуникации. Не имеется
механизма подтверждений ни между отправителем и получателем, ни между
хост-компьютерами. Не имеется контроля ошибок для поля данных, только
контрольная сумма для заголовка. Не поддерживается повторная передача,
нет управления потоком.
   Обнаруженные ошибки могут быть оглашены посредством протокола ICMP
(Internet Control Message Protocol) [3], который поддерживается модулем
Internet протокола.

                                2. Обзор
2.1 Связь с другими протоколами
   Следующая диаграмма иллюстрирует место протокола Internet в иерархии
протоколов.
           +------+ +-----+ +------+       +-----+
           |Telnet| | FTP | | TFTP |  ...  | ... |
           +------+ +-----+ +------+       +-----+
                 |   |         |              |
                +-----+     +-----+        +-----+
                | TCP |     | UDP |   ...  | ... |
                +-----+     +-----+        +-----+
                    |          |             |
                   +--------------------------+
                   | Internet Protocol & ICMP |
                   +--------------------------+
                                 |
                    +------------------------+
                    | Local Network Protocol |
                    +------------------------+

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

2.2 Сценарий работы
   Схему действий для передачи датаграммы от одной прикладной программы
к другой можно проиллюстрировать следующим образом:
   Предположим, что перенос будет включать прохождение одного
промежуточного шлюза. Отправляющая прикладная программа готовит свои
данные и вызывает свой локальный Internet модуль для отправки этих
данных в качестве датаграммы, а в качестве аргументов этого вызова
передает адрес получателя и другие параметры.
   Модуль Internet готовит заголовок датаграммы и стыкует с ним данные.
Модуль Internet определяет локальный сетевой адрес, соответствующий
данному адресу Internet. В данном случае это адрес шлюза.
   Модуль передает данную датаграмму и адрес в локальной сети в
распоряжение интерфейса локальной сети.
   Интерфейс локальной сети создает соответствующий этой сети заголовок
и соединяет с ним датаграмму. Затем он передает по локальной сети
полученный таким образом результат.
   Датаграмма достигает хост-компьютер, играющий роль шлюза и
расположенный в вершине сети. Интерфейс локальной сети отделяет этот
заголовок и передает датаграмму на модуль Internet. Модуль Internet
определяет из Internet адреса, что датаграмма должна быть направлена на
хост-компьютер во второй сети. Модуль Internet определяет адрес
хоста-получателя в локальной сети. Он обращается к интерфейсу локальной
сети с тем, чтобы она переслала данную датаграмму по назначению.
   Интерфейс создает заголовок локальной сети и соединяет с
ним датаграмму, а затем результат на правляет на хост-получатель.
   На хосте-получателе интерфейс локальной сети удалает заголовок
локальной сети и передает оставшееся на Internet модуль.
   Модуль Internet определяет, что рассматриваемая выше датаграмма
предназначена для прикладной программы на этот хосте. Модуль передает
данные прикладной программе в ответ на системный вызов. В качестве
результата этого вызова передаются адрес получателя и другие параметры.

прикладная программа                               прикладная программа
           \                                            /
      модуль Internet       модуль Internet      модуль Internet
              \                /        \            /
             LNI-1         LNI-1        LNI-2     LNI2
                 \          /              \      /
                локальная сеть 1        локальная сеть 2

              Рис. 2 Путь передачи датаграммы

2.3 Описание функций
   Функция или цель протокола Internet состоит в передаче датаграммы
через набор объединенных компьютерных сетей. Это осуществляется
посредством передачи датаграмм от одного модуля Internet к другому до
тех пор, пока не будет достигнут получатель. Модули Internet находятся
на хостах и шлюзах системы Internet. Датаграммы направляются с одного
модуля Internet на другой через конкретные компьютерные сети, основанные
на интерпретации Internet адресов. Таким образом, одним из важных
механизмов протокола Internet является Internet адрес.
   При передаче сообщений с одного Internet модуля на другой датаграммы
могут нуждаться в прохождении через сети, для которых максимальный
размер пакета меньше, чем размер датаграммы. Чтобы преодолеть эту
сложность, в протокол Internet включен механизм фрагментации.
   Адресация. В протоколе сделано разграничение между именами, адресами
и маршрутами [4]. Имя показывает искомый нами объект. Адрес показывает
его местонахождение. Internet имеет дело с адресами. Перевод имен в
адреса является задачей протоколов более высокого уровня (прикладных
программ или протоколов передачи синхронизации с хоста на хост).
Собственно модуль Internet осуществляет отображение адресов Internet на
адреса локальной сети. Создание карты адресов локальной сети для
получения маршрутов - задача процедур более низкого уровня (процедур
локальной сети или шлюзов).
   Адреса имеют фиксированную длину четыре октета (32 бита). Адрес
начинается с сетевого номера, за которым следует локальный адрес
(называемый полем остатка "rest"). Существуют три формата или класса
адресов Internet. В классе a самый старший бит нулевой. Следующие 7 бит
определяют сеть. а последние 24 бита - локальный адрес. В классе b самые
старшие два бита равны соответственно 1 и 0, следующие 14 бит определяют
сеть, а последние 16 бит - локальный адрес. В классе c три самых старших
бита равны соответственно 1,1 и 0, следующие 21 бит определяют сеть, а
последние 8 бит - локальный адрес.
   При отображении карты Internet адресов на адреса локальной сети
следует соблюдать осторожность. Единичный хост-компьютер должен уметь
работать так, как если бы на его месте существовало несколько отдельных
хост-компьютеров для использования нескольких адресов Internet.
Некоторые хост-компьютеры будут также иметь несколько физических
интерфейсов (multi-homing).
   Таким образом, следует обеспечить каждый хост-компьютер несколькими
физическими сетевыми интерфейсами, имеющими по несколько логических
адресов Internet.
   Примеры построения карты адресов можно найти в документе "Address
Mapping" [5].
   Фрагментация. Фрагментация Internet датаграммы необходима, когда эта
датаграмма возникает в локальной сети, позволяющей работать с пакетами
большого размера, и затем должна пройти к получателю через другую
локальную сеть, которая ограничивает пакеты меньшим размером.
   Internet датаграмма может быть помечена как нефрагментируемая. Любая
Internet датаграмма, помеченная таким образом, не может быть
фрагментирована модулем Internet ни при каких условиях. Если же Internet
датаграмма, помеченная как нефрагментируемая, тем не менее не может
достигнуть получателя без фрагментации, то вместо этого она будет
разрушена.
   Фрагментация, перенос и сборка в локальной сети, невидимые для модуля
Internet протокола, называются внутрисетевой фрагментацией и могут быть
всегда использованы [6].
   Необходимо, чтобы Internet процедуры фрагментации и сборки могли
разбивать датаграмму на почти любое количество частей, которые
впоследствии могли бы быть вновь собраны. Получатель фрагмента
использует поле идентификации для того, чтобы быть убежденным в том, что
фрагменты различных датаграмм не будут перепутаны. Поле смещения
фрагмента сообщает получателю положение фрагмента в исходной датаграмме.
Смещение фрагмента и длина определяют кусок исходной датаграммы,
принесенный этим фрагментом. Флаг "more fragments" показывает
(посредством перезагрузки) появление последнего фрагмента. Эти поля дают
достаточное количество информации для сборки датаграмм.
   Поле идентификации позволяет отличить фрагменты одной датаграммы от
фрагментов другой. Модуль Internet, отправляющий Internet датаграмму,
устанавливает в поле идентификации значение, которое должно быть
уникальным для данной пары отправитель - получатель, а также время, в
течении которого датаграмма будет активна в системе Internet. Модуль
протокола, отправляющий нерасчлененную датаграмму, устанавливает в нуль
флаг "more fragments" и смещение во фрагменте.
   Чтобы расчленить большую Internet датаграмму, модуль протокола
Internet (например, шлюз), создает две новые Intenet датаграммы и
копирует содержимое полей Internet заголовка из большой датаграммы в оба
новых Internet заголовка. Данные из старой датаграммы делятся на две
части по границе на очередном восьмом октете (64 бита). Полученная таким
образом вторая часть может быть кратна 8 октетам, а может и не быть, но
первая часть кратна всегда. Заказывается количество блоков первой части
NFB (количество блоков фрагмента). Первая часть данных помещается в
первую новую Internet датаграмму, в поле общей длины помещается длина
первой датаграммы. Флаг "more fragments" устанавливается в единицу.
Вторая часть данных помещается во вторую новообразованную Internet
датаграмму, в поле общей длины заносится длина второй датаграммы. В поле
смещения фрагмента во второй Internet датаграмме устанавливается
значение такого же поля в исходной большой датаграмме, увеличенное на
NFB.
   Эта процедура может быть обобщена на случай многократного расщепления
исходной датаграммы.
   Чтобы собрать фрагменты Internet датаграммы, модуль протокола
Internet (например, модуль на хост-компьютере) объединяет Internet
датаграммы, имеющие одинаковые значения в полях идентификатора,
отправителя, получателя и протокола. Собственно объединение заключается
в помещении данных из каждого фрагмента в позицию, указанную в заголовке
Internet пакета в поле "fragment offset". Первый фрагмент будет иметь в
поле "fragment offset" нулевое значение, а последний фрагмент будет
иметь флаг "more fragments", вновь установленный в нуль.

2.4 Шлюзы
   С помощью шлюзов протокол Internet осуществляет передачу датаграмм
между сетями. Шлюзы также поддерживают протокол шлюз-шлюз (GGR) [7] для
координации маршрутизации и передачи другой управляющей информации для
протокола Internet.
   Нет нужды держать на шлюзе протоколы более высокого уровня, а функции
GGP добавляются к возможностям IP модуля.

                   +--------------------------------+
                   | Internet протокол & ICMP & GGP |
                   +--------------------------------+
                           |                |
                 +----------------+  +----------------+
                 | локальная сеть |  | локальная сеть |
                 +----------------+  +----------------+

                        Рис. 3   Протоколы шлюзов

                             3. Специфиация
3.1 Формат заголовка Internet
   Ниже приведена полная схема полей заголовка Internet

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Рис. 4 Пример заголовка Internet датаграммы
Заметим, что каждая позиция соответствует одному биту.

Version (версия) 4 бита
   Поле версии показывает формат заголовка Internet. Данный документ
   описывает версию 4.
IHL (длина Internet заголовка) 4 бита
   Длина Internet заголовка измеряется в словах по 32 бита каждый и
   указывает на начало поля данных. Заметим, что корректный заголовок
   может иметь минимальный размер 5 слов.
Type of Service (тип сервиса) 8 бит
   Тип сервиса определяет с помощью неких абстрактных параметров тип
   требуемого обслуживания. Эти параметры должны использоваться для
   управления выбором реальных рабочих характеристик при передаче
   датаграммы через конкретную сеть. Некоторые сети осуществляют
   обслуживание с приоритетом, которое неким образом дает преимущество
   для продвижения данной датаграммы по сравнению со всеми остальными.
   Реально выбор осуществляется между тремя альтернативами: малой
   задержкой, высокой достоверностью и высокой пропускной способностью.
   биты 0-2  приоритет
   бит 3     0 - нормальная задержка, 1 - малая задержка
   бит 4     0 - нормальная пропускная способность,
             1 - высокая пропускная способность
   бит 5     0 -  обычная достоверность, 1 - высокая достоверность
   биты 6-7 зарезервированы

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |     приоритет   |  D  |  T  |  R  |  0  |  0  |
   +-----+-----+-----+-----+-----+-----+-----+-----+

   Приоритет
   111 - управление сетью
   110 - межсетевое управление
   101 - CRITIC/ECP
   100 - более, чем мгновенно
   011 - мгновенно
   010 - немедленно
   001 - приоритетно
   000 - обычный маршрут

   Использование индикации задержки, пропускной способности и
   достоверности может, в некотором смысле, увеличить стоимость
   обслуживания. Во многих сетях улучшение одного из этих параметров
   связано с ухудшением другого. Исключения, когда имело бы смысл
   устанавливать два из этих трех параметров, очень редки.
      Тип обслуживания используется для указания типа обработки
   датаграммы при ее прохождении через систему Internet. Примеры
   отображения типа обслуживания в протоколе Internet на реальные
   услуги, предоставляемые такими сетями, как AUTODIN II, ARPANET,
   SATNET и PRNET даны в документе "Service Mapping" [8]. Значение
   "управление сетью" следует присваивать приоритету только для
   использования внутри локальной сети. Управление и реальное
   использование этого аргумента должно находиться в согласии с каждой
   применяющей его сетью. Аргумент "межсетевое управление" предназначен
   только для использования шлюзами, берущими на себя управление. Если
   вышеописанные аргументы приоритета находят применение в какой-либо
   сети, то это означает, что данная сеть может управлять приемом и
   использованием этих аргументов.
Total Length (общая длина) 16 бит
   Общая длина - это длина датаграммы, измеренная в октетах, включая
   Internet заголовок и поле данных. Это поле может задавать длину
   датаграммы вплоть до 65535 октетов. В большинстве хост-компьютеров и
   сетей столь большие датаграммы не используются. Все хосты должны быть
   готовы принимать датаграммы вплоть до 576 октетов длиной (приходят ли
   они целиком или по фрагментам). Хостам рекомендуется отправлять
   датаграммы размером более чем 576 октетов, только если они уверены,
   что принимающий хост готов обслуживать датаграммы повышенного
   размера.
      Значение 576 выбрано с тем, чтобы соответсвующим образом
   ограниченный блок данных передавался вместе с требуемой информацией в
   заголовке. Например, этот размер позволяет заполнять датаграмму полем
   данных размером в 512 октетов и заголовком в 64 октета. Наибольший
   Internet заголовок занимает 60 октетов, а его типичный размер
   составляет всего 20 октетов, что оставляет место под заголовки
   протоколов более высокого уровня.
Identification (идентификатор) 16 бит
   Идентификатор устанавливается отправителеим для сборки фрагментов
   какой-либо датаграммы.
Flags (различные управляющие флаги) 16 бит
   бит 0      зарезервирован, должен быть нуль
   бит 1 (DF) 0 - возможно фрагментирование, 1 - запрет фрагментации
   бит 2 (MF) 0 - последний фрагмент, 1 - будут еще фрагменты
      0    1    2
   +----+----+----+
   |  0 | DF | MF |
   +----+----+----+
Fragment Offset (смещение фрагмента) 13 бит
   Это поле показывает, где в датаграмме находится этот фрагмент.
   Смещение фрагмента изменяется порциями по 8 октет (64 бита). Первый
   фрагмент имеет смещение нуль.
Time to Live (Время жизни) 8 бит
   Это поле показывает максимальное время, в течении которого датаграмме
   позволено находиться в системе Internet. Если это поле имеет значение
   нуль, то датаграмма должна быть разрушена. Значение этого поля
   изменяется при обработке заголовка Internet. Время измеряется в
   секундах. Однако, поскольку каждый модуль, обрабатывающий датаграмму,
   должен уменьшать значение поля TTL по крайней мере на единицу, даже
   если он обрабатываетт эту датаграмму менне, чем за секунду, то поле
   TTL следует понимать как максимальный интервал времени, в течении
   которого датаграмма может сущенствовать. Внимание следует обратить на
   разрушение датаграмм, не могущих достигнуть получателя, а также на
   ограничение времени жизни датаграммы.
Protocol (Протокол) 8 бит
   Это поле показывает, какой протокол следующего уровня использует
   данные из Internet датаграммы. Значения для различных протоколов
   приводятся в документе "Assigned Numbers" [9].
Header Checksum (Контрольная сумма заголовка) 16 бит
   Поскольку некоторые поля заголовка меняют свое значение (например,
   время жизни), это значение проверяется и повторно рассчитывается при
   каждой обработке Internet заголовка.
   Алгоритм контрольной суммы следующий:
     Поле контрольной суммы - это 16 бит, дополняющие биты в сумме всех
     16 битовых слов заголовка. Для вычисления контрольной суммы
     значение этого поля устанавливается в нуль.
   Контрольную сумму легко рассчитать и опытным путем доказать ее
   адекватность, однако это временная мера и должна быть заменена CRC
   процедурой в зависимости от дальнейшего опыта.
Source Address (адрес отправителя) 32 бита (см. часть 3.2)
Destination Address (адрес получателя) 32 бита (см. часть 3.2)
Options (опции)    поле переменной длины
   Опции могут появиться в датаграммах, а могут и не появляться. Они
   должны поддерживаться всеми Internet модулями (хостами и шлюзами).
   Не обязательно каждая конкретная датаграмма несет опции, но нести их
   все же может.
   В некоторых приложениях опция секретности должна присутствовать во
   всех датаграммах.
   Поле опций не имеет постояннойц длины. Опций может не быть, а может
   быть несколько. Существуют два формата опции:
   - единичный октет с указанием типа опции
   - единичный октет с указанием типа опции, октет для указания длины
   опции, и, наконец, октеты собственно данных.
   Октет длины поля учитывает октет типа опции, сам себя и октеты с
   данными для опции.
   Считается, что октет типа опции состоит из трех полей:
      1 бит   флаг копирования
      2 бита  класс опции
      5 бит   номер опции
   Флаг копирования показывает, что эта опция копируется во все
   фрагменты при фрагментации.
      0 - не копируется
      1 - копируется
   Классы опции
      0 - управление
      1 - резервировано
      2 - отладка и измерения
      3 - резервировано
   Определены следующие опции Internet
   класс номер длина описание
     0     0     -   Конец списка опций. Эта опция занимает лишь один
                     октет, октет длины отсутствует.
     0     1     -   Нет операции. Эта опция занимает лишь один октет.
                     Не имеет октета длины.
     0     2    11   Безопасность. Используется для поддержания
                     безопасности, изоляции, разделения на группы
                     пользователей (TCC), обработки кодов ограничения,
                     соответсвующих DOD требованиям.
     0     3   перем Потеря маршрута отправителя. Используется для
                     передачи Internet датаграммы, основанной на
                     имеющейся у отправителя информации
     0     9   перем Определение маршрута отправителя. Используется для
                     передачи Internet датаграммы, основанной на
                     имеющейся у отправителя информации
     0     7   перем Запись маршрута. Используется для отслеживания
                     проходимого Internet датаграммой маршрута.
     0     8     4   Идентификатор маршрута. Используется для поддержки
                     идентификации потока.
     2     4   перем Временной штамп Internet.
   Отдельные описания опций
           +--------+
   Тип 0   |00000000| End of Option List   (конец списка опций)
           +--------+
      Эта опция обозначает конец списка опций. Он может не совпадать с
      окончанием Internet заголовка, обозначаемым полем Internet header
      length. Эта опция используется после всех опций, но не после
      каждой. Она необходима только в том случае, если конец списка
      опций не совпал с окончанием Internet заголовка.
      Может быть скопирован, внесен или удален при фрагментации, или по
      какой-либо другой причине.
           +--------+
   Тип 1   |00000001| No operation  (нет действий)
           +--------+
      Эта опция может быть использована между другими опциями. Ее целью
      может служить, к примеру, выравнивание очередной опции по 32-
      битной границе. Может быть скопирована, внесена или удалена при
      фрагментации и по любой другой причине.
   Тип 130            Security  (безопасность)
      Эта опция дает способ хост-компьютерам отправлять параметры,
      связанные с безопасностью, закрытостью, введением ограничений и
      параметрами TCC (закрытой группой пользователей). Формат этой
      опции следующий:  (длина 11 октетов)
      +--------+--------+---///---+---///---+---///---+---///----+
      |10000010|00001011|SSS...SSS|CCC...CCC|HHH...HHH|   TCC    |
      +--------+--------+---///---+---///---+---///---+---///----+
      Поле S (security) 16 бит
         Указывает один из 16 уровней безопасности (восемь из которых
         зарезервировано).
         00000000 00000000 - неклассифицировано
         11110001 00110101 - конфиденциальный
         01111000 10011010 - EFTO
         10111100 01001101 - MMMM
         01011110 00100110 - PROG
         10101111 00010011 - ограниченный
         11010111 10001000 - секретный
         01101011 11000101 - особо секретный
         00110101 11100010 - резервировано
         10011010 11110001 - резервировано
         01001101 01111000 - резервировано
         00100100 10111101 - резервировано
         00010011 01011110 - резервировано
         10001001 10101111 - резервировано
         11000100 11010110 - резервировано
         11100010 01101011 - резервировано
      Поле C (compartments) 16 бит
         Нулевое значение во всех позициях используется когда передача
         информации не ограничена. Остальные значения для этого поля
         можно получить от Секретного Оборонного Агенства.
      Поле H (введение ограничений) 16 бит
         Значения для управления и внесения меток являются буквенно-
         цифровыми диграммами и опредены в документе DIAM 65-19
         "Standard Security Markings".
      Поле TCC (поле управления переносом) 24 бита
         Дает средства для отслеживания процесса отделения, его значения
         контролируются группами заинтересованных подписчиков. Значения
         TCC имеют три поля для записей и могут быть получены из
         документа HQ DCA Code 530.
      Рассматриваемый тип должен копироваться при фрагментации. Эта
      опция появляется в датаграмме не более одного раза.
   Тип 131           Loose Source and Record Route
                    (Потеря отправителя и запись маршрута)
      +--------+--------+---------+------- // ------+
      |10000011| длина  |указатель|данные о маршруте|
      +--------+--------+---------+------- // ------+
      Опция потери отправителя и записи маршрута (LSRR) обеспечивает
      средства, позволяющие отправителю Internet датаграммы передавать
      информацию, используемую шлюзами при передаче датаграмм по
      назначению, а также записывать информацию о маршруте.
      Опция начинается с кода типа. Второй октет - октет длины, которая
      учитывает код типа опции и сам себя, а также октет указателя.
      Третий октет является указателем на данные о маршруте, он
      определяет октет, с которого начинается следующий адрес
      отправителя, подлежащий обработке. Указатель отсчитывается от
      начала рассматриваемой опции, а его наименьшее допустимое значение
      - 4.
      Данные о маршруте состоят из ряда Internet адресов. Каждый
      Internet адрес - это 32 бита или 4 октета. Если указатель
      превышает длину, то маршрут отправителя пуст (поле с записями
      маршрута заполнено), а маршрутизация должна основываться на
      значениях поля с адресом получателя.
      Если адрес, записанный в поле адреса получателя, был достигнут, а
      указатель не превысил длину, то следующий адрес в маршруте
      отправителя замещает адрес в поле с адресом получателя. Записанный
      адрес маршрута заменяет только что использованный адрес
      отправителя, а указатель увеличивается на 4.
      Записанный адрес маршрута является собственным Internet адресом
      Internet модуля, известным во внешнем окружении, куда эта
      датаграмма направляется.
      Эта процедура замещения исходного маршрута записанным маршрутом
      (хотя при обратном порядке он должен использоваться как маршрут
      отправителя) означает, что данная опция (а также и весь IP
      заголовок) сохраняет постоянный размер при прохождении датаграммы
      по Internet системе.
      Эта опция называется потерей маршрута отправителя (loose source
      route), поскольку шлюз или IP хост могут использовать любые
      маршруты через любое количество других промежуточных шлюзов для
      достижения следующего адреса в рассматриваемом маршруте. При
      фрагментации опция должна копироваться. В датаграмме она должна
      появляться не более одного раза.
   Тип 137          Strict Source and Record Route
                   (Уточнить отправитель и записать маршрут)
      +--------+--------+---------+------- // --------+
      |10001001| длина  |указатель| данные о маршруте |
      +--------+--------+---------+------- // --------+
      Опция "уточнить отправитель и записать маршрут" (SSRR) дает
      средства отправителю Internet датаграммы для поддержания
      информации о маршрутизации, которая должна использоваться шлюзами
      при передаче датаграммы по назначению, а также для записи этой
      информации.
         Опция начинается с кода типа. Второй октет - длина опции,
      которая учитывает код типа опции и октет длины, октет указателя (3
      октета с данными о маршруте). Третий октет является указателем на
      данные маршрута, определяющим октет, с которого начинается
      следующий адрес отправителя, подлежащий обработке. Указатель
      отсчитывается с начала этой опции, а наименьшее допустимое
      значение указателя - 4.
         Данные о маршруте состоят из серии Internet адресов. Каждый
      Internet адрес - это 32 бита или 4 октета. Если указатель
      превышает длину, то маршрут отправителя пуст (записываемый маршрут
      полон), а маршрутизация основывается на значении поля с адресом
      получателя.
         Если адрес в поле адреса получателя был достигнут, а указатель
      не превышает длины, то следующий адрес в маршруте отправителя
      замещает адрес в поле с адресом получателя, а записанный адрес
      маршрута замещает только что использованный адоес отправителя,
      указатель увеличивается на 4.
         Записанный адрес маршрута - это собственный Internet - адрес
      Internet - модуля, как он был бы распознан во внешней среде, куда
      эта датаграмма направляется.
         Эта процедура замещения маршрута отправителя записанным
      маршрутом (хотя в обратном порядке он должен использоваться как
      маршрут отправителя) означает, что опция (и весь IP заголовок)
      сохраняет постоянный размер при прохождении датаграммы через
      Internet систему.
         Эта опция является точным маршрутом отправителя, поскольку шлюз
      или IP хост должен посылать данную датаграмму непосредственно на
      следующий адрес в маршруте отправителя через напрямую соединенную
      сеть, на адрес, показывающий следующий шлюз или хост, указанный в
      маршруте.
         Опция должна копироваться при фрагментации. Появляется не более
      одного раза в датаграмме.
Тип 7  Record Route        (Записать маршрут)
      +--------+--------+---------+------- // --------+
      |00000111| длина  |указатель| данные о маршруте |
      +--------+--------+---------+------- // --------+
         Опция записи маршрута дает средства для записи маршрута
      Internet датаграммы.
         Опция начинается с кода типа. Второй октет определяет длину
      опции, которая учитывает код типа опции, сам себя, октет указателя
      и длину трех октетов с данными о маршруте. Третий октет является
      указателем на данные маршрута. Указатель определяет октет, с
      которого начинается следующее поле для размещения адреса маршрута.
      Указатель отсчитывается от начала рассматриваемой опции, а его
      наименьшее допустимое значение - 4.
         Записываемый маршрут состоит из серии Internet адресов. Каждый
      Internet адрес - это 32 бита или 4 октета. Если указатель больше,
      чем длина опции, то поле с записываемым маршрутом заполнено. Хост
      - компьютер, создающий эту опцию, должен зарезервировать поле с
      данными о маршруте и достаточным размером, с тем, чтобы оно
      вместило все ожидаемые адреса. Размер этой опции не изменяется при
      добавлении адресов. Первоначальное содержимое поля под данные о
      маршруте должно быть нулевым.
         Когда Internet модуль направляет датаграмму, он проверяет ее на
      присутствие рассматриваемой опции с записываемым маршрутом. Если
      она присутствует, то он вставляет свой собственный Internet адрес
      в качестве распознанного во внешней среде, куда эта датаграмма
      направлена. Вставка осуществляется в опцию записи маршрута, в то
      место, на которое указывает октет указателя. Указатель затем
      увеличивается на 4.
         Если поле с данными о маршруте уже заполнено (указатель
      превышает длину), то датаграмма направляется без вставки адреса в
      опцию заполняемого маршрута. Если имеется некоторое пространство,
      но недостаточное для вставки полного адреса, то исходная
      датаграмма считается ошибочной и разрушается. И в том, и в другом
      случае на хост-отправитель напрвляется сообщение о проблеме с ICMP
      параметром [3].
         При фрагментации не копируется, присутствует лишь в первом
      фрагменте. В датаграмме присутствует не более одного раза.
Тип 136 (длина 4)     Stream Identifier     (Идентификатор потока)
      +--------+--------+--------------------+
      |10001000|00000010|идентификатор потока|
      +--------+--------+--------------------+
         Эта опция дает средства для поддержания 16-битовой SATNET
      идентифткации потока в сетях, которые парвоначально не
      поддерживали потоковую концепцию.
         Опцтя должна копироваться при фрагментации. В датаграмме
      появляется не более одного раза.
Тип 68     Internet timestamp     (Временной штамп Internet)
      +--------+--------+---------+-----+-----+
      |01000100| длина  |указатель|oflw | flg |
      +--------+--------+---------+-----+-----+
      |           Internet адрес              |
      +---------------------------------------+
      |              Timestamp                |
      +---------------------------------------+
      |                                       |
         Длина - это количество октетов в опции, которое учитывает
      октеты типа, длины, указателя и overflow/flag (максимальная длина
      40 октетов).
         Указатель - это количество октетов от начала этой опции до
      конца временных штампов, плюс единица (т.е. он указывает на октет,
      с которого начинается свободное место для следующего временного
      штампа). Наименьшее допустимое значение - 5. Поле временного
      штампа считается заполненным, когда указатель превышает длину
      опции.
         Overflow (oflw, переполнение  4 бита) - это количество IP
      модулей, которые не могут произвести регистрацию временных штампов
      по причине отсутствия свободного места.
         Flag (flg, флаги  4 бита) - это
      0 - оставлять лишь временные штампы, размещенные в следующих друг
          за другом 32-битных словах
      1 - каждому временному штампу предшествует Internet адрес
          регистрируемого объекта
      3 - поля Internet адресов определены заранее. IP модуль лишь
          регистрирует свой временной штамп, если его собственный адрес
          совпадает со следующим указанным Inernet адресом.
      Timestamp - это выровненный по правой границе 32-битный временной
      штамп в миллисекундах (относительно полуночи по Единому Времени).
      Если время в миллисекундах неопределимо или не может быть
      отсчитано относительно полуночи по Единому Времени, то может быть
      внесено любое другое время в качестве временного штампа при
      условии, что самый старший бит в поле временного штампа будет
      установлен в единицу (что указавает на использование
      нестандартного значения).
         Хост-отправитель должен создавать эту опцию так, чтобы поля для
      временных штампов были достаточны для размещения всей ожидаемой
      информации. Размер опции не изменяется при добавлении временных
      штампов. Первоначально содержимое поля под временные штампы должно
      быть заполнено нулями, либо Internet адреса должны чередоваться с
      нулями.
         Если поле с временными штампами уже заполнено (указатель
      превышает длину опции), то датаграмма передается без вставки
      временного штампа, а счетчик переполнения увеличивается на
      единицу.
         Если имеется место, но оно недостаточно для вставки полного
      временного штампа, или же счетчик переполнения сам переполнен, то
      исходная датаграмма рассматривается как ошибочная и уничтожается.
      И в том, и в другом случае на хост-отправитель должно посылаться
      сообщение о проблеме с ICMP параметром [3].
         Опция временного штампа не копируется при фрагментации, а
      сохраняется в первом фрагменте. В датаграмме появляется не более
      одного раза.
Padding (Выравнивание)
      Выравнивание Internet заголовка используется для того, чтобы
      убедиться в том, Internet заголовок заканчивается на 32-битной
      границе. Варавнивание осуществляется нулями.

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

                                Адресация
   Чтобы обеспечить гибкость в присвоении адресов комптьютерным сетям и
позволить применение большого количества малых и средних сетей, поле
адреса кодируется таким образом, чтобы определять малое количество сетей
с большим количеством хостов, среднее количество сетей со средним
количеством хостов и большое количество сетей с малым количеством
хостов. Дополнительно имеется escape код для расширенного режима
адресации.
      Форматы адресации
   Старшие биты       Формат                             Класс
     0          7 бит в сети, 24 бита для хостов           А
     10         14 бит в сети, 16 бит для хостов           В
     110        21 бит для сети, 8 бит для хостов          С
     111        переход в расширенный режим адресации
   Нулевое значение в поле сети означает данную сеть. Этот режим
используется только в определенных ICMP сообщениях. Расширенный режим
адресации неопределен. Обе эти возможности зарезервированы для будущих
реализаций. Реальные значения, присваиваемые сетевым адресам, даны в
документе "Assigned Numbers" [9].
   Локальный адрес, присвоенный локальной сети, должен позволять
одиночному физическому хосту работать как несколько отдельных Internet
хостов. А именно, должен существовать промежуток между адресами Internet
хостов и должны присутствовать интерфейсы между сетью и хостом, которые
позволили бы нескольким Internet адресам соответствовать одному
интерфейсу. Хост должен иметь возможность для поддержки нескольких
физических интерфейсов и для обработки датаграмм с любого из них, как
если бы они были адресованы к единственному хосту.
   Карта соответствия между Internet адресами и адресами таких сетей,
как ARPANET, SATNET, PRNET и др. описаны в документе "Address Mapping"
[5].

                          Фрагментация и сборка
   Поле Internet идентификации (ID) используется вместе с
адресамиотправителя и получателя, полями протокола для идентификации
фрагментов датаграммы при сборке.
   Бит флага More Fragments (MF) устанавливается, если датаграмма не
является последним фрагментом. Поле Fragment Offset идентифицирует
расположение фрагмента относительно начала в первоначальной
нефрагментированной датаграмме. Единица измерения - 8 октетов. Стратегия
фрагментации разработана так, чтобы нефрагментированная датаграмма имела
нули во всех полях с информацией о фрагментации (MF=0, Fragment
Offset=0). Если же Internet датаграмма фрагментируется, то выделение
информации производится кусками и по границе 8 октет.
   Данный формат позволяет использовать 2**32=8192 фрагментов по 8
октетов каждый, а в целом 65536 октетов. Заметим, что это совпадает со
значением поля общей длины для датаграммы (конечно, заголовок
учитывается в общей длине датаграммы, но не фрагментов).
   Когда происходит фрагментация, то некоторые опции копируются, а
другие остаются лишь в первом фрагменте.
   Каждый Internet модуль должен быть способен передать датаграмму из 68
октетов без дальнейшей фрагментации. Это происходит потому, что Internet
заголовок может включать до 60 октетов, а минимальный фрагмент - 8
октетов. Каждый Internet - получатель должен быть в состоянии принять
датаграмму из 576 октетов в качестве единого куска, либо в виде
фрагментов, подлежащих сборке.
   Процесс фрагментации может повлиять на предыдущие поля
   (1) - поле опций
   (2) - флаг "more fragments"
   (3) - смещение фрагмента
   (4) - поле длины Internet заголовка
   (5) - поле общей длины
   (6) - контрольная сумма заголовка
   Если бит флага запрета фрагментации (Don't Fragment - DF) установлен,
то Internet фрагментация данной датаграммы запрещена, даже если она
может быть разрушена. Данное средство может использоваться для
предотвращения фрагментации в тех случаях, когда хост-получатель не
имеет достаточных ресурсов для сборки Internet фрагментов.
   Одним из примеров использования средства запрета фрагментации должна
служить линия, ведущая к малому хосту. Маленький хост может иметь
фмксированную загрузочную программу, которая принимает датаграмму,
помещает в памяти, а затем исполныет ее.
   Процедуры фрагментации и сборки наиболее просто описываются
примерами. Следующие процедуры являются учебными реализациями.
   В следующих псевдопрограммах принимается следующая нотация:
"=<" означает "меньше или равно", "#" означает "не равно", "=" означает
"равно", "<-" означает "устанавливается в". Кроме этого, "с x по y"
означает включительно по x, но не включая y. К примеру, выражение "с 4
по 7" означало бы включение 4,5 и 6, но не включало бы 7.

                      Пример процедуры фрагментации
    Датаграмма наибольшего размера, которая еще может быть передана
через очередную локальную сеть, называется наибольшей передаваемой
единицей (maximum transmission unit - MTU).
   Если общая длина датаграммы меньше или равна максимальной
передаваемой единице, то датаграмма передается следующим процедурам
обработки. В противном случае прежде она разбивается на два фрагмента,
причем первый из них будет иметь максимальный размер, соотвественно во
второй фрагмент будет помещен остаток исходной датаграммы. Первый
фрагмент отправляется на дальнейшую обработку, а второй повторно
подвергается только что рассмотренной процедуре, если и его размер
окажется слишком большим.
   Обозначения:
FO  - смещение фрагмента
IHL - длина Internet заголовка
DF  - флаг запрета фрагментации
MF  - флаг появления дополнительных фрагментов
TL  - общая длина
OFO - старое смещение фрагмента
OIHL- старая длина Internet заголовка
OMF - старое значение флага появление дополнительных фрагментов
OTL - старое значение общей длины
NFB - количество блоков фрагментации
MTU - максимальная длина переноса
Процедура
   IF TL =< MTU THEN отправить датаграмму на следующие процедуры
                     обработки
   ELSE
       IF DF =1 THEN разрушить датаграмму
       ELSE
           создать первый фрагмент
           (1) скопировать исходный Internet заголовок;
           (2) OIHL <- IHL; OTL <- TL; OMF <- MF;
           (3) NFB <- (MTU - IHL*4)/8;
           (4) взять первые NFB*8 октетов данных;
           (5) скорректировать заголовок:
               MF <- 1; TL <- (IHL*4)+(NFB*8);
               пересчитать контрольную сумму;
           (6) направить данный фрагмент на последующие
               процедуры обработки
           создать второй фрагмент:
           (7) выборочно скопировать Internet заголовок (некоторые
               опции не копируются, см. определение опций)
           (8) добавить оставшиеся данные
           (9) скорректировать заголовок
               IHL <- (((OIHL*4)-(длина нескопированных опций))+3)/4;
               TL <- OTL - NFB*8 - (OIHL-IHL)*4;
               FO <- OFO + NFB;  MF <- OMF;
               пересчитать контрольную сумму;
           (10) Приготовить этот фрагмент к повторному тесту на
                необходимость фрагментации. Выполнить.
   В предыдущей процедуре каждый фрагмент (за исключением последнего)
получает максимально разрешенную длину. Альтернатива может заключаться в
создании датаграмм, не достигающих максимального размера. Для примера,
она может включать процедуру фрагментации, которая повторно делит
большие датаграммы пополам до тех пор, пока получающиеся фрагменты не
станут короче, чем максимальный допустимый размер передаваемой единицы.

                         Пример процедуры сборки
   Для каждой датаграммы идентификатор буфера определяется как
объединение полей адреса отправителя, адреса получателя, протокола и
идентификации. Если это целая датаграмма (поля fragment offset и more
fragments нулевые), то все ресурсы, связанные с этим
идентификатором буфера, освобождаются, а сама датаграмма направляется на
следующие процедуры обработки.
   Если следующий фрагмент не связан с этим идентификатором буфера, то
выделяются ресурсы для сборки. Они включают буфер данных, буфер
заголовка, битовую таблицу фрагментации, поле общей длины данных, а
также таймер. Данные из фрагмента помещаются в буфер данных в
соответствии со значением полей fragment offset и длины, а также
устанавливаются биты в битовой таблице фрагментации согласно полученным
блокам фрагментов.
   Если это первый фрагмент (поле fragment offset нулевое), то его
заголовок помещается в буфер заголовка. Если это последний фрагмент
(поле more fragments нулевое), то вычисляется общая длина данных. Если
этот фрагмент завершает датаграмму (проверяется по установке битов в
таблице фрагментации), то датаграмма направляется на следующий этап
обработки. В противном случае таймер устанавливается на максимальное из
двух: текущее значение таймера и время жизни для данного фрагмента.
Выполнение процедуры сборки приостанавливается.
   Если таймер отсчитал положенное время, то все ресурсы сборки,
связанные с данным идентификатором буфера, освобождаются. Первоначальная
установка таймера является нижней границей для времени ожидания при
сборке. Это происходит потому, что всемя ожидания будет увеличено, если
время жизни приходящего фрагмента окажется больше, но не может быть
уменьшено. Установка таймера может достигать максимального времени жизни
(примерно 4.25 минуты). В настоящее время рекомендуется первоначально
устанавливать таймер на 15 секунд. Это значение можно изменить при
получении достаночного практического опыта. Заметим, что выбор значения
для этого параметра связи связан с емкостью буфера и скоростью получения
данных с коммуникационных сетей. Например, скорость получения данных
следует умножать на размер буфера (т.е. 10 кбайт/сек * 15 сек =
150 кбайт).
Обозначения
FO    - смещение фрагмента
IHL   - длина Internet заголовка
MF    - флаг More Fragments
TTL   - время жизни
NFB   - количество фрагментов
TL    - общая длина
TDL   - общая длина данных
BUFID - идентификатор буфера
RCVBT - битовая таблица фрагментации
TLB   - нижняя граница для значения таймера
Процедура
(1) BUFID <- отправитель|получатель|протокол|идентификация;
(2) IF FO = 0 AND MF = 0 THEN
(3)     IF буфер с идентификатором BUFID выделены THEN
(4)         завершить сборку для этого идентификатора BUFID;
(5)         Приготовить датаграмму для дальнейшей обработки.
            Запустить обработку
(6)     ELSE
            IF буфер для идентификатора BUFID не выделен THEN
(7)             выделить ресурсы для сборки с идентификатором BUFID
                TIMER <- TLB; TDL <- 0;
(8)         перенести данные из фрагмента в буфер данных с идентификатором
            BUFID, данные с октета FO*8 по октет (TL-(IHL*4))+FO*8;
(9)         установить биты RCVBT с FO по FO+((TL-(IHL*4)+7)/8);
(10)        IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11)        IF FO = 0 THEN поместить заголовок в буфер заголовка
(12)        IF TDL # 0 AND все биты RCVBT с 0 по (TDL+7)/8 выставлены THEN
(14)            TL <- TDL+(IHL*4)
(15)            Приготовить датаграмму к дальнейшей обработке
(16)            Освободить все ресурсы сборки для этого идентификатора
                BUFID. Запустить обработку.
(17)        TIMER <- MAX(TIMER,TTL);
(18)        приостановить работу до получения следующего фрагмента или
            сигнала от таймера
(19) Сигнал от таймера:
         Освободить все ресурсы, связанные с этим идентификатором BUFID.
   В случае, если два или более фрагмента содержат одни и те же данные,
либо идентичны или частично перекрываются, то эта процедура будет
использовать последнюю полученную копию при создании буфера данных и
воссоздании датаграммы.

                               Идентификация
   Выбор способа идентификации исходит из необходимости уникальной
идентификации фрагментов конкретной датаграммы. Модуль протокола,
собирающий фрагменты, считает, что они относятся к одной и той же
датаграмме, если они имеют общего отправителя, получателя, протокол и
идентификатор. Таким образом, отправитель должен выбрать идентификатор
таким образом, чтобы он был уникален для данной пары отправителя -
получателя, для данного протокола и в течении того времени, пока данная
датаграмма (или любой ее фрагмент) может существовать в сети Internet.
   Очевидно, что модуль протокола, отправляющий датаграммы, должен иметь
таблицу идентификаторов, где каждая запись соотносится с каждым отдельным
получателем, с которым осуществлялась связь, и указывает последнее
значение максимального времени жизни датаграммы в сети Internet.
   Однако, поскольку поле идентификатора позволяет использовать 65536
различных значений, некоторые хост-компьютеры могут использовать просто
уникальные идентификаторы независимо от адреса получателя.
   Обычно идентификаторы выбирают протоколы более высокого уровня,
например модули TCP протокола могут повторно передавать идентичные TCP
сегменты. Вероятность правильного приема увеличивалась бы, если повторная
передача осуществлялась с тем же самым идентификатором, что и исходная
датаграмма, поскольку ее фрагменты могли бы использоваться для сборки
правильного TCP сегмента.

                             Тип обслуживания
   Тип обслуживания (TOS) используется для выбора качества Internet
сервиса. Тип обслуживания определяется абстрактными параметрами
приоритета, задержки, продолжительности и достоверности. Эти параметры
должны отображаться на реальные параметры сервиса для конкретных сетей,
через которые проходит данная датаграмма.
Приоритет. Независимая единица измерения для важности данной датаграммы.
Задержка. Указание задержки важно для датаграмм с этим знаком.
Пропускная способность. Для датаграмм с этим знаком важна высокая скорость
   передачи данных.
Достоверность. Для датаграмм с таким типом обслуживания важен более
   высокий уровень усилий, предпринимаемых для обеспечения достоверности.
   Например, сеть ARPANET имеет бит приоритета, а также выбор между
"стандартными" сообщениями (тип 0) и "неконтролируемыми" (тип 3) (также в
качестве одного из сервисных параметров может использоваться выбор между
единичным пакетом и многопакетными сообщениями). Неконтролируемые
сообщения имеют тенденцию иметь меньшую достоверность, но и меньшую
задержку. Допустим, Internet датаграмма должна быть передана через сеть
ARPANET. Пусть тип Internet сервиса определен как
 приоритет:              5
 задержка:               0
 пропускная способность: 1
 достоверность:          1
   В рассматриваемом примере отображение описанных параметров на
параметры, допустимые в сети ARPANET, привело бы к установке бита
приоритета ARPANET (поскольку приоритет Internet находится в верхней
половине своего диапазона), выбору стандартного типа сообщений (поскольку
указаны требования высокой пропускной способности и достоверности, а
параметр задержки сброшен). Дополнительные детали реализации сервиса даны
в документе "Service Mappings" [8].

                                Время жизни
   Время жизни устанавливается отправителем в соответствии с максимальным
значением, которое данная датаграмма может иметь в системе Internet. Если
датаграмма пребывает в системе Internet дольше, чем указанное время жизни,
она подлежит уничтожению.
   Значение в поле, где указано время жизни, должно уменьшаться в каждой
точке, где обрабатывается Internet заголовок, с тем, чтобы показать время,
потраченное на обработку датаграммы. Даже если нет возможности получать
информацию о том, сколько реально времени было потрачено, значение этого
поля должно быть уменьшено на единицу. Время изменяется в секундах (т.е.
указанная единица соответствует одной секунде). Таким образом,
максимальное время жизни составляет 255 секунд или 4.25 минуты. Поскольку
каждый модуль, обрабатывающий датаграмму, должен уменьшать значение поля
TTL по крайней мере на единицу, даже если он обрабатывает ее быстрее, чем
за секунду, то поле TTL следует рассматривать лишь как верхнюю границу для
времени существования датаграммы. Цель процедуры заключается в разрушении
датаграмм, не достигших получателя, а также в ограничении времени жизни
датаграммы в сети.
   Некоторые протоколы более высокого уровня, управляющие соединениями,
основываются на предположении, что старые датаграммы-дубликаты не
достигают цели по истечении определенного времени. TTL - это способ, с
помощью которого такие протоколы могли бы убедиться, что их предположение
удовлетворяется.

                                   Опции
   Опции могут присутствовать в любой датаграмме, но должны всегда быть
обработаны. А именно, наличие или отсутствие какой-либо опции дело
отправителя, но каждый Internet модуль должен быть в состоянии произвести
разбор каждой опции.
   Опции могут оканчиваться не на 32-битной границе. В этом случае
Interntet заголовок может дополняться нулевыми октетами. Первый из них
должен интрепретироваться как заключительная опция, а остальные - как
октеты выравнивания Internet заголовка по границе.
   Каждый Internet модуль должен быть в состоянии реагировать на каждую
опцию. Например, опция безопасности требует классификации, внесения
ограничений, или передачи по изолированному пути.

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

                                  Ошибки
   Ошибки Internet заголовка могут быть оглашены посредством ICMP
сообщений [3].

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

                  Пример интерфейса с вышестоящим уровнем
   Два примера вызовов, приведенные ниже, удовлетворяют запросы
пользователя в общении с Internet протоколом (символ "=>" означает
возвращаемое значение).
SEND(src,dst,prot,TOS,TTL,BufPTR,len,Id,DF,opt => result)
где
  src    - адрес отправителя
  dst    - адрес получателя
  prot   - протокол
  TOS    - тип сервиса
  TTL    - время жизни
  BufPTR - указатель буфера
  len    - длина данных в буфере
  Id     - идентификатор
  DF     - запрет фрагментации
  opt    - опции
  result - ответ:
     Ok    - успешная посылка датаграммы
     Error - ошибка в аргументах функции или в локальной сети
   Заметим, что тип сервиса TOS включает приоритет, а требование
безопасности передается в качестве опции.
RECV(BufPTR,prot => result,src,dst,TOS,len,opt)
  BufPTR - указатель буфера
  prot   - протокол
  result - ответ:
      Ok    - успешное получение датаграммы
      Error - ошибка в аргументах
  len    - длина буфера
  src    - адрес отправителя
  dst    - адрес получателя
  TOS    - тип сервиса
  opt    - опции
   Когда пользователь отправляет датаграмму, он осуществляет SEND вызов,
сопровождаемый всеми аргументами. Модуль Internet протокола по получении
этого вызова проверяет аргументы, приготавливает и отправляет сообщение.
Если аргументы в порядке, а датаграмма принята локальной сетью, то вызов
завершается успешно. Если же агрументы неверны или датаграмма не принята
локальной сетью, то вызов завершается с ошибкой. В последнем случае должен
быть сделан соответствующий отчет о причине проблемы, однако детали таких
отчетов относятся уже к конкретным реализациям.
   В момент, когда датаграмма приходит на модуль Internet протокола из
локальной сети, может присутствовать ожидающий ее RECV вызов от
пользователя - адресата, а может и не присутствовать. В первом случае
ожидающий вызов удовлетворяется посылкой информации из датаграммы к
пользователю. Во втором случае пользователю - адресату посылается
напоминание о ждущей его датаграмме. Если пользователь - адресат не
присутствует, отправителю возвращается ICMP сообщение об ошибке, а
принятые данные разрушаются.
   Напоминание пользователю может быть выполнено через псевдопрерывание
или с помощью аналогичного механизма в соответствии с конкретной
операционной системой, поддерживающей данную реализацию.
   Сделанный пользователем запрос RECV может быть немедленно удовлетворен
ждущей этого датаграммой или же он может быть задержан до получения
соответствующей датаграммы.
   Адрес отправителя включается в запрос на посылку, если отправляющий
датаграмму хост-компьютер имеет несколько адресов (несколько физических
соединений или же чисто логических адресов). Internet модуль должен
следить за тем, чтобы адрес отправителоя был одним из разрешенных адресов
для данного хоста.
   Реализация протокола может допускать или даже требовать применения
запроса к Internet модулю для обозначения заинтересованности, или же,
наоборот, использование исключительно какого-либо класса датаграмм (т.е.
всех датаграмм, которые имеют в поле протокола определенное занчение).
   Данная глава характеризует функции интерфейса между пользователем и
Internet протоколом. Используемые обозначения аналогичны большинству
процедур функций вызовов на языках высокого уровня, однако данный способ
обращения с Internert протоколом не является правилом для запросов на
обслуживание типа ловушек (т.е. SVC, UUO, EMT), или для любой другой формы
общения между процессами.

                     Приложение А: Примеры и сценарии
Пример 1
   Пример минимальной Internet датаграммы, несущей данные
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service|          Total Length = 21    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|    Fragment Offset = 0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time =123   |  Protocol =1  |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     data      |
+-+-+-+-+-+-+-+-+
                    Рис. 5  Пример Internet датаграммы
   Напомним, что каждая метка означает место для одного бита. Здесь
приведена Internet датаграмма версии 4 Internet протокола. Internet
заголовок состоит из пяти 32 битных слов, а общая длина датаграммы
составляет 21 октет. Данная датаграмма является полноценной датаграммой
(а не фрагментом).

Пример 2
   В данном примере мы показываем сперва Internet датаграмму
промежуточного размера (452 октета данных), а затем два Internet
фрагмента, которые могли бы возникнуть при фрагментации исходной
датаграммы в случае, когда максимальная допустимая единица пересылки
составляла 280 октетов.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service|          Total Length = 472   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|    Fragment Offset = 0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time =123   |  Protocol =6  |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
\                                                               \
\                                                               \
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              data             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Рис. 6 Пример Internet датаграммы
   Теперь приведем первый фрагмент, который возникает при расщеплении
исходной датаграммы по границе после 256 октета данных.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service|          Total Length = 276   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=1|    Fragment Offset = 0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time =119   |  Protocol =6  |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
\                                                               \
\                                                               \
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Рис. 7 Пример Internet фрагмента
и второй фрагмент
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service|          Total Length = 216   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|   Fragment Offset = 32  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time =119   |  Protocol =6  |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
\                                                               \
\                                                               \
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              data             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Рис. 8 Пример Internet заголовка

Пример 3
   Здесь мы показываем пример, когда датаграмма имеет опции
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=8 |Type of Service|          Total Length = 576   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|   Fragment Offset = 32  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time =123   |  Protocol =6  |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. len. = 3 | option value  | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. len. = 4 |        option value           | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. len. = 3 | option value  | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              data                             |
\                                                               \
\                                                               \
|                              data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Рис. 9 Пример Internet датаграммы

                   Приложение Б: Порядок передачи данных
   Порядок передачи заголовка и данных, описанных в данном документе,
определяется на уровне октетов. В то время как диаграмма обозначает группу
октетов, порядок их передачи является таким же, как при чтении на
английском языке. Например, в нижеприведенной диаграмме октеты передаются
в порядке номеров.
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       1       |       2       |       3       |       4       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       5       |       6       |       7       |       8       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       9       |      10       |      11       |      12       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Рис. 10 Порядок передачи байтов
   Октет представляет собой число, для котрого самый левый бит на
диаграмме является самым старшим или самым значащим битом. Так бит,
отмеченный нулем, является наиболее значащим битом. Например, следующая
диаграмма представляет число 170 (десятичное)
                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |1 0 1 0 1 0 1 0|
                             +-+-+-+-+-+-+-+-+
                         Рис. 11 Старшинство битов
   Аналогично, если многооктетное поле представляет число, то самый левый
бит в этом поле является самым значащим битом. При передаче многооктетного
чила самый значащий октет передается первым.

                             Толковый словарь
1822 BBN доклад 1822, "The Specification of the Interconnection of a Host
     and an IMP". Спецификация взаимодействия между хост-компьютером и
     сетью ARPANET.
ARPANET проводник
     Управляющая информация в ARPANET сообщении для интерфейса между
     хост-компьютером и IMP процессором.
ARPANET сообщение
     Единица передачи между хост-компьютером и IMP процессором в сети
     ARPANET. Максимальный ее размер примерно 1012 октетов (8096 битов).
ARPANET пакет
     Единица передачи внутри сети ARPANET между IMP процессорами.
     Максимальный размер ее около 126 октетов (1008 бит).
Destination (Получатель)
     Адрес получателя, поле в Internet заголовке.
DF
     Бит запрета фрагментации в поле флагов.
Flags (Флаги)
     Поле Internet заголовка, содержащее различные управляющие биты.
Fragment Offset (Смещение фрагмента)
     Это поле Internet заголовка указывает, к какому месту в Internet
     датаграмме относится фрагмент.
GGP
     Gateway to Gateway Protocol - Протокол общения между шлюзами. Данный
     протокол первоначально использовался шлюзами для управления
     маршрутизацией и другими функциями шлюзов.
header (заголовок)
     Управляющая информация в начале сообщения, сегмента, датаграммы,
     пакета или блока данных.
ICMP
     Internet Control Message Protocol - Протокол контрольных сообщений
     Internet. Поддерживаемое Internet модулем, ICMP сообщение передается
     от шлюзов к хост-компьютерам и между хост-компьютерами, используется
     для отчетов об ошибках а также для создания предположений о
     маршрутизации.
Identification (Идентификация)
     Поле Internet заголовка, содержащее идентифицирующее значение,
     назначенное отправителем, и служащее для сборки фрагментов какой-либо
     датаграммы.
IHL
     The Internet Header Length - Поле Internet заголовка. Представляет
     собой длину Internet заголовка, измеренную в 32-битных словах.
IMP
     The Interface Message Processor - Процессор сообщений интерфейса.
     Пакетный переключатель сети ARPANET.
Internet Address (адрес Internet)
     Четырехоктетный (32 бита) адрес отправителя или получателя. Состоит
     из поля сети и поля локального адреса.
Internet фрагмент
     Порция данных из Internet датаграммы, снабженная Internet заголовком.
Local Address (локальный адрес)
     Адрес хост-компьютера внутри какой-либо сети. Реальное отображение
     локального адреса Internet на адреса хост-компьютеров в сети довольно
     произвольное, что позволяет отображать несколько локальных адресов на
     один хост-компьютер.
MF
     Флаг появления дополнительных фрагментов, содержащийся в поле флагов
     Internet заголовка
module (модуль)
     Реализация, обычно программная, протокола или других процедур
more-fragments flag (флаг дополнительных фрагментов)
     Флаг, показывающий, содержит ли данная Internet датаграмма
     заключительную часть исходной Internet датаграммы. Флаг включен в
     поле флагов Internet заголовка.
NFB
     The Number of Fragments Blocks - количество блоков фрагментации с
     данными в Internet фрагменте. Иными словами, длина поля с данными.
     Единица измерения - 8 октет.
octet (октет)
     байт с восемью битами
Options (опции)
     Поле опций Internet заголовка, может содержать несколько опций.
     Каждая опция может иметь длину в несколько октет.
Padding (Выравнивание)
     Поле выравнивания Internet заголовка, используемое для того, чтобы
     убедиться в том, что данные начинаются по границе 32-битного слова.
     Выравнивание осуществляется нулями.
Protocol (Протокол)
     Для данного документа это идентификатор протокола более высокого
     уровня, поле в Internet заголовке.
Rest (Остаток)
     Часть Internet адреса, указывающая локальный адрес.
Source (Отправитель)
     Адрес отправителя, поле Internet заголовка.
TCP
     Transmission Control Protocol - Протокол управления передачей.
     Протокол общения между хост-компьютерами для осуществления
     коммуникаций в среде Internet.
TCP сегмент
     Единица данных, передаваемая между TCP модулями (имеющая TCP
     заголовок).
TFTP
     Trivial File Transfer Protocol: Простой протокол передачи файлов,
     созданный для UDP.
Time to Live (Время жизни)
     Поле Internet заголовка, показывающее верхний предел для времени
     существования данной Internet датаграммы.
TOS
     Тип сервиса
Total length (общая длина)
     Поле Internet заголовка Total Length, определяющее длину датаграммы в
     октетах, включающее Internet заголовок и данные.
TTL
     Время жизни
Type of Service (Тип сервиса)
     Поле Internet заголовка, определяющее тип сервиса для данной Internet
     датаграммы.
UDP
     User Datagram Protocol. Протокол на уровне пользователя для
     приложений, ориентированных на транзакции.
User (Пользователь)
     Пользователь Internet протокола. Это может быть модуль протокола
     более высокого уровня, прикладная программа или программа шлюза.
Version (версия)
     Поле версии, определяющее формат Internet заголовка.

                                  Ссылки
[1] Cerf, V., "The Catenet Model for Internetworking," Офис технологий
    обработки информации, Оборонное Агентство расширенных
    исследовательских проектов, IEN 48, июль 1978.
[2] Bolt Beranek and Newman, "Specification for the Interconnection of a
    Host and an IMP," BBN Технический отчет 1822, пересмотрен в мае 1978.
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
    Program Protocol Specification," RFC 792, USC/Институт Информатики,
    сентябрь 1981.
[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON,
    компьютерное общество IEEE, конец 1978 года.
[5] Postel, J., "Address Mappings," RFC 796, USC/Институт Информатики,
    сентябрь 1981.
[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer
    Networks, v.3, n.1, январь 1979.
[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
    Newman, август 1979.
[8] Postel, J., "Service Mappings," RFC 795, USC/Институт Информатики,
    сентябрь 1981.
[9] Postel, J., "Assigned Numbers," RFC 790, USC/Институт Информатики,
    сентябрь 1981.
Содержание


Радик Усманов. RFC-792: Протокол ICMP

Протокол ICMP

Радик Усманов
radik@binep.ac.ru

Январь, 1995 г.

Реферат: Документ содержит русский перевод спецификации протокола ICMP (Internet Control Message Protocol) - протокола управляющих сообщений в стеке протоколов IP, применяемого в международной компьютерной сети Internet. Оригинальный документ известен, как RFC792.

Примечания редактора

Со временем в спецификацию протокола ICMP были введены еще два дополнительных типа сообщений: Address Mask Request (код 17) и Address Mask Reply (код 18). Данные типы сообщений описаны в документе RFC950 "Internet Standard Subnetting Procedure".

Оригинальная версия документа RFC792 размещается на сервере ISI (Information Sciences Institute http://www.isi.edu/):

 URL - http://info.internet.isi.edu/in-notes/rfc/files/rfc792.txt
Группа разработки сетей                                   J.Postel
Request for Comment                                      ISI
                                                     сентябрь 1981

              Протокол контрольных сообщений Internet
                     Программа DARPA Internet
                      Спецификация протокола

Введение
   Протокол Internet (IP) [1] используется для обработки датаграм-
мы, передаваемой между хост-компьютерами в системе объединенных
сетей, называемой Catenet [2]. Устройства, осуществляющие соедине-
ние различных сетей, называются шлюзами. Для обеспечения управле-
ния шлюзы общаются друг с другом посредством протокола Gateway to
Gateway Protocol (GGP) [3,4]. Порой шлюз или хост-компьютер, полу-
чающий данные, обменивается информацией с хост-компьютером, от-
правляющим эти данные. Именно для таких йелей используется данный
протокол - протокол контрольных сообщений Internet (ICMP). ICMP
использует основные свойства протокола Internet (IP), как если бы
ICMP являлся протоколом более высокого уровня. Однако фактически
ICMP является составной частью протокола Internet и должен являть-
ся составной частью каждого модуля IP.
   Сообщения ICMP должны отправляться в некоторых затруднительных
ситуациях. Например, когда датаграмма не может достичь своего
адресата, когда шлюз не имеет достаточно места в своем буфере для
передачи какой-либо датаграммы, или когда шдюз приказывает хост-
компьютеру отправлять информацию по более короткому маршруту.
   Протокол Internet не создан для того, чтобы обеспечивать абсо-
лютную надежность передачи информации. Целью же данных контрольных
сообщений является обеспечение обратной связи, оповещение отправи-
теля данных о проблемах, возникающих в комминикационном оборудова-
нии. Их целью не является придание надежности протоколу IP. Прото-
кол не дает гарантий, что датаграмма достигает своего адресата или
что контрольное сообщение будет возвращено компьтеру, отправившему
данные. Некоторые из датаграмм могут исчезнуть в сети, не вызвав
при этом ни каких оповещений. Протоколы более высокого уровня,
использующие протокол IP, должны применять свои собственные проце-
дуры для обеспечения надежности передачи данных, если таковая тре-
буется.
   Сообщения ICMP протокола, как правило, оповещают об ошибках,
возникающих при обработке датаграмм. Чтобы проблемы с передачей
сообщений не вызывали появление новых сообщений, чтобы это в свою
очередь не привело к лавинообразному росту количества сообщений,
циркулирующих в сети, констатируется, что нельзя посылать сообще-
ния о сообщениях. Также констатируется, что ICMP сообщения можно
посылать только о проблемах, возникающих при обработке нулевого
фрагмента в сегментированной датаграмме (нулевой фрагмент имеет
нуль в поле смещения фрагмента).

Форматы сообщений
   ICMP сообщения посылаются с помощью стандартного IP заголовка.
Первый октет в поле данных датаграммы - это поле типа ICMP сообще-
ния. Значение этого пля определяет формат всех остальных данных в
датаграмме. Любое поле, которое помечено "unused", зарегистрировано
для последующих разработок и должно при отправлении содержать нули.
Однако получатель не должен использовать значения этих полей (за
исключением процедуры вычисления контрольной суммы). Если обратное
особо не оговорено при описании отдельных фрагметов, Internet заго-
ловок должен иметь в своих полях следующие значения:
Версия
   4
IHL
   Длина Internet заголовка; единица измерения - 32-битное слово.
Тип сервиса
   0
Общая длина
   Длина Internet заголовка и поля данных в октетах.
Идентификация, флаги, смещение фрагмента
   Используются в случае фрагментации, см. [1].
Время жизни
   Время жизни в секундах. Поскольку значение этого поля уменьша-
   ется на единицу в каждой машине, на которой обрабатывается дан-
   ная датаграмма, то значение этого поля должно, по крайней мере,
   превышать количество шлюзов, через которые будет проходить дан-
   ная датаграмма.
Протокол
   ICMP=1
Контрольная сумма заголовка
   16-битное дополнение до единицы суммы дополнений до единицы
   всех 16-битных слов в заголовке. При вычислении данной суммы
   следует первоначально устанавливать значение этого поля в нуль.
   В дальнейшем этот алгоритм вычисления контрольной суммы должен
   быть изменен.
Адрес отправления
   Адрес шлюза или хост-компьютера, который составил данное ICMP
   сообщение. Если не оговорено обратное, в этом поле может нахо-
   диться любой из адресов шлюза.
Адрес получателя
   Адрес шлюза или хост-компьютера, которому следует послать
   данное сообщение.

   Сообщение о недостижимости порта
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      не используется                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля Internet протокола:
   Адрес получателя
      Локальная сеть и адрес компьютера, отправившего исходную
      датаграмму
Поля ICMP протокола
   Тип
      3
   Код
      0 - невозможно передать датаграмму на локальную сеть, где
          находится адресат
      1 - невозможно передать датаграмму на хост-компьютер,
          являющийся адресатом
      2 - нельзя воспользоваться указанным протоколом
      3 - нельзя передать данные на указанный порт
      4 - для передачи датаграммы по сети требуется фрагментация,
          однако выставлен флаг DF.
      5 - сбой в маршрутизации при отправлении
   Контрольная сумма
      Контрольная сумма является 16-битным дополнением до единицы
      суммы дополнений октетов в полях ICMP сообщения, начиная с
      поля типа ICMP. Для вычисления контрольной суммы первона-
      чально значение этого поля обнуляется. В будущем процедура
      вычисления контрольной суммы может быть изменена.
   Internet заголовок + 64 бита данных из исходной датаграммы
      Данное поле содержит Internet заголовок и первые 64 бита дан-
      ных из исходной датаграммы для выработки сообщения для соот-
      ветствующего процесса. Если протокол более высокого уровня
      использует номера портов, то предполагается, что эти номера
      находятся в первых 64 битах поля данных.
Описание
      Если, согласно информации в таблицах маршрутизации шлюза,
   локальная сеть, указанная в Internet заголовке датаграммы в поле
   адресата, является недостижимой, например, из-за ее чрезмерной
   удаленности, то шлюз может послать хост-компьютеру, отправившему
   датаграмму по Internet сети, сообщение о недостижимости адреса-
   та.
      Кроме этого, в некоторых сетях шлюз может иметь возможность
   определять доступность отдельного хост-компьютера. Шлюз в такой
   сети может послать данное сообщение, если хост-компьютер, являю-
   щийся адресатом, недоступен.
      Иная ситуация возникает, когда для достижения адресата дата-
   грамма должна быть разбита шлюзом на отдельные фрагменты, но
   установлен флаг запрета фрагментации. О этом случае шлюз обязан
   ликвидировать датаграмму и можен при этом послать сообщение о
   недостижимости адресата.
      Шлюз может послать сообщения с кодами 0, 1, 4 и 5. Хост-
   компьютер может послать сообщения с кодами 2 и 3.

   Сообщение о превышении контрольного времени
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      не используется                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Заимствованы сеть и адрес отправителя из мсходной датаграммы с
   данными.
Поля ICMP сообщения
   Тип
      11
   Код
      0 - при передаче превышено время жизни
      1 - превышено контрольное время при сборке фрагментов дата-
          граммы
   Контрольная сумма
      Контрольная сумма является 16-битным дополнением до единицы
      суммы дополнений в ICMP сообщении, начиная с поля типа ICMP.
      При вычислениии суммы следует сперва обнулить поле
      контрольной суммы. В будущем алгоритм контрольной суммы может
      быть изменен.
   Internet заголовок + 64 бита данных из исходной датаграммы
      Internet заголовок плюс первые 64 бита данных из исходной
      датаграммы. Эти биты данных используются хост-компьютером для
      привязки сообщения к соответствующему процессу. Если протокол
      более высокого уровня использует номера портов, то предпола-
      гается, что эти номера входят в первые 64 бита данных в ис-
      ходной датаграмме.
Описание
      Если фрагмент нулевого размера превысил контрольное время, то
   сообщение в этом не посылается вовсе.
      Шлюз может послать сообщение с кодом 0б а хост - с кодом 1.

   Сообщение о проблемах с параметром
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   указатель   |      не используется                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Заимствованы сеть и адрес отправителя из мсходной датаграммы с
   данными.
Поля ICMP сообщения
   Тип
      12
   Код
      0 - указатель показывает ошибку
   Контрольная сумма
      Контрольная сумма является 16-битным дополнением до единицы
      суммы дополнений в ICMP сообщении, начиная с поля типа ICMP.
      При вычислении суммы следует сперва обнулить поле контрольной
      суммы. В будущем алгоритм вычисления контрольной суммы может
      быть изменен.
   Указатель
      Если код = 0, то он указывает на октет, где была обнаружена
      ошибка.
   Internet заголовок + 64 бита данных из исходной датаграммы
      Эти биты данных используются хост-компьютером для привязки
      сообщения к соответствующему процессу. Если протокол более
      высокого уровня использует номера портов, то предполагается,
      что эти номера входят в вервые 64 бита данных в исходной да-
      таграмме.
Описание
      Если шлюз или хост-компьютер, обрабатывающий датаграмму,
   обнаруживает проблему с обработкой параметров заголовка, и это
   не позволяет завершить ее обработку, то он должен ликвидировать
   рассматриваемую датаграмму. Одной из потенциальных причин такой
   неприятности могут бить неправильные аргументы в опции. Шлюз или
   хост-компьютер в сообщении о проблеме с параметрами может также
   упомянуть хост-компьютер, породивший датаграмму с ошибкой. Сооб-
   щения такого типа посылаются лишь в том случае, если ошибка при-
   водит к ликвидации этой датаграммы.
      Указатель определяет октет в заголовке исходной датаграммы,
   где была обнаружена ошибка (этот ошибочный октет может находить-
   ся даже посередине опции). Например, 1 указывает на то, что име-
   ется какая-то ошибка в поле типа сервиса, а (если имеются опции)
   20 определяет, что имеется ошибка в коде типа для первой опции.
      Код 0 сообщения может приходить как от шлюза, так и от хост-
   компьютера.

   Сообщение для приостановки отправителя
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      не используется                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Заимствованы сеть и адрес отправителя из исходной датаграммы с
   данными.
Поля ICMP сообщения
   Тип
      4
   Код
      0
   Контрольная сумма
      Контрольная сумма является 16-битным допонением до единицы
      суммы дополнений в ICMP сообщении, начиная с поля типа ICMP.
      При вычислении контрольной суммы следует сперва обнулить поле
      контрольной суммы. В будущем алгоритм вычисления контрольной
      суммы может быть изменен.
   Internet заголовок + 64 бита данных из исходной датаграммы
      Internet заголовок плюс первые 64 бита данных из исходной
      датаграммы. Эти данные используются хост-компьютером для
      привязки сообщения к соответствующему процессу. Если протокол
      более высокого уровня использует номера портов, то предпола-
      гается, что эти номера входят в первые 64 бита данных ис-
      ходной датаграммы.
Описание
      Шлюз может ликвидировать Internet датаграммы, если у него нет
   места в буфере для постановки этих датаграмм в очередь на от-
   правление в очередную сеть по маршруту следования к адресату.
   Если шлюз ликвидирует датаграмму, то он должен послать сообщение
   для приостановки хост-компьютеру в Internet системе, отправивше-
   му данную датаграмму. Сообщение о приостановке может послать
   также сам адресат, если датаграммы приходят слишком быстро, что-
   бы успеть их обработать. Сообщение о приостановке является за-
   просом для хост-компьютера уменьшить скорость посылки данных на
   этот конкретный адрес. Шлюз может посылать сообщение для при-
   остановки отправителя в каждом случае ликвидации. При получении
   такого сообщения хост-компьютер, отправивший данные, должен
   уменьшить скорость посылки данных по этому адресу до тех пор,
   пока не перестанут приходить запросы на приостановку с данного
   шлюза. После этого хост-компьютер, отправляющий данные, может
   постепенно увеличивать скорость посылки данных по этому адресу,
   пока вновь не станут приходить сообщения о приостановке.
      Шлюз или хост-компьютер может посылать сообщение о приоста-
   новке еще до достижения предельной пропускной способности, и не
   ждать, пока этот предел будет пройден. Это означает, что дата-
   грамма с данными, вызвавшая появление сообщения о приостановке,
   все же может достичь своего адресата.
      И шлюз и хост-компьютер могут отправить сообщение с кодом 0.

   Сообщение о переадресации
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Internet адрес шлюза                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Заимствованы сеть и адрес отправителя из исходной датаграммы с
   данными.
Поля ICMP сообщения
   Тип
      5
   Код
      0 - переадресация датаграмм для сети
      1 - переадресация датаграмм для хост-компьютера
      2 - переадресация датаграмм для типа услуг и сети
      3 - переадресация датаграмм для типа услуг и хост-компьютера
   Контрольная сумма
      Контрольная сумма - это 16-битное допонение до единицы суммы
      дополнений в ICMP сообщении, начиная с поля типа ICMP. При
      вычислении контрольной суммы следует сперва обнулить поле
      контрольной суммы. В будущем алгоритм вычисления контрольной
      суммы может быть изменен.
   Internet адрес шлюза
      Адрес шлюза, на который должен быть проложен маршрут к сети,
      указанной в поле адреса в исходной датаграмме с данными.
   Internet заголовок + 64 бита данных из исходной датаграммы
      Internet заголовок плюс первые 64 бита данных из исходной
      датаграммы. Эти данные используются хост-компьютером для при-
      вязки сообщения к соответствующему процессу. Если протокол
      более высокого уровня использует номера портов, то предпола-
      гается, что эти номера входят в первые 64 бита данных исход-
      ной датаграммы.
Описание
      Шлюз посылает сообщение на хост-компьютер о переадресации в
   следующей ситуации: Шлюз G1 получает Internet датаграмму от
   хост-компьютера в сети, где он расположен. Шлюз G1 проверяет
   таблицу маршрутизации и находит адрес слеудющего шлюза G2 в ка-
   честве маршрута для датаграммы по пути в сеть X, где расположен
   ее адресат. Если G2 и исходный хост-компьютер идентифицируются
   Internet адресом как находящиеся в одной и той же сети, то на
   хост-компьютер следует послать сообщение о переадресации. Сооб-
   щение о переадресации заставляет хост-компьютер посылать дата-
   граммы для сети X прямо на шлюз G2, поскольку это более короткий
   путь, нежели привлекать еще шлюз G1. Шлюз передает данные исход-
   ной датаграммы их адресату в системе Internet.
      Для датаграмм с опциями IP маршрутизации отправления и адре-
   сом шлюза в поле получателя сообщение не посылается, даже если и
   существует более оптимальный маршрут к конечному адресату, чем
   следующий адрес, указанный в такой опции маршрута.
      Шлюзом могут быть переданы сообщения с кодами 0, 1, 2 и 3.

   Эхо-сообщение и сообщение в ответ на эхо
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Идентификатор       |     Номер очереди             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Данные .....
+-+-+-+-+-+-+-

Поля IP заголовка
   Адреса
      Адрес отправителя в эхо-сообщении будет адресом получателя в
      ответном сообщении. Чтобы сформировать сообщение ответа, сле-
      дует просто переставить местами адреса отправителя и получа-
      теля, код типа изменить на 0 и пересчитать контрольную сумму.
Поля ICMP сообщения
   Тип
      8 - эхо-сообщение
      0 - сообщение в ответ на эхо
   Код
      0
   Контрольная сумма
      Контрольная сумма - это 16-битное допонение до единицы суммы
      дополнений для ICMP сообщения, начиная с поля типа ICMP. При
      вычислении контрольной суммы это поле должно быть сперва об-
      нулено. Если общая длина сообщения нечетная, то для вычисле-
      ния контрольной суммы поле данных дополняется еще одним нуле-
      вым октетом. В будущем алгоритм вычисления контрольной суммы
      может быть изменен.
   Идентификатор
      Если код = 0, то идентификатор для соотнесения эхо-сообщений
      и ответов на них, должен быть обнулен.
   Номер очереди
      Если код = 0, то номер очереди, служащий для соотнесения
      эхо-сообщений и ответов на них, должен быть обнулен.
Описание
      Данные из эхо-сообщения должны быть переданы в ответе на это
   сообщение.
      Идентификатор и номер очереди может использоваться отправите-
   лем эхо-сообщения с целью идентификации приходящих пакетов. На-
   пример, идентификатор может использоваться в качестве порта по-
   добно протоколам TCP и UDP для идентификации сеанса. Номер оче-
   реди может увеличиваться на единицу припосылке каждого эхо-
   сообщения (запроса). Компьютер, отозвавшийся на это сообщение,
   возвращает в своем ответе те же значения для идентификатора и
   номера очереди, что были в исходном эхо-сообщении.
      Как шлюз, так и хост-компьютер могут возвращать сообщение с
   кодом 0.

   Сообщение со штампом времени и сообщение с ответом на штамп
   времени
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Идентификатор       |     Номер очереди             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Штамп времени отправления                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Штамп времени получения                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Штамп времени передачи                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Адреса
      Адрес отправителя в сообщении со штампом времени будет адре-
      сом получателя в сообщении с ответом. Чтобы сформировать от-
      вет на сообщение, следует просто поменять местами адреса от-
      правителя и получателя, выбрать код типа 14, а также пересчи-
      тать контрольную сумму.
Поля ICMP сообщения
   Тип
      13 для сообщения со штампом времени
      14 для ответа на сообщение со штампом времени
   Код
      0
   Контрольная сумма
      Контрольная сумма - это 16-битное допонение до единицы суммы
      дополнений для ICMP сообщения, начиная с поля типа ICMP. При
      вычислении контрольной суммы это поле должно быть сперва об-
      нулено. В будущем алгоритм вычисления контрольной суммы
      может быть изменен.
   Идентификатор
      Если код = 0, то идентификатор, служащий для соотнесения
      сообщений со штампом времени и ответов на них, должен быть
      обнулен.
   Номер очереди
      Если код = 0, то номер очереди, служащий для соотнесения
      сообщений со штампом времени и ответов на них, должен быть
      обнулен.
Описание
      Данные из сообщения (штамп времени) возвращаются вместе с
   ответом, при этом в них добавляется еще один штамп времени.
   Штамп времени - это 32 бита, где записано время в миллисекундах,
   прошедшее после полуночи по единому времени (UT). Один из приме-
   ров использования таких временных штампов приведен в документе
   [5].
      Штамп времени отправления - это время, которое отправитель
   фиксировал последний раз перед посылкой сообщения. Штамп времени
   получения - это время, когда исходное сообщение впервые увидел
   получатель первоначального сообщения. Штамп времени передачи -
   это время, которое фиксировал в последний раз компьютер, отправ-
   ляющий ответное сообщение.
      Если нет возможности измерять время в миллисекундах или нель-
   зя определить единое время (UT), то в штамп все же можно занести
   имющееся время, снабдив его единицей в старшем бите. Последнее
   также указывает на запись нестандартного значения в этом поле.
      Идентификатор и номер очереди могут использоваться отправите-
   лем для соотнесения сообщений (запросов) и ответов на них. На-
   пример, идентификатор может использоваться в качестве порта,
   аналогично протоколам TCP и UDP, для идентификации сессии. Номер
   очереди может увеличиваться на единицу при каждой посылке сооб-
   щения (запроса). Адресат возвращает для этих параметров те зна-
   чения, которые были обнаружены в запросе.
      И шлюз и хост-компьютер могут возвращать сообщения с кодом 0.

   Запрос информации и ответное сообщение с информацией
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |      Код      |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Идентификатор       |     Номер очереди             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP заголовка
   Адреса
      Адрес отправителя в сообщении с запросом информации окажется
      адресом получателя в ответном сообщении с информацией. Чтобы
      сформировать ответное сообщение, следует просто поменять мес-
      тами адреса отправителя и получателя, код типа сменить на 16,
      пересчитать контрольную сумму.
Поля ICMP сообщения
   Тип
      15 - сообщение с запросом информации
      16 - ответное сообщение с информацией
   Код
      0
   Контрольная сумма
      Контрольная сумма - это 16-битное допонение до единицы суммы
      дополнений для ICMP сообщения, начиная с поля типа ICMP. При
      вычислении контрольной суммы следует предварительно обнулить
      поле самой контрольной суммы. В будущем алгоритм вычисления
      контрольной суммы может быть изменен.
   Идентификатор
      Если код = 0, то идентификатор, служащий для соотнесения за-
      просов и ответов, может быть обнулен.
   Номер очереди
      Если код = 0, то номер очереди, служащий для соотнесения за-
      просов и ответов, может быть обнулен.
Описание
      Данное сообщение может быть послано, когда в IP заголовке в
   полях отправителя и получателя записаны нули (это означает
   "именно эту" локальную сеть). В ответ должен быть послан IP мо-
   дуль с полностью заданными адресами. Данное сообщение является
   способом, с помощью которого хост-компьютер сможет определить
   номер сети, куда он подключен.
      Отправитель сообщений может использовать идентификатор и но-
   мер очереди для соотнесения запросов и пришедших ответов. Напри-
   мер, идентификатор может использоваться как порт в протоколах
   TCP и UDP для идентификации сеанса. Номер очереди может увеличи-
   ваться на единицу всякий раз, когда посылается запрос. Адресат
   возвращает в ответе те же значения этих параметров, которые были
   обнаружены в запросе.
      И хост-компьютер и шлюз могут возвращать сообщения с кодом 0.

                        Список типов сообщений
   0    ответ на запрос эхо
   3    адресат недостижим
   4    приостановка отправителя
   5    переадресация
   8    эхо-запрос
   11   превышение контрольного времени
   12   проблемы с параметрами
   13   штамп времени
   14   ответ на запрос штампа времени
   15   запрос информации
   16   ответ на запрос информации

                               Ссылки
[1]  Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
     Protocol Specification," RFC 791, USC/Information Sciences
     Institute, September 1981.
[2]  Cerf, V., "The Catenet Model for Internetworking," IEN 48,
     Information Processing Techniques Office, Defense Advanced
     Research Project Agency, July 1978.
[3]  Strazisar, V., "Gateway Routing: An Implementation
     Specification", IEN 30, Bolt Beranek and Newman, April 1979.
[4]  Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek
     and Newman, August 1979.
[5]  Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT
     Laboratories, April 1981.
Содержание


Протокол TCP

Радик Усманов
radik@binep.ac.ru

Ноябрь, 1994 г.

Реферат: Документ содержит русский перевод спецификации протокола TCP (Transmission Control Protocol) - основного транспортного протокола стека IP, применяемого в международной компьютерной сети Internet. Оригинальный документ известен, как RFC793.

Примечания редактора

Оригинальная версия документа RFC793 размещается на сервере ISI (Information Sciences Institute "http://www.isi.edu/"):

 URL - http://info.internet.isi.edu/in-notes/rfc/files/rfc793.txt

                    Протокол управления передачей
                   (Transmission Control Protocol)
                        Проект DARPA Internet
                        Спецификация протокола

                            сентябрь 1981

                           подготовлено для
         Агенства оборонных проектов расширенных исследований
                 Офис технологий обработки информации
                        1400 Wilson Boulevard
                      Arlington, Virginia 22209

                        Институтом Информатики
                    Университетом Южной Калифорнии
                          4676 Admiralty Way
                   Marina del Rey, California 90291

                              Содержание
Предисловие
1. Введение
  1.1 Мотивация
  1.2 Цель
  1.3 О данном документе
  1.4 Интерфейсы
  1.5 Действие
2. Идеология протокола
  2.1 Элементы системы объединенных сетей
  2.2 Модель действия
  2.3 Программное обеспечение хост-компьютера
  2.4 Интерфейсы
  2.5 Связь с другими протоколами
  2.6 Надежные коммуникации
  2.7 Установка соединения и его отмена
  2.8 Коммутация данных
  2.9 Приоритет и безопасность
  2.10 Принцип устойчивости
3. Спецификация для функций протокола
  3.1 Формат заголовка
  3.2 Терминология
  3.3 Номера последовательности
  3.4 Установка соединения
  3.5 Закрытие соединения
  3.6 Приоритет и безопасность
  3.7 Коммутация данных
  3.8 Интерфейсы
  3.9 Обработка событий
Словарь
Ссылки

                             Предисловие
Данный документ описывает Протокол управления передачей данных в DoD стан-
дарте (TCP). Данный стандарт основывается на девяти предыдущих изда-
ниях ARPA спецификации TCP, данный текст сильно отличается от них. В
него внесены большие изменения как в отношении концепций, так и в от-
ношении текста. Данное издание проясняет некоторые детали протокола и
не включает выравнивания по размеру буфера в конце письма, а также
переопределяет механизм писем как push функцию.
                                             Джон Постел (Jon Postel)
                                                      Редактор
RFC: 793
заменяет RFC 761 и IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5

                    Протокол управления передачей
                       Протокол DARPA Internet
                        Спецификация протокола

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

                            1.1 Мотивация
Компьютерные коммуникационные системы играют все более важную роль в
военных, правительственных и гражданских приложениях. Этот документ в
первую очередь освещает требования к компьютерным коммуникациям в во-
енной области, и особенно к устойчивости в условиях недостаточной на-
дежности коммуникаций и возможности перегрузок. Тем не менее, многие
из этих проблем имеют место также в гражданском и правительственном
секторе.
В условиях, когда стратегические и тактические сети компьютерных ком-
муникаций возникают и исчезают, важно обеспечить средства для их со-
единения, а также стандартные протоколы коммуникации между процесса-
ми, которые бы поддерживали большой диапазон прикладных программ.
Предвидя потребность в таких стандартах, Представительство Секретари-
ата Обороны по научно-исследовательским и опытно- конструкторским ра-
ботам предъявило протокол управления передачей (Transmission Control
Protocol - TCP), описанный здесь, на основе стандартизации DoD прото-
кола коммуникаций между процессами.
TCP - это протокол обеспечения надежности прямых соединений, создан-
ный для многоуровневой иерархии протоколов, поддерживающих межсетевые
приложения. Протокол TCP обеспечивает надежность коммуникаций между
парами процессов на хост-компьютерах, включенных в различные ком-
пьютерные коммуникационные сети, которые объединены в единую систему.
В отношении надежности протоколов более низкого, чем TCP, уровня
сделаны весьма скромные запросы. TCP предполагает, что он может
получить простой, потенциально ненадежный сервис для своих датаграмм
со стороны протоколов нижнего уровня. В принципе, протокол TCP должен
быть работоспособен на большом наборе коммуникационных систем,
начиная с кабельных соединений и кончая сетями с переключением
пакетов или электрических цепей.
Протокол TCP основывается на концепциях, впервые описанных авторами
Cerf и Kahn в документе [1]. TCP занимает в многоуровневой архитек-
туре протоколов нишу непосредственно над протоколом Internet, который
позволяет протоколу TCP отправлять и получать сегменты информации пе-
ременной длины, заключенные в оболочку Internet датаграмм. Internet
датаграмма предоставляет средства для адресации отправителя и получа-
теля сегментов TCP в различных сетях. Протокол Internet также осу-
ществляет любую фрагментацию и сборку сегментов TCP, необходимую для
осуществления передачи и доставки через множество сетей и промежуточ-
ных шлюзов. Протокол Internet также обработывает информацию о приори-
тете, классификации безопасности, а также осуществляет разграничение
TCP сегментов. Так что данная информация может быть передана напрямую
через множество сетей.
                          Уровни протоколов
                       +----------------------+
                       |   верхний уровень    |
                       +----------------------+
                       |         TCP          |
                       +----------------------+
                       |  протокол Internet   |
                       +----------------------+
                       |коммуникационная сеть |
                       +----------------------+
                                Рис. 1
Большая часть этого документа написана всвязи с реализациями TCP про-
токола, которые вместе с протоколами более высокого уровня присут-
ствуют на хост-компьютере. Некоторые компьютерные системы будут вклю-
чаться в сети через главные компьютеры, содержащие протоколы уровней
TCP и Internet, а также специфическое сетевое программое обеспечение.
Спецификация TCP описывает ее интерфейс с протоколами более высокого
уровня, которые оказались осуществимы даже в случае главного компью-
тера, если реализован соответствующий протокол общения между хост-
компьютером и главным компьютером.

                               1.2 Цель
Протокол TCP обязан обеспечить надежный сервис для коммуникаций между
процессами в многосетевой системе. Протокол TCP должен быть общим
протоколом для коммуникаций между хост-компьютерами во множестве се-
тей.

                        1.3 О данном документе
Данный документ предоставляет описание поведения, ожидаемого от любой
реализации протокола TCP, а также его взаимодействия как с протокола-
ми более высокого уровня, так и с протоколами TCP на других компьюте-
рах. Оставшаяся часть данной главы дает очень краткий обзор действия
протокола и его интерфейсов. Глава 2 суммирует идейный базис для соз-
дания протокола TCP. Глава 3 дает как детальное описание поведения,
требуемого от протокола TCP при появлении различных событий (прибытие
новых сегментов, запрос от пользователя, ошибки и т.д.), так и описа-
ние деталей форматов TCP сегментов.

                            1.4 Интерфейсы
Протокол TCP взаимодействует с одной стороны с пользователем или при-
кладной программой, а с другой - с протоколом более низкого уровня,
таким как протокол Internet.
Интерфейс между прикладным процессом и протоколом TCP мы поясняем с
приемлемой детализацией. Этот интерфейс состоит из набора вызовов,
которые похожи на вызовы операционной системы, предоставляемые при-
кладному процессу для управления файлами. Например, в этом случае
имеются вызовы для открытия и закрытия соединений, для отправки и по-
лучения данных на установленных соединениях. Предполагается также,
что протокол TCP сможет асинхронно взаимодействовать с прикладными
программами. Хотя разработчикам TCP протокола и предоставлена значи-
тельная свобода в создании интерфейсов, которые соответствуют свой-
ствам конкретной операционной системы, все же от любой приемлемой ре-
ализации требуются некие обязательные минимальные функции интерфейса
между протоколом TCP и пользователем.
Интерфейс между протоколом TCP и протоколами более низкого уровня за-
дан в значительно меньшей степени, за исключением того, что должен
существовать некий механизм, с помощью которого эти два уровня могут
асинхронно обмениваться информацией друг с другом. Обычно полагают,
что протокол нижнего уровня задает данный интерфейс. Протокол TCP
спроектирован так, чтобы работать с весьма разнообразной средой объ-
единенных компьютерных сетей. В данном документе предполагается, что
протокол более низкого уровня - это Internet [2].

                             1.5 Действие
Как указывалось ранее, главной целью протокола TCP является обеспече-
ние надежного, безопасного сервиса для логических цепей или соедине-
ний между парами процессов. Чтобы обеспечить такой сервис, основыва-
ясь на менее надежных коммуникациях Internet, система должна иметь
возможности для работы в следующих областях:
- базовая передача данных
- достоверность
- управление потоком
- разделение каналов
- работа с соединениями
- приоритет и безопасность
   Основные действия протокола TCP в каждой из этих областей описаны
   в следующих параграфах.
Базовая передача данных
      Протокол TCP способен передавать непрерывные потоки октетов
   между своими клиентами в обоих направлениях, пакуя некое количес-
   тво октетов в сегменты для передачи через системы Internet. В об-
   щем случае протоколы TCP решают по своему усмотрению, когда произ-
   водить блокировку и передачу данных.
      Иногда пользователям бывает необходимо убедиться в том, что все
   данные, переданные ими протоколу TCP, уже отправлены. Для этой це-
   ли определена функция проталкивания (push). Чтобы убедиться в том,
   что данные, отправленные протоколу TCP, действительно переданы,
   отправитель указывает, что их следует протолкнуть к получателю.
   Проталкивание приводит к тому, что программы протокола TCP сразу
   осуществляют отправление и, соответственно, получение остающихся
   данных. Правильно осуществленное проталкивание может быть невидимо
   для получателя, а сама функция проталкивания может не иметь
   маркера границы записи.
Достоверность
      Протокол TCP должен иметь защиту от разрушения данных, потери,
   дублирования и нарушения очередности получения, вызываемых
   коммуникационной системой Internet. Это достигается присвоением
   очередного номера каждому передаваемому октету, а также
   требованием подтверждения (ACK) от программы TCP, принимающей
   данные. Если подтверждения не получено в течении контрольного
   интервала времени, то данные посылаются повторно. Со стороны
   получателя номера очереди используются для восстановления
   очередности сегментов, которые могут быть получены в неправильном
   порядке, а также для ограничения возможности появления дубликатов.
   Повреждения фиксируются посредством добавления к каждому
   передаваемому сегменту контрольной суммы, проверки ее при
   получении и последующей ликвидации дефектных сегментов.
      До тех пор, пока программы протокола TCP продолжают функциони-
   ровать корректно, а система Internet не развалилась полностью на
   составные части, ошибки пересылки не будут влиять на правильное
   получение данных. Протокол TCP защищает от ошибок коммуникационной
   системы Internet.
Управление потоком
      Протокол TCP дает средства получателю управлять количеством
   данных, посылаемых ему отправителем. Это достигается возвратом так
   называемого "окна" (window) вместе с каждым подтверждением, кото-
   рое указывает диапазон приемлемых номеров, следующих за номером
   последнего успешно принятого сегмента. Окно определяет количество
   октетов, которое отправитель может послать до получения дальнейших
   указаний.
Разделение каналов
      Чтобы позволить на отдельно взятом компьютере многим процессам
   одновременно использовать коммуникационные возможности уровня TCP,
   протокол TCP предоставляет на каждом хост-компьютере набор адресов
   или портов. Вместе с адресами сетей и хост-компьютеров на коммни-
   кационном уровне Internet они образуют сокет (socket - разъем).
   Каждое соединение уникальным образом идентифицируется парой соке-
   тов. Таким образом, любой сокет может одновременно использоваться
   во многих соединениях.
      Соотнесение портов и процесов осуществляется каждым хост-
   компьютером самостоятельно. Однако оказывается полезным связывать
   часто используемые процессы (такие как "logger" или сервис с раз-
   делением времени) с фиксированными документированными сокетами.
   Этот сервис можно впоследствии использовать через известные адре-
   са. Установка и настройка адресов портов для других процессов мо-
   жет включать более динамичные механизмы.
Работа с соединениями
      Механизмы управления потоком и обеспечения достоверности, опи-
   санные выше, требуют, чтобы программы протокола TCP инициализиро-
   вали и поддерживали определенную информацию о состоянии каждого
   потока данных. Набор такой информации, включающий сокеты, номера
   очереди, размеры окон, называется соединением. Каждое соединение
   уникальным образом идентифицируется парой сокетов на двух концах.
      Если два процесса желают обмениваться информацией, соответству-
   ющие программы протокола TCP должны сперва установить соединение
   (на каждой стороне инициализировать информаицию о статусе). По за-
   вершении обмена информацией соединение должно быть расторгнуто или
   закрыто, чтобы освободить ресурсы для предоставления другим поль-
   зователям.
      Поскольку соединения должны устанавливаться между ненадежными
   хост-компьютерами и через ненадежную коммуникационную систему
   Internet, то во избежание ошибочной инициализации соединений ис-
   пользуется механизм подтверждения связи с хронометрированными но-
   мерами очереди.
Приоритет и безопасность
      Пользователи протокола TCP могут затребовать для своего соеди-
   нения приоритет и безопасность. Предусмотрены принимаемые по умол-
   чанию характеристики соединений, когда такие параметры не требуют-
   ся.

                        2. Идеология протокола

                2.1 Элементы системы обединенных сетей
   Среда объединенных сетей состоит из хост-компьютеров, включенных в
сети, которые в свою очередь соединятся друг с другом через шлюзы.
Здесь предполагается, что компьютерные сети могут быть либо локальны-
ми (например, ETHERNET), либо большими сетями (например ARPANET), но
в любом случае они основываются на технологии коммутации пакетов. Ре-
альными агентами, создающими и потребляющими сообщения, циркулирующие
в сети, являются процессы. Протоколы различных уровней в сетях, на
шлюзах и на хост-компьютерах поддерживают систему коммуникаций между
процессами, которая обеспечивает двунаправленный поток данных по ло-
гическим соединениям между портами процессов.
   Термин пакет используется здесь в общем случае для обозначения
порции данных, участвующей в отдельном элементарном акте взаимодей-
ствия между сетью и соединенным с ней хост-компьютером. В общем слу-
чае нас не будет касаться формат блоков данных, циркулирующих в сети.
   С точки зрения коммуникационных сетей, хост-компьютеры - это ком-
пьютеры, связанные с сетью и являющиеся отправителями и получателями
пакетов. Процессы рассматриваются как активные элементы на хост-
компьютерах (согласно наболее общему определению процессов как испол-
няющихся программ). Предполагается, что даже терминалы, файлы и дру-
гие устройства ввода-вывода взаимодействуют друг с другом посредством
процессов. Таким образом, любые коммуникации рассматриваются как ком-
муникации между процессами.
   Поскольку процесс может контролировать несколько коммуникационных
потоков, ведущих от него к другому процессу (или другим процессам),
то мы постулируем, что каждый процесс может иметь набор портов, через
которые он общается с портами других процессов.

                         2.2 Модель действия
   Процесс пересылает данные, вызывая программу протокола TCP и пере-
давая ей в качестве аргументов буферы с данными. Протокол TCP пакует
данные из этих буферов в сегменты, а затем вызывает модуль Internet
для передачи каждого сегмента на программу протокола TCP, являющуюся
адресатом. Этот адресат в свою очередь помещает данные из сегмента в
буферы получателя и затем оповещает свего клиента о прибытии предназ-
наченных ему данных. Программы протокола TCP помещают в сегменты кон-
трольную информацию, которая затем используется ими для проверки оче-
редности передачи данных.
   Модель Internet коммуникаций состоит в том, что с каждой програм-
мой протокола TCP связан модуль протокола Internet, обеспечивающий ей
интерфейс с локальной сетью. Данный модуль Internet помещает сегменты
TCP в Internet датаграммы, а затем направляет их на другой Internet
модуль или же промежуточный шлюз. Для передачи датаграммы по локаль-
ной сети она в свою очередь помещается в пакет соответствующего типа.
   Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фраг-
ментацию или другие операции с тем, чтобы в локальной сети осущест-
вить передачу пакетов по назначению на модуль Internet.
   На шлюзах между локальными сетями датаграмма Internet освобождает-
ся от пакета локальной сети и исследуется с тем, чтобы определить, по
какой сети она должна в дальнейшем идти. Затем Internet датаграмма
упаковывается в пакет, соответствующий выбранной локальной сети, и
посылается на следующий шлюз или же прямо к конечному получателю.
   Шлюз имеет возможность разбивать Internet датаграмму на более мел-
кие датаграммы-фрагменты, если это необходимо для передачи по очеред-
ной локальной сети. Чтобы осуществить это, шлюз сам создает набор
Internet датаграмм, помещая в каждую по одному фрагменты. В дальней-
шем фрагменты могут быть снова разбиты следующими шлюзами на еще бо-
лее мелкие части. Формат фрагмента Internet датаграммы спроектирован
так, чтобы адресат - модуль Internet смог собрать фрагменты снова в
исходные Internet датаграммы.
   Internet модуль, являющийся адресатом, выделяет сегмент из дата-
граммы (после ее сборки в случае необходимости) и затем передает его
по назначению на программу протокола TCP.
   Данная простая модель действия протокола зачастую замалчивает мно-
жество деталей. Одной из важных характеристик является тип сервиса.
Этот признак дает указание шлюзу (или модулю Internet) о выборе пара-
метров сервиса, которые должны использоваться при передаче датаграммы
в очередной локальной сети. Приоритет датаграммы указывается среди
информации о типе сервиса. Датаграммы также могут нести информацию о
безопасности с тем, чтобы позволить хост-компьютерам и шлюзам, дей-
ствующим в многоуровневой системе безопасности, подвергать проверке
соотвествующие датаграммы.

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

                            2.4 Интерфейсы
   Для запросов со стороны пользователя к протоколу TCP интерфейс
TCP/пользователь обеспечивает открытие и закрытие соединения, посылку
и получение данных или же получение статуса соединения. Эти запросы
похожи на другие запросы программы пользователя к операционной систе-
ме, например, на запросы открытия, чтения и закрытия файла.
   Интерфейс между протоколами TCP и Internet поддерживает запросы на
посылку и получение датаграмм, адресованных на модули TCP в хост-
компьютерах в любом месте сети Internet. Рассматриваемые запросы име-
ют аргументы для указания адреса, типа сервиса, приоритета, безопас-
ности, а также передачи другой правляющей информации.

                   2.5 Связь с другими протоколами
   Нижеприведенная диаграмма иллюстрирует место протокола TCP в
иерархии протоколов
+------+ +-----+ +-----+        +-----+
|Telnet| | FTP | |Voice|  ...   |     |    Уровень приложений
+------+ +-----+ +-----+        +-----+
      |   |         |              |
     +-----+     +-----+        +-----+
     | TCP |     | RTP |  ...   |     |    Уровень хостов
     +-----+     +-----+        +-----+
        |           |              |
      +------------------------------+
      |   Internet протокол и ICMP   |     Уровень шлюзов
      +------------------------------+
                     |
      +------------------------------+
      |   протокол локальной сети    |     Сетевой уровень
      +------------------------------+
         Рис.2 Взаимосвязь протоколов
Предполагается, что протокол TCP будет в состоянии эффективно поддер-
живать протоколы более высокого уровня. Протокол TCP должен легко
взаимодействовать с такими протоколами более высокого уровня, как
ARPANET Telnet или AUDIN II THP to the TCP.

                      2.6 Надежные коммуникации
   Поток данных, посылаемый на TCP соединение, принимается получате-
лем надежно и в соответствующей очередности.
   Передача осуществляется надежно благодаря использованию подтвер-
ждений и номеров очереди. Концептуально каждому октету данных присва-
ивается номер очереди. Номер очереди для первого октета данных в сег-
менте передается вместе с этим сегментом и называется номером очереди
для сегмента. Сегменты также несут номер подтверждения, который явля-
ется номером для следующего ожидаемого октета данных, передаваемого в
обратном направлении. Когда протокол TCP передает сегмент с данными,
он помещает его копию в очередь повторной передачи и запускает тай-
мер. Когда приходит подтверждение для этих данных, соответствующий
сегмент удаляется из очереди. Если подтверждение не приходит до исте-
чения срока, то сегмент посылается повторно.
   Подтверждение протокола TCP не гарантирует, что данные достигли
конечного получателя, а только то, что программа протокола TCP на
компьютере у получателя берет на себя ответственность за это.
   Для направления потока данных между программами протоколов TCP
используется механизм управления потоками. Получающая программа прото-
кола TCP сообщает "окно" посылающей программе. Данное окно указывает
количество октетов (начиная с номера подтверждения), которое принима-
ющая программа TCP готова в настоящий момент принять.

                  2.7 Установка соединения и его отмена
   Чтобы идентифицировать отдельные потоки данных, поддерживаемые
протоколом TCP, последний определяет идентификаторы портов. Поскольку
идентификаторы портов выбираются каждой программой протокола TCP не-
зависимо, то они не будут уникальны. Чтобы обеспечить уникальность
адресов для каждой программы протокола TCP, мы объединяем идентифици-
рующий эту программу Internet адрес и идентификатор порта. В резуль-
тате получаем сокет, который будет уникален во всех локальных сетях,
объединенных в единое целое.
   Соединение полностью определяется парой сокетов на своих концах.
Локальный сокет может принимать участие во многих соединениях с раз-
личными чужими сокетами. Соединение можно использовать для передачи
данных в обоих направлениях, иными словами, оно является "полностью
дуплексным".
   Протокол TCP волен произвольным образом связывать порты с процес-
сами. Однако при любой реализации протокола необходимо придерживаться
нескольких основополагающих концепций. Должны присутствовать общеиз-
вестные сокеты, которые протокол TCP ассоциирует исключительно с
"соответствующими им" процессами. Мы представляем себе, как будто
процессы могут "владеть"портами и что процессы могут инициировать со-
единения только с тех портов, которыми они владеют. (С точки зрения
реализации протокола "владение" ограничивается хост-компьютером, од-
нако мы можем представить себе команду пользователя по запросу порта
(Request Port) или же метод выделения группы уникальных портов данно-
му процессу, например посредством ассоциирования старших байтов в
имени порта с данным процессом).
   Соединение задается командой OPEN (открыть), сделанной с локально-
го порта и имеющей аргументом чужой сокет. В ответ на такой запрос
программа протокола TCP предоставляет имя локального (короткого) со-
единения. По этому имени пользователь адресуется к данному соединению
при последующих вызовах. О соединениях следует помнить кое-какие вещи.
Мы предполагаем, что имеется некая структура данных, называемая бло-
ком управления передачей (Transmission Control Block -TCB), предназ-
наченная для сохранения описанной выше информации. Можно было бы ре-
ализовать протокол таким образом, чтобы локальное имя для соединения
было бы указателем на структуру TCB последнего. Запрос OPEN указывает
также, осуществляется ли соединение активным образом, или же происхо-
дит пассивное ожидание соединения извне.
   Запрос на пассивное открытие соединения означает, что процесс ждет
получения извне запросов на соединение, вместо того, чтобы пытаться
самому установить его. Часто процесс, сделавший запрос на пассивное
открытие, будет принимать запросы на соединение от любого другого
процесса. В этом случае чужой сокет указывается как состоящий целиком
из нулей, что означает неопределенность. Неопределенные чужие сокеты
могут присутствовать лишь в командах пассивного открытия.
   Сервисный процесс, желающий обслужить другие, неизвестные ему про-
цессы, мог бы осуществить запрос на пассивное открытие с указанием
неопределенного сокета. В этом случае соединение может быть установ-
лено с любым процессом, запросившим соединения с этим локальным соке-
том. Такая процедура будет полезна, если известно, что выбранный ло-
кальный сокет ассоциирован с определенным сервисом.
   Общеизвестные сокеты представляют собой удобный механизм априорно-
го привязывания адреса сокета с каким-либо стандартным сервисом. На-
пример, процесс "сервер для программы Telnet" жестко связан с кон-
кретным сокетом. Другие сокеты могут быть зарезервированы за передат-
чиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером,
а также Sink-процессами (последние три пункта связаны с обработкой
текстов). Адрес сокета может быть зарезервирован для доступа к проце-
дуре "просмотра", которая могла бы указывать сокет, через который
можно было бы получить новообразованные услуги. Концепция общеизвест-
ного сокета является частью TCP спецификации, однако собственно асо-
циирование сокетов с услугами выходит за рамки данного описания про-
токола (см. документ [4]).
   Процессы могут осуществлять пассивные открытия соединений и ждать,
пока от других процессов придут соответсвующие завпросы на активное
открытие, а протокол TCP проинформирует их об установлении соедине-
ния. Два процесса, сделавшие друг другу одновременно запросы на ак-
тивное открытие, получат корректное соединение. Гибкость такого под-
хода становится критичной при поддержке распределенных вычислений,
когда компоненты системы взаимодействуют друг с другом асинхронным
образом.
   Когда осуществляется подбор сокетов для локального запроса пассив-
ного открытия и чужого запроса на активное открытие, то принципиаль-
ное значение имеют два случая. В первом сслучае местное пассивное от-
крытие полностью определяет чужой сокет. При этом подбор должен осу-
ществляться очень аккуратно. Во втором случае во время местного пас-
сивного открытия чужой сокет не указывается. Тогда в принципе может
быть установлено соединение с любых чужих сокетов. Во всех остальных
случаях подбор сокетов имеет частичные ограничения.
   Если на один и тот же местный сокет осуществлено несколько ждущих
пассивных запросов на открытие (записанных в блоки TCB), и осущест-
вляется извне активный запрос на открытие, то чужой активный сокет
будет связываться с тем блоком TCB, где было указание именно на этот
запросивший соединения сокет. И только если такого блока TCB не су-
ществует, выбор партнера осуществляется среди блоков TCB с неопреде-
ленным чужим сокетом.
   Процедура установки соединения использует флаг управления синхро-
низацией (SYN) и трижды обменивается сообщениями. Такой обмен называ-
ется трехвариантным подтверждением [3].
   Соединение инициируется при встрече пришедшего сегмента, несущего
флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент
и запись создаются пришедшими от пользователей запросами на открытие.
Соответствие местного и чужого сокетов устанавливается при инициали-
зации соединения. Соединение признается установленным, когда номера
очередей синхронизированы в обоих направлениях между сокетами.
   Отмена соединения также включает обмен сегментами, несущими на
этот раз управляющий флаг FIN.

                       2.8 Коммуникация данных
   Набор данных, передаваемых по соединению, можно рассматривать как
поток октетов. Пользователь, отправляющий данные, указывает при за-
просе по посылку, следует ли данные, отправляемые при этом запросе,
немедленно проталкивать через сеть к получателю. Указание осуществля-
ется установкой флага PUSH (проталкивание).
   Программа протокола TCP может собирать данные, принимаемые от
пользователя, а затем передавать их в сеть по своему усмотрению в ви-
де сегментов. Если же выставлен запрос на проталкивание, то протокол
должен передать все неотправленные ранее данные. Когда программа про-
токола TCP, принимающая данные, сталкивается с флагом проталкивания,
ей не следует ожидать получения новых данных по сети до тех пор, пока
уже имеющиеся данные не будут переданы ждущему их местному процессу.
   Нет нужды привязывать функции проталкивания к границам сегмента.
Данные, содержащиеся в каком-либо сегменте, могут быть результатом
одного или нескольких запросов на посылку. Или же один запрос может
породить несколько сегментов.
   Целью функции проталкивания и флага PUSH является проталкивание
данных через сеть от отправителя к получателю. Функция не
осуществляет обработки самих данных.
   Существует связь между функцией проталкивания и использованием
буферов данных в интерфейсе между пользователем и протоколом TCP.
Каждый раз, когда в буфер получателя приходят данные с флагом PUSH,
содержимое этого буфера передается пользователдю на обработку, даже
если буфер и не был заполнен. Если приходящие данные заполняют буфер
пользователя до того, как получена команда проталкивания,
пользователю отправляется блок данных, соответствующий размеру
буфера. Протокол TCP имеет также средства для сообщения получателю,
что с некоторого момента он имеет дело со срочными данными. Протокол
TCP не пытается определить, что именно пользователь делает со ждущими
обработки срочными данными. Однако обычно предполагается, что
получающий данные процесс будет предпринимать усилия для быстрой
обработки срочных данных.

                     2.9 Приоритет и безопасность
   Протокол TCP использует тип сервиса и опцию безопасности протокола
Internet с тем, чтобы пользователям протокола TCP обеспечить приори-
тет и безопасность на каждом соединении. Не все модули протокола TCP
обязательно будут действовать в многоуровневой системе обеспечения
безопасности. Некоторые модули ограничиваются только обычными, неспе-
цифическими соединениями, другие ограничиваются лишь первым уровнем
безопасности и закрытости. Следовательно, некоторые реализации прото-
кола TCP и услуг для пользователей могут использовать лишь часть мно-
гоуровневой системы безопасности.
   Модули TCP, действующие в многоуровневой системе безопасности,
должны адекватным образом выставлять в отсылаемых сегментах флаги
безопасности и приоритета. Такие модули TCP должны также позволять
своим клиентам или вышестоящим протоколам, таким как Telnet и THP,
указывать требуемый уровень безопасности, закрытости и приоритета для
устанавливаемых соединений.

                      2.10 Принцип устойчивости
   Все реализации протокола TCP будут следовать общему принципу
устойчивости: быть консервативным в своих действиях и предоставлять
свободу для других.

                 3 Спецификация для функций протокола

                         3.1 Формат заголовка
   Передача TCP сегментов осуществляется в виде Internet датаграмм.
Заголовок датаграммы в Internet протоколе имеет несколько информаци-
онных полей, включая адреса отправляющего и принимающего хост-
компьютеров [2]. Заголовок TCP следует за Internet заголовком и до-
полняет его информацией, специфической для TCP протокола. Такое де-
ление допускает использование на уровне хост-компьютеров протоколов,
иных нежели TCP.
   Формат TCP заголовка
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Рис. 3 Формат TCP заголовка
Отметим, что каждая метка указывает здесь место для соответствующего
бита.
Source Port (порт отправителя) 16 бит
   номер порта отправителя
Destination Port (порт получателя) 16 бит
   номер порта получателя
Sequence Number (номер очереди) 32 бита
   Номер очереди для первого октета данных в данном сегменте (за ис-
   ключением тех случаев, когда присутствует флаг синхронизации SYN).
   Если же флаг SYN присутствует, то номер очереди является инициали-
   зационным (ISN), а номер первого октета данных - ISN+1.
Acknowledgment Number (номер подтверждения) 32 бита
   Если установлен контрольный бит ACK, то это поле содержит следущий
   номер очереди, который отправитель данной датаграммы желает полу-
   чить в обратном направлении. Номера подтверждения посылаются по-
   стоянно, как только соединение будет установлено.
Data Offset (смещение данных)  4 бита
   Количество 32-битных слов в TCP заголовке. Указывает на начало по-
   ля данных. TCP заголовок всегда кончается на 32-битной границе
   слова, даже если он содержит опции.
Reserved   6 бит
   Это резервное поле, должно быть заполнено нулями.
Control Bits (контрольные биты)  6 бит
   Биты этого поля слева направо
   URG: поле срочного указателя задействовано
   ACK: поле подтверждения задействовано
   PSH: функция проталкивания
   RST: перезагрузка данного соединения
   SYN: синхронизация номеров очереди
   FIN: нет больше данных для передачи
Window (окно)  16 бит
   Количество октетов данных, начиная с октета, чей номер указан в
   поле подтверждения. Количество октетов, получения которых ждет
   отправитель настоящего сегмента.
Checksum (контрольная сумма)  16 бит
   Поле контрольной суммы - это 16-битное дополненение суммы всех 16-
   битных слов заголовка и текста. Если сегмент содержит в заголовке
   и тексте нечетное количество октетов, подлежащих учету в контоль-
   ной сумме, последний октет будет дополнен нулями справа с тем,
   чтобы образовать для предоставления контрольной сумме 16-битное
   слово. Возникший при таком выравнивании октет не передается вместе
   с сегментом по сети. Перед вычислением контрольной суммы поле этой
   суммы заполняется нулями.
      Контрольная сумма, помимо всего прочего, учитывает 96 бит псев-
   дозаголовка, который для внутреннего употребления ставится перед
   TCP заголовком. Этот псевдозаголовок содержит адрес отправителя,
   адрес получателя, протокол и длину TCP сегмента. Такой подход
   обеспечивает защиту протокола TCP от ошибшихся в маршруте сегмен-
   тов. Эту информацию обрабатывает Internet протокол. Она передается
   через интерфейс протокол TCP/локальная сеть в качестве аргументов
   или результатов запросов от протокола TCP к протоколу IP.
                  +--------+--------+--------+--------+
                  |         Адрес отправителя         |
                  +--------+--------+--------+--------+
                  |         Адрес получателя          |
                  +--------+--------+--------+--------+
                  |  нули  |  PTCL  |    длина TCP    |
                  +--------+--------+--------+--------+
      Длина TCP сегмента - это длина TCP заголовка и поля данных, из-
   меренная в октетах. Это не является точным указанием количества
   передаваемых по сети октетов, она не учитывает 12 октетов псевдо-
   заголовка, но тем не менее расчет этого параметра все же произво-
   дится.
Urgent Pointer (срочный указатель)  16 бит
   Это поле сообщает текущее значение срочного указателя. Последний
   является положительной величиной - смещением относительно номера
   очереди данного сегмента. Срочный указатель сообщает номер очереди
   для октета, следующего за срочными данными. Это поле интерпретиру-
   ется только в том случае, когда в сегменте выставлен контрольный
   бит URG.
Options (опции)  длина переменная
   Опции могут располагаться в конце TCP заголовка, а их длина кратна
   8 бит. Все опции учитываются при расчете контрольной суммы. Опции
   могут начинаться с любого октета. Они могут иметь два формата:
   - однооктетный тип опций;
   - октет типа опции, октет длины опции и октеты данных
     рассматриваемой опции.
   В октете длины опции учитываются октет типа опции, сам октет
   длины, а также все октеты с данными.
   Заметим, что список опций может оказаться короче, чем можно ука-
   зать в поле Data Offset. Место в заголовке, остающееся за опцией
   "End-of-Option", должно быть заполнено нулями. Протокол TCP должен
   быть готов обрабатывать все опции.
      В настоящее время определены следующие опции:
   Тип     Длина      Значение
    0        -       конец списка опций
    1        -       нет операций
    2        4       максимальный размер сегмента
                       Определения указанных опций
   Конец списка опций
   +--------+
   |00000000|   тип 0
   +--------+
   Этот код опции определяет конец списка опций. Конец списка может
   не совпадать с концом TCP заголовка, указанным в поле Data Offset.
   Эта опция используется после всех опций, но не после каждой из
   них. Опцию необходимо использовать только в том случае, если иначе
   не будет совпадения с концом TCP заголовка.
   Нет операций
   +--------+
   |00000001|    тип 1
   +--------+
      Опции этого типа могут ставиться между опциями. Целью при этом
   может служить выравнивание очередной опции по границе слова. Нет
   гарантии, что отправители будут использовать данную опцию. Поэтому
   получатели должны быть готовы обрабатывать опции, даже если они не
   будут начинаться на границе слова.
   Максимальный размер сегмента
   +--------+--------+--------+--------+
   |00000010|00000100| макс.разм.сегм. |
   +--------+--------+--------+--------+
     тип 2   длина=4
      Поле данных опции - 16 бит. Если опция присутствует в списке,
   то она указывает для программы протокола TCP максимальный размер
   получаемого сегмента, отправившей сегмент с этой опцией. Эту опцию
   следует посылать лишь при первоначальном запросе на установление
   соединения (т.е. в сегментах с установленным контрольным битом
   SYN). Если данная опция не была использована, ограничения на раз-
   мер отсутствуют.
Padding (выравнивание)  длина переменная
   Выравнивание TCP заголовка осуществляется с тем, чтобы убедиться в
   том, что TCP заголовок заканчивается, а поле данных сегмента начи-
   нается на 32-битной границе. Выравнивание выполняется нулями.

                           3.2 Терминология
   Прежде чем мы сможем обсудить многие детали действия TCP протоко-
ла, нам необходимо ввести подробную терминологию. Для поддержания TCP
соединения необходиом иметь несколько переменных. Мы решили, что эти
переменные будут помещены в соответствующую запись - блок управления
передачей (Transmission Control Block - TCB). Среди переменных блока
TCB имеются номера местного и чужого сокетов, флаги безопасности и
приоритета для данного соединения, указатели буферов посылки и полу-
чения, указатели текущего сегмента и очереди повторной посылки. Кроме
всего этого в TCB имеются несколько переменных, имеющих отношение к
номерам очередей отправителя и получателя.

Отправление
SND.UNA - посылка неподтверждена
SND.NXT - послать следующий сегмент
SND.WND - отправить окно
SND.UP  - отправить срочный указатель
SND.WL1 - номер очереди сегмента, использованный для обновления
          последнего окна
SND.WL2 - номер подтверждения в сегменте, используемый для обновления
          последнего окна
ISS     - первоначальный номер очереди отправления

Получение
RCV.NXT - получить следующий сегмент
RCV.WND - получить окно
RCV.UP  - получить срочный указатель
IRS     - первоначальный номер очереди получения

   Нижеприведенные диаграммы могут помочь связать некоторые из этих
переменных с местом в очереди

Очередь отправления
         1          2          3          4
    ----------|----------|----------|----------
           SND.UNA    SND.NXT    SND.UNA
                                +SND.WND
1. - старые номера очереди, которые получили подтверждение
2. - номера очереди для данных, не получивших подтверждения
3. - номера очереди, допущенные к новой передаче
4. - следующие номера очереди, чья передача еще не разрешена
                      Рис. 4 Очередь отправления
Окно отправления - это участок очереди, отмеченный меткой 3 на
рисунке 4.

Очередь получения
         1          2          3
    ----------|----------|----------
           RCV.NXT    RCV.NXT
                     +RCV.WND
1. - старые номера очереди, которые получили подтверждение
2. - номера очереди, допущенные к очередному этапу получения
3. - следующие номера очереди, еще не получившие разрешения
                       Рис. 5 Очередь получения
Окно получения - это участок очереди, отмеченный меткой 2 на рисунке
5.
   В обсуждении также часто используются некоторые переменные,
берущие свое значение из полей очередного сегмента.
Переменные для очередного сегмента
SEG.SEQ - номер очереди для сегмента
SEG.ACK - номер подтвержения для сегмента
SEG.LEN - длина сегмента
SEG.WND - окно для сегмента
SEG.UP  - срочный указатель для сегмента
SEG.PRC - приоритет для сегмента
Соединение во время функционирования проходит через серии промежу-
точных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED,
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED явля-
ется фиктивным, поскольку оно представляет состояние, когда не су-
ществует блока TCP, а потому и нет соединения. Краткое описание сос-
тояний:
LISTEN       - Ожидание запроса на соединение со стороны чужих портов
               и программ TCP
SYN-SENT     - Ожидание парного запроса на установление соединения. С
               нашей стороны запрос уже сделан.
SYN-RECEIVED - Ожидание подтверждения после того, как запрос
               соединения уже принят и отправлен.
ESTABLISHED  - Состояние открытого соединения, принимаемые данные
               можно представить пользователю. Это нормальное
               состояние соединения в фазе передачи данных.
FIN-WAIT-1   - Ожидание запроса от чужой программы TCP, или
               подтверждения ранее отправленного запроса на закрытие
               соединения.
FIN-WAIT-2   - Ожидание запроса на закрытие соединения со стороны
               чужой программы TCP.
CLOSE-WAIT   - Ожидание запроса на закрытие соединения со стороны
               своего клиента.
CLOSING      - Ожидание подтверждения со стороны чужой программы TCP
               запроса о закрытии соединения.
LAST-ACK     - Ожидание запроса на закрытие соединения, ранее
               отправленного чужой программе TCP (запрос включал
               также подтверждение получения чужого запроса на
               закрытие соединения).
TIME-WAIT    - Ожидание когда истечет достаточное количество времени
               и можно быть уверенным, что чужая программа TCP
               получила подтверждение своего запроса на закрытие
               соединения.
CLOSED       - Состояние полного отсутствия соединения.
Соединение TCP переходит с одного состояния на другое в ответ на со-
бытия. Событие - это запросы клиента (открытие, посылка, получение,
закрытие, отказ, получение состояния соединения), приход сегментов, и
особенно тех, которые содержат флаги SYN, ACK, RST и FIN, а также ис-
течение выделенного времени.
Диаграмма состояний на рисунке 6 иллюстрирует лишь смену состояний, а
также вызвавшие это события, производимые действия, но не адреса, ус-
ловия ошибок, не действия, не связанные прямо с изменением состояния.
Более подробные сведения о действиях программы протокола TCP в ответ
на события приведены в последней главе.
Замечание. Данная диаграмма является лишь сводной, но не должна
восприниматься как полная спецификация.

                                           Активное открытие
                                        -------------------------
                                        создание TCB, посылка SYN
                              +--------+ -----------------
                              | CLOSED |                  \
                              +--------+<---------------   \
                                |    ^                   \  \
             Пассивное открытие |    |     CLOSE          \  \
             ------------------ |    | --------------      \  \
               создание TCB     |    | ликвидация TCB       \  \
                                V    |                       \  \
                              +--------+          CLOSE       \  \
                              | LISTEN |      --------------  |  |
                              +--------+      ликвидация TCB  |  |
               получение SYN    |    |      SEND              |  |
             ----------------   |    |   -----------          |  V
+--------+   посылка SYN, ACK  /      \  посылка SYN    +----------+
|        |<-------------------          --------------->|          |
|  SYN   |                  получение SYN               |          |
|  RCVD  |<---------------------------------------------| SYN SENT |
|        |                   посылка ACK                |          |
|        |---------------------        -----------------|          |
+--------+                     \      /                 +----------+
  |    получение ACK для SYN    |    |  получение SYN, ACK
  |    ---------------------    |    |  ------------------
  |             x               V    V      посылка ACK
  |                           +--------+
  |    CLOSE                  | ESTAB  |
  | -----------               +--------+
  | послать FIN   CLOSE         |    |   получить FIN
  V            -----------      |    |   ------------
+--------+     послать FIN     /      \   послать ACK     +--------+
|  FIN   |<-------------------          ----------------->|  CLOSE |
| WAIT-1 |---------------------                           |  WAIT  |
+--------+                     \  получить FIN            +--------+
  | получить ACK для FIN        | -------------       CLOSE     |
  | --------------------        | отправить ACK    -----------  |
  V          x                  V                  послать FIN  V
+--------+                    +--------+                  +--------+
|  FIN   |                    | CLOSING|                  |LAST-ACK|
| WAIT-2 |                    +--------+                  +--------+
+--------+   Получить ACK для FIN |        Получить ACK для FIN |
  |          -------------------- |        -------------------- |
  |  получить FIN      x          V                  x          |
  |  ------------             +--------+                        V
   \ послать ACK              |  TIME  |                  +--------+
     ------------------------>|  WAIT  |----------------->| CLOSED |
                              +--------+   Timeout=2MSL   +--------+
                                          --------------
                                          ликвидация TCB

                          3.3 Номер очереди
   Основополагающей идеей в проектировании протокола является то, что
каждый октет данных, посылаемый на TCP соединение, имеет номер очере-
ди. Поскольку каждый октет пронумерован, то каждый из них может быть
опознан. Приемлемый механизм опознания является накопительным, так
что опознание номера X означает, что все октеты с предыдущими номера-
ми уже получены. Этот механизм позволяет регистрировать появление
дубликатов в условиях повторной передачи. Нумерация октетов в преде-
лах сегмента осуществляется так, чтобы первый октет данных сразу
вслед за заголовком имел наименьший номер, а следующие за ним октеты
имели номера по возрастающей.
   Важно помнить о том, что количество номеров для очереди, хоть и
велико, но ограничено. Диапазон номеров - от 0 до 2**32-1. Поскольку
набор ограничен, то все арифметические операции с номерами очередей
должны осуществляться по модулю 2**32. Это совсем не означает всякий
раз предварительную арифметическую проверку номеров очереди на попа-
дание в диапазон от 2**32-1 до 0. В работе с модульной арифметикой
есть некие тонкости, поэтому нужно аккурактно программировать сравне-
ние столь больших величин. Так символ '=<' означает "меньше или рав-
но" (по модулю 2**32).
   Протокол TCP должен осуществлять следующие типы сравнения для
номеров очереди:
(a) является ли номер в подтверждении номером очереди для октетов,
    уже отправленных, но еще не получивших подтверждения;
(b) получили ли все октеты в сегменте подтверждение своих номеров
    (т.е. следует ли удалить данный сегмент из очереди на повторную
    посылку);
(c) содержит ли пришедший сегмент ожидаемые нами номера (т.е.
    "перекрывает" ли этот сегмент окно получателя).
   В ответ на посылку данных протокол TCP будет получать их подтвер-
ждение. Для работы с полученным подтверждением необходимо уметь де-
лать сравнение для
SND.UNA - самого старого из номеров, не имевших подтверждения,
SND.NXT - следующего номера очереди, ждущего посылки,
SEG.ACK - номера подтверждения, полученного от чужой принимающей про-
          граммы TCP (следующего номера очереди, ожидаемого чужой
          программой TCP),
SEG.SEQ - номера очереди первого октета в сегменте,
SEG.LEN - количества октетов в поле данных сегмента (учитывая SYN и
          FIN),
SEG.SEQ+SEG.LEN-1 - номера очереди последнего октета из сегмента.
   Новое подтверждение (называемое "подтверждением приемлемости") -
это подтверждение выполнимости неравенств
SND.UNA < SEG.ACK =< SND.NXT
Сегмент из очереди повторной посылки получает полное подтверждение,
если сумма его номера в очереди и длины поля данных меньше или равна
номеру подтверждения из пришедшего сегмента.
   При получении данных необходимо производить операции сравнения для
следующих величин:
RCV.NXT - следующий номер из очереди приходящих сегментов, а также
          левая или нижняя граница окна получения,
RCV.NXT+RCV.WND-1 - номер очереди последнего сегмента, ожидаемого в
          приходящем сегменте, а также правая или верхняя граница
          окна получения,
SEG.SEQ - первый номер в очереди, принесенный пришедшим сегментом,
SEG.SEQ+SEG.LEN-1 - последний номер в очереди, принесенный пришедшим
          сегментом.
   Считается, что сегмент перекрывает часть разрешенных номеров в
очереди получения, если
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND    или
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Первая часть этого текста смотрит, попадает ли начало сегмента на ок-
но, а вторая часть - попадает ли в окно задняя часть сегмента. Если
выполняется какая-либо часть теста, то сегмент попадает в окно.
   Действительность несколько сложнее. Выбирая окно нулеволй длины
или сегмент нулевой длины, мы получаем четыре варианта проверки на
приемлемость для приходящих сегментов
длина     окно
сегмента  получения     тест
--------  ---------  ---------------------------------------------
   0          0      SEG.SEQ = RCV.NXT
   0         >0      RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
  >0          0      неприемлемо
  >0         >0      RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND  или
                     RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Заметим, что когда окно, получения нулевое, никакие сегменты прини-
маться не будут за исключением ACK сегментов. Таким образом, протокол
TCP может устанавливать нулевое окно получения при передаче данных и
получении подтверждений. Однако даже когда окно получения нулевое,
программа протокола TCP обязана обрабатывать поля RST и URG всех при-
ходящих сегментов.
   Мы получили преимущество данной схемы нумерации в том, что она
допускает также защиту для определенной управляющей информации. Это
достигается косвенным образом посредством включения некоторых кон-
трольных флагов в очередь, так что они могут быть повторно посланы и
подтверждены без сбоя (т.е. будет задействована одна или несколько
копий). Управляющая информация реально находится не в поле данных
сегмента. Следовательно, мы должны принять правила косвенного присво-
ения номеров очереди сегментам управления. SYN и FIN являются един-
ственными управляющими сигналами, приемлемыми для такой защиты, и они
используются только при открытии и закрытии соединения. Для целей
поддержания очередности, сигнал SYN рассматривается как стоящий перед
первым действительным октетом данных в сегменте, куда оба они были
помещены. В то же время FIN считается стоящим после последнего реаль-
ного октета данных в сегменте. Длина сегмента (SEG.LEN) учитывает как
данные, так и номера очереди, отведенные под управление. В случае,
когда присутствует SYN, значение SEG.SEQ соответствует номеру в оче-
реди для сигнала SYN.

               Выбор первоначального номера для очереди
   Протокол не накладывает ограничения на многократное повторное ис-
пользование конкретного соединения. Соединение задается подбором пары
сегментов. Новые запросы на установление какого-либо соединения будут
рассматриваться как повторные реализации этого соединения. Вследствие
такого подхода возникает следующая проблема: "Как протокол TCP отли-
чает дубликаты сегментов, оставшиеся от предыдущей реализации этого
соединения?" Эта проблема становится явной, если соединение быстро
открывается и закрывается несколько раз подряд, или же если соедине-
ние прерывает свою работу с потерей информации, хранившейся в опера-
тивной памяти компьютера, и затем устанавливается повторно. Чтобы
избежать сбоя, мы должны избегать использования сегментов данной реа-
лизации соединения, когда в сети еще присутствуют те же самые номера
очереди, оставшиеся от предыдущей реализации соединения. Мы желаем
застраховаться от этого, даже если программа протокола TCP даст сбой
и потеряет всю информацию об используемых ею номерах очередей. При
создании новых соединений применяется генератор первоначальных номе-
ров очереди (ISN), который выбирает новые 32 битные значения ISN.
Генератор привязан к 32-битным часам (вероятно, фиктивным), чье зна-
чение меняется каждые 4 микросекунды. Таким образом, полный цикл ча-
сов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что
сегменты будут существовать в сети не более максимального времени
жизни сегмента (Maximum Segment Lifatime - MSL), и что MSL меньше,
чем 4.55 часа, то мы можем с основанием полагать, что номера ISN бу-
дут уникальны.
   Для каждого соединения существует номер в очереди отправления и
номер в очереди получения. Первоначальный номер в очереди отправления
(ISS) выбирается программой TCP, посылающей данные в этой очереди, а
первоначальный номер в очереди получения (IRS) выясняется во время
установления соединения.
   Во время установления или инициализации какого-либо соединения обе
программы протокола TCP должны синхронизировать друг с другом перво-
начальные номера очередей. Это осуществляется посредством обмена сег-
ментами, устанавливающими соединения, несущими контрольный бит, назы-
ваемый "SYN" (for synchronize - для синхронизации), несущими исходные
номера для очередей. Для краткости, сегменты, несущие бит SYN, также
называются SYN сегментами. Следовательно, решение проблемы требует
приемлемого механизма для подбора первоначального номера очереди и
немногочисленных сигналов подтверждения при обмене номерами ISN.
   Синхронизация требует, чтобы каждая сторона, участвующая в соеди-
нении, посылала свой собственный первоначальный номер очереди, а так-
же получала подтверждение на это от напарника. Каждая сторона должна
также получить первоначальный номер очереди от напарника и послать
подтверждение.
  1) A --> B сигнал SYN: мой номер очереди X
  2) A <-- B сигнал ACK: ваш номер очереди X
  3) A <-- B сигнал SYN: мой номер очереди Y
  4) A --> B сигнал ACK: ваш номер очереди Y
Поскольку шаги 2 и 3 можно объединить в одно сообщение, последнее
называется подтверждением трех путей (трех сообщений).
   Подтверждение трех путей необходимо, поскольку номера очереди не
привязываются к неким глобальным часам данной компьютерной сети, и
программы TCP могут иметь различные механизмы для подбора номеров
ISN. Получатель первого сигнала SYN не может знать, задержался ли
этот сигнал и уже устарел, или это не так, даже если получатель не
помнит последний номер очереди, использованный этим соединением (что
тоже не всегда возможно). Так что он должен попросить отправителя
проверить этот сигнал SYN. Подтверждение трех путей и преимущества
хронометрированной схемы обсуждаются в статье [3].

                           Период молчания
   Чтобы быть уверенным в том, что программа TCP не создает сегмента,
несущего номер очереди, который уже используется старым сегментом,
все еще "ходящим" по сети, программа TCP должна сохранять молчание по
крайней мере в течении времени жизни сегмента (MSL) до тех пор, пока
она не назначит какие-либо номера очереди при запуске или восстанов-
лении после сбоя, когда записи в пямяти для прежних номеров из очере-
ди были потеряны. В данной спецификации MSL берется равным 2 минуты.
Это значение выбрано разработчиками и может быть изменено, если прак-
тика покажет необходимость в этом. Заметим, что если программа прото-
кола в некотором смысле повторно инициализируется, но при этом в па-
мяти остались применявшиеся ранее номера очереди, то в ожидании нужды
нет; следует лишь убедиться в том, что новые рабочие номера очередей
больше, чем применявшиеся ранее.

              Концепция периода молчания в протоколе TCP
   Данная спецификация ставит условие что компьютеры, потерпевшие
крах с потерей всей информации о последних номерах очередей, переда-
ваемых  по открытым (т.е. не закрытым специальной командой) соедине-
ниям, будут воздерживаться от посылки каких-либо TCP сегментов в те-
чении по крайней мере максимального времени жизни сегмента (Maximum
Segment Lifetime - MSL) в системе Internet, чей частью и является
данный хост. В последующих параграфах приводится объяснение для этой
спецификации. Некоторые реализации протокола TCP могут нарушать со-
глашение о периоде молчания, рискуя при этом тем, что некоторые полу-
чатели в системе Internet будут воспринимать старые данные как новые,
или новые данные будут отброшены словно дубликаты в действительности
устаревших сегментов.
   Программы протокола используют новые номер очереди всякий раз,
когда какой-либо сегмент формируется и помещается на хосте в очередь
отправления по сети. Процедура фиксирования дубликатов и алгоритм
очереди в протоколе TCP полагаются на уникальное связывание данных
сегмента с местом в очереди. Номера очереди не успевают пройти весь
диапазон в 2**32 значения, прежде чем связанные с ними данные из от-
правленного сегмента получат подтверждение от получателя, а все
копии-дубликаты упомянутого сегмента покинут сеть Internet. Без этого
условия можно предположить, что двум отдельным TCP сегментам могут
быть назначены одинаковые или перекрывающиеся номера, что вызовет
проблему у получателя при определении, какие данные являются новыми,
а какие устаревшими. Напомним, что каждый сегмент привязан как ко
множеству следующих друг за другом номеров очереди, так и к имеющимся
в этом сегменте октетам данных.
   При обычных условиях программы TCP отслеживают текущий номер оче-
реди, подлежащий отправке, а также самое старое из ожидаемый подтвер-
ждений, что позволяет избежать ошибочного использования номера очере-
ди, прежде чем будет получено подтверждение от более раннего исполь-
зования этого же номера. Одно это не гарантирует, что старые данные -
дубликаты будут удалены из сети, поэтому номера очереди сделаны очень
большими, чтобы уменьшить вероятность того, что странствующие по сети
дубликаты вызовут сбой по прибытии. При скорости обмена 2
мегабайта/сек очереди в 2**32 октета хватает на 4.5 часа. Поскольку
максимальное время жизни сегмента в сети вряд ли превышает несколько
десятков секунд, это считается достаточной защитой для будущих сетей,
даже если скорости передачи данных возрастут до десятков мегабит/сек.
При скорости 100 мегабит/сек один цикл использования всех номеров
очереди составляет 5.4 минуты, что может быть достаточно мало, но еще
остается приемлемым.
   Однако основной механизм регистрации дублей и поддержания очередей
может быть отменен, если программа протокола TCP, посылающая данные,
не имеет места в памяти для хранения номеров в очереди, которые она
использовала в последний раз для конкретного соединения. Например,
если программа TCP при создании всех соединений начинает с номера
очереди 0, то при сбое и повторном запуске программа TCP может по-
вторно сформировать прежнее соединение (возможно, после анализа напо-
ловину открытого соединения) и послать по нему пакеты, чьи номера в
очереди полностью совпадают или лишь частично перекрывают номера па-
кетов, которые еще присутствуют в сети и были отправлены предыдущей
реалиизацией этого же соединения. В отсутствие сведений о номерах
очереди, прежде использовавшихся для передачи информации по данному
конкретному соединению, спецификация протокола TCP рекомендует отпра-
вителю воздержаться на MSL секунд от посылки сегментов по этому со-
единению, что даст возможность сегментам, запущенным в сеть старой
реализацией соединения, покинуть систему.
   От этой проблемы не защищены даже те хост-компьютеры, которые мо-
гут отслеживать текущее время и использовать его при выборе исходных
номеров очереди (т.е. даже если время используется для выбора исход-
ного номера при реализации каждого нового соединения).
   В качестве примера предположим, что соединение открыто со старто-
вым номером очереди S. Предположим также, что это соединение исполь-
зуется не столь часто и возможно, функция определения исходного номе-
ра очереди (ISN(t)) принимает значение (скажем, S1), равное номеру
последнего сегмента, отправленного данной программой TCP, по этому
конкретному соединению, Теперь предположим, что именно в этот момент
хост-компьютер дал сбой, восстановился и устанавливает новую реализа-
цию этого соединения. Первоначальный номер очереди при этом будет
S1=ISN(t), а это последний номер очереди в старой реализации соедине-
ния! Если восстановление произойдет достаточно быстро, то старые ду-
бликаты, созданные с номером очереди, близким к номеру S1, могут быть
получены своим адресатом и обработаны так, как будто бы это новые
пакеты в новой реализации соединения.
   Проблема состоит в том, что хост-компьютер - получатель может не
знать, как долго он был в состоянии сбоя и существуют ли еще в систе-
ме старые дубликаты, оставшиеся от прежних реализаций соединений.
   Одним из путей решения этой проблемы является преднамеренная за-
держка в отправлении сегментов в течении времени MSL после восстанов-
ления вслед за крахом - это спецификация периода молчания. Хост-
компьютеры, предпочитающие избегать паузы, рискуют получить проблему
столкновения старых и новых пакетов на каком-либо адресате, пожелав-
шем не прибегать к периоду молчания.
   Реализации протокола могут предложить пользователям TCP возмож-
ность выбора между ожиданием в соединениях после сбоя и несоблюдением
периода молчания для любых соединений. Очевидно, что для тех про-
грамм, где пользователь выбрал режим ожидания, в действительности, в
этом нет нужды после того, как компьютер был выключен по крайней мере
MSL секунд.
   Итак, каждый отправленный сегмент занимает один или несколько но-
меров в очереди ожидания. Номера, отведенные под сегмент, являются
"занятыми" или "в работе", пока не истекут MSL секунд. При сбое опре-
деленное место в очереди в течении определенного времени продолжает
оставаться занятым октетами из последнего отправленного сегмента.
Если вскоре создается новое соединение и оно испльзует какие-либо
номера из очереди в момент, когда ими еще пользуется сегмент из пре-
дыдущей реализации соединения, то следовательно эта область перекры-
вания номеров очередей может являться причиной проблем у получателя.

                     3.4 Установление соединения
   "Подтверждение трех путей" - это процедура, используемая при уста-
новлении соединения. Эта процедура обычно инициируется программой
протокола TCP в ответ на запрос другой программы TCP. Данная процеду-
ра также работает, если две программы TCP инициируют ее одновременно.
Когда попытка инициализации осуществляется с обоих концов одновремен-
но, каждая программа протокола TCP получает сегмент "SYN", который не
несет подтверждения для уже отправленного ею "SYN". Конечно, прибытие
старых дубликатов сегмента "SYN" может произвести впечатление на по-
лучателя, будто осуществляется одновременное открытие соединения.
Корректное применение сегментов "перезагрузки" может предотвратить
двусмысленность таких ситуаций.
   Ниже приведены несколько примеров инициализации соединений. Хотя
эти примеры не показывают синхронизации соединения с помощью сегмен-
тов, несущих данные, это совершенно правомерно, поскольку программа
TCP, получающая сегменты, не передаст данные своему клиенту, пока не
станет очевидным корректность данных (т.е. данные должны
"складироваться" пользователем до тех пор, пока соединение не перей-
дет в состояние ESTABLISHED). Подтверждение трех путей уменьшает ве-
роятность появления ложных соединений. Получение информации для такой
проверки достигается посредством реализации обмена между памятью ком-
пьютера и циркулирующими в сети сообщениями.
   Простейшая процедура подтверждения трех путей показана ниже на
рисунке 7. Рисунки следует интерпретировать следующим образом. Для
удобства каждая строка пронумерована. Правые стрелки (-->) показывают
отправление TCP сегмента от программы TCP A в программу TCB B, или же
получение сегмента программой B из программы A. Левые стрелки (<--)
показывают обратные процессы. Многоточие (...) показывает сегмент,
который все еще задерживается в сети. "XXX" указывает на сегмент,
который потерян или отвергнут. Комментарии появляются в скобках.
Здесь "состояния" программы протокола TCP соответствуют моменту сразу
после посылки или получения сегмента (содержимое этого сегмента пока-
зано в средней колонке каждой строки). Содержимое сегмента в приво-
дится в сокращенной форме и представляет собой номер очереди, флаги
управления и поле ACK. Остальные поля сегмента, такие как окно, длина
и поле данных остаются за рамками нашего интереса.
     TCP A                                                  TCP B
1. CLOSED                                                LISTEN
2. SYN-SENT    --> <SEQ=100><CTL=SYN>                --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>   <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
           Основная процедура подтверждения трех путей для
                       синхронизации соединения
                              Рисунок 7.
   На строке 2 рисунка 7 программа TCP A начинает с посылки сигнала
SYN, показывая тем самым, что она будет использовать нимера очереди,
начиная с номера 100. На строке 3 программа TCB B посылает сигнал
SYN, а также подтверждение о том, что сигнал SYN со стороны программы
TCP A получен. Заметим, что поле подтверждения информирует о том, что
программа TCP B в данный момент ожидает получение номера 101. Послед-
нее также подтверждает, что сигнал SYN уже занял место в очереди под
номером 100.
   На строке 4 для отправленного программой TCP B в строке 3 сигнала
SYN программа TCP A дает ответ с помощью пустого сегмента, содержаще-
го сигнал ACK . В строке 5 программа TCP A передает по сети уже некую
порцию данных. Заметим, что сегмент в строке 5 имеет тот же номер
очереди, что был у сегмента в строке 4, поскольку сигнал ACK в очере-
ди места не занимает (если бы это было не так, то нам следовало обза-
вестись подтверждением -ACK- для самого подтверждения!).
   На рисунке 8 показана та же инициализация с незначительными услож-
нениями. Каждая программа TCP проходит по очереди состояния CLOSED,
SYN-SENT, SYN-RECIEVED и наконец, ESTABLISHED.
   TCP A                                                  TCP B
1.CLOSED                                               CLOSED
2.SYN-SENT     --> <SEQ=100><CTL=SYN>              ...
3.SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT
4.             ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
5.SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6.ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7.             ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED
                Одновременная синхронизация соединения
                              Рисунок 8
   Главной причиной для приненения подтверждения трех путей является
попытка преотвратить возникновение сбоев при получении старых дубли-
катов, инициирующих соединение. Для работы с подтверждением трех пу-
тей придумано специальное контрольное сообщение - перезагрузка
(reset). Если получающая сигнал программа TCP находится не в синхро-
низированном состоянии (т.е. в SYN-SENT, SYN-RECEIVED), то она воз-
вращает сигнал LISTEN, показывая, что она получила приемлемый сигнал
перезагрузки. Если же программа TCP находится в одном из синхронизи-
рованных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK, TIME-WAIT), то она ликвидирует соединение и про-
информирует об этом своего клиента. Мы обсудим ниже такую ситуацию
при рассмотрении "наполовину открытых" соединений.
    TCP A                                               TCP B
1.CLOSED                                              LISTEN
2.SYN-SENT    --> <SEQ=100><CTL=SYN>              ...
3.(дубликат)  ... <SEQ=90><CTL=SYN>               --> SYN-RECEIVED
4.SYN-SENT    <-- <SEQ=300><ACK=91><CTL=SYN,ACK>  <-- SYN-RECEIVED
5.SYN-SENT    --> <SEQ=91><CTL=RST>               --> LISTEN
6.            ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
7.SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8.ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>     --> ESTABLISHED
               Получение старого дубликата сигнала SYN
                              Рисунок 9
   В качестве простого примера рассмотрим ситуацию с получением ста-
рых дубликатов на рисунке 9. На строке 3 старый дубликат сигнала SYN
достигает программу TCP B. Последняя не может определить, что это
старый дубликат, и поэтому отвечает обычным образом (строка 4). Про-
грамма TCP A обнаруживает ошибочное значение в поле ACK и поэтому
возвращает сигнал RST (перезагрузка). При этом значение поля SEQ вы-
бирается таким образом, чтобы сделать сегмент правдоподобным. Про-
грамма TCP B по получении сигнала RST переходит в состояние LISTEN.
Когда на строке 6 сигнал SYN, действительный, а не устаревший, дости-
гает программу TCP B, процесс синхронизации происходит нормально.
Если же сигнал SYN на строке 6 достигает программу TCP B прежде сиг-
нала RST, может возникнуть более сложная комбинация обмена с посылкой
RST в обоих направлениях.

           Наполовину открытые соединения и другие аномалии
   Уже установившееся соединение называется "наполовину открытым",
если одна из программ TCP закрыла соединение, или отказалась от него.
Причем сделала это на своем конце, не предупредив своего партнера.
Также такая ситуация может возникнуть, если нарушена синхронизация на
концах линии вследствие сбоя, приведшего к потере информации в памя-
ти. Если на таких соединениях делается попытка отправить данные в
каком-либо направлении, то автоматически производится перезагрузка
соединения. Однако пердполагается, что наполовину открытые соединения
являются редкостью, а процедура восстановления применяется в сети
весьма умеренно.
   Если на конце A соединение считается уже несуществующим, а клиент
на конце B пытается послать данные, то это приведет к тому, что про-
грамма TCP на конце B получит контрольное сообщение о перезагрузке.
Такое сообщение показывает программе TCP на конце B, что что-то не-
правильно и ей предлагается ликвидировать это соединение.
   Предположим, что два клиента в точках A и B общаются друг с дру-
гом, и в этот момент происходит крах, приводящий к потере информации
в памяти у программы TCP на конце A. В зависимости от операционной
системы, обслуживающей программу TCP A, вероятно, будет задейстовован
некий механизм исправления ошибки. Когда программа TCP A будет запу-
щена вновь, она, вероятно, вновь начнет свою работу с самого начала
или же с инструкции преодоления сбоя. В результате, программа A, ве-
роятно, попытается открыть (OPEN) соединение или послать информацию
(SEND) через соединение, которое, как она полагает, является откры-
тым. В последнем случае от местной программы TCP (на конце A) будет
получено сообщение "соединение не открыто". При попытке установить
соединение программа TCP A будет посылать сегмент, содержащий сигнал
SYN. Такой сценарий приводит к ситуации, показанной на рисунке 10.
После того, как программа TCP A потерпит крах, пользователь попытает-
ся повторно открыть соединение. Программа TCP B тем временем продол-
жает полагать, будто соединение остается открытым.
    TCP A                                               TCP B
1.сбой                          (номер посылки 300, получения - 100)
2.CLOSED                                              ESTABLISHED
3.SYN-SENT    --> <SEQ=400><CTL=SYN>              --> (??)
4.(!!)        <-- <SEQ=300><ACK=100><CTL=SYN>     <-- ESTABLISHED
5.SYN-SENT    --> <SEQ=100><CTL=RST>              --> (ликвидация!!)
6.SYN-SENT                                            CLOSED
7.SYN-SENT    --> <SEQ=400><CTL=SYN>              -->
             Обнаружение наполовину открытого соединения
                              Рисунок 10
   Когда на строке 3 сигнал SYN достигает программу TCP B, находящую-
ся в синхронизированном состоянии, а пришедший сегмент находится за
пределами окна, программа TCP B отвечает на это его подтверждением,
показывает номер очереди, который она желает получить (ACK=100). Про-
грамма TCP A, видя, что сегмент на строке 4 не подтвердил отправлен-
ную ею информацию, фиксирует отсутствие синхронизации и посылает сиг-
нал перезагрузки (RST), поскольку обнаружено, что соединение является
открытым наполовину. На строке 5 программа TCP B ликвидирует соедине-
ние. Программа TCP A будет продолжать попытки установить соедлинение.
Теперь возникшая проблема решается простым подтверждением трех путей
(рисунок 7).
   Другой интересный сюжет имеет место, если программа TCP A терпит
крах, а программа TCP B, полагая, что находится в состоянии синхрони-
зации, пытается послать данные. Эта ситуация показана на рисунке 11.
В этом случае данные, отправленные программой TCP B, и пришедшие на
программу TCP A (строка 2). будут отвергнуты, поскольку используемого
ими соединения не существует. На основании этого программа TCP A по-
сылает сигнал RST. Как только сигнал RST принят программой TCP B, он
будет рассмотрен, а использованное прежде соединение будет ликвидиро-
вано.
    TCP A                                               TCP B
1.сбой                          (номер посылки 300, получения - 100)
2.(??)   <-- <SEQ=300><ACK=100><DATA=10><CTL=SYN> <-- ESTABLISHED
3.            --> <SEQ=100><CTL=RST>              --> (ликвидация!!)
               Активная сторона приводит к обнаружению
                   наполовину открытого соединения
                              Рисунок 11
   На рисунке 12 показано, что две программы TCP - A и B - ,имея
пасивное состояние, ждут сигнала SYN. Старый дубликат сигнала, дости-
гает программу TCP B (строка 2), запускает ее. Возвращается сигнал
SYN-ACK (строка 3) и заставляет программу TCP A генерировать сигнал
RST (на строке 3 сигнал ACK неприемлем). Программа TCP B принимает
команду перезагрузки и волзвращается в пассивное состояние LISTEN.
    TCP A                                               TCP B
1.LISTEN                                               LISTEN
2.            ... <SEQ=Z><CTL=SYN>                --> SYN-RECEIVED
3. (??)       <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK>   <-- SYN-RECEIVED
4.            --> <SEQ=Z+1><CTL=RST>              --> возврат в LISTEN
5.LISTEN                                              LISTEN
         Старый дубликат сигнала SYN инициирует перезагрузку
                      на двух пассивных сокетах
                              Рисунок 12
Может быть множество других вариаций, которые могут быть объяснены
нижеописанными правилами для создания и обработки сигналов RST.

                    Создание сигнала перезагрузки
   Согласно главному правилу, сигнал перезагрузки (RST) должен посы-
латься всякий раз, когда приходит сегмент, который очевидным образом
не предназначен для данного соединения. Если непонятно, имеет ли мес-
то данный случай, следует воздержаться от перезагрузки.
   Можно выделить три группы состояний для соединения:
1. Если соединения не существует (CLOSED), то сигнал перезагрузки по-
   сылается в ответ на любой пришедший сегмент, за исключением
   встречного сигнала перезагрузки. В частности, сигналы SYN, адресо-
   ванные на несуществующее соединение, ответгаются именно таким об-
   разом.
   Если приходящий сегмент имеет флаг в поле ACK, то сегмент с сигна-
   лом перезагрузки получает номер для очереди из поля ACK первого
   сегмента. В противном случае сегмент с сигналом перезагрузки имеет
   нулевой номер очереди и значение в поле ACK, равным сумме номера
   очереди пришедшего сегмента и его же длины. Соединение остается в
   состоянии CLOSED.
2. Если соединение находится в каком-либо несинхронизированном состо-
   янии (LISTEN, SYN-SENT, SYN-RECEIVED), если какие-либо подтвержде-
   ния пришедшего сегмента еще не отправлены (сегмент несет неприем-
   лемое значение в поле ACK) или пришедший сегмент имеет уровень
   безопасности/закрытости не соответствующий уровню и защите данного
   соединения, то отправляется сигнал перезагрузки.
   Если наш сигнал SYN не был подтвержден, а уровень приоритета при-
   шедшего сегмента больше запрошенного уровня, то либо будет увели-
   чен местный уровень приоритета (если это приемлемо для пользовате-
   ля и системы), либо будет послан сигнал перезагрузки. Или же если
   уровень приоритета пришедшего сегмента меньше запрошенного, то об-
   работка будет продолжена далее, как если бы уровень был таким же
   (если чужая программа TCP не может повысить уровень приоритета до
   нашего, то это будет отмечено в следующем отправляемом ею сегмен-
   те, тогда и будет закрыто соединение). Если наш сигнал SYN получил
   подтверждение (возможно в пришедшем к нам сегменте), то уровень
   приоритета пришедшего сегмента должен точно соответствовать мест-
   ному уровню. Если последнее условие не выполняется, посылается
   сигнал перезагрузки.
   Если приходящий сегмент несет сигнал ACK, то сигнал перезагрузки
   будет иметь номер в очереди, соответствующий номеру сигнала ACK в
   пришедшем сегменте. В противном случае сигнал перезагрузки будет
   иметь нулевой номер очереди, а сигнал ACK - номер, равный сумме
   номера пришедшего сегмента и его же длины. Соединение не меняет
   своего состояния.
3. Если соединение находится в синхронизированном состоянии
   (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-
   ACK, TIME-WAIT), то любой неприемлемый сегмент (не попадающий в
   окно номеров очереди, несущий неправильный номер подтверждения)
   должен приводить к появлению сегмента с пустым полем подтвержде-
   ния, содержащего текущий номер в очереди на посылку, а также под-
   тверждение, указывающее на следующий ожидаемый с этого соединения
   номер. Соединение остается в своем прежнем состоянии.
      Если пришедший сегмент имеет уровень защиты, изоляции или прио-
   ритета, не соответствующий местному уровню соединения, то отправ-
   ляется сигнал перезагрузки, а соединение переходит в состояние
   CLOSED. Сигнал перезагрузки имеет номер очереди, соответствующий
   номеру сигнала ACK в пришедшем сегменте.

                  Обработка сигнала на перезагрузку
   Для всех состояний, кроме SYN-SENT, все сегменты с сигналом пере-
загрузки (RST) проходят проверку полей SEQ. Сигнал перезагрузки приз-
нается, если его номер очереди попадает в окно. В состоянии же SYN-
SENT (сигнал RST получен в ответ на посылку инициирующего сигнала
SYN), сигнал RST признается, если поле ACK подтверждает ранее сделан-
ную посылку сигнала SYN.
   Получатель сигнала RST сперва проверяет его, и лишь потом меняет
свое состояние. Если получатель находился в состоянии LISTEN, то он
игнорирует сигнал. Если получатель находился в состоянии SYN-
RECEIVED, то он возвращается вновь в состояние LISTEN. В иных случаях
плучатель ликивдирует соединение и переходит в состояние CLOSED. Если
получатель находтся в каком-либо ином состоянии, то он ликвидирует
соединение и прежде чем перейти в состояние CLOSED, оповещает об этом
своего клиента.

                       3.5 Закрытие соединения
   Состояние CLOSED означает "я не имею данных для передачи". Конеч-
но, закрытие полнодуплексного соединения является предметом множества
интерпретаций, поскольку не очевидно, как интерпретировать в соедине-
нии сторону, получающую информацию. Мы решили интерпретировать CLOSE
в упрощенной манере. Клиент, находящийся в состоянии CLOSE, может все
еще получать информацию (RECEIVE) до тех пор, пока партнер тоже не
сообщит, что переходит в состояние CLOSE. Таким образом, клиент может
изящно завершить работу на своем конце соединения. Программа протоко-
ла TCP гарантированно получит все буферы с информацией, отправленные
до того, как соединение было закрыто. Поэтому клиенту, не ждущему
информации с соединения, следует лишь ждать сообщения об успешном
закрытии этого соединения, что означает, что все данные получены про-
граммой TCP, принимающей информацию. Клиенты должны сохранять уже
закрытые ими для чтения информации соединения до тех пор, пока про-
грамма протокола TCP не сообщит им, что такой информации больше нет.
   Особое значение имеют три случая:
1) клиент инициирует закрытие соединения, дав команду своей программе
   протокола TCP.
2) закрытие соединения начинается с того, что напарник посылает сюда
   управляющий сигнал FIN.
3) оба клиента дают команду на закрытие одновременно.
Случай 1  Местный клиент инициирует закрытие
      В этом случае создается сегмент с сигналом FIN и помещается в
   очередь сегментов, ждущих отправления. После этого программа TCP
   уже не будет принимать от этого клиента каких-либо команд на от-
   правление данных по закрытому соединению, а сама переходит в со-
   стояние FIN-WAIT-1. Тем не менее, в этом состоянии еще возможно
   получение клиентом данных с этого соединения. Все сегменты, стоя-
   щие в очереди, и сам сегмент с сигналом FIN будут в случае необхо-
   димости посылаться напарнику вновь и вновь, пока не получат своего
   подтверждения. Когда программа TCP партнера подтвердит получение
   сигнала FIN, и сама отправит сюда свой сигнал FIN,  местная про-
   грамма может подтвердить получение последнего. Заметим, что про-
   грамма TCP, получающая сигнал FIN, будет подтверждать его, но не
   будет посылать своего собственного сигнала FIN до тех пор, пока ее
   клиент тоже не закроет соединения.
Случай 2  Программа TCP получает из сети сигнал FIN.
      Если из сети приходит невостребованный сигнал FIN, то принимаю-
   щая его программа TCP может подтвердить получение такого сигнала и
   оповестить своего клиента о том, что соединение закрыто. Клиент
   ответит командой CLOSE, по которой программа TCP может после пере-
   сылки оставшихся данных послать партнеру сигнал FIN. После этого
   программа TCP ждет, пока не прийдет подтверждение на отправленный
   ею сигнал FIN, после чего она ликвидирует соединение. Если под-
   тверждения не было по истечении отведенного времени, то соединение
   ликвидируется в принудительном порядке, о чем дается сообщение
   клиенту.
Случай 3  Оба клиента закрывают соединение одновременно.
      Одновременное закрытие соединения клиентами на обоих концах
   приводит к обмену сегментами с сигналом FIN. Когда все сегменты,
   стоящие в очереди перед сегментом с FIN, будут переданы и получат
   подтверждение, каждая программа TCP может послать подтверждение на
   полученный ею сигнал FIN. Обе программы по получении этих под-
   тверждений будут ликвидировать соединение.
   TCP A                                                      TCP B
1.ESTABLISHED                                            ESTABLISHED
2.(Close)
  FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  -->  CLOSE-WAIT
3.FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <--  CLOSE-WAIT
4.                                                        (Close)
  TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <--  LAST-ACK
5.TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      -->  CLOSED
6. (2 MSL)
  CLOSED
                    Нормальная процедура закрытия
                              Рисунок 13

   TCP A                                                      TCP B
1.ESTABLISHED                                            ESTABLISHED
2.(Close)                                                    (Close)
  FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ...   FIN-WAIT-1
              <-- <SEQ=300><ACK=100><CTL=FIN,ACK>    <--
              ... <SEQ=100><ACK=300><CTL=FIN,ACK>    -->
3.CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>        ... CLOSING
              <-- <SEQ=301><ACK=101><CTL=ACK>        <--
              ... <SEQ=101><ACK=301><CTL=ACK>        -->
4.TIME-WAIT                                              TIME-WAIT
  (2 MSL)                                                  (2 MSL)
  CLOSED                                                    CLOSED
     Процедура одновременного закрытия соединения с обоих концов
                              Рисунок 14

                     3.6 Приоритет и безопасность
   Замысел этой части протокола состоит в том, что соединение может
существовать лишь между портами, имеющими одинаковое значение без-
опасности и закрытости, а уровень приоритета должен соответствовать
наибольшему из запрошенных этими двумя портами значений.
   Параметры приоритета и безопасности, применяемые в протоколе TCP,
в точности соответствуют заявленным в протоколе Internet (IP) [2]. В
спецификации протокола TCP понятие "безопасность" должно включать
используемые в IP параметры, которые включают собственно безопас-
ность, закрытость, определение группы для пользователей, а также под-
держку различных ограничений.
   Попытка соединиться с неприемлемыми значениями безопасности/ за-
крытости или же с недостаточно малым значением приоритета должна
отвергаться через посылку сигнала перезагрузки. Отказ в соединении по
причине недостаточного приоритета может осуществляться только после
получения подтверждения на сигнал SYN.
   Заметим, что модули TCP, работающие лишь с значением приоритета,
установленным по умолчанию, будут тем не менее проверять приоритет
пришедших сегментов и, в случае необходимости, повышать уровень прио-
ритета, применяемый в данном конкретном соединении.
   Параметры безопасности могут быть использованы даже программами
TCP, не поддерживающими систему безопасности (значения поля безопас-
ности относилось бы к неклассифицируемым данным). Таким образом,
хост-компьютеры, не поддерживающие систему безопасности, должны быть
готовы принимать параметры безопасности, хотя сами они в посылке та-
ких параметров не нуждаются.

                         3.7 Передача данных
   Коль соединение установлено, передача данных осуществляется с по-
мощью обмена сегментами. Т.к. сегменты могут быть потеряны в резуль-
тате ошибок (например, ошибки в контрольной сумме) или перегрузки
сети, то программа протокола TCP использует механизм повторной посыл-
ки (по истечении определенного времени) с тем, чтобы убедиться в по-
лучении каждого сегмента. В главе, посвященной номерам очередей, об-
суждалось, как программа TCP в сегментах осуществляет проверку номе-
ров очередей и номеров подтверждения на предмет их корректности.
   Отправитель данных с помощью значения переменной SND.NXT отслежи-
вает следующий номер в очереди, подлежащий отправке. Получатель дан-
ных с помощью переменной RCV.NXT отслеживает следующий номер, прибы-
тие которого он ожидает. В переменную SND.UNA отправитель данных по-
мещает значение самого старого номера, который был отправлен, но еще
не получил подтверждения. Если бы поток данных моментально иссяк, а
все отправленные данные получили подтверждение, то тогда бы все эти
при переменные содержали одинаковое значение.
   Когда отправитель информации создает и посылает некий сегмент, он
увеличивает значение переменной SND.NXT. Адресат по получении сегмен-
та увеличивает значение переменной RCV.NXT и отправляет подтвержде-
ние. Когда программа TCP, пославшая данные, получает подтверждение,
она увеличивает значение SND.UNA. Разность в значениях этих перемен-
ных является мерой, характеризующей задержку сегментов в сети. Вели-
чина, на которую надо всякий раз осуществлять приращение значения
этих переменных, является длиной поля данных в сегменте. Заметим, что
поскольку соеднения находятся в состоянии ESTABLISHED, все сегменты,
в дополнение к собственно данным, должны нести некую информацию о
подтверждении ранее отправленных сегментов.
   Запрос пользователя о закрытии соединения (CLOSE) подразумевает
использование функции проталкивания, что осуществляется с помощью
контрольного флага FIN приходящем сегменте

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

      Пример процедуры измерения контрольного времени для повторной
                            посылки сегментов
      Во-первых, измерьте время, прошедшее между посылкой октета дан-
   ных, имеющего некий определенный номер в очереди, и получение под-
   тверждения, указывающего наряду с другими и на этот номер (посыла-
   емые сегменты не обязаны соответствовать полученным сегментам).
   Измеренная временная задержка - это время обращения (Round Trip
   Time - RTT). Следующий шаг - вычисление усредненного времени обра-
   щения (Smoothed Round Trip Time - SRTT):
               SRTT = (ALPHA * RSTT) + ( (1-ALPHA) * RTT)
   Затем с помощью найденного значения определяется контрольное время
   повторной посылки (Retransmission Timeout - RTO):
            RTO = min[ UBOUND, max[ LBOUND, (BETA * SRTT) ]]
   где UBOUND - верний предел контрольного времени (например, 1 мин),
   LBOUND - нижний предел (например, 1 сек). ALPHA - фактор сглажива-
   ния (например, от 0.8 до 0.9), а BETA - фактор изменения задержки
   (например, от 1.3 до 2.0).

                     Передача срочной информации
   Механизм срочной передачи протокола TCP предназначен для того,
чтобы клиент, отправляющий данные, мог побудить получателя принять
некую срочную информацию, а также позволить программе TCP, принимаю-
щей данные, информировать своего клиента, когда вся имеющаяся на на-
стоящий момент информация будет получена.
   Данный механизм позволяет помечать некую точку в потоке данных как
конец блока срочной информации. Когда в программе TCP, принимающей
данные, данная точка окажется впереди индикатора номера в очереди
получения (RCV.NXT), эта программа TCP должна дать команду своему
клиенту перейти в "срочный режим". Когда номер в очереди получения
догонит срочный указатель в потоке данных, программа TCP должна дать
команду клиенту прийти в "нормальный режим". Если срочный указатель
сменит свое положение, когда клиент находится в "срочном режиме",
последний не узнает об этом.
   Данный метод использует поле флага срочности, котрый присутствует
во всех передаваемых сегментах. Единица в поле контрольного флага URG
означает, что задействовано поле срочности . Чтобы получить указатель
этого поля в потоке данных, необходимо дополнить его номером рассмат-
риваемого сегмента в очереди. Отсутствие флага URG означает отсут-
ствие у отправителя непосланных срочных данных.
   При указании срочности клиент должен также послать по крайней мере
один октет данных. Если клиент, помещающий данные, дополнительно за-
кажет функцию проталкивания, то передача срочной информации ждущему
ее процессу многократно ускорится.

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

                      Пожелания по управлению окном
      Выделение очень малого окна приводит к передаче данных очень
   маленькими сегментами, тогда как лучший режим осуществляется при
   использовании сегментов большего размера.
      Чтобы избежать применения малых окон, получателю данных предла-
   гается откладывать изменение окна до тех пор, пока свободное место
   не составит X процентов от максимально возможного в памяти для
   этого соединения (где X может быть от 20 до 40).
      Другой совет, чтобы не посылать малые сегменты, состоит в том,
   чтобы отправитель не спешил с посылкой данных, пока окно не станет
   достаточно большим. Но если клиент дает команду на использование
   функции проталкивания, то данные следует немедленно отправлять,
   даже если это будет осуществляться малым сегментом.
      Заметим, что во избежание ненужных повторных пересылок не нужно
   медлить с посылкой подтверждений. Стратегия может заключаться в
   посылке подтверждения при получении сегмента малого размера (без
   обновления информации обокне), затем посылается другое другое под-
   тверждение с новой информацией об окне, если последнее расширяет-
   ся.
      Сегмент, посылаемый для проверки нулевого окна, может иницииро-
   вать разбивку передавамых данных на все более и более мелкие сег-
   менты. Если сегмент, содержащий единичный октет данных и отправ-
   ленный для проверки нулевого окна, получен, то он займет один ок-
   тет в имеющемся в данный момент окне. Если же программа TCP просто
   посылает столько данных, сколько может, всякий раз, когда окно
   ненулевое, то передаваемые данные будут разбиваться на большие и
   малые сегменты. По истечении некоторого времени случающиеся паузы
   в выделении окна получателем данны приведут к разбивке больших
   сегментов на многочисленные и уже не столь большие пары. Итак, по
   прошествии некоторого времени передача данных будет осуществляться
   преимущественно малыми сегментами.
      Предложение состоит в том, чтобы реализации протокола TCP ак-
   тивно пытались объединить малые окна в более крупые, поскольку
   механизмы управления окном стремятся ввести много малых окон в
   простейших реализациях протокола.

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

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

                        TCP команды клиента
   В следующих параграфах функционально характеризуется интерфейс
клиент/протокол TCP. Нотация вызова подобна нотации большинства
процедур или нотации вызова функции в языках высокого уровня, од-
нако это не означает неправомерность вызовов на обслуживание в
виде ловушек (trap) (например SVC, UUO, EMT).
   Описанные ниже команды клиента определяют основные операции,
которые должна выполнять программа протокола TCP для поддержки
коммуникаций между процессами. Отдельные реализации протокола дол-
жны определять свой собственный конкретный формат и могут обеспе-
чить комбинации или наборы базовых функций для одиночных вызовов.
В частности, некоторые реализации могут автоматически открывать
соединение (OPEN), как только по нему клиент дает первую команду
посылки (SEND) или получения (RECEIVE).
   Для того, чтобы поддерживать интерфейс между процессами, про-
грамма TCP должна не только принимать команды, но и возвращать
некую информацию обслуживаемым процессам. Эта информация состоит
из:
a) общей информации о соединении (т.е. прерываний, закрытия соеди-
   нения партнером, управление связью с непредопределенным чужим
   сокетом).
b) ответа на конкретные команды клиента, указыващего на успешность
   действий или различные типы ошибок.

Команда открытия
   Формат
   OPEN (свой порт, чужой порт, активный/пассивный [,контрольное
   время] [,приоритет] [,безопасность] [,опции]) -> местное имя
   для соединения
      Мы полагаем, что местная программа TCP несет ответственность
   за идентификацию обслуживаемых процессов и будет проверять при-
   надлежность процессов, желающих обратиться к данному соедине-
   нию. В зависимости от реализации протокола TCP, либо программа
   TCP, либо протокол более нижнего уровня (например, IP) будут
   создавать адрес отправителя, а точнее, идентификаторы для ло-
   кальной сети и интерфейса TCP. Такая предусмотрительность явля-
   ется результатом учета безопасности, а именно того, чтобы ни
   одна из программ TCP не смогла замаскироваться под какую-либо
   другую, и т.д. Аналогичным образом ни один процесс не должен
   замаскироваться под другой без того, чтобы не иметь конфликт с
   протоколом TCP.
      Если флаг активный/пассивный установлен в состояние
   "пассивный", то это означает, что дан запрос на "прослушивание"
   (LISTEN) сигнала установления соединения извне. Пассивное от-
   крытие может дать либо полное описание чужого сокета, с которым
   должно быть установлено данное соединение, либо не давать ника-
   ких указаний по поводу чужого сокета, который должен дать сиг-
   нал. Пассивное открытие соединения с четко определенным чужим
   сокетом может стать в любой момент активным открытым соединени-
   ем, если будет дана команда на посылку данных (SEND). Создается
   блок управления передачей (TCB) и частично заполняется информа-
   цией, полученной от параметров команды OPEN.
      В случае команды на активное открытие (OPEN) протокол TCP
   немедленно запустит процедуру синхронизации (точнее, установле-
   ния) соединения.
      Контрольное время, если оно присутствует среди параметров
   функции, позволяет клиенту установить контрольное время ликви-
   дации для всех данных, посылаемых от имени протокола TCP. Если
   в течение этого контрольного времени какие-либо данные не до-
   стигли своего адресата, программа TCP ликвидирует соединение. В
   настоящее время общепринятым контрольным временем являются пять
   минут.
      Программа протокола TCP или какая-либо компонента операцион-
   ной системы будет проверять права клиента на открытие соедине-
   ния, имеющего заказанные клиентом приоритет и безопасность. Ес-
   ли приоритет или безопасность/закрытость не указаны, должен ис-
   пользоваться вызов CALL, использующий значения этих параметров,
   принятые по умолчанию.
      Программа протокола TCP будет воспринимать приходящие запро-
   сы только если они имеют тот же самый уровень безопасности/за-
   крытости. Приоритет запросов должен быть равен или превышать
   приоритет, указанный в команда открытия (OPEN).
      Если приоритет для соединения оказывается больше, чем значе-
   ние, указанное в запросе CALL, то берется приоритет из пришед-
   шего запроса и становится постоянной характеристикой соедине-
   ния. Разработчики могут перепоручить клиентам ведение перегово-
   ров по поводу установления приоритета соединения. Например,
   клиент может указывать приоритет, который должен быть присвоен
   соединению. В другом примере, любая попытка повысить приоритет
   соединения должна получить санкцию клиента.
      По завершении операции протокол TCP возвращает клиенту мест-
   ное название для открытого соединения. Впоследствии имя соеди-
   нения может использоваться в качестве короткого обозначения для
   соединения, идентифицируемого парой <местный сокет, чужой со-
   кет>.

Команда на посылку данных
   Формат
   SEND (местное название соединения, адрес буфера, количество
   байтов с данными, флаг проталкивания, флаг срочности
   [контрольное время])
      Данная команда приводит к тому, что данные, содержащиеся в
   указанном клиентом буфере, передаются на указанное соединение.
   Если соединение не было к этому времени открытым, команда SEND
   является ошибочной. Некоторые реализации протокола TCP могут
   позволить клиентам начинать общение сразу с команды SEND. При
   этом команда OPEN должна осуществляться автоматически. Если
   процесс, давший команду на посылку, не уполномочен использовать
   данное соединение, команда возвращает клиенту ошибку.
      Если установлен флаг проталкивания (PUSH), то данные должны
   быть переданы по назначению с соответствующим сообщением, а бит
   PUSH должен быть установлен на последний из созданных в буфере
   TCP сегментов. Если флаг PUSH не выставлен, то имеющиеся данные
   могут быть объединены с данными из посылаемых следом датаграмм.
   Кроме того, хост-компьютер, посылающий данные, может получить
   сообщение от шлюза об истечении контрольного времени.
      Если хост-компьютер, осуществляющий сборку фрагментов дата-
   граммы, не может в отведенное для этого время завершить свою
   работу из-за получения ошибочного фрагмента, то он выкидывает
   датаграмму и может послать сообщение об превышении контрольного
   времени. Этого сообщения не следует посылать вовсе, если не был
   получен нулевой фрагмент датаграммы.
      От шлюза приходит сообщение с кодом 0 ,а от хост-компьютера
   - сообщение с кодом 1.

               Формат сообщения о ошибках с параметрами
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Тип       |     Код       |    Контрольная сумма          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   указатель   |               не используется                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet заголовок + 64 бита данных из исходной датаграммы    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Поля IP протокола:
   Адрес получателя
        Компьютерная сеть и адрес отправителя заносятся в дата-
      грамму, возвращающую ошибку. Клиенты могут использовать ко-
      манду STATUS для определения состояния соединения. В некото-
      рых реализациях протокол TCP может оповещать клиента, когда
      выходит на связь незаказанный сокет.
         Если было указано контрольное время, то в этом соединении
      его текущее значение, заданное клиентом, будет изменено.
         В простейших реализациях команда SEND не предает управле-
      ние обратно вызвавшей ее программе, пока не будет завершена
      передача или пока не будет превышено контрольное время. Од-
      нако, такой простой метод может приводить к блокировке (на-
      пример, когда обе стороны на концах соединения пытаются
      сперва выполнить команду SEND, а лишь потом - RECEIVE) и
      плохим эксплуатационным характеристикам. Поэтому такой под-
      ход не рекомендуется использовать. В более сложной реализа-
      ции возврат из функции SEND осуществляется незамедлительно,
      что позволяет процессу выполняться параллельно с вводом/вы-
      водом в компьютерную сеть. И даже более того - позволяет вы-
      полнять одновременно несколько команд SEND. Множественные
      команды SEND обрабатываются по принципу "первый пришел -
      первый обслужен", поэтому протокол TCP будет иметь очередь,
      которая не может быть обслужена мгновенно.
         Косвенным образом мы предположили асинхронность интерфей-
      са с клиентом, при которой команда SEND вызывает появление
      особого рода сигнала или псевдо-прерывания изобслуживающей
      программы TCP. Альтернатива состоит в немедленном возврате
      из команды. Например, команды SEND могут возвращать немед-
      ленно подтверждение от местной системы, даже если посланный
      сегмент не получил подтверждения от чужой программы TCP. Мы
      оптимистически относимся к возможному успеху этой операции.
      Если мы ошибаемся, то соединение в любом случае будет разор-
      вано по истечении контрольного времени. В реализациях прото-
      кола TCP такого типа (синхронных) будет все равно оставаться
      некоторые асинхронные сигналы, одноко они будут относиться к
      самому соединению, а не к конкретным сегментам или буферам.
         Чтобы процесс мог различать сообщения об ошибках и успеш-
      ное рапорты от различных команд SEND, может оказаться удоб-
      ным возвращать в ответ на запрос SEND адрес буфера наряду с
      кодированным ответом. Сигналы между клиентом и протоколом
      TCP обсуждаются ниже и определяют ту информацию, которую
      следует возвращать отправившему команду процессу.

Команда получения
   Формат
   RECEIVE (местное имя соединения, адрес буфера, счетчик байт) ->
   счетчик байт, флаг срочности, флаг проталкивания
      Данная команда размещает получаемую информацию в буфере,
   связанном с конкретным соединением. Если команде не предшеству-
   ет команда OPEN или если процесс, осуществляющий вызов, не
   уполномочен на использование данного соединения, то возвращает-
   ся ошибка.
      В простейшей реализации протокола управление не должно пере-
   даваться осуществившей вызов программе до тех пор, пока либо не
   будет заполнен буфер, либо не произойдет какая-либо ошибка. Од-
   нако данная схема в значительной мере подвержена блокировкам.
   Более сложная реализация могла бы позволить за раз выдвигать
   несколько команд RECEIVE. Эти запросы будут выполняться по мере
   поступления сегментов с данными. Такая стратегия позволяет уве-
   личить пропускную способность за счет применения более развитой
   схемы (возможно, асинхронной), а также оповещения программы о
   том, что получен сигнал проталкивания PUSH или заполнен буфер.
      Если получено достаточное количество данных, чтобы заполнить
   буфер до того, как получен сигнал проталкивания PUSH, то в от-
   вет на RECEIVE не будет установлен флаг PUSH. Буфер будет со-
   держать столько данных, насколько позволяет его емкость. Если
   сигнал PUSH обнаружен до того, как буфер заполнился, то буфер
   будет возвращен заполненным частично и с сигналом PUSH.
      Если обнаружены срочные данные, то сразу же по их прибытии
   клиент будет оповещен сигналом от программы протокола TCP. Кли-
   ент, получающий данные, должен по этому сигналу перейти в
   "срочный режим". Если флаг срочности URGENT установлен, то до-
   полнительные срочные данные останутся неполученными. Если флаг
   URGENT сброшен, то данный запрос на получение RECEIVE возвратит
   все срочные данные и клиент может освободиться от "срочного ре-
   жима". Заметим, что данные, следующие за указателем срочности
   (несрочные данные) не могут быть доставлены к клиенту в одном и
   том же буфере с предыдущими срочными данными, если сам клиент
   не определил четко границу.
      Чтобы проводить различие между несколькими сделанными коман-
   дами на получение RECEIVED и следить за заполнением буферов,
   код, возвращаемый клиенту сопровождается как указателем на бу-
   фер, так и количеством действительно полученных данных.
      Другие реализации команды RECEIVE могут сами выделять буфер
   для размещения получаемых данных или же программа протокола TCP
   может одновременно с клиентом пользоваться циклическим буфером.

Команда закрытия соединения
   Формат
   CLOSE (локальное имя соединения)
      Данная команда приводит к закрытию указанного соединения.
   Если соединение не открыто или отдавший команду процесс не
   уполномочен использовать данное соединение, то возвращается со-
   общение об ошибке. Предполагается, что закрытие соединения бу-
   дет медлительной операцией в том смысле, что оставшиеся команды
   посылки SEND будут еще некоторое время передавать данные (и да-
   же, в случае необходимости, делать это повторно), насколько это
   позволит управление потоком, и не будет выполнена заказанная
   работа. Таким образом, можно будет сделать несколько команд по-
   сылки SEND, а затем закрыть соединение командой CLOSE, будучи
   уверенным, что отправленные данные достигнут адресата. Очевид-
   но, что клиенты должны продолжать давать команды получения дан-
   ных с уже закрытых соединений, поскольку чужая программа будет
   еще пытаться переслать оставшиеся у нее данные. Итак, команду
   CLOSE следует интерпретировать как "у меня нет больше данных
   для пересылки", а не как "я больше не хочу ничего получать".
   Может случиться (если протокол на уровне клиента не продуман до
   конца), что сторона, закрывающая соединение, не сможет изба-
   виться от всех своих данных до истечения контрольного времени.
   В этом случае команда CLOSE транслируется в ABORT, и программа
   TCP отказывается от соединения.
      Клиент может дать команду CLOSE в любой момент по своему
   собственному усмотрению, а также в ответ на различные сообщения
   от протокола TCP (например, когда выполнено закрытие соединения
   с чужой стороны, превышено контрольное время передачи, адресат
   недоступен).
      Поскольку закрытие соединения требует общения с чужой про-
   граммой TCP, то соединения могут пребывать в закрытом состоянии
   короткое время. Попытки повторно открыть соединение до того,
   как программа TCP отреагирует на команду CLOSE, приведет к воз-
   врату на вызов сообщения об ошибке.
      Команда закрытия предполагает выполнение операции проталки-
   вания данных через соединение.

Команда определения статуса соединения
   Формат
   STATUS (местное имя соединения) -> информация о статусе
     Это команда клиента, зависящая от конкретной реализации. Она
   должна выполняться без опасных последствий для системы. Возвра-
   щаемая клиенту информация обычно получается из блока TCB, свя-
   занного с данным соединением, Данная команда возвращает блок
   данных с информацией о
   - местном сокете
   - чужом сокете
   - местном имени соединения
   - окне получения
   - окне отправления
   - статусе соединения
   - количестве буферов, ждущих подтверждения
   - количестве буферов, ожидающих получения данных
   - статусе срочности
   - приоритете
   - безопасности/закрытости
   - контрольном времени пересылки
      В зависимости от состояния соединения или от особенностей
   реализации протокола, часть указанной информации может быть не-
   доступна или не имеет смысла. Если процесс, осуществивший вы-
   зов, не имеет прав на использование данного соединения, то воз-
   вращается сообщение об ошибке. Такой подход не позволяет не
   имеющим полномочий процессам получать информацию о соединении.

Команда ликвидации соединения
   Формат
   ABORT (местное имя соединения)
      Выполнение данной команды приводит к ликвидации всех неза-
   конченных операций посылки и получения данных. Блок TCB ликви-
   дируется, а также должно быть послано специальное сообщение
   RESET программе TCP на другом конце соединения. В зависимости
   от реализации протокола, клиенты могут получать сообщение о
   ликвидации в ответ на каждый оставшийся невыполненным запрос о
   посылке или получении данных. Или же клиенты вместо этого могут
   просто получить подтверждение команды ABORT.

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

     Интерфейс программы TCP с протоколом более низкого уровня
   Программа протокола TCP для реальной посылки информации по се-
ти, а также для ее получения делает запросы к модулю протокола
нижнего уровня. Одним из примеров такой реализации является систе-
ма ARPA Internetwork, где модулем нижнего уровня является Internet
протокол (IP) [2].
   Если протоколом более низкого уровня является IP, то он в ка-
честве аргументов вызова запрашивает требуемый тип сервиса и время
жизни данных в сети. Программа протокола TCP использует следующие
значения для упомянутых параметров:
   Тип сервиса = приоритет: обычный, задержка: нормальная,
      пропускная способность: нормальная, надежность: нормальная,
      т.е. 00000000
   Время жизни = одна минута, или 00111100
   Заметим, что принято максимальное время жизни сегмента в две
минуты. Здесь мы явным образом определяем, что сегмент должен быть
ликвидирован, если он в течении одной минуты не достигает адресата
в системе Internet.
   Если ниже расположен протокол IP (или какой-либо другой прото-
кол с теми же функциями) и применяется процедура маршрутизации, то
интерфейс должен допускать передачу информации о маршруте. Это
особенно важно, поскольку адреса отправителя и получателя, учиты-
ваемые в контрольной сумме TCP протокола, будут соответствовать
действительному отправителю данных и самому последнему адресату.
Важно также сохранять обратный маршрут для ответов на запросы со-
стояния.
  Любой протокол нижнего уровня будет обязан предоставить адрес
отправителя, адрес получателя, поля протокола, некую процедуру
определения "длины TCP сообщения", необходимую как для сервистных
функций протокола IP, так и для проверки контрольной суммы в самом
протоколе TCP.

                       3.9 Обработка событий
   Обработка, описанная в данной главе, является лишь примером
одной из возможных реализаций протокола. Иные реализации могут
иметь несколько иные процедуры обработки, однако они должны отли-
чаться от описанных в данной главе лишь в деталях, но никак не по
существу.
   Деятельность программы протокола TCP можно рассматривать как
реагирование на события. Эти происходящие события можно разбивать
на три категории: запросы клиентов, прибытие сегментов, истечение
контрольного времени. Данная глава описывает деятельность в прото-
коле TCP в ответ на каждое их этих событий. Во многих случаях не-
обходимая обработка зависит от состояния соединения. События, ко-
торые могут произойти:
   Команды клиента
   - на открытие соединения
   - на посылку данных
   - на получение данных
   - на закрытие соединения
   - на ликвидацию соединения
   - на определение статуса соединения
   Получения сегментов
   Истечение контрольного времени
   - для действий клиента
   - для повторной посылки
   - в состоянии ожидания
   Модель интерфейса TCP и клиента состоит в том, что команды кли-
ента выполняются немедленно, а вероятный отложенный отчет предо-
ставляется через механизм событий или псевдопрерываний. В дальней-
шем описании понятие "сигнал" может обозначать некое основание для
посылки отложенного отчета.
   Сообщение об ошибках пердоставляется в виде текстовых строк.
Например, команды клиента, адресованные к несуществующим соедине-
ниям, получат сообщение "error: connection not open".
   Пожалуйста учтите, что в дальнейшем вся арифметика для номеров
очереди, номеров подтверждения, окон и т.д. осуществляется по мо-
дулю 2**32, что соответствует размеру множества номеров очередей.
Заметим также, что "=<" означает "меньше или равно" (по модулю
2**32).
   Чтобы постичь смысл обработки приходящих сегментов, естествен-
ным было бы представить, что они сперва проверяются на коррект-
ность номера очереди (т.е. что их информация попадает в диапазон
"окна получения" среди ожидаемых номеров очереди) и что они, в
общем случае, будут ставиться в очередь и подвергаться обработке
соответственно своим номерам.
   Если одни сегменты перекрываются с другими, ранее полученными
сегментами, то мы конструируем сегмент, содержащий лишь действи-
тельно новые данные, а затем соответствующим образом корректируем
поля заголовка.
   Заметим, что состояние программы протокола TCP остается при
обработке событий без изменений, если обратное не указано особо.

Запрос OPEN
   Состояние CLOSED (т.е. блок TCB отсутствует)
         Создать новый блок управления передачей (TCB) для хране-
      ния информации о состоянии соединения. Заполнить поля иден-
      тификатора местного сокета, чужого сокета, приоритета, за-
      крытости/безопасности, а также контрольного времени для кли-
      ента. Заметим, что некоторые параметры чужого сокета могут
      остаться неконкретизированными при пассивном открытии и со-
      ответствующие им поля должны быть заданы исходя из парамет-
      ров пришедшего SYN сигнала. Клиенту может быть предоставлена
      возможность проверять параметры безопасности и приоритета,
      если в ответ на такой запрос не будет получено сообщение
      "error: precedence not allowed" или "error: security/
      compartment not allowed". В случае пассивного открытия
      следует перейти в состояние LISTEN и вернуть управление дав-
      шему команду OPEN процессу. Если открытие является активным,
      а чужой сокет не конкретизирован, то вернуть сообщение
      "error: fireign socket unspecified". Если открытие является
      активным и указан чужой сокет, то послать сегмент с сигналом
      SYN. Выбирается начальный номер для очереди отправления.
      Посылаемый сегмент и сигналом SYN имеет форму
      <SEQ=ISS><CTL=SYN>. Установить переменную SND.UNA в ISS, а
      SND.NXT - в ISS+1. Перейти в состояние SYN-SENT. Вернуть
      управление процессу, вызвавшему рассматриваемую команду.
         Если сделавший запрос клиент не получил доступа к указан-
      ному в запросе сокету, то вернуть сообщение "error:
      connection illegal for this process". Если для создания но-
      вого соединения нет места в памяти компьютера, то вернуть
      сообщение "error: insufficient resources".
   Состояние LISTEN
         Если происходит активизация и указан чужой сокет, то сме-
      нить состояние соединения с пассивного на активный, выбрать
      ISS. Послать сегмент с сигналом SYN, занести в SND.UNA зна-
      чение ISS, а в SND.NXT - ISS+1. Перейти в SYN-SEND состо-
      яние. Данные, указанные в команде SEND, могут быть посланы в
      том же сегменте с сигналом SYN, или же могут быть помещены в
      очередь на передачу, которая может быть осуществлена после
      перехода в ESTABLISHED состояние. Если в команде сделан за-
      прос на применение бита срочности, то в результате ее выпол-
      нения должны быть посланы сегменты данных. Если в очереди
      заказов на пересылку нет места, то в результате будет полу-
      чен ответ "error: insufficient resources". Если чужой сокет
      не указан, то вернуть сообщение "error: foreign socket
      unspecified"
   Состояния
      SYN-SENT
      SYN-RECEIVED
      ESTABLISHED
      FIN-WAIT-1
      FIN-WAIT-2
      CLOSE-WAIT
      CLOSING
      LAST-ACK
      TIME-WAIT
      возвращают в ответ на команду открытия сообщение "error:
      connection already exist"

Запрос SEND
   Состояние CLOSED (например, нет блока TCB)
         Если клиент не имеет доступа к такому соединению, то вер-
      нуть сообщение "error: connection illegal for this process".
      В противном случае вернуть "error: connection does not
      exist".
   Состояние LISTEN
         Если указан чужой сокет, то сменить состояние соединения
      с пассивного на активный, выбрать номер ISS. Послать сегмент
      с сигналом SYN, установить SND.UNA в ISS, а SND.NXT - в
      ISS+1. Установить новое состояние SYN-SENT. Данные из вызова
      SEND могут быть посланы вместе с сигналом SYN, а могут быть
      помещены в очередь и отправлены уже после установления
      ESTABLISHED состояния. Если в команде дан запрос на примене-
      ние бита срочности, то он должен быть передан вместе с сег-
      ментом данных, возникающим при выполнении этой команды. Если
      в очереди нет места для запроса, то вернуть сообщение
      "error: insufficient resources". Если чужой сокет не указан,
      то вернуть "error: foreign socket unspecified".
  Состояние SYN-SENT
  Состояние SYN-RECEIVED
         Поместить данные в очередь с тем, чтобы отправить после
      установления ESTABLISHED состояния. Если в очереди нет мес-
      та, то вернуть сообщение "error: insufficient resources".
   Состояние ESTABLISHED
   Состояние CLOSE-WAIT
         Сегментировать буфер данных и переслать его с ответным
      подтверждением (значение подтверждения = RCV.NXT). Если для
      размещения этого буфера недостаточно места в памяти, то
      просто вернуть сообщение "error: insufficient resources".
         Если установлен флаг срочности, то занести в SND.UP зна-
      чение SND.NXT-1 и установить указатель срочности на уходящие
      сегменты.
   Состояния
      FIN-WAIT-1
      FIN-WAIT-2
      CLOSING
      LAST-ACK
      TIME-WAIT
         Вернуть сообщение "error: connection closing" и не выпол-
      нять запрос клиента.

Запрос RECEIVE
   Состояние CLOSED (например, отсутствует блок TCB)
         Если клиент не имеет доступа к такому соединению, вернуть
      сообщение "error: connection illegal for this process". В
      противном случае вернуть сообщение "error: connection does
      not exist".
   Состояния
      LISTEN
      SYN-SENT
      SYN-RECEIVED
         Поместить запрос в очередь на обслуживание после установ-
      ления ESTABISHED состояния. Если в очереди для этого нет
      места, вернуть сообщение "error: insufficient resources".
   Состояния
      ESTABLISHED
      FIN-WAIT-1
      FIN-WAIT-2
         Если в пришедших сегментах недостаточно данных для выпол-
      нения данного запроса, поместить последний в очередь на об-
      служивание. Если же в очереди нет места для размещения за-
      проса RECEIVE, вернуть сообщение "error: insufficient
      resources".
         Собрать данные из приходящих сегментов в буфере получе-
      ния, а затем передать их клиенту. Установить флаг
      "обнаружено проталкивание" (PUSH), если это имеет место.
         Если данным, передаваемым в настоящий момент клиенту,
      предшествовал RCV.UP, то оповестить клиента о присутствии
      срочных данных. Когда протокол TCP берет на себя ответствен-
      ность за получение клиентом данных, то это фактически озна-
      чает обмен информацией с отправителем в виде подтверждений.
      Формирование такого подтверждения обсуждается ниже при рас-
      смотрении алгоритма обработки приходящего сегмента.
   Состояние CLOSE-WAIT
         Поскольку партнер на другом конце соединения уже послал
      сигнал FIN, то команды RECEIVE должны получать данные, уже
      имеющиеся в системе, а не только те, которые уже переданы
      клиенту. Если в системе больше нет текста, ждущего своего
      запроса RECIVE, то передать клиенту сообщение "error
      connection closing". В противном случае использовать для
      удовлетворения запроса RECEIVE любую имеющуюся информацию.
   Состояния
      CLOSING
      LAST-ACK
      TIME-WAIT
         Вернуть сообщение "error connection closing".

Запрос CLOSE
   Состояние CLOSED (например, нет блока TCB)
         Если клиент не имеет доступа к такому соединению, вернуть
      сообщение "error: connection illegal for this process". В
      противном случае вернуть сообщение "error: connection does
      not exist".
   Состояние LISTEN
         Любые остающиеся неудовлетворенными запросы RECEIVE будут
      завершены с сообщением "error: closing". Стереть блок TCB,
      перейти в CLOSED состояние и вернуть управление клиенту.
   Состояние SYN-SENT
         Стереть блок TCB и вернуть сообщение "error closing" для
      любых еще остающихся в очередях запросов SEND или RECEIVE.
   Состояние SYN-RECEIVED
         Если не сделано каких-либо запросов SEND и нет данных,
      ожидающих отправки, то сформировать FIN сегмент и послать
      его, а затем перейти в FIN-WAIT-1 состояние. В противном
      случае поместить данные в очередь для рассмотрения после
      установления ESTABLISHED состояния.
   Состояние ESTABLISHED
         Поместить запрос в очередь в ожидании, когда все данные
      предшествующих команд будут сегментированы. Тогда сформиро-
      вать FIN сегмент и отправить его партнеру. В любом случае
      перейти в FIN-WAIT-1 состояние.
   Состояние FIN-WAIT-1
   Cостояние FIN-WAIT-2
         Строго говоря, такая ситуация является ошибочной и должна
      привести к получению клиентом сообщения "error: connection
      closing". Однако может быть приемлемым также ответ "Ok",
      пока не отправлен второй FIN (хотя первый FIN может быть
      отправлен повторно).
   Состояние CLOSE-WAIT
         Поместить этот запрос в очередь, пока все предшествующие
      запросы SEND не будут помещены в сегменты. Затем послать
      сегмент с сигналом FIN, перейти в CLOSING состояние.
   Состояния
      CLOSING
      LAST-ACK
      TIME-WAIT
         Возвратить сообщение "error: connection closing".

Запрос ABORT
   Состояние CLOSED (например, нет блока TCB)
         Если клиент не имеет доступа к такому соединению, вернуть
      сообщение "error: connection illegal for this process". В
      противном случае вернуть сообщение "error: connection does
      not exist".
   Состояние LISTEN
         Любые остающиеся запросы RECEIVED должны завершиться с
      возвратом сообщения "error: connection reset". Стереть блок
      TCB, перейти в состояние CLOSED, вернуть управление програм-
      ме клиента.
   Состояние SYN-SENT
         Все находящиеся в очереди запросы SEND и RECEIVE должны
      получить сообщение "connection reset", стереть блок TCB,
      перейти в состояние CLOSED, вернуть управление клиенту.
   Состояния
      SYN-RECEIVED
      ESTABLISHED
      FIN-WAIT-1
      FIN-WAIT-2
      CLOSE-WAIT
         Послать сегмент перезагрузки
      <SEQ=SND.NXT><CTL=RST>
      Все находящиеся в очереди запросы SEND и RECEIVED должны
      получить сообщение "connection reset". Все сегменты, находя-
      щиеся в очереди на передачу (за исключением только что сфор-
      мированного сигнала RST) и в очереди на повторную пересылку
      должны быть ликвидированы. Стереть блок TCB, перейти в
      CLOSED состояние, вернуть управление клиенту.
   Состояния
      CLOSING
      LAST-ACK
      TIME-WAIT
         Вернуть сообщение "ok" и стереть блок TCB, перейти в со-
      стояние CLOSED, вернуть управление клиенту.

Запрос STATUS
   Состояние CLOSED (например, нет блока TCB)
         Если клиент не имеет доступа у такому соединению, то воз-
      вратить сообщение "error: connection illegal for this
      process". В противном случае вернуть "error: connection does
      not exist".
   Состояние LISTEN
      Вернуть сообщение "state=LISTEN" и указатель на блок TCB.
   Состояние SYN-SENT
      Вернуть сообщение "state=SYN-SENT" и указатель на блок TCB.
   Состояние SYN-RECEIVED
      Вернуть сообщение "state=SYNRECEIVED" и указатель на болк
      TCB.
   Состояние ESTABLISHED
      Вернуть сообщение "state=ESTABLISHED" и указатель на блок
      TCB.
   Состояние FIN-WAIT-1
      Вернуть сообщение "state=FIN-WAIT-1" и указатель на блок
      TCB.
   Состояние FIN-WAIT-2
      Вернуть сообщение "state=FIN-WAIT-2" и указатель на блок
      TCB.
   Состояние CLOSE-WAIT
      Вернуть сообщение "state=CLOSE-WAIT" и указатель на блок
      TCB.
   Состояние CLOSING
      Вернуть сообщение "state=CLOSING" и указатель на блок TCB.
   Состояние LAST-ACK
      Вернуть сообщение "state=LAST-ACK" и указатель на блок TCB.
   Состояние TIME-WAIT
      Вернуть сообщение "state=TIME-WAIT" и указатель на блок TCB.

Приход сегментов
   Если состояние соединения CLOSED (например, нет блока TCB), то
      все данные из указанного сегмента будут выброшены. Сегмент,
      пришедший с сигналом RST, будет ликвидирован. Сегмент же, не
      содержащий сигнала RST, вызовет посылку сигнала RST в ответ.
      Подтверждение и номер очереди будут выбраны таким образом,
      чтобы сделать последовательность перезагрузки приемлемой для
      программы TCP, отправившей сегмент, который и вызвал такую
      реакцию.
         Если бит ACK сброшен, то используется номер очереди нуль:
      <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
      Если же ACK установлен, то
      <SEQ=SEG.ACK><CTL=RST>
      Вернуть управление прерванной программе.
   Если состояние соединения LISTEN, то
         Сперва проверить присутствие сигнала RST.
      Сигнал RST, пришедший вместе с сегментом, должен игнориро-
      ваться, а управление должно быть возвращено прерванной про-
      грамме.
         Во-вторых, проверить на присутствие ACK.
      Любое подтверждение является ошибкой, если оно пришло на
      конец соединения, все еще находящийся в состоянии LISTEN. В
      ответ на любой сегмент, пришедший с ACK, должен быть сформи-
      рован приемлемый сегмент с сигналом перезагрузки. Сигнал RST
      должен быть сформирован следующим образом:
      <SEQ=SEG.ACK><CTL=RST>
      Вернуть управление прерванной программе.
         В-третьих, проверить на присутствие сигнала SYN
      Если установлен бит SYN, то проверить безопасность. Если
      значение параметра безопасность/закрытость в пришедшем сег-
      менте не совпадает в точности со значением безопасность/
      закрытость в блоке TCB, то послать сигнал перезагрузки и
      вернуть управление прерванной программе:
      <SEQ=SEG.ACK><CTL=RST>
      Если значение SEQ.PRC меньше, чем TCB.PRC, то перейти к сле-
      дующему пункту. Установить RCV.NXT в SEG.SEQ+1, IRS устано-
      вить в SEG.SEQ, а остальные тексты и функции управления по-
      местить в очередь для последующей обработки. Выбрать значе-
      ние для ISS и отправить сегмент подтверждения в форме
      <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
      Переменную SND.NXT установить в ISS+1, а SND.UNA - в ISS.
      Установить для соединения новое состояние - SYN-RECEIVED.
      Заметим, что в состоянии SYN-RECEIVED будут обрабатываться
      все приходящие данные и команды управления (вместе с SYN),
      но уже не будет как прежде осуществляться обработка сигналов
      SYN и ACK. Если состояние LISTEN не сформулировано полностью
      (например, не указан исчерпывающе чужой сокет, то именно в
      этот момент должны быть доопределены поля блока TCB, остав-
      шиеся незаполненными.
         В-четвертых, искать в пришедшем сегменте остальные коман-
      ды управления, а также собственно данные. Любые сегменты с
      иными командами управления или заполненные текстом (но не
      содержащие сигнала SYN) должны получить от местной программы
      TCP подтверждение, и, таким образом, будут отброшены во вре-
      мя работы с подтверждением. Приходящий сегмент с сигналом
      RST не может быть правильным, поскольку он не может являться
      ответом на информацию, переданную данной реализацией соеди-
      нения. Так что Вы вряд ли получите это сигнал, но если это
      произойдет, выбросьте пришедший сегмент и верните управление
      прерванной программе.

   Если состояние соединения SYN-SENT
         Во-первых, проверить бит ACK Если бит ACK выставлен, то
         В случае, если SEG.ACK = <ISS или SEG.ACK > SND.NXT,
            послать сигнал перезагрузки
            <SEQ=SEG.ACK><CTL=RST>
            (Если не выставлен бит RST. Если он все же выставлен,
            то, ничего не делая выкинуть пришедший сегмент и вер-
            нуть управление прерванной программе.) Ликвидировать
            сегмент, вернуть управление.
         Если SND.UNA =< SEG.ACK =< SND.NXT, то полученное в сег-
            менте подтверждение становится приемлемым.
         Во-вторых, проверить бит RST.
            В случае,если бит RST выставлен
               Если ожидалось получение сегмента с подтверждением,
               то дать клиету объявление "error: connection
               reset", вернуть сегмент, перейти в состояние
               CLOSED, убрать блок TCB, и, наконец, вернуть управ-
               ление прерванной программе. В противном случае (нет
               подтверждения) ликвидировать сегмент и вернуть
               управление.
         В-третьих, проверить уровни безопасности и приоритета
            Если в пришедшем сегменте значения полей безопасность/
               закрытость не совпадают в точности со значениями в
               блоке TCB, то послать сигнал перезагрузки, а точнее
               если имеется ACK, то послать
               <SEQ=SEG.ACK><CTL=RST>
               в противном случае послать
               <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
            Если имеется значение ACK, то
               приоритет в пришедшем сегменте должен совпадать с
               приоритетом, указанным в блоке TCB. Если это не
               так, то послать сигнал перезагрузки
               <SEQ=SEG.ACK><CTL=RST>
            Если же ACK отсутствует, то выполнить следующее
               Если в сегмете указан приоритет выше, чем приоритет
               в блоке TCB, то, если это позволяют клиент и систе-
               ма, увеличить значение приоритета в блоке TCB до
               значения, указанного в сегменте. Если же увеличи-
               вать приоритет не разрешается, послать сигнал пере-
               загрузки:
               <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
               Если в сегменте указан приоритет, меньший, чем в
               блоке TCB, то просто перейти к следующему пункту
               анализа.
         В-четвертых, проверить установку бита SYN. Данный этап
     должен осуществляться только если бит ACK не вызывает про-
     блем, или если он не установлен, сегмент также не содержит
     сигнала RST.
     Если бит SYN установлен и параметры безопасности/ закрытости
     приоритета являются приемлемыми, то в переменную SEG.NXT за-
     писать значение SEG.SEQ+1, а IRS установить равным SEG.SEQ.
     SND.UNA должно быть повышено до SEG.ACK (если имеется ACK), а
     любые сегметы в очереди на повторную посылку, получившие та-
     ким образом подтверждение, должны быть удалены.
     Если SND.UNA > ISS (наш сигнал SYN получит подтверждение), то
     установить для соединения состояние ECTABLISHED и сформиро-
     вать ACK сегмент
     <SEQ-SND.NXT><ACK=RCV.NXT><CTL=ACK>
     и отправить его. В этот сегмент могут быть включены данные
     или команды из очереди на отправление. Если в пришедшем сег-
     менте есть иные команды или даже некий текст в поле данных,
     то продолжить обработку далее, начиная с шестого этапа ниже,
     где осуществляется проверка бита URG. Если таких команд и
     данных нет, передать управление прерванной программе.
     Если же бит SYN не установлен, то перейти в состояние
     SYN-RECEIVED, сформировать сегмент SYN, ACK:
     <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
     и послать его. Если в пришедшем сегменте имеются команды или
     текст в поле данных, то поместить их в очередь для обработки
     после установления ESTABLISH состояния. Вернуть управление
     прерванной программе.
        В-пятых, если установлены биты SYN или RST, то выкинуть
     пришедший сегмент и вернуть управление прерванной программе.
Если во время прихода сегмента соединение находилось в состоянии,
не описанном выше, то
   Во-первых, проверить номер очереди
      Состояния
      SYN-RECEIVED
         ESTABLISHED
         FIN-WAIT-1
         FIN-WAIT-2
         CLOSE-WAIT
         CLOSING
         LAST-ACK
         TIME-WAIT
         Сегменты обрабатываются по очереди. По получении сегмента
     сперва осуществляется тест для удаления старых дубликатов, но
     дальнейшая обработка осуществляется в порядке номеров
     SEG.SEQ. Если содержимое сегмента перекрывает границу между
     старой и пока новой информацией, то должны обрабатываться
     только новые данные.
      Тест на приемлемость приходящего сегмента рассматривает че-
      тыре варианта:
      Длина    Окно         Текст
      сегмента получения
         0       0       SEG.SEQ = RCV.NXT
         0      >0       RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
        >0       0       сегмент неприемлем
        >0      >0       RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
               или RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
      Если RCV.WND нулевой, никакие сегменты не будут приемлимы,
      однако должна быть специально оговорена приемлемость получе-
      ния правильных сигналов ACK, URG и RST.
         Если приходящий сегмент неприемлем, то в ответ послать
      его подтверждение
      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
      если бит RST не установлен (если он все же выставлен, то
      выкинуть пришедший сегмент и вернуть управление прерванной
      программе. )
      После посылки подтверждения ликвидировать непринятый сегмент
      и вернуть управление прерванной программе.
         В дальнейшем рекомендации строятся на предположении, что
      пришедший сегмент является идеализированным и начинается с
      RSV.NXT, не выходящим за окно. Реальные же сегменты можно
      подгонять под такое предположение, отбрасывая любые их час-
      ти, выходящие за пределы окна (включая даже сигналы SYN и
      FIN), и осуществляяя дальнейшую их обработку только если
      сегмент после этого начинается с номера RCV.NXT. Сегменты с
      большими номерами в очереди сохраняются для обработки в
      дальнейшем.
   Во-вторых, проверить бит RST.
      Состояние SYN-RECEIVED
         Если бит RST установлен, то выполнить следующие действия:
            Если данное соединение было инициировано командой пас-
         сивного открытия - OPEN (например, был осуществлен пере-
         ход из состояния LISTEN), то возвратить данное соединение
         в состояние LISTEN, а управление вернуть прерванной про-
         грамме. Нет нужды информировать обэтом пользователя. Если
         данное соединение инициируется командой активного откры-
         тия OEPN (например, был переход из состояние SYN-SENT),
         то происходит отказ от этого соединения, а клиенту посы-
         лается сообщение "connection refused". В любом случае
         должны быть удалены все сегменты из очереди на повторную
         посылку. Кроме того, в случае активного открытия перейти
         в состояние CLOSED, удалить блок TCB и вернуть управление
         прерванной программе.
      Состояния
         ESTABLISHED
         FIN-WAIT-1
         FIN-WAIT-2
         CLOSE-WAIT
            Если установлен бит RST, то все ждущие обработки за-
         просы RECEIVE и SEND должны получить ответ "reset".
         Убрать все сегменты из очередей. Клиенты должны получить
         необязательное сообщение общего назначения "connection
         reset". Перейти в состояние CLOSED, стереть блок TCB и
         вернуть управление прерванной программе.
      Состояния
         CLOSING
         LAST-ACK
         TIME-WAIT
            Если выставлен бит RST, то перейти в состояние CLOSED,
         удалить блок TCB и вернуть управление прерванной програм-
         ме.
   В-третьих, проверить значение безопасности и приоритета у
      пришедшего сегмента
      Состояние SYN-RECIEVED
            Если безопасность/закрытость и приоритет в пришедшем
         сегменте не совпадают с безопасностью/закрытостью и прио-
         ритетом, указанными в блоке TCB, то послать сигнал пере-
         загрузки и возвратить управление прерванной программе.
      Состояние ESTABLISHED
            Если безопасность/закрытость и приоритет в пришедшем
         сегменте не совпадают в точности с безопасностью/ закры-
         тостью и приоритетом, указанными в блоке TCB, то послать
         сигнал перезагрузки, все еще остающиеся необслуженными
         запросы RECEIVED и SEND должны получить ответ "reset".
         Все сегменты из очередей должны быть удалены. Клиенты
         должны тоже получить необязательный общий сигнал
         "connection reset". Перейти в состояние CLOSED, удалить
         блок TCB и вернуть управление прерванной программе.
      Заметим, что данная проверка ставится после проверки номера
   в очереди для того, чтобы предотвратить разрыв данного соедине-
   ния, инициированный получением сегмента, оставшегося от прежне-
   го соединения с иными безопасностью и приоритетом, существовав-
   шего некогда между данными портами.
   В-четвертых, проверить бит SYN
      Состояния
         SYN-RECEIVED
         ESTABLISHED
         FIN-WAIT-1
         FIN-WAIT-2
         CLOSE-WAIT
         CLOSING
         LAST-ACK
         TIME-WAIT
            Если SYN находится в пределах окна, то послать сигнал
         перезагрузки. Любые ждущие обработки команды RECEIVE и
         SEND должны получить ответ "reset", убрать из очередей
         все сегменты, а клиент должен получить необязательное
         общее сообщение "connection reset". Перейти в состояние
         CLOSED, убрать блок TCB, вернуть управление прерванной
         программе.
            Если SYN находится за пределами окна, то до данного
         пункта дело не должно дойти. Еще на первом этапе (провер-
         ка номера очереди) должно было быть послано подтвержде-
         ние.
   В-пятых, проверить поле ACK
      Если бит ACK не установлен, то сегмент ликвидировать, а
         управление передать прерванной программе.
      Если бит ACK установлен
         Состояние SYN-RECEIVED.
            Если SND.UNA =< SEG.ACK =< SND.NXT, то перейти в со-
            стояние ESTABLISHED и продолжить обработку.
            Если же подтверждение в сегменте оказалось неприемли-
            мым, то сформировать сегмент с сигналом перезагрузки
            <SEQ=SEG.ACK><CTL=RST>
            и послать его.
         Состояние ESTABLISHED
            Если SND.UNA < SEG.ACK =< SND.NXT, то установить в
            SND.UNA значение из SEG.ACK. Любые сегменты из очереди
            на повторную посылку, получившие при этом подтвержде-
            ние, удаляются. Клиенты должны получить положительные
            отзывы на буферы, которые были посланы командой SEND,
            а ныне получили полное подтверждение (например, коман-
            да послать буфер с данными должна завершиться сообще-
            нием "ok"). Если подтверждение является дубликатом
            (SEG.ACK < SND.UNA), то его можно игнорировать. Если
            сообщение ACK подтверждает что-либо, еще не отправлен-
            ное (SEG.ACK > SND.NXT), то послать ACK, ликвидировать
            сегмент и вернуть управление прерванной программе.
               Если SND.UNA < SEG.ACK =< SND.NXT, то следует обно-
            вить окно для посылки. Если (SND.WL1 < SEG.SEQ или
            (SND.WL1 = SEG.SEQ и SND.WL2 =< SEG.ACK)), то устано-
            вить SND.WND согласно значению SEG.WND, SND.WL1 - в
            SEG.SEQ, SND.WL2 - в SEG.ACK.
               Заметим, что в SND.WND записано смещение относи-
            тельно SND.UNA, xnj d SND.WL1 записан номер очереди
            для последнего сегмента, используемого для обновления
            SND.WND, а также, что в SND.WL2 записан номер под-
            тверждения из последнего сегмента, используемого для
            обновления SND.WND. При этом проверка охраняет от ис-
            пользования устаревших сегментов для обновления окна.
         Состояние FIN-WAIT-1
               Все так же как при обработки в случае состояния
            ESTABLISHED, но если наш сигнал FIN теперь получил
            подтверждение, то перейти к FIN-WAIT-2 и продолжить
            обработку в таком состоянии.
         Состояние FIN-WAIT-2
               Все так же как при обработке для случая состояния
            ESTABLISHED, но если очередь повторной посылки пуста,
            то команда клиента на закрытие соединения CLOSE может
            получить подтверждение ("ok"), но при этом не удаляет
            блока TCB.
         Состояние CLOSE-WAIT
               Делается та же обработка, что была для случая со-
            стояния ESTABLISHED.
         Состояние CLOSING
               Все так же, как при обработке в случае состояния
            ESTABLISHED, но если ACK в пришедшем сегменте подтвер-
            ждает наш сигнал FIN, то перейти в состояние TIME-
            WAIT. В противном случае сегмент игнорируется.
         Состояние LAST-ACK
               Единственная вещь, которая может произойти в этом
            состоянии - получение подтверждения на сигнал FIN.
            Если наш сигнал FIN не был подтвержден, то удалить
            блок TCB, перейти в состояние CLOSED и вернуть управ-
            ление прерванной программе.
         Состояние TIME-WAIT
              Единственная вещь, которая может произойти в этом
            состоянии - это повторная передача чужого сигнала FIN.
            Подтверждить сигнал и повторно стартовать по истечении
            контрольного времени 2MSL.
   В-шестых, проверить бит URG
      Состояния
         ESTABLISHED
         FIN-WAIT-1
         FIN-WAIT-2
            Если бит URG установлен, то в RCV.UP занести
         max(RCV.UP, SEG.UP), а также дать знать клиенту, что на
         другом конце соединения имеются срочные данные, если
         срочный указатель (RCV.UP) стоит перед данными. Если же
         клиент уже был оповещен о данной цепочке срочных данных
         (или если все еще находится в "режиме срочности"), не
         следует ему напоминать об этом снова.
      Состояния
         CLOSE-WAIT
         CLOSING
         LAST-ACK
         TIME-WAIT
            Такого не должно произойти, поскольку был получен си-
         гнал FIN с другого конца соединения. Игнорировать бит
         URG.
   В-седьмых, обработать данные их сегмента
      Состояния
         ESTABLISHED
         FIN-WAIT-1
         FIN-WAIT-2
            Раз мы оказались в состоянии ESTABLISHED, то стало
         возможным принимать текст для размещения в буферах полу-
         чения, указанных клиентом. Текст из сегментов может пере-
         носиться в буферы до тех пор, пока либо не наполнится
         соответствующий буфер, либо не станет пустым сегмент.
         Если сегмент пуст и несет флаг  проталкивания PUSH, то
         при возврате буфера оповестить клиента о том, что был
         получен сигнал PUSH.
            Когда протокол TCP берет на себя ответственность за
         получение клиентом данных, то он должен также давать под-
         тверждение факта получения этих данных.
            Как только программа протокола TCP  принимает на себя
         управление потоком данных, она ставит значение RCV.NXT
         перед блоком принимаемых данных, а RCV.WND устанавливает
         соответственно емкости буфера в данный момент. В общем
         случае значения RCV.NXT и RCV.WND не должны корректиро-
         ваться в меньшую сторону.
            Отметьте, пожалуйста, что управление окном базируется
         на предположениях, указанных в главе 3.7.
            Послать подтверждение в виде
         <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
         Данное подтверждение должно быть добавлено к уходящему на
         другой конец соединения сегменту и, по возможности, без
         излишних задержек.
      Состояния
         CLOSE-WAIT
         CLOSING
         LAST-ACK
         TIME-WAIT
            Такого не должно случаться, поскольку был получен си-
         гнал FIN с другого конца соединения. Игнорировать текст в
         сегменте.
   В-восьмых, проверить бит FIN
         Не обрабатывать сигнала FIN, если состояние CLOSED,
      LISTEN или SYN-SENT, поскольку нет возможности проверить
      SEG.SEQ, выкинуть пришедший сегмент и возвратить управление
      прерванной программе.
         Если бит FIN установлен, то дать клиенту сигнал
      "connection closing", с тем же сообщением завершить все жду-
      щие решения запросы RECEIVED, установить RCV.NXT перед мес-
      том в очереди сигнала FIN, послать для последнего подтверж-
      дение. Заметим, что сигнал FIN подразумевает проталкивание
      (PUSH) текстов во всех сегментах, еще не полученных клиен-
      том.
      Состояния
         SYN-RECEIVED
         ESTABLISHED
            Перейти в состояние CLOSE-WAIT
      Состояние FIN-WAIT-1
            Если наш сигнал FIN получил подтверждение (возможно в
         этом же сегменте), то перейти в состояние TIME-WAIT, за-
         пустить контрольный таймер, отключить все иные таймеры.
         Если подтверждения не было, перейти в состояние CLOSING.
      Состояние FIN-WAIT-2
            Перейти в состояние TIME-WAIT. Запустить контрольный
         таймер, отключить все контрольные таймеры.
      Состояние CLOSE-WAIT
         Остаться в состоянии CLOSE-WAIT
      Состояние CLOSING
         Остаться в состоянии CLOSING
      Состояние LAST-ACK
         Остаться в состоянии LAST-ACK
      Состояние TIME-WAIT
         Остаться в состоянии TIME-WAIT. По истечении контрольного
         времени 2MSL стартовать повторно.
      Вернуть управление прерванной программе.

Истечение контрольного времени для клиента
      Если истекло контрольного время, то в каком бы состоянии не
   находилась программа, убрать все очереди, дать клиенту общий
   сигнал "error: connection aborted due to user timeout", такой
   же сигнал дать всем ждущим обработки запросам, ликвидировать
   блок TCB, перейти в состояние CLOSED, вернуть управление прер-
   ванной программе.
Истечение контрольного времени для повторной посылки
      В каком бы состоянии не находилась программа, если для сег-
   мента в очереди на повторную посылку истекло контрольное время,
   послать этот сегмент еще раз, но уже вне очереди, произвести
   вновь инициализацию таймера повторной посылки, вернуть управле-
   ние прерванной программе.
Истечение контрольного времени для состояния TIME-WAIT
      Если истекло контрольное время для состояния TIME-WAIT, то
   ликвидировать соединение и блок TCB, перейти в состояние
   CLOSED, вернуть управление прерванной программе.

                              Словарь
1822
   BBN Report 1822, "The Specification of the Interconnection of a
   Host and an IMP". Спецификация интерфейса между хост-компьюте-
   ром и сетью ARPANET.
ACK
   Контрольный бит (подтверждения), не занимающий какого-либо мес-
   та в очереди. Бит информирует о том, что поле подтверждения в
   данном сегменте определяет номер очереди, который хочет полу-
   чить программа протокола TCP, пославшая данный сегмент. Это
   означает подтверждение факта получения всех предшествующих сег-
   ментов в очереди.
ARPANET сообщение
   Единица посылки между хост-компьютером и IMP в сети ARPANET.
   Максимальный размер такой единицы около 1012 октетов (8096
   бит).
ARPANET пакет
   Единица посылки между разными IMP внутри сети ARPANET. Макси-
   мальный размер такой единицы около 126 октетов (1008 бит).
Соединение
   Логический путь для коммуникаций, определяемый парой сокетов.
Датаграмма
   Сообщение, посылаемое через компьютерную коммуникационную си-
   стему с коммуникацией пакетов.
Адрес получателя
   Адрес получателя - это обычно идентификаторы сети и хост-ком-
   пьютера
FIN
   Контрольный бит (конечный), занимающий одно место в очереди и
   указывающий на то, что программа протокола TCP не будет более
   посылать данные или какие-либо команды, под которые следует в
   очереди отводить место.
Фрагмент
   Часть логической единицы данных. В частности фрагмент Internet
   являются частью Internet датаграммы.
FTP
   Протокол передачи файлов
Заголовок
   Контрольная информация в начале сообщения, сегмента, фрагмента,
   пакета или блока данных
хост-компьютер
   Просто компьютер. В частности, он является отправителем и полу-
   чателем сообщений с точки зрения коммуникационной сети.
Идентификация
   Поле Internet протокола. Значение этого поля назначает отправи-
   тель для идентификации с тем, чтобы осуществлять сборку фраг-
   ментов датаграммы.
IMP
   Процессор интерфейсных сообщений, переключатель пакетов в сети
   APRANET.
Internet адрес
   Адрес отправителя или получателя на уровне хоста
Internet датаграмма
   Блок данных, передаваемый между модулем протокола Internet и
   программой вышестоящего протокола, снабженное Internet заголов-
   ком.
Internet фрагменты
   Часть данных из Internet датаграммы, которая обзавелась соб-
   ственным Internet заголовком.
IP
   протокол Internet
IRS
   Первоначальный номер в очереди получения. Первый номер очереди,
   который использует программа протокола TCP при посылке данных
   через соединение.
ISN
   Первоначальный номер очереди. Первый номер, используемый соеди-
   нением (либо ISS либо IRS). Определяется процедурой выбора,
   использующей таймер.
ISS
   Первоначальный номер в очереди посылки. Первый номер очереди,
   используемый программой протокола TCP при посылке данных через
   соединение.
leader
   Некая контрольная информация в начале сообщения или блока дан-
   ных. В частности, в сети ARPANET контрольная информация о
   ARPANET сообщении записана в формате хост-IMP интерфейса.
Остающаяся очередь
   Это следующий номер в очереди, который должен быть подтвержден
   программой TCP, получающей данные (или иначе - наименьший номер
   в очереди, еще не получивший в данный момент своего подтвержде-
   ния). Иногда на него ссылаются как на левый край окна посылки.
Местный пакет
   Блок данных, передаваемый в местной сети
Модуль
   Реализация, обычно программая, какого-либо протокола или иной
   процедуры.
MSL
   Максимальное время жизни сегмента. Время, в течении которого
   TCP сегмент может существовать в системе объединенных сетей.
   Примерно оценивается в 2 минуты.
Октет
   Байт, состоящий из восьми битов
Опции
   Поле опций может содержать несколько опций, каждая опция может
   иметь длину в несколько октетов. В основном, опции используются
   для тестирования различных ситуаций. Например, опции могут нес-
   ти временной штамп. Поля с опциями могут иметь оба протокола
   Internet и TCP.
Пакет
   Пакет данных, имеющий заголовок, который в свою очередь может
   быть логически завершенным, а может и не быть. Чаще это означа-
   ет физическую упаковку данных, нежели логическую.
Порт
   Часть сокета, указывающая логический канал ввода или вывода для
   процесса, имеющего дело с данными.
Процесс
   Некая использующаяся программа. Отправитель или получатель дан-
   ных с точки зрения протокола TCP или иных фрагментов уровня
   хост-хост.
PUSH
   Контрольный бит, который не требует места в очереди и указывает
   на то, что данный сегмент содержит данные, которые следует
   "протолкнуть" к клиенту-адресату.
RCV.NXT
   Следующий номер в очереди получения
RCV.UP
   Срочный указатель для получения
RCV.WND
   Окно получения
Следующий номер в очереди получения
   Это следующий номер в очереди, который хочет получить местная
   программа протокола TCP
Окно получения
   Это понятие характеризует номера в очереди, которые должна по-
   лучить местная программа протокола TCP. Таким образом, местная
   программа TCP считает, что сегменты, попадающие в диапазон от
   RCV.NXT до RCV.NXT+RCV.WND-1, несут данные и команды управле-
   ния, которые следует принимать во внимание. Сегменты, чьи номе-
   ра в очереди ни коим образом не попадают в этот диапазон, вос-
   принимаются как дубликаты и ликвидируются.
RST
   Контрольный бит (бит перезагрузки), который не занимает места в
   очереди и указывает, что получатель этого бита должен ликвиди-
   ровать соединение без каких-либо дополнительных действий. Полу-
   чатель может, основываясь на анализе номера очереди и поля под-
   тверждения в сегменте, принесшем данный сегмент, решить, следу-
   ет ли выполнять операцию перезагрузки или же следует проигнори-
   ровать эту команду. Ни в коем случае получатель сегмента с би-
   том RST не должен давать в ответ ту же команду RST.
RTP
   Протокол реального времени. Протокол для передачи критической
   информации между хост-компьютерами.
SEG.ACK
   Подтверждение сегмента
SEG.LEN
   Длина сегмента
SEG.PRC
   Значение приоритета в сегменте
SEG.SEQ
   Номер очереди для сегмента
SEG.UP
   Поле срочного указателя для сегмента
SEG.WND
   Поле окна в сегменте
Сегмент
   Логический блок данных. В частности, сегмент TCP является бло-
   ком данных, который передается между парой TCP модулей.
Подтверждение сегмента
   Номер для очереди в поле подтверждения в пришедшем сегменте
Длина сегмента
   Место в очереди, которое занимают данные этого сегмента (с уче-
   том также всех команд, под которые тоже отводится место в оче-
   реди).
Номер сегмента в очереди
   Значение в поле номера у пришедшего сегмента
Номер в очереди отправления
   Следующий номер очереди для местной программы протокола TCP,
   отправляющей данные и использующей эти номера для управления
   соединением. Первоначальный номер очереди (ISN) выбирается про-
   цедурой инициализации, а затем увеличивается на единицу с пере-
   дачей по сети каждого октета данных или некоторой команды.
Окно посылки
   Окно представляет собой набор номеров из очереди, которые жела-
   ет получить чужая программа протокола TCP. Информация о грани-
   цах этого окна берется из сегментов, пришедших от чужой про-
   граммы TCP, получающей данные. Программе протокола TCP дозволя-
   ется посылать данные с номерами от SND.NXT до SND.UNA+SND.WND-1
   (конечно, это подразумевает повторную посылку тех данных, чьи
   номера лежат между SND.UNA и SND.NXT).
SND.NXT
   Очередь на посылку
SND.UNA
   Очередь еще не посланных данных
SND.UP
   Срочный указатель в очереди на посылку
SND.WL1
   Номер очереди сегмента в последнем обновленном окне
SND.WL2
   Номер подтверждения сегмента в последнем обновленном окне
SND.WND
   Окно посылки
Сокет
   Адрес, который особым образом включает в себя идентификатор
   порта. А именно, он включает связь Internet адреса с TCP портом
Адрес отправителя
   Адрес отправления, обычно состоящий из идентификаторов сети и
   хост-компьютера.
SYN
   Контрльный бит в приходящем сегменте, который занимает одно
   место в очереди и используется для инициализации соединения,
   для указания, где начинается отсчет номеров очереди.
TCB
   Контрольный блок для передачи, некая структура данных, где за-
   писан статус соединения.
TCB.PRC
   Приоритет данного соединения
TCP
   Протокол управления пересылкой, протокол для надежной передачи
   информации между хост-компьютерами в системе объединенных се-
   тей.
TOS
   Тип сервиса, поле заголовка в Internet протоколе
Тип сервиса
   Поле заголовка в Internet протоколе, которое определяет тип
   сервиса для данного фрагмента в стандарте Internet.
URG
   Контрольный бит (бит срочности), который не требует места в
   очереди. Этот бит требует, чтобы клиенту был послан приказ ис-
   пользовать ускоренную обработку до тех пор, пока имеются дан-
   ные, чьи номера в очереди меньше, чем указано в срочном указа-
   теле.
Срочный указатель
   Срочный указатель имеет значение лишь если установлен бит URG.
   В поле срочного указателя определается значение, которое указы-
   вает на некий октет данных,. Последний был связан с запросом
   клиента на срочную пересылку

                              Ссылки
[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network
    Intercommunication", IEEE Transactions on Communications,
    Vol. COM-22, No. 5, pp 637-648, May 1974.
[2] Postel, J, (ed.) "Internet Protocol - DARPA Internet Program
    Protocol Specification", RFC 791, USC/Information Sciences
    Institute, September 1981.
[3] Dalal, Y. and C.Sunshine, "Connection Management in Transport
    Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473,
    December 1978.
[4] Posterl, J, "Assigned Numbers", RFC 790, USC/Information
    Sciences Institute, September 1981.
Содержание


Д. Комер "Межсетевой обмен с помощью TCP/IP". Предисловие

Предисловие

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

Хотя эта книга и написана специально о связке протоколов TCP/IP, она также является хорошей книгой для изучения протоколов взаимодействия компьютеров вообще. Принципы архитектуры, уровни, мультиплексирование, инкапсуляция, адресация и отображение адресов, маршрутизация и именование аналогичны для любой связки протоколов, хотя, конечно, и отличаются в деталях(Смотри глав 3, 10, 18, 20, и 26).

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

Так как прикладные процессы - это активные элементы, использующие взаимодействие , обеспечиваемое протоколами, то TCP/IP - это механизм "межпроцессного взаимодействия"(IPC). В то время как проводятся эксперименты с целью организации межпроцессного взаимодействия образом, похожим на тот, который применяется в операционных системах, на основе IP, главное внимание в этой книге сосредоточено на более традиционных приложениях, которые используют дейтаграммы UDP или логические соединения TCP для организации IPC(МПВ)(Смотри главы 11, 12, 18, 20 и 22-25). Обычно в операционных системах существует набор функций, обеспечиваемых операционной системой для прикладных процессов. Этот интерфейс системных вызовов обычно включает вызовы для открытия, чтения, записи и закрытия файлов помимо всего прочего. Во многих системах существуют аналогичные системные вызовы для функций МПВ, включая сетевое взаимодействие. Как пример такого интерфейса, Дуглас Комер приводит обзор интерфейса портов(socket)(Смотри главу 21).

Одной из главных идей, лежащих в основе TCP/IP и вынесенной в название книги, является межсетевой обмен. Мощь коммуникационной системы напрямую связана с числом сущностей в этой системе. Телефонная сеть очень полезна, так как (почти) все телефоны находятся в одной сети(по крайней мере, так кажется пользователям). Системы компьютерного взаимодействия и сети в настоящее время отделены друг от друга и фрагментированы. Цель взаимного соединения и взаимодействия для создания одной мощной компьютерной коммуникационной сети являлась основной при проектировании TCP/IP. Самым главным для межсетевого обмена являются адресация(Смотри главы 4, 5, 6 и 17) и универсальный протокол - Межсетевой протокол(Internet Protocol)(Смотри главы 7, 8 и 9). Конечно, индивидуальные сети имеют свои собственные протоколы, которые используются для того чтобы нести дейтаграммы IP(Смотри главу 2), и должно существовать отображение между адресами индивидуальных сетей и адресами IP(Смотри главы 5, 6 и 19).

Для организации межсетевого обмена индивидуальные сети должны быть соединены. Соединяющие их устройства называются шлюзами(gateway) . Более того, эти шлюзы должны иметь некоторые процедуры для передачи данных от одной сети к следующей. Данные передаются в форме дейтаграмм IP и назначение указывается с помощью адреса IP, но шлюзы должны принимать решение о направлении передачи дейтаграммы на основе адреса IP и своих знаний о связности сетей, составляющих Интернет. Процедуры для распространения информации о текущей связности называются алгоритмами маршрутизации и являются в настоящее время предметом многих исследований(Смотри главы 13, 14, 15, 16 и 17).

Как и все коммуникационные системы, связка протоколов TCP/IP - это незавершенная система. Она развивается, отражая меняющиеся требования и новые возможности. Поэтому эта книга является по существу, представлением о TCP/IP в начале 1990 года. И, как указывает Дуглас Комер, существует много проблем(смотри главу 27). Одной из быстро меняющихся областей является сетевое управление(Смотри главу 25).

Большинство глав заканчиваются небольшим количеством ссылок на материал для дальнейшего изучения. Большинство из них - это документы серии RFC. Эта серия является результатом политики общедоступности идей и спецификаций протоколов , разработанных исследователями и разработчиками сообщества TCP/IP. Эта доступность базовой и детальной информации об этих протоколах, и доступность их первых реализаций явилась основной причиной их нынешнего широкого использования. Передача в общее пользование документации с такой степенью детализации является необычной для исследовательских проектов, но дает значительное ускорение разработки компьютерного взаимодействия(Смотри приложения 1, 3 и 4).

Эта книга вобрала в себя информацию о различных частях архитектуры и протоколов TCP/IP и сделала ее доступной. Эта публикация является очень значительным шагом в эволюции компьютерного взаимодействия.