Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 2966 сообщений
Cообщения с меткой

http - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Маршрутизация в CleverStyle Framework

Воскресенье, 14 Августа 2016 г. 15:31 (ссылка)

Многие аспекты CleverStyle Framework имеют альтернативную по отношению к большинству других фреймворков реализацию тех же вещей.

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



Основное отличие



Главное отличие маршрутизации от реализаций в популярных фреймворках типа Symfony, Laravel или Yii это декларативность вместо императивности.



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

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



Основы маршрутизации



Любой URL в представлении фреймворка разбивается на несколько частей.



В самом начале до какой-либо обработки из пути страницы удаляются параметры запроса (? и всё что после него).



Далее мы получаем общий формат пути следующего вида (| используется для разделения выбора из нескольких вариантов, в [] сгруппированы необязательные самостоятельные компоненты пути), пример разбит на несколько строчек для удобства, перед обработкой путь разбивается по слэшах и превращается в массив из частей исходного пути:




[language/]
[admin/|api/|cli/]
[Module_name
[/path
[/sub_path
[/id1
[/another_subpath
[/id2]
]
]
]
]
]


Количество уровней вложенности не ограничено.



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

Формат зависит от используемых языков и их количества, может бы простым (en, ru), либо учитывать регион (en_gb, ru_ua).



После языка следует необязательная часть, определяющая тип страницы.

Это может быть страница администрирования ($Request->admin_path === true), запрос к API ($Request->api_path === true), запрос к CLI интерфейсу ($Request->cli_path === true) или обычная пользовательская страница если не указано явно.



Далее определяется модуль, который будет обрабатывать страницу. В последствии этот модуль доступен как $Request->current_module.

Стоит заметить, что название модуля может быть локализовано, к примеру, если для модуля My_blog в переводах есть пара "My_blog" : "Мой блог", то можно в качестве названия модуля использовать Мой_блог, при этом всё равно $Request->current_module === 'My_blog'.



Остаток элементов массива после модуля попадает в $Request->route, который может использоваться модулями, к примеру, для кастомной маршрутизации.



Перед тем, как перейти к следующим этапам, заполняются ещё 2 массива.

$Request->route_ids содержит элементы из $Request->route, которые являются целыми числами (подразумевается что это идентификаторы), $Request->route_path же содержит все элементы $Request->route кроме целых чисел, и используется как маршрут внутри модуля.



Как вклиниться в маршрутизацию на ранних этапах



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



Событие System/Request/routing_replace/before срабатывает сразу перед определением языка страницы и позволяет как-то модифицировать исходный путь в виде строки, самые низкоуровневые манипуляции можно проводит в этом месте.



Событие System/Request/routing_replace/after срабатывает после формирования $Request->route_ids и $Request->route_path, позволяя откорректировать важные параметры после того, как они были определены системой.



Пример добавления поддержки UUID как альтернативы стандартным целочисленным идентификаторам:



Event::instance()->on(
'System/Request/routing_replace/after',
function ($data) {
$route_path = [];
$route_ids = [];
foreach ($data['route'] as $item) {
if (preg_match('/([a-f\d]{8}(?:-[a-f\d]{4}){3}-[a-f\d]{12}?)/i', $item)) {
$route_ids[] = $item;
} else {
$route_path[] = $item;
}
}
if ($route_ids) {
$data['route_path'] = $route_path;
$data['route_ids'] = $route_ids;
}
}
);




Структура маршрутов



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



Пример текущей структуры API системного модуля:



{
"admin" : {
"about_server" : [],
"blocks" : [],
"databases" : [],
"groups" : [
"_",
"permissions"
],
"languages" : [],
"mail" : [],
"modules" : [],
"optimization" : [],
"permissions" : [
"_",
"for_item"
],
"security" : [],
"site_info" : [],
"storages" : [],
"system" : [],
"themes" : [],
"upload" : [],
"users" : [
"_",
"general",
"groups",
"permissions"
]
},
"blank" : [],
"languages" : [],
"profile" : [],
"profiles" : [],
"timezones" : []
}


Примеры (реальные) запросов, подходящих под данную структуру:




GET api/System/blank
GET api/System/admin/about_server
SEARCH_OPTIONS api/System/admin/users
SEARCH api/System/admin/users
PATCH api/System/admin/users/42
GET api/System/admin/users/42/groups
PUT api/System/admin/users/42/permissions




Получение окончательного маршрута



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



Для чего это нужно? Допустим, пользователь открывает страницу /Blogs, а структура маршрутов сконфигурирована следующим образом (modules/Blogs/index.json):



[
"latest_posts",
"section",
"post",
"tag",
"new_post",
"edit_post",
"drafts",
"atom.xml"
]


В этом случае $Request->route_path === [], но $App->controller_path === ['index', 'latest_posts'].



index будет здесь вне зависимости от модуля и конфигурации, а вот latest_posts уже зависит от конфигурации. Дело в том, что если страница не API и не CLI запрос, то при указании неполного маршрута фреймворк будет выбирать первый ключ из конфигурации на каждом уровне, пока не дойдет до конца вглубь структуры. То есть Blogs аналогично Blogs/latest_posts.



Для API и CLI запросов в этом смысле есть отличие — опускание частей маршрута подобным образом запрещено и допускается только если в структуре в качестве первого элемента на соответствующем уровне используется _.



К примеру, для API мы можем иметь следующую структуру (modules/Module_name/api/index.json):



{
"_" : []
"comments" : []
}


В этом случае api/Module_name аналогично api/Module_name/_. Это позволяет делать API с красивыми методами (помним, что идентификаторы у нас в отдельном массиве):




GET api/Module_name
GET api/Module_name/42
POST api/Module_name
PUT api/Module_name/42
DELETE api/Module_name/42
GET api/Module_name/42/comments
GET api/Module_name/42/comments/13
POST api/Module_name/42/comments
PUT api/Module_name/42/comments/13
DELETE api/Module_name/42/comments/13




Расположение файлов со структурой маршрутов



Модули в CleverStyle Framework хранят всё своё внутри папки модуля (в противовес фреймворкам, где все view в одной папке, все контроллеры в другой, все модели в третьей, все маршруты в одном файле и так далее) для удобства сопровождения.



В зависимости от типа запроса используются разные конфиги в формате JSON:


  • для обычных страниц modules/Module_name/index.json

  • для страниц администрирования modules/Module_name/admin/index.json

  • для API modules/Module_name/api/index.json

  • для CLI modules/Module_name/cli/index.json



В тех же папках находятся и обработчики маршрутов.



Типы маршрутизации



В CleverStyle Framework есть два типа маршрутизации: основанный на файлах (активно использовался ранее) и основанный на контроллере (более активно используется сейчас).



Возьмем из примера выше страницу Blogs/latest_posts и окончательный маршрут ['index', 'latest_posts'].



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




modules/Blogs/index.php
modules/Blogs/latest_posts.php




Если же используется маршрутизация, основанная на контроллере, то должен существовать класс cs\modules\Blogs\Controller (файл modules/Blogs/Controller.php) со следующими публичными статическими методами:




cs\modules\Blogs\Controller::index($Request, $Response) : mixed
cs\modules\Blogs\Controller::latest_posts($Request, $Response) : mixed




Важно, что любой файл/метод кроме последнего можно опустить, и это не приведет к ошибке.



Теперь возьмем более сложный пример, запрос GET api/Module_name/items/42/comments.



Во-первых, для API и CLI запросов кроме пути так же имеет значение HTTP метод.

Во-вторых, здесь будет использоваться под-папка api.



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




modules/Module_name/api/index.php
modules/Module_name/api/index.get.php
modules/Module_name/api/items.php
modules/Module_name/api/items.get.php
modules/Module_name/api/items/comments.php
modules/Module_name/api/items/comments.get.php




Если же используется маршрутизация, основанная на контроллере, то должен существовать класс cs\modules\Blogs\api\Controller (файл modules/Blogs/api/Controller.php) со следующими публичными статическими методами:




cs\modules\Blogs\api\Controller::index($Request, $Response) : mixed
cs\modules\Blogs\api\Controller::index_get($Request, $Response) : mixed
cs\modules\Blogs\api\Controller::items($Request, $Response) : mixed
cs\modules\Blogs\api\Controller::items_get($Request, $Response) : mixed
cs\modules\Blogs\api\Controller::items_comments($Request, $Response) : mixed
cs\modules\Blogs\api\Controller::items_comments_get($Request, $Response) : mixed




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



Как можно заметить, для API и CLI запросов используется явное разделение кода обработки запросов с разными HTTP методами, в то время как для обычных страниц и страниц администрирования это не учитывается.



Аргументы в контроллерах и возвращаемое значение



$Request и $Response не что иное, как экземпляры cs\Request и cs\Response.



Возвращаемого значения в простых случаях достаточно для задания контента. Под капотом для API запросов возвращаемое значение будет передано в cs\Page::json(), а для остальных запросов в cs\Page::content().



public static function items_comments_get () {
return [];
}
// полностью аналогично
public static function items_comments_get () {
Page::instance->json([]);
}




Несуществующие обработчики HTTP методов



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



API: если нет ни cs\modules\Blogs\api\Controller::items_comments() ни cs\modules\Blogs\api\Controller::items_comments_get() (либо аналогичных файлов), то:


  • в первую очередь будет проверено существования обработчика метода OPTIONS, если он есть — он решает что с этим делать

  • если обработчика метода OPTIONS нет, то автоматически сформированый список существующих методов будет отправлен в заголовке Allow (если вызываемый метод был отличный от OPTIONS, то дополнительно код статуса будет изменен на 501 Not Implemented)



CLI: Аналогично API, но вместо OPTIONS особенным методом является CLI, и вместо заголовка Allow доступные методы будут выведены в консоль (если вызываемый метод был отличный от CLI, то дополнительно статус выхода будет изменен на 245 (501 % 256)).



Использование собственной системы маршрутизации



Если вам по какой-то причине не нравится устройство маршрутизации во фреймворке, в каждом отдельном модуле вы можете создать лишь index.php файл и в нём подключить маршрутизатор по вкусу.

Поскольку index.php не требует контроллеров и структуры в index.json, вы обойдете большую часть системы маршрутизации.



Права доступа



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

В качестве группы при проверки прав доступа к странице используется название модуля с опциональным префиксом для страниц администрирования и API, в качестве метки используется путь маршрута (без учета префикса index).



К примеру, для страницы api/Module_name/items/comments будут проверены права пользователя для разрешений (через пробел group label):




api/Module_name index
api/Module_name items
api/Module_name items/comments




Если на каком-то уровне у пользователя нет доступа — обработка завершится ошибкой 403 Forbidden, при этом обработчики предыдущих уровней не будут выполнены, так как права доступа определяются на этапе окончательного формирования маршрута, до запуска обработчиков.



Напоследок



Реализация обработки запросов в CleverStyle Framework достаточно мощная и гибкая, являясь при этом декларативной.

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

