http/https协议总结

http是一个是用于在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP状态码

1xx：

        1xx类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx：

        2xx类状态码表示服务器成功处理了客户端的请求。

        [200 OK] 是最常见的成功状态码，表示一切正常。如果是非HEAD请求，服务器返回的响应头都会有body数据。

        [204 No Content]也是常见的成功状态码，与200 OK基本相同，但响应头没有body数据。

        [206 Partial Content]是应用于HTTP分块下载或断点续传，表示响应返回的body数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx:

        3xx类状态码表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向。

        [301 Moved Permanently] 表示永久重定向，说明请求的资源以及不存在了，需改用新的URL再次访问。

        [302 Moved Temporary] 表示临时重定向，说明请求的资源还在，但暂时需要用另一个URL来访问。

        301和302都会在响应头里使用字段Location，指明后续要跳转的URL，浏览器会自动重定向新的URL。

        [304 Not Modified]不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4xx

        4xx类状态码表示客户端发送的报文有错误，服务器无法处理，也就是错误码的含义。

        [400 Bad Request]表示客户端请求的报文有错误，但只是个笼统的错误。

        [403 Forbidden] 表示服务器禁止访问资源，并不是客户端的请求出错。

        [404 Not Found] 表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx:

        5xx类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务端的错误码。

        [500 Internal Server Error]与400类似，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

        [501 Not Implemented] 表示客户但请求的功能还不支持，还未实现。

        [502 Bad Gateway] 通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

        [503 Service Unavailable] 表示服务器当前很忙，暂时无法响应服务器。

HTTP字段

• Host：客户端发送请求时，用来指定服务器的域名。
• Content-Length：服务器在返回数据时，会有Content-Length字段，表明本次回应的数据长度。
• Connnection：最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。HTTP/1.1版本的默认连接都是持久连接，但为了兼容老版本的HTTP，需要指定Connection首部字段的值为Keep-Alive。Connection:keep-Alive。
• Content-Type：用于服务器回应时，告诉客户端本次数据时什么格式。Content-Type:text/html;charset=utf-8:表明服务器会送的是网页，而且编码是UTF-8。客户端请求的时候，可以使用Accept字段声明自己可以接收那些数据格式。比如Accept:/:客户端声明自己可以接收任何格式的数据。
• Content-Encoding：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式，客户端在请求的时候，用Accept-Encoding字段说明自己可以接收那些压缩方法。

请求方法：GET、POST

区别：

• Get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
• POST方法则是相反的操作，它向URL指定的资源提交数据，数据就放在报文的body里。

GET请求是只读属性，请求内容直接在请求行中不安全。POST是可以修改服务器的数据，内容在body里是比较安全。

HTTP特点

优点

        HTTP最突出的优点是简单、灵活和易于扩展、应用广发和跨平台。

• 简单：HTTP基本的报文格式就是header+body，头部信息也是key-value简单文本的形式，易于理解。
• 灵活和易于扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成部分都没有被固定死，都允许开发人员自定义和扩充。同时HTTP由于是工作在应用层，则它下层可以随意变换。比如，HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层，HTTP/3甚至把TCP层换成了基于UDP的QUIC。

缺点：无状态、明文传输、不安全

无状态：无状态的坏处使得服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。对于无状态的常用解决方案是Cookie。

        Cookie通过在请求和响应报文中写入Cookie信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的小贴纸，后续客户端请求服务器的时候，带上这个小贴纸，服务器就能认得了。

        Cookie与Session区别：

        cookie是存储在本地浏览器，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被盗取。但存储在服务器也有一定的弊端，就是会占用服务器的资源

        cookie与session的配合使用：

        存储在服务端：通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登陆，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server-side session.

        将session数据加密，然后存储在cookie中。这种专业术语叫做client-side session.

明文传输：

        明文传输利于阅读和Debug，但是信息不安全，在信息传输过程中信息内容毫无隐私可言。

不安全：HTTP的不安全性问题可以使用HTTPS引入SSL/TLS层得到解决

HTTPS协议

ssl/tls是位于tcp/ip 7层协议中的会话层，用于认证用户和服务器，加解密数据以及维护数据的完整性，确保数据在传输过程中不会被修改。

