一、URL与资源

URI是一类更通用的概念，用来表示某一个互联网资源的“位置”。

URI有两个重要的子集：URL和URN。

URL语法

URL由三个部分组成：

第一部分：URL方案，告知客户端通过怎样的方式访问资源（如http://，说明要使用HTTP协议）

第二部分：指的是服务器所在的位置（如ip地址或域名，一般也包含了端口号）

第三部分：资源的路径。路径说明了请求的是服务器上的那个资源。

大多数URL语法都建立在以下由9个部分构成的通用格式上：

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

下面提一下某些组件的注意事项：

参数：

参数由“；”将其与URL其他部分分隔开来（此处的其他部分指的是“参数组件”之前的URL部分，因为其后的部分的分隔符由后面的组件决定）

比如像FTP协议有两种传输模式（二进制和文本形式）。此时就可以通过参数来指定传输形式。

如：ftp://xxx.xx.xx.xx/pub;type=d

其中有一个参数type=d，参数名是type，对应的值时d。

而路径组件可以分为多个路径段，每一个路径段都能有自己的参数组件。如：

http://xxx.xx.xx.xx/hammers;sale=false/index.html;graphics=true

片段：

为了应用部分资源内容，可以使用“片段组件”表示资源内部的一个片段。

http://xxx.xx.xx.xx/tools.html#drills如：

浏览器并不会发送#drills，当从服务器拿到html文档并解析后，浏览器会根据片段内容（也就是drills）将页面向下滚动到名为drills的片段处。

URL快捷方式

相对URL：

URL有两种方式：相对的和绝对的。

绝对URL包含有访问资源所需的全部信息。

而相对URL则是不完整的，他所缺失的信息要从另一个“基础URL”中推导出来。

基础URL来自以下几个地方：

1、在资源中显示提供

有些资源会显式的指定“基础URL”，如，HTML文档可以包含一个定义了基础URL的HTML标记<BASE>

2、封装资源的基础URL

 如果一个资源中没有定义显式的基础URL，则相对URL会将“所在资源的URL作为基础URL”

将相对URL转换成绝对URL：

保留相对引用中定义的“组件”，然后继承“基础URL”中的剩下的“组件。

字符

有些协议（如SMTP协议）在传输的时候，会“剥去”URL中的一些特定的字符，

所以，在设计URL的时候，为了安全起见，我们需要一个“转义机制”，将特殊字符们转义成安全字符。

这种转义方法为：将一个“特殊字符”用一个百分号（%），后面跟着两个表示该字符ASCII码的十六进制数来替换它。

如：字符“~”，ASCII码为126，其十六进制数为0x7E。 所以应该转义成：%7E

http://xxx.xx.xx.xx/~abc即：将URL：

转义为：http://xxx.xx.xx.xx/%7Eabc

所有的字符在URL中使用时都应该被转义。（但这并不是强制的，对某些传输协议来说，不转义也不会产生什么问题）。

但某些字符“在作为某些用途时”不用转义，即被保留下来（不过在将其用于保留用途之外的场合时，还是要进行转义）。这些有特殊用途的字符为：

方案

常见的方案格式：

http

超文本传输协议，没有用户组件和密码组件，默认端口为80.

基本格式：

http://<host>:<port>/<path>?<query>#<frag>

https

与http方案唯一的区别在于，https方案使用了SSL，SSL为http连接提供了端到端的加密机制。https语法与http相同。默认端口为443.

基本格式：

https://<host>:<port>/<path>?<query>#<frag>

mailto

该URL指向的是E-mail地址。mailto URL的格式与标准URL格式不同。具体语法记录在RFC822中。

基本格式：

mailto:<RFC-822-addr-spec>

ftp

文本传输协议。用来从FTP服务器上下载或向其上传文件。

基本格式：

ftp://<user>:<password>@<host>:<port>/<path>;<params>

rtsp，rtspu

音/视频媒体资源标识符。

