TCP / IP 응용 프로그램과 HTTP 응용 프로그램 비교 [닫기]


13

Java로 작성된 대규모 사용자 관련 웹 사이트를 개발하고 싶습니다.

디자인과 관련하여 필자는 기본 웹 응용 프로그램의 데이터 공급자로 작동 할 수있는 독립적 인 모듈 식 서비스를 개발하려고합니다.

이러한 모듈 식 서비스 (데이터 제공 업체)를 작성하는 경우 Spring과 같은 기존 프레임 워크를 활용하고 RESTful 디자인 패턴에 따라 이러한 서비스를 개발하고 JSON과 같은 메시지 형식으로 HTTP를 통해 리소스를 노출하거나 기존 네트워크를 활용할 수 있습니다. Netty ( http://netty.io/ )와 같은 프레임 워크 및 Protobufs ( https://developers.google.com/protocol-buffers/docs/overview )와 같은 직렬화 형식 및 직렬화 된 프로토 타입을 주고받는 TCP 서버 개발 유효 탑재량.

언제 다른 것을 선택해야합니까? Protobufs와 같은 직렬화 형식을 사용하고 유선으로 바이트 스트림을 전송하면 어떤 이점이 있습니까? JSON을 사용하는 데 오버 헤드가 있습니까? TCP / IP 사용과 HTTP 사용 사이에 얼마나 많은 오버 헤드가 있습니까? 언제 그런 서비스를 구축하기 위해 Spring over Netty를 사용해야합니까?


실제 요구 사항보다 기술 스택에 대해 더 많이 생각하는 것처럼 들립니다. 어떻게해야하는지 모른 채이 질문에 어떻게 대답 할 있습니까? 지연 시간이 거의없는 멀티 플레이어 게임을 만들고 있습니까? 또는 대부분의 액세스가 이미 HTTP를 통해 이루어지고 한 번에 몇 시간 동안 데이터를 캐싱하고 대기 시간은 물론 신선도에 신경 쓰지 않는 소셜 북마크 응용 프로그램입니까?
Aaronaught

3
나는 OP가 우리에게 그를 선택하도록 요구한다고 생각하지 않습니다. 그는 그러한 선택이 어떻게 이루어지고 어떤 요소가 고려되는지에 대해 간단히 질문하고있다. 그것에 대한 높은 수준의 답변을 제공하는 데 잘못이 있다고 생각하지 마십시오 .... 그리고 나는했습니다.
DXM

나는 실제로 당신이 정말로하지 않는 한 바이너리 형식을 사용하는 것에 반대합니다. 이진 파일 형식, 이진 직렬화 등이 없습니다. 예를 들어 Java에서 이진 직렬화는 Java 버전과 자체 소프트웨어 버전간에 비 호환성을 유발하지만 XML은 그다지 많지 않다고 생각합니다. 나는 다음 TCP / IP> HTTP> XML을 생각할 것입니다. 물론, 당신이하는 일에 달려 있습니다. JSON이 XML의 대안이라고 생각합니다. Spring 또는 Netty에 대해서는 잘 모르지만 사람들이 Spring을 사용하고 있다는 것을 읽습니다.
Kaydell

+1 DXM, 나는 그러한 결정을 내릴 때 생각할 음식으로 높은 수준의 질문을합니다.
HiChews123

답변:


21

바이너리 프로토콜을 사용하여 JSON over REST vs. TCP / IP를 사용하는 것에 대한 장단점이 분명히 있으며 바이너리 프로토콜이 더 빠를 것이라고 이미 생각하고 있습니다. 나는 당신이 얼마나 빨리 더 빠를 지 말할 수는 없지만 (그리고 이것은 많은 요소에 달려있을 것입니다) 1-2 크기의 차이가있을 것입니다.

언뜻보기에 어떤 것이 다른 것보다 10-100 배 느리면 무릎이 부딪 히고 "빠른 것"으로 갈 수 있습니다. 그러나이 속도 차이는 프로토콜 자체에만 있습니다. 서버 측에 데이터베이스 / 파일 액세스가있는 경우 선택한 전송 계층의 영향을받지 않습니다. 경우에 따라 전송 레이어 속도가 훨씬 덜 중요해질 수 있습니다.

HTTP REST와 JSON은 여러 가지 이유로 좋습니다.

  • 그들은 거의 누구나 쉽게 소모품을 사용할 수 있습니다. 웹 응용 프로그램을 작성한 다음 다른 국가에서 사용할 수 있도록 API를 돌아서 게시 할 수 있습니다. 이제 누구나 동일한 엔드 포인트에 도달하여 서비스를받을 수 있습니다
  • 그것들은 쉽게 디버깅 할 수 있습니다. 패킷 스니퍼를 열거 나 들어오는 요청을 텍스트 파일로 덤프하고 진행 상황을 볼 수 있습니다. 바이너리 프로토콜로는 그렇게 할 수 없습니다
  • 그들은 쉽게 확장 할 수 있습니다. 나중에 더 많은 속성과 데이터를 추가 할 수 있으며 이전 클라이언트와의 호환성을 손상시키지 않습니다.
  • 자바 스크립트 클라이언트가 소비 할 수 있습니다 (protobuf JS 파서가 있는지 확실하지 않습니다.

TCP / IP를 통한 프로토 타입 :

  • 그들은 더 빠르다

그것이 나의 선택이라면, HTTP REST와 JSON으로 손을 내밀 것입니다. 다른 많은 회사와 웹 사이트가 그 길을 갔다는 이유가 있습니다. 또한 앞으로는 항상 2 개의 엔드 포인트를 지원할 수 있습니다. 설계가 올 바르면 엔드 포인트 선택이 서버 측 비즈니스 로직 또는 데이터베이스와 완전히 분리되어야합니다. 따라서 나중에 모든 / 일부 요청에 대해 더 많은 속도가 필요하다는 사실을 알게되면 최소한의 번거 로움없이 프로토 타입을 추가 할 수 있습니다. 그러나 바로 박쥐, REST / JSON은 더 빨리 당신을 데려다 줄 것입니다.

Netty vs Spring이가는 한. Netty를 직접 사용하지는 않았지만 Spring은 단순한 웹 서버 일뿐 아니라 Spring은 단순한 웹 서버보다 훨씬 많은 것을 제공하는 프레임 워크라고 생각합니다. 그것은 데이터 액세스 계층, 백그라운드 작업 스케줄링 및 MVC 모델을 가지고 있으므로 훨씬 더 무겁습니다. 어느 것을 선택해야합니까? HTTP 방식으로 가기로 결정했다면 다음 질문은 아마도 표준이 앱의 표준입니까? 표준 금형에 맞지 않는 미친 커스텀 로직을 작성하려고하고 HTTP 서버 계층 만 있으면 Netty를 사용하십시오.

그러나 나는 당신이 응용 프로그램이 그렇게 특별하지 않다고 생각하며 Spring이 제공 해야하는 많은 것들로부터 이익을 얻을 수 있습니다. 그러나 이는 Spring의 프레임 워크를 중심으로 앱을 구성하고 원하는 방식으로 작업을 수행해야한다는 것을 의미합니다. 이는 제품에 들어가기 전에 Spring에 대해 더 많이 배우는 것을 의미합니다. 일반적으로 프레임 워크는 다시 빨리 빠져 나올 수 있기 때문에 훌륭하지만 단점은 자신의 디자인을 수행하는 대신 금형에 맞추고 프레임 워크가 제대로 작동해야한다는 것입니다.

(*)-과거에는 내 게시물이 전 세계의 의견을 반영하지 않는다는 것이 지적되었으므로 기록을 세우고 Netty에 대한 경험이 제한적이라고 덧붙였습니다 (이전에 Play 프레임 워크를 사용했습니다) Netty) 또는 Spring (나는 그것에 대해서만 읽었습니다)을 기반으로합니다. 그래서 내가 말한 것을 한 알의 소금으로 가져 가십시오.


1
+1, 특히 "이 속도 차이는 프로토콜 자체에만 있습니다. 서버 측에 데이터베이스 / 파일 액세스가있는 경우 선택한 전송 계층의 영향을받지 않습니다". 99 %는 정확히 그럴 것이며, 잘못된 위치에서 조기 최적화는 전혀 도움이되지 않습니다.
Shivan Dragon

긴 응답과 두 가지를 비교하는 심층 분석에 감사드립니다. 공용 클라이언트가 쉽게 사용할 수 있기 때문에 RESTful 애플리케이션을 빌드하면 얻을 수있는 이점을 잘 알고 있습니다. 그러나 모든 것을 사내에서 유지하고 서비스를 공개하지 않으려는 경우 (직렬화 / 역 직렬화를 관리함) 사용자 정의 이진 프로토콜을 사용하지 않는 것이 왜 첫 번째 선택이 아닌지 알 수 없습니다. 예. 기존 프레임 워크를 사용하면 더 빨리 시작할 수 있지만 API에 얽매이지 않고 세밀한 제어가 필요하지 않습니다.
HiChews123

REST는 공용 클라이언트뿐만 아니라 모든 클라이언트가 쉽게 사용할 수 있지만 확실히 포함되어 있습니다. 우리 회사는 현재 약 1 년 동안 개발 한 제품을 보유하고 있습니다. 우리는 쉬는 "독점적"프로토콜을 가졌습니다. 우리는 다른 사람들에게 공개했습니다. 그들이 비즈니스 스쿨에서 당신에게 가르치는 것 중 하나는 "선택적 사고"이며, 나중에 결정을 내릴 수 있도록 가능한 한 많은 옵션을 남기기로 결정합니다. 따라서 모두 동일하게 설정하면 오늘 JS 클라이언트 또는 API 액세스 권한이 없기 때문에 REST를 선택하지만 나중에 필요할 경우 나중에 선택할 수있는 옵션이 있습니다. 그렇다면 다시 ...
DXM

... 바이너리 프로토콜을 사용하도록 설정했습니다. 96 %의 확률로 선택한 프로토콜이 최종 응용 프로그램에 영향을 미치지 않으므로 그 결정에 너무 많은 영향을 미치지 않습니다. 그리고 대답에서 말했듯이 적절한 디자인으로 나중에 프로토콜을 나중에 바꿀 수 있어야합니다. 내가하고 싶은 또 다른 일은 두 가지 경우를 모두 시도하는 것입니다. 결정을 내릴 때 울타리에 있으면 동전을 뒤집고 옵션 A를 선택하십시오. 다음에 비슷한 프로젝트를 할 때 옵션 B를 선택하여 다시 돌아갈 수 있습니다 내 경험을 비교 / 대조하십시오. 때때로, 그것은 당신이 더 나은 것을 결정하는 유일한 방법입니다
DXM

@DXM, 훌륭한 답변, 브라보!
HiChews123

0

이것은 실제로 질문이 아닙니다. 인터넷 프로토콜 스위트에 따르면 tcp는 전송 계층의 프로토콜이고 http는 응용 프로그램 계층의 프로토콜입니다. 당신은 서로 완전히 다른 것들을 비교하고 있습니다. (자세한 내용은 여기를 참조하십시오 : http://en.wikipedia.org/wiki/Internet_protocol_suite )

사실, 대부분의 http는 tcp / ip 이상입니다. 따라서 귀하의 질문에 대답하려면 그렇습니다 .tcp / ip를 사용해야합니다. 그런 다음 (예 : http) 및 데이터 형식 (json, xml, html) 위에 응용 프로그램 계층 프로토콜을 추가하려고합니다. Netty는 http를 사용하고 protobuff는 json, xml, html과 같습니다.

그것은 모두 요구 사항과 전송해야 할 데이터 유형에 따라 다릅니다. 프로토콜에서 세션이 필요하고 핸드 셰이크가 프로토콜 구성을 개선 할 수 있습니까? 한 번에 얼마나 많은 데이터를 전송할 것인지, 암호화가 필요합니까? 다음은 응용 프로그램 프로토콜을 선택할 때 답변해야하는 질문입니다.

데이터 표현 형식 (json, xml, html, protobuff 등)을 선택하려면 대역폭, 가독성, 언어 / 도구 지원 등에 따라 다릅니다.

http와 tcp를 비교할 수 없습니다.

속도가 전부는 아니라는 것을 기억하십시오. 합리적인 방법으로 자신을 표현할 수 없으면 속도는 아무 소용이 없습니다.


5
그의 질문에는 그가 네트워킹 스택의 계층들 사이의 차이점을 모른다는 것을 암시하는 것은 없습니다. 그는 HTTP (HTTP가 TCP / IP보다 높은 계층이라는 사실)를 사용하거나 자신의 사용자 지정 프로토콜과 함께 TCP / IP를 사용해야하는지 물었습니다. 그의 질문에는 아무런 문제가 없습니다.
Michael

물론 동의하지 않습니다. 그건 내가 그를 이해하는 방법이 아닙니다
iveqy

1
예, HTTP가 TCP / IP보다 높은 계층에 있다는 것을 알고 있습니다. 제 질문은 실제로 지연 시간, 개발 속도 등 트레이드 오프 측면에서 결정을 내리는 것에 대한 생각입니다.
HiChews123

2
@ acspd7 나는 자신의 프로토콜을 만드는 것을 피하고 이미 입증 된 프로토콜이 많이 있으며 프로토콜이 경쟁사보다 유리한 것이 아니라면 표준 프로토콜을 사용하는 것이 좋습니다. 나는 사용자 정의 프로토콜을 구현했으며, 그것은 많은 재미였습니다! 그러나 암호화, 홀 펀칭, 유지, 핸드 쉐이킹 (다른 네트워크는 서로 다른 프레임 길이를 필요로 함) 등을 수행하는 데 많은 작업이 필요합니다. 필요한 모든 문서는 말할 것도 없습니다. 사용자 지정 작업을 수행하기 전에 기능에 실제로 필요한 것을 생각하십시오.
iveqy

1
GPB는 잘 문서화되어 있으며 많은 사람들이 사용하므로 실제로 사용하는 데 아무런 문제가 없습니다. XML과 JSON보다 더 간결한 것이 좋을 것입니다! (인간 가독성이 부족할 수도 있지만 요구 사항이 아닌 경우 ...). 그러나 레이어를 그리워하지 않습니까? 일반적으로 tcp와 xml, json, protobuff 사이에 레이어가 있습니다. http, ssh 등과 같은 것
iveqy
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.