TCP协议浅析

作者: VictorHong | 来源:发表于2020-07-16 15:56 被阅读0次

iOS网络协议----HTTP/TCP/IP浅析
IOS 网络协议浅析
iOS-10 网络协议
我整理的网上讲解详细的文章
TCP协议浅析
TCP协议浅析
15分钟TCP
计算机网络02 - 传输层
TCP协议三次握手和四次挥手
TCP/IP协议

TCP中流的解释

TCP中的“流”(stream)指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

一个简单的示意图如下：

TCP流的概念

TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用进程给出的）。如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去

TCP报文格式

TCP报文

TCP的固定包头为20个字节，下面是几个参数：

序号：即SEQ序号。TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
确认号：即确认序号，也叫ACK序号。是期望收到对方的下一个报文段的数据的第一个字节的序号。只有ACK标志位为1时，确认序号字段才有效，ACK=SEQ+1。
数据偏移：它指出。TCP报文段的数据起始处距离TCP报文段的起始处有多远。
标志位：共6个，即URG(紧急比特)、ACK(确认比特)、PSH(推送比特)、RST(复位比特)、SYN(同步比特)、FIN(结束比特)等。
窗口大小：窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上。
校验和：检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
紧急指针：紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。
选项：TCP只规定了一种选项，即最大报文段长度MSS（MaximumSegment Size）。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是MSS 个字节。”

三次握手：

三次握手是必须的——TCP 需要 seq 序列号来做可靠重传或接收，而避免连接复用时无法分辨出 seq 是延迟或者是旧链接的 seq，因此需要三次握手来约定确定双方的 ISN（初始 seq 序列号）。

三次握手

建立TCP连接时，需要客户端和服务器共发送3个包。

第一次：客户端发送初始序号x和syn=1请求标志

第二次：服务器发送请求标志syn，发送确认标志ACK，发送自己的序号seq=y，发送客户端的确认序号ack=x+1

第三次：客户端发送ACK确认号，发送自己的序号seq=x+1，发送对方的确认号ack=y+1

连接过程

四次挥手

其中A发送的X为前面已传送过的数据的最后一个字节的序号加1。

第一次A到B方向结束，第二次B到A方向结束。

第二次B发送的SEQ=Z(在半关闭状态B可能又发送了一些数据),B还必须重复上次已发送过的确认号ACK = X+1。

四次挥手

请注意，TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命(Maximum Segment Lifetime)，RFC 793建议设为2分钟。但这完全是从工程上来考虑，对于现在的网络，MSL = 2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。

为什么A在TIME-WAIT状态(发送最后一个数据包之后)必须等待2MSL的时间呢？这有两个理由。

第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN + ACK报文段的确认。B会超时重传这个FIN + ACK报文段，而A就能在2MSL时间内收到这个重传的FIN + ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早一些。

断开过程

TCP的4个定时器

重传定时器、坚持定时器、保持定时器、时间等待定时器

重传计时器：

当TCP发送报文段时，就创建该特定报文段的重传计时器。

若在计时器截止时间到(通常60秒)之前收到了对此特定报文段的确认，则撤销此计时器。
若在计时器截止时间之前没有收到对此特定报文的确认，则就认为该报文丢失，需要重传此报文段，并将计时器复位。

坚持计时器-防止收不到非0窗口大小的报文

假设TCP收到了一个窗口大小为0报文段，发送TCP就停止传送报文段，直到接收TCP发送一个非零的窗口大小。但是这个确认有可能丢失，若确认丢了，接收TCP并不会知道，而是认为他已经完成任务了。但是发送TCP由于没有收到确认，就会一直等待接收方发送确认来通知窗口的大小。双方的TCP这时就会造成死锁，所以要使用一个计时器来避免死锁的发送。

当TCP收到一个窗口大小为0的确认时，就要启动坚持计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的探测报文，这个探测报文段只有一个字节数据，它有一个序号，但是它的序号永远不需要确认。探测报文段提醒对端，确认已丢失，必须重传。
坚持计时器的值设置为重传时间的数值。若没有收到从接收端来的响应，需要发送一个探测报文，并将坚持计时器的值加倍和复位，直到这个值增大到门限值(通常60秒)为止。在这以后，发送端每隔60秒发送一个探测报文，直到窗口重新打开。

保活计时器
保活计时器用来防止两个TCP之间的连续出现长时间的空闲。

假定客户已主动与服务器建立了TCP链接。然后这个客户端出现故障。在这种情况下，这个链接就会永远的处于打开状态。而服务器维护一个链接，也是要耗费一定的资源的，所以必须采取措施，使服务器不能白白等下去。
要解决这种问题，就要对服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位，保活时间通常设置为2小时。若服务器过了两小时还没有收到客户的信息，他就发送一个探测报文，以后每隔75秒就发一次，连续发送10个探测报文后客户端仍然没有响应，服务器就认为客户端出现了故障，接着就关闭这个链接。

时间等待计时器
当客户端进入TIME-WAIT状态的时候，链接还没有释放掉，必须等待2倍的MSL(最长报文段寿命)后，客户端才能关闭连接。在时间等待期间，链接还处于一种过渡状态。这就可以使重复的FIN报文段(若果有的话)可以到达目的站因而可将其丢弃。

保证传输可靠

理想的传输条件有以下两个特点：

传输信道不产生差错。
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。这样一来，本来是不可靠的传输信道就能够实现可靠传输了。

序号与确认号

