네트워크 기초 Part 3 퀴즈 — 애플리케이션 프로토콜
마지막 업데이트: 2026년 8월 28일
DNS부터 MQTT까지 애플리케이션 계층 프로토콜 10개에 대한 이해도를 테스트합니다.
객관식 문제
- "HTTP/3를 활성화했는데 왜 빨라지지 않는가"를 조사할 때 가장 먼저 확인해야 할 것은 무엇인가요?
- A) 서버 인증서의 만료일
- B) 방화벽에서 UDP 443이 차단되어 TCP로 폴백하고 있는지
- C) DNS TTL 설정
- D) HTTP/2 헤더 압축(HPACK) 설정
정답 보기
정답: B) 방화벽에서 UDP 443이 차단되어 TCP로 폴백하고 있는지
설명: HTTP/3는 QUIC(UDP 443) 위에서 동작합니다. UDP 정책이 엄격한 환경(국내 금융권 등)에서는 QUIC이 차단되어 TCP 기반 HTTP/2로 폴백하므로 HTTP/3의 이점을 받지 못합니다. 손실이 거의 없고 RTT가 짧은 구간에서는 개선 폭 자체가 작다는 점도 함께 고려해야 합니다.
- DNS 기반 페일오버가 기대보다 훨씬 느리게 전환되는 주된 이유는 무엇인가요?
- A) DNS는 TCP만 사용하므로 핸드셰이크 비용이 크다
- B) TTL을 짧게 설정해도 클라이언트나 중간 리졸버가 이를 존중하지 않는 경우가 있다
- C) 루트 네임서버가 갱신을 승인해야 하기 때문이다
- D) A 레코드는 변경이 불가능하기 때문이다
정답 보기
정답: B) TTL을 짧게 설정해도 클라이언트나 중간 리졸버가 이를 존중하지 않는 경우가 있다
설명: DNS 캐시는 TTL 기준으로 만료되지만, 일부 클라이언트·리졸버는 TTL을 무시하고 더 오래 캐시합니다. 빠른 전환이 필요하면 DNS보다 앞단의 애니캐스트나 로드밸런서 레벨에서 처리하는 것이 맞습니다.
- 기업 네트워크 관점에서 DoH(DNS over HTTPS)가 "골칫거리"가 되는 이유는 무엇인가요?
- A) DNS 응답 크기가 커져 대역폭을 낭비하기 때문에
- B) DNS 기반 필터링·로깅이 무력화되고, 브라우저가 조직 내부 DNS를 우회할 수 있기 때문에
- C) UDP 53 포트가 과부하되기 때문에
- D) DNSSEC과 호환되지 않기 때문에
정답 보기
정답: B) DNS 기반 필터링·로깅이 무력화되고, 브라우저가 조직 내부 DNS를 우회할 수 있기 때문에
설명: DoH는 DNS 질의를 HTTPS로 감싸 일반 웹 트래픽과 구분되지 않게 만듭니다. 프라이버시는 개선되지만 조직의 DNS 필터링·로깅이 무력화되고, 브라우저 자체 DoH 리졸버가 내부 도메인 해석을 깨뜨릴 수 있어 규제 환경에서는 브라우저 정책으로 통제하는 설정이 함께 갑니다.
- gRPC 서비스 앞에 L4 로드밸런서를 두었더니 특정 백엔드에만 트래픽이 몰립니다. 원인은 무엇인가요?
- A) Protocol Buffers 직렬화가 비대칭적이기 때문에
- B) gRPC가 하나의 TCP 연결을 오래 유지하며 그 위에서 요청을 다중화하므로, 연결 단위 분산으로는 요청이 고르게 퍼지지 않기 때문에
- C) HTTP/2 헤더 압축이 로드밸런서에서 깨지기 때문에
- D) gRPC는 UDP 기반이라 L4 분산이 불가능하기 때문에
정답 보기
정답: B) gRPC가 하나의 TCP 연결을 오래 유지하며 그 위에서 요청을 다중화하므로, 연결 단위 분산으로는 요청이 고르게 퍼지지 않기 때문에
설명: L4 로드밸런서는 연결 단위로만 분산합니다. gRPC는 장수 연결 하나에 많은 요청을 다중화하므로 요청 단위 분산이 되지 않습니다. L7 로드밸런싱, 클라이언트 사이드 로드밸런싱, 또는 서비스 메시(Istio 등)가 해결책입니다.
- WebSocket 서비스 운영에서 발생하는 문제와 대응의 연결이 잘못된 것은 무엇인가요?
- A) 로드밸런서 유휴 타임아웃으로 끊김 → 핑/퐁 프레임으로 연결 유지
- B) 배포 시 재연결 폭풍 → 지터를 넣은 지수 백오프
- C) 스케일 아웃 시 인스턴스 간 연결 상태 공유 → Redis Pub/Sub 등 활용
- D) 프록시가 Upgrade 헤더를 차단 → QoS 2로 상향
정답 보기
정답: D) 프록시가 Upgrade 헤더를 차단 → QoS 2로 상향
설명: QoS 레벨은 MQTT의 개념으로 WebSocket과 무관합니다. 프록시·방화벽이 HTTP Upgrade 핸드셰이크를 제대로 통과시키는지는 프록시 설정에서 확인·허용해야 할 문제입니다. 나머지 보기는 모두 상태를 갖는 장기 연결이라는 WebSocket의 특성에서 나오는 실제 운영 이슈와 올바른 대응입니다.
- 이메일 발신 도메인 보호를 위한 인증 체계 3종(SPF, DKIM, DMARC)의 역할이 올바르게 짝지어진 것은 무엇인가요?
- A) SPF: 메시지 서명 / DKIM: 발신 IP 목록 게시 / DMARC: 암호화 강제
- B) SPF: 발신 허용 IP 목록을 DNS에 게시 / DKIM: 도메인 키로 메시지 서명 / DMARC: 실패 시 처리 정책과 리포팅 선언
- C) SPF: 수신 서버 인증 / DKIM: 전송 구간 암호화 / DMARC: 스팸 필터링
- D) SPF: 메일 큐 관리 / DKIM: MX 레코드 검증 / DMARC: TLS 강제
정답 보기
정답: B) SPF: 발신 허용 IP 목록을 DNS에 게시 / DKIM: 도메인 키로 메시지 서명 / DMARC: 실패 시 처리 정책과 리포팅 선언
설명: SMTP 원래 설계에는 인증이 없어 발신자 위조가 자유롭습니다. SPF는 도메인의 발신 허용 IP를 DNS에 게시하고, DKIM은 도메인 키 서명으로 위조·변조를 탐지하며, DMARC는 SPF/DKIM 실패 시 처리 정책과 리포팅을 선언합니다. 셋을 모두 설정하지 않으면 전달률이 떨어지고 도메인 사칭을 막을 수 없습니다.