1. 请求报文(Request)
客户端向服务器发起 HTTP 请求,请求的报文结构如下:
GET /index.htm HTTP/1.1
Host: www.baidu.com
一开始的 GET 是请求方法(Request Method),/index.htm 表明要访问的服务器上的文件,HTTP/1.1 表示 HTTP 的版本号,用来提示服务器客户端所使用的 HTTP 协议版本。
通过 Chrome 的开发者工具,我们看一个比较复杂的请求。这是百度登录账号的请求。
与刚才不一样的地方是,这一次使用的请求方法(Request Method)是 POST。GET 与 POST 之间的区别有哪些?
网上公认的一些区别有下面这些。(ps:有些区别其实在某种程度上来说算不上区别,看每个人的理解吧。)
- GET在浏览器回退时是无害的,而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark,而POST不可以。
- GET请求会被浏览器主动cache,而POST不会,除非手动设置。
- GET请求只能进行url编码,而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的,而POST么有。(URL 长度限制其实是与浏览器实现以及操作系统有关的,HTTP 规范中并没有对 URL 长度做限制。)
- 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。(这里的安全性比较,大家自行判断吧,有些人可能会认为这两者所谓的安全性并没有什么区别。)
- GET参数通过URL传递,POST放在Request body中。
其实在我看来,GET 与 POST 主要的区别还是在“语义”上。在 HTTP 规范中,GET 主要用于信息的获取,而不会对数据产生影响,不会去增加或修改数据。而 POST 则主要用于向服务器传输数据,增加或修改数据。这两者在语义上存在根本的区别。在 RESTFul (一种后端 Web Service 的接口风格)风格的 API 中,GET 就表示获取资源,POST 表示新增资源。
2. 响应报文(Response)
3. HTTP 方法
GET:通常用于获取资源。
POST:向服务器发送数据,主要目的不是用于获取响应内容。
PUT:传输文件(在 RESTful 架构中用于修改资源)。
DELETE:删除文件。
OPTIONS:询问支持的方法。
HEAD:获得响应的头部,不返回 body。
TRACE:追踪路径,让 Web 服务器端将之前的请求通信环回给客户端的方法。
CONNECT:要求用隧道协议连接代理(连接代理时使用)
4. 持久连接
当浏览一个包含图片及其他资源的 HTML 页面时,除了请求 HTML 页面,还会请求页面中的其他资源。而每次请求都会产生新的 TCP 连接建立和断开,这增加了通信量。HTTP/1.1 和 HTTP/1.0(没有完全标准化)通过持久连接(HTTP Persistent Connections,也称为 HTTP keep-alive 或 HTTP connection reuse)来解决这一问题。持久连接的特点是,只有在客户端或服务器其中一方明确提出断开连接的时候,才会断开 TCP 连接。
5. 管线化(pipelining)
持久连接为管线化提供了基础。管线化的意思是,不用等待上一个请求收到响应,就可以发送下一个请求,这样就可以做到同时并行发送多个请求。
6. Cookie
HTTP 协议是无状态的,也就是说不对之前发生过的请求和响应信息进行保存及管理,这样的优点是可以减少服务器的 CPU 和内存资源的消耗。
但是在有些时候,我们却需要在一定程度上保存客户端的状态,例如用户登录之后获取个人信息等,如果没有一种机制来保存登录状态,则需要每次发起 HTTP 请求时带上用户认证信息参数(例如用户名密码)。
为了解决这个问题,引入了 Cookie 技术,Cookie 通过在请求头及响应头中附上信息来保存状态。服务器可以在响应头中附上名为 Set-Cookie 的字段,来告知客户端保存 Cookie(也就是头部的这段信息)。客户端每次发起请求的时候,则会自动在请求头中附带上保存的 Cookie 信息,服务器端则可以根据客户端发来的 Cookie 信息来判断客户端状态(例如判断是否已经登录,以及登录的用户是谁)。单纯的 Cookie 模式只在客户端上保存信息,而不在服务器端保存信息。
7. Session
一种更常见的模式是在服务器上保存信息,也就是 Session 机制。当客户端向服务器发起请求时,服务器会在内存中为该客户端创建一块区域,用来存储当前客户端的一些信息,例如登录状态已经用户信息等。并将 Session 对应的 Session Id (类似于钥匙的概念,通过 session id 可以查找到对应的 session 信息)以 Cookie 的形式发送给客户端,客户端就会将 Cookie 保存至本地,每次请求带上 Cookie,服务器端就可以通过 Cookie 中的 Session Id 来获取客户端的状态。