По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть HTTP и REST. Понимание HTTP имеет решающее значение для веб-разработчиков, поскольку оно облегчает поток информации в веб-приложении, позволяя улучшить взаимодействие с пользователями и повысить производительность сайта. Что такое HTTP? В клиент-серверной модели клиенты и серверы обмениваются сообщениями по принципу «запрос-ответ»: клиент отправляет запрос, а сервер возвращает ответ. Хранить трек из этих сообщений сложнее, чем звучит, поэтому клиент и сервер придерживаются общего языка и набора правил. Этот «язык», или протокол, называется HTTP. Протокол HTTP определяет синтаксис (формат и кодировку данных), семантику (значение, связанное с синтаксисом) и тайминг (скорость и последовательность). Каждый HTTP-запрос и ответ, которыми обмениваются клиент и сервер, рассматривается как одна HTTP-транзакция. HTTP: Общая информация Есть несколько вещей, которые стоит отметить про HTTP, прежде чем погрузиться в детали. Во-первых, HTTP текстовый протокол, что означает, что сообщения, которыми обмениваются клиент и сервер, являются битами текста. Каждое сообщение содержит две части: заголовок и тело. Во-вторых, HTTP - это протокол прикладного уровня, то есть это просто абстракционный уровень, который стандартизирует взаимодействие хостов. Сам HTTP не передает данные. Получение запроса и ответа от одной машины к другой по-прежнему зависит от базового протокола TCP/IP. Напоминаем, что TCP/IP - это двухкомпонентная система, которая функционирует как фундаментальная «система управления» Интернета. Наконец, возможно, вы видели протокол «HTTPS» в адресной строке браузера и интересовались, является ли HTTP тем же самым, что HTTP + «S». Если коротко, то HTTPS разновидность HTTP, с небольшой разницей. Простой HTTP-запрос или ответ не зашифрован и уязвим для различных типов атак. HTTPS, напротив, является более безопасной протоколом связи, которая использует TLS/SSL шифрование для обеспечения безопасности. SSL - это протокол безопасности, который позволяет клиенту и серверу взаимодействовать по сети безопасным способом - чтобы предотвратить сниффинг и подмену во время передачи сообщений по сети. Клиент обычно указывает, требуется ли ему подключение TLS/SSL, используя специальный номер порта 443. Как только клиент и сервер соглашаются использовать TLS/SSL для обмена данными, они согласовывают соединение с отслеживанием состояния, выполняя так называемое «квитирование TLS». Затем клиент и сервер устанавливают секретные сеансовые ключи, которые они могут использовать для шифрования и дешифрования сообщений, когда они разговаривают друг с другом. Многие крупные веб-сайты, такие как Google и Facebook, используют HTTPS - в конце концов, это то, что сохраняет ваши пароли, личную информацию и данные кредитных карт в безопасности. Что такое API HTTP: Углубляясь в детали Теперь, вооружившись базовыми знаниями, погрузимся глубже в структуру HTTP. Мы можем начать с посещения https://www.github.com, чтобы связаться с сервером GitHub. Если вы используете Chrome или Firefox с установленным расширением Firebug, вы можете подробно изучить HTTP-запрос, перейдя на вкладку «Сеть» или «Network». С открытой кладкой «Сеть», перейдите на сайт www.github.com, введя его в адресную строку, и вы должны увидеть что-то подобное: Затем на левой панели щелкните по первому пути, «github.com.» Теперь вы должны увидеть следующее: Заголовок запроса HTTP Заголовки HTTP обычно содержат метаданные (данные о данных). Метаданные включают тип запроса (GET, POST, PUT или DELETE), путь, код состояния, тип содержимого, используемый браузер, cookie, текст сообщения (иногда) и многое другое. Рассмотрим наиболее важные части заголовка на примере GitHub, начиная с раздела «Заголовки ответа»: Request URL: https://github.com/ - Запрошенный URL-адрес Request Method: GET - Тип используемого метода HTTP. В нашем случае наш браузер сказал: «Эй, сервер GitHub, я хочу ПОЛУЧИТЬ (GET) домашнюю страницу». Status Code:200 OK - Стандартизированный способ информирования клиента о результате запроса. Код состояния 200 означает, что сервер успешно нашел ресурс и отправляет его вам. Remote Address:192.30.252.129:443 - IP-адрес и номер порта веб-сайта GitHub, который мы посетили. Обратите внимание, что это порт номер 443 (это означает, что мы используем HTTPS вместо HTTP). Content-Encoding: gzip - Кодировка ресурса, который мы получили обратно. В нашем случае сервер GitHub сообщает нам, что содержимое, которое он отправляет назад, сжато. Возможно, Github сжимает файлы, чтобы страница быстрее загружалась. Content-Type: text/HTML; charset = utf-8 - Задает представление данных в теле ответа, включая тип и подтип. Тип описывает тип данных, в то время как подтип указывает конкретный формат для этого типа данных. В нашем случае, мы имеем текст, в формате HTML. Во второй части указывается кодировка символов для HTML-документа. Чаще всего это будет UTF-8, как и выше. Есть также куча информации заголовка, которую клиент должен был отправить, чтобы сервер мог знать, как ответить. Посмотрите на раздел «Заголовки запросов» или «Headers»: User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 - Программное обеспечение, которым пользуется пользователь. Иногда веб-сайт должен знать, с какого устройства он просматривается. Поэтому браузер отправляет эту последовательность User-Agent, которую сервер может использовать для определения того, что используется для доступа к веб-сайту Accept-Encoding: gzip, deflate, sdch - Указывает кодировку содержимого, которую может обработать браузер. Мы видим, что указан gzip, и поэтому сервер Github смог отправить нам содержимое в формате gzip. Accept-Language: en-US, en; q = 0.8 - Описывает язык, на котором должна отобразиться веб-страница. В нашем случае «en» означает английский. Host: github.com - Описывает хост, на который мы идем Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay; _gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz = America% 2FLos_Angeles _ - Фрагмент текста, который веб-сервер может хранить на компьютере пользователя и впоследствии извлекать. Информация сохраняется как пара имя-значение. Например, одна из пар имя-значение, сохраненных GitHub для моего запроса, является «dotcom_user=iam-peekay,», которая сообщает GitHub, что мой userid – Iam-peekay. Что теперь со всеми этими парами имя-значение? Итак, у нас есть много пар имя-значение. Но как создаются эти пары имя-значение? Каждый раз, когда браузер будет открывать веб-сайт, он будет искать на компьютере файл cookie, установленный веб-сайтом ранее. Так что, при посещении www.github.com, браузер будет искать файл cookie, который GitHub сохранил на жестком диске компьютера пользователя. Если он найдет файл cookie, он отправит все пары имя-значение в заголовке запроса. Веб-сервер GitHub теперь может использовать данные cookie различными способами, такими как рендеринг контента на основе сохраненных пользовательских предпочтений, подсчет количества времени, проведённого на сайте. Если браузер не находит файл cookie - либо потому, что сайт никогда не посещался, либо пользователь заблокировал или удалил его - браузер не отправляет данные cookie. В этом случае сервер GitHub создает новый идентификатор в качестве пары имя-значение, вместе с любыми другими необходимыми ему парами имя-значение, и отправляет его пользователю через заголовок HTTP. Получив данные, устройство хранит их на своем жестком диске. Тело HTTP Выше мы узнали, что сервер содержит большинство важных «метаданных» (данные о данных), которые необходимы для связи с клиентом. Теперь поговорим о теле HTTP запроса. Тело – это основная часть сообщения. В зависимости от типа запроса он может быть и пустым. В нашем случае вы можете увидеть тело на вкладке «Response». Поскольку мы сделали запрос GET на www.github.com, тело содержит содержимое HTML-страницы для www.github.com. Дополнительные упражнения Надеюсь, такой разбор позволит вам лучше понять структуру HTTP. На практике вы можете просмотреть на другие ресурсы, запрашиваемые вашим браузером (изображения, файлы JavaScript и т.д.) при посещении www.github.com. Теперь рассмотрим различные методы HTTP запросов, которые клиент может инициировать. Методы HTTP Команды или методы HTTP указывают серверу, что делать с данными, определенными по URL. URL-адреса всегда идентифицируют определенный ресурс. Когда клиент использует URL-адрес в сочетании с командой HTTP, это сообщает серверу, какое действие необходимо выполнить с указанным ресурсом. Примеры URL-адресов: GET http://www.example.com/users (получить всех пользователей) POST http://www.example.com/users/a-unique-id (создание нового пользователя) PUT http://www.example.com/comments/a-unique-id (обновить комментарий) DELETE http://www.example.com/comments/a-unique-id (удалить комментарий) Когда клиент делает запрос, он указывает тип запроса, используя одну из этих команд. Наиболее важными являются GET, POST, PUT и DELETE. Есть и другие методы, такие как HEAD и OPTIONS, но они используются редко, поэтому в данном материале мы пропустим их. GET GET является наиболее часто используемым методом. Он используется для чтения информации по данному URL-адресу с сервера. Запросы GET доступны только для чтения, что означает, что данные никогда не должны быть изменены на сервере - сервер должен просто извлечь данные без изменений. Таким образом, запросы GET считаются безопасными операциями, поскольку сколько бы не вызывай его, ответ будет одинаковым. Кроме того, запросы GET являются идемпотентными. Это означает, что отправка нескольких запросов GET на один и тот же URL-адрес должна привести к тому же эффекту, что и один запрос GET, поскольку запрос GET просто запрашивает данные с сервера, а не изменяет их. Запросы GET отвечают кодом состояния 200 (ОК), если ресурс был успешно найден, и 404 (NOT FOUND), если ресурс не был найден. (Отсюда термин «404 page» для сообщений об ошибках при посещении несуществующих или неправильно набранных URL-адресов.) POST POST используется для создания нового ресурса, например, через форму регистрации. Функция POST используется при необходимости создания дочернего ресурса (например, нового пользователя) для какого-либо родительского ресурса (http://example.com/users). Родительский ресурс запроса на создание новой сущности определяется по URL-адресу, и сервер обрабатывает новый ресурс и связывает его с родительским ресурсом. POST не является ни безопасным, ни идемпотентным. Это связано с тем, что выполнение двух или более идентичных запросов POST приведет к созданию двух новых идентичных ресурсов. Запросы POST отвечают кодом состояния 201 (CREATED) вместе с заголовком местоположения со ссылкой на вновь созданный ресурс. PUT PUT используется для обновления ресурса, идентифицированного по URL, с использованием информации в теле запроса. PUT также может использоваться для создания нового ресурса. Запросы PUT не считаются безопасными операциями, поскольку они изменяют данные на сервере. Однако он является идемпотентным, поскольку несколько идентичных запросов PUT на обновление ресурса должны иметь тот же эффект, что и первый. Запросы PUT отвечают кодом состояния 200 (OK), если ресурс был успешно обновлен, и 404 (NOT FOUND), если ресурс не был найден. DELETE DELETE используется для удаления ресурса, определенного по URL-адресу. Запросы DELETE являются идемпотентным, поскольку если УДАЛИТЬ ресурс, он будет удален, и даже если вы сделаете несколько идентичных запросов DELETE, результат будет одинаковым: удаленный ресурс. Скорее всего, вы просто получите сообщение об ошибке 404, если отправить запрос DELETE для одного и того же ресурса несколько раз, поскольку сервер не сможет найти его после удаления. Запросы DELETE отвечают кодом состояния 200 (OK) в случае успешного удаления или 404 (NOT FOUND), если не удалось найти удаляемый ресурс. Все вышеуказанные запросы возвращают значение 500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА), если обработка завершается неуспешно и сервер выдаёт ошибку. Что же такое REST? Перейдем к последнему термину – REST. Возможно, вы слышали термин RESTful application ранее. Важно понимать, что это означает, потому что, если вы используете HTTP для обмена данными между клиентом и сервером, полезно следовать рекомендациям REST. На самом деле, HTTP-методы, которые мы рассмотрели выше, не что иное, как часть REST. REST расшифровывается как Representational State Transfer (Передача состояния представления). Это архитектурный стиль проектирования приложения. Основная идея заключается в том, что для выполнения вызовов между машинами используется протокол «без состояния», «клиент-сервер», «кэшируемый» - и чаще всего этот протокол HTTP. В общем, REST это согласованный набор ограничений для проектирования приложения. Эти ограничения помогают сделать систему более производительной, масштабируемой, простой, изменяемой, видимой, портативной и надежной. Полный список ограничений очень длинный, и вы можете прочитать об этом здесь. В этой статье остановимся на двух наиболее важных из них: 1. Унифицированный интерфейс - Uniform interface: это ограничение позволяет определить интерфейс между клиентом и сервером путь, чтобы упростить и разъединить архитектуру. Там написано, что: Ресурсы должны быть идентифицируемыми в запросе (например, с помощью идентификаторов ресурсов в URI). Ресурс (например, данные в базе данных) - это данные, которые определяют представление ресурса (например, JSON, HTML). Ресурсы и представления ресурсов - это концептуально разные сущности - клиент взаимодействует только с представлением ресурсов. Клиент должен иметь достаточно информации для управления ресурсами на сервере с помощью представления ресурса. Каждое сообщение, которым обмениваются клиент и сервер, должно быть самоописательным и содержать информацию о том, как обрабатывать сообщение. Клиенты должны отправлять данные о состоянии с использованием основного содержимого HTTP, заголовка HTTP-запроса, параметров запроса и URL-адреса. Серверы должны отправлять данные о состоянии с помощью тела HTTP, кодов ответов и заголовков ответов. Примечание: Описанные выше команды HTTP составляют основную часть ограничения «унифицированного интерфейса», поскольку они представляют собой единообразные действия, которые происходят с ресурсами. 2. Отсутствие состояния - Stateless: это ограничение говорит о том, что все данные о состоянии, необходимые для обработки запроса клиента, должны содержаться в самом запросе (URL, параметры запроса, тело HTTP или заголовки HTTP), а сервер должен отправить все необходимые данные о состоянии клиенту через сам ответ (заголовки HTTP, код состояния и тело ответа HTTP). Примечание: Состояние - или состояние приложения - это данные, необходимые серверу для выполнения запроса. Это означает, что для каждого запроса мы пересылаем информацию о состоянии туда и обратно, так что сервер не должен поддерживать, обновлять и отправлять состояние. Наличие системы без сохранения состояния делает приложения намного более масштабируемыми, потому что ни один сервер не должен беспокоиться о поддержании одного и того же состояния сеанса на протяжении нескольких запросов. Все необходимое для получения данных о состоянии доступно в самом запросе и ответе. Заключение HTTP далеко не прост. Но, как вы видите, это критически важный компонент отношений между клиентом и сервером. Для создания RESTful приложений требуется по крайней мере базовое понимание HTTP. С таким багажом знаний, следующий проект для вас будет намного проще.
img
Всем привет! Сегодня мы рассмотрим параметры Option 150 и Option 66 в протоколе DHCP, которые используются VoIP для того чтобы телефонный аппарат мог найти TFTP сервер и забрать оттуда всю необходимую информацию. Для IP-телефонов Cisco адресация может быть назначена вручную или при помощи протокола DHCP. При этом устройствам требуется доступ до TFTP сервера, который содержит файлы конфигурации телефона формата .cnf, при помочи которых телефон связывается с CUCM или CME. Телефоны скачивают свою конфигурацию с TFTP сервера и когда телефон запускается и у него нет предварительно настроенного IP-адреса и TFTP-сервера, он отправляет запрос с параметром 150 (option 150) на сервер DHCP для получения этой информации. Опция 150 DHCP является собственностью компании Cisco. Стандартом IEEE, который соответствует этому требованию, является Option 66. Как и Option 150, Option 66 используется для указания имени TFTP-сервера. Option 66 является открытым стандартом, определенным в RFC 2132, который поддерживает устройства Juniper. При этом между этими опциями есть разница: DHCP Option 150 поддерживает список TFTP-серверов (множество IP-адресов серверов). DHCP Option 66 поддерживает только IP-адрес или имя хоста одного сервера TFTP. Настройка Конфигурация Juniper DHCP Option 66: set system services dhcp pool 10.1.1.0/24 boot-file test.cnf // option 67 set system services dhcp pool 10.1.1.0/24 next-server 20.1.1.25 // option 66 Мы можем указать следующий TFTP-сервере как глобально, так и специфично для пула. Если следующий сервер настроен в обоих местах, тогда будет использоваться IP-адрес, указанный в пуле. Конфигурация Cisco DHCP Option150: ip dhcp pool vlan 10 network 192.168.10.0 255.255.255.0 default-router 192.168.10.254 option 150 ip 10.10.22.99 10.10.22.100 Тут, как видно, можно сразу настроить несколько IP-адресов. А если хотите поподробнее узнать про настройку DHCP сервера на оборудовании Cisco, то про это прочитать можно тут, тут и тут.
img
Продолжаем рассказывать про Terraform. Предыдущая статья тут. В данной статье мы разберем динамичные блоки кода в Terraform, которые можно использовать в своей работе. Данный функционал значительно облегчает написание кода Terraform с помощью которого мы управляем сервисами Amazon. В статье будет описан сценарий с генерацией кода Terraform. Данный функционал был добавлен в terraform 0.12 версии. Для работы создадим новую директорию, можно путем копирования из предыдущего урока. Директорию назовем lesson-5. Для написания кода мы по-прежнему используем текстовый редактор Atom. Мы можем создать файлик с именем DynamicSecurityGroup.tf или переименуем существующий webserver.tf если вы добавили папку путем копирования. Если вы создавали путем копирования отредактируем файл, убрав строчки, которые создают веб-сервер. Удаляем. Теперь мы начнем писать код Terraform, чтобы у нас появилась динамическая группа безопасности. В прошлой статье мы прописывали 2 правила. Данные правила открывали нам порты 80 и 22, аналогично можно прописать, чтобы открывался порт 443 ну или любой другой, который нам необходим для корректного инстанса и работоспособности сервиса. А теперь представим, что нам необходимо открыть еще 20 разных портов. Можно сделать это с помощью copy-paste, т.е. копированием и вставкой уже существующих блоков кода с редактированием протокола и номеров портов. В terraform версии 0.12 добавили функционал и назвали его DynamicBlocks, что позволит генерировать кусочки кода в Terraform. Добавим следующую часть кода: dynamic "ingress" { for_each = ["80", "443", "8080", "1541", "9092"] content { from_port = ingress.value to_port = ingress.value protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } } Разберем для лучшего понимания. Функция Dynamic, далее кавычки двойные и внутри мы пишем, что-будет динамическим, в нашем случае это функция Ingress. Открываем фигурные скобки и пишем цикл с помощью for_each = ["номерпорта1", "номерпорта2"] указывая номера портов. Следовательно, цикл for_each пройдется по каждому из параметров и будет применена конструкция content. Значения внутри конструкции content, будут заменены, а именно с какого порта на какой порт открывается доступ. Далее в конструкции content описываем используемый протокол сетевого уровня и cider_blocks – с каких IP или диапазонов IP разрешено использовать данной правило. Конструкция 0.0.0.0/0 позволяет указать, что данное правило с данным портом разрешено использовать всему интернету вне зависимости от IP адреса. В целях информационной безопасности рекомендую использовать конкретные подсети или конкретные IP адреса, конечно, если это не публичный сервис. Если посмотреть на пример, то написанное таким образом правило, сгенерирует нам 5 отдельных правил, т.е. получается достаточно удобно и сокращает нам количество строчек в коде, а также потенциально количество ошибок. Код становится более читаемым и легким. После использования в коде функции dynamic, мы можем удалить все ставшие ненужными функции ingress. Не забывайте изменить имя ресурса. Это делается путем редактирования переменной name в разделе функции resource, для читаемости кода и удобства управления ресурсами в облаке AWS. После того, как у нас готов наш код, мы можем его запустить. Так как, была создана новая папка, нам необходимо инициализировать ее использования. Переходим в необходимую директорию, в которой находится файл. И запускаем инициализацию стандартной командой terraform init. После ввода команды ожидаем пару минут, пока Terraform скачает все необходимые модули для подключения и работы. Следующей командой terraform apply мы запускаем код на исполнение. И получаем запрос на подтверждение операции. Среди вывода мы можем видеть: Это значит что все порты, которые были указаны в аргументах будут созданы. Осталось подтвердить и дождаться успешного выполнения операции.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59