HTTP/HTTPS: что это, протоколы передачи данных и TLS шифрование

Что такое HTTP и HTTPS?

HTTP (HyperText Transfer Protocol) — это протокол прикладного уровня модели OSI, предназначенный для передачи гипертекстовых документов и других данных в World Wide Web. Разработанный Тимом Бернерсом-Ли в 1989 году, HTTP прошёл несколько версий: от HTTP/0.9 (только GET-запросы и HTML-ответы) до современных HTTP/2 и HTTP/3. Протокол работает по схеме запрос-ответ: клиент отправляет запрос на сервер, сервер обрабатывает его и возвращает ответ.

HTTPS (HTTP Secure) — это расширение протокола HTTP, добавляющее уровень шифрования через TLS (Transport Layer Security). HTTPS не является отдельным протоколом — это комбинация HTTP и TLS. Данные, передаваемые через HTTPS, шифруются на стороне клиента и расшифровываются на сервере, что делает их недоступными для перехвата и подделки. HTTPS также обеспечивает аутентификацию сервера через SSL/TLS-сертификаты, гарантируя, что клиент подключается к настоящему серверу, а не к злоумышленнику.

Ключевое различие между HTTP и HTTPS — безопасность. HTTP передаёт данные в открытом виде: любой узел сети между клиентом и сервером может прочитать содержимое запроса или ответа. HTTPS шифрует всё содержимое, включая URL, заголовки и тело запроса, оставляя видимым только IP-адрес сервера и порт подключения. Для мобильных приложений, работающих через общественные Wi-Fi сети, HTTPS является обязательным требованием безопасности.

Как работает HTTP

HTTP — это протокол без сохранения состояния (stateless), работающий поверх TCP/IP. Клиент устанавливает TCP-соединение с сервером (обычно на порт 80 для HTTP или 443 для HTTPS), отправляет HTTP-запрос, получает HTTP-ответ и закрывает соединение (в HTTP/1.1 соединение может быть переиспользовано). Каждое взаимодействие между клиентом и сервером состоит из запроса и ответа. Отсутствие состояния означает, что сервер не хранит информацию о предыдущих запросах клиента — каждый запрос обрабатывается независимо.

Процесс HTTP-взаимодействия включает следующие шаги:

• DNS-resolve — браузер или клиент преобразует доменное имя в IP-адрес через DNS
• TCP-handshake — устанавливается TCP-соединение через трёхэтапное рукопожатие (SYN, SYN-ACK, ACK)
• TLS-handshake — для HTTPS дополнительно устанавливается шифрованное соединение (обмен сертификатами и ключами)
• HTTP-запрос — клиент отправляет метод, URL, заголовки и опционально тело запроса
• HTTP-ответ — сервер возвращает статус-код, заголовки и тело ответа

Важная характеристика HTTP — идемпотентность методов. GET, HEAD, PUT, DELETE и OPTIONS являются идемпотентными: многократное выполнение одного и того же запроса не меняет состояние сервера после первого выполнения. POST, PATCH и CONNECT не идемпотентны — каждый вызов может создавать новый ресурс или изменять состояние. Для мобильной разработки понимание идемпотентности критично: при повторной отправке запроса из-за ошибки сети клиент должен знать, безопасно ли повторить запрос.

HTTPS и TLS шифрование

HTTPS использует криптографический протокол TLS (Transport Layer Security) для защиты передаваемых данных. TLS — наследник SSL (Secure Sockets Layer), который был разработан компанией Netscape в 1995 году. Версии SSL 2.0 и 3.0 считаются устаревшими и небезопасными; современные версии TLS 1.2 (выпущен в 2008) и TLS 1.3 (выпущен в 2018) используются повсеместно. TLS 1.3, в частности, сокращает время установки соединения с 2 round-trips до 1, что значительно ускоряет загрузку на мобильных устройствах.

Процесс TLS-рукопожатия (handshake) включает следующие этапы:

• Client Hello — клиент отправляет список поддерживаемых версий TLS и наборов шифров
• Server Hello — сервер выбирает версию TLS и набор шифров, отправляет свой SSL/TLS-сертификат
• Проверка сертификата — клиент проверяет сертификат сервера через цепочку доверия до корневого CA
• Обмен ключами — клиент и сервер генерируют общий секретный ключ (сеансовый ключ)
• Switch Cipher — обе стороны подтверждают переход на шифрованное соединение

Проверка SSL/TLS-сертификата — критический этап для безопасности. Клиент проверяет, что сертификат: не истёк, подписан доверенным удостоверяющим центром (CA), соответствует домену в URL и не отозван (через CRL или OCSP). В мобильных приложениях рекомендуется использовать Certificate Pinning — привязку к конкретному сертификату или публичному ключу сервера. Это предотвращает MITM-атаки даже в случае компрометации CA. Однако pinning требует осторожности: при смене сертификата приложение должно быть заранее обновлено.

Структура HTTP запроса и ответа

HTTP-запрос состоит из трёх частей: стартовая строка (request line), заголовки (headers) и опциональное тело (body). Стартовая строка содержит HTTP метод, URL запроса и версию HTTP. Заголовки передают мета-информацию: тип контента, аутентификационные токены, настройки кэширования. Тело присутствует только в методах, передающих данные (POST, PUT, PATCH), и отсутствует в GET и DELETE.

