Определения методов rfc 2068


Содержание

Hypertext Transfer Protocol — HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as «HTTP/1.1», and is an update to RFC 2068 [33].

Метрика 5: Отклик для класса RFC (Response For a Class)

Введем вспомогательное определение. Множество отклика класса RS — это множество методов, которые могут выполняться в ответ на прибытие сообщений в объект этого класса. Метрика RFC равна количеству методов во множестве отклика.

Приведем другое определение метрики: RFC — это количество методов класса плюс количество методов других классов, вызываемых из данного класса.

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

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

С ростом RFC увеличивается сложность класса. Наихудшая величина отклика может использоваться при определении времени тестирования.

Метрика 6: Недостаток связности в методах LСOM (Lack of Cohesion in Methods)

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

Можно определить метрику по-другому: LCOM — это количество пар методов, не связанных по свойствам класса, минус количество пар методов, имеющих такую связь.

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

Высокие значения LCOM означают, что класс, вероятно, надо спроектировать лучше (разбиением на два или более отдельных класса). Любое вычисление LCOM помогает определить недостатки в проектировании классов, так как эта метрика характеризует качество упаковки данных и методов в оболочку класса.

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

Набор метрик Чидамбера-Кемерера — одна из пионерских работ по комплексной оценке качества ОО-проектирования. Известны многочисленные предложения по усовершенствованию, развитию данного набора.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась — это был конец пары: «Что-то тут концом пахнет». 8379 — | 8008 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Что нужно знать про HTTP протокол веб-разработчику. Правила HTTP протокола

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

Всё, что тебе нужно знать про HTTP протокол

Что такое HTTP протокол?

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

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

HTTP протокол – это правила дорожного движения в интернете, только если в жизни люди могут не соблюдать правила дорожного движения и им за это ничего не будет, то несоблюдение правил HTTP протокола ведет к тому, что пользователь не сможет работать в интернете.

HTTP протокол – это протокол передачи данных седьмого уровня модели OSI, работающий на основе технологии клиент-сервер.

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

HTTP протокол – изначально простой протокол передачи гипертекста, по которому сейчас можно передавать все, что угодно.

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

HTTP протокол – это технология, которую должен понимать любой веб-разработчик.

