tcp和tls区别(TLS和SSL的区别)

前言：之前有个误解，我一直以为SSL是属于应用层的，因为HTTPS用的就是它嘛。直到笔试遇到了一题选择题，把SSL归到了运输层，我就犹豫了。我需要确切的答案。首先我查看《计算机网络第七版》，P345：然后在同一页的底部：按书上的话，那SSL应该属于运输层了。但是这应该两字让我又上网查了一下，发现各种说法都有：会话层、表示层、介于两层之间...都有。于是我就上Stack Exchange，找到两个提问，以下内容为两个问题中自己的部分翻译（只保留原文，不掺杂自己的评论，翻译得不好见谅哈，原链接也有，可以直接看。（2021年更新：由于的傻逼锁定文章机制，链接不得已去除了。））：Q：TLS代表着 “运输层的安全性”。并且在IP协议号列表中 “TLSP” 是作为 “运输层安全协议” 的。这两点让我相信 TLS 是一种运输层协议。但是，大多数人似乎都在谈论TLS是TCP上的。维基百科将其列为 “应用层” 协议。由于TCP没有像协议号这样的东西，这更加复杂：它只是打包原始字节，所以如何解析你得到的TLS数据包，而不是刚开始为0x14-0x18或类似的数据包？A1：OSI模型，将通信协议分类为连续的层：嗯...它只是一个模型。它试图将现实世界用整齐定义的框框来表示。但没有人能保证它一定有效......回顾历史，当ISO推动采用自己的网络协议时，该模型就已经建立并发布。但是他们失败了。作为一个整体世界，更倾向于使用更简单的TCP / IP。ISO模型的生态系统死亡了，但这“模型”却幸存了下来。许多人试图用它来理解TCP / IP。甚至以这种方式来教授。但是，这个模型与TCP / IP是不匹配的。TCP / IP中的有些东西不适合放到ISO模型具体的哪一层中，SSL / TLS就是其中之一。如果你看了协议细节：因此，在OSI模型中，SSL / TLS必须在第6层或第7层，同时在第4层或更低层。不可避免的结论是：OSI模型不适用于SSL / TLS。TLS不在任何层中。（这并不妨碍某些人在任意一层中使用TLS。它没有实际的影响 - 这只是一个模型 - 你可以在概念上说TLS是第2,5甚至17层的都可以，没人可以证明你说的不对。）A2：对于TCP / IP模型：TLS在传输层和应用层之间运行。实际上它只是在传输过程中将应用层数据包装在加密中。TLS密钥交换发生在层与层之间。这里并不是传输层，因为端口号和序列号之类的东西已经存在于传输层了。它只发送数据来建立加密协议，以便它可以包装应用层。对于OSI模型：OSI模型具有更细的粒度。TLS建立加密会话。在OSI模型中，这是TLS运行的地方。它设置其会话，并为应用层（HTTP）添加一层加密。Q：我使用Firebug检测了HTTPS网站（gmail.com）的数据传输。但我看到我提交的数据（用户名和密码）的并没有加密。SSL加密到底在哪里做的？A：SSL协议实现为HTTP协议的透明包装。就OSI模型而言，它有点像灰色区域。它通常在应用层中实现，但严格来说是在会话层中。如下所示：请注意，SSL位于HTTP和TCP之间。如果你想看到它的实际效果，请抓包一个用HTTP协议的网站，再抓包另一个用HTTPS协议的网站。您将看到使用HTTP协议网站的请求和响应都是纯文本，但HTTPS协议的网站是加密。您还可以从数据链路层向上看到数据包一层层的拆分。更新：有人指出（见评论）OSI模型过于概括，并不适合这里。这说得没错。但是，使用此模型是为了说明SSL位于TCP和HTTP之间的“某处”。严格上它不是准确的，是对现实的一种模糊抽象。下面是这条答案的评论：2.@Bruno 我不确定你说的。TCP / IP是一套网络协议，而TCP和IPv4是OSI模型中各个层的不同协议。在这个例子下，OSI模型是一个很好的抽象，因为它显示了SSL的大概位置。不需要100％准确 - 没有任何关于这种抽象的东西 - 它只是帮助理解。-Polynomial3.@Polynomial 我只是说OSI模型被广泛传授作为一个理论概念，但TCP / IP协议栈（最常用的协议栈之一）明确地不适合该模型。事实上，维基百科页面将SSL / TLS放在第6层（表示层）中，而不是像你的答案那样。传播OSI模型在许多情况下实际上没有帮助，并且该层可能非常“人为”（"artificial"）。它只是一个模型，它总是由人决定的，模型并不总是与现实世界相匹配，就像你硬要把VPNs协议归到某一层一样不适合。同样的SSL / TLS也不合适 - Bruno4.@Bruno 正如我们讨论的那样，TLS并不适合OSI模型中的任一层。严格来说，它是第7层，而不是5或6。但就网络协议封装而言，它位于TCP和应用程序之间，因此5和6是有意义的。5和6之间的区别也是一个灰色区域，因为TLS不仅仅是加密数据。所以，正如我之前所说的，这是一个简单的说明，只是为了在实际意义上表达它在网络协议栈中的大概位置。哈哈哈，有趣有趣，相信看完后有了进一步了理解，有空再将翻译完善完善，把其他一些答案也翻译出来。从上面的答案中我总结了以下几点：1.OSI模型不适用于SSL，不能100％准确的说在哪个位置。只能表示SSL的大概位置。用于帮助理解。2.SSL作用于应用层和运输层之间。如果硬要说在哪个位置，那就是：会话层

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。SSL (Secure Socket Layer)为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。SSL协议提供的服务主要有：1）认证用户和服务器，确保数据发送到正确的客户机和服务器；2）加密数据以防止数据中途被窃取；3）维护数据的完整性，确保数据在传输过程中不被改变。SSL协议的工作流程：服务器认证阶段：1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。用户认证阶段：在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。从SSL 协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。TLS(Transport Layer Security Protocol)：安全传输层协议安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。TLS 记录协议提供的连接安全性具有两个基本特性：私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。可靠――信息传输包括使用密钥的MAC进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。TLS记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 TLS 握手协议提供的连接安全具有三个基本属性：可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。TLS的最大优势就在于：TLS是独立于应用协议。高层协议可以透明地分布在TLS协议上面。然而， TLS 标准并没有规定应用程序如何在TLS上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。协议结构TLS 协议包括两个协议组――TLS记录协议和TLS握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。TLS连接状态指的是TLS记录协议的操作环境。它规定了压缩算法、加密算法和MAC算法。TLS记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和MAC密钥。TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。关系就是。。。。并列关系最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。1．TLS与SSL的差异1）版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。2）报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。3）伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。4）报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。5）密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。6）certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。7）加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。8）填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。2．TLS的主要增强内容TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：1）更安全的MAC算法2）更严密的警报3）“灰色区域”规范的更明确的定义3．TLS对于安全性的改进1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。 TLS：（Transport Layer Security，传输层安全协议），用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

