我眼中数据通信的三种情况

背景：网络是一个荒凉的世界，除了善良的数据还有各种寄生虫，善良的数据民族为了完成伟大的互联梦，毅然决然走上了征途。。。。。。

一 自生自灭型   无法保证数据的 是否正确 和 是否遗漏

    发送端发送该数据后就不管不问了，接收端接收到后看也没看就丢给了应用程序进行处理。这样的数据跟没人要的孩子一样有可能在路上被寄生虫寄生，直到应用程序碰见了它，应用程序看着无辜的数据，不知道该不该放他进城，如果放他进城，他身上有寄生虫的话，就会在城里造成骚乱。

    为了确定数据在一路上有没有奇怪的东西被寄生，在发送端发送数据之前，发送端的应用程序先给这包数据身上贴个纸条写明这孩子重多少斤。等接收端的应用程序收到这包数据，就把这包数据放在秤上一称，如果发现和纸条上写的重量一样，就得出结论，这孩子没毛病，可以接收他。如果发现和纸条上的重量不一致，那么这小孩有可能被某种生物寄生了，所以不能接收。

二 宁缺毋滥型    可以保证数据的 是否正确 但是 无法保证数据不遗漏（不能保证顺序）

    这次假定要运送的是一个军队，有很多小数据包，每个数据包在出发时都记住了自己的体重，经过长途跋涉，途中遇险无数，终于来到了接收端，应用程序看着这些人，太多了，一个一个称太麻烦了，让系统兄帮我做吧。于是城外盖起了个小棚子，城墙上两个看门的被调来给那群数据包称体重，这时突然发现一个数据包的体重和他报的数不一样，两个看门的对视一眼，把这个不正常的数据包踢了出去。这两个看门的实在太忙了，把那数据包踢出去以后了没时间记下不正常的那个数据包是哪位，而且在安排这群正常的数据包进城的时候也没有维持秩序，导致这群数据包插队的插队，没有顺序。应用程序看着这群横七竖八的数据包，也不知道他们的队型先后顺序，也不知道少了哪几个。应用程序让他们排队，却发现他们并不知道自己在队伍中的位置。看着一团乱糟糟的数据，应用程序开始怀疑人生。

接收端的应用程序实在没办法，找到了发送端应用程序，心说这家伙真清闲，不用像我这么操心。

接收端APP：老哥，你可不能害我，你给我发来的都是什么数据包啊，乱七八糟不成队形的，我都不好意思对别人说这是我要带的兵。
发送端APP：你这不是扯淡吗，我每次发送的时候都是把他们排好队，一个一个送出去的。我还不知道吗？
接收端APP：那是为啥...哦，对,我想起来了，肯定是有几个抄近路自己提前到了，要不就是几个迷路晚到了。

发送端APP望着远方的的风雪和来回交错的大路以及时不时冒头寻找猎物的寄生虫，眼睛微眯，留下一句：这是个危险的世界。

接收端APP无语半晌，还是问：那该咋办？
发送端APP：下次我让他们都记好自己的序号，然后发过去你再通过序号组织他们吧。
接收端APP：好办法，但是如果上一组的数据混到下一组里该怎么办？
发送端APP：那我再让他们记住所属队伍的编号，再配合他们的序号，这下肯定出不了错了吧。
接收端APP：好吧，老哥稳。

于是接收端的应用程序按照新的方法接收数据，如果外面来了个数据包，就问他是哪个部队的，又是在队里什么位置，然后给他安排位置让他排队等着，正常情况下没一会时间一队数据包就凑齐了，只要数据包凑齐了，就可以被允许进城了。但是如果有一队数据包实在等不到他们的队友，那无奈只能让他们解散。因此要求必须有个较大的空间让好几个队的数据包等待他们的队友。

三 保质保量型     既可以保证数据的正确 又可以保证数据的存在（以及顺序）

    网络世界的管理者发现各个城池的数据来往可靠性太差，于是命令各个城池之间一定要相互联系。既然上面的发话了，各个城池就开始了通信方式的革新，发送端发送记住了自己体重的数据包，然后派了个人在城门口守着，接收端接收到数据包，如果确定可以进城，就派一个最小号的数据回去通知发送端成功接收了，可以继续发送了。如果数据包不满足进城的要求，则派出去的迷你数据回到发送端通知再发送一个相同的数据包，这样就能确保每次发送的数据都会被接收。
    如此以来，每次发送端发送的数据和接收端数据不会存在错位的问题，数据虽然会丢失，但是会补偿，因此可以认为在这种数据传输的制度下，数据不存在丢失的可能，而且同时确保了传输的顺序。当然，经过一来一回，其通信的周期自然大大增加。

    接收端应用程序的工作就轻松了，只需要不断接收数据就可以了。由于接收端的应用程序和发送端的应用程序事先已经约定第几个数据用来干什么，因而在接收端和发送端的同步情况下，两端不需要额外的数据进行同步。