http와 https 뭐야?
HTTP와 HTTPS의 차이
HTTP와 HTTPS의 정의
HTTP(Hypertext Transfer Protocol)는 웹에서 클라이언트와 서버 간에 데이터를 주고받기 위한 기본적인 통신 프로토콜이다. 웹 브라우저와 웹 서버 간의 통신 방식을 정의한다.
HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 데이터 암호화 계층(SSL/TLS)을 추가한 보안 강화 버전의 프로토콜이다. 민감한 정보를 안전하게 전송하기 위해 설계되었다.
-> 즉, 둘의 가장 큰 차이점은 데이터 전송 시 보안 계층의 존재 여부이다.
HTTP의 발전사 및 버전별 특징
HTTP는 1989년 팀 버너스리(Tim Berners-Lee)가 WWW(World Wide Web)와 함께 개발한 이후 지속적으로 발전해왔다. 각 버전은 웹의 성장과 함께 새로운 요구사항을 충족하기 위해 진화했다.
HTTP/0.9 (1991년)
HTTP의 첫 번째 공식 버전으로, 매우 단순한 형태였다.
주요 특징:
- 단일 메서드: GET 메서드만 지원
- HTML만 전송: HTML 문서만 전송 가능
- 헤더 없음: HTTP 헤더가 존재하지 않음
- 상태 코드 없음: 에러 처리 메커니즘이 부재
- 단순한 요청: 요청 형태가
GET /path형태로 매우 간단
GET /index.htmlHTTP/1.0 (1996년)
웹의 상업적 활용이 증가하면서 더 복잡한 기능이 필요해져 개발된 버전이다.
주요 특징:
- 다양한 메서드: GET, POST, HEAD 메서드 추가
- HTTP 헤더: Content-Type, Content-Length 등 메타데이터 전송 가능
- 상태 코드: 200, 404, 500 등 응답 상태를 나타내는 코드 도입
- 다양한 콘텐츠: HTML뿐만 아니라 이미지, 비디오 등 다른 형태의 콘텐츠 전송 가능
- 버전 정보: 요청과 응답에 HTTP 버전 정보 포함
GET /index.html HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/1.0HTTP/1.1 (1997년, 1999년 개정)
현재까지도 가장 널리 사용되는 HTTP 버전으로, 웹의 폭발적 성장을 지원했다.
주요 특징:
- 지속적 연결(Persistent Connection): 한 번의 TCP 연결로 여러 요청/응답 처리 가능
- 파이프라이닝(Pipelining): 응답을 기다리지 않고 연속적으로 요청 전송 가능
- 청크 전송 인코딩(Chunked Transfer Encoding): 콘텐츠 길이를 미리 알 수 없는 경우에도 전송 가능
- 추가 메서드: PUT, DELETE, OPTIONS, TRACE 등 새로운 HTTP 메서드 추가
- Host 헤더: 하나의 IP 주소에서 여러 도메인 호스팅 가능 (가상 호스팅)
- 캐시 제어: 더 정교한 캐싱 메커니즘 제공
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
Accept: text/html,application/xhtml+xmlHTTP/1.1의 한계:
- Head-of-Line Blocking: 파이프라이닝에서 첫 번째 요청이 지연되면 뒤의 모든 요청이 대기
- 헤더 중복: 동일한 헤더 정보를 반복적으로 전송
- 연결 제한: 브라우저당 도메인별 동시 연결 수 제한 (일반적으로 6-8개)
HTTP/2 (2015년)
Google의 SPDY 프로토콜을 기반으로 개발된 대규모 성능 개선 버전이다.
주요 특징:
- 이진 프로토콜: 텍스트 기반에서 이진 기반으로 변경하여 파싱 효율성 향상
- 멀티플렉싱(Multiplexing): 하나의 연결에서 여러 요청과 응답을 병렬 처리
- 스트림 우선순위: 중요한 리소스를 먼저 전송할 수 있도록 우선순위 설정 가능
- 서버 푸시(Server Push): 클라이언트 요청 없이 서버가 필요한 리소스를 미리 전송
- 스트림 기반: 각 요청/응답을 독립적인 스트림으로 처리
# HTTP/2는 이진 프로토콜이므로 텍스트로 표현하기 어려움
# 다음은 개념적 표현
:method: GET
:path: /index.html
:scheme: https
:authority: www.example.com성능 향상 효과:
- 페이지 로딩 속도 10-30% 향상
- 서버 리소스 효율성 증대
- 네트워크 지연 시간 감소
SPDY는 Google이 2009년에 개발한 실험적 프로토콜로, HTTP/2의 기초가 되었다. 현재는 사용이 중단되고 HTTP/2로 대체되었다.
HTTP/3 (2022년)
UDP 기반의 QUIC 프로토콜을 사용하는 차세대 HTTP 버전이다.
주요 특징:
- QUIC 프로토콜: TCP 대신 UDP 기반의 QUIC 사용
- 연결 설정 최적화: 0-RTT 또는 1-RTT 연결 설정으로 지연 시간 감소
- 내장 암호화: 전송 계층에서 기본적으로 암호화 제공
- 독립적 스트림: 스트림 간 Head-of-Line Blocking 완전 해결
- 연결 마이그레이션: IP 주소나 포트 변경 시에도 연결 유지 가능
- 향상된 혼잡 제어: 더 효율적인 네트워크 혼잡 제어 알고리즘
장점:
- 모바일 환경에서 성능 향상
- 네트워크 전환 시 연결 유지
- 더 빠른 연결 설정
현재 상태:
- 주요 브라우저와 CDN에서 지원 시작
- 점진적 도입 단계
- HTTP/2와 병행 사용
QUIC(Quick UDP Internet Connections)는 Google이 개발한 전송 프로토콜로, UDP 위에 신뢰성과 보안 기능을 추가한 것이다.
버전별 성능 비교
| 버전 | 연결 방식 | 다중화 | 암호화 | 주요 개선점 |
|---|---|---|---|---|
| HTTP/0.9 | 연결당 1요청 | 없음 | 없음 | 기본 웹 페이지 전송 |
| HTTP/1.0 | 연결당 1요청 | 없음 | 선택적 | 헤더, 상태코드 도입 |
| HTTP/1.1 | 지속적 연결 | 제한적 | 선택적 | 파이프라이닝, 가상호스팅 |
| HTTP/2 | 단일 연결 | 완전 지원 | 권장 | 이진 프로토콜, 서버 푸시 |
| HTTP/3 | QUIC 기반 | 완전 지원 | 필수 | 0-RTT, 연결 마이그레이션 |
HTTP와 HTTPS의 기본 개념
HTTP와 HTTPS는 다음과 같은 기본적인 특성을 가진다.
HTTP의 특성
- 단순성: 텍스트 기반의 간단한 요청-응답 구조
- 상태 비저장(Stateless): 각 요청은 독립적이며 이전 요청에 대한 정보를 저장하지 않음
- 개방성: 누구나 내용을 볼 수 있는 일반 텍스트 형태로 데이터 전송
HTTPS의 특성
- 보안성: SSL/TLS 암호화를 통한 데이터 보호
- 무결성: 데이터 전송 중 변조 감지 및 방지
- 인증: 사용자가 접속한 웹사이트의 신원 확인 가능
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 웹사이트와 사용자 브라우저 간 또는 두 서버 간의 데이터 전송을 암호화하여 보호하는 기술이다.
HTTP와 HTTPS의 주요 목적은 웹 브라우저와 웹 서버 간 정보 교환을 위한 규칙을 정의하는 것이다. 사용자가 웹사이트에 접속할 때, 브라우저는 서버에 HTTP 또는 HTTPS 요청을 보내고, 서버는 이에 응답하여 웹페이지를 표시한다. 예를 들어, 온라인 쇼핑몰에서 제품을 검색할 때, 브라우저는 서버에 요청을 보내고 서버는 제품 정보를 응답으로 전송한다.
HTTP와 HTTPS의 구조적 차이
1. 프로토콜 구조
HTTP는 TCP/IP 위에서 직접 동작하는 단순한 구조를 가진다.
TCP/IP는 인터넷의 기본 통신 프로토콜로, 컴퓨터들이 서로 데이터를 주고받는 방법을 정의한 규칙의 집합이다.
클라이언트 → HTTP 요청 → 서버
클라이언트 ← HTTP 응답 ← 서버HTTPS는 HTTP와 SSL/TLS 암호화 계층의 조합으로 구성된다.
클라이언트 → HTTP 요청 → SSL/TLS 암호화 → 서버
클라이언트 ← HTTP 응답 ← SSL/TLS 복호화 ← 서버2. 포트 번호
HTTP는 기본적으로 80번 포트를 사용한다.
http://example.com → http://example.com:80HTTPS는 기본적으로 443번 포트를 사용한다.
https://example.com → https://example.com:443HTTP가 80번, HTTPS가 443번 포트를 사용하는 것에는 특별한 기술적 이유나 의미가 있는 것은 아니다. 이 포트 번호들은 단순히 인터넷 초창기에 포트를 할당하는 과정에서 선택된 임의의 번호이다. IANA(Internet Assigned Numbers Authority)에서 다양한 인터넷 서비스에 포트 번호를 할당할 때, 0-1023 사이의 번호는 "잘 알려진 포트(well-known ports)"로 지정되었고, 그 중에서 HTTP에는 80번, 나중에 HTTPS에는 443번이 할당된 것이다.
3. URL 구조
HTTP와 HTTPS는 URL의 시작 부분에서 쉽게 구분할 수 있다:
HTTP: http://www.example.com
HTTPS: https://www.example.com4. 인증서 사용
HTTP는 서버 인증서를 사용하지 않는다.
HTTPS는 SSL/TLS 인증서를 사용하여 웹사이트의 신원을 확인한다:
- 인증서는 인증 기관(CA)에 의해 발급됨
- 웹사이트 도메인, 조직 정보, 공개 키 등의 정보 포함
- 방문자는 브라우저의 자물쇠 아이콘을 통해 인증서 정보 확인 가능
HTTP와 HTTPS의 기술적 차이
1. 보안 메커니즘
HTTP는 별도의 보안 메커니즘이 없어 다음과 같은 위험에 노출된다:
- 도청(Eavesdropping): 제3자가 통신 내용을 쉽게 가로채 볼 수 있음
- 중간자 공격(Man-in-the-Middle): 악의적인 중개자가 통신을 가로채 정보를 조작할 수 있음
- 데이터 변조: 전송 중인 데이터의 무결성을 보장할 수 없음
HTTPS는 다음과 같은 보안 메커니즘을 제공한다:
- 암호화: 대칭키와 비대칭키 암호화를 조합하여 데이터를 암호화
- 데이터 무결성: 해시 함수를 사용하여 전송 중 데이터 변조 감지
- 인증: 인증서를 통한 서버 신원 확인
2. 핸드셰이크 과정
HTTP는 단순한 TCP 연결 수립 후 바로 데이터 전송을 시작한다.
HTTPS는 데이터 전송 전 복잡한 SSL/TLS 핸드셰이크 과정을 거친다:
1. 클라이언트 헬로: 클라이언트가 지원하는 암호화 방식 전송
2. 서버 헬로: 서버가 선택한 암호화 방식과 인증서 전송
3. 인증서 검증: 클라이언트가 인증서의 유효성 확인
4. 키 교환: 안전한 통신을 위한 대칭키 생성 및 교환
5. 세션 설정: 합의된 암호화 방식으로 안전한 통신 채널 설정
"핸드셰이크"는 컴퓨터 네트워크에서 두 장치가 서로 통신을 시작하기 전에 연결 매개변수를 교환하고 합의하는 과정을 말한다. 이는 실제 사람들이 만났을 때 악수를 통해 인사를 나누는 것에서 유래한 용어이다.
3. 성능 차이
HTTPS는 암호화/복호화 및 핸드셰이크 과정으로 인해 HTTP보다 약간의 성능 저하가 발생할 수 있다:
- 초기 연결 지연: SSL/TLS 핸드셰이크로 인한 추가 왕복 시간
- 처리 오버헤드: 암호화/복호화 작업으로 인한 CPU 사용량 증가
실제 사용 사례 비교
HTTPS가 필수적인 경우
- 금융 거래: 온라인 뱅킹, 결제 시스템, 전자상거래 사이트
- 개인정보 처리: 로그인 페이지, 회원가입 양식, 개인정보 설정
- 의료 정보: 환자 기록, 처방전, 의료 상담 서비스
- 기업 데이터: 내부 문서, 고객 데이터, 비즈니스 정보
HTTP가 사용되는 경우
- 공개 정보: 공개적으로 접근 가능한 뉴스, 블로그, 정적 콘텐츠
- 내부 네트워크: 인트라넷 등 외부에서 접근할 수 없는 폐쇄형 네트워크
- 레거시 시스템: HTTPS를 지원하지 않는 오래된 시스템
브라우저에서의 표시 차이
HTTP 사이트:
- 최신 브라우저에서는 "안전하지 않음" 경고 표시
- 주소창에 자물쇠 아이콘이 없음
- 일부 브라우저에서는 적극적인 경고 메시지 출력
HTTPS 사이트:
- 주소창에 자물쇠 아이콘 표시
- EV(Extended Validation) 인증서의 경우 추가 정보 표시
- 보안 연결 수립됨을 나타내는 시각적 표시
웹 개발에서의 HTTP와 HTTPS
프론트엔드와의 관계
프론트엔드 개발에서 프로토콜 선택은 사용자 경험과 웹 애플리케이션의 보안에 영향을 미친다.
HTTP와 프론트엔드
- 혼합 콘텐츠 문제: HTTPS 페이지 내에서 HTTP 리소스 로드 시 브라우저 경고 발생
- 제한된 API 접근: 최신 브라우저 API(위치 정보, 카메라 등)는 HTTPS에서만 사용 가능
- 캐싱 전략: 중간자의 캐시 조작 가능성으로 인한 보안 위험
HTTPS와 프론트엔드
- 보안 쿠키: Secure 플래그가 설정된 쿠키는 HTTPS에서만 전송 가능
- 서비스 워커: 프로그레시브 웹 앱(PWA)의 핵심 기능은 HTTPS 환경에서만 작동
- 콘텐츠 보안 정책(CSP): 더 강력한 보안 정책 적용 가능
쿠키 데이터 : 웹사이트가 사용자의 브라우저에 저장하는 작은 텍스트 파일
백엔드와의 관계
백엔드 시스템에서 프로토콜 선택은 서버 구성과 데이터 보안에 직접적인 영향을 준다.
HTTP와 백엔드
- 단순한 구성: 인증서 관리가 필요 없어 서버 설정이 간단
- 프록시 활용: 리버스 프록시를 통한 내부 서비스 접근 시 사용
프록시 : 클라이언트와 서버 사이에서 중개자 역할을 하는 서버 또는 소프트웨어
HTTPS와 백엔드
- 인증서 관리: Let's Encrypt와 같은 서비스를 통한 무료 인증서 발급 및 갱신
- 마이크로서비스: 서비스 간 통신에도 HTTPS를 적용한 종단간 암호화
- API 보안: API 키, OAuth 토큰 등 민감한 인증 정보의 안전한 전송
프론트엔드와 백엔드는 HTTP/HTTPS를 통해 데이터를 주고받으며, 현대 웹 개발에서는 보안 강화를 위해 HTTPS가 표준으로 자리잡고 있다. 특히 Google 등 주요 브라우저 업체들은 웹의 보안 강화를 위해 HTTP 사이트에 대한 경고를 강화하고, 새로운 웹 기술을 HTTPS에서만 사용할 수 있도록 제한하고 있다.
결론
HTTP와 HTTPS는 웹 통신의 기본을 이루는 프로토콜로, 데이터 전송 방식에 있어 근본적인 차이를 가진다. HTTP는 단순하고 빠른 통신을 제공하지만 보안에 취약한 반면, HTTPS는 암호화 계층을 추가하여 데이터의 기밀성, 무결성, 인증을 보장한다.
HTTP의 발전 과정을 살펴보면, 웹의 성장과 함께 성능과 보안 요구사항이 지속적으로 증가해왔음을 알 수 있다. HTTP/0.9의 단순한 시작부터 HTTP/3의 혁신적인 QUIC 프로토콜까지, 각 버전은 이전 버전의 한계를 극복하고 더 나은 사용자 경험을 제공하기 위해 진화했다.
현대 웹 환경에서는 사용자 개인정보 보호와 데이터 보안의 중요성이 높아짐에 따라 HTTPS가 사실상의 표준으로 자리잡고 있다. 주요 브라우저와 검색 엔진이 HTTPS 채택을 권장하고, 새로운 웹 기술들이 HTTPS에서만 작동하도록 설계되면서 이러한 추세는 더욱 강화되고 있다.
결국 HTTP와 HTTPS의 선택은 단순한 기술적 결정을 넘어, 사용자 신뢰, 규제 준수, 비즈니스 신뢰성 등 다양한 측면을 고려한 전략적 결정이 되었다. 대부분의 새로운 웹 프로젝트에서는 초기부터 HTTPS를 적용하는 "HTTPS by default" 접근 방식이 권장되며, 이는 웹의 미래가 보다 안전하고 신뢰할 수 있는 방향으로 발전하고 있음을 보여준다.
