index.md

layout	../../layouts/Layout.astro
title	Веб-протоколы и безопасность
description	Сетевые протоколы, HTTP, безопасность, аутентификация и авторизация
category	Основы и инструменты
kind	questions
order	30

Веб-протоколы и безопасность

Что такое протокол? Какие протоколы знаешь?

Короткий ответ Протокол — это набор правил, по которым участники обмениваются сообщениями: формат данных, порядок действий и реакция на ошибки. Например, HTTP описывает обмен веб-запросами, TCP — надежную доставку байтов, а IP — маршрутизацию пакетов. Полный ответ Протокол задает контракт взаимодействия между независимыми системами. Обычно он определяет: синтаксис — как устроено сообщение, какие поля и кодировки допустимы; семантику — что означает каждое поле и какое действие должен выполнить получатель; последовательность — кто начинает обмен и какие сообщения ожидаются дальше; обработку ошибок — таймауты, повторные попытки, коды ошибок и завершение соединения. Протоколы работают слоями. Каждый слой решает свою задачу и использует нижележащий слой как транспорт: прикладной уровень: HTTP, DNS, SMTP, SSH, WebSocket; транспортный уровень: TCP, UDP, QUIC; сетевой уровень: IPv4, IPv6, ICMP; канальный уровень: Ethernet, Wi-Fi. Например, браузер может отправить HTTP-запрос через TLS и TCP поверх IP и Wi-Fi. HTTP не обязан знать, как Wi-Fi передает кадры, а Wi-Fi не обязан понимать HTTP-заголовки. Такое разделение позволяет менять реализацию одного слоя без полной переработки остальных. Важно различать протокол и продукт или API. REST — архитектурный стиль, gRPC — RPC-фреймворк и формат взаимодействия, который обычно использует HTTP/2, а JSON — формат данных. На интервью полезно не просто перечислить названия, а назвать уровень, задачу и один trade-off. Например: TCP гарантирует порядок и доставку, но имеет дополнительные задержки; UDP проще и быстрее, но надежность при необходимости реализует приложение.

Чем отличается http от https?

Короткий ответ HTTPS — это HTTP поверх TLS. TLS шифрует трафик, проверяет его целостность и обычно подтверждает подлинность сервера с помощью сертификата. HTTP без TLS передает данные открыто. Полный ответ HTTP описывает структуру запросов и ответов: методы, URL, заголовки, тело и статус-коды. Сам по себе HTTP не защищает данные между клиентом и сервером. Посредник в сети может прочитать или изменить незашифрованный запрос. HTTPS использует тот же HTTP, но перед обменом прикладными данными устанавливает защищенный канал TLS. Он дает три основных свойства: конфиденциальность: содержимое запроса и ответа нельзя прочитать без ключей сессии; целостность: изменение данных при передаче будет обнаружено; аутентификация сервера: браузер проверяет сертификат, доменное имя, срок действия и цепочку доверия. Во время TLS-handshake клиент и сервер согласуют параметры соединения, сервер предъявляет сертификат, а стороны получают общие сессионные ключи. Асимметричная криптография помогает безопасно договориться о ключах, после чего основной трафик шифруется быстрым симметричным алгоритмом. Практические отличия: стандартные порты — 80 для HTTP и 443 для HTTPS; браузеры ограничивают опасный mixed content, когда HTTPS-страница загружает активный ресурс по HTTP; HSTS может заставить браузер всегда обращаться к домену по HTTPS; cookie с флагом Secure отправляется только по защищенному соединению. HTTPS не делает приложение автоматически безопасным. Он не защищает от XSS, SQL injection, утечки токена в логах или ошибочной авторизации. Защита действует только на участке TLS-соединения: после TLS-терминации на CDN или reverse proxy данные должны быть защищены уже инфраструктурой приложения. Также не всегда используется TCP. HTTP/1.1 и HTTP/2 обычно работают поверх TCP и TLS, а HTTP/3 — поверх QUIC, который использует UDP и включает TLS 1.3 в установление соединения. На интервью стоит сформулировать главное: HTTPS защищает канал передачи, но не заменяет безопасность самого приложения.

Что такое авторизация и аутентификация?

Короткий ответ Аутентификация отвечает на вопрос «кто пользователь?», а авторизация — «что ему разрешено?». Сначала система подтверждает личность, затем проверяет права на конкретный ресурс или действие. Полный ответ Аутентификация подтверждает личность пользователя, сервиса или устройства. Для этого могут использоваться: пароль или PIN-код; одноразовый код, аппаратный ключ или приложение-аутентификатор; биометрия; клиентский сертификат; вход через внешний identity provider по OAuth 2.0 и OpenID Connect. Несколько независимых факторов образуют MFA. Например, пароль относится к фактору знания, а аппаратный ключ — к фактору владения. Два разных пароля не считаются двумя факторами. После успешной аутентификации сервер создает сессию или выдает токен. Cookie, session id и JWT не являются авторизацией сами по себе: они только переносят подтверждение личности и иногда набор claims между запросами. Авторизация проверяет, разрешено ли уже известному субъекту выполнить конкретное действие. Распространенные модели: RBAC: права назначаются ролям, например admin или editor; ABAC: решение зависит от атрибутов пользователя, ресурса и контекста; ACL: у ресурса хранится список субъектов и разрешенных операций; policy-based access: правила описываются централизованными политиками. Пример: сотрудник успешно вошел в систему — это аутентификация. Просмотр собственной заявки ему разрешен, а изменение чужой заявки запрещено — это авторизация. Во frontend можно скрыть недоступную кнопку, но это только часть UX. Настоящая проверка должна выполняться на сервере для каждого защищенного действия. Иначе пользователь сможет вызвать API напрямую. В HTTP часто используют такое различие: 401 Unauthorized обычно означает, что аутентификация отсутствует или недействительна; 403 Forbidden означает, что сервер распознал пользователя, но не разрешает действие. На интервью полезно упомянуть принцип минимальных привилегий, отзыв сессий, срок жизни токенов и необходимость проверять доступ к конкретному объекту, а не только общую роль пользователя.

