Сети

Уровни и что на них живёт

• L1 физический — вольты, свет, радио; по нему бегут биты.
• L2 канальный — Ethernet, Wi-Fi (802.11), PPP. Адресует по MAC, передаёт кадры и не выходит за пределы одного широковещательного сегмента. Здесь же VLAN и коммутаторы.
• L3 сетевой — IP, ICMP, IPsec, протоколы маршрутизации (OSPF, BGP). Адресует по IP, передаёт пакеты. Гарантий никаких, только best effort: пакет может пропасть, задублироваться, прийти не в том порядке. Здесь работают роутеры.
• L4 транспортный — TCP, UDP, QUIC (формально поверх UDP), SCTP. Здесь появляется порт, то есть адрес конкретного процесса на хосте. TCP добавляет надёжность, порядок, управление потоком и перегрузкой, UDP не добавляет ничего.
• L5/L6 в OSI — сеансовый и представления (сессии, шифрование, кодировки). В реальном стеке их отдельно нет: TLS формально «L6», а на деле библиотека между TCP и HTTP.
• L7 прикладной — HTTP, gRPC, DNS, SMTP, SSH, AMQP, Redis-протокол, Postgres wire protocol.

Зачем это знать на практике

Почти любой вопрос про инфраструктуру задают в терминах уровней. L4-балансировщик (LVS/IPVS, AWS NLB, HAProxy в режиме tcp) видит только пятёрку адрес/порт и перекладывает пакеты. Он дешёвый и держит миллионы соединений, но не знает ни URL, ни заголовка Host, ни куки. L7-балансировщик (nginx, Envoy, ALB, Traefik) терминирует TCP и TLS, разбирает HTTP и умеет маршрутизировать по пути, хосту, заголовкам, делать ретраи отдельных запросов и circuit breaking — но ест процессор и добавляет задержку. Из той же оперы правило безопасности «фильтруем на L3/L4 файрволом, на L7 — WAF».

Про инкапсуляцию — обязательно проговорить

На отправке каждый уровень дописывает свой заголовок вокруг данных верхнего: HTTP-текст оборачивается в TCP-сегмент, сегмент в IP-пакет, пакет в Ethernet-кадр. На приёме всё разбирается обратно. Отсюда MTU: в Ethernet-кадр влезает 1500 байт полезной нагрузки, IP-заголовок 20 и TCP-заголовок 20 съедают 40, остаётся MSS 1460. Если у кого-то на пути MTU меньше (VPN, PPPoE, туннели в облаке), а ICMP-сообщения «Fragmentation Needed» режет файрвол, получаешь классический баг: рукопожатие проходит, мелкие запросы работают, а большой POST висит намертво. Это чёрная дыра PMTU.

Маска и подсеть

10.0.5.17/24: 24 бита — сеть, 8 — хост. В адресе сети все хостовые биты нулевые (10.0.5.0), в broadcast единичные (10.0.5.255), полезных адресов 2^8 - 2 = 254. Чем короче префикс, тем больше сеть: в /16 65534 хоста, в /30 два (классический линк между роутерами), /32 означает один конкретный адрес.

$ ipcalc 10.0.5.17/24
Address:   10.0.5.17    00001010.00000000.00000101. 00010001
Netmask:   255.255.255.0 = 24
Network:   10.0.5.0/24
Broadcast: 10.0.5.255
HostMin:   10.0.5.1     HostMax: 10.0.5.254

Маршрут выбирают по правилу longest prefix match: если адрес назначения после наложения маски совпадает с собственной сетью, шлём напрямую соседу (узнав его MAC через ARP), иначе отдаём кадр на MAC шлюза по умолчанию, не трогая IP назначения.

Приватные диапазоны

Диапазоны RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) в интернете не маршрутизируются. Ещё полезно помнить 127.0.0.0/8 (loopback целиком, не только 127.0.0.1), 169.254.0.0/16 (link-local; сюда входит и 169.254.169.254, метадата-сервис в AWS/GCP/Yandex Cloud, откуда при SSRF утекают креды) и 100.64.0.0/10 (CGNAT).

NAT

Почти всегда это NAPT: роутер подменяет src IP:port на свой публичный адрес и свободный порт, запись кладёт в таблицу трансляций и по ней разворачивает обратный трафик. Услышать хотят три следствия:

• Соединение может инициировать только внутренняя сторона — снаружи записи в таблице нет. Поэтому p2p требует port forwarding, UPnP или hole punching через STUN/TURN.
• Записи протухают: у UDP обычно через 30–120 с, у TCP через минуты и десятки минут. Из-за этого простаивающее соединение «внезапно» перестаёт работать; лечат это TCP keep-alive с интервалом меньше таймаута NAT.
• Порты кончаются: за одним публичным IP на одну пару (dst IP, dst port) больше ~64 тысяч одновременных соединений не спрячешь. На NAT-шлюзе перед большим кластером это реальная беда: SNAT port exhaustion в Kubernetes случается сплошь и рядом.

Порядок разрешения имени

1. Кэш браузера (десятки секунд), затем кэш ОС (systemd-resolved, nscd), затем /etc/hosts — до сети дело может и не дойти.
2. Stub resolver шлёт вопрос с флагом RD=1 («сделай за меня всю работу») на резолвер из /etc/resolv.conf. Ходит он по UDP/53; если ответ не влез, приходит флаг TC (truncated), и клиент повторяет запрос по TCP/53. С EDNS0 UDP-ответ может быть больше 512 байт.
3. Резолвер идёт по иерархии: корневой сервер отдаёт NS для com, TLD-сервер отвечает NS для google.com, а авторитативный возвращает саму A-запись с флагом AA=1.
4. Ответ кладётся в кэши на всём обратном пути на время TTL.

TTL и отрицательное кэширование

TTL задаёт владелец зоны: у A-записей обычно 60–300 секунд, у NS часы. Перед миграцией TTL заранее опускают до 60 секунд, переключают запись, ждут и потом поднимают обратно. NXDOMAIN тоже кэшируется, срок задаёт поле minimum в SOA. Поэтому «создал запись, а её не видно» часто означает, что ты успел спросить имя до создания и отрицательный ответ осел в кэше.

Типы записей

• A / AAAA хранят IPv4 / IPv6. Несколько A-записей дают round-robin-балансировку «для бедных»: порядок ротируется, но клиент может закэшировать одну и сидеть на ней.
• CNAME — алиас на другое имя, разрешение продолжается по цепочке. Нельзя на вершине зоны (рядом с SOA и NS), поэтому провайдеры придумали ALIAS/ANAME.
• MX указывает почтовый сервер с приоритетом (чем меньше число, тем выше приоритет).
• В TXT кладут произвольный текст: SPF, DKIM, DMARC, подтверждение владения доменом для ACME/Let's Encrypt (_acme-challenge).
• SRV: _service._proto.name → приоритет, вес, порт и хост. Порт отдают она и записи SVCB/HTTPS (RFC 9460), а на SRV держится service discovery в Consul и headless-сервисы Kubernetes.
• NS — делегирование зоны, SOA — параметры зоны, PTR — обратное разрешение.

Решает он вот что: в провод кладут не IP-пакет, а Ethernet-кадр, и адреса у кадра MAC. Значит, перед отправкой хосту нужно знать MAC следующего узла. ARP-запрос уходит на ff:ff:ff:ff:ff:ff, его видят все в сегменте, а отвечает только владелец адреса.

$ ip neigh                 # ARP-кэш в Linux
10.0.5.1   dev eth0 lladdr 02:42:ac:11:00:01 REACHABLE
10.0.5.23  dev eth0 lladdr 02:42:ac:11:00:17 STALE

$ tcpdump -n -i eth0 arp
ARP, Request who-has 10.0.5.1 tell 10.0.5.17, length 28
ARP, Reply 10.0.5.1 is-at 02:42:ac:11:00:01, length 46

Главная мысль ответа

ARP не работает через роутер. Если адрес назначения в другой сети, хост никогда не спрашивает про него ARP, он спрашивает MAC своего шлюза. По дороге IP-адреса источника и назначения не меняются (пока нет NAT), а MAC-адреса переписываются на каждом роутере. Так коротко и объясняют разницу между L2 и L3.

Что ещё бывает вокруг ARP

• При Gratuitous ARP хост сам объявляет «этот IP теперь мой». Так переезжает виртуальный IP при failover (keepalived/VRRP), чтобы коммутаторы и соседи обновили кэш.
• Proxy ARP — роутер отвечает за чужой адрес.
• ARP spoofing возможен, потому что у протокола нет аутентификации: кто угодно в сегменте может ответить «это я» и устроить MITM. Защищаются Dynamic ARP Inspection, статическими записями, 802.1X.
• В IPv6 ARP заменён на NDP поверх ICMPv6 (Neighbor Solicitation/Advertisement) и использует multicast вместо broadcast.

Отсюда вывод: сервер обслуживает тысячи клиентов на одном порту. Порт 443 один, а сокетов столько, сколько соединений, и ядро различает их по пятёрке. Классический неверный ответ на собесе: «на каждого клиента сервер выделяет новый порт» — нет, новый порт выделяет клиент, а серверный остаётся тем же.

ln, _ := net.Listen("tcp", ":8080")   // один слушающий сокет
for {
    conn, err := ln.Accept()          // каждый Accept -> новый fd на том же :8080
    if err != nil { continue }
    go handle(conn)                   // conn.RemoteAddr() у всех разный
}

