Фрагментация пакетов IPv4

Как мы знаем, практически все сетевые технологии имеют ограничение на максимальную длину передаваемого блока полезных данных, называемую "блок данных максимальной длины" или MTU (Maximum Transfer Unit). Если блок данных имеет большую длину, он автоматически разбивается на части меньшей длины, каждая из которых передается затем по отдельности.

Это и есть фрагментация. Фрагментация происходит в случае, если длина пакета превосходит MTU физического сетевого уровня. Однако она также происходит, когда пакет попадает в маршрутизатор с MTU меньшим, нежели MTU локальной сети отправителя.

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

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

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

В действительности размер каждого фрагмента слегка отличается от значения MTU. На рис. 1.4 приведена структура IP -заголовка. Обратите внимание на то, что длина поля длины пакета равна 16 битам, а поля смещения фрагмента - тринадцати.

Длина поля длины пакета в шестнадцать битов означает, что максимальная длина пакета может равняться 65535 битам. Поле смещения фрагмента должно уметь обозначить точку смещения на всей длине IP -пакета, следовательно, должно адресовать от 1 до 65536 байтов (или от 0 до 65535). Однако длина поля смещения фрагмента равна всего тринадцати битам и, следовательно, может принимать значения в интервале от 0 до 8191, позволяя адресовать максимум 8192 байт. Если значение поля смещения фрагмента кратно 8 байтам, проблема решается. Например, значение поля смещения 1 означает смещение в восемь байтов, 2 - в шестнадцать и т. д. Максимальное смещение при этом равно 65528 (8191*8).

Число 65528 указывает на последние восемь байтов пакета максимально возможной длины: 65528 плюс 7 равно 65535 (максимальная длина пакета).

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

Рассмотрим пример. Пусть MTU=128, а длина данных исходного пакета – 730 байт. Значит, наши новые пакеты-фрагменты не должны быть больше 128 байт, и тогда поле данных составит 128-20=108 байт. Но число 108 не делится нацело на 8, что должно было бы гарантировать выравнивание на границу 8-ми байт. Ближайшее число, удовлетворяющее этому условию - это 104. Далее получаем: 730=7*104+2. Таким образом, у нас будет 7 новых пакетов 20+104=124 байта длиной каждый и последний пакет-фрагмент 20+2=22 байта - всего 8 пакетов. Применяя этот алгоритм, мы всегда будем иметь размер последнего пакета меньшим (или равным), чем предыдущий.

В UNIX–системах применяется другой подход. Для нашего примера мы тоже будем иметь базовое число в 104 байта и будем последовательно слать 6 пакетов, содержащих 6*104=624 байта исходных данных. После отсылки 6-го пакета окажется, что данных осталось 106 байт. Если добавить к ним 20 байт заголовка, последний 7-ой пакет будет иметь длину в 126 байт (больше, чем 124), но все равно меньше MTU. А так как он последний, для него кратность 8-ми не имеет никакого значения. В результате Windows-алгоритм пошлет 8 пакетов, а UNIX – 7!

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

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

IP-модуль на принимающем IP -фрагменты узле в ситуации, когда он должен транслировать IP -сегмент далее по сети, имеет три варианта действий с фрагментами:

2. разбить (если в этом есть необходимость) полученные IP -фрагменты на еще более короткие IP -фрагменты;

3. восстановить исходный IP -пакет из фрагментов.

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

C приходом первого фрагмента IP -пакета запускается специальный таймер сборки и устанавливается в исходное состояние (для UNIX-реализаций это, обычно, 30 сек). Далее таймер начинает обратный отсчет. До момента обнуления таймера должны прийти все IP -фрагменты, относящиеся к этому пакету. Если время истекло, а все фрагменты так и не появились, модуль IP отбрасывает уже принятые фрагменты и не обрабатывает частично принятый пакет.

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

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

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

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

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

Пример фрагментации

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

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

Поле данных длинного пакета затем делится на N равных частей на границе, кратной 8 байтам (64 бит). При этом сумма длины заголовка + длина первой порции не должна превышать MTU сети, через которую будет пересылаться новый пакет. Вторая порция и последующие могут не быть кратны 8-ми байтам. Назовем число восьмибайтовых блоков в первой порции NFB (Число Блоков Фрагмента).

Первая часть данных помещается в первую новый пакет, и поле суммарной длины в заголовке устанавливается равным длине первого пакета. Флаг "more fragments" устанавливается в 1.

Вторая часть данных помещается во втором новом пакете, и поле общей длины пакета устанавливается равной длине второго пакета. Флаг "more fragments" имеет то же самое значение, которое было установлено в первоначальном пакете. Поле смещения фрагмента второго нового пакета устанавливается равным значению этого поля в оригинальном длинном пак6ете плюс NFB. Эта процедура может быть обобщена для разбиения на N частей.

