每个Web开发者必须知道的HTTP/1.1 part2-CSDN博客

HTTP: The Protocol Every Web Developer Must Know - Part 2

code.tutsplus.com/tutorials/h…

摘要：

HTTP Connections
- 在我们建立通信之前我们需要建立连接，HTTP使用可靠的TCP transport protocol，默认使用80端口，TCP流被分解成IP数据包，它确保这些数据包总是按正确的顺序到达，不会出错。HTTP是TCP之上的应用层协议，TCP是IP之上的协议。(TCP stream is broken into IP packets, and it ensures that those packets always arrive in the correct order without fail.)
- HTTPS是HTTP的安全版本，在HTTP和TCP之间插入一个额外的层，称为TLS或SSL(Transport Layer Security or Secure Sockets Layer, 分别是传输层安全性或安全套接字层)。
- HTTP Connetctions
  - 通过DNS从主机名解析IP地址
  - 与服务器建立连接
  - 发送请求
  - 等待响应
  - 关闭连接
- sub-optimal 次优的
- 在HTTP/1.0，所有的连接在一次事务完成后都会被关闭
- 为了减少连接建立延迟(connection-establishment delays)，HTTP/1.1引入了persistent connections, 默认使用长连接，发起一次事务连接时需要在request header中设置Connection: colse
- 除了持久连接之外，浏览器/客户机还使用一种称为并行连接（parallel connections）的技术来最小化网络延迟。古老的并行连接概念涉及创建连接池(通常限制在6个连接)。如果客户端需要从网站上下载6个资产，那么客户端会建立6个并行连接来下载这些资产，从而加快周转速度。与串行连接相比，这是一个巨大的改进，在串行连接中，客户端只在完成前一个资产的下载之后才下载资产。
Server-side Connection Handling
- Server服务器主要监听传入的连接，并在接收请求时处理它们。
  - 建立套接字以开始监听端口80(或其他端口) (establishing a socket to start listening on port 80 (or some other port))
  - 接收请求并解析消息 (receiving the request and parsing the message)
  - 处理响应 (processing the response)
  - 设置响应头部 (setting response headers)
  - 将响应发送到客户机 (sending the response to the client)
  - 如果设置 Connection: close 则关闭连接 (close the connection if a Connection: close request header was found)
- exhaustive 详尽的；彻底的；消耗的
身份识别和认证 Identification and Authentication
- 为了跟踪应用程序或站点的使用情况以及用户的一般交互模式，几乎必须知道谁连接到服务器。
- premise
  - n. 前提；上述各项；房屋连地基
    
    vt. 引出，预先提出；作为…的前提
    
    vi. 作出前提
- 有几种不同的方式，服务器可以收集这些信息，和大多数网站使用这些方法的混合:
  - Request headers: From, Referer, User-Agent - We saw these headers in Part 1.
  - Client-IP - 客户端的IP地址 the IP address of the client
  - Fat Urls - 通过修改URL并在每次单击时重定向到不同的URL来存储当前用户的状态;每次点击都会累积状态
  - Cookies - 最流行的非侵入性方法。
    - cookie 设置一个或者多个 name=value 对，使用 (;)分隔,
- 识别用户的最佳方法是要求他们注册和登录，但是实现这个特性需要开发人员和用户付出一些努力。
- Authentication
  - rudimentary 基本的；初步的；退化的；残遗的；未发展的
  - HTTP确实支持一种称为基本身份验证的基本形式的身份验证，以及更安全的摘要身份验证。Basic Authentication, as well as the more secure Digest Authentication
  - Basic Authentication
    - Server denies client requst with www-Authenticate response header and 401 Unauthorized
    - client 看到这个头部，展示登录对话框（login dialog）
    - 根据填入的消息，然后使用base-64 encoded format，将发送的信息放在Authentication request header.
    - 一些Server还可能发送包含额外身份验证详细信息的Authentication-Info header。
  - 代理认证 Proxy Authentication
    - intermediate proxy 中间代理
    - 代理发送 Proxy-Authenticate 头部状态码407 Unauthorized . 作为回复, 客户端应该通过(via) Proxy-Authorization请求头发送凭证(credentials).
  - 摘要身份验证（Digest Authentication）与基本身份验证类似，使用与“WWW-Authenticate”和“Authorization”报头相同的握手技术，但摘要身份验证使用更安全的散列函数加密用户名和密码(通常使用MD5或KD摘要函数)。尽管摘要身份验证应该比基本身份验证更安全，但由于其简单性，网站通常使用基本身份验证。为了减轻安全性问题，基本身份验证与SSL结合使用
