HTTP는 클라이언트와 서버 간 통신의 프로토콜로, 백엔드 개발자는 이 프로토콜을 이해해야 효율적인 API와 서비스를 개발할 수 있다. 최근 많이 사용하는 RESTful API를 개발할 때도, HTTP는 필수적인 개념이다. 개발자는 각 상황에 적합한 HTTP 메서드(GET, POST, PUT, DELETE 등)를 선택하고, 적절한 상태 코드를 반환함으로써 일관되고 직관적인 API를 개발할 수 있어야 한다. 하지만 HTTP는 데이터가 평문으로 전송되기 때문에 보안이 취약하다는 문제점이 있다. 이를 해결하기 위해 SSL/TLS 암호화를 더한 HTTPS가 등장했다. 따라서, 백엔드 개발자는 HTTP와 HTTPS에 대해 철저히 이해하고 있어야 한다.
HTTP에 관하여
HTTP(Hyper Text Transfer Protocol)은 웹에서 클라이언트와 서버 간 데이터를 주고받기 위한 애플리케이션 계층의 통신 프로토콜이다. HTTP 메세지는 텍스트 기반 형식으로 다음과 같이 생겼다.
HTTP의 특징
- 비연결성
서버는 클라이언트의 요청에 응답한 후 연결을 유지하지 않는다. 이는 서버 리소스를 효율적으로 사용할 수 있게 하지만, 매 요청마다 새로운 TCP 연결해야 하므로 오버헤드가 크다. (HTTP/1.1은 Keep-Alive 헤더를 통해 여러 요청/응답을 하나의 TCP 연결로 처리한다. 클라이언트는 응답을 기다리지 않고 여러 요청을 연속적으로 전송하고, 서버는 요청 순서대로 응답을 처리하여 전송한다. 큰 응답이 작은 응답을 차단하는 블로킹 문제가 있어 대부분의 브라우저에서 비활성화된다.) - 무상태(Stateless)
각 요청은 독립적이며, 서버는 이전 요청의 상태를 저장하지 않는다. 이러한 특징 때문에 세션 관리나 사용자 인증을 위한 쿠키, 세션, 토큰 등이 필요하다. - 요청-응답 구조
클라이언트가 요청을 보내면 서버는 응답을 반환하는 통신 방식이다.
HTTP 통신 기본 흐름
- 클라이언트가 서버와 TCP 연결
- 클라이언트가 HTTP 요청을 서버로 전송
- 서버가 요청을 처리
- 서버가 HTTP 응답을 클라이언트에게 전송
- HTTP 버전에 따라 연결을 종료하거나 유지
HTTP 메세지 구조
HTTP 요청 메세지
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: sessionId=abc123; userId=johndoe
Cache-Control: max-age=0
- `GET /index.html HTTP/1.1`
- HTTP 메서드: GET
- 요청 경로: /index.html
- HTTP 버전: HTTP/1.1
- `Host: www.example.com` - 요청하는 호스트 서버 정보
- `User-Agent` - 클라이언트 정보
- `Accept` - 클라이언트가 처리할 수 있는 컨텐츠 타입
- `Accept-Language` - 선호하는 언어
- `Accept-Encoding` - 지원하는 압축 방식
- `Connection: keep-alive` - 연결 유지 요청
- `Cookie` - 서버에 전송되는 쿠키 정보 (세션 ID와 사용자 ID)
- `Cache-Control: max-age=0` - 캐시 저장하지 않고 매번 서버에 확인
HTTP 응답 메세지
HTTP/1.1 200 OK
Date: Mon, 23 May 2022 22:38:34 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2022 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close
- `HTTP/1.1 200 OK`
- HTTP 버전: HTTP/1.1
- 상태 코드: 200
- 상태 메세지: OK
- `Date: Mon, 23 May 2022 22:38:34 GMT` - 응답이 생성된 날짜와 시간
- `Server: Apache/2.4.41 (Ubuntu)` - 서버 소프트웨어 정보
- `Content-Type: text/html; charset=UTF-8` - 응답 본문의 미디어 타입과 문자 인코딩
- `Content-Length: 138` - 응답 본문의 길이
- `Last-Modified: Wed, 08 Jan 2022 23:11:55 GMT` - 리소스가 마지막으로 수정된 시간
- `ETag: "3f80f-1b6-3e1cb03b"` - 리소스의 특정 버전을 식별하는 태그(캐싱에 사용)
- `Accept-Ranges: bytes` - 서버가 범위 요청을 지원함을 나타냄
- `Connection: close` - 응답 후 연결을 닫음
HTTP 버전별 특징
- HTTP/1.0
- 단순한 요청-응답 모델
- 연결당 하나의 요청만 처리 (비연결성)
- HTTP/1.1
- Keep-Alive 연결을 통해 여러 요청-응답을 하나의 TCP에서 처리 ➡️ 파이프라이닝
- HOL 블로킹 문제 발생
- HTTP/2
- 텍스트 기반 프로토콜에서 바이너리 프로토콜로 변경 ➡️ 효율적인 파싱과 처리 가능
- 멀티플렉싱을 지원 ➡️ 하나의 TCP 연결 내에서 다수의 요청과 응답을 동시에 처리 가능, 각 요청과 응답은 스트림이라는 독립적인 양방향 시퀀스로 식별해, 스트림 ID를 사용하여 여러 메세지가 뒤섞여도 올바르게 재조합이 가능 ➡️ HOL 블로킹 문제 해결
- HTTP/3
- UDP 기반 QUIC 프로토콜 사용
- 첫 연결에서 통합된 핸드셰이크를 사용해 1-RTT만 소요
HTTP 메서드
HTTP 메서드는 클라이언트가 서버에게 요청의 목적과 종류를 알려주는 방법이다.
- GET: 리소스 조회
- 서버로부터 데이터를 요청할 때 사용한다.
- URL에 데이터가 노출되므로 보안이 취약하다.
- 요청 본문을 가질 수 없다.
- POST: 리소스 생성 및 데이터 제출
- 서버에 데이터를 전송하여 새 리소스를 생성할 때 사용한다.
- 요청 본문에 데이터를 포함한다.
- 멱등성이 보장되지 않는다.
- PUT: 리소스 전체 수정
- 리소스를 완전히 대체할 때 사용한다.
- 멱등성이 보장된다. (같은 요청을 여러 번 보내도 결과가 동일하다.)
- PATCH: 리소스 부분 수정
- 리소스의 일부만 수정할 때 사용한다.
- 멱등성이 보장되지 않을 수 있다.
- DELETE: 리소스 삭제
- 지정된 리소스를 삭제할 때 사용한다.
- 멱등성이 보장된다.
HTTP의 문제점
HTTP는 데이터를 평문으로 전송하기 때문에 네트워크 경로 상의 어느 지점에서든 패킷을 캡쳐하면 그 내용을 그대로 읽을 수 있다. HTTP 통신은 여러 네트워크 장비를 통과하며, 공격자가 쉽게 패킷을 가로챌 수 있는데 상대방의 신원을 확인하는 인증이 없어 공격자가 중간에 통신을 가로채도 클라이언트나 서버가 이를 감지할 수 없다.
HTTPS에 관하여
HTTPS = HTTP + TLS(SSL) 이다. 위의 HTTP의 문제점을 해결하기 위해 암호화를 추가했다. HTTPS는 데이터 암호화를 통해 패킷이 캡쳐되어도 제3자는 내용을 읽을 수 없다. 또, MAC(Message Authentication Code) 또는 HMAC(Hash-based Message Authentication Code)를 통해 데이터 무결성을 보장하고, 디지털 인증서와 PKI(Public Key Infrastructure)를 통해 클라이언트가 통신하고 있는 서버가 신뢰할 수 있는 서버인지 확인할 수 있는 인증을 제공한다.
💡SSL와 TLS란?
SSL과 TLS는 모두 보안 프로토콜이며 사실상 같은 프로토콜이다. SSL이 먼저 개발되었으며, TLS은 SSL의 후속 버전이다. 현재는 보안상의 이유로 SSL은 완전히 폐기되고 TLS1.2, TLS1.3 프로토콜만 사용한다. SSL이 일반적으로 사용되지만 더 정확한 표현은 TLS이다.
HTTPS의 암호화
HTTPS는 비대칭 암호키와 대칭 암호키를 사용한다.
비대칭 암호키(공개키 암호화)
비대칭 암호키는 공개키와 개인키를 사용하는 방식이다. 공개키는 누구나 접근 가능하며, 이 키로 암호화된 데이터는 개인키로만 복호화할 수 있다. 개인키는 소유자만 접근 가능하며, 이 키로 암호화된 데이터는 공개키로만 복호화할 수 있다.
비대칭 암호키는 키 분배 문제를 해결하지만, 적은 양만 암호화가 가능하며 키의 길이가 길어 속도가 느리다.
대칭 암호키
대칭 암호키는 암호화와 복호화에 동일한 키를 사용하는 방식이다. 같은 키를 사용하기 때문에 키 분배에 문제가 발생한다. 하지만 많은 의 암호화가 가능하고 키가 짧아 속도가 빠르다.
CA와 디지털 인증서
CA는 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제 3자 기관이다. 기존 HTTP는 상대방의 신원을 확인하는 인증이 없어 중간자 공격에 취약했다. CA가 발급한 디지털 인증서를 서버가 클라이언트에 전송하면 클라이언트는 디지털 인증서를 검증해 서버의 신원을 확인할 수 있다. 클라이언트는 서버로 받은 디지털 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인하고 인증서에 포함된 CA의 디지털 서명을 CA의 공개키로 검증한다. 인증서에 명시된 도메인 이름이 실제로 접속한 도메인과 일치하는지 확인한 후 인증서의 유효기간이 만료되었는지 확인해 서버가 진짜임을 신뢰하고 통신을 진행한다.
💡 CA의 신뢰성은 어떻게 보장될까?
CA는 계증척 구조로 설계되어 있다.
1. 루트 CA: 신뢰의 최상위 기관으로, 자체 서명된 인증서를 가지며 오프라인 환경에서 관리된다.
2. 중간 CA: 루트 CA에 의해 인증되어 실제 인증서 발급 업무를 수행한다.
3. 최종 인증서: 웹 사이트나 서비스에 발급되는 인증서이다.
이 구조를 통해 루트 CA의 노출을 최소화하고, 문제가 발생하면 피해 범위를 제한할 수 있다.
TLS/SSL 핸드셰이크 과정

