Простыми словами о веб-разработке.

Эгея | Основы веба | Как стать веб-разработчиком
Docker | Веб-сервер | PHP | Базы данных

Позднее Ctrl + ↑

Эгея. Как починить комментарии, если у вас Nginx

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

Решение

  1. Обновляем одну строку в файле Nginx-конфига, соответствующего блогу на Эгее.
location / {
    log_not_found off;
    # Было:
    # try_files $uri $uri/ /index.php?go=$uri;
    # Стало:
      try_files $uri $uri/ /index.php?go=$uri&$query_string;
  }
  1. Перезагружаем веб-сервер.
$ nginx -s reload

Причина

Эгея обрабатывает все запросы путём пробрасывания через фронт-контроллер index.php. При этом первоначальный URI передаётся как GET-параметр «?go=».

Исходный запрос Обработанный запрос
/tags/ /index.php?go=/tags/
/all/how-web-works/ /index.php?go=all/how-web-works/
/sign-in-done/vk/?data={«user»: ...} /index.php?go=sign-in-done/vk/

В последнем случае исходный запрос уже содержит GET-параметры, которые до php не дойдут.

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

ps.: большое спасибо Евгению Степанищеву, что обнаружил этот баг и не поленился написать мне на почту.

Что такое HTTP, или как браузеры общаются с веб-серверами

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

Что такое HTTP

HTTP — это протокол передачи данных для клиент-серверных приложений.

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

  • При встрече на протянутую руку принято отвечать рукопожатием. Отсутствие рукопожатия — это тоже ответ, иногда даже более красноречивый, чем само рукопожатие.
  • Девушкам же руку не протягивают — это тоже часть протокола. Можно и им руку протянуть, но в большинстве случаев не поймут, а в некоторых странах заставят жениться.
  • Электрические розетки — хотя в разных странах они разные, внутри одной страны они одинаковы.
  • Разъёмы для кабелей — USB type B, USB type C, mini USB, micro USB. Производители приняли внегласный протокол и производят кабели и устройства именно таких форматов, иначе при прочих равных пользователи их не поймут и не будут покупать их продукцию (исключение — Apple).
  • Правила дорожного движения — знаки, разметка и светофоры помогают пешеходам дойти, а автомобилистам доехать до места назначения без происшествий.
  • Формы налоговых деклараций и прочих бюрократических документов.

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

HTTP — это набор некоторых правил, которым должны следовать клиенты и сервера, если они хотят, чтобы их правильно поняли.

HTTP-клиентами чаще всего являются браузеры — Google Chrome, Mozilla Firefox, Safari, Opera, Yandex Browser и другие. А серверами являются веб-сервера. Вот эта приставка «веб-» и указывает на то, что это не просто какой-то сервер, а сервер, который умеет принимать запросы и отвечать на них по протоколу HTTP. Как он будет устроен внутренне — не определено и не важно. Наиболее популярными в мире веб-серверами являются Nginx, Apache2, но вы можете написать и свой — в некоторых языках это делается крайне легко, см. пример на Golang.

Прикидываемся браузером, или делаем HTTP-запрос из терминала

Чтобы понять, как браузер общается с сервером, нужно думать как браузер, нужно стать браузером.

Попробуем обратиться к веб-странице http://http.maxkuznetsov.ru так, как это делают браузеры под капотом. Для этого отправим запрос из терминала/командной строки с помощью утилиты netcat. Чаще всего она установлена по умолчанию: в Mac OS X — это «nc», в других ОС может быть «ncat» или «netcat». (Или воспользуйтесь онлайн-сервисом https://reqbin.com/u4178vu3, в котором слева и справа выберите табы Raw для отображения «голых» запросов и ответов. Но из терминала получится нагляднее.)

nc http.maxkuznetsov.ru 80

Дальше ничего не произойдёт, терминал подвиснет — это нормально. Команда netcat подключилась к серверу по адресу http.maxkuznetsov.ru к 80-му порту, и сервер ждёт от нас текст запроса.

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