Что же, я думаю, мы разобрались с тем, что такое HTTP протокол и можем теперь посмотреть, где он используется.

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные типы данных.

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола:

  1. HTTP протокол работает по технологии клиент-сервер.
  2. HTTP протокол относится к седьмому уровню модели OSI.
  3. HTTP протокол относится к семейству протоколов TCP/IP.
  4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
  5. Спецификация протокола RFC 2616.
  6. Для идентификации ресурса HTTP протокол использует URI (читай про URI в HTTP).
  7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
  8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

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

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. Клиент (в данном случае покупатель) полностью управляет развитием событий, то есть сервер (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

  1. Стандарт HTTP/0.9 – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
  2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
  3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, HTTP приложения могут себя идентифицировать, посылая информацию о себе в заголовке.
  4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

  • Google Chrome;
  • Mozilla FireFox;
  • Opera;
  • Internet Explorer;
  • Яндекс Браузер;
  • Safari.

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

Серверы HTTP протокола

Серверы HTTP протокола можно условно разделить на два вида: исходные сервера и прокси-сервера. К исходным серверам относятся те сервера, к которым непосредственно обращается клиент, прокси-сервера HTTP – это транзитные сервера между клиентом и тем сервером, к которому он желает обратиться. Зачастую бывает так, что HTTP сервер выполняет одновременно функцию и конечного сервера, и прокси-сервера, а иногда и клиента.

Вот примеры конечных HTTP серверов:

Давайте посмотрим на прокси-сервера:

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

Требования HTTP протокола

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

Структура HTTP протокола

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

  1. Стартовая строка или строка состояния, которая определяет тип HTTP сообщения. Стартовая строка обязательна для любого сообщения.
  2. Заголовок HTTP сообщения, который может включать одно поле Host или несколько полей для передачи различной служебной информации.
  3. Тело HTTP сообщения, которое содержит HTTP объекты. Тело сообщения служит для передачи пользовательской информации и есть не у каждого HTTP сообщения.

Терминология HTTP протокола

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

Параметры HTTP протокола

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

  1. Версия HTTP протокола является его обязательным параметром и указывается в первой строке любого HTTP сообщения.
  2. URI – это параметр, который позволяет однозначно идентифицировать ресурс, который хочет запросить клиент.
  3. Дата и время – это тоже параметр HTTP протокола.
  4. HTTP протокол имеет параметры кодирования сообщений и кодирования передачи.
  5. Тип данных или медиа тип – очередной параметр HTTP протокола.
  6. Лексемы программ позволяют определить разработчика HTTP приложения и версию приложения, а еще лексема является параметром HTTP протокола.
  7. HTTP протокол имеет параметры, которые позволяют определить язык сообщения, в HTTP это называется метка языка.
  8. А еще в HTTP есть единицы измерения диапазонов, которые позволяют запросить только часть ресурса.

Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ

Основной и единственной единицей измерения в HTTP протоколе является байт. Основным и единственным способом общения в HTTP протоколе является HTTP сообщение. Сообщения делятся на два вида: HTTP запрос – это сообщение, которое клиент посылает серверу и HTTP ответ – это сообщение, которое сервер посылает клиенту. В принципе, мы уже разобрались со структурой HTTP сообщения ранее, давайте теперь посмотрим примеры запросов и ответов в HTTP протоколе.

Давайте сначала посмотрим на то, что есть общего у любого сообщения в HTTP протоколе. Первое, что хочется выделить – это структура, она общая: статусная строка обязательна для всех сообщений, далее идет заголовок сообщения, в котором обязательное поле Host (в него записывается URI ресурса) и необязательное тело сообщения или, как его еще называют HTTP объект.

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

  1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
  2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
  3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
  4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
  5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

Простой пример запроса в HTTP протоколе: сначала идет статусная строка, в которой мы указываем версию протокола HTTP и метод, который будет использован для обращения к ресурсу, а скрипт, находящийся по URL /cgi-bin/process.cgi будет использован для обработки данных. Статусная строка отделена символом CRLF в конце от заголовка, далее идет набор полей HTTP заголовка, которые отделяются друг от друга символом CRLF в конце строки. Если у одного поля есть несколько значений, то они отделяются друг от друга запятой. Тело сообщения отделено пустой строкой. Значение и описание всех полей заголовка HTTP протокола вы сможете найти на моем блоге в специальной записи: список полей HTTP заголовка.

А вот пример ответа в протоколе HTTP:

Синтаксис ответа в протоколе HTTP практически ничем не отличается, ключевым отличием является то, что в первой строке сервер посылает коды статуса, о которых мы поговорим чуть ниже.

Методы в HTTP протоколе

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

Методы в HTTP протоколе делятся на безопасные и идемпотентные. К безопасным относятся методы GET и HEAD, потому что они используются лишь для получения содержимого или его характеристик от сервера, а идемпотентные методы, это такие методы HTTP протокола, которые в случае своего многократного использования к ресурсу на одном и том же URI от одного и того же клиента будут давать такую же нагрузку, как будто этот метод выполнился только один раз, к идемпотентным методам HTTP протокола относятся: GET, HEAD, PUT, DELETE, OPTIONS и TRACE.

Давайте коротко рассмотрим методы HTTP протокола и их назначение:

  1. Метода GET в HTTP протоколе используется для получения информации от сервера по заданному URI. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
  2. Метод HTTP протокола HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
  3. Метод HTTP протокола POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
  4. Метода HTTP протокола PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.
  5. Метод HTTP протокола DELETE удаляет указанный в URI ресурс.
  6. Метод HTTP протокола CONNECT преобразует существующее соединение в тоннель.
  7. Метод HTTP протокола OPTIONS используется для получения параметров текущего HTTP соединения/.
  8. Метод HTTP протокола TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.

Как происходит соединение по HTTP протоколу

На данный момент для каждого HTTP соединения HTTP протокол поддерживает постоянные TCP соединения, это означает, что при повторном запросе к серверу с одним и тем же IP-адресом, соединение четвертого уровня рваться не будет, а будет использовано существующее. Раньше это было не так и, если в HTML документе были картинки, то для загрузки каждой картинки использовалось новое соединение TCP/IP.

Обсуждение содержимого в HTTP протоколе

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

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

Коды состояния в HTTP протоколе

Коды состояния в HTTP протоколе говорят клиенту о том, что произошло с его запросом, как сервер понял запрос и нужно ли делать что-нибудь клиенту, чтобы запрос был выполнен корректно. Коды состояния – это три цифры, например, 100, 301, 404, 503. Коды состояния в HTTP протоколе делятся на пять классов состояния: информационные коды (они начинаются с единицы), успешные коды (начинаются с двойки), коды перенаправления (начинаются с тройки), коды ошибок клиента (начинаются с четверки), коды ошибок сервера (начинаются с пятерки). Ниже приведена таблица классов кодов состояния их короткое описание. А еще вы можете посмотреть справочник кодов состояния.

Номер Класс кода состояния в HTTP протоколе и его описание
1 HTTP коды состояний 1xx: информационные

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

2 HTTP коды состояний 2xx: успешные

Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента.

3 HTTP коды состояний 3xx: перенаправление

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

4 HTTP коды состояний 4xx: ошибка клиента

Если вы увидели код состояния, который начинается с четверки, то это означает, что произошла ошибка по вине клиента.

5 HTTP коды состояний 5xx: серверная ошибка

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

Поля заголовка HTTP сообщения

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

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

  1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
  2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
  3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
  4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Более подробно о полях заголовков HTTP сообщения смотрите справочник полей заголовка HTTP сообщения.

Кэширование HTTP протокола

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

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

Номер Директивы поля заголовка Cache Control для клиента и их описание
1 no cache

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

2 no store

Директива HTTP протокола no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.

3 max age = seconds

Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.

4 max stale [ = seconds ]

Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.

5 min fresh = seconds

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

6 Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7 only if cached
Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.
Номер Директивы поля заголовка Cache Control для сервера и их описание
1 public


Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше.

2 private

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

3 no cache

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

4 no store

Директива HTTP протокола no store говорит о том, что ответ сервера нельзя сохранять в кэше.

5 no transform

Директива HTTP протокола no transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.

6 must revalidate

Директива HTTP протокола must revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.

7 proxy revalidate

Директива HTTP протокола proxy revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.

8 max age = seconds

Директива HTTP протокола max age говорит о том, сколько живет кэш на сервере.

9 Директива поля заголовка Cache Control ответа сервера: s maxage = seconds

Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов

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

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

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

Безопасность HTTP протокола

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

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

Определения методов / rfc 2068

Network Working Group
Request for Comments: 2068
Category: Standards Track

R. Fielding
UC Irvine
J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
January 1997

Hypertext Transfer Protocol — HTTP/1.1


Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as «HTTP/1.1».

Table of Contents

Next: 1 Introduction Connected: An Internet Encyclopedia
RFC 2068

1. Протокол http

Протокол передачи гипертекста HTTP (Hypertext Transfer Protocol, RFC 1945, 2068) предназначен для передачи гипертекстовых документов от сервера к клиенту. Протокол HTTP относится к протоколам прикладного уровня. Согласно RFC, транспортным протоколом для него должен быть протокол с установлением соединения, надежной передачей данных и без сохранения границ между сообщениями. На практике в подавляющем большинстве случаев транспортным протоколом для HTTP является протокол TCP, причем сервер HTTP (сервер Web) находится в состоянии ожидания соединения со стороны клиента стандартно по порту 80 TCP, а клиент HTTP (браузер Web) является инициатором соединения.

В терминах Web все, к чему может получить доступ пользователь, – документы, изображения, программы, – называется ресурсами. Каждый ресурс имеет уникальный для Web адрес, называемый универсальным идентификатором ресурса (URI – Universal Resource Identifier). В самом общем случае URI выглядит следующим образом:

Отдельные поля URI имеют следующий смысл:

protocol — прикладной протокол, посредством которого получают доступ к ресурсу;

user — пользователь, от имени которого получают доступ к ресурсу либо сам пользователь в качестве ресурса;

password — пароль пользователя для аутентификации при доступе к ресурсу;

host — IP-адрес или имя сервера, на котором расположен ресурс;

port — номер порта, на котором работает сервер, предоставляющий доступ к ресурсу;

path — путь к файлу, содержащему ресурс;

file — файл, содержащий ресурс;

parameters — параметры для обработки ресурсом-программой;

fragment — точка в файле, начиная с которой следует отображать ресурс.

Взаимодействие между клиентом и сервером Web осуществляется путем обмена сообщениями. Сообщения HTTP делятся на запросы клиента серверу и ответы сервера клиенту.

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

поле заголовка 1

поле заголовка 2

поле заголовка N

Формат начальной строки клиента и сервера различаются и будут рассмотрены далее. Заголовки бывают четырех видов:

общие заголовки (general-headers), которые могут присутствовать как в запросе, так и в ответе;

заголовки запросов (request-headers), которые могут присутствовать только в запросе;

заголовки ответов (response-headers), которые могут присутствовать только в ответе;

заголовки объекта (entity-headers), которые относятся к телу сообщения и описывают его содержимое.

Каждый заголовок состоит из названия, символа двоеточия «:» и значения. Наиболее важные заголовки приведены в табл. 1.

Заголовки протокола HTTP

Перечисляет поддерживаемые сервером методы

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

Длина сообщения в байтах

Тип содержимого и, возможно, некоторые параметры

Уникальный тэг ресурса на сервере, позволяющий сравнивать ресурсы

Дата и время, когда ресурс на сервере будет изменен, и его нужно получать заново

Дата и время последней модификации содержимого

Число секунд, через которое нужно повторить запрос для получения нового содержимого

URI ресурса, к которому нужно обратиться для получения содержимого

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

Название программного обеспечения сервера, приславшего ответ

Типы содержимого, которое «понимает» клиент и может воспроизвести

Кодировки символов, в которых клиент может принимать текстовое содержимое

Способ, которым сервер может закодировать сообщение

Хост и номер порта, с которого запрашивается документ

Заголовки запроса для условного обращения к ресурсу

Запрос части документа

Название программного обеспечения клиента

Указывает серверу на завершение (close) или продолжение (keep-alive) сеанса

Дата и время формирования сообщения

Окончание табл. 1

Специальные, зависящие от реализации команды, касающиеся передаваемого содержимого

Способ кодирования сообщения при передаче

Подробное описание заголовков HTTP/1.0 можно найти в RFC 2068.

В теле сообщения содержится собственно передаваемая информация – полезная нагрузка сообщения. Тело сообщения представляет собой последовательность октетов (байтов). Тело сообщения может быть закодировано, например, для уменьшения объема передаваемой информации, при этом способ кодирования указывается в заголовке объекта Content-Encoding.

Сообщение запроса от клиента к серверу состоит из строки запроса (request-line), заголовков (общих, запросов, объекта) и, возможно, тела сообщения. Строка запроса начинается с метода, затем следует идентификатор запрашиваемого ресурса, версия протокола и завершающие символы конца строки:

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

В RFC 2068 представлен протокол HTTP/1.1.

Рассмотрим основные методы протокола HTTP.

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

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

Если идентификатор запрашиваемого ресурса – звездочка («*»), то запрос OPTIONS предназначен для обращения к серверу в целом.

Если идентификатор запрашиваемого ресурса – не звездочка, то запрос OPTIONS применяется к опциям, которые доступны при соединении с указанным ресурсом.

Метод GET позволяет получать любую информацию, связанную с запрашиваемым ресурсом. В большинстве случаев, если идентификатор запрашиваемого ресурса указывает на документ (например, документ HTML, текстовый документ, графическое изображение, видеоролик), то сервер возвращает содержимое этого документа (содержимое файла). Если запрашиваемый ресурс является приложением (программой), формирующим в процессе своей работы некоторые данные, то в теле сообщения ответа возвращаются эти данные, а не двоичный образ выполняемого файла. Это используется, например, при создании приложений CGI. Если идентификатор запрашиваемого ресурса указывает на директорию (каталог, папку), то, в зависимости от настроек сервера, может быть возвращено либо содержимое директории (список файлов), либо содержимое одного из файлов, находящегося в этой директории (как правило, index.html или Default.htm). В случае запроса папки ее имя может указываться как с символом «/» на конце, так и без него. При отсутствии на конце идентификатора ресурса данного символа сервер выдает один из ответов с перенаправлением (с кодами статуса 301 или 302).

Одной из разновидностей метода GET является «условный GET» («conditional GET»), при котором сообщение запроса включает заголовки запроса If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Условный метод GET запрашивает передачу объекта, только если он удовлетворяет условиям, описанным в приведенных заголовках. Например, при наличии заголовка If-Modified-Since содержимое запрашиваемого ресурса будет получено только в том случае, если оно не изменялось после момента времени, указанного в качестве значения данного заголовка. Условный метод GET предназначен для уменьшения ненужной загрузки сети, поскольку позволяет не загружать вторично уже сохраненные клиентом данные.

Различают также «частичный GET» («partial GET»), при котором сообщение запроса включает заголовок запроса Range. Частичный GET запрашивает передачу только части объекта. Частичный метод GET предназначен для уменьшения ненужной загрузки сети, за счет запроса только части объекта, когда другая часть уже загружена клиентом. Значением заголовка Range является строка «bytes=» с последующим указанием диапазона байтов, которые необходимо получить. Байты нумеруются с 0. Начальный и конечный байты диапазона разделяются символом «–». Как начальный, так и конечный байты в диапазоне могут отсутствовать. Если нужно получить несколько диапазонов, то они перечисляются через запятую. Если некоторые из перечисленных диапазонов пересекаются, то сервер осуществляет их объединение. Сообщение ответа в случае запроса с частичным методом GET должно содержать заголовок Content-Range, в котором указывается передаваемый диапазон. Если сервер передает несколько непересекающихся диапазонов, то заголовок Content-Type принимает специальное значение «multypart/byteranges». Тело сообщения разбивается на части, разделенные сгенерированным сервером разделителем и переданным в качестве параметра заголовка Content-Type. Каждая отдельная часть содержит собственные заголовки Content-Type и Content-Range с пустой строкой перед содержимым диапазона.

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

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

аннотация существующих ресурсов;

регистрация сообщения на электронной доске объявлений (BBS), в конференциях новостей (newsgroups), списках рассылки (mailing lists) или подобной группе статей;

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

выполнение запросов к базам данных (БД);

загрузка файлов на сервер.

Фактически функция, выполняемая методом POST, определяется приложением, на которое указывает идентификатор запрашиваемого ресурса. Наряду с методом GET, метод POST используется при создании приложений CGI. Браузер может формировать запросы с методом POST при отправке форм. Для этого элемент FORM документа HTML, содержащего форму, должен иметь атрибут method со значением POST.

Приложение, запуск которого инициируется методом POST, может выполнить действие на сервере и не передать никакого содержимого в качестве результата работы. В зависимости от того, включает ответ тело сообщения, описывающее результат, или нет, код состояния в ответе может быть как 200 (OK), так и 204 (Нет содержимого, No Content).

Если ресурс на сервере был создан, ответ содержит код состояния 201 (Создан, Created) и включает заголовок ответа Location.

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

Различие между методами POST и PUT заключается в различном значении идентификатора запрашиваемого ресурса. URI в запросе POST идентифицирует ресурс, который обрабатывает включенный в тело сообщения объект. Этим ресурсом может быть приложение, принимающее данные. Напротив, URI в запросе PUT идентифицирует объект, включенный в запрос в виде тела сообщения, то есть пользовательский агент назначает данный URI включенному ресурсу.

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

Метод TRACE используется для возврата переданного запроса на уровне протокола HTTP. Получатель запроса (сервер Web) отправляет полученное сообщение обратно клиенту как тело сообщения ответа с кодом состояния 200 (OK). Запрос TRACE не должен содержать тела сообщения.

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

Если запрос успешно выполнен, то ответ содержит все сообщение запроса в теле сообщения ответа, а заголовок объекта Content-Type имеет значение «message/http».

Подробную информацию о методах протокола HTTP/1.1 можно найти в RFC 2068.

После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP ответа.

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

Версия протокола имеет тот же смысл, что и в запросе.

Элемент код состояния (Status-Code) – это целочисленный трехразрядный (трехзначный) код результата понимания и удовлетворения запроса. Поясняющая фраза (Reason-Phrase) представляет собой короткое текстовое описание кода состояния. Код состояния предназначен для обработки программным обеспечением, а поясняющая фраза предназначена для пользователей.

Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры:

1xx: Информационные коды – запрос получен, продолжается обработка.

2xx: Успешные коды – действие было успешно получено, понято и обработано.

3xx: Коды перенаправления – для выполнения запроса должны быть предприняты дальнейшие действия.

4xx: Коды ошибок клиента – запрос имеет ошибку синтаксиса или не может быть выполнен.

5xx: Коды ошибок сервера – сервер не в состоянии выполнить допустимый запрос.

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

Коды ответов сервера HTTP

Поясняющая фраза согласно

Эквивалентная поясняющая фраза на русском языке

ИТ База знаний

ShareIT — поделись знаниями!


Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

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

Корпоративные сети

Похожие статьи

Система записи телефонных разговоров

Примеры использования Puppet

Роль Proxy серверов в ИБ

15 примеров CURL в Linux

HyperText Transfer Protocol (HTTP)

Работает прямо сейчас

4 минуты чтения

The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет — браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP.

Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии:

  • HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы
  • HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером.
  • HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования.

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

Получение веб страницы по HTTP

Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков:

  1. Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы.
  2. Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы.
  3. Клиент начинает анализировать полученный документ и формировать WEB – страницу.
  4. Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера.

Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1).

