HTTP1.1协议

摘要

http1.1自1997年诞生，发布以来，直到今天依然是最流行的版本

持久化连接

TCP默认连接不关闭，可以被多次请求，不用声明Connection:keep-alive。同一个域名允许同时建立6个持久连接。规范做法是在客户端最后一个请求时，关闭TCP连接。Connection:close

引入管道机制

在同一个TCP连接里面，可以发送多个请求，服务器按照先后顺序处理

在头部加入Content-Length字段

HTTP1.1允许多个请求，就要区分数据是回应哪一个请求的数据，声明本次回应的数据长度。

分块传输

对于耗时请求，采用流模式代替缓存模式，产生块数据，发送一块。需要在Transfer-Encoding:chunked代替Content-Length字段。

增加了命令

新增了PUT、PATCH、OPTIONS、DELETE等命令

缺点

1.1版本允许重复连接，但是同一个TCP连接连里面多个请求，服务器顺序处理，容易造成请求排队，回应缓慢。

不能不说的TCP

都知道htpp请求是通过TCP建立的连接，而建立连接的过程需要有三次握手

TCP为这么要经过三次握手？本质上就是要确认客户端和服务端彼此的收发能力，刚好三次能够确认彼此的收发能力，连接可以建立传输，多一次无意义，少一次不行。一定要明白，客户端发送出去，并不代表客户端的发送能力就是好的，发送能力这个时候并不能被确认，无论是服务端还是客户端自身，都不能确认。这个类似于《三体》的提到的猜疑链。也就说，两个没有交流过的对方，现在还没有办法确认对方，信任对方。

1. 在服务端收到第一次握手时，在服务端这一侧，确认了客户端的发送能力和服务端自身的接收能力
2. 在客户端收到服务端的第二次握手回应时，对于客户端来讲，确认了客户端的发送能力和接收能力，同时也确认了服务端的发送能力和接收能力
3. 在服务端接收到第三次握手回应时，对于服务端来讲，确认了客户端的接收能力和服务端自身的发送能力。

至此，彼此双方的收发能力在两端都得到了确认，可以发送数据。

那么还有一个问题，就是断开连接为什么又是四次握手？

1. 第一次握手，客户端告诉服务端，自己没有数据要发送了，请求关闭连接，进入等待状态1(FIN_WAIT_1)
2. 第二次握手，服务端收到请求后，回应ACK,表示同意，客户端进入状态2(FIN_WAIT_2)
3. 第三次握手，服务端请求关闭关闭连接，服务端进入LAST_ACK状态
4. 第四次握手，客户端收到请求后，回应ACK报文，进入TIME_WAIT状态，服务端收到后，关闭连接，客户端等待一段时间后，没有收到回复，证明服务端连接已关闭，客户端关闭连接