Лекция 2. Сетевые основы и архитектура веб-приложений

Введение

Любое интернет-приложение — это прежде всего обмен данными по сети между клиентом и сервером. Прежде чем писать обработчики запросов на FastAPI, важно понимать, как байты доходят от браузера до вашего Python-кода и обратно: какие уровни сети участвуют в передаче, что гарантирует доставку, что такое порт и сокет и почему HTTP «живёт» поверх TCP.

Эта лекция — обзорная. Мы строим общую картину сетевого взаимодействия, на которую в следующих лекциях будут «навешиваться» детали: подробный разбор HTTP (методы, заголовки, коды состояния) — тема лекции 3.

План лекции: сетевые модели OSI и TCP/IP; инкапсуляция данных; транспортный уровень (TCP, UDP, кратко SCTP); порты и сокеты; HTTP поверх TCP; клиент-серверное взаимодействие в вебе.

1. Сетевые модели

Чтобы описать сложный процесс передачи данных, его разбивают на уровни (layers). Каждый уровень решает свою задачу и «не знает», как устроены соседние, — он лишь пользуется услугами уровня ниже и предоставляет услуги уровню выше. Такой подход называется разделением ответственности и делает сети модульными: можно заменить Wi-Fi на Ethernet, не переписывая браузер.

Существуют две ключевые модели: теоретическая OSI (7 уровней) и практическая TCP/IP (4 уровня), на которой реально работает Интернет.

1.1. Модель OSI (Open Systems Interconnection)

Модель OSI разработана Международной организацией по стандартизации (ISO) в 1984 году как эталонная схема. На практике в чистом виде она не реализована, но её терминологию используют повсеместно (особенно «уровень 7», «уровень 3» и т. д.).

№	Уровень	Назначение	Примеры протоколов	Единица данных
7	Прикладной (Application)	Интерфейс сетевых служб для приложений	HTTP, HTTPS, DNS, SMTP, FTP	Данные / сообщения
6	Представления (Presentation)	Кодирование, сжатие, шифрование	TLS/SSL, JPEG, ASCII	Данные
5	Сеансовый (Session)	Управление сессиями диалога	RPC, NetBIOS	Данные
4	Транспортный (Transport)	Сквозная доставка между процессами	TCP, UDP, SCTP	Сегменты / датаграммы
3	Сетевой (Network)	Логическая адресация и маршрутизация	IP, ICMP, OSPF	Пакеты
2	Канальный (Data Link)	Передача между соседними узлами	Ethernet, Wi-Fi, PPP	Кадры
1	Физический (Physical)	Передача битов по среде	Ethernet, Wi-Fi, Bluetooth	Биты

Для нас как backend-разработчиков важнее всего верхушка: уровни 7 (приложение) и 4 (транспорт).

1.2. Модель TCP/IP

Модель TCP/IP появилась раньше OSI (в рамках проекта ARPANET, 1970-е) и стала фактическим стандартом Интернета. Она содержит четыре уровня и объединяет несколько уровней OSI в один.

Уровень TCP/IP	Соответствие OSI	Примеры протоколов	Функции
Прикладной (Application)	5–7	HTTP, HTTPS, WebSocket, gRPC, DNS	Формат и семантика обмена данными
Транспортный (Transport)	4	TCP, UDP, SCTP	Сквозная доставка между процессами
Сетевой / Интернет (Internet)	3	IP (IPv4/IPv6), ICMP	Адресация и маршрутизация пакетов
Канальный (Link)	1–2	Ethernet, Wi-Fi, ARP	Физическая передача в локальной сети

Важно для разработчика веб-приложений. Из всей этой иерархии нас прежде всего интересуют два верхних уровня TCP/IP:

транспортный (TCP, UDP) — отвечает за надёжность и доставку данных нужному процессу;

прикладной (HTTP, WebSocket, gRPC) — определяет формат и смысл передаваемых сообщений.

Маршрутизацией пакетов и физической средой занимаются ОС, сетевое оборудование и провайдеры — нам не нужно программировать эти уровни.

2. Инкапсуляция данных

Инкапсуляция — это механизм, который связывает уровни между собой. Когда приложение отправляет данные, они проходят сверху вниз по уровням, и на каждом к ним добавляется свой служебный заголовок (header) с информацией, необходимой именно этому уровню.

Путь данных при отправке (упрощённо, для веб-запроса):

Прикладной:   [ HTTP-сообщение ]                       ← данные приложения
Транспортный: [ TCP-заголовок | HTTP-сообщение ]        ← сегмент
Сетевой:      [ IP | TCP | HTTP-сообщение ]             ← пакет
Канальный:    [ Ethernet | IP | TCP | HTTP | CRC ]      ← кадр → биты в провод

На принимающей стороне происходит обратный процесс — декапсуляция: каждый уровень «снимает» свой заголовок, обрабатывает его и передаёт оставшиеся данные наверх. В итоге серверное приложение получает ровно то HTTP-сообщение, которое отправил клиент, не зная подробностей о маршруте и кадрах. Ключевая идея: каждый уровень общается со своим «коллегой» на другой стороне (TCP на клиенте — с TCP на сервере, IP с IP) через свой заголовок и не вмешивается в данные чужих уровней.