rtspu中的u表示它使用的是UDP协议获取资源。

基本格式：

rtsp://<user>:<password>@<host>:<port>/<path>

rtspu://<user>:<password>@<host>:<port>/<path>

file

方案file表示一台指定主机上课直接访问的文件。如果省略了主机名，就默认为正在使用URL的本地主机。

基本格式：

file://<host>/<path>

news

用来访问一些特定的文章或新闻组。它有一个独特的性质：news URL自身包含的信息不足以对资源进行定位。

new URL中没有提供主机名或机器名。而是需要从用户那里获取此类信息。如 可以在浏览器的选项里指定服务器。

新闻资源可以从多台服务器中获取。被称为位置无关的。

基本格式：

news:<newsgroup>

telnet

用于访问交互式业务。他表示的不是资源本身。而是可通过telnet协议访问的交互式应用程序。

基本格式：

telnet://<user>:<password>@<host>:<port>/

二、HTTP报文

如果说HTTP是信使，那么HTTP报文就是用来搬东西的包裹了。

HTTP报文由一行行的简单字符串组成。

HTTP报文都是纯文本的，不是二进制代码，读写方便。

HTTP报文只有两种：客户端发送的“请求报文”。服务端发送的“响应报文”。

HTTP报文由三个部分组成：起始行、首部字段、主体。

报文流

HTTP使用术语“流入”、“流出”、“上游”、“下游”来描述报文的方向。

如：报文流入服务器后，又会流出回用户的浏览器。

所有的HTTP报文都会向“下游”游动，所有的发送者都在接收者的“上游”。

报文的组成

之前提到了，每条报文由三个部分组成：

起始行和首部是由“行”分隔的ASCII文本。

每行以一个“由两个字符组成的行终止序列”作为结束，即：一个回车符（ASCII码13）和一个换行符（ASCII码10）。

（虽然规范中要求用这两种字符表示行终止，但稳健的应用也应该接受单个“换行符”作为行终止。因为有些老HTTP程序可能只会发送个换行符）。

报文的语法

所有的报文都能分为两类：请求报文和响应报文。

请求报文的格式：

<method> <request-URL> <version>

<headers>

<entity-body>

响应报文的格式：（只有起始行的语法有所不同）

<version> <status> <reason-phrase>

<headers>

<entity-body>

对各部分的简要描述（稍后会详细介绍）：

方法（method）

客户端希望服务端对资源执行的动作。如：GET、POST等

请求URL（request-URL）：

完整的URL。

版本（version）：

报文所使用的HTTP版本，格式为：HTTP/<major>.<minor>

其中主要版本号（major）和次要版本号（minor）都是整数。

状态码（status）：

这三位数字用于描述请求过程中所发生的情况（如成功、出错等）。

原因短语（reason-phrase）

状态码（status）的可读版本，原因短语只对人类有意义，机器不会处理它。

首部（headers）：

可以有零个或多个首部。每个首部占一行。

每个首部的格式为：先是一个首部名，后面跟一个冒号（：），然后是一个可选的空格，接着是一个值。

在整个首部组结束时，跟一个空行（CR+LF，即回车符+换行符）结束该首部。

主体（entity-body）：

该部分包含一个由“任意数据组成的数据块”。

并不是所有的报文都有实体部分。

注：虽然规定里首部必须以空行结束。但很多客户端和服务端在没有实体时，（错误的）省略了首部最后的空行。

起始行

所有的HTTP报文都是以一个起始行作为开始。

请求报文的起始行说明了要做什么。或称为请求行，包含了一个方法、一个请求URL、HTTP的版本。这些字段都是由空格符分隔。

响应报文的起始行说明了发生了什么。或称为响应行。包含了HTTP的版本、数字状态码、原因短语。这些字段都是由空格符分隔。

方法

常用的HTTP方法：

由上表可知，有些方法的请求报文中并不存在主体。

服务器还可以实现一些自己定义的方法。这些方法被称为扩展方法。