Надеюсь, данного руководства достаточно для того, чтобы не потеряться.

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



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

GitHub репозиторий: github.com/nazar-pc/CleverStyle-Framework

Документация по фреймфорку: github.com/nazar-pc/CleverStyle-Framework/tree/master/docs



Конструктивные комментарии как обычно приветствуются.



Какой подход предпочитаете вы?




























Проголосовало 6 человек. Воздержалось 3 человека.





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


Original source: habrahabr.ru.

https://habrahabr.ru/post/307690/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Хабрахабр в гостях у Александра Лямина, QRATOR

Суббота, 31 Июля 2016 г. 00:17 (ссылка)





Полная версия видео доступна в конце публикации и по ссылке



Это была лишь середина жаркого московского июля, который вот-вот подойдёт к концу. Договорившись с Александром о записи, мы все немного волновались — никогда ещё никто в Хабрахабре не пытался вести предметный диалог с известным техническим специалистом на видео. Не были мы оба уверены и в ходе диалога — в первую очередь потому что, оба Александры, мы никогда не встречались до этого лично. Тем не менее, наша небольшая съёмочная группа прибыла на место назначения, где-то между Беговой и Полежаевской.



Герой сегодняшнего рассказа и диалога родился в городе Ногинск Московской области. Как он рассказал нам, вся его семья по маминой линии из этого региона — на Клязьме деревня была еще несколько веков назад.



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



Ключевых отправных точек в жизни сегодняшнего героя было две. Первая – это когда в 10 лет он увидел «Роботрон-1820», немецкий компьютер: «Меня сильно удивило, что можно рисовать в телевизоре. Мне стало интересно, что это такое, как можно программировать, что такое операционная система. Так получилось, что семья у меня была не сильно богатая…».



Своего компьютера у Саши не было — он занимался в кружке программирования, в областном Дворце Пионеров. Ездил на Олимпиады по программированию, так же, как и по многим другим естественно-научным предметам.



Зато, хватается он, у одного из первых в городе появился модем — подарили старый-старый терминал DEC VT-220. Так он познакомился с миром сетей.



Второй такой wow-момент был, когда Александр понял, что может разговаривать с человеком, который находится вообще в другом полушарии. Это подвигло его к увлечению сетями – Х25, IP. Он стал сетевым инженером.



Первым местом работы Александра стала компания Инкома (сеть Х25). Там он проработал буквально одно лето, а потом устроился в компанию ComStar, где строил первую в России ISDN-ку. На тот момент (1996 год) считалось, что скорость в 128 Килобит в интернете — это очень круто.



Параллельно занимался консультациями, поучаствовал в создании dial-up пула в Ситилайн – самой большой компании такого рода и на тот момент в Москве. Немножко позанимался спутниковым интернетом. И в 1998 году, в разгар кризиса, Александра пригласили на работу в Московский государственный университет. По его словам, это было существенной потерей денег, но на тот момент сети круче, чем в МГУ, в России не было ни у кого. Поэтому наш герой, не сомневаясь, ушел туда и проработал до 2012 года.



Естественно, жить на университетскую зарплату сложно. Параллельно, как уже говорилось, Саша занимался консультациями, поработал в команде Ханса Райзера, который делал файловую систему Razer FS. И в этот момент ощутил, что для того, чтобы заниматься сетями, нужно еще заниматься операционными системами, которые в этих сетях живут.



Далее работал в разовых проектах, но было несколько крупных и среди них. Можно отметить его сотрудничество с Игорем Мацанюком (IT-Territory), где Александр оказался как консультант и работал part-time. Это была интересная история: «Пришел в гости к своему другу, который там работал. Сидели и обсуждали какие-то технические проблемы у них в офисе на кухне. Заходит какой-то мужик и говорит: «Ты у меня работаешь». Я удивляюсь и говорю: «Да нет, у меня в принципе все хорошо…». Он говорит: «Мне все равно, ты у меня работаешь». Так я и познакомился с Игорем Мацанюком.»



В какой-то момент герой нашего рассказа решил, что можно попробовать адаптировать веб-игрушки для вывода на мировой рынок. К моменту, когда в России только появилась Zynga, у компании, в которой трудился Александр, уже были 4 игры, которые зарабатывали больше $1 миллиона в год, и был отработан технологический стек: «Без ложного стеснения могу сказать: идея того, что можно играть не из нативного клиента, появилась в России».



В 2007 году Александр ушел из IT-Territory, чтобы создать свою консалтинговую компанию. Проработал в таком формате ровно два месяца: «Первый мой заказчик из поисковой системы по товарам предложил стать партнером и техдиректором. Это был короткий период увлечения поисковыми алгоритмами и товарным поиском. Ну, и с 2008 года я занимаюсь Qrator и системами фильтрации трафика».



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







— Когда и по какой причине родилась идея, которая переросла в Qrator? Что было началом?


Давайте начнем с момента, который был до Qrator. Я консультировал людей и организации по поводу того, как строить распределенные сетевые приложения. И в 2008 году так получилось, что тот проект, которым я занимался (это был товарный поиск), был продан Microsoft.



По своему предыдущему опыту знаю, что кризис – это всегда время, когда можно заняться тем, что интересно тебе – для души. Потому что все равно большой бизнес делать в этот момент – не совсем удачная идея. В 2008 году мы решили позаниматься исследованием проблематики DDoS, потому что к тому моменту у меня уже была накоплена некоторая база, был опыт. До того с этой проблемой сталкивались регулярно, хотелось изучить её фундаментально. Поэтому я пришел к своему руководству в Московский государственный университет и сказал: «Смотрите, есть такая штука Электронное правительство. И это значит, что в интернет идет критическая инфраструктура».



Если вы не сможете посмотреть почту – это одна история. Если вы не можете обратиться в налоговую со своей проблемой – совсем другая история. У правительственных ресурсов в этом смысле дела обстоят крайне плохо. И я продемонстрировал это. У меня был наладонник Nokia 900 и самописный код на С. Прямо по GPRS-связи зашел на тестовый сайт, который сделал мой знакомый, и вывел его из строя за несколько секунд. Руководство согласилось.



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



— А в какой момент произошло обособление Qrator? Если говорить юридическим языком, в какой момент вы зарегистрировали ООО, поняв, что это будущий бизнес? Все тот же 2008 год?


Нет. Могу даже назвать дату – это было 22 июня 2010 года. Мы приняли на университетскую сеть атаку, которая превышала возможности магистрали сети. И университетское начальство сказало: «Это все очень интересно… но хорошо, что это 22 июня произошло, потому что учебный процесс закончен, каникулы. А в семестровый период мы не можем такого себе позволить, поэтому нужно что-то делать с проектом: или находить финансирование, или закрывать его».



Это был переломный момент. Я понял, что с этим нужно что-то делать. И плюс ко всему – интересный фактор: производительности сети не хватало. Перенести оборудование с университетской сети без федерального финансирования было невозможно, поэтому я инвестировал собственные накопленные средства в то, чтобы построить распределенную. На первом этапе было три площадки – все они находились в России. Уже 1 сентября 2010 года мы запустили эти площадки в эксплуатацию.



— Насколько вообще математикоемкая и алгоритмоемкая эта задача – защита от DDoS? Я разговаривал со специалистами различного профиля для того, чтобы глубже понять это. И в целом, я слышу, что якобы никакой нетривиальной задачи там нет: это вопрос протоколов, точек в распределенной сети, ширины канала и так далее. Что вы можете сказать по этому поводу?


Я тут улыбнусь и прокомментирую это следующим образом. У меня есть слайд, который «гуляет» почти по всем презентациям, на котором мы пытаемся сформулировать, как мы классифицируем DDoS-атаки. Это 4 уровня:

1. транспортный;

2. TCP/IP уровень;

3. уровень инфраструктуры сети;

4. уровень приложений.
Начнем с самого первого уровня. Переполнение канала – самый простой и тривиальный способ для того, чтобы и атаковать, и защищаться. Казалось бы, просто достаточно иметь эту полосу. В качестве контрпримера (потому что это задача тривиальная) приведу следующую ситуацию, это реальная история. Заказчик располагается в крупном российском дата-центре. Дата-центр декларирует, что у него 600 гигабит. Это действительно так: набор физических интерфейсов емкостью 600 гигабит. Но на самом деле это не что-то единое, это дискретные интерфейсы, по которым трафик распределяется по каким-то алгоритмам. Что контролируют эту алгоритмы?



Это низкоуровневые механики типа LACP и высокоуровневые типа маршрутизации, например, BGP. И тут, как обычно, дьявол в деталях: самые важные межоператорские стыки у этого центра – самые загруженные. Поэтому хватило атаки, слегка превышающей 30 гигабит в секунду, для того, чтобы сделать нашего заказчика и все остальные ресурсы в этом дата-центре недоступными для большинства аудитории.



Люблю приводить такой пример: атака на полосу – это как удар кулаком в лицо. Больно, ощутимо сразу. Но стоит кулак «распылить», и это уже не настолько ощутимо. Не будет нокдауна. Но как именно распределить трафик – задача не такая тривиальная.



Внутри сети, там, где вы контролируете свои стыки, там, где вы контролируете механику посева по физике, – там все просто. Если мы выходим на уровень магистральной межоператорской связности (тот самый протокол BGP – Border Gateway Protocol), в текущей своей имплементации он больше похож на черный ящик, у которого есть только один метод управления, и он работает совершенно не очевидным способом.



Почему? Потому что так устроен дизайн протокола BGP. Попытаюсь объяснить просто. BGP – стандартный distant-selector протокол, казалось бы. Но на самом деле он отражает в себе не столько топологию сети, сколько материальные отношения между участниками сети. Так называемый local pref – это и есть синтетическая метрика, которую операторы используют для того, чтобы банально заработать больше денег (что естественно для любого бизнеса). Local pref имеет более высокий приоритет, чем ваш единственный метод управления. Соответственно, если вы не знаете, что вы делаете, у вас нет шансов построить сеть, которую можно будет сбалансировать и грамотно распылить большие объемы трафика.



Мы это прекрасно понимали еще в 2008 году, поэтому у нас появилась крайне интересная машинка, которую мы называли между собой «радаром Азимова». Машинка являет собой ни много ни мало очередную модель интернета, которая моделирует связность сети на межоператорском уровне. Грубо говоря, она в состоянии решать задачу предсказания пути трафика из любой точки интернета до любой точки интернета. И это позволяет нам строить нашу сеть не эмпирически, как делает сейчас большинство операторов связи, а используя математическое моделирование. Мы точно знаем, где нам надо поставить следующую точку на карте так, чтобы она была эффективна и с технической точки зрения, и с точки зрения бизнеса.



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



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



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



