왜 응용 계층부터 다시 보는가

지금까지는 아래 계층(물리·데이터링크·네트워크·전송)이 데이터를 “어떻게 옮기는가”를 다뤘습니다. 하지만 사람이 실제로 마주하는 것은 웹 브라우저 주소창에 www.example.com을 치는 행위, 이메일을 보내고 받는 행위입니다. 이 행위 뒤에서 동작하는 규칙이 응용 계층(application layer) 프로토콜입니다.

응용 계층은 03편에서 다룬 TCP/IP 4계층 모델의 맨 위층으로, OSI 7계층의 세션·표현·응용 계층 역할을 뭉쳐서 담당합니다(자세한 계층 대응은 03편 참고). 이 계층의 프로토콜은 대부분 전송 계층으로 TCP나 UDP를 그대로 빌려 쓰고(17편), 그 위에 “무엇을 주고받을지”에 대한 약속만 추가로 얹습니다.

1. DNS — 이름을 주소로 바꾸는 전화번호부

왜 필요한가

네트워크 계층(12편)에서 배웠듯, 인터넷에서 실제로 패킷을 주고받으려면 IP 주소가 있어야 합니다. 그런데 사람은 172.217.175.100 같은 숫자를 기억하지 못합니다. 이름은 기억하지만 기계는 이름으로 길을 찾지 못하는 이 간극을 메우는 것이 DNS(Domain Name System, 도메인 이름 시스템)입니다.

쉽게 말하면: DNS는 전화번호부입니다. 사람 이름(도메인 이름)을 알려주면 전화번호(IP 주소)를 찾아줍니다.

도메인 이름의 계층 구조

DNS의 이름 공간은 나무(tree) 구조입니다. www.example.com을 오른쪽부터 읽으면 계층이 보입니다.

• 루트(root): 이름 없이 점(.) 하나로 표현되는 최상위 노드. 사실 모든 도메인 이름 끝에는 생략된 점이 하나 더 있습니다(www.example.com.).
• 최상위 도메인(TLD, Top-Level Domain): com, org, kr처럼 루트 바로 아래 계층. 국가 코드(kr, jp)와 일반 목적(com, org)으로 나뉩니다.
• 2차 도메인(second-level domain): 조직이 실제로 등록해 사용하는 이름, 예를 들면 example.com.
• 호스트 이름(host name): 그 조직 안에서 특정 서버를 가리키는 이름, 예를 들면 www나 mail.

이 계층 구조 덕분에 DNS는 분산 데이터베이스로 운영될 수 있습니다. 전 세계 모든 도메인 이름을 한 서버가 관리하는 것이 아니라, 각 계층을 책임지는 네임서버(name server)가 나뉘어 있고, 각 네임서버는 자기 하위 영역(zone, 존)만 정확히 알면 됩니다.

재귀 질의와 반복 질의

이름을 실제로 찾는 과정에서 질의(query) 방식이 두 가지로 나뉘는 것이 시험에서 자주 나오는 포인트입니다.

• 재귀 질의(recursive query): 질의를 받은 서버가 답을 모르면, 자신이 대신 다른 서버에 물어서 최종 답을 찾아 돌려줍니다. 클라이언트 입장에서는 한 번 묻고 최종 답만 받습니다.
• 반복 질의(iterative query): 질의를 받은 서버가 답을 모르면, “나는 모르니 이 서버에 물어봐라”라며 다른 서버의 주소만 알려줍니다. 질의한 쪽이 직접 다음 서버에 다시 물어야 합니다.

실제 DNS 조회는 이 둘이 섞여서 일어납니다. 일반 사용자의 PC(리졸버, resolver)는 보통 로컬 DNS 서버(local DNS server, 흔히 ISP가 제공)에게 재귀 질의를 보냅니다. 로컬 DNS 서버는 답을 모르면 루트 → TLD → 권한(authoritative) 네임서버 순서로 반복 질의를 이어가며 답을 찾아, 최종적으로 사용자에게 재귀 질의의 답을 돌려줍니다.

한 번 찾은 결과는 캐싱(caching, 임시 저장)되어 재사용됩니다. DNS 레코드에는 TTL(Time To Live, 생존 시간)이 붙어 있어, 이 시간이 지나기 전까지는 다시 질의하지 않고 캐시된 값을 씁니다. TTL을 짧게 두면 변경 사항이 빨리 반영되지만 질의 트래픽이 늘고, 길게 두면 질의는 줄지만 변경 반영이 늦어지는 트레이드오프가 있습니다.

주요 레코드 타입

DNS가 저장하는 정보는 레코드(record) 단위입니다. 시험에 자주 등장하는 몇 가지만 정리합니다.

2. 이메일 프로토콜 — 보내기와 받기는 다른 문제다