В компьютерных сетях всё точно также. На одном адресе (IP или доменном имени) могут висеть и ожидать запросов несколько портов одновременно. Чтобы избежать путаницы, сообщество разработчиков договорилось для наиболее популярных серверов выделять одни и те же порты: SSH — 22, FTP — 21, база данных MySQL — 3306, веб-сервера — 80. Это лишь соглашение и рекомендация, можно поднять какой угодно сервер на каком угодно порту, но для клиентов это скорее всего станет неожиданностью.

Когда в браузере мы вбиваем в адресной строке http.maxkuznetsov.ru, браузер подставляет порт 80 незаметно для нас. Вы можете убедиться в этом, вбив в адрес не http.maxkuznetsov.ru, а http.maxkuznetsov.ru:80 — результат не изменится.

Введём в терминале такие строки запроса.

$ nc http.maxkuznetsov.ru 80
GET / HTTP/1.1
Host: http.maxkuznetsov.ru

После Host нужно ввести две пустые строки: одна строка отступа, вторая содержит тело запроса, но в данном примере оно пустое. Такие правила протокола HTTP. Получив вторую пустую строку, веб-сервер поймёт, что запрос завершён, обработает его и пришлёт ответ, включающий интересующую нас веб-страницу с html.

$ nc http.maxkuznetsov.ru 80
GET / HTTP/1.1
Host: http.maxkuznetsov.ru

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Mon, 13 Apr 2020 20:10:04 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive

<html>
<head>
  <title>This is a test page for Max's blog article about http</title>
</head>
<body>
  <h1>Hello HTTP world!</h1>
  <form method="POST" action="/">
    <input name="name" type="text" placeholder="Name" />
    <button type="submit">Submit</button>
  </form>
</body>
</html>

После этого браузер разбирает ответ, убирает техническую информацию и отображает html-страницу в кодировке UTF-8  — так ему сказал сервер в заголовке Content-Type. Если в HTML включены CSS, Javascript, картинки, то браузер запросит их отдельными запросами ровно таким же образом. Если он их уже запрашивал раньше, то возьмёт из локального кэша. Поэтому первый раз страницы грузятся визуально дольше.

Разберём структуру запроса и ответа более детально.

Структура HTTP-запроса

Каждый запрос имеет один и тот же формат:

метод /путь протокол
Host: <site.ru>
заголовок1: значение
заголовок2: значение
заголовокN: значение

<тело_запроса_в_одну_строку или пустая_строка_если_тело_пустое>

протокол

Указывает, какая конкретная версия протокола HTTP будет использоваться. Чаще всего 1.0 и 1.1, но могут встречаться устаревшая 0.9 или новая 2.0. Однако, веб-сервер может не поддерживать указанную версию и вернуть ошибку. На практике подавляющее количество веб-серверов поддерживают 1.0 и 1.1.

/путь

Относительный путь (без доменного имени) до документа. В нашем примере указан корень /, но путь может быть любым: /index.php, /catalog/food/milk. Под документом понимаются не только файлы с расширением .html, но и любые другие файлы, например картинки, .css, .js.

метод

Определяет, что веб-сервер должен сделать с документом, найденным по указанному «/пути».

  • GET — вернуть документ — GET /messages/1.
  • HEAD — вернуть только заголовки без самой страницы. Это подходит для случая, когда мы хотим проверить, что ссылка на документ валидная. Пример: HEAD /messages/1
  • POST — отправить данные для создания документа — POST /messages (и детали нового сообщения).
  • PUT — заменить документ
  • PATCH — частично обновить документ
  • DELETE — удалить документ
  • TRACE, CONNECT — технические методы, которые можно пропустить.
  • OPTIONS — просьба к веб-серверу вернуть разрешённые настройки для запросов к указанному документу. Ответ включает в себя в том числе список разрешённых методов.

На практике примерно 80% запросов приходится на GET, 15% — на POST и 5% — на все остальные методы.

Заголовки

Они опциональны (в нашем примере их не было вовсе) и подсказывают веб-серверу, как именно нужно обработать запрос. Например, что клиент отправляет запрос в виде текста с кодировкой utf-8, а ожидает получить json в кодировке cp1251.

