HTTP History
Hypertext Transfer Protocol
1. HTTP1.x
기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다.
매 연결마다 3way handshake 를 계속 해줘야하는데, 이는 자연스럽게 RTT 를 증가시키게 된다.
RTT : 패킷이 목적지에 도달하고나서 다시 출발지로 돌아오기까지 걸리는 시간. 패킷의 왕복시간.
RTT 지연문제를 해결하기 위한 3가지 방법
1-1. 이미지 스프리팅
많은 이미지를 다운받게 되면, 과부하가 걸리기 때문에, 많은 이미지가 합쳐있는 하나의 이미지를 다운로드 받고, 이를 기반으로 background-image 의 position 을 이용하여 이미지를 표기하는 방법이다.
background-image: url("icons.png");
background position 등을 기반으로 이미지를 쪼개서 사용한다.
1-2. 코드압축
코드를 압축해서 개행문자, 빈칸 등을 없에서 코드의 크기를 최소화하는 방법이다.
개행문자, 띄어스기 등이 사라져서 코드가 압축된다.
결국 코드 용량이 줄어드는 셈!
배포용 css 가 1줄로 다 줄여진것
1-3. Base64 encoding
이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법.
인코딩 : 정보의 형태나 형식을 표준화, 보안, 처리속도 향상, 저장공간 절약 등을 위해서 다른 형태나 형식으로 변환하는 처리 방식.
장점
이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해서 서버에 HTTP 요청을 할 필요가 없어진다.
단점
이미지 -> base64 변환시 크기가 37%정도 커진다.
예를 들면, base.html
이미지에 대한 요청을 하지 않고, html 파일만으로도 이미지를 표현할 수 있다.
1-4. HTTP 1.1 의 등장
HTTP1.0 에서 여러가지 보완 방법이 나왔지만, 그것에서 좀 더 발전하여 나온 것이 바로 HTTP1.1이다.
이전의 문제점이 매번 TCP 연결을 해서 RTT 가 느려지는 것이 문제였다면, 한번만 TCP 초기화를 하고, 이후에는 keep-alive 라는 옵션으로 여러개의 파일을 송수신할 수 있게 바뀌었다.
참고로 HTTP1.0 에서도 keep-alive 옵션이 있었으나 표준화되지 않았고, HTTP1.1 부터 표준화가 되어 기본 옵션으로 설정된 것이다.
1-5. 여전한 문제점 : HOL BLOCKING
그러나 HTTP1.1 에서도 해결할 수 없는 문제점이 있었는데, 그것은 HOL Blocking 이었다.
HOL Blocking : Head Of Line Blocking 을 의미하며, 네트워크에서 같은 큐에 잇는 패킷이 그 첫번째 패킷에 의해 지연이 될 때에 발생하는 성능 저하 현상을 말한다.
예를 들어, image.jpg -> style.css -> main.html 순서로 패킷을 다운받는다고 한다면, 평소에는 잘 다운받아지겠지만, image.jpg 가 느리게 다운받아진다면, 연속적으로 style.css, main.html 도 대기를 하게 되어 다운로드 자체가 지연되게 된다.
2. HTTP2
HTTP/2 는 SPDY 프로토콜에서 파생된 HTTP/1.x 보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있으며
멀티플렉싱, 헤더압축, 서버푸시, 요청의 우선순위처리 등을 지원하는 프로토콜이다.
2-1. 멀티플렉싱
여러개의 스트림을 사용하여 송수힌한다는 것.
특정 스트림의 패킷이 손실되었다고 해도, 해당 스트림에만 영향을 미치고, 나머지 스트림은 멀쩡하게 동작할 수 있다.
스트림
시간이 지남에 따라 사용할 수 있게 되는 일련의데이터 요소를 가리키는 데이터 흐름을 말한다.
2-2. 헤더압축
HTTP/1.x 에는 크기가 큰 헤더라는 문제가 있었다. 이를 HTTP/2 에서는 헤더 압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.
허프만코딩 : Huffman Coding 은 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적인 비트수를 사용하여 표현하고, 빈도가 낮은 정보는 비트수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리가 들어있는 알고리즘
2-3. 서버푸시
HTTP/1.1 에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었는데, HTTP/2 에서는 요청 없이 서버가 바로 리소스를 푸시할 수 있다.
html에는 css 나 js 파일이 포함되기 마련이다. 이때, html 파일을 읽으면서 그 안에 들어있던 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있다.
3. HTTP3
크롬 > 네트워크 > 타입을 보면 h3 가 HTTP3를 의미한다.
현재 구글은 HTTP3로만, 네이버는 HTTP2와 HTTP3를 섞어서 서빙한다.
TCP 위에서 돌아가는 HTTP/2 와는 다르게 HTTP/3 는 QUIC 라는 계층 위에서 돌아가며 UDP 기반으로 돌아간다.
HTTP/2 에서 장점이었던 멀티플렉싱을 가지고 있으며
"초기 연결 설정 지연 시간 감소"라는 대표적인 특징이 있다.
QUIC 은 TCP 를 사용하지 않기 때문에 통신을 시작할 때, 번거로운 3웨이 핸드쉐이크 과정을 거치지 않아도 된다.
QUIC 은 첫 연결 설정에 1-RTT 만 소요된다. 클라이언트가 서버에 어떤 신호를 한번 주고, 서버도 거기에 응답하기만 하면, 바로 본 통신을 시작할 수 있다는 것이다.
참고로 QUIC 는 순방향 오류 수정 매커니즘인 FEC(Forword Error Correction) 이 적용되어있다.
즉, 전송한 패킷이 손실되었다면, 그 패킷을 수신한 쪽에서 에러를 검출하고 수정하는 방식이다. (다시 전송된 쪽으로 되돌려보내지 않아서 순방향 오류 수정 매커니즘!)
열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.
Last updated
