计算机网络 第二讲：HTTP

参考资料：

JavaGuide面试指南

这一节内容比较多，相信你读完一定有很多的收获。加油！！！

HTTP

1、从输入URL 到页面展示到底发生了什么？（非常重要）

变向问题：打开一个网站，整个过程会使用到哪些协议？

上图有一个错误，请注意，是 OSPF 不是 OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议, 是由 Internet 工程任务组开发的路由选择协议

总体来说分为以下几个过程:

1. URL 输入
2. DNS 解析
3. 建立TCP 连接
4. 发送 HTTP 请求
5. 服务器处理请求并返回 HTTP 报文
6. 浏览器解析渲染页面
7. HTTP 请求结束，断开 TCP 连接

1.1、URL 输入：

URL（统一资源定位符，Uniform Resource Locator）用于定位互联网上资源，俗称网址。

我们在地址栏输入 HZFE 官方网址 hzfe.org 后敲下回车，浏览器会对输入的信息进行以下判断：

检查输入的内容是否是一个合法的 URL 链接。
是，则判断输入的 URL 是否完整。如果不完整，浏览器可能会对域进行猜测，补全前缀或者后缀。
否，将输入内容作为搜索条件，使用用户设置的默认搜索引擎来进行搜索。

1.2、DNS（Domain Name System）解析：

因为浏览器不能直接通过域名找到对应的服务器 IP 地址，所以需要进行 DNS 解析，查找到对应的 IP 地址进行访问。

DNS 解析流程如下：

DNS 解析 ：

1. 在浏览器中输入 hzfe.org 域名，操作系统先检查浏览器缓存和本地的 hosts 文件中，如果有记录，则从记录里面找到对应的 IP 地址，完成域名解析。

2. 查找本地 DNS 解析器缓存中，如果有记录，从记录里面找到对应的 IP 地址，完成域名解析。

3. 使用 TCP/IP 参数中设置的 DNS 服务器进行查询。如果要查询的域名包含在本地配置区域资源中，则返回解析结果，完成域名解析。

4. 检查本地 DNS 服务器是否缓存该网址记录，有则返回解析结果，完成域名解析。

5. 本地 DNS 服务器发送查询报文至根 DNS 服务器，根 DNS 服务器收到请求后，用顶级域 DNS 服务器地址进行响应。

6. 本地 DNS 服务器发送查询报文至顶级域 DNS 服务器。顶级域 DNS 服务器收到请求后，用权威 DNS 服务器地址进行响应。

7. 本地 DNS 服务器发送查询报文至权威 DNS 服务器，权威 DNS 服务器收到请求后，用 hzfe.org 的 IP 地址进行响应，完成域名解析。

1.3、建立 TCP 连接

世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的，TCP/IP 是全球计算机及网络设备都在使用的一种常用的分组交换网络分层。 HTTP 的连接实际上就是 TCP 连接以及其使用规则。

当浏览器获取到服务器的 IP 地址后，浏览器会用一个随机的端口（1024 < 端口 < 65535）向服务器 80 端口发起 TCP 连接请求（注：HTTP 默认约定 80 端口，HTTPS 为 443 端口）。这个连接请求到达服务端后，通过 TCP 三次握手，建立 TCP 的连接。

分层模型：

    ----------------------------------
  7|   应用层   |           |   HTTP  |

  6|   表示层   |   应用层   |

  5|   会话层   |           |         |
    ---------------------------------
  4|   传输层   |   传输层   | TCP TLS |
    ---------------------------------
  3|   网络层   |   网络层   |   IP    |
    ---------------------------------
  2|  数据链路层
               |   链路层
  1|   物理层
    --------------------------------
       [OSI]   |   [TCP/IP]

TCP 三次握手

# SYN 是建立连接时的握手信号，TCP 中发送第一个 SYN 包的为客户端，接收的为服务端
# TCP 中，当发送端数据到达接收端时，接收端返回一个已收到消息的通知。这个消息叫做确认应答 ACK

  假设有客户端A，服务端B。我们要建立可靠的数据传输。
      SYN(=j)       // SYN: A 请求建立连接
  A ----------> B
                |
     ACK(=j+1)  |   // ACK: B 确认应答 A 的 SYN
     SYN(=k)    |   // SYN: B 发送一个 SYN
  A <-----------
  |
  |  ACK(=k+1)
   -----------> B   // ACK: A 确认应答 B 的包

1.4、TLS 协商

TLS协商：
建立连接后就可以通过 HTTP 进行数据传输。如果使用 HTTPS，会在 TCP 与 HTTP 之间多添加一层协议做加密及认证的服务。HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 协议，保障了信息的安全。

这 两个协议是加在 HTTP应用层 和 TCP传输层 之间的。

