[컴퓨터네트워크] Application Layer | HTTP & WWW, SMTP & Email, DNS

Application Layer, 인터넷 세상은 어떻게 소통할까

TCP/IP라는 튼튼한 도로와 배송 시스템을 이해하고 나니, 이제 그 위를 달리는 '화물'의 정체가 궁금해졌다. 우리가 매일 마주하는 인터넷 세상은 크게 세 가지 축으로 움직인다. 정보를 탐색하고 보여주는 HTTP(웹), 비동기적으로 소식을 전하는 Email(이메일), 그리고 복잡한 숫자 주소 대신 친숙한 이름을 쓰게 해주는 DNS(도메인 시스템)이다.

오늘은 거대한 웹 세상을 지탱하는 약속, HTTP(HyperText Transfer Protocol)에 대해 깊이 있게 알아보고, 남은 두 기둥인 Email System과 DNS을 통해 인터넷을 이루는 세 주요 개념이 어떻게 유기적으로 연결되어있는지 확인해보고자 한다.

1. WWW: 정보의 거미줄 (The World Wide Web)

팀 버너스 리(Tim Berners-Lee)가 1989년에 제안한 WWW는 '연결' 그 자체다. 전 세계에 흩어진 문서(Web Page)들이 서로 링크(Link)로 연결되어 있는 구조. 이것이 바로 하이퍼텍스트(Hypertext)의 개념이다.

WWW example

구조: 분산된 클라이언트-서버(Client-Server) 모델이다.
클라이언트(브라우저): 사용자의 요청을 받아 서버에 전달하고, 응답받은 HTML, 자바스크립트 등을 해석(Interpret)해서 보여주는 역할을 한다. (Controller + Protocols + Interpreters)
Web Client
서버: 웹 페이지를 저장하고 있다가 요청이 오면 내어준다. (Apache, IIS 등)

이때, 수많은 문서 중 내가 원하는 문서를 정확히 가리키기 위해 우리는 URL(Uniform Resource Locator)이라는 주소 체계를 사용한다.

URL 구조: Protocol://Host:Port/Path
http: 프로토콜
www.google.com: 호스트(IP 주소 또는 도메인)
80: 포트 (HTTP의 기본 포트는 80이다)
/index.html: 파일의 경로

2. HTTP: 웹의 언어 (HyperText Transfer Protocol)

HTTP는 이름 그대로 '하이퍼텍스트를 전송하는 규약'이다. 하지만 단순한 텍스트 전송을 넘어, 이미지, 비디오 등 모든 웹 리소스를 나르는 수단이 되었다.

HTTP는 TCP 위에서 동작한다. 즉, 신뢰성(Reliability)을 중요하게 생각한다. 데이터를 요청하기 전에 먼저 서버와 3-Way Handshake를 통해 연결을 맺어야 한다는 뜻이다. 여기서 중요한 이슈가 발생한다.

Non-persistent vs. Persistent Connections

초기 HTTP(1.0)는 비지속 연결(Non-persistent) 방식이었다.

HTTP(1.0)

TCP 연결을 맺는다.
파일 하나(예: HTML)를 요청하고 받는다.
연결을 끊는다.
HTML 안에 이미지 10개가 있네? 다시 1번부터 10번 반복.

이건 너무 비효율적이다. 오버헤드가 너무 컸다. 그래서 HTTP 1.1부터는 지속 연결(Persistent Connection)이 기본이 되었다. 한 번 문을 열었으면(TCP Connection), 필요한 파일들을 다 주고받을 때까지 문을 닫지 않고 열어두는 것이다. 이 작은 변화가 웹의 속도를 비약적으로 향상시켰다.

HTTP(1.1~)

참고로 우리가 주로 보는 HTTPS는 여기서 말하는 HTTP에 TLS라는 보안을 위한 프로토콜이 결합된 개념이다.

HTTPS

3. 메시지의 구조: Request와 Response

HTTP 통신은 철저하게 "주세요(Request)"와 "여기 있습니다(Response)"의 티키타카다. 개발자 도구(F12)를 열어 네트워크 탭을 보면 이 대화가 텍스트로 오가는 것을 볼 수 있다.

Message Format

Request Message (요청)

Request Line: Method URL Version (예: GET /index.html HTTP/1.1)
- Method: GET(주세요), POST(보낼게요(주로 새로 업로드)), PUT(올릴게요(주로 수정사항)), DELETE(지워주세요) 등 행동을 정의한다.
Header Lines: 브라우저 정보, 쿠키 등 부가 정보.
Body: POST 요청 시 보낼 데이터를 담는다.

Response Message (응답)

Status Line: Version Status Code Phrase (예: HTTP/1.1 200 OK)

1xx: 정보 제공
2xx: 성공 (200 OK)
3xx: 리다이렉션 (301 Moved Permanently)
4xx: 클라이언트 실수 (404 Not Found - 가장 익숙한 에러다)
5xx: 서버 실수 (500 Internal Server Error)

