1. HTTP协议

1.1. 什么是 HTTP 协议?

日常我们使用网络用得最多的无疑是在 Web 浏览器(下文统一使用浏览器)上查找资 料、看视频、看书、看新闻等等,而在浏览器中只需要输入一些搜索就可以得到想要的信 息,这归根于搜索引擎的好处,但是实际上每个网页其实由多个资源组成。我们的浏览器 就是一个 HTTP 客户端,通过 HTTP 协议访问服务器,得到服务器中的 HTML 页面、文本 文件、图片、音频等资源,并且将这些资源搬运到浏览器(客户端) 显示给我们。 HTTP 协议是 Hyper Text Transfer Protocol (超文本传输协议)的缩写, 是用于从万维 网 (WWW:World Wide Web) 服务器传输超文本到本地浏览器的传输协议,它是基于 TCP/IP 协议通信的,因此它也是基于模型运作的,是一个应用层协议, 可以用它来传输服务器的各种资源,如文本、图片、音频等。

1.2. HTTP 协议的特点:

  1. 简单:当客户端向服务器请求服务时,只需传送请求方法和路径即可获取服务器的资源, 请求方法常用的有 GET、 HEAD、 POST 等, 每种方法规定了客户端与服务器通信的类型不同。
  2. 快捷: 由于 HTTP 协议简单,使得 HTTP 服务器的程序规模小,因而通信速度很快。
  3. 灵活: HTTP 允许传输任意类型的数据对象, 传输的类型由 Content-Type 加以标记。
  4. 无连接: 无连接的含义是限制每次连接只处理一个请求, 服务器处理完客户的请求,并收到客户的应答后,即断开连接,简单来说就是每进行一次 HTTP 通信,都要断开一次 TCP 连接, 可随着 HTTP 的普及,文档中包含大量图片的情况多了起来,每次请求完都要断开 TCP 连接,无疑增加通信量的开销, 为了解决 TCP 的连接问题, HTTP1.1 提出了持久连接的方法,即任意一端只要没有明确提出断开连接,则保持 TCP 连接状态,这样子就就减少了 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务端的负载。注意,在 HTTP1.1 版本之后才出现持久连接的方法。
  5. 无状态: HTTP 协议是无状态协议, 无状态是指协议对于事务处理没有记忆能力,即 HTTP 协议无法根据之前的状态进行本次的请求处理,这就意味着如果后续处理需要前面的信息,它必须重传数据,这样的情况可能导致 HTTP 协议传输的数据量增大,当然,凡事都有两面性,在另一方面,在服务器不需要先前信息时它的应答就较快,可以减少服务器的资源消耗,其实这种无状态对于用户来说也是不友好的,因此为了解决无状态的问题,引入了 Cookie 技术,这是一种可以让服务器知道用户上一次做了什么操作,并且记录下来,它是存储在客户端之中的,比如我们在淘宝上买东西,我们选择了几个商品,但是到了结账会跳转到另一个页面,此时如果服务器不知道我们选择了哪些商品,那怎么能结账成功呢? 所以 Cookie 就是用来绕开 HTTP 的无状态性的“手段”之一, 服务器可以设置或读取 Cookies 中包含信息,让服务器知道我们选择了什么商品,借此维护用户跟服务器会话中的状态,当然, Cookie 会被加密存储在客户端中,直到过期或者手动清除。

1.3. URL与资源

我们可以把整个英特网看做是一个巨大的图书馆,里面的资源应有尽有, 并且是对我 们是开放的,我们想要找一本书,那么我们就需要直到他存放在哪里,然后去找到它。 网络中的资源也是应有尽有,那么怎么样才能在网络的海洋中找到我们想要的资源呢? 因此 URI(Uniform Resource Identifiers) 就被设计出来,用于统一管理资源,就像我们去 图书馆找书一样,我们必须通过图书馆的系统,找到书所在的位置,而不是让我们自己一 本一本书去找。

URL 全称是 Uniform Resource Locator , 中文叫统一资源定位符, 是互联网上用来标识 某一处资源的绝对地址,使用它我们就必然能找到资源,除非资源已经被转移了。 URI 是 一个通用的概念,由两个子集组成,分别是 URLURNURL 是通过资源的位置来标识 资源,而 URN 更高级一点,只需通过资源名字即可识别资源,与他们所处的位置是无关 的,目前暂时还未推广 URN

大部分 URL 都会遵循 URL 的语法, 一个 URL 的组成有多个不同的组件,一个 URL 的通用格式如下:

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

当然,绝大部分的 URL 是不会包含所有组件的内容的,关于 URL 组件具体见表格

