本文以总结的形式，先大体介绍TCP／IP协议整体组成，再择其应用层上的HTTP协议进行详细总结，继而拓展知识点讲解加密学，过渡到HTTPS协议的学习，除去网络知识必备掌握的三次握手、四次挥手，另需了解基于SSL/TLS的握手，也是重要的一个环节。

本文涉及到的知识点如下：

• 网络基础TCP/IP
• HTTP协议基础与重点
• 加密与签名
• HTTPS协议（基于SSL/TLS的握手）

（若想要详细了解TCP三次握手、四次挥手相关知识点，可看此篇博客：
深入浅出之 TCP协议（三次握手与四次挥手、超时重发、流量控制、拥塞控制、与UDP区别））

---

---

一. 网络基础TCP/IP

在正式介绍HTTP网络知识之前，先追其根源—–TCP/IP协议族，通常使用的网络是在TCP/IP协议族的基础上运作的，而HTTP属于它内部的一个子集，所以先了解有关TCP/IP有关知识，为HTTP做铺垫。

1. TCP/IP协议分层管理

（1）协议（protocal）

计算机与网络相互通信，双方必须基于相同的方法，例如由哪一方先发起通信、使用哪种语言进行通信、如何结束通信等都需要事先规定。不同的硬件、OS之间的通信都需要一种规则，就是协议（protocal）。

（2）TCP/IP协议定义

协议中存在各种内容，例如从电缆规格到IP地址的选定方法、双方建立通信的顺序，以及web页面显示需要处理的步骤等。以上这种与互联网相关联的协议集合起来总称为 TCP/IP。（有的说法是TCP/IP是指TCP和IP这两种协议，还有一种说法是TCP/IP是在IP协议的通信过程中使用的协议族的统称）

（3）分层管理

TCP/IP协议族里重要的一点是分层，可分为：应用层、传输层、网络层、数据链路层。

其实层次化是有它的好处，如果互联网只有一个协议统筹，某个地方需要改动时需要将所有部分换掉，而分层之后只需替换变动层即可。每一层也只需考虑自己的任务即可。

• 应用层：应用层决定了向用户提供应用服务时通信的活动。

TCP/IP协议族内预存了各类通用的应用服务，例如FTP（File Transfer Protocol文件传输协议）和DNS（Domain Name System域名系统）服务就是其中两类，HTTP协议也处于改层。

• 传输层：传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。

在传输层有两个性质不同的协议：TCP（Transmission Control Protocol传输控制协议）和UDP（User Data Protocol用户数据报协议）。

• 网络层（网络互连层）：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传送给对方。

与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起作用就是在众多选项内选择一条传输路线。

• 链路层（网络接口层）：用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、网卡，以及光纤等物流可见部分。硬件上的范畴均在链路层的作用范围内。

---

2. TCP/IP通信传输流

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端的顺序从应用层往下走，接收端则往应用层上走。

举个HTTP的例子：作为发送端的客户端在应用层（HTTP协议）发出一个想看某个Web页面的HTTP请求。

• 为了传输方便，在传输层（TCP协议）把应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。

• 在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这样发送网络的通信请求就准备完全了。

• 接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输层到应用层，才算真正接收到由客户端发送过来的HTTP请求。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。

这种包装数据信息的行为称为封装（encapsulate）

---

3. 与HTTP关系密切的协议：IP、TCP和DNS

（1）负责传输的IP协议

定义作用

• 定义： IP（Internet Protocol）网际协议位于网络层。IP占据了TCP/IP协议族的“一半”，可见其重要性，切勿将IP同IP地址搞混，“IP”是一种协议的名称。

• 作用：把各种数据包传送给对方。要保证确实传送到对方那里，需满足各类条件，其中两个重要的条件：（IP地址可以和MAC地址进行配对，IP地址可变换，但MAC地址基本上不会改变。）

  • IP地址：指明节点被分配的位置。
  • MAC地址（Media Access Control Address）：指网卡所属的固定地址。

