计算机网络 - 传输层

传输层

运输层位于应用层和网络层之间，是分层的网络体系结构中重要的部分，该层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。

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

3.1 概述和运输层服务

传输层协议为运行在不同端系统上的应用进程之间提供逻辑通信功能；应用层进程使用传输层提供的逻辑通信功能而无需考虑实现通信的物理基础设施的细节；

值得注意的是，传输层协议是在端系统中实现的而不是在路由器中实现的。传输层接收来自应用层的报文并通过添加传输层首部以生成传输层报文段。在生成过程中可能会对来自应用层的报文加以分割；

然后在发送端系统中，运输层会将这些报文段交给网络层；

网络层将其封装成网络层分组，也被称为数据报，然后向目的地发送**。路由器不会检查封装在数据报中的传输层报文段的字段**；

在接收端，网络层从数据报中抽取传输层报文段，并将其交给传输层，传输层接收到报文段后，使该报文段中的数据被接收进程所使用。

网络应用可以使用多种传输层协议**，因特网有两种传输层协议，即TCP和UDP**，不同的传输层协议提供不同的运输层服务

3.1.1 一些常用协议

应用 应用层协议 运输层协议
电子邮件 SMTP TCP
远程终端访问 Telnet TCP
Web HTTP TCP
文件传输 FTP TCP
远程文件服务器 NFS UDP
流式多媒体 通常专用 UDP或TCP
因特网电话 通常专用 UDP或TCP
网络管理 SNMP UDP
路由选择协议 RIP UDP
名字转换 DNS UDP

3.1.2 传输层和网络层的关系

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

运输层协议只工作在端系统中。在端系统中，传输层协议将来自应用进程的报文移动到网络边缘即网络层，反过来也从网络层接收这些报文段；传输层对报文段如何在网络核心传输并不做干涉；事实上中间路由器既不处理也不识别传输层加载应用层报文上的任何信息

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

然而即使底层网络协议不能在网络层提供响应的服务，运输层协议也能提供某些服务。

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

3.1.3 因特网传输概述

因特网为应用层提供了截然不同的两种传输层协议：UDP（用户数据报协议）它提供一种不可靠、无连接的服务；另一种是TCP，它提供可靠的，面向连接的服务；运输层分组也被称为报文段；

简单了解一下因特网的网络层，网络层协议有一个名字即IP，即网际协议。

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

UDP和TCP最基本的责任就是将IP提供的主机间交付服务扩展到不同端系统上两个个进程之间的服务。这也被称为传输层的多路分解和多路复用；UDP和TCP通过在传输层首部添加差错检查字段来提供完整性检查。进程到进程之间的数据交付和差错检查是最低限度的两种传输层服务，也是UDP可以提供的仅有的两种服务。UDP和IP一样，也是不可靠服务；

TCP提供额外的服务，首先它是一种可靠数据服务，这意味着TCP协议保证数据的按序、完整地从发送端应用进程发送到接收端应用进程；

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

3.2 多路复用和多路分解

有前面的介绍，我们可以知道，传输层将网络层提供的面向主机的逻辑通信扩充为面向不同应用进程的逻辑通信，并且这一过程称为多路复用和多路分解；值得注意的是，多路复用和多路分解是每个计算机网络都需要的

实际上，传输层和应用程序进程之间通过Socket（套接字）关联，这样通过Socket就可以区别同一主机上的不同应用进程，从而传输层提供服务变为可能；

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

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

实际上，每个套接字都有一个唯一的ID，被称为端口号；而在传输层接收到来自应用程序的分组并通过添加传输层首部而形成报文段的过程中，该端口号被写入；端口号大小在0-65535之间，其中0-1023属于周知端口号，它们为特定的Socket而拥有。

3.2.1 无连接的多路复用与多路分解

需要注意的是，在创建Socket的时候，是由传输层为之分配端口号；一个UDP套接字是由一个目的IP地址和目的端口号即二元组来标志的；如果两个UDP报文段有不同的源IP地址或者源端口号，但是有相同的目的IP和目的端口号的话，它们将通过同一个Socket到达同一个应用程序

