Cloud Native Operations

한국어

English

한국어

English

Appearance

네트워크 기초 Part 3 퀴즈 — 애플리케이션 프로토콜 ​

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

DNS부터 MQTT까지 애플리케이션 계층 프로토콜 10개에 대한 이해도를 테스트합니다.

객관식 문제 ​

  1. HTTP/3를 활성화했는데 성능 개선이 없을 때 유용한 전송 계층 점검은 무엇인가요?
    • A) 서버 인증서의 만료일
    • B) UDP 443에 도달할 수 있고 실제로 HTTP/3을 협상했는지
    • C) DNS TTL 설정
    • D) HTTP/2 헤더 압축(HPACK) 설정
정답 보기

정답: B) UDP 443에 도달할 수 있고 실제로 HTTP/3을 협상했는지

설명: HTTP/3은 보통 UDP 443의 QUIC을 사용합니다. 경로가 차단되면 지원되는 경우 클라이언트가 TCP 기반 HTTP/2·HTTP/1.1을 사용할 수 있습니다. 성능 비교 전에 실제 협상된 프로토콜을 확인하세요. 손실·RTT·워크로드·구현·CPU와 오프로드도 결과에 영향을 주며, 이 문제만으로 실제 장애 원인을 확정할 수는 없습니다.

  1. 권한 레코드를 변경한 뒤에도 DNS 페일오버를 지연시킬 수 있는 요인은 무엇인가요?
    • A) DNS는 TCP만 사용하므로 핸드셰이크 비용이 크다
    • B) 이전에 캐시된 응답, 애플리케이션 캐시, 기존 연결이 레코드 변경 후에도 남을 수 있다
    • C) 루트 네임서버가 갱신을 승인해야 하기 때문이다
    • D) A 레코드는 변경이 불가능하기 때문이다
정답 보기

정답: B) 이전에 캐시된 응답, 애플리케이션 캐시, 기존 연결이 레코드 변경 후에도 남을 수 있다

설명: 새로 낮춘 TTL은 이전 TTL로 이미 캐시된 응답의 수명을 단축하지 않습니다. 장애 감지·레코드 갱신·애플리케이션 캐시·연결 재사용도 복구에 영향을 줍니다. 리졸버는 정의된 장애 조건에서 만료된 데이터를 제공할 수도 있습니다(RFC 8767). DNS·로드밸런서·애니캐스트 모두 장애 감지와 수렴 동작을 측정해야 합니다.

  1. 브라우저가 승인되지 않은 공개 DoH 리졸버를 선택하면 어떤 정책 문제가 생길 수 있나요?
    • A) DNS 응답 크기가 커져 대역폭을 낭비하기 때문에
    • B) 조직 리졸버 정책을 우회하거나 사설 이름 해석에 실패할 수 있기 때문에
    • C) UDP 53 포트가 과부하되기 때문에
    • D) DNSSEC과 호환되지 않기 때문에
정답 보기

정답: B) 조직 리졸버 정책을 우회하거나 사설 이름 해석에 실패할 수 있기 때문에

설명: DoH는 HTTPS로 클라이언트–리졸버 구간의 무결성을 포함한 보안을 제공합니다. 별도 공개 리졸버는 조직 리졸버의 통제를 우회할 수 있지만 관리형 DoH 자체도 정책·로깅을 제공할 수 있습니다. 단말 정책으로 승인된 리졸버를 선택하고 분할 DNS를 검증하세요. 암호화해도 리졸버 주소나 모든 트래픽 메타데이터가 숨겨지지는 않습니다.

  1. L4 로드밸런서가 gRPC 트래픽을 일부 백엔드에 집중시킬 수 있는 이유는 무엇인가요?
    • A) Protocol Buffers 직렬화가 비대칭적이기 때문에
    • B) 여러 RPC가 장기 연결을 공유할 수 있지만 L4는 연결별로 백엔드를 선택하기 때문에
    • C) HTTP/2 헤더 압축이 로드밸런서에서 깨지기 때문에
    • D) gRPC는 UDP 기반이라 L4 분산이 불가능하기 때문에
정답 보기

정답: B) 여러 RPC가 장기 연결을 공유할 수 있지만 L4는 연결별로 백엔드를 선택하기 때문에

