http 和 https的区别，概念，工作流程

1、概念

这是一个CSDN的博客访问URL，https是协议，blog.csdn.net是域名。

补充URI和URL和URN的概念

原文：“http://web.jobbole.com/83452/#article-comment”

区别

首先我们要弄清楚一件事：URL和URN都是URI的子集。

换言之，URL和URN都是URI，但是URI不一定是URL或者URN。为了更好的理解这个概念，看下面这张图片。

通过下面的例子（源自 Wikipedia），我们可以很好地理解URN 和 URL之间的区别。如果是一个人，我们会想到他的姓名和住址。

URL类似于住址，它告诉你一种寻找目标的方式（在这个例子中，是通过街道地址找到一个人）。要知道，上述定义同时也是一个URI。

相对地，我们可以把一个人的名字看作是URN；因此可以用URN来唯一标识一个实体。由于可能存在同名（姓氏也相同）的情况，所以更准确地说，人名这个例子并不是十分恰当。更为恰当的是书籍的ISBN码和产品在系统内的序列号，尽管没有告诉你用什么方式或者到什么地方去找到目标，但是你有足够的信息来检索到它。

关于URL：

URL是URI的一种，不仅标识了Web 资源，还指定了操作或者获取方式，同时指出了主要访问机制和网络位置。
关于URN：

URN是URI的一种，用特定命名空间的名字标识资源。使用URN可以在不知道其网络位置及访问方式的情况下讨论资源。
现在，如果到Web上去看一下，你会找出很多例子，这比其他东西更容易让人困惑。我只展示一个例子，非常简单清楚地告诉你在互联网中URI 、URL和URN之间的不同。
我们一起来看下面这个虚构的例子。
这是一个URI：“http://bitpoetry.io/posts/hello.html#intro”
“http://”是定义如何访问资源的方式。
“bitpoetry.io/posts/hello.html”是资源存放的位置。
“#intro”是资源。
URL是URI的一个子集，告诉我们访问网络位置的方式。在我们的例子中，URL应该如下所示：
“http://bitpoetry.io/posts/hello.html”
URN是URI的子集，包括名字（给定的命名空间内），但是不包括访问方式，如下所示：
“bitpoetry.io/posts/hello.html#intro”
就是这样。现在你应该能够辨别出URL和URN之间的不同。

如果你忘记了这篇文章的内容，至少要记住一件事：URI可以被分为URL、URN或两者的组合。如果你一直使用URI这个术语，就不会有错。

---

网站的URL通常会分为两部分：通信协议和域名地址。

可以看到CSDN博客用的是https协议。与此类似的还有http协议

• http

  • 是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

    TCP：传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

  • 百度百科 HTTP

• https

  • 是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
  • SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。更多…
  • 百度百科 HTTPS

2、区别

HTTPS和HTTP的区别主要如下：

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

可以简单的理解为 https=http+ssl ，即http是超文本传输协议 ，https是超文本安全传输协议。百度百科也是这样说明定义的。可见二者的根本区别就是 安全

3、优缺点

• http的优点：

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

• http的缺点

  http协议是一种使用明文数据传输的网络协议。一直以来http协议都是最主流的网页协议，但是互联网发展到今天，http协议的明文传输会让用户存在一个非常大的安全隐患。

---

• https的优点：

  相比于http，https可以提供更加优质保密的信息，保证了用户数据的安全性和完整性，此外https同时也一定程度上保护了服务端，使用恶意攻击和伪装数据的成本大大提高。

• https的缺点

  • https的技术门槛较高，多数个人或者私人网站难以支撑，CA机构颁发的证书都是需要年费的，此外对接Https协议也需要额外的技术支持；
  • 目前来说大多数网站并不关心数据的安全性和保密性，其https最大的优点对它来说并不适用；
  • https加重了服务端的负担，相比于http其需要更多的资源来支撑，同时也降低了用户的访问速度；
  • 目前来说Http网站仍然大规模使用，在浏览器侧也没有特别大的差别，很多用户不关心的话根本不感知。

4、工作流程

• http：

  第一步：建立TCP/IP连接，客户端与服务器通过Socket三次握手进行连接

  第二步：客户端向服务端发起HTTP请求（例如：POST/login.html http/1.1）

  第三步：客户端发送请求头信息，请求内容，最后会发送一空白行，标示客户端请求完毕

  第四步：服务器做出应答，表示对于客户端请求的应答，例如：HTTP/1.1 200 OK

  第五步：服务器向客户端发送应答头信息

  第六步：服务器向客户端发送请求头信息后，也会发送一空白行，标示应答头信息发送完毕，接着就以Content-type要求的数据格式发送数据给客户端

  第七步：服务端关闭TCP连接，如果服务器或者客户端增Connection:keep-alive就表示客户端与服务器端继续保存连接，在下次请求时可以继续使用这次的连接

• https:

  第一步：客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

  第二步：Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

  第三步：客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

  第四步：客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

  第五步：Web服务器利用自己的私钥解密出会话密钥。

  第六步：Web服务器利用会话密钥加密与客户端之间的通信。
  
  总结：HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的 对称加密算法，但是协商对称加密算法的过程，需要使用 非对称加密算法 来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

