Cloud Native Operations

한국어

English

한국어

English

Appearance

Linux 네트워크 진단 퀴즈 ​

마지막 업데이트: 2026년 9월 14일

12문제로 로컬 HTTP·소켓·라우팅·MTU 실습 결과를 해석합니다. 문제의 수치는 설명용이며 기록된 측정값이 아닙니다.

객관식 문제 ​

  1. 셸에서 원격 Docker 컨텍스트를 선택한 상태로 라우팅 도우미를 실행하려 합니다. 도우미의 실행 조건에 맞는 준비는 무엇인가요?
    • A) 도우미가 선택된 원격 데몬을 자동으로 사용하게 한다
    • B) /var/run/docker.sock의 로컬 Linux Engine에 고정 이미지를 준비하고 서브넷 충돌 사전 검사를 통과한다
    • C) privileged 컨테이너를 활성화하고 라우터 포트를 공개한다
    • D) 서브넷 범위가 무작위이므로 여러 사본을 동시에 시작한다
정답 보기

정답: B) /var/run/docker.sock의 로컬 Linux Engine에 고정 이미지를 준비하고 서브넷 충돌 사전 검사를 통과한다

설명: 도우미는 로컬 Unix 소켓을 고정하고 원격 호스트·컨텍스트 환경 설정을 무시합니다. 고정 문서용 서브넷을 사용하므로 실행이 겹치면 안 됩니다. 이미지도 미리 있어야 합니다. 전용 브리지에서 masquerading을 끄고 소유한 컨테이너 세 개에서만 IPv4 기본 경로를 제거합니다. Docker는 여전히 호스트 브리지를 만들고 네트워크 규칙을 관리합니다.

  1. GET /lesson이 b"hello\n" 본문을 반환합니다. 올바른 Content-Length는 무엇인가요?
    • A) 보이는 글자만 세므로 5
    • B) 본문의 모든 개행은 CRLF여야 하므로 7
    • C) ASCII 글자 다섯 개와 마지막 LF가 6바이트이므로 6
    • D) 응답 헤더와 본문을 더한 길이
정답 보기

정답: C) ASCII 글자 다섯 개와 마지막 LF가 6바이트이므로 6

설명: 본문은 16진수로 68 65 6c 6c 6f 0a입니다. HTTP/1.1 헤더 줄의 CRLF 규칙이 본문의 LF를 CRLF로 변환하지는 않습니다. Content-Length는 시작 줄·헤더·구분자를 제외한 콘텐츠 바이트를 셉니다. echo 도우미도 --data-binary로 전달한 바이트를 보존합니다.

  1. curl --http1.1 -I가 /lesson에서 Content-Length: 6을 받았지만 본문은 표시하지 않습니다. 무엇이 일어난 건가요?
    • A) curl이 HEAD를 보냈으며 본문 없는 응답의 길이 필드는 대응하는 GET 표현을 설명한다
    • B) curl이 GET을 보내고 본문 6바이트를 받은 뒤 버렸다
    • C) 서버가 필요한 6바이트를 보내지 않아 프레이밍을 위반했다
    • D) HEAD의 Content-Length는 항상 0이어야 한다
정답 보기

정답: A) curl이 HEAD를 보냈으며 본문 없는 응답의 길이 필드는 대응하는 GET 표현을 설명한다

설명:-I는 HEAD를 선택합니다. HEAD 응답에는 허용된 표현 길이가 있어도 메시지 본문이 없습니다. 일반 출력에 헤더를 포함하는 -i와 다릅니다. HEAD 메타데이터를 본문 프레이밍으로 해석하면 지속 연결에서 다음 응답을 잘못 읽을 수 있습니다.

  1. curl 추적에 HTTPS 요청의 HTTP 헤더가 읽기 쉬운 텍스트로 표시됩니다. 무엇을 증명하나요?
    • A) 헤더가 암호화되지 않은 채 네트워크를 통과했다
    • B) 추적의 각 줄이 TCP 패킷 하나에 해당한다
    • C) HTTP/2·HTTP/3도 전송 시 HTTP/1.1 텍스트 줄을 사용한다
    • D) 클라이언트가 자신이 처리하는 HTTP 데이터를 표시할 수 있으며 수동 패킷 캡처는 아니다
정답 보기

정답: D) 클라이언트가 자신이 처리하는 HTTP 데이터를 표시할 수 있으며 수동 패킷 캡처는 아니다