使用ARP协议凭借MAC地址进行通讯

IP间的通信依赖MAC地址。在网络上，通信的双方在同一局域网（LAN）内的情况很少，通常是经过多台计算机和网络设备中转才能连接到对方。

在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时会采用ARP协议（Address Resolution Protocol），它是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

无法全面掌握互联网中的传输状况

在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。

这种机制称为路由选择（rounting），有点像快递送货，寄快递时把货物送到集散中心，即可知道是否肯收件，接着检查送达地址，明确下一站送达的集散中心，下一个集散中心再判断是否能送达目的地。（其中的中转过程无法掌握，所以无法掌握互联网中的细节。）

（2）确保可靠性的TCP协议

TCP位于传输层，提供可靠的字节流服务（Byte Stream Service）。

• 字节流服务：为了方便传输，将大块数据分割以报文段（segment）为单位的数据包进行管理。
• 可靠的传输服务：能够把数据准确可靠地传给对方。

TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

确保数据能到达目标

为了准确无误地将数据送达目标处，TCP协议采用了三次握手（three-way handshaking）策略。用TCP协议将数据包送出去后，TCP一定会向对方确认是否成功送达。若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的顺序包。

握手过程

• 定义：三次握手，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
• 目的：是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息

在socket编程中，客户端执行connect()时，将触发三次握手。

• 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

• 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

• 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据。

（若想要详细了解TCP三次握手、四次挥手相关知识点，请看此篇博客：
深入浅出之 TCP协议（三次握手与四次挥手、超时重发、流量控制、拥塞控制、与UDP区别））

（3）负责域名解析的DNS服务

DNS（Domain Name System）服务是和HTTP协议一样位于应用层的协议，它提供域名到IP地址之间的解析服务。

计算机不仅可以被赋予IP地址，也可以被赋予主机名和域名。例如 www.baidu.com。用户经常使用这种方式来访问对方计算机，但要让计算机去理解名称就显得困难，因此DNS服务应运而生，DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。

---

4. 各种协议与HTTP协议的关系

这张图是客户端向服务器请求资源时的过程，在HTTP通信过程中包含了IP协议、TCP协议、DNS服务，发挥着各自的作用，查看下图。

---

---

---

二. Http协议

1. 基本概念

（1）HTTP协议及特点

• 协议：指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则。

• HTTP协议：超文本传输协议（HTTP）是一种通信协议，它允许将超文本标记语言（HTML）文档从Web服务器传送到客户端的浏览器。

如上图，其实HTTP协议是基于TCP/IP协议来传递数据，从服务器端获取到数据，是C/S架构——客户端到服务端通信的接口。浏览器作为HTTP协议下的客户端，通过URL发送请求到服务端，服务端做出响应将内容返回给浏览器显示，这就是一个基本的C/S架构的HTTP协议。

HTTP协议特点：

• 支持客户/服务器模式。
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、 HEAD、POST。每种方法规定了客户与服务器联系的类型不同。 由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
• 灵活： HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• 无连接： 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求， 并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。限制地每次连接只处理一个请求，处理完请求后收到客户端应答从而断开连接。采用这种方式可节省传输时间。
• 无状态： HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。 缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每 次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

（2） Http 版本区别

（3）HTTP请求报文和响应报文

HTTP请求报文主要由请求行、请求头、空行、请求正文（GET方式无请求正文）4部分组成。

• 请求行：由请求方法、URL和协议版本3部分组成。
• 请求头：为请求报文添加一些信息，由“名／值”组成。
• 空行：请求头的最后会有一个空行，代表请求头部结束，接下来为请求正文。此部分不可少。
• 请求正文

HTTP响应报文主要由状态行、响应头、空行、响应正文4部分组成。

• 状态行：由状态码、状态码描述和协议版本3部分组成。
• 响应头：为响应报文添加一些信息，由“名／值”组成。
• 空行：头的最后会有一个空行，代表响应头部结束，接下来为响应正文。此部分不可少。
• 响应正文

（4） Http的请求方式总结

