По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В проводной сети любые два устройства, которые должны взаимодействовать друг с другом, соединяются проводом. В качестве провода может выступать медный или волоконно-оптический кабель. Функциональные возможности по передаче данных по проводу, ограничены физическими свойствами провода. Строгие требования к проводам Ethernet определены в стандарте IEEE 802.3, в котором описаны способы подключения устройств, способы отправки и получения данных по проводным соединениям.
Проводные сети имеют ограничения для передачи данных по каналам связи, что не способствует, успешной коммуникации. Качество передачи данных, их успешная доставка до получателя, очень сильно зависит от типа и размера провода, количества витков, межвиткового расстояния, и максимальной длины кабеля. Все эти требования должны соответствовать стандарту IEEE 802.3.
Проводная сеть является ограниченной по длине и количеству подключаемых устройств, а именно напрямую по проводу могут подключиться только два устройства.
К основным недостаткам проводных сетей так же относится стационарность сетевого оборудования и компьютеров. Это означает, что соединенные проводами устройства, не могут легко перемещаться по помещению. Все устройства привязаны к сетевым разъемам. В современном мире очень много стало мобильных устройств и поэтому нецелесообразно привязывать их к конкретной розетке или разъёму коммуникационного оборудования.
Понятие беспроводной сети следует из ее названия, то есть данная сеть устраняет необходимость в проводе. Первостепенным становится удобство и мобильность, давая пользователям свободу перемещения в любом направлении, оставаясь подключенными к сети. Пользователь может использовать любое беспроводное устройство, которое имеет возможность подключения к сети.
Передача данных в беспроводных сетях осуществляется "по воздуху" при отсутствии препятствий и помех. При использовании беспроводной среды передачи данных, для их качественной доставки необходимо учитывать две вещи:
Беспроводные устройства должны соответствовать единому стандарту (IEEE 802.11).
Беспроводное покрытие должно охватывать ту область, на которой планируется использование устройствами.
Топологии Wireless LAN
Беспроводная связь осуществляется "по воздуху" посредством радиосигналов. Предположим, что одно устройство, передатчик, посылает радиосигналы другому устройству, приемнику. Как показано на рисунке, связь между передатчиком и приемником осуществляется в любое время, если оба устройства настроены на одну и ту же частоту (или канал) и используют одну и ту же схему для передачи данных между ними. Все это выглядит просто, за исключением того, что на самом деле это не удобно и не практично.
Для эффективного использования беспроводной сети данные должны передаваться в обоих направлениях, как показано на рисунке. Для отправки данных с устройства А на устройство В, устройство В должно дождаться прихода данных к себе и когда канал освободится отправить на устройство А.
В беспроводной связи, при одновременной передаче данных, могут возникнуть помехи, т.е. передаваемые сигналы будут мешать друг другу. Чем больше беспроводных сетей, тем выше вероятность возникновения помех. Например, на рисунке изображены четыре устройства, работающие на одном и том же канале, и то, что может произойти, если часть из них или все одновременно начнут передавать данные.
Вышенаписанное сильно напоминает нам традиционную (некоммутируемую) локальную сеть Ethernet, где несколько хостов могут подключаться к общему ресурсу и совместно использовать канал передачи данных. Чтобы эффективно использовать общий ресурс, все хосты должны работать в полудуплексном режиме, во избежание столкновений с другими уже выполняемыми передачами. Побочным эффектом является то, что ни один хост не может передавать и принимать одновременно в общей среде.
Аналогичное происходит и в беспроводной сети. Так как несколько хостов могут совместно использовать один и тот же канал, они также совместно используют "эфирное время" или доступ к этому каналу в любой момент времени. Что бы избежать конфликтных ситуаций и создание помех, хосты должны передавать данные в определенный момент времени, ожидая освобождения канала. Для работы в беспроводных сетях все устройства должны соответствовать стандарту 802.11.
Важно понимать, что по умолчанию беспроводная среда не учитывает количество устройств и не контролирует устройства, которые могут передавать данные. Любое устройство, имеющее адаптер беспроводной сети, может в любой момент подключиться к беспроводной сети.
Как минимум, беспроводная сеть должна уметь определять, что каждое устройство, подключаемое к каналу передачи данных, поддерживает общий набор параметров. Кроме того, должен быть способ контроля устройств (и пользователей), которым разрешено использовать беспроводную среду и методы, используемые для обеспечения безопасности беспроводной передачи данных.
Базовый набор услуг (BSS)
Идея состоит в том, чтобы сделать каждую беспроводную зону обслуживания замкнутой для группы мобильных устройств, которая формируется вокруг фиксированного устройства. Прежде чем устройство сможет подключиться, оно должно объявить о своих возможностях, а затем получить разрешение на подключение. В стандарте 802.11 это называется базовым набором услуг (BSS, Basic Service Set). В центре каждого BSS находится беспроводная точка доступа (AP). AP работает в инфраструктурном режиме, что означает, что он предлагает услуги, необходимые для формирования инфраструктуры беспроводной сети. AP также устанавливает свой BSS по одному беспроводному каналу. AP и члены BSS должны использовать один и тот же канал для правильной связи.
Поскольку работа BSS зависит от точки доступа, то BSS ограничена областью, равной расстоянию, на которое может распространяться сигнал точки доступа. Это называется базовой зоной обслуживания (BSA) или ячейкой. На рисунке ячейка показана в виде окружности, в центре которой имеется точка доступа. Ячейки могут выглядеть по-разному:
зависит от устройств, подключенных к AP;
зависит от физического окружения, которое может повлиять на сигналы AP;
Точка доступа (АР) служит единственной точкой контакта для каждого устройства, которое хочет использовать BSS. Она объявляет о существовании BSS, чтобы устройства могли найти его и попытаться присоединиться. Для этого AP использует уникальный идентификатор BSS (BSSID), основанный на собственном MAC-адресе.
Кроме того, точка доступа присваивает беспроводной сети идентификатор набора услуг (SSID-текстовую строку, содержащую логическое имя). Представьте себе, что BSSID - это машинный код, который однозначно идентифицирует BSS (AP). А SSID - это символьная строка, задаваемая человеком, который идентифицирует беспроводную службу.
Членство в BSS называется ассоциацией. Беспроводное устройство должно отправить запрос на ассоциацию точке доступа, и точка доступа должна либо предоставить, либо отклонить запрос. При разрешении, устройство становится клиентом, или станцией 802.11 (STA) в BSS. И что же дальше? Пока клиент беспроводной сети остается подключенным к BSS, все данные, приходящие к нему и исходящие от клиента, проходят через точку доступа, как показано на рисунке. Используя BSSID в качестве адреса источника или назначения, фреймы данных можно ретранслировать в точку доступа или из нее.
На рисунке изображено движение трафика внутри BSS. BSS содержит четыре устройства, подключенные к точке доступа по беспроводному соединению. Идентификатор набора служб (SSID) носит название "Моя сеть". Базовый идентификатор набора услуг (BSSID) - это MAC-адрес точки доступа d4:20:6d:90:ad:20. Любой клиент, связанный с BSS, не может напрямую связаться с любым другим клиентом в BSS. Весь трафик проходит через точку доступа.
Почему же два клиента должны общаться именно через точку доступа, а не напрямую? Это связано с тем, что все подключения через точку доступа и BSS стабильны и контролируются.
Система распределения
Нужно учитывать то, что BSS имеет одну точку доступа AP и не имеет явного подключения к обычной сети Ethernet. В этом случае точка доступа и связанные с ней клиенты образуют автономную сеть. Но роль точки доступа не ограничивается только управлением BSS, рано или поздно появится необходимость взаимодействия беспроводных клиентов с другими устройствами, которые не являются членами BSS. К счастью, точка доступа имеет возможность подключаться к сети Ethernet, как по беспроводным каналам, так и по проводам. Стандарт 802.11 позволяет подключаться по проводам Ethernet и использовать их в качестве распределительной системы (DS) для беспроводной BSS (см. рис.6).
Вообще можно сказать, что точка доступа выступает в качестве моста между разнородными средами передачи данных (проводной и беспроводной). Проще говоря, точка доступа отвечает за сопоставление виртуальной локальной сети (VLAN) с SSID. На рисунке точка доступа сопоставляет VLAN 10 с беспроводной локальной сетью, используя SSID "Моя сеть". Клиенты, связанные с SSID "Моя сеть", будут, подключены к VLAN 10.
Рисунок иллюстрирует систему распределения, поддерживающую BSS. Система распределения состоит из коммутатора третьего уровня в сети VLAN 10. Данный коммутатор подключен к интернету с помощью кабеля. AP (точка доступа) подключается к коммутатору так же с помощью кабеля. Точка доступа формирует BSS (базовый набор услуг). Устройства, входящие в область BSS - это все устройства, подключенные по беспроводной связи к точке доступа. Идентификатор SSID "Моя сеть" и BSSID- d4:20:6d:90:ad:20.
Данный принцип подключения позволяет сопоставлять несколько VLAN с несколькими SSID. Для этого точка доступа должна быть соединена с коммутатором магистральным каналом. На рисунке 7 VLAN 10, 20 и 30 соединены с точкой доступа через распределительную систему (DS). Точка доступа использует тег 802.1Q для сопоставления номеров VLAN с соответствующими SSID. Например, VLAN 10 сопоставляется с SSID "Моя сеть", VLAN 20 сопоставляется с SSID "Чужая сеть" и VLAN 30 к SSID "Гости".
На рисунке показан процесс поддержки нескольких SSID одной точкой доступа:
Несмотря на то, что точка доступа поддерживает одновременно несколько логических беспроводных сетей, каждый из SSID работают в одной зоне (области). Причина в том, что точка доступа использует один и тот же передатчик, приемник, антенну и канал для каждого SSID. Однако это утверждение может ввести в некоторое заблуждение: несколько SSID могут создать иллюзию масштабируемости сети. Хоть и беспроводные клиенты могут быть распределены по разным SSDI, но все же они используют совместно одну точку доступа. А это в свою очередь приводит к "борьбе" за эфирное время на канале.
Расширенный набор услуг
Обычно одна точка доступа не может охватить всю зону (область), где могут находиться клиенты. Например, потребуется беспроводное покрытие на всем этаже торгового центра, гостиницы, больницы или другого крупного здания. Что бы покрыть большую площадь, которую может охватить одна ячейка точки доступа, просто необходимо добавить больше точек доступа и распределить их по этажу (этажам).
Когда точки доступа расположены в разных местах, все они могут быть связаны между собой коммутируемой инфраструктурой. В стандарте 802.11 эта возможность называется расширенным набором услуг (extended service set (ESS))
Расширенный набор услуг показан на рисунке.
Идея состоит в том, чтобы заставить несколько точек доступа взаимодействовать так, чтобы беспроводное подключение было не заметным для клиента. В идеале, любые SSID, определенные на одной точке доступа, так же должны быть определены на всех остальных точках доступа в ESS (Extended Service Set). В противном случае клиенту приходилось бы каждый раз переподключаться, как только бы он попадал в ячейку другой точки доступа.
Как видно из рисунка, что каждая ячейка имеет уникальный BSSID, но обе ячейки имеют общий SSID. Независимо от местоположения клиента в пределах ESS, SSID останется тем же самым, но клиент всегда может отличить одну точку доступа от другой.
На рисунке показан принцип работы расширенного набора услуг. Коммутатор (VLAN 10) подключен к интернету по кабелю. Две точки доступа подключены к этому коммутатору так же проводами. Эти точки располагаются рядом так, что области их действия пересекаются. BSS двух точек доступа, объединены, и образуют расширенный набор услуг (ESS). AP-1 имеет BSSID d4:20:6d:90:ad:20, а её базовый набор услуг-BSS-1. Точка доступа подключена к клиенту по беспроводной сети. AP2 имеет BSSID e6:22:47:af:c3:70, а её базовый набор услуг-BSS-2. Точка доступа подключена к клиенту по беспроводной сети. SSID обоих BSS - это "Моя сеть". Переход клиента от одной точки доступа к другой называется роумингом.
В ESS беспроводной клиент может связываться с одной точкой доступа, пока он физически расположен рядом с этой точкой. При перемещении клиента в другое место, он автоматически подключается к ближайшей точке доступа. Переход от одной точки доступа к другой называется роумингом. Имейте в виду, что каждая точка предлагает свой собственный BSS на своем собственном канале, чтобы предотвратить помехи между точками доступа. Так как беспроводное устройство (клиентское) может перемещаться от одной точки доступа к другой, оно должно уметь сканировать доступные каналы, чтобы найти новую точку доступа (и BSS) для переподключения. Фактически клиент перемещается от BSS к BSS и от канала к каналу.
Независимый базовый набор услуг
Обычно беспроводная сеть использует точку доступа для организации, контроля и масштабируемости. Иногда это невозможно или неудобно в различных ситуациях. Например, два человека, которые хотят обменяться электронными документами на встрече, могут не найти доступную BSS или не смогут пройти аутентификацию в сети. Кроме того, многие принтеры могут печатать документы по беспроводной сети, не полагаясь на обычный BSS или точку доступа.
Стандарт 802.11 позволяет двум или более беспроводным клиентам напрямую связываться друг с другом, без каких-либо посредников сетевого подключения. Это называется специальной беспроводной сетью (ad hoc) или независимым базовым набором услуг (IBSS), как показано на рисунке. Чтобы это работало, одно из устройств должно стать главным и разослать в эфир свое сетевое имя, необходимые параметры беспроводного подключения, так же как это сделала бы точка доступа. Любое другое устройство может затем присоединиться по мере необходимости. IBSS предназначены для организации небольшой беспроводной сети для восьми - десяти устройств. Эта сеть не масштабируема.
Данное волокно состоит из стекла или пластика и позволяет передавать сигналы в виде света. Чтобы понять, как передаются сигналы в оптическом волокне, нам сначала необходимо разобраться со способами передачи лучей света.
Способы распространения сигналов в оптоволокне
Современная технология передачи данных поддерживает два метода распространения света в оптических каналах. Для каждого метода требуются волокна с различными физическими характеристиками.
Существуют:
Многомодовый
Одномодовый
Многомодовый режим может быть реализован в двух формах:
Step- Index
Graded- Index
Далее более подробно разберем каждый из двух методов.
Многомодовый
Это название произошло из-за волокна, по которому могут передаваться большое количество световых лучей, двигающихся через сердечник в различных направлениях. Эти лучи перемещаются внутри кабеля в зависимости от структуры сердечника.
Многомодовый Step-Index
В многомодовом волокне Step-Index от центра к краям плотность ядра остается постоянной. Луч света проходит через эту постоянную плотность по прямой линии, пока не достигнет границы раздела ядра и оболочки. На границе раздела происходит резкое изменение плотности на более низкую, что изменяет угол преломления луча. Внезапность этого изменения обозначается термином Step-index.
На рисунке ниже показаны различные лучи, проходящие через многомодовое Step-Index волокно. Часть лучей в середине проходят по прямым линиям через ядро и достигают цели, не отражаясь и не преломляясь.
Часть же лучей ударяются о поверхность раздела ядра и оболочки под углом, меньшим критического угла преломления. Эти лучи проникают сквозь оболочку и пропадают. Тем не менее, другие ударяются о край ядра под углами, превышающими критический угол, и отражаются в ядро и с другой стороны, отражаясь назад и вперед по каналу, пока не достигнут цели.
Многомодовый Graded-Index
Второй тип волокна называется многомодовым Graded-Index. Это волокно уменьшает искажение сигнала через кабель. Слово индекс здесь относится к индексу преломления, а индекс преломления связан с плотностью.
Таким образом, волокно с Graded-Index -это волокно с различной плотностью. Плотность самая высокая в центре ядра и постепенно уменьшается до самого низа на краю.
На этом рисунке показано влияние этой переменной плотности на распространение световых лучей.
Одномодовый
Одномодовое волокно использует режим step-index и сильно зависит от источника света, который использует ограниченный угол преломления света, близкий к горизонтали. Волокно изготавливается с гораздо меньшим диаметром, чем у многомодовых волокон, и с существенно меньшей плотностью (показателем преломления).
Уменьшение плотности световых пучков приводит к критическому углу преломления, который приближается к 90 градусам, так чтобы лучи распространялись почти горизонтально.
В этом случае распространение различных лучей осуществляется практически одинаково и задержки незначительны. Все лучи поступают на сторону приемника вместе и могут быть рекомбинированы без искажений сигнала.
Преимущества оптоволоконного кабеля
Помехоустойчивость: для передачи данных не используется электрический сигнал, а используется свет. Электромагнитные излучения не создают помех для передачи данных. Единственная возможная помеха-это внешний свет, который изолируется внешней оболочкой.
Меньшее затухание сигнала: расстояние волоконно-оптической передачи значительно больше по сравнению с другими управляемыми средами. Сигнал может проходить на многие километры, не требуя регенерации.
Более высокая пропускная способность: по сравнению с коаксиальным кабелем или витой парой, волоконно-оптический кабель может поддерживать значительно более высокую пропускную способность, что увеличивает скорость передачи данных. Существует ограничение на скорость передачи данных и использование полосы пропускания по волоконно-оптическому кабелю, причем не носителем, а доступной технологией передачи и приема данных.
Недостатки оптоволоконного кабеля
Стоимость: этот кабель дорогой, так как любые нарушения технологии изготовления сердечника могут ослабить передаваемый сигнал. Кроме того, лазерный источник света может стоить огромных денег, по сравнению с сотнями генераторов электрических сигналов.
Установка / техническое обслуживание: при наличии шероховатости или трещин в сердечнике оптического кабеля приведет к рассеиванию и затуханию сигнала. Все соединения должны быть идеально сварены. Соединения же медных кабелей могут быть сделаны путем резки и обжима с использованием относительно простых инструментов.
Хрупкость: оптоволокно может быть легко сломано, чем медный провод, что делает его не транспортабельным, то есть там, где требуется постоянное перемещение оборудования его использовать нельзя или по крайней мере не удобно.
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть 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. С таким багажом знаний, следующий проект для вас будет намного проще.