И тут опять смотрим… Протокол BGP, версия 4, изобретен в позапрошлом десятилетии. Устаревший, крайне уязвимый. Нам это было очевидно еще в 2008 году. Но, к сожалению, в отличие от предыдущего уровня, здесь невозможно этот протокол переписать, потому что, переписав только свою часть, мы изменим и обеспечим устойчивость только своей сети (что мы, собственно говоря, и сделали). Но весь остальной интернет нам неподконтролен. Его мы можем либо мониторить на предмет злонамеренного воздействия (что мы и делаем для всех наших заказчиков, используя тот же самый Qrator.Radar), либо изменить его (что мы тоже сейчас делаем).



Здесь есть единственный способ, которого я лично дико боялся и продолжаю бояться. Потому что если вы хотите сделать новый интернет-стандарт, у вас есть только одна дорога: вы должны написать драфт этого стандарта, податься с ним в IETF (Internet Engineering Task Force) и убедить IETF, свою орг. группу, всех операторов связи и инженеров, которые в ней работают, что вы делаете правильное дело, которое а) решает проблему, б) делает это эффективно. И это то путешествие, в котором мы сейчас находимся.



Тот стандарт, с которым мы работаем сейчас, – это самая простая и маленькая идея из тех, которые витают у нас в голове на данный момент. Потому что даже с тривиальными идеями, особенно новичкам (а мы именно новички в ИТ, несмотря на многолетний опыт), бывает очень непросто. Думаю, что как только мы получим какую-то обратную связь (любую: позитивную или негативную, например, выход другого конкурирующего предложения), для нас это будет хорошо. Потому что нам было важно заварить эту кашу, обозначить, то здесь есть проблемы, надо их решать, и в конечном итоге сделать BGP безопасней. Неважно, произойдет ли это с помощью наших идей или идей конкурирующей команды.



Конкурирующая команда – более, чем достойная. Это люди, которые работают в NIST, Американском институте стандартов и времени. У них тоже есть идеи, они не плохие – они просто другие.



И последний уровень, самый верхний, – уровень приложений. Как правило, на данный момент большинство приложений, существующих в сети, – это HTTP-based, то, что мы привыкли называть «Web’ом». Там тоже очень интересная проблематика. Но это не только Web.



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



В 2008 году у меня была очень простая и понятная идея: чем отличается робот от неробота? ККапча — очень грубый инструмент. В Советском Cоюзе роботы решают капчу гораздо лучше, чем люди. Она раздражает меня лично, и ее можно легко обойти, причем в автоматическом формате. То, что такие методы прохода капчи возникнут, было очевидно еще в 2008 году.



Поэтому в качестве основной я выбрал простую идею: роботы видят веб-страницу

иначе, чем люди. Когда вы открываете веб-страницу,

1. вам требуется время на то, чтобы обработать ее содержимое;

2. вы реагируете вполне определенно эмоциональным образом на ее оформление;

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



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



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



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



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



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



На мой взгляд, задача крайне интересная… Кстати, вы можете познакомиться с этой моделью интернета. В какой-то момент человек, который занимается PR нашей компании, сказал: «Саша, у вашей компании должен появиться блог». Я подумал и сказал: «Знаете, мы в принципе можем писать блог… Но есть такое дело: либо ты пишешь блог, либо ты пишешь код. Мне милее второе, потому что нас мало и нужно писать код. Поэтому давайте мы что-нибудь придумаем. Вот у нас есть модель интернета, давайте мы ее сделаем в виде блога».



И так мы сделали то, что сейчас можно найти на сайте radar.qrator.net. Это, в принципе, модель интернета.



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



Дальше было, кстати, очень интересно. Первый фидбэк, который я получил про нее, – это обратная связь от коллег из Renesis, которые уточнили: «Александр, а как вы видите вашу компанию: как scientific-лабораторию крупной американской компании или как самостоятельную?». На что я рассмеялся и сказал: «Ребят, это даже не наш продукт, мы на этом деньги не зарабатываем».



На каждом уровне есть свои математические вызовы. Задача может казаться простой только на первый взгляд. Я встречал много коллег, которые считают, что стоит научиться быстро обрабатывать пакеты, и проблема DDoS для вас решена. На самом деле, нет.



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


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



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



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



На мой взгляд, прямо сейчас идет разворот тренда, и великолепно это иллюстрирует недавняя успешная атака на Blizzard. И это несмотря на то, что Blizzard считали, что у них суперготовность Blizzard, в свою очередь, прикрывал TNT. Атака была проведена с использованием того, что сейчас журналисты называют интернетом вещей (IoT). Это на самом деле, «сборная солянка» мелких устройств с дырявыми прошивками, которые атакующая сторона собрала в кулак и провела успешную атаку. Так что, тренды постоянно меняются.



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


Одно только могу сказать, что мы – компания инженерная. Для нас важны инженеры и математики. А еще лучше, если человек совмещает в себе и то, и другое. Минимальное требование – человек не должен бояться математики. Если ты не боишься математики – это уже неплохо.



Могу выделить несколько групп, которые у нас работают:



1. Математики решают задачи кластеризации, анализа данных. Часто приходится делать что-то в реал-тайме или близко к реал-тайму.



2. Низкоуровневое программирование и программирование PLIS. Это инженеры, которые могут писать эффективный код быстро и качественно. У нас, как правило, приживаются люди с опытом спортивного программирования.



3. Команда, которая пишет то, что мы называем инфраструктурой. Это, собственно говоря, и есть движок Qrator’а. Здесь важен подход прагматичный, deutsch-инжиниринг с пониманием того, что мы с этим кодом будем делать дальше. Модульные инфраструктуры способны заглянуть в терминах развития своего кода не в «завтра», но и в «послезавтра».



В отличие от многих других решений, мы стоим инлайн. Мы обрабатываем трафик наших заказчиков постоянно, каждую секунду. Если где-то у нас возникают проблемы, заказчики это непременно почувствуют и это выльется, в конечном итоге, в потери. Поэтому требования к архитектуре, качеству кода и инфраструктуре, конечно, космические. То есть, оперировать Qrator’ом – это сродни полету в космосе: ничего не должно отказывать. Если какой-то из модулей выходит из строя, система, как правило, автоматически диагностирует его и выводит из обслуживания. По крайней мере, к этому мы стремимся. Это инфраструктура.



4. Есть еще группа сетевиков-математиков, которые разрабатывают и строят модель Radar’а. По сути, это такой внутренний продукт, у которого мы являемся единственным заказчиком, потому что именно эти люди говорят, где и когда зажжется следующая точка на глобусе, где мы запустим следующий центр очистки трафика.



5. Я говорил уже, что у нас очень мало веб-программистов. Сейчас их стало четверо – это уже полноценный отдел. И вся эта математика, «колокольчики» и «свисточки» не имеют смысла, если вы не можете это представить в конечном виде пользователю. Достаточно посмотреть на тот же Radar или Qrator, где объем данных, которые нужно представить пользователю, составляет более 6 Тбайт метаданных в сутки. Их можно и нужно представлять в виде пользовательского интерфейса так, чтобы конечный человек с самым разным уровнем технологической подготовки мог это воспринять. Или графы связности в том же самом Radar’е – не самая простая визуализация.



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



6. Группа эксплуатации – это наш интерфейс ко всем организациям: к партнерам, операторам связи, к заказчикам. Это те люди, на которых выпадает, наверное, больше всего стресса, которые оперируют в формате 24/7, решая иногда сложнейшие задачи по траблшутингу. Поэтому обычно люди, приходящие на должность инженера NOC, несколько удивлены уровнем задач, которые мы им даем на собеседовании. Нужно понимать, что это траблшутинг не только нашей собственной сети, но и окружения, всего того зоопарка оборудования, который реально может встретиться в энтерпрайзе у заказчиков.



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



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


Хостинги и телекоммуникационные компании для нас при текущем положении дел – однозначно партнеры. Мы просто не рассматриваем их как конкурентов. И, как я уже говорил, сама проблематика динамична в поле игры. Давайте посмотрим на ситуацию в ретроспективе…



Вот появилась проблема DDoS, появилась эффективная механика SYN-flood, направленная на TCP/IP стек. Как отреагировала индустрия? Бернштайн придумал SYN cookies. Их можно включить прямо на хосте и эффективно решить проблему. Скорости SYN flag росли. Обычные сервера перестали справляться. Появились коробочные решения, которые вставали в стойку к заказчику. И к коробке, которая моргает лампочками (Firewall), добавилась коробка DDoS-mitigation. Это тоже решило проблему, но только на какой-то период.



Скорости, packet rate атак продолжали расти, и тот канал, который приходил в дата-центр или в стойку заказчика, перестал справляться. Рынок отреагировал на это следующим образом: устройства, услуга, оборудование мигрировали в сеть операторов связи. Поставщиком услуги стали операторы связи, сеть которых, как правило (не берем в расчет таких гигантов, как Google или Яндекс), мощнее сетей заказчиков.



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



Скорости атак продолжали расти, и за последнее десятилетие они выросли на порядок, или даже порядки. Для примера можно сказать, что та атака, которая была произведена на нашу площадку в университете, едва превышала 14 Гигабит в секунду. На данный момент мы сталкиваемся регулярно с атаками, которые превышают 100 Гбит, 140 Гбит, 300 Гбит.



Недавно наши коллеги из Микапсулы предоставили данные об атаках, превышающих 500 Гбит. В принципе, на мой взгляд, операторам связи становится экономически невыгодно строить сети, способные выдерживать такие атаки. Логика развития сети оператора связи так выглядит: «У меня есть заказчики (например, в городе Одинцово). Протяну-ка я туда волокно». Заказчиков становится больше, туда тянется ядро сети, и оттуда выходят лучи следующего access-level. Оператор связи всегда тянется за своей клиентской базой и обязательно строит магистраль. Это очень дорого.



Как развивается Qrator? Он ставит точки туда, где можно перехватить паразитный трафик как можно раньше. Как взлет баллистической ракеты: на момент разгона мы ее перехватили, купировали трафик атаки в том регионе, откуда он происходит. Таким образом мы создаем меньше нагрузки на инфраструктуру сети и можем получить получше цены от операторов в регионе. Потому что, приходя в регион, мы говорим: «Дорогие операторы связи, мы любим держать наш трафик локально даже больше, чем вы. Это не шутка. Трафик, имеющий происхождение в регионе, останется в регионе». И это касается не только трафика атаки, но и легитимного трафика.



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



С точки зрения бизнеса наши затраты на развитие сети существенно ниже затрат любого оператора связи. А эффективность ее работы – выше.



— Как много сегодня у вас точек присутствия? Какие планы до конца 2016 года?


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



В том же Radar’е вы можете сделать запрос про Qrator и увидеть все наши точки присутствия по операторам связи, по географии: Сан-Хосе, Даллас, Эшборн, Амстердам, Стокгольм, Россия, Казахстан, Гонконг. В планах – до конца года обязательно открыть точки присутствия в Токио и Сингапуре. Без них, к сожалению, наше присутствие в Юго-Восточной Азии не является полным. На следующий год, наверное, будем смотреть в сторону Южной Америки.



— Насколько хорошо сегодня этот рынок растет?