3.2.2 面向连接的多路复用与多路连接

TCP协议中的Socket是通过一个四元组来标记的：源IP地址，源端口号，目的IP地址，目的端口号；

两个具有不同源IP地址或者源端口号，但有相同的目的IP地址和目的端口号的TCP报文段将通过两个不同的Socket进入同一应用进程；这也表示，一个应用进程可以关联多个Socket，而一个Socket将只关联一个应用进程；

常常，这样的对应关系是通过线程来实现的：一个进程有多个线程，而每个线程关联了一个Socket；这样做可以提高服务器性能

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

3.3 无连接运输：UDP

一个不提供不必要服务的传输层协议是什么样的呢？什么都不做？那是不行的，我们必须做一些什么。前面提到过，差错检查和进程到进程的数据交付是传输层协议必须提供的功能，事实上，UDP的确做到了这些，并且只做了这些。它几乎没有对IP增强别的东西；因为在发送报文段之前，发送方和接收方的传输层实体之间没有握手，所以UDP也被称为无连接的；

DNS是一个使用UDP的应用层协议例子；

UDP在接收到来自Socket的数据时，UDP为该报文添加首部字段（源和目的端口号，以及其他两个小字段），然后将报文段交给网络层，网络层通过IP协议尽力地将该报文段交付，至于结果，尽力就好；当DNS客户端等待不到对该查询的响应时（有可能网络层将其丢失了）则会向其他Name Server发送查询请求，要么就通知应用程序，做不到

既然TCP提供了可靠数据传输，并且提供了拥塞控制，为什么人们还需UDP呢？事实上，有些应用很适合UDP（因为没有连接过程，因为不会受拥塞控制的调节啊，更自由）

3.3.1 UDP有以下好处：

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

这些应用程序使用了TCP作为其传输层协议：电子邮件、远程终端访问、Web、文件传输；

这些应用通常使用UDP作为其传输层协议：远程文件服务器、网络管理（因为这里应用即便在网络处于拥塞的情况下仍要工作，所以UDP更为合适）、路由选择协议和名称转换（DNS）；

这些应用两个都有使用：流式多媒体、因特网电话等多媒体应用；这些应用对实时性的要求较高同时对可靠性的要求又不是很高，所以既可以使用UDP也可以使用TCP协议。

不过在UDP之上运行多媒体应用是有争议的，因为UDP没有拥塞控制协议，所以其对网络有很大的威胁性：大量的UDP流量将使网络过度拥塞而造成TCP连接几乎无法传输数据，并且因为网络拥塞，所以应用又有着较高的丢包率，而因为丢包率UDP很有可能继续发送数据，由此使得网络效率低下。也有研究人员提出一些新的机制，使得所有数据源，包括UDP源执行自适应的拥塞控制来解决这一问题；

需要注意的是，使用UDP仍然可以实现可靠数据传输，只不过这一部分功能需要在应用程序中自主开发；将可靠性直接构建于应用程序中，将使其既可以可靠地传输数据又可以避免受制于TCP的拥塞控制（传输速率的控制）

3.3.2 UDP报文结构

UDP首部只有4个字段，每个字段占用两个字节，分别是：源端口号、目的端口号、长度和校验和；其中，长度表示包含首部在内的UDP报文段长度，以字节为单位；

校验和字段用来计算报文段在传输的过程中是否出现了差错；一种常见的校验和的计算方法是：发送方将前三个字段做按位加运算，然后将其取反作为校验和；然后接收方对所有四个字段（每个字段16位）进行求和，如果没有出现差错，则最后的结果全是1，否则就表明出现了错误；

出现错误的原因可能有：传输链路上数据受到干扰、数据存储在中间路由器的时候，出现了错误

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

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

IP作为网络层协议，可以运行在任何第二层协议上，所以运输层提供差错检测也是必须的；