Два типа сокетов у TCP

• Слушающий: пятёрка неполная ({tcp, *, 8080, *, *}), у него две очереди — SYN queue (полуоткрытые) и accept queue (готовые, длина = backlog, ограничена net.core.somaxconn). Когда accept queue переполнена, SYN молча отбрасываются, а клиент ловит «непонятные» таймауты.
• Установленный: полная пятёрка, свои буферы приёма и отправки в ядре.

Где реально кончаются ресурсы

• Сервер упирается в файловые дескрипторы (ulimit -n), память ядра под буферы и длину accept-очереди, но не в порты.
• Клиент упирается в эфемерные порты: net.ipv4.ip_local_port_range = 32768 60999, то есть ~28 тысяч. Лимит считается на пару (dst IP, dst port): к одному бэкенду 28 тысяч, к десяти разным уже 280 тысяч. Этот лимит и выжигает TIME_WAIT, когда нет keep-alive.
• Порты 0–1023 привилегированные: нужен root или CAP_NET_BIND_SERVICE.

1. Разбор строки и HSTS

Браузер решает, это URL или поисковый запрос, нормализует (punycode для кириллицы, схема, порт по умолчанию). Затем проверяет HSTS: если домен есть в preload-списке или в локальном кэше HSTS, схема принудительно становится https ещё до какого-либо трафика. Так браузер защищается от downgrade-атаки, и редиректа 301 не будет.

2. Кэши: сети может и не быть вообще

По очереди: HTTP-кэш браузера (свежий ответ отдаётся мгновенно), Service Worker (может ответить из своего кэша офлайн), кэш DNS браузера, кэш DNS операционной системы, /etc/hosts. Скажи это вслух: здесь впервые отвечают на вопрос «почему быстро/медленно».

3. DNS

Stub resolver шлёт рекурсивный запрос (RD=1) резолверу по UDP/53. Резолвер обходит иерархию: корень → NS зоны com → NS зоны google.com → авторитативный сервер отдаёт A/AAAA с TTL. Если ответ не влез в датаграмму, ставится флаг TC и запрос повторяют по TCP. Клиент получает набор адресов и по Happy Eyeballs (RFC 8305) начинает соединяться по IPv6, а через четверть секунды и по IPv4, оставляя того, кто ответил первым. В жизни ответ для google.com придёт из кэша резолвера за единицы миллисекунд, а адрес будет ближайшим GeoDNS/anycast-узлом.

4. Маршрутизация, ARP, NAT

Хост накладывает маску: адрес не свой — берём default gateway. ARP даёт MAC шлюза, IP-пакет уходит в Ethernet-кадре. Домашний роутер делает NAPT: подменяет src на публичный адрес и свободный порт. Дальше пакет идёт по цепочке роутеров, каждый уменьшает TTL и переписывает MAC-адреса, а IP остаются прежними.

5. TCP-рукопожатие — 1 RTT

SYN (со своим ISN, опциями MSS, window scale, SACK permitted, timestamps) → SYN-ACK → ACK. После третьего пакета сокет в состоянии ESTABLISHED, и данные можно слать прямо с ним. Если сервер за CDN и находится в соседней стране, это уже 20–40 мс.

6. TLS-рукопожатие — 1 RTT (TLS 1.3)

ClientHello везёт версии, шифронаборы, SNI (по нему сервер выбирает сертификат, когда на одном IP много доменов), ALPN (h2, http/1.1; h3 бывает только в TLS внутри QUIC) и уже свою долю ключа ECDHE. Сервер отвечает ServerHello, сертификатом и цепочкой, подписью и Finished — дальше трафик шифруется. Клиент проверяет цепочку до доверенного корня, срок действия, соответствие имени в SAN, отзыв (OCSP stapling). Асимметрика нужна, только чтобы аутентифицировать сервер и договориться об общем секрете, а сами данные шифруются симметрично (AES-GCM или ChaCha20-Poly1305). При возобновлении сессии по билету бывает 0-RTT.

7. HTTP-запрос и путь до приложения

Браузер шлёт GET / HTTP/1.1 с Host, User-Agent, Accept, Accept-Encoding, Cookie, а если ALPN договорился о h2, то HEADERS-фрейм с заголовками, сжатыми HPACK. По пути обычно стоят CDN edge (может ответить из кэша), L4-балансировщик, реверс-прокси/L7-балансировщик, который терминирует TLS и выбирает бэкенд, и только потом само приложение. Каждый прокси добавляет X-Forwarded-For/Forwarded и, если всё сделано правильно, X-Request-ID для сквозной трассировки.

8. Ответ и рендер

Приходят статус, заголовки и тело (обычно Transfer-Encoding: chunked или DATA-фреймы в h2, часто со сжатием gzip/br). Браузер потоково парсит HTML в DOM и CSS в CSSOM, объединяет их в render tree, считает layout (геометрию), paint (растеризацию слоёв) и composite (сборку слоёв на GPU). Параллельно preload scanner уже тянет подресурсы. Синхронный <script> без defer/async блокирует парсер, CSS блокирует рендер, и отсюда растут все метрики FCP/LCP.

Рукопожатие

SYN (клиент шлёт свой ISN и опции) → SYN-ACK (сервер шлёт свой ISN и подтверждает чужой) → ACK. Три пакета, потому что четыре логических события (два ISN и два подтверждения) склеиваются в три: SYN сервера и ACK на SYN клиента едут вместе. ISN обязательно псевдослучайный: иначе заблудившийся сегмент от старого соединения с той же пятёркой был бы принят за валидный, а ещё это защищает от подделки соединений извне. Данные можно класть уже в третий пакет, поэтому рукопожатие «стоит» ровно один RTT. TCP Fast Open кладёт их даже в SYN, по куки от прошлой сессии.

Состояния: CLOSED → SYN_SENT → ESTABLISHED у клиента, LISTEN → SYN_RECEIVED → ESTABLISHED у сервера. На сервере полуоткрытые лежат в SYN queue, готовые — в accept queue длиной backlog.

Гарантии и как они обеспечиваются

Нумеруются байты. ack кумулятивный: «всё до этого номера получено». Приёмник складывает пришедшее не по порядку в буфер и отдаёт приложению только непрерывный префикс: отсюда и порядок, и head-of-line blocking. Целостность проверяет контрольная сумма (слабая, 16 бит, поэтому поверх часто ещё TLS или CRC приложения).

Ретрансмиссии

• По таймауту RTO: RTO = SRTT + 4 × RTTVAR, оценка по алгоритму Джекобсона, при повторе RTO удваивается, а по алгоритму Карна замеры по ретрансмиссиям не учитываются.
• Fast retransmit: три дублирующих ACK подряд означают «одна дырка, остальное идёт», и сегмент повторяют сразу, без таймера.
• SACK позволяет приёмнику перечислить полученные диапазоны, чтобы отправитель повторил ровно дырки, а не всё с потерянного места. На каналах с потерями это разница в разы.

Два окна

Flow control — приёмник в каждом ACK объявляет rwnd, свободное место в своём буфере. Ноль означает «замолчи», и отправитель шлёт window probe до открытия окна. Опция window scale поднимает потолок с 64 КБ до 1 ГБ, без неё быстрый канал с большим RTT не разогнать: скорость упирается в window / RTT.

Congestion control ведёт отправитель: сам оценивает состояние сети и держит cwnd. Slow start (удвоение за RTT) до ssthresh, дальше congestion avoidance (+1 MSS за RTT). При потере по трём dup ACK окно режут (Reno вдвое, CUBIC до 0,7) и продолжают (fast recovery), при таймауте cwnd = 1 и всё заново. В Linux по умолчанию CUBIC; BBR вместо потерь меряет полосу и минимальный RTT и лечит bufferbloat. В полёте разрешено min(rwnd, cwnd).

Последовательность

FIN от активной стороны (FIN_WAIT_1) → ACK от пассивной (та переходит в CLOSE_WAIT, активная — в FIN_WAIT_2) → пассивная сторона, когда её приложение тоже закроется, шлёт свой FIN (LAST_ACK) → активная подтверждает и уходит в TIME_WAIT на 2 × MSL. Между вторым и третьим пакетом соединение полузакрыто: пассивная сторона всё ещё может слать данные. Если она закрывается сразу, ACK и FIN склеиваются и пакетов получается три.

Зачем TIME_WAIT

1. Дать последнему ACK шанс дойти. Если он потеряется, пассивная сторона по таймауту повторит FIN, и кто-то должен на него ответить. Иначе она получит RST и решит, что соединение оборвалось аварийно.
2. Дать умереть заблудившимся сегментам. Сегмент старого соединения, застрявший в сети, не должен быть принят за данные нового соединения с той же пятёркой. MSL — это максимальное время жизни сегмента, а двойка нужна, потому что сегмент может блуждать в обе стороны.

Чем грозит

Сначала раздели два случая. TIME_WAIT на сервере (сервер закрывает первым, например отдаёт Connection: close) не съедает порты: порт-то один, 443. Он ест память ядра и записи в conntrack, и в масштабе сотен тысяч это заметно, но не смертельно. TIME_WAIT на клиенте гораздо злее: каждое закрытое соединение к одному (dst IP, dst port) занимает эфемерный порт на 60 секунд. При диапазоне 32768–60999 это ~28 тысяч портов, то есть потолок примерно 470 новых соединений в секунду к одному бэкенду. Дальше — EADDRNOTAVAIL, в Go connect: cannot assign requested address. Так и «внезапно ложится» сервис, который ходит к соседу без переиспользования соединений.