Наиболее частые на практике заголовки:

  • Accept — в каком формате ожидаем ответ: обычный текст, html, xml, json, что угодно ещё.
  • Accept-Charset — кодировка тела запроса: utf8, cp1251, koi8.
  • Authorization — данные для авторизации между запросами. Здесь чаще всего передаются токены API. Авторизация между запросами будет рассмотрена ниже.
  • Accept-Language — список языков, которые нас бы устроили. Например: «Accept-Language: ru».
  • Cache-Control — настройки кэширования страниц
  • Cookie — известные браузеру куки. В них сохраняются идентификаторы сессий и пользовательские предпочтения.
  • Referrer — с какой страницы был сделан текущий запрос. Полезно для аналитики сайта и для возвращения юзера на первоначальную страницу после регистрации, например.
  • User-Agent — тип клиента (чаще всего тип вашего браузера). Пример: «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36». Это поле часто используется на сервере, чтобы отслеживать количество запросов с одного устройства и блокировать их при превышении лимита. Однако это не панацея, ведь после блокировки злоумышленник может поменять User-Agent на любой другой.

Тело

Для GET-запросов тело не имеет смысла, так как всё, что нужно — это путь в стартовой строке и заголовки. Но что происходит, когда мы хотим отправить информацию на сервер? Логин-пароль, форма обратной связи, форма создания поста? Для этого используется POST-запрос.

Каждый элемент формы имеет аттрибут name. В нашем примере страница http://http.maxkuznetsov.ru содержит форму с единственным тегом input, который имеет name=«name». Именно это имя и введённое пользователем в инпут значение будут отправлены на сервер. В консоли такой браузерный запрос будет выглядеть так:

$ nc http.maxkuznetsov.ru 80
POST / HTTP/1.1
Host: http.maxkuznetsov.ru
Content-Type: application/x-www-form-urlencoded
Content-Length: 8

name=Max

Обратите внимание, что POST запрос очень похож на GET, мы даже обращаемся к тому же документу «/». Однако есть и отличия:

  • вместо второй пустой строки в конце запроса содержатся данные: «name=Max»
  • эти данные могут быть в разном формате, поэтому мы должны явно указать веб-серверу, что это данные из формы — application/x-www-form-urlencoded
  • также мы сообщаем серверу, что в теле запроса содержится ровно 8 символов — «Content-Length: 8». Это техническое поле, которое браузер выполняет на лету, а нам приходится считать самим.

В ответ придёт знакомая страница, но с другим h1 заголовком — php-скрипт, обрабатывающий страницу, подставил вместо «http world» введённое нами имя.

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Mon, 13 Apr 2020 22:26:19 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip

<html>
<head>
  <title>This is a test page for Max's blog article about http</title>
</head>
<body>
  <h1>Hello Max</h1>
  <form method="POST" action="/">
    <input name="name" type="text" placeholder="Name" />
    <button type="submit">Submit</button>
  </form>
</body> 
</html>

Структура HTTP-ответа на основе примера выше

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

HTTP/1.1 200 OK
протокол статус пояснение

протокол

Значение поля то же самое, что и в запросе. Но может отличаться от версии, что запросил браузер, если веб-сервер её не понимает.

статус и пояснение

HTTP-статус из трёх цифр и короткая поясняющая фраза. Все фразы стандартизированы и чётко соответствуют статусу.

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

Первая цифра статуса указывает на класс:

  • 1xx — информационные — технические статусы, вероятнее всего вы их не увидите в реальной жизни
  • 2xx — успешно обработанные запросы с детализацией. Наиболее частые: 200 — всё ок, 201 — документ был создан, 204 — запрос завершился успешно, но ответ содержит заголовки и пустое тело. На практике реальные API не парятся и в 95% случаев возвращают код 200, а детали успешной операции отсылаются в теле.
  • 3xx — перенаправление — запрос следует выполнить по другому адресу, который передаётся в заголовке Location. Частые: 301 — документ перенесён навсегда, 302 — документ перенесён временно. Они довольно критичны для поисковых ботов, которые индексируют ваш сайт. 301 говорит боту, чтобы он запомнил новый адрес страницы, а прежний забыл.
  • 4xx — ошибка клиента — запрос содержит не все или некорректные данные (400), требуется аутентификация (401) или не хватает прав на выполнение операции (403), запрошенной страницы не существует (404) или http метод запроса для этой страницы запрещён (405).
  • 5xx — ошибка на сервере — сервер не справился или произошла непредвиденная ошибка (500), ошибка обработки запроса вышестоящим сервером, например php-fpm не отвечает nginx’у (502), сервер временно не отвечает по техническим причинам (503), сервер не дождался ответа и запрос отвалился по таймауту (504). Например, стандартное ограничение на время выполнения php-скрипта — 30 секунд. Если скрипт делает запрос к стороннему ресурсу, который под нагрузкой, то nginx покажет 504ю ошибку.

