Cython是Python的一个超集，结合了Python的易用性和原生代码的速度，可以编译成C语言，产生的性能提升可以从几个百分点到几个数量级，具体取决于手头的任务。

使用Cython，你可以避开Python的许多原生限制，或者完全超越Python，而无需放弃Python的简便性和便捷性。

Python代码可以直接调用C模块。这些C模块可以是通用的C库或专门为Python工作的库。Cython生成第二种类型的模块：与Python内部对话的C库，可以与现有的Python代码绑定在一起。

Cython代码在设计上看起来很像Python代码。如果你给Cython编译器提供了一个Python程序，它将会按原样接受它，但是Cython的原生加速器都不会起作用。但是如果你用Cython的特殊语法来修饰Python代码，那么Cython就可以用快速的C代替慢的Python对象。

请注意，Cython的方法是渐进的。这意味着开发人员可以从现有的Python应用程序开始，通过对代码立刻进行更改来加快速度，而不是从头开始重写整个应用程序。

这种方法通常与软件性能问题的性质相吻合。在大多数程序中，绝大多数CPU密集型代码都集中在一些热点上，也就是帕累托原则的一个版本，也被称为“80/20”规则。因此，Python应用程序中的大部分代码不需要进行性能优化，只需要几个关键部分。你可以逐渐将这些热点转换为Cython，从而获得你最需要的性能提升。程序的其余部分可以保留在Python中，以方便开发人员。

相关推荐：《Python入门教程》

Cython优势

除了能够加速已经编写的代码之外，Cython还具有其他几个优点：

使用外部C库可以更快

像NumPy这样的Python软件包可以在Python界面中打包C库，使它们易于使用。但是，这些包在Python和C之间来回切换会减慢速度。Cython可以让你直接与底层库进行通信，而不需要Python（也支持C ++库）。

可以同时使用C和Python内存管理

如果你使用Python对象，它们就像在普通的Python中一样被内存管理和垃圾收集。但是如果你想创建和管理自己的C级结构，并使用malloc/free来处理它们，你可以这样做，只记得自己清理一下。

可以根据需要选择安全性或速度

Cython通过decorator 和编译器指令（例如@boundscheck（False））自动执行对C中弹出的常见问题的运行时检查，例如对数组的超出边界访问。因此，由Cython生成的C代码默认比手动C代码安全得多。

如果确信在运行时不需要这些检查，则可以在整个模块上或仅在选择功能上禁用它们以获得额外的编译速度。

Cython还允许本地访问使用“缓冲协议”的Python结构，以直接访问存储在内存中的数据（无需中间复制）。Cython的“记忆视图”可以高速地在这些结构上进行工作，并且具有适合任务的安全级别。

Cython C代码可以从释放GIL中受益

Python的全局解释器锁（Global Interpreter Lock，GIL）同步解释器中的线程，保护对Python对象的访问并管理资源的争用。但GIL被广泛批评为Python性能的绊脚石，特别是在多核系统上。

如果有一段代码不会引用Python对象并执行长时间运行，那么可以使用nogil：指令将其标记为允许它在没有GIL的情况下运行。这使得Python中间人可以做其他事情，并允许Cython代码使用多个内核（附加工作）。

Cython可以使用Python类型的提示语法

Python有一个类型提示语法，主要由linters和代码检查器使用，而不是CPython解释器。 Cython有它自己的代码装饰的自定义语法，但是最近修改了Cython，你可以使用Python类型提示语法为Cython提供类型提示。

Cython限制

请记住，Cython不是一个魔术棒。它不会自动将每一个poky Python代码变成极速的C代码。为了充分利用Cython，你必须明智地使用它，并理解它的局限性：

常规Python代码的加速很少

当Cython遇到Python代码时，它不能完全翻译成C语言，它将这些代码转换成一系列对Python内部的C调用。这相当于将Python的解释器从执行循环中提取出来，这使得代码默认加速了15％到20％。请注意，这是最好的情况。在某些情况下，可能看不到性能改善，甚至性能下降。