Как лечить, по убыванию правильности

• Переиспользовать соединения. Keep-alive и нормальный пул: http.Transport с поднятым MaxIdleConnsPerHost (дефолт всего 2!), пул к БД, один gRPC-канал на процесс. Это убирает проблему, а не маскирует.
• Обязательно дочитывать тело ответа перед Close(), иначе соединение не вернётся в пул и keep-alive не заработает.
• Пусть закрывает клиент. Настроить сервер так, чтобы он не рвал соединения первым (аккуратно с IdleTimeout и Connection: close).
• SO_REUSEADDR нужен, чтобы перезапущенный сервер сразу забиндился на порт, где остались TIME_WAIT-сокеты; Go ставит его на слушающие сокеты сам. Проблему клиентских портов не решает. SO_REUSEPORT про другое: несколько процессов слушают один порт, ядро балансирует между ними.
• Тюнинг ядра: расширить ip_local_port_range, включить tcp_tw_reuse=1. tcp_tw_recycle использовать нельзя: он ломал клиентов за общим NAT и удалён из ядра начиная с 4.12.

// SO_REUSEADDR Go ставит на слушающий сокет сам; SO_REUSEPORT — через Control
lc := net.ListenConfig{
    Control: func(network, address string, c syscall.RawConn) error {
        var opErr error
        err := c.Control(func(fd uintptr) {
            opErr = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
        })
        if err != nil { return err }
        return opErr
    },
}
ln, err := lc.Listen(context.Background(), "tcp", ":8080")

Чего нет

• Доставки: датаграмма может пропасть молча, отправитель не узнает.
• Порядка: вторая может обогнать первую.
• Дедупликации: сеть может размножить пакет, приложение получит два.
• Flow и congestion control: UDP-приложение способно утопить и приёмник, и канал, и ответственность целиком на нём. Ядро просто выбросит датаграммы, если буфер приёма полон (счётчик RcvbufErrors в netstat -su).
• Состояния: net.DialUDP ничего не открывает, он только запоминает адрес, чтобы можно было звать Write вместо WriteTo.

Что есть

Границы сообщений. Одна запись = одна датаграмма = одно чтение. Фреймер не нужен, «слипания» сообщений, как в TCP, нет. Цена: если буфер чтения меньше датаграммы, хвост просто отрезается. Плюс multicast и broadcast, которых в TCP нет в принципе.

conn, _ := net.ListenPacket("udp", ":9000")
buf := make([]byte, 65535)               // берём с запасом: короткий буфер отрежет хвост
for {
    n, addr, err := conn.ReadFrom(buf)   // ровно одна датаграмма за вызов
    if err != nil {
        if errors.Is(err, net.ErrClosed) { return }
        continue                         // прочие ошибки чтения на UDP обычно не фатальны
    }
    go handle(conn, addr, append([]byte(nil), buf[:n]...)) // копия: buf перезапишет следующий ReadFrom
}

Практический размер

Датаграмма теоретически вмещает до 65507 байт, но всё, что больше MTU, фрагментируется на IP-уровне, и потеря одного фрагмента убивает всю датаграмму. Поэтому в реальных протоколах держатся в пределах ~1400 байт: DNS до EDNS0 вообще ограничивал ответ 512 байтами, а QUIC сам следит за размером пакета.

TCP keep-alive

Когда в соединении тишина дольше tcp_keepalive_time, ядро шлёт пустой пробный сегмент. Если после tcp_keepalive_probes попыток с интервалом tcp_keepalive_intvl ответа нет, соединение объявляется мёртвым, приложение получает ошибку. В Linux по умолчанию 7200 секунд, то есть два часа, и толку от этого почти нет, поэтому значение всегда переопределяют на уровне сокета. Реальных задач две: во-первых, обнаружить пира, который умер молча (выдернули провод, упала виртуалка, и FIN никто не прислал); во-вторых, не дать NAT или файрволу выбросить запись о сессии по таймауту неактивности.

HTTP keep-alive

В HTTP/1.0 нужно было явно просить Connection: keep-alive; в HTTP/1.1 соединение постоянное по умолчанию, а закрыть его просят через Connection: close. Так не приходится платить за TCP- и TLS-рукопожатие в каждом запросе: экономятся два RTT на запрос, и не тянется шлейф TIME_WAIT. В HTTP/2 и HTTP/3 отдельной такой настройки нет: там соединение изначально долгоживущее и мультиплексированное.

// сервер: свои таймауты и время жизни простаивающего соединения
srv := &http.Server{
    ReadHeaderTimeout: 5 * time.Second,
    ReadTimeout:       15 * time.Second,
    WriteTimeout:      30 * time.Second,
    IdleTimeout:       120 * time.Second, // сколько держим keep-alive без запросов
}
// srv.SetKeepAlivesEnabled(false) выключает HTTP keep-alive, например перед graceful shutdown

HOL в HTTP/1.1

В одном соединении ответы обязаны идти в порядке запросов. Медленный первый ответ держит остальные. Конвейеризация (pipelining) позволяла слать запросы, не дожидаясь ответов, но порядок ответов оставался жёстким: выигрыша почти не было, а багов в прокси набралось много, и во всех браузерах её выключили. Реальным обходом стали 6 параллельных соединений на домен и доменный шардинг.

HOL в TCP

Этот HOL сидит уровнем ниже, и прикладной протокол его не лечит. TCP гарантирует порядок, значит, при потере сегмента все пришедшие после него данные лежат в буфере приёма и не отдаются приложению, пока дырка не будет закрыта ретрансмиссией. Простой выходит минимум на один RTT, даже если приложению те, «застрявшие», байты были нужны прямо сейчас и относились к другому логическому запросу.

Цепочка, которую хотят услышать

• HTTP/2 мультиплексирует независимые потоки внутри одного TCP-соединения и убирает HOL прикладного уровня: ответы приходят вперемешку, порядок не важен.
• Но, сложив всё в одно TCP-соединение, HTTP/2 сделал транспортный HOL больнее: потеря одного пакета останавливает все потоки сразу. В HTTP/1.1 с шестью соединениями встали бы запросы только одного из них. На плохой сети HTTP/2 иногда проигрывает HTTP/1.1 именно поэтому.
• QUIC (HTTP/3) решает обе проблемы: он поверх UDP, и порядок доставки у каждого потока свой — номера пакетов и подтверждения общие на соединение, но потерянные байты задерживают только свой поток. Потеря пакета тормозит только тот поток, чьи байты потерялись; остальные едут дальше.

Запрос

POST /api/v1/orders?dry=1 HTTP/1.1     <- стартовая строка: метод, target, версия
Host: api.example.com                  <- обязателен в 1.1, иначе 400
Content-Type: application/json
Content-Length: 21
Authorization: Bearer eyJhbGciOi...
X-Request-Id: 0f1c-88ad-...
                                       <- ПУСТАЯ строка = конец заголовков
{"sku":"A-1","qty":2}

Строки разделяются строго \r\n (CRLF), а не \n. Регистр имён заголовков не важен (content-type == Content-Type), и в Go http.Header приводит имя к канонической форме (X-Request-Id). Это аукнется, если лезешь руками в map[string][]string: ключ "x-request-id" там не найдётся, нужен Header.Get.

Ответ

HTTP/1.1 201 Created                   <- версия, код, reason phrase (в HTTP/2 её нет вообще)
Content-Type: application/json; charset=utf-8
Location: /api/v1/orders/42
Transfer-Encoding: chunked

18
{"id":42,"status":"new"}
0
                                       <- нулевой чанк = конец тела

Где кончается тело — три варианта

• Content-Length: N велит прочитать ровно N байт. Длину надо знать заранее, то есть сначала собрать весь ответ.
• Transfer-Encoding: chunked режет тело на куски «длина в hex, CRLF, данные», а конец отмечает чанк нулевой длины. Нужен для стриминга, когда длина неизвестна: логи, SSE, выгрузка большой таблицы. В Go включается сам, если ты не поставил Content-Length и данных больше буфера.
• Закрытие соединения — легаси из HTTP/1.0: тело кончается там, где кончился TCP. Несовместимо с keep-alive.

Чем добить

В HTTP/2 стартовой строки нет: метод, схема, авторитет и путь стали псевдозаголовками :method, :scheme, :authority, :path, а у ответа есть :status. Reason phrase («Not Found» после 404) выбросили за ненадобностью. Имена заголовков в HTTP/2 пишутся только в нижнем регистре, прописная буква считается протокольной ошибкой.

Почему PUT идемпотентен, а POST нет

PUT /orders/42 означает «пусть по этому адресу лежит вот такое представление». Повтори хоть десять раз, состояние останется тем же. POST /orders означает «обработай вот эти данные», и адрес сервер выбирает сам, поэтому десять повторов дают десять заказов. Вот почему клиенты и прокси вправе автоматически ретраить GET/PUT/DELETE при сетевой ошибке, а POST нет.

Как сделать POST идемпотентным на практике

