Backend Checklist — День 6: HTTP/2 Multiplexing

Почему страница по HTTP/2 загружается быстрее, чем по HTTP/1.1, при хорошем Wi-Fi, но может работать медленнее при нестабильном соединении?

Допустим, странице нужно загрузить 40 файлов. HTTP/1.1 отправляет по одному request за раз в рамках одного connection и ждёт response, прежде чем отправить следующий. Поэтому браузеры обходили это ограничение, открывая до шести connections к одному сайту. В итоге одновременно выполняются шесть запросов, а седьмой ждёт, пока освободится один из connections.

HTTP/2 вместо этого открывает один connection и отправляет через него все 40 запросов одновременно. Каждый request получает собственный stream, а части всех 40 запросов передаются вперемешку через одно соединение. Больше не нужно ждать своей очереди.

Это та часть, о которой знают многие. Но у такого подхода есть своя цена.

TCP ничего не знает о streams

Streams — это концепция, которую добавил HTTP/2. На уровне ниже TCP видит только одно connection с непрерывным потоком bytes и понятия не имеет, что эти bytes относятся к 40 разным запросам.

Один поток bytes — одна очередь

TCP передаёт bytes в том порядке, в котором они были отправлены. Поэтому, если один packet потерялся, всё, что пришло после него, ждёт повторной передачи потерянного packet. Это называется head-of-line blocking.

Для HTTP эти 40 запросов независимы, но для TCP — нет, поэтому ждать приходится всем вместе.

В HTTP/1.1 потерянный packet блокирует одно из шести connections, а остальные пять продолжают работать.

В HTTP/2 потерянный packet блокирует единственное connection, через которое идёт весь трафик.

Именно поэтому HTTP/2 выигрывает при хорошем соединении, но может проигрывать при плохом. Он устранил ожидание, вызванное самим HTTP, но не мог устранить ожидание, возникающее на уровне TCP.

nghttp -nv выводит каждый frame вместе с его stream ID, поэтому можно увидеть, как несколько responses одновременно чередуются внутри одного connection.

👉 @BackendPortal

300+ практических задач: бесплатный тренажер по SQL

SQL Climber интерактивный тренажер с сотнями заданий, где можно решать SQL-задачи прямо в браузере и сразу получать проверку решений.

Практика лучший способ освоить SQL, этот сервис идеально подходит чтобы набить руку. Забираем 🥊

👉 @BackendPortal

Шпаргалка по самым частым ошибкам в Python

Эта шпаргалка поможет быстро находить и устранять распространённые ошибки в Python. Вы узнаете, как распознавать SyntaxError, TypeError, NameError и другие исключения, а также разберётесь в их причинах.

В материале есть примеры ошибок и простые способы их исправления, от пропущенных кавычек до проблем с файлами и словарями.

👉 @BackendPortal

Backend Checklist — День 7: HTTP/3 поверх QUIC

HTTP/3 — одна из тех технологий, которые поначалу кажутся странными: зачем строить надёжный transport поверх UDP? Ответ — TCP.

HTTP/2 представил streams, но TCP по-прежнему воспринимал connection как один упорядоченный поток bytes. Один потерянный packet мог задержать всё, что шло следом за ним.

QUIC перенёс управление streams на уровень самого transport. Теперь, если один stream ждёт потерянный packet, остальные могут продолжать передачу данных.

В этом и заключается основная идея HTTP/3: те же HTTP semantics, но transport, который действительно понимает streams.

👉 @BackendPortal

👉 @BackendPortal

Backend Checklist — День 8: Resource-based URLs

Почему вообще важно, назван endpoint в честь invoice или в честь действия, которое нужно с ним выполнить, если оба возвращают абсолютно одинаковый JSON? Response одинаковый. Но всё, что находится между client и server, работает по-разному.

Два места — одна задача

HTTP определяет methods для обозначения цели request, а URI используется для идентификации resource. Если поместить action в path, то path начинает отвечать на вопрос, на который уже должен отвечать method, и две части одной request line могут противоречить друг другу.

Path перестаёт разрастаться

Если называть resource, то все новые действия с invoice будут определяться через method, а не через очередной endpoint. В итоге API растёт вместе с количеством resources, а не с количеством добавленных features.

Что видит cache

Response может кэшироваться, если используется GET или HEAD. POST и PATCH подходят для этого только при наличии freshness information и соответствующего Content-Location header, что практически нигде не реализуется. Поэтому endpoint, названный в честь action, в итоге ничего не сохраняет на edge, и каждый read request проходит весь путь до origin server.

Обратная ситуация ещё опаснее