原生Python数据结构有一点加速

Python提供了大量的数据结构 - 字符串，列表，元组，字典等等。它们对于开发者来说非常方便，而且他们自带了自动内存管理功能，但是他们比纯C慢。

Cython让你继续使用所有的Python数据结构，尽管没有太多的加速。这又是因为Cython只是在Python运行时调用创建和操作这些对象的C API。因此，Python数据结构的行为与Cython优化的Python代码大致相同：有时会得到一个提升，但只有一点。

Cython代码运行速度最快时，“纯C”

如果你在C中有一个标有cdef关键字的函数，那么它的所有变量和内联函数调用都是纯C的，所以它的运行速度可以和C一样快。 但是，如果该函数引用任何Python原生代码（如Python数据结构或对内部Python API的调用），则该调用将成为性能瓶颈。

幸运的是，Cython提供了一种方法来发现这些瓶颈：一个源代码报告，一目了然地显示您的Cython应用程序的哪些部分是纯C以及哪些部分与Python交互。 对应用程序进行了更好的优化，就会减少与Python的交互。

为Cython应用程序生成的源代码报告。 白色区域纯C；黄色区域显示与Python内部的交互。一个精心优化的Cython程序将尽可能的黄色。 展开的最后一行显示了解释其相应Cython代码的C代码。

Cython NumPy

Cython改进了基于C的第三方数字运算库（如NumPy）的使用。由于Cython代码编译为C，它可以直接与这些库进行交互，并将Python的瓶颈带出循环。

但是NumPy特别适用于Cython。 Cython对NumPy中的特定结构具有本地支持，并提供对NumPy数组的快速访问。在传统的Python脚本中使用的熟悉的NumPy语法可以在Cython中使用。

但是，如果要创建Cython和NumPy之间最接近的绑定，则需要使用Cython的自定义语法进一步修饰代码。例如，cimport语句允许Cython代码在编译时在库中查看C级构造，以实现最快的绑定。

由于NumPy被广泛使用，Cython支持NumPy“开箱即用”。如果你安装了NumPy，你可以在你的代码中声明cimport numpy，然后添加进一步的装饰来使用暴露的函数。

Cython分析和性能

可以通过分析代码并亲眼目睹瓶颈在哪里获得最佳性能。Cython为Python的cProfile模块提供钩子，因此可以使用Python自己的分析工具来查看Cython代码的执行情况。无需在工具组之间切换；可以继续所熟悉和喜爱的Python世界中工作。

它有助于记住所有情况下，Cython不是魔术，仍然适用明智的现实世界的表现实践。在Python和Cython之间来回穿梭越少，你的应用运行得越快。

例如，如果你有一个你想要在Cython中处理的对象的集合，那么不要在Python中迭代它，并且在每一步调用一个Cython函数。将整个集合传递给你的Cython模块并在那里迭代。这种技术经常在管理数据的库中使用，因此这是在自己的代码中模拟的好模型。

我们使用Python是因为它为程序员提供了便利，并且能够快速开发。有时程序员的工作效率是以牺牲性能为代价的。使用Cython，只需要一点点额外的努力就可以给你两全其美的好处。

mitmtproxy即mitm+proxy,顾名思义是中间人攻击加代理。用于中间人攻击的代理首先会向正常代理一样转发请求，保障服务器与客户端的通信，其次，会适时的查、记录截获的数据或 篡改数据 ，引发服务端和客户端的特定行为。

mitmproxy可以利用python实现高度定制脚本。因为mitmproxy工作在http层，现在的绝大部分的https拥有检测并规避中间人攻击的能力，所以mitmproxy工作时必须忽略浏览器的SSL证书或让其主动信任。由于此工具具有一定的黑产性质，使用时注意有所规范。