Через ключ идемпотентности: клиент генерирует UUID и шлёт его в заголовке Idempotency-Key. Сервер в транзакции пытается вставить этот ключ в таблицу с уникальным индексом. Если вставка прошла, он выполняет операцию и сохраняет рядом результат; если ключ уже есть, возвращает сохранённый ответ и ничего не выполняет. Так делают Stripe, YooKassa и все платёжные API. Ключ живёт с TTL (сутки-неделя). Тонкое место: состояние «ключ вставлен, но операция ещё выполняется». Второй запрос в этот момент должен получить 409 или подождать, а не начать вторую операцию.

2xx

• 200 OK — успех с телом.
• 201 Created: ресурс создан, обычно с заголовком Location на его адрес.
• 202 Accepted: приняли в обработку, результата ещё нет. Правильный код для асинхронных операций, к нему отдаём Location на статус-ресурс.
• 204 No Content — успех без тела (удаление, PUT без возврата). Тело писать нельзя вообще.
• 206 Partial Content отвечает на Range: докачка и стриминг видео.

3xx

• 301 Moved Permanently переносит навсегда, браузеры кэшируют его агрессивно и надолго. Ошибёшься — пользователи месяцами будут ходить на старый адрес, пока не почистят кэш.
• 302 Found / 307 Temporary Redirect переносят временно. Разница в том, что при 301/302 браузеры исторически меняли POST на GET, а 307 и 308 обязаны сохранять метод и тело. Нужен предсказуемый редирект — бери 307/308.
• Go 1.26 переехал на 307 в стандартном роутере. Раньше, когда net/http.ServeMux сам перекидывал /x на зарегистрированный /x/, он отдавал 301. Это была мина: 301 браузер кэширует практически навсегда, и после переделки роутов пользователь всё равно шёл по старому адресу, пока не почистит кэш, а POST по дороге превращался в GET. С Go 1.26 здесь уходит 307: он не кэшируется и сохраняет метод с телом. Хорошая иллюстрация того, почему «навсегда» в вебе стоит дороже всего.
• 303 See Other говорит «сходи туда методом GET»: канонический ответ на POST по паттерну Post/Redirect/Get, чтобы F5 не отправил форму дважды.
• 304 Not Modified — ответ на условный запрос: тела нет, бери из кэша.

4xx — где ошибаются чаще всего

• 400 Bad Request — запрос синтаксически сломан: не распарсился JSON, не тот тип поля.
• 401 Unauthorized на самом деле значит «не аутентифицирован»: токена нет, он протух или подпись не сошлась. Обязан идти с WWW-Authenticate. Клиенту есть смысл обновить токен и повторить.
• 403 Forbidden: «кто ты, понятно, но тебе нельзя». Повтор с тем же токеном бессмыслен. Путаница 401/403 остаётся самым частым ляпом в API.
• 404 Not Found: ресурса нет. Иногда его намеренно отдают вместо 403, чтобы не подтверждать чужому пользователю, что объект существует.
• 405 Method Not Allowed — путь есть, метод не тот; обязателен Allow.
• 409 Conflict означает конфликт с текущим состоянием: оптимистическая блокировка не сошлась, дубликат по уникальному ключу, попытка повторно оплатить оплаченный заказ.
• 412 Precondition Failed приходит, когда не выполнилось условие If-Match: ресурс изменили между чтением и записью.
• 422 Unprocessable Content: JSON валидный и разобрался, но бизнес-валидация не прошла («qty должен быть больше нуля»). Разница с 400: синтаксис против семантики. Это соглашение, а не жёсткое требование, но команды его любят.
• 429 Too Many Requests — рейт-лимит. Отдавай его с Retry-After, иначе клиенты начнут долбить сильнее и устроят тебе метастабильный отказ.

5xx

• 500 Internal Server Error: «мы сломались», в 99% случаев из-за необработанной паники или неожиданной ошибки. Деталей клиенту наружу не отдаём.
• 502 Bad Gateway отдаёт прокси, который сходил на апстрим и получил мусор или разрыв. Смотри бэкенд.
• 503 Service Unavailable — временно не можем: перегрузка, деплой, отключён брейкером. Вместе с ним правильно отдавать Retry-After.
• 504 Gateway Timeout: прокси не дождался апстрима. Классика: у nginx таймаут 60 с, а запрос идёт 90 с.

Content-Type и Accept

Content-Type: application/json; charset=utf-8 описывает текущее тело, Accept: application/json говорит, что клиент хочет в ответ (content negotiation). Не умеет сервер отдать запрошенный тип, отвечает 406; не понимает присланный — 415 Unsupported Media Type. На практике Content-Type из запроса решает, парсить форму или JSON, а без него браузер может начать MIME sniffing: угадает тип по содержимому и превратит загруженную картинку в исполняемый HTML. Лечится X-Content-Type-Options: nosniff.

Authorization

Схемы: Basic base64(user:pass) (только поверх TLS, пароль летит фактически открытым), Bearer <token> (JWT или opaque-токен, стандарт для API), Digest (легаси). Инфраструктуру он тоже задевает: с Authorization в запросе общим кэшам по умолчанию запрещено кэшировать ответ. И целиком этот заголовок в логи не пишут, только префикс или хэш.

X-Request-Id и трассировка

Балансировщик или самый первый сервис генерирует идентификатор запроса, кладёт в X-Request-Id и пишет в каждую строку лога. Дальше он прокидывается во все исходящие вызовы, в сообщения в брокер, в атрибуты спанов. Так по одной строке из тикета пользователя собирают весь путь запроса через десяток сервисов. Стандартом сейчас стал traceparent из W3C Trace Context (OpenTelemetry), но X-Request-Id живёт практически везде.

