Tip7 – 来一次痛快的 HTTP 之旅吧

前语

《图解 HTTP》这本书把我多年的散装网络给治好了，不像《计算机网络》那么单调，读起来非常的畅快，这篇文章算是一份笔记，记载了我觉得 ioser（不是 loser…）应该把握的关于网络的常识点，在结尾也做了一些补偿（因为书里没有讲的那么细，也是比较常见的面试题）。

看完这篇文章，你能够了解以下常识：

• HTTP 协议是什么，效果
• TCP、IP、DNS 的概念
• URI 和 URL 的区别
• Cookie 的效果
• 署理、网关、地道的概念
• HTTP 的缺陷
• HTTPS 的效果、原理
• HTTPS 的通讯机制
• SSL、TLS 的概念
• …

在文章的最终，补偿了关于以下常识点：

• TCP 的三次握手和四次挥手的进程及原因
• TCP 和 UDP 的差异
• SSL 和 TLS 的联系
• Charles 为什么能够抓到 HTTPS 的包

万字长文，字数有点多，可是读起来很轻松（dog head），让咱们开端。

一、了解 Web 及网络根底

平常咱们在阅读器中输入 URL 后，能够看到 Web 页面，这些 Web 页面并不是随便出来的，是 Web 阅读器依据地址栏中指定的 URL，从 Web 服务器端获取文件资源（resource）等信息，然后显现出 Web 页面。

咱们将 经过发送恳求获取服务器资源的 Web 阅读器等，称为 客户端。

客户端与服务器端之间的通讯，选用了一种叫做 HTTP（HyperText Transfer Protocol，超文本传输协议） 的协议作为标准。协议便是规矩的约好，能够说，Web 是树立在 HTTP 协议上通讯的。

TCP/IP

为了理解 HTTP，咱们需求先了解一下 TCP/IP 协议族。

一般运用的网络（包括互联网）是在 TCP/IP 协议族的根底上运作的，而 HTTP 归于它内部的一个子集。

计算机与网络设备要彼此通讯，两边就有必要依据相同的办法。比方，怎么探测到通讯方针、由哪一边先建议通讯、运用哪种言语进行通讯、怎样结束通讯等规矩都得完成确定，不同的硬件、操作体系之间的通讯，都需求一种规矩，而咱们就把这种规矩称为协议（protocol）。

TCP/IP 是互联网相关的各类协议族的总称。

分层办理

TCP/IP 协议族按层次分红 4 层：

• 运用层
• 传输层
• 网络层
• 数据链路层

运用层决议了向用户供给运用服务时通讯的活动，HTTP 协议也处于该层。

传输层对上层运用层，供给处于网络衔接中的两台计算机之间的数据传输，在传输层中有 TCP（Transmission Control Protocol，传输操控协议）和 UDP（User Data Protocol，用户数据报协议）。

网络层用来处理在网络上活动的数据包。数据包是网络传输的最小数据单位。

链路层用来处理衔接网络的硬件部分。

通讯传输流

运用 TCP/IP 协议族进行网络通讯时，会经过分层顺序与对方进行通讯。发送端从运用层往下走，接纳端则从链路层往上走。

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

这些把数据包装起来的做法称为封装。

IP、TCP 和 DNS

IP

IP（Internet Protocol）网际协议 坐落网络层，效果是 把各种数据包传送给对方。而要确保的确传送到对方那里，则需求满意各类条件，其间两个重要的条件是 IP地址 和 MAC地址（Media Access Control Address）。

有人会把 “IP” 和 “IP地址” 搞混，”IP” 其实是一种协议的名称。

IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定地址。IP 地址能够和 MAC 地址进行配对。IP 地址可变换，但 MAC 地址基本上不会更改。

在网络上，通讯的两边常常是经过多台计算机和网络设备中转才干衔接到对方，而在进行中转时，会运用下一站中转设备的 MAC 地址来搜索下一个中转方针。这时，会选用 ARP 协议（Address Resolution Protoco），是一种用以解析地址的协议，依据通讯方的 IP 地址就能够反查出对应的 MAC 地址。

没有人能够全面把握互联网中的传输状况，在抵达通讯方针前的中转进程中，那些计算机和路由器等网络设备只能获悉很粗略的传输道路。这种机制称为 路由挑选（routing）。

有点像快递公司的送货进程。想要寄快递的人，只需将自己的货品送到集散中心，就能够知道快递公 司是否肯收件发货，该快递公司的集散中心查看货品的送达地址，明 确下站该送往哪个区域的集散中心。接着，那个区域的集散中心自会 判别是否能送到对方的家中。

每个中转设备都只能把握一部分的传输道路信息。

TCP

TCP 坐落传输层，供给牢靠的字节省服务。

字节省服务（Byte Stream Service）是指，为了便利传输，将大块数据分割成以报文段（segment）为单位的数据包进行办理。

牢靠的传输服务指，能够把数据精确牢靠的传给对方。

为了精确无误的将数据送达方针处，TCP 协议选用了 三次握手（three-way handshaking） 策略。

• 发送端首要发送一个带有 SYN 的数据包给对方。
• 接纳端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达承认信息。
• 发送端再回传一个带有 ACK 标志的数据包，代表 “握手” 结束。

DNS

DNS（Domain Name System） 供给域名到 IP 地址之间的解析服务。 也是坐落运用层的协议。

如： 域名：www.hackr.jp

对应的

IP 地址：20X.189.105.112

一般用户运用主机名或域名来拜访对方的计算机，而计算机更擅长的是处理一长串数字，也便是 IP 地址，所以 DNS 服务应运而生，经过供给域名查找 IP 地址，或逆向经过 IP 地址反查域名。

各种协议与 HTTP 协议的联系

URI 和 URL

URL（Uniform Resource Locator，统一资源定位符），便是运用 Web 阅读器等拜访 Web 页面时需求输入的 网页地址。

比方 https://www.baidu.com/ 便是 URL。

URI 是 Uniform Resource Identifier 的缩写，便是由某个协议计划标明的资源的定位标识符。协议计划便是指拜访资源所运用的协议类型名称。

选用 HTTP 协议时，协议计划便是 http。

