2-5. HTTP - HTTP/1.0, HTTP/1.1, HTTP/2, HTTPS, HTTP/3

1. HTTP/1.0

HTTP/1.0은 1996년 처음 발표된 버전으로, 웹 통신의 기본적인 요청(Request)-응답(Response) 구조와 HTTP 헤더 개념을 확립한 버전이다. 이로 인해 요청의 성공/실패 여부를 나타내는 응답 상태코드(200 OK, 404 Not Found)를 도입할 수 있었으며, 이미지 및 CSS 등 다양한 종류의 파일을 전송할 수 있게 되었다. 하지만 HTTP/1.0에는 RTT 증가라는 핵심 한계점이 존재한다.

* RTT : 패킷이 목적지에 도달한 후 다시 출발지로 돌아오기까지 걸리는 시간 = 패킷 왕복 시간

 

1) RTT 증가

- 1 연결당 1 요청 : 클라이언트가 서버에 하나의 요청을 보내고 하나의 응답을 받으면, 해당 TCP 연결을 즉시 해제하도록 설계되었다.

- 잦은 Handshake : 서버로부터 여러 리소스 파일을 가져올 때마다 새로운 TCP 연결의 3-Way Handshake 과정이 반복된다.

- 성능 저하 : 반복적인 Handshake 때문에 RTT가 증가되며, 이는 웹페이지 로딩 속도 저하와 서버 자원의 낭비로 이어진다.

 

 

2) RTT 증가를 해결하기 위한 방법

- 이미지 스플리팅 : CSS 스프라이트라고도 불리며, 대량의 이미지를 다운로드 받을 시 과부하가 걸리는 것을 방지하기 위해 사용한다. 여러 개의 이미지가 합쳐진 하나의 이미지를 다운로드 받고, 이를 background-image의 position을 이용하여 웹페이지에 표시하는 방법이다.

- 코드 압축 : 코드의 동작에 영향을 주지 않는 개행 문자, 빈칸 등의 불필요한 문자를 없애 코드의 크기를 최소화하여 전송 속도를 빠르게 하는 방법이다.

- 이미지 Base64 : 이미지 파일을 64진법으로 이루어진 텍스트 문자열로 인코딩하는 방법이다. 서버에 HTTP 요청을 할 필요가 없는 장점이 있지만, 파일 크기가 약 37% 정도 더 커진다는 단점이 있다.

 

 

 

2. HTTP/1.1

HTTP/1.1은 1997년에 발표된 버전으로, HTTP/1.0의 가장 큰 문제였던 잦은 TCP 연결 설정 및 해제를 해결한 버전이다. HTTP/1.1은 처음 한 번 TCP를 초기화 한 이후, TCP를 지속적으로 유지하는 keep-alive를 통해 여러 개의 파일을 송수신할 수 있다. 하지만 다수의 리소스 파일을 처리하려면, 대기 시간이 요청 리소스 개수에 비례하는 단점이다.

 

1) HOL Blocking

네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다. 즉, 응답이 반드시 요청한 순서대로 와야한다.

 

 

2) 무거운 헤더 구조

HTTP/1.1부터는 요청 메시지에 Host: 헤더를 반드시 포함해야하며, 헤더에는 쿠키 등 많은 메타데이터가 들어 있으며, 압축이 되지 않아 무거운 단점이 있다. Range 헤더를 통해 파일 다운로드 중 연결이 끊겼을 때, 특정 범위부터 전송을 재개할 수 있는 부분 전송이 가능하다.

 

 

 

3. HTTP/2

HTTP/2는 2015년에 발표된 버전으로, HTTP/1.x의 문제를 해결하기 위해 바이너리 프레이밍 계층을 도입했으며 지연 시간을 줄이고 응답 시간을 더 빠르게 하여 성능을 극대화하였다. HTTP/2는 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜이다.

 

1) 멀티플렉싱

HTTP/1.1의 HOL Blocking 문제를 해결한 것으로, 하나의 TCP 연결을 통해 여러 개의 스트림을 사용하여 동시에(병렬), 비순차적으로 송수신하는 것이다. 이를 통해 특정 스트림의 패킷이 손실되어도 나머지 스트림은 멀쩡하게 동작한다. 모든 HTTP 메시지는 독립된 프레임으로 분할되어 송수신된 후, 스트림 ID를 기반으로 다시 조립되어 데이터를 주고 받는다.

* 스트림 : 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

 

 

2) 헤더 압축

허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 방식을 사용한다. 허프만 코딩은 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현한다. 전체 데이터의 표현에 필요한 비트양을 줄이는 원리이다.

 

 

3) 서버 푸시

클라이언트 요청 없이 서버가 바로 리소스를 미리 클라이언트에게 보내주는 기능이다. 클라이언트가 HTML 파일을 요청하면, 서버는 HTML 파일의 응답과 함께 HTML 내부의 CSS, JavaScript, 이미지 파일 등을 미리 푸시한다. 이를 통해 RTT를 줄이고 페이지 로딩의 회전 지연이 감소하여 초기 렌더링 속도가 향상된다.

 

 

 

4. HTTPS

HTTPS는 애플리케이션 계층과 전송 계층 사이에 보안 계층인 SSL/TLS 계층을 결합하여 데이터를 암호화하는 프로토콜이다. 브라우저 주소창에 자물쇠 모양이 표시되는 웹사이트는 HTTPS를 사용하고 있으며, 사용자와 서버 간 통신이 안전하게 보호되고 있음을 의미한다.

 

