计算机网络--传输层

传输层

传输层位于应用层和网络层之间，是分层的网络体系结构中重要的部分

该层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。

在这里我们将讨论两个大的问题：

• 将网络层在不同端系统之间的通信服务扩充到运行在两个端系统上不同的应用层进程之间的通信服务（如何实现进城之间通信的可靠传输）
• 控制传输层实体的传输速度以避免网络拥塞或者从网络拥塞中恢复过来，这里需要考虑的有拥塞的后果和原因以及常见的拥塞控制手段

1 运输层服务概述

传输层协议为运行在不同端系统上的应用进程之间提供逻辑通信功能；

应用层进程使用传输层提供的逻辑通信功能而无需考虑实现通信的物理基础设施的细节；

传输层接收来自应用层的报文并通过添加传输层首部以生成传输层报文段。在生成过程中可能会对来自应用层的报文加以分割；然后在发送端系统中，运输层会将这些报文段交给网络层；网络层将其封装成网络层分组，也被称为数据报，然后向目的地发送。路由器不会检查封装在数据报中的传输层报文段的字段；在接收端，网络层从数据报中抽取传输层报文段，并将其交给传输层，传输层接收到报文段后，使该报文段中的数据被接收进程所使用。

网络应用可以使用多种传输层协议

因特网有两种传输层协议，即TCP和UDP，不同的传输层协议提供不同的运输层服务

1.1 传输层和网络层的关系

网络层提供主机之间的逻辑通信而传输层为运行在不同主机上的应用进程提供逻辑通信；

运输层协议只工作在端系统中

在端系统中，传输层协议将来自应用进程的报文移动到网络边缘即网络层，反过来也从网络层接收这些报文段；

传输层对报文段如何在网络核心传输并不做干涉；

运输层协议能提供的服务常常受制于底层网络层协议的服务类型，如果网络层协议无法为主机之间的通信提供时延和带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或者带宽保证.

然而即使底层网络协议不能在网络层提供响应的服务，运输层协议也能提供某些服务。例如，即使底层网络协议是不可靠的，运输协议也能为应用程序提供可抗的数据传输服务。

1.2 因特网传输概述

因特网为应用层提供了两种传输层协议：

• UDP（用户数据报协议）：它提供一种不可靠、无连接的服务；
• TCP，它提供可靠的，面向连接的服务；

运输层分组也被称为报文段；而在考虑整个网络传输过程时，我们称之为分组。

网络层协议：IP。IP为主机间提供逻辑通信，IP的服务模型为尽力而为交付服务（best-effort delivery service）

这意味着IP尽最大的努力在主机间交付报文段，但是不做任何保证。它不保证报文段的交付、不保证报文段按序交付、不保证报文段中数据的完整性；即IP提供一种不可靠的服务；每台主机都需要有一个网络层地址，即IP地址。

UDP和TCP将IP提供的主机间交付服务扩展到不同端系统上两个进程之间的服务。这也被称为传输层的多路分解和多路复用；

UDP和TCP通过在传输层首部添加差错检查字段来提供完整性检查。

• 进程到进程之间的数据交付和差错检查是最低限度的两种传输层服务，也是UDP可以提供的仅有的两种服务。UDP和IP一样，也是不可靠服务；

• TCP提供额外的服务

  1. 首先它是一种可靠数据服务，这意味着TCP协议保证数据的按序、完整地从发送端应用进程发送到接收端应用进程；TCP通过序号、确认、定时器以及流量控制来将IP的不可靠数据传输转换为可靠数据传输；
  2. 其次，TCP提供拥塞控制，拥塞控制与其说是一种提供给应用程序的服务，不如说是一种提供给整个网络的服务，因为整个网络都将因为拥塞控制而受益；不太严格地说，拥塞控制力求为每一个经过一条拥塞网络的连接提供平等的共享网络链路带宽，从而避免一条TCP连接用过多的流量来淹没通信主机之间的链路和设备；拥塞控制是通过调节发送进网络的的流量速率来做得到；UDP不提供拥塞控制，使用UDP传输的应用程序可以根据需要以任意的速率发送数据。

2 多路复用和多路分解

实际上，传输层和应用程序进程之间通过**Socket（套接字）**关联。

这样通过Socket就可以区别同一主机上的不同应用进程，从而传输层提供服务变为可能；

