이병록의 개발 블로그

HTTP/2의 특징 및 간략 정리 본문

교육자료

HTTP/2의 특징 및 간략 정리

로빈 후드 이병록 2020. 5. 20. 21:42

최종 수정 일 : 2020-05-20

 

정리의 이유

는 다음과 같다. 책 또는 서칭을 통해서 정보나 지식을 찾아 학습을 하게 되다보면 실제로 머리속에 남는 경우가 많지 않다.

즉, 눈으로 정보와 지식을 습득(input)하나 누군가에게 설명(output)하기가 쉽지 않다.

그 이유는 머리속에 정리되지 못했기 떄문이다. 

지식과 정보를 습득 후 정리를 통해 머리속에 차곡 차곡 정리를 할 수 있다.

내용이 긴 것은 중요한 것이 아니다. 요약 정리만 되도 충분히 도움이 된다.

(A4용지 1장 분량, 또는 확장은 3장 분량이면 되는 것 같다. 1, 3, 5, 7?)

 

아인슈타인이 말했다.

“If you can’t explain it simply, you don’t understand it well enough."

"간단히, 설명할 수 없다면, 그것을 충분히 이해하지 못한 것이다."

 

 

HTTP/2 간략 정리 순서

1. HTTP/2가 생긴 배경(왜?)

2. HTTP/2의 특징

    1) 프레임

    2) 스트림

    3) 서버푸시

    4) 헤더압축(HPACK)

3. 안티패턴

4. 결론

 

 

 

HTTP/2가 생긴 배경

TCP 스펙하의 HOL 블락킹 문제

TCP의 혼잡 회피 메거니즘에서, 느린시작의 문제

비대한 메세지 헤더

 

 

1. TCP 스펙하의 HOL 블락킹 문제

 

*HOL(Head of line) 블락킹 - 여러 입력 인터페이스에서 동일 출력 인터페이스로 패킷을 보낼 때, Switching Fabric 구간에서 이전 패킷이 처리 되기 까지 이후의 패킷이 블락킹되어 딜레이되는 것. (즉, 동일 시간 시점에서 먼저 들어온 것을 처리해야 다음 패킷을 처리할 수 있는 순차 처리 특성으로 인한 문제)

 

2. TCP의 혼잡 회피 메거니즘에서, 느린시작의 문제

혼잡 회피 메커니즘에서 혼잡 제어의 방식으로 혼잡 윈도우가 존재한다.

TCP의 스펙 특성상 느린시작이 발생한다.

 

TCP 전송 혼잡 제어, 느린 시작(지수증가 방식)

 

*혼잡윈도우(Congestion Window)- 수신자가 확인하기 전까지 발신자가 보낼 수 있는 패킷의 수가 정해져 있다.

 

3. 비대한 메세지 헤더

텍스트 구문 기반의 메세지 헤더는, 바이너리 구문 기반의 메세지 헤더보다 비대함.

네트워크 특성상 전송량과 대역폭에 영향을 받으므로 비대하면 비대할 수록 퍼포먼스가 떨어질 수 있음.

 

 

HTTP/2의 특징

프레임

스트림

서버푸시

헤더압축

 

 

1. 프레임

 

HTTP/2는 프레임형식의 프로토콜. 프레임이라는 형식 때문에 다중화 방식이 가능하다.

 

1) 프레임 형식

HTTP/2 RFC7540 Section 4.1 Frame Format

앞의 9byte만 읽으면 해당 프레임이 어떤 프레임인지 확인할 수 있다.

 

 

2) 프레임 bit 설명

 

(1) Length 

부호 없는 24비트 정수로 표현되는 프레임 페이로드의 길이.

수신자가 SETTINGS_MAX_FRAME_SIZE에 대해 더 큰 값을 설정하지 않는 한 2^14(16,384) 이상의 값을 전송해서는 안 된다.(MUST NOT)

 

(2) Types 

프레임의 8비트 타입.

프레임 타입은 프레임의 형식과 의미론을 결정한다.

구현은 반드시 알 수 없는 타입의 프레임을 무시하고 폐기해야 한다.(MUST)

 

(3) Flags

프레임 타입별 boolean 플래그용으로 예약된 8비트
플래그에는 표시된 프레임 타입에 특정한 의미론이 할당된다.
특정 프레임 타입에 대해 정의된 의미론이 없는 플래그는 무시해야 하며 전송 시 설정되지 않은 상태(0x0)로 두어야 한다.(MUST)

 

(4) R