설명: gRPC 채널은 0개 이상의 HTTP/2 연결을 사용할 수 있습니다. 적은 수의 장기 연결이 많은 RPC를 전달하면 L4는 각 RPC를 재분산하지 못합니다. 적절한 클라이언트 정책이나 gRPC를 이해하는 L7 프록시로 요청 분산을 개선할 수 있지만 이미 수립된 스트림은 해당 백엔드에 남습니다.

  1. WebSocket 서비스 운영에서 발생하는 문제와 대응의 연결이 잘못된 것은 무엇인가요?
    • A) 로드밸런서 유휴 타임아웃으로 끊김 → 핑/퐁 프레임으로 연결 유지
    • B) 배포 시 재연결 폭풍 → 지터를 넣은 지수 백오프
    • C) 인스턴스 간 애플리케이션 이벤트 전달 → Redis Pub/Sub 등 사용, 소켓은 해당 인스턴스가 계속 소유
    • D) 프록시가 Upgrade 헤더를 차단 → QoS 2로 상향
정답 보기

정답: D) 프록시가 Upgrade 헤더를 차단 → QoS 2로 상향

설명: QoS는 MQTT 개념이며 WebSocket 핸드셰이크 문제를 해결하지 못합니다. HTTP/1.1은 Upgrade를, HTTP/2·HTTP/3은 지원되는 경우 Extended CONNECT를 사용합니다. 하트비트는 유휴 타임아웃에 맞춰야 하며 백오프·점진적 종료는 재연결 급증을 줄입니다. Pub/Sub는 애플리케이션 이벤트를 전달하지만 소켓을 이전하거나 자체적으로 영속 전달을 제공하지 않습니다.

  1. 이메일 발신 도메인 보호를 위한 인증 체계 3종(SPF, DKIM, DMARC)의 역할이 올바르게 짝지어진 것은 무엇인가요?
    • A) SPF: 메시지 서명 / DKIM: 발신 IP 목록 게시 / DMARC: 암호화 강제
    • B) SPF: 봉투·HELO 식별자의 호스트 허용 / DKIM: 도메인 키로 대상 내용 서명 / DMARC: 표시 From 도메인과 통과한 SPF 또는 DKIM 정렬 및 정책 게시
    • C) SPF: 수신 서버 인증 / DKIM: 전송 구간 암호화 / DMARC: 스팸 필터링
    • D) SPF: 메일 큐 관리 / DKIM: MX 레코드 검증 / DMARC: TLS 강제
정답 보기

정답: B) SPF: 봉투·HELO 식별자의 호스트 허용 / DKIM: 도메인 키로 대상 내용 서명 / DMARC: 표시 From 도메인과 통과한 SPF 또는 DKIM 정렬 및 정책 게시

설명: SPF는 봉투·HELO 도메인을 확인하고 DKIM은 서명 도메인에 대해 대상 내용의 서명을 검증합니다. DMARC는 표시 From 도메인과 정렬된 인증 방식 하나 이상이 통과해야 하며 둘 다 통과할 필요는 없습니다. 이 체계들은 도메인 보호에 도움이 되지만 전달 성공이나 표시 이름·유사 도메인 사칭 방지까지 보장하지는 않습니다.

  1. HTTP/1.1 요청은 POST /echo HTTP/1.1, 응답은 HTTP/1.1 200 OK로 시작합니다. 올바른 해석은 무엇인가요?
    • A) POST는 헤더 필드이고 /echo는 응답 상태이다
    • B) 200은 본문 길이이고 OK가 요청 성공 여부를 결정한다
    • C) 요청 줄에는 메서드·대상·버전이, 상태 줄에는 버전·상태 코드·선택적 사유 문구가 들어간다
    • D) 첫 빈 줄은 본문을 포함한 전체 메시지를 종료한다
정답 보기

정답: C) 요청 줄에는 메서드·대상·버전이, 상태 줄에는 버전·상태 코드·선택적 사유 문구가 들어간다

설명: POST는 대상에 전달한 콘텐츠의 처리를 요청하고 200은 성공 상태입니다. 시작 줄 다음에는 헤더 필드 줄이 오며 빈 줄로 헤더 영역을 끝냅니다. 메시지 규칙이 허용할 때만 본문이 뒤따릅니다. 설명용 화면에서 LF를 표시하더라도 HTTP/1.1의 해당 전송 줄바꿈은 CRLF입니다.

  1. HTTP/1.1 메시지 본문에는 끝 개행 없이 ASCII 5바이트 hello만 들어 있고 콘텐츠 코딩과 전송 코딩도 없습니다. Content-Length: 5는 무엇을 세나요?
    • A) 시작 줄과 헤더를 포함한 전체 메시지
    • B) 본문 5바이트만 세며, Content-Type은 별도로 미디어 유형을 설명한다
    • C) 바이트 인코딩과 관계없이 유니코드 문자 다섯 개
    • D) 본문을 전달하는 TCP 패킷 수