HTTP запросы

Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже:

Запрос Описание HTTP/1.0 HTTP/1.1
GET Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
POST Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы Да Да
PUT Позволяет клиенту добавить файл в определенную директорию сервера. Нет Да
DELETE Позволяет клиенту удалить файл указанный в рамках запроса. Нет Да
TRACE Позволяет клиенту отслеживать свой запрос к серверу. Нет Да
OPTIONS Позволяет клиенту определять параметры взаимодействия с сервером. Нет Да

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

Что такое URL?

Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

RFC 2068 расширенный BNF

Я пытаюсь разобрать заголовки запроса авторизации, см. Https://www.ietf.org/rfc/rfc2617.txt раздел 3.2.2. Там, дайджест-ответ определяется следующим образом:

Расширенный BNF, который используется здесь, определен в http://www.ietf.org/rfc/rfc2068.txt, раздел 2.1.

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

У меня есть некоторые вопросы относительно определения дайджест-ответа:

1) Является ли приведенный ниже дайджест-ответ действительным (если нет, почему)? username_1, username_2

2) Является ли следующий ответ дайджест действительным (если нет, почему)? имя пользователя, область, nonce, digest-uri

3) Является ли следующий дайджест-ответ действительным (если нет, почему)? username_1, realm, nonce, digest-uri, response, username_2