mitmproxy有三种启动命令，分别是mitmproxy,mitmdump,mitmweb，三个命令都会启动软件，区别在于交互界面的不同。

mitmproxy没有window，再次略过。

mitmdump启动后在后台默默运行，实用性不强，也略过。

mitmweb启动后，在8081端口开一个窗口，形如：

[图片上传失败...(image-369edf-1541148099114)]

接下来就是启动chrome，不过启动要设置代理，并忽略证书错误，命令行如下

上述工作完成后就可以开发自定义脚本了，这才是mitmproxy真正强大的地方。方法有两个：

1.编写一个 py 文件供 mitmproxy 加载，文件中定义了若干函数，这些函数实现了某些 mitmproxy 提供的事件，mitmproxy 会在某个事件发生时调用对应的函数。

2.编写一个 py 文件供 mitmproxy 加载，文件定义了变量 addons，addons 是个数组，每个元素是一个类实例，这些类有若干方法，这些方法实现了某些 mitmproxy 提供的事件，mitmproxy 会在某个事件发生时调用对应的方法。

推荐使用第二种方法。

事实上考虑到mitmproxy的实际使用场景，大多数情况下我们只会用到针对HTTP生命周期的几个事件。只会用到http_connect/request/response三个时间就能完成大多数需求了。

详细使用还在研究中。敬请期待。

HTTPS是什么相信大家都知道，如果你不知道。。。请关闭此文！！！

HTTP的数据是明文传输的，没有安全性可言。HTTPS是秘文传输，那么HTTPS是怎么实现数据的安全(加密)传输的？那是因为HTTPS比HTTP多了个'S'。 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL/TLS协议是网络安全通信的重要基石，本文将简单介绍SSL/TLS协议，主要关注SSL/TLS协议的安全性，特别是SSL规范的正确实现。 本系列的文章大体分为几个部分：

1、SSL/TLS简介

2、SSL/TLS协议的基本流程

3、从SSL到TLS

4、SSL/TLS的流行实现库

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)设计的主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 1.0、SSL2.0、SSL 3.0)由网景公司设计和维护，从3.1版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 1.0、TLS1.1、TLS1.2这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

认证性——借助数字证书认证服务器端和客户端身份，防止身份伪造

机密性——借助加密防止第三方窃听

完整性——借助消息认证码(MAC)保障数据完整性，防止消息篡改

重放保护——通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务器端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。

在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

Handshake协议：包括协商安全参数和密码套件、服务器身份认证(客户端身份认证可选)、密钥交换

ChangeCipherSpec 协议：一条消息表明握手协议已经完成

Alert 协议：对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告

Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等。

图2、图3都是表示的协议流程，大同小异。可以对比着看加深理解。

每一个SSL/TLS链接都是从握手开始的，握手过程包含一个消息序列，用以协商安全参数、密码套件，进行身份认证以及密钥交换。握手过程中的消息必须严格按照预先定义的顺序发生，否则就会带来潜在的安全威胁。今年顶级安全会议CCS 有文章提出了建立综合状态机来检查SSL链接中消息序列……

2.1 握手过程中的消息序列

ClientHello：ClientHello通常是握手过程中的第一条消息，用于告知服务器客户端所支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法。

ClientHello中还包含一个随机数，这个随机数由4个字节的当前GMT UNIX时间以及28个随机选择的字节组成，共32字节。该随机数会在密钥生成过程中被使用。

另外，ClientHello中还可能包含客户端支持的TLS扩展。(TLS扩展可以被用来丰富TLS协议的功能或者增强协议的安全性)

ServerHello：服务器接受到ClientHello后，会返回ServerHello。服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持的项，并把它的选择包含在ServerHello中告知客户端。接下来SSL协议的建立就基于服务器选择的密码套件类型、SSL/TLS协议版本以及压缩算法。

ServerHello中同样会包含一个随机数，同样4+28 字节类型，由服务器生成。