3. Транспортный уровень

Транспортный уровень обеспечивает сквозную (end-to-end) доставку данных между процессами на разных хостах. Именно здесь решается главный вопрос: нужна ли гарантированная доставка или важнее минимальная задержка. Два основных протокола — TCP и UDP.

3.1. TCP (Transmission Control Protocol)

TCP — надёжный протокол с установлением соединения. Он гарантирует, что данные дойдут полностью, без потерь и в правильном порядке.

Основные механизмы TCP:

Подтверждения (ACK) — получатель сообщает, что данные дошли; неподтверждённые данные передаются повторно.
Контрольная сумма — обнаружение повреждённых сегментов.
Упорядочивание — сегменты собираются в исходном порядке, даже если пришли вразнобой.
Управление потоком (скользящее окно) и управление перегрузкой — отправитель не «затопляет» ни получателя, ни сеть.

Установление соединения — «тройное рукопожатие» (three-way handshake):

SYN — клиент запрашивает соединение и сообщает начальный номер последовательности.
SYN-ACK — сервер подтверждает и присылает свой номер.
ACK — клиент подтверждает; соединение установлено.

Завершение соединения симметрично и использует флаги FIN/ACK (так называемое четырёхэтапное закрытие).

Где применяется TCP: веб (HTTP/HTTPS), электронная почта (SMTP, IMAP), передача файлов, базы данных, SSH — везде, где корректность данных важнее скорости.

3.2. UDP (User Datagram Protocol)

UDP — простой протокол без установления соединения и без гарантий доставки. Он лишь отправляет независимые датаграммы и не следит за тем, дошли ли они.

Особенности UDP:

Минимальный заголовок (8 байт) и почти отсутствие накладных расходов.
Нет соединения — можно сразу отправлять данные.
Нет подтверждений, повторов и упорядочивания — пакеты могут теряться, дублироваться или приходить не по порядку.
Низкая задержка — главное преимущество.

Где применяется UDP: потоковое видео и аудио, видеоконференции (WebRTC), онлайн-игры, DNS-запросы, телеметрия и мониторинг (SNMP) — везде, где задержка критичнее, чем потеря отдельного пакета. Если небольшая часть данных потеряна, проще пропустить её, чем ждать повторной передачи.

3.3. TCP vs UDP — сравнение

Характеристика	TCP	UDP
Соединение	С установлением (handshake)	Без установления
Надёжность доставки	Гарантирована (ACK, повторы)	Не гарантирована
Порядок данных	Сохраняется	Не гарантируется
Контроль потока/перегрузки	Есть	Нет
Размер заголовка	20+ байт	8 байт
Задержка	Выше	Минимальная
Применение	Веб, почта, БД, файлы	Стриминг, игры, DNS, RTC

3.4. SCTP (Stream Control Transmission Protocol) — кратко

SCTP — современный транспортный протокол, который сочетает надёжность TCP с дополнительной гибкостью. Кратко его особенности:

Мультипотоковость (multistreaming) — несколько независимых потоков в одном соединении, что устраняет проблему «блокировки головы очереди».
Частично упорядоченная доставка — порядок можно требовать не для всех сообщений.
Multi-homing — соединение может использовать несколько IP-адресов узла для отказоустойчивости.
Защита от SYN-flood атак за счёт механизма cookie при установлении соединения.

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

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

4. Порты и сокеты

IP-адрес определяет хост (компьютер) в сети, но на одном хосте одновременно работает множество сетевых программ: веб-сервер, почтовый сервер, база данных. Чтобы данные попали именно нужной программе, используется порт.

