Linux 네트워크 성능 퀴즈
마지막 업데이트: 2026년 9월 15일
Linux 네트워크 성능을 먼저 읽으세요. 가장 적절한 답 하나를 선택하고 해석과 측정 한계를 함께 설명합니다.
- Bootlin 공개 자료와 이 워크북의 관계를 올바르게 설명한 것은?
- A) 슬라이드를 내려받을 수 있으면 무료 지원 하드웨어 실습도 보장된다.
- B) 입문 VM은 모든 보드·드라이버 관측을 반드시 재현한다.
- C) 공개 슬라이드·지침은 학습에 쓰며 하드웨어 실습에는 명시된 보드·도구 체인과 C·커널 배경이 필요하다.
- D) 교육 인증서로 누락된 캡처를 대신할 수 있다.
정답 보기
정답: C
설명: 공개 읽기 접근은 강의 지원, 하드웨어, 등록과 다릅니다. 드라이버 실습에는 저수준 지식과 적합한 환경이 필요합니다. 기본 Python 루프백 실험의 선행 조건은 더 작고 물리 NIC 동작을 증명하지 못합니다. 없는 하드웨어 증거는 인증서로 대체하지 말고 명시합니다.
- 클라이언트가 헤더 해석 뒤 의도적으로 0.15초 기다리자 총 트랜잭션 시간이 늘었습니다. 정당한 결론은?
- A) 네트워크 RTT가 정확히 150 ms 증가했다.
- B) 클라이언트 소비 지연이 완료 시간에 기여하며 경로 지연에는 별도 증거가 필요하다.
- C) qdisc가 반드시 패킷을 버렸다.
- D) 수신 버퍼를 키우면 의도한 대기가 사라진다.
정답 보기
정답: B
설명: 설정한 대기는 read_ms와 total_ms의 일부이지 주입한 네트워크 지연이 아닙니다. 스케줄링과 버퍼링은 실제 측정값에 영향을 줍니다. headers_ms도 연결·요청 처리를 포함하며 순수 RTT가 아닙니다. 특정 실측 시간을 주장하지 않고 애플리케이션이라는 경쟁 설명을 시험합니다.
ss에 대한 적절한 해석은?- A) LISTEN
Recv-Q는 항상 읽지 않은 애플리케이션 바이트 수다. - B) ESTABLISHED
Send-Q는 설정한 송신 버퍼 최댓값이다. - C) ESTABLISHED
Recv-Q는 미소비 수신 데이터이며 소켓 메모리·LISTEN backlog는 별개다. - D)
skmem, 광고 수신 윈도,cwnd는 반드시 같은 수치여야 한다.
- A) LISTEN
정답 보기
정답: C
설명: 소켓 상태에 따라 열의 의미가 달라집니다. ESTABLISHED Send-Q는 아직 보내지 않은 바이트를 포함한 미확인 바이트이고 LISTEN 열은 연결 수락을 다룹니다. 메모리 집계에는 부가 비용이 포함되어 스트림 점유량과 다릅니다. cwnd와 비교하려면 세그먼트 단위와 MSS도 확인해야 합니다.
- 가상의 경로가 100 Mbit/s, RTT 40 ms입니다. BDP와 의미는?
- A) 4,000,000바이트이며 모든 소켓 버퍼를 그 값으로 설정해야 함을 증명한다.
- B) 500,000바이트이며 느린 실행의 원인을 확정하지 않는 추론 입력이다.
- C) 500바이트이며 측정된 루프백 용량이다.
- D) 2,500,000바이트이며 필수 qdisc 큐 길이다.
정답 보기
정답: B
설명: RTT를 0.040초로, 비트를 바이트로 바꾸면 100,000,000 × 0.040 ÷ 8 = 500,000입니다. 이는 가상 산술입니다. 처리량에는 유효 윈도, 애플리케이션 공급, 혼잡과 다른 제약이 작용하므로 계산만으로 병목을 진단하거나 전역 튜닝을 승인할 수 없습니다.
- 호스트 캡처에 큰 TCP 단위와 송신 체크섬 오류 표시가 있습니다. 먼저 할 일은?
- A) NIC 오프로딩을 모두 끄고 무제한 부하로 반복한다.
- B) 물리 네트워크가 손상된 초대형 프레임을 전송했다고 선언한다.
- C) 캡처 위치·방향, 오프로딩 맥락, 잘림·캡처 카운터를 기록한다.
- D) 쓸모 있는 증거가 없으므로 캡처를 삭제한다.
정답 보기
정답: C
설명: GSO·TSO·GRO와 체크섬 오프로딩은 물리 전송과 호스트 관측의 차이를 만들 수 있습니다. 그렇다고 네트워크 정상까지 증명되지는 않습니다. 관측 지점을 확정하고 필요하면 대응하는 종단·선로 증거를 찾습니다. 이 워크북은 출력 모양을 맞추기 위해 NIC 오프로딩을 바꾸지 않습니다.
- 정확한 조합은?
- A) NAPI는 모든 애플리케이션 지연 목표를 보장한다.
- B) RSS는 하나의 TCP 흐름을 항상 모든 CPU로 분산한다.
- C) RSS는 하드웨어 수신 큐 분산, RPS는 소프트웨어 CPU 선택이며 NAPI는 드라이버 이벤트 폴링을 다룬다.
- D) 루프백으로 물리 NIC의 RSS 간접 테이블을 직접 벤치마크할 수 있다.
정답 보기
정답: C
설명: 관련 있지만 서로 다른 위치에서 동작하는 메커니즘입니다. 흐름이 RSS 큐 하나에 해시될 수 있고 소프트웨어 처리의 CPU 분포는 다를 수 있습니다. NAPI 예산·실행 문맥은 애플리케이션 완료 시간을 보장하지 않습니다. 루프백은 물리 NIC의 수신 큐를 통과하지 않습니다.
- tcpdump가 캡처 드롭을 보고하고
ss에는 재전송이 나타납니다. 가능한 결론은?- A) 모든 재전송은 tcpdump가 패킷을 놓쳐서 발생했다.
- B) qdisc가 손실 위치로 증명되었다.
- C) 관측자 손실과 TCP 재전송은 별개 신호이며 시간·흐름 대응과 추가 증거가 필요하다.
- D) 원격 종단의 수신 버퍼가 반드시 소진되었다.
정답 보기
정답: C
설명: 캡처 드롭은 관측자의 전달·처리 한계이며 경로의 패킷 전달 결과를 직접 뜻하지 않습니다. TCP는 손실, 순서 변경, 불필요한 타임아웃 동작으로 재전송할 수 있습니다. 어느 카운터도 단독으로 실패 구성 요소를 식별하지 못합니다. 같은 시간·튜플을 비교하고 가설에 필요하면 양쪽 종단을 조사합니다.
bpftool net show에 연결된 프로그램이 있습니다. 자신의 흐름을 가속했다고 주장하려면 무엇이 더 필요한가요?- A) 연결 자체가 가속을 뜻하므로 추가 증거는 없다.
- B) 흐름·훅 대응, 정의된 비교, 실제 성능 측정과 관측 부하 집계
- C) BPF 프로그램 이름만 필요하다.
- D) 다른 호스트에서 실패한 권한 확인만 필요하다.
정답 보기
정답: B
설명: 목록은 실행·성능 증거가 아닙니다. native XDP, generic XDP, TC의 위치도 다릅니다. 유효한 비교에는 부하와 측정 규약이 필요하며 추적 손실·부하도 중요합니다. 권한 부재는 BPF 없음이 아닌 미관측입니다. 기본 워크북은 프로그램을 적재하지 않습니다.
- 단계의 요청 5개는 성공했지만 주기적
ss표본 대부분이 비어 있습니다. 타당한 보고서는?- A) 입증된 운영 p99와 소켓이 없었다는 주장
- B) 실제 표본 수·최솟값·중앙값·최댓값 및 짧은 연결의 관측 공백 명시
- C) 누락된 모든 소켓 표본의 지연을 0으로 처리
- D) 가장 큰 echo 본문만으로 계산한 NIC 최대 처리량
정답 보기
정답: B
설명: 짧은 연결은 관측 간격 사이에서 끝날 수 있습니다. 트랜잭션 5개는 작은 기술 통계를 뒷받침할 뿐 신뢰할 만한 꼬리 지연 서비스 목표가 아닙니다. 자료 누락은 0이 아닙니다. 페이로드를 트랜잭션 시간으로 나누면 애플리케이션·연결 작업을 포함한 작업 단위 goodput이며 NIC 선속도가 아닙니다.
- 워크북 요구사항에 맞는 복구 계획은?
- A) 호스트 루트 qdisc를 교체했다가 삭제하면 이전 계층이 돌아온다고 가정한다.
- B) 모든 경로를 비우고 모든 Python 프로세스를 종료한다.
- C) 소유한 루프백 프로세스만 종료하고 수신 대기 제거를 확인하며 netem은 별도 소유권·사전 상태·정확한 복구를 정의할 때까지 설계로 둔다.
- D) 관측이 없으면 공유 보호 장치를 끈다.
정답 보기
정답: C
설명: 기본 실험은 전역 네트워크 설정을 바꾸지 않습니다. 복구 범위는 자신의 프로세스·파일이며 TIME_WAIT는 정상적으로 남을 수 있습니다. qdisc 삭제는 임의의 이전 설정을 재구성하지 못합니다. 이후 netem 실험에는 별도 네임스페이스·VM 경계와 정확한 복구 또는 기록한 자원만 폐기하는 절차가 필요합니다.