HTTP method считается safe, если он не изменяет состояние server. Браузеры могут выполнять prefetch, полагаясь на это правило, а crawlers также рассчитывают на него. Если направить их на endpoint, который что-то удаляет, — они это удалят.

Ничто не обеспечивает это автоматически

Nginx не может проверить, что route предназначен только для чтения. Framework тоже не может этого проверить. Это правило соблюдается лишь потому, что handler за конкретным route действительно ведёт себя соответствующим образом.

URL — это имя, а не инструкция

Если path уже говорит, что должно произойти, request сообщает одно и то же дважды. А всё, что находится между client и server, будет ориентироваться на ту часть request, для чтения которой оно было спроектировано.

👉 @BackendPortal

Эффективное освоение алгоритмов через паттерны LeetCode

Ресурс группирует задачи LeetCode по фундаментальным паттернам решения, превращая разрозненные задачи в понятную систему подходов.

Каждый паттерн объяснён, подкреплён примерами и визуализациями что помогает не просто «зубрить» задачи, а понимать сам подход, который легко переносится на новые задачи.

Есть треки для пошаговой подготовки от новичка до продвинутого. Это экономит время: вместо хаотичного выбора задач вы двигаетесь по структурному пути, который закрывает все ключевые темы для собесов.

👉 @BackendPortal

Backend Checklist — День 9: Idempotency

Клиенты повторяют запросы. Request может завершиться по timeout, соединение может оборваться, пользователь может снова нажать кнопку — и один и тот же request попадёт на server дважды.

Request считается idempotent, если его повторное выполнение безопасно. Отправите его один раз или десять — server останется в одном и том же состоянии.

Какие методы гарантируют idempotency?

GET, PUT и DELETE.

Повторно получите invoice, снова запишите тот же invoice или снова удалите его — итоговое состояние server останется тем же. POST такой гарантии не даёт. Каждый POST — это новая операция, поэтому два запроса могут означать две оплаты, два заказа или две строки в базе данных.

Но одинаковый результат не означает одинаковый response

Удалите invoice — получите 204. Попробуйте удалить его ещё раз — получите 404.

Responses разные, но invoice в обоих случаях остаётся удалённым. Idempotency относится к состоянию server, а не к ответу, который вы получаете.

Ваш proxy уже полагается на это

Если server падает до отправки response, reverse proxy может повторить GET, PUT или DELETE на другом server, но не станет автоматически повторять POST. Он ориентируется на HTTP method и доверяет его семантике.

Поэтому главная проблема — POST

Платёж завершается по timeout через 30 секунд. На 29-й секунде транзакция уже прошла, пользователь снова нажимает «Оплатить» — и в результате получает два списания.

Для этого используется idempotency key. Client отправляет уникальный key, server сохраняет первый результат под этим ключом, а каждый повторный request с тем же key получает сохранённый результат вместо повторного выполнения операции.

Где HTTP method может гарантировать idempotency — это делает method. Где не может — эту гарантию обеспечивает idempotency key. Проверьте proxy_next_upstream в конфигурации Nginx. Он уже определяет, какие requests можно повторять при определённых ошибках.

👉 @BackendPortal

Приоритеты плохого разработчика 😪

👉 @BackendPortal

Backend Checklist — День 10: Status Codes

Request завершился ошибкой. Что вернуть: 400, 401, 403, 404 или 422? Большинство API используют тот status code, который кажется наиболее знакомым. Именно с этой привычки и начинаются незаметные баги.

Первая цифра передаёт основную суть:
1xx → request всё ещё обрабатывается
2xx → всё прошло успешно
3xx → resource перемещён или требуется перенаправление
4xx → ошибка на стороне client
5xx → server столкнулся с ошибкой при обработке request

А дальше начинаются пары, которые часто путают:
401 vs 403:

401 = «Я пока не знаю, кто вы».
403 = «Я знаю, кто вы, но доступ вам всё равно запрещён».
400 vs 422:
400 = request не удалось корректно разобрать.
422 = request разобран, но переданные значения невалидны.
301 vs 307:
301 означает постоянный redirect и может кэшироваться.
307 сохраняет исходные HTTP method и body.

Главное правило: status code — это обещание о том, что произошло, а не просто label, который добавляется к response постфактум.

Верните 200 с ошибкой в body — и вы только что сообщили всем retry-механизмам, alerts и uptime checks, что всё в порядке.

Выбирайте status code исходя из того, что действительно произошло, а не из того, какой оказался под рукой.

👉 @BackendPortal

AI-агенты и инфраструктура

Вашему coding agent не нужно знать, где именно выполняется команда: локально, внутри Docker или в удалённой sandbox.

Предоставьте каждому execution backend одинаковый интерфейс, а harness пусть работает с ними одинаково.

👉 @BackendPortal