- 安全的HTTP Secure HTTP
  - SSL使用RSA和公钥加密的强大加密形式 SSL uses a powerful form of encryption using RSA and public-key cryptography.
  - a powerful form of 一种强有力的
  - encryption 加密，数据加密
  - cryptography 密码学
  - 现有的客户机/服务器不需要改变它们处理消息的方式，因为大部分艰苦的工作都发生在SSL层。因此，可以使用Basic Authentication 开发web应用程序，并通过切换到https://协议自动获得SSL的好处。然而，要使web应用程序在HTTPS上工作，您需要在服务器上部署一个工作的数字证书。
  - web服务器需要一个数字证书来标识自己。证书(或“证书”)由证书颁发机构(CA)颁发，并在web上为您的身份作担保
  - 当客户机通过HTTPS发出请求时，它首先尝试定位服务器上的证书。如果找到证书，它将尝试根据已知的ca列表对其进行验证。如果它不是列出的CAs之一，它可能会向用户显示一个关于网站证书的对话框。
    
    一旦证书得到验证，SSL握手就完成了，安全传输就生效了。
- HTTP Caching
  - 同样的事情做两次很浪费，这是HTTP caching概念的指导原则
  - pillar n. 柱子，柱形物；栋梁；墩
    
    vt. 用柱支持
    
    n. (Pillar)人名；(英)皮勒
  - HTTP Network Infrastructure的支柱之一
  - 节省时间、节省带宽、改善体验
  - 缓存用于网络基础结构中的多个位置，从浏览器到源服务器.
    - Private: 在浏览器中，缓存用户名、密码、url、浏览历史和web内容。它们通常很小，并且是特定于用户的.
    - Public: 部署为服务器和客户机之间的缓存代理。它们要大得多，因为它们服务于多个用户。一种常见的做法是在客户机和原始服务器之间保留多个缓存代理。这有助于服务频繁访问的内容，同时仍然允许访问服务器获取不经常需要的内容.
  - 缓存处理 Cache Processing
    - 无论缓存位于何处，维护缓存的过程都非常类似 Regardless of where a cache is located, the process of maintaining a cache is quite similar:
    - 维护缓存的过程 the process of maintaining a cache
      - Receive request message. 接受到请求
      - Parse the URL and headers. 解析URL和头部
      - Lookup a local copy; otherwise, fetch and store locally 检查本地副本,否则fetch并本地存储
      - Do a freshness check to determine the age of the content in the cache; make a request to refresh the content only if necessary. 进行freshness check，有必要的话刷新内容
      - Create the response from the cached body and updated headers. 根据缓存中和更新的头部创建响应
      - Send the response back to client. 发送给client
      - Optionally, log the transaction. 其他
  - Cache Control Headers
    - 与持久连接相结合的并行连接是当今最小化网络延迟的解决方案.
    - 以上了解caching的工作方式，是时候看一下在response and request headers 中启用caching infrastructure
    - consistent with 与...一致
    - 其中两项关键的技术：Document Expiration and Server Revalidation
    - 文档过期 Document Expiration
      - HTTP允许原始服务器使用“Cache-Control”和“Expires”response headers为每个文档附加一个“到期日期” HTTP allows an origin-server to attach an expiration date to each document using the Cache-Control and Expires response headers.
    - 服务器再验证 Server Revalidation
      - 可以使用两种请求头来完成重新验证步骤:“If-Modified-Since”和“If-None-Match” The revalidation step can be accomplished with two kinds of request-headers: If-Modified-Since and If-None-Match.
      - If-Modified-Since, the Last-Modified response header is used; for If-None-Match, it is the ETag response header. 请求头中If-Modified-Since的值使用响应头中的Last-Modified，请求头中的If-None-Match使用响应头中的ETag
    - Controlling the Cachability
      - Cache-Control: no-cache: 允许客户端存储文档;但是，它必须在每个请求上与服务器重新验证。有一个名为Pragma: no-cache的HTTP/1.0兼容头文件，其工作原理是一样的.
      - Cache-Control: no-store: 这是一个更强的指令，要求客户端完全不存储文档.
      - Cache-Control: must-revalidate: 这告诉客户端绕过其新鲜度计算，并始终与服务器重新验证。如果服务器不可用，则不允许提供缓存的响应.
      - Cache-Control: max-age: 这将设置从生成响应开始的相对过期时间(以秒为单位).
    - Cachability 可缓存性
    - 限制来自客户机的新鲜度 Constraining Freshness from the Client
      - Cache-Control: min-fresh=<s>: the document must be fresh for at least <s> seconds.
      - Cache-Control: max-stale or Cache-Control: max-stale=<s>: the document cannot be served from the cache if it has been stale for longer than <s> seconds.
      - Cache-Control: max-age=<s>: the cache cannot return a document that has been cached longer than <s> seconds.
      - Cache-Control: no-cache or Pragma: no-cache: the client will not accept a cached resource unless it has been revalidated.