• 传输层从同一台主机上的不同Socket接收数据的过程称为多路复用；
• 传输层向同一台主机上的不同Socket传输数据的过程称为多路分解；

为了实现多路复用和多路分解，我们需要标志套接字，并将相关信息添加到报文段中。

每个套接字都有一个唯一的ID，被称为端口号

• 无连接的多路复用与多路分解
  在创建Socket的时候，是由传输层为之分配端口号；

  一个UDP套接字是由一个目的IP地址和目的端口号即二元组来标志的；

  如果两个UDP报文段有不同的源IP地址或者源端口号，但是有相同的目的IP和目的端口号的话，它们将通过同一个Socket到达同一个应用程序

• 面向连接的多路复用与多路连接
  TCP协议中的Socket是通过一个四元组来标记的：（源IP地址，源端口号，目的IP地址，目的端口号）；

  两个具有不同源IP地址或者源端口号，但有相同的目的IP地址和目的端口号的TCP报文段将通过两个不同的Socket进入同一应用进程；

  这也表示，一个应用进程可以关联多个Socket，而一个Socket将只关联一个应用进程；

  常常，这样的对应关系是通过线程来实现的：一个进程有多个线程，而每个线程关联了一个Socket；

实际上，传输层就是根据这些信息来实现多路分解的；而这些信息是在多路复用的时候被放置在报文段中的

3 无连接运输：UDP

前面提到过，差错检查和进程到进程的数据交付是传输层协议必须提供的功能

事实上，UDP仅能完成这些。

它几乎没有对IP增强别的东西；因为在发送报文段之前，发送方和接收方的传输层实体之间没有握手，所以UDP也被称为无连接的；

既然TCP提供了可靠数据传输，并且提供了拥塞控制，为什么人们还需UDP呢？

事实上，有些应用很适合UDP（因为没有连接过程，不会受拥塞控制的调节）；

UDP有以下好处：

• 旦应用程序将数据交给UDP，UDP就会打包将其发送给网络层，不会受到传输层的调节，这在一些实时应用中比较实用；当然，应用程序还可以通过UDP+自主开发一些功能的模式来扩展UDP。
• TCP的主要原因是对TCP的可靠性的依赖超过对速度的要求；
• 无需维护连接状态：TCP为了实现可靠数据传输和拥塞控制需要在端系统中维护一些参数，这些参数包括：接收和发送的缓存、拥塞控制参数、确认号和序号；这些参数信息都是必须的；而UDP因为不建立连接，所以自然也就不需要维护这些状态，这就减少了时空开销；
• 分组首部更小：TCP有20字节的首部开销，而UDP只有8字节；

需要注意的是，使用UDP仍然可以实现可靠数据传输，只不过这一部分功能需要在应用程序中自主开发；

将可靠性直接构建于应用程序中，将使其既可以可靠地传输数据又可以避免受制于TCP的拥塞控制（传输速率的控制）

3.1 UDP报文结构

UDP首部只有4个字段，每个字段占用两个字节，分别是：源端口号、目的端口号、长度和校验和；

• 长度表示包含首部在内的UDP报文段长度，以字节为单位；

• 校验和字段用来计算报文段在传输的过程中是否出现了差错；

  一种常见的校验和的计算方法是：发送方将前三个字段做按位加运算，然后将其取反作为校验和；然后接收方对所有四个字段（每个字段16位）进行求和，如果没有出现差错，则最后的结果全是1，否则就表明出现了错误；出现错误的原因可能有：传输链路上数据受到干扰、数据存储在中间路由器的时候，出现了错误

端到端原则：“因为某一功能必须在端到端实现，与在较高层次提供这些功能的代价相比，在较低层次上设置的功能可能是冗余的，或者根本是没有用的”

UDP作为传输层协议，提供的差错检测功能很有可能和底层协议提供的相似功能产生冗余；但是，这是必须的，因为由于不能保证源和目的地之间所有链路都提供差错检测功能，即便数据在链路上正确传输，也无法保证其在中间路由器的内存中不发生错误；所以要实现端到端的差错检测，就必须在传输层协议中实现该功能；

4 可靠数据传输原理

可靠数据传输为上层实体提供的服务抽象是：数据可以通过一套可靠的信道进行传输，借助于可靠信道，传输数据就不会受到损坏或者丢失；并且所有数据都可以按照其发送顺序进行交付。

4.1 构造可靠信道的可靠数据传输