4) Возьмем возможные постановки для 1 # (a | b) и 1 # (a | [b]), и в чем разница?

Методы HTTP

Практически все, кто связан с веб-разработкой, знают два метода HTTP — это GET и POST. Но кроме этих методов — есть и другие, не менее полезные методы, которые могут пригодится в повседневной работе и облегчить многие ежедневные процессы.Абсолютно любой веб-сервер должен работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501, если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405. Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

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

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

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

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

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

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

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

Метод HEAD

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

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

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

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

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

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

Связывает указанный ресурс с другим ресурсом.

Принципы контроля параметров NGSDH на уровне Ethernet. RFC-2544

Читайте также:

  1. Cостав микрофлоры основных заквасок, применяемых в молочной промышленности. Принципы подбора культур в состав заквасок.
  2. Gigabit Ethernet, 10GE и дальнейшее развитие технологии Ethernet.
  3. I. Понятие, признаки, принципы, цели юридической ответственности.
  4. II. Принципы, требования и гарантии законности.
  5. II.Принципы принятия инвестиционных решений
  6. IX.2.1. ОПИСАНИЕ И АНАЛИЗ ДЕЯТЕЛЬНОСТИ НА УРОВНЕ СИСТЕМЫ
  7. Literal и Encoded Кодирование Параметров
  8. O учет антропометрических и биомеханических параметров человека
  9. Абсолютное и относительное изменение уровней ряда
  10. Автоидентификация в сетях NGSDH.
  11. АВТОКОРРЕЛЯЦИЯ УРОВНЕЙ ВРЕМЕННОГО РЯДА И ВЫЯВЛЕНИЕ ЕГО СТРУКТУРЫ
  12. Автоматизированная система контроля оплаты проезда (АСКОП)

Контроль параметров NGSDH.

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

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

Действительно, для проверки эффективности работы системы NGSDH на уровне передачи и приема пакетного трафика Ethernet достаточно измерить параметры качества образованного в рамках транспортной сети виртуального коридора (рис. 8.1).

Рис. 8.1. Проблема паспортизации виртуальных коридоров.

Здесь нас будут интересовать только параметры качества канального уровня, измеряемые по схеме «точка – точка» от пункта передачи трафика до пункта приема. Шлейфовые измерения параметров качества в виртуальном коридоре Ethernet исключаются в силу технологических особенностей последней.

Современная методология паспортизации параметров качества проработана довольно детально и отражена в рекомендации IETF RFC-2544: «Методология эталонного тестирования для устройств, входящих в состав сети». Рассмотрим эту рекомендацию и ее применимость для решения задачи паспортизации виртуальных коридоров в сети NGSDH.

RFC-2544 определяет множество тестов, которые могут использоваться для определения производительности сетевых устройств или сегментов сетей Ethernet/IP. Все измерения по рек. RFC-2544 относятся к уровню транспортной сети и опираются на понятие тестового канала. Тестовым каналом называется

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

Для производителей оборудования Internet и Ethernet RFC-2544 стал естественной методологией испытаний. В отличие от традиционных базовых услуг TDM и ATM, Ethernet не имеет строгих требований по качеству для каждого класса обслуживания. Необходимые условия тестирования для MAN традиционно ориентировались на параметры пропускной способности, задержки и уровня потери пакетов, а не на битовые ошибки и «пять девяток» надежности. Причина здесь в том, что измерение параметров ошибок (BER) теряет смысл, если передаваемый трафик является пакетным. Коль скоро трафик передается в виде пакетов Ethernet или IP, в составе каждого пакета присутствует контрольная сумма. При идентификации ошибки пакет уничтожается, так что на сторону приемника поступает не загруженная тестовая последовательность, а лишь ее отдельные фрагменты (блоки). С точки зрения пакетной технологии одна или несколько битовых ошибок приводят к одному и тому же результату – пакет уничтожается на стороне прима. Следовательно, методика должна опираться не на количество битовых ошибок в нагрузке, а на количество пакетов, принятых с ошибками или количество потерянных пакетов. В этом коренное отличие пакетного трафика от трафика TDM с точки зрения нормирования и измерения параметров качества.

RFC-2544 имеет высокую ценность для тестирования качества обслуживания в традиционных сетях, ее значение сопоставимо со значением методик G.821/G.826/M.2100. Методика включает в себя измерения, проводящиеся в режиме имитации, т. е. с генерацией тестовой нагрузки и ее приемом. Всего в методике устанавливается семь групп параметров качества тестового потока:

· Пропускная способность (Throughput – Th)

· Задержка передачи данных (Latency – Lat) и ее производные параметры: девиация задержки (Latency Deviation – LD) и изменение задержки во времени (Latency over Time — LoT)

· Количество ошибок в потоке (Frame Errors – FE)

· Количество потерянных пакетов (Frame Loss – FL)

· Параметры качества передачи/приема берстного трафика (Back-to-back frames)

· Время восстановления канала при возникновении неисправности (System Recovery)

· Время восстановления исходного состояния системы (Reset)

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

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

Методика измерений RFC-2544 предполагает несколько методов подключения приборов:

· Использование одного прибора

· Использование двух приборов

Рассмотрим теперь несколько типовых методов организации измерений по методике RFC-2544.

Один измерительный прибор и одно испытуемое устройство.

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

Рис. 8.2. схема организации измерений с одним прибором и одним тестовым устройством.

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

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

Рис. 8.3. Схема организации измерений с одним прибором и несколькими тестовыми устройствами.

Два измерительных прибора и сегмент сети.

Формирование локального шлейфа в сети Ethernet представляет собой довольно сложную процедуру, требующую изменения установок по МАС-адресации потока на всех узлах, через которые проходит тестовый маршрут. В большой сети, где требуются регулярные измерении для паспортизации разных виртуальных коридоров, формировать для каждого такого измерения логический шлейф представляется очень трудоемким. По этой причине в методике рек. RFC-2544 было предложено несколько схем, использующих принципы организации измерений по схеме «точка – точка». Использование таких схем уменьшает объем необходимых подготовительных работ при проведении измерений и соответствует специфике эксплуатационного тестирования.

