TCP协议与流通讯

TCP(Transportation Control Protocol)协议与IP协议是一同产生的。事实上，二者最初是一个协议，后来才被分拆成网络层的IP和传输层的TCP。咱们已经在UDP协议中介绍过，UDP协议是IP协议在传输层的“傀儡”，用来实现数据包形式的通讯。而TCP协议则实现了“流”形式的通讯。

TCP的内容很是丰富。我不能在一篇文章中将TCP讲完。这一篇主要介绍TCP协议的下面几个方面：

1. “流”通讯的意义与实现方式

2. 如何实现可靠传输

3. 使用滑窗提升效率

 

“流”通讯

TCP协议是传输层协议，实现的是端口到端口(port)的通讯。更进一步，TCP协议虚拟了文本流(byte stream)的通讯。在Linux文本流中咱们谈到，计算机数据的本质是有序的0/1序列 (若是以byte为单位，就叫作文本流)。计算机的功能就是储存和处理文本流。CPU + memory + 存储设备实现了文本流在同一台计算机内部的加工处理。经过一些IO，好比屏幕和键盘，文本流实现了人机交互。而进一步，若是网络通讯可在不一样计算机之间进行文本流的交互，那么咱们就和整个计算机系统的数据处理方式实现了对接。

IP协议(参考协议森林03, 05)和UDP协议采用的是数据包的方式传送，后发出的数据包可能早到，咱们并不能保证数据到达的次序。TCP协议确保了数据到达的顺序与文本流顺序相符。当计算机从TCP协议的接口读取数据时，这些数据已是排列好顺序的“流”了。好比咱们有一个大文件要从本地主机发送到远程主机，若是是按照“流”接收到的话，咱们能够一边接收，一边将文本流存入文件系统。这样，等到“流”接收完了，硬盘写入操做也已经完成。若是采起UDP的传输方式，咱们须要等到全部的数据到达后，进行排序，才能组装成大的文件。这种状况下，咱们不得不使用大量的计算机资源来存储已经到达的数据，直到全部数据都达到了，才能开始处理。

“流”的要点是次序(order)，然而实现这一点并不简单。TCP协议是基于IP协议的，因此最终数据传送仍是以IP数据包为单位进行的。若是一个文本流很长的话，咱们不可能将整个文本流放入到一个IP数据包中，那样有可能会超过MTU。因此，TCP协议封装到IP包的不是整个文本流，而是TCP协议所规定的片断(segment)。与以前的一个IP或者UDP数据包相似，一个TCP片断一样分为头部(header)和数据(payload)两部分 (“片断”这个名字更可能是起提醒做用：嘿，这里并非完整的文本流)。整个文本流按照次序被分红小段，而每一段被放入TCP片断的数据部分。一个TCP片断封装成的IP包不超过整个IP接力路径上的最小MTU，从而避免使人痛苦的碎片化(fragmentation)。

(给文本流分段是在发送主机完成的，而碎片化是在网络中的路由器完成的。路由器要处理许多路的通讯，因此至关繁忙。文本流提早在发送主机分好段，能够避免在路由器上执行碎片化，可大大减少网络负担)

片断与编号

TCP片断的头部(header)会存有该片断的序号(sequence number)。这样，接收的计算机就能够知道接收到的片断在原文本流中的顺序了，也能够知道本身下一步须要接收哪一个片断以造成流。好比已经接收到了片断1，片断2，片断3，那么接收主机就开始期待片断4。若是接收到不符合顺序的数据包(好比片断8)，接收方的TCP模块能够拒绝接收，从而保证呈现给接收主机的信息是符合次序的“流”。

 

可靠性

片断编号这个初步的想法并不能解决咱们全部的问题。IP协议是不可靠的，因此IP数据包可能在传输过程当中发生错误或者丢失。而IP传输是"Best Effort" 式的，若是发生异常状况，咱们的IP数据包就会被轻易的丢弃掉。另外一方面，若是乱序(out-of-order)片断到达，根据咱们上面说的，接收主机不会接收。这样，错误片断、丢失片断和被拒片断的联手破坏之下，接收主机只可能收到一个充满“漏洞”的文本流。

请补上漏洞

TCP的补救方法是，在每收到一个正确的、符合次序的片断以后，就向发送方(也就是链接的另外一段)发送一个特殊的TCP片断，用来知会(ACK，acknowledge)发送方：我已经收到那个片断了。这个特殊的TCP片断叫作ACK回复。若是一个片断序号为L，对应ACK回复有回复号L+1，也就是接收方期待接收的下一个发送片断的序号。若是发送方在必定时间等待以后，仍是没有收到ACK回复，那么它推断以前发送的片断必定发生了异常。发送方会重复发送(retransmit)那个出现异常的片断，等待ACK回复，若是尚未收到，那么再重复发送原片断... 直到收到该片断对应的ACK回复(回复号为L+1的ACK)。

终于收到ACK的发送主机

