Ethernet: доставить кадр соседнему компьютеру

Задача: два процесса, два компьютера, один локальный сегмент

На прошлом занятии client и server обменялись данными через loopback. Теперь оставим почти тот же Winsock-код, но действительно перенесём process B на второй компьютер в той же локальной сети.

Процесс A уже подготовил payload:

D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82

Это шесть символов Привет, двенадцать UTF-8-байтов. Компьютер A имеет IPv4 192.168.10.42/24, компьютер B — 192.168.10.80/24. Они подключены к одному Ethernet-коммутатору. Теперь нужно доказать не абстрактное «сеть работает», а конкретную цепочку:

NIC A -> кабель -> switch -> кабель -> NIC B

На этом участке IP-пакет едет внутри Ethernet-кадра, а кадр передаётся через физическую среду как последовательность символов.

Шаг 1. PHY не знает слово «Привет»

Ethernet объединяет несколько технологий с общей канальной моделью. Удобно разделить две части:

• MAC работает с кадрами, MAC-адресами и FCS;
• PHY согласует скорость и режим линии, кодирует данные физическими символами и восстанавливает их на другом конце.

На витой паре PHY использует электрическую сигнализацию. В Ethernet по оптоволокну — оптическую. Разные поколения Ethernet используют разные кодировки: модель «высокое напряжение — 1, низкое — 0» слишком груба даже для первой диагностики. На приёмной стороне важны синхронизация, допустимые уровни сигнала и способность декодировать символы, а не человеческое значение payload.

Если link-индикатор погас, ОС показывает интерфейс Disconnected, а кадры не покидают NIC, причина находится ниже IP. Менять порт процесса или DNS в этот момент бессмысленно.

Wi-Fi решает похожую задачу локальной доставки через радиосреду, но его кадры определены IEEE 802.11. Здесь мы изучаем IEEE 802.3 Ethernet; IP и транспорт позже смогут работать поверх обоих каналов.

Шаг 2. MAC оформляет IP-пакет как кадр

Базовый Ethernet II frame на одном link выглядит так:

[ Destination MAC 6 ]
[ Source MAC      6 ]
[ EtherType       2 ]
[ Payload       46..1500 ]
[ FCS              4 ]

На основном маршруте пока достаточно четырёх мыслей: frame имеет адрес отправителя, адрес следующего получателя, указание типа payload и проверку целостности локальной передачи.

Шаг 3. IP отвечает «кому», ARP — «какой MAC на этом link»

ОС сравнивает destination 192.168.10.80 со своими on-link маршрутами. Для адреса 192.168.10.42/24 оба узла принадлежат сети 192.168.10.0/24, поэтому следующим соседом становится сам B, а не default gateway.

Но Ethernet не доставляет кадр по IPv4-адресу. Компьютеру A нужен MAC B. Если соответствия нет в neighbor cache, A отправляет ARP request в broadcast frame:

Who has 192.168.10.80? Tell 192.168.10.42

Узлы в том же broadcast domain могут получить запрос, но отвечает владелец 192.168.10.80. В ARP reply он сообщает свой MAC. После этого A формирует кадр:

Destination MAC: MAC компьютера B
Source MAC:      MAC компьютера A
EtherType:       IPv4
Payload:         IP packet ... TCP/UDP ... "Привет"

ARP не проверяет, что на B запущено нужное приложение. Он лишь даёт канальному уровню адрес следующего IPv4-соседа. Для IPv6 похожую роль играет Neighbor Discovery поверх ICMPv6, а не ARP.

Шаг 4. Switch принимает локальное решение

Коммутатор изучает source MAC входящих кадров и запоминает, за каким портом недавно был виден адрес. Затем он смотрит destination MAC:

• известный unicast MAC отправляется на соответствующий порт;
• неизвестный unicast временно рассылается по другим портам VLAN;
• broadcast рассылается внутри broadcast domain;
• кадр для MAC на том же входном порту не нужно выводить на остальные.

Switch не обязан понимать слово Привет, TCP-порт или destination IP, чтобы переслать обычный кадр. Его базовое решение относится к канальному уровню.

Когда NIC B принимает подходящий неповреждённый кадр, он передаёт payload сетевому стеку B. IP распознаёт локальный destination, транспорт находит конечную точку по протоколу и порту, и только процесс B получает 12 байтов.

C/Winsock checkpoint: тот же код, но другой путь