ssl有v2和v3两个版本，而v1因为有严重的缺陷从未公开过。ssl发展到v3时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组在1999年把它改名为tls(传输层安全，Transport Layer Security)，正式标准化，版本号从1.0重新计算，所以tls1.0 实际就是ssl 3.1。

目前应用的最广泛的tls是1.2，而之前的协议(tls 1.2/1.0、ssl 3/2)，都已经被认为是不安全的。

tls由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成。综合使用了对称加密、非对称加密、身份认证等许多密码学前言技术。浏览器和服务器在使用tls建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为"密码套件"(cipher suite，也叫加密套件)。

ssl/tls分为对称加密和非对称加密两种方式。

对称加密

        对称加密是指加密和解密都用同一份密钥。

        AES的意思是"高级加密标准"(Advanced Encryption Standard)，密钥长度可以是128、192或256。他是DES算法的替代者，安全强度很高，性能也很好，而且由的硬件还会做特殊处理，所以非常流行，是应用最广泛的对称加密算法。国产类似的算法是sm4。

        ChaCha20是Google设计的另一种加密算法，密钥长度固定为256位，纯软件运行性能要超过AES，曾经在移动客户端上比较流行，但但ARMv8之后加入了AES硬件优化，所以现在不在具有明显的优势，但仍然算得上是一个不错的算法。

非对称加密

        非对称加密对应于一对密钥，称为私钥和公钥，用私钥加密后需要用公钥解密，用公钥加密后需要用私钥解密。

        对称加密看上去好像完美地实现了机密性，但其中有一个很大的问题：如何把密钥安全地传递给对方，术语叫"密钥交换"。因为在对称加密算法中只要持有密钥就可以解密了。如果你和网站约定的密钥在传输过程中被黑客窃取，那他就可以在之后随意解密收发的数据，通信过程也就没有机密性可言了。

        所以就出现了非对称加密。它有两个密钥，一个叫公钥，一个叫私钥。两个密钥是不同的，公钥可以公开给任何其他人使用，而私钥必须严格保密。

        公钥和私钥有个特别的单向性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后只能用公钥解密。

        非对称加密算法的设计要比对称算法难的多，在tls里只有很少的几种，比如DH、DSA、RSA、ECC等。国产是sm2。

• RSA可能是其中最知名的一个，几乎可以说是非对称加密的代名词，它的安全性基于"整数分解"的数学难度，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。10年前RSA密钥的推荐长度是1024，但随着计算机运算能力的提高，现在1024已经不安全，普遍任务至少要2048位。
• ECC是非对称加密里的后起之秀，它基于"椭圆曲线离散对数"的数学难题，使用特点的曲线方程和基于点生成公钥和私钥，子算法ECDHE用于密钥交换，ECDSA用于数字签名。

        比起RSA，ECC在安全强度和性能上都有明显优势。160位的ECC相当于1024位的RSA，而224位的ECC则相当于2048位的RSA。因为密钥短，所以响应的计算量、消耗的内存和宽带也就少，加解密的性能就上去了，对于现在的移动互联网非常有吸引力。

        对称加密的优点是运算速度快，缺点是互联网环境下无法将密钥安全的传给对方。非对称加密的优点是可以安全的将公钥传递给对方，但是运算速度慢。

        在通信刚开始的时候使用非对称算法，比如RSA、ECDHE、首先解决密钥交换的问题。然后用随机数产生对称算法使用的"会话密钥"(session key)，在用公钥加密。对方拿到密文后用私钥解密，取出会话密钥，这样，双发就实现了对称密钥的安全交换，后续就不再使用非对称加密，全部使用对称加密。

        这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。不过这只是"万里长征的第一步"，后面还有完整性、身份认证、不可否认等特性没有实现，所以现在的通信还不是绝对安全。

数字签名与 证书

        黑客虽然拿不到会话密钥，无法破解密文，但是可以通过窃听收集到足够多的密文，在尝试者修改、重组后发给网站。因为没有完整性保证，服务器只能"照单全收"，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。

        另外，黑客也可以伪造身份发布公钥。如果你拿到了假的公钥，混合加密就完全失效了。你以为自己是在和"某宝"通信，实际上网线的另一端却是黑客，银行卡号、密钥等敏感信息就在"安全"的通信过程中被窃取了。

        所以，在机密性的基础上还必须加上完整性、身份认证等特性，才能实现真正的安全。

