HTTP и TLS
Версии HTTP, заголовки, методы и коды статуса, виртуальные хосты и SNI, рукопожатие TLS, HSTS и mutual TLS, чтение падающего curl.
11 вопросов
JuniorТеорияОчень частоЧто происходит при TLS-рукопожатии и что проверяет валидация сертификата?
Что происходит при TLS-рукопожатии и что проверяет валидация сертификата?
Клиент шлёт hello с шифрами и именем хоста (SNI); сервер отвечает сертификатом; обе стороны выводят общий сеансовый ключ и переходят на шифрование. Валидируя сертификат, клиент проверяет цепочку до доверенного корневого CA, совпадение имени хоста с SAN и что серт не истёк.
Типичные ошибки
- ✗Считать, что сервер шлёт приватный ключ во время рукопожатия
- ✗Верить, что валидация проверяет лишь срок, а не цепочку и имя хоста
- ✗Полагать, что SNI шлётся шифрованным, а не в первом hello
Уточняющие вопросы
- →Почему имя хоста должно совпадать с SAN сертификата, а не с CN сегодня?
- →Что ломается, если сервер пропустит промежуточный сертификат в цепочке?
JuniorТеорияЧастоКакие заголовки HTTP-запроса и ответа важнее всего для оператора?
Какие заголовки HTTP-запроса и ответа важнее всего для оператора?
Host выбирает виртуальный хост; Content-Type задаёт формат тела; Cache-Control и ETag управляют кешированием; Connection отвечает за keep-alive. За обратным прокси X-Forwarded-For и X-Forwarded-Proto несут реальный IP и схему клиента, которых бэкенд иначе не увидит.
Типичные ошибки
- ✗Путать роли
HostиContent-Type - ✗Считать, что бэкенд видит реальный IP клиента без
X-Forwarded-For - ✗Думать, что
Connection: closeвключает keep-alive, а не завершает его
Уточняющие вопросы
- →Почему доверять
X-Forwarded-Forот любого источника опасно? - →Как
ETagиIf-None-Matchдают ответ 304 Not Modified?
JuniorТеорияЧастоКакие методы HTTP безопасны, а какие идемпотентны — GET, POST, PUT, DELETE?
Какие методы HTTP безопасны, а какие идемпотентны — GET, POST, PUT, DELETE?
Безопасные методы не меняют состояние сервера: GET и HEAD. Идемпотентные дают тот же результат при одном или повторном вызове: GET, HEAD, PUT и DELETE. POST — ни то ни другое: повтор может создать второй ресурс или списать дважды. Поэтому прокси может повторить GET или PUT, но не POST.
Типичные ошибки
- ✗Называть POST идемпотентным, потому что он часто проходит дважды
- ✗Считать, что безопасность и идемпотентность — одно свойство
- ✗Верить, что DELETE неидемпотентен, ведь повтор может дать 404
Уточняющие вопросы
- →Почему
DELETEидемпотентен, хотя повтор может вернуть 404? - →Как идемпотентность позволяет балансировщику безопасно повторить запрос?
JuniorТеорияЧастоЧто значат классы статусов HTTP 2xx/3xx/4xx/5xx — пример каждого?
Что значат классы статусов HTTP 2xx/3xx/4xx/5xx — пример каждого?
Первая цифра задаёт класс: 2xx успех (200), 3xx редирект (301 постоянный против 302 временного), 4xx ошибка клиента, чините запрос (404, 401 неаутентифицирован против 403 запрещено, 429 слишком много), 5xx сбой сервера (500). Класс говорит, на чьей стороне проблема.
Типичные ошибки
- ✗Менять местами ответственность 4xx (клиент) и 5xx (сервер)
- ✗Считать 401 (не аутентифицирован) и 403 (запрещено) одним и тем же
- ✗Путать 301 (постоянный) и 302 (временный) редиректы
Уточняющие вопросы
- →Почему 301 кешируется браузерами, а 302 обычно нет?
- →Когда API вернёт 403, а не 401, на один и тот же запрос?
MiddleТеорияЧастоЧто такое mutual TLS и когда его применять?
Что такое mutual TLS и когда его применять?
В обычном TLS только сервер доказывает личность. В mutual TLS (mTLS) клиент тоже предъявляет сертификат, поэтому обе стороны аутентифицируются. Нужен для трафика сервис-сервис без входа человека — внутренние сервисы, mesh — часто терминируется на шлюзе с перешифровкой до бэкенда.
Типичные ошибки
- ✗Считать, что mTLS лишь усиливает шифр, а не добавляет аутентификацию клиента
- ✗Применять mTLS к обычному браузерному трафику без клиентского серта
- ✗Полагать, что mTLS нельзя терминировать на шлюзе
Уточняющие вопросы
- →Как service mesh выдаёт и ротирует сертификаты mTLS автоматически?
- →Чем TLS termination отличается от TLS passthrough на балансировщике?
MiddleТеорияЧастоЧто такое цепочка сертификатов и как клиент проверяет доверие до корневого CA?
Что такое цепочка сертификатов и как клиент проверяет доверие до корневого CA?
Листовой серт сервера подписан промежуточным центром сертификации (CA), а тот — корневым CA, которому клиент доверяет: цепочка подписей. Клиент проверяет каждую подпись до доверенного корня и сроки. Сервер обязан прислать промежуточные; пропустит один — клиенты без него не достроят цепочку.
Типичные ошибки
- ✗Считать, что сервер шлёт лишь листовой, а остальное клиент качает сам
- ✗Верить, что самоподписанному листу доверяют без цепочки
- ✗Забывать, что пропущенный промежуточный ломает валидацию у многих клиентов
Уточняющие вопросы
- →Почему одни браузеры проходят, а другие падают при пропущенном промежуточном?
- →Как
openssl s_client -showcertsпоказывает неполную цепочку?
JuniorТеорияИногдаЧем различаются HTTP/1.0, 1.1, 2 и 3 — keep-alive, мультиплексирование, QUIC?
Чем различаются HTTP/1.0, 1.1, 2 и 3 — keep-alive, мультиплексирование, QUIC?
HTTP/1.0 открывал новое TCP-соединение на каждый запрос. 1.1 добавил keep-alive, но отдаёт ответы по порядку, поэтому один медленный блокирует остальные — head-of-line blocking. HTTP/2 мультиплексирует потоки в одном соединении; HTTP/3 идёт поверх QUIC на UDP, убирая блокировку транспортного уровня.
Типичные ошибки
- ✗Считать, что HTTP/2 открывает много соединений, а не мультиплексирует одно
- ✗Верить, что keep-alive был в 1.0 или что 1.1 мультиплексирует потоки
- ✗Полагать, что HTTP/3 работает на TCP, а не на QUIC поверх UDP
Уточняющие вопросы
- →Почему мультиплексирование HTTP/2 не убирает head-of-line blocking уровня TCP?
- →Что экономит переиспользование keep-alive-соединения на каждом запросе?
JuniorТеорияИногдаЧто такое виртуальный хост и как один IP обслуживает много разных сайтов?
Что такое виртуальный хост и как один IP обслуживает много разных сайтов?
Виртуальный хост даёт одному серверу (один IP и порт) обслуживать много сайтов, выбирая сайт по заголовку Host — name-based хостинг. Сервер сопоставляет имя хоста с блоком конфигурации. По HTTPS выбор делается раньше — по полю SNI в TLS, до отправки сертификата.
Типичные ошибки
- ✗Считать, что каждому сайту нужен свой выделенный IP-адрес
- ✗Верить, что заголовок
Hostнеобязателен при многих сайтах на одном IP - ✗Забывать, что HTTPS выбирает сайт по SNI до расшифровки
Уточняющие вопросы
- →Почему заголовок
Hostобязателен в HTTP/1.1, но не в 1.0? - →Как SNI раскрывает запрошенное имя хоста до начала шифрования?
MiddleДебаггингИногдаОбратный прокси всплесками выдаёт 502/503/504 — диагностируйте и почините
Обратный прокси всплесками выдаёт 502/503/504 — диагностируйте и почините
Каждый код — своя причина сбоя. 502 Bad Gateway — апстрим ответил некорректно или отказал в соединении (упал или не тот порт). 504 Gateway Timeout — апстрим принял, но не ответил в таймаут прокси (медленный/перегружен). 503 — здоровых бэкендов нет. Чините причину: бэкенд, таймаут или health-check.
Открыть задачу →Типичные ошибки
- ✗Путать 502 (плохой ответ) и 504 (таймаут апстрима)
- ✗Перезапускать прокси, когда сбой в апстриме
- ✗Считать 503 клиентской ошибкой, а не отсутствием здоровых бэкендов
Уточняющие вопросы
- →Какая настройка прокси чаще всего вызывает 504 под нагрузкой?
- →Как неверный health-check даёт 503 при живых pod-ах?
MiddleТеорияИногдаЧто такое HSTS и какую атаку он предотвращает?
Что такое HSTS и какую атаку он предотвращает?
HSTS (HTTP Strict Transport Security) — заголовок ответа Strict-Transport-Security, велящий браузеру ходить на домен только по HTTPS в течение max-age. После первого визита браузер отвергает HTTP и сам повышает запросы, предотвращая SSL-stripping — понижение посредником до HTTP.
Типичные ошибки
- ✗Считать, что HSTS сам шифрует трафик, а не принуждает к HTTPS
- ✗Верить, что он защищает самый первый визит без preload
- ✗Называть его заголовком запроса, а не ответа
Уточняющие вопросы
- →Почему preload-список HSTS важен для самого первого визита?
- →Чем рискован очень большой
max-ageво время выката?
MiddleДебаггингИногдаHTTPS отдаёт сертификат чужого сайта — диагностируйте SNI-несоответствие
HTTPS отдаёт сертификат чужого сайта — диагностируйте SNI-несоответствие
Много HTTPS-сайтов делят один IP и порт, поэтому сервер выбирает сертификат по полю SNI (имя хоста в client hello). Запрос без SNI (старый клиент, голый IP) получает серт хоста по умолчанию — отсюда несоответствие у таких клиентов. Фикс: слать SNI и сделать нужный сайт default server-блоком.
Открыть задачу →Типичные ошибки
- ✗Винить DNS или истёкший серт вместо выбора по SNI
- ✗Считать, что один IP навязывает единый общий сертификат всем сайтам
- ✗Забывать, что клиенты без SNI падают на хост по умолчанию
Уточняющие вопросы
- →Почему голый IP или очень старый клиент вызывает это, а браузеры нет?
- →Как server-блок по умолчанию меняет запасной сертификат?
