Network Fundamentals - 09. HTTP·HTTPS·TLS

 

봉투에 인감도장을 찍어 보내는 우편 — HTTP·HTTPS·TLS

브라우저에 https://example.com을 친다. 주소창의 자물쇠 아이콘이 잠긴다. "연결이 안전합니다"라는 메시지가 보인다. 이 자물쇠가 의미하는 것은 — 전송되는 데이터가 암호화돼 있어서, 중간에 가로채도 내용을 못 읽는다는 뜻이다. 이 암호화를 담당하는 것이 TLS(Transport Layer Security) 고, 그 위에서 동작하는 웹 프로토콜이 HTTPS(HTTP Secure) 다. http://(암호화 없음)와 https://(TLS 암호화)의 차이가 — 바로 이 자물쇠다.

이 글은 HTTP와 TLS를 다룬다. HTTP가 어떻게 발전했는지(HTTP/1.1 → HTTP/2 → HTTP/3), TLS가 어떻게 암호화 연결을 설정하는지(핸드셰이크·인증서·SNI), 그리고 HTTPS가 왜 인터넷의 표준이 됐는지를 본다. 이전 글에서 본 TCP가 "신뢰성 있는 전송"을 담당했다면, TLS는 그 위에서 "보안(기밀성·무결성·인증)"을 담당하고, HTTP는 그 위에서 "웹의 규칙(요청·응답)"을 담당한다. 계층이 쌓이는 마지막 단계다.

HTTP — 웹의 언어

HTTP(HyperText Transfer Protocol) 는 웹에서 데이터를 주고받는 프로토콜이다. 클라이언트(브라우저)가 요청(request) 을 보내고, 서버가 응답(response) 을 보낸다. 비유하자면 — 식당에서 메뉴를 보고 주문(요청)하면, 주방에서 음식(응답)을 내오는 것.

HTTP 요청의 구조:

GET /api/users HTTP/1.1       ← 메서드(GET), 경로(/api/users), 버전(HTTP/1.1)
Host: example.com             ← 헤더 (요청하는 도메인)
User-Agent: Mozilla/5.0       ← 헤더 (클라이언트 정보)
Accept: application/json      ← 헤더 (받을 수 있는 형식)

(본문 — GET은 보통 없음, POST는 데이터가 여기)

HTTP 응답의 구조:

HTTP/1.1 200 OK               ← 버전, 상태 코드(200), 메시지(OK)
Content-Type: application/json ← 헤더 (응답 형식)
Content-Length: 142            ← 헤더 (본문 길이)

{"users": [...]}               ← 본문 (실제 데이터)

HTTP 메서드 — 요청의 종류를 나타낸다. GET(조회), POST(생성), PUT(전체 수정), PATCH(부분 수정), DELETE(삭제). REST API 설계에서 각 메서드의 의미가 중요하다.

HTTP 상태 코드 — 응답의 결과를 나타낸다. 세 자리 숫자.

코드	의미	전형 사례
200	성공	200 OK
301/302	리다이렉트	301 Moved Permanently
400	클라이언트 오류	400 Bad Request
401	인증 필요	401 Unauthorized
403	권한 없음	403 Forbidden
404	없음	404 Not Found
429	요청 과다	429 Too Many Requests
500	서버 오류	500 Internal Server Error
502/503/504	게이트웨이 오류	503 Service Unavailable

HTTP/1.1 → HTTP/2 → HTTP/3 — 진화

HTTP/1.1 (1997, RFC 9112)

인터넷의 오랜 표준. keep-alive로 한 TCP 연결에서 여러 요청을 보낼 수 있지만 — 순차적이다. 앞의 요청 응답이 와야 다음 요청을 보낼 수 있다(HEAD-of-LINE 블로킹). 이미지가 많은 웹 페이지에서 — 한 이미지가 느리면 전체가 느려진다. 브라우저는 이를 우회하기 위해 한 도메인에 TCP 연결 6개를 동시에 여는다(연결당 순차 처리). 하지만 연결 6개는 각각 TCP 3-way 핸드셰이크와 TLS 핸드셰이크 비용을 갖는다.

HTTP/2 (2015, RFC 9113)

Google의 SPDY 프로토콜이 기반. 한 TCP 연결에서 여러 요청을 동시에 처리한다(멀티플렉싱, multiplexing). "스트림(stream)"이라는 논리적 채널로 — 한 연결 안에서 여러 요청·응답이 병렬로 오간다. HEAD-of-LINE 블로킹이 해결된다. 또한 — 헤더 압축(HPACK) 으로 헤더 크기를 줄이고, 서버 푸시로 클라이언트가 요청하지 않은 리소스를 서버가 미리 보낼 수 있다.