摘要算法

        实现完整性的手段主要是摘要算法(digest algorithm)，也就是常说的散列函数、哈希函数。

        我们可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据压缩成固定长度、而且独一无二的摘要字符串，就好像是给这段数据生成了一个数字指纹。

        换一个角度，也可以把摘要算法理解成特殊的单向加密算法，它只有算法，没有密钥，加密后数据无法解密，不能从摘要逆推出原文。

完整性

        摘要算法保证了"数字摘要"和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

        比如，你发了条消息："转账1000"，然后在加上一个SHA-2的摘要。网站收到后也计算一下消息的摘要，把者两份指纹做个对比，如果一致，就说明消息是完整可信的，没有被修改。

        如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发小消息被篡改，是不可信的。不过摘要算法不具有机密性，如果明文传输，那么黑客可以修改消息后把摘要也一起改了，网站还是鉴别不出完整性。

        所以真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了，这个术语，叫哈希消息认证码(HMAC)。

数字签名

        加密算法结合摘要算法，我们的通信过程可以说是比较安全了。但这里还有个漏洞，就是通信的两个端点。

        就像一开始所说，黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱就可能就这么被偷走了。

        现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件却是是由本人而不是其他人发送的。

        在这里，使用非对称加密里的私钥在加上摘要算法，就能够实现数字签名，同时实现身份认证和不可否认。

        数字签名的原理其实很简单，就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。

        但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。签名和公钥一样完全公开，任何人都可以获取。但这个签名只有私钥对于的公钥才能解开，拿到摘要后，在比对原文验证完整性，就可以像签署文件一样证明消息却是是你发的。

        刚才的这两个行为也又专业术语，叫做签名和验签。

        只要你和网站相互交换公钥，就可以用签名和验签来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双发的身份。

        比如，你用自己的私钥签名一个消息"我是小明"。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息"我是某宝"。你收到后在用它的公钥验一下，也没问题，这样你的网站就都知道对方不是假冒的，后面就可以用混合加密进行安全通信了。

数字证书和CA

        到现在，综合使用对称加密、非对称加密和摘要算法，是不是已经完美了呢？

        不是的，这里还有一个"公钥的信任"问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你的或者某宝的公钥呢？

        真是按下葫芦浮起瓢，安全还真是个麻烦事，一环套一环的。

        我们可以用类似密钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，者又会陷入无穷递归。但这次实在是没招了，要终结这个死循环，就必须引入外力，找一个公认的可信第三方，让它作为信任的起点，递归的终点，构建起公钥的信任链。

        这个第三发，就是我们常说的CA(Certificate Authority，证书认证机构)。它就像网络世界里的公安局、教育局、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。CA对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包在签名，完整地证明公钥关联的各种信息，形成数字证书。

        不过CA怎么证明自己呢？

        这还是信任链的问题。小一点的CA可以让大CA签名认证，但链条的最后，也就是Root CA，就只能自己证明自己了，这个就叫"自签名证书"(self-signed ceriticate)或者"根证书"(root ceriticate)。你必须相信，否则整个证书信任链就走不下去了。

        有了这个证书体系，操作系统和浏览器都内置了各大CA的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链一层层地验证，直到找到根证书，就能够确认证书是可信的，从而能里面的公钥也是可行的。

证书体系的弱点

        证书体系(PKI，public key infrastructure)虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，还有关键的信任二字。

        如果CA失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。

        还有一种更危险的情况，CA被黑客攻陷，或者CA有恶意，因为它(即根证书)是信任的源头，整个信任链里的所有证书也就都不可信了。

        针对第一种，开发出了CRL(证书吊销列表，Certificate revocation list)和OCSP(在线证书状态协议，online certificate status protocol),及时废止有问题的证书。

        对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上下狠手了，撤销对CA的信任，列入黑名单，这样它颁发的所有证书就都会被认为是不全的。