UDP可以检测差错，但是无法恢复差错，能做的除了将其丢弃外，便是将其交给应用程序然后给出警告

3.4 可靠数据传输原理

可靠数据传输的问题，不仅在传输层需要考虑，在链路层以及应用层都需要考虑这个问题，所以了解一些其基本原理是必要的，特别是在详细了解TCP中为实现可靠数据传输而采取的许多原理

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

实现这种抽象服务是可靠数据传输的责任，但是因为可靠数据传输的底层协议可能是不可靠的，所以这项任务有一点困难

单方向的可靠数据传输流程大概是这样的：可靠数据传输（TCP）->不可靠数据传输（IP）->不可靠的传输信道（链路层）->不可靠数据接收（IP）->可靠数据接收（TCP）-> 交付到应用层

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

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

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

RDT的发展历程

• 经完全可靠信道的可靠数据传输：RDT 1.0

  最简答的情况，底层信号完全可靠，然而这在实际中不能实现

• 经由具有比特差错信道的可靠数据传输：RDT 2.0

  假设所有发送的分组都可以按其发送顺序被接收。基于重传机制的可靠数据传输协议称为自动重传请求协议（ARQ）。增加了ACK和NCK

  增加了反馈机制，接收成功ACK，如果传输不正确反馈NCK

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

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

• 增强了反馈机制：RDT 2.1

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

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

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

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

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

• 删除了NAK，使用序号版的ACK：RDT 2.2

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

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

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

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

• 增加定时机制，超时重传：RDT 3.0

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

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

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

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

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

一次只能接收和发送一个

流水线协议

RDT 3.0 是一个功能正确的协议，但是由于它是一个停等协议，大部分的时间都浪费在等待确认上面，所以性能不好。
解决这种特殊性能问题的一个简单的方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。这种技术被称为 流水线。

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

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

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

• 回退 N 步，顺序接收，一个错了回退重传整个分组
• 选择重传，允许逆序接收，一个分组中一个没有接收到只用重传没有接收到的

3.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，这就导致发送方移动窗口；如果不是按序到达，那么接收方丢弃所有失序分组；丢弃一个正确接收的失序分组可能会导致更多的重传

发送方的缓存可以缓存多个，但是接收方的缓存只能缓存一个，因此当接收方在接收时，如果缓存已经被占，则不会再接收，并且在接收方发出的ACK是累计确认的，当发送超时事件时发送方缓存中所有已经发送但是没有确认的分组都会再重新发送

3.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，所以有可能不同分组同时占用一个序号，为了避免这种情况，需要做的是控制分组的生命周期。窗口长度必须小于或等于序号空间大小的一半

3.4.5 可靠数据传输机制和用途总结

3.5 面向连接的TCP

3.5.1 TCP连接

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

TCP的连接，并不是一条像电路交换网络中端到端的TDM、FDM电路，也不是一条虚电路；其连接状态被端系统所维护而中间路由器完全忽略了该协议，中间路由器看到的只是数据，也就是说，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报文段到达接收端时，便进入了接收端的缓存，等待被应用程序读取。

TCP连接的每一端都有发送和接收缓存

3.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连接可以采取任意数字作为初始序号，这样可以减少将那些残存在网络中的报文段误认为是新建连接的报文段（新旧连接恰巧采用了相同端口）

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

TCP提供累计确认

Telnet：应用层协议

即使报文段没有护具仍有序号。这是因为TCP存在序号字段，报文段必须填入某个序号

3.5.3 往返时间的估计与超时

TCP使用超时重传机制来处理报文段的问题；虽然这在概念上很简单，但是一个问题是，如何设置超时时间？

如何设置超时时间，取决于网络的状态，所以需要做的是估计网络的状态。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就又用上值计算了

3.5.4 可靠数据传输

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

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

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

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

1.超时时间加倍

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

2. 快速重传

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

