[네트워크] HTTP 프로토콜의 발전 과정과 HTTPS, TLS
✒️ 0. 들어가기 전
이전 포스팅에서 다루었던 내용에서 HTTP에 대한 심화된 내용을 조금 더 다뤄보겠다.
[네트워크] HTTP 헤더(header)
✒️ 0. 들어가기 전HTTP 요청/응답 과정에서 Header와 Body를 주고 받는다.이 중에서 헤더에 대해 알아보자. ✒️ 1. HTTP 헤더HTTP 헤더는 사용자가 HTTP 요청을 할 때 주고받는 중요한 정보다.헤더와
jinhos-devlog.tistory.com
✒️ 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가지 차이점이 있다.
- Keep-Alive 기본 설정: 연결을 재사용할 수 있어 TCP 연결 횟수를 줄일 수 있다.
- 호스트 헤더 도입: 동일 IP 주소에서 여러 도메인을 호스팅할 수 있게 되었다.
HTTP/1.0은 서버가 하나의 호스트만 가진다고 가정하기 때문에 HTTP/1.0은 헤더에 호스트를 포함하지 않았다.
그러나 사실 서버는 여러개의 호스트를 가질 수 있으며
이런 유연성을 위해 HTTP/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 핸드셰이크는 클라이언트와 서버가 안전하게 통신을 시작하는 과정이다.
간단히 살펴보자
1. Client Hello: 클라이언트가 서버에 연결을 시도한다. (안녕!) TLS 버전, 지원하는 암호 스위트, 랜덤 값 등을 전송한다.
2. Server Hello 및 관련 메시지: 서버가 응답한다. TLS 버전을 확정하고, 암호 스위트를 선택하며, 인증서를 전송한다.
3.인증: 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증한다. 이를 통해 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지를 확인한다.
4. Key Exchange: 여기서 Diffie-Hellman(DH) 알고리즘이 중요한 역할을 한다. DH는 양쪽에서 비밀키를 안전하게 생성할 수 있게 해준다.
(중략)
5. Finished: 모든 것이 확인되면, 이제 암호화된 통신이 시작된다.
이 과정에서 비대칭 암호화로 인증을 하고, 그 후 대칭 암호화로 실제 통신을 수행한다.
왜 그럴까?
비대칭 암호화는 안전하지만 느리고, 대칭 암호화는 빠르지만 키 공유가 문제니까, 이렇게 두 방식의 장점을 모두 활용하는 것.