有些技术知识点能在这么短的工夫里搞清楚弄明确, 和本人接触的技术深度以及广度, 工作教训密不可分。再次强调一下, 千万不要试图去钻研你钻研了很久都整不明确的货色，或者是你的档次不到，也或者是你从未在理论的利用场景接触过，这种状况下你去钻研，只会事倍功半，徒劳一番罢了。(在不该了解的时候了解不该了解的知识点, 后果只会事倍功半)。
GRPC 包含 =》传输协定 (http2.0) + 序列化协定 (pb)
HTTP 协定是基于申请 / 响应模式的，因而只有服务端给了响应，本次 HTTP 连贯就完结了，或者更精确的说，是本次 HTTP 申请就完结了，基本没有长连贯这一说。那么天然也就没有短连贯这一说了。
网络上说 HTTP 分为长连贯和短连贯，其实实质上是说的 TCP 连贯。TCP 连贯是一个双向的通道，它是能够放弃一段时间不敞开的，因而 TCP 连贯才有真正的长连贯和短连贯这一说。
HTTP 协定说到底是应用层的协定，而 TCP 才是真正的传输层协定，只有负责传输的这一层才须要建设连贯。
举例：
一个形象的例子就是，拿你在网上购物来说，HTTP 协定是指的那个快递单，你寄件的时候填的单子就像是发了一个 HTTP 申请，等货物运到中央了，快递员会依据你发的申请把货物送给相应的收货人。而 TCP 协定就是两头运货的那个大货车，也可能是火车或者飞机，但不论是什么，它是负责运输的，因而必须要有路，不论是地上还是天上。那么这个路就是所谓的 TCP 连贯，也就是一个双向的数据通道。
HTTP 申请和 HTTP 响应，都是通过 TCP 连贯这个通道来回传输的。
肯定要务必记住，长连贯是指的 TCP 连贯，而不是 HTTP 连贯。
问题:
1. 第一个问题是，是不是只有设置 Connection 为 keep-alive 就算是长连贯了？
当然是的，但要服务器和客户端都设置。
2、第二个问题是，咱们平时用的是不是长连贯？
当初用的基本上都是 HTTP1.1 协定，基本上 Connection 都是 keep-alive。而且 HTTP 协定文档上也提到了，HTTP1.1 默认是长连贯，也就是默认 Connection 的值就是 keep-alive
3、长连贯有啥益处？
长连贯是为了复用，那既然长连贯是指的 TCP 连贯，也就是说复用的是 TCP 连贯。那这就很好解释了，也就是说，长连贯状况下，多个 HTTP 申请能够复用同一个 TCP 连贯，这就节俭了很多 TCP 连贯建设和断开的耗费。
比方你申请了淘宝的一个网页，这个网页里必定还蕴含了 CSS、JS 等等一系列资源，如果你是短连贯（也就是每次都要从新建设 TCP 连贯）的话，那你每关上一个网页，根本要建设几个甚至几十个 TCP 连贯，这节约了多少资源就不必 LZ 去说了吧。
但如果是长连贯的话，那么这么屡次 HTTP 申请（这些申请包含申请网页内容，CSS 文件，JS 文件，图片等等），其实应用的都是一个 TCP 连贯，很显然是能够节俭很多耗费的, 只须要一次 TCP 三次握手就行了。
长连贯还要多提一句，那就是，长连贯并不是永恒连贯的。如果一段时间内（具体的工夫长短，是能够在 header 当中进行设置的，也就是所谓的超时工夫），这个连贯没有 HTTP 申请收回的话，那么这个长连贯就会被断掉。
参考: https://juejin.cn/post/692388…