URI 用字符串标识某一互联网资源，而 URL 标明资源的地址（互联网上所在的位置），可见 URL 是 URI 的子集。

二、简略的 HTTP 协议

HTTP 协议用于客户端与服务器端之间的通讯。

恳求拜访 文本或图画等资源的一端称为 客户端，而 供给资源呼应 的一端称为 服务器端。

HTTP 协议规定，恳求从客户端发出，最终服务器端呼应该恳求并回来。换句话说，肯定是先从客户端开端树立通讯的，服务器端在没有接纳到恳求之前不会发送呼应。

HTTP 是一种不保存状况，即无状况（stateless）协议。

每当有新的恳求发送时，就会有对应的新呼应发生，协议自身不保存之前一切的恳求或呼应报文的信息。这是为了更快的处理许多事务，确保协议的可伸缩性，而特意把 HTTP 协议规划成如此简略的。

可是，跟着 Web 不断发展，因为无状况而导致事务处理变得扎手的状况增多了，比方坚持用户的登录状况等，所以引入了 Cookie 技能，稍后会讲。

HTTP 办法

• GET：用来恳求拜访已被 URI 辨认的资源
• POST：用来传输实体的主体
• PUT：传输文件（有安全性问题，一般不运用）
• HEAD：取得报文首部（与 GET 相同，仅仅不回来报文主体）
• DELETE：删除文件（与 PUT 相反，不安全，一般不运用）
• OPTIONS：查询针对恳求 URI 指定的资源支撑的办法（比方回来该资源支撑 GET 和 HEAD 办法）
• TRACE：让 Web 服务器将之前的通讯环回给客户端的办法，客户端能够查询发出去的恳求是怎样被加工/篡改的。（不怎么常用，而且容易引入 XST（Cross-Site Tracing，跨站追寻））
• CONNECT：要求在于署理服务器通讯时树立地道，完成用地道协议进行 TCP 通讯。首要运用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通讯内容加密后经网络地道传输

耐久衔接节省通讯量

在 HTTP 协议的初始版别中，每进行一次 HTTP 通讯就要断开一次 TCP 衔接。

跟着 HTTP 的遍及，现在一个 HTML 页面或许包括许多个资源。比方，在运用阅读器阅读一个包括多张图片的 HTML 页面时，在发送恳求拜访 HTML 页面资源的一起，也会恳求该 HTML 页面里包括的其他资源。因而，每次的恳求都会形成无谓的 TCP 衔接和断开，添加通讯量的开支。

为了处理这个问题，提出了 耐久衔接（HTTP Persistent Connections， 也称为 HTTP keep-alive 或 HTTP connection reuse） 办法，特点是，只需恣意一端没有明确提出断开衔接，则坚持 TCP 衔接状况。

耐久衔接使得大都恳求以管线化（pipelining）办法发送成为或许。从前发出恳求后需等候并收到呼应，才干发送下一个恳求。管线化技能能够完成 不同等候呼应也能够直接发送下一个恳求。

运用 Cookie 的状况办理

HTTP 是无状况协议，无状况协议的长处是能够削减服务器的 CPU 及内存资源的耗费，缺陷是有些事务场景没有状况办理的话处理起来很繁琐。

比方要求登录认证的 Web 页面，假如不进行状况办理，那每次跳转新页面不是要再次登录，便是要在每次的恳求报文中附加参数来办理登录状况。

为了保存无状况协议的长处，又处理状况办理的问题，所以引入了 Cookie 技能。Cookie 技能经过在恳求和呼应报文中写入 Cookie 信息来操控客户端的状况。

Cookie 会依据从服务器端发送的呼应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送恳求时，客户端会自动在恳求报文中参加 Cookie 值后发送出去。

服务器端发现客户端发送过来的 Cookie 后，会去查看究竟是从哪一个客户端发来的衔接恳求，然后对比服务器上的记载，最终得到之前的状况信息。

没有 Cookie 信息状况下的恳求：

存有 Cookie 信息状况的恳求：

三、HTTP 报文内的 HTTP 信息

用于 HTTP 协议交互的信息被称为 HTTP 报文。 客户端的 HTTP 报文叫做恳求报文，服务器端的叫做呼应报文。HTTP 报文自身是由多行（用 CR+LF 作换行符）数据构成的 字符串文本。

恳求报文和呼应报文的首部内容由以下数据组成：

• 恳求行

  • 包括用于恳求的办法，恳求 URI 和 HTTP 版别

• 状况行

  • 包括标明呼应成果的状况码，原因短语和 HTTP 版别

• 首部字段

  • 包括标明恳求和呼应的各种条件和特点的各类首部
  • 一般有 4 种首部
  • 通用首部
  • 恳求首部
  • 呼应首部
  • 实体首部

• 其他

  • 或许包括 HTTP 的 RFC 里未定义的首部（Cookie 等）

HTTP 在传输数据时能够依照数据原貌直接传输，但也能够在传输进程中经过编码进步传输速率。经过在传输时编码，能有用的处理许多的拜访恳求。可是，编码的操作需求计算机来完成，因而会耗费更多的 CPU 等资源。

编码进步传输功率

• 报文（message）

  • 是 HTTP 中通讯的基本单位，由 8 位组字节省组成，经过 HTTP 通讯传输

• 实体（entity）

  • 作为恳求或呼应的有用载荷数据（补偿项）被传输，其内容由实体首部和实体主体组成

HTTP 报文的主体用于传输恳求或呼应的实体主体。

一般，报文主体等于实体主体，只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体发生差异。

向待发送邮件内添加附件时，为了使邮件容量变小，咱们会先用 ZIP 压缩文件之后再添加附件发送。HTTP 协议中有一种被称为 内容编码 的功用也能进行类似的操作。

内容编码指明运用在实体内容上的编码格局，并坚持实体信息原样压缩。内容编码后的实体由客户端接纳并负责解码。

在 HTTP 通讯进程中，恳求的编码实体资源尚未悉数传输完成之前，阅读器无法显现恳求页面。在传输大容量数据时，经过把数据分割成多块，能够让阅读器逐步显现页面。

这种把实体主体分块的功用称为 分块传输编码。

发送多种数据的多部分方针调集

