Документ описывает архитектуру и принципы работы типового веб-приложения, которое функционирует как клиент-серверное приложение с разделением логики между сервером и клиентом. Он затрагивает технологии, используемые на серверной и клиентской стороне, принципы работы протоколов TCP/IP и HTTP, а также спецификации обмена данными и обработки запросов в веб-приложениях. Основное внимание уделяется взаимодействию между компонентами системы, включая серверы, базы данных и пользовательские интерфейсы.

1. Архитектура и принципы работы типового web-
приложения

2. WEB-приложение
Клиент-серверное приложение, в котором клиентом
выступает браузер, а сервером — web-сервер.
Логика web-приложения распределена между
сервером и клиентом.
Хранение данных осуществляется, преимущественно,
на сервере.
Обмен информацией происходит по сети.

3. Диаграмма типового web-приложения

4. В web-приложениях существуют две программы,
работающие одновременно:
Код живущий на сервере и отвечающий на HTTP
запросы;
Код живущий в браузере и отвечающий на ввод
данных пользователем.

5. Серверный код
Языки программирования/фреймворки:
Javascript(Node.js), Python(Django), PHP, Ruby On
Rails, Java, C# etc;
Не виден пользователю;
Может отвечать только на HTTP запросы конкретного
URL, а не на любой тип пользовательского ввода;

6. Клиентский код
Языки программирования: HTML, CSS, JavaScript;
Парсится браузером пользователя;
Реагирует на пользовательский ввод;
Доступен для просмотра и редактирования
пользователю в полном объеме;
Не может читать файлы с сервера на прямую, должен
общаться с сервером через HTTP запросы;

7. Технологический стек
1. Операционная система (файловая система). Чаще
всего Linux;
2. WEB-сервер (Apache, NGINX, IIS etc.);
3. База данных (MySql, MongoDB, MS Sql, Oracle,
PostgreSql, Redis, Cassandra etc.);

8. Технологический стек

9. Путь запроса
1. DNS
2. HTTP, SPDY
3. Front Server (NGINX)
4. Back Server ot Application Server (Apache, PHP-FPM)
5. PHP code, opcode
6. Response

10. DNS
DNS (англ. Domain Name System — система доменных
имён) — компьютерная распределённая система для
получения информации о доменах. Чаще всего
используется для получения IP-адреса по имени хоста
(компьютера или устройства), получения информации о
маршрутизации почты, обслуживающих узлах для
протоколов в домене (SRV-запись).

11. DNS
Путь пользовательского запроса начинается с DNS:
1. Пользователь обращается к DNS для получения IP
адреса
2. DNS отдает пользователю IP адрес
3. Пользователь обращается к WEB-приложению по IP
через TCP/IP
4. Открывается сетевое соединение (HTTP, SPDY)

12. How web-browser works?

13. How web-browser works?

14. TCP/IP
Стек протоколов TCP/IP — набор сетевых протоколов передачи данных,
используемых в сетях, включая сеть Интернет. Название TCP/IP происходит
из двух наиважнейших протоколов семейства — Transmission Control Protocol
(TCP) и Internet Protocol(IP), которые были разработаны и описаны первыми
в данном стандарте. Также изредка упоминается как модель DOD в связи с
историческим происхождением от сети ARPANET из 1970 годов (под
управлением DARPA, Министерства обороны США).

15. TCP/IP

16. TCP/IP
IP — протокол, лежащий в основе Интернета, его название так и расшифровывается: Internet Protocol.
В настоящее время используются следующие две версии протокола IP:
IPv6 — сравнительно новая (текущая версия спецификации опубликована в декабре 1998[1]); IP-адрес имеет
разрядность 128 бит и записывается в виде восьми 16-битных полей, с использованием
шестнадцатеричной системы счисления и с возможностью сокращения двух и более последовательных
нулевых полей до ::; пример: 2001:db8:42::1337:cafe;
IPv4 — «классическая» (1981 г.[2]); IP-адрес имеет разрядность 32 бита и записывается в виде четырех
десятичных чисел в диапазоне 0 … 255 через точку; пример: 192.0.2.34.
Каждый узел может напрямую связаться только с узлами своей сети (например: подключенными к тому же
сегменту Ethernet), для определения которых используется адрес сети — часть IP-адреса, определяемая маской
сети). Связь с узлами других сетей осуществляется через промежуточные узлы — маршрутизаторы.
Посмотреть, как выглядит маршрут пакета от вашего компьютера к другим узлам, можно с помощью команды
traceroute (в Linux) или tracert (в Windows).

17. TCP/IP
TCP протокол базируется на IP для доставки пакетов, но добавляет две важные вещи:
установление соединения — это позволяет ему, в отличие от IP, гарантировать доставку
пакетов
порты — для обмена пакетами между приложениями, а не просто узлами
Протокол TCP предназначен для обмена данными — это «надежный» протокол, потому что:
1. Обеспечивает надежную доставку данных, так как предусматривает установления
логического соединения;
2. Нумерует пакеты и подтверждает их прием квитанцией, а в случае потери организует
повторную передачу;
3. Делит передаваемый поток байтов на части — сегменты - и передает их нижнему
уровню, на приемной стороне снова собирает их в непрерывный поток байтов.

