реклама
ОНЛАЙН АПТЕКА НИЗКИХ ЦЕН
цены ниже розничных точек. доставка по украине

   Любые виды проектных, дизайнерских и строительных работ в Украине и Киеве    
АПТЕКА

proxy  статьи  библиотека  softice  free_юр.консультация  hard  iptv
рекламодателям  фирмы/add  расшифровка штрих-кодов  links/add

http://kiev-security.org.ua

3 Спецификация

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].

Назад | Вперед

Содержание

HOME


Если у вас есть сайт или домашняя страничка - поддержите пожайлуста наш ресурс, поставьте себе кнопочку, скопировав этот код:

<a href="http://kiev-security.org.ua" title="Самый большой объем в сети онлайн инф-ции по безопасности на rus" target="_blank"><img src="http://kiev-security.org.ua/88x31.gif" width="88" height="31" border="0" alt="security,безопасность,библиотека"></a>

Идея проекта(C)Anton Morozov, Kiev, Ukraine, 1999-2022,

Meteo.ua

Wordfactory.ua