HTTPS и TCP/IP: уровни, протоколы и взаимодействие

HTTPS и TCP/IP — это не конкурирующие технологии и не разные названия одного и того же протокола. Они работают на разных уровнях: HTTPS отвечает за безопасную передачу веб-запросов, TCP — за надёжную доставку потока данных, а IP — за адресацию и перемещение пакетов между сетями. Чтобы понять, как открывается сайт и почему в адресной строке появляется значок замка, важно увидеть всю систему целиком.

HTTPS защищает содержимое общения, TCP обеспечивает надёжный канал передачи, а IP помогает пакетам найти путь до нужного устройства. Вместе эти протоколы образуют не один «суперпротокол», а согласованную цепочку сетевого взаимодействия.

Ниже разберём путь запроса от браузера до веб-сервера: где находится HTTP, какую роль играет TLS, зачем нужен порт 443, как TCP устанавливает соединение, почему IP не знает о веб-страницах и чем HTTPS отличается от FTP, FTPS и SFTP. В результате станет понятно, что происходит за доли секунды после ввода адреса сайта.

Иерархия знаний по HTTPS

Эта схема показывает, как тема HTTPS связана с другими материалами. Центральная статья объясняет взаимодействие HTTPS с TCP/IP, а соседние разделы раскрывают отдельные элементы: шифрование, порты, DNS, установку сертификата и проверку соединения.

HTTPS
├── HTTPS: что это такое, как работает и зачем нужен протокол
├── Как работает HTTPS: принцип работы, устройство и порядок соединения
├── HTTPS, SSL и TLS: как работает шифрование и защита данных
├── Порт HTTPS — 443: какой порт использует протокол и зачем он нужен
├── HTTPS и TCP/IP: уровни, протоколы и взаимодействие
├── Как подключить HTTPS к сайту: установка, настройка и переход с HTTP
├── DNS over HTTPS (DoH): что это такое, как работает и как настроить
├── Проверка HTTPS: как протестировать протокол и исправить ошибки
└── HTTPS, DNS, SSH, FTP и API: чем отличаются сетевые протоколы

Где находятся HTTP, HTTPS, TCP и IP в сетевой модели

Сетевая модель нужна не для красивой теории, а для разделения обязанностей. Каждый уровень решает свою задачу и передаёт результат следующему уровню. Благодаря этому браузеру не нужно самостоятельно управлять маршрутизацией, а IP не приходится разбираться в HTML.

Уровни сетевого взаимодействия

В упрощённом виде путь данных можно представить как несколько этажей. На верхнем этаже находятся приложения, ниже — механизмы доставки, ещё ниже — адресация и физическая передача сигналов.

Чаще всего используют модель TCP/IP из четырёх уровней. Её можно сопоставить с семиуровневой моделью OSI, но в повседневной практике достаточно понимать назначение каждого слоя.

Уровень TCP/IP	Основная задача	Примеры протоколов
Прикладной	Обмен данными между программами	HTTP, HTTPS, FTP, DNS, SSH
Транспортный	Доставка данных между процессами	TCP, UDP, QUIC
Межсетевой	Адресация и маршрутизация пакетов	IP, ICMP
Канальный	Передача по конкретному физическому или локальному каналу	Ethernet, Wi‑Fi

Прикладной, транспортный и сетевой уровни

HTTP и HTTPS относятся к прикладному уровню: они описывают, как браузер просит ресурс и как сервер отвечает. HTTPS обычно состоит из HTTP, работающего через защищённый слой TLS.

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

Протокол	Что он «понимает»	Чего он не понимает
HTTP	Методы, заголовки, URL, статус ответа	Маршруты между сетями
TLS	Сертификаты, ключи, шифрованные записи	Смысл HTML-страницы
TCP	Порты, номера последовательности, подтверждения	Логику HTTP-запроса
IP	IP-адреса и время жизни пакета	Содержимое соединения

Как протоколы разных уровней работают вместе

Когда браузер открывает сайт, он не отправляет HTTP напрямую в интернет. Сначала HTTP-данные передаются TLS, затем защищённый поток поступает в TCP, после чего TCP разбивает его на сегменты, а IP добавляет адреса источника и назначения.

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

