tls和tcp关系(tls和https的关系)

按照OSI网络分层模型，IP是网络层协议，TCP是传输层协议，而HTTP是应用层的协议。在这三者之间，SPDY和 WebSocket都是与HTTP相关的协议，而TCP是HTTP底层的协议。一、HTTP的不足HTTP协议经过多年的使用，发现了一些不足，主要是性能方面的，包括：HTTP的连接问题，HTTP客户端和服务器之间的交互是采用请求/应答模式，在客户端请求时，会建立一个HTTP连接，然后发送请求消息，服务端给出应答消息，然后连接就关闭了。（后来的HTTP1.1支持持久连接）因为TCP连接的建立过程是有开销的，如果使用了SSL/TLS开销就更大。在浏览器里，一个网页包含许多资源，包括HTML，CSS，JavaScript，图片等等，这样在加载一个网页时要同时打开连接到同一服务器的多个连接。HTTP消息头问题，现在的客户端会发送大量的HTTP消息头，由于一个网页可能需要50­100个请求，就会有相当大的消息头的数据量。HTTP通信方式问题，HTTP的请求/应答方式的会话都是客户端发起的，缺乏服务器通知客户端的机制，在需要通知的场景，如聊天室，游戏，客户端应用需要不断地轮询服务器。而SPDY和WebSocket是从不同的角度来解决这些不足中的一部分。除了这两个技术，还有其他技术也在针对这些不足提出改进。二、SPDYSPDY的主要目的是减少50%以上的页面加载时间，但是呢不增加部署的复杂性，不影响客户端和服务端的Web应用，只需要浏览器和Web服务器支持SPDY。主要有以下几点：多路复用，一个TCP连接上同时跑多个HTTP请求。请求可设定优先级。去除不需要的HTTP头，压缩HTTP头，以减少需要的网络带宽。使用了SSL作为传输协议提供数据安全。对传输的数据使用gzip进行压缩提供服务方发起通信，并向客户端推送数据的机制。实质上，SPDY就是想不影响HTTP语义的情况下，替换HTTP底层传输的协议来加快页面加载时间。SPDY的解决办法就是设计了一个会话层协议­­帧协议，解决多路复用，优先级等问题，然后在其上实现了HTTP的语义。三、WebSocketWebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。WebSocket也有自己一套帧协议。四、SPDY和WebSocket的关系SPDY和WebSocket的关系比较复杂。1.补充关系，二者侧重点不同。SPDY更侧重于给Web页面的加载提速，而WebSocket更强调为Web应用提供一种双向的通讯机制以及API。2. 竞争关系，二者解决的问题有交集，比如在服务器推送上SPDY和WebSocket都提供了方案。3. 承载关系，试想，如果SPDY的标准化早于WebSocket，WebSocket完全可以侧重于API，利用SPDY的帧机制和多路复用机制实现该API。 Google提出草案，说WebSocket可以跑在SPDY之上。WebSocket的连接建立在SPDY的流之上，将WebSocket的帧映射到SPDY的帧上。 4. 融合关系，如微软在HTTP Speed+Mobility中所做的。