Example of Request & Response

4. Stateless와 Cookies

HTTP의 가장 큰 특징이자 약점은 Stateless(무상태성)이다. 서버는 클라이언트의 이전 상태를 기억하지 않는다. 내가 방금 로그인하고 페이지를 옮겨도, 서버는 "누구세요?"라고 묻는다.

쇼핑몰을 만든다고 가정해보자. 장바구니에 물건을 담고 결제 페이지로 갔는데 장바구니가 비어있다면? 이는 비즈니스에 치명적이다. 그래서 등장한 것이 쿠키(Cookies)다.

개념: 서버가 클라이언트에게 발급하는 일종의 '식별표'다.
동작 원리:
1. 클라이언트가 요청을 보낸다.
2. 서버는 응답 헤더에 Set-Cookie: ID=1234를 담아 보낸다. (서버는 이 ID를 DB에 저장해둔다)
3. 브라우저는 이 쿠키를 저장해뒀다가, 다음 요청 때마다 자동으로 헤더에 Cookie: ID=1234를 포함시켜 보낸다.
4. 서버는 쿠키를 보고 "아, 아까 그 친구구나"라고 인식한다.

쿠키 덕분에 우리는 로그인을 유지하고, 장바구니를 채운 채 쇼핑을 계속할 수 있게 되었다.

Example of Cookies

5. Web Caching: Proxy Server

사용자가 늘어날수록 원본 서버(Origin Server)의 부하는 심해진다. 미국에 있는 서버에서 매번 이미지를 가져오는 건 느리고 비싸다. 이를 해결하기 위해 프록시 서버(Proxy Server), 즉 웹 캐시(Web Cache)를 사용한다.

클라이언트와 서버 사이에 위치하여, 자주 찾는 데이터의 사본을 저장해둔다.
사용자가 요청하면 원본 서버까지 가지 않고 프록시가 바로 응답한다.
이를 통해 트래픽을 줄이고, 응답 속도(Latency)를 획기적으로 개선한다.

Proxy Server

6. Electronic Mail: 비동기 통신의 시작

HTTP가 정보를 '찾아가는' 방식이라면, 이메일은 특정 대상에게 정보를 '보내는' 방식이다. 그리고 이 모든 통신의 뒤편에는 우리가 숫자로 된 IP 주소를 외우지 않아도 되게 해주는 가상화 도구, DNS가 있다. 다음에 올 내용들에서 이에 관해 하나씩 알아보겠다.

이메일은 인터넷의 역사와 궤를 같이하는 가장 오래된 서비스 중 하나다. 하지만 그 구조는 생각보다 복잡하다. 단순히 A가 B에게 바로 보내는 것이 아니기 때문이다.

이메일 시스템은 비동기(Asynchronous) 통신이다. 내가 보낼 때 상대방이 켜져 있을 필요가 없다. 이를 위해 이메일 시스템은 작성자(UA) → 발신 우체국(MTA) → 수신 우체국(MTA) → 수신자(UA)라는 다단계 구조를 가진다.

Electronic Mail Architecture

이메일의 세 가지 에이전트

UA (User Agent): 우리가 흔히 쓰는 아웃룩, 지메일 같은 프로그램이다. 편지를 쓰고 읽는 인터페이스를 제공한다.
User Agent
MTA (Message Transfer Agent): 실제 우편물 분류 기계와 같다. 인터넷을 통해 메일을 서버에서 서버로 전달한다. 이때 사용하는 프로토콜이 바로 SMTP다.
MAA (Message Access Agent): 우체국 사서함이다. 수신자가 접속할 때까지 메일을 보관하고 있다가, 요청하면 내어준다. POP3와 IMAP이 여기에 해당한다.

SMTP (Simple Mail Transfer Protocol): 밀어내기 (Push)

SMTP는 단순하다. 클라이언트가 서버로, 혹은 서버가 다른 서버로 메일을 밀어 넣는(Push) 역할을 한다. 재미있는 점은 SMTP가 아주 오래된 프로토콜이라 7-bit ASCII 텍스트만 지원한다는 것이다.

Example of SMTP

"그럼 한글이나 이미지는 어떻게 보내지?" 의문이 들 수 있다. 여기서 등장하는 것이 MIME (Multipurpose Internet Mail Extensions)이다.

MIME의 역할: ASCII가 아닌 데이터(한글, 이미지, 영상 등)를 SMTP가 이해할 수 있는 7-bit ASCII 문자로 변환(Encoding)해서 보낸다. 헤더에 Content-Type을 명시하여 수신자가 다시 원본으로 복구할 수 있게 돕는다.

MIME

POP3 vs IMAP4: 가져오기 (Pull)