Браузер: HTTP-запрос
↓
TLS: шифрование HTTP
↓
TCP: надёжная доставка потока
↓
IP: адресация пакетов
↓
Сеть: передача через маршрутизаторы

HTTP и HTTPS: что происходит на прикладном уровне

HTTP определяет язык общения браузера и веб-сервера. HTTPS использует тот же язык, но добавляет защиту TLS. Поэтому переход с HTTP на HTTPS обычно не меняет сам принцип работы веб-страницы: браузер по-прежнему отправляет запросы, а сервер по-прежнему возвращает ответы.

Как HTTP передаёт запросы и ответы

HTTP-запрос состоит из метода, адреса ресурса, заголовков и, иногда, тела. Например, метод GET используется для получения страницы, POST — для отправки данных формы.

Ответ сервера содержит код состояния, заголовки и тело. Код 200 означает успешную обработку, 404 — отсутствие ресурса, 500 — внутреннюю ошибку сервера.

GET /catalog/item HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Browser/1.0

Что меняется при использовании HTTPS

При обычном HTTP запрос передаётся в открытом виде. Это означает, что участник, способный перехватить трафик, может увидеть путь, параметры и содержимое запроса. HTTPS помещает HTTP внутрь защищённого TLS-соединения.

После установления TLS посторонний наблюдатель обычно видит IP-адрес сервера, факт соединения, объём и время передачи, но не содержание страницы и формы. Отдельные метаданные могут зависеть от версии протоколов и настроек шифрования.

Свойство	HTTP	HTTPS
Шифрование содержимого	Нет	Да, через TLS
Проверка подлинности сайта	Не предусмотрена	Сертификат подтверждает домен
Защита от изменения данных	Нет встроенной защиты	Есть проверка целостности
Типичный порт	80	443

Почему HTTPS не является отдельным транспортным протоколом

Название HTTPS можно мысленно раскрыть как HTTP over TLS — HTTP поверх TLS. TLS выполняет защитную функцию, но сам по себе не заменяет TCP в классической схеме.

Транспортным протоколом называют протокол, который организует доставку данных между приложениями. HTTPS описывает защищённое применение HTTP, поэтому относить его к транспортному уровню неправильно.

HTTP — содержание сообщения
TLS — защита сообщения
TCP — доставка потока
IP — доставка пакетов между сетями

HTTPS и TLS: как защищается HTTP-соединение

Главный механизм безопасности HTTPS — TLS. Он создаёт защищённый канал между клиентом и сервером, согласует параметры шифрования и проверяет, что клиент подключился именно к заявленному домену.

Что делает TLS

TLS решает три основные задачи: конфиденциальность, целостность и аутентификация сервера. Конфиденциальность скрывает содержание, целостность обнаруживает изменения, а аутентификация помогает не спутать настоящий сайт с поддельным.

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

Например, HTTPS не спасёт от слабого пароля, вредоносного расширения браузера или ошибки в логике интернет-магазина. Зато он существенно усложняет перехват данных в общественной Wi‑Fi-сети.

Установка защищённого соединения

В TLS 1.3 клиент и сервер обмениваются служебными сообщениями, выбирают криптографические параметры и формируют общий секрет. После этого прикладные данные шифруются симметричным алгоритмом.

Сертификат сервера содержит доменное имя и открытый ключ. Браузер проверяет цепочку доверия, срок действия, имя домена и ряд других параметров.

Этап TLS	Смысл	Результат
ClientHello	Клиент сообщает поддерживаемые возможности	Начало согласования
ServerHello	Сервер выбирает параметры	Общие настройки определены
Сертификат	Сервер подтверждает свою идентичность	Клиент проверяет домен и доверие
Общий секрет	Стороны получают ключи сессии	Можно шифровать трафик

Шифрование передаваемых данных

После рукопожатия TLS обычно использует симметричное шифрование: один набор ключей применяется для защиты данных в обе стороны. Оно значительно быстрее операций с асимметричными ключами.

Асимметричная криптография нужна главным образом для подтверждения стороны и согласования секрета. Использовать её для каждого байта большой страницы было бы примерно так же практично, как открывать каждый конверт сейфом.

Аутентификация сервера

Сертификат выпускается удостоверяющим центром или другой доверенной инфраструктурой. В нём указано, для какого домена он предназначен и каким открытым ключом владеет сервер.

