From da6cf513c10433f74f486f302df8740a5ee488bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC=20=D0=98=D0=B2=D0=B0?= =?UTF-8?q?=D0=BD=D0=BE=D0=B2?= Date: Fri, 31 Jul 2026 18:39:04 +0300 Subject: [PATCH] docs: expand web protocols and security answers --- src/pages/web-protocols/index.md | 296 ++++++++++++++++--------------- 1 file changed, 151 insertions(+), 145 deletions(-) diff --git a/src/pages/web-protocols/index.md b/src/pages/web-protocols/index.md index c888648..676d926 100644 --- a/src/pages/web-protocols/index.md +++ b/src/pages/web-protocols/index.md @@ -15,39 +15,33 @@ order: 30 **Короткий ответ** -Протокол: Это набор правил и соглашений, которые определяют формат, последовательность и обработку сообщений, которыми -обмениваются устройства или программы в сети или системе для успешной коммуникации. Протокол стандартизирует -взаимодействие. - Аналогия: Язык и правила этикета для общения между людьми. Чтобы два человека поняли друг друга, они -должны говорить на одном языке и следовать определенным правилам диалога. +Протокол — это набор правил, по которым участники обмениваются сообщениями: формат данных, порядок действий и реакция на +ошибки. Например, HTTP описывает обмен веб-запросами, TCP — надежную доставку байтов, а IP — маршрутизацию пакетов. **Полный ответ** -- **Протокол:** Это **набор правил и соглашений**, которые определяют **формат, последовательность и обработку - сообщений**, которыми обмениваются устройства или программы в сети или системе для успешной коммуникации. Протокол - стандартизирует взаимодействие. -- **Аналогия:** Язык и правила этикета для общения между людьми. Чтобы два человека поняли друг друга, они должны - говорить на одном языке и следовать определенным правилам диалога. -- **Какие протоколы знаешь (примеры по уровням модели OSI/TCP/IP):** - - **Прикладной уровень (Application Layer):** - - **HTTP (HyperText Transfer Protocol):** Основа веба, для передачи гипертекста (веб-страниц). - - **HTTPS (HTTP Secure):** Безопасная версия HTTP с шифрованием (TLS/SSL). - - **FTP (File Transfer Protocol):** Для передачи файлов. - - **SMTP (Simple Mail Transfer Protocol):** Для отправки электронной почты. - - **POP3 (Post Office Protocol v3) / IMAP (Internet Message Access Protocol):** Для получения электронной почты. - - **DNS (Domain Name System):** Для преобразования доменных имен в IP-адреса. - - **SSH (Secure Shell):** Для безопасного удаленного доступа к системам. - - **SOAP, WebSocket, gRPC** (можно отнести сюда же, как протоколы прикладного уровня для специфичных задач). - - **Транспортный уровень (Transport Layer):** - - **TCP (Transmission Control Protocol):** Гарантированная доставка данных с установлением соединения, контролем - ошибок и порядка пакетов. - - **UDP (User Datagram Protocol):** Быстрая доставка данных без гарантий и установления соединения (для потокового - видео, игр, DNS). - - **Сетевой уровень (Internet/Network Layer):** - - **IP (Internet Protocol):** Основной протокол для маршрутизации пакетов данных в сети Интернет. (IPv4, IPv6). - - **ICMP (Internet Control Message Protocol):** Для передачи служебных сообщений и сообщений об ошибках - (используется ping, traceroute). - - **Канальный уровень (Data Link Layer):** - - **Ethernet, Wi-Fi:** Протоколы для передачи данных в локальных сетях. +Протокол задает контракт взаимодействия между независимыми системами. Обычно он определяет: + +- **синтаксис** — как устроено сообщение, какие поля и кодировки допустимы; +- **семантику** — что означает каждое поле и какое действие должен выполнить получатель; +- **последовательность** — кто начинает обмен и какие сообщения ожидаются дальше; +- **обработку ошибок** — таймауты, повторные попытки, коды ошибок и завершение соединения. + +Протоколы работают слоями. Каждый слой решает свою задачу и использует нижележащий слой как транспорт: + +- **прикладной уровень:** 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 +проще и быстрее, но надежность при необходимости реализует приложение. @@ -59,29 +53,39 @@ order: 30 **Короткий ответ** -HTTP (HyperText Transfer Protocol): Стандартный протокол для передачи данных (в основном веб-страниц) в интернете. -Данные передаются в открытом, незашифрованном виде. - HTTPS (HyperText Transfer Protocol Secure): Это расширение -протокола HTTP, которое добавляет шифрование передаваемых данных с помощью криптографических протоколов SSL (Secure -Sockets Layer) или, что более современно, TLS (Transport Layer Security). +HTTPS — это HTTP поверх TLS. TLS шифрует трафик, проверяет его целостность и обычно подтверждает подлинность сервера с +помощью сертификата. HTTP без TLS передает данные открыто. **Полный ответ** -- **HTTP (HyperText Transfer Protocol):** Стандартный протокол для передачи данных (в основном веб-страниц) в интернете. - Данные передаются **в открытом, незашифрованном виде**. -- **HTTPS (HyperText Transfer Protocol Secure):** Это **расширение протокола HTTP**, которое добавляет **шифрование** - передаваемых данных с помощью криптографических протоколов **SSL (Secure Sockets Layer)** или, что более современно, - **TLS (Transport Layer Security)**. -- **Ключевые отличия:** - 1. **Безопасность:** HTTPS **шифрует** весь трафик между клиентом (браузером) и сервером, обеспечивая - **конфиденциальность** (данные не могут быть прочитаны посторонними) и **целостность** (данные не могут быть - незаметно изменены при передаче). HTTP передает все в открытом виде. - 2. **Аутентификация сервера:** HTTPS использует **SSL/TLS сертификаты** для проверки подлинности веб-сервера, к - которому подключается клиент. Это защищает от атак типа "человек посередине" (man-in-the-middle). HTTP не - предоставляет такой проверки. - 3. **Порт по умолчанию:** HTTP использует порт **80**, HTTPS использует порт **443**. - 4. **URL:** URL для HTTPS начинается с `https://`, для HTTP – с `http://`. -- **Итог:** HTTPS – это безопасная версия HTTP, необходимая для передачи любых конфиденциальных данных (логины, пароли, - платежная информация) и стандарт де-факто для современных веб-сайтов. +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 защищает +канал передачи, но не заменяет безопасность самого приложения. @@ -93,36 +97,45 @@ Sockets Layer) или, что более современно, TLS (Transport La **Короткий ответ** -Это два разных, но связанных процесса управления доступом: +Аутентификация отвечает на вопрос «кто пользователь?», а авторизация — «что ему разрешено?». Сначала система +подтверждает личность, затем проверяет права на конкретный ресурс или действие. **Полный ответ** -Это два разных, но связанных процесса управления доступом: - -1. **Аутентификация (Authentication):** - - **Процесс проверки подлинности пользователя или системы.** Ответ на вопрос: **"Кто ты?"**. - - Система проверяет, является ли пользователь тем, за кого себя выдает. - - **Методы:** - - Что-то, что пользователь **знает** (пароль, PIN-код). - - Что-то, что пользователь **имеет** (физический ключ, токен, SMS-код, сертификат). - - Что-то, чем пользователь **является** (биометрия: отпечаток пальца, сканирование сетчатки). - - Многофакторная аутентификация (MFA) комбинирует несколько методов. - - _Результат:_ Успешная аутентификация подтверждает личность пользователя. - -2. **Авторизация (Authorization):** - - **Процесс определения прав доступа аутентифицированного пользователя к определенным ресурсам или действиям.** - Ответ на вопрос: **"Что тебе разрешено делать?"**. - - Происходит **после** успешной аутентификации. - - Система проверяет, имеет ли подтвержденный пользователь необходимые **разрешения (permissions)** для выполнения - запрошенной операции (чтение файла, просмотр страницы, удаление записи, вызов API). - - **Механизмы:** Ролевые модели доступа (RBAC), списки контроля доступа (ACL), политики доступа. - - _Результат:_ Разрешение или запрет на выполнение действия. - -**Аналогия:** - -- **Аутентификация:** Предъявление паспорта на входе в здание (доказательство личности). -- **Авторизация:** Проверка вашего пропуска охраной, чтобы определить, в какие кабинеты этого здания вам разрешен - доступ. +**Аутентификация** подтверждает личность пользователя, сервиса или устройства. Для этого могут использоваться: + +- пароль или 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` означает, что сервер распознал пользователя, но не разрешает действие. + +На интервью полезно упомянуть принцип минимальных привилегий, отзыв сессий, срок жизни токенов и необходимость проверять +доступ к конкретному объекту, а не только общую роль пользователя. @@ -134,57 +147,38 @@ Sockets Layer) или, что более современно, TLS (Transport La **Короткий ответ** -Это сложный процесс, но вот основные шаги на высоком уровне: +Браузер разбирает URL, проверяет кэши и Service Worker, находит IP через DNS, устанавливает защищенное соединение, +отправляет HTTP-запрос, получает ответ и строит страницу из HTML, CSS и JavaScript. **Полный ответ** -Это сложный процесс, но вот основные шаги на высоком уровне: - -1. **Ввод URL и DNS-запрос:** - - Ты вводишь URL (например, `https://www.example.com`) в адресную строку браузера и нажимаешь Enter. - - Браузер сначала проверяет свой кэш (и кэш ОС), не знает ли он уже IP-адрес для `www.example.com`. - - Если нет, браузер отправляет **DNS-запрос** к DNS-резолверу (обычно предоставляется твоим интернет-провайдером или - настроен вручную, как Google DNS). - - DNS-резолвер рекурсивно опрашивает другие DNS-серверы (корневые, TLD, авторитативные), чтобы найти **IP-адрес**, - соответствующий доменному имени `www.example.com`. - - DNS-резолвер возвращает IP-адрес браузеру. -2. **Установление TCP-соединения:** - - Браузер инициирует установление **TCP-соединения** с сервером по полученному IP-адресу и порту (для HTTPS это порт - 443). - - Происходит процесс "тройного рукопожатия" (TCP three-way handshake: SYN -> SYN-ACK -> ACK) для установления - надежного соединения. -3. **TLS/SSL Рукопожатие (для HTTPS):** - - Если используется HTTPS, поверх TCP-соединения происходит **TLS/SSL рукопожатие**. - - Браузер и сервер обмениваются сообщениями для согласования версии протокола, шифров, обмена ключами и проверки - **SSL-сертификата сервера**. - - В результате устанавливается **защищенный, зашифрованный канал** связи. -4. **Отправка HTTP(S) Запроса:** - - Браузер формирует и отправляет **HTTP(S) запрос** на сервер через установленное соединение. Запрос включает: - - **Стартовую строку:** Метод (`GET`), путь (`/`), версия протокола (`HTTP/1.1` или `HTTP/2`). - - **Заголовки (Headers):** `Host`, `User-Agent`, `Accept`, `Cookie` и др. - - **(Опционально) Тело запроса (Body):** Для методов POST, PUT, PATCH. -5. **Обработка запроса сервером:** - - Веб-сервер (например, Nginx, Apache) получает запрос. - - Он может передать запрос приложению (например, на PHP, Python, Java) для обработки. - - Приложение выполняет необходимую логику: обращается к базе данных, выполняет вычисления, генерирует HTML-страницу - или другие данные. -6. **Отправка HTTP(S) Ответа:** - - Сервер формирует и отправляет **HTTP(S) ответ** обратно браузеру. Ответ включает: - - **Статус-строку:** Версия протокола, **статус-код** (`200 OK`, `404 Not Found`, `301 Redirect` и т.д.), фраза - состояния. - - **Заголовки (Headers):** `Content-Type`, `Content-Length`, `Set-Cookie`, `Cache-Control` и др. - - **Тело ответа (Body):** Содержимое ресурса (HTML-код страницы, JSON, изображение и т.д.). -7. **Отрисовка (Рендеринг) страницы браузером:** - - Браузер получает ответ. - - Он **парсит HTML-код**. - - Если в HTML есть ссылки на другие ресурсы (CSS, JavaScript, изображения), браузер **повторяет шаги 2-6** для - загрузки каждого из этих ресурсов (часто параллельно, используя существующие или новые TCP/HTTPS соединения). - - Браузер **строит DOM-дерево** (Document Object Model) и CSSOM (CSS Object Model). - - Применяет стили CSS к элементам DOM. - - **Выполняет JavaScript-код**, который может модифицировать DOM или запрашивать дополнительные данные (через AJAX). - - **Отображает (рендерит)** готовую веб-страницу на экране. -8. **(Опционально) Закрытие соединения:** Соединение может быть закрыто или оставлено открытым (keep-alive) для - последующих запросов. +Реальный путь зависит от кэша, 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. @@ -196,29 +190,41 @@ Sockets Layer) или, что более современно, TLS (Transport La **Короткий ответ** -Шифрование данных (Encryption): Это процесс преобразования исходных данных (открытого текста, plaintext) в нечитаемый -формат (шифротекст, ciphertext) с использованием алгоритма шифрования и ключа. - Цель: Обеспечить конфиденциальность -данных – сделать их непонятными для всех, кто не обладает соответствующим ключом для расшифровки (дешифрования). +Шифрование преобразует открытые данные в шифротекст с помощью алгоритма и ключа. Прочитать данные может тот, у кого есть +подходящий ключ для расшифрования. **Полный ответ** -- **Шифрование данных (Encryption):** Это процесс **преобразования исходных данных (открытого текста, plaintext)** в - **нечитаемый формат (шифротекст, ciphertext)** с использованием **алгоритма шифрования** и **ключа**. -- **Цель:** Обеспечить **конфиденциальность** данных – сделать их непонятными для всех, кто не обладает соответствующим - ключом для расшифровки (дешифрования). -- **Основные компоненты:** - - **Алгоритм шифрования:** Математическая процедура для преобразования данных (например, AES, RSA, DES). - - **Ключ шифрования:** Секретная информация (строка бит), используемая алгоритмом для шифрования данных. - - **Ключ дешифрования:** Ключ, используемый для обратного преобразования шифротекста в открытый текст. -- **Типы шифрования (по ключам):** - - **Симметричное шифрование:** Используется **один и тот же** секретный ключ для шифрования и дешифрования (например, - AES). Быстрое, но требует безопасной передачи ключа. - - **Асимметричное шифрование (с открытым ключом):** Используется **пара ключей:** **открытый ключ (public key)** для - шифрования и **закрытый ключ (private key)** для дешифрования. Открытый ключ можно свободно распространять, закрытый - хранится в секрете. Используется для безопасного обмена ключами и цифровых подписей (например, RSA). Медленнее - симметричного. -- **Применение:** Защита данных при передаче (HTTPS, VPN, SSH), защита хранимых данных (шифрование дисков, баз данных), - цифровая подпись, безопасная аутентификация. +Шифрование используется для конфиденциальности данных при передаче и хранении. Без знания ключа шифротекст не должен +раскрывать исходное сообщение, даже если алгоритм известен. Безопасная система полагается на секретность ключа, а не на +секретность алгоритма. + +Основные виды: + +- **симметричное шифрование:** один секретный ключ используется для шифрования и расшифрования; оно быстрое и подходит + для больших объемов данных, например AES-GCM или ChaCha20-Poly1305; +- **асимметричная криптография:** используется пара из открытого и закрытого ключей; она удобна для обмена ключами и + цифровых подписей, но обычно медленнее симметричных алгоритмов; +- **гибридная схема:** стороны с помощью асимметричной криптографии договариваются о сессионном секрете, а основной + трафик шифруют симметрично. Такой подход используется в TLS. + +Современные системы обычно применяют authenticated encryption: кроме конфиденциальности оно проверяет целостность и +подлинность сообщения. Простого шифрования без проверки целостности может быть недостаточно, потому что атакующий иногда +способен изменить шифротекст предсказуемым образом. + +Шифрование не нужно путать с другими операциями: + +- **хеширование** односторонне преобразует данные и применяется, например, для проверки целостности; +- **пароли** следует хранить не в зашифрованном виде, а как медленный salted hash с Argon2, scrypt или bcrypt; +- **цифровая подпись** подтверждает автора и целостность, но сама по себе не скрывает содержимое; +- **кодирование**, например Base64, не обеспечивает безопасность и легко обращается обратно. + +Главный практический риск — управление ключами. Сильный алгоритм не поможет, если ключ хранится рядом с данными, +попадает в репозиторий или никогда не ротируется. В production используют secret manager или KMS, разграничивают доступ, +планируют ротацию и резервное восстановление ключей. + +На интервью хороший ответ связывает шифрование с конкретной угрозой: TLS защищает данные в пути, disk encryption — при +краже носителя, а application-level encryption может защищать отдельные поля даже от части инфраструктуры.