Введение
Willow Games готова к новому забегу. Столу счёта нужны быстрые взаимодействия, а медиастолу — полная передача звука репетиции. Оба канала работают, но исходный маршрут отправляет обе задачи по одному каналу.
Вы повторите короткие измерения в новой подготовленной среде, выберете отдельные маршруты назначения и отправите новый счёт и полное аудио. Сначала завершите Измерьте сетевые потребности задач мероприятия или владейте аналогичными навыками ping, iperf3 и ограниченных маршрутов IPv4. Программирование и кодирование медиа не нужны.
Используйте Event Client для команд и Event Receipts для просмотра и воспроизведения фактически принятых данных. Менять можно только два названных маршрута назначения и свои новые отправления. 45 минут — оценка автора; изолированные узлы используют одно ядро и представляют проводные виртуальные пути, а не измерения публичных поставщиков.
Выбирайте по заданной рабочей нагрузке
На этом шаге вы измерите подготовленные каналы и выберете один для каждой задачи. Начните в Event Client, уже в /home/labex/project/event-links. У этой работы своя новая сеть и файлы. Предполагается владение инструментами задержки и скорости из Измерьте сетевые потребности задач мероприятия, а также основами чтения маршрутов назначения; файлы и работающие процессы не переносятся.
Сначала посмотрите на нормальную функцию, которую нужно сохранить. У стола счёта уже есть запись разминки. curl --noproxy '*' обходит прокси, -fsS завершает команду ошибкой при ошибках HTTP и показывает сообщения, а --max-time 35 ограничивает передачу:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Ожидается сохранённый счёт warmup со значением 1–1. Переключитесь на Event Receipts. Две основные карточки ждут heat-7 и opening-sound.wav; страница не считает разминку выполненной новой задачей. Вернитесь в Event Client.
Столу счёта нужны короткие взаимодействия: выберите канал со стабильно малым RTT и средним выборки заметно ниже планового бюджета 80 ms. Медиакоманде нужна высокая скорость передачи больших объёмов: выберите путь со скоростью приёмника заметно выше 10 Mbps в этой подготовленной сцене. Эти широкие бюджеты помогают выбрать, но не гарантируют интернет-сервис. Не пытайтесь подстроить каналы под них.
Прочитайте предоставленные идентификаторы каналов и новый счёт. cat выводит каждый файл:
cat links.tsv
cat source/score.json
Два бизнес-назначения — 10.205.10.10 для счёта и 10.205.10.20 для медиа, оба на HTTP-порту 8080. Изначально оба маршрута /32 используют lane1. Измерьте один медиаадресат с этого же клиента по каждому каналу, по одному тесту за раз. ip route replace меняет только это назначение; via указывает следующий узел, а dev — интерфейс. ip route get подтверждает выбор ядра до отправки трафика.
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n использует числовые адреса, -c 4 останавливается после четырёх запросов, а -W 2 ограничивает каждое ожидание ответа двумя секундами. Прочитайте среднее и разброс RTT в миллисекундах:
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c соединяется с портом 5201 подготовленного приёмника; -t 5 выполняет пятисекундный тест данных TCP. По умолчанию направление — от клиента к приёмнику, как в медиазадаче. Прочитайте итоговую скорость receiver. Mbps означает миллионы бит в секунду; деление на восемь даёт приблизительное MB/s до накладных расходов.
iperf3 -c 10.205.10.20 -t 5
Дождитесь окончания. Теперь измените только медиамаршрут и повторите:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
После опыта восстановите начальный медиамаршрут:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Должен быть заметен большой контраст: lane1 — примерно 11 ms RTT и 1,9 Mbps, lane2 — примерно 180 ms и десятки Mbps. Первое обнаружение соседей и планирование могут повлиять на один замер. Если результаты близки или сервер занят, дождитесь окончания теста ограниченной длительности, подтвердите маршрут и повторите ту же выборку последовательно. Не совмещайте тесты и не меняйте формирование трафика. Напечатанный отчёт не заменяет реального трафика, а тестовые байты iperf не доставляют ни одну из новых бизнес-задач.
Измените только маршруты назначения
На этом шаге вы преобразуете решение по измеренной рабочей нагрузке в два конкретных маршрута. Начните в Event Client. Lane1 даёт малый RTT для небольшого взаимодействия со счётом. Lane2 даёт скорость передачи, нужную большому файлу проверки звука. Оба канала должны оставаться работоспособными.
Перед правкой прочитайте всю таблицу:
ip route show
Не меняйте маршрут по умолчанию курса и эталонное назначение 10.205.10.30. Заменять можно только маршруты 10.205.10.10/32 и 10.205.10.20/32. /32 означает ровно один адрес IPv4; более широкий сетевой маршрут затронул бы другие назначения. Сеть платформы вне задачи.
Явно задайте маршрут счёта уже изученной формой с replace, via и dev:
ip route replace 10.205.10.10/32 via 10.205.1.1 dev lane1
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
Проверьте фактический выбор ядра для каждого назначения:
ip route get 10.205.10.10
ip route get 10.205.10.20
Ожидается трафик счёта через 10.205.1.1 dev lane1 src 10.205.1.2, а медиа через 10.205.2.1 dev lane2 src 10.205.2.2. Если один выбор неверен, повторите только его полную команду replace с правильными следующим узлом и интерфейсом. Не очищайте таблицу и не меняйте маршрут по умолчанию.
Проверьте сохранность независимого эталонного маршрута реальным запросом:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Ожидается исходный ответ warmup, 1–1, preserved. Упражнение разделяет трафик по двум разным адресам назначения. Оно не различает приложения с одним адресом, не настраивает маршрутизацию по политикам, не объединяет каналы и не выбирает публичного интернет-провайдера.
Доставьте новый счёт и медиа
На этом шаге вы передадите новую работу по выбранным маршрутам и сравните полностью принятое медиа. Начните в Event Client. Новый счёт — матч heat-7, хозяева 3, гости 1. Новая медиазадача — opening-sound.wav, оригинальный синтетический 48-секундный тон проверки звука для репетиции. Корректные байты моно PCM WAV подготовлены; кодировать или менять их не нужно.
Перед отправкой прочитайте предоставленный счёт:
cat source/score.json
Имена и строковые значения JSON используют двойные кавычки; счёт — числа. -H задаёт тип содержимого JSON, а --data-binary @source/score.json читает точный файл и выполняет POST. Строка -w добавляет прошедшие секунды после подтверждения: \n создаёт новую строку, а %{time_total} — общее время curl. Оно включает установку соединения, а не только RTT.
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/score.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Ожидайте правильные матч и счёт, local_ip со значением 10.205.10.10 и peer_ip со значением 10.205.1.2. Peer — источник, который действительно наблюдал приёмник. Подтверждение свидетельствует об этой передаче, а не прогнозирует её по текущему маршруту.
-T отправляет указанный файл методом PUT в медиасервис. Это может занять несколько секунд; дождитесь результата:
curl --noproxy '*' -fsS --max-time 35 -T source/opening-sound.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/opening-sound.wav
Ожидаются новое имя файла, число байтов, хеш содержимого, local_ip со значением 10.205.10.20 и peer_ip со значением 10.205.2.2. Успешный ответ для демонстрационного файла не завершает эту задачу.
POST с тем же ID матча заменяет этот матч; PUT с тем же именем медиа заменяет эту медиазадачу. Если передали по неверному пути, исправьте маршрут и отправьте ту же задачу снова. Изменение маршрута после передачи не меняет её старое подтверждение. Никогда не редактируйте хранилище подтверждений или исходные файлы, чтобы имитировать результат.
Независимо прочитайте приёмники методом GET:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/receipts
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.20:8080/receipts
Скачайте принятое медиа, а не копируйте локальный источник. -o сохраняет ответ, cmp сравнивает каждый байт, а sha256sum выводит хеш каждого указанного файла:
curl --noproxy '*' -fsS --max-time 35 -o received/opening-sound.wav http://10.205.10.20:8080/media/opening-sound.wav
cmp source/opening-sound.wav received/opening-sound.wav
sha256sum source/opening-sound.wav received/opening-sound.wav
Ожидайте отсутствие вывода cmp и совпадение двух строк хеша. Пустой файл или файл с другим содержимым не совпадёт с подготовленным аудио. Переименование файла не меняет его байты или хеш. Если сравнение не удалось, прочитайте медиаподтверждение, повторите PUT неизменённого источника по верному назначению, скачайте снова и сравните.
Переключитесь на Event Receipts, выберите Refresh receipts и найдите heat-7 со счётом 3 : 1, новое имя медиа и разные источники соединений. Запустите Received event audio и используйте Download received audio для получения байтов приёмника. Браузер может быть без звука или аудиоустройства; длительность и продвижение воспроизведения всё равно подтверждают декодирование принятого WAV. Запустите воспроизведение явно; страница не делает этого автоматически.
В итоговом виде ниже сравните два значения Connection from рядом с новым счётом и принятым аудио. Аудиоплеер показывает фактически декодированную длительность и позволяет выбрать позицию воспроизведения.
Если curl не соединяется (код 7) или превышает время (код 28), вернитесь в Event Client и перепроверьте соответствующий результат ip route get и точный URL. Отказ HTTP (код 22) отличается: сравните точный путь конечной точки и предоставленный JSON или файл тела. Параметр -f опускает тело HTTP-ошибки; не настраивайте сеть для исправления ошибки бизнес-формата. Обновление страницы лишь читает приёмники и не выполняет недостающую работу.
Вернитесь в Event Client и ещё раз подтвердите сохранённый эталон:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Вы доставили две разные нагрузки по подходящим путям, сохранив оба канала, исходные байты, подготовленное формирование трафика, эталонные данные и посторонние маршруты. Оценка читает существующие бизнес-записи и нативные сетевые факты до ограниченных GET-проверок; она никогда не отправляет счёт, не загружает файлы и не чинит путь.
Резюме
Вы выбрали пути по нагрузке, изменили только два маршрута назначения и доставили новый счёт и полное воспроизводимое медиа. Источники соединений на приёмнике доказывают, откуда пришли передачи; последующее изменение маршрута не может их переписать. Вы также сохранили существующий эталон и оба подготовленных канала.