Если сертификат просрочен, выпущен для другого домена или подписан недоверенным центром, браузер показывает предупреждение. Это не всегда означает атаку, но означает, что доверенное соединение не подтверждено.

Конфиденциальность и целостность данных

Шифрование скрывает содержимое от наблюдателя. Механизмы аутентификации сообщений позволяют обнаружить изменение зашифрованных данных по дороге.

Если злоумышленник попытается незаметно подменить часть ответа, проверка целостности должна завершиться ошибкой. Это важное отличие HTTPS от простого «перевода текста в непонятные символы».

Пользователь вводит пароль:
Браузер → TLS: шифрует данные
TLS → TCP: передаёт защищённый поток
Перехватчик видит набор зашифрованных байтов, а не пароль

HTTPS и TCP: как устанавливается транспортное соединение

До того как TLS начнёт обмен сообщениями, обычно устанавливается TCP-соединение. TCP создаёт двусторонний поток между конкретными портами клиента и сервера.

Что делает TCP

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

TCP не гарантирует, что сервер правильно обработает запрос. Он гарантирует лишь работу транспортного механизма: байты либо доставлены в согласованном порядке, либо соединение сообщает о проблеме.

Если веб-приложение возвращает ошибку 500, TCP не считает это своей неудачей. С точки зрения TCP сервер получил данные и отправил ответ.

Установка TCP-соединения

Классическая установка использует трёхэтапное рукопожатие: SYN, SYN-ACK и ACK. Клиент предлагает начать соединение, сервер подтверждает готовность, клиент подтверждает ответ сервера.

После этого стороны могут передавать данные. Само рукопожатие не шифрует содержимое: защиту добавляет следующий слой — TLS.

Сообщение	Отправитель	Назначение
SYN	Клиент	Запросить TCP-соединение
SYN-ACK	Сервер	Подтвердить запрос и предложить параметры
ACK	Клиент	Подтвердить получение ответа

Как TCP передаёт данные HTTPS

TLS формирует поток зашифрованных записей, а TCP видит этот поток как обычные байты. Если данных много, TCP делит их на сегменты подходящего размера.

На принимающей стороне TCP собирает сегменты обратно. Поэтому TLS и HTTP получают непрерывный поток, даже если IP-пакеты пришли разными маршрутами и в разное время.

Надёжность передачи

TCP использует подтверждения и таймеры. Если сегмент потерялся, отправитель повторяет его. Скорость передачи уменьшается или увеличивается в зависимости от состояния сети.

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

Порядок доставки данных

Каждый фрагмент получает номер последовательности. Получатель может принять сегменты в неправильном порядке, но передаст приложению данные только после восстановления правильной последовательности.

Именно поэтому HTTP не обязан самостоятельно разбираться с потерями отдельных TCP-сегментов.

Клиент: SYN
Сервер: SYN-ACK
Клиент: ACK
TCP-соединение установлено
Далее: TLS ClientHello → TLS ServerHello → HTTPS-запрос

HTTPS и IP: как данные находят нужный сервер

IP отвечает за межсетевую доставку. Он переносит пакеты от одного IP-адреса к другому через цепочку маршрутизаторов, но не знает, какую веб-страницу запросил пользователь.

Что делает IP

В IP-пакете находятся адрес отправителя, адрес назначения, информация о версии протокола и другие служебные поля. Маршрутизатор анализирует адрес назначения и выбирает следующий участок пути.

IP не гарантирует доставку, порядок или отсутствие дубликатов. Если нужен надёжный поток, эту работу выполняет TCP, а если нужна защита — TLS.

IP-адрес сервера

Доменное имя удобно человеку, а IP-адрес нужен сетевым устройствам. Один домен может иметь несколько IPv4- и IPv6-адресов для балансировки, отказоустойчивости и работы в разных регионах.

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

Параметр	Пример	Роль
Домен	example.com	Человеческое имя сервиса
IPv4	203.0.113.10	Адрес в сети IPv4
IPv6	2001:db8::10	Адрес в сети IPv6
Порт	443	Точка входа конкретного сервиса

Маршрутизация пакетов

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

Маршрутизаторы принимают решение по IP-адресу назначения. Они не устанавливают TLS и не интерпретируют HTML-ответ.