在我之前的文章中，我们介绍了HTTP的一些基础知识，例如URL方案，状态代码和请求/响应标头。以此为基础，我们将研究HTTP的更精细方面，如连接处理，身份验证和HTTP缓存。这些主题相当广泛，但我们将介绍最重要的内容。

HTTP连接

客户端和服务器之间必须建立连接才能相互通信，HTTP使用可靠的TCP传输协议进行连接。默认情况下，Web流量使用TCP端口80. TCP流被分解为IP数据包，并确保这些数据包始终以正确的顺序到达而不会失败。HTTP是TCP上的应用层协议，它是通过IP实现的。

HTTPS是HTTP的安全版本，在HTTP和TCP之间插入一个名为TLS或SSL（传输层安全性或安全套接字层Transport Layer Security or Secure Sockets Layer）的附加层。HTTPS默认通过端口443进行通信，我们将在本文后面介绍HTTPS。

HTTP连接由 <source-IP，source-port> 标识和 <destination-IP，destination-port> 。在客户端上，HTTP应用程序由 <IP，port> 元组标识。在两个端点之间建立连接是一个多步骤过程，涉及以下内容：

通过DNS从主机名解析IP地址 resolve IP address from host name via DNS
与服务器建立连接 establish a connection with the server
发送请求 send a request
等待响应 wait for a response
关闭连接 close connection

服务器负责始终使用正确的标头和响应进行响应。

在HTTP / 1.0中，所有连接在单个事务后关闭。因此，如果客户端想要从同一服务器请求三个单独的图片，它就会与远程主机建立三个独立的连接。从上图中可以看出，这会引入大量网络延迟，从而导致次优的用户体验。

为了减少连接建立延迟，HTTP / 1.1引入了 持久连接，长期连接保持打开直到客户端关闭它们。持久连接在HTTP / 1.1中是默认的，并且建立单个事务连接需要客户端设置Connection：close 请求标头。这告诉服务器在发送响应后关闭连接。

除了持久连接之外，浏览器/客户端还采用称为 并行连接的技术来最小化网络延迟。古老的并行连接概念涉及创建连接池（通常以六个连接为上限）。如果客户需要从网站下载六个资产，则客户端会建立六个并行连接来下载这些资产，从而加快周转速度（resulting in a faster turnaround）。这是对串行连接的巨大改进，串行的做法是客户端仅在完成先前资源的下载后下载资源。

并行连接与持久连接相结合，是当今最小化网络延迟并在客户端上创建流畅体验的答案。有关HTTP连接的深入处理，请参阅 HTTP规范的 Connections section 。

服务器端连接处理

服务器主要侦听传入连接并在收到请求时处理它们。这些行动包括：

establishing a socket to start listening on port 80 (or some other port)
receiving the request and parsing the message
processing the response
setting response headers
sending the response to the client
close the connection if a Connection: close request header was found

当然，这不是详尽的操作清单。大多数应用程序/网站需要知道谁提出请求才能创建更多自定义响应。这是一个 identification and authentication的领域。

Identification and Authentication

HTTP是TCP上的应用层协议，它是通过IP实现的。

几乎必须知道谁连接到服务器以跟踪应用程序或站点的使用情况以及用户的一般交互模式。识别的前提是定制响应以提供个性化体验; 当然，服务器必须知道用户是谁才能提供该功能。

服务器可以通过几种不同的方式收集此信息，大多数网站使用这些方法的混合：

Request headers**: From, Referer, User-Agent - We saw these headers in Part 1.
Client-IP - the IP address of the client
Fat Urls - storing state of the current user by modifying the URL and redirecting to a different URL on each click; each click essentially accumulates state.
Cookies - the most popular and non-intrusive approach.

Cookie允许服务器通过 Set-Cookie 响应头附加传出响应的任意信息。使用由分号（; ）分隔的一个或多个name = value 对设置cookie ，如Set-Cookie中所示：session-id = 12345ABC; username = nettuts 。

服务器还可以将cookie限制为特定域（domain）和路径（path），它可以标记过期（expires）后持久化。浏览器会针对服务器发出的每个请求自动发送Cookie，浏览器会确保在请求中仅发送域和路径特定的Cookie。请求头部Cookie：name = value [; name2 = value2] 用于将这些cookie发送到服务器。

