HTTP协议：一.什么是 HTTP 协议？

前言：本篇文章主要参考自《图解HTTP》，在学习期间也查询过其他资料。仅作为个人的学习记录。

一.什么是 HTTP 协议

1.关于 HTTP 协议

1)HTTP协议是 TCP/IP 五层模型中应用层的一个协议

HTTP 协议和 TCP/IP 协议族内的其他众多协议相同,用户客户端和服务器之间的通信.

访问文本或者图像资源的一段称为客户端,而提供资源响应的一端称为服务器端

2)版本号:

HTTP1: 当前主流版本,基于 TCP 协议.(HTTP/1.0 --> HTTP/1.1)
HTTP2: 也是基于 TCP 协议,但用的不多,是HTTPS的加强版本
HTTP3: 基于 UDP 协议,提高效率(还在建设中)

3)HTTP 是超文本传输协议:

超文本也就是 HTML,当我们发送 HTTP 请求的时候,响应就会返回相应的页面.

4)HTTP 是不保存状态的协议

HTTP 是一种不保存状态的协议,即**无状态协议.**HTTP 协议自身不对请求和响应之间的通信状态进行保存.

图:HTTP 协议自身不具备保存之前发送过的请求或响应的功能

一开始是为了能够更快的处理大量的事务,而设计的,但无状态也有弊端,如果无法保存状态,当我们使用一个购物网站,每次点开一个页面就得进行登录一次.这样做就很影响用户的体验.

所以为了解决无状态的协议带来的问题,HTTP/1.1 引入了Cookie 技术.就能够管理状态了.

2.URI 和 URL

1)概念

URI(Uniform Resource Identifier,统一资源标识符) : 用字符串标识某一互联网资源

URL(Uniform Resource Locator，统一资源定位符 ): 用户标识资源的地点(俗成"网址")

二者关系: URL 是 URI 的子集

2)URI 格式

**协议名:**采用 HTTP 协议时,协议方案就是 http://,除此之外,还有 https,file,telnet,jdbc(jdbc:mysql://) 等协议

**服务器地址: **可以是域名,也可以是详细 IP 地址

**服务器端口号: **可以不写,有默认端口号 .HTTP 协议默认端口号为80,HTTPS 默认端口号为 443

带层次的文件路径: 指定服务器上的文件路劲来定位特指的资源

**查询字符串(query string): **以 ? 标志开始,是以键值对的形式来进行组织的,键值对之间用 & 分割,键和值之间用 = 分割

3)query string 的注意事项

URL 中有一些特殊符号: ? / : . = &

如果在 query string 中的键或值也参有这些符号,而不进行处理就会出现问题.

所以我们需要对这些键或值中的这些特殊的符号进行转译

URL encode: 把特殊字符转义成转义字符

URL decode: 把转义字符转义成特殊字符

在线转义网站

输入汉字则是对应 utf-8 编码,每个汉字对应三个字符

3.HTTP 协议的工作过程

当我们访问一个 URL 地址,会发生什么呢?

例如访问下,b站

https://www.bilibili.com/

此时我们得到一个动态页面.

看起来很简单,但其中涉及到 TCP/IP 多个协议

交互图如下:

注: 以下内容涉及到 TCP/IP 协议相关知识

准备工作: 客户端发送请求数据报

1)看此 URL 中服务器地址是否为 IP 地址.例如 www.bilibili.com 则为域名.则先通过 DNS 协议,根据域名查找到对应的 IP 地址.

2)从上到下,先是在应用层,浏览器打包好对应数据后,会构造一个 HTTP 请求并发送

3)这个数据包会往下走,到达传输层.浏览器就要调用操作系统的socket api,把这个HTTP数据交给TCP来进一步处理

HTTP 协议使用了 TCP 请求,对这个数据包进行再封装成一个 TCP 数据包.
在发送数据包之前,会进行"三次握手"确认连接(TCP 协议能够保证可靠传输)

注: 此处的三次握手涉及到的SYN/ACK也是同样要经过网络层,数据链路层,物理层,依次封装到达对端服务器之后再依次分用的

建立好连接后,将数据包发给下层(网络层)

4)网络层就负责具体的传输,使用 IP 协议.其作用就是将数据包送达目的地主机(当前服务器)

当前: 目的主机 IP 为 www.bilibili.com 所对应的IP地址

在网络层接收到数据之后,IP 协议就对这个数据包进行再封装,封装成一个 IP 数据包.

发送给下层数据链路层.

注: 在网络层这一层,还会维护一个路由表(通过"路由协议"制作而成)

路由器根据路由**控制表（Routing Table）**转发数据包它根据所收到的数据包中目标主机的IP地址与路由控制表的比较得出下一个应该接收的路由器

5)到达数据链路层后,使用**“以太网协议”,会继续对这个数据包进行封装成一个以太网数据帧**

在构造帧头的时候,会根据 IP 地址映射到 MAC 地址(ARP 协议: 用以解析地址的协议,根据通信方的 IP 地址就可以反查出对应的 MAC 地址)

ARP 寻址: 查找下一跳的路由器/主机的 MAC 地址

