【读】这一次,让咱们再深刻一点 - TCP协议

这是关于网络系列的第三篇文章,接下来会有更多精彩内容.敬请期待! 让咱们一块儿乘风破浪!

前言

上篇咱们了解了关于UDP协议的相关知识,这里咱们继续讨论运输层的TCP协议.该篇篇幅较长,但愿你能耐心的读下去并有所收获.

TCP概述

TCP自己比较复杂, 也比较重要, 这里先简单了解下.慢慢来!

TCP的主要特色

• 面向链接.应用程序在使用TCP以前, 必须创建TCP链接. 在传送完数据以后,再释放链接.
• 点对点通讯.链接了两端的socket.
• 提供可靠交付的服务. 经过TCP链接传送的数据, 无差错, 不丢失, 不重复且按序到达.
• 全双工.双方能够在任什么时候候发送数据.
• 面向字节流.
  流是指流入到进程或从进程流出的字节序列.
  面向字节流的含义是:虽然应用程序和TCP交互的是大小不等的数据块,但TCP把这些数据当作无结构的字节流.TCP只保证发送方发出的字节流和接收方接到的字节流相同.

TCP的链接

每条TCP链接有两个端点(正是TCP提供点对点通信的体现).其链接的两个端点称为套接字(socket).套接字是由IP地址和端口组成, 中间使用冒号隔开.如192.168.0.1:80.

TCP可靠传输的工做原理

TCP报文最终仍是要交付到网际层的IP协议手中,而IP协议不提供可靠的服务,TCP必须本身才去措施保证服务的可靠.下面先了解下相关的理论基础.

中止等待协议

中止等待协议意为每发送完一个分组就中止发送,等待对方的确认,在收到对方确认后再发送下一个分组(TCP提供全双工的通讯,为了简单这里只考虑A作为发送方,B做为接收方).

无差错状况

使用下图来理解下:

在没有差错状况下(如上图a状况),A发送分组M1,发完就暂停,等待B的确认.B收到了M1就向A发送确认. A收到对M1的确认后发送M2..M3.这是 中止等待协议在无差错时的表现.

出现差错

上图b是传输过程当中出现差错的状况.B接受到M1检测出了差错,丢弃了M1,其余什么也不作了(也可能M1根本没有到达B).A在指定时间内没有收到对M1的确认,就认为M1丢失,须要重传,这就叫作超时重传.要实现超时重传就要在发送完分组后设置一个超时计时器,若在计时器到期以前收到了确认报文,就撤销计时器.这里须要注意如下内容:

• A在发送完分组以后,须要暂时保留发送出去的分组,以便实现超时重传.在收到确认后才能清除该分组.
• 分组和确认分组都须要进行编号 ,以便区分.
• 超时计时器的时间应当比分组传输的往返时间更长一些.关于时间如何选择,后面会进一步了解.

确认丢失和确认迟到

确认丢失和确认迟到也是可能出现的状况.以下:

• 确认丢失
  如上图a. B发送出的对M1的确认丢失了.A在规定时间内没有接收到确认,没法知道是本身发出的分组出错,丢失,或B的确认丢失.A须要在计时器到期后重传M1.这时B又收到了M1,须要

  • 丢弃该分组M1,不向上层交付.
  • 向A发送确认.以避免A再次发送M1.

• 确认迟到
  如上图b. 因为网络延迟等缘由,B发出的对M1的确认没能在指定时间内到达A,而是在之后的某个时间到达了.这时A会收到重复 的确认(由于A会超时重传).对于这样的确认,A只需丢弃.对于重传的M1,B也须要确认,并丢弃M1.

上述的确认和重传机制,就是TCP实现可靠传输的依据.

信道利用率

中止等待协议简单,可是信道的利用率过低,以下图:

• Td是发送分组所需时间, 等于分组长度除以发送速度.
• RTT是发送的分组到达对方使用的时间 和 对方确认分组回来使用的时间之和.
• Ta是发送确认分组使用的时间, 等于确认分组的长度除以发送速度.

由于仅在Td的时间内是用来传送有用数据的,信道利用率可使用下面的算法来粗略估计:

现假定1200km的信道往返时间RTT=20ms.分组长度1200bit,发送速率1 Mbit/s.忽略其余处理时间和Ta(通常Ta远小于Td).可算出U = 5.66%. 信道的利用率超低!随着发送速率的增长,这个数字还会降低!

连续ARQ协议

为了提升信道了利用率, 能够采用流水线的方式传输, 这句涉及获得连续ARQ协议.