Домен: site.example
↓ DNS
IP: 203.0.113.25
↓
Домашний роутер
↓
Сеть провайдера
↓
Маршрутизаторы интернета
↓
Сеть дата-центра
↓
Сервер site.example

Как запрос к сайту проходит через TCP/IP

Открытие страницы — это цепочка последовательных действий. Некоторые из них могут повторно использоваться из кэша, поэтому при втором посещении сайт открывается быстрее.

От ввода адреса до отправки HTTP-запроса

Браузер разбирает URL: определяет схему HTTPS, доменное имя, порт и путь. Если порт явно не указан, для HTTPS используется стандартный порт 443.

Затем браузер проверяет локальные кэши, ищет IP и готовит сетевое соединение. При наличии уже открытого соединения часть шагов может быть пропущена.

DNS-разрешение имени

DNS сопоставляет имя домена с IP-адресом. Ответ может прийти из кэша браузера, операционной системы, роутера или DNS-резолвера.

Сам DNS обычно не устанавливает HTTPS-соединение с веб-сервером. Это отдельный протокол со своей задачей — найти адрес.

TCP-соединение

Клиент подключается к IP-адресу сервера и порту 443. После трёхстороннего рукопожатия TCP готов передавать поток.

Если порт закрыт, сервер недоступен или фильтрация блокирует соединение, TLS ещё не начнётся.

TLS-соединение

Клиент отправляет приветствие TLS, сервер отвечает параметрами и сертификатом. Браузер проверяет сертификат и согласует ключи.

Только после успешного завершения этого этапа можно безопасно передавать HTTP-запрос.

Передача HTTP-запроса

Браузер отправляет метод, путь и заголовки внутри зашифрованного TLS-потока. Сервер расшифровывает данные и передаёт запрос веб-приложению.

Приложение может обратиться к базе данных, проверить сессию, сформировать HTML или вернуть JSON.

Получение ответа от сервера

Ответ проходит обратный путь: приложение формирует HTTP-ответ, TLS шифрует его, TCP обеспечивает доставку, а IP переносит пакеты к клиенту.

Браузер расшифровывает данные, анализирует заголовки и отображает страницу. Дополнительные изображения, стили и скрипты могут породить новые запросы.

Шаг	Что происходит	Возможная проблема
DNS	Имя превращается в IP	Ошибка DNS, устаревшая запись
TCP	Создаётся поток на 443 порту	Тайм-аут, блокировка, отказ
TLS	Проверяется сертификат и создаются ключи	Просроченный сертификат
HTTP	Обрабатывается запрос	404, 403, 500

https://example.com/catalog
1. DNS: example.com → IP
2. TCP: соединение с IP:443
3. TLS: проверка сертификата
4. HTTP: GET /catalog
5. Ответ: 200 OK и содержимое страницы

HTTPS поверх TCP: классическая схема работы

Классический HTTPS строится по цепочке HTTP → TLS → TCP → IP. Такое представление помогает не смешивать функции протоколов.

Последовательность установления соединения

Сначала клиент узнаёт адрес сервера, затем устанавливает TCP, после этого проводит TLS-рукопожатие. HTTP начинается последним среди этих этапов.

На практике браузер может использовать постоянные соединения и повторно применять уже открытый канал, что сокращает задержки.

Что происходит с данными на каждом уровне

HTTP создаёт логическое сообщение, TLS превращает его в защищённые записи, TCP добавляет номера последовательности и подтверждения, а IP помещает сегменты в пакеты с адресами.

На сервере заголовки каждого уровня снимаются в обратном порядке. Такой процесс называется декапсуляцией.

Схема взаимодействия HTTP → TLS → TCP → IP

Слой	Добавляет	Что получает следующий слой
HTTP	Метод, путь, заголовки, тело	Прикладные данные
TLS	Шифрование и контроль целостности	Защищённый поток
TCP	Порты, номера, подтверждения	Сегмент
IP	Адреса источника и назначения	Пакет

HTTP:       GET / HTTP/1.1
TLS:        [зашифрованная запись]
TCP:        [порт 51524] → [порт 443]
IP:         [адрес клиента] → [адрес сервера]

FTP и TCP/IP: как работает передача файлов

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

