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传输字节文件时，在传输方有一个窗口缓冲区(窗口区)，该大小由接收方返回的接收缓冲区大小决定，若产生拥塞，发送方的窗口大小可能会有所调整。1、窗口区外的字节数据要么被传输成功，并收到了ACK确认，要么是不能传输的部分。2、窗口区内的字节数据要么传输了，但未收到ACK确认，要么可传输，但还未传输。 3、正常情况下，传输方连续传输窗口内的字节数据到接收方，接收方返回ACK+期望收到的下一个序号，传输方收到ACK确认后将窗口的前沿和后沿向前移动。

前文： 网络协议一、协议1、HTTP协议:基于TCP连接的，主要解决如何包装数据，对应于应用层;2、TCP/UDP协议:主要解决数据如何在网络中传输，对应于传输层;3、IP协议:对应于网络层;· 在传输数据时，可以只使用传输层（TCP/IP），但是那样的话，由于没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用应用层协议，应用层协议很多，有HTTP、FTP、TELNET等等，也可以自己定义应用层协议。· web使用HTTP作传输层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发送到网络上。· TCP/IP:传输层协议，主要解决数据如何在网络中传输。TCP（TransmissionControl Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。UDP是User Datagram Protocol，一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。可靠性由上层应用实现，所以要实现udp可靠性传输，必须通过应用层来实现和控制。确认机制、重传机制、滑动窗口。1．应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。2．当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。3．TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。4．既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。5．既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。[2]6．TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认(Acknowlegement)就关闭该重传，如果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中，TCP必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。这种重传策略的关键是对定时器初值的设定。采用较多的 算法 是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个变量RTT（Round Trip Time），用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正[2]RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法（如Karn算法），从而得到TCP重发之前需要等待的时间值。TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认，并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。TCP在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。如果你不利用 Linux 协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：发送：包的分片、包确认、包的重发接收：包的调序、包的序号确认目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。基于UDP的数据传输协议（UDP-basedData Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。本文来自地址：https://blog.csdn.net/gettogetto/article/details/76736365

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报文段。

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建立连接时的三次握手和断开连接时的四次挥手。 首先三次握手：