Веб-стандарты → HTTP — протокол уровня приложений
Данная статья является переводом первой статьи из цикла статей о протоколе HTTP с сайта opera.com.
Пересоздал её, чтобы тип статьи стал переводом.
В Бутане, когда люди знакомятся, они обычно приветствуют друг друга словами «Твоё тело чувствует себя хорошо?». В Японии они могут кланяться, в зависимости от обстановки. В Омане мужчины обычно целуют друг друга в нос, после рукопожатия. В Камбодже и Таиланде они обычно соединяют ладони, как при молитве. Это все протоколы общения, простая последовательность кодов, которая имеется значение и готовит обе стороны к обмену информацией.
В Интернете есть очень эффективный протокол прикладного уровня, который готовит компьютеры к обмену информацией: Hypertext Transfer Protocol, или HTTP. HTTP — протокол прикладного уровня поверх коммуникационного протокола TCP/IP. HTTP часто упускается из вида при изучении веб-дизайна и веб-разработки, что является ошибкой: понимание его помогает определить лучший способ взаимодействия с пользователями, достичь лучшей производительности сайта и создает эффективный инструмент для управления информацией в сети Интернет.
Это первая статья из серии статей, целью которой является научить основам HTTP и эффективному его использованию. В этой статье мы увидим на каком этапе HTTP работает в механизме Интернет.
Пересоздал её, чтобы тип статьи стал переводом.
Введение
В Бутане, когда люди знакомятся, они обычно приветствуют друг друга словами «Твоё тело чувствует себя хорошо?». В Японии они могут кланяться, в зависимости от обстановки. В Омане мужчины обычно целуют друг друга в нос, после рукопожатия. В Камбодже и Таиланде они обычно соединяют ладони, как при молитве. Это все протоколы общения, простая последовательность кодов, которая имеется значение и готовит обе стороны к обмену информацией.
В Интернете есть очень эффективный протокол прикладного уровня, который готовит компьютеры к обмену информацией: Hypertext Transfer Protocol, или HTTP. HTTP — протокол прикладного уровня поверх коммуникационного протокола TCP/IP. HTTP часто упускается из вида при изучении веб-дизайна и веб-разработки, что является ошибкой: понимание его помогает определить лучший способ взаимодействия с пользователями, достичь лучшей производительности сайта и создает эффективный инструмент для управления информацией в сети Интернет.
Это первая статья из серии статей, целью которой является научить основам HTTP и эффективному его использованию. В этой статье мы увидим на каком этапе HTTP работает в механизме Интернет.
Информационная безопасность → Diamond Dash, или как не надо защищать свои online приложения
Я не люблю играть и игры. Но меня всегда интересовало, как они работают и какие уязвимости имеют, что передают на сервер. Уже раньше на хабре были статьи на тему уязвимостей игры Diamond Dash,
И снова Diamond Dash
Написание макроса-бота для браузерной игры
Меня тоже заинтересовала эта игра, решил в ней разобраться.
Забегая вперед скажу, что в итоге исследования игры был написан скрипт, который может поднять рейтинг для любого(!!!) человека и игре, и для этого достаточно знать id этого человека в facebook.
И снова Diamond Dash
Написание макроса-бота для браузерной игры
Меня тоже заинтересовала эта игра, решил в ней разобраться.
Забегая вперед скажу, что в итоге исследования игры был написан скрипт, который может поднять рейтинг для любого(!!!) человека и игре, и для этого достаточно знать id этого человека в facebook.
Веб-стандарты → Протокол SPDY могут включить в HTTP/2.0
Председатель Марк Ноттингем разослал вчера всем членам рабочей группы по HTTP письмо, где предложил сделать сетевой протокол SPDY частью стандарта HTTP/2.0. Эта технология, разработанная в Google, позволяет значительно ускорить загрузку сайтов по HTTP за счёт мультиплексирования запросов, расстановки приоритетов для запросов и сжатия заголовков HTTP (cм. результаты тестов). SPDY уже давно работает в связке браузера Chrome с серверами Google.
Основанием для своего предложения Ноттингем считает то, что протокол уже де-факто используется в онлайне, он реализован в двух основных браузерах: Chrome и, месяц назад, в Firefox Nightly, и уже появились его экспериментальные имплементации от независимых разработчиков, например, SPDY-сервер на Питоне.
Формальное принятие SPDY в HTTP/2.0 должно придать импульс для повсеместного внедрения этой технологии как на стороне серверов, так и в остальных браузерах.
Основанием для своего предложения Ноттингем считает то, что протокол уже де-факто используется в онлайне, он реализован в двух основных браузерах: Chrome и, месяц назад, в Firefox Nightly, и уже появились его экспериментальные имплементации от независимых разработчиков, например, SPDY-сервер на Питоне.
Формальное принятие SPDY в HTTP/2.0 должно придать импульс для повсеместного внедрения этой технологии как на стороне серверов, так и в остальных браузерах.
Сетевые технологии → Сделаем TCP быстрее
Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.
1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.
2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.
1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.
2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.
Windows Phone → Работа с HTTP в 3 строчки, или делаем свой RSS Reader c WebClient и WebBrowser
В мире мобильных устройств балом правит контент. Каждый пользователь смартфона хочет на своём устройстве получить доступ к необходимой ему информации быстро, красиво и, желательно, с экономией трафика.
С другой стороны, каждый владелец информационного ресурса, хочет, чтобы его ресурсом пользовались. Самый простой и распространённый вариант – это RSS ленты. И разнообразные «читалки» RSS доступны на всех мобильных платформах. Даже есть сервис, который может по RSS или ATOM источнику сгенерировать вам приложение для некоторых мобильных платформ, что позволяет веб-мастеру или владельцу ресурса быстро получить доступ к армии пользователей мобильных устройств.
Но мы – разработчики и не ищем лёгких путей. Давайте напишем заготовку для будущего мега-продвинутого RSS Reader для платформы Windows Phone, используя все возможности платформы.
Информационная безопасность → О некоторых приемах атаки Man in the middle
Немного Википедии: атака «человек посередине» (англ. Man in the middle, MitM-атака) — термин в криптографии, обозначающий ситуацию, когда атакующий способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале.
В этой статье будет рассмотрен прием пассивной атаки на http-соединение, без модификации проходящей информации. Итак, каким-то способом вы смогли вклиниться физически или удалённо в канал передачи данных, настроили bridge или просто получили root-управление шлюзом. Руткит поставили, базы с исходниками слили, вебшелл залили, в cron часовую бомбу заложили, и что теперь?
В этой статье будет рассмотрен прием пассивной атаки на http-соединение, без модификации проходящей информации. Итак, каким-то способом вы смогли вклиниться физически или удалённо в канал передачи данных, настроили bridge или просто получили root-управление шлюзом. Руткит поставили, базы с исходниками слили, вебшелл залили, в cron часовую бомбу заложили, и что теперь?
Lisp → Пишем веб-сервер на Common Lisp часть вторая
В прошлой статье мы начали разработку нашего веб-сервера. Продолжим c файлом util.lisp. В этом пакете будут находится все наши вспомогательные функции для обработки запросов. Для начала обьявим переменную *line*, она нам понадобится в дальнейшем.
Lisp → Пишем веб-сервер на Common Lisp часть первая
Не так давно я взялся за изучение Common Lisp. Как может показаться, изучение нового языка программирования — дело весьма не простое, тем более если он совсем непохож на все те языки, с которыми приходилось сталкиваться ранее. Поэтому я решил начать с книги Land Of Lisp. Книга весьма неплохая, с интересными картинками и очень хорошо подходит для начинающих. В одной из глав было описание создания веб-сервера на Common Lisp. Я решил слегка развить эту тему, и в итоге у меня получилось не совсем то, что было описано в этой главе, а весьма интересный веб-сервер. Исходные коды можно посмотреть тут.
Для его написания нам понадобится Linux с установленными emacs, sbcl, slime и quicklisp. Описывать, как это всё устанавливать, настраивать и как этим пользоваться, я не стану — в интернете есть множество статей об этом. Весь наш веб-сервер будет находиться в одном пакете, называемом myweb. Создайте у себя папку с данным названием, и в ней создайте две папки log и web. Папка log будет содержать лог-файл веб-сервера. В папке web будут лежать html-страницы и изображения, которые веб-сервер будет отдавать клиентам. Весь веб-сервер состоит из семи файлов.
Для его написания нам понадобится Linux с установленными emacs, sbcl, slime и quicklisp. Описывать, как это всё устанавливать, настраивать и как этим пользоваться, я не стану — в интернете есть множество статей об этом. Весь наш веб-сервер будет находиться в одном пакете, называемом myweb. Создайте у себя папку с данным названием, и в ней создайте две папки log и web. Папка log будет содержать лог-файл веб-сервера. В папке web будут лежать html-страницы и изображения, которые веб-сервер будет отдавать клиентам. Весь веб-сервер состоит из семи файлов.
.NET → Событийно-ориентированный HTTP-сервер на C# с помощью Rx и HttpListener
Достаточно большое название? Да? В этом посте я покажу Вам альтернативный подход в создании простого событийно-ориентированного HTTP-сервера на C#, используя мощь Reactive Extensions.
Веб-разработка → Сетевая утилита JInternetManiac для веб-разработчиков
С давних пор я пользовался небольшой сетевой утилитой Internet Maniac (весит 100 кб). Чаще всего в ней я пользовался функцией «Connect», с помощью которой можно создать TCP-соединение с сервером (обычно с веб-сервером), отправить запрос и увидеть ответ сервера. Такое можно повторить и с помощью консольного telnet, но в Internet Maniac это делать удобнее. Другие функции программы: host lookup (определение IP и/или имена хоста), listen (простейший TCP-сервер), сканер портов, ping, whois, проверка почты и др.
Программа давно не обновляется, я пытался найти ей замену, но нормальную бесплатную так и не нашёл. В итоге решил сделать собственный более продвинутый аналог на Java.
Программа давно не обновляется, я пытался найти ей замену, но нормальную бесплатную так и не нашёл. В итоге решил сделать собственный более продвинутый аналог на Java.