SSL 和 TLS 协议可以为通信双方提供识别和认证通道，从而保证通信的机密性和数据完整性。TLS 协议是从Netscape SSL 3.0协议演变而来的，不过这两种协议并不兼容，SSL 已经被 TLS 取代，所以下文就以 TLS 指代安全层。 TLS 握手是启动 HTTPS 通信的过程，类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中，通信双方交换消息以相互验证，相互确认，并确立它们所要使用的加密算法以及会话密钥 (用于对称加密的密钥)。可以说，TLS 握手是 HTTPS 通信的基础部分。
HTTPS是基于SSL安全连接的HTTP协议。HTTPS通过SSL提供的数据加密、身份验证和消息完整性验证等安全机制，为Web访问提供了安全性保证，广泛应用于网上银行、电子商务等领域。此图为HTTPS在网上银行中的应用。某银行为了方便客户，提供了网上银行业务，客户可以通过访问银行的Web服务器进行帐户查询、转帐等。通过在客户和银行的Web服务器之间建立SSL连接，可以保证客户的信息不被非法窃取。2.只需要验证SSL服务器身份，不需要验证SSL客户端身份时，SSL的握手过程为：(1)        SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。(2)        SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。(3)        SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。(4)        SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。(5)        SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的premaster secret，并通过Client Key Exchange消息发送给SSL服务器。(6)        SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。(7)        SSL客户端计算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。(8)        同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。(9)        SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。&  说明：l      Change Cipher Spec消息属于SSL密码变化协议，其他握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。l      计算Hash值，指的是利用Hash算法（MD5或SHA）将任意长度的数据转换为固定长度的数据。
通过抓包工具看，是tcpip先握手，当tcp连接成功后，在进入tls,如果tls证书检验成功，则开始正常收发数据
是在tls层 请求的证书可以看看阮一峰的ssl 文章  经过四次握手网页链接

传输控制协议( TCP ) 是Internet 协议套件的主要协议之一。起源于最初的网络实现，它补充了Internet 协议(IP)。因此，整个套件通常称为TCP/IP。TCP在通过 IP 网络通信的主机上运行的应用程序之间提供可靠的、有序的和经过错误检查的八位位组（字节）流传输。主要的互联网应用程序，例如万维网、电子邮件、远程管理和文件传输依赖于 TCP，它是TCP/IP 套件传输层的一部分。SSL/TLS通常运行在 TCP 之上。TCP 是面向连接的，在发送数据之前，客户端和服务器之间建立了连接。在建立连接之前，服务器必须正在侦听（被动打开）来自客户端的连接请求。三向握手（主动打开）、重传和错误检测增加了可靠性，但延长了延迟。不需要可靠数据流服务的应用程序可以使用用户数据报协议(UDP)，它提供了一种无连接 数据报服务，它优先考虑时间而不是可靠性。TCP 采用网络拥塞避免。但是，TCP 存在漏洞，包括拒绝服务、连接劫持、TCP 否决和重置攻击。网络功能传输控制协议在应用程序和 Internet 协议之间提供中间级别的通信服务。它在Internet 模型的传输层提供主机到主机的连接。应用程序不需要知道通过链接将数据发送到另一台主机的特定机制，例如为容纳传输介质的最大传输单元所需的IP 分段。在传输层，TCP 处理所有握手和传输细节，并通常通过网络套接字接口向应用程序提供网络连接的抽象。在协议栈的较低级别，由于网络拥塞、流量负载平衡或不可预测的网络行为，IP 数据包可能会丢失、重复或乱序传送。TCP 检测到这些问题，请求重新传输丢失的数据，重新排列乱序数据，甚至帮助最小化网络拥塞以减少其他问题的发生。如果数据仍未交付，则会通知源此失败。一旦 TCP 接收器重新组合了最初传输的八位字节序列，它就会将它们传递给接收应用程序。因此，TCP从底层网络细节中 抽象出应用程序的通信。

前言：之前有个误解，我一直以为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作用于应用层和运输层之间。如果硬要说在哪个位置，那就是：会话层

