HTTPS-запрос: DNS, TCP, TLS и HTTP

Что показывает схема

Строка https://example.test/items не является одним протоколом. Для обычного HTTP/1.1 или HTTP/2 over TLS/TCP клиент последовательно разрешает hostname, устанавливает transport connection, создаёт защищённый TLS channel и только затем отправляет HTTP message. Каждая граница отвечает на свой вопрос и даёт доказательство разной силы.

Схема намеренно показывает вариант over TCP, потому что семестровая практика строится на C и Winsock. HTTP/3 переносит HTTP semantics через QUIC over UDP и меняет transport path; он не отменяет разделение name resolution, secure channel и application semantics.

Как читать компоненты

• Name resolution. Возвращает address candidates. Оно не открывает port и не проверяет certificate.
• TCP endpoint. Даёт reliable ordered byte stream между sockets. Успешный handshake доказывает reachability конкретного address/port в этот момент.
• TLS endpoint. Handshake аутентифицирует server side, согласует параметры и создаёт keys; record protocol защищает дальнейшие bytes по confidentiality и integrity.
• HTTP parser. Только после TLS decryption bytes становятся HTTP control data, fields и content.
• Route handler и state. Здесь начинается поведение приложения. HTTP status может быть сформирован самим origin, proxy или gateway — фиксируйте, кто именно ответил.

Три сценария

1. Успех. Запрос проходит все границы и ответ возвращается по тому же установленному пути без reverse topology edges.
2. Certificate failure. DNS и TCP уже сработали, но TLS identity не подтверждена. Отключать validation ради «проверки сети» нельзя.
3. HTTP 503. Secure channel существует, HTTP message разобран, но application boundary сообщает временный отказ. Это не повод называть инцидент «проблемой DNS».

Предсказание до запуска

Если TcpTestSucceeded=true, но client сообщает name mismatch, какой слой уже доказан? Transport connection. Какой слой сломан? Проверка TLS identity. Увидит ли server route handler HTTP method? Корректный client должен остановиться до отправки request.

Практика на C и Winsock

Winsock предоставляет TCP bytes, но сам по себе не реализует TLS или HTTP semantics. Учебный raw TCP client обязан сначала корректно пройти getaddrinfo(), socket() и connect(), а затем использовать выбранную библиотеку TLS или системный secure transport согласно заданию. Не отправляйте HTTP plaintext на port 443 через send() и не считайте полученные бинарные TLS records «непонятным HTTP».

Для каждого шага храните собственный result: EAI_* для resolution, WSA error для socket/connect, TLS alert и certificate validation result, HTTP status и response metadata. Сохраняйте WSAGetLastError() сразу после failed Winsock call — последующий cleanup способен изменить diagnostic context.

Evidence: что собирать

• hostname, address candidate, destination port и время;
• connect result для конкретного socket;
• negotiated TLS version, peer name и certificate validation result;
• HTTP method, target, status, request id и ответивший component;
• server-side log для того же request id, если HTTP request дошёл до приложения.

Границы модели и частые ошибки

• Port 443 может принять TCP и вернуть невалидный TLS; TCP success не равен HTTPS success.
• TLS encryption скрывает HTTP content от обычного on-path packet capture, но не скрывает все размеры и timings.
• HTTP 200 подтверждает HTTP response, а не корректность всех business invariants.
• HTTP 503 может прийти от edge proxy до origin. Нужны headers, request id и server evidence.

Контрольные вопросы

1. Почему certificate failure нельзя исправлять отключением validation?
2. Какой первый артефакт отличит TCP refusal от TLS alert?
3. Что изменится в transport part схемы для HTTP/3, а что останется application semantics?

Источники

• RFC 8446 — TLS 1.3
• RFC 9110 — HTTP Semantics
• Microsoft Learn — Winsock Client Application