← Back to notes

Компьютерные сети: конспект курса —
от провода до HTTPS

2026-06-11

#osi#tcp/ip#dns#http#tls

Сквозной разбор стека L1→L4 плюс DNS, HTTP/HTTPS и TLS, собранный из пройденного. Акцент на механизмах, а не на фактах: важно не «что», а «почему именно так».

Как пользоваться:

  • Теория (этапы 0–5) — для перечитывания и справки.
  • Вопросы для холодного прогона — сначала отвечай из головы, не подглядывая, потом сверяйся с Ключами.
  • Частые ловушки — список подмен, на которых легко построить неверную модель. Перечитывать перед прогоном.

0. Две модели: OSI и TCP/IP

OSI — референсная модель для теории и общего языка. TCP/IP — то, на чём реально работает интернет. Знать обе, но не путать «удобную абстракцию» (OSI) с «тем, что бежит по проводу» (TCP/IP).

TCP/IP                OSI
──────                ──────
                      7 Прикладной
Прикладной            6 Представления
                      5 Сеансовый
──────                ──────
Транспортный          4 Транспортный
──────                ──────
Сетевой               3 Сетевой
──────                ──────
Канальный +           2 Канальный
физический            1 Физический

Сквозной приём всего стека — демультиплексирование: каждый уровень несёт указатель, кому передать содержимое выше. EtherType (L2) → выбирает протокол L3 · поле Protocol в IP → выбирает L4 (TCP=6, UDP=17) · порт → выбирает приложение.

Справочник по уровням и протоколам — в заметке про OSI и TCP/IP.

Этап 1. Физический и канальный уровни (L1/L2)

L1 — биты как сигнал

Превращает 1 и 0 в физическое явление: напряжение (медь), свет (оптика), радио (Wi-Fi). Не знает ни адресов, ни кадров. Проблема синхронизации (длинная серия одинаковых битов сбивает приёмник) решается кодированием с переходами (Manchester, 4B/5B). Устройства L1 — хабы, повторители (вымерли).

L2 — биты превращаются в кадры

Группирует биты в кадры, добавляет локальную адресацию (MAC), проверку целостности (FCS), правила доступа к среде.

MAC-адрес — 48 бит (6 байт), 00:1A:2B:3C:4D:5E. Первые 3 байта — OUI (вендор), последние 3 — устройство. FF:FF:FF:FF:FF:FF — широковещательный. Локален и не маршрутизируется: за пределами сегмента не значит ничего.

Анатомия Ethernet-кадра

┌──────────┬──────────┬──────────┬──────┬──────────────┬──────┐
│ Preamble │ Dest MAC │ Src MAC  │ Type │   Payload    │ FCS  │
│  7+1 б   │   6 б    │   6 б    │ 2 б  │ 46–1500 байт │ 4 б  │
└──────────┴──────────┴──────────┴──────┴──────────────┴──────┘
  • Type (EtherType) — что в Payload: 0x0800 IPv4, 0x86DD IPv6, 0x0806 ARP. Демультиплексирование на L3.
  • Payload — пакет вышестоящего уровня. Верх 1500 байт = MTU.
  • FCS — CRC32. Не сошлась → кадр молча выбрасывается. Ethernet обнаруживает ошибку, но не исправляет и не просит переслать. Восстановление — забота верхних уровней (TCP перешлёт; UDP потеряет).

Коммутатор vs хаб

  • Хаб — повторяет сигнал во все порты всегда. Общая среда → возможны коллизии.
  • Коммутатор — учит MAC-адреса (CAM-таблица), шлёт кадр только в нужный порт. У каждого порта свой кабель, full-duplex → коллизий между двумя ПК физически нет (сигналам негде встретиться).
  • Неизвестный Dest MAC → коммутатор флудит во все порты (как исключение, потом запомнит ответ). Хаб флудит всегда (единственный режим).
  • Коммутатор делит домены коллизий, но не домен широковещания. Роутер делит и то, и другое.

Broadcast-шторм

