From 4386f3dfdc572cc77cd51dd81a4c53ffcb5c0e00 Mon Sep 17 00:00:00 2001 From: Diger Date: Sat, 10 Feb 2024 17:00:00 +0900 Subject: [PATCH] =?UTF-8?q?=EA=B8=B0=EB=B3=B8=EC=9D=B4=20=EC=A4=91?= =?UTF-8?q?=EC=9A=94=ED=95=98=EB=8B=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2024-02-01-Easel-TwitterCloneProject.md | 71 +------------------ 1 file changed, 1 insertion(+), 70 deletions(-) diff --git a/_posts/2024-02-01-Easel-TwitterCloneProject.md b/_posts/2024-02-01-Easel-TwitterCloneProject.md index 740e133..a0fad30 100644 --- a/_posts/2024-02-01-Easel-TwitterCloneProject.md +++ b/_posts/2024-02-01-Easel-TwitterCloneProject.md @@ -53,76 +53,7 @@ mermaid: true # gRPC -- [참고자료](https://medium.com/naver-cloud-platform/nbp-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%9D%90%EB%A6%84-grpc-%EA%B9%8A%EA%B2%8C-%ED%8C%8C%EA%B3%A0%EB%93%A4%EA%B8%B0-1-39e97cb3460) - -- [참고자료](https://medium.com/naver-cloud-platform/nbp-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%9D%90%EB%A6%84-grpc-%EA%B9%8A%EA%B2%8C-%ED%8C%8C%EA%B3%A0%EB%93%A4%EA%B8%B0-2-b01d390a7190) - -- [참고자료](https://medium.com/@lchang1994/deep-dive-grpc-protobuf-http-2-0-74e6295f1d38) - -## gRPC 등장 배경 - -### IPC (Inter Process Communication 프로세스 간 통신) - -운영체제에는 IPC기법이 있다. 이 방식으로 서로 다른 서버간의 프로세스끼리 통신을 하며 정보를 교환할 수 있다. - -IPC 기법에는 소켓, 공유 메모리, PIPE, 메시지 큐 등 여러가지 기법이있다. - -그 중 소켓 통신은 E2E를 직접 연결하여 데이터를 스트리밍하며 받는 형태로 통신하기 때문에 통신간에 발생하는 예외처리, 주고받아야할 데이터가 방대해질 때의 후처리가 매우 어렵기 때문에 확장성 측면의 불편함이 있다. - -### RPC (Remote Procedure Call 원격 프로시저 호출) - -이러한 IPC의 단점을 조금 더 완화하고자 RPC기법이 등장했다. - -RPC는 네트워크 상으로 연결된 원격 서버의 함수를 호출 할 수 있도록 해서 네트워크 통신을 위한 작업을 고려하지 않도록할 수 있고 통신이나 call 방식에 신경쓰지 않고 원격지의 자원을 사용할 수 있다. - -RPC에는 `Stub`이라는 주요 개념이 등장한다. `Stub`이란 Client와 Server간의 데이터를 각 환경에 맞게 변환해주는 것이다. - -만약 `Stub`이 없다면 - -- Client와 Server는 전혀 다른 메모리 공간을 사용하고 있기 때문에 Client측 에서 가리키던 포인터가 Server측으로 넘어가게 되면서 전혀 다른 곳을 가리키게된다. -- Client는 리틀 엔디안 형식을 사용하지만 Server측은 빅 엔디안 형식을 사용한다는 경우 의도와 다르게 동작할 것이다. - -이러한 이유들로 각 데이터들은 `Stub`을 거쳐 Packet의 형태로 전달된다. - -## gRPC - -구글에서 개발한 프레임워크이다. PB(Protocol Buffer, 프로토콜 버퍼)기반 Serizlaizer에 HTTP/2를 결합한 RPC 프레임워크이다. - -![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*h3yN3b0M-G1uLCRSR7YBzA.png) - -### HTTP/2 - -우리가 일반적으로 사용하는 HTTP/1.1은 기본적으로 클라이언트의 요청이 올때만 서버가 응답을 하는 구조로 매 요청마다 Connection을 생성한다. Cookie등 메타 데이터들을 저장하는 무거운 Header가 요청마다 중복 전달되어 비효율적이고 느린 속도를 가진다. - -HTTP/2에서는 한 Connection으로 동시에 여러 개 메시지를 주고 받으며, Header를 압축하여 중복 제거 후 전달하기에 HTTP/1.1에 비해 효율적이다. 클라이언트 요청 없이도 서버가 리소스를 전달할 수도 있기 때문에 클라이언트 요청을 최소화 할 수 있다. - -- HTTP 1.1과 HTTP 2.0의 주요한 차이점은 HTTP 메세지가 1.1에서는 TEXT로 전송되었던 것과 달리, 2.0에서는 Binary Frame으로 인코딩되어 전송된다는 점이다. - -### ProtoBuf (Protocol Buffer, 프로토콜 버퍼) - -Google에서 개발한 구조화된 데이터를 직렬화(Serialization)하는 기법이다. 직렬화란, 데이터 표현을 바이트 단위로 변환하는 작업으로 아래 그림처럼 같은 정보를 저장해도 - -**TEXT기반인 JSON**의 경우 `82Byte`가 소요되는데 **직렬화 된 Protocol Buffer**는 필드 번호, 필드 유형 등을 1Byte로 받아서 식별하고, 주어진 length 만큼만 읽도록 하여 `33Byte`만 필요하게 된다. - -![](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*EqWBu3VDbav3svJk) - -### Base 128 Varint - -[Protobuf-guide](https://protobuf.dev/programming-guides/encoding/)에 따르면 프로토버퍼는 기본 인코딩 기법으로 Base 128 Varints라는 인코딩 형식을 사용하여 데이터를 압축적으로 표현할 수 있다. - -Varint는 가변 길이의 정수를 인코딩하는 방식으로 1~10Byte의 길이를 가지고 그 크기는 인코딩하려는 값에 따라 달라진다. - -Varint 인코딩 방식은 다음과 같다. - -- 각 바이트의 최하위 7비트는 정수의 일부를 나타낸다. -- 각 바이트의 최상위 비트는 다음 바이트가 더 있음을 나타낸다. -- 숫자는 7비트 단위로 나누어져 있으며, 최하위 그룹부터 시작하여 최상위 그룹까지 인코딩된다. - -- 예를 들어, 숫자 300을 varint로 인코딩하면 - - 300 = 2^8 + 44 - - 300은 두 바이트로 인코딩된다 : [1000 1100, 0000 0010] - -이러한 방식은 작은 숫자를 효율적으로 인코딩하며, 네트워크를 통한 데이터 전송을 최적화하는 데 도움이 됩니다. +[gRPC](https://k-diger.github.io/posts/gRPC/) ---