Введение
У Willow Games два сетевых канала и два вида работы: небольшие обновления счёта и крупные звуковые файлы для репетиции. Оба сервиса уже работают, но канал с самым быстрым ответом не обязательно быстрее всех передаст большой файл.
Вы попробуете обычную доставку, сравните задержку и скорость передачи к одному адресату по обоим путям и после каждого опыта восстановите исходный маршрут. Нужны базовые навыки работы с терминалом и чтения адреса назначения, следующего узла и маршрута с ограниченной областью действия, изученные в предыдущем проекте по маршрутизации или на аналогичной практике. Опыт программирования, кодирования медиа, формирования трафика и iperf не предполагается.
Все команды выполняйте в Event Client, а записи приёмников читайте в Event Receipts. Каждая лабораторная работа готовит собственную изолированную сеть; ничего из предыдущей VM не требуется. Длительность 45 минут — оценка автора с учётом чтения и обычных ошибок, а не измеренное время прохождения новичками.
Попробуйте небольшое обновление и большую передачу
На этом шаге вы воспользуетесь уже работающим сервисом счёта, затем выполните две реальные демонстрационные передачи. Начните в Event Client. Это терминал с оболочкой администратора внутри изолированного сетевого пространства имён Linux, уже в /home/labex/project/event-links. Приёмник находится в другом пространстве имён; они используют одно ядро VM. Не выполняйте эти команды в оболочке платформы. Открытие вкладки не пересоздаёт сеть.
Willow Games нужны быстрые операции со счётом и полные файлы звука для репетиции. Небольшой запрос большую часть времени ждёт перемещения пакетов; крупной передаче также нужна достаточная пропускная способность, чтобы перенести все байты. Задержка — время прохождения, а скорость полезной передачи — объём полезных данных, доставляемых за секунду. Ни одна из этих характеристик отдельно не описывает любую задачу.
pwd выводит рабочий каталог. cat выводит файл. Если команда сообщает об отсутствующем файле, сравните написание и вернитесь в рабочий каталог полной командой cd ниже; опечатка не требует сброса VM.
pwd
cd /home/labex/project/event-links
cat links.tsv
Две строки показывают lane1 и lane2, их следующие узлы и исходные адреса этого клиента. Следующий узел — сосед, получающий пакет на пути к назначению. Адрес сервиса счёта — 10.205.10.10, а медиасервиса — другой адрес 10.205.10.20. Оба слушают порт 8080. Задержка и пропускная способность каналов подготовлены при инициализации; не меняйте формирование трафика, адреса и сервисы.
Начните с существующего рабочего счёта. curl передаёт HTTP-ресурс. --noproxy '*' обходит настройки прокси окружения для всех адресов; кавычки не дают оболочке раскрыть шаблон. -f превращает HTTP-ошибки в неуспешное завершение, -s скрывает индикатор прогресса, а -S сохраняет вывод ошибок. Вместе эти параметры записываются -fsS. --max-time 35 ограничивает всю передачу 35 секундами. URL выбирает фактическое назначение, порт и ресурс.
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Ожидайте warmup, счёт 1–1 и preserved. Этот нормальный пример должен оставаться доступным. Он не является вашей новой передачей.
Прочитайте демонстрационный счёт в JSON: фигурные скобки заключают именованные поля, строки используют двойные кавычки, а два значения счёта — целые числа.
cat source/demo.json
Ожидаются матч demo, хозяева 1, гости 0. -H задаёт тип содержимого HTTP. --data-binary @source/demo.json читает именно этот файл и отправляет его через HTTP POST; @ означает тело из файла. -w выводит краткий результат измерения времени после ответа. В строке в одинарных кавычках \n означает перевод строки, а %{time_total} — прошедшие секунды. Скопируйте всю команду одной строкой:
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/demo.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Прочитайте match, счёт, peer_ip и local_ip в подтверждении. Они указывают принятые данные и фактические источник и назначение соединения. Повторный POST для того же матча заменяет его подтверждение, а не создаёт дубликаты матчей.
Подготовленный demo.wav — оригинальный двухсекундный тестовый тон в корректном формате PCM WAV. Создавать или кодировать медиа не нужно. -T загружает тело файла через HTTP PUT. Повторный PUT с тем же именем заменяет эту одну медиазадачу.
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
Подтверждение содержит число байтов и хеш SHA-256 содержимого. Хеш представляет байты; одинаковые хеши подтверждают идентичность содержимого, тогда как одного имени файла недостаточно. Чтобы сравнить действительно принятый файл, скачайте его снова. -o сохраняет ответ по указанному пути. cmp сравнивает каждый байт и при успехе ничего не выводит:
curl --noproxy '*' -fsS --max-time 35 -o received/demo.wav http://10.205.10.20:8080/media/demo.wav
cmp source/demo.wav received/demo.wav
Переключитесь на Event Receipts и выберите Refresh receipts. Откройте Existing demonstration receipts и найдите свой счёт demo и demo.wav. Страница читает реальные приёмники через Event Client; она никогда не дополняет отсутствующие записи из исходной папки. Основные карточки ждут новых задач следующей лабораторной работы.
В раскрытом разделе демонстрации ниже показаны принятый счёт demo, идентификатор demo.wav, хеш содержимого и реальные источники соединений. На этом этапе ожидание на основных карточках нормально.
Если curl завершился с 7, соединение не удалось: вернитесь в Event Client и проверьте адрес, порт и команду ip route get, изучаемую далее. Код 28 означает истечение лимита времени, а не отказ HTTP. Код 22 означает ошибку HTTP. С -f curl сообщает статус HTTP, но опускает тело ответа с ошибкой; сравните точный путь конечной точки и предоставленный JSON или файл тела. Прочитайте указанный источник через cat и исправьте команду, сохраняя предоставленные файлы. Успешное соединение с неверной задачей всё равно даёт неверный бизнес-результат.
Измерьте задержку каждого пути
На этом шаге вы сравните ограниченную выборку задержки к одному адресату через каждый канал. Начните в Event Client. Все команды выполняются на этом же клиенте; меняется только маршрут к медиаадресату. Сохраните маршруты счёта и эталона, маршрут по умолчанию, интерфейсы, исходные файлы и формирование трафика.
ip route show перечисляет текущие маршруты. /32 выбирает ровно один адрес назначения IPv4. ip route get спрашивает, какие маршрут и источник использовало бы ядро; пакет не отправляется. Перед изменением прочитайте текущий медиамаршрут:
ip route show
ip route get 10.205.10.20
Ожидается via 10.205.1.1 dev lane1 src 10.205.1.2. Запомните этот исходный маршрут: вы восстановите его после каждого опыта. Курс использует подготовленный маршрут по умолчанию внутри изолированной сети; доступа в Интернет он не предоставляет.
ip route replace добавляет или заменяет только маршрут к указанному назначению. via выбирает следующий узел, а dev — выходной интерфейс. Замена одного /32 не заменяет маршрут по умолчанию. Сначала явно задайте тест через lane1:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping отправляет эхо-запросы ICMP. -n показывает числовые адреса, -c 4 останавливается после четырёх запросов, а -W 2 ждёт ответа не более двух секунд. Время кругового прохождения (RTT) включает путь туда и ответ; это не односторонняя задержка и не время ответа приложения со счётом.
ping -n -c 4 -W 2 10.205.10.20
Прочитайте все четыре ответа и итоговую строку min/avg/max/mdev в миллисекундах (ms). Сравнивайте среднее и разброс, а не только минимальный результат. В подготовленной сцене RTT этого канала обычно около 11 ms. Первое обнаружение соседей или планирование VM может замедлить один замер.
Теперь переключите только это же назначение на lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
Перед измерением ожидается via 10.205.2.1 dev lane2 src 10.205.2.2:
ping -n -c 4 -W 2 10.205.10.20
RTT этого пути обычно около 180 ms. Разница должна быть большой; это не обещание о реальном поставщике или Интернете. Отсутствие ответов не означает автоматически поломку HTTP-сервиса: ICMP и HTTP — разные протоколы. Сначала проверьте это назначение, следующий узел и интерфейс. Если значения близки, повторите ту же ограниченную выборку по одному пути за раз; не запускайте параллельные тесты.
Восстановите исходный маршрут к одному назначению и подтвердите его:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Вы наблюдали два времени прохождения, не меняя свойства каналов. Далее проверьте, переносит ли путь с более быстрым ответом объёмные данные тоже быстрее.
Измерьте скорость в нужном направлении
На этом шаге вы сравните скорость передачи TCP от клиента по тем же двум путям. Начните в Event Client с восстановленным медиамаршрутом через lane1. Подготовленный приёмник запускает сервер iperf3 на порту 5201. Клиент начинает тест; сервер принимает тестовые данные и сообщает, что прибыло. Эти тестовые байты не являются вашей доставкой медиа.
iperf3 -c выбирает адрес сервера, а -t 5 ограничивает передачу тестовых данных пятью секундами. Стандартный TCP-тест отправляет от клиента к серверу, то есть в направлении загрузки медиа мероприятия. Мы не используем -R, меняющий направление на обратное. Краткие обмены при установке и передаче результатов могут увеличить полную длительность команды чуть сверх пяти секунд.
Перед первым тестом подтвердите маршрут:
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Прочитайте итоговую строку receiver. Столбец Bitrate может использовать Mbits/sec (Mbps): миллионы бит в секунду. В байте восемь бит, поэтому разделите Mbps на восемь для приблизительного MB/s. Например, 2 Mbps — максимум около 0,25 MB/s ещё до накладных расходов протокола. MBytes в столбце передачи — объём данных, а не скорость. Скорость приёмника по lane1 обычно близка к 1,9 Mbps.
Дождитесь завершения команды, прежде чем менять маршрут. Измерьте то же назначение через lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lane2 обычно даёт десятки Mbps несмотря на больший RTT. На скорость влияют запуск TCP, подтверждения, накладные расходы протокола, планирование и короткое окно наблюдения. Номинальная скорость виртуального интерфейса не является измеренной скоростью полезной передачи. Если сервер сообщает о текущем тесте, дождитесь завершения этого ограниченного теста и повторите один раз; не запускайте другой сервер и дополнительные одновременные тесты.
Восстановите исходный медиамаршрут и подтвердите его:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Канал с малым RTT подходит небольшим взаимодействиям, а канал с высокой скоростью полезной передачи — этой объёмной загрузке. Вывод ограничен подготовленными путями и измеренным направлением. Вы не измеряли Wi-Fi, пропускную способность публичного Интернета или надёжность в эксплуатации. Следующая независимая лабораторная работа предлагает применить наблюдения к передаче новых бизнес-данных.
Резюме
Вы отправили настоящий счёт и воспроизводимое аудио, сравнили один адресат по двум путям, интерпретировали RTT и скорость приёмника TCP и восстановили маршрут с ограниченной областью действия. Измерения описывают путь и направление; следующая задача превращает эти наблюдения в отдельные маршруты для бизнес-задач.
