- 主题:你们用哪个rpc框架？
你没有理解我的意思吧，我是说系统底层隐式调用。我们用基于http1.1，貌似每次都是有建立链接的。
【 在 oldwatch 的大作中提到: 】
: 对于浏览器来说这个问题有点复杂
:
: 如果当RPC用的话，http层不会触碰到tcp层的协议
: ...................
--
FROM 106.121.178.*
这取决于你的httpclient的实现是否能维护长连
和上面跑的具体http协议版本无关
http协议几个升级的关注点都在如何在站点/页面内令多个请求高效复用tcp连接
而不会关注连接本身
【 在 GoGoRoger (GoGoRoger) 的大作中提到: 】
: 你没有理解我的意思吧，我是说系统底层隐式调用。我们用基于http1.1，貌似每次都是有建立链接的。
--
修改:oldwatch FROM 180.173.1.*
FROM 180.173.1.*
rpc 的请求和回应一般是异步的。比如连接两个请求，再连续返回两个回应。http 1.1 的长连接不能满足这种场景。
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 这取决于你的httpclient的实现是否能维护长连
: 和上面跑的具体http协议版本无关
: http协议几个升级的关注点都在如何在站点/页面内令多个请求高效复用tcp连接
: ...................
--
FROM 59.60.57.*
那就是另外一个问题了
http1.1没异步也没有stream模式，报头冗余还一大堆
和现代RPC比是水的有点狠的
不过http/2还可以，gRPC就是基于http/2搞的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: rpc 的请求和回应一般是异步的。比如连接两个请求，再连续返回两个回应。http 1.1 的长连接不能满足这种场景。
--
修改:oldwatch FROM 180.173.1.*
FROM 180.173.1.*
哦哦，说到点子上了，http2可能不需要。
【 在 hgoldfish 的大作中提到: 】
: rpc 的请求和回应一般是异步的。比如连接两个请求，再连续返回两个回应。http 1.1 的长连接不能满足这种场景。
:
: 【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: ...................
--
FROM 106.121.178.*
websocket不是可以
【 在 hgoldfish (老鱼) 的大作中提到: 】
: rpc 的请求和回应一般是异步的。比如连接两个请求，再连续返回两个回应。http 1.1 的长连接不能满足这种场景。
--
FROM 113.67.225.*
现代的rpc，比如brpc，是不是有单点的问题，没办法使用代理？
【 在 oldwatch 的大作中提到: 】
: 那就是另外一个问题了
:
: http没异步也没有stream模式，报头冗余还一大堆
: ...................
--
FROM 106.121.178.*
gRPC，RSocket这种跑在http/2上的应该还凑合吧
【 在 GoGoRoger (GoGoRoger) 的大作中提到: 】
: 现代的rpc，比如brpc，是不是有单点的问题，没办法使用代理？
--
FROM 180.173.1.*
哦，那就又多了一个用grpc的理由
【 在 oldwatch 的大作中提到: 】
: gRPC，RSocket这种跑在http/2上的应该还凑合吧
:
: 【 在 GoGoRoger (GoGoRoger) 的大作中提到: 】
: ...................
--
FROM 106.121.178.*
依然存在，缓解了而已。
【 在 GoGoRoger 的大作中提到: 】
:
: 问一下哈，是不是http1.1或者http2.0的协议，就不存在tcp三次握手四次挥手的问题？我老是觉着http比较低效。
:
: 【 在 lambdai 的大作中提到: 】
: : grpc+protobuf，哪部分是很难维护的？能不能详细说说？
#发自zSMTH@M2007J3SC
--
FROM 223.104.39.*