Полный ответ

Протокол задает контракт взаимодействия между независимыми системами. Обычно он определяет:

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

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

• прикладной уровень: 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 описывает структуру запросов и ответов: методы, 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 означает, что сервер распознал пользователя, но не разрешает действие.

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

Полный ответ

Реальный путь зависит от кэша, Service Worker, версии HTTP и настроек сети, но типичная последовательность выглядит так.

1. Разбор URL. Браузер определяет схему, домен, порт, путь, query-параметры и fragment. Для поисковой строки он может сначала сформировать URL поисковой системы.
2. Проверка локальных источников. Ответ может быть получен из memory cache, disk cache, back-forward cache или перехвачен Service Worker. В таком случае часть сетевых шагов не потребуется.
3. DNS. Браузер или ОС ищет адрес в кэше. При отсутствии записи DNS-резолвер получает A или AAAA-запись домена. Результатом может быть адрес CDN или балансировщика, а не конечного application server.
4. Установление соединения. Для HTTP/1.1 или HTTP/2 обычно выполняется TCP-handshake, затем TLS-handshake. Для HTTP/3 используется QUIC поверх UDP, где транспортное и TLS-согласование тесно связаны.
5. HTTP-запрос. Браузер отправляет метод, путь, заголовки и при необходимости тело. Он может добавить Cookie, Accept, Accept-Encoding, Referer и условные заголовки кэша, например If-None-Match.
6. Обработка на серверной стороне. Запрос может пройти через CDN, WAF, reverse proxy и балансировщик. Приложение проверяет сессию и права, обращается к кэшу или базе данных и формирует ответ.
7. HTTP-ответ. Сервер возвращает статус, заголовки и тело. Браузер может обработать redirect, сохранить cookie, использовать 304 Not Modified, распаковать контент или применить политику CSP.
8. Рендеринг. HTML-парсер строит DOM, CSS формирует CSSOM. Затем браузер создает render tree, рассчитывает layout, выполняет paint и compositing. Внешние CSS, JavaScript, шрифты и изображения загружаются дополнительными запросами.
9. Выполнение 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 может защищать отдельные поля даже от части инфраструктуры.