[GitHub] [brpc] wwbmmm commented on issue #1991: support https alpn

[GitBox <gi...@apache.org>]

wwbmmm commented on issue #1991:
URL: https://github.com/apache/brpc/issues/1991#issuecomment-1378175719

   > @wwbmmm Client端的实现有几个问题想请教下：目前考虑的是在`ChannelSSLOptions`中新增ALPN的配置，在TLS协商成功后覆盖`ChannelOptions.protocol`字段进行后续的数据发送。
   > 
   > Q1：`Channel.Init()`方法并不会实际建立连接，这样在初始化阶段并不知道需要使用哪种协议。而在`Channel.CallMethod()`方法调用Socket发送数据前，函数内已经有根据protocol值的特殊逻辑处理。这样的话是否可以在在`Init`就进行TLS握手确定使用的协议？或者还有其他比较好的办法吗？
   > 
   > Q2：由于protocol是针对下游整体而言的，当下游是集群时，某个下游（ip:port）协商成功了是否就可以认为是整个集群的结果？以及后续连接断开重连（连接池）是否可以直接复用之前的协商结果？
   > 
   > Q3：除了普通的Channel，考虑到ParallelChannel、SelectiveChannel等其他Channel也有可能需要涉及到ALPN，是否可以将协商功能实现在ChannelBase中？
   
   ALPN的流程对现有RPC框架的冲击较大。因为ALPN是在连接建立之后才能确定协议，而RPC是在Channel::Init确定协议，CallMethod时根据协议序列化好请求，用LB选择后端服务器，再发起与后端的连接。特别是当后端是个集群时，不同后端实例的ALPN协商结果可能是不同的，这样会让问题变得很复杂。
   
   所以我建议，如果要在bRPC中支持ALPN协议，仅支持后端是单个ip的情况（single server模式），在这种模式下，可以在Channel::Init的时候，先向后端发起一个连接，然后根据协商结果确定协议。
   
   ParallelChannel、SelectiveChannel没必要处理ALPN的逻辑，只要子Channel支持了就可以。


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org