简述HTTP

HyperText Transfer Protocol(HTTP)

HTTP是一个用于传输超媒体文档（hypermedia documents）的应用层协议，其主要使用场景是网络浏览器和网络服务器之间进行通信。

1. 信息内容：Web Page

浏览器中显示的页面叫做网页(Web Page)，其通常由如下两部分构成：

• HTML文件，描述对象和布局等信息

• 对象，单个页面中可能包含多个对象，这些对象可以是图片、文件、视频等。对象可能以URL形式给出

1.1 Hypertext Markup Language(HTML)

Hyper means over or above , 即"超"的意思。所谓超媒体、超文本，意指包括但不限于的意思。典型的超媒体文档类型为HTML。

HTML是一种用于创建网页的标准标记语言，和CSS、JavaScript一起构建了万维网（World Wide Web, WWW）的基础。通常我们可以按如下形式来理解三者的关系：

• HTML结构化元素：通过标记符号来标记要显示的网页中的各个基本元素如文字、图片甚至音视频等
• CSS呈现形式：定义不同呈现方式如字体、颜色、边距等
• JavaScript负责界面功能：定义不同组件的行为，形成交互

1.2 Uniform Resource Locator(URL)

Uniform Resource Identifier(URI) 是一个由字符组成的字符串，用于标示具体资源。URI代表的是一种象征，象征着网络中每一个资源都有唯一的标识符以便于访问。URL是URI的一种常见形式，另一种还有Uniform Resource Name(URN），两者区别是：

• URN 类似于人名，标示一个资源名称

• URL 类似于地址，标示如何找到该资源

以http://www.someSchool.edu/someDepartment/picture.gif为例，URL通常由两部分组成：

• 存储对象的主机名， www.someSchool.edu
• 主机中对象的具体路径, /someDepartment/picture.gif

2. 通信流(flow)

HTTP使用TCP作为传输协议，Server与Client交互过程中会建立TCP连接，但并不会保存任何Client的状态信息，因此HTTP也成为无状态(stateless)协议。

计算机相互之间进行通讯通常有两种方式：

• 请求响应（request-response）

  向对端主机发送请求后需等待响应，这类通信过程就是由一系列的单次通信构成，典型应用如网页浏览

• 单向（one-way ）

  向对端主机发送消息后无需等待回复，典型应用如邮件

2.1 TCP

如前文所述，HTTP通信方式属于请求响应类型，因此单次通信流程通常为：

• 建立TCP连接
• 发送HTTP消息（message, 应用层信息单元）
• 读取服务器响应
• 关闭TCP连接

由于HTTP为无状态协议（即每次通信间无关联），因此通常来讲，HTTP每次通信都是使用独立TCP连接的。大部分网络应用中，client和server会在一定时间内通信多次，从每次request和response是否通过同一TCP链接发送的角度来看，可以划分为两种：

• 短连接（non-persistent connections），每个request/response对均使用单独TCP链接
• 长连接（persistent connections），每个request/response对均使用同一TCP链接

在HTTP 0.9和1.0中，连接均会在单词请求响应后关闭，而TCP连接的建立和消亡需要经过三路握手、四路断开，因此需要一定额外时间开销。有鉴于此，从HTTP 1.1开始，所有连接默认为长连接。更进一步地，如果不必每个单次通信都需等待响应后才能继续下一个通信，则可以实现流水线技术，提高并发量。

2.2 Message格式

解决了连接的问题，剩下的就是消息格式了。前面提过，通信的基础是有效的转换和逆转换，转换需要规则，规则就是协议。对于HTTP而言，存在两种规则，分别为request和response。

HTTP 1.1及之前版本中，message均是可读性强字符。在HTTP 2中，这些消息将被先封装至二进制结构frame中，并通过frame header进行其他如复用等配置。

2.2.1 Request

先放一个示例：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

(data data data data data ...)

可以看出，组成元素均为可读性强的ASCII字符，具体格式则可进一步细分为如下结构:

2.2.2 Response

HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ...)

3. 字段定义

3.1 Request methods

HTTP请求中定义了method字段以标明希望在URL上执行的操作，而该资源将如何呈现、是否已存在或将被动态创建，均基于服务器的实现本身。主流应用中，通常会选择实现如下方法：

• GET

  请求所需资源，该请求除获取数据外不应产生其他效果

• HEAD

  功能与GET相当，区别在于响应中不包括具体数据，即不含response body。可以理解为GET的轻量级，只查看元信息而不实际获取。

• POST

  将请求body中内容推送至服务器，或是存储在URI指定的资源下，或是其他实现形式

• PUT

  将请求body中内容存储至服务器中URI指定位置，如该URI已有资源，将被修改；如无资源，则将创建

• DELETE

  删除服务器中指定资源

• TRACE

  告知服务器回传所收请求，以便客户端确认链路中是否发生修改行为

• OPTIONS

  返回服务器在指定URL上所支持的方法，如URL为'*'，则查询对象为服务器本身

• CONNECT

  告知服务器去返回指定URL，并将其获取到的Response转发回请求客户端，相当于代理，网页开发中并不常用，仅预留做管理

• PATCH

  对资源进行局部修改操作