常见的扩展方法有：

并不是每个服务器都实现了所有的方法。如HTTP1.1只要求服务器必须实现GET和HEAD方法。

状态码

状态码存在于响应报文的起始行中，作用是告诉客户端，发生了什么。

状态码分类：

100~199：信息性状态码

200~299：成功状态码

300~399：重定向状态码

一般情况下重定向的流程为：

客户端发送请求报文。

服务端返回一个含有“3xx”重定向码的响应报文。

然后客户端根据响应报文的内容，再发送一个请求报文到重定向的服务器。

然后该服务器再返回给客户端响应报文。

400~499：客户端错误状态码

500~599：服务端错误状态码

以上这些状态码其实不用刻意的去背，只要多留意一下“原因短语”，还是很容易辨识的。

原因短语

原因短语与状态码是成对出现的，

HTTP并没有硬性规定什么状态码必须对应什么原因短语，但提倡使用上面提到的原因短语。

版本号

版本号会以HTTP/<major>.<minor>的形式出现。目的是以便互相了解对方的能合报文格式。

版本号不会被当作小数来处理。版本中<major>和<minor>会被当做单独的数字来比较与处理。

首部

首部和方法配合着工作。共同决定了客户端和服务器能做什么。

一个报文中可以有零个或多个首部。且“同一种首部可以有多个（如一个响应报文首部里可以有多个Set-Cookie首部）”

首部主要分为以下五类：

1、通用首部

这些首部客户端和服务端都可以使用。提供一些最基本的信息。

2、请求首部

是请求报文特有的首部，服务器可以根据请求首部中的信息，为客户端提供更好的响应。

请求首部又可以细分为以下几种请求首部：

1、请求的信息性首部

2、Accept首部

该首部为客户端提供了一种将其喜好和能力告知服务器的方式，此首部对两方都受益，

客户端会得到它想要的，而服务器也不会浪费宽带发送客户端无法使用的东西。

3、条件请求首部

客户端为请求加上某些限制，要求服务端在对请求进行响应之前，确保条件为真。

4、安全请求首部

5、代理请求首部

3、响应首部

1、响应的信息性首部

2、协商首部

3、安全响应首部

4、实体首部

实体首部提供了实体及其内容的信息，可以告知报文接收者它在对什么进行处理。

1、实体的信息性首部

2、内容首部

3、实体缓存首部

提供与被缓存实体有关的信息（之后还会详讲）

5、扩展首部

扩展首部是非标准的首部，可以由开发者自己创建。即使不知道含义，HTTP程序也应该对其进行转发。

实体

该部分为可选的。

实体的主体是HTTP要传输的内容。

该内容可以是很多类型的数字数据，如：图片、视频、HTML文档、软件应用程序、电子邮件等。

三、cookie机制

http是一种无状态协议。所以一般情况下服务端很难根据http协议来判断访问者是哪一位。

而cookie可以很好的解决这个问题。cookie是当前“识别用户，实现持久会话的最好方式”。

cookie的类型

可以笼统的分为两类：会话cookie和持久cookie。

会话cookie：是一种临时cookie，当用户退出浏览器时，会话cookie就删除了

持久cookie：存储在硬盘上，浏览器退出，计算机重启后它任然存在。

它们之间的唯一区别就是过期时间。

如果设置了Discard参数，或没有设置Expires或Max-Age参数来扩展过期时间，该cookie就是一个会话cookie

cookie的工作原理

某个客户端首次访问服务器时，服务器通过响应首部Set-Cookie或Set-Cookie2，给该客户端“贴上”一个“该客户端独有的cookie”。

这样服务端以后就能根据该cookie来识别客户端了。

浏览器会记住从服务器返回的响应首部中的cookie内容，并将cookie内容存入浏览器的“cookie数据库中”。将来如果用户使用该浏览器访问同一服务器时，浏览器就会挑出“该服务器贴到用户上的那些cookie”，然后通过请求首部Cookie将cookie内容发送给服务器。