Возьмите scaffolded TCP client/server из главы о socket. Сначала запустите их на 127.0.0.1, затем без изменения payload и socket lifecycle перенесите server на второй lab-компьютер и замените только адрес назначения клиента.

В C-коде по-прежнему есть IP address и port, но нет destination MAC и номера порта switch. Их выбирают route lookup, neighbor cache, driver и сетевое оборудование. Это важное разделение ответственности: приложение просит доставить байты endpoint, но не строит Ethernet frame вручную.

Сравните два запуска:

send() == 12 в обоих случаях остаётся локальным фактом. Только remote log process B доказывает, что приложение прочитало эти 12 байт.

Предсказание → эксперимент → доказательство

Опыт требует две отдельные лабораторные машины в одном VLAN. Замените адреса на выданные преподавателем.

Предсказание. До отправки запишите destination IP первого IP-пакета, destination MAC первого unicast frame и MAC, который появится в neighbor cache. Для on-link B все три указывают на B, но относятся к разным уровням.

Эксперимент. На A снимите состояние до и после запуска клиента:

Get-NetIPAddress -AddressFamily IPv4
Find-NetRoute -RemoteIPAddress 192.168.10.80
Get-NetNeighbor -IPAddress 192.168.10.80 -ErrorAction SilentlyContinue

# запустите C-клиент один раз

Get-NetNeighbor -IPAddress 192.168.10.80

Чтобы увидеть и ARP, и TCP в одном опыте, откройте Wireshark на физическом интерфейсе A с capture filter arp or tcp port 27015, запустите клиент один раз и остановите запись. Port-only filter в Pktmon ниже покажет TCP-путь, но не обязан включить ARP, у которого нет transport port.

Для встроенного capture откройте elevated PowerShell на отдельном lab-хосте. Команда pktmon filter remove удаляет все существующие pktmon-фильтры. Сначала посмотрите список. Если фильтры принадлежат другому опыту, хост общий или production, остановитесь и используйте отдельную точку capture.

pktmon filter list

# Только после проверки, что на выделенном lab-хосте фильтры можно удалить:
pktmon filter remove
pktmon filter add -p 27015
pktmon start --capture --pkt-size 0 --file-name ethernet-local.etl
# запустите клиент один раз
pktmon stop
pktmon etl2pcap ethernet-local.etl --out ethernet-local.pcapng

Доказательство. В evidence note сохраните:

local IP/prefix:
route says on-link or gateway:
neighbor IP -> MAC and state:
ARP request/reply observed in Wireshark or neighbor transition:
unicast frame destination MAC:
IP destination inside that frame:
12-byte payload observed or not observed:

Capture может показывать несколько представлений пакета на разных компонентах Windows, а offload меняет вид внутри хоста. Не считайте каждую строку уникальным физическим кадром; сопоставляйте адреса, протокол и payload.

Частые заблуждения

«Switch пересылает пакет по IP». Базовый Ethernet switch принимает решение по destination MAC. Маршрутизатор разбирает IP и создаёт новый frame для другого link.

«MAC-адрес идёт до удалённого сервера». MAC действует в пределах конкретного канального участка. В следующей главе destination MAC станет MAC шлюза, хотя destination IP останется адресом B.

«Ethernet — это только электрические импульсы». Ethernet определяет и общую MAC-модель, и семейства PHY. Физическая сигнализация и формат кадра — связанные, но разные обязанности.

Проверьте модель

Короткий итог

• Ethernet PHY переносит символы, а MAC работает с кадрами и MAC-адресами.
• ARP сопоставляет on-link IPv4-адрес с Ethernet-адресом соседа.
• Switch пересылает кадр внутри broadcast domain, не маршрутизируя IP.
• IP destination и destination MAC могут указывать на один и тот же локальный хост, но это разные поля с разными сроками жизни.
• Успех отправки из C ещё не является доказательством приёма процессом B.

Мост к следующей главе

Локальный кадр дошёл до B. Теперь перенесём B в другую сеть. Компьютер A уже не сможет получить его MAC через ARP: первым соседом станет default gateway. Нужно понять longest prefix match, смену frame на каждом hop и только после этого — почему MTU одного участка ограничивает размер IP-пакета на всём пути.

Официальные источники

• IEEE 802.3-2022: Ethernet MAC и PHY
• RFC 826: Address Resolution Protocol
• RFC 894: IPv4 datagrams over Ethernet
• Microsoft Learn: Packet Monitor (Pktmon)