소개
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는 자체 제작한 2초 사운드 체크 음으로 유효한 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는 응답을 최대 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 업로드 처리량을 비교합니다. 미디어 경로가 lane1로 복원된 Event Client에서 시작하세요. 준비된 수신 측은 iperf3 서버를 포트 5201에서 실행합니다. 클라이언트가 테스트를 시작하고 서버는 테스트 데이터를 받아 도착한 내용을 보고합니다. 이 테스트 바이트는 미디어 전달물이 아닙니다.
iperf3 -c는 서버 주소를 선택하고 -t 5는 데이터 테스트를 5초로 제한합니다. 기본 TCP 테스트는 클라이언트에서 서버로 전송하므로 행사 미디어 업로드와 방향이 같습니다. 방향을 뒤집는 -R은 사용하지 않습니다. 짧은 준비 및 결과 교환 때문에 명령 전체는 5초보다 조금 더 걸릴 수 있습니다.
첫 테스트 전에 경로를 확인하세요.
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
마지막 receiver 행을 읽습니다. Bitrate 열은 초당 수백만 비트인 Mbits/sec(Mbps)를 사용할 수 있습니다. 1바이트는 8비트이므로 Mbps를 8로 나누면 대략적인 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는 RTT가 길지만 보통 수십 Mbps를 전달합니다. 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 수신 측 처리량을 해석하고, 제한된 대상 경로를 복원했습니다. 측정은 특정 경로와 방향을 설명합니다. 다음 작업은 이 관찰을 서로 다른 업무 경로로 연결합니다.