方式名称	含义
GET	请求获取Request-URI所标识的资源
POST	在Request-URI所标识的资源后附加新的数据
HEAD	请求获取由Request-URI所标识的资源的响应信息报头
PUT	请求服务器存储一个资源，并用Request-URI作为其标识
DELETE	请求服务器删除Request-URI所标识的资源
TRACE	请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT	保留将来使用
OPTIONS	请求查询服务器的性能，或者查询与资源相关的选项

HEAD、GET、OPTIONS和TRACE是安全的方法，因为它们只从服务器获得资源而不对服务器做任何修改，但是前三个在用户端不安全，POST相对安全，但POST会影响服务器的资源。TRACE方法对于服务端盒用户端一定是安全的。

（5） 请求头信息

请求头	说明
User-Agent	中文名为用户代理，是Http协议中的一部分，它是一个特殊字符串头，是一种向访问网站提供你所使用的浏览器类型及版本、操作系统及版本、浏览器内核、等信息的标识
Referer	先前网页的地址，当前请求网页紧随其后,即来路
Cache-Control	指定请求和响应遵循的缓存机制
Connection	表示是否需要持久连接。（HTTP 1.1默认进行持久连接）
If-Match	只有请求内容与实体相匹配才有效
If-Modified-Since	如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
If-None-Match	如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变

这里只介绍举例部分重要的请求响应头，关于更详细信息可看：
http://tools.jb51.net/table/http_header

（6） 响应头信息

应答头	说明
Content-Encoding	文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。
Content-Type	表示后面的文档属于什么MIME类型。
Date	当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。
Expires	过期时间
Last-Modified	档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。

.
（7） 状态码信息

HTTP状态码分类

分类	描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

较常用状态码

• 200 - 请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 404 - 请求的资源（网页等）不存在
• 500 - 内部服务器错误

---

2. Http请求方式Get和Post的区别

安全幂等性质

• GET一般用于获取或者查询资源信息，这就意味着它是幂等的（对同一个URL的多次请求返回同样的结果）和安全的（没有修改资源的状态）
• POST一般用于更新资源信息，既不是安全，也非幂等。

参数存放位置

• GET方法中，客户端把要发送的数据添加到URL后面（即把数据放到HTTP协议头中，GET是通过URL请求数据的），使用“？”连接，参数之间使用“&”连接。注意：HTTP协议中并没有对URL长度进行限制，但是浏览器和服务器会对其限制！（面试中经常会问到URL长度限制问题，一定要明白协议中并未对此规定！）
• POST是将需要传递的数据放到HTTP请求报文的消息体中（同样，协议未对此部分大小进行限制），不过传送的数据量比GET更大且安全性更高（若不对数据进行加密，可使用抓包软件进行获取）。

浏览器缓存

• GET请求的数据会被浏览器缓存起来，留下历史记录。
• POST提交的数据不会。

---

3. 为什么HTTP是无状态的？如何保持状态？

HTTP无状态：是指协议对于事务处理没有记忆能力，不能保存每次客户端提交的信息，即当服务器返回应答后，此次事务的所有消息会被丢掉。即使客户端发来一个新的相同的请求，服务器无法知道它是否与上次请求有联系。

举个例子：一个包含多个图片的网页浏览步骤：

• 建立连接，客户端发送一个网页请求，服务端返回一个HTML页面（一个纯文本页面），关闭连接。
• 浏览器解析HTML文件，遇到图片标记得到URL，此时客户端和服务器再建立连接，客户端发送一个图片请求，服务器返回图片应答，关闭连接。（涉及到无状态定义，对于服务器而言，即使是同一个客户端请求，无记忆能力无法识别）

优缺点

• 优点：服务器不用为每个客户端连接分配内存来记忆大量状态，也不用在客户端失去连接时去清除内存，节省服务器端资源。
• 缺点： 如果后续处理需要前面的信息，客户端必须重传，可能导致每次连接传送的数据量增大。

解决办法