接收端每收到一个文件会对发送进行响应，如果发送总是接到某个分组后面的确认，一直没有收到该分组的确认，就会进行快速重传，通常为接收到3个后面的分组确认时，这时如果还没有到定时器结束的时间就会进行快速重传，这并不是超时重传而是在要到超时重传时间前进行的一次重传

下表是 TCP 接收方的 ACK 接收策略

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

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

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

3.5.5 流量控制

流量控制是一个速度匹配服务：TCP连接的发送方和接收方都各自维护一个缓存，因此两者的数据交换应该在一个合理的速度范围内：不让对方发生数据溢出；TCP为它的应用程序提供了这种服务：流量控制服务。虽然流量控制和拥塞控制所采取的动作非常相似，但是它们的目的很明显并不同。在接下来的讨论中，我们将假设TCP是这样实现的，即TCP接收方丢弃失序到达的报文段

在TCP首部中有一个窗口大小字段，TCP连接的双方通过该字段来向对方表明自己的窗口大小，即缓存空间的大小；同样，在TCP连接的两端，各自维护着相关的变量：last Sent、last Acked；在发送方，这两个变量之间的分组就是已经发送但是尚未确认的分组；而在接收方，last Read表示应用进程下一次读取的数据，last Revd表示最后纳入缓存的报文段编号（注意，我们讨论的前提是TCP会将失序到达的报文段丢弃的）；通过这些变量以及报文段首部中窗口大小字段，我们就可以对发送速度做一些控制：在发送方last Sent-last Acked应该小于等于接收方的窗口大小；在接收端A**=last Received-last Read就是已经使用的空间大小，所以窗口大小=buffer-A**；

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

3.3.6 TCP连接管理

• TCP三次握手

  PS：TCP协议中，主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，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状态，服务端将会一直等待下去，这样浪费服务端连接资源

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

  我们知道，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永远无法正常关闭。

3.6 拥塞控制原理

3.6.1 拥塞原因与代价

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

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

3.6.2 拥塞控制方法

拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；拥塞控制更多是为所连接的网络，减少传播过程的拥塞

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

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

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

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

3.6.3 网络辅助的拥塞控制例子：ATM、ABR拥塞控制、异步传输方式、可用比特率

ATM基本上采用一种面向虚电路的方法来处理分组交换

ABR已被设计成一种弹性数据传输服务

对于ATM和ABR服务，数据信元经过一系列交换机传输到目的地。在数据信元中夹杂着所谓的资源管理信元（RM信元）。这些RM信元可被用作在主机和交换机之间传递与堵塞相关的消息。当一个RM信源到达目的地时，它将掉头并向发送端发送。交换机也可能自己产生一个RM信元，并将该信元直接发送给源。因此，RM信元可以用来提供直接网络反馈和经由接收方的网络反馈。

与拥塞相关的信令信息：

1. EFCI比特。每个数据信元都包含一比特的显式转发拥塞指令（EFCI）。某拥塞的网络交换机可把一个数据信元中的EFCI设为1来向目的主机发送网络已经堵塞的信令。当一个RM到达时，如果多数近来收到的数据信元的EFCI都是1，则目的地会将RM的堵塞指示比特（CI）设为1，并将RM信元发送给发送方。
2. CI和NI比特。RM信元的夹杂比率可调。每个RM信元包含一个拥塞指示比特（CI）和无增长比特（NI）。轻微堵塞NI设1，严重堵塞CI设1
3. ER的设置。每一个RM信元还包含一个两个字节的显式速率（ER）字段。一个拥塞的交换机也许会降低ER的值。ER字段被设置为在源和目的路径上所有交换机中的最小可支持速率。

3.7 TCP拥塞控制原理

TCP必须使用端到端的拥塞控制而不是网络辅助的拥塞控制，因为IP并不会向端系统提供显式的网络拥塞反馈；TCP所采用的方法是让每一个发送方根据其所感知的网络拥塞程度来限制其能向连接发送流量的速率；如果TCP判断网络通畅，那么它会提高发送速率，如果TCP判断网络拥塞，那么它会限制发送速率；