Certificate：客户端和服务器都可以发送证书消息来证明自己的身份，但是通常客户端证书不被使用。 服务器一般在ServerHello后会接一条Certificate消息，Certificate消息中会包含一条证书链，从服务器证书开始，到Certificate authority(CA)或者最新的自签名证书结束。下图形象地描述了证书链：

SSL中使用的证书通常是X.509类型证书，X.509证书的内容如下表所示：

在用的X.509证书包含Version 1和Version 3两种版本，其中v1版本的证书存在安全隐患，同时不支持TLS扩展，被逐渐弃用。现在大多数在用的SSL证书都是V3版本。

同时证书会附带与协商好的密钥交换算法对应的密钥。密钥交换算法以及它们所要求的密钥类型如下表所示。

ServerKeyExchange：该消息仅当以下密钥交换算法被使用时由服务器发出：

RSA_EXPORT(仅当服务器的公钥大于512bit时)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密钥交换算法时，服务器不能发送此消息。

ServerkeyExchange消息会携带这些密钥交换算法所需要的额外参数，以在后续步骤中协商PreMasterSecret。这些参数需要被签过名。

CertificateRequest：这个消息通常在要求认证客户端身份时才会有。消息中包含了证书类型以及可接受的CA列表。

ServerHelloDone：服务器发送这条消息表明服务器部分的密钥交换信息已经发送完了，等待客户端的消息以继续接下来的步骤。这条消息只用作提醒，不包含数据域。

ClientKeyExchange：这条消息包含的数据与所选用的密钥交换算法有关。

如果选择的密钥交换算法是RSA，那么消息包含的参数为用服务器RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret，它有48个字节，前2个字节表示客户端支持的最高协议版本，后46个字节是随机选择的。

如果选择的密钥交换算法是DH或者DHE，则可能有两种情况：

隐式DH公开值：包含在Certificate消息里

显示DH公开值：公开值是本消息的一部分。

CertificateVerify：这条消息用来证明客户端拥有之前提交的客户端证书的私钥。

Finished：表明握手阶段结束。这是第一条用协商的算法和密钥保护的消息。

因为是用协商好的密钥加密的消息，它可以用来确认已经协商好的密钥。

同时Finished消息包含一个verify_data域，可以用来校验之前发送和接收的信息。

Verify_data域是一个PRF函数的输出(pseudo-random function)。这个伪随机函数的输入为：(1)两个hash值：一个SHA-1，一个MD5，对之前握手过程中交换的所有消息做哈希(2)the MasterSecret，由预备主密钥生成(3)finished_label，如果客户端发送的则是”client finished”，服务器发送的则是”server finished”。关于这个PRF的细节在3.3节中会具体描述。 此外，Finished 消息不能够在ChangeCipherSpec前发送。

2.2 不同密钥交换算法对应的握手过程

不同的密钥交换算法对应的握手过程中的消息序列是不同的，相应的实现方式也不同，本节介绍几个常见密钥交换算法对应的握手过程。

TLS-RSA：在这个场景下，PreMasterSecret是由客户端指定的，并用RSA公钥加密发送给服务器。服务器不影响PReMasterSecret的生成。

TLS-DH：基于DH的密钥交换也被称为静态Diffie-Hellman。在这种场景下，可能是双方各自提交一个证书包含DH公开值，或者服务器端提交证书包含DH公开值，客户端在每次会话中选择一个值。协商好的DH值被用作PreMasterSecret。显然证书中的参数是固定的，那么每次链接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基于DHE的TLS握手中会有ServerKeyExchange消息。握手过程中交换参数的认证通过数字签名来实现，支持的签名算法包括RSA和DSS。DH参数会有它的数字签名一起被包含在ServerKeyExchange中被发送出去。客户端在ClientKeyExchange中返回它的公开DH参数，但没有签名保护。同样协商出来的DH密钥被用作PreMasterSecret。

2.3 密钥生成

