Ключевые характеристики DNS

DNS обладает следующими характеристиками:

• Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
• Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
• Кэширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Протокол HTTP

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

В сети Интернет используются разные протоколы:

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

POP3 — это стандартный протокол почтового соединения. Серверы POP обрабатывают входящую почту, а протокол POP предназначен для обработки запросов на получение почты от клиентских почтовых программ.

HTTP — это протокол передачи гипертекста. Протокол HTTP используется при пересылке Web-страниц между компьютерами, подключенными к одной сети.

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.

Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

*Потребителей (клиентов), которые инициируют соединение и посылают запрос;

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

HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика составила 46 %, из которых почти половина — это передача потокового видео и звука.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (в частности, для этого используется HTTP-заголовок). Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

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

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

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

Google Chrome;

Mozilla FireFox;

Opera;

Internet Explorer;

Яндекс Браузер;

Safari.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

1)Стартовая строка (англ. Starting line) — определяет тип сообщения;

2)Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;

3)Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

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

Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI — для версии протокола 0.9;

Метод URI HTTP/Версия — для остальных версий.

Здесь:

Метод (англ. Method) — тип запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список методов для версии 1.1 представлен далее.

URI определяет путь к запрашиваемому документу.

Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0.

Чтобы запросить страницу данной статьи, клиент должен передать строку (задан всего один заголовок):

GET /wiki/HTTP HTTP/1.0

Host: ru.wikipedia.org

Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:

Версия — пара разделённых точкой цифр, как в запросе;

Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента;

Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Тело HTTP-сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. В теле могут передаваться сущности разных форматов (текст, графика, видео и т. д.) как вместе, так и по отдельности. Так как HTTP-сообщение – это текст, то бинарные файлы передаются в закодированном виде.

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные коды ответа:

202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.

204 No Content: в теле ответа нет сообщения.

205 Reset Content: указание серверу о сбросе представления документа.

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

3xx: Перенаправление

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

301 Moved Permanently: ресурс теперь можно найти по иному URL адресу.

303 See Other: ресурс временно можно найти по иному URL адресу. Заголовок Location содержит временный URL.

304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Entity Tag).

4xx: Клиентские ошибки

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

400 Bad Request: вопрос был сформирован неверно.

401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.

402 Payment Required: «необходима оплата».

403 Forbidden: сервер не открыл доступ к ресурсу.

404 Not Found: «не найдено». Ошибка 404 или Not Found («не найдено») — стандартный код ответа HTTP о том, что клиент был в состоянии общаться с сервером, но сервер не может найти данные согласно запросу. Ошибку 404 не следует путать с ошибкой «Сервер не найден» или иными ошибками, указывающими на ограничение доступа к серверу. Ошибка 404 означает, что запрашиваемый ресурс может быть доступен в будущем, что однако не гарантирует наличие прежнего содержания.

Пользователи наиболее часто сталкиваются с ошибкой 404 при посещении так называемых «битых» или «мёртвых ссылок», что делает, таким образом, ошибку 404 одной из наиболее узнаваемых ошибок в сети Интернет.

405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.

409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

410 Gone: «удалён». Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа (например копии). Появился в HTTP/1.1.

411 Length Required: «необходима длина».

412 Precondition Failed: «условие ложно».

413 Payload Too Large: «полезная нагрузка слишком велика».

414 URI Too Long: «URI слишком длинный».

426 Upgrade Required: «необходимо обновление».

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.

502 Bad Gateway: «плохой, ошибочный шлюз». Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

504 Gateway Timeout: «шлюз не отвечает». Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505 HTTP Version Not Supported: «версия HTTP не поддерживается».

506 Variant Also Negotiates: «вариант тоже проводит согласование».

507 Insufficient Storage: «переполнение хранилища.

508 Loop Detected: «обнаружено бесконечное перенаправление».

509 Bandwidth Limit Exceeded: «исчерпана пропускная ширина канала».

510 Not Extended: «не расширено».

511 Network Authentication Required: «требуется сетевая аутентификация»).

520 Unknown Error: «неизвестная ошибка».

521 Web Server Is Down: «веб-сервер не работает».

522 Connection Timed Out: «соединение не отвечает».

523 Origin Is Unreachable: «источник недоступен».

524 A Timeout Occurred: «время ожидания истекло».

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

Для сохранения данных предыдущей сессии при новом соединении клиента с сервером существуют механизмы, которые могут сохранять данные сессии или на стороне клиента, или на стороне сервера. В случае клиентского хранения браузер может их прочитать и передать на сервер в составе HTTP-запроса. Чтобы эти данные нельзя было подменить по пути к серверу, совместно с HTTP используется протокол SSL (Secure Sockets Layer) и это расширение HTTP уже называется HTTPS (HyperText Transfer Protocol Secure).

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

Сервер может использовать любые методы, не существует обязательных методов для сервера или клиента. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Методы HTTP:

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

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

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:

Пример:

GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Кроме обычного метода GET, различают ещё

Условный GET — содержит заголовки If-Modified-Since, If-Match, If-Range и подобные;

Частичный GET — содержит в запросе Range.

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

HEAD: Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая.

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

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

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

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

Кеширование в HTTP не является обязательным, но чаще всего бывает используется для повторного использования сохраненных ресурсов в целях оптимизации. Стандартно в HTTP не могут быть закэшированы данные, запрошенные по безопасному протоколу HTTPS или ответы на запросы с отличным от «GET» методами.

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

В зависимости от расположения кэш может разделяться на:

Частный — (в самом браузере) кэширует имена пользователей, пароли, URL, историю посещения страниц и веб-контент. Как правило, ориентирован на пользователя.

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

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL.

В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.

HTTP/TLS запросы генерируются путём разыменования URI, вследствие чего имя хоста становится известно клиенту. В начале общения сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку человек посередине.

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

54.

Коды аутентификации сообщений – МАС (Message Authentication Code)

Аутентификация - подтверждение того, что информация получена от законного источника.

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

MAC = CK(M)

Свойства функции CK (M):

- вычислительно трудно, зная М и СK (M), найти сообщение М', такое, что СK(M) = СK(M')

- значения СK(M) должны быть равномерно распределенными, т.е. для любых сообщений М и M' вероятность того, что СK(M) = СK(M'), должна быть равна , где n - длина значения МАС.

Методы аутентификации:

парольные (PIN коде и т.д.) - уникальная последовательность символов, которую пользователь должен знать.

"ключе" - в случае электронных систем это электронный ключ, который хранится на носителе (смарт-карты, электронные таблетки iButton, USB-токены и т. д.)

биометрические (отпечаток пальца, рисунок радужной оболочки глаза, форма лица, параметры голоса и т. д.)

криптографические

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

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