При этом даже неуспешный статус не запрещает серверу вернуть веб-страницу, которую браузер отобразит как ни в чём не бывало. Попробуйте зайти на несуществующую страницу моего блога: https://maxkuznetsov.ru/non-existed-page. Сервер вернёт 404 вместо 200, но мы всё равно можем показать пользователю что-то полезное.

заголовки

Заголовки сервера выполняют ту же роль, что и заголовки запроса. Есть общие заголовки, как Cache-Control, но есть и свои уникальные.

  • Allow — определяет список разрешённых http методов для запросов
  • Location — адрес для перенаправления.
  • WWW-Authenticate — информация про метод аутентификации, запрос должен послать соответствующую информацию в хедере Authorization.

тело

Тело ответа также отделяется от группы заголовков пустой строкой. При этом в теле может передаваться что угодно — текст, html, json, xml, картинки и прочие файлы. Все они отдаются браузеру в одинаковом формате, но с отличающемся заголовком Content-Type, который и поясняет браузеру, как отобразить контент пользователю: как html-страницу, как картинку, показать встроенный в браузер PDF-просмотрщик или начать скачивание файла.

Про аутентификацию и авторизацию

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

В жизни это ограничение обходят двумя путями:

  1. хранят уникальный идентификатор сессии в куках (cookies), которые браузер по требованию сервера сохраняет локально и затем прикрепляет к каждому запросу в виде заголовка «Cookie». Cервер при каждом запросе разбирает заголовок с куками и по сохранённому там идентификатору «узнаёт» пользователя.
  2. через заголовок Authorization браузер посылает серверу в каждом запросе токен (форматы могут быть разными), по которому сервер определяет пользователя аналогично сессиям. Этот способ чаще всего используется в API.

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

Что важно понимать про HTTP

  1. HTTP — это протокол общения клиент-серверных приложений в вебе. Набор правил, который помогает клиентам (прежде всего браузерам) и веб-серверам понимать друг друга.
  2. HTTP — это про формат общения, а не про управление сервером HTTP-командами. Клиент может отправить что угодно: удали страницу сайта, создай нового пользователя, выдай список всех пользователей — но сервер не обязан их выполнять, он лишь обязан ответить в формате HTTP, чтобы клиент его понял. То есть благодаря HTTP сервер поймёт, что клиент хочет, а потом уже решит, как это обработать и вернёт результат. Может быть удалит страницу, а может и нет.
  3. В HTTP общение всегда начинает клиент. А веб-сервер висит и ждёт. Сейчас есть способы инициировать запрос с сервера, но изначально протокол для этого не предназначен.
  4. HTTP-протокол не имеет шифрования, поэтому передавать персональные данные и прочие приватные данные через него не безопасно. В таком случае нужно использовать HTTPS.
  5. Простой способ изучить заголовки запроса и ответа — открыть консоль браузера на нужной странице и обновить её. В разделе Network/Сеть отобразятся все запросы с этой страницы, включая запросы на картинки и статические файлы.

Несколько слов о наступающем будущем — HTTP/2

Первая версия протокола HTTP была принята 20 лет назад. После этого 10 лет была тишина, пока Google не стал разрабатывать свой протокол SPDY поверх HTTP, что дало ускорение работе над HTTP/2. После серёзных подвижек Google отказался от разработки SPDY в пользу HTTP/2.

Вторая версия протокола отличается от первой чуть меньше, чем полностью.

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

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

Как работает веб, или что происходит, когда вы сёрфите в интернете

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

Браузер и веб-сервер

Для базового понимания работы веба можно провести аналогию с телевидением.

Браузеры — Google Chrome, Firefox, Safari, Internet Explorer / Edge — это всего лишь экраны телевизоров, которые показывают программу, записанную и транслируемую откуда-то из далёких телестудий. В вебе такие студии называются веб-серверами.

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

