Уважаемые друзья! Мы стараемся максимально предоставить помощь для наших посетителей.
Раздел помощи будет совершенствоваться, но уже сегодня мы готовы предоставить Вам ответы на важные вопросы.
Термин "RAID" был предложен в 1987 году Паттерсоном (David A. Patterson), Гибсоном (Garth A. Gibson) и Кацем (Katz).
(Randy H. Katz) - это аббревиатура от английского Redundant Array of Understand Disks ("избыточный массив недорогих дисков").
В своей презентации они аргументировали свое изобретение относительно низкой стоимостью набора дешевых дисков
предназначены для персональных компьютеров, в отличие от дисков большой емкости, которые они называли
«SLED» (Один большой дорогой накопитель).
Позже трактовка термина изменилась на избыточный массив независимых дисков (redundant array of independent Disks
(независимые) диски), поскольку в массивах часто использовались дорогостоящие серверные диски.
RAID 0 (striping — "чередование") - это дисковый массив из двух или более жестких дисков без избыточности.
Информация делится на блоки данных фиксированной длины и записывается на оба/несколько дисков по очереди, то есть
один блок на первый диск, а второй блок на второй диск, соответственно.
Уровень основан на разделении информации на блоки с одновременной записью разных блоков на разные диски.
Технология значительно увеличивает скорость чтения и записи, при этом пользователь может использовать суммарный
объем всех накопителей. Есть один недостаток — отказоустойчивость стремится к нулю, т.е. восстановить поврежденные
HDD/SSD-накопители будет уже невозможно.
Для реализации такого решения вам понадобится как минимум 2 диска.
RAID 1 (зеркальное отображение— это массив из двух дисков, являющихся полными копиями друг друга.
Не путать с RAID 1+0 (RAID 10 С), поддержка RAID 0+1 (RAID-массива 01) массивы, которые используют больше
сложные механизмы зеркалирования.
Этот метод уже основан на полном дублировании данных на нескольких носителях.
Принцип прост и железобетонен с точки зрения надежности, но при использовании двух дисков емкостью по 2 ТБ
вы получаете только одного работника. Второй становится невидимым для системы — только для RAID-контроллера.
Процесс также не дает никаких преимуществ в скорости, но отказоустойчивость повышается в несколько раз.
Если одному из жестких дисков/SSD-накопителей было приказано работать в течение длительного времени, его полное
воспроизведение происходит на втором носителе.
Процессы записи, удаления и копирования происходят параллельно. Из этого следует один нюанс: информация была стерта
с одного жесткого диска, на втором она автоматически исчезает.
Для реализации такого решения вам понадобится как минимум 2 диска.
RAID 2 массивы такого типа основаны на использовании кода Хэмминга. Диски делятся на две группы:
для данных и для кодов исправления ошибок, и если данные хранятся на двух дисках, то необходимо хранить коды исправления
как минимум на трех дисках. Общее количество дисков в этом случае будет равно трем. Данные распределены по дискам
предназначенные для хранения информации таким же образом, как и в RAID 0, то есть они разделены на небольшие блоки в
соответствии с количеством дисков.
На остальных дисках хранятся коды исправления ошибок, согласно которым, в случае выхода из строя любого жесткого диска, возможно
восстановление информации.
Для реализации такого решения необходимо как минимум 3 диска.
В дисковом массиве RAID 3 данные разбиваются на блоки размером меньше сектора (разбиваются на байты) и распределяются
на двух дисках. Другой диск используется для хранения блоков контроля четности.
Этот унифицированный формат организации дискового массива использует чередование и выделяет один диск из доступного пула
запоминающих устройств для хранения информации о четности, которая отвечает за проверку целостности путем определения
независимо от того, были ли данные потеряны или перезаписаны при непосредственном перемещении из одного места хранения в другое
или во время передачи между компьютерами.
Для реализации такого решения вам понадобится как минимум 3 диска.
RAID 4 похож на RAID 3, но отличается от него тем, что данные разбиваются на блоки, а не на байты. Таким образом,
частично удалось "победить" проблему низкой скорости передачи данных небольшого объема. Запись выполняется
медленно из-за того, что четность для блока генерируется во время записи и записывается на один диск.
Для реализации такого решения вам потребуется как минимум 3 диска.
RAID 5 представляет собой дисковый массив с чередующимися блоками данных и контролем четности.
Основным недостатком RAID уровней со 2-го по 4-й является невозможность создания параллельных
операции записи, поскольку для хранения информации о четности используется отдельный управляющий диск.
RAID 5 лишен этого недостатка. Блоки данных и контрольные суммы циклически записываются на все диски.
Конечно, асимметрии в конфигурации дисков нет. Технология считается одной из самых распространенных и безопасных,
потому что он работает на принципах четности и чередования. Чтобы создать пятый Raid, у вас должно быть как минимум 3 диска.
Во время записи данные делятся на блоки, с особым условием: на один из дисков, называемый блоком
контроля четности (Parity Drive/PD), записывается информация для дальнейшего восстановления. На случай, если что-то пошло не так по
вине пользователя или из-за устаревания накопителей в целом.
Удобство RAID 5 заключается в том, что его можно реализовать как аппаратно, так и программно с помощью соответствующих утилит
поставляемых в комплекте с операционной системой. Однако любой толковый специалист скажет, что жесткий вариант гораздо безопаснее.
Для реализации такого решения вам понадобится как минимум 4 диска.
RAID 6 представляет собой массив из четырех или более дисков с проверкой четности P+Q или DP, предназначенный для защиты
от потери данных при одновременном выходе из строя двух жестких дисков в массиве. Такая надежность достигается за
счет снижения производительности и уменьшенной емкости, для восстановления информационно
-вычислительных операций требуется два шага, а два диска в массиве используются не для хранения данных, а для контроля их
целостности и восстановления после сбоев.
Во многом эта технология дублирует возможности RAID 5, но данные для восстановления копируются сразу на два резервных носителя.
Второй диск с четностью, по сути, является дублирующим каналом связи. Принцип его работы основан на коде Рида-Соломона,
и поэтому второй привод обозначается как Q или RS.
Благодаря такому принципу владелец сервера может безболезненно перенести безвременную кончину сразу пары HDD/SSD-накопителей.
Вот только для реализации RAID 6 вам понадобится уже 4 диска.
RAID 7 является зарегистрированной торговой маркой Storage Computer Corporation, отдельного уровня
RAID нет. Структура массива следующая: два диска хранят данные, один диск используется для хранения данных
блоки четности. Запись на диски кэшируется с использованием оперативной
памяти, сам массив требует обязательного
отключения питания; в случае перебоев в подаче электроэнергии происходит повреждение данных.
Для реализации такого решения вам понадобится как минимум 2 диска.
RAID 10 (RAID 1+0)представляет собой зеркальный массив, в котором данные записываются последовательно на несколько дисков, как в RAID 0.
Эта архитектура представляет собой массив RAID 0, сегментами которого являются массивы RAID 1, а не отдельные диски.
Соответственно, массив такого уровня должен содержать не менее 4 дисков (и всегда четное число). RAID 10 сочетает в
себе высокую отказоустойчивость и производительность.
Эта технология сочетает в себе преимущества RAID 1 и RAID 0 в режиме виртуализации, что обеспечивает высокую скорость работы
восстановление, превосходная надежность и производительность.
RAID 10 - это вложенный тип RAID, который сочетает в себе RAID 1 и RAID 0, отсюда и его название. Многие профессионалы
предпочитают записывать его как RAID 1+0. Массив сначала разбивает данные на блоки (RAID 0), а затем создает для них
зеркальное отображение на отдельных дисках (RAID 1). Помните, что это не то же самое, что RAID 0 + 1, который работает
в обратном направлении, сначала создавая зеркальное отображение данных, а затем разбивая их на блоки.
Для реализации такого решения вам понадобится как минимум 4 диска.
Эта конфигурация использует все преимущества RAID 5 (четность) и RAID 0 (чередование) для повышения производительности без
снижение показателей защиты. Но только в том случае, если у вас 6 дисков или больше.
Организация RAID-пространства позволяет пережить поломку до 4 дисков, если они находятся в отдельном массиве RAID 5.
Для реализации такого решения требуется как минимум 6 дисков.
RAID 60 (также называемый RAID 6+0) представляет собой комбинированный набор массивов RAID 0 и RAID 6, обеспечивающий пользователю
повышенную производительность и скорость обработки данных массива. Эта комбинация не получила широкого распространения,
но у нее есть некоторые преимущества, среди которых особенно можно выделить возможность сохранения работоспособности
(отсутствие задержек при вычислении и записи большого количества бит четности) при одновременном увеличении общего объема
пространства.
Striping ("чередование") помогает увеличить пропускную способность и производительность без добавления дополнительных
дисков, подключаемых к каждому набору RAID 6, что, в свою очередь, снижает доступность данных. RAID 60 повышает производительность
RAID 6, несмотря на то, что RAID 60 заметно медленнее RAID 50, особенно в плане "записи" данных.
Для реализации такого решения требуется как минимум 8 дисков.
Решение для управления серверами Dell PowerEdge основано на интегрированном контроллере жизненного цикла (LCC).
LCC - это легкая операционная система, которая запускается из iDRAC и получает инструкции от систем
управление.
Он также служит непосредственным источником обновлений и помогает выполнять автоматизированные задачи
в соответствии с инструкциями по созданию и обслуживанию работоспособных серверов.
Контроллер iDRAC аппаратно интегрирован в материнскую плату сервера и,
как и другие решения BMC, имеет собственный процессор, память, сетевое подключение и доступ к системной шине.
iDRAC обеспечивает удаленный доступ к системной консоли (клавиатуре и экрану), обеспечивая доступ к BIOS
системы через Интернет после перезапуска сервера. Основные функции iDRAC включают управление питанием, доступ к
виртуальным носителям и возможности удаленной консоли. Эти функции дают администраторам возможность настраивать
компьютер работает так, как если бы они сидели перед локальной консолью.
Заголовки HTTP (англ. HTTP Headers) - это строки в HTTP-сообщении, содержащие разделённую
двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков
текстовых сетевых сообщений ARPA. Заголовки должны отделяться от тела сообщения хотя бы
одной пустой строкой.
Код состояния HTTP (англ. HTTP status code) — является частью первой строки ответа сервера.
Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния.
За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая
разъясняет человеку причину именно такого ответа.
100 Continue (Продолжать) — Сервер удовлетворён начальными сведениями о запросе, клиент
может продолжать пересылать заголовки. Появился в HTTP/1.1.
101 Switching Protocols (Переключение протоколов) — Сервер предлагает выбрать другой протокол,
более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка
Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием
нового протокола. Появился в протоколе версии HTTP/1.1.
102 Processing (Идёт обработка) — Запрос принят, но на его обработку понадобится длительное время.
Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при
получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в
WebDAV.
105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) — При разрешении доменного имени
возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.
200 OK (Хорошо) — Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке
и/или теле сообщения. Появился в HTTP/1.0.
201 Created (Создано) — В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать
его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного
ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту
получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.
202 Accepted (Принято) — Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться
окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
203 Non-Authoritative Information (Информация не авторитетна) — Аналогично ответу 200, но в этом случае передаваемая
информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть
неактуальной. Появился в HTTP/1.1.
204 No Content (Нет содержимого) — Сервер успешно обработал запрос, но в ответе были переданы только заголовки без
тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.
Появился в HTTP/1.0.
205 Reset Content (Сбросить содержимое) — Сервер обязывает клиента сбросить введённые пользователем данные. Тела
сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
206 Partial Content (Частичное содержимое) — Сервер удачно выполнил частичный GET-запрос, возвратив только часть
сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с
подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.
207 Multi-Status (Многостатусный) — Сервер передаёт результаты выполнения сразу нескольких независимых операций.
Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом
объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
226 IM Used (Использовано IM) — Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом
указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
300 Multiple Choices (Несколько вариантов выбора) — По указанному URI существует несколько вариантов предоставления
ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая
возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
301 Moved Permanently (Перемещено навсегда) — Запрошенный документ был окончательно перенесен на новый URI, указанный
в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
302 Moved Temporarily / Found (Перемещено временно / Найдено) — Запрошенный документ временно доступен по другому URI,
указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании
содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
303 See Other (Смотреть другое) — Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с
использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым
для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на
веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST,
включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303,
указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения
содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
304 Not Modified (Не изменялось) — Сервер возвращает такой код, если клиент запросил документ методом GET, использовал
заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера
не должно содержать тела. Появился в HTTP/1.0. Проверить код 304 Not Modified.
305 Use Proxy (Использовать прокси) — Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI
которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси).
Введено в HTTP/1.1.
306 (Зарезервировано, код использовался только в ранних спецификациях) — Использовавшийся раньше код ответа, в настоящий
момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
307 Temporary Redirect (Временное перенаправление) —- Запрашиваемый ресурс на короткое время доступен по другому URI,
указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности.
Введено в RFC 2616 (обновление HTTP/1.1).
400 Bad Request (Плохой запрос) — Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
401 Unauthorized (Неавторизован) — Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ
должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в
заголовок сообщения поле Authorization с требуемыми для аутентификации данными.
402 Payment Required (Необходима оплата) — Предполагается использовать в будущем. В настоящий момент не используется.
Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта
ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.
403 Forbidden (Запрещено) — Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента
к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401
или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком
веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае
клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить
попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым
был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе
управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента,
например, при блокировках. Появился в HTTP/1.0.
404 Not Found (Не найдено) — Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в
написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу
известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо
403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
405 Method Not Allowed (Метод не поддерживается) — Указанный клиентом метод нельзя применить к текущему ресурсу.
В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать,
если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём
сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
406 Not Acceptable (Неприемлемо) — Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод
был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
407 Proxy Authentication Required (Необходима прокси авторизация) — Ответ аналогичен коду 401 за исключением того, что
аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
408 Request Timeout (Истекло время ожидания) — Время ожидания сервером передачи от клиента истекло. Клиент может повторить
аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла
методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска
или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с
сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам
сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение
прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
409 Conflict (Конфликт) — Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда
два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.
410 Gone (Удалён) — Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен.
Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение,
что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
411 Length Required (Необходима длина) — Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без
указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов
типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём.
Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную
нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
412 Precondition Failed (Условие ложно) — Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.
Появился в HTTP/1.1.
413 Request Entity Too Large (Размер запроса слишком велик) — Возвращается в случае, если сервер отказывается обработать
запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу
запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по
истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
414 Request-URI Too Large (Запрашиваемый URI слишком длинный) — Сервер не может обработать запрос из-за слишком длинного
указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET,
а не POST. Появился в HTTP/1.1.
415 Unsupported Media Type (Неподдерживаемый тип данных) — По каким-то причинам сервер отказывается работать с указанным
типом данных при данном методе. Появился в HTTP/1.1.
416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) — в поле Range заголовка запроса был указан диапазон
за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер
в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616
(обновление HTTP/1.1).
417 Expectation Failed (Ожидаемое неприемлемо) — По каким-то причинам сервер не может удовлетворить значению поля Expect
заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
418 I'm a teapot (Я — чайник) — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324,
Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.
422 Unprocessable Entity (Необрабатываемый экземпляр) — Сервер успешно принял запрос, может работать с указанным видом данных,
в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести
операцию над ресурсом. Введено в WebDAV.
423 Locked (Заблокировано) — Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
424 Failed Dependency (Невыполненная зависимость) — Реализация текущего запроса может зависеть от успешности выполнения другой
операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
425 Unordered Collection (Неупорядоченный набор) — используется в расширении WebDAV Advanced Collections Protocol. Посылается,
если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.
426 Upgrade Required (Необходимо обновление) — Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа
должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
428 Precondition Required (Необходимо предусловие) — Сервер указывает клиенту на необходимость использования в запросе заголовков
условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
429 Too Many Requests (Слишком много запросов) — Клиент попытался отправить слишком много запросов за короткое время, что может
указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно
повторить запрос. Введено в черновике стандарта RFC 6585.
431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) — Превышена допустимая длина заголовков. Сервер не
обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
434 Requested host unavailable. (Запрашиваемый адрес недоступен) — Запрашиваемый адрес недоступен.
449 Retry With (Повторить с) — Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации.
При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как
минимум используется программой Microsoft Money.
451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) — Доступ к ресурсу закрыт по юридическим причинам,
например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав.
Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери "451 градус по
Фаренгейту".
456 Unrecoverable Error (Некорректируемая ошибка) — Возвращается сервером, если обработка запроса вызывает некорректируемые
сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.
499 Client Closed Request (Клиент закрыл соединение) — Используется Nginx, когда клиент закрывает соединение до получения ответа.
500 Internal Server Error (Внутренняя ошибка сервера) — Любая внутренняя ошибка сервера, которая не входит в рамки остальных
ошибок класса. Появился в HTTP/1.0.
501 Not Implemented (Не реализовано) — Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ
для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному
ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
502 Bad Gateway (Плохой, ошибочный шлюз) — Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное
сообщение от вышестоящего сервера. Появился в HTTP/1.0.
503 Service Unavailable (Сервис недоступен) — Сервер временно не имеет возможности обрабатывать запросы по техническим причинам
(обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется
повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка
большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
504 Gateway Timeout (Шлюз не отвечает) — Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для
завершения текущего запроса. Появился в HTTP/1.1.
505 HTTP Version Not Supported (Версия HTTP не поддерживается) — Сервер не поддерживает или отказывается поддерживать указанную в
запросе версию протокола HTTP. Появился в HTTP/1.1.
506 Variant Also Negotiates (Вариант тоже проводит согласование) — В результате ошибочной конфигурации выбранный вариант указывает
сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP
технологией Transparent Content Negotiation.
507 Insufficient Storage (Переполнение хранилища) — Не хватает места для выполнения текущего запроса. Проблема может быть временной.
Введено в WebDAV.
508 Loop Detected (Обнаружено бесконечное перенаправление) — операция отменена, т.к. сервер обнаружил бесконечный цикл при обработке
запроса без ограничения глубины. Введено в WebDAV.
509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) — Используется при превышении веб-площадкой отведённого ей
ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий
момент данный код не описан ни в одном RFC и используется только модулем "bw/limited", входящим в панель управления хостингом cPanel,
где и был введён.
510 Not Extended (Нет расширения) — На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно
передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
511 Network Authentication Required (Требуется сетевая аутентификация) — Этот ответ посылается не сервером, которому был предназначен
запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например,
ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или
перенаправление на неё. Введено в черновике стандарта RFC 6585.
Метод HTTP является безопасным, если он не меняет состояние сервера. Другими словами,
безопасный метод проводит операции "только чтение" (read-only).
Запрос GET отправляется через форму HTML, и многими другими программами, скриптами.
Правильная реализация безопасного метода - это ответственность серверного приложения,
сам веб-сервер Apache, nginx, IIS защитить не сможет. Это означает что, приложение не должно разрешать
изменение состояния сервера запросами GET.
Метод POST предназначен для отправки данных на сервер. Часто вызывает изменение состояния или какие-то побочные
эффекты на сервере. Запрос POST обычно отправляется через форму HTML, и многими другими программами, скриптами.
Метод HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа.
HTTP-метод HEAD запрашивает заголовки, идентичные тем, что возвращаются, если указанный ресурс
будет запрошен с помощью HTTP-метода GET. Такой запрос может быть выполнен перед загрузкой большого
ресурса, например, для экономии пропускной способности.
Ответ на метод HEAD не должен содержать тело. Если это не так, то его следует игнорировать.
Но даже в этом случае заголовки сущности, описывающие содержимое тела, например Content-Length,
должны быть включены в ответ. Они не относятся к телу ответа на запрос HEAD, которое должно быть пустым,
они относятся к телу ответа, полученный на аналогичный запрос с помощью метода GET.
Метод PUT заменяет все текущие представления ресурса данными запроса. Обычно PUT создаёт новый ресурс или заменяет
представление целевого ресурса, данными представленными в теле запроса.
Метод PATCH используется для частичного изменения ресурса.
Чтобы обозначить, что сервер поддерживает PATCH, можно добавить этот метод в список заголовков
ответа Allow (en-US) или Access-Control-Allow-Methods (для CORS).
DNS (система доменных имен) – это «телефонная книга» Интернета. В качестве номера телефона в ней выступает IP-адрес,
а в качестве наименований контактов — домены. В такую книгу можно внести не только «телефонный номер», но и дополнительную
информацию о контакте («е-mail», «место работы» и т.п.).
Запись A
Запись A (address) — одна из ключевых ресурсных записей Интернета. Она нужна для связи домена с IP-адресом сервера.
Пока не прописана А-запись, ваш сайт не будет работать.
Когда вы вводите название сайта в адресную строку браузера, именно по А-записи DNS определяет, с какого сервера нужно
открывать ваш сайт.
Запись AAAA
АААА (IPv6 address record) ― это запись, которая работает так же, как и запись А — связывает домен с
IP-адресом сервера. Однако подходит она только для адресов формата IPv6 (вида 7628:0d18:11a3:09d7:1f34:8a2e:07a0:765d).
Запись CNAME
CNAME (Canonical name) — запись, которая отвечает за привязку поддоменов (например, www.site.com) к каноническому
имени домена (site.com) или другому домену.
Основная функция CNAME — дублирование ресурсных записей домена (A, MX, TXT) для различных поддоменов.
Запись MX
MX-запись что это? Это запись, отвечающая за сервер, через который будет работать почта. Записи MX критически важны
для работы почты. Благодаря им отправляющая сторона «понимает», на какой сервер нужно отправлять почту для вашего домена.
Запись TXT
TXT (Text string) — запись, которая содержит любую текстовую информацию о домене. Записи TXT используются для различных
целей: подтверждения права собственности на домен, обеспечения безопасности электронной почты, а также подтверждения
SSL-сертификата. Часто применяется для проверок на право владения доменом при подключении дополнительных сервисов,
а также как контейнер для записи SPF и ключа DKIM. Можно прописывать неограниченное количество TXT-записей, если
они не конфликтуют друг с другом.
Запись SPF
SPF-запись (Sender Policy Framework) содержит информацию о списке серверов, которые имеют право отправлять письма
от имени заданного домена. Позволяет избежать несанкционированного использования. Настройка SPF прописывается
в TXT-записи для домена.
Запись NS
NS-запись (Authoritative name server) указывает на DNS-серверы, которые отвечают за хранение остальных ресурсных
записей домена. Количество NS записей должно строго соответствовать количеству всех обслуживающих его серверов.
Критически важна для работы службы DNS.
Запись PTR
PTR — обратная DNS-запись, которая связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись применяется
для фильтрации почты.
Запись SOA
SOA (Start of Authority) — начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о
доменном имени. Критически важна для работы службы DNS.