组件 描述
方案 scheme 指定访问服务器获取资源时使用哪种协议,有 HTTP、 HTTPS、 FTP、SMTP 等协议。
用户 user 某些方案访问资源时候需要指定用户名,才有权限获取资源。
密码 password 用户名后面可能需要密码进行验证,用户名与密码直接使用“:”冒号分隔连接。
主机 host 资源宿主服务器的主机名或者 IP 地址(点分十进制)。
端口 port 资源宿主服务器正在监听的端口号,很多方案都有默认的端口号,而无需我们自己填写,比如 HTTP 默认使用 80 端口, HTTPS 默认使用443 端口。 端口不是一个 URL 必须的部分,如果省略端口部分,将采用默认端口。
路径 path 服务器本地资源的路径,类似于电脑中的文件路径一样,使用“/”将路径与端口隔离。 从域名后的第一个“/”开始到最后一个“/”为止,虚拟目录也不是一个 URL 必须的部分,在路径之后是需要一个文件名,这就是 URL 指定的资源。 文件名部分也不是一个 URL 必须的部分,如果省略该部分,则使用默认的文件名。
参数 params 某些方案会使用这个组件来输入参数,可以拥有多个参数,使用“;”符号与路径分隔开。
查询 query 某些方案会使用这个组件传递参数以激活应用程序,查询组件的内容,没有通用的格式,用“?”字符与其他组件分隔开
片段 frag 一小片或者一部分资源的名字,引用对象时,不会将片段组件内容传输给服务器,这个字段是在客户端内部使用的,通过“#”字符与其他组件分隔开。

比如像我们论坛的网址: http://www.firebbs.cn/forum.php,它就是一个 URL ,这是最简 单的一个 URL 格式,通过它我们能访问论坛的首页资源, 其中 http 就是方案,指定 HTTP 协议进行连接 , 域名就是 www.firebbs.cnHTTP 协议默认端口是 80 ,在这里就无需指定 端口号,路径就是 forum.php , 其实这个是一个脚本文件,当客户端连接到服务器后, 服务 器会自动运行这个脚本文件, 这样子就访问到我们论坛上的资源了。

1.4. HTTP报文

HTTP 报文是由 3 个部分组成,分别是:对报文进行描述的“起始行”,包含属性的 “首部”,以及可选的“数据主体”,对于请求报文与应答报文,只有“起始行”的格式 是不一样的。

1.4.1. 请求报文

<method> <request-URL> <version>        //起始行
<headers>                               //首部

<entity-body>                           //数据主体

1.4.2. 应答报文

<version> <status> <reason-phrase>        //起始行
<headers>                               //首部

<entity-body>                           //数据主体

始行和首部就是由行分隔的 ASCII 文本组成, 每行都以由两个字符组成的行终止序 列作为结束,其中包括一个回车符 (ASCII 13) 和一个换行符 (ASCII 10) , 这个行 终止序列可以写做 CRLF。

下面就对这两种 HTTP 报文的各个部分简单描述一下:

  • 方法 (method)HTTP 请求报文的起始行以方法作为开始,方法用来告知服务 器要做些什么,常见的方法有 GET、 POST、 HEAD 等,比如 “GET /forum.php HTTP/1.1” 使用的就是 GET 方法。
  • 请求 URL(request-URL) :指定了所请求的资源。
  • 版本 (version) :指定报文所使用的 HTTP 协议版本,其中 <major> 指定了主要版 本号, <minor> 指定了次要版本号, 它们都是整数,其格式如下:
HTTP/<major>.<minor>
  • 状态码(status):这是在 HTTP 应答报文中使用的, 状态码是在每条响应报文的 起始行中返回的一个数字码,描述了请求过程中所发送的情况,比如成功、失败 等,不同的状态码有不同的含义, 具体见表格:
整体范围 已定义使用范围 描述
100 ~ 199 100 ~ 101 信息提示
200~299 200 ~ 206 成功
300 ~ 399 300 ~ 305 重定向
400 ~ 499 400 ~ 415 客户端错误
500 ~ 599 500 ~ 505 服务器错误
  • 原因短语(reason-phrase): 这其实是给我们看的原因短语,因为数字是不够直 观,它只是状态码的一个文本形式表达而已。
  • 首部(header): HTTP 报文可以有 0 个、 1 个或者多个首部, HTTP 首部字段向 请求和响应报文中添加了一些附加信息,从本质上来说,它们是一个 对, 每个首部都包含一个名字,紧跟着一个冒号“:”,然后是一个可选的空格, 接着是一个值,最后以 CRLF 结束,比如“Host: www.firebbs.cn”就是一个首部。
  • 数据主体(entity-body):这部分包含一个由任意数据组成的数据块,其实这与 我们前面所讲的报文数据区域是一样的,用于携带数据, HTTP 报文可以承载很 多类型的数字数据: 图片、视频、音频、 HTML 文档、软件应用程 序等。