http协议知识
http协议知识
一、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能够查知报文是否遭到篡改，从而保护报文的完整性。