Рассмотрим процесс фрагментации более подробно на следующем примере. IP -модуль на некотором узле получил IP -пакет с идентификатором 9876 и данными длиной 300 байт (при этом бит запрета фрагментации DF установлен в 0). Этот IP -пакет должен быть передан дальше к адресату через сеть, MTU которой равен 128 байтам.

Ниже схематично представлено разбиение исходного IP - пакета на три IP -фрагмента.

IP-фрагмент 1 IP-фрагмент 2 IP-фрагмент 3

IP-фрагмент 1 содержит в своем заголовке следующую информацию:

1. Идентификатор – 9876;

3. Длина пакета – 124 (байт);

4. Бит MF – 1;

5. Смещение фрагмента – 0 (восьмибайтных единиц).

IP-фрагмент 2 содержит в своем заголовке следующую информацию:

1. Идентификатор – 9876;

2. Длина заголовка – 5 (четырехбайтных слов);

3. Длина пакета – 124 (байт);

4. Бит MF – 1;

5. Смещение фрагмента – 13 (восьмибайтных единиц).

IP-фрагмент 3 содержит в своем заголовке следующую информацию:

1. Идентификатор – 9876;

2. Длина заголовка – 5 (четырехбайтных слов);

3. Длина пакета – 112 (байт);

4. Бит MF – 0;

5. Смещение фрагмента – 26 (восьмибайтных единиц).

Заметим, что так как смещение фрагмента измеряется в восьмибайтных единицах, то длина данных в каждом IP -фрагменте (кроме последнего в цепочке) обязательно должна быть кратна 8. Вот почему в нашем примере это 104 байта (13 восьмибайтных единиц), а не 108, как допускает максимальная длина кадра в 128 байт (128 – 20 = 108, где 20 – длина заголовка).

Чтобы собрать все фрагменты пакета в первоначальный оригинальный пакет, модуль IP -протокола компьютера-приемника объединяет те IP -пакеты, которые имеют одинаковые значения в четырех полях заголовка - требование RFC-791:

идентификатор, источник, получатель и протокол.

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

3.Межсетевой протокол IPv6

Данный раздел посвящается рассмотрению протокола сетевого уровня IPv6. Есть все основания полагать, что в ближайшие годы этот протокол полностью вытеснит предыдущую версию – IPv4.

Дело в том, что технология стека TCP/IP сложилась в основном в конце 1970-х годов - он стал стандартом Министерства обороны США 1980 году и с тех пор основные принципы работы его базовых протоколов, таких как IP, TCP, UDP и ICMP, практически не изменились. Однако за прошедшие годы существенно изменился сам компьютерный мир, и долго назревавшие усовершенствования в технологии стека TCP/IP сейчас стали необходимостью. Сейчас становится особенно очевидным, что основные концепции стека протоколов TCP/IP не полностью удовлетворяют (а по ряду требований, и противоречат) современным представлениям о компьютерной безопасности. Это находит свое отражение в получающих все большее распространение атаках, использующих уязвимости базовых протоколов сети Интернет. Имеются и типичные слабости реализации протоколов TCP/IP, наследуемые современными операционными системами. Только в 1997 году фирма Microsoft Corp. выпустила семь официальных исправлений стека TCP/IP операционной системы Windows NT, направленных на ликвидацию возможности проведения атак, использующих уязвимости базовых протоколов информационного обмена . Основными обстоятельствами, из-за которых требуется модификация базовых протоколов стека TCP/IP, являются следующие.

Повышение производительности компьютеров и коммуникационного оборудования.

За время существования стека производительность компьютеров возросла на более чем три порядка, объемы оперативной памяти выросли более чем в 100 раз, пропускная способность магистрали Интернета в Соединенных Штатах выросла в 1000 раз.

Появление новых приложений.

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

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

Бурное расширение сети Интернет.

В начале 90-х годов сеть Интернет расширялась очень быстро, новый узел появлялся в ней каждые 30 секунд, но 95-й год стал переломным – перспективы коммерческого использования Интернета стали отчетливыми и сделали его развитие просто бурным. Первым следствием этого стало почти полное истощение адресного пространства Интернета, определяемого четырехбайтовым полем IP-адреса. Для IPv4-адресов выделено только 32 бита. В мире, где почти все корпоративные и домашние ПК подключены к Интернету и где каждый холодильник, телевизор, микроволновая печь и даже электромотор являются потенциальными кандидатами на IP-адрес, IP-адресов уже просто на всех не хватает. Действительно, в 1981 году в Сети насчитывалось всего около 200 узлов, а по состоянию на март 2000 года - более 75 млн.