Порт — это 16-битное число (0–65535), идентифицирующее конкретный процесс (службу) на хосте.
Известные порты (well-known): 80 — HTTP, 443 — HTTPS, 22 — SSH, 53 — DNS, 5432 — PostgreSQL.
При локальной разработке FastAPI-приложение часто запускают на порту 8000 (http://127.0.0.1:8000).

Сокет (socket) — это «точка подключения», однозначно определяющая конец соединения. Сетевое соединение TCP описывается парой сокетов:

( IP-адрес клиента : порт клиента )  ⇆  ( IP-адрес сервера : порт сервера )
например: (192.168.1.50 : 53711)    ⇆  (93.184.216.34 : 443)

Сокет на стороне сервера обычно «слушает» (listen) известный порт и ждёт входящих подключений; порт клиента назначается операционной системой динамически. Для программиста сокет — это программный интерфейс (API операционной системы), через который приложение отправляет и принимает байты. Веб-фреймворки и ASGI-серверы (например, Uvicorn под FastAPI) скрывают работу с сокетами, но «под капотом» именно сокеты переносят HTTP-данные.

5. HTTP поверх TCP (обзор)

HTTP (HyperText Transfer Protocol) — это прикладной протокол, на котором строится Всемирная паутина и большинство веб-API. Ключевая мысль данной лекции:

HTTP — это протокол прикладного уровня, который работает поверх TCP (транспортный уровень). TCP обеспечивает надёжный канал передачи байтов, а HTTP определяет, что эти байты означают: запрос, ответ, метод, заголовки, тело.

Что нужно знать о HTTP уже сейчас (детали — в лекции 3):

HTTP построен по модели запрос-ответ: клиент отправляет запрос, сервер возвращает ответ. Сервер сам никогда не инициирует обмен.
Прежде чем отправить HTTP-запрос, клиент устанавливает TCP-соединение (handshake), а для HTTPS — ещё и защищённый TLS-канал поверх TCP.
HTTPS = HTTP + TLS: шифрование, проверка подлинности сервера и целостность данных. TLS располагается между TCP и HTTP.

Коротко об эволюции версий: HTTP/1.1 — текстовый протокол с постоянными соединениями (keep-alive); HTTP/2 — бинарный, с мультиплексированием запросов в одном TCP-соединении и сжатием заголовков; HTTP/3 — работает поверх QUIC (а QUIC — поверх UDP), что снижает задержки и повышает устойчивость к потерям пакетов.

Кроме «классического» HTTP, для особых задач существуют родственные протоколы: WebSocket — постоянное двустороннее соединение поверх TCP (открывается через HTTP-механизм Upgrade; чаты, real-time уведомления); gRPC — RPC-фреймворк поверх HTTP/2 с бинарным форматом Protocol Buffers (общение между микросервисами).

6. Клиент-серверное взаимодействие в вебе

Сложим всё вместе и проследим, что происходит, когда пользователь открывает страницу или приложение обращается к API. Это «карта», по которой мы будем двигаться весь курс.

Участники: клиент (браузер, мобильное приложение или другой сервис — инициирует запросы), сервер (принимает запросы, выполняет логику, обращается к базе данных, формирует ответы) и промежуточные узлы (DNS-серверы, прокси, балансировщики нагрузки, CDN).

Упрощённый жизненный цикл запроса:

DNS-резолюция. Доменное имя (shop.example.com) преобразуется в IP-адрес.
Установление TCP-соединения. Три рукопожатия (SYN → SYN-ACK → ACK).
TLS-рукопожатие (для HTTPS). Согласование шифрования, проверка сертификата сервера.
Отправка HTTP-запроса. Клиент формирует строку запроса, заголовки и при необходимости тело; данные инкапсулируются в TCP/IP и уходят в сеть.
Обработка на сервере. Парсинг запроса → маршрутизация к нужному обработчику → аутентификация/авторизация → бизнес-логика → запрос к базе данных → формирование ответа. В FastAPI этот этап — ваши функции-обработчики.
Отправка HTTP-ответа. Сервер возвращает код состояния, заголовки и тело (чаще всего JSON для API).
Обработка на клиенте. Парсинг ответа, обновление интерфейса (для браузера — рендеринг), либо дальнейшая обработка данных.

Именно этот цикл лежит в основе любого веб-приложения на FastAPI: фреймворк отвечает за этапы 5–6 (приём запроса и формирование ответа), а транспорт, инкапсуляцию и сокеты обеспечивают ASGI-сервер и операционная система.

Краткие итоги

Сетевое взаимодействие разбивают на уровни; теоретическая модель — OSI (7 уровней), практическая — TCP/IP (4 уровня).
Для backend-разработчика важнее всего два верхних уровня TCP/IP: транспортный и прикладной.
Инкапсуляция — добавление служебных заголовков на каждом уровне при отправке; декапсуляция — их снятие при приёме.
TCP — надёжный протокол с соединением, подтверждениями и упорядочиванием; основа веба. UDP — быстрый протокол без гарантий, для real-time задач. SCTP сочетает надёжность с мультипотоковостью и multi-homing.
Порт идентифицирует процесс на хосте; сокет (пара IP:порт с двух сторон) определяет конец соединения.
HTTP работает поверх TCP по модели запрос-ответ; HTTPS = HTTP + TLS. HTTP/3 использует QUIC поверх UDP.
Веб строится на клиент-серверном взаимодействии; типичный путь запроса: DNS → TCP → (TLS) → HTTP-запрос → обработка на сервере → HTTP-ответ.

Вопросы для самопроверки

Чем модель OSI отличается от модели TCP/IP? Сколько уровней в каждой?
Какие два уровня модели TCP/IP наиболее важны для разработчика веб-приложений и почему?
Что такое инкапсуляция и декапсуляция данных? Что добавляется на каждом уровне?
Перечислите ключевые механизмы, которые делают TCP надёжным протоколом.
Опишите этапы тройного рукопожатия TCP.
В каких случаях предпочтительнее UDP, а в каких — TCP? Приведите примеры.
Какие особенности SCTP отличают его от TCP?
Чем порт отличается от IP-адреса? Что такое сокет и какой парой он определяется?
Почему говорят, что HTTP работает «поверх TCP»? Где в этой схеме находится TLS?
Опишите жизненный цикл HTTP-запроса от ввода адреса до получения ответа.