Pseudo-random Function(PRF)：伪随机函数是SSL协议中的一个重要组成部分，它被用来秘密扩展以及生成密钥。在3.1节讲解Finished消息时已经简单提及PRF，在这里我们详细讨论PRF的工作原理。SSL/TLS协议中的PRF如下图所示：

这个PRF基于两个hash函数：MD5和SHA-1，它有3个输入，一个Secret(比如PreMasterSecret)，一个标志符(比如”client finished”, “server finished”)，还有一个种子值(比如客户端随机数+服务器端随机数)。

Secret在使用时被分为长度相同的两半：S1和S2，分别作为P_MD5和P_SHA-1的输入。

PRF的输出按如下方式处理得到：

P_MD5和P_SHA-1都是扩展函数，用来扩展秘密值以用于密钥生成，它们的计算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

这个秘密扩展会一直进行直到得到足够多的扩展数据。 Key Derivation：主密钥(MasterSecret)是利用上述PRF从预备主密钥(PreMasterSecret)生成的。每个MasterSecret为48字节，生成方式如下：

得到MasterSecret后，它会被进一步处理最后生成4个不同的密钥和2个初始向量(IV)。处理过程如下：

处理过程一直持续到足够多的输出被生成，然后把输出分为4个key和2个IV：

下图完整阐述了SSL/TLS协议中的密钥生成过程。

本节介绍SSL/TLS协议的版本变迁，不同版本的区别以及安全特性等。

SSL 1.0由于从来没有被公开过，并且存在严重安全漏洞，我们就不讨论了。

SSL 2.0：SSL 2.0于1995年4月被发布。SSL 2.0中主要存在的问题如下：

MAC不能覆盖填充长度域，攻击者可能利用这点破坏消息完整性

缺乏握手认证，攻击者可以篡改密码套件列表，诱骗通信双方使用较弱的密码套件

使用较弱的或有问题的密码算法(如MD5，RC4等)，或者使用不安全的分组模式(如CBC模式)

对于不同的密码学基元使用相同的密钥，违背基本安全常识。

由于以上安全问题，RFC 6176已经明确提出避免使用SSL 2.0，但是现实生活中还有少量客户端和服务器支持SSL 2.0.

SSL 3.0：SSL 3.0引入了一些新的特性和机制解决了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子协议。SSL 3.0向后兼容SSL 2.0，相对于SSL 2.0，它的主要改变包括以下几点：

支持更多的密码套件(支持更多的密码算法如DSS，SHA-1)

在握手阶段支持密钥协商(DH和FORTEZZA)

支持密码学参数的重协商

增加了消息压缩选项

MAC能够覆盖填充长度域了，同时MAC可以使用MD5或者SHA-1

不同的密码学基元使用不同的key

Alert子协议能对任何错误给出两种提示：Warning和Fatal

中止链接的时候会用一个close_notify警告通知通信双方

支持证书链，而非单个证书

通过Finished消息认证所有发送和接收的消息

加密了的PreMasterSecret包含当前使用的协议版本，防止协议回滚

TLS 1.0：TLS 1.0和SSL 3.0差别非常小。实际上，TLS 1.0是SSL 3.1，在IETF接手后改名为TLS。TLS 1.0版本是目前使用最广泛的SSL/TLS协议版本。

TLS 1.0不再支持使用FORTEZZA的密码套件。

TLS 1.0中MAC被替换成HMAC。

之前提到ChangeCipherSpec消息必须在Finished消息前发送，在TLS 1.0中，如果消息序列不符合这个要求，会产生FATAL警告并终止链接。

TLS 1.1：这个版本相比之前改动也很小。最重要的改动是预防了针对CBC分组模式的一些攻击。现在的填充错误变的和非法MAC错误不可区分了，防止攻击者利用可区分错误响应建立解密预言机对密文进行攻击。

在每次加密过程中，使用CBC分组模式时，都需要显示给出IV，而不用再密钥生成时使用PRF生成IV。

