tcp协议靠什么实现可靠传输(TCP靠什么实现可靠通信)

TCP/IP协议 TCP/IP（Transmission Control Protocol/Internet Protocol的简写，中文译名为传输控制协议/互联网络协议）协议是Internet最基本的协议，简单地说，就是由网络层的IP协议和传输层的TCP协议组成的。 通俗而言：TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台电脑规定一个地址。1974年12月，卡恩、瑟夫的第一份TCP协议详细说明正式发表。当时美国国防部与三个科学家小组签定了完成TCP/IP的协议，结果由瑟夫领衔的小组捷足先登，首先制定出了通过详细定义的TCP/IP协议标准。当时作了一个试验，将信息包通过点对点的卫星网络，再通过陆地电缆，再通过卫星网络，再由地面传输，贯串欧洲和美国，经过各种电脑系统，全程9.4万公里竟然没有丢失一个数据位，远距离的可靠数据传输证明了TCP/IP协议的成功。

TCP使用可靠的传输协议，即意味着必须按序、无差错的传送数据到目的端，那么如果在传输过程中发送的包丢失了该怎么办？TCP的重传机制就是：如果发送方认为发生了丢包现象就重发这些数据包。显然，我们需要一个方法去 猜测是否发生了丢包 。最简单的想法就是，接收方每接收到一个包就向发送者返回一个ACK，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到ACK，就知道 很可能是数据包丢失 了，紧接着就重发该数据包，直到收到ACK为止。 为什么是 猜测 呢？ 因为即使是超时了，这个数据包也可能并没有丢，它只是绕了段远程，来的很晚而已。毕竟TCP协议是位于传输层的协议，不可能明确知道数据链路层和物理层发生了什么。但是这并不妨碍我们的超时重传机制，因为接收方会自动忽略收到的重复的包。下面我们具体讲一讲TCP的重传机制：这种机制下，每个数据包都有相应的计时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文就会重发该数据包。超时时间应该设置为多少我们先来了解一下RTT (Round-Trip Time 往返时延)而超时时间是以RTO（Retransmission Timeout 超时重传时间） 表示。超时时间不宜设置的过长或过短，否则：综上可知，RTO设置的值应该略大于RTT的值。RTO值的计算：https://blog.csdn.net/JXH_123/article/details/27345151值得注意的是：每触发一次超时重传，都 会将下一次超时时间间隔设为先前值的两倍 。遇到超时说明网络环境差，不宜频繁发送。Wireshark 抓包显示：超时重传存在的问题是：当一个报文段丢失时，会等待一定的超时时间后才重传，增加了端到端的时延；当一个报文段丢失时，在其等待超时的过程中，可能会出现这种情况： 其后的报文段已经被接收端接收但却迟迟得不到确认，发送端就也以为丢失了，从而引起不必要的重传，既浪费时间也浪费资源。（例如： 数据包5丢失，数据包6、7、8、9都已到达接收方，这个时候客户端只能等服务端发送ACK，因此对于客户端来说，它完全不知道丢了几个包，可能就悲观的认为：5后面的数据包都丢了，就重传这5个数据包，这就比较浪费了）。刚刚提到过，基于计时器的重传往往要等待很长时间，而快速重传使用了很巧妙的方法来解决这个问题。快速重传（Fast Retransmit）机制 不以时间为驱动，而是以数据为驱动重传。由于TCP采用的是累计确认机制，当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认号，即冗余 ACK (Duplicate ACK)。这样，如果在超时重传定时器溢出之前，接收到连续的三个重复冗余 ACK (第一个ACK是正常的，后三个是冗余的)，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，而不需要等待超时重传定时器溢出，大大提高了效率。Wireshark 抓包显示：但是，快速重传仍然没有解决第二个问题：到底该重传多少个包？改进的方法就是 SACK (Selective Acknowledgment)，简单来说就是在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了。看下例子：存在 SACK 选项时当500-599报文到达，接收方发送  ACK 200  ，SACK [500,600)当600-699报文到达，接收方发送  ACK 200  ，SACK [500,700)当700-799报文到达当800-899报文到达当900-999报文到达，接收方累积确认发送  ACK 200  ，SACK [500,1000)连续收到3个重复ACK，发送方经检查发现200-499的数据丢失了，执行快速重传，待接收方接收到200-499的数据，并返回 ACK 1000时，发送方的所有数据均已确认完毕，移动滑动窗口到1000位置处。使用 SACK可以告知发送方 收到了哪些数据，发送方收到这些消息后就会知道哪些数据丢失，然后立即重传丢失的部分。需要注意的是： 只有收到失序的分组时才可能会发送SACK 。SACK 包括了两个TCP选项，一个选项用于标识是否支持 SACK（SACK_Permitted），在TCP建立连接时发送；另一种选项则包含了具体的 SACK信息。（1）SACK_Permitted 选项该选项只允许在TCP连接建立时，有 SYN标志的包中设置，在连接建立阶段，主动发起连接的一方在它的SYN中指定选项。只有在它从另一方的SYN中收到了这个选项之后，SACK机制才会被使能。（2）SACK 信息选项SACK 选项参数告诉对方 已经接收到 并缓存的不连续的数据块，发送方可据此信息检查究竟是哪个块丢失，从而发送相应的数据块。Left Edge：本区块的第一个序号。 Right Edge：本区块的最后序号的下一个序号。[Left Edge, Right Edge)区间的ACK 序号表示本次确认收到的序号。问题1：SACK选项最多能包含多少个需重传的块？由于TCP首部的最大长度为 60 byte，而固定首部占用了 20 byte，对于SACK选项本身占用了2 byte，所以剩下 60-20-2=38 byte。而每个块（包括开始和结束）占用 8 byte，所以最多可标识的块数为 38/8 = 4块，所以 SACK 最多可以包括4个需重传的块。同时由于SACK有些时候会和时间戳（占10字节）一起用，因此，此种情况下最多只有3个SACK。问题2：SACK选项的使用规则是怎么样的？SACK 的发送方，即 报文的接收端第一个块需要指出是哪一个到达的报文触发的 SACK尽可能多的把所有的块填满SACK 要报告最近接收的不连续的数据块SACK 的接收端，即 报文的发送端：数据没有被确认前，都会保持在滑动窗口内每个数据包都有一个 SACKed 的标志，对于已经标示的报文，再次接收到时会忽略如果SACK丢失，超时重传之后，重置所有数据包SACKed 标志DSACK是在SACK的基础上做了一些 扩展 ，主要用于对收到的 重复报文 进行了处理。它的主要作用是：告诉发送方有哪些数据被重复接收了。DSACK同样使用了与SACK一样的报文格式，唯一区别在于： 第一个连续的block指定的是触发DSACK的重复报文的序号空间。如果第一个段的范围被ACK范围所覆盖，那么就是DSACK。或者，第一个段的范围被SACK的第二个段覆盖，那么就是DSACK。引入DSACK的好处有：1）可以让发送方知道，是发出去的包丢了，还是回来的ACK包丢了；2）是不是自己的 timeout 设置太小了，导致重传；3）网络上出现了先发的包后到的情况（又称数据包失序）；4）网络上是不是把我的数据包给复制了；总之，DSACK的目的是帮助发送方判断，是否发生了包失序、ACK丢失、包重复或伪重传，让TCP可以更好的做网络流量控制。 超时重传机制能解决数据包丢失的问题，但是超时重传机制存在等待时间太长，浪费时间在等待上，降低了传输效率和无法知道需要重传哪些数据包的问题。 快速重传能解决超时重传的等待时间太长的问题，但是对于究竟该重传哪些包的问题仍然不能有效解决。SACK能需要重传哪些数据包的问题，它可以知道哪些包是被确认接收的，客户端能据此判断需要重传的包。DSACK则是作为SACK的一个辅助措施，可以用来判断网络究竟是出现了什么情况，据此做好网络流量控制。

