网络协议Http和Https

主要特点

1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
5、支持B/S及C/S模式。

 

请求报文的示例，如下：

响应报文结构 ：

 

HTTP 报文首部之首部字段

 

首部字段概述

HTTP 报文包含报文首部和报文主体，报文首部包含请求行（或状态行）和首部字段。
在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。使用首部字段是为了给客服端和服务器端提供报文主体大小、所使用的语言、认证信息等内容。
 

首部字段结构

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

另外，字段值对应单个 HTTP 首部字段可以有多个值。

当 HTTP 报文首部中出现了两个或以上具有相同首部字段名的首部字段时，这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，优先处理的顺序可能不同，结果可能并不一致。

 
 

首部字段类型

首部字段根据实际用途被分为以下4种类型：
 
 

通用首部字段（HTTP/1.1）

 
 

请求首部字段（HTTP/1.1）

 
 

响应首部字段（HTTP/1.1）

 
 

实体首部字段（HTTP/1.1）

 
 

为 Cookie 服务的首部字段

其他首部字段

HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上，会出现各种非标准的首部字段。以下是最为常用的首部字段。

X-Frame-Options：
X-Frame-Options: DENY 首部字段 X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。首部字段 X-Frame-Options 有以下两个可指定的字段值：
 

• DENY：拒绝；
• SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context）匹配时许可。（比如，当指定 http://sample.com/sample.html 页面为 SAMEORIGIN 时，那么 sample.com 上所有页面的 frame 都被允许可加载该页面，而 example.com 等其他域名的页面就不行了）。

X-XSS-Protection：
X-XSS-Protection: 1 首部字段 X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下:
 

• 0 ：将 XSS 过滤设置成无效状态
• 1 ：将 XSS 过滤设置成有效状态

DNT：
首部字段 DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下：
 

• 0 ：同意被追踪
• 1 ：拒绝被追踪

由于首部字段 DNT 的功能具备有效性，所以 Web 服务器需要对 DNT做对应的支持。

P3P：
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND 首部字段 P3P 属于 HTTP 响应首部，通过利用 P3P（The Platform for Privacy Preferences，在线隐私偏好平台）技术，可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

要进行 P3P 的设定，需按以下操作步骤进行：
 

• 步骤 1：创建 P3P 隐私
• 步骤 2：创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml
• 步骤 3：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中

 

HTTP通信机制是在一次完整的 HTTP 通信过程中，客户端与服务器之间将完成下列7个步骤：
 

• 1）建立 TCP 连接：在HTTP工作开始之前，客户端首先要通过网络与服务器建立连接，该连接是通过 TCP 来完成的，该协议与 IP 协议共同构建 Internet，即著名的 TCP/IP 协议族，因此 Internet 又被称作是 TCP/IP 网络。HTTP 是比 TCP 更高层次的应用层协议，根据规则，只有低层协议建立之后，才能进行高层协议的连接，因此，首先要建立 TCP 连接，一般 TCP 连接的端口号是80；
• 2）客户端向服务器发送请求命令：一旦建立了TCP连接，客户端就会向服务器发送请求命令；
  例如：GET/sample/hello.jsp HTTP/1.1；
• 3）客户端发送请求头信息：客户端发送其请求命令之后，还要以头信息的形式向服务器发送一些别的信息，之后客户端发送了一空白行来通知服务器，它已经结束了该头信息的发送；
• 4）服务器应答：客户端向服务器发出请求后，服务器会客户端返回响应；
  例如： HTTP/1.1 200 OK
  响应的第一部分是协议的版本号和响应状态码；
• 5）服务器返回响应头信息：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同响应向用户发送关于它自己的数据及被请求的文档；
• 6）服务器向客户端发送数据：服务器向客户端发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据；
• 7）服务器关闭 TCP 连接：一般情况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 连接，然后如果客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ，TCP 连接在发送后将仍然保持打开状态，于是，客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

 

通过请求和响应的交换达成通信:

应用 HTTP 协议时，必定是一端担任客户端角色，另一端担任服务器端角色。仅从一条通信线路来说，服务器端和客服端的角色是确定的。HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端在没有接收到请求之前不会发送响应。

 

HTTP 是不保存状态的协议:

HTTP 是一种无状态协议。协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。
可是随着 Web 的不断发展，我们的很多业务都需要对通信状态进行保存。于是我们引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

 

使用 Cookie 的状态管理:
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

 

请求 URI 定位资源:
HTTP 协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。

 

