1、Google ProtoBuf官方
2 Google Protocol Buffers
- gProtoBuf 制定了一些协议，基于序列化和反序列化原理，从传输算法进行处理
- gProtoBuf 解决高效的解码，提供get/set方法，但不同版本生成的文件结构发生很大的变化，从结构和使用方面都不一样，故：兼容性不够好，升级版本请注意
- gProtoBuf 是基于Client以stub，Server是sketcton方式
- gProtoBuf 不支持继承方式
3、常见的序列化和反序列化的框架有哪些
| 序列 | 名称 | 建议使用 |
|---|---|---|
| 1 | Thrift | 推荐 |
| 2 | Kyro | 推荐 |
| 3 | hessian | 推荐 |
| 4 | protobuf | 推荐 |
| 5 | fst | 不推荐 |
| 6 | fastjson | 不推荐 |
| 7 | Jackson | 推荐 |
| 8 | gson | 推荐 |
4、序列化与反序列化（要点）
- 序列化其实就是编码，加码Encoder：加码是将字符串转换成字符数组
- 反序列化其实就是解码，解码Decoder：解码是将字符数组转换成字符串
- 在Java实体类可以通过实现Serializable接口进行序列化，也可以通过transient关键字不实现某个字段不进行序列化（在grpc不建议使用）
5、gProtoBuf实现RPC步骤（重点和掌握点）
- 1、定义一个接口说明文件，描述了对象（结构体）对象成员，接口方法等一系列的信息
- 2、通过RPC框架所提供的编译器，将接口说明文件编译成具体的语言文件
- 3、在客户端和服务器翻倍引入RPC编译器所生成的
6、RPC的特点(重点)
- RPC将比较大的数据转换成比较小的序列化数据来提高性能，减少输送数据的时间(压缩)
- 注意： RPC使用Java自带的序列化来提供C++，Python调用是不允许的（不同语言的处理方式不同导致）
7、gProtoBuf的语法和特征
- 1、required 必填, opional 可选,在开发中required的坏处比好处更明显，建议使用opional
- 2、syntax = "proto2" 指定版本的语法
- 3、如提供package又提供java_package会以java_package为主生成,如：提供package不提供java_package会以package生成它为主的工程，故package是不能省的
- 4、java_outer_classsname会以这个名字生成一个大类,包含其他类.
- 5、文件.proto的1，2的数字表示是一个标识可用二进制唯一字段值
- 6、default = HOME 如果没有初始化值就是HOME
- 7、option optimize_for = SEPEEP 这个标识加快解析速度
- 8、oneof 多个自动强制设置一个字段行为来节省空间共享内存，设置任何一个成员都会自主清空
- 9、protobuf支持枚举与oneof解决多协议对象传值
8、gProtoBuf使用注意点
- Buildder VS Message是一个不可变的，通过方法连进行完成Build
- ProtobufVarint32FrameDecoder处理器,ProtobufDecder() 方法接收proto文件生成的类
- gProtoBuf建议使用下划线命名变量，主要是适配不同语言
ProtobufVarint32FrameDecoder
9、如何共享proto生成不同语言的文件（重点和掌握点）
- 1、git submodule git里面仓库的一个仓库（不推荐使用）
- 2、git subtree 推荐使用
- 3、打成jar 拉版本
10、Netty在proto的风格
- Netty采用方法的风格与proto生成的类一样的做法
11、TCP和UDP的区别（掌握点）
- 基于连接（TCP）与无连接（UDP）
- 对系统资源的要求（TCP较多，UDP较少）
- TCP能保证数据正确性，TCP保证数据是有顺序的，而且TCP逻辑通信信道是全双工（读与写）的可靠的信道
- TCP具有稳定性，有情人机制，三次握手（握手，确认，重发），容易被攻击（DOS、DDOS、CC,XSS等）
- UDP程序结构较为简单,UDP可能丢包，UDP不保证数据的正确性，信道不可靠，
- UDP 快比TCP安全，没有TCP握手，确认，重发，拥塞控制等机制，
简单比例：
UDP就好像是一个负责人的快递员，把包裹送到目的地（锋巢柜），并收件人进行签收。（发短信）
TCP就好像是一个不负责人的快递员，把包裹送到目的地，然后没送到收件人手里，放到哪个物业部或扫描对方
