本章主要通过一段对话来说明 TCP?协作的数据传输过程，主要内容是：
? 1.丢包问题，怎么知道丢包，丢包了怎么办?
? 2.乱序，网络不可靠，如何知道那些数据已被正确接收，那些没有？
? 3.如何实现最大传输效率。
client、server 和 network
lient：Hi network，我想向 server 传输数据，需要什么条件？
network：?哦，这个简单，你只需要告诉我你的 IP 和端口号、server 的 IP 和端口号(四元组)以及你要传输的内容。
client：Ok,那我试试。
client：确实发送成功了，但是我怎么知道 server 有没有接收成功？Hi server, 你能告诉我么？
server：这个嘛...，要不这样吧，我接受到你的数据的时候，我给你返回一个 ACK, 表示我已正确接收了你的消息(等停协议)，如何？
client：Ok，可以，那我也设置一个超时时间，如果在指定时间内，你都没回复我 ACK，我就认为这个数据你没有收到，我重发一次（超时重传机制）。
????????client 按这个方式发送了一段时间之后，陷入了一个苦思，它觉得这样的效率太慢了，每发送一个数据就需要等到一个 ACK，然后才能继续发送下一个，于是就去找 server 聊了起来。
client：server, 我觉得按这样的方式传输效率太慢了，每次都要等你回复之后才能进行下一个数据的传输。
server：确实是这样的，不然我们试试这样，你不用等待我的回复，你有数据就发给我，我收到数据就给你返回对应的 ACK。
?
?????????client 和 server 就按这个方式走了一会，发现挺好的，效率也高了很多。就在此时，network 打了个喷嚏。突然出现一个问题。
client：?server，我是按照 ABCD 这样的顺序给你发的，理论上你应该给返回一个 1， 怎么会返回 0。
server：let me check..., 没有问题，根据我记录我收到是 DABC, 你是不是自己弄错了。
client：没有啊，我这边记录了 ABCD 啊...。如果我们都没问题，难道是 network 搞错了。Hey network，别装死了，吭一声，这个问题怎么回事？
network：what...,上面的问题么？这个在复杂的网络中确实会出现这个问题(乱序)，这个顺序我是没办法保证的，你们要自己保证啊？
client：?啊..., 难道我要回到一个数据一个 ACK 的版本么，那效率谁受得住。
server：嗯..., 也不至于，要不你告诉每个数据的发送顺序，我处理一下如何（序列号 ISN)。
client：这个是个好办法，那就这样，每个数据我都携带一个编号，你通过编号来对数据排序。
server：?Ok，那我在每次收到数据之后，我也告诉你我下一个要接收的数据编号(ACK = ISN+1)。
?????????跑了一段时间，没啥问题，准备投入正式环境使用。client 愉快的狂发数据。
server：Hey client, 你一下发那么多数据给我，我也处理不过来啊。我只能将无法处理数据被迫丢弃了。
client：啊...., 那这样我不是得重发很多数据，那怎么行。
server：是滴，所以你得控制你发送速度？
client：这也行，但是我总不能写死一个固定速率吧，你有时候比较闲，有时候有比较忙。我也不知道什么时候应该多发，什么时候该少发。
server：嗯， 这样吧，我每次ACK，我都告诉你我的能处理的数据窗口。你可以根据这个窗口值，动态调节你的发送速率(awnd 接收端窗口)。
client：好，那么我们再试试(流量控制)。
????????过了一段时间, network 突然冒出来。?
network：?两位大佬，你们是爽了，考虑过我的心情么。我处理不过来啊。
client：啊..., 你不是数据的搬运工么，怎么你也遇到瓶颈了。
server：确实，我只考虑我和 client, 忘了 network 在复杂的网络中，每个节点的传输和处理数据能力大小不一样。
network：?是的，所以为了保证效率，你们要考虑我的传输能力。
client：好吧，要不你也告诉我，你能接受多少数据量，我在你们两者之间取个最小值？
network：我咋知道我接受能力是多少，我这边那么都中间商，每个中间商的能力不一样，而且我也不知道你要用到那些中间商。
client：...
server：client, 尝试自己去探测一下 network 的传输能力吧(拥塞控制)，比如你先发1个数，如果没问题，就发2个，然后发4个，然后发8(2的指数增长)，以此类推，直到出现丢包(慢启动)。
client：?这是个好办法，那如果出现丢包了，我怎么办？退回上一个吗？虽然上一个是不会出现丢包。但也不是最佳值，我如何逼近这个最佳值呢？
server：嗯，我觉得可以考虑线性增加，比如每一个RRT时间，就将当前的值加一，至于具体算法如何，你可以根据自己的情况考虑（拥塞避让）。
client：?好。
?
?
?
????????好了，现在传输速率大家都满意了，总不会在出什么幺蛾子吧。过了一段时间，server进入了一段深思，那就是，难道每个数据报我都需要 ACK，我能不能积累一下，一次告诉你。于是跟发送端聊了一下。
server：?要不我多个连续的数据报，我只告诉你我收到最大的连续序列号，比如你发了1,2,3,4,5, 当我接收到 1,2,3,5 的时候，我就返回给你 收到 3，这样1,2 就等于默认收到了如何(累计 ACK)。
client：let me think, 可以。
network：这样不错，这样我就不用那么累了，少了很多工作量。
????????又发了一段时间，server 抱怨。?
server：为啥当有数据丢包的时候，我总是要等一段时间，你才发给我，每次为了一个数据，要等那么久。你能不能快点啊？我很忙的。
client：我也很无奈啊，我也不能马上知道你丢了数据，我只是在长时间等不到对应数据的 ACK，我才会重新发给你。
server：好吧，那确实也不是你的问题，不如这样，上次我说过，我会将收到的最大连续序列号的ACK 告诉你么。你看，如果你发送 1,2,3,4,5。 如果2丢失了， 收到3的时候，我给你的是2，收到4也是2, 5的时候也是2,。那能不能通过这种规律，确定我是不是丢包了？(快速重传)
client：你的意思是说，如果我连续收到同一个 ACK, 那我可以认为对应序列号的数据丢失么？我觉得的可以，那收到几次算呢？(重复ACK)
server：几次我就不知道了，开放给使用者吧，默认3就挺好。(阈值)
????????又过了一段时间，client 抱怨了。
client：?每次收到重复 ACK, 我就只能发生一个数据报，我也只知道对应那个ACK的数据丢失，重发完之后，又会来一个重复 ACK，我又得重发一次。比如:
????????我发 1,2,3,4,5,6,7,8,9
????????你只收到了1,3,4,7,8,9
?我收到了2的累计 ACK,我重发了2， 但是5，6 也缺失，下次还还得重新发5，6，这样效率一点不高，不如你顺便告诉我，你已接收的序列号，比如上面这种场景， 要就告诉我 ACK=2,? SACK= 3-4,7-9。那就可以推断出2,5,6需要重发。
server：嗯，可以也是一个好办法，那这样吧，如果你开启了某个标记位，缺失需要这个功能，那我就按你的说的，告诉你一定数量的缺失序列（SACK）
client：合作愉快。
总结
? ? ? ? 本章主要介通过一个虚构故事，来阐述??TCP?协议如何保证在复杂的网络中，解决丢包、乱序、可靠性以及效率问题。其中牵扯几个概念比如 ACK、ISN、拥塞控制、慢启动、累计 ACK、快速重传等将在下一章进行解释。
参考
1.《TCP/IP 详解 卷一》 13章至17章
2.https://mp.weixin.qq.com/s/h89R86KhWiQKsBvfZpyF5Q?