HTTP/HTTPS에 대해 다시 한 번 정리해보자

네트워크

By Jeongmin Seo•8월 19일, 2024년

HTTP

HyperText Transfer Protocol의 약자로 웹에서 클라이언트(주로 브라우저)와 서버가 통신할 때 사용하는 프로토콜

HTTPS

HyperText Transfer Protocol Secure의 약자로 HTTP에 SSL/TLS를 추가해 데이터를 암호화하여 안전하게 전송하는 프로토콜

대칭키 + 공개키 암호화 사용
- 공개키로 대칭키를 암호화 → 서버가 비공개키로 복호화
보안 요소
- 기밀성: 암호화로 제3자가 내용을 볼 수 없음
- 무결성: 데이터가 변경되지 않았는지 확인 (해시)
- 인증: 서버가 진짜인지 확인 (인증서 기반)

HTTPS 통신 주요 과정

1. 클라이언트 → 서버로 접속 요청 (HTTPS)
2. 서버 → 인증서(CA 발급) 전달
3. 클라이언트 → 인증서 검증
4. 대칭키 생성 후 서버에 전달 (공개키로 암호화)
5. 서버 → 비공개키로 복호화
6. 이후 대칭키로 통신

HTTP 핵심 특징

비연결성 (Connectionless)
- 클라이언트가 요청하고 서버가 응답을 보내면, 연결을 즉시 끊음
- 매 요청마다 새로운 TCP 연결이 사용됨 (HTTP/1.1에선 keep-alive로 일부 유지 가능)
- 서버는 클라이언트 연결을 오래 유지하지 않기 때문에 리소스 절약에 유리
무상태성 (Stateless)
- 요청 간 상태를 유지하지 않음
- 서버는 각 요청을 독립적으로 처리하며, 이전 요청의 정보를 기억하지 않음
- 상태 유지를 위해선 세션, 쿠키, 토큰 등 별도 기술이 필요함
확장성 (메서드 & 상태 코드 기반 통신)
- 다양한 HTTP 메서드로 동작의 의미를 명확히 표현 가능 → GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS 등
- 상태 코드를 통해 서버의 응답 상황을 숫자로 표준화 → 200 OK, 404 Not Found, 500 Internal Server Error 등
- 구조가 단순하면서도 유연해 REST API, GraphQL, Web API 설계에 적합
유연한 데이터 전송
- 텍스트, 이미지, JSON, XML 등 다양한 형태의 데이터 전송 가능
- MIME 타입(Content-Type)으로 전송 데이터 타입 명시
TCP 위에서 동작
- HTTP는 전송 계층인 TCP 위에서 동작하여 안정적인 데이터 전달 보장
- HTTP/3는 UDP 기반의 QUIC 위에서 동작

HTTP 요청(Request) 구성

메서드: GET, POST, PUT, DELETE 등
URL: 자원의 경로
헤더: 요청자 정보, 인증, 콘텐츠 타입 등
바디: 요청 데이터 (POST, PUT 등)

HTTP 응답(Response) 구성

상태코드: 결과 요약
헤더: 응답 정보
바디: 실제 데이터

HTTP 상태코드

코드	맥락	의미	예
1xx	잠시만	서버가 요청 받았고, 처리 중이라는 신호	100 Continue(계속 보내도 됨), 101 Switching Protocols(프로토콜 변경)
2xx	좋은 통신이었어요	요청 성공, 서버가 문제없이 처리했음	200 OK(성공), 201 Created(자원 생성됨)
3xx	저기로 가	요청한 자원이 다른 곳에 있으니 새 위치로 이동	301 Moved Permanently(영구 이동), 302 Found(임시 이동)
4xx	너의 잘못	클라이언트 요청에 문제 있음 (잘못된 요청, 권한 없음 등)	400 Bad Request(요청 형식 오류), 401 Unauthorized(인증 필요), 403 Forbidden(접근 금지), 404 Not Found(존재하지 않음)
5xx	나의 잘못	서버 문제로 요청 처리 실패	500 Internal Server Error(서버 오류), 503 Service Unavailable(일시적 문제)

HTTP 메서드

멱등성 - 서버에 미치는 의도된 영향이 동일한가? 멱등에 대한 추가 설명