1) SSL/TLS

SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜이다. 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 메시지 도청, 변조를 못하도록 하는 기밀성과 무결성, 디지털 인증서를 통해 피싱이나 위장 서버 접속을 방지하는 인증을 목적으로 한다. SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며, 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.

 

1.1 보안 세션

보안 세션이란  SSL/TLS 핸드셰이크 과정을 통해 암호화 통신을 합의하고, 보안 세션을 생성하여 상태 정보 등을 공유하는 논리적인 연결 상태를 의미한다. 클라이언트와 서버는 공유 키(세션 키)를 통해 데이터를 암호화, 복호화하여 송수신한다. 클라이언트에서 사이퍼 슈트를 서버에 전달하면, 서버는 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인한다. 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작된 후 해싱 알고리즘 등으로 암호화 된 데이터 송수신이 시작된다.

 

- 사이퍼 슈트 : 클라이언트와 서버가 보안 세션을 설정할 때 사용할 암호화 알고리즘들을 조합하여 나열한 규약이다. 사이퍼 슈트의 이름은 프로토콜(TLS), 키 교환 알고리즘(ECDHE), 인증 알고리즘(RSA), AEAD 사이퍼 모드(AES_128_GCM), 해싱 알고리즘(SHA256)으로 이루어져 있다. ex) TLS_ECDHE_RSA_AES_128_GCM_SHA256

 

 

1.2 인증 메커니즘

인증 메커니즘은 CA에서 발급한 인증서를 검증하여 서버가 진짜임을 확인하는 과정이다. 인증서는 안전한 연결을 시작하기 위해 필요한 공개키를 클라이언트에게 제공하고, 사용자가 접속한 서버가 신뢰할 수 있음 서버임을 보장한다. CA는 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있다.

 

 

1.3 암호화 알고리즘

암호화 알고리즘은 데이터를 안전하게 보호하는 핵심 기술이다. 키 교환 암호화 알고리즘은 대수곡선 기반의 ECDHE, 모듈식 기반의 DHE를 사용하며, 모두 디피-헬만 방식으로 만들어졌다.

 

- 디피-헬만 키 교환 암호화 알고리즘 : 채널 없이도 통신 당사자들이 세션키를 안전하게 공유할 수 있도록 하는 알고리즘이다. 디피-헬만 알고리즘의 안전성은 '이산 로그 문제'라는 수학적 난제를 기반으로 한다. 매우 큰 소수 p와 생성자 g가 있을 때, g^a mod p의 결과값으로부터 지수 a를 역으로 계산하는 것은 현재 컴퓨터 연산 능력으로 사실상 불가능하다는 점을 이용한다.

단계

1. 공개 키 공유

2. 개인(비밀) 키 혼합

3. 혼합된 공개 키(공개+비밀키) 공유

4. 개인(비밀) 키 혼합

5. 공통 암호 키(PSK) 생성

 

 

1.4 해싱 알고리즘

해싱 알고리즘은 임의의 길이와 크기를 가진 데이터를 고정된 길이의 데이터로 변환시키는 절차와 규칙을 정의한 알고리즘이다. SSL/TLS는 해싱 알고리즘으로 SHA-256 알고리즘과 SHA-384 알고리즘을 사용한다.

 

- SHA-256 알고리즘 : 현재 가장 널리 사용되는 암호학적 해시 함수로, 해시 함수의 결과값이 항상 256비트로 고정된 알고리즘이다. 데이터를 512비트 블록의 배수가 되도록 패딩 작업을 하는 등의 전처리를 한 후, 전처리된 메시지를 기반으로 최종 256비트 해시를 반환한다. 비트코인과 같은 블록 체인 시스템, 비밀번호 저장 등에 많이 사용된다.

* 해시 : 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값

* 해싱 : 임의의 데이터를 해시로 바꿔주는 일

* 해시 함수 : 임의의 데이터를 입력 받아 일정한 길이의 데이터로 바꿔주는 함수

 

 

2) HTTPS 구축 방법

- 직접 CA에서 구매한 인증키를 기반으로 구축

- 서버 앞단의 HTTPS를 제공하는 로드밸런서 구축

- 서버 앞단에 HTTPS를 제공하는 CDN 구축

 

 

 

5. HTTP/3

HTTP/3은 TCP 기반의 기존 HTTP 프로토콜의 한계를 극복하고자 개발된 버전이다. HTTP/3는 구글이 개발한 QUIC 계층 위에서 동작하며, TCP가 아닌 UDP 기반으로 돌아간다. HTTP/2의 멀티플렉싱을 강화하고, 초기 연결 설정 시 지연 시간을 감소하였다.

 

1) 초기 연결 설정 시 지연 시간 감소

QUIC는 UDP를 사용하기 때문에 TCP의 3-Way Handshake 과정을 거치지 않아도 된다. 클라이언트가 서버에게 한 번의 신호를 전달하며, 서버가 응답하면 바로 본 통신을 시작한다(1-RTT). QUIC는 전송한 패킷이 손실되면 수신 측이 에러를 검출하여 수정하는 방식인 순방향 오류 수정 메커니즘(FEC)을 적용한다. 이를 통해 낮은 패킷 손실률을 자랑한다.