29 вопросов
HTTP (HyperText Transfer Protocol) - протокол прикладного уровня для передачи данных (часто HTML, JSON, API). Запрос-ответ: клиент шлет запрос (метод, URL, заголовки, тело), сервер возвращает ответ (статус, заголовки, тело). Не сохраняет состояние между запросами (stateless). Версии: HTTP/1.0, HTTP/1.1 (keep-alive, chunked), HTTP/2 (мультиплексирование, бинарный фреймы), HTTP/3 (QUIC).
HTTP/2 - бинарный протокол поверх одного TCP-соединения. Мультиплексирование: множество запросов/ответов параллельно без блокировки. Сжатие заголовков (HPACK). Один соединение на домен - меньше накладных расходов. Серверный push (отправка ресурсов до запроса). Требует TLS в браузерах. HTTP/1.1 - текстовый, один запрос-ответ на соединение (или очередь), без сжатия заголовков.
HTTPS - HTTP поверх TLS (Transport Layer Security). TLS обеспечивает шифрование и проверку подлинности. Handshake: согласование версии, обмен ключами, сертификат сервера (и опционально клиента). После handshake трафик шифруется. Сертификаты выдают CA (Certificate Authority); клиент проверяет цепочку и домен. TLS 1.2/1.3 - современные версии. Защита от перехвата и подмены.
TCP - надежная доставка, с установлением соединения, порядок пакетов, повторная передача при потере, контроль потока. Подходит для HTTP, БД, когда важна целостность. UDP - без установления соединения, без гарантий доставки и порядка. Меньше накладных расходов, ниже задержка. Подходит для стриминга, голоса, игр, DNS. Выбор по требованию: надежность (TCP) или минимальная задержка (UDP).
DNS (Domain Name System) переводит имена доменов в IP-адреса и обратно. Иерархия: корневые серверы, TLD (.com, .ru), авторитативные серверы домена. Резолвер (на стороне клиента или провайдера) выполняет запросы A (IPv4), AAAA (IPv6), MX (почта), CNAME (алиас) и кеширует ответы (TTL). Рекурсивный запрос: резолвер обходит цепочку серверов до получения ответа.
Модель OSI - семь уровней сетевого взаимодействия: 7 Application (HTTP, FTP), 6 Presentation (кодирование, шифрование), 5 Session (сессии), 4 Transport (TCP, UDP), 3 Network (IP, маршрутизация), 2 Data Link (Ethernet, MAC), 1 Physical (сигналы). На практике часто используют упрощенную модель TCP/IP: Application, Transport, Internet, Link. Понимание уровней помогает отлаживать сетевые проблемы.
GET - получение ресурса, идемпотентный, без тела. POST - создание ресурса или действие, не идемпотентный. PUT - полная замена ресурса по URI, идемпотентный. PATCH - частичное обновление ресурса. DELETE - удаление, идемпотентный. HEAD - как GET, но без тела. OPTIONS - допустимые методы для ресурса (CORS).
PUT - клиент передает полное представление ресурса; сервер заменяет ресурс целиком. Идемпотентный: повторный PUT с теми же данными дает тот же результат. PATCH - клиент передает только изменяемые поля (частичное обновление). Результат зависит от текущего состояния. Для частичных обновлений в REST API предпочтительнее PATCH; PUT - когда клиент владеет полным ресурсом.
2xx - успех: 200 OK, 201 Created, 204 No Content. 3xx - перенаправление: 301 Moved Permanently, 302 Found, 304 Not Modified. 4xx - ошибка клиента: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity. 5xx - ошибка сервера: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable. Выбор кода важен для кеширования и обработки на клиенте.
301 Moved Permanently - ресурс навсегда перенесен по новому URL. Браузеры и поисковики могут кешировать и в дальнейшем обращаться сразу к новому URL. Поисковая семантика: передача веса на новый URL. 302 Found - временное перенаправление. Запрос в следующий раз снова пойдет на старый URL. Не кешируется как постоянное. Для временных редиректов (обслуживание, A/B) используют 302 или 307.
REST (Representational State Transfer) - архитектурный стиль для распределенных систем. Ресурсы идентифицируются URI. Стандартные методы HTTP (GET, POST, PUT, PATCH, DELETE). Stateless: сервер не хранит состояние клиента между запросами. Представления ресурсов (JSON, XML). Кешируемость, единообразный интерфейс, слои. RESTful API - API, следующее этим принципам. Часто используют для веб-API и мобильных бэкендов.
Метод идемпотентен, если повторное выполнение того же запроса дает тот же результат и не имеет дополнительных побочных эффектов. GET, PUT, DELETE - идемпотентны. POST - не идемпотентен (создание ресурса при каждом запросе). Важно для повторных запросов при таймаутах и ретраях: клиент может безопасно повторить GET/PUT/DELETE. Для POST идемпотентность достигают через идемпотентные ключи на стороне сервера.
CORS (Cross-Origin Resource Sharing) - механизм разрешения запросов с одного домена (origin) к другому. Браузер при cross-origin запросе шлет preflight (OPTIONS), сервер отвечает заголовками Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers. Без правильных заголовков браузер блокирует ответ. Настройка на сервере: разрешить нужные origin (или * для публичных API), методы, заголовки. Credentials - с cookies через Allow-Credentials.
Cookies - данные хранятся в браузере, отправляются с каждым запросом на домен. HttpOnly, Secure, SameSite для безопасности. Session - идентификатор сессии в cookie, данные сессии на сервере (файлы, Redis, БД). Token (JWT и др.) - подписанный артефакт с данными, хранится у клиента (localStorage или cookie), сервер проверяет подпись. Stateless против stateful. Выбор: сессии для традиционных приложений с серверным состоянием, токены для API и SPA.
JWT (JSON Web Token) - компактный способ передачи утверждений (claims) между сторонами в виде подписанного JSON. Структура: Header (алгоритм), Payload (claims: sub, exp, iat и др.), Signature (подпись HMAC или RSA). Токен передается в заголовке Authorization: Bearer <token> или в cookie. Сервер проверяет подпись и exp. Не хранит сессию на сервере. Минусы: отзыв до истечения срока сложнее (blacklist или короткий TTL).
OAuth2 - протокол авторизации: клиент получает ограниченный доступ к ресурсам пользователя на другом сервере без передачи пароля. Роли: Resource Owner (пользователь), Client (приложение), Authorization Server (выдает токены), Resource Server (API). Флоу: Authorization Code (веб, с редиректом), Client Credentials (сервис-сервис), Password (legacy), Implicit (устарел). Токены: access token для API, refresh token для обновления. Используется для "Войти через Google/GitHub".
Варианты: 1) Session: логин создает сессию на сервере, cookie с session_id. 2) JWT: после логина выдается access (и refresh) token, клиент шлет токен в заголовке. 3) API Key: статический ключ для сервис-сервис. 4) OAuth2: делегирование третьей стороне. Безопасность: HTTPS, защита от CSRF для cookie, короткий TTL access token, безопасное хранение refresh/ключей. Rate limiting и блокировка при подозрительной активности.
Протокол полнодуплексной связи поверх одного TCP-соединения. Handshake по HTTP (Upgrade: websocket), затем кадры данных в обе стороны. Постоянное соединение, низкая задержка. Применение: чаты, уведомления в реальном времени, игры, дашборды. В отличие от HTTP - сервер может инициировать отправку. Реализации: в PHP (Ratchet, Swoole), на уровне балансировщика (sticky session) или отдельный сервис на Node/Go.
Механизм односторонней потоковой передачи с сервера к клиенту по HTTP. Соединение держится открытым, сервер шлет события в формате text/event-stream (data, id, event, retry). Клиент - EventSource API. Проще чем WebSocket, работает через обычный HTTP, автоматическое переподключение. Подходит для лент обновлений, уведомлений, логов. Не подходит для двусторонней связи - только сервер к клиенту.
Клиент отправляет запрос и сервер держит его открытым до появления данных (или таймаута). Когда данные есть - сервер отвечает; клиент сразу шлет следующий запрос. Имитация push при отсутствии WebSocket/SSE. Минусы: накладные расходы на частые запросы, задержка до одного интервала опроса. Используется как fallback для старых браузеров или в ограниченных средах. Предпочтительнее SSE или WebSocket где возможно.
gRPC - RPC-фреймворк от Google на базе HTTP/2 и Protocol Buffers (бинарная сериализация). Описание сервисов в .proto файлах; генерация клиентского и серверного кода. Стриминг: unary, client stream, server stream, bidirectional. Высокая производительность, типизация, подходящ для микросервисов. Минусы: меньше поддержки в браузерах (нужен proxy), не человекочитаемый формат. Альтернатива REST для внутренних сервисов.
JSON-RPC - простой протокол: запрос с method и params, ответ с result или error. Легковесный, один endpoint. Подходит для внутренних API и простых сценариев. SOAP - XML-based, WSDL описание, строгая типизация, стандарты WS-*. Тяжелее, сложнее в интеграции. Используется в корпоративных и legacy системах. Для современных веб-API чаще REST или gRPC; JSON-RPC - когда нужен именно RPC-стиль поверх JSON.
Язык запросов и исполнения: клиент описывает нужные поля, сервер возвращает только их. Один endpoint, типизированная схема (типы, запросы, мутации). Решает overfetching/underfetching REST. Поддерживает вложенные запросы и фрагменты. Реализации: Apollo, Relay; на бэкенде - библиотеки для каждого языка. Кеширование и версионирование через схему. Не заменяет REST во всех сценариях - выбор по требованиям (сложные графы данных, мобильные клиенты).
OpenAPI - спецификация для описания REST API (формат YAML/JSON). Описываются пути, методы, параметры, ответы, схемы данных. Инструменты: генерация документации (Swagger UI), генерация клиентов и серверных заглушек, валидация запросов. Версия 3.x - актуальная. Используется для контрактного тестирования и единого источника правды для API. Интеграция в CI и в код (аннотации в PHP/Java).
Заголовки кеширования: Cache-Control (max-age, no-cache, no-store, private, public), ETag (хеш контента), Last-Modified. Браузер может хранить ответ и при повторном запросе отправить If-None-Match (ETag) или If-Modified-Since; сервер отвечает 304 Not Modified при неизменности. Управление: для статики - длинный max-age; для API - no-cache с проверкой ETag или короткий max-age. CDN кеширует по тем же заголовкам.
HTTP/1.1 по умолчанию поддерживает постоянное соединение (keep-alive): одно TCP-соединение используется для нескольких запросов подряд. Заголовок Connection: keep-alive (или отсутствие close). Снижает задержки и нагрузку на установку TCP (и TLS). Таймаут неактивности и лимит запросов на соединение задаются сервером. В HTTP/2 одно соединение мультиплексируется для многих потоков - keep-alive по сути встроен.
CDN (Content Delivery Network) - сеть edge-серверов, раздающих контент географически близко к пользователю. Кеширование статики (картинки, CSS, JS) и иногда API. Снижение задержки и нагрузки на origin. Провайдеры: CloudFlare, AWS CloudFront, Fastly. Настройка: DNS указывает на CDN, CDN запрашивает origin при cache miss. Инвалидация по URL или ключу. Защита от DDoS и WAF часто входят в CDN.
Ограничение частоты запросов от клиента (по IP, пользователю, API-ключу). Цели: защита от злоупотреблений, справедливое распределение ресурсов, защита от DDoS. Алгоритмы: фиксированное окно, скользящее окно, token bucket, leaky bucket. Ответ при превышении: 429 Too Many Requests, заголовки Retry-After, X-RateLimit-*. Реализация: в приложении (счетчики в Redis), на уровне Nginx/балансировщика, в API Gateway. Важно для публичных API.
1) DNS-резолвинг домена в IP. 2) Установка TCP-соединения (и при HTTPS - TLS handshake). 3) Отправка HTTP-запроса (метод, URL, заголовки, тело). 4) Сервер (веб-сервер, приложение, БД при необходимости) обрабатывает запрос. 5) Сервер отправляет HTTP-ответ (статус, заголовки, тело). 6) Браузер обрабатывает ответ (рендер, выполнение JS, кеширование). 7) Соединение может быть закрыто или оставлено для keep-alive. На любом этапе возможны кеш (DNS, HTTP), редиректы, балансировка.