[네트워크] HTTP 프로토콜의 발전 과정과 HTTPS, TLS

✒️ 0. 들어가기 전

---

이전 포스팅에서 다루었던 내용에서 HTTP에 대한 심화된 내용을 조금 더 다뤄보겠다.

[네트워크] HTTP 헤더(header)

 

 

✒️ 1. HTTP 프로토콜의 진화: HTTP/1.0부터 HTTP/3까지

---

💡 HTTP/1.0: 초기 단계

HTTP/1.0은 웹의 초기 단계에서 사용된 프로토콜이다. (완전 초기의 HTTP)

 

이 버전의 주요 특징은 다음과 같다:
연결 수명이 짧다: 각 HTTP 요청마다 새로운 TCP 연결을 설정한다.
요청당 하나의 연결: 기본적으로 한 연결에서 하나의 요청만 처리할 수 있다.
RTT (Round Trip Time) 증가: 연결을 자주 설정하고 해제하므로 지연 시간이 증가한다.

RTT(Round Trip Time ; 왕복 지연시간)
신호를 전송하고 해당 신호의 수신확인에 걸린 시간을 더한 값이자 어떤 메시지가 두 장치 사이를 왕복하는 데 걸린 시간
즉, Send Request -> -> Send Response -> Receive Request 까지의 시간이다.

매 메시지마다 TCP 연결/해제를 반복하는 것이다...

 

💡 HTTP/1.1: 개선된 효율성

HTTP/1.1은 HTTP/1.0의 단점을 보완한 버전이다.

 

크게 3가지 차이점이 있다.

1. Keep-Alive 기본 설정: 연결을 재사용할 수 있어 TCP 연결 횟수를 줄일 수 있다.
2. 호스트 헤더 도입: 동일 IP 주소에서 여러 도메인을 호스팅할 수 있게 되었다.
   HTTP/1.0은 서버가 하나의 호스트만 가진다고 가정하기 때문에 HTTP/1.0은 헤더에 호스트를 포함하지 않았다.
   그러나 사실 서버는 여러개의 호스트를 가질 수 있으며
   이런 유연성을 위해 HTTP/1.1은 헤더에 특정 호스트를 포함할 수 있게 변경되었으며
   항상 호스트를 포함해서 요청하도록 바뀌었다.
3. 대역폭 최적화: 중단된 다운로드를 이어서 받을 수 있다.

일단, 연결을 한 번 해두면 원하는 데이터를 주고 받는 데 까지는 해당 연결을 사용 할 수 있다.

1.0 VS 1.1

 

💡 HTTP/1.1: 개선점

HTTP/1.1에서도 여전히 성능 개선이 필요했고, 이를 위해 다양한 기술이 사용되었다:

이미지 스프라이트: 여러 이미지를 하나의 이미지로 합쳐 요청 횟수를 줄인다.
코드 압축: JavaScript, CSS 등의 코드를 압축하여 전송한다.
Base64 인코딩: 이미지를 텍스트로 변환하여 별도의 요청 없이 전송한다.

그러나 HTTP/1.1에는 여전히 HOL(Head-of-Line) 블로킹 문제와 무거운 헤더 등의 한계가 존재했다.

HOL : 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능저하현상
(자세한 것은 이번 포스팅에서는 다루지 않겠다...)

 

💡 HTTP/2: 성능의 혁신

HTTP/2는 2015년에 등장한 프로토콜이다. (생각보다 오래되지 않았다...)
HTTP/2는 SPDY 프로토콜을 기반으로 개발되었다.
(아래 링크 참고)
https://d2.naver.com/helloworld/140351

 

1. 바이너리 프로토콜

 - HTTP 1.0은 일반 텍스트 메시지를 전송하고 줄바꿈으로 데이터를 나눴다면

HTTP 2.0은 0과 1로 이루어진 바이너리 데이터로 변경되었고 더 작은 메시지가 프레임으로 캡슐화 되어서 전송된다.

바이너리 프로토콜

2. 멀티플렉싱

- 하나의 연결로 여러 요청을 동시에 처리할 수 있어 HOL 블로킹 문제를 해결했다.

HTTP/2.0에서는 리소스를 작은 프레임으로 나누고 이를 스트림으로 프레임을 전달한다.