Петля между коммутаторами + нет STP → широковещательный кадр ходит по кругу и удваивается на каждом обороте. Смертелен, потому что у Ethernet-кадра нет поля TTL (у IP-пакета есть — гасит зациклившийся пакет). Коммутатор бессилен: у broadcast адресат «все» по определению, MAC-таблица неприменима. Лечится: петли — STP, размер домена — VLAN или роутер.

ARP — мост L2↔L3

Чтобы построить кадр, нужен MAC получателя, а есть только IP.

  1. Проверить ARP-кэш.
  2. Нет → широковещательный запрос «у кого IP X? сообщите MAC».
  3. Владелец отвечает адресно.
  4. Кэшировать.

Работает только внутри сегмента. Если IP в другой сети — хост ARP-ит не получателя, а шлюз по умолчанию.

Сегментация L2 на практике — в заметке про VLAN и trunk (802.1Q).

Этап 2. Сетевой уровень (L3)

IP логический и сквозной; MAC физический и локальный. IP неизменен от отправителя до получателя, MAC переписывается на каждом прыжке.

Маска подсети и развилка «свой/чужой»

Хост решает «получатель в моей сети или нет» побитовым AND своего адреса и адреса цели с маской:

хост:        192.168.1.10
маска /24:   255.255.255.0
AND       =  192.168.1.0   ← сеть хоста

цель .20:     AND /24 = 192.168.1.0  → совпало → СВОЙ  → ARP по .20
цель 8.8.8.8: AND /24 = 8.8.8.0      → не совп. → ЧУЖОЙ → MAC шлюза

На нестандартной маске считать обязательно побитово (не «по октетам»). Пример /26 (маска …192, блоки по 64):

.70  = 01000110  AND 11000000 = 01000000 = 64  → сеть .64
.50  = 00110010  AND 11000000 = 00000000 = 0   → сеть .0

.50 и .70 — в РАЗНЫХ сетях, хотя первые три октета совпадают.

Блоки по маскам: /25→128, /26→64, /27→32, /28→16. Сеть называется по нижней границе блока, где лежит хост.

Шлюз и связка с ARP

Цель чужая → ARP по шлюзу (его IP прописан в настройках) → в Dest MAC ложится MAC шлюза, но IP назначения в пакете остаётся серверным. L2 адресован «следующему прыжку», L3 — конечной цели.

Маршрутизация

Пакет идёт прыжками. Каждый роутер смотрит IP назначения, ищет в таблице (longest prefix match), передаёт дальше. На каждом прыжке: MAC src/dst переписываются, TTL −1, контрольная сумма заголовка пересчитывается. Неизменны: IP src/dst, порты, данные.

TTL — счётчик-предохранитель от зацикливания, НЕ указатель маршрута. Дошёл до 0 → пакет уничтожается, источнику шлётся ICMP. Маршрут роутер берёт из таблицы по IP назначения, не из TTL.

ICMP

Служебный протокол L3. ping — Echo Request/Reply. traceroute — хак поверх TTL: шлёт пробы с TTL 1, 2, 3…; каждый роутер, убивая пробу, шлёт назад ICMP Time Exceeded, в котором source IP = адрес этого роутера → так строится цепочка.

* * * в traceroute = «не пришёл ICMP-ответ» (фильтрация проб или обраток), не «сайт лежит». Дефолтный traceroute = UDP (легко режется); -I = ICMP, -T -p 443 = TCP SYN (пробивает там, где UDP молчит).

NAT и частные адреса

Частные диапазоны (10/8, 172.16/12, 192.168/16) не маршрутизируются в интернете. NAT подменяет приватный IP-источник на публичный и запоминает соответствие в таблице. Ответ возвращается, потому что: (1) исходящий IP едет внутри пакета, (2) таблица NAT пробивает путь обратно к конкретному устройству. Извне нельзя инициировать соединение — для непрошеного входящего в таблице нет записи, роутер его отбрасывает.

100.64.0.0/10 в трейсе = CGNAT (провайдерский NAT поверх домашнего, второй слой).

IPv6 — кратко

128 бит вместо 32, hex (2001:db8::1), NAT не нужен, ARP заменён на NDP. Принцип маршрутизации тот же.

Подсети, CIDR, DHCP и NAT/PAT подробнее — в заметке про сетевые основы.

Этап 3. Транспортный уровень (L4)

Порты и сокеты