• SSL

  • 认证用户和服务器，确保数据发送到正确的客户端和服务器。
  • 加密数据防止数据中途被窃取。
  • 维护数据的完整性，确保数据在传输过程中不被改变。

• TLS

  • 用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

1.4.1、TLS握手协议

TLS握手协议：

1. 客户端发出一个 client hello 消息，携带的信息包括：所支持的 SSL/TLS 版本列表；支持的与加密算法；所支持的数据压缩方法；随机数 A。

2. 服务端响应一个 server hello 消息，携带的信息包括：协商采用的 SSL/TLS 版本号；会话 ID；随机数 B；服务端数字证书 serverCA；由于双向认证需求，服务端需要对客户端进行认证，会同时发送一个 client certificate request，表示请求客户端的证书。

3. 客户端校验服务端的数字证书；校验通过之后发送随机数 C，该随机数称为 pre-master-key，使用数字证书中的公钥加密后发出；由于服务端发起了 client certificate request，客户端使用私钥加密一个随机数 clientRandom 随客户端的证书 clientCA 一并发出。

4. 服务端校验客户端的证书，并成功将客户端加密的随机数 clientRandom 解密；根据随机数 A/随机数 B/随机数 C（pre-master-key） 产生动态密钥 master-key，加密一个 finish 消息发至客户端。

5. 客户端根据同样的随机数和算法生成 master-key，加密一个 finish 消息发送至服务端。
   服务端和客户端分别解密成功，至此握手完成，之后的数据包均采用 master-key 进行加密传输。

1.5、服务器响应

当浏览器到 web 服务器的连接建立后，浏览器会发送一个初始的 HTTP GET 请求，请求目标通常是一个 HTML 文件。服务器收到请求后，将发回一个 HTTP 响应报文，内容包括相关响应头和 HTML 正文。

1.5.1、状态码

状态码是由 3 位数组成，第一个数字定义了响应的类别，且有五类可能取值

• 1xx：指示信息——表示请求已接收，继续处理
• 2xx：成功——表示请求已被成功接收、理解、接受
• 3xx：重定向——要完成请求必须进行更进一步的操作
• 4xx：客户端错误——请求有语法错误或请求无法实现
• 5xx：服务器端错误——服务器未能实现合法的请求

1.5.2、常见的请求头和字段

• Cache-Control：must-revalidate、no-cache、private（是否需要缓存资源）
• Connection：keep-alive（保持连接）
• Content-Encoding：gzip（web 服务器支持的返回内容压缩编码类型）
• Content-Type：text/html；charset=UTF-8（文件类型和字符编码格式）
• Date：Sun， 21 Sep 2021 06:18:21 GMT（服务器消息发出的时间）
• Transfer-Encoding：chunked（服务器发送的资源的方式是分块发送）

1.5.3、HTTP 响应报文

响应报文由四部分组成（响应行 + 响应头 + 空行 + 响应体）

• 状态行：HTTP 版本 + 空格 + 状态码 + 空格 + 状态码描述 + 回车符（CR） + 换行符（LF）
• 响应头：字段名 + 冒号 + 值 + 回车符 + 换行符
• 空行：回车符 + 换行符
• 响应体：由用户自定义添加，如 post 的 body 等

1.6、浏览器解析并绘制

不同的浏览器引擎渲染过程都不太一样，这里以 Chrome 浏览器渲染方式为例。

• 处理 HTML 标记并构建 DOM 树。
• 处理 CSS 标记并构建 CSSOM 树。
• 将 DOM 与 CSSOM 合并成一个渲染树。
• 根据渲染树来布局，以计算每个节点的几何信息。
• 将各个节点绘制到屏幕上。

1.7、TCP 断开连接

现在的页面为了优化请求的耗时，默认都会开启持久连接（keep-alive），那么一个 TCP 连接确切关闭的时机，是这个 tab 标签页关闭的时候。这个关闭的过程就是四次挥手。关闭是一个全双工的过程，发包的顺序是不一定的。一般来说是客户端主动发起的关闭，过程如下图所示：

1. 主动关闭方发送一个 FIN，用来告诉被动关闭方：我已经不会再给你发数据了（在 FIN 包之前发送出去的数据，如果没有收到对应的 ACK 确认报文，主动关闭方依然会重发这些数据），但此时主动关闭方还可以接受数据。

2. 被动关闭方收到 FIN 包后，发送一个 ACK 给对方，确认序号为收到序号+1（与 SYN 相同，一个 FIN 占用一个序号）。

3. 被动关闭方发送一个 FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

4. 主动关闭方收到 FIN 后，发送一个 ACK 给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

2、HTTP 状态码有哪些？

2xx Success（成功状态码）

