HTTP协议类
HTTP协议的主要特点
-
无连接
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 -
无状态
HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。同一个客户端的这次请求和上次请求是没有对应关系，对http服务器来说，它并不知道这两个请求来自同一个客户端。为了解决这个问题， Web程序引入了Cookie机制来维护状态 -
简单快速
客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 -
灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
HTTP报文组成部分
- 请求报文(包含4个部分)
- 请求行
请求行包含
1.请求方法； 2.页面地址; 3.HTTP协议及版本
- 请求头
就是一些key:value值，来告诉服务端我要哪些内容，要注意什么类型
- 空行
请求头部后面的空行是必须的,即使第四部分的请求数据为空，
也必须有空行。服务端通过空行可以区分请求头和请求体
- 请求体
- 响应报文
- 状态行
状态行包含3部分
1. HTTP协议版本号； 2.状态码； 3. 状态消息
- 响应头
用来说明客户端要使用的一些附加信息
- 空行
响应头后面的空行是必须的
- 响应体
服务器返回给客户端的文本信息。
HTTP方法
- GET 方法 获取资源
- POST方法 传输资源
- PUT方法 更新资源
- DELETE方法 删除资源
- HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
GET和POST 方法的区别
1. GET在浏览器回退时是无害的，而POST会再次提交请求
- GET产生的URL地址可以被收藏，而POST不可以
3. GET 请求会被浏览器主动缓存，而POST不会，除非手动设置
- GET请求只能进行URL编码，而POST支持多种编码方式
5. GET请求参数会被完整的保留在浏览器历史记录里，而POST的参数不会被保留
6. GET请求在URL中传送的参数是有长度限制的，而POST没有限制
- 对参数的数据类型，GET请求只接受ASCII字符，而POST没有限制
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息
9. GET参数通过URL传递，而POST放在Request body中
HTTP状态码
1xx 指示信息：表示请求已接收，继续处理
2xx 成功：表示请求已被成功接收
常见的
200 OK
客户端请求成功
206 Partial Content
客户端发送了一个带有Range头的GET请求
服务器完成了它（大概意思就是请求完整内容里的一部分，range范围）
常见的,用video标签去播放一个视频地址或用audio标签去播放一个音频地址，
当视频或音频文件很大是时候，基本上都是返回一个206
3xx 重定向：要完成请求必须进行更进一步的操作
301
Move Permanently 所请求的页面已经转移至新的URL
302 Found
所请求的页面已经临时转移至新的URL
304 Not Modified
客户端有缓冲的文档，并发出了一个条件性的请求，
服务器告诉客户端，原来缓冲的文档还可以继续使用
4xx 客户端错误：请求有语法错误或请求无法实现
400 Bad Request
客户端请求有语法错误，不能被服务器理解
401 Unauthorized
请求未经授权，这个状态代码必须和WWW.Authenticate报头域一起使用
403 Forbidden 对被请求页面的访问被禁止
404 Not Found 请求资源不存在
5xx 服务器错误：服务器未能实现合法的请求
500 Internal Server Error 服务器发生不可预期的错误，原来缓冲的文档还可以继续使用
503 Server Unavailable 请求未完成，服务器临时过载或宕机，一段时间后可恢复正常
持久链接
- HTTP协议采用的是“请求-应答模式”，当使用普通模式 即非
Keep-Alive模式时，每个请求/应答,客户端和服务器都要新建一个连接，完成之后立即断开（HTTP协议为无连接的协议） - 当使用
Keep-Alive模式时(又称持久连接，连接重用)时，Keep-Alive功能使客户端到服务端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或重新建立连接(HTTP 1.1版本支持，1.0版本不支持)
管线化
在使用持久连接的情况下，某个连接上消息的传递类似于
请求1—>响应1—>请求2—>响应2—>请求3—>响应3(这里的箭头表示整个连接一直没有断开)
上边是正常的持久连接的情况，那么管线化是指，这个连接通道是持久建立的，但是不是我请求一次，服务端响应一次，而是我把我现在的请求打包一次性给服务端传输过去，而服务端也把响应打包一次性响应给我
请求1—>请求2—>请求3—>响应1—>响应2—>响应3
管线化的特点
1. 管线化机制通过持久连接完成，仅HTTP/1.1支持此技术
2. 只有GET和HEAD请求可以进行管线化，而POST则有所限制
3. 初次创建连接时不应启动管线机制，因为对方(服务器)不一定支持HTTP/1.1版本的协议
- 管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变
- HTTP/1.1 要求服务端支持管线化，但并不要求服务端也对响应进行管线化处理，只是要求对管线化的请求不失败即可。
- 由于上面提到的服务器端问题，开启管线化可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因为现代浏览器如Chrome和Firefox默认并未开启管线化支持