资料来自百度百科 TLSTLS：安全传输层协议（TLS：Transport Layer Security Protocol）安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 TLS 记录协议提供的连接安全性具有两个基本特性：私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。可靠――信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 TLS 握手协议提供的连接安全具有三个基本属性：可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。TLS 的最大优势就在于：TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而， TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。协议结构TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。TLS 连接状态指的是 TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。 TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。改变密码规格协议警惕协议 握手协议
词名：TLS 中文解释：传输层安全；传送层安全缩写：TLS来历：Transport Layer Security TLS是IETF的SSL(安全套接层)3．0版。IETF曾设法使SSL标准化，但不愿意使用RSA Security的专有加密技术，因此它开始致力于TLS(传输层安全)，TLS使用Diffie-Hellman公钥密码技术。如在RFC 2246(The TLS Protocol，Version 1．0，January 1999)所概述的，TLS还使用了HMACTLS。另请参阅“SSL(安全套接层)”。 根据RFC 2316(Report of the IAB，April 1998)，HMAC(散列消息身份验证码)以及IPSec被认为是Interact安全的关键性核心协议。它不是散列函数，而是采用了将MD5或SHA．1散列函数与共享机密密钥(与公钥／私钥对不同)一起使用的消息身份验证机制。基本来说，消息与密钥组合并运行散列函数。然后运行结果与密钥组合并再次运行散列函数。这个128位的结果被截断成96位，成为MAC。 RFC 2104(HMAC：Keyed—Hashing for Message Authentication，February 1997)说明了应该如何优先使用HMAC(优先于旧技术，特别加密的散列函数)。由于MD5的一些弱点，特别应该避免基于MD5的加密散列。HMAC是首选的共享机密身份验证技术，应该与SHA．1结合使用。它可以用于验证任意消息并适于登录。