发送邮件时，咱们能够在邮件里写入文字并添加多份附件。这是因为选用了 MIME（Multipurpose Internet Mail Extensions， 多用途因特网邮件扩展） 机制，它允许邮件处理文本、图片、视频等多个不同类型的数据。

相应的，HTTP 协议中也选用了多部分方针调集，发送的一份报文主体内可含有多类型实体。一般是在图片或文本文件等上传时运用。

• multipart/from-data
  • Web 表单文件上传时运用
• multipart/byteranges
  • 呼应报文包括了多个规模的内容时运用

获取部分内容的规模恳求

以前，用户不能运用现在这种高速的宽带拜访互联网，其时，下载一个尺寸稍大的图片或文件就现已很吃力了。假如下载进程中遇到网络中止的状况，那就有必要从头开端。为了处理上述问题，需求一种 可恢复 的机制，所谓恢复是指 能从之前下载中止处恢复下载。

要完成该功用需求指定下载的实体规模，像这样，指定规模发送的恳求叫做规模恳求（Range Request）。

假如服务器端无法呼应规模恳求，则会回来状况码 200 OK 和完整的实体内容。

内容洽谈回来最合适的内容

当阅读器的默认言语为英文或中文，拜访相同 URI 的 Web 页面时，则会显现对应的英文版或中文版的 Web 页面，这样的机制称为 内容洽谈（Content Negotiation）。

内容洽谈机制是指客户端和服务器端就呼应的资源内容进行交涉，然后供给给客户端嘴和合适的资源。内容洽谈会以呼应资源的言语、字符集、编码办法等作为判别的基准。

四、回来成果的 HTTP 状况码

HTTP 状况码负责标明客户端 HTTP 恳求的回来成果、符号服务器端的处理是否正常，通知呈现的错误等作业。

（看到 5 最初的就能够找服务端了）。

五、与 HTTP 协作的 Web 服务器

一台 Web 服务器可树立多个独立域名的 Web 网站，也可作为通讯路径上的中转服务器进步传输功率。

HTTP/1.1 标准允许一台 HTTP 服务器树立多个 Web 站点。比方，供给 Web 保管服务（Web Hosting Service）的供货商，能够用一台服务器为多位客户服务，也能够以每位客户持有的域名运转各自不同的网站。这是因为运用了 虚拟主机（Virtual Host，又称虚拟服务器） 的功用。

即使物理层面只有一台服务器，但只需运用虚拟主机的功用，则能够设想已具有多台服务器。

在相同的 IP 地址下，因为虚拟主机能够寄存多个不同主机名和域名的 Web 网站，因而在发送 HTTP 恳求时，有必要在 Host 首部内完整指定主机名或域名 URI。

通讯数据转发程序：署理、网关、地道

• 署理

  • 一种有转发功用的运用程序，扮演了坐落服务器和客户端 “中心人” 的角色，接纳由客户端发送的恳求并转发给服务器，一起也接纳服务器回来的呼应并转发给客户端。

• 网关

  • 网关是转发其他服务器通讯数据的服务器，接纳从客户端发送来的恳求时，它会像自己具有资源的源服务器相同对恳求进行处理。有时客户端或许都不会察觉，自己的通讯方针是一个网关。

• 地道

  • 地道是在相隔甚远的客户端和服务器两者之间进行中转，并坚持两边通讯衔接的运用程序。

署理

署理服务器的基本行为便是接纳客户端发送的恳求后转发给其他服务器。署理不改动恳求 URI，会直接发送给前方持有资源的方针服务器。

每次经过署理服务器转发恳求或呼应时，会追加写入 Via 首部信息以符号出经过的主机信息。

运用署理服务器的理由有：

• 运用缓存技能削减网络带宽的流量
• 安排内部针对特定网站的拜访操控
• 以获取拜访日志为首要意图
• …

缓存署理（Caching Proxy）：预先将资源的副本（缓存）保存在署理服务器上。

透明署理：转发时，不对报文做任何加工。反之，对报文内容进行加工的署理被称为非透明署理。

网关

网关的作业机制和署理十分相似，而网关能使通讯线路上的服务器供给非 HTTP 协议服务。

运用网关能进步通讯的安全性，因为能够在客户端与网关之间的通讯线路上加密以确保衔接的安全。比方，网关能够衔接数据库，运用 SQL 语句查询数据。别的，在 Web 购物网站上进行信用卡结算时，网关能够和信用卡结算体系联动。

地道

地道可按要求树立起一条与其他服务器的通讯线路，到时运用 SSL 等加密手法进行通讯。地道的意图是确保客户端能与服务器进行安全的通讯。

地道自身不会去解析 HTTP 恳求。也便是说，恳求坚持原样中转给之后的服务器。地道会在通讯两边断开衔接时结束。

经过地道的传输，能够和远距离的服务器安全通讯。地道自身是透明的，客户端不用介意地道的存在。

保存资源的缓存

缓存是指署理服务器或客户端本地磁盘内保存的资源副本。运用缓存可削减对源服务器的拜访，因而也就节省了通讯流量和通讯时刻。

即使缓存服务器内有缓存，也不能确保每次都会回来对同资源的恳求，因为这联系到被缓存资源的 有用性 问题。

即使存在缓存，也会因为客户端的要求、缓存的有用期等要素，向源服务器承认资源的有用性。若判别缓存失效，缓存服务器将会再次从源服务器上获取 “新” 资源。

缓存不只能够存在于缓存服务器内，还能够存在客户端阅读器中。

别的，和缓存服务器相同的一点是，当判别缓存过期后，会向源服务器承认资源的有用性。若判别阅读器缓存失效，阅读器会再次恳求新资源。

六、HTTP 首部

HTTP 协议的恳求和呼应报文中必定包括 HTTP 首部，仅仅咱们平常在运用 Web 的进程中感受不到它。首部内容为客户端和服务器分别处理恳求和呼应供给所需求的信息。

运用首部字段是为了给阅读器和服务器供给报文主体巨细、所运用的言语、认证信息等内容。

4 种 HTTP 首部字段类型：

• 通用首部字段（General Header Fields）
  • 恳求报文和呼应报文都会运用的首部
