Web 2 해독: 인터넷의 언어
Source: Dev.to
Source: …
Episode 2 – 웹을 구동하는 네트워킹 프로토콜
Episode 1에서는 웹이 작동하는 기본 원리(URL 입력, DNS 조회, 보안 연결, 페이지 렌더링)를 살펴보았습니다. TCP와 HTTP에 대해서는 표면만 훑어봤죠.
이번에는 네트워킹 프로토콜이 어떻게 데이터를 신뢰성 있게, 빠르게 인터넷을 가로질러 이동시키는지 깊이 파고들어 보겠습니다. 낮은 수준의 전송 프로토콜부터 시작해 브라우저와 서버가 사용하는 애플리케이션‑계층 언어까지 차근차근 살펴볼게요.
1. 전송 계층 – 두 머신 사이에 데이터 패킷이 이동하는 방식
전송 계층을 신중한 택배(신뢰성은 높지만 느림)와 빠른 자전거 메신저(속도는 빠르지만 신뢰성은 낮음) 중 하나를 고르는 것으로 비유할 수 있습니다.
| Protocol | 주요 특징 | 전형적인 사용 사례 |
|---|---|---|
| TCP (Transmission Control Protocol) | • 연결 지향 – 데이터 전송 전에 3‑way 핸드셰이크로 가상 연결을 설정합니다. • 데이터를 번호가 매겨진 세그먼트로 나누고, 수신 측에서 순서대로 재조립합니다. • ACK를 기다리고, 손실된 세그먼트를 재전송하며, 순서 보장을 제공합니다. • 흐름 제어와 혼잡 제어를 수행해 네트워크 과부하를 방지합니다. • 부가적인 오버헤드 → 약간 높은 지연시간. | 웹 브라우징, 이메일, 파일 전송 등 정확성이 속도보다 중요한 모든 상황. |
| UDP (User Datagram Protocol) | • 비연결 지향 – 핸드셰이크가 없고 개별 패킷을 추적하지 않습니다. • 재전송, 순서 보장, 혼잡 제어가 내장되어 있지 않습니다. • 최소 오버헤드 → 낮은 지연시간과 더 예측 가능한 타이밍. • 소량의 손실은 허용됩니다. | 실시간 스트리밍, 화상 회의, 온라인 게임, VoIP 통화 등 속도가 신뢰성보다 중요한 경우. |
2. 애플리케이션 계층 – 브라우저와 서버가 대화하는 언어
TCP 혹은 UDP가 패킷을 전달한 뒤, 웹은 요청/응답 통신을 위한 프로토콜이 필요합니다.
2.1 HTTP (Hypertext Transfer Protocol)
클라이언트(예: 브라우저)가 요청을 보내고 서버가 응답하는 방식을 정의합니다.
- 텍스트 기반의 요청‑응답 프로토콜.
- 클라이언트가 리소스(HTML, CSS, JSON 등)를 요청합니다.
- 서버는 상태 라인, 헤더, 그리고 선택적인 본문을 포함해 응답합니다.
- 클래식 HTTP/1.1은 TCP 위에서 동작하며, TCP의 신뢰성과 순서 보장을 그대로 물려받습니다.
2.2 HTTPS (HTTP Secure)
별도의 애플리케이션 프로토콜이 아니라 TLS‑암호화 터널 안에 포함된 HTTP입니다.
- HTTP 메시지가 교환되기 전에 클라이언트와 서버가 TLS 핸드셰이크를 수행해 키, 암호화 방식, 서버 인증서를 협상합니다.
- “전송 계층에서 HTTP의 모든 바이트를 TLS로 감싸는” 것으로 생각하면 됩니다.
- 최신 브라우저는 일반 HTTP를 “보안되지 않음”으로 간주하고, 가능한 한 HTTPS를 강력히 선호합니다.
2.3 HTTP/3 (QUIC)
- HTTP/2는 하나의 TCP 연결 위에 여러 HTTP 스트림을 다중화해 성능을 개선했지만, 헤드‑오브‑라인(HOL) 차단 문제가 남아 있었습니다: 하나의 TCP 패킷이 손실되면 해당 연결의 이후 모든 패킷이 대기하게 됩니다.
- HTTP/3는 UDP 위에 구축된 전송 프로토콜 QUIC을 사용합니다.
- QUIC은 자체적인 신뢰성, 암호화(TLS 1.3 통합), 혼잡 제어를 제공합니다.
- 스트림 인식 구조: 각 HTTP 스트림이 독립적이어서 하나의 스트림 손실이 다른 스트림을 차단하지 않습니다.
- 결과: HOL 차단 감소, 페이지 로드 속도 향상, 불안정한 모바일·Wi‑Fi 네트워크에서도 더 높은 복원력.
- 주요 브라우저들은 점차 많은 대형 사이트에 대해 HTTP/3를 채택하고 있습니다.
3. 실시간 및 레거시 프로토콜 – 클래식 웹 페이지를 넘어
인터넷의 모든 것이 “HTML + CSS”에만 국한되지 않습니다. 아래는 여러분이 마주하게 될 추가 프로토콜들입니다.
3.1 WebSockets
- HTTP가 클라이언트가 항상 대화를 시작해야 한다는 제한을 해결합니다.
- 브라우저는 기존 HTTP 연결을 전이시켜 양방향 전이중 프로토콜로 업그레이드하고, 단일 TCP 연결을 열어 두 방향으로 지속적인 데이터를 주고받을 수 있게 합니다.
Source: https://example.com/your-article
3.2 이메일 프로토콜
| 프로토콜 | 목적 | 전송 |
|---|---|---|
| SMTP (Simple Mail Transfer Protocol) | 메일 서버 간에 이메일을 전송합니다. | TCP (보통 포트 25) |
| IMAP (Internet Message Access Protocol) | 서버에 메시지를 보관하면서 메시지를 가져오며, 기기 간 동기화를 제공합니다. | TCP (포트 143/993, TLS 사용) |
| POP3 (Post Office Protocol v3) | 메시지를 로컬 장치에 다운로드하고 일반적으로 서버에서 삭제합니다. | TCP (포트 110/995, TLS 사용) |
3.3 파일 전송 프로토콜
| 프로토콜 | 설명 | 보안 |
|---|---|---|
| FTP (File Transfer Protocol) | 가장 오래된 파일 전송 방식 중 하나이며, TCP 위에 제어 채널과 데이터 채널을 별도로 사용합니다. | 평문(암호화 없음) |
| SFTP (SSH File Transfer Protocol) | SSH를 통해 파일을 전송하며, 명령과 데이터를 모두 암호화된 단일 채널로 처리합니다. | 강력한 암호화(SSH) |
| FTPS (FTP Secure) | TLS/SSL 암호화를 적용한 FTP(명시적 또는 암시적 모드). | TLS/SSL 암호화 |
4. 요약
- 전송 계층: TCP(신뢰성) vs. UDP(속도).
- 응용 계층: HTTP → HTTPS → HTTP/3 (QUIC).
- 특수 프로토콜: WebSockets, SMTP/IMAP/POP3, FTP/SFTP/FTPS.
이러한 기본 요소들을 이해하면 웹이 왜 빠르고, 신뢰할 수 있으며, 안전하게 느껴지는지, 그리고 실시간 상호작용이나 레거시 지원이 필요할 때 어떤 트레이드‑오프가 발생하는지를 파악할 수 있습니다.
다음 에피소드에서는 브라우저가 이러한 리소스를 화면에 표시되는 페이지로 렌더링하는 과정을 살펴볼 것입니다.
FTPS – File Transfer Protocol Secure (보통 FTPS로 표기)로, 기존 FTP 모델 위에 SSL/TLS를 적용해 암호화를 추가한 방식입니다.
TCP와 UDP에서 시작해 HTTP, HTTPS, WebSockets, SMTP, FTP까지 응용 계층까지 이르는 모든 프로토콜은 인터넷을 연결해 주는 보이지 않는 접착제와 같습니다. 각각은 약간씩 다른 문제를 해결합니다:
- 신뢰성 있는 전송 – TCP
- 저지연, 비연결형 통신 – UDP
- 웹 페이지 조회 – HTTP
- 보안 웹 브라우징 – HTTPS (HTTP + TLS)
- 실시간 양방향 업데이트 – WebSockets
- 이메일 전송 – SMTP
- 파일 전송 – FTP (암호화가 필요하면 FTPS)
prasunchakra.com을 입력하거나 좋아하는 앱을 열면, 실제로는 기계들 간에 정교하게 계층화된 대화가 시작되는 것이며, 각 프로토콜이 스택에서 자신의 역할을 수행합니다.
웹 앱, API, 백엔드 시스템을 구축할 때 이 계층들을 이해하면 다음과 같은 도움이 됩니다:
- 성능 문제를 분석할 수 있음
- 보안 선택을 현명하게 할 수 있음
- 실제 네트워크에서 가끔 발생하는 “신비한” 오류를 진단할 수 있음
다음 에피소드에서는 이 퍼즐의 특정 조각들을 자세히 살펴볼 예정입니다.