在 连续ARQ协议中,发送方须要维持一个 发送窗口,它可使在窗口内的连续多个分组的数据连续发送出去,没必要等待对方的确认.以下图:

图中的 发送窗口大小为5, a中的5个分组能够连续的发送不用等待确认.在发送方每收到一个确认,就将发送窗口向前(向前指向着时间增大的方向,向后指向时间减小的方向)滑动一个位置.如b所示.此时能够发送第6个分组了.

接收方通常采起累积确认的方式, 接收方没必要对每一个分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认, 这就表示到这个分组为止的全部分组都以正确收到.这样的优势是即便确认丢失也没必要重传,缺点是不能向发送方反映出接收方已经正确收到的全部分组信息.

例如,发送方发送了5个分组,而中间3个分组丢失.这时接收方只能对前两个分组确认.发送方没法知道后3个分组的下落,只好把后3个都重传一次.这就叫作Go-back-N,表示须要在退回来传送以发送的N个分组.

滑动窗口是TCP的精华所在,后面再详细的说明.

TCP报文首部

在深刻了解TCP以前, 了解TCP报文首部是必要的.下面一块儿来了解下其首部的具体内容.

虽然TCP是面向字节流的, 但TCP传送的数据单元是报文. 一个TCP报文包括首部和数据两个部分(IP报文和UDP报文也是由首部和数据组成),TCP的功能也是依靠首部各个字段的.

从上图能够看到, TCP的首部是由固定的20字节加上后面的选项部分(4n字节,n 须要为整数).

• 目的端口和源端口, 各占2字节.基于端口复用和分用(在上篇提到过这个概念).
• 序号, 占4字节. 范围是[0, 2^32-1].序号达到最大值后, 又回到0重新开始.由于TCP是面向字节流的, 在TCP中传送的每个字节都按序编号. 整个要传送的字节流的起始序号在链接创建时肯定.首部中的该字段指的是本报文段所发送的数据的第一个字节的序号.例如: 一个报文段的序号为301, 而携带数据100字节; 能够肯定的是,本报文段数据的第一个字节序号为301, 最后一个字节的序号为400, 下一个报文段的序号应该是401.
• 确认号, 占4字节.表示指望收到对方下一个报文段的数据第一个字节的序号.例如,B正确收到A发过来的一个报文段,其序号值为501,而数据长度是200字节(也就是说该报文段的数据字节序号从501到700).这代表B正确收到了A发送的到序号700为止的数据, 所以B指望收到A的下一个数据的序号是701, 因而B将发给A的确认报文的确认号置为701.请记住,确认号为N,代表序号为N-1的全部数据都以正确收到.
• 数据偏移, 占4bit. 它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远(单位4字节).其实它指出了TCP报文首部的长度是多少.因为TCP报文首部还有不肯定的选项部分,该字段的存在是必要的.最大偏移为15 * 4字节=60字节(也肯定了TCP首部的最大字节数), 去掉首部固定的20字节, 即选项部分最大为40字节.
• 保留, 占6bit. 暂未使用,目前置为0.
• 紧急URG(URGent), 占1bit. 当URG=1时,代表后面的紧急指针有效.它代表该报文中有紧急数据,须要优先传送.
• 确认ACK(ACKnowledgment), 占1bit.当ACK=1时,确认号字段才有效.
• 推送PSH(Push),占1bit. 当两个应用程序进行交互式通讯时, 在一端的应用进程但愿在键入一个命令后当即的到对方的响应.这种状况下,TCP能够将PSH置为1,并当即建立一个报文发送出去,接收方在收到PUS=1的报文后,尽快的向上交付.
• 复位RST(ReSet), 占1bit. 当RST=1时,代表TCP链接出现严重错误,必须释放链接,从新创建.还可使用RST=1来拒绝一个非法的报文段或拒绝打开一个链接.
• 同步SYN(SYNChronization), 占1bit. 在创建链接时使用同步序号.当SYN=1而ACK=0时代表这是一个请求创建链接的报文. 若对方赞成创建链接,则响应报文中SYN和ACK都应该是1.能够发现,当SYN=1时说明该报文是用来创建链接的(请求创建链接报文,或赞成创建链接报文).
• 终止FIN, 占1bit.用来释放链接,当FIN=1时,代表此报文的发送方数据已经发送完毕,要求释放链接.
• 窗口, 占2字节.值的范围是[0, 2^16-1]之间的整数.指出了接收方目前能够接受数据的大小, 发送方在发送数据时必须考虑到这点.例如,A(做为接收方)发出了一个确认报文,确认号为701(这代表前700个编号数据都正确接收),窗口字段为1000. 这代表A的接收缓存空间还能够接收从编号701到1700的1000字节数据.总之,窗口明确指出了容许发送方发送的数据数量.
• 校验和, 占2字节. 包含首部和数据两部分的校验.这里不对校验的方法作深刻讨论.
• 紧急指针, 占2字节.仅在URG=1才有效.它指出紧急数据的字节数量(紧急数据在该报文的数据部分最前方).即便窗口为0,也能够发送紧急数据.
• 选项, 长度可变,最长40字节.

