tls和tcp关系(tls和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的关系比较复杂。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中所做的。

1969年11月，美国国防部 高级研究计划管理局（ ARPA 全称： Advanced Research Projects Agency）开始建立一个命名为ARPAnet的网络，这是就是互联网的前身，一个军事用途的网络。 随着ARPAnet网络的逐渐发展，更多的主机接入，原来的架构和协议已经不够用了，研究人员把重点投向了第二代网络协议的研究，于是TCP/IP协议簇出现了。而TCP/IP簇使用的网络参考模型就是TCP/IP参考模型，我们称之为“五层网络模型”。当然也有人说这个TCP/IP参考模型是四层的，不是五层的。其实这么理解也是对的，TCP/IP参考模型只是一种概念，并没有相关的标准。TCP/IP协议里边 只是要求能够提供给其上层-网络互连层（Internet layer）一个访问接口，以便在其上传递IP分组就可以。由于这一层次未被定义，所以其具体的实现方法将随着网络类型的不同而不同。全称Open Systems Interconnection Reference Model，即“开放式系统互连参考模型”，是七层参考模型。1978年（或1979年），为了统一网络系统的体系结构，ISO（International Standards Organization国际标准化组织）和CCITT（International Telegraph and Telephone Consultative Committee国际电报电话咨询委员会）分别起草了定义网络模型的文档。1983年，这两份文档合并，形成一个标准，称为开放系统互连的基本参考模型（the OSI Reference Model）。它把通信系统划分成七个不同的抽象层，每一层服务于上一层，并由下面的层提供服务。1984年，该标准分别被列入了ISO标准（ISO 7498) 和 CCITT标准（X.200）。无论是TCP/IP四层模型还是OSI七层模型，简单来讲，发送数据的时候就是数据经过层层包装，包装成每一层能看得明白的信息，然后到了物理层转化成了二进制流，发送出去，接收方再经过逆向的层层剥离，把数据拿出来，最后就完成了数据的传输。无论OSI 或TCP/IP 参考模型都有成功和不足的方面。ISO本来计划通过推动OSI参考模型与协议的研究来促进网络标准化，但是事实上这个目标没有达到。TCP/IP 协议利用正确的策略，抓住有利的时机，伴随着互联网发展而成为目前公认的工业标准。在网络标准化的进程中，人们面对着的就是这样一个事实。OSI 参考模型由于要照顾各方面的因素，使得OSI参考模型变得大而全、效率低。尽管这样，它的很多研究结果、方法对今后网络的发展有很好的指导意义、并且经常被用于教学。TCP/IP 协议的应用非常广泛，但是它的参考模型研究却很薄弱。HTTP通信，是不加密的通信。所有信息明文传播，带来了三大风险。而SSL/TLS协议的诞生便是为了解决这三大风险：HTTPS就是在TCP协议层和HTTP协议层中间架起了一层SSL/TSL协议层，这一层能够把在网络中传输的数据进行有效的加密。下面是基于SSL协议的五层网络模型图：https支持单向认证（只验证服务端证书的有效性），也支持双向验证（既验证服务端证书的有效性也验证客户端证书的有效性）SSL（Secure Sockets Layer安全套接层），是一种网络安全协议。主要依赖数字证书、非对称加密、对称加密、数据完整性校验以及随机数这5个密码学的基础知识，构建出一个完整可信的传输链。TLS（Transport Layer Security传输层安全协议），是基于SSL协议的通用化协议，正逐步替代SSL。SSL/TLS分为两层，一层是记录协议（建立在可靠的传输协议上（比如tcp），提供数据封装，加密解密，数据建议等基本功能），一层是握手协议（建立在记录协议上，在实际的数据传输开始前，进行加密算法的协商，通信密钥的交换等）。目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息并发送给服务器，服务器收到密文后，用自己的私钥解密。那么，非对称加密的引入是否解决了数据传输的安全问题？这个问题大家可以思考一下，我们稍后再讨论。另外，细心的人都会发现，非对称加密机制的安全性，必须建立在公钥的安全发放这个大前提上。毕竟在大多数情况下，通信双方并不是面对面的，无法通过安全可靠的物理介质交换公钥，公钥本身也是通过网络传输的，那么，如何防止公钥的传输过程被攻击？举个简单的例子，A和B为了通信安全，约定使用非对称加密进行通信，在开始加密通信前，B需要通过网络向A发放自己的公钥B’和一段密文，但此时C截获了B‘的发放过程，将自己伪装成B，并将自己的公钥C‘和自己的私钥加密的一段密文发放给了A，A拿到C’后，验证解密过程成功，就以为自己拿到的确实是B‘，于是开始了加密通信，这样，A和B都以为自己在和对方通信，但实际上他们其实各自在和C通信，此时C就可以为所欲为。针对公钥的安全发放问题，解决办法就是数字证书。私钥持有者需要向CA购买数字证书，将公钥放在数字证书中传输，任何第三方只要验证了数字证书是可信的，就可以相信该证书中的公钥是可信的。然而，细心的人可能又有疑问了：数字证书会不会也存在问题，换句话说，如何保证数字证书的有效安全？数字证书的非法可能有两种情况：数字证书的可靠性，就要靠数字签名来保证了。关于数字证书和数字签名的详细介绍，参考我的另一篇文章 《信息安全的护城河：数字证书与数字签名技术》 ，这里不再赘述。解决了证书的安全发放问题后，再回头看第一个问题：非对称加密的引入是否解决了数据传输的安全问题？答案是，还不够！为什么这么说？因为非对称加密只能保证数据的传输单向安全。所谓非对称加密，就是一方加密的信息，只能由另一方解密。虽然私钥只有自己（服务器）持有，但是公钥却是公开的，任何人都可以持有公钥，那么服务器用私钥加密过的信息，任何持有公钥的人都可以解密出来，换句话说，服务器的数据相当于是在网络上换了种方式裸奔。※引申思考：既然私钥加密的数据并没有隐私性可言，是不是私钥加密就没有用处了？说到这里，你可能会有疑惑：加入了SSL加密层，服务器数据还是在裸奔，还不如直接用HTTP来的省事。非也非也，单纯的非对称加密确实只能保证数据传输的单向安全。然而SSL不仅用了非对称加密，同时还结合了对称加密机制，来确保数据传输的双向安全，而这同时也解决了非对称加密效率过低的弊病。概括来说，整个简化的加密通信的流程就是：上述过程的前4步，又称为“握手阶段”。首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息：服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容：除此之外，如果服务器需要使用双向认证，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。上面的随机数C，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"（对称密钥）。然后，向客户端最后发送下面信息。（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。Stackoverflow 的创始人也曾经针对为什么Stackoverflow不使用https做出了回答： Stackoverflow.com: the road to SSL «Nick Craver关于HTTPS，经常会提到的就是中间人攻击，即所谓的Man-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到原本直接通信的双方，让双方以为还在直接跟对方通讯，但实际上双方的通信对方已变成了中间人，信息已经被中间人获取或篡改。此类攻击较为简单常见。首先通过ARP欺骗、DNS劫持甚至网关劫持等等，将客户端的访问重定向到攻击者的机器，让客户端机器与攻击者机器建立HTTPS连接（使用伪造证书），而攻击者机器再跟服务端连接。这样用户在客户端看到的是相同域名的网站，但浏览器会提示证书不可信，用户不点击“继续浏览”就能避免被劫持。所以这是最简单的攻击方式，也是最容易识别的攻击方式。SSL剥离，即将HTTPS连接降级到HTTP连接。假如客户端直接访问HTTPS的URL，攻击者是没办法直接进行降级的，因为HTTPS与HTTP虽然都是TCP连接，但HTTPS在传输HTTP数据之前，需要进行SSL握手，并协商对称密钥用于后续的加密传输；假如客户端与攻击者进行SSL握手，而攻击者无法提供可信任的证书来让客户端验证通过进行连接，所以客户端的系统会判断为SSL握手失败，断开连接。该攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站，或者有些网站并非全网HTTPS，而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后，将HTTP页面里面所有的https://超链接都换成http://，用户在点击相应的链接时，是使用HTTP协议来进行访问；这样，就算服务器对相应的URL只支持HTTPS链接，但中间人一样可以和服务建立HTTPS连接之后，将数据使用HTTP协议转发给客户端，实现会话劫持。这种攻击手段更让人难以提防，因为它使用HTTP，不会让浏览器出现HTTPS证书不可信的警告，而且用户很少会去看浏览器上的URL是https://还是http://。特别是App的WebView中，应用一般会把URL隐藏掉，用户根本无法直接查看到URL出现异常。下面开始讲一个无聊的故事，和问题关系不大，时间紧张的看官可以到此为止了。从前山上有座庙，庙里有个和尚......，别胡闹了，老和尚来了。小和尚问老和尚：ssl为什么会让http安全？老和尚答道：譬如你我都有一个同样的密码，我发信给你时用这个密码加密，你收到我发的信，用这个密码解密，就能知道我信的内容，其他的闲杂人等，就算偷偷拿到了信，由于不知道这个密码，也只能望信兴叹，这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密，所以让http安全了，常用的加解密算法主要有3DES和AES等。小和尚摸摸脑袋问老和尚：师傅，如果我们两人选择“和尚”作为密码，再创造一个和尚算法，我们俩之间的通信不就高枕无忧了？老和尚当头给了小和尚一戒尺：那我要给山下的小花写情书，还得用“和尚”这个密码不成？想了想又给了小和尚一戒尺：虽然我们是和尚，不是码农，也不能自己造轮子，当初一堆牛人码农造出了Wifi的安全算法WEP，后来发现是一绣花枕头，在安全界传为笑谈；况且小花只知道3DES和AES，哪知道和尚算法？小和尚问到：那师傅何解？老和尚：我和小花只要知道每封信的密码，就可以读到对方加密的信件，关键是我们互相之间怎么知道这个对称密码。你说，我要是将密码写封信给她，信被别人偷了，那大家不都知道我们的密码了，也就能够读懂我们情书了。不过还是有解的，这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码，一个叫“公钥”，一个叫“私钥”，公钥发布到了江湖上，好多人都知道，私钥嘛，江湖上只有我一个人知道；这两个密钥有数学相关性，就是说用公钥加密的信件，可以用私钥解开，但是用公钥却解不开。公钥小花是知道的，她每次给我写信，都要我的公钥加密她的对称密码，单独写一张密码纸，然后用她的对称密码加密她的信件，这样我用我的私钥可以解出这个对称密码，再用这个对称密码来解密她的信件。老和尚顿了顿：可惜她用的对称密码老是“和尚为什么写情书”这一类，所以我每次解开密码纸时总是怅然若失，其实我钟意的对称密码是诸如“风花”“雪月”什么的，最头痛的是，我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书，人世间最痛苦的事莫过于如此。可我哪里知道，其实有人比我更痛苦。山下的张屠夫，暗恋小花很多年，看着我们鸿雁传书，心中很不是滋味，主动毛遂自荐代替香客给我们送信。在他第一次给小花送信时，就给了小花他自己的公钥，谎称是我公钥刚刚更新了，小花信以为真，之后的信件对称密码都用张屠夫的这个公钥加密了，张屠夫拿到回信后，用他自己的私钥解开了小花的对称密码，然后用这个对称密码，不仅能够看到了小花信件的所有内容，还能使用这个密码伪造小花给我写信，同时还能用他的私钥加密给小花的信件。渐渐我发现信件变味了，尽管心生疑惑，但是没有确切的证据，一次我写信问小花第一次使用的对称密码，回信中“和尚为什么写情书”赫然在列，于是我的疑惑稍稍减轻。直到有一次去拜会嵩山少林寺老方丈才顿悟，原来由于我的公钥没有火印，任何人都可以伪造一份公钥宣称是我的，这样这个人即能读到别人写给我的信，也能伪造别人给我写信，同样也能读到我的回信，也能伪造我给别人的回信，这种邪门武功江湖上称之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印，这个火印可有讲究了，需要将我的公钥及个人在江湖地位提交给18罗汉委员会，他们会根据我的这些信息使用委员会私钥进行数字签名，签名的信息凸现在火印上，有火印的公钥真实性在江湖上无人质疑，要知道18罗汉可是无人敢得罪的。小和尚问：那然后呢？老和尚：从嵩山少林寺回山上寺庙时，我将有火印的公钥亲自给小花送去，可是之后再也没有收到小花的来信。过了一年才知道，其实小花还是给我写过信的，当时信确实是用有火印的公钥加密，张屠夫拿到信后，由于不知道我的私钥，解不开小花的密码信，所以一怒之下将信件全部烧毁了。也由于张屠夫无法知道小花的对称密码而无法回信，小花发出几封信后石沉大海，也心生疑惑，到处打听我的近况。这下张屠夫急了，他使用我发布的公钥，仿照小花的语气，给我发来一封信。拿到信时我就觉得奇怪，信纸上怎么有一股猪油的味道，结尾竟然还关切的询问我的私钥。情知有诈，我思量无论如何要找到办法让我知道来的信是否真是小花所写。后来竟然让我想到了办法....老和尚摸着光头说：这头发可不是白掉的，我托香客给小花带话，我一切安好，希望她也拥有属于自己的一段幸福，不对，是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后，托香客给我送来，这样小花在每次给我写信时，都会在密码纸上贴上一朵小牡丹，牡丹上写上用她自己的私钥加密过的给我的留言，这样我收到自称是小花的信后，我会先抽出密码纸，取下小牡丹，使用小花的公钥解密这段留言，如果解不出来，我会直接将整封信连同密码纸一起扔掉，因为这封信一定不是小花写的，如果能够解出来，这封信才能确信来之于小花，我才仔细的解码阅读。 小和尚：难怪听说张屠夫是被活活气死的。您这情书整的，我头都大了，我长大后，有想法直接扯着嗓子对山下喊，也省的这么些麻烦。不过我倒是明白了楼上的话，ssl 握手阶段，就是要解决什么看火印，读牡丹，解密码纸，确实够麻烦的，所以性能瓶颈在这里，一旦双方都知道了对称密码，之后就是行云流水的解码读信阶段了，相对轻松很多。

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作用于应用层和运输层之间。如果硬要说在哪个位置，那就是：会话层