Что такое FTP

FTP позволяет просматривать каталоги, загружать и скачивать файлы, переименовывать их и выполнять другие операции при наличии прав. В отличие от HTTP, FTP изначально создавался именно как файловый сервис.

Классический FTP передаёт команды и данные без встроенного шифрования, поэтому для современных систем его применяют осторожно.

Как FTP использует TCP

FTP традиционно использует отдельное соединение для команд и отдельное — для передачи данных. Командный канал часто работает на порту 21, а канал данных зависит от активного или пассивного режима.

Такая архитектура может создавать сложности с NAT и межсетевыми экранами. В пассивном режиме сервер сообщает клиенту порт, к которому тот должен подключиться для передачи данных.

Чем FTP отличается от HTTP и HTTPS

HTTP обычно обращается к ресурсам через URL и возвращает ответы в рамках веб-модели. FTP работает с файловой системой сервера и каталогами.

HTTPS лучше подходит для веб-страниц, API и безопасных форм, а FTP-подобные решения — для специализированного обмена файлами.

Характеристика	HTTP/HTTPS	FTP
Основное назначение	Веб-ресурсы и API	Файловые операции
Модель соединения	Запрос — ответ	Команды и отдельная передача данных
Стандартный порт	80/443	21 для команд
Шифрование	HTTPS использует TLS	У обычного FTP отсутствует

FTP-клиент
├── TCP-соединение: сервер:21
├── Команда: USER
├── Команда: PASS
├── Команда: LIST
└── Отдельное TCP-соединение для передачи данных

HTTPS и FTP: чем отличаются протоколы

Оба протокола могут передавать файлы, но это не делает их взаимозаменяемыми. Различаются назначение, модель взаимодействия, безопасность и требования к инфраструктуре.

Назначение HTTPS

HTTPS используется для сайтов, веб-приложений, REST- и GraphQL-API, авторизации, платежей и передачи данных между браузером и сервером.

Он хорошо интегрирован с браузерами, кэшированием, прокси, CDN и стандартными механизмами веб-разработки.

Назначение FTP

FTP ориентирован на управление файлами: список каталогов, загрузка, скачивание и удаление. Пользовательская модель FTP ближе к работе с удалённой папкой, чем к открытию веб-страницы.

Однако классический FTP плохо подходит для передачи паролей и конфиденциальных файлов в открытых сетях.

HTTPS, FTPS и SFTP: в чём разница

FTPS — это FTP с добавлением TLS. Он сохраняет модель FTP, включая командный и файловый каналы. SFTP — совсем другой протокол, работающий поверх SSH, а не «защищённый FTP» в техническом смысле.

Протокол	Основа	Типичное применение	Защита
HTTPS	HTTP + TLS	Сайты, API, веб-файлы	TLS
FTP	FTP + TCP	Старые файловые сервисы	Нет встроенной
FTPS	FTP + TLS	Совместимые файловые системы	TLS
SFTP	SSH	Администрирование и обмен файлами	SSH

Нужно открыть страницу или вызвать API → HTTPS
Нужно работать со старым FTP-сервисом → FTPS
Нужно безопасно передать файлы по SSH → SFTP
Не следует передавать пароль через открытый FTP → небезопасно

Как протоколы TCP/IP взаимодействуют между собой

Интернет работает именно благодаря разделению обязанностей. Протоколы можно заменять или развивать независимо, пока сохраняются правила взаимодействия между уровнями.

Роль каждого протокола

HTTP формирует смысл сообщения, TLS защищает его, TCP доставляет поток, IP направляет пакеты, а Ethernet или Wi‑Fi передают их на ближайшем участке сети.

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

Как данные передаются между уровнями

Верхний уровень передаёт данные нижнему вместе с инструкциями. Нижний уровень добавляет свой заголовок и не обязан понимать содержимое вложенной части.

На принимающей стороне каждый уровень удаляет собственную служебную информацию и передаёт полезную нагрузку выше.

Почему протоколы нельзя рассматривать изолированно

Если смотреть только на HTTPS, непонятно, как запрос доходит до сервера. Если смотреть только на IP, невозможно объяснить шифрование и проверку сертификата.

Полная картина появляется только при рассмотрении цепочки. Это особенно полезно при диагностике: ошибка DNS, TCP, TLS и HTTP требует разных способов исправления.

