一、URL-俗称“网址”
HTTP 使用 URL(Uniform Resource Locator，统一资源定位符)来定位资源，它是 URI(Uniform Resource Identifier，统一资源标识符)的子集，URL 在 URI 的基础上增加了定位能力
URI 除了包含 URL，还包含 URN(Uniform Resource Name，统一资源名称)，它只是用来定义一个资源的名称，并不具备定位该资源的能力
urlencode、urldecode
像 : / ? 等这样的字符, 已经被 url 当做特殊含义理解了，因此这些字符不能随意出现，否则需要对其进行转义
例如，‘+’ 经过 urlencode 被转义成了 “%2B”
而 urldecode 就是 urlencode 的逆过程
二、HTTP 报文
1、请求报文
- 第一行是请求行，包含用于请求的方法、URL 和 HTTP 版本
- 接下来的多行都是首部(Header)，包含请求首部、通用首部、实体首部以及 HTTP 的 RFC 中未定义的其他首部(Cookie 等)
- 一个空行用来分隔首部和主体(Body)，Body 允许为空字符串. 如果 Body 存在, 则 Header 中会有一个 Content-Length 属性用于标识 Body 长度
2、响应报文
- 第一行是状态行，包含HTTP 版本、表明响应结果的状态码和状态码描述
- 接下来的多行都是首部(Header)，包含响应首部、通用首部、实体首部以及 HTTP 的 RFC 中未定义的其他首部(Cookie 等)
- 一个空行用来分隔首部和主体(Body)，Body 允许为空字符串. 如果 Body 存在, 则 Header 中会有一个 Content-Length 属性用于标识 Body 长度
此时可能会有疑问，示例 Header 中也没有 Content-Length 属性啊，但请注意，服务器返回了一个 html 页面，而且 Header 中的 Transfer-Encoding 属性值是 chunked
三、HTTP 请求方法
| 方法 | 说明 | 支持的 HTTP 版本 | 注意 |
|---|---|---|---|
| GET | 获取资源 | 1.0、1.1 | 常用方法 |
| POST | 传输实体主体 | 1.0、1.1 | 常用方法 |
| PUT | 传输文件 | 1.0、1.1 | 鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件，存在安全问题，因此一般的 Web 网站不使用 |
| HEAD | 获取报文首部 | 1.0、1.1 | |
| DELETE | 删除文件 | 1.0、1.1 | 鉴于 HTTP/1.1 的 DELETE 方法自身也不带验证机制，所以一般的 Web 网站也不使用 |
| OPTIONS | 访问支持的方法 | 1.1 | |
| TRACE | 追踪路径 | 1.1 | TRACE 方法不怎么常用，而且还容易受到 XST(Cross-Site Tracing，跨站追踪) 攻击 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 | 使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输 |
| LINK | 建议和资源之间的联系 | 1.0 | |
| UNLIKE | 断开连接关系 | 1.0 |
四、HTTP 状态码
| 类别 | 原因短语 | |
|---|---|---|
| 1xx | Informational(信息性状态码) | 接收的请求正在处理 |
| 2xx | Success(成功状态码) | 请求正常处理完毕 |
| 3xx | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
| 4xx | Client Error(客户端错误状态码) | 服务器无法处理请求 |
| 5xx | Server Error(服务器错误状态码) | 服务器处理请求出错 |
常见的状态码, 比如 200(OK)、404(Not Found)、403(Forbidden)、302(Redirect, 重定向)、504(Bad Gateway)
五、HTTP 首部
1、首部
常见的首部见下：
- Content-Type：数据类型(text/html 等)
- Content-Length：Body 长度
- Host：客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上
- User-Agent：声明用户的操作系统和浏览器版本信息
- referer：当前页面是从哪个页面跳转过来的
- location：搭配 3xx 状态码使用, 告诉客户端接下来要去哪里访问
- Cookie：用于在客户端存储少量信息. 通常用于实现会话(session)功能
1.1、HTTP/1.1 首部
1.1.1、通用首部
1.1.2、请求首部
1.1.3、响应首部
1.1.4、实体首部
1.2、非 HTTP/1.1 的其他首部
在 HTTP/1.1 协议通信交互中使用到的首部，不限于 RFC2616 中定义的上述 47 种，还有一些非正式的首部，如 Cookie、Set-Cookie 和 Content-Dispostion 等都定义在 RFC4229 HTTP Header Field Registrations，它们的使用频率也很高
2、长短连接
HTTP 协议的初始版本中，每进行一次 HTTP 通信就要断开一次 TCP 连接
以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题，可随着 HTTP 的普及，文档中包含大量图片的情况多了起来，比如，使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该页面里包含的其他资源，因此，每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销
为了解决上述 TCP 连接的问题，想出了持久连接(HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse)的方法，持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态
持久连接的好处在于减少了 TCL 连接的重复创建和断开所造成的额外开销，减轻了服务器端的负载，另外，减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高了
HTTP/1.1，默认长连接，如果想断开连接，需要由客户端或服务器端任意一端使用 Connection: close 明确提出断开连接
HTTP/1.1 以前，默认短连接，如果想用长连接，需要指定 Connection: Keep-Alive
3、管线化
持久连接使得多数请求以管线化(pipelining)方式发送成为可能，从前发送请求后需等待并收到响应，才能发送下一个请求，管线化技术出现后，不用等待响应亦可直接发送下一个请求，这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了
比如，当请求一个包含 10 张图片的 HTML Web 页面，与挨个连接相比，用持久连接可以让请求更快结束，而管线化技术则比持久连接还要快，请求数越多，时间差就越明显