정답 보기

정답: B) 본문 5바이트만 세며, Content-Type은 별도로 미디어 유형을 설명한다

설명: Content-Length는 시작 줄·헤더·구분용 빈 줄을 제외한 바이트 수입니다. ASCII hello는 5바이트이며 실제 LF를 하나 추가하면 6바이트입니다. 비ASCII UTF-8 문자는 여러 바이트를 차지할 수 있습니다. Content-Type은 표현의 해석 방법을 알려주며 메시지 종료 위치를 정하지 않습니다.

  1. GET에 대한 유효한 HTTP/1.1 200 응답이 Transfer-Encoding: chunked를 사용하고 TCP 연결을 유지합니다. 본문 경계는 어떻게 정하나요?
    • A) TCP 패킷 경계로 정한다
    • B) Content-Type만으로 정한다
    • C) Transfer-Encoding과 함께 반드시 전송하는 Content-Length로 정한다
    • D) 청크 프레이밍을 따르며 0 크기 청크, 트레일러(있는 경우), 최종 빈 줄로 끝낸다
정답 보기

정답: D) 청크 프레이밍을 따르며 0 크기 청크, 트레일러(있는 경우), 최종 빈 줄로 끝낸다

설명: 청크 프레이밍은 연결을 닫지 않고 종료 위치를 나타냅니다. 송신자는 Transfer-Encoding과 Content-Length를 함께 보내면 안 됩니다. TCP는 바이트 스트림이므로 한 메시지가 여러 패킷에 걸치거나, 한 패킷에 여러 메시지의 바이트가 들어갈 수 있습니다.

  1. HEAD에 대한 유효한 HTTP/1.1 응답에 Content-Length: 500이 있습니다. 클라이언트는 헤더 뒤에서 본문 500바이트를 읽어야 하나요?
  • A) 아니다. HEAD 응답에는 메시지 본문이 없고, 이 필드는 대응하는 GET 응답의 길이를 설명한다
  • B) 그렇다. Content-Length는 항상 메서드보다 우선한다
  • C) 그렇다. 다만 Content-Type이 text/plain일 때만 그렇다
  • D) 아니다. 모든 HEAD 응답에서 Content-Length가 금지되기 때문이다
정답 보기

정답: A) 아니다. HEAD 응답에는 메시지 본문이 없고, 이 필드는 대응하는 GET 응답의 길이를 설명한다

설명: 메서드·상태 규칙이 일반적인 길이 프레이밍보다 먼저 적용됩니다. HEAD 응답에는 본문이 없으며 허용된 길이 필드는 메타데이터입니다. 1xx·204·304 응답에도 본문은 없지만 허용되는 필드의 제약은 각각 따로 적용됩니다.

  1. 클라이언트 도구가 HTTP/2로 협상된 HTTPS 요청의 헤더를 읽기 쉬운 텍스트로 표시합니다. 세션 비밀값 없는 수동 캡처에서는 무엇을 예상해야 하나요?
  • A) 동일한 평문 GET ... HTTP/1.1 요청 줄
  • B) 헤더는 평문으로 보이고 본문만 암호화된다
  • C) 보호된 애플리케이션 데이터가 보이며, HTTP/2는 바이너리 프레임을 사용하고 도구는 디코딩된 필드를 표시한 것이다
  • D) 모든 HTTP/2 스트림을 구분하는 HTTP/1.1 청크 크기
정답 보기

정답: C) 보호된 애플리케이션 데이터가 보이며, HTTP/2는 바이너리 프레임을 사용하고 도구는 디코딩된 필드를 표시한 것이다

설명: HTTPS 연결에서 TLS는 HTTP/2 헤더와 콘텐츠를 보호합니다. HTTP/2는 TCP 위에서 HEADERS·DATA 프레임을 사용하고 HTTP/3은 보호된 QUIC 스트림 위에서 자체 프레임을 사용합니다. 둘 다 HTTP 의미를 유지하지만 HTTP/1.1의 텍스트 시작 줄이나 chunked 전송 코딩을 사용하지는 않습니다. 권한이 있는 끝점이나 종료 지점에서 디코딩된 메시지를 관측하세요.

학습 자료로 돌아가기 | 다음 퀴즈: Part 4

HTTP 메시지 구조·프레이밍·관측 범위와 해당 절의 공식 참고 자료를 복습하세요.