测试过程中经常会碰到TCP和HTTPS，有一天因为某个bug，认识了TLS和SSL，然后就乱了，这都是什么错综复杂的关系啊！惊叹…..
然后本小白，凭借着一颗八卦之心去研究了一下，这四角恋的四位主角和他们之间的爱恨情仇。
首先介绍一下四位主角。
TCP
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，是七层协议中的第四层传输层的协议之一，大名鼎鼎的三次握手就发生在这里。
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
SSL(Secure Sockets Layer 安全套接层)是为网络通信提供安全及数据完整性的一种安全协议。
安全传输层协议（TLS：Transport Layer Security）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake），是更新、更安全的SSL版本。
现在来跟大家介绍一下四位主角之间错综复杂的关系。
大家有没有发现，上面对四位主角的介绍中一直在提的一个词——安全。TCP和HTTPS在谈恋爱，他们之间要进行情感交流，但是又不能让别人发现他们的关系，为了保障TCP和HTTPS的安全，就是要保障他们之间通信的安全，所以SSL就出现了，成为了他们中间的传信人，由他在中间传递消息。时间长了，更可靠的中间人TLS出现了，他可以更好的保障TCP和HTTPS之间安全顺畅的交流。
八卦完了，下面用专业术语再跟大家介绍一下他们四位的关系。HTTPS是应用层的安全协议，TCP是传输层的协议，但是它不安全，因为它是明文传输的，所以SSL的诞生就是给TCP加了一层保险，使HTTPS和TCP之间使用加密传输。而TLS只是SSL的升级版，他们的作用是一样的。
SSL 凭证安装于伺服器（例如网站服务器）上，但是在浏览器上，使用者仍可看到网站是否受到SSL 的保护。首先，如果SSL 出现在网站上，使用者看到的网址会是以https:// 开头，而不是http:// （多出的一个s 代表「安全」）。按照企业所获得的验证或凭证等级，安全连接会通过挂锁图标或绿色地址栏来显示。
HTTPS会在网站受到SSL凭证保护时在网址中出现。该凭证的详细资料包括发行机构与网站拥有人的企业名称，可以通过按一下浏览器列上的锁定标记进行检视。
目前TLS和SSL的使用情况：
目前，应用最广泛的是TLS1.0，接下来是SSL3.0 。但主流浏览器都已经实现了TLS 1.2 的支持 ；
TLS 1.0有时被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
TLS和SSL协议理论上属于传输层，在应用层实现，所以我们可以在浏览器中设置是否使用此协议，使用哪一版本的协议。
如：ie浏览器中查看使用的TLS和SSL协议
经过上面的介绍和分析，是不是对他们的关系清楚些了。但是TLS和SSL是怎么保证安全性的呢？下面就给大家简单介绍一下他们的工作原理。
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
（1）如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
（2）公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成”对话密钥”。
（3） 双方采用”对话密钥”进行加密通信。
上面过程的前两步，又称为”握手阶段”（handshake）。
“握手阶段”涉及四次通信，我们一个个来看。需要注意的是，”握手阶段”的所有通信都是明文的。
第一步：客户端发出请求
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数，稍后用于生成”对话密钥”。
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展（SNI），允许客户端向服务器提供它所请求的域名。
第二步：服务器回应
服务器收到客户端请求后，向客户端发出回应，这叫做ServerHello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成”对话密钥”。
（3） 确认使用的加密方法，比如RSA公钥加密。
（4） 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
第三步：客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。
第四步：服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。
读过这篇文章后，您是不是对TCP HTTPS SSL TLS 的概念很清楚了，还知道他们四个之间的关系了，SSL TLS的工作原理也清楚了