一个可靠数据传输协议，将要面对以下问题：分组丢失、分组损坏到达、分组乱序到达

总结可靠传输需要的技术：检验和、序号、定时器、肯定和否定确认分组。

1. 经完全可靠信道的可靠数据传输：rdt 1.0

​ 底层信号完全可靠，然而这在实际中不能实现

2. 经具有比特差错信道的可靠数据传输：rdt 2.0

​ 假设所有发送的分组都可以按其发送顺序被接收。

​ 基于重传机制的可靠数据传输协议称为自动重传请求协议（ARQ）。增加了ACK和NCK

​ ARQ协议中还需要另外三种协议功能来处理存在比特差错的情况：差错检测，接收方反馈，重传。

​ rdt2.0的发送端每发送一个分组需要等待接收端的确认信号，这种协议被称为停等协议。

3. rdt 2.1

​ rdt 2.0 中有一个致命的缺陷，就是没有考虑到 ACK 和 NAK 分组受损的可能性。

​ 考虑ACK和NAK受损的个两可能性：

• 增加足够的校验和比特
• 当接受到模糊不清的ACK和NAK分组时，只需要重传当前数据分组。这引入了冗余分组

​

​ 冗余分组的根本困难在于接收方不知道它上次所发送的ACK和NAK是否被发送方正确接收到。因此它无法事先知道接收到的分组是新的 还是一次重传。

​ 解决这个新问题的一个简单的方法就是在数据分组中添加一个字段，让发送方对其数据分组编号，即将发送数据分组的 序号 放在该字 段。于是，接收方只需要检查序号即可确定收到的分组是否一次重传。对于停等协议这种简单的情况，1 比特的序号就足够了。

4. rdt 2.2

​ 如果不发送NAK，而是对上次正确接收的分组发送一个ACK，我们也能实现同样的效果。

​ 发送方接收到对一个分组的两个ACK（冗余ACK）后，就知道接收方没有正确接收到跟在确认两次的分组后面的分组。

​ rdt 2.2 是在有比特差错信道上实现的一个无NAK的可靠数据传输协议。

​ rdt 2.1和rdt 2.2的区别在于，接收方此时必须包括由一个ACK报文所确认的分组序号

5. 经具有比特差错的丢包信道的可靠数据传输：rdt3.0

​ 在 rdt 3.0 中，丢包的问题让发送方解决。不管是发送的分组丢失，还是接收方返回的确认分组丢失，只要在经过一定的时延后，让 发送方重发该分组即可。

​ 由此产生的 冗余数据分组 则由接收方通过序号处理。为了实现基于时间的重传机制，需要一个倒计时定时器

​ 因为分组序号在 0 和 1 之间交替，因此 rdt 3.0 有时被称为 比特交替协议。

4.2 流水线可靠数据传输协议

rdt 3.0的核心问题在于他是一个停等协议

rdt 3.0 是一个功能正确的协议，但是由于它是一个停等协议，大部分的时间都浪费在等待确认上面，所以性能不好。

解决这种特殊性能问题的一个简单的方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。这种技术被称为流水线

要使用流水线技术，则须：

• 增加序号范围。因为要传送多个分组，而每个传输中的分组必须有一个单独的序号
• 协议的发送方和接收方两端必须能缓存多个分组。发送方至少得能缓存那些已发送但未确认的分组，而接收方或许也需要缓存那些已经正确接收的分组。
• 所需序号的范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。

流水线的差错恢复有两种基本方法：

• 回退 N 步
• 选择重传

4.3 回退N步(GBN)

在回退N步中，发送方维护一个N——窗口大小和一个base——发送方期待收到的最小待确认分组序号，同样也是窗口的起点，还有一个next Sequence变量，表示上层需要发送分组时，可以使用的序号。

这样全部序号就被划分为:

• 0-base-1，这一部分的分组是已发送且收到接收方确认的分组，
• base~next Sequence-1这一部分的分组是已发送但是尚未收到确认的，其中base是尚未收到确认的最小序号；
• next-1~base+N-1表示当前发送方可以使用的序号，表示一种发送能力；
• 当发送方收到确认号为base的确认分组后就会向前移动窗口，所以回退N步也被称为滑动窗口协议

这是发送方需要维护的数据，同时发送方需要响应的事件有：上层调用、收到ACK、超时事件；