• 200 OK ：请求被成功处理。比如我们发送一个查询用户数据的HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
• 201 Created ：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
• 202 Accepted ：服务端已经接收到了请求，但是还未处理。
• 204 No Content ： 服务端已经成功处理了请求，但是没有返回任何内容。

3xx Redirection（重定向状态码）

• 301 Moved Permanently ： 资源被永久重定向了。比如你的网站的网址更换了。
• 302 Found ：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

4xx Client Error（客户端错误状态码）

• 400 Bad Request ： 发送的HTTP请求存在问题。比如请求参数不合法、请求方法错误。
• 401 Unauthorized ： 未认证却请求需要认证之后才能访问的资源。
• 403 Forbidden ：直接拒绝HTTP请求，不处理。一般用来针对非法请求。
• 404 Not Found ： 你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
• 409 Conflict ： 表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

5xx Server Error（服务端错误状态码）

• 500 Internal Server Error ： 服务端出问题了（通常是服务端出Bug了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
• 502 Bad Gateway ：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。

3、HTTP 和 HTTPS (应用层)有什么区别？（重要）

• 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
• URL 前缀 ：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
• 安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

---

3.1、HTTP 协议

HTTP 协议介绍：
HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾名思义，HTTP 协议就是用来规范超文本的传输，超文本，也就是网络上的包括文本在内的各式各样的消息，具体来说，主要是来规范浏览器和服务器端的行为的。

并且，HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。

HTTP 协议优点：
扩展性强、速度快、跨平台支持性好。

3.1.1、HTTP 协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：

服务器在 80 端口等待客户的请求。
浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
服务器接收来自浏览器的 TCP 连接。
浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
关闭 TCP 连接。

3.2、HTTPS 协议

HTTPS 协议介绍

• HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。 默认端口号是 443.

• HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。

HTTPS 协议优点：

• 保密性好、信任度高

3.2.1、HTTPS 的核心—SSL/TLS协议

• HTTPS 之所以能达到较高的安全性要求，就是**结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。**接下来重点介绍一下 SSL/TLS 的工作原理。

SSL 和 TLS 的区别？：
SSL 和 TLS 没有太大的区别。

SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

3.2.2、SSL/TLS 的工作原理

非对称加密

• SSL/TLS 的核心要素是非对称加密。非对称加密采用两个密钥——一个公钥，一个私钥。 在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。可以设想一个场景，

在某个自助邮局，每个通信信道都是一个邮箱，每一个邮箱所有者都在旁边立了一个牌子，上面挂着一把钥匙：这是我的公钥，发送者请将信件放入我的邮箱，并用公钥锁好。
但是公钥只能加锁，并不能解锁。解锁只能由邮箱的所有者——因为只有他保存着私钥。
这样，通信信息就不会被其他人截获了，这依赖于私钥的保密性。

非对称加密的公钥和私钥需要采用一种复杂的数学机制生成（密码学认为，为了较高的安全性，尽量不要自己创造加密方案）。公私钥对的生成算法依赖于单向陷门函数。

单向函数：已知单向函数 f，给定任意一个输入 x，易计算输出 y=f(x)；而给定一个输出 y，假设存在 f(x)=y，很难根据 f 来计算出 x。
单向陷门函数：一个较弱的单向函数。已知单向陷门函数 f，陷门 h，给定任意一个输入 x，易计算出输出 y=f(x;h)；而给定一个输出 y，假设存在 f(x;h)=y，很难根据 f 来计算出 x，但可以根据 f 和 h 来推导出 x。
这里的 h 就是私钥

在这里，函数 f 的计算方法相当于公钥，陷门 h 相当于私钥。公钥 f 是公开的，任何人对已有输入，都可以用 f 加密，而要想根据加密信息还原出原信息，必须要有私钥才行。

x 是我们要传的消息，通过 f 加密 ，f ( x ; h ) = y，得到消息y，传递 y 给接收者，接收者通过 私钥 h，y = f ( x ; h ) 反推出 x。但是如果没有私钥h，是无法反推的，h也叫陷门

对称加密

使用 SSL/TLS 进行通信的双方需要使用非对称加密方案来通信，但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。

对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。

对称加密的密钥生成代价比公私钥对的生成代价低得多，那么有的人会问了，为什么 SSL/TLS 还需要使用非对称加密呢？因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。 这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性

公钥传输的信赖性

SSL/TLS 介绍到这里，了解信息安全的朋友又会想到一个安全隐患，设想一个下面的场景：

客户端 C 和服务器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。要注意网络信道通信中有几个前提：

1. 任何人都可以捕获通信包
2. 通信包的保密性由发送者设计
3. 保密算法设计方案默认为公开，而（解密）密钥默认是安全的