• 恳求首部字段（Request Header Fields）
  • 客户端发送恳求时运用的首部，补偿了恳求的附加内容、客户端信息、呼应内容相关优先级等信息
• 呼应首部字段（Response Header Fields）
  • 服务端回来呼应报文时运用的首部，补偿了呼应的附加内容，也会要求客户端附加额定的内容信息
• 实体首部字段（Entity Header Fields）
  • 针对恳求报文和呼应报文的实体部分运用的首部，补偿了资源内容更新时刻等与实体有关的信息

HTTP/1.1 标准定义了如下 47 种首部。

通用首部字段：

恳求首部字段：

呼应首部字段：

实体首部字段：

为 Cookie 服务的首部字段

七、确保 Web 安全的 HTTPS

在 HTTP 协议中有或许存在信息偷听或身份假装等安全问题，运用 HTTPS 通讯机制能够有用防止这些问题。

HTTP 有许多长处，也有一些缺乏，首要体现为：

• 通讯运用明文（不加密），内容或许会被偷听
• 不验证通讯方的身份，因而有或许遭受假装
• 无法证明报文的完整性，所以有或许已遭篡改

这些问题不只在 HTTP 上呈现，其他未加密的协议中也会存在这类问题。

通讯运用明文或许被偷听

因为 HTTP 自身不具有加密的功用，所以也无法做到对通讯全体（运用 HTTP 协议通讯的恳求和呼应的内容）进行加密。

互联网上的任何旮旯都存在通讯内容被偷听的危险。

偷听相同段上的通讯并非难事，只需求收集在互联网上活动的数据包（帧）就行了。关于收集来的数据包的解析作业，可交给那些抓包（Packet Capture）或嗅探器（Sniffer）东西。

在现在大家正在研究的怎么防止偷听维护信息的几种对策中，最为遍及的便是加密技能，加密的方针能够有这么几个：

• 通讯的加密
  • 经过和 SSL 或 TLS 的组合运用，加密 HTTP 的通讯内容
  • 用 SSL 树立安全的通讯线路之后，就能够在这条线路上进行 HTTP 通讯了，与 SSL 组合运用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

• 内容的加密
  • 把 HTTP 报文里所含的内容进行加密处理
  • 这种状况下，客户端需求对 HTTP 报文进行加密处理后再发送恳求
  • 为了做到有用的内容加密，条件是要求客户端和服务器一起具有加密和解密机制
  • 因为该办法不同于 SSL 或 TLS 将整个通讯线路加密处理，所以内容仍有被篡改的危险

不验证通讯方的身份就或许遭受假装

HTTP 协议的完成自身非常简略，不论是谁发送过来的恳求都会回来呼应，因而不承认通讯方，会存在以下各种危险：

• 无法确定服务器是否是假装的 Web 服务
• 无法确定客户端是否是假装的客户端
• 无法确定正在通讯的两边是否已具有拜访权限
• 无法判定恳求是来自何方、出自谁手
• 即使是无含义的恳求也会照单全收，无法阻止海量恳求下的 DoS 进犯（Denial of Service，拒绝服务进犯）

尽管运用 HTTP 协议无法确定通讯方，但假如运用 SSL 则能够。SSL 不只供给加密处理，而且还运用了一种被称为证书的手法，可用于确定通讯方。

证书由值得信赖的第三方组织颁布，用以证明服务器和客户端是实践存在的。别的，伪造证书从技能视点来说是异常困难的一件事。所以只需能够承认通讯方（服务器或客户端）持有的证书，即可判别通讯方的实在意图。

无法证明报文完整性，或许已遭篡改

所谓完整性是指信息的精确度，若无法证明其完整性，一般也就意味着无法判别信息是否精确。

像这样，恳求或呼应在传输途中，遭进犯者阻拦并篡改内容的进犯称为中心人进犯（Man-in-the-Middle attack，MITM）。

为了防止这些坏处，有必要运用 HTTPS。SSL 供给认证和加密处理及摘要功用。仅靠 HTTP 确保完整性是非常困难的，因而经过和其他协议组合来完成这个方针。

HTTP + 加密 + 认证 + 完整性维护 = HTTPS

HTTPS 并非是运用层的一种新协议，仅仅 HTTP 通讯接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议替代罢了。

一般，HTTP 直接和 TCP 通讯。当运用 SSL 时，则演变成先和 SSL 通讯，再由 SSL 和 TCP 通讯了。简言之，所谓 HTTPS，其实便是身披 SSL 协议这层外壳的 HTTP。

在选用 SSL 后，HTTP 就具有了 HTTPS 的加密、证书和完整性维护这些功用。

SSL 是 独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运转在运用程的 SMTP 和 Telnet 等协议均可合作 SSL 协议运用。能够说 SSL 是当今世界上运用最为广泛的网络安全技能。

彼此交流密钥的揭露密钥加密技能

SSL 选用一种叫做 揭露密钥加密（Public-key cryptography） 的加密处理办法。

近代的加密办法中加密算法是揭露的，而密钥却是保密的。经过这种办法得以坚持加密办法的安全。

加密和解密都会用到密钥，没有密钥就无法对暗码解密，反过来说，任何人只需持有密钥就能解密了，假如密钥被进犯者得到，那加密也就失去了含义。

加密和解密同用一个密钥的办法称为同享加密（Common key crypto system），也被叫做对称密钥加密。

以同享密钥办法加密时有必要将密钥也发给对方，可究竟怎样才干安全的转交？在互联网上转发密钥时，假如通讯被监听那么密钥就或许会落入进犯者之手，一起也就失去了加密的含义。别的还得设法安全的保管接纳到的密钥。

发送密钥就有被偷听的危险，但不发送，对方就不能解密。再说，密钥若能够安全发送，那数据也应该能安全送达。

揭露密钥加密办法很好的处理了同享密钥加密的困难。

揭露密钥加密运用一对非对称的密钥，一把叫做私有密钥（private key），另一把叫做揭露密钥（public key）。 望文生义，私有密钥不能让其他任何人知道，而揭露密钥则能够随意发布，任何人都能够取得。

