不得不了解的HTTP协议

了解 HTTP 协议

浏览器背后的故事

当我们在浏览器输入一个域名后，背后究竟发生了什么？

第一步：当我们输入域名后，在 DNS 服务器进行域名查询。

第二步：得到对应的 ip 地址。

第三步：浏览器根据 ip 向 web 服务器进行通信发送请求，而通信的协议就是 HTTP。

第四步：web 服务器回传页面内容。

第五步：浏览器收到回传信息的报文数据，进行渲染出我们看得懂的页面。

举个例子：如果我们想给张三打电话，我们需要在通讯录中先找到名字为张三的人，而张三这个名字就是域名，对应的手机号就是 ip。在通话过程中我讲普通话，而张三讲英语，这样肯定是没有办法沟通的，而共同语言就是 HTTP 协议。

那什么是 HTTP？

• 超文本传输协议(Hyper Text Transfer Protocol)是一种通信协议，它允许将超文本标记语言(HTML)文档从 Web 服务器传送到客户端的浏览器。

• HTTP 是一个属于应用层的面向对象的协议，由于其便捷、快速的方式，适用于分布式超媒体信息系统。它于 1990 年提出，经过几年的使用与发展，得到不断的完善和扩展。

WEB 和 HTTP

• WEB 是一种基于超文本和 HTTP 的、全球性的、动态交互的、跨平台的分布式图形信息系统。

• 建立在 Internet 的一种网络服务，为浏览者在 Internet 上查找和浏览信息提供了图形化的、易于访问的直观界面，其中的文档及超级链接将 Internet 上的信息节点组织成一个互为关联的网状结构。

HTTP 协议的前世今生

万维网的创始人叫蒂姆·伯纳斯·李（Tim Berners-Lee）简单点说，是当代互联网的创始人。

在 1990 年，他发表了一篇论文，提出了在互联网上构建超链接文档系统的构想，在这篇论文里他确立了三项关键技术：

• URI：统一资源标识符，作为互联网上资源的唯一标识
• HTML：超文本标记语言，描述超文本文档
• HTTP：超文本传输协议，用来传输超文本

这三项技术直接奠定了我们当今 Web 世界的技术，蒂姆把它称为万维网（World Wide Web）。

所以，1991 年，HTTP 0.9 诞生了。

HTTP 0.9

该版本极其简单，只有一个命令 GET。协议规定，服务器只能回应 HTML 格式的字符串，不能回应别的格式。服务器发送完毕，就关闭 TCP 连接。

虽然这一版 HTTP 协议虽然很简单，但是作为一个原型，充分验证了 Web 服务的可行性。

HTTP 1.0

主要增加了以下几部分内容：

• 增加了 HEAD/POST 等新方法
• 增加了响应状态码
• 增加了版本号
• 增加了 Header 头部的概念
• 增加了 Content-Type，传输数据不再仅限于文本

但是 HTTP/1.0 并不是一个标准，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，相当于一个备忘录。

HTTP 1.1

主要增加了以下几部分内容：

• 增加了 PUT/DELETE/OPITIONS 等新方法
• 增加了缓存控制和管理 Cache Control
• 明确了连接管理，允许持久连接 Keepalive
• 允许响应数据分块，利于传输大文件（Chunked）
• 强制要求 Host 头

由于 HTTP/1.1 太过庞大和复杂，因此在 2014 年又进行了一次修订，拆分为六份较小的文档

这六份文档增加了两个大的需求：

• 加大了 HTTP 的安全性，比如使用 TLS 协议
• 让 HTTP 可以支持更多的应用，目前已经支持四种网络协议：
  • 传统的短连接
  • 可重用 TCP 的长连接模型
  • 服务端 PUSH 模型
  • WebSocket 模型

HTTP 2.0

HTTP/1.1 存在两个问题：

1. 连接慢，请求是串行的，需要保证顺序，例如一个网页中可能会有多个资源

2. 性能差，HTTP/1.1 是以文本的方式，借助 CPU 的 zip 压缩方式减少网络带宽，但是耗费了 前端和后端的 CPU
   2010 年，Google 推出了新的 SPDY 协议，并应用于自家的服务器，HTTP/2 就是以 SPDY 为基础的，它的特点主要是：

   • 使用二进制传输，不再是纯文本
   • 可以在一个 TCP 连接中并发多个 HTTP 请求，移除了 HTTP/1.1 中的串行请求
   • 使用 HPACK 算法来压缩头部
   • 允许服务器主动向客户端推送数据
   • 增强了安全性，基于 TLS 协议

HTTP 3.0

HTTP 2.0 的主要问题有队头阻塞问题，也就是说，若干个 HTTP 请求在复用一个 TCP 的连接，那么一旦发生丢包，造成的问题就是所有的请求都必须等待这个丢了的包重传回来，哪怕这个包不是我的 HTTP 请求的。

基于此，Google 发明了 QUIC（Quick UDP Internet Connections）协议，它是基于 UDP 的。

