(네트워크) gRPC로 가는길(1) / HTTP의 역사(1.0, 1.1, 2.0)

MSA에서 사용하는 기술, gRPC.

 

컴포넌트 간에 통신을 위해서 사용됩니다.

 

왜 REST를 사용하지 않고 gRPC를 사용해서 통신할까요?

 

HTTP1.1을 사용하는 HTTP/REST와는 달리 gRPC는 HTTP 2.0을 사용하기 때문에 1.1 대비 빠른 속도를 가지고 있습니다.

 

그러니까 gRPC를 알기 위해서는 HTTP 2.0에 대해서 알아야 합니다.

2.0을 이해하기 위해서는 HTTP의 역사에 대해서 아는 게 도움이 되겠죠?

 

그러니 이 문서에서는 HTTP의 역사에 대해 다루겠습니다.

 

⚡️HTTP 0.9 - One line 프로토콜

---

HTTP 초기버전에는 버전 번호가 없었습니다. 

그러니까 그때 당시에는 HTTP를 사용한다고 말했을 뿐, HTTP0.9를 사용한다고 말하지 않았다는 것입니다.

 

HTTP 0.9가 원 라인 프로토콜이라고 불리는 이유는 오직 GET 메서드 만을 사용하고

요청하는 자원의 경로만 명시할 뿐 그 어떤 것도 존재하지 않았습니다.

 

GET /index.html

 

 

실제로 이게 전부입니다.

응답 역시 오로지 파일 내용 자체로 구성됩니다.

 

 

⚡️HTTP 1.0

---

HTTP 1.0은 0.9에서 보다 많은 것들이 생겨났습니다.

 

먼저 지원되는 메서드가 많아졌습니다.

 

메서드 지원

GET 만을 지원하던 0.9 버전과는 다르게 GET, HEAD, POST, PUT, DELETE 메서드를 지원합니다.

 

상태코드

0.9에서는 없었던 상태코드가 생겼습니다.

• 100 ~ 199번대:  정보 응답
• 200 ~ 299: 성공 응답
• 300 ~ 399: 리다이렉션 메시지
• 400 ~ 499: 클라이언트 에러
• 500 ~ 599: 서버 에러

 

헤더 도입

헤더의 도입으로 다양한 것들이 가능해졌습니다.

• Content-Type 구분을 통해서 HTML이 아닌 다른 형태의 문서를 전송할 수 있게 되었습니다.
• 헤더에 다양한 콘텐츠 전송 가능

 

 

⚡️HTTP 1.1

---

1.1 버전은 현재까지도 널리 사용되고 있는 버전입니다.

 

1.1 버전에는 다음과 같은 특징들이 있습니다.

 

persistent connection: 커넥션 유지 by keep alilve

커넥션을 닫지 않고 유지함으로써 기존의 TCP 연결 시간을 단축시킨 것입니다.

 

HTTP 1.0 버전의 경우 응답을 주면 커넥션이 닫히고, 다시 똑같은 URL로 요청해도 다시 TCP 연결을 해야 하는 문제가 있었습니다.

1.1 버전에서는 timeout옵션과 max request의 개수를 명시할 수 있어서, 그 시간 안에 이루어지는 max 이하의 requests에 대해서는 

커넥션을 유지한 채 통신을 할 수 있습니다.

 

pipelining: 흐름 개선

기존 HTTP 1.0의 경우에는 한 커넥션에서 응답을 받아야 만, 요청을 할 수 있었습니다.

 

1.1에서는 응답을 기다리지 않아도 요청을 할 수 있는 pipelining 기능이 도입됐습니다.

다만 요청에 대한 응답은 순차적으로 도착합니다.

 

 

Host Header 추가

HTTP 1.1이 되면서 host 헤더가 추가되었습니다.

이 덕분에 하나의 IP에 여러 개의 도메인을 호스팅 할 수 있게 되었죠.

 

이 것을 좀 자세히 설명하고 싶네요(왜냐면 제가 이해가 안 갔거든요)

 

HTTP1.0은 host가 없고 네트워크 계층에서 IP 헤더에 IP 주소를 담아서 요청을 처리하곤 했습니다.

OSI 7계층에 대한 이해가 없으신 분들 위해서 간략한 설명을 해드리면

 

인터넷의 요청은 계층이 내려가면서 응용계층(Application Layer) 메시지에 해더를 추가하면서

Link 계층까지 내려가는 것이 인터넷 통신의 방식입니다.

 

즉, 각각의 계층이 담당하고 있는 '책임'이 있고 이 '책임'에 대한 일만 수행할 뿐 그 외의 것에는 관여하지 않습니다.

 

그렇기 때문에 각 계층의 헤더에는 다른 정보가 적혀있고, IP 주소에 대한 정보는 Network 계층에서 담당합니다.

그러니까 TCP든 HTTP든 UDP든 IP 주소에 대해서는 알 도리가 없습니다. 알 필요도 없고요.

 

이 때문에 HTTP 1.0에서는 헤더에 host 이름을 알 수 있는 헤더가 없다 보니 오직 네트워크 계층에 의존해야 했습니다.