在计算机网络的经典五层协议中，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总结请收下

1、检验和 TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。2、序列号TCP将每个字节的数据都进行了编号，这就是序列号。序列号的作用：数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现。TCP在发送数据时，并不是按顺序发送的，发送出去的数据包也不能保证按序到达（网络的不确定性）。接收端接收到数据之后，按序号排序，如果中间某个数据报丢失了，之后的数据报还是会被接收，但是不会对发送端返回之后的确认，而是会重复发送对丢失出之前的数据确认，保证发送端会对丢失的数据段进行重发。保证数据的按序组装TCP规定，在确认报文里，若确认号=N，意思是告诉发送者，到序号N-1为止的所有数据都已经正确的收到，下次你从N开始发送建立连接时，双方发送的SYN报文和ACK报文段都是不携带数据的，但是会消耗一个序号，这个序号通常是随机值TCP规定，首部中序号字段的值是本报文段发送数据的第一个字节的序号。3、确认应答机制（ACK）TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。正常情况下的应答机制：4、超时重传机制当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个定时器，到点了还没有收到应答则进行重传），其基本过程如下：当然，未收到确认不一定就是发送的数据包丢了，还可能是确认的ACK丢了：当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，就要用到前面提到的序列号了，利用序列号很容易就可以做到去重的效果。重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2500ms后再进行重传，如果仍然得不到应答就等待4500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。超时重传的过程：放置片段到重传队列中，启动计时器：TCP在发送包含数据的片段后，片段都会被复制一份并放在重传队列中，然后启动计时器。确认处理：如果在计时器超时之前收到确认信息，就把该片段从重传队列中移除超时重传：如果在计时器超时之前没有收到确认信息，则相应片段被重新发送给对方，即重传机制，但是TCP也不能保证重传报文的可靠性，所以该报文依然会处于重传队列中，并重新计时，如果还是超时，则重复这一动作，而且超时时间会设置的较之前长，但是TCP只会重传一定数量的次数，因此当超过这个次数时，TCP会检查故障并断开连接这个等待的时间被称为RTO，RTO也是根据RTT（传输往返时间）来确定的，也和当时网络的状态有关系，需要通过具体算法实现，不是确定值如果超时时间设置的太长，会影响整体的重传效率如果超时时间设置的太短，会频繁发送很多重复的包去重：当主机B的确认报文丢失时，主机A没有收到相应的确认报文，就会重传，主机B会收到重复的报文，TCP会根据报文中的序列号来移除重复收到的报文。5、连接管理机制连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。 首先三次握手：

