- HTTP/1.1 vs HTTP/22022년 07월 22일
- starryeye
- 작성자
- 2022.07.22.:59
위는 HTTP/1.0, HTTP/1.1, HTTP/2의 특징들을 간단하게 보여준다..
그림 먼저 보고 들어가자..
HTTP/1에서 HTTP/1.1로 가면서..
TCP 연결에 대한 부담과 요청/응답 속도(RTT)를 많이 개선하게 되었다.
persistent, pipelining 방법으로 커넥션을 유지하고 연속적으로 보낼 수 있게 된 것이다.
하지만 여전히 문제는 많았다..
persistent
TCP 한번의 연결로 여러 요청/응답을 처리한다. (커넥션 재사용)
pipelining
한번 요청하면 그 응답 대기하고를 반복하지 말고..
여러번의 요청을 보내고 대기함 (latency 낮춤)
(이론적으로는, 두 개의 HTTP 요청을 하나의 TCP 메시지 안에 채워서(be packed) 성능 향상 할 수 있다고 한다.)
HTTP/1.1
클라이언트와 서버간의 연결에서 HTTP/1.1은 HOL Blocking 문제가 존재한다.
1. HOL(Head of Line) Blocking (어느 특정 응답이 지연)
클라이언트와 서버의 요청/응답이 무조건 순차적으로 동작하여
앞선 요청에 대한 응답이 지연되거나 수신되지 못하면 장시간 대기상태가 된다.
(도메인 샤딩이라는 기술로 어느정도 회피가 가능하나 근본 해결책은 아님)
2. HTTP 요청 Header가 무거움
HTTP/1.1은 Header를 이용하여 다양한 기능을 제공한다.
(세션, 쿠키, 가상 호스팅 등)
-> 이는 매 요청 시, 중복되어 담아져서 전달된다.
-> 중복으로 인해 대역폭 점유가 늘어나 회선 비용 증가로 이어짐.
-> 패킷 사이즈 증가로 PPS(packets per second)를 높이기 때문에 네트워크 장비들의 처리 부담 가중
3. HTTP/1.1은 클라이언트의 요청에 의해 응답이 전달되는게 원칙이다.
naver 홈 화면의 경우, 수 많은 파일들이 담겨져있다..
이를 보여주기 위해서는 클라이언트가 여러번의 요청을 수행 해야 하거나..
때로는 응답을 받고 또 요청을 보낸다거나..
아니면.. 한번의 요청을 했지만 대기시간이 긴.. 상황이 연출된다.
4. HTTP/1.1에서는 웹페이지 렌더링에 효과적인 옵션이 없다.
하나의 웹페이지를 접근할때 수많은 컨텐츠들 중 우선순위가 없기 때문에
먼저 처리가 되어야 할 컨텐츠가 뒤늦게 수신 되면 그동안 대기시간이 길어질 수 있다.
HTTP/2
HTTP/1.1에서 HTTP/2로 가면서.. 위 4가지 문제점들을 개선하였다.
(요청/응답 속도를 개선하는 4가지 기술이 도입되었다.)
1. 멀티 플렉싱 (Multiplexing)
하나의 TCP 커넥션으로 바이너리 프레임의 스트림 전송 방식 사용(FDM느낌인듯 하다..)
패킷을 프레임 단위로 세분화하여 순서에 상관없이 받는 쪽에서 조립하도록 함
framing 작업은 당연히 Application(HTTP/2)에서 해주고 조립도한다.
따라서 Binary Framing + Multiflexing 을 이용하여 여러개의 연결 없이도 병렬 처리가 가능하다..
-> 이러한 기술로.. HOLB 문제를 어느정도 해결하였다.
(하지만.. 그 스트림이 막힌다면.. 여전히 HOLB 문제 발생한다.)
2. 헤더 압축
중복되는 반복 비율이 높을 수록 압축 효율이 높아지는 허프만 HPACK 알고리즘으로
헤더를 압축하여 HTTP 응답 시간(Latency)를 개선한다.
3. Server Push
하나의 HTML 웹페이지를 구성하는데 수 많은 컨텐츠를 전달 해줘야한다..
HTTP/2는 클라이언트가 요청하지 않은 데이터에 대해서도
서버에서 클라이언트로 전송가능하도록 하는 기술이다.
4. 우선 순위 (Stream Proioritization)
예를 들면, 하나의 웹페이지를 보여주는데
클라이언트 입장에서 css가 먼저 수신되어야 스타일을 정의하여
페이지를 만들 기반이 생긴다..
아무리 다른 컨텐츠가 먼저 수신되어도 먼저 처리를 시작 할 수가 없다.
따라서 css가 먼저 수신 될 수 있도록 전송에 우선순위를 두어 처리 될 수 있도록 하는 기능이다.
참고
'Network' 카테고리의 다른 글
HTTP3, QUIC + TLS (0) 2022.07.25 HTTP polling, long polling (0) 2022.07.23 GSLB, CDN, DNS (0) 2022.07.21 다음글이전글이전 글이 없습니다.댓글