针对这些问题，可以采用会话跟踪技术，即把状态保存在服务器，只发送回一个标识符，浏览器在下次提交中把这个标识符发送过来，这样可以定位存储在服务器上的状态信息。技术有以下：

• COOKIE
• SESSION
• URL重写
• 作为隐藏域嵌入HTML表单中

---

4. cookie与session

（1）Cookie

定义

Cookie技术是客户端的解决方案，由服务器发送给客户端的特殊信息，存放在response的header中，这些信息以文本文件方式存放在客户端，由客户端每次向服务器发送请求时带上，此时是存放在request的header中。

如下图，Cookie的设置可分为以下几个步骤：

• 客户端向服务端Request请求。
• 服务器在response的header中设置Cookie，发送给客户端。
• 客户端会将请求request和Cookie一起打包发送给服务端。
• 服务端会根据Cookie判断将response返回给客户端。

因为HTTP协议“无状态”的特点，在请求完毕后会关闭连接，再次交换数据需要建立新的连接，无法跟踪会话。Cookie机制的引入正好弥补了HTTP协议“无状态”的缺陷。

工作原理

由于HTTP协议是“无状态”的，所以服务器无法从网络上获取用户的真实身份。

解决办法：此时客户端给服务端发一个“通行证”，它是一个唯一的标识，无论哪个用户访问服务器需要带上此标识，这样服务器即可辨识用户，这也就是Cookie的原理—–个人身份标识。

总结

在客户端向服务端请求时，若服务器要记录该用户信息，就发送一个携带cookie的response，客户端会保留此cookie，当客户端需要再次请求时，将请求URL和Cookie信息一同打包发送给服务端，此时服务器即可根据cookie辨认状态再做出响应（也可修改）。

总而言之，Cookie就是用户识别标志，保存在客户端！

（2）session

定义

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器行。客户端浏览器访问的时候，服务器把客户端信息以某种形式记录在服务器上。

注意：当客户端浏览器再次请求服务器时是不需要携带信息的，在服务器上已有记录。

工作原理

• 在服务端运行程序时创建Session
• 在创建Session的同时，服务器会为该Session生成唯一的Session ID
• 在Session被创建后，可以调用相关方法往Session中添加内容，注意发送到客户端的只有Session ID
• 当客户端再次发送请求时，会将Session ID带上，服务器接受到请求之后就会依据ID确认用户身份，找到相应的Session。

（3）两者的区别

• 存放位置不同
  
  • Cookie：保存在客户端；
  • Session：保存在服务端；
• 存取方式不同
  
  • Cookie：只能保存ASCII码字符串；
  • Session：可保存任何数据；
• 安全性（隐私策略）不同
  
  • Cookie：由于它存放在浏览器中，所以对客户端是可见的，客户端的程序有可能修改内容；
  • Session：存放在服务端，不存在敏感信息泄露；
• 有效期不同
  
  • Cookie：客户端一般设置有效期较长，这样可保存较长时间；
  • Session：设置成-1后，在用户关闭浏览器后，session就会失效；
• 对服务器造成的压力不同
  
  • Cookie：保存在客户端，不占用服务器内存；
  • Session：由于它存放在服务端，多个用户并发访问服务器时，会产生多个session，十分消耗内存；

---

5. HTTP的短连接和长连接的原理

在HTTP1.0中默认采用的是短连接，即浏览器和服务器每进行一次HTTP操作需要进行一次连接，任务结束时中断。若客户端访问的某个HTML或其他类型的Web中又包含其他Web资源，例如JS文件、图像文件、CSS文件，那么每次遇到以一个Web资源都会建立一个HTTP会话，进行三次握手，十分耗费资源。因此，通过在Request中增加“Connection：keep-alive”可支持长连接。

当HTTP采用长连接时的数据交互流程如下：

• 客户端发出request，其中该版本号为1.0，并且在request中包含了一个header：“Connection：keep-alive”。
• 服务器收到该请求的长连接后，将会在response加上“Connection：keep-alive”，同时不会关闭已建立的TCP连接。
• 同时，客户端收到response中的header，发现是一个长连接，同样不会关闭已建立的TCP连接。