Симптом	Вероятный уровень	Что проверить
Домен не находится	DNS	Записи, резолвер, делегирование
Соединение истекает	TCP/IP	Маршрут, firewall, доступность порта
Ошибка сертификата	TLS	Срок, имя, цепочка сертификатов
404 или 500	HTTP/приложение	Маршруты и код сервера

Диагностика сайта:
DNS → найден ли IP?
TCP → открыт ли порт 443?
TLS → принят ли сертификат?
HTTP → какой код ответа?
Приложение → корректно ли обработан запрос?

Инкапсуляция данных: как формируется сетевой пакет

Инкапсуляция — это добавление служебных заголовков при движении данных вниз по стеку. Представьте посылку: товар помещают в коробку, коробку снабжают адресом, а затем отправляют через транспортную сеть.

Данные прикладного уровня

На верхнем уровне находятся HTTP-запрос или HTTP-ответ. В них есть метод, путь, заголовки и содержимое.

До TLS это понятные прикладные данные. После TLS они становятся зашифрованной нагрузкой, которую нельзя прочитать без ключей сессии.

Сегмент TCP

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

Порт 443 указывает на сервис HTTPS на сервере, но не является отдельным полем IP-адреса. Он находится в заголовке TCP.

IP-пакет

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

Передача по сети

На канальном уровне пакет помещается в кадр Ethernet или Wi‑Fi. После передачи через один участок кадр снимается, а следующий маршрутизатор формирует новый кадр для следующего участка.

Уровень	Единица данных	Что добавляется
HTTP/TLS	Данные или запись	Служебные поля приложения/шифрования
TCP	Сегмент	Порты и контроль доставки
IP	Пакет	IP-адреса
Ethernet/Wi‑Fi	Кадр	Локальные адреса канала

Внутри:
[IP-заголовок
  [TCP-заголовок
    [TLS-запись
      [HTTP-данные]
    ]
  ]
]

Что знает каждый протокол о передаваемых данных

Уровни стека намеренно ограничены. Чем ниже протокол, тем меньше он знает о смысле данных, зато тем универсальнее его применение.

Что знает HTTP

HTTP знает методы, URL-пути, заголовки, коды состояния, типы содержимого и правила кэширования. Он может определить, что клиент просит HTML или JSON.

HTTP не знает, через какие маршрутизаторы прошёл запрос и сколько TCP-сегментов потребовалось.

Что знает TLS

TLS знает, как договориться о ключах, проверить сертификат и защитить поток. Он не обязан понимать, является ли содержимое HTML, изображением или API-ответом.

Что знает TCP

TCP знает порты, последовательность байтов, подтверждения, окно приёма и состояние соединения. Для него зашифрованная TLS-запись — просто данные.

Что знает IP

IP знает адреса назначения и источника, размер пакета и параметры маршрутизации. Он не знает доменное имя, пароль, URL или код HTTP-ответа.

HTTP знает: «GET /account»
TLS знает: «данные зашифрованы»
TCP знает: «байты доставлены»
IP знает: «пакет направляется к адресу»

Как открывается cio-navigator.ru: полный путь запроса

Рассмотрим условный пример с доменом cio-navigator.ru. Конкретные IP-адреса и серверная архитектура могут меняться, но логика взаимодействия остаётся такой же.

Поиск IP-адреса через DNS

Браузер запрашивает DNS-запись домена. В ответ он получает IPv4- или IPv6-адрес, иногда несколько адресов.

Если запись отсутствует или домен не делегирован, до TCP-соединения дело не дойдёт.

Установка TCP-соединения

Клиент подключается к найденному адресу на порт 443. Сервер или балансировщик принимает SYN и отвечает подтверждением.

После завершения рукопожатия устанавливается двусторонний поток.

Установка TLS-соединения

Сервер предъявляет сертификат для домена. Браузер проверяет его и согласует с сервером ключи шифрования.

Если сертификат предназначен для другого имени, браузер предупредит пользователя, даже если TCP работает исправно.

Отправка HTTPS-запроса

Запрос к главной странице отправляется в зашифрованном виде. Внутри TLS может находиться обычный HTTP-запрос с путём «/».

Получение и обработка ответа