IP довозит до машины, порт (16 бит) — до приложения. Сокет = IP:порт. Соединение опознаётся четвёркой: src IP, src port, dst IP, dst port. Один серверный порт 443 обслуживает тысячи клиентов, потому что клиентский IP:порт у каждого свой → каждая четвёрка уникальна. Well-known: 80 HTTP, 443 HTTPS, 53 DNS, 22 SSH.

TCP vs UDP — две философии

  • TCP — соединение с гарантиями: доставка, порядок, без дублей, защита получателя и сети. Цена — накладные расходы.
  • UDP — выстрелил и забыл: ни соединения, ни подтверждений, ни порядка. Цена почти нулевая. Потерю даже не заметит.

TCP: тройное рукопожатие

Клиент                          Сервер
  │ ── SYN seq=x ─────────────────▶ │
  │ ◀──── SYN-ACK seq=y, ack=x+1 ── │
  │ ── ACK ack=y+1 ───────────────▶ │
  │      ESTABLISHED — данные        │

Почему три, а не два: после двух сообщений полную картину имеет только клиент (знает, что обе стороны его слышат). Серверу не хватает подтверждения, что его SYN (его seq=y) дошёл до клиента — обратный канал не подтверждён. Третий ACK закрывает ровно это. seq — случайный (защита), считает байты, не пакеты.

TCP: надёжность

seq/ack нумеруют байты. ack = номер первого недостающего байта = «что жду следующим». Потеря:

получено до 5000, кусок 5001–6000 потерян, 6001–7000 пришёл
→ получатель повторяет ack=5001 (не 5002, не 6001)
→ кусок 6001–7000 НЕ выбрасывается — лежит в буфере
→ получатель НЕ шлёт запрос на недостающее (такого сообщения в TCP нет)
→ отправитель видит 3 одинаковых ack=5001 (duplicate ACK) и сам шлёт только 5001–6000
→ это fast retransmit

Ключевой механизм: получатель пассивно повторяет старый ack; отправитель догадывается по повтору. Никто ничего не «запрашивает».

Flow control vs congestion control

  • Flow control защищает получателя: он сообщает «окно» — сколько ещё байт примет в буфер.
  • Congestion control защищает сеть: отправитель наращивает темп осторожно, потери/задержки = сигнал перегрузки, сбрасывает скорость (slow start, CUBIC, BBR).

Закрытие — обмен FIN/ACK с каждой стороны (4 шага). SYN/ACK — установка (одноразово); duplicate ACK/retransmit — рабочая рутина во время передачи. Не путать фазы.

UDP: ниша

Живое видео/голос (поздно пересылать, гарантия порядка вредит — head-of-line blocking), DNS (мелкий запрос-ответ), игры (свежесть важнее полноты). Дефолтный traceroute — тоже UDP. QUIC (HTTP/3) — надёжность заново реализована поверх UDP, чтобы получить гарантии TCP без его болячек.

ICMP, сокеты, состояния TCP и сетевые утилиты — в заметке про TCP, UDP, ICMP и сокеты.

Этап 4а. DNS

Переводит имя в IP. Без него весь стек стоит — он работает на IP. Разрешение sashasup.link → 188.114.96.3 происходит до первого TCP-пакета.

Дерево и разрешение

Распределённая иерархия, имя читается справа налево: корень (знает, кто отвечает за TLD) → TLD .link (знает, кто за домены внутри) → авторитативный сервер домена (знает настоящий IP). Никто не знает всё, каждый знает «к кому дальше».

Клиент ──(1 рекурсивный запрос)──▶ Resolver
                                     │ (2) Root  → спроси .link
                                     │ (3) TLD   → спроси authoritative
                                     │ (4) Auth  → = 188.114.96.3
Клиент ◀──(5 готовый ответ)──────── Resolver

Запрос клиента → резолверу рекурсивный («сделай всё»). Резолвер по дереву ходит итеративно («дай ответ или адрес следующего»).

Кэш и TTL

Каждый уровень кэширует. DNS TTL = секунды жизни записи в кэше — НЕ путать с IP TTL (счётчик прыжков). Тёзки. Ступени кэша: браузер → ОС → резолвер; чем ближе сработала, тем быстрее.