有一个问题：这条连接突然断开重连后，TCP 怎么样识别之前旧链接重发的包？——这就需要独一无二的 ISN（初始序列号）机制。

超时重传

超时重传：可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。

要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器

确认丢失与确认迟到：

超时重传

停止等待协议 - 简单的保证传输的可靠性- ARQ协议

停止等待协议：“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。(信道利用率低)

连续ARQ协议

连续ARQ协议：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。

连续ARQ协议

滑动窗口

发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用

滑动窗口

从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1，P2和P3。指针都指向字节的序号。这三个指针指向的几个部分的意义如下：小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分。P3 - P1 = A的发送窗口（又称为通知窗口）P2 - P1 = 已发送但尚未收到确认的字节数P3 - P2 = 允许发送但尚未发送的字节数（又称为可用窗口或有效窗口）

发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。下图表示了发送方维持的发送缓存和发送窗口，以及接收方维持的接收缓存和接收窗口。

发送窗口-接受窗口

总结：

发送缓存用来暂时存放：

发送应用程序传送给发送方TCP准备发送的数据
TCP已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：

按序到达的、但尚未被接收应用程序读取的数据
未按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。

超时重传的选择

TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间 $RTT_S$ （这又称为平滑的往返时间，S表示Smoothed。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时，RTTS值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次 $RTT_S$

超时重传

RFC2988推荐的α值为1/8，即0.125。用这种方法得出的加权平均往返时间RTTS就比测量出的RTT值更加平滑

超时计时器设置的超时重传时间 RTO (RetransmissionTime-Out)应略大于上面得出的加权平均往返时间 $RTT_S$ 。RFC 2988建议使用下式计算RTO：
$RTO = RTT_{S} + 4 \times RTT_{D}$
而 $RTT_D$ 是RTT的偏差的加权平均值，它与 $RTT_S$ 和新的RTT样本之差有关。当第一次测量时，RTTD值取为测量到的RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的RTTD：

公式

这里 β 是个小于1的系数，它的推荐值是1/4，即0.25。

接受方有一个判断接受的报文时之前发送的还是之后重传的报文的问题，这里接受方如何判断给哪一个报文发送确认？

判断超时重传

选择确认SACK

这就是若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

流量控制

所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收

滑动窗口流量控制：

可变窗口流量控制

现在我们考虑一种情况。、B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。这个时候就需要坚持计时器来保证了。

控制TCP发送报文段的时机

有三种发送报文段的方法：

第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。
第二种机制是由发送方的应用进程指明要求发送报文段，即TCP支持的推送(push)操作
第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。

在TCP的实现中广泛使用Nagle算法。算法如下：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，就可以有效地提高网络的吞吐量。

另一个问题叫做糊涂窗口综合症。要解决这个问题，可以让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

拥塞控制

流量控制与拥塞控制的区别：

拥塞控制与流量控制的关系密切，它们之间也存在着一些差别。所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

相反，流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制

什么是网络拥塞？

在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞(congestion)。

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。但TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想在当前网络中的某处很可能发生了拥塞，但这时却无法知道拥塞到底发生在网络的何处，也无法知道发生拥塞的具体原因（是访问某个服务器的通信量过大？还是在某个地区出现了自然灾害）。

拥塞控制所起的作用如下：

拥塞控制作用

图中随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。也就是说，在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。更值得注意的是，当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作。这就是所谓的死锁(deadlock)。

由于计算机网络是一个很复杂的系统，因此可以从控制理论的角度来看拥塞控制这个问题。这样，从大的方面看，可以分为开环控制和闭环控制两种方法。开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦整个系统运行起来，就不再中途进行改正了。

闭环控制是基于反馈环路的概念。属于闭环控制的有以下几种措施：

监测网络系统以便检测到拥塞在何时、何处发生。
把拥塞发生的信息传送到可采取行动的地方。
调整网络系统的运行以解决出现的问题。

几种方法

1999年公布的因特网建议标准RFC 2581定义了进行拥塞控制的四种算法，即慢开始(slow-start)、拥塞避免(congestion avoidance)、快重传(fast retransmit)和快恢复(fast recovery)。

慢开始和拥塞避免

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。

送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

发送方又是如何知道网络发生了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，就可以猜想网络可能出现了拥塞。现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于1 %）。

慢开始算法的思路是这样的。当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。

经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS的数值[插图]。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。

慢开始拥塞窗口变化：
慢开始
图解：
拥塞避免
拥塞避免算法就是指拥塞窗口按线性规律增长。

在TCP拥塞控制的文献中经常可看见“乘法减小”(Multiplicative Decrease)和“加法增大”(Additive Increase)这样的提法。“乘法减小”是指不论在慢开始阶段还是拥塞避免阶段，只要出现超时（即很可能出现了网络拥塞），就把慢开始门限值ssthresh减半，即设置为当前的拥塞窗口的一半（与此同时，执行慢开始算法）。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。而“加法增大”是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。上面两种算法合起来常称为AIMD算法（加法增大乘法减小）。对这种算法进行适当修改后，又出现了其他一些改进的算法。但使用最广泛的还是AIMD算法。

快重传和快恢复

快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待为M3设置的重传计时器到期。由于发送方能尽早重传未被确认的报文段，因此采用快重传后可以使整个网络的吞吐量提高约20%。

示意图：
快重传
快重传配合使用的还有快恢复算法，其过程有以下两个要点：
- 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。
- 由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连有好几个报文段连续到达接收方，也就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
示意图：
快恢复