一、下图为每一次HTTP请求的流程。对于一个完整的HTTP/1.1的请求和响应:建立tcp连接 (syn; ack, syn2; ack2; 三个分组握手完成)请求响应……请求响应关闭连接 (fin; ack; fin2; ack2 四个分组关闭连接)。如果请求和响应都只有一个分组，那么HTTP/1.1 至少要传输11个分组，才拿到一个分组的数据。而Keep-Alive就可以更充分的利用这个已经建立 的连接，避免的频繁的建立和关闭连接，减少网络阻塞。
分析图
一次完整的HTTP TCP的 四次握手（可靠连接，所以最后还有一次关闭告知）
二、HTTP请求全过程：
1、解析URL （ 浏览器 ）
2、DNS查询 （ 浏览器获取目标服务器的ip ）
3、TCP封包、传输 （ 根据2的步骤获取到了ip 及 端口，浏览器生成套接字，再进行与服务端捂手建立连接，传输数据 ）
4、服务器接收请求、响应
三、基于TCP的特性。每一次TCP封包之后只会传输与服务端进行一次HTTP请求。如果当请求开启了keep-alive之后，在上述的HTTP请求过程的时候，再TCP封包时候就不需要去进行与服务器握手，省去了改流程带来的空间与时间问题。另外每一次的请求结束之后，如果keep-alive与服务还未断开，那么后面的其他HTTP请求可以继续沿用该已经与服务端建立好连接的TCP “通道”（个人理解为一个由浏览器缓存的一个通道） 。
四、在一个大网页情况下，keep-alive怎么就保证了网页的加载速度？
当网页过大时，当请求的接口或者资源都是来自于同一个域名的时候，如果keep-alive如果为打开状态时，就会创建多个 TCP“通道”，以供其他请求使用，这样就大大的减少了 很多次的与服务端建立TCP与关闭TCP的时间（握手）。但是这个创建多少个 “TCP通道” 就基于每个浏览器本身的对通域名下的并发量设置。（ 经过调研，谷歌的并发为8，IE10 为10，火狐为 6等等....当然这些都是基于HTTP 1.1 的 ，HTTP1.0 有点出入）。其实这样也会带来一些弊端，当所有的资源都加载好了，不需要去用“通道”的时候也会带来另外一个问题，就是占用了服务端的内存消耗，毕竟服务端还是和客户端保持着连接的状态。在开源apach官网中看到，google 对此进行了大量的调研，并且对其进行了优化，他建议，在引入keep-alive的同时应该合理控制Keep-Alive TimeOut这个参数可以大量的节约连接的开销，提高相应速度。如果设置不好，在大并发的情况小，因维持大量连接而使服务器资源耗尽，而对于目前国内大 部分的用户使用的还是IE6，7的情况下关闭Keep-Alive可以充分利用浏览器默认最大并发连接数的好处实现不增加额外的开销页面快速的展示。
redis中的keep-alive超时时间为 300 s
五、根据以上第四点，同一个域名下浏览器本身就做了这种并发控制。那么京东主页，淘宝主页的一些图片资源都已过百，按照6的并发两，如果带宽不够，那也肯定达不到3秒钟原则，那他们又是怎么做的，经过调研发现，他们其实就是对于通信这块在上述第二点中的DNS解析加上浏览器并发控制，根据这一特性引入了多域名资源共享机制。就是一个服务器申请多个域名，访问到的是同一个服务器资源，来以此骗过DNS，这样就轻松实现了一个大网站，有多个域名，所以就可以同时并发的去请求，同时响应渲染了。当然这会去牺牲一点性能还可以，加强用户体验，3秒钟原则。（个人理解）
六、其实每次连接、互联网的目的就是达到进程与进程之间的通信。以此来各取其需，实现互联。
网友评论