TCP相关知识点

TCP

多路分解和多路复用

将运输层报文段中的数据交付到正确的套接字的工作成为多路分解。在源主机从不同的套接字中收集数据块，并为每个数据块封装上首部信息（这将在以后用于分解）从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。

可靠数据传输原理

停-等协议

回退N步协议

基序号base定义为最早的未确认分组的序号，将下一个序号nextseq定义为最小的未使用序号（即下一个待发分组的序号），则可将序号范围分割成4段。在[0, base-1]段内的序号对应于已经发送并被确认的分组。[base, nextseq-1]段内对应已经发送但未被确认的分组。[nextseq, base+N-1]段内的序号能用于那些要被立即发送的分组，如果有数据来自上层的话。最后，大于或等于base+N的序号是不能使用的，直到当前流水线中未被确认的分组（特别是序号为base的分组）已得到确认为止。

那些已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口。随着协议的运行，该窗口在序号空间向前滑动。因此，N常被称为窗口长度（Window size），GBN协议也常被称为滑动窗口协议。这个机制是用于流量控制的关键之一。

协议名字“回退N协议”来源于出现丢失和时延过长是发送方的行为。如果出现超时，发送方重传所有已经发送但还未被确认过的分组。

接收方需要维护的唯一信息就是下一个按序接收的分组序号。如果一个序号为n的分组被正确接收到，并且按序（即上次交付给上层数据是序号为n-1的分组），则接收方为分组n发送一个ACK，并将该分组中的数据部分交付给上层。在所有其它情况下，接收方丢弃该分组，并为最近按序接收的分组重新发送ACK，以提醒发送方下一个需要发送的分组。

选择重传

GNB协议潜在地允许发送方用多个分组“填充流水线”，因此避免了停等协议中所提到的信道利用率问题。然而，GBN本身也有一些情况存在着性能问题。单个分组的差错就能够引起GBN重传大量分组，而许多分组根本没有必要重传。

选择重传（SR）协议通过让发送方仅重传那些它怀疑在接收方出错（即丢失或受损）的分组而避免了不必要的重传。

对于发送方来说，如果收到ACK，若该分组序号在窗口内，则SR发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。发送方通过定时器来防止丢失分组，每个分组必须拥有其自己的逻辑定时器，因为超时发生后只能发送对应的一个分组。

对接收方来说，序号在[rev_base, rev_base+N-1]内的分组被正确接收。在此情况下，收到的分组落在接收方的窗口内，一个选择ACK被送回给发送方。如果该分组以前没有收到过，则缓存该分组，如果该分组的序号等于接收窗口的基序号，则该分组以及以前缓存的序号连续的分组交付给上层。序号在[rev_base-N, rev_base-1]内的分组被正确收到。在此情况下，必须产生一个ACK，即使该分组是接收方以前已确认过的分组，因为之前的ACK可以丢失了。其它情况下，丢弃该分组即可。

TCP连接管理

三次握手

第一步：客户端TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含应用层数据。但是在报文段的首部中的第一个标志位（即SYN比特）被置为1.因此，这个特殊报文段被称为SYN报文段。另外，客户会随即选择一个初始序号client_ins，并将此编号放置与起始的TCP SYN报文段的序号字段中。该报文段会被封装在一个IP数据报中，并发送给服务器。

第二步：一旦包含TCP SYN报文段的IP数据报到达服务器主机，服务器会从该数据报中提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向该客户TCP发送允许连接的报文段。这个允许的报文段也不包含应用层数据。但是，该TCP报文段首部的确认号字节被置为client_ins+1，并且选择自己的初始序号server_ins，并将其放置到TCP报文段首部的序号字段中。这个允许连接的报文段有时被称为SYNACK报文段。

第三步：在收到SYNACK报文段后，客户也要给该连接分配缓存和变量。客户端主机想服务器发送另外一个报文段；这最后一个报文段对服务器的允许连接的报文段进行确认。因为连接已经确认了，所以该SYN的比特位为0。该三次握手的第三个阶段可以在报文段负载中携带客户到服务器的数据。

为什么是三次握手，而不是两次？

第一次握手：客户端什么也不能确认；服务器确认对方发送正常，自己接收正常。
第二次握手：客户端确认自己发送正常，接收正常，对方发送正常，接收正常；服务器确认对方发送正常，自己接收正常。
第三次握手：客户端确认自己发送正常，接收正常，对方发送正常，接收正常；服务器确认对方发送正常，接收正常；自己发送正常，接收正常。

四次挥手

参与一条TCP连接的两个进程中的任何一个都能终止该连接。当连接结束后，主机中的“资源”将被释放。假设某客户打算关闭连接。客户应用进程发出一个关闭连接命令。这会引起客户TCP向服务器进程发送一个特殊的TCP报文段。这个特殊的报文段让其首部中的一个标志位即FIN比特位被设置为1。当服务器接收到该报文段后，就向发送方回送一个确认报文段，其FIN比特位被置为1。最后，该客户对这个服务器的终止报文进行确认。此时，在两台主机上用于该连接的所有资源都被释放了。

为什么需要四次挥手？

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据要发送时，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

在socket编程中，当recv返回0时，指示对端已经关闭。

TCP状态序列

客户端：

服务器：

快速重传

超时触发重传存在的问题之一是超时周期可能相对较长。当一个报文段丢失时，这种超时周期迫使发送方延迟重传丢失的分组，因而增加了端到端时延。幸运的是，发送方通常可在超时事件发生之前通过注意所谓冗余ACK来较好地检测到丢包的情况。冗余ACK就是再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。