运用揭露密钥加密办法，发送密文的一方运用对方的揭露密钥进行加密处理，对方收到被加密的信息后，再运用自己的私有密钥进行解密。运用这种办法，不需求发送用来解密的私有密钥，也不必担心密钥被进犯者偷听而盗走。

别的，要想依据密钥和揭露密钥，恢复到信息原文是异常困难的，因为解密进程便是在对离散对数进行求值，这并非垂手可得就能办到。退一步讲，假如能对一个非常大的证书做到快速的因式分解，那么暗码破解仍是有希望的，但就现在的计数来看是不太实践的。

HTTPS 选用同享密钥加密和揭露密钥加密两者并用的混合加密机制。若只考虑完成安全交流，那么仅运用揭露密钥加密来通讯就好了，可是揭露密钥加密比同享密钥加密的处理速度要慢。

所以应充分运用两者各自的优势，在交流密钥环节运用揭露密钥加密办法确保安全，之后的树立通讯交流报文阶段则运用同享密钥加密办法确保功率。

遗憾的是，揭露密钥加密办法仍是存在一些问题的，那便是 无法证明揭露密钥自身便是名副其实的揭露密钥。比方，正准备和某台服务器树立揭露密钥加密办法下的通讯时，怎么证明收到的揭露密钥便是本来料想的那台服务器发行的揭露密钥。或许在揭露密钥传输途中，实在的揭露密钥现已被进犯者替换掉了。

为了处理上述问题，能够运用由 数字证书认证组织（CA,Certificate Authority） 和其相关机关颁布的 揭露密钥证书。

数字证书认证组织处于客户端与服务器两边都信赖的第三方组织的立场上。

数字证书认证组织的事务流程：

1. 服务器的运营人员向数字证书认证组织提出揭露密钥的恳求

2. 数字证书认证组织在判明出恳求者的身份之后，会用自己的私有密钥对已恳求的揭露密钥做数字签名，将其和公钥证书绑定，并颁布给服务端

3. 服务器会将这份由数字证书认证组织颁布的公钥证书发送给客户端

4. 接到证书的客户端可运用数字证书认证组织的揭露密钥，对那张证书上的数字签名进行认证，一旦验证经过，客户端便可明确两件事：

   • 认证服务器的揭露密钥是实在有用的数字证书认证组织
   • 服务器的揭露密钥是值得信赖的

5. 运用服务器的揭露密钥对报文加密后发送

6. 服务器运用私有密钥对报文进行解密

此处认证机关的揭露密钥有必要安全的转交给客户端，运用通讯办法时，怎么安全转交是一件很困难的事。因而，大都阅读器开发商发布版别时，会 事先在内部植入 常用认证机关的揭露密钥。

证书的一个效果是用来证明通讯一方的服务器是否标准，别的一个效果是可承认服务器背后运营的企业是否实在存在，具有该特性的证书便是 EV SSL 证书（Extended Validation SSL Certificate）。

客户端证书

HTTPS 中还能够运用客户端证书，以客户端证书进行客户端认证，证明服务器正在通讯的对方是预料之内的客户端，其效果跟服务器证书千篇一律。

但客户端仍存在几处问题点：

• 证书的获取及发布

  • 想获取证书时，用户得自行装置客户端证书。因为客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用
  • 别的，要让常识层次不同的用户们自行装置证书，这件事自身也充满了各种挑战

• 客户端证书只能用来证明客户端实践存在，而不能证明用户自己的实在有用性。也便是说，只需取得了装置有客户端证书的计算机的运用权限，也就意味着一起具有了客户端证书的运用权限

现状是，安全性极高的认证组织可颁布客户端证书但仅用于特别用途的事务，比方那些可支撑客户端证书支付费用的事务。

例如，银行的网上银行就选用了客户端证书，在登录网银时不只需求用户承认输入 ID 和暗码，还会要求用户的客户端证书，以承认用户是否从特定的终端拜访网银。

由自认证组织颁布的证书称为自签名证书

独立构建的认证组织叫做自认证组织，由自认证组织颁布的 “无用” 证书也被戏称为自签名证书。

阅读器拜访该服务器时，会显现 “无法承认衔接安全性” 或 “该网站的安全证书存在问题” 等正告信息。

由自认证组织颁布的服务器证书之所以不起效果，是因为它无法消除假装的或许性。自认证组织能够发生的效果顶多便是自己对外声称 “我是 oo” 的程度。即使选用自签名证书，经过 SSL 加密之后，或许偶然还会看见通讯处在安全状况的提示，可那也是有问题的。因为就算加密通讯，也不能排除正在和现已过假装的加服务器坚持通讯。

中级认证组织

大都阅读器会预先植入备受信赖的认证组织的证书，但也有一小部分阅读器会植入中级认证组织的证书。

关于中级认证组织办法的服务器证书，某些阅读器会以正规的证书来对待，可有的阅读器会作为自签名证书。

HTTPS 的安全通讯机制

为了更好的理解 HTTPS，咱们来观察一下 HTTPS 的通讯步骤：

1. 客户端经过发送 Client Hello 报文开端 SSL 通讯。报文中包括客户端支撑的 SSL 指定版别、加密组件（Cipher Suite）列表（所运用的加密算法及密钥长度等）。
2. 服务器可进行 SSL 通讯时，会以 Server Hello 报文作为应对。和客户端相同，在报文中包括 SSL 版别以及加密组件。服务器的加密组件内容是从接纳到的客户端加密组件内筛选出来的。
3. 之后服务器发送 Certificate 报文，报文中包括揭露密钥证书。
4. 最终服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手洽谈部分结束。
5. SSL 第一个握手结束之后，客户端以 Cline 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 报文

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

HTTPS 存在的问题

HTTPS 也存在一些问题，那便是当运用 SSL 时，它的处理速度会变慢。它的慢分两种：

• 通讯慢
  • 和运用 HTTP 相比，网络负载或许会变慢 2 到 100 倍。除去和 TCP 衔接、发送 HTTP 恳求/呼应 以外，还有必要进行 SSL 通讯，因而全体上处理通讯量不可防止会添加。
