彻底解析http1,2,3

先来简介

什么是HTTP？

HyperText Transfer Protocol，超文本传输协议，是目前互联网上应用最普遍的一种网络协议，全部的www文件都必须遵照该标准。而Http又使用了可靠的数据传输协议TCP协议，不会产生数据丢失和损坏。

什么又是TCP?

计算机和网络设备相互通讯，必须知足的一种规则，咱们称之为协议（ protocal）

与HTTP密切关联的TCP、IP以及DNS

IP协议，位于网络层，做用是把各类数据包发送给对方，经过IP地址和MAC地址来保证数据传达。怎么保证呢？IP地址指明了节点被分配的地址，MAC地址是网卡所属的固定地址，彼此可进行配对，IP地址可变，但MAC地址基本不变。

ARP（Address Resolution Protocol）协议是一种解析地址的协议，可根据IP地址解析出对应的MAC地址。

TCP协议是如何作到可靠的数据传输的？
首先，TCP位于传输层，为了方便传输，将大块的数据分割成以报文为单位的数据包进行管理，即所谓的字节流服务。

三次握手策略（three-way handshaking）。TCP协议将数据发送出去后，必定会向对方确认数据是否送达，不然会按顺序从新发送相同的数据包。

字段	含义
URG	紧急指针是否有效。为1，表示某一位须要被优先处理
ACK	确认号是否有效，通常置为1。
PSH	提示接收端应用程序当即从TCP缓冲区把数据读走。
RST	对方要求从新创建链接，复位。
SYN	请求创建链接，并在其序列号的字段进行序列号的初始值设定。创建链接，设置为1
FIN	但愿断开链接。

三次握手流程

四次挥手流程

在HTTP1.1中，默认链接是持久链接的（即http keep-alive），特色是只要任意一端没有明确断开链接，则保持TCP链接状态。这样就能够作到同时并行的发送多个请求，而不须要一个个的等待响应。

DNS(Domain Name System)也位于应用层的协议，它提供域名到IP地址的解析服务。

HTTP/1.1

URL与URI

URL(Uniform Resource Locator)，网页地址
URI(Uniform Resource Identifier),统一资源标识符

HTTP的工做流程

1. 浏览器与服务器创建TCP链接，即三次握手
2. TCP链接成功，浏览器发送HTTP请求命令
3. 服务接收到请求并返回HTTP响应
4. 服务器关闭链接，即四次挥手
5. 浏览器解析请求的资源

Connection:keep-alive可让TCP链接保持打开，浏览器可继续经过相同的链接发送请求。其实HTTP1.1全部的请求都是默认保持持续链接的

HTTP报文

分为请求和响应报文。由多行（CR+LF做为换行符）数据结构构成的字符串文本，大体可分为报文首部和报文主体两部分。

1. 请求行：包含请求方法，请求的URI和HTTP版本
2. 状态行：包含响应结果的状态码
3. 首部字段：包含请求和响应的各类条件、属性的各种首部；
4. 其余：包含未定义的首部如Cookie等

内容协商

请求格式

# 请求方法 URL 协议/版本
GET /u013870094/article/details/79098628 HTTP/1.1
# 用于指定被请求资源的Internet主机和端口号
Host: blog.csdn.net
# 表示是否须要持久链接。
Connection: keep-alive
# 防止页面被缓存,只有一个用法， Pragma: no-cache
Pragma: no-cache
# 这个用来指定Response-Request遵循的缓存机制
#   Cache-Control:Public    能够被任何缓存所缓存,多用户间共享
#   Cache-Control:Private   内容只缓存到私有缓存中,不能在用户间共享
#   Cache-Control:no-cache   全部内容都不会被缓存
#   Cache-Control: max-age=x：缓存时间 以秒为单位
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
# 览器的名称和版本等信
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
# 浏览器能够接受的媒体类型（MIME类型）
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
# 提供了Request的上下文信息的服务器，告诉服务器我是从哪一个连接过来的，
Referer: https://blog.csdn.net/u013870094/article/details/79098628
# 浏览器申明本身接收的编码方法，一般指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）
Accept-Encoding: gzip, deflate, br
# 浏览器申明本身接收的语言。
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: xxxxx

响应格式

HTTP/1.1 200 OK
Date: Wed, 23 Oct 2019 02:14:16 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: openresty
Vary: Accept-Encoding
Content-Encoding: gzip
Strict-Transport-Security: max-age=86400