Недостатки собственно IPv4.

Одним из решающих недостатков является несовершенство системы адресации IPv4. Сейчас в ходу две системы адресации – классовая (пять классов сетей – A, B, C, D и E), а также так называемая бесклассовая адресация. Адреса класса А обеспечивают 16777214 узлов, класса В - 65534 узлов, класса С - до 254 узлов. Узлом может быть любой устройство - компьютер, маршрутизатор или сетевое устройство типа принтера - имеющее сетевой интерфейс. Сейчас наиболее популярны адреса класса В, поскольку в действительности мало компаний, имеющих свыше 16 млн. узлов (класс А), но подавляющему большинству требуется больше 254 узлов (класс С). Однако в классе В возможны только 16 384 сети.

Бесклассовая адресация позволяет игнорировать различия между классами A, B и C заданием сетевого адреса с произвольным положением границы "сеть – хост" внутри IP-адреса. К IP-адресу прилагается 32-битовая маска, которую называют маской сети (или маской подсети), которая формируется по следующему правилу: на позициях, соответствующих номеру сети, биты установлены, а на позициях, соответствующих номеру хоста, биты сброшены.

Нехватка реальных IPv4 адресов часто решается с помощью протокола трансляции сетевых адресов - NAT (Network Address Translation), что сильно перегружает шлюзы провайдеров и приводит ко многим неудобствам для пользователей. Широко используемые так называемые "частные адреса" – в классе А это диапазон от 10.0.0.0 до 10.255.255.255, В - от 172.16.0.0 до 172.31.0.0 и С - от 192.168.0.0 до 192.168.255.0 - позволяют восполнить нехватку адресов, но в результате все пользователи выходят в сеть под одним и тем же адресом NAT-сервера, и они не могут воспользоваться никакими персональными настройками, если для них нужен IP-адрес. По некоторым прогнозам, при сохранении существующих тенденций роста Интернет свободные адреса могут закончиться примерно в 2005-6 году. Для таких адресов иногда употребляются такие синонимы: "Серые адреса, "Fake -адреса" или адреса, не маршрутизируемые Интернет-провайдером".

Наиболее подробная информация о распределении IPv4-адресов может быть найдена в RFC-3330 или по адресу /assignments/ipv4-address-space.

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

Спецификация IPv4 малопригодна для приложений, требующих услуг высокого качества (QoS – Quality of Service), например, для мультимедийных приложений, которые за короткое время передают огромные объемы данных, а также для новых приложений, нуждающихся в более высоком уровне безопасности и аутентификации (решение проблемы аутентификации может помочь в борьбе со спамом и другими современными проблемами сетевой безопасности).

Основные проблемы, с которыми сталкивается дальнейшее применение IPv4, кратко могут быть сформулированы следующим образом :

проблемы масштабируемости;

истощение адресного пространства;

разрастание маршрутных таблиц;

сложность массового изменения IP-адресов;

относительная сложность обработки заголовков пакетов IPv4;

отсутствие встроенных механизмов обеспечения «качества обслуживания»;

отсутствие встроенных механизмов автоконфигурации хостов;

отсутствие встроенных средств безопасности;

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

Для решения подобного рода проблем группа IETF - Internet Engineering Task Force - в начале 90-х годов запустила новый проект. Первым конкретным результатом стала публикация в 1995 году RFC-1752 – «The Recommendation for IP Next Generation Protocol». В нем были определены требования к так называемому протоколу IP Next Generation (IPng). Затем появилось другие документы, например RFC-1883, и протокол был официально переименован в Internet Protocol version 6 (IPv6).

Вот наиболее существенные преимущества IPv6:

Упрощен стандартный заголовок IP-пакета.

Значительно увеличено адресное пространство. Адреса в IPv6 имеют длину 128 бит, что примерно в 2 96 раз больше, чем в IPv4.

Изменено представление необязательных полей заголовка.

Возросла скорость обработки IРv6-заголовков маршрутизатором. Несмотря на то, что заголовок стал больше (не менее 40 байт в IPv6 против минимального размера 20 байт в IPv4), он имеет меньше полей (8 против 12). Не в последнюю очередь это можно отнести на счет ликвидации в IPv6 контрольного суммирования (CRC). Кроме того, большинство параметров, не обрабатываемых маршрутизаторами, вынесены в дополнительные заголовки.

Улучшена поддержка иерархической адресации, агрегирования маршрутов и автоматического конфигурирования адресов.

Реализованы механизмы аутентификации, проверки подлинности и целостности IP -пакетов.

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

