要想理解可靠数据传输（Reliable Data Transfer），那么不妨结合与其相对的概念——不可靠数据传输进行理解。

UDP可靠性设计、TCP/UDP应用场景分析

比如我们要实现这样的一组通信，发送方通过一个网络协议给接收方发送一些数据分组，接收方有可能接收到了全部数据，也可能因为各种原因只接收到了部分数据分组或者根本没有收到任何数据分组。即使收到了全部的数据分组，但可能这些分组是有序的（或者说可以通过一些操作恢复为发送时的顺序）可以得到完整的消息（message)，也有可能是无序的，无法恢复出完整的信息。即使数据包是完整的、有序的，有可能在某些地方因为信道有噪声或者其他缘故出现一些差错，导致数据上出了偏差。

协议要保证的不仅仅是发送方可以发数据，同时也会对接收方将接收到怎样的数据做出一定的保证，这才是完整的通信。

Thus, to support these applications, something has to be done to guarantee that the data sent by one end of the application is delivered correctly and completely to the other end of the application. If a protocol provides such a guaranteed data delivery service, it is said to provide reliable data transfer.

分组可能会在网络中丢失、损坏，应用层可能对网络通信有所要求，不允许出现这种差错，必须保证接收方的应用收到了完整且正确的数据，这种服务就是可靠数据传输服务。

如果一个协议可以确保发送端发送了怎样的数据，那么接收端就必然能接收到怎样的数据，那么就可以说这个协议提供了可靠数据传输服务，这个协议是可靠的，反之则是不可靠的。

类比一个比较形象的场景，一个记者去现场报道国家主席接见现任特首，那么这个记者就相当于一个通信协议，如果能保证把所有的信息都完整、真实、无差错地报道出来，让观众、读者可以通过她的报道真实感受现场情景，那么她就提供了可靠的数据传输服务，如果她可能故意问一些没有质量且水平低下的引导性问题，丢失一些信息没有完全报道，夹带私货，把无中生有的事再重复一遍，宣传上就出现了偏差，她就是不可靠的记者（协议）。

TCP服务模型除了面向连接以外，也提供可靠数据传输服务。

The communicating processes can rely on TCP to deliver all data sent without error and in the proper order. When one side of the application passes a stream of bytes into a socket, it can count on TCP to deliver the same stream of bytes to the receiving socket, with no missing or duplicate bytes.

通过TCP协议的通信进程可以无差错地以正确的顺序传送所有数据。当一方的应用向套接字传送字节流时，它可以通过TCP向接收套接字传送完全相同的字节流而没有丢失或者冗余的字节。

而同样是传输层的重要协议UDP则不提供可靠传输服务，仅仅提供最小服务（minimal services）,是无连接的。与之相对，无法保证接收套接字接收到的字节流是完整的、无差错的、有序的。

传输层之下的网络层，主要使用的是因特网协议（IP协议）。IP协议是一个尽力而为（best-effort）的传送协议，只实现通信方之间逻辑上的连接，IP协议只能尽力去传送通信双方的报文段，而不作出任何保证（完整性、正确性、有序性）

在实际上的通信实现中，选取怎样的协议，设计怎样的协议栈，协议本身特性固然重要，但也有考虑通信需求的进程。说具体一些的例子，一般常用的应用涉及的也就是TCP和UDP的选择，当然现实中还是使用TCP较多，因为大多数应用对数据的完整性、正确性有很高的要求，比如邮件服务/文件下载，但是对吞吐量和时间却没什么要求，而有些应用比如视频游戏/即时通讯对实时性的要求非常高，对数据丢失却是可以容忍的，视频聊天的时候清晰度不高或者出现小规模马赛克，略显失真不是什么大事，所以这个时候选用UDP协议更合适。 还是沿用上面的类比，传输层协议就像记者一样，每个记者的技能点不一样，一般情况下我们当然会偏爱知识水平高、立场客观真实的西方记者，所以他的出勤会比较多比较著名。那么香港记者经验不足太肤浅、年轻不足以报道全部内容，她就一无是处吗？不是的，她就像UDP，不存在任何拥塞控制而且轻量简单（simple），跑的比谁都快，善于弄大新闻，对于实时性很高的新闻事件让她去也很合适。 因此应用层上的每个协议都会根据需求选择与之对应的传输层协议。

对于底层信道完全可靠的情况，只需要调用跟着基本法来，接到上层调用就做一系列操作（打包之类的）把数据发给下层，接收方对应层协议收到下层的调用就将数据做些操作然后发给上层协议，其他的就不需要考虑了。

我们已经在2.1提到，IP是不可靠的，但是可以依靠上层的协议（如TCP）使这个使用IP协议的通信变得可靠，这就好比记者在采访现场引导出了一些不符合积极向上的个人形象的言辞，但是没关系，上层还有编辑和其他审核人员，他们的专业技能可以保证把通讯稿写的符合基本法，那么宣传上就不会出现偏差。

现在要解决的问题就是怎样在不可靠的网络层协议之上实现可靠的传输层协议。这里以在IP上实现的TCP为例。 3.1 差错检测

包括奇偶校验、校验和、CRC等方法判断收到的数据分组是否损坏，如果不能校正那就丢弃分组。

3.2ACK确认

这是在不可靠底层信道上加入的一种反馈机制，由接收方发送确认消息。发送方发送数据，接收方接收到了以后发了ACK表示“我已经收到了，可以继续发了”，就像发了一个“支持XXXX吗？”对方回答“吼啊”你才可以继续提问，如果你问的那么热情对方一句话也不说，这就不好了，虽然不排除无可奉告的可能，但是也不能再继续问下去了，这个模式就是停止等待（stop-and-wait）协议的思想，只有得到肯定的确认才能继续发送数据。除了肯定确认ACK表示确认收到以外，还有否定确认NAK，用来表示某个数据没有收到，比如滑动窗口协议中用的就是NAK，意思就是“没听说过”。

发送方收到了接收方发来的ACK/NAK后自己也要判断的，然后再把接收方丢失的数据分组（无论是在信道上丢失的还是因为出了偏差所以主动丢弃的）重传一遍。

以上其实就差不多是停止等待协议的基本内容了。

3.3 序号

但是ACK/NAK也可能在传输过程中被损坏，这时候就需要引入序号（sequence number），接收方可以通过检查收到的数据分组的序号发现哪些分组没有收到、哪些分组冗余了。发送ACK/NAK反馈时也可以指定Seq表示需要重传哪些分组或者继续往下发送哪些分组。序号的引入也让传送的效率大大提升，不用像停止等待那种朴素（naive）方法受限于当前的分组战战兢兢，可以以流水线传送数据。

4.后记

“如何理解可靠数据传输”这个问题实在太大，仅仅从概念上来讲就已经非常大了，我不知道题主需要的是具体哪方面的内容，所以把最基础的部分写出来了，事实上比如重传中的超时机制也是很重要的，虽然涉及了一些最基础的元素，但是基础的方法比如退回N步（Go-back-N）、选择重传（SR)、滑动窗口之类也都很重要，但是我的篇幅和精力有限，无法兼顾，只能带你进门，剩下的学习要你自己去完成。这还仅仅是概念，源码阅读和实际应用也需要你自己多多考虑一下。

References [1] Velten, David, R. M. Hinden, and Jack Sax. Reliable data protocol. No. RFC 908. 1984. [2] Kurose, James F. Computer Networking: A Top-Down Approach Featuring the Internet, 3/E. Pearson Education India, 2005.

C/C++Linux服务器开发/后台架构师面试题、学习资料、教学视频和学习路线图（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享有需要的可以自行添加学习交流群960994558