Типы записей (по смыслу)

  • Адресация: A (IPv4), AAAA (IPv6), CNAME (алиас на имя), ALIAS/ANAME (CNAME-подобное на apex, проприетарно).
  • Почта: MX (куда слать, с приоритетами) + SPF/DKIM/DMARC (хранятся как TXT — переиспользовали готовый универсальный тип, чтобы не обновлять всю инфраструктуру).
  • Инфраструктура: NS (авторитативные серверы зоны = «referral» в схеме), SOA (служебная, одна на зону), PTR (обратная, в in-addr.arpa).
  • Безопасность/сервисы: CAA (какому CA разрешено выдавать сертификаты), DNSSEC (DS/RRSIG/DNSKEY), SRV (хост+порт сервиса), SVCB/HTTPS (параметры подключения до соединения).

CNAME и apex

Apex — голый домен (sashasup.link), вершина зоны. CNAME вешается на псевдоним и указывает на настоящее имя: www.sashasup.link CNAME sashasup.link. На apex CNAME нельзя: правило «на имени с CNAME нет других записей» конфликтует с обязательными на apex SOA и NS. На поддомене (shop.…) этих обязательных записей нет → CNAME можно.

Транспорт и безопасность

UDP/53 по умолчанию (мелкий запрос-ответ); откат на TCP для крупных ответов (зоны, DNSSEC). По UDP нет состояния → опознать ответ можно только по ID транзакции + порт, оба угадываемы → cache poisoning (атака Камински). Лечат: DNSSEC (подпись против подделки), рандомизация порта (смягчение). Приватность (запрос идёт открыто) → DoH/DoT — DNS поверх TLS/HTTPS, т.е. поверх TCP, ценой скорости.

DNSSEC, DoH/DoT/DoQ и операционные грабли DNS — в отдельной заметке про DNS.

Этап 4б. HTTP

Текстовый запрос-ответ поверх TCP.

GET /index.html HTTP/1.1            HTTP/1.1 200 OK
Host: sashasup.link                 Content-Type: text/html
User-Agent: ...                     Content-Length: 1256

                                    <!DOCTYPE html>...

Методы и свойства

GET (забрать), POST (создать/действие), PUT (заменить), PATCH (изменить), DELETE, HEAD (только заголовки), OPTIONS.

  • Безопасный — не меняет состояние (GET, HEAD).
  • Идемпотентный — повтор = тот же результат (GET, PUT, DELETE; POST — НЕТ).

Практика: GET можно повторить при сбое; повтор POST может создать второй заказ. Не «POST меняет, GET нет», а повтор POST накапливает эффект, а PUT идемпотентен, хоть и меняет.

Коды по классам

2xx успех · 3xx редирект (301 навсегда, 304 бери из кэша) · 4xx вина клиента (400/401/403/404/429) · 5xx вина сервера (500/502/503/504). Граница 4xx/5xx = граница вины.

Host и stateless

Host разруливает виртуальный хостинг: на одном IP (Cloudflare) тысячи сайтов, IP довёл до машины, Host выбирает сайт. HTTP stateless — память даёт cookies: сервер шлёт Set-Cookie, браузер прикладывает Cookie к каждому запросу → сессия поверх беспамятного протокола.

Эволюция

  • 1.1 — текст, один запрос за раз (HoL на уровне приложения), keep-alive.
  • 2 — бинарный, мультиплексирование в одном TCP; но потеря пакета тормозит все потоки (HoL уехал на TCP).
  • 3 — QUIC поверх UDP, потоки независимы, быстрее установка. Запись HTTPS/SVCB в DNS заранее сообщает «умею HTTP/3».

Кэширование, CORS, HSTS и детали HTTP/2–HTTP/3 — в отдельной заметке про HTTP.

Этап 4в. HTTPS / TLS

HTTPS = HTTP в шифрованном туннеле TLS. Слой TLS между TCP и HTTP. TLS-рукопожатие ≠ TCP-рукопожатие (тёзки на разных уровнях). SSL = старое имя TLS, отдельного шага нет.

Три гарантии: шифрование (никто не прочитает), целостность (не подменят), аутентификация (сервер настоящий).