识别用户的最佳方法是要求他们注册并登录，但实现此功能需要开发人员和用户付出一些努力。

像 OAuth 这样的技术可以简化此类功能，但仍需要用户同意才能正常工作。身份验证在这里发挥着重要作用，它可能是识别和验证用户的唯一方法。

Authentication

HTTP确实支持称为基本形式验证的基本身份验证（ Basic Authentication）形式，以及更安全的摘要式身份验证（Digest Authentication）。

在基本身份验证中，服务器最初使用 WWW-Authenticate 响应头和401 Unauthorized 状态代码拒绝客户端的请求。在看到此标题时，浏览器会显示一个登录对话框，提示输入用户名和密码。此信息在身份验证请求标头中以base-64编码格式发送。服务器现在可以验证请求，并在凭据有效时允许访问。某些服务器可能还会发送包含其他身份验证详细信息的Authentication-Info 标头。

基本身份验证的必然结果是 代理身份验证（Proxy Authentication）。验证挑战请求中间代理而不是Web服务器。代理发送带有407 Unauthorized 状态代码的Proxy-Authenticate 标头。作为回复，客户端应该通过Proxy-Authorization请求头部发送凭证。

摘要式身份验证与Basic类似，并使用与 WWW-Authenticate 相同的握手技术和授权标头，但Digest使用更安全的散列函数来加密用户名和密码（通常使用MD5或KD摘要功能）。尽管摘要式身份验证应该比基本身份验证更安全，但网站通常使用基本身份验证，因为它很简单。为了缓解安全问题，Basic Auth与SSL结合使用。

安全的HTTP（Secure HTTP）

HTTPS协议在Web上提供安全连接。了解您是否使用HTTPS的最简单方法是检查浏览器的地址栏。HTTPs的安全组件涉及在HTTP和TCP之间插入一层加密/解密。这是安全套接字层 (Secure Sockets Layer) (SSL)或改进的传输层安全(Transport Layer Security)（TLS）。

SSL使用强大的加密形式，使用RSA和公钥加密。由于安全交易在网络上如此重要，因此基于标准的普遍存在的公钥基础设施（PKI）工作已经进行了很长时间。

现有客户端/服务器不必更改处理消息的方式，因为大多数艰苦工作都发生在SSL层中。因此，您可以使用基本身份验证开发Web应用程序，并通过切换到 https：// 协议自动获得SSL的好处。但是，要使Web应用程序通过HTTPS工作，您需要在服务器上部署有效的数字证书。

证书（Certificates）

正如您需要身份证来显示您的身份一样，Web服务器需要数字证书来识别自己。证书（或“证书”）由证书颁发机构（CA）颁发，并在网上为您的身份提供担保。CA是PKI的监护人。最常见的证书形式是 X.509 v3 standard，其中包含以下信息：

证书颁发者 the certificate issuer
用于证书的算法 the algorithm used for the certificate
为其创建此证书的主题名称或组织 the subject name or organization for whom this cert is created
该主题的公共密钥信息 the public key information for the subject
证书颁发机构签名，使用指定的签名算法 the Certification Authority Signature, using the specified signing algorithm

当客户端通过HTTPS发出请求时，它首先尝试在服务器上找到证书。如果找到证书，它会尝试根据其已知的CA列表进行验证。如果它不是列出的CA之一，它可能会向用户显示一个对话框，警告该网站的证书。

验证证书后，SSL握手完成，安全传输生效。

HTTP缓存（HTTP Caching）

人们普遍认为，两次做同样的工作是浪费。这是围绕HTTP缓存概念的指导原则，HTTP缓存是HTTP网络基础设施的基础支柱。由于大多数操作都是通过网络进行的，因此缓存有助于节省时间，成本和带宽，并在Web上提供改进的体验。

高速缓存用于网络基础结构中的几个位置，从浏览器到源服务器。根据它的位置，缓存可以分类为：

Private ：在浏览器中，缓存用户名，密码，URLs，浏览历史记录和Web内容。它们通常很小并且特定于用户。
Public ：部署为服务器和客户端之间的缓存代理。它们更大，因为它们服务于多个用户。通常的做法是在客户端和源服务器之间保留多个缓存代理。这有助于提供经常访问的内容，同时仍然允许访问服务器以获取不常需要的内容。

缓存处理（Cache Processing）

无论缓存位于何处，维护缓存的过程都非常相似：

接收请求消息。 Receive request message.
解析 URL和标头。 Parse the URL and headers.
查找本地副本; 否则，在本地获取和存储 Lookup a local copy; otherwise, fetch and store locally
进行 新鲜度检查以确定缓存中内容的年龄; 仅在必要时请求刷新内容。 Do a freshness check to determine the age of the content in the cache; make a request to refresh the content only if necessary.
创建响应从缓存的正文和更新的标题。 Create the response from the cached body and updated headers.
发送回复客户的回应。 Send the response back to client.
（可选）记录事务。 Optionally, log the transaction.