Рис. 8.4. Методика организации измерений по схеме «точка – точка».

Наиболее простая схема организации измерений представлена на рис. 8.4. Согласно ей используется два прибора: один выступает генератором тестового потока пакетов, другой – анализатором параметров качества. Эта методика накладывает ограничения на перечень измеряемых параметров. Например, для измерения параметра Lat передатчик и приемник тестового потока должны иметь синхронизацию по абсолютному времени не хуже 1 мкс, что в реальной практике едва ли достижимо. Поэтому при выполнении измерений в соответствии с рис. 8.4 абсолютные параметры задержки Lat не измеряются, а измеряются только относительные параметры LD и LoT.

Методика организации измерений по удаленному шлейфу.

Ограничения на перечень измеряемых параметров при выполнении тестов в режиме «точка – точка» представляют собой неприятное последствие схемы рис. 8.4. Параметр абсолютной задержки Lat является принципиальным для многих интерактивных услуг, и невозможность его измерения объективно ограничивает применение методики. Для нахождения компромисса между схемой рис. 8.4 и решением вопроса о временной синхронизации была разработана схема организации измерений с удаленным шлейфом (рис. 8.5). Согласно этой схеме, на удаленном конце приемника тестового потока устанавливается устройство, которое осуществляет логическое шлейфообразование, преобразуя поля адресации пакетов. Затем поток тестовых пакетов передается в обратном направлении на порт приемника основного анализатора. В результате измеряется полная спецификация параметров качества рек. RFC-2544. Использование одного прибора в качестве генератора и анализатора тестового потока устраняет требование временной синхронизации, так что параметр Lat может измеряться точно. Формирование шлейфа на удаленном конце за счет использования специального устройства решает вопрос об изменении установок в сети. Действительно, при формировании виртуального коридора в сети Ethernet он обычно существует в виде дуплексного канала, так что нет необходимости прописывать по сети обратный маршрут. Единственное изменение в конфигурации касается устройства удаленного шлейфа, но оно не является частью сети и обычно конфигурируется дистанционно. Следовательно, выполнение измерений не требует изменения установок сетевых элементов и в то же время решает вопрос с измерением Lat. Единственным недостатком методики рис. 8.5 является то, что параметры качества измеряются одновременно в прямом и обратном направлении. В случае, если в прямом и обратном направлении параметры качества не совпадают, т. е. существует анизотропия в параметрах, разделить полученный результат между прямым и обратным направлением не представляется возможным. Пожалуй, это единственный серьезный методический недостаток предложенной схемы. На практике его компенсируют, объединяя схемы рис. 8.4 и 8.5. Ряд приборов для паспортизации потоков Ethernet имеют функции формирования локального шлейфа. Тогда их можно использовать как по схеме рис. 8.4, так и по схеме рис. 8.5. Использование схемы рис. 8.5 позволяет

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


Рис. 8.5. Методика организации измерений с удаленным шлейфом.

Во всех перечисленных методиках используется генерация специализированных пакетов, содержащих временные метки для измерения Lat, LD, LoT, и нумерацию следования для измерения FE, FL. Поток таких пакетов можно рассматривать как тестовый канал. В общем случае тестовый поток «растекается» по сети Ethernet, чтобы потом собраться на стороне приемника. В случае NGSDH и тестирования отдельных виртуальных коридоров поток пакетов находится в определенной виртуальной трубе. Тестовый поток имеет ряд параметров:

· Уровень загрузки виртуального коридора – GAP

· Размер кадра – L

· Приоритетность кадров – Pr

· Параметры полей, связанные с верхними уровнями (HTTP, SMTP, IP и пр.)

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

Уровень загрузки виртуального коридора GAP

Параметр GAP определяет уровень загрузки виртуального коридора. GAP представляет собой защитный интервал между пакетами. В данном случае это параметр, определяющий уровень загрузки виртуального коридора тестовым трафиком. Например, для измерений можно загрузить весь виртуальный коридор (100%), а можно использовать и часть ресурса (10 – 15%). С параметром GAP уровень загрузки ресурса связан обратным соотношением: чем больше GAP, тем меньше загружен ресурс. Можно использовать как абсолютные единицы GAP (мксек), так и относительные (%).

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

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

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

Согласно классической методике RFC-2544 рекомендуется проводить измерения для нескольких значений размеров кадра L: 64, 128, 256, 512, 1024, 1280 и 1518 байтов. Каждое измерение проводится отдельно для каждого размера кадра или параллельно с использованием методики смешанного трафика. Для систем, использующих пакеты расширенного размера (Jumbo frame) 4096 или 9000 байтов, измерения проводятся по дополнительным методикам, представляющим собой модификации методики RFC-2544.

Приоритетность кадров Pr

Приоритетность тестового потока Pr определяется параметрами приоритетов отдельных кадров. Обычно приоритетность связана с тремя классификационными иерархиями: ToS (Type of Services), DiffServ и VLAN. Тип иерархии устанавливается для всей схемы формирования трафика. Приоритетность внутри VLAN представляет собой отдельную схему установления приоритетов в том случае, если передаваемый тестовый трафик поддерживает VLAN. ToS и DiffServ являются альтернативными схемами установки приоритетов, принятыми в системах адресации IPv4 и IPv6. Все приоритеты отдельных кадров используются в системе коммутации. Трафик более высокого приоритета имеет преимущества в системе коммутации и обслуживается сетевыми элементами в первую очередь. Приоритетность трафика всегда связана с типом услуг, для которых трафик передается. Примерами трафика высокого приоритета являются трафик VoIP или передачи видеоинформации.

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

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

Наличие адресации канального уровня является важной особенностью технологии Ethernet, соответственно, МАС-адреса передатчика и приемника являются важными параметрами любого тестового потока. В одном виртуальном коридоре могут существовать несколько тестовых потоков кадров, отличающихся параметрами МАС-адресов передатчиков и приемников (рис. 8.6 сверху). В процессе проведения измерений параметры МАС-адресации приемника и передатчика могут быть как фиксированными, так и переменными. В качестве примера на рис. 8.6 снизу показан пример переменного значения МАС-адреса приемника. В результате тестовый поток распространяется на стороне приемника «веером». Такой режим называется режимом сканирования по МАс-адресам приемника. Существует возможность установок аналогичного режима по МАС-адресам передатчика.

Параметры полей, связанные с верхними уровнями (HTTP, SMTP, IP и пр.)

Помимо параметров канального уровня (поля VLAN и МАС-адресация) тестовый поток может содержать необходимые поля верхних уровней, к которым относятся:

· IP-адресация (адресация сетевого уровня)

· Параметры специализированных полей транспортного уровня (например, параметры MPLS)

· Параметры поддерживаемой сигнализации (HTTP, TCP, UDP, SMTP и пр.)

Определения методов / rfc 2068

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Примечание IESG

Этот документ является воспроизведением RFC 1944 с корректировкой значений IP-адресов, которые были выделены для использования по умолчанию оборудованием для тестирования сетей (см. параграф C.2.2 ). Данный документ заменяет собой утративший силу RFC 1944.

Тезисы

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

1. Введение

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

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

Предшествующий документ «Benchmarking Terminology for Network Interconnect Devices» (RFC 1242) содержит определения множества терминов, используемых в этом документе. Рекомендуется прочесть документ, содержащий определения используемых терминов.