Что происходит когда ты переходишь по Url?

Короткий ответ Браузер разбирает URL, проверяет кэши и Service Worker, находит IP через DNS, устанавливает защищенное соединение, отправляет HTTP-запрос, получает ответ и строит страницу из HTML, CSS и JavaScript. Полный ответ Реальный путь зависит от кэша, Service Worker, версии HTTP и настроек сети, но типичная последовательность выглядит так. Разбор URL. Браузер определяет схему, домен, порт, путь, query-параметры и fragment. Для поисковой строки он может сначала сформировать URL поисковой системы. Проверка локальных источников. Ответ может быть получен из memory cache, disk cache, back-forward cache или перехвачен Service Worker. В таком случае часть сетевых шагов не потребуется. DNS. Браузер или ОС ищет адрес в кэше. При отсутствии записи DNS-резолвер получает A или AAAA-запись домена. Результатом может быть адрес CDN или балансировщика, а не конечного application server. Установление соединения. Для HTTP/1.1 или HTTP/2 обычно выполняется TCP-handshake, затем TLS-handshake. Для HTTP/3 используется QUIC поверх UDP, где транспортное и TLS-согласование тесно связаны. HTTP-запрос. Браузер отправляет метод, путь, заголовки и при необходимости тело. Он может добавить Cookie, Accept, Accept-Encoding, Referer и условные заголовки кэша, например If-None-Match. Обработка на серверной стороне. Запрос может пройти через CDN, WAF, reverse proxy и балансировщик. Приложение проверяет сессию и права, обращается к кэшу или базе данных и формирует ответ. HTTP-ответ. Сервер возвращает статус, заголовки и тело. Браузер может обработать redirect, сохранить cookie, использовать 304 Not Modified, распаковать контент или применить политику CSP. Рендеринг. HTML-парсер строит DOM, CSS формирует CSSOM. Затем браузер создает render tree, рассчитывает layout, выполняет paint и compositing. Внешние CSS, JavaScript, шрифты и изображения загружаются дополнительными запросами. Выполнение JavaScript. Скрипты могут блокировать парсинг, изменять DOM, запускать fetch-запросы и планировать задачи. После изменений браузер при необходимости повторяет layout, paint или compositing. Современный браузер оптимизирует этот процесс: переиспользует соединения, выполняет preconnect и preload, а HTTP/2 и HTTP/3 позволяют передавать несколько потоков через одно соединение. Поэтому фраза «для каждого ресурса создается новое TCP-соединение» обычно неверна. На интервью сначала стоит дать последовательность URL -> DNS -> connection -> HTTP -> server -> rendering, а затем добавить две оговорки: ответ может прийти из кэша или Service Worker, а HTTP/3 не использует TCP.

Что такое шифрование данных?

Короткий ответ Шифрование преобразует открытые данные в шифротекст с помощью алгоритма и ключа. Прочитать данные может тот, у кого есть подходящий ключ для расшифрования. Полный ответ Шифрование используется для конфиденциальности данных при передаче и хранении. Без знания ключа шифротекст не должен раскрывать исходное сообщение, даже если алгоритм известен. Безопасная система полагается на секретность ключа, а не на секретность алгоритма. Основные виды: симметричное шифрование: один секретный ключ используется для шифрования и расшифрования; оно быстрое и подходит для больших объемов данных, например AES-GCM или ChaCha20-Poly1305; асимметричная криптография: используется пара из открытого и закрытого ключей; она удобна для обмена ключами и цифровых подписей, но обычно медленнее симметричных алгоритмов; гибридная схема: стороны с помощью асимметричной криптографии договариваются о сессионном секрете, а основной трафик шифруют симметрично. Такой подход используется в TLS. Современные системы обычно применяют authenticated encryption: кроме конфиденциальности оно проверяет целостность и подлинность сообщения. Простого шифрования без проверки целостности может быть недостаточно, потому что атакующий иногда способен изменить шифротекст предсказуемым образом. Шифрование не нужно путать с другими операциями: хеширование односторонне преобразует данные и применяется, например, для проверки целостности; пароли следует хранить не в зашифрованном виде, а как медленный salted hash с Argon2, scrypt или bcrypt; цифровая подпись подтверждает автора и целостность, но сама по себе не скрывает содержимое; кодирование, например Base64, не обеспечивает безопасность и легко обращается обратно. Главный практический риск — управление ключами. Сильный алгоритм не поможет, если ключ хранится рядом с данными, попадает в репозиторий или никогда не ротируется. В production используют secret manager или KMS, разграничивают доступ, планируют ротацию и резервное восстановление ключей. На интервью хороший ответ связывает шифрование с конкретной угрозой: TLS защищает данные в пути, disk encryption — при краже носителя, а application-level encryption может защищать отдельные поля даже от части инфраструктуры.