Сущности, имеющие дело с http запросом

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

  1. Какая- то сущность должна открыть tcp-порт и ждать запроса от клиента. Ответственность за это лежит на http-сервере.
  2. После того, как http- запрос был получен, нужен кто- то, кто мог бы его распарсить, получить из него всякие данные и позвать приложение (приложение представляет собой обычную программку на компьютере, она может быть написана чуть ли не на любом языке программирования, например, это может быть программа на C, C++, Java, C#, Python, F#, в общем, думаю, вы поняли). Этим всем занимается сервер приложений (application server);
  3. Само приложение, которое ведет непосредственную работу с http: обращается в базу данных в таблицу с мемами и отдает клиенту порцию мемов в виде http ответа.

Как надо было смотреть мемы раньше, в давние времена?

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

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

  1. Приняла http запрос, заглянув в него, поняла, что от неё хотят (допустим, клиент шлет запрос GET, чтобы посмотреть определенную html страницу;
  2. Сообразила бы, где искать эту страницу или какой- то другой ресурс, старый мем, мы же тут старину вспоминаем. Этот путь до ресурса она получила бы, опираясь на URL, по которому обратился клиент. URL представлял собой либо настоящий путь до файла, либо программка бы использовала его для отображения на настоящий путь, чтобы не раскрывать клиенту файловую структуру, могли использовать отображение;
  3. Сформировала бы http ответ с применением запрашиваемого ресурса (запихнула бы мем или html-страницу в http) и отправила клиенту.

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

Если вы попробуете по протоколу SMB из Linux обратиться к какому- то файлу на удаленном хранилище, то скорее всего, вам придется вбивать куда- нибудь строку- адрес SMB-сервера. Что- то наподобие smb://remote_storage/users/my_user/funny_mem.jpg. Вы также можете вспомнить, что ранее, годах в 2010-х да и попозже в адресной строке браузера вы вбивали http://название_сайта.ru, не находите сходство?

smb или http лишь протокол, который будет использоваться для доступа к удаленной машине, в случае http, скорее всего соединение пойдет через tcp- порт 80 на удаленной машине, в случае smb через tcp порты 137 или 139. Ну и со своими нюансами, ведь smb и http по- разному описывают то, как клиент и сервер должны общаться. А то, что идет после :// является адресом запрашиваемого ресурса. Таким образом, получается, что и в том и в другом случае вы делаете примерно одно и то же похожими способам.

Так, а как сервер приложений вызывает приложение?

Описанная выше схема хорошо работает и по сей день, если бы не один нюанс: разным пользователям демонстрируется по одному и тому же адресу веб- страницы с разной наполненностью, а то и вовсе разные веб -страницы (это уже тема A/B тестирования, пока что её касаться не будем). Например, я захожу на свою страницу в Вконтакте и вижу элементы управления: могу загрузить видео или новый пост на свою страницу. Но при этом вы, если перейдете по этому же адресу, увидите лишь мою страницу, без возможности внесения изменений в неё. В ином случае рискну предположить, что вы меня взломали.

Теперь веб- страницы формируются приложениями. Как мы помним, приложение может быть написано на множестве языков программирования, возникает вопрос, а как серверу приложений и приложению договориться о том, как им вместе работать? В качестве ответа на этот давнишний вопрос появился протокол CGI или Common Gateway Interface.

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

Для python тоже появился свой протокол взаимодействия WSGI, он был разработан специально для веб-приложений, написанных на Python, что добавляло и добавляет удобства разработчикам веб- приложений на Python. Свое развитие этот протокол получил в лице ASGI, асинхронной своей версии. Протокол ASGI позволяет вызывать как асинхронный python код, так и синхронный, , а также обладает обратной совместимостью с WSGI, то есть, может вызывать код WSGI- совместимого приложения.

Как сейчас мемы получаются из Интернета?

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

Я надеюсь, что у меня не получилось вас убедить в целесообразности использовать веб-http-сервер, сокращенно веб-сервер. Ведь, фактически, ничего не стоит в плане затрат на написание кода “выставить” сервер приложений по 443 или по 80 порту наружу (http, https) и обрабатывать клиентские запросы через него.

В моих планах рассказать в одном из будущих постов, а также о проблемах C10K и C10M. Пока что прошу принять на веру то, что такой веб-сервер, как Nginx жизненно необходим для веб- приложения, для которого планируется нагрузка порядка 10000 одновременных подключений.