HTTP协议类

一、HTTP协议主要特点

• 简单快速：通过统一资源定位符URI。
• 灵活：一个http请求可以传输很多类型的资源。
• 无连接：连接完后会断开。
• 无状态：服务端没法判断两次连接是不是同一个身份。

二、HTTP报文组成部分

参考

分为请求报文和响应报文

请求报文包含：请求行、请求头、空行、请求体。

响应报文包含：状态行、响应头、空行，响应体。

请求报文示例：

POST /user HTTP/1.1      //请求行
Host: www.user.com
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
User-agent: Mozilla/5.0.      //以上是首部行
（此处必须有一空行）  //空行分割header和请求内容 
name=world   请求体

响应报文示例：

 HTTP/1.1 200 OK  // 状态行
Accept-Ranges: bytes
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: Keep-Alive
Content-Length: 2381
Content-Type: text/html
Date: Tue, 29 Oct 2019 15:08:16 GMT
Etag: "588604c8-94d"
Last-Modified: Mon, 23 Jan 2017 13:27:36 GMT  // 以上是响应头

三、HTTP方法

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

OPTIONS 用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。

四、HTTP状态码

1XX:指示信息一表示请求已接收，继续处理

2XX:成功一表示请求已被成功接收

3Xx:重定向一要完成请求必须进行更进一步的操作

4xx:客户端错误一请求有语法错误或请求无法实现

5xx:服务器错误-服务器未能实现合法的请求

几个比较重要的状态码：

2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
• 206 Partial Content，进行范围请求

3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
• 307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX 客户端错误

• 400 bad request，请求报文存在语法错误
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误
• 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

五、HTTP持久连接

在HTTP1.0中，默认的是短连接，在HTTP1.1中所有连接都是Keep-alive的，也就是默认都是持久连接的（Persistent Connection）。

HTTP/1.0 keep-alive连接

现在很多客户端和服务器仍然在使用这些早期的keep-live连接。

在HTTP/1.0中，keep-alive并不是默认开启的。客户端必须发送一个Connection：Keep-Alive请求首部来激活keep-alive连接。如果服务器愿意为下一条请求连接保持在打开状态，就在响应头中包含相同的首部，如果响应中没有Connection:Keep-Alive首部，客户端就认为服务器不支持keep-live，会在返回响应报文后关闭连接。

只有在无需检测到连接的关闭就可以确定报文实体主体部分长度的情况下，才能将连接保持在打开状态--也就是说实体的主体部分必需有正确的Content-Length。

HTTP/1.1 Persistent Connection

HTTP/1.1逐渐停止了对keep-alive连接的支持，用一种名为持久连接的改进型设计取代了它。持久连接的目的与keep-alive连接的目的相同，但是工作机制更优些。HTTP/1.1持久连接在默认情况下是激活的，除非特别指明，否则HTTP/1.1假定所有的连接都是持久的，要在事务处理结束之后将连接关闭，HTTP/1.1应用程序必须向报文中显示地添加一个Connection：close首部。

HTTP/1.1客户端在收到响应后，除非响应中包含了Connection：close首部，不然HTTP/1.1连接就仍然维持在打开状态。但是，客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection：close并不意味这服务器承诺永远将连接保持在打开状态。

六、HTTP管线化

在使用持久连接的情况下，某个连接上消息的传递类似于，请求1->响应1->请求2→>响应2→请求3->响应3。 如果用管线化，则会把请求和响应打包，然后发送。请求1->请求2->请求3->响应1->响应2->响应3。

管线化的特点：

• 管线化机制通过持久连接完成，仅HTTP/1.1支持此技术。
• 只有GET和HEAD请求可以进行管线化，而POST则有所限制。
• 初次创建连接时不应启动管线机制，因为对方(服务器)不一定支持HTTP/1.1版本的协议。

管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变。

HTTP/1.1要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可。

由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如Chrome和Frefx默认并未开启管线化支持。

七、get和post的区别

记忆：回退、缓存、记录、长度、传递。

GET在浏览器回退时是无害的，而POST会再次提交请求。

GET产生的URL地址可以被收藏，而POST不可以。

GET请求会被浏览器主动缓存，而POST不会，除非手动设置。

GET请求只能进行ur编码，而POST支持多种编码方式。

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET请求在URL中传送的参数是有长度限制的，而POST没有限制。

对参数的数据类型，GET只接受ASC字符，而POST没有限制GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

GET参数通过URL传递，POST放在 Request body中。

GET请求具有幂等性(多次请求不会对资源造成影响)，POST请求不幂等。