• 上层调用：检查next Sequence是否在窗口之内，如果在，这说明发送方还有发送能力，发送之；
• 收到ACK：回退N步策略对序号为n的分组采取累积确认的方式，即当收到序号为n的ACK时，表明序号小于等于n的分组全部到位；发送方收到的ACK毕竟来自接收方，收到ACK的情况还得看接收方如何发送
• 超时事件：如果发生超时事件，那么发送方会重发所有已发送但是未确认的分组，即分组号在base和next sequence-1之间的所有分组；这也是为什么叫“回退N步”，如果收到一个ACK，则定时器会重行启动；如果没有待确认的分组，定时器将被终止；

在接收方，如果到达分组的序号为n且该分组是按序到达，那么发送ACK，这就导致发送方移动窗口；如果不是按序到达，那么接收方丢弃所有失序分组；丢弃一个正确接收的失序分组可能会导致更多的重传

4.4 选择重传（SR）

回退N步协议存在一个问题就是当窗口和带宽的时延都较大时，单个分组的差错可能会引起GBN重传大量的分组，造成资源浪费；

选择重传就是让发送方仅重传那些丢失和受损的分组而避免不必要的重传

SR 发送方的事件和动作：

• 从上层接收数据： 检查下一个可用于该分组的序号，若在发送方的窗口内，则将数据打包发送。
• 超时： 定时器再次用来防止丢失分组。但是现在每个分组必须得有单独的定时器。
• 收到 ACK：倘若该分组序号在窗口内，则 SR 发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且该序号落在窗口内的未发送分组，则发送这些分组。

SR 接收方的事件于动作：

• 序号在 [rcv_base, rcv_base + N -1] 内的分组被正确接收：在此情况下，收到的分组落在接收方的窗口内，一个选择 ACK 被回送给发送方。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收窗口的基序号，则该分组及以前缓存的序号连续的分组交付给上层。
• 序号在 [rcv_base - N, rcv_base - 1] 内的分组被正确接收： 产生一个 ACK，即使该分组是接收方以前已确认过的分组。因为视图不一致
• 其他情况：忽略该分组。

接收方将确认一个正确接收的分组而不管其是否按序；失序的分组被缓存，直到形成连续数据后将其提交给上层；值得注意的是，如果接收方收到了已经确认的分组，则说明确认ACK丢失，或者时延太长，接收方和发送方沟通不及时；这也表明了关于那些分组到位了，那些分组还没到位，接收方和发送方有着不一样的视图。

另外还需要注意的是，序号的重用问题，如果在分组中序号字段的位数为k，那么最大的序号为2^k-1，所以有可能不同分组同时占用一个序号，为了避免这种情况，需要做的是控制分组的生命周期。窗口长度必须小于或等于序号空间大小的一半。

5 面向连接的TCP

5.1 TCP连接

TCP协议之所以被称为是面向连接的协议，是因为在一个应用进程可以向另一个应用进程发送数据前，这两个进程将首先“握手”，即它们必须交换一些预报文段，已建立对关于数据传输的参数的共识；作为TCP连接建立的一部分，通信双方都将初始化与TCP连接的许多相关变量

TCP的连接被端系统所维护而中间路由器完全忽略了该协议，中间路由器看到的只是数据，也就是说，TCP只运行在端系统之上；

所以，TCP连接更像一种状态而不是物理的、实际的连接

TCP提供全双工服务，并且是点对点的，数据从A到B的同时，也能从B到A；TCP协议无法提供“多播”服务，一条TCP连接只关联一个发送方和接收方（当然，发送方也是接收方）；

对于TCP建立过程中的“握手”阶段，需要明白的是，手一共握了三次，前两次报文段不承载“有效负载”，第三次握手的时候，报文段是可以装载“有效负载”的；

这个过程是这样的：通信的发起方首先发送一个特殊的TCP报文段给接收方，这是第一次握手；接收方收到该报文段后，对该报文段进行响应，此为第二次握手；发送方接收到响应报文段后，发送第三个报文段，其中包含了有效负载；因为TCP建立的过程，一共发生了三次握手，所以该过程也被称为“三次握手”

当TCP连接建立后，两个应用进程就可以发送数据了。应用程序将要发送的数据通过Socket传递给TCP，TCP将数据引导到该连接的发送缓存，发送缓存大小是在三次握手的过程中确定的；之后TCP将时不时从该缓存中拿出数据进行发送，一个有趣的事情是，TCP规范中没有规定TCP应该在何时发送缓存里的数据，描述为“TCP应该在它方便的时候以报文段的形式发送数据”；