在HTTP1.1起，默认使用长连接，来保持连接特性，即在请求头和响应头中默认加入“Connection：keep-alive” 。HTTP长连接利用同一个TCP连接处理多个HTTP请求和响应。

Keep-Alive不会永久保持连接，有一个保持时间，可以在不同的服务器中设定时间，实现长连接要求客户端和服务器都支持长连接。

---

---

三. 加密与签名

在讲解HTTPS之前需要了解一些预备知识，即加密与签名。

1. 密码学

如果不对传输数据进行加密，很容易被第三方窃取或篡改，所以加密是保护数据的措施。最常见的就是对数据进行MD5加密，获取数据后再将其解密。

（1）组成

因此，加密包含算法和密钥这两个元素，两者结合会使原有数据加密为明文，而加密分为以下两个部分：

• 对称加密

  • 定义：加密数据用的密钥，跟解密数据用的密钥是一样的。
  • 优势：此定义决定了它的特点：加密和解密过程效率非常高
  • 劣势：但是缺点也很明显，即双方执同一个密钥，必须要确保密钥的安全性，带来的技术成本很高。

• 不对称加密：其中含有两个密钥，一个是一方保管的私有密钥，另一个是双方公有的公有密钥。这种方式决定了发送秘文的一方先获取对方的公有密钥，通过算法进行处理，对方收到加密数据后，使用自己的私有密钥进行解密。

（2）数字证书

定义：数字证书就是互联网通讯中标志通讯各方身份的一串数字。

产生的原因：请求方如何确定它想要的公钥未经过第三方篡改，一定是从目标主机而来的？此时需要一个权威机构来发放密钥，来解决数字证书的安全问题。

颁发过程：首先用户要产生自己的密钥，和公有密钥一起交给认证中心，认证中心核实身份之后会将确认中心发给用户，会颁发一个数字证书，含有密钥信息。

---

2. 密钥

（1）定义

密钥是一种参数，它是在使用密码cipher算法过程中输入的参数。同一个明文在相同的密码算法和不同的密钥计算下会产生不同的密文。密钥才是决定加密数据是否安全的重要参数。

（2）明文到密文的加密过程

（3）密钥组成

• 对称密钥

  • 定义：又称为共享密钥加密，对称密钥在加密、解密过程中使用的密钥相同，常见对称加密算法有：DES、3DES、AES、RC5、RC6。
  • 优点：计算速度快；
  • 缺点：密钥需要在通讯的两端共享，存在安全性问题；

• 不对称密钥

  • 定义：又称为公开密钥加密。服务端会生成一对密钥，一个私钥保存在服务端，仅自己知道，另一个公钥可以自由发布供任何人使用。常见的是RSA算法。
  • 优点：无需在客户端和服务端之间共享密钥，只要私钥不发给任何用户，即使公钥在网络上被截获，也无法破解数据。

（4）RSA加密简单过程

• 服务端生成配对的公钥和私钥；
• 密钥保存在服务端，公钥发送给客户端；
• 客户端使用公钥加密明文传输给服务端；
• 服务端使用私钥解密密文得到明文。

---

3. 数字签名

首先思考一个问题：浏览器和服务器直接传输数据时，有可能被黑客篡改，如何保证数据安全性？需要引出此部分核心——数字签名。

（1）定义

数字签名是用于验证传输内容是否是真实服务器发送的数据，是否被篡改过，主要验证这两件事，是非对称加密的一种应用场景，但它是反过来用秘钥加密，通过与之配对的公钥解密。

（2）加密过程

• 第一步：查看上图，服务端将报文进行哈希处理后生成摘要信息，摘要信息使用私钥加密之后才会生成签名，而服务端将签名连同报文一起发送给客户端。