• 耗费许多 CPU 及内存等资源，导致处理速度慢
  • SSL 有必要进行加密处理。在服务器和客户端都需求进行加密和解密的运算处理。因而从成果上来讲，比起 HTTP 会更多的耗费服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的处理计划，咱们会运用 SSL 加速器这种（专用服务器）硬件来改进该问题。该硬件为 SSL 通讯专用硬件，相对软件来说，能够进步数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL 加速器的成效，以分管负载。

为什么不一向运用 HTTPS？

1. 加密通讯会耗费更多的 CPU 及内存资源
2. 得买证书，证书得花钱

八、承认拜访用户身份的认证

计算机自身无法判别坐在显现器前的运用者的身份。为了弄清楚是谁在拜访服务，就得让对方的客户端自报家门。

为了承认是自己真的具有拜访体系的权限，就需求核对 “登录者自己才知道的信息”、”登录者自己才会有的信息”。核对的信息一般是指以下这些：

• 暗码
• 动态令牌
• 数字证书
• 生物认证
• IC 卡等

可是，即使对方是冒充的用户，只需能经过用户验证，那么计算机就会默认是出自自己的行为。因而，掌控机密信息的绝不能让别人得到，更不能容易的就被破解出来。

HTTP 运用的认证办法：

• BASIC 认证（基本认证）
  • 运用 Base64 对用户 ID 和暗码进行编码后传输，可是不是加密处理，容易被解码
  • 运用上不行灵敏，且达不到大都 Web 网站希望的安全性等级，因而它并不常用
• DIGEST 认证（摘要认证）
  • 供给防止暗码被偷听的维护机制，但并不存在防止用户假装的维护机制
  • 与 BASIC 认证相同，运用上不灵敏，也仍达不到大都 Web 网站对高度安全等级的寻求标准，适用规模有限
• SSL 客户端认证
  • 一般会和 FormBase 认证组合形成一种双要素认证，便是指，认证进程中不只需求暗码这一个要素，还需求恳求认证者供给其他持有信息
  • 需求用到客户端证书，需求支付一定费用才干运用
• FormBase 认证（依据表单认证）
  • 客户端会向服务器上的 Web 运用程序发送登录信息（Credential），按登录信息的验证成果认证。
  • 可是表单认证不具有一起标准标准，在每个 Web 网站都会有各不相同的完成办法。在表单认证的完成中存在问题的 Web 网站也是层出不穷。

依据表单认证的标准标准尚未有定论，一般会用 Cookie 来办理 Session（会话）。

依据表单认证自身是经过服务器端的 Web 运用，将客户端发送过来的用户 ID 和暗码与之前登录过的信息做匹配来进行认证的。

但 HTTP 是无状况协议，因罢了认证成功的用户状况无法经过协议层面保存下来，所以该用户下次拜访时，也无法将其和其他用户区分开来。所以咱们运用 Cookie 来办理 Session，以补偿 HTTP 协议中不存在的状况办理功用。

1. 客户端把用户 ID 和暗码等登录信息放入报文的实体部分，一般是以 POST 办法把恳求发送给服务器。而这时，会运用 HTTPS 通讯来进行 HTML 表单画面的显现和用户输入数据的发送。
2. 服务器会发放用以辨认用户的 Session ID。经过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状况与 Session ID 绑定跋文载在服务器端。
3. 客户端接纳到从服务器端发来 Session ID 后，会将其作为 Cookie 保存在本地。下次向服务器发送恳求时，阅读器会自动发送 Cookie，所以 Session ID 也随之发送到服务器。服务器可经过验证接纳到的 Session ID 辨认用户和其认证状况。

你能够把 Session ID 幻想成一种用以区分不同用户的等位号。

假如 Session ID 被第三方盗走，对方就能够假装成你的身份进行恶意操作了。因而有必要防止 Session ID 被盗，或被猜出。

一种安全的保存办法是，先运用给暗码加盐（salt）的办法添加则外信息，再运用散列（hash）函数计算出散列值后保存。可是咱们也常常看到直接保存明文暗码的做法，而这样的做法具有导致暗码泄露的危险。

九、依据 HTTP 的功用追加协议

尽管 HTTP 协议既简略又便捷，但跟着时代的发展，其功用运用上绰绰有余的疲态现已凸显。

HTTP 功用上的缺乏可经过创立一套全新的协议来补偿。可是现在依据 HTTP 的 Web 阅读器的运用环境已遍布全球，因而无法完全抛弃 HTTP。有一些新协议的规矩是依据 HTTP 的，并在此根底上添加了新的功用。

在 Facebook 和 Twitter 等 SNS 网站上，几乎能够实时观察到海量用户揭露发布的内容，Web 网站为了保存这些新增内容，在很短的时刻内就会发生许多的内容更新。

为了尽或许实时的显现这些更新的内容，服务器上一有内容更新，就需求直接把这些内容反馈到客户端的界面上。尽管看起来挺简略的，但 HTTP 却无法妥善的处理好这项使命。

运用 HTTP 协议探知服务器上是否有内容更新，就有必要频繁的从客户端到服务器端进行承认。假如服务器上没有内容更新，那么就会发生徒劳的通讯。

若想在现有 Web 完成所需的功用，以下 HTTP 标准就会称为瓶颈：

• 一条衔接只可发送一个恳求
• 恳求只能从客户端开端，客户端不能够接纳除了呼应以外的指令
• 恳求/呼应 首部未经压缩就发送，首部信息越多推迟越大
• 发送冗长的首部，每次相互发送相同的首部形成的浪费较多
• 可恣意挑选数据压缩格局，非强制压缩发送

运用阅读器进行全双工通讯的 WebSocket

其实便是咱们所说的长链接。

一旦 Web 服务器与客户端之间树立起 WebSocket 协议的通讯衔接，之后所有的通讯都依托这个专用协议进行。通讯进程中可相互发送 JSON、XML、HTML 或图片等恣意格局的数据。

由所以树立在 HTTP 根底上的协议，因而衔接的建议方仍是客户端，而一旦树立 WebSocket 通讯衔接，不论是服务器仍是客户端，恣意一方都可直接向对方发送报文。

WebSocket 的首要特点：

• 推送功用
  • 服务器可直接发送数据到客户端
• 削减通讯量
  • 树立之后一向坚持在衔接状况，WebSocket 的首部信息也很小