HTTP 메소드	요청	응답	특징/용도	안전	멱등	캐시 가능 여부	예시
GET	선택 사항	예	서버 자원 요청, 안전	예	예	예	유저 정보 조회, 게시글 목록 조회
HEAD	선택 사항	아니요	GET과 같으나 본문 없이 헤더만 받음	예	예	예	리소스 존재 여부 확인
POST	예	예	서버 상태 변경	아니요	아니요	예	회원가입, 댓글 작성, 좋아요 추가
PUT	예	예	서버 상태 변경, 본문에 수정할 전체 데이터 포함	아니요	예	아니요	회원 정보 전체 수정, 파일 업로드
DELETE	선택 사항	예	서버 상태 변경	아니요	예	아니요	회원 탈퇴, 게시글 삭제
CONNECT	선택 사항	예	프록시나 VPN 터널링용	아니요	아니요	아니요	HTTPS 프록시 연결
OPTIONS	선택 사항	예	서버가 지원하는 HTTP 메서드나 기능 조회	예	예	아니요	CORS 정책 확인
TRACE	아니요	예	클라이언트-서버간 요청 경로 확인용, 디버깅 목적	예	예	아니요	디버깅, 테스트용
PATCH	예	예	서버 상태 변경, 본문에 수정할 부분 데이터 포함	아니요	아니요	아니요	유저 정보 일부 수정, 설정값 변경, 조회수 증가 등

GET vs POST (POST가 GET보다 더 안전한가?)

주요 특징

항목	GET	POST
데이터 위치	URL의 쿼리스트링 (`?key=value`)	HTTP 메시지 바디
주 용도	데이터 조회	데이터 생성/수정
길이 제한	있음 (브라우저/서버에 따라 URL 길이 제한)	사실상 없음 (대용량 전송 가능)
캐싱	캐싱 (같은 URL로 판단)	가능은 하지만 사용 안 함
북마크 가능성	가능 (URL에 데이터 포함)	불가능
안전성	O	X
멱등성	O	X
데이터 노출 위험	브라우저 히스토리, 서버나 프록시 로그 등 URL이 유출되는 경우 데이터도 함께 노출	비교적 낮음

클라이언트/서버 상 보안

GET
- 데이터가 URL에 그대로 노출됨
- 브라우저 히스토리, 북마크, 서버 및 프록시 로그에 기록될 수 있음
- 따라서 내 PC를 다른 사람이 쓰거나 서버 로그가 유출되면 민감 정보가 노출될 위험이 큼
POST
- 데이터가 HTTP Body에 담겨 전송되어 URL에는 노출되지 않음
- 히스토리나 북마크, 서버 로그에 데이터가 기록될 가능성 적음
- 다만, 개발자 도구 네트워크 탭 등에서는 여전히 내용 확인 가능

URL 노출로 인한 의도치 않은 민감 정보 노출 위험을 줄이기 위해 POST 방식 사용 권장

네트워크 상 보안

HTTP는 데이터가 암호화되지 않아 누군가 중간에서 가로채면 GET이든 POST든 내용이 그대로 노출된다.
HTTPS는 통신 내용을 암호화해, 패킷을 가로채도 내용을 알 수 없어 도청이나 변조 위험이 크게 줄어든다.

결론

HTTP 환경에서는 GET이나 POST나 별 차이 없이 위험하다.
HTTPS를 사용하면 둘 다 안전하게 보호받는다.

GET과 POST는 전송 위치, 캐싱 방식, 그리고 사용 목적에 차이가 있다.

GET은 데이터를 URL 쿼리 문자열에 담아 전송해서 브라우저 히스토리에 남고, 캐싱이 쉽게 되며, 주로 조회용으로 사용된다.

POST는 데이터를 HTTP 바디에 담아 전송해 URL에 노출되지 않고, 기본적으로 캐싱되지 않으며, 서버에 데이터를 생성하거나 수정할 때 사용한다.

보안 관점에서는 ‘POST가 무조건 안전하다’는 오해가 있는데, HTTPS를 쓰지 않으면 GET, POST 모두 네트워크 상에서 도청될 수 있다.

다만 GET 방식은 URL에 민감한 정보가 노출돼 로그나 히스토리에 기록될 위험이 있으니, 민감 정보는 POST와 HTTPS 조합으로 보내는 게 적절하다.

목차

HTTP

HTTPS

HTTPS 통신 주요 과정

HTTP 핵심 특징

HTTP 요청(Request) 구성

HTTP 응답(Response) 구성

HTTP 상태코드

HTTP 메서드

GET vs POST (POST가 GET보다 더 안전한가?)

주요 특징

클라이언트/서버 상 보안

네트워크 상 보안

결론