因此，它就解决了以下几个问题：

• UDP 是无序的，因此不存在队头阻塞问题
• QUIC 有一套自己的丢包重传和拥塞控制的协议
• HTTPS 握手通常需要六次网络交互，QUIC 直接将 TLS 和 TCP 合并成了三次握手

透过 TCP/IP 看 HTTP

HTTP 协议是构建在TCP/IP协议之上的，是 TCP/IP 协议的一个子集。

TCP/IP 协议族

TCP/IP 协议其实是一系列与互联网相关联的协议集合起来的总称。

TCP/IP 协议族是由一个四层协议组成的系统，这四层分别为：应用层、传输层、网络层、数据链路层。

应用层

应用层一般是我们编写的应用程序，决定了向用户提供的应用服务。应用层可以通过系统调用与传输层进行通信。如：FTP、DNS、HTTP等。

传输层

传输层通过系统调用向应用层提供处于网络连接中的两台计算机之间的数据传输功能。

在传输层有两个性质不同的协议：TCP、UDP。

网络层

网络层用来处理在网络上流动的数据包，数据包是网络传输的最小数据单位。该层规定了通过怎样的路径(传输路线)到达对方的计算机，并把数据包传输给对方。

链路层

链路层用来处理连接网络的硬件部分，包括控制操作系统、硬件设备驱动、NIC(Network Interface Card，网络适配器)以及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。

HTTP 数据传输过程

发送端发送数据时，数据会从上层传输到下层，且每经过一层都会被加上该层的头部信息。

而接收端接受数据时候，数据会从下层传输到上层，传输前会把下层的头部信息删除。

传输层 —— TCP 三次握手

• 第一次握手：客户端发送带有 SYN 标志的连接请求报文段，然后进入 SYN_SEND 状态，等待服务端确认。

• 第二次握手：服务端接受到客户端的 SYN 报文段后，需要发送 ACK 信息对这个 SYN 报文段进行确认。同时，还要发送自己的 SYN 请求信息。服务端会将上述信息放到一个报文段(SYN+ACK 报文段)中，一并发送给客户端，此时服务端进入 SYN_RECV 状态。

• 第三次握手：客户端接收到服务端的 SYN+ACK 报文段后，会向服务端发送 ACK 确认报文段，这个报文段发送完毕后，客户端和服务端都进入 ESTABLEISHED 状态，完成 TCP 三次握手。

顺便说一下四次挥手：

当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。

原理：

1. 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2. 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3. 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4. 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

DNS 域名解析

已经介绍了与 HTTP 协议有着密切关系的 TCP/IP 协议，接下来介绍的 DNS 服务也是与 HTTP 协议有着密不可分的关系。

通常我们访问一个网站，使用的是主机名或者域名来进行访问的。因为相对于 IP 地址（一组纯数字），域名更容易让人记住。但 TCP/IP 协议使用的是 IP 地址进行访问的，所以必须有个机制或服务把域名转换为 IP 地址，DNS 服务就是用来解决这个问题的，DNS提供了域名到IP地址之间的解析服务。

DNS 域名解析流程

1. 浏览器缓存 ：当用户通过浏览器访问某域名时，浏览器首先会在自己的缓存中查找是否有该域名对应的 IP 地址（若曾经访问过该域名且没有清空缓存）。

2. 系统缓存 ：当浏览器缓存中无域名对应 IP 则会自动检查用户计算机系统 Hosts 文件 DNS 缓存是否有该域名对应 IP。

3. 路由器缓存 ：当浏览器及系统缓存中均无域名对应 IP 则进入路由器缓存中检查，以上三步均为客户端的 DNS 缓存。

4. ISP（互联网服务提供商）DNS缓存 ： 当在用户客服端查找不到域名对应 IP 地址，则将进入 ISP DNS 缓存中进行查询。比如用的是电信的网络，则会进入电信的 DNS 缓存服务器中进行查找。

5. 根域名服务器：当以上均未完成，则进入根服务器进行查询。全球仅有 13 台根域名服务器，1 个主根域名服务器，其余 12 为辅根域名服务器。根域名收到请求后会查看区域文件记录，若无则将其管辖范围内顶级域名（如.com）服务器 IP 告诉本地 DNS 服务器。

6. 顶级域名服务器：顶级域名服务器收到请求后查看区域文件记录，若无则将其管辖范围内主域名服务器的 IP 地址告诉本地 DNS 服务器。

7. 主域名服务器：主域名服务器接受到请求后查询自己的缓存，如果没有则进入下一级域名服务器进行查找，并重复该步骤直至找到正确记录。

8. 保存结果至缓存：本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时将该结果反馈给客户端，客户端通过这个 IP 地址与 web 服务器建立链接。

回顾 HTTP 事务处理流程

当客户端访问 Web 站点时，首先会通过 DNS 服务查询到域名的 IP 地址。然后浏览器生成 HTT