TCP每次可以从缓存中发送的最大数据长度称为MSS(Maximum Segment Size)。一般来说，MSS+TCP/IP首部的长度要小于等于链路的MTU（即链路层最大帧长度Maximum Transport Unit）

而以太网和PPP的MTU都等于1500字节，TCP/IP的首部通常为40字节，所以MSS一般来说为1460字节。

注意：MSS指的是报文段中应用层数据最大长度，而不是包括TCP首部的报文段长度。

TCP为每块客户数据加上TCP首部后就形成了一个个TCP报文段；这些TCP报文段被交给网络层，然后被发送到网络中；当TCP报文段到达接收端时，便进入了接收端的缓存，等待被应用程序读取。

5.2 TCP报文段结构

TCP报文段结构，从整体上来说由首部+数据字段组成；

其中数据字段来自应用层，其长度不能大于MSS；

首部的常规长度为20字节，但是值得注意的是，TCP首部是可变长的；

TCP首部是以32比特为单位组织的

• 源端口号和目的端口号
  这两个数据用于TCP的多路复用和多路分解；分别为16位；

• 序号
  该数据被用于实现可靠数据传输之按序到达，在一个TCP连接中，算是一个报文段的id，同时该id还指示了其所承载的数据的位置信息；占32位；

• 确认号
  该数据表示接收方已经正确接收的报文段的序号，在流水线的差错恢复方案里，不同的恢复策略有不同的意义：回退N步里，当发送方接收到对K的确认号时，表示所有序号小于K的报文段均已到达；而在选择重传里，则仅表示序号为K的报文段被正确接收；

• 首部长度
  TCP的首部是可变长的，所以该字段表示报文段的首部长度，也揭示了应用数据的开始位置；该字段以32比特为单位，占4比特

• 选项字段
  该字段用于在发送方和接收方之间协商MSS的大小，在高速网络环境下，也可用于调节窗口大小；

• 标记字段
  ACK位表示确认号字段的里的值是否有效，如果ACK被置位，那么该报文段就对确认号所指示的报文段进行了确认；

• RST、SYN和FIN位用于TCP的连接和拆除；

• PSH被置位时，指示接收方应该立即将数据交给上层；

• URG被置位时表示报文段里存在着发送端的上层实体置为紧急的数据；紧急数据的最后一个字节由16位紧急指针指出。当紧急数据存在并且给出了指向紧急数据尾指针时，TCP必须通知接收端的上层实体；

然而，实际上，PSH、URG和紧急数据指针在实践中并没有被使用；标记字段一共6比特；

TCP报文段中两个重要的字段是确认号和序号；

这两个字段是TCP实现可靠数据传输的重要部分；

TCP将数据看作是一个无结构、有序的字节流；

值得注意的是，TCP的序号是基于传输的字节流之上，而不是报文段的序列之上；也就是说，来自应用层的数据被TCP包装在多个报文段中，其中第2个报文段的序列号不是2，而是1001，如果MSS为1000。关于确认号，如果采取回退N步策略，那么TCP采用一种累计确认的方法，前面已经提到过，这里就不赘述；一条TCP连接可以采取任意数字作为初始序号，这样可以减少将那些残存在网络中的报文段误认为是新建连接的报文段（新旧连接恰巧采用了相同端口）

总体来说，一个报文段的序号就是该报文段数据字段首字节的序号；确认号就是接受主机正在等待接收的数据的下一个字节序号；值得注意的是，服务端对接收端发来的报文段的确认被装载到一个从服务端发往到接收端的报文段中，这种确认被称为“捎带”

5.3 往返时间的估计与超时

如何设置超时时间？

如何设置超时时间，取决于网络的状态，所以需要做的是估计网络的状态。

TCP使用一种Sample RTT的方法来估计RTT。

Sample RTT就是从某报文段发出到收到对该报文段的确认之间的时间量。大多数TCP的实现是在某个时刻做一个Sample RTT测试。TCP并不为已经重发的报文段做Sample RTT测试，它只为传输一次的报文段测量Sample RTT。

TCP一般来说通过Estimated RTT=(1-a)Estimated RTT+a*Sample RTT来计算因路由器的拥塞和端系统负载变化所导致变化的RTT。