按照OSI网络分层模型，IP是网络层协议，TCP是传输层协议，而HTTP是应用层的协议。在这三者之间，SPDY和WebSocket都是与HTTP相关的协议，而TCP是HTTP底层的协议。 一、HTTP的不足HTTP协议经过多年的使用，发现了一些不足，主要是性能方面的，包括：HTTP的连接问题，HTTP客户端和服务器之间的交互是采用请求/应答模式，在客户端请求时，会建立一个HTTP连接，然后发送请求消息，服务端给出应答消息，然后连接就关闭了。（后来的HTTP1.1支持持久连接）因为TCP连接的建立过程是有开销的，如果使用了SSL/TLS开销就更大。在浏览器里，一个网页包含许多资源，包括HTML，CSS，JavaScript，图片等等，这样在加载一个网页时要同时打开连接到同一服务器的多个连接。HTTP消息头问题，现在的客户端会发送大量的HTTP消息头，由于一个网页可能需要50-100个请求，就会有相当大的消息头的数据量。HTTP通信方式问题，HTTP的请求/应答方式的会话都是客户端发起的，缺乏服务器通知客户端的机制，在需要通知的场景，如聊天室，游戏，客户端应用需要不断地轮询服务器。而SPDY和WebSocket是从不同的角度来解决这些不足中的一部分。除了这两个技术，还有其他技术也在针对这些不足提出改进。二、SPDYSPDY的主要目的是减少50%以上的页面加载时间，但是呢不增加部署的复杂性，不影响客户端和服务端的Web应用，只需要浏览器和Web服务器支持SPDY。主要有以下几点：多路复用，一个TCP连接上同时跑多个HTTP请求。请求可设定优先级。去除不需要的HTTP头，压缩HTTP头，以减少需要的网络带宽。使用了SSL作为传输协议提供数据安全。对传输的数据使用gzip进行压缩提供服务方发起通信，并向客户端推送数据的机制。实质上，SPDY就是想不影响HTTP语义的情况下，替换HTTP底层传输的协议来加快页面加载时间。SPDY的解决办法就是设计了一个会话层协议--帧协议，解决多路复用，优先级等问题，然后在其上实现了HTTP的语义。三、WebSocketWebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。WebSocket也有自己一套帧协议。四、SPDY和WebSocket的关系SPDY和WebSocket的关系比较复杂。补充关系，二者侧重点不同。SPDY更侧重于给Web页面的加载提速，而WebSocket更强调为Web应用提供一种双向的通讯机制以及API。竞争关系，二者解决的问题有交集，比如在服务器推送上SPDY和WebSocket都提供了方案。承载关系，试想，如果SPDY的标准化早于WebSocket，WebSocket完全可以侧重于API，利用SPDY的帧机制和多路复用机制实现该API。 Google提出草案，说WebSocket可以跑在SPDY之上。WebSocket的连接建立在SPDY的流之上，将WebSocket的帧映射到SPDY的帧上。融合关系，如微软在HTTP Speed+Mobility中所做的。五、题外话1. HTTP Speed+Mobility还有一个有趣的技术叫做HTTP Speed+Mobility，和SPDY一样都是HTTP 2.0标准的竞争者，HTTP Speed+Mobility来自微软。HTTP SM借鉴了SPDY和WebSocket的协议，将二者揉为一体，又有所取舍。HTTP SM的设计原则包括：保留HTTP的语义，这一点和SPDY一致，但也正应如此，抛弃了SPDY里的ServerPush。遵守分层的网络架构，TCP能做的，HTTP SM不做，因此去除了SPDY的流控。使用现有标准，因此使用HTTP/1.1 Upgrade header机制，借用了WebSocket的握手机制和帧格式（RFC6455）。客户端掌握内容的控制，因此不强制使用压缩和SSL/TLS。考虑到网络的费用和电力，这点考虑到了移动设备以及物联网，提供了Credit Control机制。HTTP SM分以下几层：会话层和帧协议，这部分取自WebSocket协议。包括握手机制，以及帧格式。流层（包括多路复用），这部分主要借鉴SPDY，包括多路复用，流优先级，但增加了Credit Control。这部分作为 WebSocket协议的扩展。HTTP层，在流层上实现HTTP语义，这部分也借鉴自SPDY。2. Network-Friendly HTTPNF是HTTP 2.0候选方案之一，主要提出以下改进：对HTTP头的名称进行二进制编码对通用HTTP头进行分组请求/应答的多路复用分层模型NF同样定义了帧和流，3. WAKAWAKA也是HTTP 2.0候选方案之一，是HTTP协议原作者Roy Fielding提出的一个提案。 WAKA支持多路复用，支持优先级。WAKA提出了两个新的HTTP方法，RENDER和MONITOR。