그러니 하나의 IP에 하나의 도메인만 할당할 수 있었던 것이죠.

 

 

그런데 HTTP 1.1이 되면서 HTTP 메시지에 host이름 즉 도메인 이름을 넣을 수 있게 되었습니다.

이 덕분에 HTTP 하나의 IP 주소에 호스팅 되고 있는 여러 개의 도메인 중 HTTP 헤더에 있는 Host와 연결할 수 있다는 것이죠.

 

메서드 추가

기존의 메서드에서 CONNECT, OPTIONS, TRACE, PATCH가 추가되었습니다.

특히 PATCH는 2010년이라는 늦은 시기에 추가되었습니다.

 

 

Chunked transfer encoding

이 방식은 본문 데이터를 여러 개의 덩어리로 분할하여 전송하는 방식입니다.

덩어리마다 크기를 헤더에 명시하고 그 끝을 CRLF로 표시해 전송합니다.

 

전송할 데이터의 크기를 미리 알 수 없을 때, 전체 다운로드 말고 일부만 다운로드하고 싶을 때 유용합니다.

 

 

 

⚡️HTTP 2.0

---

2015년 비교적 최근에서야 HTTP 2.0이 발표되었습니다.

HTTP2.0은 HTTP 1.1과 2.0 사이에 크고 작은 변화들을 모조리 흡수했습니다.

대표적으로 SSL/TLS가 있죠.

 

HTTP 2.0은 구글에서 HTTP 1.1의 단점을 개선하기 위해 만든 오픈소스 프로토콜인 SPDY를 기반으로 만들어졌습니다.

 

주요 특징은 다음과 같습니다.

 

Multiplexing

1.1에서 파이프라이닝을 기억하시나요? 파이프라이닝은 분명히 장점이 존재하지만 치명적인 단점이 있었습니다.

여러 개의 응답 중 처음 요청에 대한 응답이 만들어지는데 속도가 느리다면 뒤에 만들어지는 응답의 속도가 어떻든

전체 응답시간이 길어지는 문제가 있죠.

 

이 문제를 해결하기 위해서 Mutliplexing이 도입되었습니다.

 

Multiplexing은 하나의 TCP 연결에서 동시에 여러 개의 HTTP 요청과 응답을 처리할 수 있는 기술입니다.

즉, 각각의 요청과 응답이 모두 독립적인 스트림으로 처리될 수 있기 때문에 빠른 응답은 빠른 만큼, 느린 응답은 느린 대로 처리가 가능하죠.

 

 

하나의 스트림에 가중치를 부여에서 우선순위를 조절할 수도 있습니다. (Prioritization)

 

또한 하나의 연결에서 처리하기 때문에 TCP 연결을 자체를 줄여 보안상의 이점도 가져갈 수 있습니다.

 

Server push

서버 푸시 기능은 클라이언트가 요청하기 전 미리 클라이언트가 필요한 데이터에 대해서 서버가 데이터를 보내주는 기능입니다.

 

흔히 보이는 예시로 HTML 파일을 요청할 때 CSS파일과 JS파일을 함께 전송하는 것이죠.

 

 

헤더 압축

헤더 압축을 통해서 데이터의 절대적 양을 줄였습니다.

어떻게 압축할 수 있었을까요? 

 

HPACK이라는 알고리즘을 사용해서 이전에 전송한 헤더 정보를 기반으로 동작합니다.

ID와 정보를 가지고 있는 Key value 테이블에서 기존에 전송한 헤더의 경우 key만 담아서 전송하고,

새로운 헤더의 경우 key와 value를 담아서 전송하는 방식으로 헤더를 압축했습니다.

 

HPACK의 테이블은 정적 테이블과 동적 테이블을 사용합니다.

정적 테이블은 서버와 클라이언트가 모두 공유하며 HTTP 1.1에 사용되던 공통 헤더들이 미리 정의되어 있습니다.

 

동적 테이블은 가장 오래된 항목을 새로운 항목으로 대체하는 방식으로 사용되며 해당 헤더가 참조할 수 있는 이전 헤더의 인덱스를 함께 전송합니다.

 

 

 

BINARY Data

이전까지는 모두 텍스트 기반으로 동작했습니다.

이진 데이터로 전송으로 인해 더 빠른 속도로 전송할 수 있게 되었습니다. 

 

또한 더 적은 대역폭을 사용하기 때문에 낭비가 적습니다.

그리고 보안이 뛰어납니다.

 

 

TLS 기본 적용

HTTP 2.0은 TLS를 필수로 요구합니다. 그렇기 때문에 더 높은 보안 수준을 제공하죠.

 

 

⚡️정리

---

지금까지 HTTP의 0.9부터 2.0까지를 다뤘습니다.

 

이후 시간이 된다면 3.0까지 자세하게 다뤄보도록 하겠습니다.

 

다음 문서에서는 gRPC로 가는 길 두 번째 RPC에 대한 문서를 작성해 보겠습니다.

 

이 문서는 추후 HTTP 3.0에 대한 설명이 추가될지도 모릅니다.