TCP可靠传输的实现

为了方便说明,下面的讨论基于A发送数据,B接收给出确认.

以字节为单位的滑动窗口

假定A收到了B的确认报文,该报文首部的窗口字段值为20字节,确认号字段为31(这代表B正确接收了前30字节的数据, 指望收到编号为31开始的数据).那么A能够根据此信息构造本身的发送窗口.以下:

说明以下:

• A此时能够将窗口内的数据都连续的发送出去, 在未收到确认以前,该数据须要保留,以便超时重传使用.

• A的发送窗口的大小受B确认报文中的窗口字段值的影响(如今A的发送窗口大小为20).A的发送窗口大小不能超过B指定的窗口大小.

• A的发送窗口后沿后面部分的数据是以收到确认的,能够再也不保留.前沿前面的数据是不能发送的,对方B没有足够的缓存区接收.

• A的发送窗口的后沿变化状况有两种:

  • 不动.说明没有收到新的确认.
  • 向前移动.说明收到了新的确认.
  • 不可能出现向后移动,若向后移动表明确认过的报文须要再次确认,这是不存在的.

• A的发送窗口的前沿一般不断向前移动,但可能不动:

  • 未收到新的确认,B通知的窗口大小也未变化.
  • 收到新的确认,但B的窗口缩小,恰好使A的发送窗口不动.

  若A收到确认后,得知B的接收窗口小于如今的发送窗口, 这时须要A发送窗口的前沿向后移动! 这是TCP标准强烈不建议的.由于A可能再收到该确认以前,已经将发送窗口的数据发送出去,如今又不容许发送(数据不在窗口中就是不容许发送的意思).将会出错.

假定如今A发送了31~41的数据,但未收到确认,发送窗口位置不变,42~50表示未发送的.以下图a示 :

从上面的状况能够看出,描述一个发送窗口的状态须要如上图的三个指针: P1, P2, P3,它们都指向字节的序号.

• 小于P1的表示已发送且收到确认的部分,大于等于P3的表示不容许发送的.
• P3-P1表示了A的发送窗口
• P2-P1表示发送但未确认的字节数
• P3-P2表示容许发送但未发送的字节,或者称为可用窗口或有效窗口.

对于上图B的接收窗口:

• B的接收窗口大小为20(从31~50).30及以前的数据时已经发送确认且交付上层的,可用不用保留了.序号31~50的数据是容许接收或但愿接收的数据.
• 假设如今B收到了序号32和33的数据,但未接收到序号31的数据,B只能给出确认号为31的确认,不能是32或33.

如今假定B接收到了31号数据 ,并将序号31~33的数据交付上层,而后删除这些数据,给A发出确认报文(确认号为34).将窗口向前移动3个序号 ,窗口大小任然为20.

如今B又收到了未按序到达的37,38和40的数据,B选择先暂存.

A在收到B的确认后,将发送窗口向前移动3个序号,P2指针不动(P2表示了A能够发送但未发送的起始序号),如今A能够发送的数据增多了,直到53.

上面的状况以下:

如今A选择继续发送数据,将A中的待发送数据全都发送出去.以下:

此时,A并无收到B确认,本身的有效窗口为0,再也不继续发送数据. 也许在超时计时器到期后A任然未收到B的确认,A会从新发送数据,直到收到B的确认后.

经过上面的描述,咱们了解了TCP中滑动窗口的工做模式,但愿你能理解.

超时重传时间的选择

超时重传是保证TCP可靠的重要举措, 这个时间时如何肯定的呢?

TCP采用了自适应的算法: 它会记录一个报文发出去的时间,和接收到相应确认的时间.这两个时间之差就是报文段的往返时间RTT.TCP还会保留RTT的加权平均RTTs.当第一次获取到RTT时,RTTs的值也是这个,之后每次获取到RTT后,就会从新计算RTTs:

新的RTTs = (1-x) *  旧RTTs + x * 新RTT值
复制代码

超时重传时间(RTO, retransmissionTime-Out)应略大于RTTs,具体更详细的计算,这里就再也不展开.