因此，假设 S 公钥不做加密，在信道中传输，那么很有可能存在一个攻击者 A，发送给 C 一个诈包，假装是 S 公钥，其实是诱饵服务器 AS 的公钥。当 C 收获了 AS 的公钥（却以为是 S 的公钥），C 后续就会使用 AS 公钥对数据进行加密，并在公开信道传输，那么 A 将捕获这些加密包，用 AS 的私钥解密，就截获了 C 本要给 S 发送的内容，而 C 和 S 二人全然不知。
同样的，S 公钥即使做加密，也难以避免这种信任性问题，C 被 AS 拐跑了

为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。

当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

• 小结：CA（受信任的第三方） 会给每个服务器 证书，客户端在请求服务器之前，服务器会先把证书给客户端，证书里面有公钥和数字签名，客户端会检查证书的 合法性，如果合法 就使用上面的公钥。

数字签名

数字签名防止证书被伪造，第三方信赖机构 CA 之所以能被信赖，就是 靠数字签名技术 。

数字签名，是 CA 在给服务器颁发证书时，使用 散列+加密 的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下：

CA 知道服务器的公钥，对证书采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密，并附在证书下方，发送给服务器。
现在服务器将该证书发送给客户端，客户端需要验证该证书的身份。客户端找到第三方机构 CA，获知 CA 的公钥，并用 CA 公钥对证书的签名进行解密，获得了 CA 生成的摘要。
客户端对证书数据（包含服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。

发送方私钥是CA私钥，发送方公钥是CA公钥

总结来说，带有证书的公钥传输机制如下：

1. 设有服务器 S，客户端 C，和第三方信赖机构 CA。
2. S 信任 CA，CA 是知道 S 公钥的，CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
3. S 获得 CA 颁发的证书，将该证书传递给 C。
4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。

• 小结：服务器发送的证书是 原文A+签名（CA私钥加密的原文A）， 传给 客户端，此时客服端有原文A 和签名，客户端向CA要CA公钥，解密签名，得到原文B，对比原文A和原文B，相同意味着验证成功。

4、HTTP 1.0 和 HTTP 1.1 有什么区别？

• 连接方式 : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
• 状态响应码 : HTTP/1.1中新加入了大量的状态码
• 缓存处理 : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
• 带宽优化及网络连接的使用 ： HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• Host头处理 : HTTP/1.1在请求头中加入了Host字段

4.1、响应状态码

HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。

4.2、缓存处理

缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟。

HTTP/1.0：
HTTP/1.0提供的缓存机制非常简单。服务器端使用Expires标签来标志（时间）一个响应体，在Expires标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被请求资源在服务器端的最后一次修改。在请求头中，使用If-Modified-Since标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之后，我要请求的资源是否有被修改过？”通常情况下，请求头中的If-Modified-Since的值即为上一次获得该资源时，响应体中的Last-Modified的值。

如果服务器接收到了请求头，并判断If-Modified-Since时间后，资源确实没有修改过，则返回给客户端一个304 not modified响应头，表示”缓冲可用，你从浏览器里拿吧！”。

如果服务器判断If-Modified-Since时间后，资源被修改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。

HTTP/1.1：
HTTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是Cache-Control

4.3、连接方式

HTTP/1.0 默认使用短连接 ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。

为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。 采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。

有必要说明的是，HTTP/1.0仍提供了长连接选项，即在请求头中加入Connection: Keep-alive。同样的，在HTTP/1.1中，如果不希望使用长连接选项，也可以在请求头中加入Connection: close，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。

HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

实现长连接需要客户端和服务端都支持长连接。

4.4、Host头处理

域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题，假设我们有一个资源URL是http://example1.org/home.html，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。

因此，HTTP/1.1在请求头中加入了Host字段。加入Host字段的报文头部将会是:

GET /home.html HTTP/1.1
Host: example1.org

这样，服务器端就可以确定客户端想要请求的真正的网址了。

4.5、带宽优化

范围请求：

HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略Range头部，也可以返回若干Range响应。

如果一个响应包含部分数据的话，那么将带有206 (Partial Content)状态码。该状态码的意义在于避免了HTTP/1.0代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。

• 在范围响应中，Content-Range头部标志指示出了该数据块的偏移量和数据块的长度。

状态码100：
HTTP/1.1中新加入了状态码100。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以作为指示请求是否会被正常响应，过程如下图：

然而在HTTP/1.0中，并没有100 (Continue)状态码，要想触发这一机制，可以发送一个Expect头部，其中包含一个100-continue的值。

压缩：
许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。

HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。

HTTP/1.0包含了Content-Encoding头部，对消息进行端到端编码。HTTP/1.1加入了Transfer-Encoding头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了Accept-Encoding头部，是客户端用来指示他能处理什么样的内容编码。

5、HTTP 是不保存状态的协议, 如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

6、URI 和 URL 的区别是什么?

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。