[네트워크] OSI 7_Application Layer/HTTP 버전별 특징

지난 HTTP 포스팅에 이어 HTTP 버전별 특징에 대해 공부하고 정리해보자.

REST API 개념을 확실히 알고 넘어가기 위해서 HTTP를 정리하기 시작했는데 생각보다 내용이 너무 많네. 헤헤 🫠 

 

지난 포스팅 : HTTP > 2023.02.18 - [네트워크] - [네트워크] OSI 7_Application Layer/HTTP 개요

---

HTTP/1.0

- 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었다. 이는 파일을 서버에서 가져올 때마다 3-way handshake를 거쳐야했기 때문에 RTT 증가를 불러오게 되었다.

💡RTT(Round-Trip Time) : 패킷이 클라이언트에서 서버(목적지)에 도달하고나서 다시 클라이언트로 돌아오기까지 걸리는 왕복 시간.

- 위의 이미지 처럼 한 파일을 가져오기 위해 2RTT + 파일 전송시간이 소모된다.

 

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

1. 이미지 스플리팅

많은 이미지를 다운로드 하면 과부화가 생기기 때문에 많은 이미지가 합쳐져 있는 하나의 이미지를 다운로드 받고, background-image의 position 을 이용하여 이미지를 표기하는 방법이다.

 

2. 코드 압축

코드를 압축해서 개행문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법

다음과 같은 코드가 있을 때,

body
{
    background-color: red;
}
div
{
    padding: 5px;
}
#btn
{
    background-color: blue;
}

아래와 같이 코드를 압축해 코드의 용량을 줄이는 방식이다.

body{background-color:red;}div{padding:5px;}#btn{background-color: blue;}

 

3. 이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩 하는 방법

이 방법을 사용하면 서버와의 연결을 열고, 서버에 이미지 요청을 할 필요가 없다. 그러나 37% 정도 크기가 더 커지는 단점이 있다.

 

HTTP/1.1

현재 가장 많이 사용하는 버전이다.

매번 TCP 연결을 하는 것이 아니라, TCP 초기화를 한 이후에 keep-alive 라는 옵션으로 여러번의 파일을 송수신 할 수 있도록 바꼈다. HTTP/1.0 에도 있었지만, HTTP/1.1 버전에서 표준화가 되어 기본 옵션으로 설정되었다.

이는 앞선 포스팅에서 설명한 Permanent Connection 개념을 참고하면 좋을 것 같다.

 

- 하지만 하나의 문서 안에 포함된 많은 리소스를 처리하기 위해서 요청할 리소스 개수에 비례해 대기 시간이 길어지는 단점이 있다.

 

HTTP/1.1의 문제 2가지

• HOL Blocking (Head Of Line Blocking)
  

  

  정상적으로 다운로드가 수행된다면 image.jpg - style.css - main.html 순으로 순차적으로 잘 다운로드되지만, image.jpg를 다운받을 때 지연이 발생한다면 그 다음으로 다운받아지는 파일들이 image.jpg의 다운로드가 완료될때까지 대기하게 되면서 다운로드가 지연되는 현상이 발생할 수 있다.
• 무거운 헤더 구조
  : HTTP 헤더에 쿠키 등 많은 메타데이터가 들어있고 압축이 되지않아 무겁다.

 

HTTP/2

HTTP/1.x 보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있다.

구글에서 2015년에 웹 접속 속도를 개선하기 위해 'SPDY'라는 자체 프로토콜을 개발했다. SPDY는 HTTP 헤더 단축, 바이너리 프로토콜, 멀티플렉싱 등의 특징이 있다. 이는 웹 서비스의 전송 지연시간 단축에 유용하게 사용되어 HTTP/2 표준의 근간이 되었다.

 

멀티플렉싱

여러 개의 스트림을 사용하여 송수신 하는 방식 → 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미침

💡 스트림 : 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름
- 단일 연결을 사용하여 병렬로 여러 요청과 응답을 주고 받을 수 있어 HOL Blocking 문제를 해결할 수 있다.

헤더압축

HTTP/1.x의 헤더가 큰 문제를 해결하는 방법

허프만 코딩 알고리즘을 사용하는 HPACK 압축형식을 가진다.

💡 허프만 코딩
: 문자열을 문자단위로 쪼개 빈도수를 계산하여 빈도수가 높은 정보는 적은 비트 수로, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해 전체 데이터의 표현에 필요한 비트양을 줄이는 압축 방식

 

서버푸시

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있지만, HTTP/2 는 클라이언트 요청없이 서버가 리소스를 바로 푸시할 수 있다.

html 파일에 포함되는 css나 js 파일을 서버가 푸시할 수 있다.

 

HTTPS

 

HTTP/2 는 HTTPS 위에서 동작한다.

HTTPS 는 응용계층과 전송계층 사이에 신뢰 계층인 SSL/TLS 계층을 추가한 HTTP 요청을 말한다. 이를 통해 HTTP 통신을 암호화한다. HTTPS 가 어떻게 보안을 제공하는지 자세한 설명은 내용이 방대하니 보안 관련 공부를 할 때 추가적인 포스팅을 해야겠다.

 

SSL/TLS (Secure Socket Layer / Transposrt Layer Security Protocol)

전송계층에서 보안을 제공하는 프로토콜이다. 통신 시 SSL/TLS를 통해 제 3자가 메세지를 도청하거나 변조하지 못하도록 한다.

 

HTTPS는 SEO에도 도움이 된다. SEO (Search Engine Optimization)은 검색엔진 최적화를 뜻하며 사용자들이 검색엔진으로 웹 사이트를 검색했을 때 결과를 상단에 노출 시켜 많은 사람들이 접할 수 있도록 한다. 구글에서는 SSL 인증서를 통해 HTTPS 통신을 제공한다면 HTTP 보다 SEO 순위가 높을 것이라고 공식적으로 밝혔다. (https://www.seroundtable.com/google-outdated-tls-seo-24916.html)

 

HTTPS 구축 방법

- CA 에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축한다.

- 서버 앞단의 HTTPS 를 제공하는 로드밸런서를 둔다.

- 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다.

HTTP/3

TCP 위에서 돌아가는 이전 버전의 HTTP와는 달리 HTTP/3은 QUIC 계층 위에서 돌아가며, TCP 대신에 UDP를 사용한다.

초기 연결 설정 시 지연시간 감소라는 장점이 있다.

 

QUIC 계층

앞서 말한 SPDY 기능과 함께 TLS 1.3 보안 기능을 포함하여 설계되었다.

RTT 최소화

: 초기 연결 설정 시 지연시간 감소

QUIC는 TCP를 사용하지 않기 때문에 3-way handshake 과정을 거치지 않아도 된다.

 

TCP + TLS연결의 경우, 3-way handshake와 보안 채널 setup을 위해 2-RTT가 소모되는데

반면 QUIC는 첫 연결에서도 클라이언트가 서버에 신호를 한번 주고 서버가 응답하기만 하면 바로 본 통신을 시작할 수 있어 1 RTT만 소요되며, 후속 연결에 대해선 0-RTT가 소모된다.

---

오늘은 HTTP 버전별 차이에 대해 알아봤다.

아직 대부분의 웹 서비스들이 HTTP/1.1을 쓰는 것 같은데, 언제쯤 HTTP/3의 시대가 올까?

 

-

 

잘못된 정보가 있는 경우 댓글로 알려주시면 감사하겠습니다!

 

참고 : 면접을 위한 CS 전공지식 노트(길벗, 주홍철)