У каждого веб-сервера подобно телеканалу есть свой номер, который называется IP. Чаще всего он выглядит как четыре группы трёхзначных чисел, разделённых точкой — XXX.XXX.XXX.XXX, но может выглядеть иначе — см. IPv6.

Например, Вконтакте имеет IP 87.240.137.158, Facebook — 31.13.72.36, данный блог — 5.63.155.79.

Чтобы нам не пришлось запоминать адреса в виде 87.240.137.158 для посещения контакта, были придуманы доменные имена — это как раз тот понятный и лёгкий для запоминания адрес, что мы вбиваем в браузере: vk.com, facebook.com, maxkuznetsov.ru.

Поскольку таких пар «IP — домен» по всему интернету огромное количество, то браузер не может все их знать и поэтому он обращается за помощью к DNS-серверу, который работает как адресная книга — по домену выдаёт IP, на который нужно слать запросы, и перенаправляет запрос на нужный веб-сервер в интернете.

Получив запрос от браузера, веб-сервер отправляет в ответ запрошенную веб-страницу или ошибку, если что-то пошло не так.

Если такой страницы не существует, браузер покажет ошибку.

Из чего состоит веб-страница

Веб-страница — это то, что вы видите в браузере. Она представляет собой HTML — обычный текст, но помещённый в специальные символы — «теги», подсказывающие браузеру, где заголовки и списки, а где картинки, формы для пользовательского ввода и, конечно же, ссылки на другие страницы. Ссылки — они же гипертекс — в своё время и сделали веб таким удобным и популярным.

Вы можете посмотреть из чего состоит любая веб-страница, кликнув по ней в браузере правой кнопкой мыши и выбрав пункт View Page Source / Посмотреть исходную страницу или что-то аналогичное в зависимости от браузера и языка интерфейса. Скорее всего вы ничего не поймёте, так как помимо HTML-разметки современные веб-страницы включают в себя кучу CSS и Javascript. Первая технология позволяет создавать красивый вид страниц (дизайн), а вторая — анимировать их и расширять функционал: всплывающие окна, проигрыватели аудио и видео, слайдеры, счётчики, метрики, обработка картинок, анимированная галерея фотографий и много чего ещё.

Кратко:
HTML — это разметка статического контента, задание его структуры
CSS — наведение красоты, включая простую анимацию
Javascript — более сложная анимация и дополнительный функционал поверх контента

Вы можете создавать свои веб-страницы прямо у себя на компьютере. Но чтобы другие люди их увидели, вам нужен веб-сервер, доступный через интернет. Попробуйте создать на своём компьютере файл index.html (скачать готовый пример), внутри которого написать

<h1>Hello world!</h1>
<ol>
  <li>Это мой первый</li>
  <li>Сайт</li>
</ol>
<button>Супер!</button>

Сохраните и перетащите файл прямо в браузер — вы увидите ваш первый, хоть и не публичный, сайт.

Статические и динамические страницы

Все веб-страницы можно условно разделить на два вида — статичные и динамичные.

  • Статичные — это уже готовый HTML, CSS, Javascript, который веб-сервер сразу же отдаёт по запросу браузера. Пример с index.html выше является статичной страницей. Её контент зафиксирован и будет отображаться одинаково для всех браузеров.
  • Динамичные (и их сейчас большинство) страницы можно представить себе как шаблоны итоговых страниц, но с вкраплениями серверного кода. Такой код при выполнении может проверять авторизован пользователь или нет, обращаться к базе данных или сторонним сервисам (например, за курсом валют) и даже полностью менять содержимое страницы, но в конечном итоге он всё равно превращается в HTML, CSS и Javascript, которые веб-сервер отдаёт браузеру.

Так, разные пользователи видят страницу https://youtube.com по-разному. Красным выделены те блоки, что «вставляются» серверным кодом, остальная часть страницы имеет одинаковый вид для всех пользователей.
Серверный код определяет вас по логину и выстраивает контент из ваших предпочтений. При этом шаблон страницы один для всех, что очень удобно, например, при редизайне — можно менять представление сайта без изменения самого контента. Это довольно важный принцип в программировании — разделять логику, данные и их визуальное представление.