HTTPS建立连接

        当我们在浏览器地址栏里输入https开头的url，在按回车，会发送什么呢？

        浏览器首先要从url里提取出协议名和域名。因为协议名是https，所有浏览器就知道了端口号是默认的443，它在用DNS解析域名，得到目标的ip地址，然后就可以使用三次握手与网站建立tcp连接了。

        在http协议里，建立连接后，浏览器会立即发送请求报文。但现在是https协议，它需要在用另一个握手过程。在tcp上建立安全连接，之后才是收发https报文。

TLS协议的组成

        在讲TLS握手之前，先了解一下TLS协议的组成

        TLS包含几个子协议，可以理解为他是由几个不同的职责的模块组成的，比较常用的有记录协议、警报协议、握手协议、变更密钥规范协议等。

• 记录协议(record protocol)规定了TLS收发数据的基本单位：记录(record)。它有点像是TCP里的segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个TCP包里一次性发出，也并不需要像tcp那样返回ack。
• 警报协议(alert protocol)的职责是向对方发出警报信息，有点像http协议里的状态码。比如，protocol_version就是不支持旧版本，bad_certificate就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。
• 握手协议(handshake protocol)是tls里最复杂的子协议，要比tcp的syn/ack复杂的多，浏览器和服务器会在握手过程中协商TLS版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双发协商得到会话密钥，用于后续的混合加密系统。
• 最后一个是变更密码规范协议(change cipher spec protocol)，它非常简单，就是一个通知，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。

TLS握手协议

        在用ssl进行通信之前，首先要使用ssl的handshake协议在通信两端握手，协商数据传输中要用到的相关安全参数(如加密算法、共享密钥、产生密钥所要的材料等)，并对对端的身份进行验证。

clientHello

        握手的第一步时客户端向服务端发送client hello消息，这个消息里包含了一个客户端生成的随机数random1、客户端支持的加密套件ciphers和ssl version等信息。

• 客户端版本：按优先级列出客户端支持的协议版本，首选客户端希望支持的最新协议版本。
• 客户端随机数random
• 会话ID(Session id)：如果客户端第一次连接到服务器，那么这个字段就会保持为空。如果该字段不为空，说明以前时与服务器有连接的，在此期间，服务器将使用Session ID映射对称密钥，并将Session ID存储在客户端浏览器中，为映射设置一个时间限。如果浏览器将来连接到同一台服务器(在时间到期之前)，它将发送Session ID，服务器将对映射的Session ID进行验证，并使用以前用过的对称密钥来恢复Session，这种情况下不需要完全握手。也叫做SSL会话恢复。
• 加密套件：客户端会给服务器发送自己已经知道的密码套件列表，这时由客户端按优先级排列的，但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标志格式。客户端发送了多个加密套件列表。服务端会从中选出一种来作为双发共同的加密套件。
• 压缩算法：为了减少带宽，可以进行压缩。但从成功攻击TLS的事例中来看，其中使用压缩时的攻击可以捕获到用HTTP头发送的参数，这个攻击可以劫持Cookie，这个漏洞我们称为CRIME。从TLS1.3开始，协议就禁用了TLS压缩。

serverHello

        收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查诸如TLS版本和算法的客户端问候的条件，如果服务器接收并支持所有条件，它将发送其证书以及其它详细信息，否则，服务器将发送握手失败消息。

        如果接受，第二步是服务器向客户端发送server hello消息，这个消息会从client hello传过来的support ciphers里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用那些算法，另外还会生成一份随机数random2。注意，至此客户端和服务端都拥有了两个随机数，这两个随机数会在后续生成对称密钥时会用到。

