通过《远程通信协议》这一章的描述我们已经知道一次 HTTP 请求会经过哪些步骤。今天主要会给大家讲解一下 HTTP 协议原理,彻底了解一下应用层协议。
HTTP 协议的组成
HTTP 协议是基于应用层的协议,并且在传输层使用的 TCP 的可靠性通信协议。既然是协议,那么就应该符合协议的定义:协议是两个需要通过网络通信的程序达成的一种约定,它规定了报文的交换方式和包含的意义,所以,接下来我们来深入去剖析 HTTP 协议的原理和组成。
URL
我们在浏览器中输入一个地址,浏览器是如何根据地址去找到服务器对应的资源并做返回的?以及这个地址包含了哪些有价值的信息呢?
这就需要我们了解 URL(Uniform Resource Locator),统一资源定位符 ,用于描述一个网络上的资源,具体格式是:
schema://host[:port]/path/.../?[query]#[frag]
组件 | 描述 |
schema | 指定应用层使用的协议(例如:http, https, ftp) |
host | HTTP 服务器的 IP 地址或者域名 |
port | HTTP 服务器的默认端口是 80,这种情况下端口号可以省略。如果使用了别的端口,必须指明,例如 http://www.cnblogs.com:8080/ |
path | 访问资源的路径 |
query | 查询字符串 |
frag | 片段标识符,使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置) |
通过这个 URL 地址,我们就可以读到,当前用户要使用 HTTP 协议访问指定服务器上对应进程中的资源,并且携带了请求参数。
MIME Type
服务器根据用户请求的资源找到对应的文件以后,会返回一个资源给到客户端浏览器,浏览器会对这个资源解析并且渲染。但是服务器上的资源类型有很多,比如图片类型、视频类型、Js、Css、文本等。浏览器如何识别当前类型做不同的渲染呢?
MIME Type:是描述消息内容类型的因特网标准,常见的几种类型。
- 文本文件:text/html、text/plain、text/css、application/xhtml+xml、application/xml
- 图片文件:image/jpeg、image/gif、image/png
- 视频文件:video/mpeg、video/quicktime
我们可以通过两种方式来设置文件的渲染类型,第一种是 Accept,第二种是 Content-Type。
- Accept:表示客户端希望接受的数据类型,即告诉服务器我需要什么媒体类型的数据,此时服务器应该根据 Accept 请求头生产指定媒体类型的数据。
- Content-Type:表示发送端发送的实体数据类型,比如我们应该写过类似的:resposne.setContentType("application/json;charset=utf-8") 的代码,表示服务端返回的数据格式是 JSON。
如果 Accept 和 Content-Type 不一致,假如说 Accept 要接收的类型是 image/gif,但是服务端返回的数据是 text/html,那么浏览器将会无法解析。
状态码
如果用户访问的地址没问题,或者服务器也能正常解析及处理当前用户的请求,那就能够返回正确的信息给到客户端。但是如果用户访问的地址有问题,或者服务端在解析用户请求以及处理请求逻辑时出现问题,怎么办呢?浏览器应该怎么告诉用户当前是处理失败的呢?
因此这里就涉及到一个状态码的概念,状态码的职责是当客户端向服务端发送请求时,描述服务端返回的请求处理结果,通过状态码,浏览器可以知道服务器是正常处理请求还是出现了错误。
状态码系列 | 类别 | 描述 |
1XX | Informational(信息性状态码) | 接收的请求正在处理 |
2XX | Success(成功状态码) | 请求正常处理完毕 |
3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
关于详细的状态码信息参考《HTTP 状态码》这篇文章。
HTTP Methods
有了 URL,MIME Type、状态码,能够基本满足用户的需求,但是,很多时候一个网站不单纯只是不断从服务端获取资源并做渲染,可能还需要做一些数据的提交、删除等功能。所以浏览器定义了 8 种方法来表示对于不同请求的操作方式,当然最常用的还是 GET 和 POST。
- GET:一般是用于客户端发送一个 URI 地址去获取服务端的资源(一般用于查询操作),GET 请求的传输数据大小有限制,具体限制由浏览器决定。
- POST:一般用户客户端传输一个实体给到服务端,让服务端去保存(一般用于创建操作)。
- PUT:向服务器发送数据,一般用于更新数据的操作
- DELETE:客户端发起一个 DELETE 请求要求服务端把某个数据删除(一般用于删除操作)。
- HEAD:获得报文首部。
- OPTIONS:询问支持的方法。
- TRACE:追踪路径。
- CONNECT:用隧道协议连接代理。
在 REST 架构风格中,有严格规定对于不同的请求类型要设置合适的请求方法。也是避免出现因为乱用导致混乱的问题。这里提到了 REST 架构,现在很多同学都在写 REST,有没有人能够明白为什么要定义 REST 这个架构风格?
我个人认为是这样:
- 随着服务化架构的普及,HTTP 协议的使用频率越来越高。
- 很多人在错误的使用 HTTP 协议定义接口,比如各种各样的命名,什么 getUserInfoById,deleteById 之类的有状态和无状态请求混用。
- 对于 HTTP 协议本身提供的规则并没有很好的利用。
所以,为了更好的解决这些问题,干脆就定义一套规则,这套规则并没有引入新的东西,无非就是对 HTTP 协议本身的使用做了一些约束,比如说:
- REST 是面向资源,每一个 URI 代表一个资源。
- 强调无状态化,服务器端不能存储来自某个客户的某个请求中的信息,并在该客户的其他请求中使用。
- 强调 URL 暴露资源时,不要在 URI 中出现动词。
- 合理的利用 HTTP 状态码、请求方法。
因此大家在参照这种标准去使用 REST 风格时,要明白你遵循的是什么以及要解决什么问题。
报文
请求报文
请求报文格式包含三个部分:起始行、首部字段、主体。
响应报文
响应的报文格式也是一样,分为三部分。