004-Triple协议底层原理分析

底层分析

Http 2.0

为了解决Http 1.0 和 1.1

1. 头信息无法压缩
2. 有很多比如空格、换行等无用字符
3. 请求和相应不能并行处理：一个Socket连接如果接受到Request 就必须要等到服务返回Response了才能继续发送另一个Request

就更新了Http的协议到2.0版本
下面就是Http2.0 版本的模型
新的协议中规定一次请求可以分为多个帧来发送
每次请求由多个帧组成

• 帧长度：一共24各字节，标识 实际传输数据的长度，最长有2的24次方 也就是14M
• 帧类型：一般用来标识这次帧是头信息还是Body信息
• 标志位：一般用来标识是否是这次请求的最后一个帧
• 流标识符：用来确定请求的序号，一组帧请求序号相同，可以根据这个序号确定响应属于哪个请求
• 时间传输的数据：请求头或者请求体数据，可压缩

代码

消费者-TripleInvoker

构造方法只是把socket连接的准备做好
在调用的时候 doInvoke方法
调用bootStrp.

判断调用类型 rpcType 走不同的调用实现
双端流的实现就是调用 streamCall() 入参的时候会把调用的时候传入的Stream塞进去

start：
然后再 ceateWriteQueue 去连接Socket 并且初始化一个处理响应的Handler
TripleHttp2ClientResponseHandler

这个时候请求stream就可以发送数据了
onNext方法中的 sendMessage
先发送请求头（兼容 gRPC）
加入到writeQueue中
调用 flush方法 异步获取一个请求
先把数据帧插入Http2StramChannel中 ： cmd.run(CHannel)
发送 ： channel.flush() 128次批量发送

提供者-接收请求

TripleHttp2FramServerHandler
onHeander 检查请求头
获取真实的invoker
生成
TripleDecoder对象 ：处理请求体
ReflectionServerCall对象 ：根据调用的类型生成不同的CallListener

再普通的请求中
callListener的onMessage方法只是把参数保存起来
等接收到的complete请求的时候才会调用invoker（）

消费者-接受返回

ClientCall发送处理返回
并且普通消息时同步执行的
带有stream的请求是异步执行的 因为可以交给 业务生成的ResultStreamObserver处理相应
而同步请求是 再 waitForResultIfSync里边 其实不同的返回虽然都是 CompletableFuture
但是同步的是调用 get()阻塞再那里， 而异步的请求是直接返回了CompletableFuture.completedFuture