IPv6 предполагает также значительные улучшения при работе в локальной сети. Протокол NDP (Neighbor Discovery Protocol - протокол распознавания соседей) заменяет функциональность применяемых в IPv4 протоколов ARP и ICMP, значительно расширяя их возможности. Вместо широковещательных ARP-пакетов канального уровня используется групповая передача, адресованная всем членам подсети на сетевом уровне, что существенно снизит широковещательный трафик, являющийся бичом локальных сетей Ethernet.

1. Адресация в IPv6

Система адресации IPv6 существенно отличается от системы адресации IPv4.

Адреса назначения и источника в IPv6 имеют большую длину: 128 бит или 16 байт. Это дает возможность пронумеровать огромное количество узлов: 340 282 366 920 938 463 463 374 607 431 762 211 456 или примерно 1015 адресов на каждого жителя Земли. Выбранная длина IP -адреса должна надолго снять проблему дефицита IP -адресов. Кроме того, в версии IPv6 предполагается использование протокола DHCPv6, позволяющего разделять одни и те же адреса между большим количеством узлов сети, и механизма автоконфигурации. Как и в IPv4, возможное использование NAT-серверов, подменяющих внутренние адреса узлов сети одним собственным IP -адресом, также направлено на снижение потребности в IP -адресах.

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

Идентификатор провайдера

Идентификатор абонента

Идентификатор подсети

Идентификатор узла

Предполагается также, что младшие 6 байт, которые содержат идентификатор узла, представляют собой МАС-адрес сетевого адаптера(как это уже давно делается в протоколе IPX), что обеспечит возможность автоконфигурации стека. Закрепленные на данный момент префиксы описаны в приложении 2.

В версии IPv6 отсутствуют классы адресов сетей, вместо этого используется бесклассоваяидеология, когда каждому Интернет-провайдеру назначается его непрерывный диапазон в пространстве IP -адресов, котрый соответствует размеру определенной маски. При таком подходе все внутренние адреса сетей каждого провайдера имеют общий префикс, так что маршрутизация на магистралях Интернета может осуществляться на основе префиксов, а не полных адресов всех сетей конечных абонентов. Локализация адресов позволяет уменьшить объем таблиц в маршрутизаторах всех уровней, а следовательно, ускорить работу маршрутизаторов и повысить пропускную способность Интернета. Маска переменной длины для пользователя назначается провайдером. Как указывалось ранее, бесклассовая адресация уже используется в текущей версии IPv4 и поддерживается такими протоколами маршрутизации как OSPF, RIP-2, BGP4. Предполагается, что эти же протоколы будут работать и с IPv6. Для бесклассовой адресации применяется специальная технология бесклассовой маршрутизации – CIDR – Classless InterDomain Routing.

Идея CIDR требует, в общем случае, перенумерации сетей. Однако эта процедура сопряжена с определенными временными и материальными затратами. Имеются данные о том, что для перенумерации сети, состоящей из 100 компьютеров, потребовалось 3 недели работы и 5-6 высокооплачиваемых специалистов. В качестве стимулов для проведения перенумерации сети предлагается введение платы за маршрутизацию – оплата за строку маршрутизации или за обновление информации в маршрутизаторах сети, или же введение оплаты за каждый адрес узла.

Техника CIDR помогает также решить известную проблему фрагментации адресного пространства IPv4. Например, очень редко абонент использует все 254 адреса сети класса С или 65 534 адреса сети класса В. Чтобы не происходило потери адресов, обычно выдвигают требование оплаты каждого адреса узла, что вынуждает пользователя решиться на перенумерацию, с тем, чтобы получить ровно столько адресов, сколько ему нужно. Однако у крупных Интернет-провайдеров не существует однозначной склонности к тому или иному методу адресации, и пока они успешно сосуществуют.

В IPv6 существует три вида IPv6 -адресов: индивидуальные (unicast ), групповые (multicast ) и коллективные (anycast ). Unicast означает адрес в привычном смысле значения этого понятия. Данные адреса идентифицируют в точности один интерфейс в сфере своего действия и предназначены для информационного обмена точка-точка (point-to-point). Multicast идентифицирует адреса группы интерфейсов и предназначен для групповой рассылки информации. Пакет данных, посланный по такому адресу, должен быть доставлен по каждому из адресов интерфейсов, входящих в идентифицируемую группу. Адреса anycast также представляют группу интерфейсов, однако доставка информации производится только на ближайший интерфейс из идентифицируемой группы. Нотация адресов IPv6 представляет собой разделенные на 8 групп 16-ти битовые числа, записываемые в шестнадцатеричной системе счисления, например 0123:4567:89AB:CDEF:0123:4567:89AB:CDEF. При записи адреса в целях экономии места принято опускать незначащие нули. Компьютер, использующий протокол IPv6, не обязан распознавать типыIPv6-адресов. Это дело маршрутизатора - полностью понимать и соответственно обрабатывать различные типы адресов.