Пример HTTP-запроса к REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Анна",
    "email": "anna@example.com"
}

HTTP-ответ имеет аналогичную структуру: стартовая строка с версией HTTP и статус-кодом, заголовки и тело. Статус-код — трёхзначное число, определяющее результат обработки запроса. Заголовки ответа включают Content-Type, Content-Length, Cache-Control, Set-Cookie и другие. Тело ответа содержит запрошенные данные в формате, указанном в Content-Type (обычно JSON для API, HTML для веб-страниц, изображения для медиа-контента).

Заголовки играют критическую роль в работе HTTP. Content-Type и Accept управляют форматом данных. Authorization передаёт токены доступа. Cache-Control управляет кэшированием. CORS-заголовки (Access-Control-Allow-Origin) контролируют доступ с других доменов в браузерах. User-Agent идентифицирует клиентское приложение. Для мобильных приложений особенно важны заголовки управления кэшированием — они позволяют сократить объём передаваемых данных и улучшить работу при слабом сигнале.

Коды состояния HTTP

Коды состояния HTTP группируются по пяти классам, обозначаемым первой цифрой: 1xx (информационные), 2xx (успех), 3xx (перенаправление), 4xx (ошибка клиента), 5xx (ошибка сервера). Понимание этих кодов необходимо для корректной обработки ответов в мобильном приложении: 2xx означает успех и данные можно отображать, 4xx указывает на проблему в запросе (нужно показать ошибку пользователю), 5xx — на проблему на сервере (нужно повторить запрос позже).

Для мобильных приложений особое значение имеет обработка кода 401 Unauthorized. При получении этого кода клиент должен попытаться обновить токен доступа через Refresh Token и повторить исходный запрос. Если обновление токена также возвращает 401, пользователя необходимо перенаправить на экран входа. Эта логика обычно реализуется в Interceptor (OkHttp) или в middleware слое сетевого клиента.

HTTP/1.1, HTTP/2 и HTTP/3

HTTP/1.1, опубликованный в 1999 году, до сих пор остаётся широко используемой версией протокола. Его главный недостаток — head-of-line blocking: запросы к одному серверу выполняются последовательно, каждый следующий ждёт завершения предыдущего. Для обхода этого ограничения браузеры открывают 6-8 параллельных TCP-соединений к одному домену, что увеличивает нагрузку на сервер и потребление памяти. HTTP/1.1 также передаёт заголовки в незашифрованном виде и не поддерживает серверный push.

HTTP/2 (2015) решает проблему блокировки через мультиплексирование — множество потоков данных передаются по одному TCP-соединению одновременно. Сервер может отправлять ресурсы клиенту до того, как клиент их запросит (server push). HTTP/2 также сжимает заголовки через HPACK, что уменьшает объём передаваемых данных. Для мобильных приложений HTTP/2 особенно полезен: одно соединение заменяет несколько, сокращая время TLS-рукопожатия и потребление батареи.

HTTP/3 (2022) — последняя версия протокола, которая использует QUIC (Quick UDP Internet Connections) вместо TCP. QUIC работает поверх UDP, устраняя проблему head-of-line blocking на уровне транспортного протокола. HTTP/3 сокращает время установки соединения до 0 round-trips в лучшем случае (на повторных подключениях) и до 1 round-trip при первом подключении, что значительно быстрее HTTP/2 с его 2-3 round-trips. Для мобильных устройств HTTP/3 особенно эффективен при переключении между Wi-Fi и мобильной сетью — соединение не разрывается, так как QUIC использует идентификатор соединения, а не IP-адрес.

HTTPS в мобильной разработке

Использование HTTPS в мобильных приложениях — не рекомендация, а обязательное требование. Начиная с Android 9 (API 28) и iOS 9 (ATS — App Transport Security), все сетевые запросы по умолчанию должны использовать HTTPS. HTTP-запросы блокируются системой, и для их разрешения требуется явное исключение в конфигурации приложения. Google Play Store и App Store отклоняют приложения, передающие конфиденциальные данные по HTTP, включая пароли, токены и персональные данные.

Конфигурация HTTPS в мобильном приложении на Android включает:

<!-- AndroidManifest.xml — разрешение на сетевые запросы -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — настройка HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

На iOS аналогичная настройка выполняется через Info.plist с ключом NSAppTransportSecurity. Для отладки HTTPS-трафика в мобильных приложениях используются прокси-инструменты: Charles Proxy, Proxyman или mitmproxy. Они требуют установки доверенного SSL-сертификата на устройство. В продакшн-сборках необходимо отключать возможность отладки и проверять, что Certificate Pinning настроен корректно. Использование OkHttp на Android с его CertificatePinner или TrustManager на iOS с SecTrustEvaluate — стандартные подходы для реализации pinning.

Важный аспект безопасности HTTPS в мобильной разработке — SSL Pinning. Без pinning приложение доверяет любому сертификату, подписанному известным CA. Если CA будет скомпрометирован, злоумышленник сможет перехватывать трафик приложения. Pinning привязывает приложение к конкретному сертификату или публичному ключу сервера. При смене сертификата на сервере необходимо выпустить обновление приложения, поэтому pinning планируют с запасом — привязываются к сертификату вышестоящего CA или используют несколько запасных ключей.