TCP的可靠传输是如何实现的？
浏览 1216回答 1
1、TCP的主要特点：1.TCP 是面向连接的运输层协议。2.每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一）。3.TCP 提供可靠交付的服务。4.TCP 提供全双工通信。5,.TCP是面向字节流。 6.首部最低20个字节。2、TCP的运输建立：采用客户服务器方式，主动发起建立的是客户，被动等待连接建立的应用进程是服务器。1.A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。2.B 的 TCP 收到连接请求报文段后，如同意，则发回确认。 B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x + 1，自己选择的序号 seq = y。3.A 收到此报文段后向 B 给出确认，其 ACK = 1， 确认号 ack = y + 1。A 的 TCP 通知上层应用进程，连接已经建立。4.B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立简而言之也就是采用三次握手的方式，A向B发现连接请求，B接收到（第一次握手），如果B同意则向A发送“我已接受到你的请求并且已经准备好了，可以建立连接”（第二次握手），A再接受到B的确认连接信号，向B说“我也已经准备好了，让我们开始连接吧”（第三次握手），最后才能真正确认连接。大致上就是这样的一个原理，个人理解，希望对你有帮助。
随时随地看视频TCP 的可靠传输
摘自：《深入理解计算机网络》 王达著 机械工业出版社
相关知识链接
TCP 的可靠传输
TCP是一个可以提供可靠数据传输的传输层协议，那么它到底是如何来保障可靠传输的呢？下面进行具体的分析。
TCP可靠传输方面，主要采用以下4中机制：
字节编号机制。TCP 数据段以字节为单位对数据段中的“数据”部分进行一一编号，确保每个字节的数据都可以有序传送和接受。
数据段确认机制。TCP 要求每接受一个数据段都必须由接收端向发送端返回一个确认数据段（可以用一个去人数据段一次确认全面多个数据段），其中的“确认号”表明接收端已正确接受的数据段序号（“确认号”前面的所有数据段，确认号表示将要接收的下一个数据段编号）。
超时重传机制。在 TCP 中有一个重传定时器（Retransmission Timer， RTT），在发送一个数据段的同时也启动了该定时器。如果在定时器过期之前该数据段还没有被对方确认的话，且定时器停止，然后重传对应序号的数据段。
选择性确认（Selective ACK， SACK）机制。在 SACK 支持下，仅可以重传缺少部分的数据，而不会重传那些已经正确接受的数据段。
以上所说的“字节编号机制”比较好理解，因为是按字节进行编号，所以接收端根据所接收到的数据段中的序号就可以知道前面是否还有数据没有接收到，数据可以按顺序向应用进程提交，在对经过了数据段的数据进行重组时也可以根据这个序号进行正确重组。下面我们将会重点介绍 2、3、4 机制的运行原理。
TCP 的数据段确认机制
几个重要概念的理解
若想详细了解TCP数据段，请点击
数据段指 TCP 对从应用层接受的数据进行分割所得到的数据块（也可以是没有经过分割的整个报文，只要它的大小在 MSS 之内），通常包括千个以上的字节，而且必须是整数倍字节数。正因如此，TCP 发送的是字节流，而不是通常所说的报文流，因为在 TCP 数据段中没有报文边界。
TCP 发送的数据段中“数据”部分（不包括数据段头部），每个字节都有一个序号，每个数据段中的“序号”字段是以该数据段中第一个字节的序号进行填充的。
3. 窗口大小
窗口大小是本端要告诉对端当前可以接受的数据量，也暗示着对端此时可以一次性发送的数据大小，以字节为单位，但这里仅是针对数据段中的“数据”部分，不包括 TCP 数据段头部，因为数据段到了对端的应用层后仅提交“数据”部分。TCP 可以一次性连续发送窗口大小的数据（但实际上发送数据的大小还会受到当前可用的“发送窗口大小”影响），其中包括一个或多个 TCP 数据段。但窗口大小必须小于对应网络中的 MTU （最大传输单元）值大小，否则到了数据链路层还是要进行数据分割。同时要注意的是，“窗口大小”字段是随着接收端可用“接受窗口大小”变化而变化的，不是固定的。
注意：无论是发送端，还是接收端，都分别有“发送窗口”和“接收窗口”这两个窗口，其大小分别用于发送数据和接受数据的缓存大小。这两个缓存的物理大小对于具体的主机来说是固定不变的，除非人为扩展物理内存，否则不会再扩大，只能沿着缩小的方向进行变化。
确认号指发送包含这个“确认号”的数据段的一段期望接收另一端的下一个数据段的起始序号。同时也暗示了在此序号前的所有字节数据均已正确接收。
ACK 是一个表明“确认号”字段是否有效的标志位。只有 ACK 字段的值为1，数据段中的“确认号”才有意义，否则数据段中的“确认号”没有意义，即不具有上面所说得“确认号”含义，因为 TCP 通常不会针对单个数据段进行确认，而是一次性对多个连续数据段进行确认。只需要最近收到的那个数据段进行确认，即表明前面所有数据段均已正确接收。
TCP 确认机制的特性
1. TCP 可一次连续发送多个数据段
TCP 不需要等待接受对方发送的确认数据段（“ACK”字段值为1的数据段）就可以一次性连续发送多个数据段，这样可大大提高数据发送效率。但一次性可发送多少个数据段是受对方返回的“窗口大小”字段值和当前可用“发送窗口”大小双重限制的。因为发送端对还没有收到确认的数据段要进行缓存，这需要占用一定的“发送窗口”大小。
假设发送端的物理“发送窗口”和接收端的物理“接受窗口”大小均为2000字节，设每个数据段大小为100字节，而接收端返回的数据段中显示“窗口大小”字段值也为2000，同时发送端此时的“发送窗口”还有两个数据段（200字节）还没有收到确认，则此时发送端可发送的数据段数量为18（ - 2），即1800字节，不能发送全部的2000字节数据。
如果接收端返回的数据段中显示的“窗口大小”值为1000，则此时发送端可以发送1000字节数据，因为所发送的1000字节数据，在加上原来还没有收到确认的200字节数据，小于发送端的物理“发送窗口”大小——2000。
仅对连续接收的数据段进行确认
返回的确认数据段中的“确认号”字段值仅代表对端已正确接收的连续数据段（最高字节序号+1），而不一定是已正确接收数据段中的“最高序号 + 1”，因为中间可能还有数据段因为网络延迟而暂时未收到，或出现了传输错误而丢失。
假设每个数据段的长度大小均 100 字节，接收端接收到了序号为 1、101、201、401 四个数据段。其中序号为 301 的数据段暂时还没有收到，此时接收端返回的确认数据段中的“确认号”只能是301，而不会是501，（尽管401~501的数据已经正确接受）也就是只对前三个数据段进行确认，不会对后面的401数据段进行确认，因为中间的301数据段还没有收到。当后面收到了301数据段后，可能会返回一个“确认号”为501的数据段，这时就代表301和401数据段均以正确接收了。
不连续序号的数据将先缓存
当主机接收到的数据段序号不连续时，不连续部分向应用层的应用进程进行提交，而是先缓存在“接收窗口”中，等待接收到中断的序号的数据段后再一起提交。这时，尽管接收端已正确接受了某些数据，但仍不能及时向应用层提交，需要占用“接收窗口”空间。对于没有按先后次序正确接受的数据，在向应用层提交时会重新按数据段序号重新组合，然后再提交给应用层。
如某主机先后接收到了对端发来的序号分别为 1、101、201、301、601、501、801 的数据段（假设数据段大小均为100字节），则该主机首先把 1、101、201、301 这4个数据段向应用层提交并向发送端发送一个“确认号”为401的确认数据段，从而可以从“接受窗口”中删除这4个数据段，释放“接受窗口”；然后再把 601、501、801 这3个数据段先缓存在“接受窗口”中，直到接受到了401号数据段，再按 401、501、601 顺序重组并向应用层提交，接着发送一个“确认号”为701的确认数据段，从而又可以从“接受窗口”中删除这三个数据段，释放“接受窗口”，但此时“接受窗口”中仍缓存有801号数据段，因为701号数据段还没有得到确认。
TCP 超时重传机制
“超时重传” 是TCP保证数据可靠的另一个重要机制，其原理是在发送某一个数据段以后就开启一个超时重传计时器（Retransmission Timer，RTT）。如果在这个定时器时间内没有收到来自对方的某个数据段的确认，发送端启动重传机制，重新发送对应的数据段，知道发送成功为止。需要注意的是，并不是 RTT 定时器一到，就会立即重传数据，毕竟从“发送窗口”缓存中找到对应的数据段，然后安排重新发送都是需要时间的，实际上，超时重发时间间隔（Retransmission Time Out）要大于 RTT 值。
这里涉及两个重要问题：一是如何确定 RTT 值，另一个是如何计 RTO 值。表明上看起来 RTT 值很容易确定，因为它就是一个数据段往返发送端和接收端的时间总和，但在 TCP 通信中，中间可能经过了多个性能不一样的网络，而且不同时刻网络的拥塞程度可能不一样，这就造成了不同数据段的 RTT 时间并不一致，甚至波动非常大。但 TCP 必须适应这种情况，必须能动态地跟踪这些变化并相应地改变其超时重传时间。
正因为 RTT 值不是固定的，所以就出现平滑 RTT（SRTT）的概念，就是在充分考虑历史 RTT 值的情况下所设计的一个 RTT 值计算公式。在最初的 RFC793 中，SRTT 的计算公式如下：
SRTT（新的SRTT） = αSRTT（旧的 SRTT 值）+ （1-α）RTT （新的 RTT 样本值）
SRTT 的初始值就是第一个 RTT 值。这里 α 是一个平滑因子，它决定了旧的 SRTT 值所占的权重，0≤α&1 。RFC2988 推荐的 α 典型值为0.125. 如果 α 很接近1，则表示新的 SRTT 值与旧的 SRTT很接近，变化不大。相反，则表示变化很大。显然，用这种方法计算得出的各个时刻的 SRTT 值更加平滑，更加接近当时的网络环境。
虽然可以通过公式计算出 SRTT 值，但是 RTP 的得出仍不是一件简单的事，因为到底是 RTT 定时器到后就重传，还是要再等多长时间才重传，这是必须考虑的问题。正常情况下，TCP 利用 β SRTT 作为重传超时间隔 （β&1)，而且最初的值总为2（也就是两倍的 SRTT 时间后还没有收到对应数据段的确认才重传该数据段）。
但经验表明，采用常数的 β 值不够灵活。于是，在1988年，Jacobson 提出使用平均偏差作为标准偏差（就是 β SRTT）的新估计法，要求维护另一个被平滑的偏差 RTTD 。当一个确认数据段到达时，可以得出 SRRT 的新的 RTT 样本值之间的偏差 RTTD=(SRTT-RTT)。
第一次测量时，RTTD 为测量到的 RTT 样本值的一半，在以后的测量中按照以下的公式进行计算：
RTTD（新的RTTD）=αRTTD（旧的RTTD）+(1-α)×(SRTT-RTT)
这里的 α 可能与计算 SRTT 时的值相同，也可能不同，通常取值 0.25. SRTT 是平滑 RTT 值， RTT是新的 RTT 样本值。虽然 RTTD 并不能完全等同于标准偏差，但已能足够的反应 SRTT 值的动态变化。现在大多数 TCP 实现都是使用这个算法，并且将超时重传时间设置为：
RTO=SRTT+4RTTD
这里有一个重要的问题，那就是对于重传的数据段如何计算其 RTT 的值。假设发送端发送了一个数据段，但在重传定时器内没有收到该数据段的确认数据段，于是重新发送了这个数据段，可过了一段时间，发送端又收到了该数据短短额确认数据段。这是发送端就迷糊了，这个确认数据段到底是对原来发送的那个数据段确认，还是对重发的数据段的确认呢？这两个数据段的序号是一样的，如果在上次发送的数据段后没有再重新发送新的数据段的话，接收端返回的确认数据段中的确认号都可能一样。如何收到的确认数据段是对重传数据段的确认，但却被发送端认为是对原数据段的确认，则这样计算出的 SRTT 和 RTO 值可定会偏大，否则会偏小。为此，以为发现这个问题的无线电爱好者 Karn 提出了一个建议，就是在计算加权平均 RTT 时，只要数据段被重发就不采用其往返时间作为计算 SRTT 和 RTO 的样本，这样得出的加权平均 SRTT 值和 RTO 值就比较准确了。
TCP 的选择性确认机制
在上面介绍的 TCP 重传机制中，如果在重传定时器超时后仍没收到一个数据段的确认，则可能会重传对应序号后面的所有数据段，因为后面的这些数据段均暂时不会被确认，这明显大大降低了 TCP 数据传输性能。
同样假设每个数据段大小为 100 字节，接受端已接受到了 1、101、201、401、501 这5个序号的数据段，其中 301 号数据段没有收到。按照前面介绍的确认机制，虽然 401、501 这两个序号的数据段均已收到，但因为 301 号这个数据段一直没收到，所以仍然不能像向发送端确认。在某个时间上，如果 301 号数据段重传定时器超时了，则发送端肯定会重传这个数据段，但毕竟重传的 301 数据段到达对端也是要时间的。在这个 301 号数据段的重传过程中，401 号，甚至 501 号数据段的重传定时器也可能超时，这是发送端可能由对 401号、501 号这两个数据段进行重传。这样的重传显然是不必要的，也会造成接收端重复接受 401 号、501 号这两个数据段。
为了避免这种现象的出现，在 RFC3517 中出现了一种称为 “选择性确认” （SACK）的机制，就是在 TCP 数据段格式的头部 “可选项” 字段中添加一个代表支持 SACK 选项。但这个选项在不同的数据段格式的头部 “可选项” 字段中添加一个代表支持 SACK 的选项。但这个选项在不同的数据段中有不同的字段名称和不同的含义。
首先，必须在建立 TCP 传输连接时的 SYN 数据段中包含 “SACK-Permit” （SACK 允许）字段选项，表示在今后的传输中希望收到 SACK 选项，然后在其他的数据段中包括需要包含 “SACK”字段，在这个字段中，会包含本段要告诉对端已经接收到的不连续数据段。原来的 “确认号” 字段同样有效，但此时的 SACK 扩展选项也仅在确认数据段（“ACK” 字段值为1）中才有效。
“SACK-Permit” 字段中包括 Kind （类型）和 Length（长度）两个子字段。，如下图所示。Kind 字段值固定为4，占8位，表示允许使用 SACK 扩展确认选项；Length 字段的值固定为2，占8位，表示在 SYN 数据段中 SACK 允许扩展选项占两字节。
SYN 数据中的“SACK-Permit”选项格式
在其他非 SYN 数据段的 “SACK-Permit” ，包括 Kind、Length，以及各不连续数据段的起始字节号和结束字节号，如下图所示。Kind 字段固定值为5，占8位，表示这是非 SYN 数据段的 SACK 选项；Length 字段值可变，占8位，以字节为单位表示 SACK 扩展选项的长度。后面是 n 个标识不连续数据段起始和结束序号的部分，每个序号占32位。
其他数据段中的 “SACK” 选项格式
由于 TCP 数据段头部的“可选项”字段最长为40字节，Kind 和 Length 这两部分一共占了2字节，而表示一个不连续数据段的起始序号和结束序号要占用8字节（因为一个序号要占4字节）。因此，实际上在一个数据段中最多可以标识4个不连续数据段，因为标识4个数据段的起始序号和结束序号一共要占用32字节，加上前面 Kind 和 Length 部分，就有34字节。而要标识5个数据段的起始序号和结束序号，则还要8字节，超出了“可选项”字段40字节的限制范围。所以，在“Length”子字节中，最大值其实就是34.
发送端通过识别接收端返回到确认数据段中的 SACK 扩展选项就可以得知接收端已收到了哪些不连续序号的数据段，这样发送端就可以不再发送这些数据段，而只发送已经丢失的数据段（发送端已经发送，且在重传定时器超时后接收端仍没有收到的数据段）。
假设接收端已经收到 1、101、201、401、501 这五个序号的数据段，在发送确认号为 301 的确认数据段时，在 SACK 扩展选项中标记 401（起始序号为 401，结束序号为 600）这两段不连续的数据段。这时发送端就会知道，不需要再发送 401 和 501 这两个数据段了，只需要发送301号数据段即可。这样大大节省了网络资源，也提高了数据传输的效率。
TCP协议如何保证传输可靠性
正确理解tcp的可靠传输------其实并不100%可靠
TCP可靠数据传输
TCP是如何保证数据的可靠传输的
TCP如何利用不可靠的IP协议实现可靠传输
TCP可靠传输机制
TCP可靠传输详解
TCP可靠传输的实现［流量控制、拥塞控制］
TCP协议与IP协议之间的关系？为什么TCP协议能实现可靠传输？
没有更多推荐了，为什么说tcp是可靠的服务
一个简单的 tcp 服务器tcp/ip笔记 - 综述_网络服务器_网络工程学院_希赛网基于多线程的tcp服务器项目【开源】服务器传到web浏览器的方式进行的,如下图解: http工作在tcp/ip协议体style
上一篇：　　下一篇：我们知道传输层提供最主要的两种协议，TCP和UDP，其中TCP是保证可靠传输，为什么他要保证可靠传输呢，IP说：当然是我不能，我只提供尽力而为的服务，不保证你能不能交付，不保证能不能正确的交付，不保证能不能按顺序交付。要不然干嘛要你保证呢。说的好有道理，我呵呵一笑。
那么可靠数据传输到底能保证什么呢？
1.不错：就是传输的数据包没有错误
2.不丢：传输的数据包不丢失
3.不乱：传输的数据包顺序要保持正确的交付。
可靠传输协议凭什么能做出这样的保证呢？
1.差错检测：TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
2.超时重发和确认机制：当TCP发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。
3.缓存机制：每个分组都会有一个序列号，对于后一个序列号分组先到的情况，接收端会先进行缓存，等待前一个序列号到达，然后一起交付上层。
重点讲一下流水线可靠传输协议，其实也就是滑动窗问题。
对于使用流水线可靠传输协议，如果出现丢包，损坏或超时会有哪些方法来解决呢？两种方法：回退N步（Go-Back-N，GBN）和选择重传（Selective Repeat，SR）
发送端维持这一个长度为N的滑动窗口，你也可以理解为一个数组。
1.窗口里含有发送但是没收到确认的分组，以及剩下可用的坑位，如果有可用的坑位，上层需要发送数据，则直接发送，否者缓存或返回给上层。
2.接收端实行累积确认，也就是说当接收端传送的确认号为100，也就是前面的序号都是收到了，
3.如果超时未收到确认，发送端会重传所有发送但未确认的分组。只有一个定时器，用来记录窗口的最前端，也就是最早发送的分组。
4.因为此协议是使用的累积确认，所以所有为按序到达的分组都会被丢弃。
1.发送端和接收端都会维持一个窗口，大小为N。
2.接收端每收到一个分组就会发送一个确认，并且会缓存不是按序到达的分组
3.发送端会标记已经被确认的分组，当窗口第一个值被确认后，窗口向后滑动。每一个分组为此自己的定时器。
4.当一个分组超时了，只会重传超时的分组。
窗口长度必须小于或等于序号空间大小的一半。
TCP的可靠传输协议是GBN和SR的混合的
1.他是基于累积确认的，
2.但是他是可以缓存的，不会丢弃乱序的分组，
3.只有一个定时器，记录发送端窗口的第一个未确认的分组的时间，超时发送第一个分组。
阅读(...) 评论()looking for permanent living evidence
TCP协议如何来保证传输的可靠性
TCP提供一种面向连接的、可靠的字节流服务。
面向连接：意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP。
TCP通过下列方式来提供可靠性：
1、应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。
(将数据截断为合理的长度)
2、当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
(超时重发)
3、当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒 。
(对于收到的请求，给出确认响应) (之所以推迟，可能是要对包做完整校验)
4、 TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。 (校验出包有错，丢弃报文段，不给出响应，TCP发送数据端，超时时会重发数据)
5、既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
(对失序数据进行重新排序，然后才交给应用层)
6、既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。(对于重复数据，能够丢弃重复数据)
7、TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。(TCP可以进行流量控制，防止较快主机致使较慢主机的缓冲区溢出)TCP使用的流量控制协议是可变大小的滑动窗口协议。
字节流服务::
两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（bytestreamservice）。
TCP对字节流的内容不作任何解释:: TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。
TCP协议如何来保证传输的可靠性和数据的顺序性
TCP如何保证可靠性
TCP协议如何保证可靠传输
TCP如何实现可靠性
TCP如何保证消息顺序以及可靠性到达
_我是如何讲清楚TCP协议是如何保证可靠传输的
TCP如何保证它的通信的可靠性
TCP任何保证可靠的数据传输？
没有更多推荐了，}