前端面试（4）-- HTTP 协议类

知识点：

1. HTTP 协议的主要特点
2. HTTP 报文的组成部分
3. HTTP 方法
4. POST 和 GET 的区别
5. HTTP 状态码
6. 什么是持久连接
7. 什么是管线化

1. HTTP 协议的主要特点

• 简单快速：每个资源URI(统一资源符)是固定的，比如图片、页面地址，所以HTTP协议中处理比较简单，访问某个资源输入URI即可；
• 灵活：每个http协议中有一个头部分，有个数据类型，通过一个http协议的就可以完成不同数据类型的传输；
• 无连接 (重点)：连接一次就会断开，不会保持连接；
• 无状态 (重点)：客户端和服务端两种身份，客户端向服务端请求一个图片，http帮你建立连接、传输结束后，连接断开，下次客户端在请求数据，服务端是无法区分上次连接和这次连接是否是同一身份，因为服务端没有记住你的状态，单从http协议上是无法区分两次连接者的身份；（状态区分是通过服务端加一下session做到的）

2. HTTP 报文的组成部分

• 请求报文
• 响应报文

请求报文：

1. 请求行：http方法、页面地址、协议、版本；
2. 请求头：key、value告诉服务端需要内容，注意什么类型；
3. 空行：告诉服务端请求头已经结束；
4. 请求体

响应报文：

1. 状态行：协议、版本、状态码；
2. 响应头
3. 空行
4. 响应体：文档部分；

3. HTTP 方法

• GET----获取资源
• POST----传输资源
• PUT----更新资源
• DELETE----删除资源
• HEAD----获得报文首部

4. POST 和 GET 的区别

• GET 在浏览器回退是无害的，而 POST 会再次提交请求；
• GET 产生的 URL 地址可以被收藏，而 POST 不可以；
• GET 请求会被浏览器主动缓存，而 POST 不会，除非手动设置；
• GET 请求参数会被完整保留在浏览器的历史记录里，而 POST 中的参数不会被保留；
• GET 请求只能进行 url 编码，而 POST 支持多种编码方式；
• 对参数的数据类型，GET 只接受 ASCLL 字符，而 POST 没有限制；
• GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信息；
• GET 参数通过 URL 传递，POST 放在 Request body 中；

5. HTTP 状态码

• 1xx：指示信息 ——表示请求已接收，继续处理

• 2xx：成功——表示请求已被成功接收

• 3xx：重定向——要完成请求必须进行更进一步的操作

• 4xx：客户端错误——请求有语法错误或请求无法实现

• 5xx：服务端错误——服务器未能实现合法的请求

   > 200：客户端请求成功
   > 206：客户发送了一个带Range头的GET请求，服务器完成了它
   
   > 301：所请求的页面已经转移到新的url
   > 302：所请求的页面已经临时转移至新的url
   > 304：客户端有缓冲的文档并发出了一个条件性的请求，服务器告诉客户，原来缓冲的文档还可以继续使用
   
   > 400：客户端请求有语法错误，不能被服务端所理解
   > 401：请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
   > 403：对被请求页面的访问被禁止
   > 404：请求资源不存在
   
   > 500：服务器发送不可预期的错误原来缓冲文档还可以继续使用
   > 503：请求未完成，服务器临时过载或当机，一段时间后可能恢复正常
  

6. 持久连接

HTTP协议采用"请求-应答"模式,当使用普通模式，即非Keep-Alive模式时，每个请求/应答客户和服务器都要建立一个连接，完成之后立即断开连接(HTTP协议为无连接的协议)

当使用Keep-Alive模式(持久连接、连接重用)时，Keep-Alive功能使客户端到服务器端连接持续有效，当出现对服务器的后续请求时，Keep-Alive功能避免了建立或者重新建立连接

7. 管线化

在使用持久连接的情况下，某个连接上消息的传递类似于，请求一次响应一次并且不断开
请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3

管线化通道是持久建立的，把所有请求打包一次传输，所有响应打包一次传输
请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3

特点：

1. 管线化机制通过持久连接完成，仅HTTP/1.1支持此技术；
2. 只有GET和HEAD请求可以进行管线化，而POST则有所限制；
3. 初次创建连接是不应启动管线机制，因为对方(服务器)不一定支持HTTP/1.1版本的协议；
4. 管线化不会影响响应到来的顺序，如上面的例子所示，响应返还的顺序并未改变；
5. HTTP/1.1要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可；
6. 由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如Chrome和Firefox默认并未开启管线化支持；