TCP 방식의 메시지 설계시 어떤 주의점이 있는지 궁금합니다.
조회수 3167회
안녕하세요. 이때까지 HTTP로만 작업을 진행해 왔는데요. TCP로 포팅을 시도하고 있습니다. 문자, 이미지 송수신, 보안지원에 적용하고 싶은데요.
HTTP는 문자기반이라 JSON을 이용하면 메시지 설계가 그냥 되는데요. TCP는 JSON, XML 같은 문자기반 패키징을 이용할 수 없을 것 같고 바이너리로 가야 할 거 같은데요. 이러면 구분자로 뭘 적어야 하나... 감이 안옵니다. 제맘대로 규칙을 정하면 또 현실과 동떨어질 것 같고 해서 실무에서는 어떻게 하시는지요. 그리고 듣자하니 HTTP방식의 설계가 오랜기간동안 검증된 방법이어서 뻑나는 거에 무감각했었다면 TCP 메시지 설계 또한 안정적으로 설계하지 못하면 뻑이 난다고 하는데요. 고민이네요. 감사합니다.
아 그리고 문득 드는게 HTTP 오버헤드란게 솔직히 제 실력이 부족해서 헤더 몇개 안쓰기 때문에 적게 느껴지는 것일 수도 있지만 그냥 GET방식이나 POST방식이라도 헤더 최소화 하면 그게 TCP랑 비교해서 오버헤드가 그렇게 차이가 많이 나나요? 기껏해야 몇자 더 적는거 아닌가요? 감사합니다.
-
(•́ ✖ •̀)
알 수 없는 사용자
1 답변
-
제 경험에서는 대부분의 경우 프로토콜(HTTP) 자체가 오버헤드가 되는 경우는 거의 없었습니다. 대부분의 병목은 DB에서 왔습니다.
HTTP를 쉽게 처리 가능한 이유는 서버(tomcat)/클라이언트(chrome) 등에서 반복되는 많은 부분을 사용하기 쉽게 잘 구현해 놨기 때문에, 인코딩/디코딩, 직렬화, 에러/예외 처리 등이 사용자(개발자) 영역까지 넘어오지 않기 때문입니다. 이 말은 반대로 직접 구현할 경우 위 부분을 손수 다 개발해야 한다는 뜻 입니다.
분야에 따라 다르겠지만 제 경험에 한해서는 실무에서도 바이너리 프로토콜을 직접 다루는 일은 많지 않았습니다.
직접 작성하게 된다면 protobuf, thrift 등과 같이
binary <-> structured data
를 상호 변환해 주는 라이브러리를 사용해서 프로토콜을 작성하고, 여기에 Netty같은 네트워크 프레임워크를 붙여서 서버/클라이언트를 구현하는게 일반적인 패턴인거 같습니다.직접 구현하는게 어렵고 버그 발생 확률이 많은걸 차치하더라도 얻는 것에 비해서 생산성 측면에서 마이너스가 많습니다. (RAW_TCP로 서버를 작성하시면 클라이언트도 직접 구현해야 합니다.)
최근 많은 모바일 게임들이 HTTP를 기반으로 서버를 구현하는 이유도 여기에 있습니다.
p.s: HTTP는 문자 기반 프로토콜이 아닙니다.
-
(•́ ✖ •̀)
알 수 없는 사용자 -
(•́ ✖ •̀)
알 수 없는 사용자 - 〉
-
댓글 입력