바이너리 프로토콜 vs 텍스트 프로토콜

2981 단어

바이너리 프로토콜 vs 텍스트 프로토콜


서버 프로그램 개발 과정에서 각 서비스는 직접적으로 상호작용을 해야 한다.이렇게 하면 정보를 정의하는 프로토콜이 필요하다. 일반적으로 프로토콜은 주로 2진 프로토콜과 텍스트 프로토콜을 포함한다. 다음은 내가 업무에서 사용하는 두 가지 프로토콜에 대해 자신의 견해를 말해 보자.

1 바이너리 프로토콜


현재 회사에서 서버 백엔드 개발을 하려면 여러 개의 서비스 프로그램이 상호작용을 해야 한다.TCP 직접 연결이기 때문에 바이너리 메시지를 직접 사용하는 방식입니다.메시지의 정의는 메시지 헤더(메시지 ID+ 메시지 길이)+x 메시지체(메시지 내용)의 방식을 통일적으로 사용하기 때문에 확장이 비교적 편리하다.코드로 다음과 같이 표시하다
struct CommonMsg
{
    uint32_t  m_msgId;
    uint32_t  m_msgLen;
};

struct KeepAlive:public CommonMsg
{
    uint32_t m_timeStamp;
};

doRead()
{
    CommonMsg * msg=(CommonMsg*)buffer;
    if(msg->m_msgId==ID_KEEP_ALIVE)
    {
         handleKeepAlive(msg);
    }
}

1.1 이점


바이너리 프로토콜에는 다음과 같은 몇 가지 장점이 있습니다.

1. 메모리, 대역폭 절약.


2진 프로토콜은 필요한 정보만 저장하고 대량의 정보를 전달해야 할 때 대역폭 절약이 매우 뚜렷하다.

2. 암호화가 용이합니다.


2진 프로토콜은 다른 또는 압축 방식으로 암호화하기 편리하고 프로토콜이 해독되는 것을 방지하여 전달된 정보를 보호하고 프로토콜 해독의 어려움을 증가시킨다.

1.2 단점


바이너리 프로토콜의 단점도 매우 뚜렷하다.

1. 해석하기 어렵다.


모든 메시지에 대해 스스로 설명할 수 없기 때문에 모든 메시지에 대해 대응하는 문서가 있어야 한다.문서와 코드의 일치성은 매우 중요하다.

2. 프로세서를 사용하지 않습니다.


엄격한 메모리에서 대상으로의 전환이기 때문에 송신자와 수신자의 기계 바이트 순서가 일치하도록 요구합니다. 그렇지 않으면 정확하게 해석할 수 없습니다.

3. 메시지 수정이 불편합니다.


메시지의 확장은 비교적 편리하지만, 메시지의 뒤에 필드를 추가해야만 호환할 수 있다.기존 필드의 순서를 수정하면 메시지가 정확하게 해석되지 않습니다.

2 텍스트 프로토콜


http 요청에서 일반적으로 json 또는 xml 형식의 프로토콜을 사용합니다.특히 웹 사이드의 백그라운드 상호작용은 json을 더 많이 사용한다.일반적으로 코드는 다음과 같습니다.
//http://www.chat.com/getuserinfo/
//Request:
{
"user":"[email protected]",
"token":"af89da025"
}

//Response
{
  "code":0,
  "msg":"succeed",
  "info":
  {
     "user":"[email protected]",
     "name":"test",
     "group":"test",
     "tel":"18888888"
  }
}

2.1


텍스트 프로토콜의 이점은 다음과 같습니다.

1. 확장이 편리합니다.


만약 조건을 좀 더 늘려야 한다면 키와 Value를 직접 추가하면 됩니다. 확장이 편리합니다.

2. 업그레이드가 용이합니다.


기존 메시지의 업그레이드가 필요하면 업그레이드 후 요청한 주소와 메시지 형식을 답장에 직접 제시할 수 있습니다.

3. 크로스 언어 크로스 플랫폼이 편리하다.


메시지의 발송자와 수신자가 사용하는 프로그래밍 언어는 엄격한 제한이 없고 다중 언어의 작성에 편의를 제공한다.

2.2


텍스트 프로토콜에는 다음과 같은 단점이 있습니다.

1. 대역폭을 낭비한다.


텍스트 프로토콜은 처리에서 실제로 사용되지 않는 내용을 너무 많이 전달하기 때문에 처리 요청의 양이 매우 많으면 대역폭에 대한 낭비가 심각하다.

2. 암호화하기가 불편합니다.


텍스트 프로토콜은 해석하기 쉽기 때문에 다른 프로그램과 통신 프로토콜을 공유하지 않으려면 텍스트 프로토콜을 사용하지 않는 것이 좋다.

3 장면 적용


자는 짧고 작은 것은 장점이 있다.모든 협의는 자신이 적용되는 장면이 있다.
  • 회사 내부의 서비스 프로그램 간에 통신을 하려면 2진 프로토콜을 사용하는 것이 좋다
  • 외부에 제공해야 하는 인터페이스에 대해 텍스트 형식의 프로토콜을 제공하는 것이 좋습니다

  • 다음으로 전송:https://www.cnblogs.com/Dennis-mi/p/7287415.html

    좋은 웹페이지 즐겨찾기