TCP/IP Socket vs RESTful API vs gRPC vs WebSocket

들어가면서

서버에서 클라이언트 혹은 다른 서버와 통신하는 방법으로 여러가지가 있지만 그 중에서 TCP 상에서 IPC를 위해 자주 사용되는

TCP/IP Socket, RESTful API, gRPC, WebSocket의 차이를 공부하고자 한다

 

프로세스는 기본적으로 상호독립적으로 가동되기 때문에 서로 메모리를 공유하지 않고, 서로 간섭하지 않는다.

그렇기 때문에 프로세스간의 정보교환이 이루어져야 할 때의 방법 중 하나가 IPC이다.

 

서버는 각 클라이언트와 일대일 혹은 일대다의 관계를 가지며

 

일대일의 경우 Request/Response, Notification이 통신에 사용되며,

일대다의 경우 Publish/Subscribe 구조를 가지게 된다. (다른 경우도 있지 않을까?)

 

 

 

 

TCP/IP Socket

TCP/IP Socket은 어플리케이션 계층에서 전송 계층 내의 TCP를 이용하여 통신하기 위한 수단으로, 통신에 대한 접속점을 역할을 하는 통로이다. 소켓이기 때문에 장애나 명령이 떨어지기 전까지 지속적으로 연결을 유지하고 있으며 데이터를 통신한다.

컴퓨터 네트워크 수업에서 자주 봤던 그 기능들

IPC를 컴퓨터 내부가 아닌, 네트워크 범위에서 적용하여 네트워크간 통신을 이루어주지만, 통신과정 전반을 개발자가 직접 구현해야하고, 통신 관련 장애를 직접 핸들링 해주어야한다.

 

또한, RESTful API와는 다르게 연결 기반 프로토콜이기 때문에 데이터를 지속적으로 주고 받으며 상대방의 정보를 가지고 있다.

RESTful API와 gRPC 등 여러 통신 방식의 기반으로 사용된다.

 

 

 

 

RESTful API

RESTful API는 HTTP상의 많은 부분에서 사용되는 IPC 방법으로, 자원을 URI로 표현하고 HTTP method를 통해 처리하는 방식을 사용한다. HTTP method에는 대표적으로 GET,POST,PUT,DELETE가 존재하며 용도에 따라 달리 사용된다.

 

TCP/IP Socket을 기반으로 동작하며 HTTP 특성을 따라가기 때문에 무상태성과 비연결성의 특징을 가지고 있어 상대방의 정보를 가지고 있지 않는다. method를 사용하여 의도하는 바를 쉽게 나타낼 수 있고 모든 플랫폼에서 사용이 가능하여 용이하다.

 

 

 

 

gRPC

gRPC에 대해 알기 위해서는 RPC와 Protocol Buffers에 대해 먼저 알아야 한다.

 

RPC와 Protocol Buffers란?

Protobuf(Protocol Buffers)와 RPC

gRPC는 구글에서 개발한 다양한 환경이든 실행할 수 있는 고성능 오픈소스 RPC 프레임워크이다.

스트림 기반 프로토콜인 HTTP/2 프로토콜을 기반으로 동작하며 HTTP/2 프로토콜은 바이너리 프로토콜이다.

 

TCP/IP Socket을 기반의 IPC 기술이며 여러 개의 데이터 스트림을 동시에 처리할 수 있기 때문에 기존의 RESTful API나 RPC 프레임워크와 비교해 빠른 전송 속도를 보장한다.

 

동시에 1개의 세션으로 여러 요청을 순서에 상관없이 스트림으로 받아 처리하고 응답할 수 있다. 특정 요청이 먼저 끝나면 해당 요청에 대해 먼저 응답해버리기 때문에 HOL Blocking(가장 앞선 요청에 대한 응답이 지연되어 이후 응답도 지연되는 현상)이 발생하지 않는다.

 

대신 각 요청에 우선순위를 부여하여 데이터를 보낼 수 있고, 헤더를 허프만 코딩을 사용하여 압축하고 바디는 Protobuf를 이용해 크기가 작아지기 떄문에 작은 패킷을 보내 더욱 짧은 시간내에 통신할 수 있게 된다.

 

서버 측에서 정의한 서비스 규격에 따라 인터페이스를 구현하고, gRPC 서버를 실행하여 클라이언트 호출을 처리하여 원격에 있는 어플리케이션의 메서드를 로컬 메서드인 것처럼 직접 호출할 수 있기 때문에 분산 어플리케이션 서비스를 보다 쉽게 만들 수 있다.

(메세지 지향 통신 - 데이터 형식이나 구조를 미리 약속하고, 그 약속된 구조에 맞게 데이터를 송수신)

 

그렇지만 HTTP 기반이기 때문에 RESTful API와 유사한 아키텍처를 가지며 무상태성이기 때문에 요청과 응답 사이에 세션 상태를 유지하지 않는다.

 

 

 

 

WebSocket

RESTful API는 HTTP상의 많은 부분에서 사용되는 IPC 방법으로, 자원을 URI로 표현하고 HTTP method를 통해 처리하는 방식을 사용한다. HTTP method에는 대표적으로 GET,POST,PUT,DELETE가 존재하며 용도에 따라 달리 사용된다.

 

웹소켓은 HTTP 프로토콜 위에 실시간 양방향 통신 기능을 추가한 프로토콜로 ws/wss 프로토콜 위에서 동작한다. HTTP의 헤더를 Upgrade해서 동작하기 때문에 서버나 클라이언트는 전이중 양방향 통신을 수행하며 언제든지 메시지를 보낼 수 있다.

 

이렇게 보면 TCP/IP Socket과 WebSocket의 차이가 무엇인지 모를 수 있다.

 

TCP/IP Socket은 인터넷을 통한 통신을 위한 프로토콜이기 때문에 소켓을 이용하여 양 끝단의 IP/Port 번호를 이용해 연결을 수립하고 데이터를 주고 받고, 데이터의 신뢰성을 보장한다. 기본적으로 네트워크 레이어에서 동작하기 때문에 단순한 바이트 스트림을 통해 전송할 수 있는 데이터만 다루어야 한다.

 

WebSocket 또한 양방향 통신이 가능하지만, WebSocket은 HTTP위에서 동작하기 때문에 어플리케이션 레이어에서 동작하며

기존의 HTTP는 단방향 통신으로 실시간 통신이 불가하기 때문에 웹 상에서 소켓처럼 커넥션을 유지하고자 나온 것이다. 7계층에 기반하기 때문에 메시지 형식의 데이터를 다루게 된다.

 

목적과 특성이 달라 상황에 따라 적합한 프로토콜을 선택하여야 한다.

 

 

 

 

마치며

gRPC에서 사용되는 Protocol Buffers는 데이터를 바이트 스트림으로 직렬화하여 HTTP/2 상에서 전송을 하는데, 

HTTP는 기본적으로 양방향 통신이 아니기 때문에(그렇다고 불가능한 것은 아니다) 매우 빠른 통신이 필요한 서비스(게임과 같은)에 적합하지 않다. 

 

TCP/IP Socket은 네트워크 레이어(L4)에서 동작하기 때문에 바이트 스트림을 전송할 수 있고,  Protocol Buffers는 데이터를 바이트 스트림으로 직렬화하기 때문에 이를 동시에 사용하면 지속적으로 연결된 매우 빠른 통신을 이용할 수 있다.

 

하지만 클라이언트와 서버 간의 통신 규약을 직접 정의하고, 프로토콜 스택도 직접 구현해야 하는 단점이 있다.