Путь запроса от ввода URL в браузере до полной отрисовки страницы на 1С-Битрикс

1. Сетевой уровень: От клика до сервера

DNS (Domain Name System): Браузер не знает, где живет site.ru. Он спрашивает у системы: «Какой IP у этого имени?». Система идет к провайдеру, тот к корневым серверам. Итог: получение IP-адреса (например, 1.2.3.4).
TCP Three-Way Handshake: Браузер говорит серверу: «Привет, хочешь соединиться?». Сервер: «Привет, давай». Браузер: «Ок, начинаем». Это база для надежной передачи данных.
TLS Handshake (HTTPS): Если сайт на SSL, клиент и сервер обмениваются сертификатами и создают секретный ключ шифрования. Теперь данные не украсть.
HTTP-пакет: Браузер формирует текстовый запрос: метод (GET/POST), заголовки (User-Agent, Cookies) и сам URL.

Nginx (Front-end):
Static Handling: Nginx смотрит на запрос. Если в конце .png или .css, он просто берет файл с диска через sendfile и отдает. Это в десятки раз быстрее, чем если бы это делал PHP.
Reverse Proxying: Если запрос — это папка или .php, Nginx переупаковывает HTTP-запрос и перекидывает его на 127.0.0.1:8080 (где слушает Apache).
Apache (Back-end):
Чтение .htaccess: Это критический момент. Apache видит файл настроек в корне. Там стоит правило: «Если файла /catalog/shoes/ не существует физически, перенаправь запрос на index.php». Это и есть работа ЧПУ (человекопонятных URL).
mod_php: В отличие от PHP-FPM, здесь интерпретатор — это часть самого процесса Apache. Он уже загружен и готов исполнять код немедленно.

А. Инициализация (Prolog Before)

Конфигурация: Битрикс лезет в bitrix/.settings.php (новый формат D7) и bitrix/php_interface/dbconn.php (старый формат). Там лежат данные для MySQL: HOST, USER, PASSWORD.
Коннект к БД: PHP устанавливает соединение. Если оно падает — вылетает знаменитая ошибка «DB query error».
Константы и Автозагрузка: Определяются пути (например, SITE_ID). Регистрируется автозагрузчик классов, чтобы можно было писать new \Bitrix\Main\User, не подключая файлы вручную.
События (Events): Выполняются обработчики OnPageStart и OnBeforeProlog. Здесь работают кастомные скрипты или модули оптимизации.

Б. Сборка страницы

Header (/bitrix/header.php):
Запускает буферизацию вывода.
Подключает файл /local/templates/ваш_шаблон/header.php.
Там срабатывает метод $APPLICATION->ShowHead(), который позже подставит скрипты и стили.
Компоненты (Workarea):
В центре страницы стоит вызов bitrix:catalog или bitrix:news.
Компонент идет в БД, делает запрос (например, SELECT * FROM b_iblock_element).
Получает данные, кладет их в массив $arResult.
Подключает файл template.php, где этот массив «размазывается» по HTML-тегам.
Footer (/bitrix/footer.php): Закрывает верстку шаблона.

В. Эпилог (Epilog)

Отложенные функции: Это «киллер-фича» Битрикса. Поскольку мы сначала собрали контент, а потом поняли, какой должен быть <title>, Битрикс на этом этапе берет весь накопленный в буфере HTML и заменяет в нем «заглушки» на реальные заголовки и JS-коды.
Bitrix Component Cache: Если кэш включен, Битрикс сохраняет результат работы компонентов в файлы или Redis, чтобы в следующий раз не дергать БД.

Final Output: Apache отдает готовый HTML-текст в Nginx.
Gzip: Nginx на лету сжимает этот текст (из 100 Кб делает 20 Кб) и отправляет браузеру.
Browser Rendering: Браузер получает HTML, строит дерево объектов (DOM), видит ссылки на картинки (которые Nginx отдает мгновенно) и собирает финальную картинку для пользователя.