Рынок растет. Рынок растет динамично. Мы в последние пять лет росли, несмотря на кризис, минимум на 100% в год. Но в этом году мы почувствовали, что российский рынок близится к заполнению. Это было предсказуемое событие. Поэтому мы начали экспансию. Мы стараемся двигаться на Запад и настраиваемся на Восток.



— Про атаку на российские СМИ в 2011 году… Как вы поучаствовали в этой истории? Каково было ваше место в ней? Я могу ошибаться, но мне кажется, про вас тогда широко услышали многие…


Я, наверное, не сказал бы, что 2011 год был поворотным с точки зрения бизнеса. Мы, когда стартовали, сделали все ошибки, которые только можно было. В частности, традиционная ошибка любого стартапа – переоценка рынка. Я считал, что рынок уже сформировался. Мы стартовали с планами, нацеленными на mass market, и просто промахнулись.



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



В 2011 году приключилось интересное событие, которое наделало много шума в прессе, но на бизнесе, на самом деле, не сильно сказалось. Это были парламентские выборы в России. В принципе, мы понимали, что общество идет к выборам в достаточно «нагретом» состоянии, будут возмущения и выступления.



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



Выборы – отличный пример, поэтому мы к ним готовились. Мы понимали, что что-то будет. За месяц до выборов у нас были отменены выходные, было организовано 24-часовое дежурство. Но все прошло крайне спокойно, было все тихо. И в день выборов я решил, что все закончилось, и пошел с семьей в театр. В первые 15 минут у меня начинает звонить телефон. Я его поднимаю и понимаю, что для меня на сегодня там театр закончился и начался в другом месте. Я взял ноутбук и побежал в ближайший Старбакс.



24 часами позже мы собрали у себя в сети фильтрации все, какие только можно российские СМИ, которые принято называть независимыми.



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



Отработали мы отлично. Мы к этому событию были готовы технически. Все было вполне предсказуемо: каких-то хайлайтов я бы не привел.



Интересно, что в тот же момент к нам пришел человек, который представился корреспондентом The Wall Street Journal. Он два часа задавал мне очень въедливые вопросы. Я сначала не поверил, думал, что это какая-то разведка индустриальная. Когда статья не вышла на следующей неделе, я про это и забыл. Но через неделю про нас вышла заметка. У меня бумажная версия этой газеты где-то дома лежит.



Мне позвонили друзья и сказали: «Саша, поздравляю, отличная джинса». На что я удивился и сказал: «У меня нет таких денег, чтобы купить в Wall Street Journal журналиста».



Но эта история для бизнеса не имела почти никаких последствий.



— Вопрос про конкурентов. Как много таких компаний? Где они находятся? Как вы оцениваете свое положение на рынке защиты от DDoS?


Я считаю, что у нас получилось занять уверенную позицию в России. Недавно Forbes выпускал свой рейтинг ТОП-50 российских интернет-компаний. Семь из них – наши заказчики. На мой взгляд, это такая цифра, говорящая.



В России, безусловно, конкуренция есть. Мы стартовали на полгода позже, чем сервис «Лаборатории Касперского». Это более чем сильный игрок. Нам приходилось и приходится зубами и когтями вырывать у них свою долю рынка.



Мы также ощущаем присутствие «Ростелекома». Он традиционно обслуживает госзаказчиков. Но, имея готовое оборудование, инфраструктуру, успешно предоставляет их коммерческим заказчикам. У операторов связи есть преимущество – заказчик к оператору связи уже подключен.



Помимо этого, есть огромное количество стартапов.



Ситуация не меняется лет семь точно. В России за год стартует одна-две компании, которые выходят на рынок с сервисами защиты от DDoS.



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



— А международные конкуренты?


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



Коробочные решения – это традиционно Arbor и Radva, и еще китайский NSfocus. Есть куча мелких игроков, но это тройка лидеров.



Есть операторы, которые предоставляют услугу на базе своих коробок: это практический любой крупный оператор – Deutsche Telecom, ETI и так далее. Есть компании-специалисты, которые используют чужой технологический стек и чужие решения, – Prolexic и Akamai.



И есть новая волна компаний, которые предоставляют облачные услуги. В отличие от предыдущих поколений, они сами разрабатывают свой технологический стек. За рубежом – это CloudFlare и Incapsula. В России – это мы и Касперский. В Азии можно еще назвать такого интересного игрока, как NexusGuard.



— Может, хотите подвести какой-то итог, обращаясь ко всей аудитории Хабрахабра? Что бы вы сказали тем ребятам, которые выпустились или учатся в университетах, или заканчивают последние классы школы?


Поколение до меня полетело в космос, добралось до Луны. Результаты моего поколения смотрятся как результаты неудачников. Мы построили существенный кусок российского интернета. Я тоже принимал в этом участие с самого старта. Но интернет на данный момент сломан (так я бы охарактеризовал его состояние). Его очень легко сломать, им легко можно манипулировать кому угодно, будь то преступник, отдельное государство или политический блок.



На мой взгляд, с точки зрения эволюции человечества, ситуация абсолютно недопустимая. Интернет – это новое медиа, наш коллективный разум. А я очень не хочу, чтобы мы все сошли с ума. Поэтому его нужно срочно починить. Чем скорее, тем лучше.



Когда мне говорят: «Вот, я только выпустился из университета, что я могу сделать?».



У меня есть отличный пример. Это наш интерн, Женя Богомазов, который до сих пор учится в Московском государственном университете. Он пришел к нам как практикант на лето, а сейчас является автором существенной части того драфта изменений протокола BGP, который мы сейчас и пытаемся провести через IETF.



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



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



Помимо маршрутизации, есть еще такие пласты, как транспортный уровень, авторизация и аутентификация – все это тоже требует существенной работы. К сожалению, большинство крупных бизнесов, которые существуют в интернете (Google или Microsoft), несколько подуспокоились: «Работает – не трогай».



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



Полная версия:




Original source: habrahabr.ru.

https://habrahabr.ru/post/306776/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Получаем доменное имя, DNS и SSL сертификат нахаляву

Суббота, 03 Июля 2016 г. 00:24 (ссылка)

Привет, Хабр. Данный пост предназначен для любителей халявы и содержит готовый рецепт по получению доменного имени, услуг DNS-сервера и SSL-сертификата с затратами 0 рублей 0 копеек. Бесплатный сыр бывает только в мышеловке и это правда, так что рецепт скорее для тех кто хочет красивую ссылку на свой личный небольшой проект с поддержкой https а не для серьёзных проектов.





Доменное имя



Идём на сайт www.registry.cu.cc, там сразу же вбиваем нужное имя и нажимаем check availability => checkout если нужное имя доступно. После чего регистрируемся и идём в личный кабинет где видим свои доменные имена.



img1




img2




Находим нужное имя, идём в Nameserver и прописываем там DNS яндекса.



img3




img4




DNS-сервер



Далее идём сюда pdd.yandex.ru/domains_add и добавляем только что созданное доменное имя.



img5




Видим что «Не удалось найти домен в DNS», ждём пока яндекс его найдёт.



img6




После чего подтверждаем владение доменом добавив соответствующую CNAME запись как написано в подробной инструкции яндекса. После чего ждём пока яндекс найдёт нужную ему запись и подтвердит владение доменом. Может потребоваться довольно много времени.



img7




img8




img9




После чего видим долгожданную надпись о том что домен подключён и делегирован на DNS яндекса.



img10




Далее идём в Редактор DNS и добавляем A — запись привязывая доменное имя к ip — адресу своего сервера.



img11




Может пройти довольно много времени пока эта A — запись вступит в силу. Запустим что-нибудь локально ( ведь мы прописали адрес сервера 127.0.0.1 ) и посмотрим как будет ресолвиться наш домен. Работает!



ура!




На этом с DNS-сервером всё, теперь займёмся получением ssl сертификата и обеспечим доступ к нашему серверу по https ( безопасность превыше всего ).



SSL-сертификат



Идём на www.startssl.com/Validate, регистрируемся, выбираем Validations Wizard => Domain Validation (for SSL certificate), вводим наш домен



img12




И там нам предлагают доказать что мы владеем доменом при помощи e-mail, выбираем любой который нам нравится, создаём его в яндексе. Отправляем туда письмо, берём оттуда код и доказываем что домен принадлежит нам.



img13




img14




img15




Затем идём в Certificates Wizard => Web Server SSL/TLS Certificate, указываем наш домен, генерим и вставляем ключ и нажимаем submit



img16




Ключ можно сгенерировать например так

mkdir ./certificates
mkdir ./certificates/habr.cu.cc
cd ./certificates/habr.cu.cc
openssl genrsa -out ./habr.cu.cc.key 2048
openssl req -new -sha256 -key ./habr.cu.cc.key -out ./habr.cu.cc.csr
cat ./habr.cu.cc.csr


Сертификат получен! Скачиваем себе архив



img17


Распаковываем и копируем файлы ключей в директорию nginx



cp ~/Downloads/habr.cu.cc/1_habr.cu.cc_bundle.crt /usr/local/etc/nginx/1_habr.cu.cc_bundle.crt
cp ./habr.cu.cc.key /usr/local/etc/nginx/habr.cu.cc.key
nano /usr/local/etc/nginx/nginx.conf


Немного рихтуем конфиг