浏览器缓存

先简单介绍下，后续有必要仔细研究下原理。

1. 第一次请求，浏览器经过HTTP的header报文头部，附带Expires,Cache-Control,Last-Modified/Etag向服务器请求，此时服务器记录第一次请求的Last-Modified/Etag
2. 再次请求，附带头部信息Expires，Cache-Control，If-Modified-Since/Etag
3. 服务器比对两次的Last-Modified/Etag与If-Modified-Since/Etag判断资源未发生变化，返回304响应

缺陷

高延迟，队头阻塞，带宽没法充分利用

队头阻塞是指当顺序发送的请求序列中的一个请求由于某种缘由被阻塞时，在后面排队的全部请求也一并被阻塞，会致使客户端迟迟收不到数据。

Chrome默认在同一个域名下，容许同时创建6个TCP持久链接，在当前请求没有结束以前，其余的请求只能处于被阻塞的状态；

解决办法：

1. 将资源分配在不一样的域名下
2. Spriting合并多张小图为一张大图
3. 将多个体积较小的Javascript合并成一个较大的文件；但当其中一个文件改变时，会致使整个文件从新被下载。

无状态特性带来巨大的头部

1. 携带过多的header信息，如user-agent,cookie,accept等；
2. 请求报文有过多的重复字段，资源浪费；

明文传输的不安全性

不支持服务推送

HTTP/2

SPDY协议

HTTP/2是现行HTTP协议（HTTP/1.x）的替代，但它不是重写，HTTP方法/状态码/语义都与HTTP/1.x同样。HTTP/2基于SPDY，专一于性能，最大的一个目标是在用户和网站间只用一个链接（connection）。

二进制传输

HTTP/2 将请求和响应数据分割为更小的帧，而且它们采用二进制编码。

它把TCP协议的部分特性挪到了应用层，把原来的"Header+Body"的消息"打散"为数个小片的二进制"帧"(Frame),用"HEADERS"帧存放头数据、"DATA"帧存放实体数据。HTP/2数据分帧后"Header+Body"的报文结构就彻底消失了，协议看到的只是一个个的"碎片"。

HTTP/2 中，同域名下全部通讯都在单个链接上完成，该链接能够承载任意数量的双向数据流。每一个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间能够乱序发送，根据帧首部的流标识能够从新组装。

Header压缩

采用HPACK算法压缩头部，压缩率50%-90%；
同时，同一个域名下的两个请求，只会发送差别数据，减小冗余的数据传输，下降开销。

多路复用

• 同一个域名下的全部通讯都在单个链接上完成；
• 单个链接能够承载任意数量的双向数据流；
• 数据流以消息的形式发送，而消息由一个或多个帧组成，能够乱序发送，由于根据帧首部的流标识能够从新组装。

这样作直观的好处是：

1. 同一个页面，只须要一个TCP慢链接的过程；
2. 能够并行交错的发送请求，请求之间互不影响；

服务端推送

指的是服务端能够新建“流”主动向客户端发送消息，提早推送客户端须要的静态资源，减小等待的延迟。

提升安全性

为了兼容，HTTP2也是明文的，只不过格式是二进制的，但HTTP2都是https协议的，跑在TSL上面。

缺陷

TCP+TLS创建链接的时间是主要瓶颈

没有从根本上解决头阻塞问题，一旦遇到丢包，那么TCP协议仍是会从新发送数据。

Future:HTTP/3

QUIC

• 基于UDP协议改造，实现了快速的握手；
• 集成了TLS的加密功能；
• 多路复用，完全解决了头阻塞问题；
• 实现了相似TCP的流量控制、传输可靠性的功能；

延伸出的几个问题

1. 网页中的图片资源为何放在不一样的域名下？
2. 浏览器与服务器创建一个TCP链接后，是否会在完成一个http请求后断开？什么条件会断开？
3. 一个TCP链接能够同时发送几个HTTP请求？
4. 浏览器http请求的并发性是如何体现的？并发请求的数量有限制么？

参考

1. https://blog.csdn.net/u013870094/article/details/79098628
2. http://www.fly63.com/article/detial/5974
3. http://www.javashuo.com/article/p-ewzpmicf-dz.html
4. https://http2.akamai.com/demo
5. http://www.javashuo.com/article/p-zqmaiqar-kb.html
6. http://www.javashuo.com/article/p-cklkuykr-kc.html