https, 全称Hyper Text Transfer Protocol Secure，相比http，多了一个secure，这一个secure是怎么来的呢？这是由TLS（SSL）提供的，这个又是什么呢？估计你也不想知道。大概就是一个叫openSSL的library提供的。https和http都属于application layer，基于TCP（以及UDP）协议，但是又完全不一样。TCP用的port是80， https用的是443（值得一提的是，google发明了一个新的协议，叫QUIC，并不基于TCP，用的port也是443， 同样是用来给https的。谷歌好牛逼啊。）总体来说，https和http类似，但是比http安全。 http缺省工作在TCP协议80端口(需要国内备案），用户访问网站http://打头的都是标准http服务，http所封装的信息都是明文的，通过抓包工具可以分析其信息内容，如果这些信息内容包含你的银行卡账号、密码，你肯定无法接受这种服务，那有没有可以加密这些敏感信息的服务呢？那就是https！https是http运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。https缺省工作在tcp协议443端口，它的工作流程一般如以下方式：1、完成tcp三次同步握手；2、客户端验证服务器数字证书，通过，进入步骤3；3、DH算法协商对称加密算法的密钥、hash算法的密钥；4、SSL安全加密隧道协商完成；5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。附：https一般使用的加密与hash算法如下：非对称加密算法：RSA，DSA/DSS对称加密算法：AES，RC4，3DEShash算法：MD5，SHA1，SHA256如果https是网银服务，以上SSL安全隧道成功建立才会要求用户输入账户信息，账户信息是在安全隧道里传输，所以不会泄密！TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。Web使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模型中的位置：CA证书是什么？CA（Certificate Authority）是负责管理和签发证书的第三方权威机构，是所有行业和公众都信任的、认可的。CA证书，就是CA颁发的证书，可用于验证网站是否可信（针对HTTPS）、验证某文件是否可信（是否被篡改）等，也可以用一个证书来证明另一个证书是真实可信，最顶级的证书称为根证书。除了根证书（自己证明自己是可靠），其它证书都要依靠上一级的证书，来证明自己。https大致过程：1、建立服务器443端口连接 ；2、SSL握手：随机数，证书，密钥，加密算法；3、发送加密请求 ；4、发送加密响应；5、关闭SSL；6、关闭TCP.SSL握手大致过程：1、客户端发送随机数1，支持的加密方法（如RSA公钥加密）；2、服务端发送随机数2，和服务器公钥，并确认加密方法；3、客户端发送用服务器公钥加密的随机数3；4、服务器用私钥解密这个随机数3，用加密方法计算生成对称加密的密钥给客户端；5、接下来的报文都用双方协定好的加密方法和密钥，进行加密.1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流（流模式）;UDP是面向报文的（报文模式），UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信5、TCP要求系统资源较多，UDP较少。TCP首部开销20字节;UDP的首部开销小，只有8个字节SYN：同步序列编号;   ACK=1: 确认序号 ;  FIN附加标记的报文段（FIN表示英文finish）一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的 描述下这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步 （同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同 步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。为什么需要“三次握手”?在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“ 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误 ”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不一样的表述其实阐明的是同一个问题。谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。 本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。为什么需要“四次挥手”？可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是 因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。握手，挥手过程中各状态介绍:3次握手过程状态：LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。SYN_SENT : 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。（发送端）SYN_RCVD : 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。（服务器端）ESTABLISHED ：这个容易理解了，表示连接已经建立了。4次挥手过程状态：（可参考下图）：FIN_WAIT_1:这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态， 当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示 半连接 ，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文 ，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）CLOSING（比较少见）:这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。CLOSE_WAIT:这种状态的含义其实是表示在等待关闭。怎么理解呢？ 当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。 所以你在 CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。 （被动方）LAST_ACK:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）CLOSED:表示连接中断。 TCP的具体状态图可参考：

安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。TLS 连接状态指的是TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。 TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。