长连接和短连接哪个更好， 一直是被人反复讨论且乐此不疲 的 话题。有人追求短连接的简单可靠， 有人却对长连接的低延时趋之若鹜。那么长连接到底好在哪里， 它是否是解决性能问题的银弹? 本文就从 gRPC 长连接的视角， 为你揭开这层面纱。
那么什么是长连接, 什么是短连接? 他们和 TCP 有什么关系呢?
为了理解这个概念, 我们来看下图中 TCP 连接的三种行为。
图一 展示了 client 和 server 端基于 TCP 协议的一次交互过程， 分为三个阶段: 三次握手， 数据交换和四次挥手。这个过程比较简单， 但是实际应用中存在一个问题。假如 server 处理请求过程非常耗时， 或者不幸突然宕机， 此时 client 会陷入无限等待的状态。为了解决这个问题，
图二 展示了 keepalive 的工作机制。当该机制开启之后， 系统会为每一个连接设置一个定时器， 不断地发送 ACK 包， 用来探测目标主机是否存活， 当对方主机宕机或者网络中断时， 便能及时 的 得到反馈并释放资源。
在图一和图二中可以看到， 虽然连接的持续时间不同， 但他们的行为类似， 都是完成了一次数据交互后便断开了连接， 如果有更多的请求要发送， 就需要重新建立连接。这种行为模式被称为短连接。
那有没有可能在完成数据交互后不断开连接， 而是复用它继续下一次请求呢?
图三 展示了这种交互的过程。在 client 和 server 端完成了一次数据交换后， client 通过 keepalive 机制保持该连接， 后面的请求会直接复用该连接， 我们称这种模式为长连接。
理解了上面的过程， 我们便可以得出下面的结论：
- TCP 连接本身并没有长短的区分， 长或短只是在描述我们使用它的方式
- 长 / 短是指多次数据交换能否复用同一个连接， 而不是指连接的持续时间
- TCP 的 keepalive 仅起到保活探测的作用， 和连接的长短并没有因果关系
这里需要注意的几个点:
- DCL 双检查避免连接泄露
- 当使用自定义的 dialOptions 时， 切换到短连接模式
我们在 Istio 平台下， 对同一个接口在长连接和短连接两种模式下的响应时间和吞吐量进行了压力测试。
首先是对响应时间的测试， 结果如下图所示。
对短连接来说， 当并发数 <350 的， 响应时间呈线性增长， 当并发数超过 350 时， 响应时间陡增， 很快达到了 10s 并引发了超时。
对长连接来说， 当并发数 <500 时， 响应时间虽然也呈线性增长， 但比短连接要小。当并发数超过 500 时， 响应时间陡增并很快超时。
接下来是吞吐量的测试， 结果如下图所示。
对短连接来说， 当并发数 <350 时， 吞吐量基本维持在 290， 超过 350 便开始骤减。
对长连接来说， 当并发数 <500 时， 吞吐量基本维持在 325， 超过 500 便开始骤减。
从测试结果来看， 长连接和短连接都存在明显的性能拐点 (长连接为 500， 短连接为 350)， 在到达拐点之前， 性能变化较为平稳，一旦超过便急剧下降。但无论是从响应时间，QPS， 或是拐点值大小来看， 长连接都明显要优于短连接。
本文深入解释了长连接和短连接概念， 并阐述了长连接的优势及使用时应考虑的问题。结合 Biz-UI 的业务系统， 分析了 Istio 平台中 gRPC 连接的管理方式和长连接基于 Go 语言的实现， 并通过性能测试展示了长连接带来的响应时间和吞吐量上的提升， 为 gRPC 框架中使用长连接提供了有力的理论依据和数据支持。
希望此文会对你有所帮助！
张琦，FreeWheel Biz-UI 团队高级研发工程师, 热衷于新技术的研究与分享，擅长发现与解决后端开发痛点，目前致力于 Go，容器化和无服务化相关的实践。
