Protocol Buffers 의 기술적 장점 에 대한 상세 한 설명

머리말
APP 는 이동 특성 으로 인해 인터넷 통신 은 데이터 구조 가 더욱 작고 빠 르 며 안전 해 야 한다. 주류 데이터 협 의 는 텍스트 협의 에서 직렬 화 협의 로 이전 된다.

A(XML/JSON)=>B(Protocol Buffers/Hessian/...)

Protocol Buffers (이하 PB) 는 구 글 이 개방 한 것 으로 프로 그래 밍 언어 와 상 관 없 이 플랫폼 과 상 관 없 이 확장 가능 한 직렬 화 데이터 프로 토 콜 입 니 다.간단 한 스 크 립 트 언어 로 데이터 구 조 를 정의 하면 지원 하 는 프로 그래 밍 언어의 코드 를 생 성 할 수 있 고 PB 는 자바, python, Objective - C, C + +, Go, Javanno, Ruby, and C \ # 등 모든 주류 프로 그래 밍 언어 를 지원 합 니 다.이러한 특성 으로 인해 PB 는 점차 직렬 화 데이터 프로 토 콜 의 최 우선 순위 라 고 불 린 다.
이때, 당신 은 분명히 마음속 으로 생각 하고 있 을 것 입 니 다. 허풍 을 떨 었 습 니 다. 소 가 어디 에 있 는 지 실제로 분명하게 말 하지 못 했 습 니 다!서 두 르 지 마 세 요. 다음 에 일일이 말씀 드 리 겠 습 니 다.
두 가지 사용 예 를 보십시오.

Person john = Person.newBuilder()
    .setId(1234)
    .setName("John Doe")
    .setEmail("[email protected]")
    .build();
output = new FileOutputStream(args[0]);
john.writeTo(output);

Person john;
fstream input(argv[1],
    ios::in | ios::binary);
john.ParseFromIstream(&input);
id = john.id();
name = john.name();
email = john.email();

PB 는 바 이 너 리 스 트림 방식 으로 디 코딩 을 하 는 것 을 알 수 있 습 니 다. 그 장점 도 인 코딩 기술 에 있 기 때문에 proto 3 의 직렬 화 인 코딩 과 핵심 기술 점 에 중심 을 두 고 있 습 니 다.
직렬 화 코드
직렬 화 인 코딩 은 PB 메 시 지 를 바 이 너 리 흐름 으로 바 꾸 는 방법 을 설명 합 니 다. 사용 과정 에서 이 를 알 필요 가 없 지만 서로 다른 메시지 유형, 인 코딩 후의 바이트 수 를 알 수 있 습 니 다.
메시지 구조
모든 메 시 지 는 key - value 의 구조 형식 으로 저 장 됩 니 다. 그 중에서 key 는 정형 (varint 인 코딩) 으로 (field number < < < 3) | wire 로 표 현 됩 니 다.type，wire_type 은 모든 데이터 형식의 인 코딩 방식 을 지정 합 니 다. fieldnumber 는 PB 파일 의 메시지 번호 입 니 다. 이러한 구 조 는 PB 패 킷 이 XML / JSON 형식 보다 작 을 것 임 을 결정 합 니 다.
다음은 wiretype 구조 표:
Type
Meaning
Used For
0
Varint/ZipZag
int32, int64, uint32, uint64, sint32, sint64, bool, enum
1
64-bit
fixed64, sfixed64, double
2
Length-delimited
string, bytes, embedded messages, packed repeated fields
3
Start group
groups (deprecated)
4
End group
groups (deprecated)
5
32-bit
fixed32, sfixed32, float
Base 128 Varints
Base 128 variants 는 가 변 자 절 직렬 화 정형 수 치 를 사용 하 는 기술 로 더 작은 수 치 는 더 적은 바이트 수 를 사용한다.
Varints 메커니즘 에서 하나의 정형 은 마지막 바 이 트 를 제외 하고 다른 자 절 은 모두 가장 높 은 유효 비트 (MSB) 가 있 는데 뒤의 바이트 가 이 정형 에 속 하 는 지 여 부 를 지정 하 는 데 사용 된다. 즉, MSB = 1 만 있 으 면 뒤의 자 절 은 이 정형 에 속한다.또한, variants 의 정형 은 작은 엔 드 인 코딩 을 사용 하 는 것 을 주의해 야 합 니 다.
예 를 들 어 1. 한 마디 로 표시 할 수 있 기 때문에 MSB 비트 는 설정 하지 않 아 도 되 기 때문에 인 코딩 은

0000 0001

하지만 300

1010 1100 0000 0010

왜 일 까요?우 리 는 Varints 체제 에 따라 디 코딩 하여 최종 결 과 를 얻 었 다.

1010 1100 0000 0010
→ 010 1100  000 0010 ＃  MSB
→  000 0010 ++ 010 1100 #     
→  100101100 ＃  
→  256 + 32 + 8 + 4 = 300 #  

그러나 음수 의 최고 위 는 1 로 위의 메커니즘 에 따라 어떻게 표시 해 야 합 니까?Varints 는 모든 음 수 를 간단하게 폭력 적 으로 표시 합 니 다. int 32 든 int 64 든 모두 10 개의 바이트 로 표시 합 니 다. 이것 은 분명히 좌절 적 인 표현 입 니 다. 그래서 varints 는 정형 만 표시 하기에 적합 합 니 다. 그러면 마이너스 정형 은 어떻게 합 니까?
ZigZag
PB 는 ZigZag 인 코딩 을 도입 하여 마이너스 인 코딩 문 제 를 해결 합 니 다. ZigZag 는 모든 음 수 를 양수 로 표시 한 다음 에 varint 인 코딩 을 사용 하여 압축 목적 을 달성 합 니 다.ZipZag 인 코딩 을 사용 하려 면 sint 32 또는 sint 64 라 는 성명 형식 이 필요 합 니 다.
인 코딩 예제:
Signed Original
Encoded As
0
0
-1
1
1
2
-2
3
2147483647
4294967294
-2147483648
4294967295
인 코딩 공식 은 다음 과 같 습 니 다. sint 32 에 대해 서 는...

(n << 1) ^ (n >> 31)

sint 64

(n << 1) ^ (n >> 63)

> > 산술 오른쪽 이동, 즉 양수 라면 왼쪽 모두 0 을 보충 하고 음수 라면 왼쪽 모두 1 을 보충 합 니 다.
Length-delimited
Length - delimited 는 데이터 헤드 를 추가 하고 데이터 의 길 이 를 지정 합 니 다. 전체 형식 은 다음 과 같 습 니 다.

key length value

예 를 들 어 문자열 "testing", UTF 8 인 코딩 은

12 07 74 65 73 74 69 6e 67

0x 12 는 tag = 2, type = 2, 0x 07 은 뒤의 데이터 길이 가 7 개의 바이트 임 을 나타 낸다.