当TCP接收方收到一个具有这样序号的报文段时，即其序号大于下一个所期望的、按序的报文段，它检测到了数据流中的一个间隔，这就是说有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。因为TCP不使用否定确认，所以接收方不能像发送方发回一个显式的否定确认。相反，它只是对已经接收到的最后一个按序字节数据进行重复确认（即产生一个冗余ACK）即可。

因为发送方经常一个接一个地发送大量的报文段，如果一个报文段丢失，就很可能引起许多一个接一个的冗余ACK。如果TCP发送方接收到对相同数据的3个冗余ACK，它把这当作一种指示，说明跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。

为什么发送方等待3个冗余的ACK，而不是仅等待一个？因为有可能由于时延的原因导致报文晚点到达接收方，所以等待3个冗余ACK之后才认为报文丢失是合理的。

流量控制

一条TCP连接每一侧主机都为该连接设置了接收缓存。当该TCP连接收到正确、按序的字节后，它就将数据放入接收缓存。相关联的应用进程会从该缓存中读取数据，但不必是数据刚一到达就立即读取。事实上接收方应用也许正忙于其他任务，甚至要过很长时间后才去读取该数据。如果某应用程序读取数据时相对缓慢，而发送方发送得太多、太快，发送的数据就会很容易地使该连接的接收缓存溢出。

TCP为它的应用程序提供了流量控制服务以消除发送方使接收方缓存溢出的可能性。流量控制因此是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。

TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制。通俗地说，接收窗口用于给发送方一个指示————该接收方还有多少可用的缓存空间，因为TCP是全双工的通信，在连接两端的发送方都各自维护一个接收窗口。

接收方：

• LastByteRead：接收方应用进程从缓存中读取的数据流的最后一个字节的编号
• LastByteRecv：从网络中到达的并且已放入缓存的数据流的最后一个字节的编号

由于TCP不允许已分配的缓存溢出，则下式成立：

LastByteRecv - LastByteRead <= RecvBuffer

接收窗口用rwnd表示，根据缓存可用空间的数量来表示：

rwnd = RecvBuffer - [LastByteRecv - LastByteRead]

接收方通过把rwnd值放入发给发送方的报文段接收窗口字段中，通知发送方在它的缓存空间中还有多少可用的空间。

发送方：

• LastByteSent：发送方最后一个发送的字节序号
• LastByteAcked：最后一个收到Ack的字节序号

注意到LastByteSent - LastByteAcked的值就是发送方发送到连接中但未被确认的数据量。通过将未确认的数据量控制在值rwnd以内，就可以保证发送方不会使接收方的接收缓存溢出：

LastByteSent - LastByteAcked <= rwnd

还要一个小问题。假设接收方的缓存已满，即rwnd为0。在将rwnd为0通告给发送方之后，发送方不再发送新数据给接收方，此时当接收方的缓存空间空了出来，又该如何通知发送方（因为接收方需要有数据或者有确认要发送时才能捎带告知发送方rwnd）？为了解决这个问题，TCP规范中要求：当接收方接收窗口为0时，发送方继续发送只有1个字节数据的报文段。

拥塞控制

丢包一般是当网络变得拥塞时由于路由器缓存溢出引起的。分组重传因此作为网络拥塞的征兆来对待。

TCP采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。如果一个TCP发送方感知从它到目的地之间的路径上没有什么拥塞，则TCP发送方增加其发送速率；如果发送方感知沿着该路径有拥塞，则发送方就会降低其发送速率。

拥塞窗口大小：cwnd

LastByteSent - LastByteAcked <= min{cwnd, rwnd}

慢启动

当一条TCP连接开始时，cwnd的值通常初始置为一个MSS的较小值，这就使得初始发送速率大约只有MSS/RTT。由于对TCP发送方而言，可用带宽可能比MSS/RTT大得多，TCP发送方希望迅速找到可用带宽的数量。因此，在慢启动状态，cwnd的值以1个MSS开始并且每当传输的报文段首次被确认就增加一个MSS。接下来发送两个报文段，这两个报文段被接收后，则发送方对每个确认都将拥塞窗口增加一个MSS，使得拥塞窗口变为4个MSS，并这样下去。这一过程每过一个RTT，发送速率就翻番。因此，TCP发送速率起始慢，但在慢启动阶段以指数增长。

当发生超时指示的丢包事件时，TCP发送方将cwnd设置为1并重新开始慢启动过程，并且将慢启动阈值ssthresh设置为之前cwnd/2。当cwnd达到ssthresh时，转入拥塞避免。

当检测到3个冗余ACK时，这时TCP执行一种快速重传，并进入快速恢复状态。

拥塞避免

一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的值的一般，即距离拥塞可能并不遥远！因此，TCP无法每过一个RTT再将cwnd的值翻倍，而是采用一种保守的策略，每个RTT只将cwnd的值增加一个MSS。

当发生超时指示的丢包事件时，TCP发送方将cwnd设置为1并重新开始慢启动过程，并且将慢启动阈值ssthresh设置为之前cwnd/2。

当检测到3个冗余ACK时，这时TCP执行一种快速重传，并进入快速恢复状态。

快速恢复

在快速恢复中，对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余的ACK，cwnd的值增加一个MSS。最终，当对丢失报文段的一个ACK达到时，TCP在降低cwnd后进入拥塞避免状态。如果出现超时事件，快速恢复在执行如同在慢启动和拥塞避免中相同的动作后，迁移到慢启动状态。

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

TCP发送方也可能因为IP网络的拥塞而被遏制；这种形式的发送方的控制被称为拥塞控制。尽管流量控制和拥塞控制采取的动作非常相似，但是它们显然是针对完全不同的原因而采取的措施。流量控制的目的是为了避免接收方缓冲区溢出，而拥塞控制是为了在网络拥塞时遏制发送方。