a一般取1/8；因为Estimated RTT表示最近的网络状况，所以其理应得到较大的权值；这种方法也被称为指数加权移动平均

除了估计RTT外，计算RTT的变化也是ok的，DevRTT =(1-b)DevRTT+b*|Sample RTT-Estimated RTT| ；

其中b的推荐值为0.25；当Sample RTT变化较大的时候，DevRTT的值较大，当Sample RTT变化较小的时候，DevRTT就较小；

TCP是如何考虑超时时间的呢？

该时间因略大于测量的RTT，不易过小——容易引起不必要的重传，也不易过大——网络对于报文段丢失情况的反应就会变慢；

最后TCP采用了如下计算方式：Timeout Interval=Estimated RTT+4*Dev RTT；

当出现超时后，TimeOutInteval值将加倍。不管怎么样，一旦报文段收到并更新Estimated RTT后，TimeInteval就又用上值计算了

5.4 可靠数据传输

IP协议提供的是尽力而为的服务：不保证不丢失、不保证按序到达、不保证没有损坏，TCP协议在IP协议之上，提供可靠数据传输，从而保证一个进程从其相关联的缓存中读取的数据和另一端进程发送的数据是一致的；

TCP使用超时重传和冗余确认技术来处理超时、丢失等情况；使用确认、序号等技术来保证按序到达；使用校验和来检验是否报文段在传输过程中是否发生了错误；

TCP 发送方有三个与发送和重传有关的事件：

• 从上层应用程序接收数据
• 定时器
• 收到 ACK

1. 超时时间加倍

在大多数TCP实现中，当发生超时事件时，超时时间并不是从Estimated RTT和Dev RTT推算出来而是直接将超时时间设置为原来的两倍；然而，每当定时器在另两个事件（收到ACK和接收到上层应用数据）发生时，新的超时时间将由上面提到的两个值计算出来；实际上，这是一种形式受限的拥塞控制

2. 快速重传

响应超时事件，然后重传尚未收到确认的报文段，但是，当超时时间过长的时候，会显著增加端到端的延迟；一种可行的方法是对冗余ACK的的检测；在理解冗余ACK之前，需要先看一下接收方为什么会发送冗余ACK。接收方接收到某个报文段时，会检查该报文段是否是按序到达，如果不是，那么接收端会发送对已经收到的最后一个连续报文段的确认，所以如果发送方收到冗余ACK，说明有多个报文段到达了接收端，但不是接收端所期望的——这意味着，很有可能发生了丢失。所以发送方可以在定时器过时之前快速重传所丢失的报文段

3. 是回退N步还是选择重传

首先，我们需要明白的是，TCP采用了累计确认的机制，也就说，如果接收方正确接收了某一失序到达的分组，那么接收方发送的ACK将是对最后接收的按序到达的分组的确认，而不是对刚刚接收的分组的确认；当然，许多TCP实现都会缓存失序的分组；那么问题来了，发生超时事件后，GBN将重传所有待确认的分组，而不是丢失的分组；而选择重传会好很多

对TCP提出的一种修改意见是所谓的选择确认——即接收方对失序到达的分组也会确认，当该机制和重传机制相结合使得TCP更像选择重传，于是TCP的差错恢复协议最好被分类为GBN和SR协议的混合体.

5.5 流量控制

流量控制是一个速度匹配服务：TCP连接的发送方和接收方都各自维护一个缓存，因此两者的数据交换应该在一个合理的速度范围内：不让对方发生数据溢出；

TCP为它的应用程序提供了这种服务：流量控制服务。虽然流量控制和拥塞控制所采取的动作非常相似，但是它们的目的很明显并不同。

在接下来的讨论中，我们将假设TCP是这样实现的，即TCP接收方丢弃失序到达的报文段

在TCP首部中有一个窗口大小字段，TCP连接的双方通过该字段来向对方表明自己的窗口大小，即缓存空间的大小；同样，在TCP连接的两端，各自维护着相关的变量：last Sent、last Acked；

在发送方，这两个变量之间的分组就是已经发送但是尚未确认的分组；

而在接收方，last Read表示应用进程下一次读取的数据，last Revd表示最后纳入缓存的报文段编号;

通过这些变量以及报文段首部中窗口大小字段，我们就可以对发送速度做一些控制：在发送方last Sent-last Acked应该小于等于接收方的窗口大小；在接收端A=last Received-last Read就是已经使用的空间大小，所以窗口大小=buffer-A；