Браузеру вся эта кухня не видна, он лишь делает запрос и получает в ответ HTML, CSS и Javascript. Каждый клик по ссылке или отправка формы делает новый запрос на веб-сервер, который начинает весь процесс заново.

Чтобы посмотреть на запросы, которые отправляет ваш браузер и что он получает в ответ, можно воспользоваться инструментом инспекции кода в браузере. Правый клик в любом месте страницы, выберите пункт «Inspect / Инспектировать элемент» или подобный, а потом перейдите в таб «Netword / Сеть». Перезагрузите страницу и вы увидите, как браузер общается с веб-сервером (или даже несколькими).

См. также:
HTTP: как браузеры и веб-сервера понимают друг друга
— Как поднять свой веб-сервер на NGINX

Как получить бесплатный SSL-сертификат и установить его на Nginx

Иметь сайт без HTTPS — это небезопасно. Особенно критично для интернет-магазинов и сервисов, где пользователь оставляет свои данные.

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

SSL-сертификат нужно получить в центрах сертификации (ЦС). Часто регистраторы доменов и провайдеры хостинга партнёрятся с такими центрами и облегачают задачу выпуска и установки сертификата на ваш сайт.

За выпуск сертификата ЦС берут плату, ведь им нужно по крайней мере удостовериться, что вы действительно владеете доменом, на который запрашиваете сертификат. У них такой бизнес. Можно выпустить и свой самоподписанный сертификат бесплатно, но браузеры не смогут ему доверять (ведь они не смогут уточнить его оригинальность у независимого ЦС) и  будут показывать предупреждение.

Как получить SSL-сертификат бесплатно

К счастью, есть ЦС, который выпускает SSL-сертификаты бесплатно, — это LetsEncrypt. Они это делают во имя благой цели — безопасного интернета во всём мире. Такой сертификат подойдёт для большинства небольших сайтов и сервисов, но среднему и крупном бизнесу — нет. Им нужны сертификаты с частичной или полной проверкой компании.

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

Пример установки сертификатов с помощью Certbot на Ubuntu

Предположим, у нас есть сайты yoursite.ru и yourblog.ru, работающие по HTTP через Nginx. Добавим для них сертификаты и перейдём на HTTPS.

Заходим на сайт Certbot’a и выбираем Nginx и Ubuntu.

Добавляем ppa для установки certbot на нашем сервере, обновляем зависимости и устанавливаем саму утилиту.

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot

# крайне важно выполнить эту команду, иначе следующая команда выдаст ошибку о незнакомом пакете.
$ sudo apt-get update

# Устанавливаем сам certbot
$ sudo apt-get install certbot python-certbot-nginx

Запускаем certbot и проходим через визард, отвечая на простые вопросы.

$ certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: yourblog.ru
2: yoursite.ru
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Указываем через запятую или пробел номера сайтов из списка, для которых хотим выпустить сертификат, — в нашем случае «1,2» — жмём enter.

Obtaining a new certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/yourblog.ru
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/yoursite.ru

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Certbot настолько заботлив, что предлагает настроить принудительный редирект HTTP->HTTPS за нас. Соглашаемся, введя «2».

Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/yourblog.ru
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/yoursite.ru

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://yourblog.ru and
https://yoursite.ru

Обновление letsencrypt-сертификата

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

Но сюрприз! Certbot уже добавил регулярную задачу в systemd или cron и обновит сертификат сам, нам ничего больше делать не нужно.

—-
Для других систем и веб-серверов установка будет слегка отличаться, поэтому обратитесь к официальному сайту certbot’a.

Эгея. Как добавить Яндекс Метрику и Гугл Аналитику

Чтобы добавить метрики в блог,

  1. создайте файл head-extras.tmpl.php;
  2. добавьте в него код обеих метрик, который можно получить в админках Yandex и Google;
  3. залейте файл на сервер с блогом в папку /путь/до/блога/user/extras.

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

Эгея. Редирект с http на https в Nginx