持久连接:
HTTP 协议的初始版本中，每进行一个 HTTP 通信都要断开一次 TCP 连接。比如使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的其他资源。因此，每次的请求都会造成无畏的 TCP 连接建立和断开，增加通信量的开销。
为了解决上述 TCP 连接的问题，HTTP/1.1 和部分 HTTP/1.0 想出了持久连接的方法。其特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。旨在建立一次 TCP 连接后进行多次请求和响应的交互。在 HTTP/1.1 中，所有的连接默认都是持久连接。

 

管线化:

HTTP管线化（英语：HTTP pipelining）是将多个HTTP请求（request）整批提交的技术，而在发送过程中不需先等待伺服端的回应。
持久连接使得多数请求以管线化方式发送成为可能。以前发送请求后需等待并接收到响应，才能发送下一个请求。管线化技术出现后，不用等待亦可发送下一个请求。这样就能做到同时并行发送多个请求，而不需要一个接一个地等待响应了。
比如，当请求一个包含多张图片的 HTML 页面时，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术要比持久连接速度更快。请求数越多，时间差就越明显。

 

 

 

必须要掌握的Https知识

HTTPS基础:

苹果已从去年开始强制新上线的APP必须使用HTTPS（详见《苹果即将强制实施 ATS，你的APP准备好切换到HTTPS了吗？》），谷歌的Chrome浏览器也已宣布不支持https的网络将被标记不“不安全”，做为开发者，我们能感觉到HTTPS越来越被重视，所以了解https也是必须的。

简单的说：Http + 加密 + 认证 + 完整性保护 = Https。

传统的Http协议是一种应用层的传输协议，Http直接与TCP协议通信。

其本身存在一些缺点：
 

• Http协议使用明文传输，容易遭到窃听；
• Http对于通信双方都没有进行身份验证，通信的双方无法确认对方是否是伪装的客户端或者服务端；
• Http对于传输内容的完整性没有确认的办法，往往容易在传输过程中被劫持篡改。

因此，在一些需要保证安全性的场景下，比如涉及到银行账户的请求时，Http无法抵御这些攻击。  Https则可以通过增加的SSL\TLS，支持对于通信内容的加密，以及对通信双方的身份进行验证。
 

Https的加密原理:

近代密码学中加密的方式主要有两类：
 

• 1）对称秘钥加密；
• 2）非对称秘钥加密。

对称秘钥加密是指加密与解密过程使用同一把秘钥。这种方式的优点是处理速度快，但是如何安全的从一方将秘钥传递到通信的另一方是一个问题。

非对称秘钥加密是指加密与解密使用两把不同的秘钥。这两把秘钥，一把叫公开秘钥，可以随意对外公开。一把叫私有秘钥，只用于本身持有。得到公开秘钥的客户端可以使用公开秘钥对传输内容进行加密，而只有私有秘钥持有者本身可以对公开秘钥加密的内容进行解密。这种方式克服了秘钥交换的问题，但是相对于对称秘钥加密的方式，处理速度较慢。

SSL\TLS的加密方式则是结合了两种加密方式的优点。首先采用非对称秘钥加密，将一个对称秘钥使用公开秘钥加密后传输到对方。对方使用私有秘钥解密，得到传输的对称秘钥。之后双方再使用对称秘钥进行通信。这样即解决了对称秘钥加密的秘钥传输问题，又利用了对称秘钥的高效率来进行通信内容的加密与解密。

7.3Https的认证:

SSL\TLS采用的混合加密的方式还是存在一个问题，即怎么样确保用于加密的公开秘钥确实是所期望的服务器所分发的呢？也许在收到公开秘钥时，这个公开秘钥已经被别人篡改了。因此，我们还需要对这个秘钥进行认证的能力，以确保我们通信的对方是我们所期望的对象。

目前的做法是使用由数字证书认证机构颁发的公开秘钥证书。服务器的运营人员可以向认证机构提出公开秘钥申请。认证机构在审核之后，会将公开秘钥与共钥证书绑定。服务器就可以将这个共钥证书下发给客户端，客户端在收到证书后，使用认证机构的公开秘钥进行验证。一旦验证成功，即可知道这个秘钥是可以信任的秘钥。
 

7.4Https小结:
Https的通信流程：

• 1）Client发起请求；
• 2）Server端响应请求，并在之后将证书发送至Client；
• 3）Client使用认证机构的共钥认证证书，并从证书中取出Server端共钥；
• 4）Client使用共钥加密一个随机秘钥，并传到Server；
• 5）Server使用私钥解密出随机秘钥；
• 6）通信双方使用随机秘钥最为对称秘钥进行加密解密。

 

HTTPS灵魂拷问

随着 HTTPS 建站的成本下降，现在大部分的网站都已经开始用上 HTTPS 协议。大家都知道 HTTPS 比 HTTP 安全，也听说过与 HTTPS 协议相关的概念有 SSL 、非对称加密、 CA证书等。