客户端侧状态

不同的浏览器会以不同的方式存储cookie。

1、IE浏览器

IE将每个cookie都存储在缓存目录里的独立文件中（即每个浏览器“贴的”cookie都对应一个cookie）。

2、谷歌浏览器

将所有的cookie都保存在同一的一个文件里。该文件的格式为SQLite3数据库格式的文件。文件名为Cookies

3、火狐浏览器

将所有的cookie都保存在同一的一个文件里。该文件的格式为SQLite3数据库格式的文件。文件名为cookies.sqlite

cookie成分

cookie规范定义在报文的首部里，同一种首部可以重复

如服务器可以在响应报文中设置多个Set-Cookie首部，一次性给浏览器“贴”多个cookie

目前的cookie规范有两个版本。

cookies版本0

http://home.netscape.com/newsref/std/cookie_spec.html描述文档地址：

版本0的响应首部Set-Cookie

格式：

Set-Cookie:name=value [; expires=date] [; path=path] [; domain=domain] [; secure]

其中：Set-Cookie首部有一个强制的cookie值和名。后面的属性都是可选的，由分号隔开。

版本0的请求首部Cookie

客户端发送请求时，会将所有与域、路径、过滤器相匹配且未过期的cookie键值对都发送给该站点。

格式为：

Cookie: name1=value1 [; name2=value2]·····

cookies版本1

http://www.ietf.org/rfc/rfc2965.txt描述文档地址：

cookies版本1是cookie的一个扩展版本。虽然该版本引入了新首部，但也能与版本0交互。

主要改动如下：

1、为每个cookie关联上解释性文本，对其目的进行解释。

2、允许在浏览器退出时，不考虑过期时间，将cookie销毁。

3、Max-Age使用相对秒数。

4、在域和路径的基础上还增加了端口号

5、通过cookie首部回送“域、端口、路径过滤器”（如果有的话）

6、为实现互操作性使用的版本号。

7、在Cookie首部从名字中区分出附加关键字的$前缀。

版本1的Cookie2首部：

版本1增加了一个cookie2首部，cookie可以告诉服务器：客户端所支持的新的cookie标准版本。

如：Cookie2: $Version="1"

四、HTTPS

https方案

https是最常见的http安全版本。

HTTPS就是在安全的传输层上发送HTTP。在将http发送给TCP之前，现将其发送给一个安全层对其进行加密，然后再发送给TCP传输层。

其中安全层使用的协议是SSL或TLS协议。

如果URL的方案为https，客户端就会打开一条到服务器端口443（默认情况下）的连接，然后与服务器“握手”，以二进制格式与服务器交换一些SSL安全参数，附上加密的HTTP命令。

在未加密HTTP中：

客户端会打开一条到web服务器端口80的TCP连接，发送一条请求报文，接收一条响应报文，关闭连接。

在HTTPS中：

1、客户端首先打开一条到Web服务器端口443的连接。

2、然后建立端口443的TCP连接。之后客户端与服务端进行SSL握手，即对加密参数进行沟通，并交换秘钥。

3、然后SSL初始化就完成了，客户端就可以将请求报文发送给“安全层让其进行加密”。

4、之后在将已加密的请求发送给TCP。

5、然后服务端再将响应发送给SSL层进行加密，加密后再发给TCP，然后发给客户端。

6、SSL关闭，TCP连接关闭。

SSL握手

在上面的第二步中，客户端和服务端进行了一次SSL握手。该握手主要完成以下工作：

交换协议版本号。

选择一个两端都了解的密码。

对两端的身份进行验证。

生成临时的会话秘钥，以便加密信道。

OpenSSL

SSL是个复杂的二进制协议。我们可以借助一些商业或开源库，来编写SSL客户端和服务端。

OpenSSL是一个实现了SSL和TLS协议以及以及一个全功能的通用加密库。