설명: curl 디버그 출력은 클라이언트에서 생성되므로 네트워크에서는 TLS로 보호되는 데이터를 표시할 수 있습니다. 주석은 전송 인코딩이나 세그먼트 경계가 아닙니다. HTTP/2·HTTP/3도 바이너리 프레이밍을 사용합니다. 캡처에서 보이는 범위는 관측 지점과 사용 가능한 세션 비밀값에 따라 달라집니다.

  1. 설명용 ss 스냅샷에서 LISTEN은 Recv-Q=3, Send-Q=128이고 ESTABLISHED는 Recv-Q=6입니다. 올바른 해석은 무엇인가요?
    • A) 리스너가 송신 버퍼 128바이트에 페이로드 3바이트를 보관한다
    • B) 리스너에 미완료 SYN이 세 개 있고 수립된 소켓에는 연결 여섯 개가 대기한다
    • C) 리스너에서 연결 세 개가 accept를 기다리고 최대 backlog는 128이며 수립된 소켓에는 순서대로 수신한 미소비 바이트 여섯 개가 있다
    • D) 세 숫자 모두 혼잡 윈도 크기이다
정답 보기

정답: C) 리스너에서 연결 세 개가 accept를 기다리고 최대 backlog는 128이며 수립된 소켓에는 순서대로 수신한 미소비 바이트 여섯 개가 있다

설명: 큐 열의 단위는 소켓 상태에 따라 다릅니다. LISTEN 열은 미완료 SYN 큐가 아닌 accept 큐를 나타냅니다. ESTABLISHED 열은 스트림 바이트이며 Send-Q에는 아직 확인 응답되지 않은 바이트가 포함됩니다. 테스트 포트로 제한하고 클라이언트·서버 끝점을 구분하세요.

  1. 지속 연결 클라이언트가 성공하고 두 스트림 큐는 자주 0이지만 skmem에는 0이 아닌 메모리 값이 보입니다. 어떤 결론이 적절한가요?
    • A) 큐가 비면 소켓 메모리도 0이어야 하므로 연결이 고장 났다
    • B) 메모리 집계·한도와 스트림 점유량은 다르며 작은 워크로드는 관측 사이에 소비될 수 있다
    • C) 스트림 큐가 항상 0보다 클 때까지 모든 TCP 버퍼 sysctl을 늘린다
    • D) rb는 상대에게 광고한 정확한 수신 윈도이다
정답 보기

정답: B) 메모리 집계·한도와 스트림 점유량은 다르며 작은 워크로드는 관측 사이에 소비될 수 있다

설명: 클라이언트는 각 6바이트 응답을 모두 소비한 뒤 다음 요청을 보냅니다. 버퍼를 강제로 채우는 실습이 아닌 관측 실습입니다. skmem에는 커널 집계와 한도가 포함되며 수신·혼잡 윈도는 별개입니다. 읽기 전용 정책 값과 반복 관측만으로 보편적인 튜닝 설정을 정할 수 없습니다.

  1. 클라이언트는 192.0.2.2/29이며 198.51.100.3으로 가는 경로의 게이트웨이는 192.0.2.3입니다. 어떤 ARP 결과를 기대하나요?
    • A) 192.0.2.3의 MAC이 있으며 클라이언트에 198.51.100.3의 이웃 항목은 필요하지 않다
    • B) 클라이언트의 왼쪽 네트워크에서 원격 서버의 MAC을 직접 매핑한다
    • C) ARP가 IP 목적지를 192.0.2.3으로 변경한다
    • D) DNS가 Ethernet 목적지를 제공하므로 ARP가 필요 없다
정답 보기

정답: A) 192.0.2.3의 MAC이 있으며 클라이언트에 198.51.100.3의 이웃 항목은 필요하지 않다

설명: 경로 조회가 이웃 주소 확인 전에 on-link 다음 홉을 선택합니다. Ethernet 프레임은 라우터 MAC으로 보내지만 IP 목적지는 서버 그대로입니다. 오른쪽 네트워크에서는 라우터가 별도로 조회하고 이웃 주소를 확인합니다. 서버에도 명시적인 반환 경로가 필요합니다.

  1. TTL-1 ping이 실패로 종료되었고 라우터 캡처에는 해당 probe 일부를 포함한 ICMP Type 11 Code 0이 있습니다. 실습에서는 어떻게 해석해야 하나요?
    • A) 목적지가 HTTP 요청을 완료했다
    • B) 라우터가 TCP MSS 불일치를 보고했다
    • C) 이후 모든 애플리케이션 패킷도 같은 라우터에서 반드시 실패한다
    • D) 의도적으로 작게 설정한 TTL이 라우터에서 만료되어 기대한 진단 응답을 만들었다
정답 보기

정답: D) 의도적으로 작게 설정한 TTL이 라우터에서 만료되어 기대한 진단 응답을 만들었다