十、构建 Web 内容的技能

HTML

Web 页面几乎全由 HTML 构建。

HTML（HyperText Markup Language，超文本符号言语）是为了发送 Web 上的超文本（Hypertext）而开发的符号言语。超文本是一种文档体系，可将文档中恣意位置的信息与其他信息（文本或图片等）树立关联，即超链接文本。符号言语是指经过在文档的某部分交叉特别的字符串标签，用来润饰文档的言语。咱们把呈现在 HTML 文档里的这种特别字符串叫做 HTML 标签（Tag）。

平常咱们阅读的 Web 页面几乎满是运用 HTML 携程的。由 HTML 构成的文档经过阅读器的解析、渲染后，呈现出来的成果便是 Web 页面。

CSS（Cascading Style Sheets，层叠样式表）能够指定怎么展示 HTML 内的各种元素，归于样式表标准之一。即使是相同的 HTML 文档，经过改动运用的 CSS，用阅读器看到的页面也会随之改动。CSS 的理念便是让文档的结构和规划别离，抵达解耦的意图。

动态 HTML

所谓动态 HTML（Dynamic HTML），是指用客户端脚本言语将静态的 HTML 内容编程动态的技能的总称。

动态 HTML 技能是经过调用客户端脚本言语 JavaScript，完成对 HTML 的 Web 页面的动态改造。运用 DOM（Document Object Model，文档方针模型）可指定于发生动态变化的 HTML 元素。

DOM 是用以操作 HTML 文档和 XML 文档的 API。运用 DOM 能够将 HTML 内的元素作为方针操作，如取出元素内的字符串、改动哪个 CSS 的特点等，使页面的规划发生变化。

XML（eXtensible Markup Language，可扩展符号言语）是一种可按方针进行扩展的通用符号言语。旨在经过运用 XML，使互联网数据同享变得更容易。

从 XML 文档中读取数据比起 HTML 更为简略。因为 XML 的结构基本上都是用标签分割而成的树形结构，因而经过语法分析器（Parser）的解析功用解析 XML 结构并取出数据元素，可更容易的对数据进行读取。

RSS（简易信息聚合，也叫聚合内容）和 Atom 都是发布新闻或博客日志等更新信息文档的格局的总称。两者都用到了 XML。

JSON（JavaScript Object Notation）是一种以 JavaScript（ECMAScript）的方针标明法为根底的轻量级数据符号言语。能够处理的数据类型有 false/null/true/数组/数字/字符串，这 7 种类型。

JSON 让数据更轻更朴实，而且 JSON 的字符串形式可被 JavaScript 容易的读入。最初合作 XML 运用的 Ajax 技能也让 JSON 的运用变得更为广泛。别的，其他各种编程言语也供给丰厚的库类，以抵达简便操作 JSON 的意图。

跋文和补偿

还有一章是关于 Web 的进犯技能的，这儿就不提了，感兴趣的能够去看原书。

别的做一点补偿，一般咱们项目中并不需求去处理 HTTPS 衔接相关的东西，是因为网络通讯层现已帮咱们做了这个事情，比方 AFN，这些第三方类库现已帮咱们处理好了。

苹果现已封装了HTTPS衔接的树立、数据的加密解密功用，咱们直接能够拜访https网站的，但苹果并没有验证证书是否合法，无法防止中心人进犯。要做到实在安全通讯，需求咱们手动去验证服务端回来的证书。AFNetwork中的AFSecurityPolicy模块首要是用来验证HTTPS恳求时证书是否正确。AFSecurityPolicy封装了证书验证的进程，让用户能够容易运用，除了去体系信赖CA组织列表验证，还支撑SSLPinning办法的验证。

TCP 的三次握手和四次挥手

三次握手

首要来看三次握手：

TCP 三次握手，其实便是树立了一个 TCP 衔接，客户端与服务器交互需求 3 个数据包。握手的首要效果便是为了承认两边的接纳和发送才干是否正常、初始序列号、交流窗口巨细以及 MSS 等信息。

• 第一次握手
  • 客户端发送 SYN 报文，并进入 SYN_SENT 状况，等候服务器的承认
• 第2次握手
  • 服务器收到 SYN 报文，需求给客户端发送 ACK 承认报文，一起服务器也要向客户端发送一个 SYN 报文，所以也便是向客户端发送 SYN + ACK 报文，此刻服务端进入 SYN_RCVD 状况
• 第三次握手
  • 客户端收到 SYN + ACK 报文，向服务器发送承认包，客户端进入 ESTABLISHED 状况。待服务器收到客户端发送的 ACK 包也会进入 ESTABLISHED 状况

TCP 三次握手，其实便是 TCP 运用在发送数据前，经过 TCP 协议跟通讯两边洽谈好衔接信息，树立起 TCP 的衔接联系。

为什么需求三次握手？二次不行吗？

TCP 树立衔接之前，需求承认的是客户端与服务器两边的手包和发包的才干。

1. 第一次握手
   • 客户端发送网络包，服务端收到了。服务端能够得出结论：客户端的发送才干，服务端的接纳才干是正常的。
2. 第2次握手
   • 服务端发包，客户端收到了。客户端就能够得出结论：服务的接纳、发送才干，客户端的接纳、发送才干是正常。不过此刻服务端并不能承认客户端的接纳才干是否正常。
3. 第三次握手
   • 客户端发包，服务端收到了。服务端能够得出结论：客户端的接纳、发送才干正常，服务端自己的发送、接纳才干也正常。

所以需求三次握手才干承认两边的 接纳 与 发送 才干是否正常。

四次挥手

• 第一次挥手
  • 客户端建议 FIN 包（FIN = 1），客户端进入 FIN_WAIT_1 状况。
• 第2次挥手
  • 服务端收到 FIN 包，发出承认包 ACK，服务端进入了 CLOSE_WAIT 状况。这个时分客户端现已没有数据要发送了，不过服务端有数据发送的话，客户端依然需求接纳。客户端接纳到服务器发送的 ACK 之后，进入了 FIN_WAIT_2 状况。
• 第三次挥手
  • 服务端数据发送结束后，向客户端发送 FIN 包，服务端此刻进入了 LAST_ACK 状况