TCP的可靠传输是基于连续ARQ协议的，ARQ协议中有两个重要的概念：滑动窗口和累计确认。但是我认为TCP能实现可靠传输不仅仅是靠连续ARQ协议，还依靠了：1.通过三次握手、四次挥手来保证信道的可连接性 ；2.采用停止等待协议、连续ARQ协议（自动重传）来保证数据的正确性；3.序列号和确认应答号保证了数据的有序性，4.校验和：如果收到字节的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。TCP通过三次握手来确定这是一个可靠的连接，三次握手的目的是为了确定客户端和服务端都有正常的【收发】能力，即客户端可以发送和接收消息，服务器也可以发送和接收消息。那么如果只有两次握手，则【客户端】的【接收】能力并没有得到确认，不能确定这是一个可靠的连接。同时，为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤，如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。这三个协议的目的，都是为了保证了客户端和服务器的数据，能确保传送到对面。如果数据在中途丢失或者延迟，则需要重新发送，一直到对面接收到为止。A每发送完一个报文M，就等候B对其确认；如果没收到确认，则不能继续发送，收到确认后再继续发送。缺点是一个个字节发送效率太低。数组分组在传输过程中发生错误时有两种情况：在这两种情况下，接收方都不会发送任何信息。发送方在一定时间内没有收到确认，就认为分组丢失，然后重传该数据分组，这就叫超时重传。停止等待ARQ协议就是通过这种确认和重传的机制，在不可靠的网络上实现可靠通信。显然，每次只发送一个报文然后等待确认效率太低。连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。如果中间发生丢失包的情况，A需要回退到确认的报文重新发送。A的发送窗口大小是根据B接受窗口设置的。也就是说A发送的报文速度不能超过B处理报文的速度。TCP中对于超时重传时间的选择是根据平均往返时间RTT来计算的。也就是说，如果A超过一个报文平均往返时间没有收到确认，就会重新发送报文。选择重传ARQ协议是指在接收方收到未按序排列的数据流时，通知发送方重传缺失的数据，而不是重传全部数据。TCP数据段首部中添加选择确认选项SACK可以实现该目的。如图所示，假设上述分组都在发送窗口中，收到三个不连续的分组。三个分组的边界分别为：[4000,5001]、[6000,7001]、[8000,9001]。在建立TCP连接时，连接双方先商定好，在首部选项中加入“允许SACK”的选项。在之后的TCP报文段中增加SACk选项，以便接收方向发送方报告不连续的字节块的边界。因为序号是32位，因此指明一个边界需要4个字节，说明一个字节块的边界需要8个字节。另外需要一个字节指明是SACK选项，一个字节指明这个选项的大小。TCP报文段首部选项最大为40个字节，因此最多指明4个字节块的边界信息。TCP标准并未指明发送方应该如何响应SACK，因此大多数实现还是重传所有未被确认的数据分组。利用滑动窗口机制可以实现对发送方的流量控制。在TCP连接建立时，接收方会在确认报文段中给出自己接收窗口的大小。在每次发送确认报文时能够根据情况动态调整接收窗口的大小，并将告知发送方。如下图所示：发送方发送序号从1开始的100字节的数据，接收方在确认报文中声明自身的接收窗口大小为300字节。之后发送方发送300字节数据，接收方在确认报文中声明自身接收窗口大小调整为50字节。发送方再发送50字节数据之后，收到接收方传来的确认报文，在该报文中声明接收窗口为0。在接收方接收窗口为0时，发送方不再发送数据，直到接收方发送确认报文表明窗口大小发生改变。可是这个确认报文不一定能够被发送方接收到，如果一旦该确认报文丢失，双方都将处于等待中，形成死锁。为防止这种情况出现，TCP规定在收到对方接受窗口为0时，启动一个坚持定时器周期性的发送探测报文，以确定对方接收窗口为0的状态是否改变。另外，TCP标准规定：接收方接收窗口为0时，不再接收正常数据，但是可以接收零窗口探测报文段、确认报文段、携带紧急数据的报文段。当主机开始发送数据时，如果立即将较大的发送窗口的全部数据注入网路中，那么由于不清楚网络的情况，有可能引起拥塞。比较好的方式是试探一下，即从小到大逐渐增大发送端的拥塞控制窗口数值。cwnd以指数增长的形式增长。接收方收到M1之后发送对M1的确认报文，M2报文丢失，之后接收方收到M3、M4、M5时每次都发送对M1报文的重复确认。快重传算法规定当收到三次重复确认后，发送方就认为M2报文段丢失，立即重传M2报文段。