2. Реальный мир

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

3. Тесты для выполнения

В этом документе рассматривается множество текстов. Не каждый из рассмотренных тестов применим ко всем типам тестируемых устройств (DUT, device under test). Производителям следует проводить все тесты, которые могут поддерживаться конкретным типом продукции. Авторы понимают, что выполнение всех тестов во всех рекомендуемых условиях потребует достаточно продолжительного времени. Мы надеемся, что результаты этих тестов послужат оправданием затраченных сил. В Приложении A перечислены некоторые тесты и условия, которые по мнению авторов следует включать в конкретных случаях.

4. Оценка результатов

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

5. Требования

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

Должно (MUST) — это слово, а также слова требуется (REQUIRED) и нужно (SHALL) означает, что элемент является безусловно необходимым; Следует (SHOULD) — это слово, а также глагол рекомендуется (RECOMMENDED) используются в тех случаях, когда в определенных обстоятельствах требования допускается игнорировать, но делать это следует с пониманием и учетом всех обстоятельств; Возможно (MAY) — это слово, а также слово необязательно (OPTIONAL) используется для обозначения требований, выполнение которых отдается на усмотрение тестирующего; одни производители будут включать такие требования в связи с запросами рынка или по той причине, что это подчеркнет сильные стороны их продукции, а другой производитель может игнорировать такие требования.

Реализация, в которой не выполняется одно или несколько обязательных требований (должно — MUST), считается «не соответствующей» требованиям. Реализация, в которой выполняются все обязательные требования и рекомендации, считается «полностью соответствующей» требованиям, а реализация, в которой выполнены все обязательные требования, но не выполняется часть рекомендаций, считается «условно соответствующей».

6. Организация теста

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

6.1. Организация теста для разнотипных сред

При тестировании DUT, которые используются в реальных сетях для подключения к разнотипным средам (например, ЛВС Ethernet к магистрали FDDI), могут использоваться два варианта конфигурации. Тестер может поддерживать оба типа сред и в этом случае может использоваться конфигурация, показанная на рисунке 1.

В другом варианте используется два идентичных DUT (Рисунок 3). Во многих случаях такая конфигурация может более точно имитировать реальные ситуации. Примером может служить соединение двух ЛВС по каналу WAN или высокоскоростной магистрали. Однако такая конфигурация не будет в должной мере соответствовать случаям, когда клиенты из ЛВС Ethernet взаимодействуют с сервером на магистрали FDDI.

7. Настройка DUT

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

8. Форматы кадров

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

9. Размеры кадров

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

Теоретически минимальный кадр запроса UDP Echo будет содержать заголовок IP (не менее 20 октетов), заголовок UDP (8 октетов) и заголовок уровня MAC в соответствии с требованиями среды. Теоретический максимум для размера кадра определяется размером поля длины в заголовке IP. Почти во всех случаях значения минимального и максимального размера кадров задаются ограничениями среды.

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

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

9.1. Размеры кадров Ethernet

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

9.2. Размеры кадров Token Ring 4/16 Мбит/с

Рекомендации по размерам кадров Token Ring предполагают отсутствие поля RIF в кадрах маршрутизируемых протоколов. Поле RIF будет присутствовать во всех тестах производительности мостов source route. Минимальный размер кадра для UDP в сети Token Ring составляет 54 октета. Для Token Ring 16 Мбит/с рекомендуется максимальный размер в 4472 октета вместо теоретического максимума 17,9 кбайт, поскольку многие интерфейсы Token Ring вносят такое ограничение. Остальные рекомендуемые значения выбраны для обеспечения возможности прямого сравнения между двумя разными типами сред. В дополнение могут использоваться кадры IP (т. е., не UDP), если желательно обеспечить наиболее высокую скорость передачи кадров, требующую снижения размера кадров до 46 октетов.

9.3. Размеры кадров FDDI

Минимальный размер кадра для UDP в среде FDDI составляет 53 октета, но рекомендуется использовать минимальный размер 54, обеспечивающий возможность прямого сравнения с Token Ring. В качестве максимального размера рекомендуется использовать 4472 октета взамен рекомендуемого значения 4500, чтобы обеспечить возможность прямого сравнения с Token Ring. При необходимости обеспечить наиболее высокую скорость передачи кадров, можно использовать пакеты IP (т. е., не UDP), позволяющие сократить размер кадра до 45 октетов.

9.4. Размеры кадров в присутствии несоразмерных MTU

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

Например, тестирование пересылки IP мостом или маршрутизатором, связывающим сети FDDI и Ethernet, следует использовать размеры кадров FDDI при передаче из сети FDDI в канал Ethernet. Если мост не поддерживает фрагментации IP, скорость пересылки кадров, которые слишком велики для Ethernet, следует указывать в отчете с нулевым значением.

10. Проверка полученных кадров

Тестовому оборудованию следует отбрасывать все полученные во время теста кадры, которые не относятся к тестированию. Например, кадры keep-alive и кадры маршрутных обновлений не следует включать в число принятых кадров. Во всех случаях тестовому оборудованию следует проверять размер принятых кадров на предмет соответствия ожидаемому значению.

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

11. Изменение условий тестирования

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

11.1. Широковещательные кадры

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

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

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

11.2. Кадры управления

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

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

11.3. Кадры маршрутных обновлений

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

Кадры маршрутных обновлений следует передавать с частотой, указанной в Приложении C для конкретного протокола, который будет использоваться при тестировании. В Приложении C приведены два примера кадров маршрутных обновлений для использования TCP/IP в среде Ethernet. Кадры обновлений предназначены для обновления маршрутизации во множество сетей, которые не участвуют в пересылке тестовых данных. Первый кадр устанавливает таблицу маршрутизации в состояние A, а второй переводит ее в состояние B. Кадры должны чередоваться в течение испытания.

В процессе тестирования следует удостовериться, что маршрутные обновления были обработаны устройством DUT.

11.4. Фильтры

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

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

Для мостов следует использовать фильтры вида:

После этого для DUT следует задать 25 фильтров. Для первых 24 фильтров следует использовать форму:

Для 24 входных и выходных протокольных адресов не следует использовать какие-либо адреса, присутствующие в тестовом потоке данных. В последнем фильтре следует разрешить пересылку тестового потока данных. Порядок включения фильтров выбран таким, чтобы выполнялось 25 проверок до принятия решения о пересылке кадра. Если DUT меняет порядок фильтров или не использует линейного просмотра правил, упорядочение фильтров при вводе будет утрачено.

Точную конфигурацию фильтров следует включать в отчет о результатах тестирования.

11.4.1 Адреса в фильтрах

Для фильтров требуется два набора адресов — один для случая с одним фильтром и другой для 25 фильтров.

Одиночному фильтру следует разрешать трафик с IP-адреса 198.18.1.2 на адрес 198.19.65.2 и отвергать весь остальной трафик.

В случае с 25 следует использовать приведенный набор фильтров.

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

12. Протокольные адреса

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

13. Организация маршрутов

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

14. Двунаправленный трафик

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

15. Один путь для потока

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

16. Множество портов

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

Рассмотрим 6-портовое устройство DUT, показанное на рисунке.

Для потоков данных следует задавать показанную ниже адресацию:

  • поток, передаваемый на вход A:
  • пакеты в выходные интерфейсы X, Y, Z
  • поток, передаваемый на вход B:
  • пакеты в выходные интерфейсы X, Y, Z
  • поток, передаваемый на вход C
  • пакеты в выходные интерфейсы X, Y, Z

