2.4. Протокол взаимодействия

Набор правил, по которым общаются клиент и сервер. Определяет формат сообщений, последовательность обмена, обработку ошибок.

Примеры протоколов:

• HTTP/HTTPS — для веб-сервисов.

• FTP — для передачи файлов.

• SMTP/POP3/IMAP — для электронной почты.

• TDS — для Microsoft SQL Server.

• Протоколы собственной разработки (для специфичных систем).

3. Принцип работы клиент-серверной системы

1. Сервер запускается и начинает прослушивать определённый порт, ожидая входящие соединения.

2. Клиент инициирует соединение с сервером, используя его адрес (IP-адрес или доменное имя) и порт.

3. Клиент формирует запрос в соответствии с протоколом и отправляет его серверу.

4. Сервер принимает запрос, обрабатывает его (выполняет бизнес-логику, обращается к базе данных, файловой системе или другим серверам).

5. Сервер формирует ответ и отправляет его клиенту.

6. Клиент получает ответ и обрабатывает его (отображает данные пользователю, сохраняет, запускает дальнейшие действия).

7. Соединение может быть закрыто (для протоколов без сохранения состояния, как HTTP) или оставаться открытым для последующих запросов.

4. Типы клиент-серверных архитектур

В зависимости от того, как распределены функции (представление, бизнес-логика, управление данными), выделяют несколько моделей.

4.1. Двухуровневая архитектура (2-tier)

В этой модели система делится на два уровня:

• Клиент (уровень представления) — отвечает за интерфейс и часть бизнес-логики.

• Сервер (уровень данных) — отвечает за хранение и управление данными (СУБД).

Варианты:

• Тонкий клиент — на клиенте только интерфейс, вся бизнес-логика на сервере (в хранимых процедурах). Клиент подключается к БД напрямую.

• Толстый клиент — на клиенте и интерфейс, и бизнес-логика. Сервер только хранит данные.

Пример: Приложение на Delphi или Visual Basic, подключающееся напрямую к базе данных (Oracle, MSSQL).

Плюсы: Простота, высокая производительность (если клиент "толстый"). Минусы: Сложность обновления (нужно обновлять каждого клиента), проблемы с безопасностью (прямой доступ к БД), масштабирование ограничено.

4.2. Трёхуровневая архитектура (3-tier)

Система разделена на три логических уровня:

1. Клиентский уровень (Presentation Tier) — интерфейс пользователя (веб-браузер, мобильное приложение). Взаимодействует только со следующим уровнем.

2. Уровень приложений (Application Tier / Business Logic Tier) — сервер приложений, на котором реализована бизнес-логика. Принимает запросы от клиентов, обрабатывает их, при необходимости обращается к уровню данных.

3. Уровень данных (Data Tier) — сервер баз данных, который хранит данные и управляет ими.

Пример: Веб-приложение: браузер (клиент) → веб-сервер с приложением (Tomcat, Django, Node.js) → СУБД (PostgreSQL).

Плюсы:

• Масштабируемость (каждый уровень можно масштабировать независимо).

• Безопасность (клиент не имеет прямого доступа к БД).

• Лёгкость обновления (достаточно обновить сервер приложений).

• Возможность использовать разные клиенты (веб, мобильные) с одним сервером.

Минусы: Сложнее в разработке и развёртывании, выше задержки (из-за дополнительного уровня).