HTTP и веб-протоколы

HTTP выглядит обманчиво простым — текстовая строка запроса, заголовки key: value, пустая строка и тело. Из-за этой простоты его учат как набор аббревиатур и проваливаются на первом же вопросе «что произошло между нажатием Enter и приходом ответа». Настоящий предмет темы — стек: имя резолвится в адрес через DNS, ядро открывает сокет, TCP устанавливает соединение трёхсторонним рукопожатием, TLS договаривается о ключах, и только поверх всего этого едет текст HTTP. Каждый уровень решает ровно одну задачу и передаёт наверх свою абстракцию — сломайте цепочку в любом месте, и симптом проявится совсем не там, где причина.

Python удобен тем, что стандартная библиотека выставляет каждый уровень отдельно: socket — сырой транспорт, ssl — рукопожатие и проверку сертификата, http.client — разбор сообщения, urllib.request — редиректы и политику клиента, wsgiref — серверную сторону. Любое утверждение из теории проверяется руками за пять строк. Четыре ловушки назовём сразу. Первая — путаница между безопасностью и идемпотентностью: GET безопасен, PUT и DELETE идемпотентны, но не безопасны, а POST не является ни тем, ни другим. Вторая — 301 против 307: коды различаются не только «постоянством», но и правом клиента поменять метод. Третья — HTTPS шифрует тело и заголовки, но не прячет ни IP, ни имя хоста в SNI. Четвёртая — REST это набор архитектурных ограничений, а не «JSON по HTTP».

Карта темы

• Сетевой стек — какой уровень за что отвечает и что на самом деле происходит от curl до ответа сервера.
• Сокеты — сокет как конечная точка транспорта и файловый дескриптор, SOCK_STREAM против SOCK_DGRAM.
• TCP — трёхстороннее рукопожатие, нумерация сегментов, ACK, переотправка, скользящее окно и контроль перегрузки.
• UDP — датаграмма без соединения и подтверждений, и почему её выбирают DNS, видео и игры.
• DNS — порядок разрешения имени, типы записей, TTL и откат с UDP/53 на TCP.
• Протокол HTTP — текст, отсутствие состояния, стартовая строка, заголовки, пустая строка и тело.
• Методы HTTP — семантика методов и главное различие темы, safe против idempotent.
• Коды состояния — смысл в первой цифре, и почему валидация это 4xx, а не 5xx.
• Редиректы — Location плюс 3xx, и чем 301, 302, 307 и 308 отличаются по методу.
• Кэширование — свежесть по Cache-Control против ревалидации по валидатору.
• ETag и условные запросы — If-None-Match, ответ 304 с пустым телом, сильный и слабый валидатор.
• HTTP против HTTPS — что именно добавляет TLS и что он не скрывает.
• REST — ограничения стиля, а не формат данных, и честное сравнение с SOAP.
• CGI — процесс на запрос как историческая модель и почему её сменили WSGI и ASGI.

Частые ошибки и ловушки

Значение для собеседований

Тему почти всегда открывают одним вопросом — «что происходит, когда вы выполняете curl https://example.com». Это проверка модели, а не эрудиции: интервьюер слушает, назовёте ли вы DNS до соединения, рукопожатие TCP до TLS, TLS до первого байта HTTP, и понимаете ли, что запрос спускается по уровням, а не «летит на сервер». Отсюда растут все уточнения — где сидит обратный прокси, что изменится для http://, почему keep-alive экономит именно рукопожатие. Второй обязательный блок — методы и коды, и здесь лежит самый проваливаемый пункт темы: safe против idempotent. GET и HEAD безопасны, PUT и DELETE идемпотентны, но меняют состояние, POST не обладает ни одним из свойств. Ответ «идемпотентный значит только читает» уже сказал про кандидата главное.

Дальше идут детали, отличающие практику от чтения документации. Разница 301, 302, 307 и 308 — не про «постоянно или временно», а про право клиента сменить метод на GET. Кэширование разбирают в два шага — сначала свежесть (Cache-Control, max-age), затем ревалидация (ETag, If-None-Match, ответ 304), а разница no-cache и no-store — стандартный уточняющий вопрос. По HTTPS ждут не «там шифрование», а три гарантии — конфиденциальность, целостность, аутентификация сервера сертификатом — и честное признание, что домен в SNI наблюдателю виден. По REST проверяют, назовёте ли вы ограничения стиля вместо формата; ответ «REST — это JSON вместо XML» закрывает вопрос не в вашу пользу. Замыкает тему CGI — его спрашивают, чтобы услышать, понимаете ли вы, зачем появились WSGI и ASGI.