HTTP와 HTTPS
HTTP와 HTTPS
📝 개념 정의
HTTP (Hypertext Transfer Protocol)
웹에서 클라이언트와 서버 간에 데이터를 주고받기 위한 애플리케이션 계층 프로토콜입니다.
핵심 특징:
- TCP 기반 프로토콜 (HTTP/3는 UDP 기반 QUIC 사용)
- 비연결성 (Connectionless): 요청-응답 후 연결 종료
- 무상태성 (Stateless): 이전 요청 정보를 저장하지 않음
- 평문 전송: 암호화되지 않아 보안에 취약
HTTPS (HTTP Secure)
HTTP에 TLS/SSL 암호화 계층을 추가하여 보안을 강화한 프로토콜입니다.
핵심 특징:
- TLS/SSL 프로토콜로 데이터 암호화
- 기밀성, 무결성, 인증 보장
- 포트 443 사용 (HTTP는 80)
- 인증서 기반 신뢰성 검증
🎯 HTTP vs HTTPS 비교
| 특성 | HTTP | HTTPS | |------|------|-------| | 보안 | 평문 전송 (취약) | TLS/SSL 암호화 | | 포트 | 80 | 443 | | 속도 | 빠름 | 약간 느림 (암호화 오버헤드) | | 인증서 | 불필요 | SSL/TLS 인증서 필요 | | SEO | 낮은 우선순위 | 높은 우선순위 | | 사용 예시 | 공개 정보 조회 | 로그인, 결제, 개인정보 |
🔄 HTTP 진화 과정
HTTP/0.9 (1991)
- 원-라인 프로토콜
- GET 메서드만 지원
- HTML 파일만 전송 가능
- 헤더 없음, 상태 코드 없음
HTTP/1.0 (1996)
- 버전 정보 추가
- GET, HEAD, POST 메서드 지원
- 상태 코드 도입 (200, 404 등)
- HTTP 헤더 개념 등장
- Content-Type으로 다양한 파일 전송 가능
HTTP/1.1 (1997) - 표준화
주요 개선사항:
1. 연결 재사용 (Keep-Alive)
- 한 번 수립한 TCP 연결을 재사용
- RTT (Round Trip Time) 감소
- 기본 옵션으로 설정
2. 파이프라이닝 (Pipelining)
- 첫 번째 응답을 기다리지 않고 두 번째 요청 전송 가능
- 지연 시간 개선
3. 캐시 제어 메커니즘
- Cache-Control 헤더 도입
- 서버 부하 감소, 네트워크 시간 절약
4. 호스트 헤더
- 하나의 IP에 여러 도메인 호스팅 가능 (가상 호스팅)
문제점:
- HOL (Head-of-Line) Blocking: 앞선 요청이 지연되면 뒤 요청도 지연
HTTP/2 (2015) - HTTP over SPDY
주요 개선사항:
1. 이진 프로토콜
- 텍스트 → 바이너리 변환
- 파싱 속도 향상, 오류 감소
2. 멀티플렉싱 (Multiplexing)
- 하나의 TCP 연결에서 여러 요청/응답 동시 처리
- 스트림, 메시지, 프레임 단위로 세분화
- HOL Blocking 해결
3. 헤더 압축 (HPACK)
- 중복 헤더 제거
- 허프만 코딩 기법 사용
4. 서버 푸시 (Server Push)
- 클라이언트 요청 전에 리소스 미리 전송
- 예: HTML 요청 시 CSS/JS 자동 전송
요구사항:
- HTTPS 필수 (TLS 위에서 동작)
HTTP/3 (2022) - HTTP over QUIC
등장 배경:
- TCP의 HOL Blocking 여전히 존재
- TCP 흐름 제어/혼잡 제어가 좋은 네트워크에서 지연 발생
주요 특징:
QUIC 프로토콜 기반
- UDP 기반: TCP의 신뢰성 기능을 UDP에 직접 구현
- 빠른 연결: 1-RTT (최초), 0-RTT (재연결)
- 독립적 스트림: 한 스트림 실패가 다른 스트림에 영향 없음
- Connection ID: IP 변경 시에도 연결 유지 (Wi-Fi ↔ 셀룰러)
🔒 HTTPS 보안 메커니즘
안전한 통신의 3가지 요구사항
- 기밀성 (Confidentiality): 송신자와 수신자만 내용 이해 가능
- 무결성 (Integrity): 전송 중 데이터 변경 불가
- 인증 (Authentication): 상대방 신원 확인 가능
암호화 방식
1. 대칭키 암호화
- 암호화/복호화에 같은 키 사용
- 빠른 속도
- 키 공유 문제 존재
2. 공개키 암호화 (비대칭키)
- 공개키: 모두에게 공개, 암호화에 사용
- 개인키: 소유자만 보유, 복호화에 사용
- 느린 속도
- 키 공유 문제 해결
TLS Handshake 과정
Client Server
| |
| 1. Client Hello |
|----------------------------->|
| |
| 2. Server Hello + 인증서 |
|<-----------------------------|
| (공개키 포함) |
| |
| 3. 인증서 검증 (CA 확인) |
| |
| 4. 암호화된 대칭키 전송 |
| (공개키로 암호화) |
|----------------------------->|
| |
| 5. 대칭키로 복호화 |
| (개인키 사용) |
| |
| 6. HTTPS 통신 시작 |
| (대칭키 암호화 사용) |
|<===========================>|
단계별 설명:
- TCP 연결 수립 (3-way handshake)
- Client Hello: 클라이언트가 지원하는 암호화 방식 전송
- Server Hello: 서버가 인증서 전송 (공개키 포함)
- 인증서 검증: CA (Certificate Authority)를 통해 인증서 신뢰성 확인
- 대칭키 공유: 공개키로 암호화하여 대칭키 전송
- HTTPS 통신: 대칭키로 데이터 암호화/복호화
하이브리드 방식 사용 이유:
- 핸드셰이크: 공개키 암호화 (안전한 키 공유)
- 데이터 전송: 대칭키 암호화 (빠른 속도)
CA (Certificate Authority)
- 공개키를 저장하고 인증서를 발급하는 신뢰할 수 있는 제3자 기관
- 브라우저에 CA 공개키가 내장되어 있음
- 인증서는 CA의 개인키로 서명됨
💡 HTTP 메서드
| 메서드 | 설명 | CRUD | 멱등성 | 안전성 | |--------|------|------|--------|--------| | GET | 리소스 조회 | R | O | O | | POST | 리소스 생성 | C | X | X | | PUT | 리소스 전체 수정/생성 | C, U | O | X | | PATCH | 리소스 일부 수정 | U | X | X | | DELETE | 리소스 삭제 | D | O | X | | HEAD | GET과 동일하나 헤더만 반환 | R | O | O | | OPTIONS | 지원하는 메서드 확인 | - | O | O |
멱등성 (Idempotent): 동일한 요청을 여러 번 보내도 서버 상태가 동일 안전성 (Safe): 서버 상태를 변경하지 않음
❓ 면접 질문 예시
Q1. HTTP와 HTTPS의 차이점은?
답변: HTTP는 평문으로 데이터를 전송하기 때문에 중간에 패킷을 가로채거나 수정할 수 있어 보안에 취약합니다. HTTPS는 TLS/SSL 암호화 계층을 추가하여 데이터를 암호화함으로써 기밀성, 무결성, 인증을 보장합니다.
Q2. TLS Handshake 과정을 설명해보세요.
답변:
- TCP 3-way handshake로 연결 수립
- 클라이언트가 Client Hello 전송
- 서버가 인증서(공개키 포함) 전송
- 클라이언트가 CA를 통해 인증서 검증
- 클라이언트가 대칭키를 서버의 공개키로 암호화하여 전송
- 서버가 개인키로 복호화하여 대칭키 획득
- 이후 대칭키로 암호화된 HTTPS 통신 시작
Q3. 왜 공개키와 대칭키를 함께 사용하나요?
답변: 공개키 암호화는 안전하지만 속도가 느리고, 대칭키 암호화는 빠르지만 키 공유 문제가 있습니다. 따라서 TLS Handshake에서는 공개키 암호화로 안전하게 대칭키를 공유하고, 실제 데이터 전송에서는 대칭키 암호화를 사용하여 속도와 보안을 모두 확보합니다.
Q4. HTTP/2의 멀티플렉싱이란?
답변: 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리하는 기술입니다. 스트림, 메시지, 프레임 단위로 데이터를 세분화하여 전송하므로, HTTP/1.1의 HOL Blocking 문제를 해결할 수 있습니다.
Q5. HTTP/3가 UDP를 사용하는 이유는?
답변: TCP는 신뢰성 보장을 위해 흐름 제어와 혼잡 제어를 수행하는데, 이것이 좋은 네트워크 환경에서는 오히려 지연을 발생시킵니다. HTTP/3는 QUIC 프로토콜을 사용하여 UDP 위에 필요한 신뢰성 기능만 직접 구현함으로써 더 빠른 연결과 독립적인 스트림 처리가 가능합니다.
Q6. GET과 POST의 차이는?
답변:
- GET: 서버에서 리소스를 조회합니다. 멱등성과 안전성이 보장되며, 캐싱이 가능합니다. 일반적으로 Request Body를 사용하지 않습니다.
- POST: 서버에 리소스를 생성합니다. 멱등성이 보장되지 않으며, Request Body에 데이터를 담아 전송합니다.
📚 원본 참고 자료
출처 1: 2023-CS-Study - HTTP 진화
- 링크: network_http.md
- 내용: HTTP/0.9부터 HTTP/3까지 진화 과정, 각 버전별 특징
출처 2: 2023-CS-Study - HTTPS
- 링크: network_https.md
- 내용: TLS/SSL, 암호화 방식, TLS Handshake 과정
출처 3: backend-interview-question
- 파일:
/Users/PARK/Desktop/MyBook/backend-interview-question/README.md(라인 143-160) - 내용: 면접 질문 및 답변