왜 프로토콜이 여러 개인가

이메일을 주고받는 과정은 우편 제도와 비슷합니다. 편지를 우체통에 넣는 것(보내기)과 우편함에서 편지를 꺼내는 것(받기)은 서로 다른 절차입니다. 이메일도 마찬가지로 보내는 프로토콜과 받는 프로토콜이 분리되어 있습니다.

쉽게 말하면: 메일을 보낼 때는 우체국(SMTP)에 맡기고, 메일을 받을 때는 내 우편함(POP3, IMAP)을 확인합니다. 우체국 직원과 우편함 관리인은 하는 일이 다릅니다.

SMTP — 메일을 보내는 프로토콜

SMTP(Simple Mail Transfer Protocol, 단순 메일 전송 규약)는 메일을 발신 클라이언트에서 발신 서버로, 그리고 발신 서버에서 수신 서버로 전달할 때 쓰는 프로토콜입니다. 기본 포트는 25번입니다.

SMTP는 이름 그대로 단순한 텍스트 명령 기반 프로토콜입니다. HELO(또는 EHLO)로 인사하고, MAIL FROM으로 발신자를, RCPT TO로 수신자를 알린 뒤, DATA로 본문을 전송합니다. 이 흐름 자체가 “메일을 계속 다음 서버로 넘겨주는” 릴레이(relay) 구조라는 점이 핵심입니다.

POP3 — 받아서 내려받고 지운다

POP3(Post Office Protocol version 3, 우체국 프로토콜 3판)는 메일 서버에 도착한 메일을 클라이언트로 다운로드하는 프로토콜입니다. 기본 포트는 110번입니다.

POP3의 기본 동작 방식은 “메일을 받아오면 서버에서는 삭제한다”입니다(설정으로 서버에 사본을 남길 수도 있지만 기본 개념은 다운로드 후 삭제입니다). 그래서 한 대의 컴퓨터로 메일을 내려받으면, 다른 기기에서는 그 메일을 다시 볼 수 없는 경우가 많습니다.

IMAP — 서버에 두고 여러 기기에서 본다

IMAP(Internet Message Access Protocol, 인터넷 메시지 접근 규약)도 메일을 받아오는 프로토콜이지만, 철학이 다릅니다. 기본 포트는 143번입니다.

IMAP은 메일을 서버에 그대로 둔 채로 클라이언트가 그 내용을 조회·검색·정리합니다. 읽음 표시, 폴더 이동 같은 작업도 서버에 반영되기 때문에, 스마트폰과 PC에서 같은 메일함을 열어도 항상 같은 상태를 봅니다.

세 프로토콜 비교

3. 잘 알려진 포트 번호

잘 알려진 포트(well-known port)는 0번부터 1023번까지의 범위로, 특정 서비스가 관례적으로 고정해 사용하는 포트 번호입니다. 전송 계층(17편)에서 포트는 “같은 IP 주소 안에서 어떤 프로그램에게 데이터를 전달할지” 구분하는 번호였음을 떠올리면, 왜 서비스마다 정해진 포트가 필요한지 이해가 됩니다 — 클라이언트가 “메일 서버에 접속하겠다”고 할 때마다 포트 번호를 새로 묻지 않아도 되기 때문입니다.

이 표는 21편(HTTP·FTP·DHCP)에서도 이어서 참조하니, 숫자 자체를 외우기보다는 “25는 보내기, 110·143은 받기”처럼 역할과 묶어서 기억하면 헷갈리지 않습니다.

핵심 정리

• DNS는 도메인 이름을 IP 주소로 바꾸는 분산 데이터베이스이며, 이름 공간은 루트 → TLD → 2차 도메인 → 호스트 이름의 나무 구조다.
• 재귀 질의는 질의받은 서버가 대신 답을 찾아오고, 반복 질의는 질의한 쪽이 다음 서버를 직접 찾아간다. 일반적인 이름 해석은 클라이언트-로컬 DNS 서버 구간은 재귀, 로컬 DNS 서버-상위 서버 구간은 반복으로 섞여 일어난다.
• SMTP는 메일을 보내는 릴레이 프로토콜(포트 25)이고, POP3(포트 110)는 받은 뒤 서버에서 삭제하는 방식, IMAP(포트 143)은 서버에 보관한 채 여러 기기에서 동기화하는 방식이다.
• 잘 알려진 포트 번호(FTP 20/21, SSH 22, SMTP 25, DNS 53, DHCP 67/68, HTTP 80, POP3 110, IMAP 143, HTTPS 443)는 시험에서 프로토콜 이름과 포트를 짝짓는 문제로 자주 나온다.

마무리 복습

참고 자료

• IETF RFC 1034 / 1035 - DNS 
• IANA Service Name and Transport Protocol Port Number Registry