本文参考——图解HTTP—TRICORDER 株式会社 上野宣
HTTP
Web 使用一种名为 HTTP（HyperText Transfer Protocol，超文本传输协议）的协议作为规范，完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。 1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068，之后发布的修订版 RFC2616 就是当前的最新版本。
RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1
HTTP 请求方法
| 方法 | 说明 | 支持HTTP 协议版本 |
|---|---|---|
| GET | 获取资源 | 1.0、1.1 |
| POST | 传输实体主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获得报文首部 | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问支持的方法 | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK | 建立和资源之间的联系 | 1.0 (1.1废弃) |
| UNLINE | 断开连接关系 | 1.0 (1.1废弃) |
GET ：用来请求访问已被 URI 识别源经服务器端解析后返回响应内容。如果请求的资源是文本保持原样返回；如果是像 CGI（Common Gateway Interface，通用网关接口）的程序，返回经过执行后的输出结果或304 Not Modified；
POST: 用来传输实体的主体;虽然用 GET 方法也可以传输实体的主体，但一般用 POST 方法。 POST 的功能与 GET 很相似，但 POST 的主要目的是提交请求获取处理结果，返回更新资源；
PUT：用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，因此一般的 Web 网站不使用该方法。配合 Web 应用程序的验证机制，与架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法，返回204 No Content；
HEAD：和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。响应报文为首部信息；
DELETE：用来删除文件，是与 PUT 相反的方法。按请求 URI 删除指定的资源。HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的，返回 204 No Content；
OPTIONS：询问支持的方法 OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法，返回 200；
TRACE：追踪路径 TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。请求想要连接到源目标服务器可能会通过代理中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常使用较少，返回 Max-Forwards 最大转发；
CONNECT：隧道协议连接代理。请求代理服务器通信建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输，返回 200 进入网络隧道；
在不同业务场景使用对应的 HTTP 请求方法，提高后期维护的可识别性。
Web 通信
HTTP 首部
首部字段一览
| 首部字段名 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Connection | 逐跳首部、连接的管理 |
| Date | 创建报文的日期时间 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
HTTP 状态码
| 类别 | 原因短语 | |
|---|---|---|
| 1XX | Informational | 接受的请求正在处理 |
| 2XX | Success | 请求正常处理完毕 |
| 3XX | Redirection | 需要进行附件操作完成请求 |
| 4XX | Client Error | 服务器无法处理请求 |
| 5XX | Server Error | 服务器处理请求出错 |
通信数据转发程序
- 代理 具备转发功能的应用程序，扮演了位于服务器与客户端的中间角色，接受双方请求进行转发
- 网关 转发其他服务器通信数据的服务器，通常用户无感知
- 隧道 用于建立安全稳定链接保持双方通信的应用程序
URI 和 URL
URI：Uniform Resource Identifier——统一资源标识符
表示指定的 URI，要使用涵盖全部必要信息的绝对 URI、绝对 URL以 及相对 URL。相对 URL，是指从浏览器中基本 URI 处指定的 URL， 形如 /image/logo.gif。
URL：Uniform Resource Locator——统一资源定位符
URL正是使用 Web 浏览器等 访问 Web 页面时需要输入的网页地址。比如 www.google.com
持久连接与状态管理
初代 HTTP 在进行通信时每次请求都会进行建立连接，响应，断开连接三步操作；为避免频繁建立销毁在 HTTP/1.0 提出（持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。在建立长连接后在双方都没提出断开连接的前提下都保持 TCP 连接状态。
长连接
基于长连接提出的还有管线化（pipelining）通信，与初代相比可以不用接收响应后再发送下一个请求，适用于用于并发多个请求，在资源请求比较多的情况下时间效率提升更明显
管线
Cookie 状态管理
HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态，Cookie 需要通过请求服务器生成然后由客户端在每次请求时写入：
- 客户端主动请求服务器
- 服务器返回响应报文内有一个名为 Set-Cookie 的首部字段信息，通知客户端保存 Cookie
- 客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去
- 服务器端发现客户端发送过来的 Cookie 后，根据连接请求信息对比服务器记录，得到之前的状态信息
DNS
DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的 协议。它提供域名到 IP 地址之间的解析服务。DNS 协议提供通过域名 查找 IP 地址，或逆向从 IP 地址反查域名的服务。
各协议图示
TCP/IP
计算机与网络设备要相互通信，双方就必须基于相同的规则约束。而我们就把这种规则称为协议（protocol）。 TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。
Tcp/IP 分层
发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装（encapsulate）。
| 层级 | 应用层 | 传输层 | 网络层 | 链路层 |
|---|---|---|---|---|
| 首部信息 | HTTP 报文 | TCP 首部 | IP 首部 | 以太网首部 |
三次握手
为了准确无误地将数据送达目标处，TCP 协议采用了三次握手 （three-way handshaking）策略。用 TCP 协议把数据包送出去后，TCP 不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。
