AP 과목 A 18: DNS, HTTP, TLS와 메일 통신
응용정보기술자시험 과목 A에 필요한 DNS 재귀·권한 서버와 TTL, HTTP 요청·응답과 상태 코드, 쿠키·세션·캐시, HTTPS의 TLS 역할, HTTP/3와 QUIC, SMTP·POP3·IMAP 메일 흐름을 URL 추적 예제와 오리지널 연습 문제 5문항으로 익힙니다.
AP 과목 A 제18편 · 2026년도·실라버스 Ver.7.2 기준의 독립 학습 자료입니다. IPA와 제휴하지 않으며 합격을 보장하지 않습니다. 시리즈 허브 보기
2026년 시험 기준 · 개정/출처 확인 2026-10-21 · 주 언어: 한국어
학습 인덱스
- 공식 범위와 용어 2. URL에서 페이지까지 3. DNS 4. HTTP 5. TLS 6. HTTP 버전 7. 메일 8. 시험 함정 9. 퀵 시트·복습 10. 문제
1. 공식 범위와 용어
IPA Ver.7.2의 대분류 3 기술요소 > 중분류 10 네트워크 중 3. 通信プロトコル > (1) プロトコルとインタフェース > ⑤ アプリケーション層のプロトコル(PDF 49쪽/인쇄 45쪽)과 5. ネットワーク応用 > (1) インターネット > ① 電子メール・② Web(PDF 51쪽/인쇄 47쪽)에 대응한다. 비연속 페이지이며 PDF 50쪽/인쇄 46쪽을 AP18 범위라고 주장하지 않는다. AP16의 전송 계층은 여기서 연결만 한다. AP17의 IP 라우팅도 목적지 주소로 패킷을 보내는 전 단계라는 연결만 한다.
| KO | JA | EN | 역할 |
|---|---|---|---|
| 재귀 리졸버 | 再帰リゾルバ | recursive resolver | 클라이언트를 대신해 답을 찾고 캐시 |
| 권한 서버 | 権威サーバ | authoritative server | 영역(zone)의 원본 DNS 데이터를 제공 |
| 유효 시간 | TTL | time to live | 캐시의 통상 신선도 상한 |
| 요청/응답 | リクエスト／レスポンス | request/response | HTTP 메시지 교환 |
| 쿠키 | Cookie | cookie | 클라이언트가 보관해 범위가 맞는 요청에 전송하는 데이터 |
| 세션 | セッション | session | 흔히 불투명 ID로 서버 상태를 연결하는 논리 상태 |
| 캐시 | キャッシュ | cache | 재사용 가능한 응답 표현 저장 |
| 메일 사용자 에이전트 | MUA | mail user agent | 사용자가 메일을 작성·읽는 클라이언트 |
2. https://study.example/ap18?unit=dns에서 페이지까지
모든 값은 예약된 합성 예시다.
- 브라우저는 scheme
https, hoststudy.example, 생략된 기본 포트, path/ap18, queryunit=dns를 분해한다. - 브라우저/OS의 stub 및 캐시를 확인하고, 없으면 재귀 리졸버에 묻는다. 캐시 미스 시 리졸버는 보통 root → TLD → 권한 서버의 referral을 따라 반복 질의한다. 재귀 리졸버와 권한 서버는 다른 역할이다.
- 권한 답
A=192.0.2.80,TTL=300을 t=0에 받았다고 둔다. prefetch와 serve-stale이 없는 단순 모델에서 t=120에는 180초 남아 사용 가능하고, 만료 뒤 t=301에는 다시 질의한다. - HTTP/1.1 또는 HTTP/2의 HTTPS라면
TCP 연결 → TLS → HTTP순서다. 전형적인 Web PKI TLS는 인증서의 이름·신뢰·유효기간을 확인해 서버를 인증하고 키를 정해 기밀성과 무결성을 보호한다. - 요청은 다음과 같다.
GET /ap18?unit=dns HTTP/1.1
Host: study.example응답 예시는 200 OK, Cache-Control: max-age=600, ETag: "ap18-v1", Set-Cookie: SID=synth-7f3a; Secure; HttpOnly; SameSite=Lax와 표현 본문이다.
6. 단순 캐시에서 응답 시점을 t=0으로 보면 t=500에는 신선하다. t=700에는 stale이므로 If-None-Match: "ap18-v1"로 재검증한다. 서버가 304 Not Modified를 보내면 새 빈 표현을 받은 것이 아니라 저장한 본문을 재사용한다.
3. DNS 역할, 캐시와 TTL
stub은 보통 재귀 리졸버에 최종 답을 요구한다. 재귀 리졸버는 캐시할 수 있고, 미스면 root/TLD의 referral을 따라 해당 영역의 권한 서버에서 답을 얻는다. 권한 서버는 그 zone 데이터를 보유한다. TTL 300은 정상 캐시 수명을 300초로 제한하지만 모든 곳이 즉시 바뀐다는 전파 보증이 아니다. DNS는 이름을 주소 등으로 해석하며, 이후 실제 전달은 AP17에서 다룬 IP 라우팅의 역할이다.
4. HTTP 메시지, 상태, 쿠키·세션·캐시
요청은 method, target, headers, 선택적 body로 구성된다. 응답은 status, headers, 선택적 body다. 모든 응답에 body가 있는 것은 아니다. GET은 의미상 safe이고 idempotent하도록 의도되지만 URL·로그·기록에 남을 수 있는 query에 비밀을 넣어서는 안 된다.
| 상태 | 시험 수준 의미 |
|---|---|
| 200 OK | 요청 성공 |
| 301 | 영구 리다이렉트 |
| 302 | 임시 리다이렉트 |
| 304 | 조건부 검증 성공, 캐시 본문 재사용 |
| 400 | 잘못 구성된 요청 |
| 401 | 인증 필요 |
| 403 | 이해했지만 거부 |
| 404 | 자원을 찾지 못함 |
| 500 | 서버 내부 장애 |
| 503 | 일시적으로 서비스 불가 |
쿠키는 클라이언트 저장 데이터이며 domain/path 등 범위가 맞는 요청에 전송된다. 세션은 논리적 상태로, 흔히 서버 측 상태를 불투명한 세션 ID가 가리킨다. HTTP 캐시는 응답 표현을 재사용한다. 셋은 같은 것이 아니다. Secure는 HTTPS 전송으로 제한하고, HttpOnly는 스크립트 접근을 제한하며, SameSite는 교차 사이트 전송을 제어하는 데 도움을 주지만 어느 속성도 절대 보안을 보장하지 않는다.
5. TLS의 역할과 한계
TLS는 전형적인 HTTPS에서 서버 인증, 키 설정, 전송 기밀성·무결성을 제공한다. 인증서는 본문 암호화 알고리즘 자체가 아니다. TLS는 사이트의 내용이나 애플리케이션이 선량함을 보증하지 않으며 목적지 IP도 숨기지 않는다. 인증서 체인 검증 세부, 공개키·서명, 키 교환, 암호 수학은 AP19로 미룬다.
6. HTTP 버전 비교
| 계열 | 보통의 HTTPS Web 스택(상위 → 하위) |
|---|---|
| HTTP/1.1, HTTP/2 | HTTP → TLS → TCP |
| HTTP/3 | HTTP semantics → QUIC → UDP |
표는 계층을 위에서 아래로 적은 것이며, 실제 HTTP/1.1·2 연결 수립 순서는 앞 절처럼 TCP → TLS → HTTP다. QUIC은 UDP를 기반으로 하지만 신뢰성 있는 스트림, 혼잡 제어, 통합 TLS를 제공한다. HTTP/3은 raw unreliable HTTP도 아니고 별도 TCP 연결도 쓰지 않는다. UDP/443이 흔하지만 포트만으로 프로토콜이나 보안을 증명할 수 없다.
7. 메일 통신
sender@example.test의 MUA → SMTP submission server → 송신/수신 메일 서버가 SMTP로 relay한다. 수신 도메인의 서버는 DNS MX로 찾고, recipient@example.test의 mailbox에 넣는다. 수신자는 POP3로 가져오거나 IMAP으로 동기화한다.
- SMTP는 제출·송신·중계용이지 읽기용 프로토콜이 아니다.
- POP3는 다운로드 지향이며 설정에 따라 서버 사본을 남기거나 지울 수 있다.
- IMAP은 서버의 mailbox·folder·상태를 여러 클라이언트와 동기화한다.
- MIME은 비ASCII 본문과 첨부를 포장하며 전송 프로토콜이 아니다.
| 용도 | IANA 관례 포트 |
|---|---|
| SMTP relay / submission | TCP 25 / TCP 587 |
| POP3 / TLS 관례 | TCP 110 / TCP 995 |
| IMAP / TLS 관례 | TCP 143 / TCP 993 |
| HTTP / HTTPS / HTTP/3 | TCP 80 / TCP 443 / 흔히 UDP 443 |
등록 포트만으로 상대의 신원이나 보안을 증명하지 않는다. TLS 모드와 STARTTLS 세부는 이 글의 범위 밖이다.
8. 시험 함정
- recursive와 authoritative의 역할을 뒤집지 않는다. 클라이언트가 모든 권한 서버에 재귀 질의하는 것도 아니다.
- TTL은 캐시 신선도 상한이지 전 세계 즉시 전파 약속이 아니다.
- 304는 리다이렉트·오류·새 빈 본문이 아니다. 저장 본문을 재사용한다.
- 401은 인증 필요, 403은 이해했지만 거부다.
- 쿠키, 세션, 캐시는 서로 대체어가 아니다.
- HTTPS 표시만으로 애플리케이션의 신뢰성까지 결론 내리지 않는다.
- SMTP와 POP3/IMAP, MIME의 역할을 분리한다.
9. 퀵 시트·셀프 체크·1/3/7일 복습
- 퀵 시트:
DNS → (H1/H2: TCP→TLS | H3: QUIC/UDP) → HTTP;SMTP=보내기/중계,POP3=가져오기,IMAP=서버 동기화. - 셀프 체크: recursive/authoritative를 설명하는가? t=120/301과 t=500/700을 계산하는가? 304, 쿠키·세션·캐시, TLS의 보장과 한계를 구분하는가? 메일 흐름을 재현하는가?
- 1일: URL 흐름과 상태 코드 10개를 보지 않고 쓴다.
- 3일: DNS/HTTP 캐시 시간선과 메일 흐름을 그린다.
- 7일: 다섯 문제를 다시 풀고 모든 오답의 오류를 설명한다.
10. 오리지널 4지선다 5문제
Q1
DNS 설명으로 옳은 것은? ア 권한 서버가 항상 클라이언트 대신 계층 전체에 재귀 질의한다. イ 재귀 리졸버는 캐시할 수 있고 미스 시 referral을 따라 권한 계층에 질의하며, 권한 서버는 zone 데이터를 보유하고 TTL은 통상 캐시 수명을 제한한다. ウ TTL은 변경이 전 세계에 그 시간 안에 반드시 전파됨을 보장한다. エ 클라이언트는 root부터 모든 권한 서버에 각각 재귀 질의해야 한다.
정답: イ(2). ア 두 역할을 뒤집었다. イ가 역할과 TTL을 정확히 구분한다. ウ TTL은 전파 보증이 아니다. エ 보통 stub은 재귀 리졸버에 맡긴다.
Q2
HTTPS와 HTTP/3 설명으로 옳은 것은? ア HTTP/3은 신뢰성 없는 raw HTTP를 UDP에 바로 싣는다. イ TLS는 DNS보다 먼저 실행된다. ウ 서버 인증서가 각 HTTP 본문을 직접 암호화하는 알고리즘이다. エ 일반적인 HTTPS의 HTTP/1.1·2는 TCP 뒤 TLS를 사용하고, HTTP/3은 별도 TCP 없이 신뢰성 스트림과 통합 TLS를 제공하는 QUIC over UDP를 사용한다.
정답: エ(4). ア QUIC의 신뢰성 기능을 무시했다. イ 이름 해석이 먼저 필요하다. ウ 인증서와 payload cipher를 혼동했다. エ가 두 스택을 정확히 비교한다.
Q3
stale 캐시 응답에 If-None-Match를 보냈고 validator가 일치할 때 옳은 것은? ア 304는 영구 리다이렉트다. イ 304는 서버 장애다. ウ 서버는 304를 보낼 수 있고 클라이언트는 저장한 본문을 재사용한다. エ 304에는 항상 새 표현 본문이 들어 있다.
정답: ウ(3). ア 리다이렉트가 아니다. イ 오류가 아니다. ウ가 조건부 재검증의 뜻이다. エ는 새 본문을 뜻하지 않는다.
Q4
쿠키·세션·캐시 설명으로 옳은 것은? ア 쿠키는 클라이언트 저장 범위 데이터, 세션은 흔히 불투명 ID로 연결한 논리 상태, 캐시는 응답 표현 재사용이다. イ 셋은 모두 서버의 동일 파일이다. ウ Secure면 쿠키 탈취가 절대 불가능하다. エ HttpOnly면 모든 CSRF가 사라진다.
정답: ア(1). ア가 세 역할을 구분한다. イ 서로 다른 개념이다. ウ Secure는 전송 제한이지 절대 보장이 아니다. エ HttpOnly는 스크립트 접근 제한이며 모든 공격을 막지 않는다.
Q5
메일 프로토콜 역할로 옳은 것은? ア POP3가 서버 간 relay하고 SMTP가 mailbox를 동기화한다. イ IMAP이 송신하고 SMTP가 첨부를 인코딩한다. ウ MIME은 메일 서버 간 전송 프로토콜이다. エ SMTP는 제출·relay, POP3는 다운로드 지향 retrieval, IMAP은 서버 측 mailbox 상태 동기화에 쓰인다.
정답: エ(4). ア 역할이 뒤바뀌었다. イ IMAP/SMTP 역할도, MIME 역할도 틀렸다. ウ MIME은 포장 형식이다. エ가 세 프로토콜을 정확히 구분한다.
정답 키: [2, 4, 3, 1, 4] = [イ, エ, ウ, ア, エ]
공식 출처와 고지
모두 1차 공식 자료이며 2026-10-21 확인: IPA Ver.7.2, RFC 1034, RFC 1035, RFC 9110, RFC 9111, RFC 6265, RFC 8446, RFC 9113, RFC 9114, RFC 9000, RFC 5321, RFC 1939, RFC 9051, RFC 2045, IANA ports.
독자 제작 학습 자료이며 IPA/IETF/IANA와 제휴하지 않는다. 기출문제·제3자 해설을 사용하지 않았고 합격을 보장하지 않는다.