记录 HTTP（超文本传输协议）

根据维基百科上的定义，超文本传输协议（HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。通过 HTTP 或者 HTTPS 协议请求的资源由统一资源标识符（URI）来标识。

协议概述

HTTP 是一个客户端和服务端之间请求和应答的标准，通常使用 TCP 协议。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个 HTTP 请求到服务器上指定端口（默认端口为 80 ）。通常称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如 HTML 文件和图像。通常称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

通常，由 HTTP 客户端发起一个请求，创建一个到服务器指定端口（默认是 80 端口）的 TCP 连接。HTTP 服务器则在哪个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如 "HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误信息、或者其它信息。

请求方法

HTTP/1.1 协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

• GET

  向指定的资源发出“显示”请求。使用 GET 方法应该只用在读取资源，而不应当被用于产生“副作用”的操作中，例如在网络应用程序中。其中一个原因是 GET 可能会被网络爬虫等随意访问。参见安全方法。浏览器直接发出的 GET 只能由一个 url 触发。GET 上要在 url 之外带一些参数就只能依靠 url 附带 querystring。

• HEAD

  与 GET 方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的文本部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

• POST

  向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源。或二者皆有。每次提交，表单的数据被浏览器用编码到 HTTP 请求的 body 里。浏览器发出的 POST 请求的 body 主要有两种格式，一种是 application/x-www-form-urlencoded 用来传输简单的数据，大概就是 "key1=value1&key2=value2" 这样的格式。另外一种是传文件，会采用 multipart/form-data 格式。采用后者是因为 application/x-www-form-urlencoded 的编码方式对于文件这种二进制的数据非常低效。

• PUT 向指定资源位置上传其最新内容

• DELETE

  请求服务器删除 Request-URI 所标识的资源。

• TRAGE

  回显服务器收到的请求，主要用于测试或者诊断。

• OPTIONS

  这个方法可使服务器传回该资源所支持的所有 HTTP 请求方法。 用 * 来代替资源名称，向 Web 服务器发送 OPTIONS 请求，可以测试服务器功能是否正常运作。

• CONNECT

  HTTP/1.1 协议中预留给能够将连接改为隧道方式的代理服务器。通常用于 SSL 加密服务器的链接（经由非加密的 HTTP 代理服务器）。

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候。应当返回状态码501（Not Implemented）。

HTTP 服务器至少应该实现 GET 和 HEAD 方法，其他方法都是可选的。当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的 HTTP 服务器还能够扩展自定义的方法，例如：PATCH （用于将局部修改应用到资源）。

安全方法

对于 GET 和 HEAD 方法而言，除了进行获取资源信息外，这些请求不应当再有其它意义。也就是说，这些方法应当被认为是“安全的”。客户端可能会使用其它“非安全”方法，例如 POST，PUT 及 DELETE，应该以特殊的方式（通常是按钮而不是超链接）告知客户可能的后果（例如一个按钮控制的资金交易），或请求的操作可能是不安全的（例如某个文件将被上传或删除）。

但是，不能想当然地认为服务器在处理某个 GET 请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。

副作用

例如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作幂等的。GET、HEAD、PUT 和 DELETE 方法都有这样的幂等属性，同样由于根据协议，OPTIONS、TRACE 都不应有副作用，因此也理所当然也是幂等的。

例如一个由若干请求组成的请求序列产生的结果，在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化，则这个请求序列便是幂等的。但是，可能出现一个由若干请求组成的请求序列是非幂等的，即使这个请求序列中所有执行的请求方法都是幂等的。例如，这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。

版本

超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。

• HTTP/0.9

  已过时。只接受 GET 一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持 POST 方法，因此客户端无法向服务器传递太多信息。

• HTTP/1.0

  这是第一个在通讯中指定版本号的 HTTP 协议版本。

• HTTP/1.1

  默认采用持续连接（Connection：keep-alive），能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。

HTTP/1.1 相较于 HTTP/1.0 协议的区别主要体现在：

存处理
宽优化及网络连接的使用
误通知的管理
息在网络中的发送
联网地址的维护
全性及完整性

• HTTP/2

  2015 年 5 月作为互联网标准正式发布。

状态码

所有 HTTP 响应的第一都是状态行，依次是当前的 HTTP 状态号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

• 1xx消息 —— 请求已被服务器接收，继续处理
• 2xx成功 —— 请求已成功被服务器接收、理解、并接受
• 3xx重定向 —— 需要后续操作才能完成这一请求
• 4xx请求错误 —— 请求含有词法错误或者无法被执行
• 5xx服务器错误 —— 服务器在处理某个正确请求时发生错误 虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK","404 Not Found", 但是 Web 开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。