18. TCP/IP
TCP-соединение
Соединение двух узлов начинается с handshake (рукопожатия):
1. Узел A посылает узлу B специальный пакет SYN — приглашение к соединению
2. B отвечает пакетом SYN-ACK — согласием об установлении соединения
3. A посылает пакет ACK — подтверждение, что согласие получено
После этого TCP соединение считается установленным, и приложения, работающие в этих узлах,
могут посылать друг другу пакеты с данными.
«Соединение» означает, что узлы помнят друг о друге, нумеруют все пакеты, идущие в обе
стороны, посылают подтверждения о получении каждого пакета и перепосылают потерявшиеся по
дороге пакеты.
Для узла A это соединение называется исходящим, а для узла B — входящим.

19. HTTP, SPDY
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста»)
— протокол прикладного уровня передачи данных (изначально — в виде
гипертекстовых документов в формате «HTML», в настоящий момент
используется для передачи произвольных данных).
SPDY (читается как «speedy», «спиди») — протокол прикладного уровня для
передачи веб-контента. Протокол разработан корпорацией Google. По
замыслу разработчиков, данный протокол позиционируется как замена
некоторых частей протокола HTTP — таких, как управление соединениями и
форматы передачи данных.

20. HTTP, SPDY
Клиент общается с сервером посредством HTTP-
сообщений
Обмен сообщениями идёт по обыкновенной схеме
«запрос-ответ».:
1. Клиент отправляет на сервер запрос
2. Сервер генерирует ответ.

21. HTTP/HTTPS
Структура протокола
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
1. Стартовая строка (англ. Starting line) — определяет тип сообщения;
2. Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и
прочие сведения;
3. Тело сообщения (англ. Message Body) — непосредственно данные сообщения.
Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным
элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола,
у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело
сообщения.
Для версии протокола 1.1, сообщение запроса обязательно должно содержать заголовок Host.

22. HTTP/HTTPS
Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
GET URI — для версии протокола 0.9;
Метод URI HTTP/Версия — для остальных версий.
Здесь:
Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET,
список запросов для версии 1.1 представлен ниже;
URI определяет путь к запрашиваемому документу;
Версия (англ. Version) — пара разделённых точкой цифр. Например: 1.0.
Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение, где:
Версия — пара разделённых точкой цифр, как в запросе;
Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение
клиента;
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и
является необязательным.
Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

23. HTTP/HTTPS
Методы
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих
и разделителей, указывающая на основную операцию над ресурсом.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал
указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу
метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом
405 (Method Not Allowed).
Кроме методов GET и HEAD, часто применяется метод POST.

24. Front WEB-server
Первое звено в инфраструктуре, которое обслуживает запрос
пользователя
Может быть много, один за одним (могут решать разные задачи)
Задача front web-сервера - обработать входящий запрос и решить, что с
ним делать дальше
На front web-сервер обычно ставяться быстрые web-сервера (максимально
быстрые) и универсальные (NGINX, lighttpd)

25. Front WEB-server
Общается с пользователем (решает проблему
медленных пользователей)
Способен сам отдавать статику из файловой системы
(картинки, css, js и т.д.) без участия какого либо
дополнительного кода

26. Application Server
Сервер на котором работает наше приложение
Взаимодействует с:
front web-сервером
базой данных
кешом
внешними API

27. Application Server
Включает в себя:
WEB-сервер (Apache) или Fast CGI (PHP-FPM)
Интерпретатор языка (наш код работает внутри
сервера)
Application (Динамика(PHP code, other code, binaries))
Компоненты Application сервера работают в связке, в
рамках единого процесса

28. Application (PHP-code)
Реализует какую-то логику
Взаимодействует с :
Базой данных
Внешними API
Кешом
Статическими файлами

29. Response (ответ)
1. Application возвращает ответ back серверу
2. Back сервер отдает ответ front серверу (по
протоколу HTTP либо Fastcgi)
3. Front сервер, по тому же соединению, по протоколу
HTTP либо SPDY отдает ответ клиенту
4. Клиент получает ответ и рендерит его в браузере

30. Архитектура
PHP приложения

31. Уровни абстракции
Код выполняющий какую-то одну операцию должен
находиться на одном уровне абстракции
Приложение должно разделяться на уровни, более
высокие уровни должны опираться на более низкие
Каждый уровень выполняет свою задачу и
предоставляет сервис для более высокого уровня

32. Компонентный подход
Приложение должно быть модульным
Разделять на модули необходимо в зависимости от реализации логики,
(например модуль работы с хранилищем данных, модуль бизнес-
логики)
Модули должны в рамках всего приложения (back-end application, front-
end application, storage, API Access Application)
Модули должны быть автономными
Модули должны взаимодействовать через API
Необходимо абстрагировать способ взаимодействия между

33. Front-end
Это часть приложения
Это сайт
Это один из способов доступа к back-end`у

34. Back-end
Это ядро приложения (логика приложения)
Интерфейсом beck-end`а может выступать:
API CLI (command line interface) - в данном случае front-end вообще не
нужен
API Access Interface - реализуется доступ к бизнес логики для front-end`а
либо API Access Application

35. Business logic
Это основная задача приложения:
Обработка данных
Логические преобразования
Алгоритмические вычисления
etc.
Сосредоточена в back-end application
Для реализации чаще всего используются MVC фреймворки

36. Persistence Logic
Реализация логики хранения информации
CRUD+ (Create, Read, Update, Delete + расширенные
возможности)
Что нужно сохранить, куда, когда и в каком виде

37. ORM, DBAL
Инструменты работы с хранилищем данных
Запись/чтение из конкретной сущности конкретного
хранилища
Абстракция над хранилищем
Логика преобразования объектов в данные которые
воспринимает хранилище