TCP握手为何三次而不是二次或者四次？
TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。
HTTP的发展历史很多前端小伙伴不屑一顾，其实清楚其演化过程能够帮助我们理解许多HTTP存在的“疑难杂症”，同时http/1、http/2的Keep-Alice、pipline、多路复用、ServerPush等特点是我们面试时候很多必答提，能够帮助我们在面试的时候加分。
一、http发展历程
1http/0.9
没有HEADER等描述数据的信息，只规定了客户端和服务端的通信形式，只支持GET请求
增加status code和header
2http/1.0
正式作为标准，传输内容格式不限制，增加了PUT、PATCH、HEAD、OPTIONS、DELETE 命令
3http/1.1
增加了持久连接（Keep-Alive）和管道机制
4http/2
增加了多路复用，服务端推送，头部️压缩，二进制帧数据传输等
二、Keep-Alive是什么？
从刚才所陈述的HTTP发展的过程中，已经提及Keep-Alive是在http/1.1时候增加的，在没有其之前，http所有请求全部是短连接。
翻译成人话的大概意思：我们每一次请求之后，务必要立刻关闭连接，也是前文《大厂面试指南——TCP协议相关篇》所讲述的三次握手，四次挥手的整个过程！这样做一个是影响传输速度，另一个是带来资源上浪费，为了提高访问速度减少资源浪费，从而有了Keep—Alice。
Keep-Alive图解过程
Keep—Alive允许在一定时间内，同一个域名多次请求数据，只建立一次http连接，其他请求可以复用这个连接通道，以达到提高请求效率的目的。
三、管道机制又是什么？
如果浏览器要向一个域名发送多个请求，需要在本地维护一个FIFO队列，完成了一个再发送下一个，这样就存在一个问题，服务端从完成一个请求开始回传，到收到下一个请求的这段时间内是处于空闲状态的。
于是提出了管道机制，试图将浏览器的请求一股脑的打包发给服务器，服务器就可以在出开完一个请求后，马上处理下一个，不会在之前说的空闲时间。
管道机制
从Keep-Alive我们引出了管道机制，如果我们的浏览器需要向某一个域名发送多个请求，这样该怎么办？
此时需要在本地建立一个FIFO队列，让这些请求“排好队，吃果果”，完成一个再处理下一个。这样有一个问题，当服务端完成一个请求进行回传，到接收下一个请求的这段时期是处于闲置状态。
于是管道机制尝试把所有请求一股脑打包给云服务器进行处理！这样在一个回传周期，不会存在闲置时间。
本文是相关系列文章，主要讲解TCP、HTTP、HTTPS
《大厂面试指南——TCP协议相关篇》
《TCP握手为何三次而不是二次或者四次？》
《HTTP发展各版本特点，专治各种“疑难杂症”的面试官（上）》
《HTTP发展各版本特点，专治各种“疑难杂症”的面试官（下）》
《HTTPS相关，面试想要的都在这》