• 服务器版本version：服务器会选择客户端支持的最新版本。
• 服务器随机数random：服务器和客户端都会生成32字节的随机数。用来创建加密密钥。
• 加密套件：服务器会从客户端发送的加密套件列表中选出一个加密套件。
• 会话ID(Session ID):服务端将约定的Session参数存储在TLS缓存中，并生成与其对应的Session id。它与Server hello一起发送到客户端。客户端可以写入约定的参数到此Session id，并给定到期时间。客户端将在Client hello中包含此id。如果客户端在此到期时间之前再次连接到服务器，则服务器可以检查与Session id对应的缓存参数，并重用它们而无需完全握手。这非常有用，因为服务器和客户端都可以节省大量的计算成本。在涉及亚马逊和谷歌等流量巨大的应用程序时，这种方法存在缺点。每天都有数百万人连接到服务器，服务器必须使用Session密钥保留所有Session参数的TLS缓存。这是一个巨大的开销。为了解决这个问题，在扩展包里加入Session Tickets，在这里，客户端可以在client hello中指定它是否支持session ticket。然后，服务端将创建一个新的会话票证(Session Ticket)，并使用只有服务端知道的经过私钥加密的Session参数。它将存储在客户端上，因此所有session数据仅存储在客户端计算机上，但Ticket仍然是安全的，因为该密钥只有服务器知道。此数据可以作为名为Session Ticket的扩展包含在client hello中。
• 压缩算法：如果支持，服务端将同意客户端的首选压缩算法。
• 扩展包

这个阶段之后，客户端服务端知道了下列内容：

• SSL版本
• 密钥交换、信息验证和加密算法
• 压缩方法
• 有关密钥生成的两个随机数

Certificate消息(可选) 第一次建立必须要有证书

        一般情况下，除了会话恢复时不需要发送该消息，在SSL握手的全流程中，都需要包含该消息。消息包含一个X.509证书，证书中包含公钥，发给客户端用来验证签名或在密钥交换的时候给消息加密。

        这一步时服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证用过后取出证书中的公钥。

Server Key Exchange (可选)

        根据之前在Client hello消息中包含的Cipher suite信息，决定了密钥交换方式(例如RSA或者DH)，因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。

        当是DH算法，就需要发送服务器使用的DH参数。RSA算法不需要这一步。

        在Diffie-Helloman中，客户端无法自行计算预主密钥；客户端需要从服务器获取Diffie-Helloman公钥。

Certificate Request(可选)  可以是单向的身份认证，也可以是双向认证

        这一步是可选的，如果在对安全性要求高的可能会用到。服务端用来验证客户端。服务端发送Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务端支持的证书类型(RSA、DSA、ECDSA等)和服务端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。

Server Hello Done

        该消息表示服务器已经将所有信息发送完毕，接下来等待客户端的消息。

SSL建立第三阶段：客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发给服务器。

Certificate(可选)

        如果在第二阶段服务端要求发送客户端证书，客户端便会在该阶段将自己的证书发送过去。服务端在之前发送的Certificate Request消息中包含了服务端所支持的证书类型和CA列表，因此客户端会在自己的证书中选择满足这两个条件的第一个证书发送过去。若客户端没有证书，则发送一个no_certificate警告。

Client key exchange

        根据之前从服务器端收到的随机数，按照不同的密钥交换算法，算出一个pre-master，发送给服务端，服务端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双发就算出了对称密钥。

        如果是RSA算法，会生成一个48字节的随机数，然后用server的公钥加密后在放入报文中。如果是DH算法，这是发送的就是客户端DH参数，之后服务器和客户端根据DH算法，各自计算出相同的pre-master secret。

        本消息在给服务端发送的过程中，使用了服务器的公钥加密。服务器用自己的私钥解密后才能得到pre-master key。

Certificate verify（可选）

        只有在客户端发送了自己证书到服务端，这个消息才需要发送。其中包含一个签名，对从第一条消息以来的所有握手信息的HMAC值进行签名。

ChangeCipherSpec

        编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送(ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件的状态，准备使用之前协商好的加密套件加密数据并传输了)。

Client Finished

        客户端握手结束通过，表示客户端的握手阶段已经结束。这一项同时也是前面发送的的所有内容的hash值，用来供服务端校验(使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加密通道进行验证。)

Server Finished

 服务端握手结束通知：

• 使用私钥解密加密的pre-master数据，基于之前(client hello和server hello)交换的两个明文随机数random_C和random_S，计算得到协商密钥 enc_key。
• 计算之前所有接收信息的hash值，然后解密客户端发送的encrypted_handshake_message，验证数据和密钥正确的；
• 发送一个ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和Session Secret加密数据了。
• 服务端也会使用Session secret加密一段Finish消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。