// Middleware: взять входящий id или создать свой, положить в контекст
func RequestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := r.Header.Get("X-Request-Id")
        if id == "" {
            id = uuid.New().String()   // Go 1.27: uuid уже в стандартной библиотеке
        }
        w.Header().Set("X-Request-Id", id)                 // вернём клиенту
        ctx := context.WithValue(r.Context(), ctxKeyReqID, id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

Куки

Сервер ставит Set-Cookie: sid=abc; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400, браузер потом сам шлёт Cookie: sid=abc на каждый подходящий запрос. Атрибуты:

• HttpOnly: JS не видит куку через document.cookie, и при XSS сессию не украсть.
• Secure — отправляется только по HTTPS.
• SameSite бывает Strict (вообще не отправлять при переходах с чужих сайтов), Lax (отправлять при обычной навигации по ссылке, но не при POST/iframe/img; дефолт в Chrome) и None (отправлять всегда, обязателен Secure). Это главная встроенная защита от CSRF.
• Domain / Path — область видимости; Max-Age / Expires — срок жизни, без них кука сессионная и живёт до закрытия браузера.

Что было в 1.1

Keep-alive (дефолт с 1.1) оставляет TCP открытым после ответа, чтобы заново не платить за рукопожатие и медленный старт. Pipelining разрешает слать несколько запросов, не дожидаясь ответов, но отвечать сервер обязан строго по порядку. Поэтому один медленный запрос запирает все следующие: это и есть HOL-блокировка прикладного уровня. Вдобавок кривые прокси ломали порядок, и браузеры конвейеризацию отключили — на практике её нет. Обходились «шардированием доменов» (img1.site.com, img2.site.com), склейкой CSS/JS и спрайтами. С HTTP/2 эти костыли стали вредны.

Что принёс HTTP/2

• Бинарный фрейминг. Вместо текста идут фреймы фиксированной структуры: HEADERS, DATA, SETTINGS, WINDOW_UPDATE, RST_STREAM, GOAWAY, PING. Парсится однозначно и быстро.
• Мультиплексирование. У каждого запроса свой stream id, фреймы разных потоков чередуются в одном соединении и собираются на той стороне. Сотне параллельных запросов хватает одного TCP-соединения и одного TLS-хендшейка.
• HPACK. Сжимает заголовки статической таблицей (61 частый заголовок), динамической таблицей на соединение и кодом Хаффмана. Повторные Cookie и User-Agent схлопываются до пары байт, а в 1.1 они летели целиком в каждом запросе.
• Приоритеты и управление потоком на уровне отдельных стримов (WINDOW_UPDATE), Server Push (оказался неудачным и де-факто мёртв).

Четыре вещи, которые QUIC решает

• HOL на транспорте. Порядок и восстановление потерь у каждого стрима свои, и потерянный пакет стрима A не задерживает данные стрима B.
• Стоимость установки. TCP+TLS 1.3 обходятся в 2 RTT (1 на SYN, 1 на TLS). QUIC совмещает транспортное и криптографическое рукопожатие в 1 RTT, а при возобновлении по билету данные летят в первом же пакете, за 0 RTT.
• Смена сети. Соединение опознаётся не по пятёрке адрес/порт, а по connection ID. Переключился с Wi-Fi на LTE, IP сменился, а соединение живо: ни рукопожатия заново, ни обрыва загрузки.
• Окостенение (ossification). TCP нельзя развивать: промежуточные железки режут незнакомые опции. QUIC шифрует почти весь заголовок, включая номера пакетов, поэтому middlebox видит только UDP и не мешает эволюции.

Цена

• Процессор. Пакеты обрабатываются в userspace, а не в ядре: нет разгрузки на сетевую карту (частично её сейчас дают UDP GSO/GRO), больше системных вызовов. Раньше разрыв был в 2–3 раза, сейчас заметно меньше, но он есть.
• UDP местами режут. Корпоративные файрволы и некоторые провайдеры блокируют UDP/443, поэтому нужен фолбэк на TCP: сервер объявляет поддержку заголовком Alt-Svc: h3=":443", а клиент пробует оба варианта.
• Инструменты. Привычный tcpdump покажет только шифрованный UDP; отладка требует ключей и свежих версий Wireshark.

Рукопожатие TLS 1.3 по шагам

1. ClientHello: версии, список шифронаборов, поддерживаемые группы, SNI (какой домен нужен), ALPN (h2/http1.1) и сразу key_share, долю ключа для той группы, которую клиент угадал.
2. ServerHello: выбранный шифронабор и свой key_share. С этого момента обе стороны уже могут вычислить общий секрет, и всё дальнейшее шифруется.
3. Сервер шифрованно шлёт Certificate, CertificateVerify (подписывает хэш всего рукопожатия приватным ключом и так доказывает владение) и Finished.
4. Клиент проверяет цепочку и подпись, шлёт Finished и в том же полёте может слать HTTP-запрос. Итого 1 RTT.

Если клиент не угадал группу, сервер отвечает HelloRetryRequest, и рукопожатие стоит 2 RTT. В TLS 1.2 полное рукопожатие — 2 RTT, есть RSA key transport без forward secrecy и живы CBC-режимы, на которые пришлась половина известных атак. TLS 1.3 всё это выкинул: осталось пять шифронаборов, все с AEAD, а обмен ключами только эфемерный, с forward secrecy (её нет лишь у возобновления по одному PSK и у 0-RTT).

Цепочка доверия

Сертификат X.509 связывает домен с публичным ключом и подписан удостоверяющим центром. Клиент строит цепочку (лист → промежуточный → корень из хранилища ОС/браузера) и проверяет подписи, сроки, соответствие имени полю SAN (Common Name как имя не используется с 2017 года), назначение ключа и отзыв (CRL; OCSP уходит — Let's Encrypt выключил его в 2025 году). Корневые ключи держат офлайн и подписывают ими только промежуточные, поэтому сервер обязан отдавать промежуточный.

SNI и mTLS

SNI несёт имя домена открытым текстом в ClientHello. Без него на одном IP не удержать много сайтов с разными сертификатами: сервер не знает, какой предъявить. Побочный эффект: наблюдателю видно, куда ты идёшь. Закрывает это расширение ECH.

В mTLS (взаимный TLS) сертификат предъявляет и клиент, а сервер проверяет его по своему пулу CA. Где применяется: межсервисный трафик в service mesh (Istio, Linkerd делают это прозрачно через сайдкар), доступ к Kubernetes API, банковские и платёжные интеграции, IoT, доступ к внутренним системам вместо VPN (модель BeyondCorp). Плюс: аутентификация без паролей и токенов, личность привязана к криптографии. Минус: свой PKI, то есть выпуск, распространение, ротация (в mesh автоматом каждые 24 часа) и отзыв.

// Сервер, требующий клиентский сертификат
srv := &http.Server{
    Addr: ":8443",
    TLSConfig: &tls.Config{
        MinVersion: tls.VersionTLS12,
        ClientAuth: tls.RequireAndVerifyClientCert, // не Request и не Verify...IfGiven
        ClientCAs:  clientCAPool,
    },
}
// Клиент с внутренним CA вместо InsecureSkipVerify
cfg := &tls.Config{RootCAs: internalPool, MinVersion: tls.VersionTLS12}

Как кэш принимает решение

1. Есть ли запись по ключу (URL + заголовки из Vary)? Нет — идём в сеть.
2. Свежа ли она (возраст меньше max-age / до Expires)? Если да, отдаём мгновенно, в сеть не ходим вообще.
3. Протухшую не выбрасываем, а делаем условный запрос с If-None-Match (или If-Modified-Since). На 304 продлеваем свежесть и отдаём старое тело, на 200 заменяем.

Директивы, которые путают

• no-cache не значит «не кэшировать». Кэшировать можно, но перед каждой отдачей обязательна ревалидация.
• А вот no-store значит «вообще не сохранять». Для персональных данных и страниц с токенами.
• private пускает только в браузер, не в CDN. public пускает и в общие кэши (и даже перебивает запрет для ответов с Authorization, штука опасная).
• immutable — не перепроверять никогда: для файлов с хэшем в имени.
• stale-while-revalidate=30: отдать протухшее сразу, а обновить фоном.

ETag против Last-Modified

ETag несёт хэш или версию содержимого и точен побайтово; W/"..." помечает слабый, «то же по смыслу». Last-Modified несёт время с точностью до секунды и два изменения внутри одной секунды не различит. Если есть оба, приоритет у ETag. Бонусом тот же механизм даёт оптимистическую блокировку на запись: If-Match: "9a1f3c", и при несовпадении сервер отвечает 412, а не затирает чужие изменения.

Шесть ограничений и что каждое даёт

Stateless — что это значит на практике

Это не значит «состояния нет вообще»: данные в базе никуда не деваются. Речь про состояние сессии клиента на конкретном инстансе. Всё нужное запрос обязан нести сам: токен вместо «сервер помнит, что ты залогинен», курсор пагинации вместо «сервер помнит, где ты остановился». Взамен любой инстанс обрабатывает любой запрос, sticky session не нужен, падение узла не рвёт работу пользователя, ретрай безопасен, а автоскейл честный.

Ресурс, представление, URI

• Ресурс — сущность с идентичностью: «заказ 42». Представлением называют то, как её сериализовали сейчас: JSON, XML, CSV, PDF. Один URI отдаёт много представлений, нужное клиент выбирает через Accept.
• URI именует существительное, а не действие. /orders/42 годится, а /getOrder?id=42 уже RPC в URL-костюме.
• Коллекция и элемент: /orders и /orders/42. Множественное число никто не требует, это соглашение, но полезное.
• Вкладывай не глубже одного уровня: /orders/42/items. Дальше (/users/7/orders/42/items/3/comments) начинается ад: элемент всё равно адресуется своим id, а длинные пути ломают кэш и роутинг.

RESTful vs REST-like

RESTful соблюдает все ограничения, включая гипермедиа: уровень 3. У REST-like есть ресурсные URI, корректные методы и статус-коды, но переходы клиент знает из документации, а не из ответов: уровень 2. Индустрия живёт на уровне 2, потому что там всё окупается: кэш, идемпотентность, ретраи и понятность для прокси уже есть, а гипермедиа машинному клиенту обходится дорого.

Одна и та же задача в двух моделях

# REST: состояние ресурса
GET    /orders/42            -> 200 Order
POST   /orders               -> 201 + Location
PATCH  /orders/42            -> 200
DELETE /orders/42            -> 204

# «отменить» тоже состояние:
PATCH  /orders/42
{"status": "cancelled"}
# или ресурс-действие:
POST   /orders/42/cancellation

# RPC: список процедур
POST /OrderService/GetOrder
POST /OrderService/CreateOrder
POST /OrderService/UpdateOrder
POST /OrderService/DeleteOrder
POST /OrderService/CancelOrder
POST /OrderService/RecalculateTotals
POST /OrderService/SendReceiptEmail
# в gRPC то же самое, но с контрактом
# и бинарным телом

Посмотри на нижние строки правой колонки: RecalculateTotals и SendReceiptEmail в RPC ложатся естественно, а в REST их приходится придумывать как ресурсы. Это честная слабость REST, и, признав её, ты только выиграешь. Обратный пример: «отдай мне заказ, и пусть CDN его закэширует на 5 минут». В REST хватит одной строки заголовка, в RPC нужна отдельная инфраструктура.

Разница в том, где живёт семантика

• REST: семантика в протоколе. Посредник (прокси, CDN, WAF, балансировщик) видит GET /orders/42 и знает: это чтение, безопасно, идемпотентно, кэшируемо, можно ретраить. Ему не нужен твой контракт.
• RPC: семантика в контракте. Для посредника любой вызов выглядит как POST с непрозрачным телом. Не зная твоего .proto, он не может ни ретраить, ни кэшировать, ни маршрутизировать по смыслу.
• Отсюда и практическое правило: наружу — REST (открываемость, кэш, любой клиент), внутрь — RPC/gRPC (контракт, скорость, стриминг).

Может ли REST жить не поверх HTTP

Может: в диссертации HTTP ни разу не назван обязательным. Требуются идентификаторы ресурсов, единообразный набор операций с описанной семантикой, самоописывающиеся сообщения, statelessness, явная кэшируемость, слоистость.

• CoAP (RFC 7252) даёт самый чистый пример: GET/POST/PUT/DELETE, URI вида coap://device/sensors/temp, коды ответов «2.05 Content», «4.04 Not Found», кэширование по Max-Age, подписки через Observe. Работает поверх UDP, потому что рассчитан на устройства с батарейкой и каналом в килобиты.
• Поверх брокера (AMQP, MQTT, NATS): метод и путь кладут в свойства сообщения, а ответ шлют в reply-to. Формально похоже на REST, по сути это уже самодельный протокол.

Почему всё равно HTTP? Он уже даёт URI, глаголы с зафиксированной семантикой, коды ответов, согласование содержимого, условные запросы, диапазоны, сжатие, а главное, планетарную кэш-инфраструктуру и инструменты, которые понимают всё это без твоего участия. Вне HTTP всё это пишут руками, и обычно хуже.

Кэш: почему у REST он бесплатный

• Ключом кэша служит URI плюс заголовки из Vary. У RPC ключа нет: у всех вызовов один путь и разные тела, а тело в ключ кэша не входит.
• GET объявлен безопасным и идемпотентным, поэтому кэшировать его можно по умолчанию. POST кэшируем только в теории и практически никем.
• Условные запросы (ETag + If-None-Match → 304) дают почти бесплатную ревалидацию: 150 байт вместо мегабайта.
• Уровни кэша складываются: браузер → Service Worker → CDN → реверс-прокси → кэш приложения. Каждый снимает часть нагрузки, и ни один не знает про твой код.

В RPC/gRPC всё это делают вручную: кэш в Redis по ключу из имени метода и полей запроса, своя логика инвалидации, TTL своими руками. Исключения есть: кэшируемые методы можно объявить через google.api.http и выставить наружу как GET через grpc-gateway. Но это уже трансляция в REST, а не кэш gRPC.

Балансировка: где именно ломается

1. Клиент открывает одно TCP-соединение. L4-балансировщик выбирает бэкенд по 5-кортежу (src IP, src port, dst IP, dst port, протокол) и делает это один раз.
2. gRPC мультиплексирует в этом соединении сотни потоков. Все они, естественно, идут на выбранный бэкенд.
3. Соединение живёт часами: gRPC его не рвёт, а keepalive-пинги не дают закрыться.
4. В итоге один под получает весь трафик клиента, остальные простаивают. Отскейлились с 3 подов до 30, а нагрузка не перераспределилась: никто не переподключался.

Решения и их цена

// 1. Сервер: не давать соединениям жить вечно + защита от «пинг-флуда»
srv := grpc.NewServer(
    grpc.KeepaliveParams(keepalive.ServerParameters{
        MaxConnectionAge:      30 * time.Minute, // потом GOAWAY
        MaxConnectionAgeGrace: 5 * time.Minute,  // доиграть текущие RPC
        Time:                  2 * time.Minute,  // пинг простаивающему клиенту
        Timeout:               20 * time.Second,
    }),
    grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{
        MinTime:             1 * time.Minute,
        PermitWithoutStream: true,
    }),
)

// 2. Клиент: сам балансирует через headless service.
// dns:/// отдаёт все A-записи; перечитывает их резолвер при обрыве, а не по таймеру.
conn, err := grpc.NewClient(
    "dns:///orders.default.svc.cluster.local:9000",
    grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[{"round_robin":{}}]}`),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

Терминология, на которой путаются

Swagger — исторический бренд: в конце 2015 года спецификацию Swagger передали в Linux Foundation, а с 2016-го она называется OpenAPI (3.0, 3.1, 3.2). Сейчас «Swagger» зовут инструменты (Swagger UI, Swagger Editor, Swagger Codegen), а формат называется OpenAPI. Главное в 3.1: он стал полностью совместим с JSON Schema 2020-12, так что одна схема годится и для валидации, и для документации.

Что реально даёт спека

• Документация без ручной работы в Swagger UI, Redoc, Scalar. Уже одно это окупает спеку.
• Кодогенерация клиентов для всех потребителей: фронтенд, мобилки, соседние команды. В Go есть oapi-codegen (умеет и сервер: типы, роутинг, валидацию под chi/echo/gin/std).
• Валидация на входе из схемы, а не из руками написанных if-ов. Меньше кода, меньше расхождений документации с поведением.
• Моки для фронтенда (Prism, WireMock): фронт пишут, не дожидаясь бэкенда.
• Контрактные тесты и diff в CI: oasdiff breaking --fail-on ERR валит пайплайн, если удалили поле или сузили enum. Так спека из документа становится инструментом.
• Импорт в шлюзы: Kong, APIM, AWS API Gateway настраиваются прямо из OpenAPI.

Contract-first против code-first

# contract-first в Go: генерируем типы + серверный интерфейс + валидацию
oapi-codegen -generate types,chi-server,spec -package api \
             -o internal/api/api.gen.go openapi.yaml

# CI проверяет обратную совместимость
oasdiff breaking origin/main:openapi.yaml openapi.yaml --fail-on ERR

Что происходит при вызове

1. Сгенерированный клиент сериализует запрос в protobuf.
2. Открывается новый поток в уже существующем HTTP/2-соединении. Летят HEADERS: :method: POST, :path: /order.v1.OrderService/GetOrder, content-type: application/grpc, te: trailers, дедлайн в grpc-timeout, метаданные пользователя.
3. DATA-фреймы несут «length-prefixed message»: 1 байт флага сжатия + 4 байта длины big-endian + сами байты сообщения. Если сообщений несколько, это и есть стриминг.
4. Ответ приходит так же, а результат вызова лежит в трейлерах после тела: grpc-status: 0, при ошибке ещё grpc-message и grpc-status-details-bin.

Откуда берётся скорость — по пунктам

Трезвая оценка: на межсервисном вызове «получить объект по id» gRPC выигрывает единицы миллисекунд, а по трафику в разы. Если ручка делает три запроса в базу на 20 мс, выигрыш утонет. Поэтому правильный ответ всегда уточняет: «быстрее в чём и при каких условиях».

Минимальный сервер и клиент в Go

// сервер
type server struct {
    orderv1.UnimplementedOrderServiceServer // обязательно: даёт forward-совместимость
    repo *Repo
}

func (s *server) GetOrder(ctx context.Context, req *orderv1.GetOrderRequest) (*orderv1.Order, error) {
    o, err := s.repo.Get(ctx, req.GetId())      // GetXxx() безопасен для nil-приёмника
    if errors.Is(err, ErrNotFound) {
        return nil, status.Errorf(codes.NotFound, "order %d not found", req.GetId())
    }
    if err != nil {
        return nil, status.Error(codes.Internal, "internal error") // без утечки деталей наружу
    }
    return toProto(o), nil
}

func main() {
    lis, _ := net.Listen("tcp", ":9000")
    s := grpc.NewServer(grpc.ChainUnaryInterceptor(logging, recovery, metrics))
    orderv1.RegisterOrderServiceServer(s, &server{repo: repo})
    reflection.Register(s) // чтобы grpcurl/Postman видели схему; в проде только внутри периметра
    _ = s.Serve(lis)
}

// клиент: NewClient не подключается сразу, соединение ленивое
conn, err := grpc.NewClient("orders:9000", grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil { return err }
defer conn.Close()

cli := orderv1.NewOrderServiceClient(conn)

ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
defer cancel()

o, err := cli.GetOrder(ctx, &orderv1.GetOrderRequest{Id: 42})
if st, ok := status.FromError(err); ok && st.Code() == codes.NotFound {
    // здесь обрабатываем именно NotFound
}

Разбор конкретного сообщения

message User {
  int32  id   = 1;
  string name = 2;
}
// id = 300, name = "Go"   ->   08 AC 02 12 02 47 6F   (7 байт)

08 = 0000 1000 -> номер поля 1, wire type 0 (VARINT)
AC = 1010 1100 -> старший бит 1: читаем дальше; полезные 7 бит = 0101100
02 = 0000 0010 -> старший бит 0: конец числа;   полезные 7 бит = 0000010
     значение = (0000010 << 7) | 0101100 = 256 + 44 = 300
12 = 0001 0010 -> номер поля 2, wire type 2 (LEN)
02 -> длина 2
47 6F -> "Go"

// то же в JSON: {"id":300,"name":"Go"} = 22 байта, и это без пробелов

Из разбора видно: младшая группа varint идёт первой (little-endian по 7-битным группам), а числа 0–127 занимают ровно один байт. Ключ тоже varint: пока номер поля не больше 15, ключ влезает в один байт (15<<3|7 = 127), а с номера 16 занимает два. Поэтому в проектных гайдлайнах номера 1–15 берегут для полей, которые есть в каждом сообщении, а редкие поля нумеруют от 16.

Wire types и типы данных

Эволюция схемы

message Order {
  int64  id       = 1;
  string customer = 2;
  int64  amount   = 3;

  reserved 4, 7 to 9;          // номера, которые больше нельзя занимать
  reserved "discount", "promo"; // и имена, чтобы не сломать JSON-представление

  optional string coupon = 10;  // explicit presence: отличаем "" от «не задано»
}

Ещё две тонкости proto3, которые любят спрашивать. Первая: нет различия «ноль» и «не задано» у скаляров, нулевые значения на провод вообще не пишутся. Отсюда проблема с частичным обновлением («сбросить скидку в 0» неотличимо от «не трогать»), её решают через optional, обёртки (google.protobuf.Int32Value) или FieldMask. Вторая: protobuf не детерминирован. Порядок полей и кодирование map не гарантированы между реализациями и версиями, поэтому байты protobuf не годятся ни в ключ кэша, ни во вход хэша, ни в основу цифровой подписи.

Где применяется, кроме gRPC

• События в Kafka/Pulsar вместе со Schema Registry: компактно и с контролем совместимости схем (как альтернативу берут Avro, у которого схема эволюционирует по именам, а не по номерам).
• В Prometheus remote write метрики едут в protobuf поверх HTTP, сжатые snappy.
• Envoy xDS — вся динамическая конфигурация service mesh описана в protobuf.
• Кэши и хранилища, где важен размер значения; в Redis это заметно на десятках миллионов ключей.
• Мобильные и IoT-протоколы, где трафик стоит денег и батарейки.
• Форматы файлов: например, OSM PBF для карт, tfrecord-подобные форматы в ML.

Как объявляются и когда какой

Server streaming в Go

// сервер: шлём заказы потоком, пока клиент не отменил
func (s *server) ListOrders(req *orderv1.ListOrdersRequest, stream orderv1.OrderService_ListOrdersServer) error {
    rows, err := s.repo.Cursor(stream.Context(), req.GetFilter())
    if err != nil { return status.Error(codes.Internal, "query failed") }
    defer rows.Close()

    for rows.Next() {
        select {
        case <-stream.Context().Done(): // клиент ушёл или сработал дедлайн
            return status.FromContextError(stream.Context().Err()).Err()
        default:
        }
        if err := stream.Send(toProto(rows.Order())); err != nil {
            return err // соединение оборвалось, отдаём наверх без обёртки
        }
    }
    return rows.Err()
}

// клиент: поток заканчивается io.EOF, и это не ошибка
st, err := cli.ListOrders(ctx, &orderv1.ListOrdersRequest{})
if err != nil { return err }
for {
    o, err := st.Recv()
    if errors.Is(err, io.EOF) { break }   // нормальное завершение
    if err != nil { return err }          // всё остальное — ошибка
    handle(o)
}

Client streaming и bidirectional

// client streaming: клиент шлёт N, получает 1 итог
up, _ := cli.ImportOrders(ctx)
for _, o := range batch {
    if err := up.Send(o); err != nil { break } // при ошибке Send настоящую причину даст CloseAndRecv
}
summary, err := up.CloseAndRecv()

// bidirectional: запись и чтение в разных горутинах, не вперемешку
stream, _ := cli.Watch(ctx)
go func() {
    for ev := range outbox {
        if err := stream.Send(ev); err != nil { return }
    }
    _ = stream.CloseSend() // «я больше не пишу», но продолжаю читать
}()
for {
    ev, err := stream.Recv()
    if errors.Is(err, io.EOF) { break }
    if err != nil { return err }
    apply(ev)
}

Дедлайн, а не таймаут — и почему это важно

Клиент передаёт не «дай мне 300 мс», а «истекает через 300 мс от сейчас». Сервер получает grpc-timeout: 300m, кладёт дедлайн в ctx, а вызывая следующий сервис, передаёт тот же ctx, то есть оставшееся время. Если A дал 300 мс, B потратил 250 на базу, то C получит 50 мс и, скорее всего, сразу вернёт DeadlineExceeded, не тратя ресурсы впустую. Так цепочка обрывается вся разом, а не каскадом наложенных друг на друга таймаутов.

// дедлайн задаёт вызывающий, а не сервер
ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
defer cancel()
resp, err := cli.GetOrder(ctx, req)
if status.Code(err) == codes.DeadlineExceeded { /* сюда попадём ровно через 300 мс */ }

// сервер проверяет остаток и передаёт контекст дальше
func (s *server) GetOrder(ctx context.Context, req *orderv1.GetOrderRequest) (*orderv1.Order, error) {
    if dl, ok := ctx.Deadline(); ok && time.Until(dl) < 20*time.Millisecond {
        return nil, status.Error(codes.DeadlineExceeded, "not enough time left") // fail fast
    }
    o, err := s.repo.Get(ctx, req.GetId()) // ctx уходит в database/sql, запрос отменится сам
    ...
}

Отмена работает симметрично: если клиент вызвал cancel() или ушёл, gRPC шлёт RST_STREAM, а сервер видит ctx.Done() и context.Canceled. Отсюда разница в кодах: Canceled — отменил клиент, DeadlineExceeded — вышло время. Первое обычно не считают ошибкой сервиса и не алертят по нему, а второе считают.

Метаданные

// клиент кладёт метаданные в исходящий контекст
ctx = metadata.AppendToOutgoingContext(ctx,
    "authorization", "Bearer "+token,
    "x-request-id", reqID,
    "x-trace-bin", string(traceBytes)) // суффикс -bin => значение бинарное, поедет в base64

// сервер читает входящие
md, ok := metadata.FromIncomingContext(ctx)
vals := md.Get("x-request-id")

// заголовки (до тела) и трейлеры (после тела)
var header, trailer metadata.MD
resp, err := cli.GetOrder(ctx, req, grpc.Header(&header), grpc.Trailer(&trailer))

Имена ключей приводятся к нижнему регистру, ключи с суффиксом -bin несут бинарь и кодируются base64, а префикс grpc- зарезервирован. Через метаданные передают аутентификацию, трассировку, идемпотентность, версию клиента и локаль, то есть всё сквозное, чему не место в теле сообщения.

Коды ошибок и их маппинг на HTTP

Интерцепторы

Это middleware gRPC, и их два независимых семейства: unary и stream. Одну и ту же функцию на оба не навесишь. Об этом регулярно забывают, и стриминговые методы остаются без логов, метрик и recovery.

// unary-интерцептор: логи + метрики + recovery
func unaryObs(l *slog.Logger) grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req any, info *grpc.UnaryServerInfo,
                handler grpc.UnaryHandler) (resp any, err error) {
        start := time.Now()
        defer func() {
            if r := recover(); r != nil {          // паника не должна ронять весь сервер
                l.Error("panic", "method", info.FullMethod, "panic", r)
                err = status.Error(codes.Internal, "internal error")
            }
            code := status.Code(err)
            rpcDuration.WithLabelValues(info.FullMethod, code.String()).Observe(time.Since(start).Seconds())
            l.Info("rpc", "method", info.FullMethod, "code", code, "dur", time.Since(start))
        }()
        return handler(ctx, req)
    }
}

// stream-интерцептор: чтобы подменить ctx, оборачивают ServerStream
type wrappedStream struct {
    grpc.ServerStream
    ctx context.Context
}
func (w *wrappedStream) Context() context.Context { return w.ctx }

func streamAuth(srv any, ss grpc.ServerStream, info *grpc.StreamServerInfo, h grpc.StreamHandler) error {
    ctx, err := authorize(ss.Context())
    if err != nil { return err }
    return h(srv, &wrappedStream{ServerStream: ss, ctx: ctx})
}

s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(unaryObs(log), auth, validate, ratelimit),  // порядок = порядок выполнения
    grpc.ChainStreamInterceptor(streamObs(log), streamAuth),
)

Типовой набор в проде: recovery (самый внешний), логирование и трассировка, метрики, аутентификация и авторизация, валидация запроса (protoc-gen-validate), rate limiting, проброс request-id. На клиенте интерцепторами вешают дефолтный дедлайн, ретраи, circuit breaker и подстановку токена. ChainUnaryInterceptor вызывает их по порядку, снаружи внутрь, поэтому recovery и логирование идут первыми, а бизнес-валидация последней.

Гибрид, который встречается чаще всего

Внутри ходит gRPC, а на границе стоит шлюз, который выставляет наружу REST/JSON: grpc-gateway генерирует обратный прокси прямо из .proto с аннотациями google.api.http, так что и REST-контракт, и OpenAPI-спека берутся из того же источника истины. Браузеру отдают gRPC-Web через Envoy. Схема одна, интерфейсов два, и руками их синхронизировать не надо.

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order) {
    option (google.api.http) = { get: "/v1/orders/{id}" };   // и REST, и gRPC из одного описания
  }
  rpc CreateOrder(CreateOrderRequest) returns (Order) {
    option (google.api.http) = { post: "/v1/orders", body: "*" };
  }
}

Рукопожатие

GET /ws HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==     <- случайные 16 байт в base64
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat.v1                 <- согласование субпротокола
Origin: https://app.example.com                 <- проверять обязательно!

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat.v1

Sec-WebSocket-Accept вычисляется как base64(SHA1(key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11")). Это не безопасность, а защита от дурака: так клиент проверяет, что на том конце WebSocket-сервер, а не кэширующий прокси, который решил, что понял запрос.

Кадры

• Заголовок кадра: FIN-бит (последний фрагмент), 4 бита opcode (0x1 текст, 0x2 бинарь, 0x8 close, 0x9 ping, 0xA pong), MASK-бит, длина (7, 7+16 или 7+64 бита). Итого 2–14 байт вместо сотен байт HTTP-заголовков.
• Клиент обязан маскировать данные 4-байтовым ключом (сервер — нет). Это тоже не про шифрование: маскирование ломает атаки на промежуточные прокси, которые могли бы принять содержимое кадра за начало нового HTTP-запроса (cache poisoning).
• Ping/pong — служебные кадры для keepalive, и они обязательны: без трафика NAT и балансировщики рвут «мёртвые» соединения через 30–120 секунд, а клиент узнаёт об этом только при попытке записи. Пингуют обычно раз в 20–30 секунд.
• Сообщение можно фрагментировать на несколько кадров: так стримят большие полезные нагрузки.

Чем отличается от HTTP

Когда что брать

• WebSocket нужен для обмена в обе стороны с низкой задержкой: чат, совместное редактирование, игры, торговый терминал, интерактивные дашборды с командами.
• Для потока только вниз хватает SSE: лента событий, уведомления, прогресс длинной задачи, потоковая выдача текста LLM, живые метрики. Он дешевле, работает через любой прокси, а переподключение и Last-Event-ID встроены в браузерный EventSource. Историческое ограничение в 6 соединений на домен в HTTP/1.1 снимает мультиплексирование HTTP/2.
• Long polling остался ради совместимости с древними клиентами и сетями, где ничего другого не проходит.
• gRPC-стриминг — то же самое между сервисами, но с контрактом, дедлайнами, кодами ошибок и flow control.
• Обычный polling раз в 5–30 секунд подойдёт, если событий мало и задержка терпима. Дешевле в эксплуатации ничего нет, и вспомнить о нём — признак опыта.

// SSE в Go делается обычным долгим обработчиком, без библиотек
func stream(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")
    w.Header().Set("X-Accel-Buffering", "no") // иначе nginx буферизует и «реалтайма» не будет

    rc := http.NewResponseController(w) // Go 1.20+: доступ к Flush и дедлайнам записи
    events := subscribe(r.Context(), r.Header.Get("Last-Event-ID"))
    heartbeat := time.NewTicker(20 * time.Second)
    defer heartbeat.Stop()

    for {
        select {
        case <-r.Context().Done(): // клиент отвалился
            return
        case <-heartbeat.C:
            fmt.Fprint(w, ": ping\n\n") // комментарий-пульс, чтобы прокси не закрыл соединение
            _ = rc.Flush()
        case ev := <-events:
            fmt.Fprintf(w, "id: %s\nevent: %s\ndata: %s\n\n", ev.ID, ev.Type, ev.JSON)
            _ = rc.Flush() // без Flush данные осядут в буфере и никуда не поедут
        }
    }
}

Сравнение по осям

Голосом стоит добавить, что у XML есть то, чего нет у JSON: атрибуты, пространства имён, XSD-валидация, XSLT и, главное, XML Signature, подпись части документа. Поэтому он и жив в банках и госсистемах, а вовсе не «потому что не переписали». У YAML же есть «норвежская проблема» (country: NO → false в YAML 1.1) и якоря, из которых собирают YAML-бомбу. Это ещё один довод не брать его форматом обмена.

encoding/json: теги и правила

type Order struct {
    ID        int64      `json:"id"`
    Customer  string     `json:"customer,omitempty"`
    Amount    int64      `json:"amount"`                 // копейки: float для денег не годится
    Note      *string    `json:"note,omitempty"`         // указатель: отличаем "" от отсутствия
    CreatedAt time.Time  `json:"created_at"`
    DeletedAt *time.Time `json:"deleted_at,omitempty"`   // только указатель даёт настоящий omitempty
    Internal  string     `json:"-"`                      // никогда не сериализуется
    Weird     string     `json:"-,"`                     // а это поле с именем "-"
    BigID     int64      `json:"big_id,string"`          // число как строка: спасает JS от потери точности
    Tags      []string   `json:"tags,omitempty"`         // nil и пустой срез оба исчезнут
    Meta      map[string]any `json:"meta,omitempty"`
}

• Сериализуются только экспортируемые поля. Поле с маленькой буквы молча исчезнет, отсюда классическое «почему у меня в JSON пусто».
• При разборе имена сопоставляются без учёта регистра, если точного совпадения нет: {"ID":1} попадёт в поле с тегом json:"id".
• Встроенная (embedded) структура «разворачивается» в родителя, если у неё нет своего имени в теге.
• []byte кодируется в base64. time.Time — в RFC 3339. Ключи map сортируются, поэтому вывод детерминирован (в отличие от protobuf).
• json.Marshal экранирует <, >, & в \u003c, \u003e, \u0026. Отключается только через Encoder.SetEscapeHTML(false).

// Go 1.24: omitzero, каким omitempty должен был быть с самого начала
type Event struct {
    At      time.Time `json:"at,omitzero"`     // нулевое время исчезнет, этого ждали годами
    Retries int       `json:"retries,omitzero"`// а вот значимый 0 придётся оставить без тега
    Addr    Address   `json:"addr,omitzero"`   // пустая структура тоже исчезнет
}
// omitzero проверяет «нулевое значение типа» (и уважает метод IsZero() bool),
// omitempty проверяет «пустое» по своему списку. Их можно комбинировать в одном теге.

json.RawMessage и отложенный разбор

// когда часть документа надо разобрать позже или пробросить как есть
type Envelope struct {
    Type    string          `json:"type"`
    Payload json.RawMessage `json:"payload"` // не разбираем, пока не знаем тип
}

var e Envelope
if err := json.Unmarshal(data, &e); err != nil { return err }
switch e.Type {
case "order.created":
    var o OrderCreated
    if err := json.Unmarshal(e.Payload, &o); err != nil { return err }
    handle(o)
}

Тот же приём используют, чтобы не потерять неизвестные поля при проксировании: разобрал что нужно, остальное протащил байтами. json.RawMessage всего лишь []byte с методами MarshalJSON/UnmarshalJSON. При разборе байты копируются как есть, а при Marshal содержимое уплотняется и экранируется (< станет \u003c), так что байт в байт он данные не протащит.

Кастомные MarshalJSON и UnmarshalJSON

// Задача: наружу отдавать длительность как "1500ms", а не как 1500000000 наносекунд
type Duration struct {
    time.Duration
}

func (d Duration) MarshalJSON() ([]byte, error) {          // приёмник-значение
    return json.Marshal(d.String())
}

func (d *Duration) UnmarshalJSON(b []byte) error {          // обязательно указатель
    var s string
    if err := json.Unmarshal(b, &s); err != nil { return err }
    v, err := time.ParseDuration(s)
    if err != nil { return fmt.Errorf("duration %q: %w", s, err) }
    d.Duration = v
    return nil
}

// Приём «alias»: добавить поле без бесконечной рекурсии
type Order struct {
    ID     int64     `json:"id"`
    Status Status    `json:"status"`
}

func (o Order) MarshalJSON() ([]byte, error) {
    type alias Order          // новый тип без методов: рекурсии не будет
    return json.Marshal(struct {
        alias
        StatusText string `json:"status_text"`
    }{alias(o), o.Status.String()})
}

Decoder против Unmarshal и неизвестные поля

// Unmarshal: весь документ уже в памяти
var o Order
err := json.Unmarshal(body, &o)

// Decoder читает из io.Reader: тело целиком не держим, умеем поток
dec := json.NewDecoder(io.LimitReader(r.Body, 1<<20)) // лимит от «бомбы» на 2 ГБ
dec.DisallowUnknownFields()                            // строгий разбор: лишнее поле = ошибка
dec.UseNumber()                                        // числа как json.Number, а не float64

if err := dec.Decode(&o); err != nil {
    var syn *json.SyntaxError
    var typ *json.UnmarshalTypeError
    switch {
    case errors.As(err, &syn):  // битый JSON
    case errors.As(err, &typ):  // "amount": "abc" при int64 — можно назвать поле в ответе
    }
    return err
}
// поток JSON-объектов подряд (ndjson): Decode в цикле до io.EOF
for dec.More() { ... }

encoding/json/v2 — с Go 1.27 это уже не эксперимент

В Go 1.25 encoding/json/v2 был экспериментом и включался переменной окружения GOEXPERIMENT=jsonv2. В Go 1.27 он включён по умолчанию безо всяких настроек, а выключает его обратная переменная GOEXPERIMENT=nojsonv2. Пакетов теперь два, и граница между ними чёткая:

• encoding/json/v2 отвечает за семантику: как Go-значение соответствует JSON. Теги, omitzero, кастомные маршалеры, опции разбора.
• encoding/json/jsontext — синтаксис: как JSON выглядит текстом. Токены (Token), «сырое» значение (Value), потоковые Encoder/Decoder, отступы. Раньше всё это было слеплено в одном пакете, и половину настроек нельзя было выразить.

Паниковать не надо: старый encoding/json никуда не делся и поведения не поменял. Его переписали поверх v2, но наблюдаемую семантику намеренно сохранили, иначе сломался бы весь существующий код в мире. Строгость v2 приезжает ровно тогда, когда ты сам меняешь импорт. Зато Unmarshal стал заметно быстрее, а API — по-настоящему потоковым: MarshalWrite/UnmarshalRead работают с io.Writer/io.Reader, MarshalEncode/UnmarshalDecode — с jsontext.Encoder/Decoder.

import (
    "encoding/json/v2"        // пакет называется json, импортируется без переименования
    "encoding/json/jsontext"
)

// синтаксическую опцию (отступ) и семантическую передают одинаково, списком Options
b, err := json.Marshal(v, jsontext.WithIndent("  "))

// строгий разбор конфига: неизвестное поле = ошибка (замена DisallowUnknownFields)
err = json.Unmarshal(data, &cfg, json.RejectUnknownMembers(true))

// поток без промежуточного буфера
err = json.MarshalWrite(w, v)
err = json.UnmarshalRead(io.LimitReader(r.Body, 1<<20), &req)

// 1. Дублирующиеся ключи объекта
json.Unmarshal([]byte(`{"a":1,"a":2}`), &v)
// v2 -> ошибка: jsontext: duplicate object member name "a"
// v1 -> nil, молча побеждало последнее значение

// 2. Невалидный UTF-8 (и на чтении, и на записи)
json.Unmarshal([]byte("{\"b\":\"\xff\xfe\"}"), &v)
// v2 -> ошибка: jsontext: invalid UTF-8 within "/b" after offset 6
// v1 -> nil, битые байты тихо заменялись на U+FFFD

// 3. Регистр имён: v2 по умолчанию строгий
json.Unmarshal([]byte(`{"ID":7}`), &v)   // при теге `json:"id"`
// v2 -> поле осталось нулевым, ошибки нет
// v1 -> поле заполнено: при промахе он пробовал сопоставить без учёта регистра