Отметим, что во всех этих потоках используются одинаковые последовательности, поэтому сначала будут одновременно приходить 3 пакета на интерфейс X, затем 3 на интерфейс Y и после этого — 3 на Z. Такая процедура обеспечивает близкое соответствие реальным сетям и DUT будет иметь дело одновременно с множеством пакетов, адресованных в один выход.

17. Множество протоколов

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

18. Множество размеров кадров

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

19. Тестирование более одного DUT

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

Эта модель полезна в тех случаях, когда кадры на входе и выходе однотипны (например, 64-байтовые пакеты IP в кадрах 802.3 на входе и выходе DUT) или метод тестирования может различать разнотипные входы и выходы (например, 1518-байтовые пакеты IP в кадрах 802.3 на входе и 576-байтовые фрагменты IP в кадрах X.25 на выходе).

При расширении теста для случая нескольких DUT могут собираться результаты, относящиеся ко множеству DUT или гетерогенным средам. В таком расширенном тесте одно устройство DUT заменяется системой соединенных через сеть DUT. Такая методология позволяет тестировать множество комбинаций из устройств/сред/протоколов/служб. Например, конфигурация теста ЛВС-WAN-ЛВС может иметь вид:

Или может тестироваться смешанная конфигурация ЛВС:

В обоих примерах (1 и 2) можно эмпирически оценить сквозные параметры каждой системы. , end-to-end benchmarks of each system could be empirically ascertained. Для оценки других параметров могут служить промежуточные устройства. В примере 2 можно оценить возможности передачи данных между сетями FDDI через DUT 2.

Поскольку множество DUT трактуется как единая система, у такой методологии имеются ограничения. Например, можно получить агрегированные параметры для тестируемой системы в целом, однако результаты теста могут не отражать асимметрию поведения устройств DUT, задержки, вносимые другими устройствами (например, CSU/DSU, коммутаторами) и т. п.


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

20. Максимальная скорость передачи кадров

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

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

Список максимальных скоростей передачи кадров для соединений ЛВС приведен в Приложении B.

21. Пиковый трафик

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

Задачей такого теста является определение минимального интервала между пиками, при котором DUT еще сможет обрабатывать трафик без потери пакетов. В процессе тестирования число пакетов в каждом пике сохраняется постоянным, а варьируется интервал между пиками. Тесты следует выполнять для пиков, содержащих 16, 64, 256 и 1024 кадра.

22. Число кадров на маркер

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

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

23. Описание испытания

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

Если DUT представляет собой маршрутизатор, сначала передается обновление маршрутных данных на «входной» порт и задается пауза в две секунды для пересчета маршрутов.

Передаются «кадры обучения» в «выходной порт» и устанавливается пауза в две секунды для завершения самообучения моста. Обучающие кадры для моста представляют собой кадры, в которых адреса отправителя совпадает с адресом получателя, используемым в тестовых кадрах. Кадры обучения для других протоколов служат для заполнения таблицы преобразования адресов в DUT. Для эти кадров следует использовать форматы, указанные в документе Test Frame Formats.

Устанавливается пауза в две секунды для получения всех остающихся в сети кадров.

Устанавливается пауза не менее пяти секунд для стабилизации DUT.

24. Продолжительность испытания

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

25. Преобразование адресов

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

26. Тестирование производительности

Примечание: Слова «тип потока данных» говорят об описанных выше модификациях потока кадров с постоянным межкадровым интервалом (например, добавление фильтров трафика в конфигурацию DUT.

26.1. Пропускная способность

Определение пропускной способности DUT в соответствии с RFC 1242.

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

Пропускная способность определяется максимальной скоростью, при которой число кадров, переданных DUT, еще равно числу кадров, переданных тестовым оборудованием.

Результаты теста пропускной способности следует представлять в виде графика. В этом случае по оси x следует указывать размер кадров, а по оси y — скорость передачи кадров. На графике следует указывать по крайней мере две линии, одна из которых показывает теоретическое значение скорости передачи кадров разного размера для данного типа среды. С помощью второй линии следует показывать реальные результаты теста. Можно также выводить дополнительные графики, показывающие результаты теста для разных типов потока данных. В сопровождающем график тексте следует указывать протокол, тип потока данных и тип среды, использованные при тестировании.

Мы предполагаем, что если для рекламных целей требуется одно значение производительности, производитель будет выбирать минимальный размер кадров для среды. В таких случаях результат должен выражаться числом кадров в секунду. Скорость также может указываться в битах (или байтах) в секунду. Заявленная производительность должна включать: a) измеренное значение максимальной скорости передачи кадров, b) размер использованных кадров, c) теоретический предел скорости для данной среду при использованном размере кадров и d) протокол, использованный для тестирования. Даже в тех случаях, когда для рекламных целей используется одно значение в описание продукции следует включать всю таблицу результатов тестирования пропускной способности.

26.2. Задержка

  • Цель: Определение задержки в соответствии с RFC 1242.
  • Процедура: Сначала определяется пропускная способность DUT для каждого размера кадров из списка. После этого через DUT передается поток кадров заданного размера с определенной полосой (пропускная способность), адресованных одному получателю. Продолжительность потока следует делать не менее 120 секунд. После 60 секунд испытания в поток следует включить идентификационную метку, тип которой зависит от реализации. Время завершения передачи этой метки фиксируется (время A). Логика приемной части тестера должна распознавать метку в потоке кадров и фиксировать время завершения приема кадра с меткой (время B).

Задержка составляет разницу значений B и A в соответствии с определением RFC 1242 (а именно, задержка для устройств пересылки или пересылки с промежуточным сохранением).

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

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

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

26.3. Частота потери кадров

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

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

((input_count — output_count) * 100) / input_count

Первое испытание следует проводить при максимальной скорости для данного размера кадров во входной среде. При следующих испытаниях скорость снижается сначала до 90% от максимальной скорости, а затем до 80%. Снижение скорости на 10% следует повторять, пока не будет зафиксировано два результата без потери кадров. Гранулярность снижения скорости должна быть не более 10% от максимальной скорости; приветствуется снижение скорости с меньшим шагом.

Результаты определения частоты потери кадров следует представлять в форме графика. В этом случае по оси X должна указываться скорость передачи кадров на входе в процентах от теоретического максимума для данной среду при конкретном размере кадров. По оси Y должны указываться потери кадров в процентах. Начальные точки обеих осей должны соответствовать нулевым значениям, а конечные — 100 %. На графике могут выводиться несколько линий, соответствующих потерям кадров различного размера, разных протоколов и типов потока данных.

Примечание: В разделе 18 рассмотрены максимальные значения скорости передачи кадров, которые следует использовать.

26.4. Кадры, передаваемые с минимальными интервалами

Определение возможностей DUT по обработке кадров back-to-back в соответствии с определением RFC 1242.

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

Значение back-to-back определяется числом кадров в максимальном пакете, который устройство DUT смогло обработать без потери кадров. Продолжительность испытания должна быть не менее 2 секунд, а испытания следует повторять не менее 50 раз с усреднением значений.

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

26.5. Восстановление системы

Определение скорости восстановления DUT после перегрузки.

Сначала определяется пропускная способность DUT для каждого из перечисленных размеров кадра.