• 第二步：查看上图，客户端接收到数据后，把签名提取出来用公钥解密，如果能正常将Digest2 解密出来，即可确认是对方发的。
• 第三步：客户端把报文Text提取出来做同样的哈希出来，得到的摘要信息Digest1，再与之前解密出来的Digest2 对比。

---

---

---

四. HTTPS（TLS与SSL握手）

1. HTTP的缺点

在了解HTTP特点之后，不可忽视的是它的不足之处：

• 通信使用明文（不加密），内容可能被监听；
• 不验证通信方的身份，有可能遭遇伪装；
• 无法证明报文的完整性，有可能已遭篡改；

以上三个问题不仅在HTTP上出现，其它未加密的协议也存在这些问题。除此之外，还有其它的缺点。

（1）通信使用明文可能会被窃听

由于HTTP本身不具备加密功能，所以无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密，即HTTP报文使用明文的方式发送。

TCP/IP是可能被窃听的网络

按照TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。

加密处理防止被窃听

防止窃听保护信息的几种对策中，最为普及的就是加密技术，加密对象有以下几个：

• 通信的加密： HTTP协议中没有加密机制，可以通过SSL（Secure Socket Layer安全套接层）或TLS（Transport Layer Security安全传输层协议）的组合使用，加密HTTP的通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信。与SSL组合使用的HTTP被称为HTTPS。

• 内容的加密：对HTTP协议传输内容本身加密。客户端需要对HTTP报文进行加密处理后再发送请求。为了做到有效的内容加密，前提是客户端和服务器同时具备加密和解密机制。（该方法不同于SSL或TLS将整个通信线路加密处理，所以内容有篡改的风险，后续讲解）

（2）不验证通信方的身份可能遭遇伪装

在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求，服务器只有收到请求，不论是谁都返回响应，因此存在以下隐患：

• 无法确定请求发送至目标的Web服务器是否是真实返回响应的服务器。（可能是伪装的）
• 无法确定响应返回到客户端是否是真实接收响应的客户端。（可能是伪装的）
• 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器保存重要信息，只想发给特定用户通信的权限。
• 无法判定请求出处。
• 即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击。

查明对手的证书

虽然HTTP协议无法确定通信方，但是使用SSL可以。SSL不仅提供加密处理，还使用了一种被称为证书的手段，可用于确定方。

通过使用证书，来证明通信方就是意料中的服务器，这对使用者个人来讲减少了信息泄露的危险。另外客户端持有证书即可完成个人身份验证，可用于Web认证环节。

（3）无法证明报文完整性，可能已遭篡改

由于HTTP协议无法证明通信报文的完整性，即使请求或响应内容遭到篡改，也没有办法获悉。

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack）

如何防止篡改

虽然有使用HTTP协议确定报文完整性的方法，事实上并不可靠，常用的是MD5（单向函数生成的散列值）和SHA-1等散列值校验方法，及用来确认文件的数字签名方法。可惜的是如果MD5本身被改写，用户没有办法意识到。

为了有效防止以上这些弊端，需要使用到HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是非常困难的，因此通过和其他协议组合来实现此目标。

---

2. HTTPS = HTTP + 加密 + 认证 + 完整性保护

（1）定义

HTTPS并非是应用层的一种新协议，只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。通过在TCP和HTTP之间加入TLS来加密，由此保证数据传输的安全性。HTTPS就是身披SSL协议这串外壳的HTTP。

（2）SSL/TLS协议

SSL协议是一种安全传输协议，TLS是SSL v3.0的升级版。

（3）HTTPS层次图

查看HTTPS层次图，最底层是NetWork，依次往上是网络层、传输层、应用层。

传输层上面夹着TLS层，它就是安全传输协议在现实中的应用版，其中最上方的3个绿色小方框组成了TLS协议。上图类似于TCP/IP模型，只是多了一层TLS层，用来加密数据。

（4）HTTPS架构图

查看HTTPS架构图，其实HTTPS协议就是在HTTP基础上加上了加密、验证以及数据的保护。在使用HTTPS通信时，使用的是 https://