当然，服务器负责始终使用正确的标头和响应进行响应。如果文档未更改，则服务器应使用 304 Not Modified进行响应。如果缓存副本已过期，则应生成具有更新响应标头的新响应，并返回200 OK 。如果资源被删除，它应该返回404 Not Found 。这些响应有助于调整缓存并确保陈旧内容不会保留太长时间。

缓存控制标头（Cache Control Headers）

并行连接与持久连接相结合，是当今最小化网络延迟的答案。

现在我们已经了解了缓存的工作原理，现在是时候查看启用缓存基础结构的请求和响应头。保持内容新鲜和最新是缓存的主要职责之一。为了使缓存副本与服务器保持一致，HTTP提供了一些简单的机制，即Document Expiration 和 服务器重新验证（Server Revalidation）。

文件到期（Document Expiration）

HTTP允许源服务器使用Cache-Control 将到期日期附加到每个文档和过期响应头。这有助于客户端和其他缓存服务器知道文档有效和新鲜的时间。只要缓存可以提供副本年龄该文件的有效期限。文档到期后，缓存必须与服务器核对更新的副本并相应地更新其本地副本。

Expires 是一个较旧的HTTP / 1.0响应头，它将值指定为绝对日期。这仅在服务器时钟与客户端同步时才有用，这是一个可怕的假设。与较新的Cache-Control 相比，此标头不太有用：HTTP / 1.1中引入的max-age = <s> 标头。这里， max-age 是一个相对年龄，以秒为单位，从创建响应开始。因此，如果文档在一天后过期，则过期标头应为Cache-Control：max-age = 86400 。

服务器重新验证（Server Revalidation）

缓存文档到期后，缓存必须与服务器重新验证，以检查文档是否已更改。这称为 服务器重新验证，并用作文档陈旧的查询机制。仅仅因为缓存副本已过期并不意味着服务器实际上具有更新的内容。重新验证只是确保缓存保持新鲜的一种方法。由于到期时间（在先前的服务器响应中指定），缓存不必针对每个请求检查服务器，从而节省带宽，时间并减少网络流量。

文档过期和服务器重新验证的组合是一种非常有效的机制，它允许分布式系统维护具有过期日期的副本。

如果已知内容经常更改，则可以减少到期时间 - 允许系统更频繁地重新同步。

重新验证步骤可以使用两种请求标头来完成： If-Modified-Since 和如果 - 无匹配。前者用于基于日期的验证，而后者使用实体标签（ETags），内容的散列。这些标头使用从先前服务器响应获得的日期或ETag值。在 If-Modified-Since的情况下，使用Last-Modified 响应头; 对于 If-None-Match ，它是 ETag 响应头。

控制可达性

文档的有效期应由生成文档的服务器定义。如果是报纸网站，主页应该在一天之后（有时甚至每小时！）过期。HTTP提供 Cache-Control 和过期响应标头以设置文档的到期时间。如前所述，Expires 基于绝对日期而不是控制缓存的可靠解决方案。

该 Cache-Control 标头更有用，并且有一些不同的值来约束客户端缓存响应的方式：

Cache-Control: no-cache**: the client is allowed to store the document; however, it must revalidate with the server on every request. There is a HTTP/1.0 compatibility header called Pragma: no-cache, which works the same way.
Cache-Control: no-store: this is a stronger directive to the client to not store the document at all.
Cache-Control: must-revalidate: this tells the client to bypass its freshness calculation and always revalidate with the server. It is not allowed to serve the cached response in case the server is unavailable.
Cache-Control: max-age: this sets a relative expiration time (in seconds) from the time the response is generated.

**Cache-Control：no-cache** ：允许客户端存储文档; 但是，它必须在每个请求上重新验证服务器。有一个名为 **Pragma：no-cache** 的HTTP / 1.0兼容头，它的工作方式相同。
**Cache-Control：no-store** ：这是一个更强大的指令，客户端根本不存储文档。
**Cache-Control：must-revalidate** ：这告诉客户端绕过其新鲜度计算并始终使用服务器重新验证。如果服务器不可用，则不允许提供缓存的响应。
**Cache-Control：max-age** ：设置生成响应时的相对到期时间（以秒为单位）。
复制代码

另外，如果服务器不发送任何 Cache-Control 头部，则客户端可以自由使用其自己的启发式过期算法来确定新鲜度。