Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 <h2>Процессы</h2>

3 Единицей исполнения в операционных системах является процесс. Это некоторая абстракция внутри ОС. Любая запущенная программа - это либо один процесс, либо набор процессов. Например, в браузерах одна вкладка, как правило, - это один процесс.

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

5 Внутри себя процесс может делиться на потоки:

6 Посмотреть список процессов в Linux можно командой ps aux либо top.

7 Подробнее о менеджменте процессов можно прочитать в<a>книгах</a>по операционным системам.

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

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

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

11 Благодаря DNS браузер получает IP-адрес компьютера, на котором расположен сайт указанного домена. Также существует соглашение, согласно которому веб-сервер, обслуживающий сайт по протоколу HTTP, слушает порт 80, а протокол HTTPS обслуживается на порту 443. Поэтому браузер знает порт, на котором висит веб-сервер в ожидании входящих запросов.

12 Но так бывает не всегда. Во время локальной разработки обычно используются другие порты, например, 3000 или 4000. Сам номер не принципиален. Главное, что он доступен для веб-сервера, и мы обращаемся через браузер именно к нему. Порт указывается через двоеточие после названия сайта, например, www.google.com:80.

13 <h2>Веб-сервер</h2>

14 Веб-сервер- специализированная программа для обслуживания сайтов. Один веб-сервер может обрабатывать практически любое число сайтов (Virtual Hosts в HTTP). Он перенаправляет входящие сетевые запросы на код сайтов, получает от них ответ и возвращает его браузеру.

15 Еще у веб-серверов есть большое количество вспомогательных функций. Среди них кеширование, перезапись запросов, раздача статики, reverse proxy, балансировка нагрузки и многое другое.

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

17 Первым и самым простым способом взаимодействия веб-сервера с сайтом былCGI- Common Gateway Interface. Этот стандарт сразу разрабатывался с учетом того, что сервер не должен зависеть от того, на чем написан сайт. Он основан на переменных окружения.

18 По сути, сайт - это исполняемый файл, который запускается веб-сервером во время обработки входящего запроса и передает в него все параметры запроса через переменные окружения. Все, что требуется от скрипта, - это вернуть HTTP-ответ в стандартный вывод (STDOUT). Общий алгоритм работы выглядит так:

19 <ol><li>Клиент запрашивает страницу сайта</li>

20 <li>Веб-сервер принимает запрос и устанавливает переменные окружения. Через них приложению передаются данные и служебная информация</li>

21 <li>Веб-сервер перенаправляет запросы через стандартный поток ввода (stdin) на вход вызываемой программы</li>

22 <li>CGI-приложение выполняет все необходимые операции и формирует результаты в виде HTML</li>

23 <li>Сформированный гипертекст возвращается веб-серверу через стандартный поток вывода (stdout). Сообщения об ошибках передаются через поток ошибок (stderr)</li>

24 <li>Веб-сервер передает результаты запроса клиенту</li>

25 </ol><h2>WSGI</h2>

26 У CGI-серверов был один важный недостаток - они запускали скрипты на каждый запрос, значит, каждый раз запускался интерпретатор. В ответ CGI в Python-комьюнити предложили новый стандарт, описанный в<a>PEP3333</a>- WSGI (Web Server Gateway Interface).

27 Основная идея WSGI - простое взаимодействие Python-приложения и веб-сервера. Согласно стандарту, веб-приложение - это просто функция или другой callable объект, которая принимает два аргумента

28 <ul><li>Словарь переменных окружения</li>

29 <li>Функцию, которая устанавливает параметры ответа, а возвращает iterable в качестве ответа</li>

30 </ul>Минимальное WSGI-приложение, то есть приложение, которое поддерживает стандарт WSGI, выглядит примерно так:

31 WSGI-сервер внутри себя вызовет функцию app и с помощью механизма замыканий передаст в нее необходимые аргументы. Все, что касается конкретного запроса, приходит в аргументе environ. Функция start_response() устанавливает параметры ответа. В приведенном примере - размер ответа и тип содержимого. Затем функция просто возвращает итератор, который построчно отдает ответ.

32 Все современные веб-фреймворки в Python поддерживают стандарт WSGI, то есть предоставляют на верхнем уровне этот callable объект - app во Flask, wsgi модуль в Django. А все WSGI-серверы умеют с этим объектом работать. Некоторые веб-серверы, как nginx, не поддерживают стандарт, но все равно умеют общаться с WSGI совместимыми (gunicorn, uWSGI). Поэтому мы часто будем встречать классическую связку как nginx-gunicorn-Django.

33 <h2>Реализации</h2>

34 Веб-серверов довольно много. Самым популярным и эффективным решением на текущий момент является nginx. Именно с ним и стоит познакомиться. Для разработки он не понадобится, но в продакшен-среде без него нельзя.

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

36 Еще в Python самым популярным решением для WSGI-сервера остается gunicorn. Хоть gunicorn и является полноценным веб-сервером, его чаще используют в связке с nginx или Caddy. Так он отдает все сложности по кешированию, балансировке, раздаче статики, сертификатам и многое другое на их плечи.