5、https的通俗理解，以情景的模式理解https的工作原理

原文转自：http://blog.jobbole.com/110354/

摘要：本文尝试一步步还原HTTPS的设计过程，以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时，你可以尝试放下已有的对HTTPS的理解，这样更利于“还原”过程。

我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B：

如果我们要实现这个聊天软件，本文只考虑安全性问题，要实现

A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容

如何做到真正的安全？

这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？

我个人的理解是：

A与B通信的内容，有且只有A和B有能力看到通信的真正内容

好，问题域已经定义好了（现实中当然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。

题外话，但是只有这一种方法吗？我看未必，说不定在将来会出现一种物质打破当前世界的通信假设，实现真正意义上的保密。

对于A与B这样的简单通信模型，我们很容易做出选择：

这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。

只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。

但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：

如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？请读者思考21秒钟。?

答案是：Web服务器与每个客户端使用不同的对称加密算法：

如何确定对称加密算法

慢着，另一个问题来了，我们的服务器端怎么告诉客户端该使用哪种对称加密算法？

当然是通过协商。

但是，你协商的过程是没有加密的，还是会被中间人拦截。那我们再对这个协商过程进行对称加密就好了，那你对协商过程加密的加密还是没有加密，怎么办？再加密不就好了……好吧，进行鸡生蛋蛋生鸡的问题了。

如何对协商过程进行加密

新问题来了，如何对协商过程进行加密？密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。

好了，如何协商加密算法的问题，我们解决了：使用非对称加密算法进行对称加密算法协商过程。

这下，你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧？

协商什么加密算法

要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？

使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。

这下，你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。

如何得到公钥？

细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。

这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？

我能想到的方案只有这些：

方案1. 服务器端将公钥发送给每一个客户端

方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到

我们选择方案1，因为方案2又多了一次请求，还要另外处理公钥的放置问题。

公钥被调包了怎么办？又是一个鸡生蛋蛋生鸡问题？

但是方案1有个问题：如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？

我画了张图方便理解：

显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

使用第三方机构的公钥解决鸡生蛋蛋生鸡问题

公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。

如果让你来解决，你怎么解决？如果你了解过HTTPS，会知道使用数字证书来解决。但是你想过证书的本质是什么么？请放下你对HTTPS已有的知识，自己尝试找到解决方案。

我是这样解决的。既然服务器需要将公钥传给客户端，这个过程本身是不安全，那么我们为什么不对这个过程本身再加密一次？可是，你是使用对称加密，还是非对称加密？这下好了，我感觉又进了鸡生蛋蛋生鸡问题了。

问题的难点是如果我们选择直接将公钥传递给客户端的方案，我们始终无法解决公钥传递被中间人调包的问题。

所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。

下图就是我们设计的第一版“数字证书”，证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了：

如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。

话到此，我以为解决问题了。但是现实中HTTPS，还有一个数字签名的概念，我没法理解它的设计理由。

原来，我漏掉了一个场景：第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：

第三方机构向多家公司颁发证书的情况：

客户端能解密同一家第三机构颁发的所有证书：

最终导致其它持有同一家第三方机构证书的中间人可以进行调包：

数字签名，解决同一机构颁发的不同证书被篡改问题

要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？

只能放到客户端了。意思是，客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？

我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。

我们的客户端能不能采用这个机制呢？像这样：

可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地了。

客户端本地怎么验证证书呢？

客户端本地怎么验证证书呢？答案是证书本身就已经告诉客户端怎么验证证书的真伪。

也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。

同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。

这地方有些抽象，我们来个图帮助理解：

证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端：你使用MD5对证书的内容求值就可以得到一个证书编号。

当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过：

但是第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。

其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

题外话：如果浏览器和操作系统这道防线被破了，就没办法。想想当年自己装过的非常规XP系统，都害怕。

说到这里，想必大家已经知道上文所说的，证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。

CA如何颁发数字证书给服务器端的？

当我听到这个问题时，我误以为，我们的SERVER需要发网络请求到CA部门的服务器来拿这个证书。? 到底是我理解能力问题，还是。。

其实，问题应该是CA如何颁发给我们的网站管理员，而我们的管理员又如何将这个数字证书放到我们的服务器上。

我们如何向CA申请呢？每个CA机构都大同小异，我在网上找了一个：

拿到证书后，我们就可以将证书配置到自己的服务器上了。那么如何配置？这是具体细节了，留给大家google了。

也许我们需要整理一下思路

我们通过推算的方式尝试还原HTTPS的设计过程。这样，我们也就明白了为什么HTTPS比HTTP多那么多次的交互，为什么HTTPS的性能会差，以及找到HTTPS的性能优化点。

而上面一大堆工作都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方使用这个对称加密算法进行加密解密。

以下是一张HTTPS协议的真实交互图（从网上copy的，忘了从哪了，如果侵权麻烦告知）：