选择确认SACK

若接收方收到的报文无差错,只是未按序到达,中间缺乏了一些, 那么可否只让发送方只重传缺乏的数据呢? 选择确认是一种方法.

假如,接收方收到的数据以下:

• 1~1000, 1501~3000, 3501~4500已经正确收到
• 中间多个部分缺失

若想发送方只传递缺失部分,须要告知接收方接收数据的状况.接收方能够将这些边界告知发送方.例如图中的L1, R1, L2, R2...

若选择使用选择确认,须要在TCP链接创建时彼此商量好,在TCP报文首部的选项部分来讲明这些边界值.

L1, R1, L2, R2这些也是报文序号中的一个,所以每个须要4字节.在接收方存在多个不连续数据时,报文首部的选项字段的大小(40字节)是不够用的.因此重传时大多仍是选择对未确认的数据重传.

基于滑动窗口的流量控制

流量控制,控制的流量是发送方发出的流量,不至于发的数据太多,接收方来不及接收.TCP基于滑动窗口很容易实现流量控制.借用下图理解下:

• 在创建链接时,接收方(B),告诉了发送方(A):个人接收窗口是400(单位字节).

• 图中的ACK为TCP首部的ACK字段,ack为首部的确认号字段.

• 流量控制体如今:rwnd=300, rwnd=100, rwnd=0.在确认报文的窗口字段设定了发送方可以发出的数据多少,从而控制流量.注意只有到首部的ACK字段值为1,窗口字段的值才有效.

• 假设在B发送了rwnd=0以后,过段时间因为本身又但愿接收到数据,因而发出rwnd=400的报文,可是该报文丢失了,这样A依然没法发送数据,B但愿接收但接收不到数据.

  为解决该问题,TCP为每一个连接都设有一个持续计时器.只要接收到对方窗口为0的通知,就启动持续计时器.在计时器到期后,就发送探测报文,对方能够在该报文的确认中告知当前的窗口值.若窗口任然为0,那么就从新设定计时器,若不为0,那么上述的问题就解决了.

是否是在理解了滑动窗口的基础上,流量控制应该很简单了吧!

拥塞控制

拥塞是指对网络某一资源(带宽,缓存等)的需求超过了可提供的部分,从而使网络中传送的数据不能按时到达,网络性能变差的状况.

拥塞控制就是防止过多的数据注入到网络中,这样网络中的资源压力就小了.

流量控制和拥塞控制彷佛很类似,可是他们不一样.前者立足于接收和发送者双方的状况;然后者注重的是数据量对网络环境的影响.

TCP 控制拥塞的方法

TCP采用慢开始,拥塞避免,快重传,快恢复.

• 慢开始.当链接创建开始传递数据时,因为不清楚网络情况,先将较小数据发送出去,有小到大的增长发送窗口.好比先发送一个字节数据,等收到确认后再发送2个字节...4个等.每通过一次确认就将发送窗口加倍.
• 拥塞避免思路是在通过确认后,每次将发送窗口增长1,而不是像慢开始那样成倍增长.

经过下图理解:

• 图中的ssthresh为慢开始门限,在慢开始的做用下,发送窗口成倍增长,不可能没有上限,这个上限就是慢开始门限.慢开始门限如下使用慢开始控制发送窗口,而在慢开始门限以上使用避免拥塞方法.
• 横轴,传送轮次意为:连续发出的数据,再通过确认后,称为一个轮次. 纵轴,拥塞窗口,就是发送窗口.
• 标注1以前(发送窗口值未达到慢开始门限),采用慢开始方法控制发送窗口;到达门限值后,为避免拥塞采用避免拥塞方法控制发送窗口.
• 发送窗口还继续增大,直到标注的2,网络出现超时,发送方判断出现了拥塞,将慢开始门限设置为发送窗口值的一半,同时将发送窗口设为1,进入慢开始.
• 当再次到达慢开始门限时(标注3),执行避免拥塞控制,直到标注4.此时出现了对一个报文3次确认的状况(如图中标注3-ACK).
  • 在个别报文丢失(而不是网络拥塞),发送方收不到确认,误觉得网络拥塞.
  • 快重传可让发送方尽早知道报文丢失.它要求接收方要对收到的数据尽快确认.即便收到了未按序到达的数据,也要对以前确认过的报文再次确认.这样就不会超时,也不会形成发送方误解网络拥塞.
  • 上图标注的3-ACK就是连续的3次重复确认.