SMTP로 상대방 서버까지 도착한 메일은 수신자가 직접 가져와야 한다(Pull). 이때 두 가지 방식 중 하나를 선택한다.

POP3 (Post Office Protocol v3): "다운로드 후 삭제". 서버에서 내 컴퓨터로 메일을 가져오고 서버에서는 지운다(옵션 설정 가능). 여러 기기에서 메일을 확인하기 불편하다.
IMAP4 (Internet Mail Access Protocol v4): "서버 동기화". 메일이 서버에 계속 남아있고, 내 컴퓨터에서는 헤더만 먼저 보거나 폴더를 관리할 수 있다. 스마트폰, 노트북 등 여러 기기를 쓰는 요즘 환경에 적합하다.

7. DNS (Domain Name System): 인터넷의 전화번호부

우리는 친구에게 전화를 걸 때 전화번호(IP 주소)를 외우지 않는다. 대신 주소록(DNS)에서 친구 이름(도메인 네임)을 검색한다. www.dgist.ac.kr 같은 도메인 이름을 147.46.x.x 같은 IP 주소로 변환해주는 시스템, 그것이 바로 DNS다.

계층적 구조 (Hierarchy of Name Space)

전 세계의 모든 도메인 정보를 한 대의 서버에 저장할 수는 없다. 그래서 DNS는 역트리(Inverted Tree) 구조로 분산되어 있다.

Hierarchical Name Space

Root Server (.): 최상위 관리자. 전 세계에 13개 세트가 존재한다.
Top-Level Domain (TLD) Server: .com, .edu, .kr 등을 관리한다.
Authoritative Server: 실제 특정 도메인(google.com, naver.com)의 IP 정보를 가지고 있는 서버다.

Domain example

DNS Resolution: 주소를 찾는 여정

브라우저에 주소를 입력했을 때 일어나는 일(Resolution)은 마치 꼬리에 꼬리를 무는 질문과 같다.

Recursive Resolution (재귀적 해석): 클라이언트가 로컬 DNS 서버(통신사 서버 등)에게 "이 주소 알아?"라고 묻는다. 로컬 서버는 답을 알아낼 때까지 대신 뛰어다닌다.
Recursive Resolution
Iterative Resolution (반복적 해석): 로컬 DNS 서버가 상위 서버들에게 차례로 묻는다.
- "루트야, www.naver.com 어디니?" -> "난 모르겠고 .com 관리자한테 가봐."
- ".com 관리자야, www.naver.com 어디니?" -> "난 모르겠고 naver.com 관리자 IP 알려줄게."
- "네이버 관리자야, www IP 뭐니?" -> "아, 그거 223.130.x.x야."
  Iterative Resolution

Caching: 효율성을 위해

이 복잡한 과정을 매번 반복하면 인터넷은 너무 느릴 것이다. 그래서 캐싱(Caching)이 필수다. 한 번 알아낸 주소는 일정 시간(TTL, Time To Live) 동안 로컬에 저장해두고, 다시 물어보면 바로 답해준다.

DNS 설정을 변경해도 바로 적용되지 않는 이유가 바로 이 TTL 때문이라는 것을, 서버 배포 과정에서 뼈저리게 느꼈던 기억이 난다.

마치며

지금까지 Application Layer의 핵심인 HTTP, Email, DNS를 살펴보았다.

"Application Layer는 네트워크의 존재 이유"가 아닐까 싶을 정도로 실생활에 밀접한 개념들이 많이 있었다. 물리적 케이블부터 TCP/IP의 복잡한 제어 과정까지, 그 아래의 모든 계층이 존재하는 이유는 결국 사용자가 웹을 서핑하고(HTTP), 메시지를 보내고(SMTP), 이름을 통해 접속(DNS)하기 위함이다.

나는 이 계층에서 사용자와 가장 가까운 코드를 작성하기만 했었는데, 그 코드가 어떤 과정을 거쳐 전달되는지, 도메인 이름 하나가 어떻게 IP로 변환되는지를 이번 기회에 이해할 수 있었던 것 같다.

컴퓨터 네트워크의 가장 윗단, Application Layer에 대한 내용을 끝으로 네트워크 강의도 여기서 마쳤다. 이제 내가 만든 서비스가 이 거대한 네트워크 위에서 어떻게 돌아가는지 더 선명하게 보일 것 같다.

추천글

[컴퓨터 네트워크] 데이터 통신의 기본 요소와 TCP/IP 5계층

[컴퓨터 네트워크] Data-link layer | Frameing, Error Control methods, MAC Protocols

[컴퓨터 네트워크] Physical Layer | 데이터 전송 속도의 한계, 아날로그의 디지털화 & 디지털의 아날로그화

[컴퓨터네트워크] Network Layer: Data transfer | IPv4 datagram, Fragmentation, ICMP, Mobile IP, IPv6

[컴퓨터네트워크] Transport Layer | UDP, TCP, Flow/Error/Congestion Control