Глоссарий — Computer Networks для Junior

Сетевой протокол уровня L3 (Network) в стеке TCP/IP, отвечающий за маршрутизацию пакетов между host'ами через несколько сетей. Connectionless и unreliable: не гарантирует доставку, порядок и отсутствие дубликатов -- это задача транспортного уровня (TCP). Каждый пакет содержит source и destination IP-адреса, по которым промежуточные роутеры решают, в какой интерфейс отправить пакет дальше (longest prefix match). Существуют две версии: IPv4 (32 бита, ~4.3 млрд адресов, исчерпан) и IPv6 (128 бит, фактически неисчерпаем). Для DE и backend важно: IP -- это адрес интерфейса, а не машины (у host'а может быть несколько IP), и в большинстве случаев приватный IP сидит за NAT.

Четвёртая версия IP, 32-битный адрес в dotted decimal нотации (192.168.1.10). Адресное пространство ~4.3 млрд, исчерпано в 2011 году на уровне IANA. Структура заголовка: 20 байт минимум (Version, IHL, TOS, Total Length, Identification, Flags+Fragment Offset, TTL, Protocol, Header Checksum, Src IP, Dst IP, опции). MTU обычно 1500 байт на Ethernet. Несмотря на дефицит, IPv4 до сих пор доминирует благодаря NAT: миллионы private IP за одним публичным. Для разработчика типичные сценарии IPv4 -- 10.0.0.0/8 во внутренних сетях, 127.0.0.1 как loopback, 0.0.0.0 для bind на все интерфейсы.