需要解决三个问题：TCP如何限制发送速率？TCP如何感知网络拥塞程度？TCP该以何种算法改变其发送速率？

我们知道，TCP连接的双方都维护着两个窗口，其中一个是作为发送方的窗口，也被称为拥塞窗口（CWND），它对发送方能向网络中发送流量的速率进行了限制，last sent-last acked<=min{cwnd,rwnd}；另一个自然是作为接收方的接收窗口。

我们假设，发送方可以在RTT时间范围内连续发送cwnd个字节的数据，所以发送速率即为cwnd/RTT；发送方通过调整窗口大小来对发送数据的速率加以控制

我们将TCP发送方的丢包事件定义为：要么超时，要么收到接收方的3个冗余ACK；如果网路拥塞，那么网络中的路由器就会发生缓存溢出，进而导致数据报被丢弃，然后就会引起发送方的丢包事件；此时，TCP发送方就可以认为TCP连接出现了拥塞

另外，TCP将接收方发送的ACK视为网络通畅的标志，如果ACK到达的速率较高，那么TCP的拥塞窗口就会以较高的速率扩大，如果ACK到达的速率较慢，那么TCP拥塞窗口的增加速度也会较慢；因为TCP使用ACK对拥塞窗口做出调节，所以也别称为自计时的；

TCP发送速率过高，网络就很容易拥塞；TCP发送方如果过于谨慎，那么就无法充分利用网络的带宽；所以TCP如何设置自己的发送速率，才能使得网络不会拥塞而且还充分利用带宽呢？关于这个问题，TCP使用下列指导性原则回答这些问题：

一个丢失的报文段意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率

一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此，当收到对先前报文段的确认时，可以增加发送方的速率

带宽检测，TCP调节器传输速率的策略是增加其速率以响应到达的ACK，除非出现丢包，此时才减少发送速率；因为网络中没有明确的拥塞控制状态信令，ACK和丢包事件充当了隐式信号

以上为TCP拥塞控制的概述，接下来就是广受赞誉的TCP拥塞控制算法，该算法包含三个主要部分：**慢启动、拥塞避免、快速恢复；**慢启动和拥塞控制是TCP的强制部分；两者的差异在于对收到的ACK做出反应时增加cwnd长度的方式；快速恢复是推荐部分，对于TCP发送方并非是必须的

1.慢启动

TCP连接在开始的时候，其cwnd常设置为一个MSS，然后在慢启动状态每收到一个ACK，cwnd就增加一倍MSS；这样的话，在慢启动阶段，发送速率是指数增加的（1,2,4,8…）

何时结束这种指数增长？

有三种情况：发送了超时、发生了冗余ACK以及cwnd达到ssthresh。ssthresh是慢启动阈值的速记；在慢启动阶段，如果发生了超时事件，那么ssthresh就被设置为当前cwnd的一半，然后将cwnd置为1；当cwnd逐步增加到ssthresh时，再翻倍增加cwnd就有一点鲁莽了，所以此时TCP结束慢启动，进入拥塞避免模式。在拥塞避免模式里，TCP将更谨慎地增加cwnd；如果收到冗余ACK，那么TCP会做一次快速重传，然后进入快速恢复阶段；

2.拥塞避免

一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的一半，所以TCP在每个RTT中，只将cwnd增加一个1个MSS大小；也就是说在拥塞避免阶段，cwnd是线性增加的；

当出现超时时，TCP将cwnd设置为1，然后将ssthresh更新为cwnd的一半；当收到冗余ACK时，TCP将cwnd减半，然后将ssthresh置为cwnd值的一半，并且进入快速恢复状态；

3.快速恢复

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

当多条连接共享一条瓶颈链路时，那些具有较小RTT的连接能够在链路空闲时更快的抢到可用带宽（即较快的打开其拥塞窗口），因而将比那些具有较大RTT的连接享用更高的吞吐量。