Sakaru pasaule. #2(46) 2007.g. 70 ... uzdevumi matemātikas papildnodaļās transporta un mašīnzinību spacialitātēm. RTU ... 1993. g. Profesors, Elektronikas un datorzinātnes instit ūts , Latvijas Universitāte (Profesora ...

Latvijas Izglītības un zinātnes ministrijai (3)

Документ

... un psiholoģijas katedra/ instit ūts , docente 1999. - 2002.g. Pedagoģijas un psiholoģijas instit ūts ... ājums, 37. – 39. lpp. Rīga, Transporta un sakaru instit ūts , 2005 J.Mencis, V.Neimanis. GENESIS OF ...

IP (internet protocol - межсетевой протокол) - маршрутизируемый сетевой протокол, протокол сетевого уровня семейства («стека») TCP/IP. IPv4 описан в RFC 791 (сентябрь 1981 года).

Основные положения:

IP - основной протокол стека TCP/IP, он решает вопросы доставки сообщений между узлами составной сети.

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

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

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

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

  Во-вторых, администратор вручную заносит статические записи о специфичных маршрутах или о маршрутизаторе по умолчанию.

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

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

Структура IP пакета

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

Рассмотрим поля структуру IP- пакета на конкретном примере.

Поле Длина заголовка (IHL) IP- пакета занимает 4 бит и указывает значение длины заголовка, измеренное в 32-битовых словах. Обычно заголовок IP-пакета имеет длину в 20 байт (пять 32-битовых слов), но при увеличении объема служебной информации эта длина может быть увеличена. Наибольший заголовок занимает 60 октетов.

Поле Тип сервиса (Type of Service) занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence) . Приоритет может иметь значения от самого низкого - 0 (нормальный пакет) до самого высокого - 7 (пакет управляющей информации) . Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь. Поле Type of Service содержит также три бита, определяющие критерий выбора маршрута. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого, кроме того, обработка каждого из них требует дополнительных вычислительных затрат. Поэтому редко, когда имеет смысл устанавливать одновременно хотя бы два из этих трех критериев выбора маршрута. Зарезервированные биты имеют нулевое значение. Установленный * бит D (delay) говорит о том, что маршрут должен выбираться для минимизации задержки доставки данного пакета * бит Т - для максимизации пропускной способности * бит R - для максимизации надежности доставки.

Поле Общая длина (Total Length) занимает 2 байта и означает общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65 535 байт, однако в большинстве компьютеров и сетей такие большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP- пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандарте предусматривается, что все хосты должны быть готовы принимать пакеты вплоть до 576 байт длиной (приходят ли они целиком или по фрагментам). Существует такое правило: хостам рекомендуется отправлять пакеты размером более чем 576 байт, только если они уверены, что принимающий хост или промежуточная сеть готовы обслуживать пакеты такого размера.

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

Поле Флаги (Flags) занимает 3 бита и содержит признаки, связанные с фрагментацией: установленный бит DF (Do not Fragment) запрещает маршрутизатору фрагментировать данный пакет, а установленный бит MF (More Fragments) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Оставшийся бит зарезервирован.

Поле Смещение фрагмента (Fragment Offset) занимает 13 бит и задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного пакета, подвергнутого фрагментации. Используется при сборке/разборке фрагментов пакетов при передачах их между сетями с различными величинами MTU . Смещение должно быть кратно 8 байт.

Поле Время жизни (Time to Live) занимает 1 байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

Идентификатор Протокол верхнего уровня (Protocol) занимает 1 байт и указывает, какому протоколу верхнего уровня принадлежит информация, размещенная в поле данных пакета (например, это могут быть сегменты протоколов верхних уровней или протоколов маршрутизации). Значения идентификаторов для различных протоколов приводятся в документе RFC 3232 - Assigned Numbers.

Контрольная сумма (Header Checksum) занимает 2 байта и рассчитывается только по заголовку. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, время жизни), контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP- заголовка. Контрольная сумма - 16 бит - подсчитывается как дополнение к сумме всех 16-битовых слов заголовка. При вычислении контрольной суммы значение самого поля "контрольная сумма" устанавливается в нуль. Если контрольная сумма неверна, то пакет будет отброшен, как только ошибка будет обнаружена.

Поля IP-адрес источника (Source IP Address) и

IP-адрес назначения (Destination IP Address) имеют одинаковую длину - 32 бита - и одинаковую структуру.

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

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

IP фрагментация, MTU, MSS, и PMTUD

