오늘의 질문
📍 정답 확인
HTTP/1.1
지속 커넥션 (Persistent Connection)
HTTP/1.0 의 경우에는 한 개의 요청과 응답마다 TCP 커넥션을 생성하여 통신했다. 하지만 이러한 방식은 매 요청마다 연결을 생성하는 오버헤드가 발생한다. HTTP/1.1 은 이러한 문제를 지정한 타임아웃만큼 커넥션을 종료하지 않는 방식으로 해결한다.
파이프라이닝 (Pipelining)
요청의 응답 지연을 감소시키는 기술. 파이프라이닝에서 HTTP 요청은 연속적이며, 순차적으로 전달된다. 기존에는 요청한 이후에 응답을 기다리고 그 다음 요청을 보냈는데, 파이프라이닝에서는 요청을 순차적으로 서버로 전송한 다음 모든 요청에 대한 응답은 한 번에 기다린다.
문제점
HTTP/1.1 은 1.0 버전에 비해 상당히 개선됐지만 여전히 문제가 있다. 대표적으로 Head-of-Line Blocking (HOL Blocking) 문제가 있다. 만약 3개의 요청을 파이프라인을 통해 전송했다고 했을 때, 서버는 모든 요청을 순서에 맞춰 응답해야 한다. 이때 첫 번째 요청이 오래 걸린다고 하면 나머지 요청은 첫 번째 요청의 처리를 기다려야 한다.
또한, 1.1 버전은 매 요청마다 동일한 헤더를 반복해서 전송한다는 문제점도 있다.
HTTP2.0
데이터 형식의 변화
HTTP/1.1 은 메시지를 일반 텍스트 형식으로 전송했다. 2.0 버전 부터는 기존 HTTP 메시지를 프레임이라는 단위로 분할하고 이를 바이너리 형태로 만들어서 전송한다. 따라서 기존 1.1 버전에 비해 파싱 및 전송 속도가 향상되었다.
멀티플렉싱 (Multiplexing)
하나의 커넥션을 사용하여 요청과 응답을 병렬로 처리할 수 있는 방식이다. 클라이언트가 서버로 여러 요청을 동시에 보내도 각 요청이 독립적으로 처리되기 때문에 애플리케이션 레이어의 HOL Blocking 문제를 해결할 수 있다. 또한 HPACK 압축 방식을 사용해 반복되는 헤더를 효율적으로 관리하여 대역폭 사용이 최적화되었다.
정리
| 특징 | HTTP/1.1 | HTTP/2.0 |
|---|---|---|
| Connection | Persistent Connection | Persistent Connection + Multiplexing |
| Request Handling | 요청이 순차적으로 처리됨 | 요청을 동시에 처리함 (Multiplexing) |
| Header Compression | 없음 | HPACK 으로 헤더 압축 |
| Protocol | 텍스트 기반 | Binary 기반 |
Server Push *1 | 없음 | 있음 |
*1 : Client 가 요청하지 않은 리소스도 Server 가 미리 전송할 수 있게 한다.
🚀 심화 내용 - gRPC
REST API 의 단점
MAS 구조에서 서버 간 통신을 HTTP/2.0 로 변경하면 어느정도 성능을 향상시킬 수 있지만, REST 통신을 하게 되면 JSON 으로 인한 성능 문제가 발생할 수 있다.
직렬화/역직렬화
JSON 은 텍스트 기반의 데이터 포맷으로, 네트워크 효율성이 떨어진다. 직렬화/역직렬화 과정에서 CPU 사용량이 많이 필요하여 MSA 간의 빈번한 데이터 교환이 있다면 성능 저하로 이어질 수 있다.
타입 제약
JSON 은 복잡한 데이터 구조나 날짜, 시간, 이진 데이터를 처리할 때 추가적인 파싱이나 인코딩이 필요하다.
데이터 중복
필드를 key-value 쌍으로 표현하여 여러 개의 필드를 가진 객체에서 필드 이름이 반복되면 데이터 크기가 증가한다.
gRPC 에서 REST 의 단점을 어떻게 해결 했을까 ?
protobuf (protocol buffers) 로 JSON 성능 문제를 해결했다.
- Google 이 개발한 언어 중립적이고 플랫폼 중립적인 데이터 직렬화 포맷이다.
- 다양한 프로그래밍 언어에서 동일한 스키마 파일 (proto 파일) 을 통해 데이터르 직렬화하고 역직렬화한다.
- gRPC 는 이 프로토콜을 활용해서 서버와 클라이언트 간의 효율적인 데이터 통신을 지원한다.
🔖 참고자료