Симметрика / асимметрика / гибрид

  • Симметрика (AES) — один общий ключ, быстрая. Проблема: как договориться о ключе через прослушиваемый канал.
  • Асимметрика (RSA, ECDH) — пара ключей (открытый/закрытый), из открытого не вычислить закрытый. Решает распределение, но медленная.
  • Гибрид (то, что делает TLS): асимметрией один раз договариваются о симметричном ключе, дальше весь объём шифруют симметрикой.

Диффи-Хеллман (обмен ключом без передачи секрета)

Публично: g=5, p=23   (видит и перехватчик)

Клиент: тайна a=6              Сервер: тайна b=15      ← a,b НЕ передаются
A = g^a mod p = 8    ──A=8──▶
                     ◀─B=19── B = g^b mod p = 19       ← A,B идут открыто
s = B^a mod p = 2             s = A^b mod p = 2
        └──────── общий секрет = 2, по сети не передавался ───────┘

Работает, потому что (g^b)^a = (g^a)^b = g^(a·b) — обе стороны приходят к g^(a·b). Перехватчик видит g, p, A, B, но чтобы добыть a из A, нужно решить дискретный логарифм — на больших числах неподъёмно. Вперёд (возвести) дёшево, назад (извлечь степень) нельзя.

Что секрет, что публично: тайна — степени a, b (строчные), их не шлют. Публичны — A, B (заглавные), ими меняются.

Forward secrecy

Эфемерный DH: a, b генерируются заново на каждое соединение и уничтожаются. Кража постоянного ключа сервера через год не вскрывает записанный год назад трафик: сессионный секрет давно стёрт, а постоянный ключ к нему не причастен (он используется для подписи, не для запирания ключа). В TLS 1.3 в полном (certificate) handshake обмен ключом — только эфемерный DH (исключение — PSK-only режим psk_ke, без forward secrecy).

RSA key exchange — мёртвая альтернатива (выпилен в 1.3)

Клиент придумывал секрет и отправлял по каналу, зашифровав открытым ключом сервера. Секрет реально летел по проводу (в шифре), заперт постоянным ключом сервера. Записал трафик → украл ключ через год → расшифровал секрет → весь архив. Нет forward secrecy. Отличие от DH: при RSA секрет передавался, при DH — нет.

Шифрование vs подпись

  • Чужим открытым ключом → расшифрует только владелец закрытого → прячет (секретность).
  • Своим закрытым ключом → проверит любой открытым → не прячет, доказывает авторство (подпись).

Целостность: MAC/AEAD vs FCS

MAC/AEAD ловит злонамеренную подмену (атакующий не пересчитает код без ключа). FCS на L2 ловит только случайный шум. Та же идея «проверка целостности», но FCS наивен (только случайная порча), MAC учитывает активного врага.

Сертификаты и цепочка доверия

Сертификат — подписанная CA связка «домен ↔ открытый ключ» (+ издатель, срок). Именно подпись (содержимое открыто, любой читает; подделать без ключа CA нельзя).

[Root CA]  самоподписан, предустановлен в trust store ── доверен аксиоматически
   │ подписывает
[Intermediate CA]  подписан корнем ── расходное звено (ключ "на передовой")
   │ подписывает
[Leaf: sashasup.link + публичный ключ]

Строится сверху вниз подписями, проверяется снизу вверх: сервер шлёт лист + промежуточные, браузер проверяет подписи до известного корня в trust store + совпадение домена + срок. Корень доверен без проверки, потому что предустановлен (якорь).

Зачем промежуточный: ключ корня держат офлайн в сейфе, им подписывают только промежуточные (редко). Утёк промежуточный → отзывают его, корень нетронут (замена корня = перевыкатка trust store на все устройства мира).

Аутентифицированный обмен ключом: сервер подписывает свои DH-значения закрытым ключом из сертификата. Так аутентификация и обмен ключом сходятся в точку — браузер уверен, что DH ведёт именно с владельцем сертификата, а не с MITM. Без подписи MITM провёл бы DH сам с собой.