Фрагментация IP пакетов: MTU , MSS , и PMTUD . PMTUD (Path MTU Discovery) и проблема фрагментации пакетов (network mtu ping packet)

Почему же работают пинг при проблемах с MTU? Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, пингуемый сервер возвращает очень мало информации, которая вполне укладывается в допустимый размер вместе со всеми заголовками.

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

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

Поэтому протокол IP в узле-отправителе не использует свои возможности по фрагментации пакетов.

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

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

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

Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI - 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

Итак, необходимость фрагментации пакетов на уровне IP мы пояснили. Теперь перейдем к самому процессу фрагментации пакетов IP.

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

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

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

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

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

Для того, чтобы не перепутать фрагмент различных типов, в заголовке IP-пакетов используется поле Identification.

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

Поле смещения фрагмента (Fragment Offset) сообщает получателю положение фрагмента в исходном пакете. Смещение фрагмента и длина определяют часть исходного пакета, принесенную этим фрагментом. Флаг "more fragments" показывает появление последнего фрагмента. Модуль протокола IP, отправляющий неразбитый на фрагменты пакет, устанавливает в нуль флаг "more fragments" и смещение во фрагменте.

Все эти поля дают достаточное количество информации для сборки пакета.

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

Размер последней части данных равен полученному остатку.

Каждая из полученных частей данных помещается в новый пакет.

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

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

В заголовок каждого пакета заносятся соответствующие значения в поле смещения "fragment offset", а в поле общей длины пакета помещается длина каждого пакета.

Таким образом, первый фрагмент будет иметь в поле "fragment offset" нулевое значение. Во всех пакетах, кроме последнего, флаг "more fragments" устанавливается в единицу, а в последнем фрагменте - в нуль.

Теперь давайте рассмотрим процесс сборки фрагментов пакетов.

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

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

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

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

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

Процедура объединения заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке пакета в поле "fragment offset".