当发送方收到ACK回复时，它看到里面的回复号为L+1，也就是发送方下一个应该发送的TCP片断序号。发送方推断出以前的片断已经被正确的接收，随后发出L+1号片断。ACK回复也有可能丢失。对于发送方来讲，这和接收方拒绝发送ACK回复是同样的。发送方会重复发送，而接收方接收到已知会过的片断，推断出ACK回复丢失，会从新发送ACK回复。

经过ACK回复和从新发送机制，TCP协议将片断传输变得可靠。尽管底盘是不可靠的IP协议，但TCP协议以一种“不放弃的精神”，不断尝试，最终成功。(技术也能够很励志)

面对“挫折”，TCP协议的态度: never give up

TCP协议和UDP协议走了两个极端。TCP协议复杂但可靠，UDP协议轻便但不可靠。在处理异常的时候，TCP极端负责，而UDP一副无所谓的样子。咱们能够顺便“黑”一下UDP协议：

一样面对“挫折”，UDP的态度: who cares...

 

滑窗

上面的工做方式中，发送方保持发送->等待ACK->发送->等待ACK...的单线工做方式，这样的工做方式叫作stop-and-wait。stop-and-wait虽然实现了TCP通讯的可靠性，但同时牺牲了网络通讯的效率。在等待ACK的时间段内，咱们的网络都处于闲置(idle)状态。咱们但愿有一种方式，能够同时发送出多个片断。然而若是同时发出多个片断，那么因为IP包传送是无次序的，有可能会生成乱序片断(out-of-order)，也就是后发出的片断先到达。在stop-and-wait的工做方式下，乱序片断彻底被拒绝，这也很不效率。毕竟，乱序片断只是提早到达的片断。咱们能够在缓存中先存放它，等到它以前的片断补充完毕，再将它缀在后面。然而，若是一个乱序片断实在是太过提早(太“乱”了)，该片断将长时间占用缓存。咱们须要一种折中的方法来解决该问题：利用缓存保留一些“不那么乱”的片断，指望能在段时间内补充上以前的片断(暂不处理，但发送相应的ACK)；对于“乱”的比较厉害的片断，则将它们拒绝(不处理，也不发送对应的ACK)。

总有那么几个“出格”片断

 

滑窗(sliding window)被同时应用于接收方和发送方，以解决以上问题。发送方和接收方各有一个滑窗。当片断位于滑窗中时，表示TCP正在处理该片断。滑窗中能够有多个片断，也就是能够同时处理多个片断。滑窗越大，越大的滑窗同时处理的片断数目越多(固然，计算机也必须分配出更多的缓存供滑窗使用)。

 

同时处理多个片断

咱们假设一个能够容纳三个片断的滑窗，并假设片断从左向右排列。对于发送方来讲，滑窗的左侧为已发送并已ACK过的片断序列，滑窗右侧是还没有发送的片断序列。滑窗中的片断(好比片断5，6，7)被发送出去，并等待相应的ACK。若是收到片断5的ACK，滑窗将向右移动。这样，新的片断从右侧进入滑窗内，被发送出去，并进入等待状态。在接收到片断5的ACK以前，滑窗不会移动，即便已经收到了片断6和7的ACK。这样，就保证了滑窗左侧的序列是已经发送的、接收到ACK的、符合顺序的片断序列。

对于接收方来讲，滑窗的左侧是已经正确收到并ACK回复过的片断(好比片断1，2，3，4)，也就是正确接收到的文本流。滑窗中是指望接收的片断(好比片断5, 6, 7)。一样，若是片断6，7先到达，那么滑窗不会移动。若是片断5先到达，那么滑窗会向右移动，以等待接收新的片断。若是出现滑窗以外的片断，好比片断9，那么滑窗将拒绝接收。

下面一个视频中，尝试模拟可容纳三个片断的滑窗(固定大小)的工做过程。

可点下面连接： http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html

上面的视频是用Python和matplotlib包制做的。蓝色点表示片断，红色点表示ACK。为了说明乱序片断，我故意让片断和ACK的速度从两个值中随机选择。

能够看到，随着滑窗的滑动，愈来愈多的片断被正确的传送。利用滑窗，咱们必定程度上实现了对乱序数据的缓存。可是，过于乱序的数据依然会被拒绝。咱们以前说的stop-and-wait的工做方式，至关于发送方和接收方的滑窗都只能容纳一个片断。

咱们将在之后看到，TCP协议有实时调整滑窗大小的算法，以实现最优效率。

 

总结

TCP协议和UDP协议走了两个极端。TCP协议复杂但可靠，UDP协议轻便但不可靠。在处理异常的时候，TCP极端负责，而UDP一副无所谓的样子。在TCP中，分段和编号实现了次序；ACK和从新发送实现了可靠性；sliding window则让上面的机制更加有效率的运行。Never give up，这就是TCP协议的态度。

做者：Vamei 出处：http://www.cnblogs.com/vamei
 

欢迎添加我的微信号：Like若所思。

欢迎关注个人公众号，不只为你推荐最新的博文，还有更多惊喜和资源在等着你!一块儿学习共同进步！