HTTPS가 연결될 때 클라이언트와 서버는 TLS 핸드셰이크라는 과정을 거친다.
- Client Hello
클라이언트가 서버에게 보내는 첫 메세지이다. 클라이언트는 다음 정보들을 포함해 보낸다:- 클라이언트가 지원하는 가장 높은 TLS(SSL) 버전
- 클라이언트의 무작위 데이터(나중에 세션 키 생성에 사용)
- 세션 ID
- 클라이언트가 지원하는 암호화 알고리즘 목록
- Server Hello
Client Hello에 대한 서버의 응답 메세지이다. 서버는 다음 정보들을 포함해 보낸다:- 서버가 지원하는 가장 높은 버전의 TLS(클라이언트가 제안한 버전 중)
- 서버의 무작위 데이터(나중에 세션 키 생성에 사용)
- 세션 ID
- 클라이언트가 제공한 암호화 알고리즘 중 선택한 암호화 알고리즘
- 인증서 전송
서버가 자신의 신원을 증명하기 위해 디지털 인증서를 전송한다. 서버는 다음 정보들을 포함해 보낸다:- 서버의 공개키
- 서버 도메인 이름
- 인증서 발급자 정보
- 유효 기간
- 디지털 서명(CA의 개인키로 서명)
- 키 교환(서버 키 교환)
선택한 암호화 알고리즘에 따라 서버가 추가 키 파라미터를 전송한다. - 서버 핸드셰이크 종료
- 클라이언트 키 교환
클라이언트가 pre-master secret을 생성하고 서버에 전송한다. - pre-master secret에서 master secret 생성
클라이언트와 서버 양쪽에서 독립적인 master secret을 생성한다. (이 때, 1번과 2번에서 서로 주고 받은 무작위 데이터를 사용한다.) - master secret에서 실제 암호화와 무결성 보호에 사용할 여러 키들을 추출
'Network' 카테고리의 다른 글
| [Network] HTTPS는 정말 안전할까? : TLS Handshake의 원리와 PFS (1) | 2025.12.05 |
|---|---|
| [Network] 소켓 통신에서 멀티스레드가 필요한 이유 (0) | 2025.06.26 |
| [Network] TCP 3-way handshake와 4-way handshake (0) | 2025.03.21 |