Предположим, вы хотите, чтобы блог http://blog.ru всегда открывался как https://blog.ru.

  1. Заливаем на сервер в папку /etc/ssl сертификат и ключ, которые вам предоставил регистратор SSL-сертификата:
    /etc/ssl/blog.ru.crt
    /etc/ssl/blog.ru.key
  2. Редактируем файл конфига вашего блога /etc/nginx/sites-enabled/blog.ru
    # Включаем редирект http на https
    server {
        listen 80;
    
        server_name blog.ru www.blog.ru;
        return 301 https://blog.ru$request_uri;
    }
    # Настраиваем обработку HTTPS
    server {
      listen 443 ssl;
      ssl_certificate /etc/ssl/blog.ru.crt;
      ssl_certificate_key /etc/ssl/blog.ru.key;
      server_name blog.ru www.blog.ru;
      ... 
      # остальные конфиги сервера, которые были в разделе HTTP
    }
  3. Перезагружаем nginx в консоли сервера:
    $ nginx -s reload
  4. Заходим на https://blog.ru/@sync/ для чистки кэша. Без этого браузер будет по https://blog.ru показывать статус «No secure».

Базы данных, транзакции и ACID

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

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

ACID — это требования к транзакциям и системам, работающим с ними (например, базам данных). ACID требует, чтобы каждая транзакция

  • не зависала в середине пути в случае ошибки, а откатывала все сделанные изменения (атомарность),
  • после своего завершения не оставляла данные неконсистентными (консистентность),
  • не влияла на другие транзакции (на самом деле влияла, но как можно меньше — 4 уровня изолированности),
  • а вся система гарантировала, что выполненные транзакции будут запомнены системой даже при возникновении аварий и форс-мажоров (стойкость, durability).


Подробнее о каждом требовании и с примерами

  1. Atomicity/Атомарность требует, чтобы либо все команды транзакции были выполнены, либо ни одной. То есть транзакция должна действовать как единая атомарная команда.

    На практике атомарность реализуется через версионирование и откаты (rollback) команд транзакции до первоначального состояния базы. Строго говоря, индексы могут обратно не откатиться, но чаще всего СУБД это разруливают сами.
  2. Сonsistency/Консистентность требует, чтобы после завершения транзакции данные оставались консистентными и валидными, т. е. чтобы они не имели логических или технических противоречий.

    Пример: суммарный баланс счетов должен оставаться неизменным (логическая К.), запись одной таблицы не должна ссылаться на удалённый айдишник другой записи (техническая К.).
  3. Isolation/Изолированность — при параллельном выполнении транзакции не должны влиять друг на друга.

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

  4. Durability/Стойкость — если транзакция завершена успешно, то она не может быть отменена даже при авариях, внезапном отключении света в датацентре и проблем в сети. В этом случае база данных должна сама восстановить последние транзакции.

Уровни изолированности в базах данных

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

  1. Read uncommitted — позволяет избежать «потерянных обновлений», когда две транзакции обновляют одно и то же значение/строку.

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

    Пример: транзакция на перевод денег состоит из команды на списание денег с одного счёта и команды пополнения другого счёта. На момент изменения баланса счёта первой транзакцией вторая подобная транзакция встанет в очередь, пока данные не освободятся. Но SELECT-запрос может считать состояние, когда деньги списаны с одного счёта, но на второй ещё не зачислены.

  2. Read committed — то же, что выше + решает проблему чтения «грязных» состояний незавершённых транзакций. Большинство баз данных по умолчанию работает на этом уровне изолированности.

    Однако если транзакция содержит две SELECT-команды и во время между ними другая UPDATE-транзакция успешно завершится, то результат этих SELECT-запросов может отличваться: один вернёт состояние до UPDATE-транзакции, второй — после. Важно, что это не «грязное» состояние, а чистое, после успешной транзакции.

  3. Repeatable read (повторяемость чтения) — оба пункта выше + гарантирует, что SELECT-запросы в рамках одной транзакции всегда будут возвращать один и тот же результат, даже если другие транзакции обновляют или удаляют эти же данные.

    Транзакция блокирует все строки, затрагиваемые её командами, включая SELECT, а другие транзакции с SELECT-, UPDATE- и DELETE-запросами к этим данным ждут её завершения. Естественно, это сильно снижает скорость обработки транзакций базой данных.

  4. Serializable — три пункта выше + исключает «фантомные чтения».

    «Фантомное чтение» похоже на проблему с двумя последовательными SELECT-запросами одной транзакции, но возникает, когда между SELECT-запросами была выполнена именно вставка (INSERT). Пример: аггрегационные запросы SELECT SUM(), SELECT COUNT().

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

  5.  