对了，还有一个问题就是，如果接收方的窗口大小为0，那么发送端该如何处理呢？

一个需要注意的事实是，接收方在没有ACK或者数据要向发送端发送的时候，是不会通知发送方其窗口大小已经改变，即如果应用程序读取了缓存中的数据，发送方是不会知道的，除非它向接收方发送了数据，而发送方对其进行了确认；实际上，发送方也是这么做的！当接收到窗口大小为0的报文段后，发送方会向接收方间隔发送只有一个字节的数据。

6 TCP连接管理

6.1 TCP三次握手

起初，服务器和客户端都为CLOSED状态。在通信开始前，双方都得创建各自的传输控制块（TCB）。
服务器创建完TCB后遍进入LISTEN状态，此时准备接收客户端发来的连接请求。

• 第一次握手

客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。

PS1：SYN=1，ACK=0表示该报文段为连接请求报文。
PS2：x为本次TCP通信的字节流的初始序号。
TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。

• 第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。
该应答发送完成后便进入SYN-RCVD状态。

PS1：SYN=1，ACK=1表示该报文段为连接同意的应答报文。
PS2：seq=y表示服务端作为发送者时，发送字节流的初始序号。
PS3：ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。

• 第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。
该报文段的头部为：ACK=1，seq=x+1，ack=y+1。
客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成！
为什么连接建立需要三次握手，而不是两次握手？

防止失效的连接请求报文段被服务端接收，从而产生错误。

PS：失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。

若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。

6.2 四次挥手

2TCP连接的释放一共需要四步，因此称为『四次挥手』：

我们知道，TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。

• 第一次挥手

若A认为数据发送完成，则它需要向B发送连接释放请求。该请求只有报文头，头中携带的主要参数为：
FIN=1，seq=u。此时，A将进入FIN-WAIT-1状态。

PS1：FIN=1表示该报文段是一个连接释放请求。
PS2：seq=u，u-1是A向B发送的最后一个字节的序号。

• 第二次挥手

B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含：
ACK=1，seq=v，ack=u+1。

PS1：ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。
PS2：seq=v，v-1是B向A发送的最后一个字节的序号。
PS3：ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节。
A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。

第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。但B到A方向的连接仍然存在，B可以继续向A发送数据。

• 第三次挥手

当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。B便进入LAST-ACK状态。

• 第四次挥手

A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入CLOSED状态，撤销TCB。当B收到确认应答后，也便进入CLOSED状态，撤销TCB。
为什么A要先进入TIME-WAIT状态，等待时间后才进入CLOSED状态？

为了保证B能收到A的确认应答。
若A发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。

7 拥塞控制原理

7.1 拥塞原因与代价

计算机网络拥塞的原因是因为网络中的分组太多，而链路带宽和路由器缓存容量都是有限的；

• 当分组的到达速率接近链路容量时，分组将经历巨大的排队时延；
• 发送方必须执行重传已补偿因为缓存溢出而丢弃的分组
• 发送方遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转必要的分组副本。
• 当一个分组沿着一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了；

7.2 拥塞控制方法

1. 拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；

2. 流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收。

   总体来说，我们可以更具网络层是否为传输层拥塞控制提供了显式帮助来区分拥塞控制方法：端到端拥塞控制和网络辅助拥塞控制；

   在端到端拥塞控制方法中，网络层并没有向传输层拥塞控制提供显式支持，即便网络中存在拥塞，端系统也必须通过对网络行为的观察（如分组丢失与时延）来判断；TCP必须通过端到端的方法解决拥塞控制，因为IP层不会像端系统提供有关网络拥塞的反馈信息。TCP报文段的丢失（超时或者收到3次冗余确认而得知）被认为是网络拥塞的一个迹象，TCP将相应地减小窗口长度；

   在网络辅助的拥塞控制方法里，网络层会向发送方提供关于网络中拥塞状态的显式反馈消息；比如使用一个比特位来指示网络是否拥塞；拥塞信息从网络反馈到发送方一般有两种方式，其中直接反馈信息可以由网络路由器发送给发送方，这种方式的通知通常采用一种拥塞分组的形式；第二种形式的通知是路由器标记或者更新从发送方到接收方的分组中的某个字段来指示拥塞的产生，然后由接收方向发送方通知该网络发生了拥塞。