단점 — HTTP/2는 TCP 위에서 동작하므로, TCP 수준의 패킷 손실이 한 스트림에만 영향을 줘야 하는데 — 실제로는 모든 스트림이 블록된다(TCP 수준 HEAD-of-LINE 블로킹). 이게 HTTP/3가 만들어진 원인이다.

HTTP/3 (2022, RFC 9114)

QUIC(Quick UDP Internet Connections, RFC 9000) 위에서 동작. QUIC은 UDP를 쓰면서 TCP의 신뢰성을 앱 수준에서 직접 구현한 프로토콜. Google이 2012년에 개발, IETF가 표준화(RFC 9000, 2021).

HTTP/3의 핵심 이점:

• TCP HEAD-of-LINE 블로킹 없음 — QUIC은 스트림별로 독립적인 신뢰성을 보장. 한 스트림에서 패킷 손실이 나도 다른 스트림은 안 멈춘다.
• 연결 설정이 빠름 — QUIC은 TLS 1.3을 통합해서, 연결 설정 + 암호화 협상을 1-RTT(한 번 왕복)에 끝낸다. HTTP/2 over TCP over TLS는 2 ~ 3-RTT가 필요했다. 0-RTT 재개 모드로 — 이미 연결한 적이 있는 서버면 첫 패킷에 데이터를 실어 보낸다.
• 연결 마이그레이션 — IP가 바뀌어도(예: Wi-Fi → 모바일 데이터) 연결이 유지된다. TCP는 IP+포트로 연결을 식별하므로 IP가 바뀌면 끊기지만, QUIC은 연결 ID로 식별해서 안 끊긴다.

특성	HTTP/1.1	HTTP/2	HTTP/3
전송	TCP	TCP	QUIC (UDP)
멀티플렉싱	없음 (순차)	있음 (스트림)	있음 (독립 스트림)
HEAD-of-LINE 블로킹	있음 (HTTP)	있음 (TCP)	없음
연결 설정	1-RTT (TCP)	2-3 RTT (TCP+TLS)	1-RTT (QUIC+TLS 통합)
헤더 압축	없음	HPACK	QPACK
연결 마이그레이션	불가	불가	가능

2026년 기준, 주요 웹사이트(Google·Facebook·Cloudflare)의 약 30%가 HTTP/3를 지원한다.

TLS — 전송 계층 보안

TLS(Transport Layer Security) 는 — TCP 위에서 동작하며, 데이터를 암호화(기밀성), 변조 방지(무결성), 상대방 확인(인증)을 제공한다. HTTPS는 "HTTP over TLS"다 — HTTP 데이터를 TLS로 암호화해서 보낸다. TLS의 현재 버전은 TLS 1.3(RFC 8446, 2018) 이다.

TLS 핸드셰이크 — 암호화 연결 설정

TLS 핸드셰이크는 — 클라이언트와 서버가 "어떤 암호 알고리즘으로, 어떤 키로 암호화할까?"를 협상하는 과정이다. TLS 1.3의 핸드셰이크를 간단히 보자.

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버

    C->>S: ClientHello (지원 암호 목록, 키 공유)
    Note over S: 서버가 암호 알고리즘 선택
    S->>C: ServerHello (선택된 암호, 키 공유)
    S->>C: 인증서 (서버 신원 증명)
    S->>C: 인증 완료 (서버 핸드셰이크 끝)
    Note over C: 인증서 검증 (CA 체인)
    C->>S: Finished (클라이언트 핸드셰이크 끝)
    Note over C,S: 암호화된 데이터 통신 시작

핵심 단계:

1. ClientHello — 클라이언트가 "나는 이런 암호 알고리즘들을 지원해"라고 알린다. 동시에 키 교환용 데이터(ECDHE 공개값)를 보낸다.
2. ServerHello — 서버가 "이 알고리즘으로 하자"라고 선택한다. 서버의 키 교환 데이터도 보낸다.
3. 인증서 — 서버가 자기 인증서를 보낸다. 인증서에는 서버의 공개키와 "이 서버는 example.com이 맞다"는 CA의 서명이 있다.
4. 키 파생 — 양쪽의 키 교환 데이터로 대칭키를 계산한다(ECDHE). 이후 모든 데이터는 이 대칭키로 암호화된다.
5. Finished — 양쪽이 "핸드셰이크 끝, 이제 암호화 통신하자"고 확인.