Принципы работы docker и примеры использования docker-compose

Артём Матяшов записал отличный полуторачасовой урок про основы докера. Можно посмотреть на x1.5 за час.

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

Однозначно лайк!

Как улучшить терминал в Mac OS X: iTerm2, omyzsh, zsh

Отличная статья про апгрейд встроенного Terminal
https://medium.com/@Clovis_app/configuration-of-a-beautiful-efficient-terminal-and-prompt-on-osx-in-7-minutes-827c29391961

Краткий план действий

  1. Ставим iTerm2 на замену Terminal. Они нормально сосуществуют и можно будет откатиться, если не понравится.
brew cask install iterm2
  1. Ставим цветовую cхему для iTerm2 (сохраняйте именно как .itermcolors) — это набор цветов и ничего больше. На данном этапе терминал всё ещё будет выглядеть уныло.
  2. Качаем шрифт с поддержкой дополнительных символов-иконок: обычный или жирный (он контрастнее) — и устанавливаем в систему. Иначе увидим не иконки, а пустые квадратики.
    Меняем размер шрифта на 12-14pt или какой удобнее.
  3. Через консоль iTerm’a устанавливаем Zsh (вместо стандартного Bash) и Oh my Zsh — само ядро командной строки и оболочку с форматированием вокруг неё.
# Возможно, zsh у вас уже есть по умолчанию. Чтобы проверить, нужно ввести : 
which zsh
# Если вернёт путь, значит есть. Если нет, то ставим:
brew install zsh zsh-completions
# Устанавливаем Oh my Zsh
sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
  1. Важно: теперь основной конфигурационный файл консоли — ~/.zshrc, а не ~/.bashrc или ~/.bash_profile.
  2. Скачиваем в дефолтную директорию тему — самую маковку, которая добавит красоты в терминал
git clone https://github.com/bhilburn/powerlevel9k.git ~/.oh-my-zsh/custom/themes/powerlevel9k
# Редактируем ~/.zshrc и меняем конфиг
ZSH_THEME="powerlevel9k/powerlevel9k"
  1. Перезагружаем iTerm и вуаля.

Улучшение вида и поведения терминала

  1. Вид самой строки
POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir rbenv vcs)
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator background_jobs history time)
POWERLEVEL9K_VCS_MODIFIED_BACKGROUND='red' # Будет менять цвет, если есть обновления в гит-репозитории
  1. Я не стал делать перенос строки (POWERLEVEL9K_PROMPT_ON_NEWLINE=true), так как у меня терминал всегда на всю ширину экрана и места хватает.
  2. Обязательно: iTerm → Preferences → Profiles → Keys → Load Preset… → Natural Text Editing, чтобы работала навигация через Option + стрелки и прочее.
  3. Можно добавить автодополнение команд на основе истории
git clone https://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM/plugins/zsh-autosuggestions
vim ~/.zshrc
# Внутри файла добавляем через пробел название плагина
plugins=(… zsh-autosuggestions)
  1. Включаем автозагрузку ssh-ключей при старте терминала:
    https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/ssh-agent
vim ~/.zshrc
# Внутри файла добавляем через пробел название плагина
plugins=(… ssh-agent)
# Сразу ниже включаем ssh-agent и указываем ключи через пробел — у меня их два
zstyle :omz:plugins:ssh-agent agent-forwarding on
zstyle :omz:plugins:ssh-agent identities id_rsa id_rsa2
# Эта строка у вас уже будет, главное команды выше поместить до этой строки с source
source $ZSH/oh-my-zsh.sh
  1. Перезагружаем iTerm. Уже всё готово!
  2. Опционально: после всех правок IDE, которые содержат встроенный терминал, могут выглядеть слегка кривовато. Нужно им помочь с определением шрифта. Например, в VS Code в настройках меняем параметры:
"terminal.integrated.fontFamily": "Meslo LG M for Powerline"
"terminal.integrated.fontSize": 12
Ранее Ctrl + ↓