（注意：HTTPS并非是新协议，他只是HTTP通信接口中加了一个SSL协议）

在HTTPS通信时会先和SSL层建立通信，然后SSL层再和传输层中的TCP通信。所以HTTPS就是披了一层SSL外壳的HTTP协议

（5）HTTPS传输速度

SSL的慢可归于以下两点：一是通信慢，一是由于大量消耗CPU及内存等资源，导致处理速度变慢。

• 通信慢：同HTTP协议相比，网络负载会变慢，因为除去TCP连接、HTTP请求与响应外，还必须处理SSL、TSL通信，导致通信量的增加。
• SSL必须进行加密处理：在服务器端和客户端都要通过加密、解密进行数据的安全处理，因此从结果而言，比起HTTP会更多地消耗服务器和客户端的硬件资源，导致负载增强。

综合以上因素，只有在处理敏感信息时才使用HTTPS加密通信。

---

3. TLS与SSL握手过程

查看上图，TLS与SSL握手过程可以总结以下5个步骤：

（1）客户端发起请求

首先客户端会将它支持的协议版本、加密压缩算法，并生成一个随机数（握手过程的第一个随机数）一起传送给服务端。注意：此随机数与后续服务端产生的随机数会组成密钥。

（2）服务器回应

当服务端收到客户端 hello的请求后，会确定加密的协议算法，也会生成自己的一个随机数（握手过程的第二个随机数），连同证书一起发送给客户端。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

（3）客户端验证证书

当客户端再次回应时，首先对服务端发来的证书进行验证，验证完毕后会再次产生一个随机数（握手过程的第三个随机数），此随机数是使用证书中公钥加密的，通知服务端编码已改变、握手结束。

（4）生成密钥

服务端接收到密钥之后，用私钥对这加密的数据进行解密并验证，验证完毕后向客户端发出通知确认编码改变、握手结束。

（5）客户端发送数据

客户端收到服务端发来的通知确认后，可以和服务端进行HTTPS安全的消息通讯了。

注意

由于SSL协议在握手阶段使用的是非对称加密，一般是RSA加密算法，所以需知随机数是不能随意破解的，它是安全性的保证。

---

4. 再论TLS与SSL握手过程

以上第3点对TLS与SSL握手过程的总结适合新手初次学习，而此部分就正式地去介绍其细节，查看以下时序图：

(1)client_hello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息：

• 支持的最高TSL协议版本version；
• 客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验)；
• 支持的压缩算法；
• 扩展字段 extensions；
• 随机数 random_C（此过程的第一个随机数），用于后续的密钥的生成；

(2)server_hello + server_certificate + sever_hello_done

• server_hello：服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S（此过程的第二个随机数） 等，其中随机数用于后续的密钥协商;
• server_certificates： 服务器端配置对应的证书链，用于身份验证与密钥交换;
• server_hello_done：通知客户端 server_hello 信息发送结束;

(3)证书校验

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：

• 证书链的可信性 trusted certificate path，方法如前文所述;
• 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
• 有效期 expiry date，证书是否在有效时间范围;
• 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;

(4)client_key_exchange + change_cipher_spec + encrypted_handshake_message

• client_key_exchange：合法性验证通过之后，客户端计算产生随机数字 Pre-master（此过程的第三个随机数），并用证书公钥加密，发送给服务器。

此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥。

• change_cipher_spec：客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。

• encrypted_handshake_message：，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证。

(5) change_cipher_spec + encrypted_handshake_message

• 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥

enc_key=Fuc(random_C, random_S, Pre-Master)

• 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性。

• change_cipher_spec： 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信。

• encrypted_handshake_message： 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端。

(6)握手结束

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成。

(7)加密通信

开始使用协商密钥与算法进行加密通信。

注意：

服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证。

后续相关知识还有：为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。可查看以下链接。

此小节是借鉴于TLS/SSL握手过程，推荐查看。

---

5. 总结

HTTPS实际上就是在TCP层与HTTP层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。

---

---

---

若有错误，虚心指教～