Сервер возвращает статус, заголовки и содержимое. Браузер затем может запросить таблицы стилей, скрипты, изображения, шрифты и данные API.

Фаза	Пример результата	Что означает сбой
DNS	198.51.100.20	Имя не сопоставлено с адресом
TCP	Connected to :443	Сервис недоступен на уровне транспорта
TLS	Certificate verified	Канал не подтверждён
HTTP	200 OK	Приложение ответило успешно

cio-navigator.ru
↓ DNS
IP-адрес
↓ TCP 443
TLS-сертификат
↓ HTTPS
GET /
↓
HTTP/1.1 200 OK

Какие данные передаются на каждом уровне

Одна и та же информация выглядит по-разному в зависимости от уровня наблюдения. Разработчик видит HTTP, администратор сети — TCP и IP, а система мониторинга TLS — параметры защищённого соединения.

HTTP-запрос и HTTP-ответ

До шифрования запрос может выглядеть как набор строк с методом, путём и заголовками. В HTTPS этот же логический запрос существует, но передаётся внутри зашифрованной TLS-записи.

TLS и зашифрованные данные

TLS скрывает тело запроса и ответа. При этом служебные характеристики соединения — например факт подключения и объём трафика — не обязательно исчезают полностью.

TCP-сегменты

TCP-сегмент содержит порты и поля управления доставкой. Он не содержит «HTML как таковой»: HTML находится внутри полезной нагрузки, которая для TCP является непрозрачным потоком байтов.

IP-пакеты

IP-пакеты несут адреса и фрагменты TCP-сегментов. Один HTTP-ответ может занимать десятки или тысячи пакетов.

Наблюдатель	Что обычно видит	Чего не видит без расшифровки
Маршрутизатор	IP-адреса и размеры пакетов	HTTP-содержимое
TCP-анализатор	Порты, порядок, потери	Смысл TLS-данных
TLS-инструмент	Сертификат и параметры шифрования	Содержимое без ключей
Браузер	HTTP и отображаемый ресурс	Необязательно видит внутреннюю маршрутизацию

HTTP-ответ: «страница»
↓ TLS
Зашифрованная запись
↓ TCP
Несколько сегментов
↓ IP
Множество пакетов
↓
Сеть

Сравнение HTTP, HTTPS, TCP, IP и FTP

Эти названия часто ставят в один ряд, хотя они относятся к разным задачам. Сравнение помогает увидеть, почему HTTPS нельзя заменить TCP, а IP нельзя использовать вместо HTTP.

Назначение протоколов

HTTP и FTP относятся к прикладным протоколам. TCP обеспечивает транспорт, IP — межсетевую доставку, а HTTPS объединяет HTTP с защитой TLS.

Уровень работы

Уровень определяет, какие проблемы решает протокол. Нельзя требовать от IP шифрования или от HTTP выбора маршрута: это не входит в их обязанности.

Используемые порты

Порт — это числовая точка входа в службу на конкретном устройстве. Он не заменяет IP-адрес и не является самостоятельным протоколом.

Шифрование и безопасность

Шифрование не определяется одним номером порта. Порт 443 обычно связан с HTTPS, но безопасность зависит от фактической конфигурации TLS и работающего сервиса.

Протокол	Уровень	Типичный порт	Основная задача	Шифрование
HTTP	Прикладной	80	Веб-запросы и ответы	Нет
HTTPS	Прикладной + TLS	443	Защищённый веб-обмен	Да
TCP	Транспортный	Нет одного порта	Надёжный поток	Нет
IP	Межсетевой	Нет	Адресация и маршрутизация	Нет
FTP	Прикладной	21	Работа с файлами	Нет в обычном виде

Если нужно:
показать веб-страницу → HTTP/HTTPS
надёжно доставить поток → TCP
найти путь между сетями → IP
управлять файлами → FTP/SFTP/FTPS

Распространённые ошибки и заблуждения о HTTPS и TCP/IP

Ошибки в терминологии часто приводят к ошибкам в настройке. Разберём наиболее распространённые представления, которые звучат правдоподобно, но технически неточны.

«HTTPS — это транспортный протокол»

Нет. HTTPS работает на прикладном уровне и использует TLS для защиты. В классической архитектуре ниже находятся TCP и IP.