이 작게 나뉜 프레임을 다운로드하더라도 응답데이터에서는 올바른 순서로 받을 수 있다.

3. 서버 푸시

- 서버가 리소스를 클라이언트에 푸시를 할 수 있다.

요청된 html파일과 함께 다른 개체를 별도로 보낼 수 있다.
만약 요청한 html에 css가 포함되어있다면 별도 요청없이 css를 같이 보낼 수 있다.

4. 헤더 압축

- 똑같은 서버에서 2개의 데이터를 준다고 했을 때 중복되는 헤더는 제외한 채 보내고
해당 공통 필드로 헤더를 재구성하며 중복되지 않은 헤더값은 허프만 인코딩 압축 방법으로 압축해 전송한다.

5. 스트림 우선순위 지정

- 리소스의 중요도에 따라 우선순위를 설정할 수 있다.

💡 HTTP/2의 보안

HTTP/2는 대부분의 브라우저에서 HTTPS를 통해서만 구현된다.

이는 'h2'(TLS 사용)와 'h2c'(TLS 미사용)로 구분되며, 브라우저는 보안을 위해 'h2'만을 지원한다.

 

💡 HTTP/3: UDP 기반의 혁신

HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용한다.

각각의 핸드쉐이크가 필요한 이전 버전과 다르게 1-RTT만으로 연결 설정이 가능하다.

이로써 초기 연결 지연이 감소한다. 
또한, 순방향 오류 수정(FEC) 메커니즘을 통해 패킷 손실에 더 강하다.

-> 수신측에서 에러를 검출하고 수정하는 방식

 

 

✒️ 2. HTTPS와 TLS: 웹 보안의 핵심

---

💡 암호화의 기본 개념

암호화는 승인된 당사자만이 정보를 이해할 수 있도록 데이터를 변환하는 과정이다.

 

암호화는 승인된 당사자만 정보를 이해할 수 있도록 데이터를 “스크램블”한 방법이다.

이를 복호화하려면 송신자와 수신자가 서로 동의한 “키”가 필요하다.

 * 키(Key): 암호화와 복호화에 사용되는 비밀 정보

 

💡 대칭 암호화

동일한 키로 암호화와 복호화를 수행한다.

이 방식은 빠르고 효율적이지만, 키를 안전하게 공유하는 것이 challenge이다.
EX) DES, AES

💡 비대칭 암호화

'공개키 암호화'라고도 하며,
공개키와 개인키 쌍을 사용한다.

공개키로 암호화한 데이터는 개인키로만 복호화할 수 있다!! 

EX) RSA, DH(Diffie-Hellman)

 

✒️ 3. TLS(Transport Layer Security)

---

HTTPS를 가능하게 하는 프로토콜이다.

(참고) https://www.cloudflare.com/ko-kr/learning/ssl/what-is-https/

SSL에서 발전한 프로토콜이다.

💡 TLS 핸드셰이크

TLS 핸드셰이크는 클라이언트와 서버가 안전하게 통신을 시작하는 과정이다.

간단히 살펴보자

TLS HandShake

1. Client Hello: 클라이언트가 서버에 연결을 시도한다. (안녕!) TLS 버전, 지원하는 암호 스위트, 랜덤 값 등을 전송한다.

 

2. Server Hello 및 관련 메시지: 서버가 응답한다. TLS 버전을 확정하고, 암호 스위트를 선택하며, 인증서를 전송한다.

3.인증: 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증한다. 이를 통해 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지를 확인한다.

 

4. Key Exchange: 여기서 Diffie-Hellman(DH) 알고리즘이 중요한 역할을 한다. DH는 양쪽에서 비밀키를 안전하게 생성할 수 있게 해준다.

(중략)

5. Finished: 모든 것이 확인되면, 이제 암호화된 통신이 시작된다.

이 과정에서 비대칭 암호화로 인증을 하고, 그 후 대칭 암호화로 실제 통신을 수행한다.

왜 그럴까?

비대칭 암호화는 안전하지만 느리고, 대칭 암호화는 빠르지만 키 공유가 문제니까, 이렇게 두 방식의 장점을 모두 활용하는 것.