• 第四次挥手
  • 客户端收到服务端的 FIN 包后，发出承认包，此刻客户端就进入了 TIME_WAIT 状况。留意此刻 TCP 衔接还没有开释，有必要经过 2*MSL 后，才进入 CLOSE 状况，能够看出服务器结束 TCP 衔接的时刻要比客户端早一些

为什么树立只需求三次握手，封闭时却需求四次挥手？

其实在 TCP 三次握手的时分，接纳端发送的 SYN+ACK 的包是将一个 ACK 和一个 SYN 合并到一个包中，所以削减了一次包的发送，三次就完成了握手。

可是关于四次握手，因为 TCP 是全双工通讯，在主动封闭方发送 FIN 包后，接纳端或许还需求发送数据，不能立即封闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先承认 ACK，然后服务端等无需发送数据时再发送 FIN 包，所以四次挥手时有必要是进行四次数据包的交互。

为什么 TIME_WAIT 状况需求经过 2*MSL 才干回来到 CLOSE 状况？

MSL 指的是报文在网络中传输的最大生存时刻。在客户端发送对服务端的 FIN 的承认包 ACK 后，这个 ACK 包有或许是不可达的，服务端假如收不到 ACK 的话就需求从头发送 FIN 包。

所以客户端发送 ACK 后需求留出 2*MSL 时刻（ACK 抵达服务器 + 服务器发送 FIN 重传包，一来一回）等候承认服务端的确收到了 ACK 包。

也便是说客户端假如等候 2MSL 时刻也没有收到服务端的重传包 FIN，说明能够承认服务器现已收到客户端发送的 ACK。

还有第 2 个理由，防止新旧衔接混淆。

在客户端发送完最终一个 ACK 报文段后，在经过 2MSL 时刻，就能够使本衔接持续的时刻内所发生的所有报文都从网络中消失，使下一个新的衔接中不会呈现这种旧的衔接恳求报文。

有些自作主张的路由器会缓存 IP 数据包，假如衔接重用了，那么这些推迟收到的包就有或许会跟新衔接混在一起。

TCP 和 UDP

差异：

• 衔接性
  • TCP 是面向衔接的协议，在收发数据前有必要和对方树立牢靠的衔接。
  • UDP 是一个面向无衔接的协议，数据传输前，源端和终端不树立衔接
• 牢靠性
  • TCP 供给牢靠交给的服务，传输进程中选用许多办法确保在衔接上供给牢靠的传输服务，如编号与承认，流量操控、计时器等，确保数据无差错，不丢失，不重复且按序抵达
  • UDP 运用尽或许最大努力交给，但不确保牢靠交给
• 报文首部
  • TCP 报文首部有 20 个字节，额定开支大
  • UDP 首部只有 8 个字节，标题短，开支小
  • TCP 协议面向字节省，将运用层报文当作一串无结构的字节省，分解为多个 TCP 报文段传输后，介意图站从头装配
  • UDP 协议面向报文，不拆分运用层报文，只保存报文边界，一次发送一个报文，接纳方去除报文首部后，原封不动的将报文交给上层运用
• 吞吐量
  • TCP 拥塞操控、流量操控、重传机制、滑动窗口等机制确保传输质量
  • UDP 没有
• 双工性
  • TCP 只能点对点全双工通讯
  • UDP 支撑1对1、一对多、多对一和多对多交互通讯

SSL 和 TLS

TLS 实践上是 SSL 的更新版别，它修正了早期 SSL 协议中的一些安全漏洞。

• SSL 1.0 – 因为安全问题从未揭露发布
• SSL 2.0 – 1995 年发布，2011 年弃用，存在已知的安全问题
• SSL 3.0 – 1996 年发布，2015 年弃用，存在已知的安全问题
• TLS 1.0 – 1999 年作为 SSL 3.0 的升级发布，计划在 2020 年弃用
• TLS 1.2 – 2008 年发布
• TLS 1.3 – 2018 年发布

关于抓包东西能够抓取 HTTPS 通讯内容

这儿咱们以 Charles 为例，用过 Charles 都知道它不只能够抓 HTTP 的包，而且还能够抓 HTTPS 的包，但条件是你得装置并信赖它的证书。

这个抓包并解密的要害便是这个证书，当阅读器和服务器通讯时，Charles 接纳服务器的证书，但动态生成一张证书给阅读器（客户端），也便是说 Charles 作为中心署理在阅读器和服务器之间通讯，所以通讯的数据能够被 Charles 阻拦并解密。因为 Charles 更改了证书，阅读器校验不经过会给出安全正告，有必要装置 Charles 的证书后才干正常拜访。

1. 客户端向服务器建议 HTTPS 恳求
2. Charles 阻拦客户端的恳求，假装成客户端向服务器进行恳求
3. 服务器向 “客户端”（实践上是 Charles）回来服务器的 CA 证书
4. Charles 阻拦服务器的呼应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles 拿到了服务器证书的公钥）
5. 客户端接纳到 “服务器”（实践上是 Charles）的证书后，生成一个对称密钥，用 Charles 的公钥加密，发送给 “服务器”（Charles）
6. Charles 阻拦客户端的呼应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles 拿到了对称密钥）
7. 服务器用自己的私钥解密对称密钥，向 “客户端”（Charles）发送呼应
8. Charles 阻拦服务器的呼应，替换自己的证书后发送给客户端
9. 至此，衔接树立，Charles 拿到了服务器证书的公钥和客户端与服务器洽谈的对称密钥，之后就能够解密或许修正加密的报文了

简略来说便是 Charles 作为中心人署理，拿到了服务器的公钥证书和 HTTPS 衔接的对称密钥，条件是客户端挑选装置并信赖 Charles 的 CA 证书，不然客户端就会 “报警” 并终止衔接。如此看来，HTTPS 也算是安全的。

可是咱们平常在开发时，假如是比较重要的接口，最好仍是加密一下通讯的内容，不要明文传输，这样才更加保险。

OVER~

参考

• 《图解 HTTP》
• 淘宝二面，面试官竟然把TCP三次握手问的这么详细
• 浅谈HTTPS通讯机制和Charles抓包原理