Почему MITM не пройдёт (два независимых барьера)

  1. Подпись CA не подделать — нет закрытого ключа CA → нельзя нарисовать валидный сертификат.
  2. Domain validation не пройти — чтобы получить настоящий сертификат, CA требует доказать владение доменом (файл по HTTP или TXT-запись в DNS), а доменом атакующий не управляет.

CAA, отзыв, прозрачность

  • CAA (в DNS) перечисляет, какому CA разрешено выдавать на домен; CA обязан проверить и отказать, если его там нет. Страхует от того, что чужой CA втихую выпишет сертификат.
  • Отзыв до истечения: CRL/OCSP (с проблемами) → тренд на короткоживущие сертификаты (Let's Encrypt 90 дней, отзыв почти не нужен).
  • Certificate Transparency — все выданные сертификаты пишутся в публичные неизменяемые логи; логи не блокируют подделку превентивно, но делают её видимой (история DigiNotar 2011).

Хендшейк TLS 1.3 с практическими проверками — в отдельной заметке; X.509 и цепочка доверия — в заметке про TLS и firewall.

Этап 5. Сквозная сборка: https://sashasup.link от Enter до страницы

  1. DNS. Имя → IP. Кэши (браузер → ОС) → рекурсивный резолвер → иерархия корень → TLD .link → авторитативный → 188.114.96.3. (Сам DNS-запрос уже едет по UDP/53 — нижний стек крутится и тут.)
  2. Свой/чужой. Хост делает AND своего адреса и цели с маской → сеть другая → цель чужая.
  3. ARP. По чужому адресу ARP нельзя (broadcast наружу не уйдёт) → ARP по шлюзу → в кадр ложится MAC роутера, IP назначения остаётся серверным.
  4. Маршрутизация. Пакет идёт прыжками (шлюз → CGNAT 100.64… → магистраль → Cloudflare). На каждом: MAC переписывается, TTL −1. Неизменны IP/порты/данные.
  5. Обратный путь. Обеспечивают исходящий IP в пакете + таблица NAT (приватный 192.168… наружу не маршрутизируется, роутер подменил на публичный и запомнил).
  6. TCP-рукопожатие на :443 — SYN/SYN-ACK/ACK, канал установлен.
  7. TLS-рукопожатие поверх TCP: сертификат (цепочка до корня) доказывает подлинность; Диффи-Хеллман даёт общий ключ; DH подписан ключом из сертификата (аутентифицированный обмен). Итог — общий симметричный ключ + уверенность, с кем.
  8. HTTP GET по зашифрованному каналу, с заголовком Host: sashasup.link. Сервер → 200 OK + тело. Браузер рендерит.

(На практике Cloudflare почти наверняка отдаёт по HTTP/3 / QUIC поверх UDP — TCP+TLS совмещены в один шаг, каркас тот же.)

Частые ловушки (перечитывать перед прогоном)

  1. Получатель/L2 ничего не «запрашивает заново». L2 с битым FCS — молча выбрасывает. TCP-получатель при потере — повторяет старый ack; отправитель догадывается по 3 дублям (fast retransmit). Запроса на недостающее в TCP нет.
  2. MAC переписывается не потому, что «не знаем MAC цели». А потому что MAC локален и адресует следующий прыжок, не конечную цель.
  3. TTL — предохранитель от петель, не указатель маршрута. Маршрут — из таблицы по IP назначения.
  4. Коллизии нет на коммутаторе из-за физики (свой кабель на порт, full-duplex — сигналам негде встретиться), не из-за «умной рассылки».
  5. Forward secrecy — про механизм: одноразовый секрет уничтожен, постоянный ключ ни при чём. Не «за счёт математики вообще».
  6. RSA-обмен: секрет ПЕРЕДАВАЛСЯ (зашифрован открытым ключом сервера). DH — не передаётся. Отсюда разница в forward secrecy.
  7. Подпись ≠ шифрование. Закрытым ключом подписывают (не прячут). Сертификат подписан, а не зашифрован.
  8. DNS TTL ≠ IP TTL. Секунды кэша vs счётчик прыжков. Тёзки.
  9. CNAME на apex нельзя из-за обязательных SOA/NS и правила «CNAME живёт один».
  10. DH: тайна — степени a,b; публичны — A,B. Не перепутать, что летит по сети.

Вопросы для холодного прогона

Отвечай из головы, не подглядывая. Потом сверься с ключами.

L1/L2

  1. Что физически делает коллизию невозможной между двумя ПК на коммутаторе, но возможной на хабе?
  2. У кадра не сошлась FCS. Что делает получатель и чья задача — восстановить данные?
  3. Почему MAC бесполезен за пределами сегмента, но без него кадр не доедет до соседа? Кто смотрит на MAC при передаче?
  4. Петля между коммутаторами без STP. Почему это смертельно и отсутствие какого поля виновато?

L3

  1. Хост 10.0.0.20 /28. До 10.0.0.30 и до 10.0.0.14 — напрямую или через шлюз?
  2. Пакет через 3 роутера: что меняется на каждом прыжке, что неизменно?
  3. Зачем нужен TTL и что им НЕ является (подсказка: маршрут)?
  4. Хост шлёт на чужой IP: по какому IP делает ARP и чей MAC в кадре? Почему не MAC цели?
  5. 100.64.0.1 в трейсе — что это и о чём говорит?
  6. Как сервер адресует ответ обратно, если твой 192.168… не маршрутизируется?

L4

  1. 500 клиентов на одном серверном порту 443. Как ОС их различает?
  2. Получено до 12000, 12001–13000 потерян, 13001–14000 пришёл. Какой ack? Что с пришедшим куском? По какому сигналу отправитель шлёт повтор?
  3. Почему рукопожатие — три сообщения? Чего не хватает серверу после двух?
  4. Игра шлёт координаты 60 раз/сек: TCP или UDP и почему гарантия порядка тут вредна?

DNS

  1. Резолвер 30 сек назад разрешил имя, TTL 600. Пойдёт ли снова к корню? Почему?
  2. DNS TTL 3600 и IP TTL — одно и то же? Что считает каждый?
  3. Почему на sashasup.link нельзя CNAME, а на shop.sashasup.link можно? Что обязано лежать на первом?
  4. Почему по UDP возможен cache poisoning и какие два поля угадывает атакующий?

HTTP

  1. На одном IP тысячи сайтов. Что подсказывает серверу, чью страницу отдать?
  2. Граница 4xx/5xx — это граница чего? Пример из каждого класса.
  3. HTTP stateless, но ты залогинен между запросами. Какой механизм и как?

TLS

  1. Зачем и симметрика, и асимметрика — какая для чего?
  2. В DH: что в тайне (буквы), что публично (буквы), что летит по сети? Почему перехватчик не вычислит секрет?
  3. Forward secrecy: что при краже ключа сервера через год — почему прошлое нечитаемо с эфемерным DH?
  4. RSA key exchange: секрет передавался или нет? А в DH? Почему это лишало RSA forward secrecy?
  5. Открытым ключом получателя vs закрытым отправителя — что достигается, который прячет?
  6. Что внутри сертификата (кроме подписи) и какая операция его заверяет — почему она?
  7. Три звена цепочки: кто кого подписывает, какое доверено без проверки и почему?
  8. MITM умеет DH и хочет выдать себя за домен. Два барьера, на которых он ломается?
  9. Что делает CAA: что перечисляет и что обязан сделать CA перед выдачей?

Ключи к вопросам

  1. У каждого порта свой кабель, приём/передача по разным парам (full-duplex) — сигналы двух хостов никогда не в одной среде, встретиться негде. На хабе среда общая.
  2. Молча выбрасывает кадр. Восстановление — верхние уровни (TCP перешлёт, UDP потеряет). На L2 запроса на повтор нет.
  3. MAC локален, переписывается на каждом прыжке, за сегментом не значит ничего. На MAC при передаче смотрят коммутатор и сетевая карта (на IP не глядят). Без MAC следующего узла кадр некуда положить физически.
  4. Широковещательный кадр в петле размножается бесконечно — у Ethernet нет TTL (предохранителя). Коммутатор бессилен: broadcast адресован «всем», MAC-таблица неприменима.
  5. .20 /28 → блок .16–.31. .30 там же → напрямую. .14 в блоке .0–.15 → через шлюз.
  6. Меняются: MAC src/dst, TTL −1 (и пересчёт контрольной суммы заголовка). Неизменны: IP src/dst, порты, данные.
  7. TTL — счётчик-предохранитель от зацикливания (0 → пакет уничтожен). НЕ указатель маршрута — маршрут берётся из таблицы по IP назначения.
  8. ARP по шлюзу (IP шлюза), в кадре MAC шлюза. MAC цели нельзя узнать — она не в сегменте, ARP туда не долетит; цель чужая по маске.
  9. CGNAT (100.64.0.0/10) — провайдерский NAT поверх домашнего; провайдер прячет многих абонентов за общими публичными адресами (нехватка IPv4).
  10. Исходящий IP внутри пакета (сервер меняет src↔dst). 192.168… наружу не маршрутизируется → NAT подменил на публичный и хранит в таблице, кому вернуть.
  11. По уникальной клиентской паре IP:порт (серверный конец у всех одинаков; четвёрка уникальна).
  12. ack=12001 (первый недостающий). 13001–14000 лежит в буфере (не выброшен). Отправитель видит 3 дубля ack=12001 → fast retransmit, шлёт только 12001–13000. Запроса на недостающее нет.
  13. После двух сообщений знает всё только клиент. Серверу не хватает подтверждения, что его SYN (seq=y) дошёл до клиента — обратный канал не подтверждён. Третий ACK закрывает это.
  14. UDP: свежесть важнее полноты, досланные координаты устарели; гарантия порядка TCP = head-of-line blocking, старый потерянный пакет держал бы всё свежее.
  15. Не пойдёт — отдаст из кэша, пока жив TTL (600 сек). Ступени: браузер/ОС → резолвер.
  16. Нет. DNS TTL — секунды жизни записи в кэше; IP TTL — убывающие прыжки до уничтожения пакета. Тёзки.
  17. sashasup.link — apex, на нём обязательны SOA и NS, а правило «на имени с CNAME нет других записей» с ними конфликтует. На shop обязательных записей нет → CNAME можно.
  18. По UDP нет состояния соединения → ответ опознаётся только по угадываемым ID транзакции + порт источника; кто реально прислал — проверить нечем. Подпись ответов отсутствует.
  19. Заголовок Host (виртуальный хостинг).
  20. Граница вины: 4xx — клиент (напр. 404 нет ресурса), 5xx — сервер (напр. 503 недоступен/перегружен).
  21. Cookies: сервер Set-Cookie, браузер прикладывает Cookie к каждому запросу → сессия поверх stateless.
  22. Асимметрией один раз добывают симметричный ключ; симметрикой шифруют весь объём (асимметрика дорогая, гонять ею всё нельзя).
  23. Тайна — степени a, b (не передаются). Публичны — A, B (летят по сети). Перехватчик не добудет a из A — это дискретный логарифм, на больших числах неподъёмно.
  24. Эфемерные a,b сгенерированы на сессию и уничтожены; красть нечего, постоянный ключ к сессионному секрету не причастен → прошлое нечитаемо.
  25. RSA: секрет передавался (зашифрован открытым ключом сервера), заперт постоянным ключом → кража ключа задним числом вскрывает архив. DH: не передавался, поэтому forward secrecy.
  26. Открытым получателя → прячет (расшифрует только он). Закрытым отправителя → подпись, не прячет (удостоверяет авторство).
  27. Связка «домен ↔ открытый ключ» (+ издатель, срок). Заверяет подпись CA — цель не спрятать (содержимое открыто), а доказать, что связку заверил конкретный CA; подделать без его ключа нельзя.
  28. Корень → промежуточный → лист, каждый подписывает нижестоящего. Без проверки доверен корень — самоподписан и предустановлен в trust store (якорь).
  29. (1) Подпись CA не подделать (нет ключа CA). (2) Domain validation не пройти (не владеет доменом — ни сайтом по HTTP, ни DNS-зоной).
  30. CAA перечисляет, какому CA разрешено выдавать на домен; CA обязан проверить её перед выдачей и отказать, если его там нет. Страхует от чужого/скомпрометированного CA.

Куда дальше (отдельные ветки, не продолжение лестницы)

Компьютерные сети: конспект курса — от провода до HTTPS | Aleksandr Suprun