此外，TLS 1.1禁止为适应之前出口限制而使用弱化的密码套件。

TLS 1.2：这是最新的版本，部署的还比较少。这个版本禁用了PRF中的MD5和SHA-1，而用一个可配置的hash函数取代了它们，这样的修改简化了计算过程。修改后的PRF风格如下：

此外，TLS 1.2的一个重要变化是支持认证加密模式(支持GCM等)。但是由于一些AEAD(Authenticated Encryption with Associated Data)密码算法要求IV为隐式的，所以IV又恢复到由MasterSecret生成，即TLS 1.0以前的风格。

TLS 1.2支持使用GCM、CCM的新密码套件。

同时SSL 2.0被宣布放弃，不再向后兼容SSL 2.0.

本节简单介绍一下流行的SSL/TLS实现库，SSL协议非常复杂，由开发者自己实现常常会出错，开发者在具体实现SSL协议时通常会依赖于这些密码学库。

4.1 常见的SSL/TLS 实现

OpenSSL：这是非常流行的开源SSL/TLS实现。

OpenSSLim完全用C语言实现，支持SSL 2.0/3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。

OpenSSL 近年来出现了很多的安全漏洞，比如2014年曝出的著名的Heartbleed漏洞等。

JSSE：这是使用Java实现的，支持SSL 3.0，TLS 1.0/1.1/1.2.

Bouncy Castle：它不仅仅支持SSL/TLS，它是一个完整的密码学库，支持各种密码学算法和协议。不过它仅仅支持TLS 1.0版本。

Android平台主要使用这个密码学库。

GnuTLS：这是另一个用C语言实现的库，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同时以各种安全漏洞多而闻名。

NSS：这是最初由网景公司(Netscape)开发的库，支持SSL 2.0/3.0，TLS 1.0/1.1，现在主要被浏览器和客户端软件使用，比如Firefox使用的就是NSS库，Chrome使用的是一个NSS库的修正版。

下表是一些常见软件以及它们所使用的SSL/TLS实现库的情况：

其它还有一些常用的SSL实现库，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由于市场占有率不高，我们这里就不多做介绍了。

4.2 流行SSL/TLS实现库的安全研究

最近几年曝出的高风险SSL安全漏洞大多跟SSL实现库有关，比如2014年4月曝出的“心脏滴血”漏洞，存在于OpenSSL 1.0.1-1.0.1f版本中，影响全球近17%的Web服务器同样是2014年曝出的苹果公司iOS 7.0.6版本系统中存在的“gotofail”漏洞，因为程序员的疏忽导致SSL证书校验中的签名校验失效包括今年曝出的SSL Freak攻击也是由于SSL实现库的安全漏洞导致的攻击，我们研究小组的同学对这个攻击有详细的分析，参见《SSL Freak来袭：如何实施一个具体的SSL Freak攻击》。同时我们还开发了一个基于python的中间人代理攻击框架“风声”对某国内知名电商的服务器进行具体的攻击，并上报了漏洞。

考虑到大量SSL/TLS实现库中存在安全问题，同时这些主流的SSL/TLS实现库对开发者而言使用难度较高，比如有些SSL/TLS实现库要求开发者自己进行随机数生成或密钥管理，让缺乏系统信息安全知识培训的开发者去使用这样高度复杂的密码学库容易产生很多安全问题。我们在这里推荐一些高级密码学库：Google keycazer、NaCl、Cryptlib、GPGME。这些密码学库存在的安全问题较少，同时封装了一些底层的密码学操作，降低了开发者的使用难度。

以上就是本次要介绍的SSL /TLS协议基本知识，后续的文章我们会对一些典型SSL/TLS攻击进行具体介绍。

参考：

1、 http://netsecurity.51cto.com/art/201505/476337.htm

2、 http://www.cnblogs.com/NathanYang/p/9183300.html

3、 https://www.cnblogs.com/bhlsheji/p/4586597.html

---