설명: 송신 Echo Request와 반환 Time Exceeded는 서로 다른 메시지입니다. 캡처한 오류를 probe와 연결하면 의도한 이벤트를 확인할 수 있습니다. 타임아웃만으로는 확인할 수 없습니다. 필터링·응답 속도 제한·반환 경로 손실도 응답을 막을 수 있기 때문입니다. 도우미는 이를 실제 라우터 네임스페이스 캡처로 검사합니다.

  1. 라우터 송신 MTU가 1280입니다. IPv4 DF ping의 데이터 크기는 하나가 1372바이트, 다른 하나가 1200바이트입니다. 기본 IPv4·ICMP 헤더를 사용할 때 기대 결과는 무엇인가요?
    • A) MTU에는 ICMP 데이터만 포함되므로 둘 다 통과한다
    • B) IP 계층에서 첫 패킷은 1372바이트이고 두 번째는 1200바이트이다
    • C) 1400바이트 IP 패킷은 Fragmentation Needed를 유발하고 1228바이트 패킷은 통과한다
    • D) 큰 probe가 TCP MSS를 1200으로 낮춰 협상한다
정답 보기

정답: C) 1400바이트 IP 패킷은 Fragmentation Needed를 유발하고 1228바이트 패킷은 통과한다

설명: IPv4 헤더 20바이트와 ICMP 헤더 8바이트를 더합니다. DF는 라우터의 단편화를 막으므로 첫 실패에는 ICMP Type 3 Code 4가 따라야 하고 작은 probe는 성공합니다. PMTU 피드백이 캐시된 뒤에는 다음 큰 전송이 라우터 캡처를 다시 만들지 않고 로컬에서 실패할 수 있습니다.

  1. 루프백 HTTP 연결의 ss -i에 1460보다 큰 MSS가 표시됩니다. 어떤 결론을 내릴 수 있나요?
  • A) 도우미가 물리 인터페이스의 점보 Ethernet 프레임을 활성화했을 것이다
  • B) 1460 계산은 Ethernet MTU 1500과 기본 IPv4·TCP 헤더를 가정하며 루프백 조건은 다르다
  • C) ICMP probe 데이터 크기가 실제 TCP MSS이다
  • D) 1500보다 큰 모든 캡처 단위는 물리 링크 MTU 위반의 증거이다
정답 보기

정답: B) 1460 계산은 Ethernet MTU 1500과 기본 IPv4·TCP 헤더를 가정하며 루프백 조건은 다르다

설명: MSS는 ICMP 데이터나 전체 프레임이 아닌 TCP 데이터를 설명합니다. 인터페이스 MTU·옵션·경로 동작이 중요합니다. TSO·GSO·GRO 때문에 호스트 관측과 물리 링크 패킷이 다를 수도 있습니다. 루프백 실습으로 물리 Ethernet MTU를 확정할 수 없습니다.

  1. Docker DNS가 라우터 이름을 정확히 해석하지만 일반적인 클라이언트→서버 ping은 실패합니다. 무엇이 확인된 건가요?
  • A) 이름 조회는 동작하며 경로 선택·전달·반환 경로는 여전히 조사해야 한다
  • B) 서버 애플리케이션이 정상이다
  • C) 전용 브리지 두 개의 인터넷 NAT가 정상이다
  • D) 모든 컨테이너의 127.0.0.1에서 호스트 루프백 HTTP 서버에 접속할 수 있어야 한다
정답 보기

정답: A) 이름 조회는 동작하며 경로 선택·전달·반환 경로는 여전히 조사해야 한다

설명: DNS와 패킷 전달은 서로 다른 메커니즘을 검사합니다. 이 구성은 masquerading을 끈 전용 브리지 사이의 명시적인 라우팅을 사용하며 인터넷 NAT 벤치마크가 아닙니다. 각 네트워크 네임스페이스에는 자체 루프백이 있으므로 호스트의 루프백 서버가 컨테이너 로컬 서비스가 되지는 않습니다. 각 조회가 일어나는 네임스페이스에서 결과를 대조하세요.

  1. 라우팅 JSON의 일부 관측은 성공했지만 상태가 실패이거나 정리가 완료되지 않았습니다. 올바른 처리는 무엇인가요?
  • A) 경로 조회가 성공했으므로 전체 실행을 통과로 처리한다
  • B) 로컬에 이미지가 캐시되어 있으면 정리는 무시한다
  • C) 깨끗한 호스트를 보장하기 위해 Docker 전체 prune을 실행한다
  • D) 실행을 실패로 유지하고 실패 단계를 확인하며 필요한 정리는 생성한 ID만 식별해 진행한다
정답 보기

정답: D) 실행을 실패로 유지하고 실패 단계를 확인하며 필요한 정리는 생성한 ID만 식별해 진행한다

설명: 통과하려면 정상 완료·검사 여덟 개 모두 참·정리 결과 보고가 필요하며, 컨테이너 세 개의 IPv4 기본 경로 목록도 비어 있어야 합니다. 도우미는 관련 없는 이름의 리소스를 지우는 대신 자신이 만든 ID를 추적합니다. 강제 종료는 정리를 막을 수 있습니다. 증거를 보존하고 이후 실행에는 새 출력 경로를 사용하며 통과를 강제하려고 공유 네트워크 제어를 우회하지 마세요.

진단 가이드로 돌아가기 · HTTP · TCP 버퍼 · 라우팅·ICMP · MTU·MSS