Передается поток кадров со скоростью 110% от пропускной способности или максимальной скоростью среды (выбирается меньшее из 2 значений) в течение по крайней мере 60 секунд. В момент A интенсивность трафика снижается вдвое и записывается момент последней потери кадра (момент B). Время восстановления системы определяется как разность времен B и A. Тест следует повторить многократно и включить в отчет среднее время восстановления.

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

26.6. Перезагрузка

Определение скорости восстановления DUT после программного или аппаратного сброса (перезагрузки).

Сначала определяется пропускная способность DUT для кадров минимального размера в соответствии с используемой для тестирования средой.

Передается непрерывный поток кадров с определенной пропускной способностью для минимального размера кадров. Выполняется сброс DUT с мониторингом выходного порта с записью времени последнего кадра перед сбросом (момент A) и первого кадра после сброса (момент B). При тестировании сброса по прерыванию питания выполняются такие же операции, но перезагрузка заменяется отключением питания DUT на 10 секунд.

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

Время перезагрузки определяется как разность между моментами B и A.

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

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

27. Вопросы безопасности

Вопросы безопасности не рассматриваются в этом документе.

Адреса редакторов

Scott Bradner
Harvard University
1350 Mass. Ave, room 813
Cambridge, MA 02138
Phone: +1 617 495-3864
Fax: +1 617 496-8500
EMail: ude.dravrah@bos

Jim McQuaid
NetScout Systems
4 Westford Tech Park Drive
Westford, MA 01886
Phone: +1 978 614-4116
Fax: +1 978 614-4004
EMail: moc.tuocsten@jdiauqcm

Приложение A: Рассмотрение тестов

A.1. Роль этого приложения

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

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

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

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

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

Производительность сетей WAN может тестироваться путем установки двух идентичных устройств, соединенных с помощью модемов для имитации каналов WAN. Производительность измеряется между интерфейсами ЛВС двух устройств DUT.

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

Приложение B: Максимальные скорости передачи кадров

(Предоставил Roger Beeman, Cisco Systems)

Приложение C: Форматы тестовых кадров

В этом приложении описаны форматы кадров, которые могут использоваться для тестирования. Кроме того, здесь приведены параметры TCP/IP в сетях Ethernet при использовании для тестирования.

C.1. Введение

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

C.2. Информация TCP/IP

В последующих параграфах приведена информация, связанная со стеком протоколов TCP/IP.

C.2.1. Тип кадров

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

Для TCP/IP используются UDP-дейтаграммы Echo Request.

C.2.2. Протокольные адреса

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

Для этой цели агентством IANA были выделены сетевые адреса с 192.18.0.0 по 198.19.255.255, закрепленные за BMWG. Такое выделение адресов было предпринято для минимизации вероятности возникновения конфликтов при случайном подключении тестовой зоны к сети Internet. Специфика использования адресов рассмотрена ниже.

C.2.2.1. Протокольные адреса портов маршрутизаторов

Половину портов многопортового маршрутизатора мы называем «входными», а остальные — «выходными», даже в тех случаях, когда отдельные тесты используют все порты в качестве входных или выходных. Для «входных» портов резервируется непрерывный блок адресов в сетях класса C от 198.18.1.0 до 198.18.64.0. Второй блок (от 198.19.1.0 до 198.19.64.0) выделяется для «выходных» потов. Во всей случаях порт маршрутизатора является узлом 1 соответствующей сети. Например, 2-портовое устройство DUT будет иметь IP-адрес 198.18.1.1 на одном порту и 198.19.1.1 — на другом.

Некоторые из описанных тестов используют управляющее соединение с DUT по протоколу SNMP. Предполагается что для интерфейса управления DUT выделяется первый адрес из числа «входных» (198.18.1.1).

C.2.2.2. Адреса в кадрах

Некоторые из описанных тестов (например, проверка времени перезагрузки) предполагают маршрутизацию смежных сетей. IP-адрес в используемых для такого теста кадрах относится к узлу 2 соответствующей сети класса C (например, 198.19.1.2).

Если тест включает маршрутизацию несмежных сетей, фантомный маршрутизатор задается как узел 10 в соответствующей сети класса C. Группа сетей класса C от 198.18.65.0 до 198.18.254.0 используется для адресации устройств в сетях, доступных через фантомные маршрутизаторы на «входной» стороне DUT. Сети класса C от 198.19.65.0 до 198.19.254.0 выделены для адресации устройств, видимых через фантомные маршрутизаторы на «выходной» стороне DUT.

C.2.3. Частота маршрутных обновлений

Интервал обновления для каждого протокола маршрутизации может определяться спецификациями соответствующего протокола. Для IP RIP, Cisco IGRP и OSPF кадр или кадры маршрутных обновлений следует передавать за 5 секунд до каждого тестового потока. Такой частоты передачи обновлений достаточно для испытаний, продолжительностью до 60 секунд. При более длительных испытаниях кадры маршрутных обновлений следует включать в поток тестовых кадров. Периодичность передачи обновлений показана ниже.

IP-RIP 30 секунд
IGRP 90 секунд
OSPF 90 секунд

C.2.4. Детальное обсуждение форматов кадров

C.2.4.1. Кадры обучения

В большинстве протоколов используется процедура отображения протокольных адресов на адреса MAC. В стеке TCP/IP для этого служит протокол преобразования адресов ARP. Для XNS и IPX такая процедура не требуется, поскольку MAC-адрес используется в качестве протокольного адреса узла.

В идеальном случае тестер будет способен отвечать на запросы ARP от DUT. В тех случаях, когда это невозможно, запросы ARP следует передавать в «выходной» порт маршрутизатора. Такой запрос следует рассматривать, как исходящий от конечного адресата тестового потока (т. е., фантомного маршрутизатора, как показано на рисунке 4 или конечного узла, если используется маршрутизация в смежную сеть). Предполагается, что маршрутизатор будет кэшировать MAC-адреса запрашивающих узлов. Запрос ARP следует передавать за 5 до начала передачи тестового потока в каждом испытании. Испытания продолжительностью более 50 могут потребовать увеличения тайм-аута ARP на маршрутизаторе.

C.2.4.2. Кадры маршрутных обновлений

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

C.2.4.3. Кадры запросов управления

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

C.2.4.4. Тестовые кадры

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

C.2.4.5. Форматы кадров — TCP/IP в сети Ethernet

Каждый из рассмотренных ниже кадров описывается для первой пары портов DUT («входного» порта 1 и «выходного» порта 1). Если кадры используются для других портов, адреса должны быть соответственно изменены.

C.2.6.1. Кадр «обучения»

Запрос ARP в сети Ethernet

C.2.6.2. Кадр маршрутных обновлений

C.2.4.6. Кадр управляющего запроса

C.2.6.4. Тестовые кадры

Запрос UDP echo в среде Ethernet

Значения, используемые с полях общего размера и размера сообщений UDP:

Перевод на русский язык

Николай Малых, moc.milib@hkylamn

Подведены итоги голосования по смене названия дистрибутива openSUSE. Подавляющее большинство разработчиков openSUSE (225 против 42) проголосовали против смены имени. В ходе голосования приняли участие 54% разработчиков, имеющих право голоса.

Илон Маск рекомендует:  Проверка поля логина на javascript
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
НОВОСТИ: Разработчики openSUSE проголосовали против смены имени проекта Fri, 08 Nov 2020 18:44:23 +0300