server {

listen 8080;

ssl on;

server_name localhost;

ssl_certificate /usr/local/etc/nginx/1_habr.cu.cc_bundle.crt;

ssl_certificate_key /usr/local/etc/nginx/habr.cu.cc.key;



Перезапускаем nginx



nginx -s stop
nginx


Открываем нашу страничку используя https… и всё работает!



ура!




Мы получили доменное имя, услуги DNS-сервера и подтверждённый SSL сертификат не заплатив никому ни копейки, и при этом совершенно легально. Для запуска нашего ультра-мега-гига сервиса осталось только поднять VPS и развернуть там нашу программу. Увы сегодня бесплатная ВПС-ка это слишком хорошо и нереально, за VPS-сервер всё-таки придётся платить кровавыми долларами из своего кармана. Но тем не менее всем хороших выходных и надеюсь заметка будет кому-нибудь полезной.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304600/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Получаем доменное имя, DNS и SSL сертификат нахаляву

Суббота, 03 Июля 2016 г. 00:24 (ссылка)

Привет, Хабр. Данный пост предназначен для любителей халявы и содержит готовый рецепт по получению доменного имени, услуг DNS-сервера и SSL-сертификата с затратами 0 рублей 0 копеек. Бесплатный сыр бывает только в мышеловке и это правда, так что рецепт скорее для тех кто хочет красивую ссылку на свой личный небольшой проект с поддержкой https а не для серьёзных проектов.





Доменное имя



Идём на сайт www.registry.cu.cc, там сразу же вбиваем нужное имя и нажимаем check availability => checkout если нужное имя доступно. После чего регистрируемся и идём в личный кабинет где видим свои доменные имена.



img1




img2




Находим нужное имя, идём в Nameserver и прописываем там DNS яндекса.



img3




img4




DNS-сервер



Далее идём сюда pdd.yandex.ru/domains_add и добавляем только что созданное доменное имя.



img5




Видим что «Не удалось найти домен в DNS», ждём пока яндекс его найдёт.



img6




После чего подтверждаем владение доменом добавив соответствующую CNAME запись как написано в подробной инструкции яндекса. После чего ждём пока яндекс найдёт нужную ему запись и подтвердит владение доменом. Может потребоваться довольно много времени.



img7




img8




img9




После чего видим долгожданную надпись о том что домен подключён и делегирован на DNS яндекса.



img10




Далее идём в Редактор DNS и добавляем A — запись привязывая доменное имя к ip — адресу своего сервера.



img11




Может пройти довольно много времени пока эта A — запись вступит в силу. Запустим что-нибудь локально ( ведь мы прописали адрес сервера 127.0.0.1 ) и посмотрим как будет ресолвиться наш домен. Работает!



ура!




На этом с DNS-сервером всё, теперь займёмся получением ssl сертификата и обеспечим доступ к нашему серверу по https ( безопасность превыше всего ).



SSL-сертификат



Идём на www.startssl.com/Validate, регистрируемся, выбираем Validations Wizard => Domain Validation (for SSL certificate), вводим наш домен



img12




И там нам предлагают доказать что мы владеем доменом при помощи e-mail, выбираем любой который нам нравится, создаём его в яндексе. Отправляем туда письмо, берём оттуда код и доказываем что домен принадлежит нам.



img13




img14




img15




Затем идём в Certificates Wizard => Web Server SSL/TLS Certificate, указываем наш домен, генерим и вставляем ключ и нажимаем submit



img16




Ключ можно сгенерировать например так

mkdir ./certificates
mkdir ./certificates/habr.cu.cc
cd ./certificates/habr.cu.cc
openssl genrsa -out ./habr.cu.cc.key 2048
openssl req -new -sha256 -key ./habr.cu.cc.key -out ./habr.cu.cc.csr
cat ./habr.cu.cc.csr


Сертификат получен! Скачиваем себе архив



img17


Распаковываем и копируем файлы ключей в директорию nginx



cp ~/Downloads/habr.cu.cc/1_habr.cu.cc_bundle.crt /usr/local/etc/nginx/1_habr.cu.cc_bundle.crt
cp ./habr.cu.cc.key /usr/local/etc/nginx/habr.cu.cc.key
nano /usr/local/etc/nginx/nginx.conf


Немного рихтуем конфиг



server {

listen 8080;

ssl on;

server_name localhost;

ssl_certificate /usr/local/etc/nginx/1_habr.cu.cc_bundle.crt;

ssl_certificate_key /usr/local/etc/nginx/habr.cu.cc.key;



Перезапускаем nginx



nginx -s stop
nginx


Открываем нашу страничку используя https… и всё работает!



ура!




Мы получили доменное имя, услуги DNS-сервера и подтверждённый SSL сертификат не заплатив никому ни копейки, и при этом совершенно легально. Для запуска нашего ультра-мега-гига сервиса осталось только поднять VPS и развернуть там нашу программу. Увы сегодня бесплатная ВПС-ка это слишком хорошо и нереально, за VPS-сервер всё таки придётся платить кровавыми долларами из своего кармана. Но тем не менее всем хороших выходных и надеюсь заметка будет кому-нибудь полезной.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304600/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Вышел официальный HTTP клиент для Yii 2

Пятница, 01 Июля 2016 г. 18:14 (ссылка)

Команда Yii выпустила официальное расширение-клиент HTTP. Написано почти целиком Павлом Климовым. До последнего времени не было тегнуто как релиз из за несовместимости с PSR-7, хотя уже много где использовалось. После долгих обсуждений было решено выпускать без PSR-7. К нему, возможно, вернутся в 2.1.x.



Выполнение HTTP запроса выглядит вот так:



use yii\httpclient\Client;

$client = new Client();
$response = $client->createRequest()
->setMethod('post')
->setUrl('http://example.com/api/1.0/users')
->setData(['name' => 'John Doe', 'email' => 'johndoe@domain.com'])
->send();
if ($response->isOk) {
$newUserId = $response->data['id'];
}


https://github.com/yiisoft/yii2-httpclient


Original source: habrahabr.ru.

https://habrahabr.ru/post/304584/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Как HTTP/2 сделает веб быстрее

Пятница, 01 Июля 2016 г. 09:51 (ссылка)





Протокол передачи гипертекста (HTTP) — это простой, ограниченный и невероятно скучный протокол, лежащий в основе Всемирной паутины. По сути, HTTP позволяет считывать данные из подключённых к сети ресурсов, и в течение десятилетий он выступает в роли быстрого, безопасного и качественного “посредника”.

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



Содержание:




  • Что такое HTTP/2?

  • Для чего создавался HTTP/2?

  • Чем был плох HTTP 1.1?

  • Особенности HTTP/2

  • Как HTTP/2 работает с HTTPS?

  • Различия между HTTP 1.x, SPDY и HTTP/2

  • Основные преимущества HTTP/2

  • Сравнение производительности HTTPS, SPDY и HTTP/2

  • Браузерная поддержка HTTP/2 и доступность

  • Как начать использовать HTTP/2?



Что такое HTTP/2?



HTTP был разработан создателем Всемирной паутины Тимом Бернерсом-Ли. Он сделал протокол простым, чтобы обеспечить функции высокоуровневой передачи данных между веб-серверами и клиентами.



Первая задокументированная версия HTTP — HTTP 0.9 — вышла в 1991. В 1996 появился HTTP 1.0. Годом позже вышел HTTP 1.1 с небольшими улучшениями.







В феврале 2015 Рабочая группа HTTP Инженерного совета Интернета (IETF) пересмотрела протокол HTTP и разработала вторую основную версию в виде HTTP/2. В мае того же года спецификация реализации была официально стандартизирована в качестве ответа на HTTP-совместимый протокол SPDY, созданный в Google. Дискуссия на тему «HTTP/2 против SPDY» будет вестись на протяжении всей статьи.



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



Чтобы говорить «HTTP/2 против HTTP/1», давайте сначала вспомним, что означает сам термин «протокол», часто упоминаемый в этой статье. Протокол — это набор правил, регулирующих механизмы передачи данных между клиентами (например, веб-браузерами, запрашивающими данные) и серверами (компьютерами, содержащими эти данные).



Протоколы обычно состоят из трёх основных частей: заголовка (header), полезных данных (payload) и футера (footer). Заголовок идёт первым и содержит адреса источника и получателя, а также другую информацию, например размер и тип. Полезные данные — это информация, которая передаётся посредством протокола. Футер передаётся в последнюю очередь и выполняет роль управляющего поля для маршрутизации клиент-серверных запросов к адресатам. Заголовок и футер позволяют избегать ошибок при передаче полезных данных.







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



Протокол HTTP изначально состоял из двух основных команд:



GET — получение информации с сервера,

POST — принимает данные для хранения.



Этот простой и скучный набор команд — получение данных и передача запроса — лёг в основу и ряда других сетевых протоколов. Сам по себе протокол является ещё одним шагом к улучшению UX, а для его дальнейшего развития необходимо внедрить HTTP/2.



Для чего создавался HTTP/2?



С момента своего возникновения в начале 1990-х, HTTP лишь несколько раз подвергался серьёзному пересмотру. Последняя версия — HTTP 1.1 — используется уже более 15 лет. В эру динамического обновления контента, ресурсоёмких мультимедийных форматов и чрезмерного стремления к увеличению производительности веба, технологии старых протоколов перешли в разряд морально устаревших. Все эти тенденции требуют значительных изменений, которые обеспечивает HTTP/2.



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



В качестве усовершенствований HTTP используются такие механизмы, как контроль потоков (flow control), апгрейд (upgrade) и обработка ошибок. Они позволяют разработчикам обеспечивать высокую производительность и устойчивость веб-приложений. Коллективная система (collective system) позволяет серверам эффективно передавать клиентам больше контента, чем они запросили, что предотвращает постоянные запросы информации, пока сайт не будет целиком загружен в окне браузера. Например, возможность отправки данных по инициативе сервера (Server Push), предоставляемая HTTP/2, позволяет серверу отдавать сразу весь контент страницы, за исключением того, что уже имеется в кэше браузера. Накладные расходы протокола минимизируются за счёт эффективного сжатия HTTP-заголовков, что повышает производительность при обработке каждого браузерного запроса и серверного отклика.







HTTP/2 разрабатывался с учётом взаимозаменяемости и совместимости с HTTP 1.1. Ожидается, что внедрение HTTP/2 даст толчок к дальнейшему развитию протокола.



Марк Ноттингем, Глава Рабочей группы HTTP IETF и член W3C TAG:



«… мы не меняем весь HTTP — методы, коды статусов и большинство заголовков остаются теми же. Мы лишь переработали его с точки зрения повышения эффективности использования, чтобы он был более щадящим по отношению к интернету…»


Важно отметить, что новая версия HTTP идёт в качестве расширения для своего предшественника, и вряд ли в обозримом будущем заменит HTTP 1.1. Реализация HTTP/2 не подразумевает автоматической поддержки всех типов шифрования, доступных в HTTP 1.1, но определённо поощряет использование более интересных альтернатив, или дополнительное обновление совместимости шифрования в ближайшем будущем. Тем не менее, в сравнениях «HTTP/2 против HTTP 1» и «SPDY против HTTP/2» герой этой статьи выходит победителем по производительности, безопасности и надёжности.







Чем был плох HTTP 1.1?



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



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







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



Сетевой индустрии фактически пришлось хакнуть эти ограничения с помощью таких методик, как доменный шардинг (domain sharding), конкатенация, встраивание и спрайтинг (spriting) данных, а также ряд других. Неэффективное использование HTTP 1.1 базовых TCP-соединений является причиной плохой приоритезации ресурсов, и в результате — экспоненциальной деградации производительности по мере роста сложности, функциональности и объёма веб-приложений.











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



Например, с помощью Cookie Hack злоумышленники могут повторно использовать предыдущую рабочую сессию для получения несанкционированного доступа к паролю пользователя. А причина в том, что HTTP 1.1 не предоставляет инструментов конечного подтверждения подлинности. Понимая, что в HTTP/2 будут искать аналогичные лазейки, его разработчики постарались повысить безопасность протокола с помощью улучшенной реализации новых возможностей TLS.



Особенности HTTP/2





Мультиплексированные потоки



Пересылаемая через HTTP/2 в обе стороны последовательность текстовых фреймов, которыми обмениваются между собой клиент и сервер, называется “потоком”. В ранних версиях HTTP можно было транслировать только по одному потоку за раз, с небольшой задержкой между разными потоками. Передавать таким способом большие объёмы медиа-контента было слишком неэффективно и ресурсозатратно. Для решение этой проблемы в HTTP/2 применяется новый бинарный слой фреймов.



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







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




  • Параллельные мультиплексированные запросы и ответы не блокируют друг друга.

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

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

  • Задержки ниже, производительность сети выше, лучше ранжирование поисковыми системами.

  • В сети и IT-ресурсах уменьшаются операционные расходы и капитальные вложения.



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



Отправка данных по инициативе сервера (Server Push)



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







Полученный от сервера ресурс Y кэшируется на клиенте для будущего использования. Этот механизм позволяет экономить циклы «запрос-ответ» и снижает сетевую задержку. Изначально Server Push появился в протоколе SPDY. Идентификаторы потоков, содержащие псевдозаголовки наподобие :path, инициируют передачу сервером дополнительной информации, которая должна быть закэширована. Клиент должен либо явным образом позволить серверу передавать себе кэшируемые ресурсы посредством HTTP/2, либо прервать инициированные потоки, имеющие специальный идентификатор.



Другие возможности HTTP/2, известные как Cache Push, позволяют с упреждением обновлять или аннулировать кэш на клиенте. При этом сервер способен определять ресурсы, которые могут понадобиться клиенту, которые он на самом деле не запрашивал.



Реализация HTTP/2 демонстрирует высокую производительность при работе с инициативно передаваемыми ресурсами:




  • Инициативно передаваемые ресурсы сохраняются в кэше клиента.

  • Клиент может многократно использовать эти ресурсы на разных страницах.

  • Сервер может мультиплексировать инициативно передаваемые ресурсы вместе с запрошенной информацией в рамках того же TCP-соединения.

  • Сервер может приоритезировать инициативно передаваемые ресурсы. Это ключевое отличие с точки зрения производительности между HTTP/2 и HTTP 1.

  • Клиент может отклонить инициативно передаваемые ресурсы для поддержания эффективности репозитория, или может вообще отключить функцию Server Push.

  • Клиент может также ограничивать количество одновременно мультиплексированных потоков с инициативно передаваемыми данными.



В неоптимальных методиках наподобие встраивания (Inlining) также используются push-функциональности, позволяющие заставить сервер откликаться на запросы. При этом Server Push представляет собой решение на уровне протокола, помогающее избежать возни с оптимизационными хаками.



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







Двоичный протокол



Последняя версия HTTP претерпела значительные изменения с точки зрения возможностей, и демонстрирует преобразование из текстового в двоичный протокол. Для завершения циклов запрос-отклик HTTP 1.x обрабатывает текстовые команды. HTTP/2 решает те же задачи с помощью двоичных команд (состоящих из единиц и нулей). Это облегчает работу с фреймами и упрощает реализацию команд, которые могли путать из-за того, что они состоят из текста и необязательных пробелов.



Читать двоичные команды будет труднее, чем аналогичные текстовые, но зато сети будет легче их генерировать и парсить фреймы. Семантика остаётся без изменений. Браузеры, использующие HTTP/2, перед отправкой в сеть конвертируют текстовые команды в двоичные. Двоичный слой фреймов не имеет обратной совместимости с клиентами и серверами, использующими HTTP 1.x. Он является ключевым фактором, обеспечивающим значительный прирост производительности по сравнению с SPDY и HTTP 1.x. Какие преимущества даёт интернет-компаниям и онлайн-сервисам использование двоичных команд:




  • Низкие накладные расходы при парсинге данных — критически важное преимущество HTTP/2 по сравнению с HTTP 1.

  • Ниже вероятность ошибок.

  • Меньше нагрузка на сеть.

  • Эффективное использование сетевых ресурсов.

  • Решение проблем с безопасностью, наподобие атак с разделением запросов (response splitting attack), проистекающих из текстовой природы HTTP 1.x.

  • Реализуются прочие возможности HTTP/2, включая сжатие, мультиплексирование, приоритезацию, управление потоками и эффективную обработку TLS.

  • Компактность команд упрощают их обработку и реализацию.

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

  • Снижение сетевой задержки и повышение пропускной способности.



Приоритезация потоков



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







Приоритезация осуществляется с помощью присваивания каждому потоку зависимостей (Dependencies) и веса (Weight). Хотя все потоки, по сути, и так зависят друг от друга, ещё добавляется присваивание веса в диапазоне от 1 до 256. Детали механизма приоритезации всё ещё обсуждаются. Тем не менее, в реальных условиях сервер редко управляет такими ресурсами, как ЦПУ и подключения к БД. Сложность реализации сама по себе не даёт серверам выполнять запросы на приоритезацию потоков. Продолжение работ в этом направлении имеет особенное значение для успеха HTTP/2 в долгосрочной перспективе, потому что протокол позволяет обрабатывать многочисленные потоки в рамках единственного TCP-соединения.



Приоритезация поможет разделять одновременно приходящие на сервер запросы в соответствии с потребностями конечных пользователей. А обработка потоков данных в случайном порядке только подрывает эффективность и удобство HTTP/2. В то же время, продуманны и широко распространённый механизм приоритезации потоков даст нам следующие преимущества:




  • Эффективное использование сетевых ресурсов.

  • Снижение времени доставки запросов первичного контента.

  • Повышение скорости загрузки страниц.

  • Оптимизация передачи данных между клиентом и сервером.

  • Снижение отрицательного эффекта от сетевых задержек.







Сжатие заголовков с сохранением состояния



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



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







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



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




  • Эффективную приоритезацию потоков.

  • Эффективное использование механизмов мультиплексирования.

  • Снижает накладные расходы при использовании ресурсов. Это один из первых вопросов, обсуждаемых при сравнении HTTP/2 с HTTP 1 и SPDY.

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

  • Устойчивость к атакам, например, CRIME — эксплойтам потоков данных со сжатыми заголовками.



Различия между HTTP 1.x и SPDY



Базовая семантика приложения HTTP в последней итерации HTTP/2 осталась без изменений, включая коды статусов, URI, методики и файлы заголовков. HTTP/2 основан на SPDY, созданной в Google альтернативе HTTP 1.x. Основные различия кроются в механизмах обработки клиент-серверных запросов. В таблице отражены основные различия между HTTP 1.x, SPDY и HTTP/2:


































HTTP 1.x SPDY HTTP2
SSL не требуется, но рекомендуется. Необходим SSL. SSL не требуется, но рекомендуется.
Медленное шифрование. Быстрое шифрование. Шифрование стало ещё быстрее.
Один клиент-серверный запрос на одно TCP-соединение. Много клиент-серверных запросов на одно TCP-соединение. Осуществляются одновременно на одном хосте. Многохостовое мультиплексирование. Осуществляются на нескольких хостах в одном экземпляре.
Нет сжатия заголовков. Введено сжатие заголовков. Используются улучшенные алгоритмы сжатия заголовков, что повышает производительность и безопасность.
Нет приоритезации потоков. Введена приоритезация потоков. Улучшенные механизмы приоритезации потоков.


Как HTTP/2 работает с HTTPS



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







Браузерная поддержка HTTP/2 включает в себя HTTPS-шифрование, и фактически улучшает общую производительность обеспечения безопасности при работе с HTTPS. Ключевыми особенностями HTTP/2, позволяющими обеспечить безопасность цифровых коммуникаций в чувствительном сетевом окружении, являются:




  • меньшее количество TLS-хэндшейков,

  • меньшее потребление ресурсов на стороне клиента и сервера,

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







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



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



Основные преимущества HTTP/2



Сетевая индустрия должна заменить устаревший HTTP 1.x другим протоколом, преимущества которого будут полезны для рядовых пользователей. Переход с HTTP 1.x на HTTP/2 почти целиком обусловлен максимальным увеличением потенциала технологических преимуществ, чтобы они соответствовали современным ожиданиям.



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



HTTP/2 создавался с учётом повышения эффективности клиент-серверного обмена данными, что позволяет бизнесменам увеличить охват своих сегментов рынка, а пользователям — быстрее получить доступ к качественному контенту. Помимо прочего, сегодня веб ситуативен как никогда ранее.







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



Производительность сети



Это понятие отражает совокупный эффект всех нововведений HTTP/2. Результаты бенчмарков (см. главу «Сравнение производительности HTTPS, SPDY и HTTP/2») демонстрируют увеличение производительности при использовании HTTP/2 по сравнению с его предшественниками и альтернативными решениями.







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



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



Что происходит, когда механизмы передачи данных сметают все преграды на пути к повышению производительности сети? У высокой скорости работы сайтов есть побочные явления: пользователи получают больше удовольствия, улучшается оптимизация для поисковых сервисов, ресурсы используются эффективнее, растёт аудитория и объёмы продаж, и многое другое.



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



Производительность мобильной сети



Ежедневно миллионы пользователей выходят в сеть со своих мобильных устройств. Мы живём в «эру постПК», множество людей используют смартфоны в качестве основного устройства для доступа к онлайн-сервисам и выполнения большинства рутинных вычислительных задач прямо на ходу, вместо длительного сидения перед мониторами настольных компьютеров.



HTTP/2 проектировался с учётом современных тенденций использования сети. Задача нивелирования небольшой пропускной способности мобильного интернета хорошо решается благодаря снижению задержки за счёт мультиплексирования и сжатия заголовков. Благодаря новой версии протокола, производительность и безопасность обмена данными на мобильных устройствах достигают уровня, характерного для десктопов. Это сразу же положительно сказывается и на возможностях онлайн-бизнеса по охвату потенциальной аудитории.







Интернет подешевле



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







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



Экспансивный охват



Густонаселённые регионы Азии и Африки всё ещё испытывают нехватку доступа в интернет с приемлемой скоростью. Провайдеры стараются извлечь максимальную прибыль, предлагая свои услуги только в крупных городах и развитых районах. Благодаря преимуществам HTTP/2 можно будет уменьшить нагрузку на сети, выделив часть ресурсов и пропускной способности каналов для жителей удалённых и менее развитых районов.







Насыщенность мультимедиа



Сегодня интернет-пользователи практически требуют контент и сервисы, насыщенные мультимедиа, с моментальной загрузкой страниц. При этом для успешной конкуренции владельцам сайтов необходимо регулярно обновлять их содержимое. Стоимость соответствующей инфраструктуры не всегда подъёмна для интернет-стартапов, даже при условии использования облачных сервисов по подписке. Преимущества и технологические особенности HTTP/2, вероятно, не помогут сильно уменьшить размеры файлов, но зато снимут по несколько байт с накладных расходов при передаче «тяжёлого» медиа-контента между клиентом и серверами.



Улучшение опыта использования мобильного интернета



Прогрессивные онлайн-компании ради эффективного охвата быстрорастущей мобильной аудитории следуют стратегии Mobile-First. Пожалуй, главным ограничением, влияющим на использование мобильного интернета, являются не самые выдающиеся характеристики аппаратных компонентов смартфонов и планшетов. Это выражается в более длительных задержках при обработке запросов. HTTP/2 позволяет уменьшить продолжительность загрузки и сетевых задержек до приемлемого уровня.







Более эффективное использование сети



«Тяжёлый» медиа-контент и сайты со сложным дизайном приводят к заметному росту потребления ресурсов при обработке клиентом и сервером браузерных запросов. Хотя веб-разработчики и выработали приемлемые оптимизационные хаки, всё же появление устойчивого и надёжного решения в виде HTTP/2 было неизбежным. Сжатие заголовков, инициативная отправка данных сервером, зависимости потоков и мультиплексирование — всё это ключевые особенности, улучшающие эффективность использования сети.



Безопасность



Преимущества HTTP/2 не ограничиваются одной лишь производительностью. Алгоритм HPACK позволяет обходить распространённые угрозы, нацеленные на текстовые протоколы уровня приложения. Для защиты данных, передаваемых между клиентом и сервером, в HTTP/2 используется подход «Безопасность через непонятность» (Security by Obscurity): команды представлены в двоичном виде, применяется сжатие метаданных HTTP-заголовков. Кроме того, протокол может похвастаться полноценной поддержкой шифрования и требует применения улучшенной версии Transport Layer Security (TLS1.2).







Инновационность



HTTP/2 является воплощением идеи высокопроизводительной сети. Этот протокол лежит в основе кибермира, каким мы его знаем сегодня. Изменения, вносимые HTTP/2, в основном базируются на свойствах SPDY, который стал огромным шагом вперёд по сравнению с HTTP 1.x. И в ближайшем будущем HTTP/2 полностью заменит как SPDY, так и предыдущие версии HTTP. Веб-разработчики смогут избавиться от сложных оптимизационных хаков при создании высокопроизводительных сайтов и сервисов.



Преимущества HTTP/2 с точки зрения SEO



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



Стандартные процессы поисковой оптимизации выходят за рамки маркетинговой фронтэнд-тактики. Теперь они охватывают полный цикл обмена данными между клиентом и сервером. SEO-оптимизаторы, которые ранее были ключевыми фигурами в командах интернет-маркетинга, потеряли свои позиции с появлением новых технологий цифровых коммуникаций. И преобладание среди них HTTP/2 свидетельствует о тектоническом сдвиге, который заставляет веб-разработчиков и маркетологов вернуться к чертёжным доскам.







Критически важным фактором для поисковой оптимизации сегодня является внедрение и оптимизация инфраструктуры для HTTP/2 и многообещающих преимуществ в производительности. Онлайн-компании, страдающие от недостаточности адекватной органической пользовательской базы, не могут позволить себе пренебрегать HTTP/2, а следовательно и улучшениями с точки зрения SEO. Ведь этим компаниям приходится конкурировать на почве инноваций с растущими сетевыми бизнес-империями, и высоко ранжированный онлайн-сервис поднимется ещё выше благодаря реализации HTTP/2 на стороне серверов.



Сравнение производительности HTTPS, SPDY и HTTP/2



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







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



Подробности тестирования:



Результаты этого теста говорят нам следующее:




  • Размеры заголовков клиентского запроса и серверного отклика: HTTP/2 демонстрирует, что использование сжатия позволяет значительно уменьшить размер заголовка. При этом SPDY уменьшает заголовок только серверного отклика для данного запроса. HTTPS вообще не уменьшает заголовки.

  • Размер сообщения серверного отклика: размер отклика HTTP/2-сервера оказался больше, но зато в нём применялось более стойкое шифрование.

  • Количество использованных TCP-соединений: при обработке многочисленных одновременных запросов(мультиплексирование) HTTP/2 и SPDY используют меньше сетевых ресурсов, следовательно, снижается задержка.

  • Скорость загрузки страницы: HTTP/2 постоянно был быстрее SPDY. HTTPS был значительно медленнее из-за отсутствия сжатия заголовков и инициативной отправки данных сервером.



Браузерная поддержка HTTP/2 и доступность



HTTP/2 уже можно использовать при адекватной поддержке со стороны серверов и браузеров, в том числе мобильных. Работа технологий, использующих HTTP 1.x, не будет нарушена при реализации HTTP/2 на вашем сайте. Но их потребуется быстро обновить, чтобы они поддерживали новый протокол. Представьте, что сетевые протоколы — это языки общения. На новых языках можно общаться только тогда, когда как-то понимаешь друг друга. Так и здесь: клиент и сервер нужно обновить, чтобы обеспечить поддержку обмена данными с помощью протокола HTTP/2.



Клиентская поддержка



Пользователям не нужно заботиться о настройке поддержки HTTP/2 в своих браузерах — «полноценных» и мобильных. Chrome и Firefox давно поддерживают эту технологию, а в Safari поддержка HTTP/2 появилась в 2014. В IE данный протокол поддерживается только начиная с Windows 8.







Основные мобильные браузеры, включая Android Browser, Chrome для Android и iOS, а также Safari в iOS8 и выше, уже поддерживают HTTP/2. Рекомендуется на всякий случай поставить последние стабильные версии мобильных и настольных браузеров, чтобы получить максимальную производительность и преимущества в безопасности.



Серверная поддержка: Apache и Nginx



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



Nginx-серверы, составляющие 66% всех активных веб-серверов, могут похвастаться встроенной поддержкой HTTP / 2. А для обеспечения браузерной поддержки HTTP/2 на Apache, нужно воспользоваться модулем mod_spdy. Он разработан Google для внедрения поддержки в Apache 2.2 таких функций, как мультиплексирование и сжатие заголовков. Это ПО было передано в дар Apache Software Foundation.







Как начать использовать HTTP/2?



Для настройки HTTP/2 на своём сайте воспользуйтесь этой простой инструкцией:




  1. Проверьте, чтобы был включен HTTPS:


    • Приобретите в проверенной организации сертификат SSL или TLS.

    • Активируйте сертификат.

    • Установите сертификат.

    • Обновите сервер для включения протокола HTTPS.


  2. Проверьте, чтобы базовая сетевая инфраструктура включала в себя поддержку HTTP/2 на уровне серверного ПО. Серверы Nginx имеют нативную поддержку, в Apache она появилась в октябре 2015 (в версии 2.4). В более ранних версиях для поддержки HTTP/2 нужно установить дополнительные модули.

  3. Обновите, сконфигурируйте и протестируйте ваши серверы. Здесь описана конфигурация и процедуры тестирования для серверов Apache. Свяжитесь со своим хостинг-провайдером и удостоверьтесь, что ваш сайт готов к использованию HTTP/2.

  4. Для проверки правильности конфигурации HTTP/2 воспользуйтесь этим инструментом.



Заключение



Нас ждёт неизбежное доминирование и превосходство HTTP/2. Протокол уровня приложения, похоже, несёт в себе наследие HTTP 1.x, которое когда-то изменила сеть благодаря своим революционным возможностям по передаче данных. Но HTTP/2 демонстрирует гораздо более значительное технологическое превосходство над своим предшественником, чем HTTP 1.x в своё время.



Тем не менее, использование HTTP/2 — это лишь один шаг на пути к увеличению скорости загрузки страниц. В нашем Пособии по оптимизации скорости работы веб-сайта для начинающих описано, как создавать быстрые сайты, как исключать узкие места производительности, а также какие стратегические бизнес-преимущества даёт высочайшая производительность веб-сайта.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304518/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Идеальная производительность протокола HTTP

Вторник, 26 Апреля 2016 г. 14:48 (ссылка)

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:







Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.



Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?



HTTP/1.1

HTTP/1.1 это хороший протокол по целому ряду причин, но, к сожалению, производительность не одна из них по причине того, как современные веб-приложения его используют. А используют они его сегодня вот так:







Не очень-то хорошо.



Использование веб-приложениями протокола HTTP/1 достаточно «болтливо», поскольку клиент обращается к серверу снова и снова для загрузки необходимых ему файлов; сначала загружается HTML, затем CSS и Javascript. Загрузка каждого следующего файла добавляем в наш «разговор» с сервером новую главу, увеличивает общую задержку загрузки страницы, нарушая наше правило «минимальности необходимых раундов связи».



Более того, даже сами запросы к ресурсам уже добавляют много лишних данных, нарушая правило «минимальности необходимых данных». Это происходит из-за наличия заголовков вроде Referer, User-Agent и, конечно же, Cookie, которые повторяются в каждом запросе, умножаясь иногда в сотню раз от минимально необходимого их количества (по количеству ресурсов, необходимых средней страницей современного Веба).



Ну и наконец, из-за присущего протоколу HTTP/1 явлению HOL-блокировки, стало общей практикой помещать несколько отдельных ресурсов в один (например, CSS spriting). Все эти изящные хаки протокола HTTP/1, тем не менее, имеют свою цену; они вынуждают клиента загружать больше данных, чем ему необходимо в данный момент для показа конкретной страницы, что нарушает описанный нами идеальный случай, а значит мы не покажем страницу так быстро, как это только возможно.



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



HTTP/2



Протокол HTTP/2 пытается решать проблемы 1.1 несколькими путями:




  1. Полное мультиплексирование означает решение проблемы HOL-блокировки. Вы можете загружать все ресурсы своей страницы по одному HTTP-соединению и не волноваться о том, сколько для этого понадобится сделать запросов. «Оптимизации» со склеиванием файлов в один можно оставить в прошлом.

  2. Сжатие заголовков решает проблему их избыточности. Теперь вы можете вместить десятки (или даже сотни) запросов в буквально несколько IP-пакетов. Это серьёзно приближает нас к «минимально необходимому набору данных» нашего идеального протокола.

  3. HTTP/2 позволяет серверу отправлять данные клиенту ещё до их запроса клиентом, исходя из предположения, что они ему скоро понадобятся. Это уменьшает количество раундов связи клиента и сервера.





Таким образом, сеанс связи с использованием протокола HTTP/2 выглядит как-то так:







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



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



HTTP/2 + дайджесты кеша

Хороший вопрос, касающийся инициированной сервером пересылки файлов: «А что, если у клиента уже есть его копия в кеше?». Действительно, было бы глупо насильно отправлять клиенту что-то, что у него уже есть.



HTTP/2 позволяет клиенту в этом случае досрочно завершить загрузку такого ресурса, с помощью сообщения RESET_STREAM. Но даже в этом случае у нас гоняются лишние данные, добавляется ещё один раунд связи, чего хотелось бы избежать. Вы помните правило из первого абзаца статьи: «пересылать лишь минимально необходимое количество данных для отображения страницы».



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







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



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



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



TCP

Давайте поговорим о влиянии на общую производительность других протоколов, используемых браузером для загрузки страниц. А оно тоже может быть существенным: TCP использует троекратное рукопожатие ещё до того, как первый байт стоящего выше HTTP будет переслан:







Это добавляет «болтливости» каждому сеансу связи. TCP Fast Open позволяет приложениям отправлять данные прямо в SYN и SYN+ACK пакетах. К сожалению, это в данный момент поддерживается только в Linux и OSX, и более того, есть некоторые особенности применения TCP Fast Open именно с протоколом HTTP, над которыми сейчас работает сообщество. Например, не гарантируется, что данные, прикреплённые к SYN-пакету, будут пересланы лишь один раз. Это открывает уязвимость с потенциальными повторными запросами, которая может быть использована для атак. Таким образом, запрос POST — не лучший кандидат для применения TCP Fast Open. Более того, некоторые GET-запросы тоже имеют заметные побочные эффекты, а браузеры не имеют никаких средств, чтобы отличить такие запросы от тех, которые таких эффектов не имеют.



TLS

TLS добавляет ещё один уровень взаимодействия клиента и сервера, уже после того, как TCP соединение было установлено. Это выглядит вот так:







Это два полных цикла обмена сообщениями перед тем, как протокол HTTP отправит свой первый запрос; достаточно разговорчиво, не правда ли? Если клиент и сервер уже общались раньше, мы можем несколько сократить общение:







Вскоре TLS 1.3 позволит достичь «нулевого» рукопожатия для случая, когда клиент и сервер уже общались ранее — иными словами протокол HTTP получить возможность добавить полезную нагрузку уже в первый отправленный на сервер пакет данных. Но так же, как и с TCP Fast Open, понадобиться некоторое решение для избегания дублирования запросов.



HTTP/next

TCP Fast Open и TLS 1.3 уменьшают количество циклов связи клиента и сервера при открытии соединения. Другой способ достичь того же — переиспользовать уже ранее открытое соединение. Сейчас идёт дискуссия о том, как объединять соединения HTTP/2 более агрессивно; это позволит не только избежать затрат на открытие новых соединений, но и более эффективно использовать уже имеющиеся — протокол TCP наиболее хорош именно в долгоживущих, плотно заполненных данными соединениях. Это включает в себя отправку клиенту сертификатов, доказывающих, что соединение может быть безопасно переиспользовано для работы с другими источниками.



Сейчас обсуждаются даже более кардинальные эксперименты: замена TCP на UDP, навроде QUIC. Есть много спорных моментов, но сама перспектива свести начальный обмен данным фактически до нуля — очень привлекательна. Более того, возможность получить доступ к данным не в том порядке, как они были отправлены, тоже может быть очень полезна. Это ещё один способ избежать HOL-блокировок в TCP (протоколе с упорядоченной доставкой пакетов). Мы можем выбрать из потока пакетов нужные нам, понять, что какие-то были потеряны, запросить их повторно — и продолжить обработку следующих, не дожидаясь результатов повторного запроса.



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282517/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Разработка webApi модуля для Angular.js

Понедельник, 25 Апреля 2016 г. 13:40 (ссылка)

Желание разработать собственный Angular.js webApi модуль возникло при работе с большим количеством http-запросов в проекте.


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



Задачи, которые должен решать будущий webApi модуль:




  1. Предотвратить дублирование http-запросов в проекте.

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

  3. Быть полностью независимой функциональной единицей приложения, которая подключается к любому другому Angular.js проекту простым Dependency Injection'ом.

  4. Инкапсулировать внутреннюю реализацию, чтобы избежать проблем при работе с внешними источниками.



Дальше поговорим о каждом из этих пунктов подробнее.



Дублирование http-запросов



Речь идет об использовании одного запроса в нескольких местах приложения (контроллеры, сервисы, фабрики). Когда методов 10-20, то внести изменения в каждый запрос не составит большой проблемы. Но когда речь идет о количестве 100, 200 и более url'ов, поддержка такого кода вызывает все больше трудностей.



Пример #1



Есть метод, который получает список групп пользователей. Допустим, он выводится в соответствующий dropdown. При выборе группы происходит подгрузка ее юзеров по другому запросу, куда передается "id" группы. Также на странице имеется дополнительный функционал для визуализации каких-то данных пользователей.



// получаем все группы
$http.get("api/group-manage/get-all")

// получаем пользователей выбранной группы
$http.get("api/group-manage/2/get-users")


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



// получаем пользователей выбранной группы
$http.get("api/group-manage/2/get-users")


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



Решение проблемы



Создать специальный файл с константами, содержащий список всех http-запросов на сервер, т.е. всех используемых в приложении url'ов. 


Данный подход позволит сэкономить время при поиске необходимого запроса в проекте и его модификации.



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



Группировать запросы по категориям



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



// http://yourapi.com/api/group-manage/2/get-users
// http://yourapi.com/api/group-manage/get-all


Из примера выше видно, что в запросах есть общий корень /api/group-manage/. Создаем категорию с соответствующим названием groupManage.js.



В Angular.js среде данный файл объявляется как constant, который в дальнейшем подключается к основному функционалу webApi модуля.


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



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



Инкапсуляция функционала



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



Пример запроса выглядит следующим образом:



{ Url: '/api/acc/login', CustomOptions: false, Method: 'post', InvokeName: 'login' }



  • customOptions — использовать ли дополнительные настройки запроса. Обычно там могут указываться header'ы для конкретного запроса, значение timeout, параметр withCredentials и др.



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



В директории webApi/config/ находится файл с настройками API. Именно там мы и указываем DOMAIN url.



Пример #2



Практически все современные Angular.js приложения работают с системой аутентификации. Обычно это post-метод, который отправляет на сервер данные юзера (login, password).



При успешном respons'e происходит оповещение главному роуту приложения, после чего пользователь будет перенаправляется на страницу с функционалом.



Вызываем метод:



webApi.login({
"Login": "user",
"Password": "qwerty"
}).success(function(response, status, headers, config){
// какие-то действия
})


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



// объявляем запрос в настройках
{ Url: '/api/acc/logout', CustomOptions: false, Method: 'get', InvokeName: 'logout' }

// где-то вызываем метод
webApi.logout([]);


Наверное, сейчас не совсем понятно использование пустого массива в get-методе, но дальше об этом всем будет рассказано.



Шаблонизация запросов



Довольно часто при разработке приложения, сервер-сайд предоставляет клиенту следующий формат запросов:




  • /api/admin/delete/profile/{id}

  • /api/admin/update/profile/{id}/block



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



// объявляем запрос в настройках
{ Url: '/api/admin/update/profile/{id}/block', CustomOptions: false, Method: 'put', InvokeName: 'blockAdminProfileById' }

// где-то вызываем метод
webApi.blockAdminProfileById({
"url": { "id": 5 }
});


Сгенерированный запрос: /api/admin/update/profile/5/block (плюс domain url, разумеется).



И если нам нужно отправить на сервер более сложный запрос (например, длительность блокировки и тип), то просто указываем остальные параметры в качестве полей объекта "url":



// объявляем запрос в настройках
{ Url: '/api/admin/update/profile/{id}/block/{type}/{time}', CustomOptions: false, Method: 'put', InvokeName: 'blockAdminProfileById' }

// где-то вызываем метод
webApi.blockAdminProfileById({
"url": {
"id": 5,
"type": "week",
"time": 2
}
});


Сгенерированный запрос: /api/admin/update/profile/5/block/week/2. И теперь пользователь будет заблокирован системой на 2 недели.



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



Передача данных в теле запроса



Следует отметить, что если Вы хотите отправить помимо шаблонизированного url на сервер еще и какие-то данные (например, post-запрос), то необходимо их передать следующим образом:



webApi.createPost({
"data": {
"title": "Test post",
"category": "sport",
"message": "Content..."
}
});


Естественно, можно использовать одновременно и url-шаблонизацию, и передачу объекта с данными. Последний будет отправлен на сервер в теле запроса.



Работа с GET-методами



Тут никакие данные в теле запроса не передаются, но всем известно, что get-запрос может быть сформирован так:



api/admin/news/10?category=sport&period=week



или так:



api/admin/manage/get-statistic/5/2016



или же так:



api/admin/manage/get-all.



Рассмотрим каждый из вариантов генерации.



Примеры создания get-запроса
// Case #1 -> api/admin/manage/get-all
// в настройках -> "Url" : 'api/admin/manage/get-all', ...
// вызываем метод
webApi.getAllAdmins([]).success(//...)

// Case #2 -> api/admin/manage/get-statistic/5/2016
// в настройках -> "Url" : 'api/admin/manage/get-statistic/{id}/{year}', ...
// вызываем метод
webApi.getAdminStatsticById({
"url": {
"id": 5,
"year": 2016
}
}).success(//...)

// Case #3 -> admin/news/10?category=sport&period=week
// в настройках -> "Url" : 'admin/news', ...
// вызываем метод
webApi.getNews({
before: ['10'],
after: {
"category": "sport",
"period": "week"
}
}).success(//...)


Со вторым типом запросов мы уже разобрались выше.



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



В случае #3 поле before определяет ряд параметров, которые идут до знака "?", а поле after — набор "ключ-значение". Естественно, в некоторых случаях можно оставить before пустой коллекцией [].



Параметр CustomOptions в настройках



Get-запрос без шаблонизации url:



webApi.getNewsById([10, {"headers": {"Content-Type": "text/plain"} } ]);


Во всех остальных случаях (в том числе, get-запросы с шаблонизацией url):



webApi.login({
options: {"timeout": 100, {"headers": {"Content-Type": "text/plain"} }
});


Настройка webApi в новом проекте



Структура модуля следующая:




  • файл module.js — объявление самого модуля;

  • директория main/ — содержит в себе ядро webApi, оно не изменяется;

  • директория categories — группы запросов, одна группа — один *.js файл;

  • директория categories-handler — регистратор всех запросов в webApi модуле.



Вам придется работать с последними двумя директориями.



Пример #3



Допустим, разрабатывается система учета книг в каком-то университете. Большая вероятность разбиения запросов на следующие группы:




  • account.js — запросы на авторизацию, деавторизацию, восстановление паролей и т.д.;

  • bookManage.js — запросы на CRUD-операции с книгами;

  • studentManage.js — менеджмент студентов;

  • adminManage.js — ряд запросов по управление админской частью приложения.



Конечно, этот список может быть расширен.



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


Объявляем новую категорию запросов
(function(){

angular
.module("_webApi_")
.constant("cat.account", {

"DATA": [

{ Url: '/api/acc/login', CustomOptions: false, Method: 'post', InvokeName: 'login' },
// остальные запросы

]

});

})();


Файл с запросами создан. Теперь нужно связать его с нашим webApi ядром.



Добавляем группу запросов в специальный обработчик
(function(){

angular
.module("_webApi_")
.service("webApi.requests", webApiRequests);

function webApiRequests(catAccount){

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

}

// IoC container.
webApiRequests.$inject = [
"cat.account"
];

})();


В данном случае все константы пишутся через "cat.имя константы", а подключаются в регистратор "catИмяКонстанты".



Таким образом, в webApi используется дополнительное пространство имен "cat.", чтобы не было конфликтов с другими константами в приложении.



И теперь вызываем метод согласно описанному шаблону:



webApi.login( //логин-пароль для авторизации )



Заключение



Мы рассмотрели вариант создания конфигурируемого и расширяемого webApi модуля для работы с Angular.js.



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



Demo



Посмотреть исходный код модуля: github.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282397/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<http - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda