详解HTTP/1.0、HTTP/1.1、HTTP/2、HTTPS

一. 什么是HTTP协议：

摘自百度百科:

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

• HTTP属于OSI网络七层协议模型中的"最上层":应用层协议。由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议 ( HTTP无状态协议，是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快 ) 。
• HTTP默认端口号为80。它也可以承载在TLS和SSL之上，通过加密、认证的方式实现数据传输的安全，称为HTTPS，HTTPS默认端口号为443。
• 早期HTTP用于传输网页HTML文件，发展到现在，应用变得广泛，客户端软件（PC，Android,iOS等）大部分通过HTTP传输数据。

二.从浏览器输入地址到呈现页面中间发生了什么事情(通信过程)

2.1 简单来说

1. 浏览器（客户端）进行地址解析。
2. 将解析出的域名进行dns解析。
3. 通过ip寻址和arp，找到目标（服务器）地址。
4. 进行tcp三次握手，建立tcp连接。
5. 浏览器发送数据，等待服务器响应。
6. 服务器处理请求，并对请求做出响应。
7. 浏览器收到服务器响应，得到html代码。
8. 渲染页面。

通过以上这些步骤，就完成了一次完整的http请求

2.2. 深入来说

一. 浏览器（客户端）进行了地址解析。

当我们在浏览器中输入一个地址，按下回车后，浏览器获取到的是一个字符串。浏览器此时要对这个地址进行解析，获取协议，主机，端口，路径等信息。

URL的一般格式为(手记会自动过滤尖括号，所以只能上传图片了)：

例如：

http://www.imooc.com/article/draft/id/430 这个网址缺少了一些东西，端口号，用户名，密码，query和flag都没有。这些东西都是非必须的，甚至协议、路径都可以不要，最简洁的方式为imooc.com，浏览器会对一些默认的东西进行补齐。例如：互联网url默认端口号为80，浏览器默认补齐功能会补齐协议http，有些还会直接在域名前面补上www。所以实际上，即使我们输入的是imooc.com，然而实际访问的却是http://www.imooc.com。

二. 将解析出的域名进行dns解析。

第一步地址解析中我们已经获取到服务器的域名。此时就需要将域名换成对应的ip地址，这就是dns解析。dns解析分为以下几个步骤：

1. 先查看浏览器dns缓存中是否有域名对应的ip。
2. 如果没有，则产看操作系统dns缓存中是否有对应的ip（例如windows的hosts文件）。
3. 依旧没有就对本地区的dns服务器发起请求，
4. 如果还是没有，就直接到Root Server域名服务器请求解析。

这里面有几点需要关注：

<1>、DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议；

<2>、全球只有十三台逻辑根服务器，为什么是十三台，请参考https://www.zhihu.com/question/22587247?answer_deleted_redirect=true。其中任何一次解析成功就返回对应的ip地址。

三. 通过ip寻址和arp，找到目标（服务器）地址。

第二步获取到了ip，此时直接通过ip寻址找到ip对应的服务器，然后通过arp协议找到服务器的mac地址。

这里有几点需要注意：

1. ip地址（ipv4， 32位）。ip地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。ip地址分为A、B、C、D、E五大类：

A类地址：一个字节（8位）的网络地址和三个字节的主机地址。地址范围为：1.0.0.0~126.255.255.255。

B类地址：二个字节的网络地址和二个字节的主机地址。地址范围为：128.0.0.0~191.255.255.255。

C类地址：三个字节的网络地址和一个字节的主机地址。地址范围为：192.0.0.0~223.255.255.255。

D类地址：D类地址用于多点广播（Multicast），D类IP地址第一个字节以“lll0”开始，它是一个专门保留的地址。地址范围为：224.0.0.0~239.255.255.255。

E类地址：E类IP地址 以“llll0”开始，为将来使用保留。地址范围为：240.0.0.0~255.255.255.254。，255.255.255.255用于广播地址。

其中缺失了两部分，一个是0开头的，“0”表示该地址是本地主机，不能传送。一个是127开头的，127开头的是网卡自身，常用于测试。这里为什么是十进制的数字，为什么中间有‘.’，其实这都是为了方便人类而人为加上去的。转化为计算机语言就是二进制的，每一个字节八位，八位二进制能表示的最大数字就是255，这样ip地址就齐全了。可能有些人还发现ip地址为 10.170.8.61/23 ，这里涉及到局域网、保留地址和子网掩码。这里的意思是，前23位表示为该台主机的网络地址，该网络有 2^(32-23) = 512台主机。具体就不展开讲了，涉及的内容太深，太多。感兴趣的可以参考https://www.zhihu.com/question/56895036

1. IP寻址如何工作？

ip寻址主要有两种方式，一种是同一网段，一种是不同网段。要判断两个IP地址是不是在同一个网段，就将它们的IP地址分别与子网掩码做与运算，得到的结果一网络号，如果网络号相同，就在同一子网，否则，不在同一子网。

同一网段的情况：

主机A和主机B，首先主机A通过本机的hosts表或者wins系统或dns系统先将主机B的计算机名 转换为Ip地址，然后用自己的 Ip地址与子网掩码计算出自己所出的网段，比较目的主机B的ip地址与自己的子网掩码，发现与自己是出于相同的网段，于是在自己的ARP缓存中查找是否有主机B 的mac地址，如果能找到就直接做数据链路层封装并且通过网卡将封装好的以太网帧发送有物理线路上去：如果arp缓存中没有主机B的的mac地址，主机A将启动arp协议通过在本地网络上的arp广播来查询主机B的mac地址，获得主机B的mac地址厚写入arp缓存表，进行数据链路层的封装，发送数据。

不同网段的情况：

不同的数据链路层网络必须分配不同网段的Ip地址并且由路由器将其连接起来。和上面一样，主机A发现和主机B不在同一个网段，于是主机A将知道应该将次数据包发送给自己的缺省网关，即路由器的本地接口。主机A在自己的ARP缓存中查找是否有缺省网关的MAC地址，如果能够找到就直接做数据链路层封装并通过网卡 将封装好的以太网数据帧发送到物理线路上去，如果arp缓存表中没有缺省网关的Mac地址，主机A将启动arp协议通过在本地网络上的arp广播来查询缺省网关的mac地址，获得缺省网关的mac地址后写入arp缓存表，进行数据链路层的封装，发送数据。数据帧到达路由器的接受接口后首先解封装，变成ip数据包，对ip 包进行处理，根据目的Ip地址查找路由表，决定转发接口后做适应转发接口数据链路层协议帧的封装，并且发送到下一跳路由器，次过程继续直至到达目的的网络与目的主机。整个过程有点像dns解析，只是dns服务器换成了下一跳路由器，udp编程了tcp，其他差别不大。