首先会明确最终的 IP 地址,根据最终 IP 地址,通过查询路由表,确定下一跳的 IP 地址.然后根据 ARP 寻址,找到下一跳的 MAC 地址.(网络层)

6)物理层

物理层将这个数据,以二进制的方式,将0,1转化成电压(电信号)和脉冲光(光信号)传输给物理的传输介质.

中间转发

7)当从客户端发出数据报后,很少是会直接到达目的主机(服务器).而是中间会经过很多路由器,通过这些路由器进行转发,最终到达目的主机.

而到达路由器,再跳往下一个路由器,也是会经过层层的封装和分用的.

过程: 路由器接收到数据报后,物理层把光电信号转成以太网数据帧,交给数据链路层.
然后数据链路层会拆掉以太网帧头,得到一个 IP 数据报,将其交给网络层.
然后取出 IP 地址,查询路由表,找到下一跳的 IP 地址,再依次进行封装.经过数据链层的时候,会根据这个 IP 地址,通过 ARP 寻找查找到下一跳的 MAC 地址.

重复这个过程

收到数据: 服务器接收数据报,返回响应数据报

8)服务器接收到这个数据包,也会经过层层的解析.

物理层把光电信号转换成以太网数据帧,交给数据链路层.
数据链路层解析(去掉以太网帧头帧尾)出 IP 数据包,交给网络层.
网络层会根据首部的 IP 地址,判断是否为发送自己的包(crc校验,),是的话就根据首部中的类型域来判断是传输层是何种协议(此处是 TCP 协议),否则丢弃;然后就进行再解析,解析出 TCP 数据报.交给传输层
再根据 TCP 数据报中的端口号,找到对应的应用,把数据放到对应的 socket 的接收缓冲区里了.

9)到达应用层,应用程序就会调用的 socket api,从 TCP 接受缓冲区中接受数据,按照相应的协议(此处是HTTP 协议)进行解析.获取到其中的 URL,根据 URL 中指定的路劲获取到资源

bilibili 服务器就会对这个路径进行配置,映射到一个具体的 HTML 文件,然后读取到这个文件,把这个文件的内容构造成一个 HTTP 响应数据,然后再调用 socket api 进行发送.

10)重复封装的过程,最后到达物理层,响应数据变成光电信号,进行传输.

11)重复转发过程,到达客户端主机.

12)重复分用过程,得到响应的数据,交给应用程序进行处理

13)浏览器(对应客户端主机)得到 HTTP 响应数据报,解析这个报文,获取到了里面的内容,根据 HTML 进行渲染.

4.持久连接

1)持久连接节省通信量

在 HTTP 协议的初始版本中,每进行一次 HTTP 通信就要断开一次 TCP 连接.

使用浏览器浏览一个包含多张图片的 HTML页面时，在发送请求访问 HTML页面资源的同时，也会请求该 HTML页面里包含的其他资源。

每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。

需要注意的是, 建立 TCP 连接的时候,也是需要经过层层封装,转发,层层分用的过程的.如果每次进行请求都要重新建立 TCP 连接,那么就会造成很大不必要的开销

2)进行持久连接

为解决上述 TCP 连接的问题， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或HTTP connection reuse）的方法。 持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

图：持久连接旨在建立 1 次 TCP 连接后进行多次请求和响应的交互

在 HTTP/1.1 中,所有的连接默认为持久连接

3)管线化

管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

**图：不等待响应，直接发送下一个请求 **

比如，当请求一个包含 10 张图片的 HTML Web 页面，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术则比持久连接还要快。请求数越多，时间差就越明显。

5.使用 Cookie 进行状态管理

HTTP 是无状态协议,它不对之前发生过的请求和响应的状态进行管理,也就是说,无法根据之前的状态进行本次的请求处理.

假设要求登录认证的 Web 页面本身无法进行状态的管理（不记录已登录的状态），那么每次跳转新页面不是要再次登录，就是要在每次请求报文中附加参数来管理登录状态。

对于无状态协议来说,由于不必保存状态,自然可减少服务器的 CPU 以及内存资源的消耗

**图：如果让服务器管理全部客户端状态则会成为负担 **

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

没有 Cookie 信息状态下的请求

第 2 次以后（存有 Cookie 信息状态）的请求

上图展示了发生 Cookie 交互的情景， HTTP 请求报文和响应报文的内容如下:

请求报文（没有 Cookie 信息的状态）

GET /reader/ HTTP/1.1
Host: hackr.jp
*首部字段内没有Cookie的相关信息

响应报文（服务器端生成 Cookie 信息）

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain; charset=UTF-8

请求报文（自动发送保存着的 Cookie 信息）

GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724

可以抓个包看看.

为了考虑安全性,浏览器是禁止网页直接访问计算机的磁盘的,但是在网页开发的时候,又需要能够在网页端保存一些数据.

早期的时候,主要就是依赖Cookie
以键值对的形式存储的数据.存储量相对来说比较小,只能存一些简单的数据
使用Cookie最常见的用法,就是存储用户的身份信息(会话ID)

保存在浏览器这边的Cookie就会在后续的请求中,自动的带入到请求的报头中