（之前我的“深入理解Connector”博客中就提到了tomcat native技术中就集成了OpenSSL）

可以从http://www.openssl.org上获取OpenSSL的相关信息，并下载。

五、实体和编码

各种媒体对象都可以通过http传送，如图像、文本、影音、软件等。HTTP还会确保它的报文被正确的传送、识别、以及适当的处理。

如果说HTTP报文是箱子，那么实体就是货物。

实体包含两个部分：实体首部和实体主体。

实体首部

在之前讲解首部的时候列出过HTTP实体首部。在此就不一一列出了。

下面详细的讲一下其中几个实体首部：

Content-Length首部详解

该首部指出实体主体的字节大小。

除非使用了“分块编码”，否则必须使用该首部。

因为该首部会被用来“检测报文结尾”，即用来识别是否传送了完整的报文实体主体。

而且Content-Length在持久连接中也是必不可少的。因为如果是持久连接传送，客户端可通过该首部知道该报文何时结束，也就能知道吓一跳报文何时开始。

Content-Length指的长度一定是“实体主体内容编码后的字节长度”。（而不是原始的字节长度）

Content-MD5首部详解

该首部发送的是“编码前”的实体主体运行md5算法的结果。

作用是验证端到端实体的完整性，即两边都做一下md5算法，比对一下结果。

另一个作用是充当散列表的关键字，用来快速定位文档。

Content-Type首部详解

该首部字段说明了实体主体的基本媒体类型，常用的媒体类型如下表：

注：该首部说明的是原始实体主体的类型，即主体编码之前的。

Content-Encoding首部详解

http应用有时在发送报文前，要对报文中的实体主体进行编码。目的可能是压缩或加密等。

Content-Encoding首部是用来说明编码时使用的算法

内容编码类型：

Accept-Encoding首部详解

毫无疑问，我们不希望服务器用一种客户端无法解析的方法来进行编码。

所以客户端可以通过该首部将自己支持的实体主体编码格式发给服务端。

客户端可以为每种编码附带Q值说明编码优先级。范围是0.0~1.0，1.0表示最希望使用的编码。

“*”表示任何其他方法。

传输编码

之前讨论的都是内容编码，主要是对实体主体进行编码。

而传输编码主要是为了改变数据在网络中的传输方式，下面主要说一下传输编码中的分块编码。

分块编码把“报文”分割陈若干个大小的块。块之间是紧挨着发送的，这样就不需要使用Content-Length首部了（因为每块的大小都是固定的，只需要知道块数即可）。

注意：分块编码是对整个传输进行编码，而不仅仅是对实体主体进行编码。

分块编码有起始的HTTP响应首部开始组成一块，随后就是一系列分块。

每个分块包含一个“长度值”和一个“该分块的数据”。长度值是16进制，数据大小是以字节计算。

长度值与分块之间由“<CR><LF>”分割（之前提到过，这个分割符就是一个回车符（ASCII码13）和一个换行符（ASCII码10））。

最后一个块比较特别，其长度为0，表示主体结束。

传输编码的规则：

1、传输编码集合中必须包含“分块”。唯一例外是使用关闭连接来结束报文。

2、当使用分块传输编码时，它必须是最后一个作用在主体之上的（如报文既有内容主体编码，又有分块编码。那么就必须先对实体主体进行内容编码，然后再对整个报文进行分块编码）。

3、分块编码不能多次作用在一个报文主体上。

所有的HTTP/1.1程序都支持分块编码。

范围请求

http允许客户端只请求文档的某一范围。

使用的自然就是我们之前提到的Range响应首部。

如：Range: bytes=4000-

这就表示，客户端只想请求文档开头4000个字节之后的部分。

另外还能用该首部来加速下载。

如客户端从多台服务器上下载同一个文档，那么就能“在一条请求报文中”同时从不同服务器上下载该文档的不同范围。返回的响应也是单个实体。

Http协议详解