Правильнее говорить: HTTPS — это защищённый вариант HTTP, обычно работающий через TLS поверх TCP.

«HTTPS всегда работает поверх TCP»

Для традиционного HTTPS с HTTP/1.1 и HTTP/2 — да, основой обычно является TCP. Но HTTP/3 использует QUIC, который работает поверх UDP и сам реализует многие транспортные функции.

Поэтому современная формулировка должна учитывать версию HTTP: HTTPS — это защищённый HTTP, а конкретный транспорт может отличаться.

«IP отвечает за доставку данных от программы к программе»

IP доставляет пакеты между сетевыми адресами, но не различает программы на одном устройстве. За разделение приложений отвечают порты транспортного уровня, например TCP или UDP.

«Порт 443 — это номер протокола HTTPS»

Порт 443 — стандартная точка входа для HTTPS, но это не определение протокола и не гарантия шифрования. На нём технически может работать другой сервис, а HTTPS можно настроить на нестандартном порту.

Заблуждение	Как правильнее
HTTPS сам доставляет пакеты	Доставкой занимаются транспортный и сетевой уровни
IP шифрует содержимое	Защиту обычно обеспечивает TLS
443 автоматически означает безопасность	Нужно проверить TLS и сертификат
FTP и SFTP — одно и то же	SFTP работает поверх SSH и является другим протоколом

Неверно: HTTPS = TCP = IP
Верно:
HTTPS → прикладной защищённый обмен
TCP → транспортный поток
IP → адресация пакетов

Частые вопросы о HTTPS и TCP/IP

Краткие ответы ниже помогают закрепить модель и быстро проверить, правильно ли выстроено понимание уровней.

HTTPS — это протокол какого уровня?

HTTPS относится к прикладному уровню. Технически это HTTP, передаваемый через TLS. TLS располагается между прикладным протоколом и транспортом.

Как связаны HTTPS и TCP?

В классической схеме TCP предоставляет HTTPS надёжный двусторонний поток. HTTPS передаёт через него защищённые TLS-записи, а TCP не анализирует их смысл.

Использует ли HTTPS IP?

Да. Чтобы добраться до сервера, соединение использует IPv4 или IPv6. Но HTTPS не управляет IP-маршрутизацией и не выбирает путь пакетов.

Может ли HTTPS работать без TCP?

Защищённый HTTP может использовать другой транспорт. HTTP/3 работает поверх QUIC, а QUIC — поверх UDP. В разговоре «HTTPS» часто имеют в виду классическую схему TCP, но архитектура веба уже не ограничивается только ею.

Вопрос	Короткий ответ
Где работает HTTPS?	На прикладном уровне, с TLS
Кто доставляет поток?	Обычно TCP
Кто направляет пакеты?	IP
Что делает порт 443?	Указывает стандартную точку входа HTTPS-сервиса
Всегда ли нужен TCP?	Нет, HTTP/3 использует QUIC поверх UDP

Проверка понимания:
HTTPS отвечает за защиту веб-обмена.
TCP отвечает за надёжный поток.
IP отвечает за адресацию.
Порт связывает соединение с нужным сервисом.

Итоги: как связаны HTTPS, TCP и IP

HTTPS, TCP и IP образуют последовательную систему, в которой каждый протокол выполняет свою работу. HTTPS формирует защищённое общение браузера и сервера, TLS шифрует и проверяет этот обмен, TCP доставляет поток байтов, а IP перемещает пакеты между сетями.

Классический путь выглядит так: браузер получает IP через DNS, устанавливает TCP-соединение с сервером на порту 443, проводит TLS-рукопожатие, отправляет HTTP-запрос и получает ответ. На обратном пути данные проходят те же уровни в противоположном направлении.

Понимание уровней превращает «магический замок в браузере» в понятную последовательность процессов: имя превращается в адрес, адрес ведёт к серверу, TCP создаёт поток, TLS защищает его, а HTTP передаёт смысл запроса.

Главное — не смешивать назначение протоколов. IP не шифрует, TCP не знает HTML, TLS не выбирает маршрут, а HTTPS не является заменой всей сетевой модели. Именно согласованная работа этих компонентов делает современный веб быстрым, совместимым и пригодным для безопасной передачи данных.