tcp为什么可靠,提供可靠传输的传输层协议是可靠传输的协议是什么
tcp为什么可靠,提供可靠传输的传输层协议是可靠传输的协议是什么详细介绍
本文目录一览： 在Internet的通信协议中，可靠的数据传输是由什么协议来保证的？
TCP协议。
TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。
原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。
扩展资料：
TCP三次握手的过程如下：
客户端发送SYN（SEQ=x）报文给服务器端，进入SYN_SEND状态。
服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK（ACK=x+1）报文，进入SYN_RECV状态。
客户端收到服务器端的SYN报文，回应一个ACK（ACK=y+1）报文，进入Established状态。三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。
TCP怎么保证可靠性的？
如今大家每天浏览网页里的购物网站，使用各种网页工具生活和学习，都使用了网页架构依赖的基础——TCP协议，浏览网页时经常需要输入http网址，而http协议下层协议就是TCP协议，我们在浏览http链接访问到网页时，如果网速正常的话，我们基本不会有数据丢失的感觉，这就是TCP在为我们保驾护航。
TCP在工作中既要保证数据发送的可靠性，又要保证数据发送的效率，也就是单位时间内数据吞吐量，还要减少丢包率，同时要保证低延时。
TCP在我们日常生活中的广泛应用中，它的可靠性保证了我们最核心的诉求之一——数据不会轻易丢失。那么数据在网络中传输，面对日益复杂的通信网络环境，它是怎么保证数据发送和接收顺序的呢？
实际工作中TCP是按照需要的顺序发送数据的，但是，却不能保证接收的顺序就是发送的顺序，如果接收的顺序不对，是怎样恢复到我们想要的顺序的呢，接下来我探讨一下 TCP的拆包和粘包
TCP在传输数据时，我们通常是感觉不到的，只知道把需要传输的文件和主机链接传给TCP，它就会把文件发送到我们指定的接收方，那么如果我们给他一个20MB的文件，TCP是一次就传输一个大小20MB的数据包吗，通常受各种条件限制和各种系统工作的限制，TCP会将要传输的文件拆分为适合当下操作系统等受限条件的数据包大小。
那么拆分包的意义是什么呢，当我们运送大批货物时，如果超出一辆卡车的运力，我们就需要用一辆卡车分成很多次把货物从一个仓库运到接收方的仓库，而拆包也是这个道理。数据在网络中传输时，受物理条件，比如我们常说的带宽等的限制，肯定会不断的调整拆包的大小，那么影响拆包大小，或者是否拆包的因素有哪些呢？
拆包 就是在发送方把大数据拆分成小数据，传送到接收方，再组装起来，具体怎么操作我们后续分析。 当然既然有拆包的需求，那也会有粘包的需求， 粘包 就是数据包太小，不值得单独发送一次，这时还有其他待传输数据，可以把比较小的数据，放在一起传输到接收方，到达接收方后，我们再拆分为多个数据。
当然，无论拆包还是粘包的过程中，都需要计算出一个合适大小的数据包，我们管这个数据包称为 TCP段（TCP Segment）
下面是TCP的主要组成部分
从图中可以看出TCP的主要组成
MSS（Maximum Segment Size） MSS是option中可选项，它用来控制TCP段大小，通过协商（Negotiate）来确定的，需要双方共同决定它最终的使用大小。
MSS是实际发送和缓冲区中TCP段的大小，是双方协商得来的，不是那一方决定的。
MSS不能设为太大的值，因为大会影响服务器的内存操作效率，也会占用过多的资源，影响其他用户请求的响应实效。
同时，传输层下层的网络层使用的IP层 也会受到影响，如果TCP协议不拆包，那么IP协议就得拆包，因为IP协议受限于网络物理条件的限制，每次传输的包需要在一定限度以下，同时拆分大量的包，会对资源和计算能力提出更高的要求，造成传输效率的延迟。
当然，也不能包越小越好，拆出的包都需要安装协议头，如果包太小，那么协议头就会占据包体积的很大比重，会成为负担，浪费资源利用率， 所以，我们需要协商解决包的大小 ，只有通过协商得到的，才是最优的解决方案。
提供可靠传输的传输层协议是可靠传输的协议是什么
1、提供可靠传输的传输层协议是TCP。TCP（TransmissionControlProtocol传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC793定义。2、TCP是面向连接的通信协议，通过三次握手建立连接，通讯完成时要拆除连接，由于TCP是面向连接的所以只能用于端到端的通讯。提供的是一种可靠的数据流服务，采用“带重传的肯定确认”技术来实现传输的可靠性。3、TCP还采用一种称为“滑动窗口”的方式进行流量控制，所谓窗口实际表示接收能力，用以限制发送方的发送速度。
tcpip协议为什么能沿用至今？
TCP/IP协议成功得到推广和应用是因为其以下主要优点：
1.开放的协议标准，可以免费使用，并且独立于特定的计算机硬件与操作系统；
2.独立于特定的网络硬件，可以运行在局域网、广域网，更适用于互联网络中；
3.统一的网络地址分配方案，所有网络设备在Internet中都有唯一的地址；
4.标准化的高层次协议，可以提供多种可靠的用户服务。
随着Internet的高速发展，TCP/IP协议与
体系结构已成为业内公认的标准
TCP的可靠性与提高性能详解
保证可靠性的机制：
提高性能机制：
定时器：
基于TCP的应用协议：HTTP、HTTPS、SSH、Telnet、FTP、SMTP
目的 是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到检验和有差错，则TCP段会被直接丢弃。 TCP计算校验和时，要加上一个12字节的伪首部。
去重， 用来解决网络包乱序问题。
每组数据都会有一个序列号seq = x，如果收到数据会发送对应确认号ack = x + 1
用来解决不丢包的问题。
主机没收到应答有两种情况：
如果发送端发送数据太快，接收端来不及接收，可能会丢失数据。所以流量控制是让发送端不要发送太快，要让接收端来得及接收。 是通过大小可变的 滑动窗口 实现的。
提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。 发送端向网络一次连续写入的数据量，我们称为SWND（Send Window，发送窗口） 这些TCP报文段的最大长度（仅数据部分）称为SMSS（Sender Maximum Segment Size，发送者最大段大小），其值一般等于MSS。 引入一个称为拥塞窗口（Congestion Window,CWND）的状态变量.
三次握手可以防止已经失效的连接请求报文突然又传输到服务器端导致的服务器资源浪费。 例如，客户端先发送了一个SYN，但是由于网络阻塞，该SYN数据包在某个节点长期滞留。然后客户端又重传SYN数据包并正确建立TCP连接，然后传输完数据后关闭该连接。该连接释放后失效的SYN数据包才到达服务器端。 在二次握手的前提下，服务器端会认为这是客户端发起的又一次请求 ，然后发送SYN ，并且在服务器端创建socket套接字，一直等待客户端发送数据。但是由于客户端并没有发起新的请求，所以会丢弃服务端的SYN 。 此时服务器会一直等待客户端发送数据 从而造成资源浪费。
由于连接的关闭控制权在应用层，所以被动关闭的一方在接收到FIN包时，TCP协议栈会直接发送一个ACK确认包，优先关闭一端的通信。然后通知应用层，由应用层决定什么时候发送FIN包。应用层可以使用系统调用函数read==0来判断对端是否关闭连接。
TCP 如何保证可靠性
[TOC]
1. TCP可靠性的保证机制总结
2. 网络基础：TCP协议-如何保证传输可靠性
3. TCP协议的流量控制和拥塞控制
4. TCP 的那些事儿（下）
5. TCP拥塞控制：慢开始、拥塞避免、快重传、快恢复
TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为：在发送方将整个报文段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确（UDP中也是全为1则正确），否则存在错误。
TCP将每个数据包都进行了编号，这就是序列号。
序列号的作用：
a、保证可靠性（当接收到的数据总少了某个序号的数据时，能马上知道）
b、保证数据的按序到达
c、提高效率，可实现多次发送，一次确认
d、去除重复数据
数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现
TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。
当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）。
一种情况是发送包丢失了，其基本过程如下：
另一种情况是ACK 丢失，过程如下：
当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，前面提到的序列号就起作用了。
重传时间的确定：
重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2 500ms后再进行重传，如果仍然得不到应答就等待4 500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。
连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。
接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，导致接收端的缓冲区满，而发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫做流量控制。
在TCP报文段首部中有一个16位窗口长度，当接收端接收到发送方的数据后，在应答报文ACK中就将自身缓冲区的剩余大小，放入16窗口大小中。这个大小随数据传输情况而变，窗口越大，网络吞吐量越高，而一旦接收方发现自身的缓冲区快满了，就将窗口设置为更小的值通知发送方。如果缓冲区满，就将窗口置为0，发送方收到后就不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
注意：窗口大小不受16位窗口大小限制，在TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。
流量控制解决了两台主机之间因传送速率而可能引起的丢包问题，在一方面保证了TCP数据传送的可靠性。然而如果网络非常拥堵，此时再发送数据就会加重网络负担，那么发送的数据段很可能超过了最大生存时间也没有到达接收方，就会产生丢包问题。
为此TCP引入慢启动机制，先发出少量数据，就像探路一样，先摸清当前的网络拥堵状态后，再决定按照多大的速度传送数据。
此处引入一个拥塞窗口：
发送开始时定义拥塞窗口大小为1；每次收到一个ACK应答，拥塞窗口加1；而在每次发送数据时，发送窗口取拥塞窗口与接送段接收窗口最小者。
慢启动：在启动初期以指数增长方式增长；设置一个慢启动的阈值，当以指数增长达到阈值时就停止指数增长，按照线性增长方式增加；线性增长达到网络拥塞时立即“乘法减小”，拥塞窗口置回1，进行新一轮的“慢启动”，同时新一轮的阈值变为原来的一半。
“慢启动”机制可用图表示：
1）连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。
2）每当收到一个ACK，cwnd++; 呈线性上升
3）每当过了一个RTT，cwnd = cwnd*2; 呈指数让升
4）还有一个ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”（后面会说这个算法）
1）收到一个ACK时，cwnd = cwnd + 1/cwnd
2）当每过一个RTT时，cwnd = cwnd + 1
这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。
当出现ack超时的时候，需要重传数据包。
TCP认为这种情况太糟糕，反应也很强烈。
快速重传在收到3个duplicate ACK时就开启重传(三次 ack 就认为丢包的原理见 关于TCP乱序和重传的问题 、 TCP 快速重传为什么是三次冗余 ACK )，而不用等到RTO超时。
TCP Reno的实现是：
快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，所以没有必要像RTO超时那么强烈。 注意，正如前面所说，进入Fast Recovery之前，cwnd 和 sshthresh已被更新：
然后，真正的Fast Recovery算法如下：
cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了）
重传Duplicated ACKs指定的数据包
如果再收到 duplicated Acks，那么cwnd = cwnd +1
如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。
如果你仔细思考一下上面的这个算法，你就会知道，上面这个算法也有问题，那就是——它依赖于3个重复的Acks。注意，3个重复的Acks并不代表只丢了一个数据包，很有可能是丢了好多包。但这个算法只会重传一个，而剩下的那些包只能等到RTO超时，于是，进入了恶梦模式——超时一个窗口就减半一下，多个超时会超成TCP的传输速度呈级数下降，而且也不会触发Fast Recovery算法了。
通常来说，正如我们前面所说的，SACK或D-SACK的方法可以让Fast Recovery或Sender在做决定时更聪明一些，但是并不是所有的TCP的实现都支持SACK（SACK需要两端都支持），所以，需要一个没有SACK的解决方案。而通过SACK进行拥塞控制的算法是FACK（可参见 关于TCP乱序和重传的问题 ）
TCP是如何实现可靠传输的？
在计算机网络的经典五层协议中，TCP属于运输层，实现了进程间的通信，保证了数据的可靠传输，属于计算机网络协议族中最重要的协议之一，那么TCP是如何实现可靠数据传输的呢？
运输层的进程间通信是通过socket实现的，socket是一个抽象的概念，在Linux系统中以文件的形式存在。网络层通过IP来区分主机，运输层则增加了端口的概念来区分进程。TCP协议中使用目标IP、目标端口、源IP、源端口来定义一个socket，只需要在运输层的报文头部附加上这些信息，目标主机就会知道数据要发送那个socket，对应监听该socket的进程就可以收到数据进行处理。
TCP报文包括首部和数据部分，首部附加了TCP报文的信息，首部长度固定部分为20字节，还有40字节的可选部分，具体如下图所示：
其中几个关键字段的作用如下：
网络层只管尽可能将数据从一个主机发送到另一个主机，并不保证数据可靠到达，由于网络环境总是不稳定的，可能存在丢包、差错等请求，TCP则通过一系列的机制在运输层保证了数据的可靠传输。 网络传输可能发生的异常情况和解决方法：
要实现可靠传输，最简单的方法就是发送方发送一个报文，接收方收到报文后发送确认报文表示我收到了，你可以发下一个了，传输模型如下：
这种方式保证可靠传输称为停止等待协议，这种方式缺点也很明显，效率非常低。
为了提高传输效率，充分利用带宽，发送方会连续的发送数据包，如下图所示：
客户端不等收到前一个包的确认报文就开始不断的发下一个包，这样可以充分利用网络带宽，提高传输效率，但是于此同时也带来了另外的问题，那么TCP是如何解决这些问题的？
累计确认 ：网络中充斥着大量的发送包和确认回复报文，这些数据只是为了确认报文到达，并不是实际需要传输的数据。是不是一定要每一个报文都要发一个回复确认的报文呢，TCP采用了累计确认的方法：接收方在累计收到了一定量的数据包后发送一个确认报文告诉发送方在此之前的数据包都已经收到了，这样便可以减少确认报文的数量，提高带宽利用率。
GBN（回退n步） ：如果发生丢包的情况，在连续ARQ中，如果接受方收到了123 567个字节，编号为4字节的包丢失了，按照累计确认只能发送3的确认回复，567都要丢掉，因为发送发会进行重传。
选择确认ACK ：在TCP报文头部的选项字段部分设置已收到的报文，每一段用两个边界来确定，比如上述情况可以用[1,3]和[5,7]来表示，客户端就会根据选项只重传丢失的数据段。
因为接收方读数据的能力有限，发送发不能一直发送报文直到把缓冲区所有数据发送完，这样会导致接收方无法接收丢弃掉数据包，发送方收不到确认认为超时又会继续重传，产生了大量无用数据的重传。对此情况TCP使用滑动窗口来解决，基本模型如下：
滑动窗口机制实现了TCP的 流量控制 ，不至于发送太快导致太多的数据丢弃和重传。
为了避免网络过分拥挤导致丢包严重，传输效率低，TCP实现了拥塞控制机制，拥塞控制的解决办法本质上是流量控制，控制发送方发送的速度，而上文提到流量控制是通过滑动窗口来实现的，所以最终也是通过调整发送方的滑动窗口大小来实现的。
拥塞控制的几个重要的概念：慢启动、拥塞避免、快恢复、快重传
Reno算法是比较常见的TCP实现的拥塞控制算法，其他拥塞算法还有Tahoe（已废弃不用）、New Reno等，通过拥塞控制算法可以很大程度避免网络拥挤。
【书籍】计算机网络：自顶向下方法 【码农有道】 这一篇TCP总结请收下
网络知识体系（三） —— TCP 如何保证可靠传输
TCP 是可靠传输协议，他是在运输层实现的可靠传输：
网络层的传输是不可靠的，虽然在网络层甚至数据链路层就可以通过协议来保证数据传输的可靠性，但将其放在到达应用层之前的最后一步会更加合适。
可靠传输的原理主要分为：确认回复，超时重传、给数据包编号、连续 ARQ、滑动窗口、累积确认、选择确认。
要实现可靠传输，最简便的方法就是：我发送一个数据包给你，然后你向我回复收到，我再继续发送下一个数据包。传输模型如下：
这种一来一去的方式就是 停止等待协议 （stop-and-wait）。上文说到，TCP 首部的 ACK 字段为 1 时，表示这个报文是一个确认收到报文。
如果当前网络环境不可靠，就会导致数据包丢失。解决这个问题的方法是： 超时重传 。当一个数据包发出去后，发送端就开始计时，如果时间到了还没有收到确认回复，就可以认为是发生了丢包，此时发送端就再次发送此数据，也就是重传。
但重传会导致另一个问题：如果原先的数据包并没有丢失，只是在网络中待得比较久，这时接收方就会收到两份一样的数据。解决这个问题的方法就是： 给数据包编号 ，接收方根据数据包的编号来判断这份数据是否已经收到过。
在 TCP 首部有两个字段：序号和确认号，他们表示发送方数据第一个字节的编号，和接收方期待的下一份数据的第一个字节的编号。前面讲到 TCP 是面向字节流的，但是他并不是一个字节一个字节的发送，而是一次截取一整段。截取的长度受多种因素影响，如缓存区的大小、数据链路层限制的帧大小等等。
停止等待协议可以满足可靠传输了，但效率太低。发送方发送数据包之后就一直等待，等待的这段时间什么事也没做，浪费了资源。解决的办法是：连续发送数据包。这被称之为 连续 ARQ （Automatic Repeat reQuest）。模型如下：
连续 ARQ 带来了三个问题，第一个问题是：考虑到接收方缓冲区及读取数据的能力，所以发送方不能无限发送。如果发送太快导致接收方无法接受，就会频繁触发重传，浪费网络资源。所以发送方发送数据的范围需要考虑接收方缓冲区的情况。这就是 TCP 的流量控制。解决方法是： 滑动窗口 。模型如下：
在 TCP 首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的窗口大小。通过滑动窗口，就可以实现 TCP 的流量控制，不至于发送太快，导致太多的数据丢失。
连续 ARQ 带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，都有一个确认回复。提高网络效率的办法是： 累积确认 。接收方不需要逐个回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据都收到了。例如，收到 1234，接收方只需要告诉发送方我收到 4 了，那么发送方就知道 1234 都收到了。
连续 ARQ 带来的第三个问题是：如何处理丢包。在停止等待协议中，用超时重传就解决了丢包，但连续 ARQ 中，还需要指定哪些数据包需要重传。
例如：接收方收到了 123 567 六个字节，编号为 4 的字节丢失了，按照累积确认的思路，只能发送 3 的确认回复，567 都必须丢掉，因为发送方会重传 567。这就是 GBN（go-back-n）的思路。但我们发现，这时只需要重传 4 即可，所以就有了： 选择确认 SACK（Selective Acknowledgment）。在 TCP 报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方就可以根据这个选项字段只重传丢失的数据了。
这就是可靠传输的基本原理，总结如下：
为什么说IP和UDP是不可靠的，而TCP是可靠的
TCP在不可靠的IP上面实现了一些防错机制，如超时重传、双方确认等，这样使用TCP的上层协议不必考虑数据是否可靠，在TCP的实现上已经帮助解决了这个问题
而UDP本身是不可靠的，他不需要双方确认数据是否传输成功，但基于UDP的上层协议也可以是可靠的，但需要上层协议来实现这种可靠性，所以UDP本身不可靠