얼마 전 좋은 제안을 받았다. 본인이 하고 있는 웹 앱 프로젝트가 있는데, 프론트엔드로 참여하겠냐는 제안이었다.
나는 한 우물에 집중하는 편인지라, 현재 기업에서 일하고 배우는 것을 중점적으로 하기에 벌써 사이드 프로젝트를 진행하는 것은 좋지 못하다 생각이 들어 거절했다.
그 프로젝트에는 여러 개발자들이 참여한다고 들었다. 주로 게임 개발자들이 많다고 하는데, 그들은 개발을 해온 삶이 게임에 치중되어 있었을 테고, 게임에서 사용하는 통신이나 툴을 웹에도 이용하면 더 효율적이라 생각하고 있는 듯 했다.
그 중 흥미로운 주제는,,
"아니 http를 왜 쓰는 거예요? 그냥 tcp쓰면 되지 않나요?" 라는 주제였다.
사실 현재 재직 중인 기업에서 Netty를 이용해 tcp 서버를 구현해본 내 입장에서는,,
"..그러게?" 라는 느낌이었다.
이 전에 타 사와 협력하는 프로젝트 진행 중, 상대 기업 보안이 까다로워 통신 호스트에 대해 모두 조사해야하는 업무가 있었는데, WireShark라는 툴을 통해 http 요청을 깊이 까본 적이 있었다.
결국 http도 tcp 기반 통신이기에, 굳이 몇 계층의 귀찮은 동작 대신 tcp를 사용하면 되지 않나..? 라는 단순한 생각이 먼저 들었다.
사실 그 단순한 생각에서 흥미가 생겨 이렇게 오랜만에 글을 써본다.
결론적으로, 웹과 같이 단순한 데이터 교환을 위한 연결은 http가 좋다.
그리고 게임과 같이 실시간 통신이 필요하다면 tcp 혹은 udp 통신이 좋다.
먼저 각 통신의 특징에 대해 간략하게 작성해보겠다.
1. HTTP 통신
웹 서버 - 웹 클라이언트 간 통신을 위해 디자인 된 프로토콜로, 클라이언트의 요청 및 서버의 응답 처리 방식으로 통신한다. 기본적으로 무상태(stateless) 프로토콜이기에 서버는 요청 간 상태 유지를 하지 않는다.
http header를 통해 통신 방법(메서드), 캐시, 쿠키, 데이터 타입 등의 정보를 담는다.
- 무상태성(요청 - 응답 후 통신 끊음)
- http 헤더
2. TCP 통신(socket)
tcp 통신은 클라이언트와 서버, 혹은 각기 다른 두 프로그램이 양방향으로 통신할 수 있는 프로토콜 방식이다. 3-way handshaking을 통해 통신 상태를 확인한 후 가능하면 연결을 유지하여 실시간 통신을 하는 프로토콜이다.
Port, 시퀀스 번호, 데이터 오프셋 등을 지니는 헤더를 담는다.
- 연결 유지
- 양방향 통신
- tcp 헤더
그냥 간단히 내가 알고 있는 http, tcp 통신의 특징을 적어봤다.
http 프로토콜은 tcp/ip 4계층에서 4계층인 application layer에 해당하며, 결국 tcp 프로토콜이 정의되어 있는 3계층 transport layer를 통한다. 더 깊이 들어가면 주제와 멀어지기에 개념은 이 정도로만 하고,
먼저 헤더라는 것은, OSI 7계층에서 각 계층마다 데이터 처리, 연결을 위한 사용 설명서? 표지판? 같은 것이다.
tcp 통신 헤더에서는
어떤 포트에서 왔는지, 어떤 포트로 가야하는지 담게 되며,
데이터 손실을 줄이기 위해 데이터를 분할하여 전송하다보니, 현재 세그먼트(원래 데이터를 나눈 데이터의 단위를 세그먼트라고한다)가 어느 순서에 해당하는 세그먼트인지,
세그먼트들이 쭉 날라오면 어디부터 데이터 시작점인지와 같은 정보들이 담긴다.
http 통신 헤더에서는
어떤 엔드포인트로 가야하는지(/ 뒤에 붙는 것들),
이 요청과 응답이 무슨 방식으로 사용되는 지(http 메서드) 등의 정보가 담긴다.
개념적 정리는 이쯤하고, 주제로 돌아와 다시 보면,
"아니 http를 왜 쓰는 거예요? 그냥 tcp쓰면 되지 않나요?"
라는 주제는 특징을 정리하다보니 답이 나온 것 같다.
개발자 입장에서 웹에서 tcp 통신을 사용할 경우 transport계층보다 상위 계층들의 모든 header와 연결 처리를 직접 구현해야한다.
(http 통신을 사용할 경우 OS에서 알아서 처리한다.)
또한 연결을 유지하는 통신이다보니, 데이터 통신 속도는 http보다 빠를지 몰라도 유지하는 만큼 resource 소비가 더 크다.
