初次熟读TCP，随着TCP的发展路线对他深入了解，真心觉得TCP协议的美妙之处。他比UDP这家伙更加可靠，深得我们信任。通过一个个英文简写，例如CRC、ARQ、RTT、ACK、SACK、DACK等，组成网络的传输控制机制。他们相辅相成，最终实现人们对他的要求——可靠！接下来我们来聊一聊TCP简写的美妙之处。
首先我们来提下TCP接收端与发送端的恩怨情仇。
发送端给接收端发一个数据，数据怎么保证不出错，这时就需要CRC或者ARQ来实现。CRC校验和保证数据的正确性。而ARQ（Automatic Repeat Request）就是自动重复请求，不断的重新发送，直到数据被接收端接收。如果用ARQ解决了数据不出错问题，还需它衍生出来的一系列问题（有趣的道与魔的抗衡）。其一，接收方如何确定已收到分组。其二，若发送方发送的多个重复分组，接收端如何确定是否是重复分组。解决第一个问题的办法是鼎鼎大名的ACK（ackonwledgment），人称确认！！发送方发一数据，等待ACK；接收方接收到数据后，发送对应ACK给发送方。如此反复！魔性剧增！ACK的问题又来了！道法怎样才能与之匹敌？ACK的问题所在有三点，1、发送方需要等ACK多久，总不能等到花儿都谢了吧。2、数据都会丢失，ACK亦会丢，该如何是好？3、发送方的数据出错了，接收方该如何应对？
有问题了，就需要被解决！发送方需要为ACK付出多少青春等待，这是又一个大哥出来露脸——RTT（round trip time），中文名叫往返时间。这个问题太难！后续章节继续讨论。第二个小问题的解决方法是既然发送方接收不到ACK，那就重新再发送ACK对应的数据呗，直到接收到ACK。简单简单！但接收端如何对重复的数据进行区分呢？又有新问题出来了，有点意思！第三个问题就是利用校验和与CRC来解决。强大的CRC适应许多生存环境！
接下来解决接收端如何区分重复的分组——序列号。给包打个唯一的tag，这样不就能够区分了嘛！！
之前所讲得是发送端发一个数据包，但网络的胃口肯定不止这样！所以发送端需要发送更多的数据给网络！这就是多分组情况！相应的问题又来了！发送方有多个分组数据时，他需要决定什么时候发送一个分组或多个，发送的分组怎样保存来应对可能的重传。而接受方需要应对的问题是哪些分组已经收到，哪些却没有收到。更有甚者，当收到多个分组失序到达时，接收端的应对策略！
接下来的博文我们来陆续探讨以上这些有意思的问题！