누구든지 바이너리 프로토콜이 무엇인지에 대한 좋은 정의를 가지고 있습니까? 실제로 텍스트 프로토콜은 무엇입니까? 와이어에서 전송되는 비트 측면에서 서로 어떻게 비교됩니까?
이진 프로토콜에 대해 위키피디아가 말하는 내용은 다음과 같습니다.
바이너리 프로토콜은 인간이 아닌 기계가 읽을 수 있도록 의도되거나 예상되는 프로토콜입니다 ( http://en.wikipedia.org/wiki/Binary_protocol )
오 어서!
더 명확하게 말하면 jpg 파일이 있으면 바이너리 프로토콜을 통해 어떻게 전송되고 어떻게 텍스트를 통해 전송됩니까? 물론 와이어에서 전송되는 비트 / 바이트 측면에서.
하루가 끝날 때 문자열을 보면 그 자체가 바이트 배열이므로 두 프로토콜 간의 구별은 실제 데이터가 유선으로 전송되는 것에 달려 있습니다. 즉, 전송되기 전에 초기 데이터 (jpg 파일)가 인코딩되는 방식입니다.
답변:
바이너리 프로토콜과 텍스트 프로토콜은 바이너리 Blob이 인코딩되는 방식에 관한 것이 아닙니다. 차이점은 실제로 프로토콜이 데이터 구조 또는 텍스트 문자열 중심인지 여부입니다. 예를 들어 보겠습니다 : HTTP. HTTP는 텍스트 프로토콜이지만 jpeg 이미지를 보낼 때 텍스트 인코딩이 아닌 원시 바이트 만 보냅니다.
그러나 HTTP를 텍스트 프로토콜로 만드는 것은 jpg 를 얻기 위한 교환 이 다음과 같다는 것입니다.
의뢰:
GET /files/image.jpg HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.01 [en] (Win95; I)
Host: hal.etc.com.au
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
응답:
HTTP/1.1 200 OK
Date: Mon, 19 Jan 1998 03:52:51 GMT
Server: Apache/1.2.4
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT
ETag: "61a85-17c3-343b08dc"
Content-Length: 60830
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg
<binary data goes here>
이것은 (C에서) 다음과 같은 구조로 훨씬 더 단단히 압축되었을 수 있습니다.
의뢰:
struct request {
int requestType;
int protocolVersion;
char path[1024];
char user_agent[1024];
char host[1024];
long int accept_bitmask;
long int language_bitmask;
long int charset_bitmask;
};
응답:
struct response {
int responseType;
int protocolVersion;
time_t date;
char host[1024];
time_t modification_date;
char etag[1024];
size_t content_length;
int keepalive_timeout;
int keepalive_max;
int connection_type;
char content_type[1024];
char data[];
};
필드 이름이 전혀 전송 될 필요가없고, 예를 들어 responseType응답 구조에서는 세 문자 '2' '0' '0'대신 값 200을 갖는 int입니다. 이것이 바로 텍스트 기반 프로토콜입니다. 다양한 유형의 구조화 된 데이터가 아닌 (일반적으로 사람이 읽을 수있는) 텍스트 줄의 플랫 스트림으로 전달되도록 설계된 프로토콜입니다.
다음은 일종의 cop-out 정의입니다.
당신은 그것을 볼 때 그것을 알게 될 것입니다.
이것은 모든 코너 케이스를 포함하는 간결한 정의를 찾기가 매우 어려운 경우 중 하나입니다. 그러나 코너 케이스는 실생활에서 단순히 발생하지 않기 때문에 전혀 관련이없는 케이스 중 하나이기도합니다.
실생활에서 접하게 될 거의 모든 프로토콜은 다음과 같습니다.
> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
> b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart
[인쇄 할 수없는 다른 쓰레기가 많이 있다고 상상해보십시오. 텍스트와 바이너리의 차이를 전달하는 데있어 어려움 중 하나는 텍스트로 전달해야한다는 것입니다. :-)]
또는 다음과 같이 :
< HELLO server.example.com
> HELLO client.example.com
< GO
> GETFILE /foo.jpg
< Length: 3726
< Type: image/jpeg
< READY?
> GO
< ... server sends 3726 bytes of binary data ...
> ACK
> BYE
[그 자리에서 만들었습니다.]
거기에는 그다지 모호하지 않습니다.
가끔 들었던 또 다른 정의는
텍스트 프로토콜은 다음을 사용하여 디버깅 할 수있는 프로토콜입니다.
telnet
어쩌면 내가 여기 내 nerdiness를 표시하고,하지만 난 한 사실 작성 및 SMTP와 POP3를 통해 전자 메일을 읽을 사용하여 HTTP를 통해 NNTP를 통해 유즈넷 기사와 본 웹 페이지를 읽기 telnet가 작업을 실제로 것 있는지 여부를 확인하는 것보다 다른 이유.
사실이 글을 쓰다가 다시 열이 났어요.
bash-4.0$ telnet smtp.googlemail.com 25
Trying 74.125.77.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200
> HELO
< 501 Syntactically invalid HELO argument(s)
> HELO client.example.com
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666]
> RCPT TO:Me <Me@Example.Com>
< 503 sender not yet given
> SENDER:Me <Me@Example.Com>
< 500 unrecognized command
> RCPT FROM:Me <Me@Example.Com>
< 500 unrecognized command
> FROM:Me <Me@Example.Com>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <Me@Example.Com>
< 250 OK
> RCPT TO:You <You@SomewhereElse.Example.Com>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <Me@Example.Com>
> To: You <You@SomewhereElse.Example.Com>
> Subject: Testmail
>
> This is a test.
> .
< 250 OK id=1O2Sjq-0000c4-Qv
> QUIT
< 221 googlemail-smtp.l.google.com closing connection
Connection closed by foreign host.
젠장, 내가이 일을 한 지 꽤 오래되었습니다. 거기에 꽤 많은 오류 :-)
대부분이 제안했듯이 우리는 단순히 유선의 내용을 보는 것만으로는 프로토콜이 바이너리인지 텍스트인지 구별 할 수 없습니다.
AFIK
바이너리 프로토콜-비트는 경계 순서가 매우 중요합니다.
예 : RTP
처음 두 비트는 버전입니다. 다음 비트는 MarkUp 비트입니다.
텍스트 프로토콜-프로토콜 고유의 구분 기호 필드 순서는 중요하지 않습니다.
예 : SIP
또 하나는 바이너리 프로토콜에서 바이트를 분할 할 수 있다는 것입니다. 즉, 단일 비트가 특정 개별 의미를 가질 수 있습니다. 텍스트 프로토콜에서 의미있는 최소 단위는 BYTE입니다. 바이트를 분할 할 수 없습니다.
둘 다 다른 문자 세트를 사용하고, 텍스트 하나, 축소 문자 세트를 사용하고, 바이너리에는 "문자"와 "숫자"뿐만 아니라 할 수있는 모든 것이 포함됩니다 (이것이 위키피디아가 "인간"이라고 말하는 이유입니다).
o 좀 더 명확하게 jpg 파일이 있다면 바이너리 프로토콜을 통해 어떻게 전송되고 어떻게> 텍스트를 통해 전송됩니까? 물론 와이어에서 전송되는 비트 / 바이트 측면에서.
이 Base64를 읽어야합니다.
어떤 의견이라도 감사드립니다. 나는 여기서 사물의 본질에 도달하려고 노력하고 있습니다.
문자셋을 좁히고 복잡성을 좁히고 이식성, 호환성에 도달하는 것이 핵심이라고 생각합니다. Wide charset (또는 wide 무엇이든)을 존중하기 위해 많은 사람들과 정렬하고 동의하는 것이 더 어렵습니다. 라틴 / 로마 알파벳과 아라비아 숫자는 전 세계적으로 알려져 있습니다. (물론 코드를 줄이기위한 다른 고려 사항이 있지만 이것이 주요 고려 사항입니다)
바이너리 프로토콜에서 파트 간의 "계약"은 비트에 관한 것이고, 첫 번째 비트는 이것, 두 번째 비트 등을 의미하거나 심지어 바이트 (하지만 이식성을 고려하지 않고 문자 세트를 자유롭게 사용할 수 있음)입니다. 예를 들어 비공개 폐쇄 시스템에서 또는 (하드웨어 표준에 가까운) 그러나 개방형 시스템을 설계하는 경우 코드가 다양한 상황에서 어떻게 표현되는지 고려해야합니다. 예를 들어, 코드가 세계의 다른 쪽 기계에서 어떻게 표현 될 것인가? 여기에 계약이 가능한 한 표준이 될 텍스트 프로토콜이 있습니다. 나는 둘 다 디자인했고 그 이유는 매우 맞춤형 솔루션을위한 바이너리와 개방형 또는 / 및 휴대용 시스템을위한 텍스트였습니다.
SOAP에서 이미지 파일을 보내는 방법 : 여기를 클릭하십시오.
이는 [ATTACHMENT]와 같이 바이너리 데이터가 첨부되고 그 참조가 SOAP 메시지에 저장되어 있음을 보여줍니다.
따라서 프로토콜은 텍스트 기반이고 데이터 [이미지]는 인코딩과 관련이없는 바이너리 첨부 파일입니다.
따라서 SOAP는 실제로 인코딩 된 데이터가 아니라 Soap 헤더를 지정하는 방식으로 인해 텍스트 프로토콜입니다.
나는 당신이 틀렸다고 생각합니다. 데이터가 "와이어"에서 어떻게 보이는지 결정하는 것은 프로토콜이 아니라 데이터를 전송하는 데 사용할 프로토콜을 결정하는 데이터 유형입니다. 예를 들어 tcp 소켓을 사용하면 jpeg 파일은 이진 데이터 (인간이 읽을 수없고 32-126 ASCII 범위에 속하는 바이트)이기 때문에 이진 프로토콜로 송수신되지만 다음을 사용하여 텍스트 파일을 보내거나받을 수 있습니다. 두 프로토콜 모두 차이를 느끼지 못할 것입니다.