HTTP工作原理
以下是 HTTP 请求/响应的步骤：
- 客户端连接到Web服务器。
浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址，一个HTTP客户端，通常是浏览器，与 Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。
-
发送HTTP请求。
通过【TCP套接字】，客户端向Web服务器发送一个文本的请求报文，一个请求报文由【请求行、请求头部、空行和请求数据】4部分组成。
-
服务器接受请求并返回HTTP响应
Web服务器【解析请求，定位请求资源】，然后将资源的复本写到TCP套接字，由客户端读取。一个响应由【状态行、响应头部、空行和响应数据】4部分组成。
-
服务器释放连接TCP连接。
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接。
若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求。无论如何都会释放。
-
客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
从以上的内容我们大致可以总结出以下几点：
1、Http是基于请求和响应的。
2、需要依托TCP协议进行三次握手连接、传输数据。
3、TCP的连接会被主动断开，并不是一直保持连接。
4、HTTP报文格式
一个完整的HTTP协议的报文主要由以下三个部分组成：
- 起始行（请求行、响应行）：起始行 start line : 描述请求或响应的基本信息。
- 首部字段（请求头、响应头）：使用key-value的形式更加详细的说明报文。
- 消息正文（请求体、响应体）：实际的传输数据，不一定是文本，也有可能是图片、音频、视频等二进制数据。
http首部字段
http首部字段是构成http报文的重要元素，它能起到传递额外重要信息的作用，首部信息一般会提供报文类型、编码和大小、认证信息，缓存策略等信息。
**不用记、不用记。**如果需要记忆和深入目前只有一个Content-Type
HTTP/1.1 规范定义了如下 47 种首部字段，分为四大类，我们大致预览一下，不能一一讲解，详情可以通过看书深入理解
1、通用首部字段 9个
| 首部字段名 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Connection | 连接的管理 |
| Date | 创建报文的日期时间 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
2、请求首部字段 共18个
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言（自然语言） |
| AuthorizationWeb | 认证信息 |
| 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 | 对请求中 URI 的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | 客户端程序的信息 |
3、响应首部字段 共9个
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向至指定URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
4、实体首部字段 共10个
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小（单位：字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
####（4）http内容协商
同一个web网页可能存在多个相同内容的网页，比如英文版和中文版，它们内容相同，语言却不同。当浏览器默认的语言不同，访问相同uri会出现不同结果，这种机制就是内容协商。
内容协商机制是指客户端和服务器就响应的资源内容进行协商交涉，然后提供给客户端最合适的资源。内容协商会以响应资源的语言、字符集、编码等方式作为判断的标准。
共有3种不同的方法可以决定服务器上哪个页面最适合客户端：让客户端来选择、服务器自动判定、让中间代理来选。这3种技术分别称为客户端驱动的协商、服务器驱动的协商以及透明协商。
客户端驱动
客户端发起请求，服务器发送可选项列表，客户端作出选择后再发送第二次请求。
- 优点：比较容易实现。
- 缺点：增加了时延，至少要发送两次请求，第一次请求获取资源列表，第二次获取选择的副本。
服务器驱动
服务器检查客户端的请求首部集并决定提供哪个版本的页面。
- 优点：比客户端驱动的协商要快。
- 缺点：首部集不匹配，服务器要做猜测。
透明协商
某个中间设备（通常是缓存代理）代表客户端进行协商。
- 优点：免除了web服务器的协商开销，比客户端驱动的协商要快。
- 缺点：HTTP并没有提供相应的规范。
其中，服务器驱动的解决方案应用较为广泛。
通用的内容协商首部集
客户端可以用下面列出的HTTP首部集发送用户的偏好信息：
- Accept：告知服务器发送何种媒体类型；
- Accept-Language：告知服务器发送何种语言；
- Accept-Charset：告知服务器发送何种字符集；
- Accept-Encoding：告知服务器采用何种编码。
【媒体类型】
因特网上有数千种不同类型的数据，HTTP仔细地给每种要通过web传输的对象都打上了名为MIME类型（MIME type）的数据格式标签。最初设计MIME（Multipurpose Internet Mali Extension，多用途英特网邮件扩藏）是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。MIME 在电子邮件系统中工作得非常好，因此 HTTP 也采纳了它，用它来描述并标记多媒体内容。
MIME 类型是一种文本标记，表示一种【主要的对象类型】和一个特定的【子类型】，中间由一条斜杠来分隔。
- HTML 格式的文本文档由【text/html】 类型来标记
- 普通的 ASCII 文本文档由 【text/plain】 类型来标
- JPEG 版本的图片为 【image/jpeg】 类型
- GIF 格式的图片为【image/gif】 类型
- Apple 的 QuickTime 电影为【video/quicktime 】类型
- 微软的 PowerPoint 演示文件为【application/vnd.ms-powerpoint】类型
当然还有很多很多.....
而我们以后见的最多的要数以下两种，这两种类型都是用来传递数据：
- application/json，学习了前端知识后，想必大家对json已经不再陌生了。
- application/x-www-form-urlencoded，我们之前都学习过表单，urlencoded格式，又叫 form 格式，它是一种表单格式。它使用键值对的方式进行表示，键和值之间用=，多个键值对之间用&
比如我们想在客户端和服务之间传递信息：
可以是这样的
name=polo&age=35&smoke=false
也可以是
{
"name" :"polo",
"age":35,
"smoke":false
}
更多的mimeType可以查看：www.w3school.com.cn/media/media…
【注意】这些首部与实体首部非常类似。不过，这两种首部的用途截然不同。
实体首部集像运输标签，它们描述了把报文从服务器传输给客户端的过程中必须的各种报文主体属性。
而内容协商首部集是由客户端发送给服务器用于交换偏好信息的，以便服务器可以从文档的不同版本中选择出最符合客户端偏好的那个来提供服务。
服务器用下面列出的实体首部集来匹配客户端的Accept首部集：
| Accept首部 | 实体首部 |
|---|---|
| Accept | Content-Type |
| Accept-Language | Content-Language |
| Accept-Charset | Content-Type |
| Accept-Encoding | Content-Encoding |