Каждый модуль IP должен быть способен передать пакет из 68 байт без дальнейшей фрагментации. Это связано с тем, что IP-заголовок может включать до 60 байт, а минимальный фрагмент данных - 8 байт. Каждый получатель должен быть в состоянии принять пакет из 576 байт в качестве единого куска либо в виде фрагментов, подлежащих сборке. Если бит флага запрета фрагментации (Don"t Fragment, DF) установлен, то фрагментация данного пакета запрещена, даже если в этом случае он будет потерян.

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

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

Рассмотрим процесс фрагментации IP-пакетов при передаче между сетями с разным размером пакетов на примере, который показан на этом рисунке.

Канальный и физический уровни обозначены, как К1, Ф1, К2, Ф2 соответственно.

Пусть компьютер 1 связан с сетью, имеющей значение MTU в 4096 байт, например с сетью FDDI.

При поступлении на IP-уровень компьютера 1 сообщения от транспортного уровня размером в 5600 байт протокол IP делит его на два IP-пакета. В первом пакете устанавливает признак фрагментации и присваивает пакету уникальный идентификатор, например 486.

В первом пакете величина поля смещения равна 0, а во втором - 2800.

Признак фрагментации во втором пакете равен нулю, что показывает, что это последний фрагмент пакета.

Общая величина IP-пакета составляет 2800 плюс 20 (размер IP-заголовка), то есть 2820 байт, что умещается в поле данных кадра FDDI.

Сетевой интерфейс отправляет кадры следующему маршрутизатору.

После того, как кадры пройдут уровень сетевого интерфейса маршрутизатора (К1 и Ф1) и освободятся от заголовков FDDI, модуль IP по сетевому адресу определяет, что прибывшие два пакета нужно передать в сеть 2, которая является сетью Ethernet и имеет значение MTU, равное 1500.

Следовательно, прибывшие IP-пакеты необходимо фрагментировать.

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

Затем он формирует новые IP-пакеты, каждый из которых имеет длину 1400 + 20 = 1420 байт, что меньше 1500 байт, поэтому они нормально помещаются в поле данных кадров Ethernet.

В результате в компьютер 2 по сети Ethernet приходят четыре IP-пакета с общим идентификатором 486.

Протокол IP, работающий в компьютере 2, должен правильно собрать исходное сообщение.

Если пакеты пришли не в том порядке, в котором были посланы, то смещение укажет правильный порядок их объединения.

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

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

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

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

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

Инструкция

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

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

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

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

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

Видео: Команда Ping или проверка работоспособности сети

Тестовые пакеты

В этой статье

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

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

При настройке тестовых пакетов, вы можете указать получателей конкретных пакетов, добавляя их в Группа известных пользователей (иногда называется тестовой группе). Любой участник тестовой группы, который использует устройство с версией Windows 10, поддерживающей тестовые пакеты (Windows.Desktop сборки 10586 или более поздней; Windows.Mobile сборки 10586.63 или более поздней или Xbox One), получит тестовые пакеты, предназначенные для этой группы. (Тестовые могут содержать пакеты для любой версии ОС, в том числе Windows 8.1 или Windows Phone 8.1 или более ранних версий, если ранее опубликованное приложение уже поддерживает их.) Любой пользователь, который не был добавлен к одному из тестовых групп или использующие устройства, не поддерживающие тестовые пакеты, получат пакеты из обычной отправки.

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

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

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

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

Создание нового тестового пакета

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

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

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

Примечание

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

Определение пакетов для включения в состав тестового пакета

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

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

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

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

Постепенный выпуск пакета

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

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

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

Настройка дополнительных параметров тестового пакета

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

Отправка тестового пакета в Магазин

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

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

Примечание

Пользователи, получившие пакет, доступный только в составе тестового, смогут выставлять приложению оценки и оставлять отзывы, но такие оценки и отзывы не будут показаны другим пользователям. (Исключением являются устаревшие пакеты XAP версии 7.x или 8.0; оценки и отзывы, оставленные участниками тестовых групп на эти пакеты, будут видны другим пользователям.) Вы можете увидеть оценки и отзывы всех пользователей, включая участников тестовых групп, в отчетах Рецензии и Отзывы для приложения.

Поддержка семейства устройств

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

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

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

Примечание

Пакеты, добавленные в тестовые пакеты, могут поддерживать любую версию ОС (или любую сборку Windows 10), но, как упоминалось выше, пользователи из тестовых групп должны использовать устройство с версией Windows 10, которая поддерживает тестовые пакеты (Windows.Desktop, сборка 10586 и выше; Windows.Mobile, сборка 10586.63 и выше). Только в этом случае можно будет получить пакеты из тестового пакета.

Обновление или изменение тестового пакета

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

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

Добавление дополнительных тестовых пакетов и назначение им приоритета

Можно создать несколько тестовых пакетов для одного приложения с целью распространения разных пакетов среди разных групп пользователей.

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

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

Обратите внимание, что и обычные отправки всегда значится на самом низком № 1. Это означает, что пользователи, не состоящие ни в одной тестовой группе, могут получать через Магазин только пакеты из обычной отправки. Участники тестовых групп всегда получают пакеты из доступных тестового пакета с самым высоким приоритетом для их (но никогда не обычную отправку, поскольку он имеет низкий приоритет). Это дает вам гибкость при распределении пакетов среди пользователей, которые могут состоять в нескольких тестовых группах.

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

Предоставление доступа к пакетам из тестового пакета всем пользователям

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

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

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

Удаление тестового пакета

Для удаления тестового пакета, поддержка которого больше не требуется, щелкните на его имя на странице обзора приложения. На обзорной странице тестового пакета щелкните Изменить и ссылку Удалить , чтобы удалить тестовый пакет. (При наличии незавершенной отправки тестового пакета необходимо сначала ее удалить.) Это может занять до 30 минут.

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

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

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

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

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

Протоколы сетевого уровня, к которым относится и IP , должны обеспечивать номера ( адреса) сетей и номера (адреса) хостов. Некоторым протоколам, например Novell Internetwork Packet Exchange (IPX ), требуется только сетевой адрес , поскольку они используют MAC-адрес устройства в качестве адреса хоста. Протоколу IP требуется адрес , содержащий как сетевую, так и узловую (хостовую) части. Для того чтобы можно было выделить адрес сети и адрес хоста, необходима маска сети или подсети (см. лекцию 7). Протоколы IP, IPX/SPX и AppleTalk обеспечивают поддержку Уровня 3 модели OSI .

Основным сетевым (routed) протоколом всемирной сети Интернет является Internet Protocol (IP ). Формат сообщения сетевого уровня представляет собой пакет , известный также как дейтаграмма ( datagram ). Это означает, что в процессе организации связи не используются схемы коммутации цепей, поскольку все соединения выполнены заранее и нужно лишь выбрать наилучший путь к адресату назначения на основе метрики протокола маршрутизации. Термины ненадежный ( unreliable ) и доставка по возможности , доставка с наибольшими возможными усилиями (besteffort delivery ) означают, что проверка ( верификация ) правильности полученных данных на сетевом уровне не производится. Для такой проверки при необходимости используется протокол транспортного уровня TCP .

Формат пакета сетевого протокола IP ( рис. 8.5) включает заголовок, состоящий из 12 полей общей длиной в 160 бит (5 слов по 4 байта, т. е. 20 байт ), поле опций переменной длины и поле данных.

Рис. 8.5.

1. Первое 4-разрядное поле ( Vers ) задает номер версии протокола. В настоящее время действует версия 4 – IPv4 , согласно которой длина адреса источника (Source IP address ) и адреса назначения ( Destination IP address ) равна 32 разрядам (4 байтам). В распечатках поля заголовка обычно представляются в десятичной и шестнадцатеричной системах. Например, действующая в настоящее время версия 4 выглядит следующим образом: Version = 4 (0x4). В поле заголовка номер версии будет задан в двоичной системе – 0100.
2. Длина заголовка – количество 32-разрядных слов в заголовке – задается вторым полем HLEN. Например, код в этом поле – 0101, и запись Header Length = 20 (0x14) означает, что заголовок содержит 5 слов по 32 разряда или 20 байт.
3. Поле типа сервиса (Type of Service – ToS ) длиной 8 бит включает четыре идентификатора: трехразрядный идентификатор PR и одноразрядные D, T и R. Идентификаторы определяют требования к метрике при прокладке маршрута. Идентификатор PR определяет тип пакета (нормальный, управляющий и др.) и в соответствие с этим задает приоритет. Установка 1 в разряде D означает требование минимизации задержки при передаче пакета; единица в разряде Т означает требование максимальной пропускной способности; установка 1 в разряде R требует максимальной надежности.
4. Поле Total Length задает общую длину пакета, включая заголовок и поле данных. 16 разрядов поля позволяют задавать максимальную длину 64 Кбайт. Поскольку максимальная длина кадра в большинстве технологий локальных сетей меньше 64 Кбайт (например, в Ethernet она составляет 1500 байт), большие пакеты разбивают на фрагменты. При фрагментации пакета используется информация 5-го, 6-го и 7-го полей, все фрагменты должны иметь: одинаковый идентификационный номер пакета; номер, определяющий порядок следования фрагмента при сборке пакета; дополнительную информацию.
5. Пятое поле заголовка содержит идентификационный номер пакета . При фрагментации пакета идентификационный номер будет единым для всех фрагментов.
6. Трехразрядное поле Flags содержит два одноразрядных флага фрагментации. Установка 1 в разряде DF запрещает маршрутизатору производить фрагментацию данного пакета. Единичка в разряде MF указывает, что данный пакет не является последним.
7. 13-разрядное поле смещения данных Fragment Offset помогает собрать фрагменты в единый пакет. Оно задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного нефрагментированного пакета.
8. Из заданного значения Time to Live – время жизни (255 – максимум) при прохождении каждого маршрутизатора или каждую секунду вычитается 1. Таким образом, число узлов, через которые может пройти пакет, ограничено.
9. Поле Protocol указывает протокол верхнего уровня (TCP, UDP , OSPF и др.), которому будет передан принятый пакет после завершения IP-процесса.
10. Поле контрольной суммы заголовка Header Checksum . Поскольку при прохождении маршрутизатора значения некоторых полей заголовка изменяются (например, время жизни), расчет контрольной суммы производится в каждом маршрутизаторе заново.
11. Source IP address – адрес источника информации, длина – 4 байта (32 разряда).
12. Destination IP address – адрес приемника информации, длина – 4 байта (32 разряда).
13. Поле IP option позволяет поддерживать различные опции, например, опцию защиты информации. Поскольку это поле может иметь разную длину, оно дополняется нулями до 32 разрядов.
14. Поле данных Data имеет длину более 64 разрядов.

Краткие итоги

1. Основным протоколом автоматического назначения IP-адресов устройств является протокол динамического конфигурирования узлов DHCP .
2. При передаче данных через составную сеть IP-адреса узла назначения и узла источника остаются неизменными.
3. При передаче данных через составную сеть МАС-адреса назначения и источника меняются при прохождении каждого маршрутизатора.
4. При формировании кадра вычисляется контрольная сумма , которая записывается в поле FCS -трейлера кадра. При приеме кадра на каждом входном интерфейсе вновь вычисляется контрольная сумма , которая сравнивается с принятой.
5. Правильность принятых данных проверяется с использованием циклического кода CRC .
6. При передаче данных через соединения "точка-точка" заголовок кадра может быть существенно упрощен.
7. Сетью с доставкой данных без предварительного соединения отправителя и получателя сообщения является Internet, где передаются пакеты ( дейтаграммы ) с использованием протокола IP .
8. Правила телекоммуникаций узлов между собой при обмене данными через сети устанавливают протоколы. Протоколы описывают формат сообщения, путь (маршрут) обмена сообщениями и другие правила.
9. Основным сетевым протоколом всемирной сети Интернет является Internet Protocol (IP).
10. Сетевые (routed) протоколы определяют