HTTP Method	RFC	Request Has Body	Response Has Body	Safe	Idempotent	Cacheable
GET	RFC 7231	Optional	Yes	Yes	Yes	Yes
HEAD	RFC 7231	No	No	Yes	Yes	Yes
POST	RFC 7231	Yes	Yes	No	No	Yes
PUT	RFC 7231	Yes	Yes	No	Yes	No
DELETE	RFC 7231	No	Yes	No	Yes	No
CONNECT	RFC 7231	Yes	Yes	No	No	No
OPTIONS	RFC 7231	Optional	Yes	Yes	Yes	No
TRACE	RFC 7231	No	Yes	Yes	Yes	No
PATCH	RFC 5789	Yes	Yes	No	No	No

3.2 Status codes

自HTTP 1.0开始，响应以状态行开始，而状态行中进一步包含了一个状态码（status code）及对应的文字说明。状态码分为五类，为了便于管理和更加直观表示，第一个数字用于标示响应的类型。

• 1xx Informational responses

  标明请求已被接收并解析，常用于服务器需较长时间处理请求时告知客户端正在处理，且客户端需等待最终的回复。

  • 100 Continue
  • 101 Switching Protocols
  • 102 Processing
  • 103 Early Hints

• 2xx Success

  标明请求已被接收、解析且已生效。

  • 200 OK
  • 201 Created
  • 202 Accepted
  • 203 Non-Autoritative Information (Since HTTP/1.1)
  • 204 No Content
  • 205 Reset Content
  • 206 Partial Content
  • 207 Multi-Status
  • 208 Already Reported
  • 226 IM Used

• 3xx Redirection

  标明客户端需要采取额外措施来完成整个请求，通常用于URL重定向。

  • 300 Multiple Choices
  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 304 Not Modified
  • 305 Use Proxy
  • 306 Switch Proxy
  • 307 Temporary Redirect
  • 308 Permanent Redirect

• 4xx Client errors

  标明可能由客户端引发的错误，除HEAD方法外，其余情况中这类Response将会在Body中包含错误情况的详细说明，以及是临时或永久状况。

  • 400 Bad Request
  • 401 Unauthorized
  • 402 Payment Required
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 407 Proxy Authentication
  • 408 Request Timeout
  • 409 Conflict
  • 410 Gone
  • 411 Length Required
  • 412 Precondition Failed
  • 413 Payload Too Large
  • 414 URI Too Long
  • 415 Unsupported Media Type
  • 416 Range Not Satisfiable
  • 417 Expectation Failed
  • 418 I'm a teapot
  • 421 Misdirected Request
  • 422 Unprocessable Entity
  • 423 Locked
  • 424 Failed Dependency
  • 426 Upgrade Required
  • 428 Precondition Required
  • 429 Too Many Requests
  • 431 Request Header Fields Too Large
  • 451 Unavailable For Legal Reasons

• 5xx Server error

  标明可能由服务器本身引发的错误。

  • 500 Internal Server Error
  • 501 Not Implemented
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
  • 505 HTTP Version Not Supported
  • 506 Variant Also Negotiates
  • 507 Insufficient Storage
  • 508 Loop Detected
  • 510 Not Extended
  • 511 Network Authentication Required

4. 高级控制

4.1 Cache

所谓缓存（Cache），就是指相比服务器本身，在更靠近客户端的链路中设置一个额外的服务器副本。简单来看，缓存技术有两大优势：

• 通过分流，降低了服务器本身负载，提高整体并发
• 缩短链路带宽、长度，降低传输引发的延时

因此，缓存技术本质上是降低了单次请求的响应时长，从而提升网络体验。

The Conditional GET

然而大部分时候，副本带来了高可靠性，也带来了同步问题。实际服务器中内容可能随时间推移会发生修改，此时副本服务器中的数据就是相对过期了的，那么必要的同步就势在必行。

什么是必要的同步，就是只有比较数据后发现有更新才进行同步，否则只是无谓的拷贝，占用带宽。判断数据是否发生更新可以从数据本身出发，也可以只从数据标签即元数据出发，只要记录的数据最后更新时间一致，就可以判定数据不必更新，否则，就有更新的必要了。HTTP中这种机制叫做conditional GET，而更新的时间，就是通过Request中的If-modified-since字段给出。

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Web, 7 Sep 2011 09:23:24

4.2 Session and Cookie

前面提到，HTTP是无状态协议，就是说HTTP服务器不会在多个请求之间维护用户信息。但实际应用中，又往往存在这种刚性需求，典型的如购物、新闻浏览等。为了实现宾至如归的错觉，增加用户的黏度，HTTP采用了会话（Session）和Cookie技术。

会话，相当于一次对话。一次对话肯定包括至少一次交互，同样一次会话也至少包括一个请求响应对。因此会话就是由一系列的请求响应对组成。要想在一系列动作中保持某种状态，比较通用的方法就是在动作之外，维护一个变量或者文件，而Cookie的组成元素中，文件就是重要的一环。

Cookie

Cookie技术由四大组件组成：

• Response中Cookie header line用于返回服务器为用户所分配的Cookie ID
• Request中Cookie header line用于告知服务器请求来自于哪一个为用户的Cookie ID
• 用户客户端上本地存储维护的Cookie文件，记录用户行为
• 网站本身的后台数据库，保存了用户与Cookie ID间映射关系等数据

Cookie的具体使用过程如上图所示，总的来讲，就是通过独立第三发信息（Cookie ID、数据库、Cookie文件）来记录用户信息，并在会话中相关请求响应对中标记，保持服务器与客户端间的同步，实现状态维护。

5. 小结

本篇概述了HTTP的大部分内容，如有兴趣进一步学习研究，可参考相关Spec.