• 到标注4后,发送方知道了网络未出现拥塞, 便启用快恢复控制,将门限值调整为发送窗口的一半,发送窗口也减半.开始避免拥塞控制.固然这只是一种快恢复的方法.

下面是TCP拥塞控制的流程图:

经过上面简单了解了TCP拥塞控制的方法,更详细的再也不深刻.经过拥塞控制和以前了解的确认报文首部的窗口值能够知道,发送方的发送窗口大小是拥塞控制的窗口和确认报文首部的窗口值中较小的一个.

链接管理

TCP是基于链接的.那么链接是如何创建的?答案就是3次握手:

• 服务器是处于监听状态的，以便及时发现客户端创建链接的需求。
• 客户端TCP进程主动发出Flag段SYN=1，报文序列号seq=x的报文段（A），请求创建链接。状态变为SYN-SENT（同步已发送）。
• 服务器收到对应报文段（A）后，会发出确认报文段（B）。该报文（B）的Flag段的SYN和ACK都是1，确认号ack=x+1（意为对A的确认），同时设定本身的初始序列号seq=y。状态由LISTEN（监听）变为SYN-RCVD（同步收到）。
• 客户端收到服务器的确认后，还需向服务器发送确认。报文段（C）的Flag的ACK=1，确认号ack=y+1（意为对B的确认），序列号seq=x+1。状态变为ESTABLISHED（已创建链接）。服务器在收到报文段后状态也变为ESTABLISHED。
• 客户端的最后确认是必要的，能够防止以失效的请求创建链接报文忽然到达服务器而产生错误。

下面再来看看链接是如何释放的：

• 在链接创建完成，数据传输完毕后，通讯的双发都是能够释放链接的。但一般状况，服务器都是被动的一端，客户端才知道，本身是否是真的没有数据要发送了。
• 在数据传输过程当中，客户端和服务器都处于已创建链接的状态。
• 客户端TCP程序先发出链接释放报文（A），并中止发送数据。该报文的Flag位的FIN=1，seq=u（等于其上一个序号+1）。客户端进入FIN-WAIT-1状态，等待服务器确认。
• 服务器接收到释放链接报文段后发出确认报文（B）Flag位ACK=1，确认号ack=u+1，序列号seq=v（等于其上一个序号+1）。服务器进入WAIT（关闭等待）状态，这条TCP链接处于半关闭状态，也就是客户端到服务器方向的通道被关闭。
• 客户端在收到服务器的确认报文（B）后，进入FIN-WAIT-2状态，等待服务器发出链接关闭的报文。
• 若服务器也没有其余数据须要发送，就会向客户端发出释放链接的报文（C），Flag端FIN=1，ACK=1，确认号ack=u+1（和报文B同样），序列号seq=w（服务器可能在发出报文B以后又发送了数据，w的值可能不是v+1）。服务器进入LAST-ACK状态，等待客户端的确认。
• 客户端在收到服务器释放链接报文（C）后，发出确认报文（D）。Flag段ACK=1，确认号ack=w+1，序列号seq=u+1（报文A的seq+1）。客户端进入TIME-WAIT状态。如今TCP链接并无释放掉，必须等待2倍MSL（最长报文段寿命Maximum Segment Lifetime，该时长是由时间等待计时器设置）后才能关闭。
• 服务器收到报文D后，就能够关闭链接。
• 为什么要等待2MSL，客户端才能关闭链接
  • 保证客户端发出的报文D可以到达服务器。在报文D丢失的状况下，服务器未收到客户端的响应，因此会触发TCP的超时重传，而客户端能够在2MSL时间内收到重传的报文，并对之响应且从新启动2MSL计时器。最终，该链接能够正常关闭。
  • 防止失效的链接请求报文出现。能够保证在建立该TCP链接中发出的报文都在网络中消失。
• 关于TCP的保活计时器：在客户端服务器之间的TCP链接创建后，客户端忽然故障，服务器也就没法再收到来自该客户端的任何报文，为了使服务器不会白白等待客户端而使用的措施是保活计时器。服务器每次收到客户端的数据就会重置保活计时器，时间2小时。若2小时未收到客户端的任何数据，服务器发送探测报文，每隔75秒一次，若连续10个探测报文都没有客户端的响应，该链接就会被服务器关闭。

结语

到这里,说明你有足够的耐心!奖励下本身!从上面能够看出,TCP的滑动窗口是比较重要的,后面的流量控制和拥塞控制都是基于滑动窗口的.再后序文章中咱们再一块儿继续学习.

注

• 部分图片来源于网络，若有侵权，请告知。
• 若有错误，还请指出。共勉！
• 您的喜欢是最大的赞扬。