비대칭 암호(공개키)로 대칭키를 교환하고, 대칭키로 데이터를 암호화하는 하이브리드 방식. 비대칭 암호(RSA·ECDHE)는 느리지만 키 교환에 적합하고, 대칭 암호(AES·ChaCha20)는 빠르지만 키를 안전하게 교환해야 한다. 각자의 장점을 조합한 것이다.

인증서와 CA — 서버가 "진짜"임을 증명

TLS 인증서(certificate)는 — "이 서버는 example.com이 맞다"는 디지털 증명서다. CA(Certificate Authority, 인증 기관) 라는 신뢰받는 제3자가 서명한다. 브라우저는 CA 목록을 자체적으로 갖고 있어서(root CA store), 그 CA가 서명한 인증서를 신뢰한다.

인증서의 핵심 필드:

• 대상(Common Name, CN / Subject Alternative Name, SAN) — example.com 같은 도메인. 인증서가 어느 도메인에 유효한지.
• 발급자(Issuer) — 누가 발급했는지(Let's Encrypt·DigiCert·GlobalSign 등).
• 유효 기간(Validity) — 보통 90일(Let's Encrypt) ~ 1년(상용 CA).
• 공개키(Public Key) — 서버의 공개키. 키 교환에 사용.
• CA 서명(Signature) — CA가 이 인증서가 진짜라고 서명한 것.

SNI(Server Name Indication) — 한 서버(한 IP)에 여러 도메인(예: a.com과 b.com)이 있을 때, 클라이언트가 "나는 a.com에 접속하고 싶어"라고 핸드셰이크 초기에 알리는 기능. 서버가 그에 맞는 인증서를 보낼 수 있다. SNI가 없으면 — 한 IP에 하나의 인증서만 쓸 수 있다. SNI는 TLS 1.2부터 표준이고, TLS 1.3에서는 ESNI(Encrypted SNI) 로 SNI 자체를 암호화하는 기능이 추가되고 있다(아직 표준화 진행 중).

Let's Encrypt — 무료 인증서의 대중화

2015년 Let's Encrypt가 등장하기 전에는 — TLS 인증서가 연간 수만 원 ~ 수십만 원이었다. 소규모 웹사이트에서 HTTPS를 쓰기 부담스러웠다. Let's Encrypt는 무료 인증서를 자동화 프로토콜(ACME, RFC 8555)으로 발급한다. certbot 도구로 — 도메인 소유권을 확인하고 인증서를 자동 발급·갱신한다. 2026년 Let's Encrypt는 전 세계 HTTPS 인증서의 약 50%를 발급한다.

TLS 세션 재개 — 핸드셰이크를 건너뛰는 기술

매번 TLS 핸드셰이크를 하면 — 1-RTT(TLS 1.3) 또는 2-RTT(TLS 1.2)의 지연이 발생한다. 이미 연결한 적이 있는 서버에 다시 연결할 때 — 이 지연을 줄이는 기술이 세션 재개(session resumption) 이다.

세션 티켓(session ticket) — 첫 연결 시 서버가 암호화된 "티켓"을 클라이언트에게 준다. 다음 연결 때 클라이언트가 이 티켓을 제시하면 — 서버가 티켓을 복호화해 이전 세션 키를 복원하고, 핸드셰이크를 생략(또는 축소)한다. TLS 1.2에서는 이걸로 1-RTT를 절약하고, TLS 1.3에서는 0-RTT(Zero Round Trip Time) 모드를 지원한다 — 첫 패킷에 요청 데이터를 실어 보낼 수 있어, 사실상 지연이 0이다.

0-RTT의 트레이드오프 — 빠르지만 재생 공격(replay attack) 에 취약하다. 공격자가 0-RTT 요청을 가로채서 나중에 재전송하면 — 서버가 같은 요청을 두 번 처리할 수 있다(예: 결제가 두 번 됨). 그래서 0-RTT는 멱등성(idempotency) 이 보장되는 요청(GET)에만 쓰는 것이 안전하다. POST(결제·주문)에는 0-RTT를 쓰면 안 된다.

HSTS — 브라우저에게 "항상 HTTPS로 접속하라"고 알리기

http://example.com으로 접속하면 — 서버가 301 Redirect로 https://example.com으로 보낸다. 하지만 — 첫 HTTP 요청이 가는 순간 공격자가 가로챌 수 있다(중간자 공격, MITM). HSTS(HTTP Strict Transport Security, RFC 6797) 는 — 브라우저에게 "이 사이트는 항상 HTTPS로만 접속해"라고 미리 알리는 HTTP 헤더다.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000 — 1년 동안 HTTPS만 사용 (초 단위)
• includeSubDomains — 하위 도메인도 포함
• preload — 브라우저의 내장 HSTS 목록에 등록 (최초 접속조차 HTTPS로)

HSTS를 쓰면 — 브라우저가 http://를 https://로 자동 변환해서, 공격자가 HTTP를 가로챌 기회를 원천 차단한다. 모든 HTTPS 사이트에서 HSTS를 설정하는 것이 권장된다.

CORS — 다른 출처의 요청을 허용할까

CORS(Cross-Origin Resource Sharing) 는 — 브라우저가 "다른 웹사이트의 리소스에 접근해도 되는가?"를 결정하는 보안 메커니즘이다. https://a.com의 JavaScript가 https://b.com/api에 요청을 보내려면 — 브라우저가 이를 차단한다(동일 출처 정책, Same-Origin Policy). b.com이 CORS 헤더로 "a.com에서 오는 요청은 허용한다"고 명시해야 차단이 풀린다.

# b.com의 응답 헤더
Access-Control-Allow-Origin: https://a.com

CORS는 HTTP의 보안 기능이지 — TLS의 기능이 아니다. HTTPS 위에서 동작하며, 브라우저가 검사한다. API 설계에서 CORS 설정이 빠지면 — 프론트엔드에서 API 호출이 실패하는 흔한 문제가 생긴다.

인증서 수명 주기 — 발급에서 갱신까지

TLS 인증서는 영원하지 않다. 유효 기간이 지나면 만료되고 — 브라우저가 "안전하지 않음" 경고를 띄운다. 인증서 만료는 — 인프라 장애의 흔한 원인이다. 2017년 Equifax는 — 인증서 만료를 몰라서 보안 모니터링이 10개월간 중단됐고, 대규모 개인정보 유출이 일어났다.

인증서 수명 주기:

1. 발급(issue) — CA에 CSR(Certificate Signing Request)을 보내 인증서 발급. ACME(certbot)로 자동화.
2. 설치(install) — 서버(또는 로드 밸런서)에 인증서와 개인키 설치.
3. 갱신(renew) — 만료 전(보통 30일 전)에 새 인증서 발급·교체. certbot으로 자동화.
4. 폐기(revoke) — 인증서가 유출됐을 때 CA에 폐기 요청. 브라우저가 폐기 목록(CRL·OCSP)을 확인.

자동화가 핵심 — 수동으로 인증서를 관리하면 — 반드시 만료 사고가 일어난다. certbot의 --deploy-hook으로 — 갱신 후 nginx 자동 재시작. Kubernetes에서는 cert-operator가 인증서를 자동 관리.

실습 — HTTP와 TLS 직접 확인

1. HTTP 요청/응답 보기

# curl로 HTTP 요청 (헤더 포함)
curl -v https://example.com 2>&1 | head -30

확인할 것: >로 시작하는 행(요청 헤더), <로 시작하는 행(응답 헤더). 상태 코드(200 OK), Content-Type, Content-Length.

2. TLS 핸드셰이크와 인증서 확인

# TLS 연결 및 인증서 상세
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | head -30
# 인증서만 상세히
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | openssl x509 -text -noout | head -20

확인할 것: Protocol: TLSv1.3(사용된 TLS 버전), Cipher: TLS_AES_256_GCM_SHA384(사용된 암호 스위트). 인증서의 Subject(CN=example.com), Issuer(Let's Encrypt), Validity(유효 기간).

# 예상 출력 (openssl s_client 요약)
  Protocol  : TLSv1.3
  Cipher    : TLS_AES_256_GCM_SHA384
  Server certificate:
    subject=C = US, ST = California, O = Internet Corporation, CN = example.com
    issuer= C = US, O = Let's Encrypt, CN = R3

3. HTTP/2 또는 HTTP/3 사용 확인

# HTTP/2 지원 확인
curl -I --http2 https://example.com 2>&1 | grep -i 'HTTP/'
# HTTP/3 지원 확인 (curl 7.66+ 필요)
curl -I --http3 https://cloudflare.com 2>&1 | grep -i 'HTTP/' || echo "HTTP/3 미지원"

확인할 것: HTTP/2 200이면 HTTP/2 사용. HTTP/3 200이면 HTTP/3 사용. 클라우드플레어·구글은 HTTP/3를 지원한다.

4. TLS 버전 확인 (서버 관점)

# 시스템의 TLS 설정 확인
openssl version
# 지원하는 TLS 버전
openssl ciphers -v | awk '{print $2}' | sort -u

확인할 것: OpenSSL 3.0+가 TLS 1.3을 지원. TLSv1.3이 보이면 지원하는 것.

미검증: openssl s_client는 대부분의 Linux에서 사용 가능. curl --http3는 별도 빌드 필요(HTTP/3 지원 버전). 클라우드 VM에서는 방화벽이 443을 차단할 수 있음.

HTTPS는 이제 선택이 아닌 필수다

HTTP와 TLS를 이해하면 — "왜 자물쇠가 잠겨 있어야 안전한가?"(암호화), "왜 인증서가 만료되면 사이트가 안 열리나?"(인증서 유효성), "왜 HTTP/3가 빠른가?"(QUIC의 1-RTT 연결), "왜 한 IP에 여러 도메인이 가능한가?"(SNI)에 답할 수 있다. 2026년 — HTTPS는 선택이 아니라 기본이다. Chrome·Firefox가 HTTP 사이트에 "안전하지 않음" 경고를 띄운다. Let's Encrypt로 인증서가 무료가 됐고, HTTP/3로 속도까지 빨라졌다.

다음 글은 이 영역의 마지막 — 로드 밸런싱. 여러 서버에 트래픽을 분산하는 기술. L4(포트 기반)와 L7(HTTP 경로 기반) 로드 밸런서의 차이, 분산 알고리즘, 헬스체크가 "트래픽을 어디로 보낼까?"를 어떻게 결정하는지를 본다.

인증서 자동화는 — 현대 인프라의 필수다. 수동으로 인증서를 관리하면 — 반드시 만료 사고가 일어난다. certbot의 자동 갱신(certbot renew --deploy-hook "systemctl restart nginx")이나 — Kubernetes의 cert-manager로 — 인증서 수명 주기를 코드(IaC)로 관리하는 것이 정답이다.
HTTP와 TLS는 — 웹의 언어이자 보안의 기반이다. HTTP/1.1에서 HTTP/3까지의 진화는 — 속도·효율성·보안의 균형을 찾는 과정이었다. HTTPS는 이제 선택이 아니라 필수이며, Let's Encrypt와 certbot으로 — 인증서 관리까지 자동화하는 것이 현대의 표준이다.

HTTP의 진화 — 1.1(순차) → 2(멀티플렉스) → 3(QUIC) — 은 속도와 효율성을 추구한 과정이다. TLS는 그 위에서 기밀성·무결성·인증을 제공한다. HTTPS는 2026년 기본이고, Let's Encrypt로 인증서가 무료가 됐다. 핵심 — HTTP는 규칙(요청·응답), TLS는 보안(암호화·인증), 두 층이 합쳐져 현대 웹을 만든다.

HTTP/1.1에서 HTTP/3까지의 진화는 속도와 효율성을, TLS는 보안을 담당한다. HTTPS는 2026년 기본이고, Let's Encrypt로 인증서가 무료가 됐다. 다음 글은 이 영역의 마지막 — 로드 밸런싱. 여러 서버에 트래픽을 분산하는 기술이다.HTTP와 TLS는 — 현대 웹의 두 기둥이다. 이해 없이는 안전한 서비스를 만들 수 없다.HTTP와 TLS는 현대 웹의 두 기둥이다. HTTP는 규칙(요청·응답)을, TLS는 보안(암호화·인증)을 담당한다. HTTP/3와 TLS 1.3이 2026년의 최신 표준이다.
HTTP와 TLS는 현대 웹의 두 기둥이다.
HTTP/3와 TLS 1.3이 2026년의 최신 표준이며,
Let's Encrypt로 인증서 관리까지 자동화된다.

---

참고

• RFC 9110~9114, Fielding, R. et al. "HTTP Semantics", "HTTP Caching", "HTTP/1.1", "HTTP/2", "HTTP/3", 2022 — HTTP 표준. 접근 2026-07-21
• RFC 8446, Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.3", 2018 — TLS 1.3. 접근 2026-07-21
• RFC 9000, Iyengar, J., Thomson, M. "QUIC: A UDP-Based Multiplexed and Secure Transport", 2021 — QUIC. 접근 2026-07-21
• RFC 8555, Barnes, R. et al. "Automatic Certificate Management Environment (ACME)", 2019 — Let's Encrypt 자동화. 접근 2026-07-21
• Kurose, J. F., Ross, K. W. 8th ed, 2021, Ch.2·Ch.8 — HTTP·TLS. 접근 2026-07-21
• Stevens, W. R., Fall, K. <TCP/IP Illustrated, Volume 1> 2nd ed, 2011 — HTTP·SSL/TLS. 접근 2026-07-21
• Grigorik, I. , O'Reilly, 2013 — HTTP/2·QUIC. 접근 2026-07-21