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

• 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.