那么okttp在客户端是如果类似于客户端做到的keep-alive的机制 。
长连接的过期时间
文章插图
上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒 。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开 。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源 。
长连接的数据传送完成识别使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束 。更细节的介绍可以看这篇文章 。
并发连接数的数量限制
【HTTP协议中的长连接，读完之后，大部分程序员收藏了...】在web开发中需要关注浏览器并发连接的数量，RFC文档说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制 。浏览器客户端就比较规矩，限制了同域名下能启动若干个并发的TCP连接去下载资源 。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接） 。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值 。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了 。
容易混淆的概念——TCP的keep alive和HTTP的Keep-alive
TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点 。它们是不同层次的概念 。
TCP keep alive的表现：
当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控 。
这个“一段时间”可以设置 。具体做法google吧 。
HTTP 流水线技术
使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指，在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起 。从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining 。
由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决） 。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果 。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样 。
在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能 。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源 。
推荐阅读
- SpringBoot中教你手把手配置 https
- https为什么能保证安全性
- 一个TCP连接可以发多少个HTTP请求？
- 六安瓜片茶旅节协议引资2025亿元
- dom 中的 nodeType 节点类型
- 早餐中的营养食物搭配
- 坏了的热水壶不急换新，无非文中的这几种情况，你试试看
- 冰箱中的风冷无霜和直冷哪个好？
- 成长当中的西红柿产生裂口是什么原因 西红柿为什么会发生裂果现象呢
- 吃盐太多当心7种病