Шестая версия IP с 128-битным адресом (~3.4 * 10^38 адресов). Записывается как 8 групп hex по 16 бит через двоеточие: 2001:0db8:85a3:0000:0000:8a2e:0370:7334; разрешено сокращение нулей (2001:db8:85a3::8a2e:370:7334). Не имеет broadcast (заменён на multicast), нет fragmentation на роутерах (только на host'е), упрощённый заголовок, встроенный IPsec в спецификации. Адаптация постепенная: dual-stack (IPv4 + IPv6 параллельно), tunneling. На практике большинство современных мобильных сетей и облачных провайдеров уже IPv6-native, но в legacy DC всё ещё IPv4.

48-битный (6 байт) аппаратный адрес сетевого интерфейса L2 (Data Link). Записывается как 6 hex-октетов через двоеточие или дефис: aa:bb:cc:dd:ee:ff. Первые 3 байта (OUI) идентифицируют производителя, последние 3 -- уникальный номер интерфейса. В отличие от IP, MAC не маршрутизируется -- работает только внутри одного broadcast-домена (LAN). Frame на L2 содержит source MAC + destination MAC. Switch ведёт MAC-таблицу: какой MAC за каким портом. MAC может быть изменён программно (spoofing) -- частая атака для обхода фильтров.

Способ обозначения подсети через slash-нотацию: 192.168.1.0/24 значит, что первые 24 бита -- адрес сети, последние 8 -- хосты. Заменил исторические классы A/B/C (с фиксированными границами /8, /16, /24). CIDR позволяет создавать подсети любой длины: /22 это 1024 адреса, /29 это 8 адресов (6 usable, 2 зарезервированы под network и broadcast). Маска /24 равна 255.255.255.0. Для routing table CIDR используется в longest prefix match: маршрут /28 победит /24 при выборе. На практике инженер пишет /24, /22, /16 для VPC subnets в AWS/GCP.

Логическое разделение IP-сети на меньшие сегменты через subnet mask. Все host'ы внутри подсети могут общаться напрямую на L2 без роутера; для выхода за пределы нужен default gateway. Mask определяет границу network/host битов: 255.255.255.0 = /24 = 256 адресов (254 usable). Subnetting нужен для изоляции (production vs staging), безопасности (firewall между subnets), масштабирования (broadcast не уходит за subnet), оптимизации (минимизация broadcast domain). В AWS VPC subnet -- это базовый строительный блок, привязанный к AZ.

IP-адрес роутера, через который host отправляет пакеты в сети, не входящие в его собственную подсеть. Когда destination IP не попадает ни под один маршрут в routing table, пакет уходит в default gateway (маршрут 0.0.0.0/0). В типичном home Wi-Fi gateway -- это сам router (обычно 192.168.1.1 или 192.168.0.1). В корпоративной сети gateway часто отдельный L3-switch или firewall. На Linux/macOS gateway показывает netstat -rn или ip route show default.

Механизм трансляции IP-адресов на границе сети, чаще всего из приватных (RFC 1918) в публичные. Когда пакет из 192.168.1.42 идёт в интернет, router заменяет src IP на свой публичный, запоминает соответствие (source IP + port -> public IP + port) в NAT-таблице и подменяет обратно для ответных пакетов. Это позволяет тысячам приватных host'ов делить один публичный IP. Типы: full cone (любой внешний может слать на mapped port), restricted cone, port-restricted, symmetric (для каждого dst создаётся отдельный mapping -- ломает P2P). NAT усложняет inbound-соединения -- отсюда port forwarding, UPnP, hole punching, STUN/TURN.

16-битный (0-65535) идентификатор endpoint на host'е, по которому ОС различает, в какое приложение отдавать пакет. Адрес соединения = IP + port (socket). Well-known ports 0-1023 (требуют root для bind), registered 1024-49151, ephemeral 49152-65535 (выделяются клиенту динамически). Стандартные: 22 (SSH), 53 (DNS), 80 (HTTP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 9092 (Kafka). Один порт = одно слушающее приложение на интерфейсе. Несколько клиентов могут одновременно подключаться к одному серверному порту -- ОС различает их по 4-tuple (src IP, src port, dst IP, dst port).

Абстракция в ОС, представляющая endpoint сетевого соединения. Уникально идентифицируется 4-tuple: (local IP, local port, remote IP, remote port) для TCP, или 2-tuple для listening UDP. Berkeley API даёт системные вызовы: socket() создать, bind() привязать к адресу, listen() начать слушать (TCP), accept() принять входящее соединение, connect() подключиться, send/recv обменяться данными, close() закрыть. На уровне ядра socket -- это file descriptor, поэтому в Unix всё работает через read/write/poll/epoll. В Python обёртка -- модуль socket в stdlib.

Транспортный протокол L4, обеспечивающий надёжную, упорядоченную, потоковую передачу данных между двумя endpoint'ами. Connection-oriented: сначала three-way handshake (SYN, SYN-ACK, ACK), потом обмен сегментами с sequence numbers и ACK, в конце четырёхэтапное закрытие (FIN, ACK, FIN, ACK). Гарантирует: данные дойдут (retransmission при потере), в порядке (по sequence number), без дублей (по ack), и с flow + congestion control. Header ~20 байт. На TCP работают HTTP/1.1, HTTP/2, SSH, SMTP, IMAP, FTP, большинство БД. Цена надёжности: handshake latency (1 RTT), head-of-line blocking, в плохих сетях ретрансмиты убивают throughput.

Транспортный протокол L4, connectionless и unreliable. Не делает handshake, не гарантирует доставку, порядок и отсутствие дубликатов -- просто шлёт datagrams. Header ровно 8 байт: src port, dst port, length, checksum. Каждый datagram самодостаточен. Используется там, где важна latency и допустимы потери: DNS (короткий запрос + ответ), VoIP / video calls (потеря кадра лучше задержки), streaming media, online games, NTP, DHCP, QUIC (поверх UDP реализован свой reliability). При необходимости reliability (как в QUIC) её реализуют на application layer.

Процесс установки TCP-соединения через обмен тремя пакетами: (1) клиент шлёт SYN с initial sequence number ISN_c, (2) сервер отвечает SYN-ACK с ISN_s и ack = ISN_c+1, (3) клиент шлёт ACK = ISN_s+1. После этого соединение в состоянии ESTABLISHED и можно отправлять данные. Зачем три пакета: чтобы обе стороны убедились, что и приём, и отправка работают двусторонне. ISN выбирается псевдослучайно для защиты от SYN-spoofing. Latency handshake'а = 1 RTT -- это причина, по которой TCP медленнее UDP при коротких запросах. Атака SYN flood: посылается много SYN без завершения handshake, забивая очередь полусоединений.

32-битный счётчик байт в TCP, по которому получатель собирает поток в правильном порядке. Начальное значение (ISN) выбирается псевдослучайно при handshake. Каждый сегмент имеет seq = байт-номер первого байта данных в сегменте. Получатель шлёт ACK с номером следующего ожидаемого байта. Если приходят сегменты с разрывом (пропуск), получатель буферизирует их и шлёт duplicate ACK -- это сигнал отправителю об потере и триггер fast retransmit. После 4 ГБ передачи sequence number wraps around (через 2^32 байт).

Подтверждение получения данных в TCP. ACK number в заголовке = номер следующего ожидаемого байта. Это cumulative ACK: ACK 1000 означает 'все байты до 999 включительно получены'. ACK обычно идёт piggyback с данными в обратном направлении или как pure ACK без payload. Если отправитель не получил ACK в течение RTO (retransmission timeout), он повторно отправит сегмент. Selective ACK (SACK, RFC 2018) -- расширение, в котором получатель указывает диапазоны полученных out-of-order сегментов, чтобы отправитель не ретрансмитил уже доставленные данные.

Механизм потокового управления передачей, при котором отправитель может слать сразу несколько unacknowledged сегментов в пределах окна (window size, передаётся в каждом ACK). После получения ACK окно сдвигается вправо. Это позволяет утилизировать пропускную способность канала: вместо stop-and-wait (один пакет -- один ACK) можно держать в полёте BDP (bandwidth-delay product) байт. Window size в TCP header -- 16 бит (макс 64 KB), для высокоскоростных сетей используется TCP window scaling option (множитель 2^n).

Механизм, не дающий быстрому отправителю переполнить буфер медленного получателя. Реализован через receive window: получатель в каждом ACK сообщает, сколько ещё байт он готов принять. Если приложение медленно читает данные из буфера, окно уменьшается. При window = 0 отправитель останавливается и периодически шлёт window probe, пока получатель не освободит место. Это решает локальную проблему 'producer faster than consumer'. Отдельно от flow control работает congestion control, который заботится о состоянии сети между host'ами.

Механизм, не дающий отправителю переполнить промежуточные роутеры на пути к получателю. Реализован через congestion window (cwnd), которое растёт при успешных ACK и резко уменьшается при потерях (interpret packet loss as congestion). Классические алгоритмы: slow start (экспоненциальный рост cwnd с 1 MSS), congestion avoidance (линейный рост после порога ssthresh), fast retransmit (по 3 dup ACK), fast recovery. Современные: CUBIC (default в Linux), BBR (Google), DCTCP (для DC). При потерях TCP замедляется -- именно поэтому plot throughput имеет 'зубцы пилы'.

Единица данных TCP, состоящая из TCP-заголовка (20-60 байт) и payload. Сегмент инкапсулируется в IP-пакет. Максимальный размер payload -- MSS (Maximum Segment Size), обычно = MTU - 40 (IP + TCP заголовки) = 1460 байт для Ethernet с MTU 1500. MSS согласовывается во время handshake. Если приложение пишет в socket 100 KB, TCP разрежет это на ~70 сегментов. Сегментация позволяет проходить через сети с разным MTU без fragmentation на L3.

Единица данных UDP: 8 байт заголовка + payload. Каждый datagram независим, шлётся как один IP-пакет (если влезает в MTU) или фрагментируется на L3. Максимальный размер UDP datagram теоретически 65507 байт (65535 - 20 IP - 8 UDP), но на практике лучше держать < MTU чтобы избежать fragmentation. Если фрагментирован, потеря одного фрагмента = потеря всего datagram. В отличие от TCP segment, у datagram нет sequence number и нет ACK -- application layer должен сам это реализовать, если нужно.

Максимальный размер payload на L2 frame в байтах. На Ethernet стандарт 1500 байт (всего frame 1518 с заголовками). Jumbo frames -- до 9000 байт, используются в DC для повышения throughput. PPPoE снижает MTU до 1492 из-за заголовка. Если IP-пакет больше MTU, он фрагментируется (IPv4) или дроп с ICMP 'Fragmentation Needed' (IPv6). MTU mismatch -- частая проблема: туннели (VPN, GRE) уменьшают эффективный MTU; если PMTUD не работает (ICMP заблокирован), получается black hole -- пакеты пропадают молча.

Семейство технологий L2 для проводных LAN, стандартизированных IEEE 802.3. Современные скорости: 1 GbE, 10 GbE, 25/40/100/400 GbE в DC. Frame состоит из: preamble (7 B), SFD (1 B), dst MAC (6 B), src MAC (6 B), EtherType (2 B, например 0x0800 для IPv4, 0x86DD для IPv6, 0x0806 для ARP), payload (46-1500 B), FCS (4 B, CRC). На физическом уровне -- кабели cat5e/cat6/cat6a (twisted pair), оптика (SFP+, QSFP). Полудуплекс с CSMA/CD устарел -- современный switched Ethernet работает full duplex.

Единица данных L2 в Ethernet-сети. Структура: dst MAC, src MAC, EtherType (тип payload, например IPv4), payload (внутри которого обычно IP-пакет), FCS (Frame Check Sequence -- CRC-32 для обнаружения ошибок). Frame передаётся между host'ами в одном broadcast-домене (без роутинга). Switch смотрит dst MAC и форвардит frame только в нужный порт (если знает MAC) или флудит во все (если не знает -- unknown unicast flooding). Размер frame'а: минимум 64 байта (с padding), максимум 1518 (или 9018 для jumbo).

Единица данных L3 (IP). Состоит из IP-заголовка (20-60 байт в IPv4, 40 байт в IPv6) и payload (обычно TCP segment или UDP datagram). Содержит src IP, dst IP, TTL/Hop Limit, protocol number (6=TCP, 17=UDP, 1=ICMP). Маршрутизаторы смотрят на dst IP и форвардят пакет согласно routing table. TTL уменьшается на каждом hop -- защита от бесконечных циклов. В IPv4 пакет может фрагментироваться на роутерах при превышении MTU; в IPv6 фрагментация только на отправителе (через PMTUD).

Протокол L2-L3 (формально между уровнями), который разрешает IP-адрес в MAC-адрес внутри одной подсети. Когда host хочет отправить пакет соседу с IP 192.168.1.10, он сначала шлёт broadcast 'who has 192.168.1.10? tell 192.168.1.1', и нужный host отвечает unicast'ом 'I have 192.168.1.10, my MAC is aa:bb:cc:dd:ee:ff'. Результат кэшируется в ARP-таблице (ip neigh на Linux, arp -a). Gratuitous ARP -- host анонсирует свой MAC сам, без запроса, для обновления соседних кэшей (используется при failover IP). Уязвим к ARP poisoning -- атакующий шлёт фейковые ARP-ответы и перехватывает трафик.

Сетевое устройство, форвардящее Ethernet frames между портами на основе MAC-адресов. Поддерживает MAC-таблицу (port -> MAC), которую заполняет наблюдая за src MAC во входящих frames (learning). При получении frame: если dst MAC известен в таблице -- шлёт только в нужный порт (unicast), если неизвестен -- флудит во все порты (unknown unicast flooding), если broadcast (ff:ff:ff:ff:ff:ff) -- флудит во все. Не уменьшает broadcast domain -- весь switch это один broadcast domain (если нет VLAN). Современные L3 switch'и умеют ещё и роутить на основе IP.

Устаревшее сетевое устройство L1, повторяющее любой входящий сигнал на все остальные порты (электрический повторитель). Не понимает MAC-адресов -- просто dumb repeater. Все host'ы делят один collision domain: если двое говорят одновременно, происходит коллизия и CSMA/CD заставляет ждать. Hub передаёт весь трафик во все порты -- значит, любой подключённый может сниффать чужие frames. Заменён switch'ами 20 лет назад. Сегодня встретить hub можно только в учебниках или старом оборудовании.

Устройство L3, форвардящее IP-пакеты между разными подсетями на основе routing table. Каждый интерфейс роутера в своей подсети. При получении пакета: проверяет dst IP, ищет в routing table longest prefix match, уменьшает TTL на 1, пересылает в соответствующий next hop. На стыке подсетей роутер выступает как default gateway для host'ов. Делает NAT, фильтрацию, QoS. Дома 'роутер' обычно совмещает функции router + switch + access point + DHCP server + DNS forwarder в одном корпусе.

Технология логического разделения одного физического switch'а на несколько изолированных broadcast-доменов. Каждый VLAN имеет ID (1-4094) и работает как отдельная LAN. Tagged port (trunk) переносит трафик нескольких VLAN'ов с 802.1Q-тегом (4 байта между src MAC и EtherType). Untagged port (access) принадлежит одному VLAN -- host'у не видно тэгов. Используется для изоляции (production / staging / dev), безопасности (отделить guests Wi-Fi от internal), оптимизации (уменьшить размер broadcast domain). Между VLAN -- только через L3 routing.

Семиуровневая референсная модель ISO/IEC 7498-1: L1 Physical (биты по проводу), L2 Data Link (frames, MAC), L3 Network (packets, IP), L4 Transport (segments/datagrams, TCP/UDP), L5 Session (логические сессии -- redko используется), L6 Presentation (encoding, encryption -- редко), L7 Application (HTTP, SMTP, DNS). На практике L5-L6 чаще объединяют с L7. Модель полезна для рассуждений и общения ('это работает на L4' = transport), но реальный стек -- TCP/IP, у которого 4 уровня. Запоминается мнемоникой 'Please Do Not Throw Sausage Pizza Away'.

Четырёхуровневая практическая модель: Link (L2-L1 OSI: Ethernet, Wi-Fi, ARP), Internet (L3: IP, ICMP), Transport (L4: TCP, UDP, QUIC), Application (L5-7 OSI: HTTP, DNS, SSH, SMTP). Реальный стек, используемый в Unix-системах. Каждый уровень предоставляет сервис верхнему через интерфейс (socket API между Transport и Application). Пакет инкапсулируется сверху вниз: HTTP -> TCP segment -> IP packet -> Ethernet frame -> биты. На приёмной стороне раскапсулируется обратно.

Процесс обёртывания данных одного уровня в заголовок другого. HTTP-запрос (Application) кладётся в TCP-сегмент (Transport: добавляет TCP header), который кладётся в IP-пакет (Network: добавляет IP header), который кладётся в Ethernet frame (Link: добавляет Ethernet header + FCS). Каждый уровень не знает о деталях верхних -- IP не знает, что внутри TCP, а TCP не знает, что внутри HTTP. На принимающей стороне идёт de-encapsulation: уровни последовательно снимают свои заголовки и передают payload наверх. Это даёт layered architecture: можно менять реализацию L4 (TCP -> QUIC), не трогая L3.

Иерархическая распределённая система, разрешающая доменные имена (example.com) в IP-адреса. Работает поверх UDP (порт 53) для коротких запросов, TCP для больших ответов и zone transfer. Структура иерархическая: root (.), TLD (com, org, ru), authoritative servers конкретного домена. Запрос проходит через recursive resolver (8.8.8.8, 1.1.1.1, провайдерский), который ходит по иерархии. Резолв кэшируется на нескольких уровнях по TTL. DNS -- единственная критическая инфраструктура интернета: если ляжет, никто не достучится до сайтов (хотя IP-адреса работают).

DNS-запись, отображающая доменное имя в IPv4-адрес. Самая распространённая запись. Может быть несколько A records на одно имя (DNS round-robin) -- resolver вернёт все, клиент выберет одну. TTL определяет, как долго resolver может кэшировать ответ (от секунд до дней). Пример: example.com -> 93.184.216.34. Для IPv6 аналог -- AAAA-запись. На практике dig +short example.com покажет все A-записи.

DNS-запись, отображающая доменное имя в IPv6-адрес. Аналог A-записи для IPv6. Имя 'AAAA' (читается 'quad-A') потому что IPv6 в 4 раза длиннее IPv4 (128 vs 32 бит). Если у домена есть и A и AAAA записи -- это dual-stack, клиент с IPv6-стеком предпочтёт AAAA (Happy Eyeballs algorithm), но fallback на IPv4 при проблемах. dig AAAA example.com покажет IPv6-адрес.

DNS-запись, создающая алиас одного домена на другой. www.example.com CNAME example.com значит 'www -- это синоним example.com, иди резолвь его'. Resolver следует цепочке CNAME, пока не упрётся в A или AAAA. Ограничения: нельзя класть CNAME на apex домена (example.com сам по себе), нельзя сочетать с другими записями на том же имени (например, MX и CNAME несовместимы). Активно используется в CDN: www.mysite.com CNAME mysite.cdn-provider.net.

DNS-запись, указывающая mail-сервер для домена. Содержит priority (меньше -- выше приоритет) и hostname почтового сервера. При отправке письма на [email protected] отправитель ищет MX-записи example.com и шлёт SMTP на сервер с минимальным priority. Если он не отвечает -- на следующий по приоритету. Несколько MX обеспечивают отказоустойчивость. Hostname в MX должен резолвиться в A/AAAA (не CNAME).

В контексте DNS: время в секундах, в течение которого resolver может кэшировать запись. Низкий TTL (60-300 сек) даёт быстрый rollout изменений, но повышает нагрузку на authoritative DNS. Высокий TTL (3600-86400) снижает нагрузку, но изменения распространяются медленно. Перед миграцией DNS заранее снижают TTL до 60. Помимо DNS, TTL есть в IP-заголовке -- счётчик max hops для предотвращения loops, уменьшается на 1 на каждом роутере.

Прикладной протокол клиент-серверной модели, основа Web. Stateless: каждый запрос самодостаточен. Версии: HTTP/1.1 (1997, текстовый, до сих пор основной для server-to-server), HTTP/2 (2015, бинарный, multiplexing поверх одного TCP), HTTP/3 (2022, поверх QUIC/UDP). Работает поверх TCP (80) или TLS (443). Структура запроса: method + path + headers + body. Структура ответа: status code + headers + body. Методы: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS.

HTTP, обёрнутый в TLS-туннель. Поверх TCP делается TLS-handshake (обмен сертификатами, согласование cipher, выработка симметричного ключа), затем HTTP идёт по зашифрованному каналу. Защищает от пассивного прослушивания, MITM и tampering. Default-порт 443. Browsers с 2018 года помечают HTTP-сайты как 'Not Secure'. Современный web почти полностью HTTPS -- HTTP редиректится на HTTPS через 301 + HSTS-header.

Версия HTTP с 2015 года, бинарный формат вместо текстового. Главные улучшения: multiplexing -- много запросов параллельно в одном TCP-соединении (без head-of-line на application layer, но остаётся на TCP), HPACK сжатие заголовков, server push (deprecated в большинстве browsers), приоритеты streams. Решает проблему HTTP/1.1, где для параллелизма открывали 6 соединений на домен. В реальности достиг широкого adoption -- 50%+ web. Минус: head-of-line blocking на уровне TCP всё ещё убивает performance при потерях.

Версия HTTP с 2022 года, работает поверх QUIC (UDP-based транспорт с встроенной TLS 1.3) вместо TCP. Решает head-of-line blocking на транспортном уровне: потеря пакета в одном stream не блокирует другие. Connection migration: можно сменить сеть (Wi-Fi -> 4G) без переустановки соединения. 0-RTT для повторных подключений. Сейчас 25%+ web, активно используется Google, Cloudflare. Минус: некоторые firewalls/NAT блокируют UDP, fallback на HTTP/2 нужен.

Транспортный протокол поверх UDP, разработанный Google, стандартизирован IETF в 2021. Объединяет функции TCP (надёжность, congestion control), TLS (шифрование) и часть HTTP/2 (multiplexing) в одном протоколе. Преимущества: 1-RTT handshake (или 0-RTT для повторов), per-stream reliability (нет head-of-line), connection migration, всегда зашифрован. Является транспортом для HTTP/3. По метрикам Google -- ускорение 3-8% для коротких запросов, ещё больше в плохих сетях.

Возможность отправлять несколько логических потоков (streams) параллельно через одно физическое соединение. В HTTP/1.1 на каждый запрос нужно своё TCP-соединение или очередь (head-of-line blocking). В HTTP/2 multiplexing на одном TCP -- много параллельных streams. В HTTP/3/QUIC streams независимы и на транспортном уровне -- потеря пакета в одном не влияет на другие. Это решает проблему параллельной загрузки ресурсов веб-страницы (CSS, JS, images) без open-and-close сотен соединений.

Ситуация, когда первый элемент очереди блокирует обработку всех последующих. В HTTP/1.1: запросы шлются последовательно (или браузер открывает 6 параллельных соединений). В HTTP/2 решена на application layer (multiplexing), но осталась на транспортном TCP: потеря одного пакета задерживает все streams, потому что TCP ждёт ретрансмит чтобы передать данные in-order. В HTTP/3/QUIC решена полностью: каждый stream имеет независимый ordering.

Криптографический протокол, обеспечивающий confidentiality, integrity и authentication между клиентом и сервером. Версии: TLS 1.2 (2008, до сих пор широко), TLS 1.3 (2018, упрощённый handshake -- 1 RTT, обязательное forward secrecy). TLS 1.0/1.1 deprecated. Handshake TLS 1.3: ClientHello (cipher suites + key share) -> ServerHello (выбор + сертификат) -> Finished, далее данные шифруются. Сертификат подписан CA из доверенного root store ОС. Self-signed cert в production -- красный флаг.

Устаревший предшественник TLS, разработан Netscape в 1990-х (SSL 2.0 в 1995, SSL 3.0 в 1996). SSL 2.0 и 3.0 deprecated (последний -- через атаку POODLE в 2014). С 1999 заменён TLS 1.0, далее TLS 1.1/1.2/1.3. В разговорной речи 'SSL' и 'TLS' часто используются как синонимы, но технически правильно говорить TLS. 'SSL certificate' -- это X.509-сертификат для TLS, название историческое.

Электронный документ, привязывающий публичный ключ к идентификатору (домен, организация). Структура: subject (на кого выдан), issuer (кто выдал, обычно CA), validity period, public key, extensions (SAN -- alternative names, key usage), и подпись issuer'а. Browser проверяет: подпись валидна, не expired, hostname совпадает с SAN, не в CRL/OCSP revocation. Цепочка доверия: server cert -> intermediate CA -> root CA (в trust store ОС). Получить можно через Let's Encrypt бесплатно.

Организация, выпускающая сертификаты и подписывающая их своим приватным ключом. Root CA -- топ цепочки, их публичные ключи зашиты в ОС/browser. Когда CA подписывает сертификат сервера, клиент может верифицировать подпись по root key из своего trust store. Известные CA: Let's Encrypt (бесплатно, автоматизация через ACME), DigiCert, GlobalSign, Sectigo. Корпоративные внутренние CA выдают сертификаты для internal сервисов -- их root cert нужно добавить в trust store. Компрометация root CA -- катастрофа (например, DigiNotar в 2011).

Совокупность ролей, политик, аппаратуры, ПО и процедур для управления цифровыми сертификатами и публично-ключевой криптографией. Включает CA (выпуск сертификатов), RA (registration authority -- верификация запросов), CRL/OCSP (revocation), trust stores, политики использования. Чисто web PKI -- иерархия CA, доверие которой зашито в browser. Корпоративный PKI -- внутренние CA для service-to-service mTLS, code signing, S/MIME. Управление приватным ключом root CA -- задача с HSM (Hardware Security Module) и многоступенчатой аутентификацией.

Атака, при которой злоумышленник встраивается между клиентом и сервером, перехватывая и (опционально) модифицируя трафик. Способы: ARP poisoning (подмена ARP), DNS spoofing (фейковый IP в DNS-ответе), захват промежуточного хопа, фейковая Wi-Fi точка. TLS делает MITM практически невозможным: сертификат сервера не пройдёт верификацию у клиента, потому что подписан другим CA. Корпоративные SSL inspection proxy (Zscaler, Palo Alto) делают 'легитимный MITM' путём установки своего root CA на endpoint.

Атака, направленная на исчерпание ресурсов жертвы (bandwidth, CPU, соединения) множеством скоординированных источников (botnet, amplification). Типы: volumetric (затопление трафиком, измеряется в Gbps), protocol (SYN flood, fragmentation, измеряется в Mpps), application layer (HTTP flood, slowloris). Защита: anti-DDoS провайдеры (Cloudflare, AWS Shield, Akamai), rate-limiting, blackholing атакующих IP, CDN. Современные DDoS могут превышать 1 Tbps.

Устройство или ПО, фильтрующее сетевой трафик по правилам (allow/deny по IP, port, protocol). Stateless: смотрит каждый пакет независимо (быстрее, проще, меньше defenсе). Stateful: отслеживает состояние соединений (различает new/established/related, может ловить отклонения). Примеры реализаций: iptables/nftables (Linux netfilter), Windows Firewall, hardware Cisco/Palo Alto, облачные Security Groups (AWS), Network ACLs. Также есть application-layer firewall (WAF) для HTTP -- режут SQL injection, XSS.

Зашифрованный туннель между двумя сетевыми точками, создающий иллюзию прямого подключения к удалённой сети. Использует: IPsec (стандарт, сложен), OpenVPN (TLS-based, гибкий), WireGuard (новый, быстрый, минималистичный), L2TP/PPTP (устаревшие). Сценарии: remote access (сотрудник к корпсети), site-to-site (соединение офисов), consumer VPN (анонимизация, обход блокировок). Split tunneling -- разделение трафика: что идёт в туннель, что в обычный интернет.

Современный VPN-протокол (2016, mainline Linux kernel с 5.6 в 2020). Минималистичный: ~4000 строк кода (vs ~600k у OpenVPN), что упрощает аудит. Использует современную криптографию: ChaCha20 + Poly1305 для шифрования, Curve25519 для key exchange, BLAKE2s для hashing. UDP-only, не attempts to look like HTTP. Конфигурация декларативная: peer = public key + endpoint + allowed IPs. Быстрее IPsec и OpenVPN на одинаковом железе. Stateless по дизайну -- работает за NAT через keepalive.

Набор протоколов для шифрования и аутентификации IP-пакетов на L3. Состоит из: AH (Authentication Header -- integrity без encryption), ESP (Encapsulating Security Payload -- encryption + integrity), IKE (Internet Key Exchange -- согласование ключей). Режимы: transport (шифруется только payload) и tunnel (весь IP-пакет внутри нового, для site-to-site VPN). Стандарт для enterprise VPN, реализован во всех ОС. Минусы: сложность настройки, проблемы с NAT (обходятся через NAT-T).

Атака на L2, при которой злоумышленник шлёт фейковые ARP-ответы в локальную сеть, ассоциируя свой MAC с IP жертвы (часто -- gateway). После этого трафик жертв идёт через атакующего, который видит/модифицирует его (MITM). Защита: статические ARP-записи для критичных host'ов, DAI (Dynamic ARP Inspection) на switch'ах, мониторинг (arpwatch). На свич, который видит несколько ARP-ответов на один IP, можно настроить алерт.

Атака, при которой атакующий инжектит фейковый DNS-ответ в кэш resolver'а (или клиента), чтобы перенаправить трафик на свой сервер. Способы: race condition на ответе (Kaminsky 2008), компрометация authoritative server, MITM с подменой ответа. Защита: DNSSEC (криптографическая подпись DNS-записей), DoH/DoT (DNS через TLS, против MITM), random source ports (против Kaminsky-style).

Перехват и анализ сетевых пакетов на интерфейсе. Требует raw socket access (root на Linux). Инструменты: tcpdump (CLI), Wireshark (GUI), tshark. На switched LAN видишь только свой трафик + broadcast (если не настроен port mirroring). На Wi-Fi monitor mode видит весь трафик в эфире (но шифрованный, без ключа). TLS-трафик сниффится, но contents зашифрованы -- видны только metadata (адреса, порты, SNI). Используется для дебага сети, security analysis, обучения протоколам.

Протокол маршрутизации между autonomous systems (между ISP). 'Клей интернета': каждая AS объявляет соседям, какие префиксы у неё есть, и выбирает best path по политикам (preference, AS-path, MED). Работает поверх TCP/179. Не использует metrics типа hop count -- решения принимает по политикам и AS-path length. Уязвим к BGP hijacking: AS может ошибочно или злоумышленно анонсировать чужие префиксы (например, инцидент Pakistan Telecom + YouTube в 2008). Защита: RPKI (Resource Public Key Infrastructure).

Внутренний протокол маршрутизации (IGP), работающий внутри AS. Link-state: каждый router знает топологию всей AS, считает shortest path Dijkstra'ом. Делит AS на areas для масштабирования. Сходится быстро при изменениях, но требует CPU и памяти на router'ах. Используется в крупных enterprise сетях, реже в ISP (там обычно IS-IS). Аналоги: RIP (старый, distance-vector), EIGRP (Cisco-proprietary, hybrid).

Группа IP-сетей под единым административным контролем (например, ISP, крупная корпорация, облачный провайдер). Идентифицируется ASN (Autonomous System Number, 16- или 32-битный). Внутри AS -- свой IGP (OSPF, IS-IS, EIGRP). Между AS -- BGP. Примеры: Cloudflare AS13335, Google AS15169, AT&T AS7018. Интернет -- это ~70000+ AS, обменивающихся маршрутами через BGP.

Организация, продающая доступ к интернету. Tier 1 ISP -- глобальные backbone (NTT, Telia, Level 3), peering между собой без оплаты. Tier 2 -- региональные, покупают transit у Tier 1. Tier 3 -- locals, покупают всё. На клиентской стороне ISP даёт CPE (модем, router), public IP (часто динамический), внешнюю связность. Bandwidth измеряется в Mbps/Gbps по плану. Между ISP -- peering point (IXP) для прямого обмена трафиком без uplink через Tier 1.

Физическая точка обмена трафиком между несколькими ISP / AS. Каждый участник подключается к общей фабрике (обычно switched LAN), обмен трафиком по BGP с peering-партнёрами. Снижает стоимость (не платить за transit) и latency (короче путь). Крупные IXP: DE-CIX (Frankfurt, ~10 Tbps), AMS-IX (Amsterdam), LINX (London), MSK-IX (Москва). Контентные провайдеры (Google, Netflix, Cloudflare) ставят CDN-кэши непосредственно в IXP для быстрого доступа местных пользователей.

Протокол L3 для control messages в IP-сети. Не для передачи данных приложений -- для диагностики и сообщений об ошибках. Типы сообщений: Echo Request/Reply (ping), Destination Unreachable (host/network/port), Time Exceeded (для traceroute), Redirect, Fragmentation Needed (для PMTUD). ICMP-пакет инкапсулируется в IP, без UDP/TCP. Часто блокируется firewall (особенно ping), что осложняет диагностику и ломает PMTUD.

Утилита для проверки доступности host'а через ICMP Echo Request/Reply. Показывает: отвечает ли host, RTT (round-trip time), packet loss. Использование: ping example.com, ping -c 10 8.8.8.8 (10 запросов на Linux). Не показывает работоспособность TCP/UDP-сервисов -- сервер может пинговаться, но HTTP не работать. На Windows используется ICMP type 8/0. Если ping не идёт, не значит, что host недоступен -- ICMP может быть заблокирован firewall'ом.

Утилита, показывающая маршрут пакета от source до destination, hop за hop. Работает так: шлёт пакеты с увеличивающимся TTL (1, 2, 3, ...). Каждый router на пути, увидев TTL=0, шлёт обратно ICMP Time Exceeded -- так мы узнаём его IP. На Linux по умолчанию использует UDP к высокому порту; mtr более интерактивная. Звёздочки (***) на hop -- router не отвечает (может быть rate-limit ICMP, не настроен Time Exceeded, или firewall). Не гарантирует, что обратный путь такой же -- routing асимметричен.

Сервер, принимающий запросы от клиентов и форвардящий их на backend-сервера, скрывая последних. Функции: load balancing, SSL termination (TLS заканчивается на reverse proxy, backend идёт plain HTTP), caching, compression, security (WAF). Популярные реализации: NGINX, HAProxy, Envoy, Traefik, AWS ALB. Клиент видит только адрес reverse proxy, не знает, сколько backend'ов за ним. В отличие от forward proxy (стоит со стороны клиента, для outbound), reverse стоит со стороны сервера.

Устройство или сервис, распределяющее запросы между несколькими backend-серверами. Цель: scalability (больше серверов -- больше пропускной способности), redundancy (отказ одного backend не убивает сервис), health checks (не слать запросы упавшим). Типы по уровню: L4 (на основе IP+port, видит TCP/UDP), L7 (на основе HTTP-заголовков, URL, cookies). Алгоритмы: round-robin, least-connections, weighted, consistent hashing. Реализации: hardware (F5, Citrix NetScaler), software (HAProxy, NGINX), облачные (AWS NLB/ALB, GCP).

Балансировка на транспортном уровне: принимает решения по IP-адресам и портам (TCP/UDP), не разбираясь в HTTP. Быстрее L7 (меньше парсинга), но и менее гибкая (нельзя роутить по URL). Использует методы: DNAT (destination NAT -- меняет dst IP), Direct Server Return (ответ идёт мимо балансировщика напрямую), L2 forwarding. Применяется для не-HTTP трафика (БД, mail, gaming) и для high-throughput сценариев. Примеры: AWS NLB, HAProxy в mode tcp, LVS (Linux Virtual Server).

Балансировка на application layer: принимает решения на основе HTTP-заголовков, URL, cookies, тела запроса. Может делать: routing /api/v1/users в один cluster, /api/v2/orders в другой; sticky sessions через cookies; request rewriting; A/B testing; rate-limiting per-user. Тяжелее L4 (нужно парсить HTTP), но даёт rich функциональность. Реализации: NGINX, Envoy, HAProxy в mode http, AWS ALB. Современный microservice ingress (Istio, Linkerd) -- всегда L7.

Распределённая сеть кэширующих серверов по всему миру, ускоряющая доставку статического контента (картинки, CSS, JS, video) и API. При запросе пользователя CDN отвечает с ближайшего edge-server'а вместо origin-сервера за океаном -- снижается latency, разгружается origin, защищается от DDoS. Крупные CDN: Cloudflare, Akamai, Fastly, CloudFront. Работают через DNS (anycast IP) или CNAME на CDN-домен. Поддерживают cache invalidation, edge functions, image optimization.

CLI-утилита для захвата и фильтрации сетевых пакетов на интерфейсе. Использует libpcap. Требует root (или CAP_NET_RAW). Базовое использование: tcpdump -i en0 'port 80' (захват HTTP на интерфейсе en0). Поддерживает BPF-фильтры: 'host 8.8.8.8 and tcp port 53'. Запись в файл: -w capture.pcap, чтение: -r. Опции вывода: -n (не резолвить DNS), -v / -vv / -vvv (verbose), -A (показывать payload как ASCII), -X (hex + ASCII). Запись pcap-файла можно открыть в Wireshark для подробного анализа.

GUI-приложение для захвата и анализа сетевых пакетов. Самый популярный инструмент для дебага сетей. Поддерживает 3000+ протоколов с детальной декомпозицией: видишь каждое поле в заголовке. Display filter (отдельный от capture filter): http.host == 'example.com', tcp.flags.reset == 1. Follow TCP/HTTP Stream -- собрать payload одного соединения. CLI-вариант: tshark. Бесплатный, open-source. Может анализировать pcap-файлы, захваченные через tcpdump на сервере.

CLI-утилита для DNS-запросов, более гибкая чем nslookup. Использование: dig example.com -- A-запись, dig MX example.com -- MX, dig +short -- только ответ, dig +trace -- полный путь от root, dig @8.8.8.8 example.com -- использовать конкретный resolver. Вывод секции: ANSWER (ответ), AUTHORITY (NS), ADDITIONAL (glue records). Часто используется для дебага DNS-проблем: проверить, какие A-записи отдаёт authoritative, какой TTL, есть ли DNSSEC. На Windows нет dig из коробки -- ставится через BIND-tools.

Утилита для DNS-запросов, проще чем dig. Кросс-платформенная (есть в Windows, Linux, macOS). Базовое: nslookup example.com -- A-запись от системного resolver, nslookup example.com 8.8.8.8 -- от Google DNS. Поддерживает type=A, type=MX, type=NS и т.д. Менее verbose чем dig, но достаточно для быстрых проверок. На Linux/macOS чаще предпочитают dig.

Старая утилита для показа сетевых соединений, routing table, статистики интерфейсов. Использование: netstat -tunlp (TCP + UDP, listening, не резолвить, показать процесс) на Linux, netstat -an на macOS. Депрекейтнута в большинстве distro в пользу ss. На macOS netstat -rn показывает routing table. Знание netstat нужно для legacy-систем; в новом коде -- ss или lsof.

Современная замена netstat, быстрее и информативнее. Использование: ss -tunlp -- открытые TCP+UDP listening сокеты с процессами, ss -t state established -- активные TCP, ss -K (kill) -- закрыть соединение. Использует netlink API ядра напрямую (быстрее /proc). Стандарт в современных Linux distro. На macOS нет ss, используется lsof -i или netstat.

Универсальный CLI-инструмент для работы с TLS и криптографией. Часто используется для дебага TLS: openssl s_client -connect example.com:443 -servername example.com (показать сертификат, версию протокола, cipher). Поддерживает: создание самоподписанных сертификатов (req -x509), CSR (req -new), проверку дат (x509 -dates), просмотр приватных ключей, расшифровку. Незаменим при настройке HTTPS и mTLS. Поставляется с OpenSSL библиотекой -- основой TLS на Linux.

CLI-утилита для отправки HTTP-запросов и других протоколов (FTP, SMTP, telnet, file). Использование: curl -v https://api/v1/users (verbose с заголовками), curl -X POST -d '{"name":"Lev"}' -H 'Content-Type: application/json' (POST с JSON), curl --resolve example.com:443:1.2.3.4 (override DNS). Для дебага: --trace, --trace-time. Не следует редиректам без -L. Поддерживает HTTP/2 (--http2), HTTP/3 (--http3, требует свежей сборки). De facto стандарт для тестирования API из shell.

Утилита для скачивания файлов по HTTP/HTTPS/FTP. В отличие от curl, оптимизирована для рекурсивного скачивания (зеркалирование сайтов): wget -r -np example.com/dir/. Удобна для batch-загрузки: -i urls.txt -- скачать URL'ы из файла. Резюмирует прерванные загрузки (-c). На macOS нужно ставить через brew, на Linux обычно предустановлен. Для interactive дебага API чаще используется curl, для скачивания файла -- wget.

Протокол, автоматически назначающий IP-параметры host'у при подключении к сети: IP-адрес, маска, gateway, DNS-серверы, lease time. Работает на UDP/67-68. Процесс DORA: Discover (broadcast от клиента 'кто даст IP?'), Offer (от сервера 'возьми этот IP'), Request (клиент 'беру'), Acknowledgement (сервер 'окей'). Lease time -- срок аренды (обычно 24 часа); клиент пытается продлить за половину lease. Если DHCP-сервер падает, существующие клиенты работают до конца lease, новые -- не подключатся.