예약된 1비트 필드.

이 비트의 의미론은 정의되지 않았으며, 전송 시 비트는 설정되지 않은 상태(0x0)로 유지되어야 하며, 수신 시에는 무시되어야 한다.(MUST)

 

(5) Stream Identifier

부호 없는 31비트 정수로 표현되는 스트림 식별자.([RFC7540] Section 5.1.1)

0x0 값은 개별 스트림과 반대로 전체적으로 연결과 연관된 프레임에 예약된다.

 

 

 

2. 스트림

 

독립적이고 양방향으로 교환되는 프레임 모음

독립적 : 응답/요청이 서로를 차단하지 않는다.(요청->응답->요청->응답 X)

양방향 : 응답/요청이 뒤섞여 있다.

 

 

1) 다중화

HTTP/2 다중화 예시

 HTTP/1.1에서는, 명세상 이전 요청 처리 후 다음 요청을 처리할 수 있는 순차적 특성(연결 당 한번에 하나의 응답만 전달되록 보장) 떄문에, 클라이언트가 커넥션을 병렬적으로 생성하고 운영하여 동시간에 여러 요청을 처리하였으나, TCP 스펙의 한계인 HOL 블락킹 문제 및 커넥션 비용 증대를 해결하기 위해 하나의 커넥션에 여러 처리 전 요청을 보낼 수 있도록 만들었다.

 

논리적 스트림 안에서 프레임 단위로 응답과 요청을 처리하기 때문에 요청과 응답이 뒤섞여있다.

프레임을 수신하는 발신자 또는 수신자가 프레임을 조립한다.

 

프레임의 특성으로 인해 청크 분할 인코딩이 별도로 필요가 없다.

 

2) 우선순위(가중치)

 스트림안에서 HEDERS와 PRIORITY 프레임을 통해 개체의 우선순위를 정할 수 있다.

 

3) 클라이언트 주도 흐름제어

 수신자가 과부화 상태인 경우 또는 일정 크기의 리소스만 할당하려는 경우, 수신자는 특정량의 데이터를 처리할 수 있다고 발신자에게 알려줄 수 있다.

 

 

3. 서버푸시

 

HTTP/2 간략 서버푸시 예시

 

클라이언트의 단일 요청에 여러 응답을 보낼 수 있는 것.

예시로 HTML을 요청하면 HTML에 작성된 의존하는 링크들의 데이터들을, 클라이언트의 별도 요청 없이 서버가 클라이언트에게 보낼 수 있도록 한다.

 

 

4. 헤더압축(HPACK)

 

 비대한 헤더문제를 줄이기위해, HPACK을 통한 헤더를 바이너리로 압축하여 전송되는 데이터의 양을 줄인다.

허프만코딩과 정적 테이블 가변 테이블 방식으로 압축을 한다.(이후 자세히)

 

 

안티패턴

 

1. 스프라이팅(Spriting)



 여러개의 이미지를 합쳐 큰 이미지로 만들어 CSS로 분할하여 로딩하는 방식이다

예시로, 과거에 아이콘이 담겨있는 하나의 이미지를 CSS로 쪼개서 사용했었음.

이유는 종단간 패킷 트래버설가 상당히 느리므로 여러 요청보단 단일 요청을 선호했었음.

다만 단점으로 독립적인 단일 캐싱이 불가능하다.

 

 

2. 도메인 샤딩

 

호스트 이름을 여러개 나누어 커넥션을 운영하여 콘텐츠를 병렬로 내려 받는 방식이다.

 

 

3. 결합

 

JS파일들을 하나로 결합 또는 CSS파일을 하나로 결합하는 방식이다.

Round-Trip 횟수를 줄이기 위해 파일을 결합 한다.

다만 단점으로 스프라이팅과 동일하게 독립적인 단일 캐싱이 불가능하다.

 

 

4. 인라이닝(Inlining)

 

HTML 파일에 JS 또는 CSS를 인라인 방식으로 작성하는 방식이다.

스프라이팅, 결합과 비슷한 문제를 가지고 있다.

 

 

결론

실제로 운영하다보면, HTTP/2의 모든 요청이 항상 성능 개선이 있는 것은 아니다.

특정상황에서는 1.x 프로토콜과 별 차이가 없을 수 있으며, 오히려 HTTP/2가 더 느릴 수 도 있다.

더 나은 퍼포먼스를 위해 항상 테스트하고 연구해야 하는 것은 당연한 것 같다.

 

Tag
0 Comments
댓글쓰기 폼