但对于以下灵魂三拷问可能就答不上了：
 

• 1）为什么用了 HTTPS 就是安全的？

HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实：HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

• 2）HTTPS 的底层原理如何实现？
• 3）用了 HTTPS 就一定安全吗？

 

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

 

① 证书验证阶段：
 

• 1）浏览器发起 HTTPS 请求；
• 2）服务端返回 HTTPS 证书；
• 3）客户端验证证书是否合法，如果不合法则提示告警。

② 数据传输阶段：
 

• 1）当证书验证合法后，在本地生成随机数；
• 2）通过公钥加密随机数，并把加密后的随机数传输到服务端；
• 3）服务端通过私钥对随机数进行解密；
• 4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

 

为什么数据传输是用对称加密？

首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。

另外：在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

 

基本概念

• CA(Certificate Authority)被称为证书授权中心，是数字证书发放和管理的机构。
• 根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。
• 数字证书颁发过程一般为：
  1. 用户首先产生自己的密钥对，
  2. 将公共密钥（公钥）及部分个人身份信息传送给认证中心
  3. 认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息

有4个概念一定要清楚：

CA根证书，CA证书

CA证书有两个作用：

1. 签发数字证书（用户找CA签发）
2. 校验数字证书（客户找CA校验收到的证书是否合法有效）

在SSL通信握手过程中，需要将公钥数字证书交给对方，对方如何对数字证书进行校验？就是要在找到签发此证书的CA证书及证书链，一直找到CA根证书。

 

数字证书

使用CA证书的私钥给用户生成的公钥签名，生成公钥数字签名证书。证书是为了防伪、防冒充的。

我们通常说的数字证书都是公钥数字证书：包含公钥、签发证书的CA证书信息、CA数字签名等数据。

要验证数字证书的真伪，就需要找到签发这个证书的CA证书，要验证CA证书的真伪则需要找到签发CA证书的CA证书，就这样一直找到根证书。

 

认证流程

https认证流程：

• 1、服务器生成一对密钥，私钥自己留着，公钥交给数字证书认证机构（CA）
• 2、CA进行审核，并用CA自己的私钥对服务器提供的公钥进行签名生成数字证书
• 3、将生成的数字证书部署到web服务器
• 4、client在https建立连接时，需要先从服务器获取数字证书，在本机找到数字证书的签发机构的CA的公钥（根证书）对数字证书进行验证，比对一致，说明该数字证书确实是CA颁发的（得此结论有一个前提就是：客户端的CA公钥确实是CA的公钥，即该CA的公钥与CA对服务器提供的公钥进行签名的私钥确实是一对。），而CA又作为权威机构保证该公钥的确是服务器端提供的，从而可以确认该证书中的公钥确实是合法服务器端提供的。

注：为保证第4步中提到的前提条件，CA的公钥必须要安全地转交给客户端（CA根证书必须先安装在客户端），因此，CA的公钥一般来说由浏览器开发商内置在浏览器或操作系统的内部。于是，该前提条件在各种信任机制上，基本保证成立。

 

为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。

“中间人攻击”的具体过程如下：

 

如上图所以，过程原理如下：
 

• 1）本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器；
• 2）中间人服务器返回中间人自己的证书；
• 3）客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输；
• 4）中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密；
• 5）中间人以客户端的请求内容再向正规网站发起请求；
• 6）因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据；
• 7）中间人凭借与正规网站建立的对称加密算法对内容进行解密；
• 8）中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输；
• 9）客户端通过与中间人建立的对称加密算法对返回结果数据进行解密。

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

浏览器是如何确保 CA 证书的合法性？

证书包含什么信息？

• 1）颁发机构信息；
• 2）公钥；
• 3）公司信息；
• 4）域名；
• 5）有效期；
• 6）指纹；
• 7）......

 

证书的合法性依据是什么？

• 1）首先：权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构；
• 2）另外：证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。

所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。
 

浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：
 

• 1）验证域名、有效期等信息是否正确：证书上都有包含这些信息，比较容易完成验证；
• 2）判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证（如下图所示）：
  
• 3）判断证书是否被篡改：需要与 CA 服务器进行校验；
• 4）判断证书是否已吊销：通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率。

总结:

Q: HTTPS 为什么安全？
A: 因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

Q: HTTPS 的传输过程是怎样的？
A: 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

Q: 为什么需要证书？
A: 防止”中间人“攻击，同时可以为网站提供身份证明。

Q: 使用 HTTPS 会被抓包吗？
A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

Q: HTTPS用的是对称加密还是非对称加密？
Q: HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。