본 게시글은 경희대학교 이성원교수님의 '풀스택 서비스 네트워킹' 강의를 바탕으로 작성되었습니다.

Web?

누가 왜 만들었나

팀 버나스 리(Tim Berners Lee) - 유럽 입자 물리 연구소(CERN)의 컴퓨터과학자이자 영국 옥스포드 대학 교수
1989년 3월, 연구자들 간 신속한 정보교환(문자, 사진, 동영상, 음성 등)과 공동연구를 위한 프로그램으로 만들어진 것이 web!

그런데 ... 사람들이 이렇게 다양한 용도로 인터넷을 사용할 줄 몰랐다.
다양한 용도로 사용하면서 HTTP1의 한계점이 드러난다.

HTTP/1.1의 문제점

1. Head of Line(HoL) Blocking
2. Fat message headers
3. Limited Priorities
4. Client-driven Transmission

1. Head of Line(HoL) Blocking

클라이언트가 서버로 여러개의 요청을 보냈을 때, 서버는 클라이언트에게 요청 받은 순서대로 응답을 보내야 한다. 예를들어 1,2,3의 요청을 서버가 받았다고 하자. 그랬을 때, 서버는 꼭 1,2,3 순서대로 응답을 보내야 하는 것이다.
이때, 만약 서버가 1의 요청을 처리하는 데에 문제가 생기면, 2,3번째 요청에 대한 응답 모두 클라이언트에게 전송되지 못하고 지연(Blocking)된다.
이를 Head of Line Blocking, 그러니까 앞쪽 요청이 처리되지 못하여 발생하는 지연(Blocking)이 된다.
이는 상업적 입장에서 회사가 서비스할 때 고객이 해당 서비스를 사용하는데에 문제를 일으키게 된다.

2. Fat message headers

통신 속도가 원만하지 않은 곳에서 인터넷을 하는 것은 힘들다. HTTP/1.1의 헤더에는 많은 메타 정보들을 저장하는데, HTTP 메시지는 앞 메시지와 뒷 메시지가 독립적이기 때문에 별도의 설정을 하지 않으면 클라이언트가 요청을 보낼 때마다 똑같은 헤더 값을 여러 번 보내게 된다.
또한 웹브라우저위에서 돌아가는 프로그램은 컴퓨터 디스크 등에 접근이 불가하여 임시로 정보를 저장하기 위해 쿠키를 사용한다. 그런데 이 쿠키 정보(해당 도메인에 설정된)도 클라이언트가 요청할 때마다 헤더에 담겨서 전송된다. 그러다보면 내가 실제로 전송하려는 값보다 헤더 값이 큰 경우도 발생한다.

3. Limited Priorities

서버가 클라이언트에게 정보를 줄 때, 모든 정보가 동일한 우선순위는 아니다. 몇몇 객체는 다른 것보다 더 중요한 것들이 있다. 그런데 HTTP/1.1에서는 이런 우선순위가 존재하지 않는다.

4. Client-driven Transmission

HTTP/1.1는 클라이언트가 요청 보내고 서버가 응답하는 방식이다. 따라서 클라이언트가 서버로 정보를 요청하지 않으면 서버가 정보를 전달할 수 없다.

HTTP2의 이해

HTTP2의 시작 : Google SPDY(Proprietary Solution)

SDPY?

웹 콘텐츠 전송을 위해 구글이 개발한 비표준 네트워크 프로토콜이다. 이는 웹 페이지 전송 지연을 줄이고 웹 보안을 개선하기 위해 만들어졌으며, 압축, 다중화, 우선순위 설정 등을 통해 전송 지연을 감소시켰다.
이는 application layer에서 HTTP와 TLS사이에 끼워져 사용하며, SSL/TSL로 암호화 되지 않은 연결은 지원하지 않는다. 이는 중간에서 전달되는 정보를 보고 어떤 정보인지 알 수 없게 한다.

연혁

2009년 구글 내부 프로젝트로 공개
2010년 크롬브라우저의 오픈소스 엔진에 탑재
2011년 구글의 모든 서비스에 도입
2012년 아파치 서버용 구글 SPDY패치 제공 & Nginx의 지원 공개
2012년 IETF 단체를 통한 표준화 추진
2015년 HTTP/2가 RFC 7540 표준화 되면서 SPDY 중단 : SPDY가 HTTP2로!!

해당 페이지에 접속하면 HTTP2의 공식 문서를 확인 할 수 있다.
HTTP2 공식 문서

HTTP2 사용 현황

전 세계 웹사이트의 45.9%가 HTTP/2 사용 중이다.

HTTP2의 주요 목표

• 줄어든 지연 시간** 가장 중요
• 응답 다중화 지원
• HTTP 헤더 필드를 압축하여 프로토콜 오버헤드 최소화
• 요청 별 우선순위 지정 추가
• 서버 푸쉬
• 기존 어플리케이션의 수정 없는 지원 : HTTP method, 상태 코드, URI 및 헤더 필드 등 지원