소개
Willow Games가 새 경기를 준비하고 있습니다. 점수 데스크에는 빠른 상호작용이, 미디어 데스크에는 완전한 리허설 오디오 전송이 필요합니다. 두 링크 모두 작동하지만 초기 경로는 두 작업을 한 링크로 보냅니다.
새로 준비한 환경에서 짧은 측정을 반복하고 목적지별 경로를 선택한 뒤 새 점수와 전체 오디오를 보냅니다. 먼저 행사 작업별 네트워크 요구 측정하기를 완료하거나 동등한 ping, iperf3, 대상을 한정한 IPv4 경로 기술을 갖추세요. 프로그래밍이나 미디어 인코딩은 필요 없습니다.
명령에는 Event Client, 실제 수신 콘텐츠의 확인과 재생에는 Event Receipts를 사용합니다. 편집할 수 있는 것은 지정된 두 목적지 경로와 새 제출뿐입니다. 45분은 저자의 예상입니다. 격리 노드는 커널을 공유하는 유선 가상 경로이며 공용 공급업체 측정이 아닙니다.
명시된 워크로드에 따라 선택하기
이 단계에서는 준비된 링크를 측정하여 각 작업에 하나를 선택합니다. 이미 /home/labex/project/event-links에 있는 Event Client에서 시작하세요. 이 실습은 독립적인 새 네트워크와 파일을 갖습니다. 행사 작업별 네트워크 요구 측정하기의 지연 및 처리량 도구와 기본 목적지 경로 읽기를 전제로 하며 파일이나 실행 중인 프로세스는 이어지지 않습니다.
먼저 보존해야 할 정상 기능을 봅니다. 점수 데스크에는 이미 워밍업 기록이 있습니다. 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는 각 응답 대기를 2초로 제한합니다. 밀리초 단위의 RTT 평균과 흩어짐을 읽으세요.
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c는 준비된 수신 측의 포트 5201에 연결하고, -t 5는 5초 TCP 데이터 테스트를 실행합니다. 기본 방향은 클라이언트에서 수신 측으로의 업로드로 미디어 작업과 같습니다. 마지막 receiver 비트레이트를 읽으세요. Mbps는 초당 수백만 비트이며 8로 나누면 부가 비용을 빼기 전의 대략적인 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가 나와야 합니다. 이 연습은 서로 다른 두 목적지 주소로 트래픽을 구분합니다. 같은 대상 주소를 공유하는 애플리케이션을 구분하거나 정책 라우팅을 구성하거나 링크를 결합하거나 공용 ISP를 고르는 작업은 아닙니다.
새 점수와 미디어 전달하기
이 단계에서는 선택한 경로로 새 작업을 전달하고 수신한 전체 미디어를 비교합니다. 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가 나와야 합니다. 데모 파일에 대한 성공 응답으로는 이 작업이 완료되지 않습니다.
같은 경기 ID의 POST는 해당 경기를 대체하고 같은 미디어 이름의 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 확인을 수행합니다. 점수를 제출하거나 파일을 업로드하거나 경로를 수리하지 않습니다.
요약
워크로드에 따라 경로를 고르고 두 목적지 경로만 변경하여 새 점수와 완전한 재생 가능 미디어를 전달했습니다. 수신 측 연결 출발지는 전달물이 어디로 도착했는지 증명하며 나중에 경로를 바꿔도 다시 쓸 수 없습니다. 기존 참조와 두 준비된 링크도 보존했습니다.
