오늘도 기본적인 주제로 블로그를 써보려고 합니다. 웹 개발자라면 하루에도 수십 번 만나는 게 바로 HTTP입니다. 그런데 정작 이 HTTP가 어떤 원리로 작동하는지, 통신 과정은 어떻게 흐르고, 왜 다양한 메서드들이 생겨났는지는 잘 모르고 넘어가는 경우가 많죠. 이번 글에서는 HTTP 통신의 기본 개념부터, 통신 흐름, 메서드 종류와 탄생 배경, 그리고 암호화와 보안까지 한 번에 정리해보겠습니다.
1. HTTP란 무엇인가?
HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트(주로 브라우저)와 서버 간에 데이터를 주고받기 위한 약속입니다. 모든 통신은 요청(Request)과 응답(Response)이라는 구조로 이루어지며, 주로 텍스트 기반의 프로토콜입니다.
2. HTTP 통신 과정: 흐름을 따라가 보자
HTTP와 HTTPS는 모두 클라이언트와 서버 간 통신을 위한 프로토콜이지만, 보안 처리 방식에서 큰 차이를 보입니다. 이 두 방식의 실제 통신 흐름을 나란히 비교해볼게요.
▶ HTTP 통신 방식 (비암호화)
- 사용자가 브라우저에
http://example.com입력 - 브라우저가 DNS를 통해 IP 주소 조회
- TCP 3-way handshake 수행
- 클라이언트가 서버로 HTTP 요청 전송 (평문)
- 서버가 HTTP 응답 반환 (역시 평문)
- 브라우저가 HTML 등 리소스를 해석하여 렌더링
이 과정은 전혀 암호화되지 않아 중간자 공격(MITM), 패킷 스니핑 등에 매우 취약합니다.
▶ HTTPS 통신 방식 (암호화 + 인증)
- 사용자가 브라우저에
https://example.com입력 - 브라우저가 DNS를 통해 IP 주소 조회
- TCP 3-way handshake 수행
- TLS 핸드셰이크 시작
- 서버가 공개키와 인증서(Certificate)를 브라우저에 전달
- 브라우저가 인증서 유효성 검증
- 세션 키 생성 후 서버에 암호화하여 전달
- 세션 키 공유 완료 → 이제부터 HTTP 요청/응답이 모두 암호화되어 전달됨
- 브라우저가 안전하게 콘텐츠를 받아 렌더링
HTTPS는 단순히 보안을 "덧씌운" 것이 아니라, 데이터 전송 전 신뢰성과 기밀성 확보를 위한 절차를 먼저 수행한 후 통신하는 방식입니다.
3. HTTP vs HTTPS: 무엇이 다를까?
| 항목 | HTTP | HTTPS |
|---|---|---|
| 프로토콜 | HyperText Transfer Protocol | HyperText Transfer Protocol Secure |
| 보안성 | 암호화되지 않음 (평문 통신) | SSL/TLS를 통한 암호화 적용 |
| 포트 | 기본 80번 | 기본 443번 |
| 사용 목적 | 내부 테스트, 비중요한 콘텐츠 | 사용자 데이터, 로그인 정보, 결제 등 민감한 정보 전송 |
| 인증서 | 없음 | 공개키 기반 인증서 필요 (CA 발급) |
통신 방식의 주요 차이점
- HTTP는 클라이언트가 요청을 보내면 서버가 응답을 주는 단순한 구조입니다. 하지만 요청/응답 내용이 암호화되지 않아, 중간자 공격(Man-in-the-Middle)에 취약합니다.
- HTTPS는 먼저 SSL/TLS 핸드셰이크를 통해 양측이 안전하게 통신할 수 있는 세션 키를 공유한 뒤, 이 키로 HTTP 메시지를 암호화하여 전송합니다.
즉, HTTPS는 HTTP의 통신 방식 위에 "보안 계층을 추가한 것"이라고 이해하면 됩니다.
4. HTTP 메서드는 왜 생겼을까?
처음 웹은 정적인 HTML만 제공했습니다. 그러나 웹이 발전하면서, 데이터 생성/수정/삭제와 같은 다양한 작업을 해야 했고, 이를 표현하기 위해 HTTP 메서드가 도입되었죠.
주요 HTTP 메서드와 그 목적
GET: 리소스를 조회할 때 사용 (ex: 게시물 목록 보기)POST: 서버에 데이터를 제출할 때 (ex: 회원가입 폼 제출)PUT: 전체 리소스를 수정할 때 (ex: 사용자 정보 전체 수정)PATCH: 리소스의 일부분만 수정할 때 (ex: 이메일만 변경)DELETE: 리소스를 삭제할 때 (ex: 게시물 삭제)HEAD: 응답 본문 없이 헤더만 요청 (주로 상태 확인용)OPTIONS: 지원되는 메서드 조회 (CORS 사전 요청에 사용됨)
이렇게 다양한 메서드를 통해 의도를 명확히 전달하고, 서버와 클라이언트의 역할을 분명하게 구분할 수 있게 되었습니다.
5. HTTPS와 암호화의 필요성
HTTP는 기본적으로 암호화되지 않은 평문 통신입니다. 따라서 제3자가 네트워크를 감청하면, 로그인 정보, 쿠키, 요청 내용 등이 그대로 노출될 수 있죠.
이를 해결하기 위해 **HTTPS(HyperText Transfer Protocol Secure)**가 등장했습니다. HTTPS는 SSL/TLS 계층을 통해 데이터를 암호화합니다.
HTTPS의 흐름
- 클라이언트가 서버에게 접속 요청 (TLS 핸드셰이크 시작)
- 서버가 공개키와 인증서 전달
- 클라이언트가 공개키로 세션키를 암호화해 전송
- 서버는 개인키로 복호화하여 같은 세션키 공유
- 이후 모든 HTTP 요청/응답은 세션키로 암호화됨
HTTPS의 효과
- 기밀성(Confidentiality): 데이터를 제3자가 볼 수 없음
- 무결성(Integrity): 중간에서 데이터가 변조되지 않음
- 인증(Authentication): 서버가 진짜인지 확인 가능 (CA 인증서 기반)
6. CORS란 무엇이고 왜 오류가 발생할까?
**CORS(Cross-Origin Resource Sharing)**는 웹 브라우저의 보안 정책인 **동일 출처 정책(Same-Origin Policy)**을 우회하기 위한 메커니즘입니다.
동일 출처 정책이란?
- 기본적으로 브라우저는 스크립트가 **다른 출처(origin)**에 요청을 보내는 것을 제한합니다.
- 출처는
프로토콜 + 도메인 + 포트로 구성되며, 이 중 하나라도 다르면 다른 출처로 간주됩니다.
예:
https://api.example.com (다름)
http://api.example.com (다름)
https://example.com:3000 (다름)CORS 오류는 언제 발생할까?
- 예를 들어,
localhost:3000에서 동작하는 프론트엔드가api.example.com에 HTTP 요청을 보낼 경우, 브라우저는 먼저 **CORS preflight 요청(OPTIONS)**을 보냅니다. - 서버가 적절한 CORS 응답 헤더(
Access-Control-Allow-Origin,Access-Control-Allow-Methods등)를 반환하지 않으면, 브라우저가 응답을 차단하며 CORS 오류가 발생합니다.
CORS 해결 방법
-
서버 측에서
Access-Control-Allow-Origin헤더를 명시해야 합니다.Access-Control-Allow-Origin: https://frontend.example.com -
인증이 필요한 경우,
Access-Control-Allow-Credentials: true설정도 필요합니다. -
프론트엔드에서는
fetch()나axios에credentials: 'include'옵션을 넣어야 할 수 있습니다.
정리하면, CORS는 브라우저의 보안 보호막이고, 이 정책을 의도적으로 열어주는 것이 CORS 허용입니다.
7. 마무리: HTTP를 이해해야 웹이 보인다
단순히 API 호출만 하고 넘어가기엔, HTTP는 너무 중요하고 기본적인 개념입니다.
- 왜 POST 대신 PUT을 쓰는지
- 왜 HTTPS가 반드시 필요한지
- 왜 프론트엔드에서 CORS 에러가 나는지
이 모든 답은 결국 HTTP 통신 흐름과 구조에 대한 이해에서 시작됩니다.
이제 여러분도 더 이상 HTTP를 단순한 요청-응답 도구로 보지 않게 되셨기를 바랍니다.
