Пост☝️ В прошлом посте мы говорили про клиент-серверное взаимодействие: API, REST, запрос-ответ.

☝️ В прошлом посте мы говорили про клиент-серверное взаимодействие: API, REST, запрос-ответ. Но прежде чем идти дальше (обсуждать двунаправленность), хочется сделать шаг вниз по стеку. Потому что REST и прочее - это архитектурные стили. А под ними живут транспорты и сетевые протоколы. Давайте разбираться. С чего всё началось — TCP и UDP (транспортный уровень): Когда два компьютера обмениваются данными, они делают это через транспортный протокол. 1️⃣ TCP — «передать всё и правильно» TCP появился в 70-х. Его цель — гарантировать доставку данных. - следит за порядком пакетов - подтверждает получение - переотправляет потерянные - регулирует перегрузку сети Это надёжно. Но за надёжность приходится платить задержками. Передача фрагметов данных - сложный процесс и достоин отдельного поста, на тему. Но, базово, из-за передачи пакетов и их согласования может возникать проблема - head-of-line blocking (если один сегмент потерялся — остальные ждут). 2️⃣ UDP — «передать быстро» UDP появился примерно тогда же, но философия у него другая. Он просто отправляет пакет. Без гарантий: - дошёл ли - в каком порядке Зато: - минимум задержек - минимум оверхеда Поэтому UDP любят там, где важнее скорость, чем идеальная надёжность: игры, голос, видео. 3️⃣ Дальше появился HTTP (прикладной уровень) Когда понадобился стандарт для веба, поверх TCP построили HTTP. GET, POST и т.д. запросы с примитивами вроде header, body и т.д. 👨‍🦳 HTTP/1.1: запрос → ответ. - каждый запрос зависел от предыдущего - соединения открывались и закрывались - производительность была далека от идеала (в т.ч. из-за текстового формата передачи данных) Но для 90-х этого было достаточно. 👷‍♂️ HTTP/2 — попытка ускорить веб. Спустя почти 20 лет стало ясно, что HTTP/1 не справляется. - стал бинарным - добавил мультиплексирование (чтобы решать head-of-line blocking на уровне HTTP) - позволил нескольким запросам идти параллельно в одном соединении Это серьёзно ускорило загрузку страниц. Но есть нюанс. HTTP/2 всё ещё работает поверх TCP. А это значит, что на транспортном уровне все еще: если один пакет потерялся — потоки блокируются внутри соединения. 🤖 HTTP/3 отказался от TCP. Он работает поверх QUIC. QUIC — новая философия транспорта, построеная поверх UDP. Но он добавляет то, чего UDP не умеет сам: - надёжность - управление потоками - шифрование - мультиплексирование И делает это без проблем TCP. Ключевые отличия: - Нет head-of-line blocking между потоками - Быстрый handshake (0-RTT) - Встроенный TLS 1.3 - Лучше переносит смену сети (например, Wi-Fi → LTE) То есть QUIC — это фактически современный транспорт, который: - взял скорость UDP - добавил надёжность - встроил безопасность А HTTP/3 — это просто HTTP-семантика поверх QUIC. #L #HTTP #TCP #UPD #TLS 👏