Что показывает схема
Packet capture — это наблюдение в конкретной точке, а не всеведущая запись «того, что было в сети». Sender host hook, независимая link capture и peer host hook находятся по разные стороны kernel processing, NIC offload и физического пути. Их нужно коррелировать по tuple, sequence context и времени.
Схема также проводит TLS boundary: application создаёт plaintext до TLS record layer, а обычный capture ниже этой границы видит защищённые records. Это полезный evidence для handshake, timings и transport behavior, но не автоматическая расшифровка HTTP content.
Как читать observation points
- Sender host capture доказывает, что representation дошло до выбранного capture hook. Это ещё не peer delivery.
- NIC/offload boundary напоминает, что часть segmentation/checksum work может выполняться аппаратно. Конкретный результат зависит от tool, driver и hook.
- Independent link capture ближе к observed link traffic, но тоже имеет filter, loss и placement limitations.
- Peer host capture подтверждает arrival в remote observation point, но не обязательно successful recv() или application handling.
- Application log нужен вместе с captures, чтобы связать network bytes с request/result.
Четыре сценария
- Three observers строит correlated timeline одного delivery.
- Encrypted content показывает, почему protected TLS records не равны видимому HTTP plaintext.
- Offload boundary запрещает сравнивать host packet image и wire image без учёта capture point.
- Missing peer evidence отделяет доказанную local transmit attempt от недоказанной delivery.
Предсказание до запуска
Предскажите, в какой capture увидите HTTP method при нормальном HTTPS без session keys. Ни в sender/wire/peer captures ниже TLS boundary. Затем предскажите, почему один host capture способен показать checksum, который выглядит незавершённым: packet work могло завершиться позже на NIC. Это hypothesis о capture boundary, а не разрешение игнорировать любую checksum error.
Практика на C и Winsock
Добавьте в client/server logs monotonic timestamp, connection tuple, request id, requested send length, actual send/recv result и saved WSA error. Не логируйте весь payload. recv() возвращает доступные bytes, а не «packet из pcap» и не прикладное message; сопоставление выполняется через protocol framing.
На Windows можно использовать встроенный Packet Monitor для capture, filtering, counters и drop detection. Перед запуском зафиксируйте component/capture point, filter и time window. После capture не ограничивайтесь красивым screenshot: сохраните исходный trace и exact conversion/analysis command.
Evidence checklist
- clocks или способ выровнять timelines;
- source/destination addresses, ports и protocol;
- место hook и включённые offload features;
- одинаковый capture filter и достаточно широкий time window;
- TCP sequence/ack context или protocol request id;
- sender/peer application logs для подтверждения send/recv/handler outcome.
Частые ошибки
- «Пакет есть у sender» не означает «peer process получил message».
- «Пакета нет» без проверки interface, filter, loss и capture window — слабое отрицательное evidence.
- TLS record length и timing могут быть видимы, но content остаётся защищённым.
- Capture может наблюдать retransmission, coalescing или segmentation иначе, чем вызовы send()/recv().
- Checksum/offload surprise нужно проверять сравнением observation points, а не объявлять corruption по одному trace.
Контрольные вопросы
- Какие две точки нужны, чтобы отличить local transmit attempt от remote arrival?
- Почему pcap не восстанавливает границы вызовов send()?
- Как TLS меняет доступный evidence, не делая capture бесполезным?
Источники