vlambda博客
学习文章列表

一、  http协议的概念及相关基础

HTTP通常被译为超文本传输协议，但这种译法并不严谨。严谨的译名应该为“超文本转移协议”。但是前一译法已约定俗成，所以一直沿用。

为了理解HTTP，有必要先了解一下TCP/IP协议族。通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的。而HTTP是属于它内部的一个子集。

 

像这样把与互联网相关的协议集合起来总称为TCP/IP。也有说法认为，TCP/IP是指TCP和IP这两种协议。还有一种说法认为，TCP/IP是在IP协议的通讯过程中，使用到的协议族的统称。

在TCP/IP协议族的分层中，处于应用层。应用层决定了向用户提供应用服务时通信的活动。

 

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，往下走每层都会对请求的报文进行一层封装，接收端则往应用层往上反向进行。示例图如下：

 

在详细介绍HTTP前，还有一个重要的策略需要提一下：那就是为了准确无误地将数据送达目标处，TCP协议采用了三次握手策略。用TCP协议把数据包送出去后TCP不会对传送后的情况置之不理，他一定会向对方确认是否成功送达。握手过程中使用的标志——SYN（synchronize）和ACK（acknowledgement）。

 

最后将这一套协议和传输过程汇总理解一下流程：

 

二、 HTTP报文信息

用于HTTP协议交互的信息被称为HTTP报文。请求端的HTTP报文叫做请求报文，响应端的叫做响应报文。HTTP报文本身是由多行数据购车的字符串文本。

1、 HTTP报文构成

HTTP报文大致可分为报文首部和报文主体两块。两者由由最初出现的空行（CR+LF）来划分。报文主体并不是必须的。

 

请求报文及响应报文的结构：

请求行：

包含用于请求的方法，请求URI和HTTP版本。

状态行：

包含表明响应结果的状态码，原因短语和HTTP版本。

首部字段：

包含表示请求和响应的各种条件和属性的各类首部。一般有4种首部，分别是：通用首部、请求首部、响应首部和实体首部。

其他：

可能包含HTTP的RFC里未定义的首部（如Cookie等）。

下面展示一个GET请求的样例：

 

2、 首部字段种类

HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务器之间以HTTP协议进行通信的过程，无论是请求还是响应都会使用首部字段，它能祈祷传递额外重要信息的作用。

HTTP首部字段石油首部字段名称和字段值构成的，中间用冒号“：”分隔。

4种HTTP首部字段类型简介（以前标准采用HTTP/1.1版本规范为例）：

通用首部字段：请求报文和响应报文两方都会使用的首部。

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	逐跳首部、连接的管理
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段：从客户端向服务器发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web认证信息
Expect	期待服务器的特定行为
From
Host	请求资源所在服务器
If-Macth	比较实体标记（ETag）
If-Moditied-Since	比较资源的更新时间
If-None-Match	比较实体标记（与If-Match相反）
If-Range	资源未更新时发送实体Byte的范围请求
If-Unmodified-Since	比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中URI的原始获取方
TE	传输编码的优先级
User-Agent	HTTP客户端程序的信息

 

响应首部字段：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端资源重定向至指定URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

 

实体首部字段：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

首部字段名	说明
Allow	资源可支持的HTTP方法
Content-Encoding	实体主体使用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小（单位：字节）
Content-Location	替代对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改时间

 

3、 常见首部字段介绍：

Accept

 

Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype这种形式，一次指定多种媒体类型。

 

Accept-Language

 

首部字段Accept-Language用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级。可以一次指定多种自然语言集。

 

User-Agent

首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器

Accept-Encoding

 

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。

Connection

Connection首部字段具备两个作用：

1、  控制不再转发给代理的首部字段

 

2、 管理持久连接

 

HTTP/1.1版本的默认连接都是持久连接。为此客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。HTTP/1.1之前版本的HTTP版本的默认连接都是非持久连接。为此如果想在旧版本的HTTP协议上维持持续连接，则需要指定Connection首部字段的值为Keep-Alive。

 

4、 返回结果的HTTP状态码

状态码的职责是当客户端向服务端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

 

状态码数字中的第一位指定了响应类别，后两位无分类。响应类别有一下5种。

 

a)  常见的状态码介绍

200 OK

表示从客户端发来的请求在服务端被正常处理了。

204 No Content

代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。

206 Partial Content

该状态码标识客户端进行了范围请求，而服务器成功执行了这部分GET请求。响应报文中包含由Content-Range指定范围的实体内容。

301 Moved Permanently

永久性重定向。该状态码标识请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。也就是说，如果已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI重新保存。

302 Found

临时重定向。该状态码标识请求的资源已被分配了新的URI，希望用户（本次）能使用的的URI访问。

303 See Other

该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。303状态码和302 Found状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。

304 Not Modified

该状态码表示客户端发送附带条件的请求时，服务器端准许请求访问资源，但未满足条件的情况。304状态码返回时，不包括任何响应主体部分。304虽然被划分在3XX类别中，但是和重定向没有关系。

400 Bad Request

该状态码标识请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外浏览器会像200 OK一样对待该状态码。

401 Unauthorized

该状态码标识发送的请求需要有通过HTTP认证的认证信息。返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用以质询用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。

403 Forbidden

该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想做说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源IP地址视图访问）等列举的情况都可能是发生403的原因。

404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务端拒绝请求且不想说明理由时使用。

500 Internal Serve Error

该状态码表明服务器端正在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。

503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

状态码和状况的不一致

不少返回的状态码响应都是错误的，但用户可能察觉不到这点。比如Web应用程序内部发生错误，应用里准备了对应的错误页面，状态码依然返回200 OK，这种情况也经常遇到。

三、  HTTPS介绍

1、  HTTPS基础介绍

上面介绍的是HTTP基础与一些优秀和方便的一面，然而HTTP并非只有好的一面，事物皆具两面性，它也是有不足之处的。

Ø  通信使用明文（不加密），内容可能会被窃听

Ø  不验证通信方的身份，因此有可能遭遇伪装

Ø  无法证明报文的完整性，所以有可能已遭篡改

由于HTTP本身不具备加密的功能，所以也无法做到对通信整体进行加密。即，HTTP报文使用明文方式发送。而互联是连通到全世界的网络组成的，无论世界哪个角落的服务器在客户端通信时，在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意的窥视行为。

 

即使已经加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

在这样的大背景环境下，为了统一解决各个环节上的安全问题，需要在HTTP上再加入加密处理和认证等机制。我们把添加了加密及认证机制的HTTP称为HTTPS（HTTP Secure）

 

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

 

随着SSL的应用广泛，已经成为互联网上的一种标准，后续将SSL（Secure Sockets Layer）标准化后更名为TLS（是Transport Layer Security的缩写）。

HTTPS采用共享密钥加密个公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密项目，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

 

由于加密、证书等相关知识内容很多，这里就不一一进行概念介绍了，有疑问可查询相关资料。

2、 HTTPS的安全通信已步骤介绍

 

步骤1：客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所以使用的加密算法及密钥长度等）。

步骤2：服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤3：之后服务器发送Certificate报文。报文中包含公开密钥证书。

步骤4：最后服务器发送Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。

步骤5：SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3的公开密钥进行加密。

步骤6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次我州协商是否能够成功，要以服务器是否能够正确解密该报文作为判断标准。

步骤8：服务器同样发送Change Cipher Spec报文。

步骤9：服务器同样发送Finished报文。

步骤10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。

步骤11：应用层协议通信，即发送HTTP请求。

步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了些省略，这步骤之后再发送TCP FIN报文来关闭与TCP的通信。

在以上流程中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。