Что такое веб-сервер: Apache, nginx и Caddy

Веб-сервер — программа, которая принимает HTTP-запрос и отвечает готовым файлом или ответом приложения. Самые известные — Apache, nginx и Caddy.

Между браузером и файлом

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

Её работа выглядит так. Она слушает порт (80 для HTTP, 443 для HTTPS) и ждёт соединений. Когда приходит запрос, она его разбирает (метод, путь, заголовок Host, о которых вы читали в уроке про HTTP), решает, что отвечать, и отправляет ответ с кодом состояния. Чаще всего «что отвечать» означает одно из двух: взять готовый файл с диска или спросить приложение, которое соберёт страницу по запросу. Об этих двух вариантах и будет эта часть.

Три сервера, с которых начинают

• Apache HTTP Server (с 1995 года) самый давний. В 1990-е он был синонимом веб-сервера, и именно на нём работает большая часть «общего хостинга», где вы платите копейки и получаете папку для файлов. Гибкий: настройки можно положить в файл .htaccess прямо в папку сайта, и они сработают без перезапуска. Платой за гибкость стала скорость при множестве одновременных посетителей.
• nginx (читается «энджин-экс», с 2004 года) придумал в России Игорь Сысоев для портала Рамблер, чтобы справляться с десятками тысяч одновременных соединений. Он устроен экономнее Apache и отлично отдаёт файлы, а ещё стал стандартным обратным прокси: его ставят перед приложениями. Сегодня это один из самых распространённых серверов в мире (свежие цифры публикуют W3Techs и Netcraft, сводка в статье Википедии из источников). Есть и его ответвления, например российский Angie.
• Caddy (с 2015 года) написан на языке Go и подкупает простотой: короткий файл настроек, а сертификат для HTTPS он сам получает и продлевает. Для небольшого проекта это самый лёгкий старт.

Есть и другие (IIS у Microsoft, LiteSpeed), но принцип у всех один, и конфиги похожи друг на друга. Научившись читать один, вы прочтёте остальные.

Как выглядит конфиг

Сервер ведёт себя так, как написано в его конфиге: текстовом файле с правилами. Вот полный пример для nginx. Поверхность его небольшая, и каждая строка читается по-русски.

server {
    listen 80;                      # слушать порт 80
    server_name example.ru;         # для сайта с таким именем (из заголовка Host)
    root /var/www/site;             # где лежат файлы сайта
    index index.html;               # что отдавать по адресу «/»

    error_page 404 /404.html;       # своя страница «не найдено»

    location = /staraya-stranica {  # точный адрес
        return 301 /uslugi.html;    # переехал навсегда сюда
    }

    location /api/ {                # всё, что начинается с /api/
        proxy_pass http://127.0.0.1:3000;   # передать приложению
    }

    location / {                    # все остальные адреса
        try_files $uri $uri/ =404;  # файл? папка? иначе 404
    }
}

Главное слово здесь location: правило для адреса. С точным знаком = оно подходит только одному адресу, без него подходит всем адресам, которые с этого начинаются; если подходят несколько, выигрывает самое длинное совпадение. Внутри правила стоят действия: return 301 отвечает переездом, try_files ищет файл по порядку и последним ставит =404, proxy_pass передаёт запрос приложению.

Попробуйте сами: измените конфиг и спросите разные адреса. Схема считает ответ по этим правилам и называет сработавшее:

Конфиг (его можно править) server { listen 80; server_name example.ru; root /var/www/site; index index.html; error_page 404 /404.html; location = /staraya-stranica { return 301 /uslugi.html; } location /api/ { proxy_pass http://127.0.0.1:3000; } location / { try_files $uri $uri/ =404; } }

Вернуть пример

Файлы на диске в папке сайта: index.html, uslugi.html, kontakty.html, 404.html

GET /GET /uslugi.htmlGET /kontakty.htmlGET /staraya-stranicaGET /net-takojGET /api/itemsGET /uslugi.html/

404 Not Found

Content-Type: text/html

Сработало правило: location /.

Отдана страница ошибки /404.html с кодом 404.

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

Проверьте себя: почему в try_files последним стоит =404?

Чтобы несуществующий адрес получал честный ответ «не найдено». Без него сервер мог бы отдать главную страницу или пустой ответ с кодом 200, и посетитель с поисковиком были бы введены в заблуждение.

Обратный прокси

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

Зачем такой посредник:

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

Если приложения нет, а сайт статический, прокси не нужен: сервер сам отдаёт файлы.

Практика

Вы на сайте эпохи 1996 года: тогда сайт был папкой с файлами, а сервер отдавал их как есть. Представьте, что страницы вашего проекта лежат в такой папке. Вам нужно: дать каждому разделу свой адрес, настроить страницу «не найдено» с честным кодом 404 и сделать переезд со старого адреса на новый кодом 301.

Настоящего сервера в песочнице нет, и поэтому конфиг вы пишете текстом, а проверяете в схеме выше, а потом им можно пользоваться почти без изменений. Вставьте в конец страницы (перед </body>) этот каркас:

<section data-scaffold id="server">
  <h2>Сервер сайта</h2>
  <table>
    <tr><th>Раздел</th><th>Адрес</th><th>Файл</th></tr>
    <tr class="route"><td>Первый раздел</td><td class="url">…</td><td class="file">…</td></tr>
  </table>
  <pre id="conf">…</pre>
  <p id="role">…</p>
</section>

Добавьте строки таблицы так, чтобы на каждый раздел вашего брифа была своя, и замените все …. В data-scaffold ничего волшебного нет, это просто отметка для курса: блок не попадёт в скачанный сайт.

Что было не так раньше

В 1996 году сайт и впрямь был папкой, а настройки сервера часто не делал никто: страница «не найдено» была стандартной серой с английским текстом, старые адреса просто переставали работать, а ссылки на них вели в никуда. Одна и та же страница открывалась и с www, и без, и поисковики считали её двумя разными. Ошибки сервера выдавали версию программы и даже пути на диске, которые стоило бы скрыть.

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