一、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 首部
通用首部
| 首部名 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Connection | 逐跳首部、连接的管理 |
| Date | 创建报文的日期时间 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
请求首部
| 首部名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言（自然语言） |
| Authorization | Web 认证信息 |
| Expect | 期待服务器的特定行为 |
| From | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| If-Match | 比较实体标记（ETag） |
| If-Modified-Since | 比较资源的更新时间 |
| If-None-Match | 比较实体标记（与 If-Match 相反） |
| If-Range | 资源未更新时发送实体 Byte 的范围请求 |
| If-Unmodified-Since | 比较资源的更新时间（与 If-Modified-Since 相反） |
| Max-Forwards | 最大传输逐跳数 |
| Proxy-Authorization | 代理服务器要求客户端的认证信息 |
| Range | 实体的字节范围请求 |
| Referer | 对请求中 URL 的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | HTTP 客户端程序的信息 |
响应首部
| 首部名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推送资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向至指定 URL |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP 服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
实体首部
| 首部名 | 说明 |
|---|---|
| Allow | 资源可支持的 HTTP 方法 |
| Content-Encoding | 主体适用的编码方式 |
| Content-Language | 主体的自然语言 |
| Content-Length | 主体的大小（单位：字节） |
| Content-Location | 替代对应资源的 URL |
| Content-MD5 | 主体的报文摘要 |
| Content-Range | 主体的位置范围 |
| Content-Type | 主体的媒体类型 |
| Expires | 主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
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 页面，与挨个连接相比，用持久连接可以让请求更快结束，而管线化技术则比持久连接还要快，请求数越多，时间差就越明显