1. arp。arp就是地址转化协议，也就是把ip地址转化为mac地址。和dns很像，先查缓存，然后查路由器。
2. mac地址。mac地址就是计算机的物理地址，每个网卡出厂时，被生产厂家烧制在网卡上。采用十六进制数表示，共六个字节（48位）。三个字节是由IEEE的注册管理机构RA负责给不同厂家分配的代码(高位24位），也称为“编制上唯一的标识符”（Organizationally Unique Identifier），后三个字节(低位24位)由各厂家自行指派给生产的适配器接口，称为扩展标识符（唯一性）。如何修改mac地址呢？一个方法就是直接修改网卡上烧制的mac地址，自己烧制。这个基本不靠谱，失误性也高。另一个方法就是修改注册表中的mac地址，因为网络中访问的mac地址都是访问的注册表中的mac地址，不会直接访问网卡。这个比较简单直接。
3. 为什么有了ip地址，还要mac地址？这个问题很关键，就像是我有驾驶证了你非要让我提供身份证。这个涉及一些历史问题，因为一开始没有互联网的时候就只有mac地址，还不存在ip地址。后来互联网越来越大之后，发现mac地址找起来太麻烦，并且耗时也越来越久，就发明了ip地址。并且mac地址在一个局域网中还是很有用的，所以就两个一起存在了。详细的信息，大家可以参考https://www.zhihu.com/question/21546408。

四. 进行tcp三次握手，建立tcp连接。

简述一下，第三步我们找到了目标ip，并获得了服务器ip的mac地址。此时浏览器就会请求和服务器连接，用来传输数据。tcp 是稳定双向面向连接的，断开时也会分两边分别断开。面向连接不是说tcp一个双方一直开着的通道，而是维持一个连接的状态，让它看起来有连接。

五. 浏览器发送数据，等待服务器响应。

第四步已经建立了连接，此时就要发送数据了。浏览器会对请求进行包装，包装成请求报文。请求报文的格式如下：

起始行：如 GET / HTTP/1.0 （请求的方法 请求的URL 请求所使用的协议）

头部信息：User-Agent Host等成对出现的值

主体

请求头部和主体之间有一个回车换行。如果是get请求，则没有主体部分，post请求有主体部分。当然里面还有些请求头部比较重要

六. 服务器处理请求，并对请求做出响应。

浏览器请求报文到达服务器之后，服务器接口会对请求报文进行处理，执行接口对应的代码，处理完成后响应客户端。由于http是无状态的，正常情况下，客户端收到响应后就会直接断开连接，然后一次http请求就完成了。但是http1.0有一个keep-alive的请求字段，可以在一定时间内不断开连接（有时时间甚至很长）。http1.1直接就默认开启了keep-alive选项。这导致了一个后果是服务器已经处理完了请求，但是客户端不会主动断开连接，这就导致服务器资源一直被占用。这时服务器就不得不自己主动断开连接，而主动断开连接的一方会出现TIME_WAIT，占用连接池，这就是产生SYN Flood攻击的原因。

此时有三种处理方式，第一是客户端主动断开连接，第二是服务器主动断开连接，第三是对tcp连接经行设置。第一种情况，如果服务器返回的数据都有确定的content-length属性，或者客户端知道服务器返回的内容终止，则客户端主动断开连接。第二种情况，服务器可以通过设置一个最大超市时间，可以主动断开tcp连接。第三种情况，调整t三个tcp参数，第一个是：tcp_synack_retries 可以用他来减少重试次数；第二个是：tcp_max_syn_backlog，可以增大syn连接数；第三个是：tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。

七. 浏览器收到服务器响应，得到html代码。

其实你心里有疑问，这一步有什么好说的。其实这里面有很多需要注意的点。浏览器发出请求时，请求报文如下：

你需要关注一个报文头--accept。accept代表发送端（客户端）希望接受的数据类型，这是浏览器自动封装的请求头。如果服务器返回的content-type是accept中的任何一个，浏览器都能解析，并直接展示在网页上。如果服务器返回的content-type是其他类型，此时浏览器有三种处理状态：

1. 正常显示。例如返回类型为text/javascript，浏览器能直接处理并展示。
2. 下载。例如返回类型为application/octet-stream（二进制流，不知道下载文件类型），这种浏览器不能直接处理的，会被下载。
3. 报错。当我们返回一个字符串hello world，却使用text/xml，格式时，浏览器不能正确解析，就会报错，并把报错信息呈现在网页中。

浏览器能直接处理很多种格式，并直接呈现在网页中，并不限于accept中规定的字段，具体有哪些，就需要自己亲自动手试试了。

附上一张content-type常用对照表地址：http content-type常用对照表

八. 渲染页面。

获取到服务器相应之后，浏览器会根据相应的content-type字段对响应字符串进行解析。能够解析并成功解析就显示，能够解析但解析错误就报错，不能解析就下载。由于浏览器采用至上而下的方式解析，所以会先解析html，直到遇到外部样式和外部脚本。这时会阻塞浏览器的解析，外部样式和外部脚本（在没有async、defer属性下）会并行加载，但是外部样式会阻塞外部脚本的执行，dom加载完毕，js脚本执行成功后dom树构建完成（DOMContentLoaded），之后就加载dom中引用的图片等静态资源。（参考文章地址：http://blog.csdn.net/u014168594/article/details/52196460）

即：

1. html解析->外部样式、脚本加载->外部样式执行->外部脚本执行->html继续解析->dom树构建完成->加载图片->页面加载完成。
2. 情况一：如果是动态脚本（即内联脚本）则不受样式影响，在解析到它时会执行。
3. 情况二：外部样式后续外部脚本含有async属性（IE下为defer），外部样式不会阻塞该脚本的加载与执行

在外部样式执行完毕后，css附着于DOM，创建了一个渲染树（渲染树是一些被渲染对象的集）。每个渲染对象都包含了与之对应的计算过样式的DOM对象，对于每个渲染元素来说，位置都经过计算，所以这里被叫做“布局”。然后将“布局”显示在浏览器窗口，称之为“绘制”。

1. 接着脚本的执行完毕后，DOM树构建完成。这时，可以触发DOMContentLoaded事件。DOMContentLoaded事件的触发条件是：在所有的DOM全部加载完毕并且JS加载执行后触发。

1.情况一：如果脚本是动态加载，则不会影响DOMContentLoaded时间的触发，浏览器会等css加载完成后再加载图片，因为不确定图片的样式会如何。

1. 要点一：CSS样式表会阻塞图片的加载，如果想让图片尽快加载，就不要给图片使用样式，比如宽高采用标签属性即可。
2. 要点二：脚本不会阻塞图片的加载

最后页面加载完成，页面load。

总结一下：运维人员需要处理页面缓存、cdn及keep-alive引起的连接池占用等问题；后端人员需要处理代码逻辑、缓存、传输优化、报错等问题；前段人员需要做好前端性能优化和配合运维、后端做好借口调试，缓存处理等问题。所以无论是前端、后台、运维都应该很清楚整个流程中的每一步，才能在配合时，得心应手，才能在出现问题时，快速准确的定位问题解决问题，才能在需要优化时，迅速完整的给出方案。

ps:本篇文章之介绍了http事物，如果是https事物，整个流程和http事物大致相同，唯一不同的就是在http层和tcp层多了一个ssl层，所以在发送数据前会有个ssl握手，发送数据时会有个ssl层的加密。ssl涉及到的东西也不少，例如ssl握手，加密技术，还要ssl层到底在tcp/ip四层协议哪一层的问题等等

三. HTTP请求和响应详解

客户端请求消息

客户端请求消息客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

请求行(request line)、请求头部(header)、空行和请求数据四个部分组成

下图给出了请求报文的一般格式

1. 请求行：请求报文的第一行，用来说明以什么方式请求、请求的地址和HTTP版本
2. 头部字段：每个头部字段都包含一个名字和值，二者之间采用“：”连接，如：Connection：Keep-Alive
3. 请求数据：请求的主体根据不同的请求方式请求主体不同

服务器响应消息

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文

1. 状态行：由HTTP版本、响应状态码、响应状态描述；如：HTTP/1.1 200 OK
2. 响应报文头部：使用关键字和值表示，二者使用“：”隔开；如：Content-Type：text/html
3. 响应内容：请求空行之后就是请求内容

四. HTTP发展史(包括版本)

• HTTP/0.9：1991年发布，极其简单，只有一个get命令
• HTTP/1.0：1996年5月发布，增加了大量内容
• HTTP/1.1：1997年1月发布，进一步完善HTTP协议，是目前最流行的版本
• SPDY ：2009年谷歌发布SPDY协议，主要解决HTTP/1.1效率不高的问题
• HTTP/2 ：2015年借鉴SPDY的HTTP/2发布

五. HTTP/1.0和1.1的区别

1. 缓存处理：HTTP/1.0 使用 Pragma:no-cache + Last-Modified/If-Modified-Since来作为缓存判断的标准；HTTP/1.1 引入了更多的缓存控制策略：Cache-Control、Etag/If-None-Match等
2. 错误状态管理：HTTP/1.1新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 范围请求：HTTP/1.1在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接，支持断点续传
4. Host头：HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础
5. 持久连接：HTTP/1.1 最大的变化就是引入了持久连接（persistent connection），在HTTP/1.1中默认开启 Connection: keep-alive，即TCP连接默认不关闭，可以被多个请求复用

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接

1. 管道机制：HTTP/1.1中引入了管道机制（pipelining）,即在同一个TCP连接中，客户端可以同时发送多个请求

六. HTTP/1.1的缺点

HTTP/1.1 的持久连接和管道机制允许复用TCP连接，在一个TCP连接中，也可以同时发送多个请求，但是所有的数据通信都是按次序完成的，服务器只有处理完一个回应，才会处理下一个回应。比如客户端需要A、B两个资源，管道机制允许浏览器同时发出A请求和B请求，但服务器还是按照顺序，先回应A请求，完成后再回应B请求，这样如果前面的回应特别慢，后面就会有很多请求排队等着，这称为"队头阻塞(Head-of-line blocking)"

七. HTTP/2

HTTP/2以Google发布的SPDY协议为基础，于2015年发布。它不叫HTTP/2.0，因为标准委员会不打算再发布子版本了，下一个新版本将是HTTP/3。HTTP/2协议只在HTTPS环境下才有效，升级到HTTP/2，必须先启用HTTPS。HTTP/2解决了HTTP/1.1的性能问题，主要特点如下：

1. 二进制分帧：HTTP/1.1的头信息是文本（ASCII编码），数据体可以是文本，也可以是二进制；HTTP/2 头信息和数据体都是二进制，统称为“帧”：头信息帧和数据帧；
2. 多路复用（双工通信）：通过单一的 HTTP/2 连接发起多重的请求-响应消息，即在一个连接里，客户端和浏览器都可以同时发送多个请求和响应，而不用按照顺序一一对应，这样避免了“队头堵塞”。HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
3. 数据流：因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。HTTP/1.1取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。
4. 首部压缩：HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息压缩后再发送（SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法）。；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
5. 服务端推送：HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

八. HTTPS

HTTPS可以说是安全版的HTTP，HTTPS基于安全SSL/TLS（安全套接层Secure Sockets Layer/安全传输层Transport Layer Security）层，即在传统的HTTP和TCP之间加了一层用于加密解密的SSL/TLS层。HTTP默认使用80端口，HTTPS默认使用443端口。

不使用SSL/TLS的HTTP通信，所有信息明文传播，会带来三大风险：

窃听风险：第三方可以获取通信内容；篡改风险：第三方可以修改通信内容；冒充风险：第三方可以冒充他人进行通信。SSL/TLS协议是为了解决这三大风险而设计的，以期达到：

信息加密传输：第三方无法窃听；校验机制：一旦被篡改，通信双方会立刻发现；身份证书：防止身份被冒充。

SSL/TLS发展

SSL/1.0：1994年NetScape公司设计，未发布；SSL/2.0：1995年NetScape公司发布，但存在严重漏洞；SSL/3.0：1996年NetScape公司发布，得到大规模应用；TLS/1.0：1999年互联网标准化组织（ISOC）接替NetScape公司，发布SSL的升级版TLS/1.0；TLS/1.1：2006年发布；TLS/1.2：2008年发布；TLS/1.2修订版：2011年发布。目前，应用最广泛的是 TLS/1.0 和 SSL/3.0，且主流浏览器已实现 TLS/1.2的支持。

SSL/TLS运行机制

SSL/TLS的基本思路是公钥加密法：客户端先向服务器索要并验证公钥，然后用公钥加密传输来协商生成“对话秘钥”（非对称加密），双方采用“对话秘钥”进行加密通信（对称加密）。

通信过程如下：

1. 客户端发出请求：给出支持的协议版本、支持的加密方法（如RSA公钥加密）以及一个客户端生成的随机数（Client random）；
2. 服务端回应：确认双方通信的协议版本、加密方法，并给出服务器证书以及一个服务器生成的随机数（Server random）；
3. 客户端回应：客户端确认证书有效，取出证书中的公钥，然后生成一个新的随机数（Premaster secret），使用公钥加密这个随机数，发送给服务端；
4. 服务端回应：服务端使用自己的私钥解密客户端发来的随机数（Premaster secret），客户端和服务端根据约定的加密方法，使用三个随机数，生成“对话秘钥”；
5. 会话通信：客户端和服务端使用“对话秘钥”加密通信，这个过程完全使用普通的HTTP协议，只不过用“会话秘钥”加密内容。

前四步称为握手阶段，用于客户端和服务端建立连接和交换参数。整个通信过程可用下图所示：

HTTPS特点

缓存：只要在HTTP头中使用特定命令，就可以缓存HTTPS；延迟：HTTP耗时 = TCP握手；HTTPS耗时 = TCP握手 + SSL握手。SSL握手耗时大概是TCP握手耗时的三倍左右。

九. 参考资料

https://www.zhihu.com/tardis/sogou/art/43787334

https://blog.csdn.net/weixin_38150378/article/details/79408886

https://www.runoob.com/http/http-tutorial.html

https://blog.csdn.net/alexwll/article/details/82287737