Как работает веб сервер?

Question

[iDennis]

К примеру я на клиенте послал запрос(http) на конкретный сервер (тут всё понятно),
сервер получил этот запрос , но как ? Каким образом реализована в apache и ос получение запроса (исходники из ос или apache) ?

Comments

[agurman]

Это все может быть реализавано от системы к системе по разному. Но на обычном компьютере, в большинстве случаев, это работает примерно так. ОС (точнее драйвер сетевой карты) получает аппаратное прерывание, когда приходят данные на карту. К слову сказать есть так называемый механизм "опложенных прерываний". Если не вдаваться в подробности, то прерывания будут приходить не на каждый кусок данных полученных картой, а только тогда, когда софт разрешит себя прерывать. То есть: получил прерывание, запретил прерывания, начал обрабатывать все что пришло и приходит, закончил, разрешил прерывания. В зависимости от системы или ее настроек, драйвер уже может что-то сделать с данными. Намеренно не употребляю слово "пакет", ибо это пока только данные, лежащие в буфере. Потом после всех проверок, они могут быть переданы сетевому стеку OS. Сетевой стэк, собственно как и драйвер, как правило является модулем ядра. На самом деле сетевой стек - это, сильно конфигурируемая и многослойная/многоуровневая и сложная подсистема ядра, и как правило представляет не один модуль, а множество. На каждом уровне, в зависимости от его настройки и/или типа данных (толко теперь уместно их называть фреймами/пакетами/дейтаграммами) может приниматься решение, что с ним делать дальше. Например: форварднуть куда-нибудь, или скипнуть, или ответить на них прямо в ядре, не передавая наверх в юзер-спайс, или все же передать. Вот если это свой пакет, то есть cвой/правильный ip, если открыт порт на прослушку, например WEB сервером (80/tcp), с помощью описанного выше механизма сокетов, тогда он будет передан в юзе-спейс web серверу на обработку. Серверы могут его тоже обрабатывать по разному. Аппачи например, по крайней мере ранние его версии, не парился особо, выделял каждому соединению по потоку загружал туда что-то, что обработает этот запрос, и уходил слушать дальше. Но сильно-нагруженные серверы, так работать не смогут, ибо потоки много "весят", поэтому есть еще куча, более продвинутых, способов обработки запросов сервером. К слову сказать, есть серверы которые прямо в ядре и живут. Зоопарк серверов, ровно как и сетевых стеков, большой и слишком сложный для одного поста. Будет время опишу полнее и грамотнее. Но "вкратце" должно быть понятно.

[agurman]

Вот кстати доступная статейка про собственно серверы algolist.manual.ru/web/servers.php

Answer 1

[Sergey Lerg]

По TCP приходит сигнал в сетевую карту, та вычленяет из него пакет и перенаправляет в ядро ОС, ядро уже смотрит какому приложению отдать этот пакет. Находит Apache и передаёт ему, тот парсит пакет, выделяет запрос, парсит запрос и дальше по программе.

Comments

[iDennis]

тогда как сетевая карта получает сигнал? что ос постоянно проверяет чтобы узнать есть запрос или нету?

[neolink]

на канальном уровне (сетевая карта) только кадры, там нет ip адресации только по mac адресу

[Sergey Lerg]

@iDennis: получает по проводам или радио (wifi), точный механизм общения драйвера и ОС не знаю, но явно модель там событийная.

Answer 2

[vinca]

Поверхностно про сеть: ru.m.wikipedia.org/wiki/%D1%E5%F2%E5%E2%E0%FF_%EC%... - тут нужно уловить, что такое сигналы, что такое пакеты и что такое данные...

Теперь, о том как пишется собственно сервер (приложение). ОС предоставляет 4-е системных вызова (про сетевую карту, драйвера и как ОС работает с erhernet не буду рассказыывать). Собственно системные вызовы:
1) socket - создает сокет, для веб сервера, обычно это tcp;
2) bind - привязывает сокет к локальному ip-адресу сервера (железки) и на определенный порт. Нужно из-за того, что на железке может быть много ip-адресов;
3) listen - переводит сокет в состояние "слушать" (включает его на прием и передачу - если просто), это значит, что сокет готов принимать соединения от клиента (см tcp handshake) и ставить его в очередь ОС (очередь приложения backlog);
4) accept - создает сокет к клиенту, позволяя уже с ним обмениваться данными. Accept вызывает само приложение, в зависимости от алгоритма, учитывая что есть ресурсы на обработку клиентского запроса. Если accept не сделать, то соединение повиснит в очереди (backlog) на время таймаута выставленного со стороны клиента или сервера.

После accept, apache создает дочерний процесс, который уже и начинает из данных извлеченных из tcp "парсить" http по rfq (аля соглашению) и обрабатывать пользовательский запрос - разбирая зоголовки и выплевывая в сетевой буфер прочтенный с диска index.html с правильными заголовками http 1.0 или 1.1.

Answer 3

[Хазрат Гаджикеримов]

В книге Котерова PHP в подлинке полностью описана работа веб сервера, она очень полезная книга! советую прочитать!

Answer 4

[agurman]

Это все может быть реализавано от системы к системе по разному. Но на обычном компьютере, в большинстве случаев, это работает примерно так. ОС (точнее драйвер сетевой карты) получает аппаратное прерывание, когда приходят данные на карту. К слову сказать есть так называемый механизм "опложенных прерываний". Если не вдаваться в подробности, то прерывания будут приходить не на каждый кусок данных полученных картой, а только тогда, когда софт разрешит себя прерывать. То есть: получил прерывание, запретил прерывания, начал обрабатывать все что пришло и приходит, закончил, разрешил прерывания. В зависимости от системы или ее настроек, драйвер уже может что-то сделать с данными. Намеренно не употребляю слово "пакет", ибо это пока только данные, лежащие в буфере. Потом после всех проверок, они могут быть переданы сетевому стеку OS. Сетевой стэк, собственно как и драйвер, как правило является модулем ядра. На самом деле сетевой стек - это, сильно конфигурируемая и многослойная/многоуровневая и сложная подсистема ядра, и как правило представляет не один модуль, а множество. На каждом уровне, в зависимости от его настройки и/или типа данных (толко теперь уместно их называть фреймами/пакетами/дейтаграммами) может приниматься решение, что с ним делать дальше. Например: форварднуть куда-нибудь, или скипнуть, или ответить на них прямо в ядре, не передавая наверх в юзер-спайс, или все же передать. Вот если это свой пакет, то есть cвой/правильный ip, если открыт порт на прослушку, например WEB сервером (80/tcp), с помощью описанного выше механизма сокетов, тогда он будет передан в юзе-спейс web серверу на обработку. Серверы могут его тоже обрабатывать по разному. Аппачи например, по крайней мере ранние его версии, не парился особо, выделял каждому соединению по потоку загружал туда что-то, что обработает этот запрос, и уходил слушать дальше. Но сильно-нагруженные серверы, так работать не смогут, ибо потоки много "весят", поэтому есть еще куча, более продвинутых, способов обработки запросов сервером. К слову сказать, есть серверы которые прямо в ядре и живут. Зоопарк серверов, ровно как и сетевых стеков, большой и слишком сложный для одного поста. Будет время опишу полнее и грамотнее. Но "вкратце" должно быть понятно.

Answer 5

[Александр Борисович]

На 80 порту висит апач и парсит что ему приходит из http. Дальше передает что пришло уже вашему коду если это поразумевают настройки апача.

Comments

[iDennis]

реализация получения запроса?

[Александр Борисович]

https://github.com/iFuSiiOnzZ/http
Как пример