传输层为网络应用进程之间的通信提供了端到端的报文传输服务。在五层参考模型中，传输层位于应用层和网络层之间，向下使用网络层提供的分组传输服务，向上为各种网络应用提供端到端的报文传输服务。传输层是除应用层外唯一的端到端层，是支持应用进程之间的端到端通信的重要一层，绝大多数网络应用都直接使用传输层提供的端到端报文传输服务。

第一节 传输层的基本服务

一、传输层功能

传输层的核心任务是为应用进程之间提供端到端的逻辑通信服务。为此，传输层主要实现如下功能：传输层寻址；对应用层报文进行分段和重组；对报文进行差错检测；实现进程

间端到端可靠数据传输控制；面向应用层实现复用与分解；实现端到端的流量控制；拥塞

控制等。当然，并不是所有传输层协议都要实现所有这些功能，通常大部分传输层协议只

实现其中一部分功能。不同传输层协议提供的服务也不同，例如，Internet 的传输层主要有

两个协议：面向连接的 TCP 和无连接的 UDP，前者提供可靠数据传输服务，而后者则不提

供可靠数据传输服务。

   传输层协议为运行在不同主机或不同端系统上的进程提供了逻辑通信服务。

   作为向上层应用提供端到端逻辑通信服务的传输层协议，只需要在端系统中实现，而在路由器等网络设备中理论上无需实现传输层协议。因此，当网络边缘中的两台主机通过网络核心进行端到端的通信时，只有主机的协议栈中才有传输层协议，而在网络核心部分中的路由器在转发分组时只用到下三层的功能，即不需要使用传输层协议。

   从传输层的角度看，通信的真正端点并不是主机，而是主机中运行的应用程序，也就是说，端到端的通信是在【应用进程】之间的通信。

   大部分计算机网络的传输层都设计实现了多种传输层协议，实现不同功能，提供不同类型或不同性能的服务，满足不同网络应用对不同传输服务质量（Qos）的需求。例如，Internet网络有两种传输层协议，即TCP和UDP，TCP提供面向连接的、可靠的、有序的字节流服务，UDP则提供无连接、不可靠的数据包传输服务。

二、传输层寻址与端口

   传输层为应用进程之间提供端到端的逻辑通信服务。

   传输层为了支持运行在不同主机、不同操作系统上的应用进程之间的通信，必须用统一的寻址方法对应用进程进行标识。TCP/IP 体系结构网络的解决方法就是在传输层使用协议端口号（protocol port number）,通常简称为端口（port）,在全网范围内利用“IP 地址+端口  号”唯一标识一个通信端点。IP 地址唯一标识进程运行在哪个主机上，同一主机上传输层协议端口号则可以唯一对应一个应用进程。

   传输层端口号为16位整数，其中0〜1023为熟知端口号；1024〜49151为登记端口号，为没有熟知端口号的应用程序（服务器）使用，必须在互联网数字分配结构（The Internet

Assigned Numbers Authority, IANA）登记，以防止重复；49152~65535为客户端口号或短暂端口号，留给客户进程或用户开发的非标准服务器暂时使用。另外，端口号只本地有效，只是标识了本计算机应用层中的各应用进程在与传输层交互时的层间接口，在 Internet 不同计算机中运行的网络应用进程可能使用相同的端口号。

    基于上述机制，两台计算机中的网络应用进程要相互通信，不仅必须知道对方的IP地址（标识对方运行的计算机），而且还要知道对方的端口号（标识对方计算机中的传输层与应用进程的接口）。Internet上的网络应用通信基本过程是客户/服务器通信方式，客户在发起通信请求时，必须知道服务器的IP地址和端口号。传输层的端口号又分为服务器端使用的端口号与客户端使用的端口号两大类。服务器端使用的端口号包括上面提到过的熟知端口号与登记端口号，IANA将熟知端口号指派给TCP/IP最重要的一些应用程序（通常也称为标准服务），作为这些应用的服务器默认端口号，便于用户熟记，如FTP服务器默认端口号是21，HTTP服务器默认端口号80，SMTP服务器默认端口号是25，DNS服务器默认端口号是53。

   客户端使用的端口号仅在客户进程运行时才动态选择，具有临时性，通常在客户进程运行时由操作系统随机选取唯一的未被使用的端口号。在客户/服务器通信中，通信总是由客户发起，当服务器进程接收到客户端进程的报文时，就可以获得客户进程所使用的端口号，因而可以把数据发送给客户进程。当通信结束后，刚才已使用过的客户端端口号就可以释放了，这个端口号就可以供其他客户进程以后使用。

三、无连接服务与面向连接服务

传输层提供的服务可以分为无连接服务和面向连接服务两大类。无连接服务是指数据传输之前无需与对端进行任何信息交换（即“握手”），直接构造传输层报文段并向接收端发

送；面向连接服务是指在数据传输之前，需要双方交换一些控制信息，建立逻辑连接，然

后再传输数据，数据传输结束后还需要再拆除连接。无连接服务类似于邮政系统的信件通

信，  邮寄信件之前无需跟收件人交换任何信息，直接写好信件，交给邮递员投递就可以了；

面向连接服务类似于电话通信，必须首先拨号，建立电话连接，对方接起电话后，才可以

进行语音交互通信，通信结束后还需要挂断电话，拆除连接。当然，电话通信建立的是电

路连接，传输层提供面向连接服务时，建立的是逻辑连接。Internet网络提供无连接服务的

传输层协议是UDP，提供面向连接服务的传输层协议是TCP。

第二节 传输层的复用与分解

支持众多应用进程共用同一个传输层协议，并能够将接收到的数据准确交付给不同的应用进程，是传输层需要实现的一项基本功能，称为传输层的多路复用与多路分解，简称为复

用与分解，也称为复用与分用。

事实上，复用与分解不仅在传输层进行，在他层协议（比如IP等）也需要完成这一功能。

在同一主机上，多个应用进程同时利用一个传输层协议（比如UDP或TCP）进行网络通信，此时该传输层协议就被多个应用进程【复用】；另外，传输层协议接收到的报文段中，可能封装了不同应用进程的数据，传输协议需要（通过正确的端口）将数据交付给正确的应用进程，即实现【分解】。

实现复用与分解的关键是传输层协议能够唯一标识一个套接字。

一个网络应用进程通过一个或多个套接字，实现传输层之间的数据传递，即发送数据和接收数据。

Internet传输层协议的报文段中都有源端口号和目的端口号字段。在接收端，传输层协议读取报文段中的这些字段，标识出接收套接字，进而通过该套接字，将传输层报文段中的数据交付给正确的套接字，这一过程就是多路分解。在源主机，传输层协议从不同套接字收集应用进程（可能时不同的网络应用）发送的数据块，并为每个数据块封装上首部信息（包括用于分解的信息）构成报文段，然后将报文段传递给网络层，这一过程就是多路复用。 

一、无连接的多路复用与多路分解

Internet传输层提供无连接服务的传输层协议是UDP。

简述为UDP套接字分配端口号的两种方法

一种方法是创建一个UDP套接字时，传输层自动地为该套接字分配一个端口号（通常从1024~65535分配一个端口号），该端口号当前未被该主机中任何其他UDP套接字使用；另一种方法是，在创建一个UDP套接字后，通过调用bind()函数为该套接字绑定一个特定的端口号。

 

UDP套接字的端口号是UDP实现【复用与分解】的重要依据。

二、面向连接的多路复用与多路分解

Internet传输层提供面向连接服务的是TCP。TCP套接字与UDP套接字不同，TCP套接字是由一个四元组：<源IP地址，源端口号，目的IP地址，目的端口号>来唯一标识的。实质上，TCP通过这样一个四元组唯一标识一条TCP连接。当一个TCP报文段从网络层到达一台主机时，该主机使用全部4个值来将报文段分解到相应的套接字。特别的，当TCP接收到两个具有不同的源IP地址或者源端口号的TCP报文段时，即使两个报文段的目的IP地址和目的端口号相同，TCP也会将两个报文段分解到两个不同的套接字。显然，这与UDP完全不同。

TCP 服务器可以同时支持多个 TCP 套接字，每个套接字与一个进程（或线程）相关联，并由一个四元组来标识每个套接字。当一个 TCP报文段到达主机时，4 个字段都被用来将报文段分解到相应的套接字。需要再次说明的是，四元组中的源端口号和目的端口号是TCP 报文段首部字段，而源IP地址和目的IP地址则是封装TCP报文段的IP数据报的首部字段。

 

简述在Internet网络中如何通过套接字实现精确分解？

概括来说，在 Internet 网络中，唯一标识套接字的基本信息是 IP 地址和端口号。UDP基于目的IP地址和目的端口号二元组唯一标识一个UDP套接字，从而可以实现精确分解；  TCP则需要基于源IP地址、目的IP地址、源端口号和目的端口号四元组唯一标识一个 TCP  套接字（即一个 TCP 连接），从而实现精确分解。

第三节 停-等协议与滑动窗口协议

Internet 传输层主要有两个协议：UDP和TCP，其中TCP就可以提供可靠数据传输服务。但是，TCP发送的报文段都是交给IP传送的，而IP只能提供“尽力”服务，也就是不可靠的数据包传输服务。显然，TCP必须采取适当的措施才能使其在基于不可靠的网络层的基础上，实现可靠数据传输，为应用层提供可靠报文传输服务。

一、可靠数据传输基本原理

理想传输信息不产生差错（即比特跳变），并提供按序交付服务的理想或逻辑信道。大部分传输信道，例如实际的网络传输服务，都不是理想传输信道。需要特别注意的是，这里所说的传输信道可以是网络层提供的主机到主机的逻辑通信服务，可以是传输层提供的进程到进程的端到端的逻辑通信服务，也可以是提供信号传输的物理链路服务等，因此可靠数据传输基本原理、停-等协议以及滑动窗口协议等，不仅适用于指导设计支持可靠数据传输的传输层协议，也适用于指导设计其他层的可靠传输协议，如数据链路层协议等。

简述不可靠传输信道的不可靠性主要表现

首先，不可靠传输信道在传输数据的过程中，可能发生比特差错。也就是说，交付给这样的信道传输的数据可能出现比特跳变，即0错成1或1错成0的现象。

其次，不可靠传输信道在传输数据的过程中，可能出现乱序，即先发的数据包后到达，后发的数据包先到达。

最后，不可靠传输信道在传输数据的过程中，可能出现数据丢失，即部分数据会在中途丢失，不能到达目的地。

 

简述传输层实现可靠数据传输的主要措施。

1、差错检测：利用差错编码实现数据包传输过程中的比特差错检测（甚至纠正）。

2、确认：接收方向发送方反馈接收状态。

3、重传：发送方重新发送接收方没有正确接收的数据。

4、序号：确保数据按序提交。

5、计时器：解决数据丢失问题。 

有效、合理地综合应用上述措施，就可以设计出实现可靠数据传输的协议。基于这些措施设计的、具有代表性的可靠数据传输协议当属停-等协议和滑动窗口协议。

二、停-等协议

基于重传机制的可靠数据传输协议称为自动重传请求（Automatic Repeat reQuest, ARQ）协议。最简单的ARQ协议就是停-等协议。

简述停-等协议的特点和基本工作过程

停-等协议的主要特点就是每发送一个报文段后就停下来等待接收方的确认，这也是该协议

名称的基本含义。停-等协议的基本工作过程是：发送方发送经过差错编码和编号的报文段，

等待接收方的确认；接收方如果正确接收报文段，即差错检测无误且序号正确，则接收报

文段，并向发送方发送ACK，否则丢弃报文段，并向发送方发送NAK；发送方如果收ACK，则继续发送后续报文段，否则重发刚刚发送的报文段。

   停-等协议虽然简单，但在应用实现可靠数据传输的各种措施时，仍然存在许多的变化或细节需要讨论。
1、关于差错检测。对于底层传输信道可能产生比特差错的情况下，不仅报文段的传输可能

发生比特差错，ACK或NAK数据包在通过底层信道传输时同样可能会发生比特差错，因

此对报文段和ACK或NAK数据包均需进行差错编码以便进行差错检测。

2、关于序列号。对于停-等协议，序列号字段只需要1位就足够了，因为在停-等协议中，

只需利用报文段的序号区分是新发的报文段还是重传的报文段。接收方根据报文段的序号

就可以知道发送方是否正在重传前一个报文段（即接收到的报文段序号与最近收到的报文

段序号相同），还是一个新报文段（即序号变化了，用模2运算“前向”移动了）。

3、关于ACK和NAK。如前所述，在停-等协议中，接收端可以利用ACK进行肯定确认，

利用NAK进行否定确认。但在实际的协议设计过程中，通常不使用NAK,而只使用ACK进行确认，这样可以减少数据包的种类，降低协议的复杂性。这会带来一个新的问题，那就是当接收端接收到的报文段出现差错时，如何向发送端进行确认呢？显然，如果只简单地发送 ACK 是肯定不行的，那会被发送方误解接收端已经正确接收了刚刚发送的报文段。为此，需要对 ACK 做细微的改进，即在ACK数据包中带上所确认的报文段序列号。例如，接收端当前正期望接收0号报文段，接收方收到报文段后首先进行差错检测，如果未发生差错，且报文段序号为0，则接收报文段，并向发送方发送ACK0,对0号报文段进行确认；如果检测到报文段有差错，或报文段不是0号报文（即1号报文段，为重复报文段），则丢弃该报文段，并向发送方发送ACK1，进行确认，相当于对上一个正确接收的1号报文段再次进行肯定确认。当发送方再次收到 ACK1 时，即收到重复的 ACK1，则表明刚刚发送的0号报文段没有被接收方正确接收，所以需要重发。也就是说，利用重复 ACK 替代了NAK。

4、关于ACK或NAK差错。在ACK或NAK数据包中增加了差错编码后，发送方可以检测出ACK 或NAK是否发生差错。如果发送方检测出ACK或NAK差错，则不能准确判断接收方是否已正确接收报文段或者没有接收报文段。在这种情况下，为了确保可靠传输，发送方采取“有错推断”'原则，即推断接收方没有正确接收相应的报文段。因此，当发送方检测到收到的ACK或NAK有差错时，便重传刚刚发送的报文段。当然，这可能带来一个新问题，就是接收方可能重复接收到同一个报文段，但接收方可以通过报文段的序号判断是否是重复的报文段，对于重复到达的报文段进行丢弃并确认即可。

 

停-等协议综合应用了差错检测、确认、重传、序号和计时器等措施，每种措施都在协议的运行中起到了至关重要的作用，实现了可靠数据传输。停-等协议的特点是简单、所需缓存存储空间小。

三、滑动窗口协议

停-等协议是一个功能正确的协议，但其性能通常并不能令人满意。停-等协议的主要性能问题在于它的停止-等待机制降低了信道的利用率。

解决这种特殊性能问题的一个简单方法是：不使用停-等协议的停止—等待运行方式，允许发送方在没有收到确认前连续发送多个分组。

 

如果发送方可以在等待确认之前连续发送 3 个分组，则协议的信道利用率相对于停-等协议就提高到3倍。在这种可靠数据传输协议中，从发送方向接收方传送的系列分组可以看成是填充到一条流水线（或一条管道）中，故称这种协议为流水线协议或管道协议。

相对于停-等协议，流水线协议实现可靠数据传输时，需要做如下的改进。

1、必须增加分组序号范围。必须确保每个正在传送中、未被确认的分组有一个唯一的  序号（重传的分组除外），以便准确区分每一个未被确认的分组。因此，在流水线可靠传输  协议中，分组中的序号字段需要多位，而不能像停-等协议那样只使用1位序号。

2、协议的发送方和（或）接收方必须缓存多个分组。发送方最低限度应当能缓冲那些  已发送但没有确认的分组，一旦其中任何一个或多个分组丢失或错误，发送方可以从缓存中

取出相应的分组，重发这些分组进行纠错。类似地，接收方或许也需要缓存那些已正确到达  但不是按序到达的分组，以便等缺失的分组到达后一并按序向上层提交数据。

最典型的【流水线可靠传输协议】是【滑动窗口协议】。

发送窗口内的序号，可能存在 3 种状态。

1）  已用未被确认序号。

2）  已用且已被确认序号。

3）  可用但尚未使用的序号。

当前接收窗口中的序号，可能存在两种状态：一种是期望接收但未收到的序号；另一种是

已接收序号。

1. GBN协议

GBN协议的发送端缓存能力较高，可以在未得到确认前连续发送多个分组，因此，GBN协议的发送窗口Ws≥1。GBN接收端缓存能力很低，只能接收1个按序到达的分组，不能缓存未按序到达的分组，通常称GBN协议的接收端无缓存能力。因此，GBN协议的接收窗口Wr=1。

 

GBN 发送方必须响应 3 种类型的事件。

1）  上层调用。当上层调用GBN协议时，发送方首先检查发送窗口是否已满，即是否有Ws个已发送但未被确认的分组。如果窗口未满，则用“下一个可用序号”编号新的分组并发

送，更新“下一个可用序号”（加1）;如果窗口已满，发送方则暂不响应上层调用，拒绝发送新的数据。

2） 收 到 1个ACKn。GBN 协议采用累积确认（cumulative acknowledgment）方式，即当发送方收到ACKn 时，表明接收方已正确接收序号为n以及序号小于n的所有分组。如果 n在当前发送窗口范围内，则表明至少1个已发送未被确认分组得到了确认，发送窗口滑动到“基序号”为 n+1 的位置；窗口滑动后，如果还有未被确认的分组，则重新启动计时器，否则停止计时。当GBN协议只使用ACK肯定确认时，发送方可能会收到对同一个序号的多次重复确认，被重复确认的序号在当前发送窗口的左侧，即n小于当前窗口的“基序号”。 收到重复ACK确认时，发送方可以不予理会。

3） 计时器超时。GBN协议发送方只使用1个计时器，且只对当前发送窗口的“基序号”

指向的分组进行计时。如果出现超时，发送方重传当前发送窗口中所有已发送但未被确认的分组,这也是为什么将GBN协议称为“回退N步”协议的原因。实质上，GBN协议之所以“回退N步”，是因为Wr=l,即接收方无缓存能力。如果发送方收到一个ACK，窗口滑动后仍有已发送但未被确认的分组，则定时器重新启动；如果没有已发送但未被确认的分组，该定时器终止。

GBN 协议的接收方的操作很简单:因为 Wr=1,所以 GBN 接收方只能接收当前接收窗口中序号（即“基序号”）所指向的分组。

  在差错率较低的情况下，GBN协议的信道利用率会得到很大提高。但是，如果信道误码率或丢包率较高，会导致大量分组的重发（包括那些正确到达接收方的失序分组），使信道传输能力降低。GBN协议比较适用于低误码率、低丢包率、带宽高时延积信道，且接收方缓存【能力要求低】。

 

2. SR协议

若改进GBN协议的设计，增加接收方缓存能力（即令Wr≥1），缓存那些正确到达但失序的分组，等缺失分组到达后一并向上层按序提交。当然，这同时需要改进确认方式，使发送方及时确认哪些分组已经被正确接收（未必是按序接收），以免发送方超时重传这些已经被接收方正确接收了的分组。这种设计可以在信道差错率或丢包率增加的情况下，减少不必要的分组重传，改进协议的性能。基于这种设计思想的滑动窗口协议就是选择重传（SR）协议。

顾名思义，选择重传（SR）协议是通过让发送方仅重传那些未被接收方确认（出错或丢失）的分组，而避免了不必要的重传。为此，SR协议的接收方是对每个正确接收的分组进行逐个确认。SR协议的发送窗口和接收窗口都大于1，虽然理论上发送窗口和接收窗口大小可以不相等，但很多SR协议设计取相同的发送窗口和接收窗口大小。

SR协议的发送方可以连续发送多个分组，每个分组在当前发送窗口中必须有唯一的编号。

SR 发送方主要响应3个事件，并完成相应操作

1）上层调用，请求发送数据。

2）定时器超时。

3）收到 ACKn

SR 协议接收方的主要操作分以下3种情况:

1）  正确接收到序号在接收窗口范围内的分组PKT

2）  正确接收到序号在接收窗口左侧的分组PKTn。

3）  其他情况，接收方可以直接丢弃分组，不做任何响应。

第四节 用户数据报协议（UDP）

用户数据报协议UDP是Internet传输层协议，提供无连接、不可靠、数据报尽力传输服务。UDP 是一种轻量级传输层协议，只提供最基本的传输层服务。UDP是无连接的，因此在支持两个进程间通信时，没有握手过程。UDP提供一种不可靠数据传送服务，也就是说，当应用进程将一个报文发送进UDP套接字时，UDP并不保证将该报文送达到目的接收进程。不仅如此，在发送方依次发送的报文段，UDP即便将这些报文段送达到接收进程，也可能是乱序到达的。UDP没有拥塞控制机制，所以UDP发送端可以用任何速率向其下层（即网络层）注入数据。当然，实际端到端吞吐量可能小于这种速率，这可能是因为中间链路的带宽受限或因为网络拥塞而造成的。

传输层协议必须至少做一点点事情，即必须提供一种复用/分解服务，这样才能在网络层与正确的应用进程之间传递数据。

UDP就是只做了传输层协议需要完成的最少功能的协议，除了复用/分解功能以及简单的差错检测外，几乎没有对网络层的IP增加任何功能。

DNS是一个使用【UDP】的应用层协议的例子。

使用 UDP 的原因

1）  应用进程更容易控制发送什么数据以及何时发送。

2）  无需建立连接。

3）  无连接状态。

4）  首部开销小。

简述UDP提供的服务的主要特征。

（1）应用进程更容易控制发送什么数据，以及何时发送。采用UDP时，只要应用进程将数据传递给UDP，UDP就会将此数据打包进UDP报文段并立即将其传递给网络层。

（2）无需建立连接。UDP不需要任何准备即可进行数据传输。因此，UDP不会引入建立连接（根本就无连接）的时延。

（3）无连接状态。UDP是无连接的，因此也无需维护连接状态。

（4）首部开销小。UDP仅有8字节的开销。

 

  需要说明的一点是，虽然UDP提供不可靠传输服务，但使用UDP的应用仍然可以实现可靠数据传输。这可以通过在应用程序自身中建立可靠传输机制来完成，如前面介绍的停-等协议或滑动窗口协议等。也就是说，应用进程可以使用UDP的同时进行可靠通信，只是需要在【应用层设计可靠传输机制】而已。

 

一、UDP数据报结构

0                                      16                                    31

源端口号

目的端口号

长度

校验和

应用数据

简述UDP数据报结构中各字段的含义

UDP首部只有4个字段，每个字段由两个字节组成。源和目的端口号用于UDP实现复用与分解。长度字段指示了在UDP报文段中的字节数（首部和数据的总和）。接收方使用校验和来检测该数据报是否出现了差错。

二、UDP校验和

UDP 校验和提供了差错检测功能。

UDP 在计算校验和时，对所有参与运算的内容（包括UDP报文段）按16位（16位对  齐）求和，求和过程中遇到的任何溢出（即进位）都被回卷（即进位与和的最低位再加）。最后得到的和取反码，就是UDP的校验和，填入UDP数据报的校验和字段。UDP 在生成校验和时，校验和字段取全0。参与UDP校验和计算的内容包括 3 部分：UDP 伪首部、UDP首部和应用层数据。

第五节 传输控制协议（TCP）

传输控制协议（TCP）是Internet一个重要的传输层协议。TCP提供面向连接、可靠、有序、字节流传输服务。为了提供可靠数据传输，TCP采用了前面所讨论的许多措施，其中  包括差错检测、重传、累积确认、定时器以及序号和确认序号等。

一、TCP报文段结构

TCP 报文段由首部字段和一个数据字段组成。

1） 源端口号与目的端口号字段分别占16位，标识发送该报文段的源端口和目的端口，  用于多路复用/分解来自或送到上层应用的数据。 

2） 序号字段与确认序号字段分别占32位。 

3） 首部长度字段占4位，指出 TCP 段的首部长度，以4字节为计算单位，例如该字段值为5时，表示TCP段的首部长度为20字节。由于TCP选项字段的原因，TCP首部的长度是可变的。当该字段取最大值15时，表示TCP段的最大首部长度，即60字节。可见，TCP 段的选项字段最多为40字节。

4）保留字段占6位，保留为今后使用，目前值为0。

5）URG、ACK、PSH、RST、SYN 和 FIN 字段各占1位，共占6位，为6位标志位（字

段）。

6）接收窗口字段占16位，用于向对方通告接收窗口大小（单位为字节），表示接收方愿意（或还可以）接收的应用层数据字节数量，其值是本端接收对方数据的缓存剩余空间，  用于实现 TCP 的流量控制。

7）校验和字段占16位，校验和字段检验的范围类似于UDP，包括TCP伪首部、TCP首部和应用层数据3部分，计算方法与UDP校验和的计算方法相同。

8）紧急指针字段占16位，该字段只有URG=1时才有效。

9）选项字段的长度可变。

10）填充字段，长度为0〜3字节，取值全0,其目的是为了使整个首部长度是4字节的整数倍。

二、TCP连接管理

TCP 连接管理包括【连接建立】与【连接拆除】。

TCP 连接建立通过“三次握手”过程。假设主机A上的一个进程想与主机B上的一个进程建立一条TCP连接，主机A应用进程首先通知主机A的TCP，它想建立一个与主机B上某个进程之间的连接,主机A中的TCP会通过以下过程与主机B中的TCP建立一条TCP连接。

1） 主机A的TCP向主机B发出连接请求段（第一次握手）。

2） —旦包含 SYN 报文段的IP数据报到达主机B，SYN报文段被从该数据报中提取出来。主机B的TCP收到连接请求段后，如同意，则发回确认报文段（第二次握手）。

3） 主机A收到SYNACK报文段后，也要给该连接分配缓存和变量，并向主机B发送确认报文段（第三次握手），该报文段是对主机B的同意连接报文段进行确认，其中ACK=1, SYN=0（因为连接已建立），seq=x+l，ack_seq=y+1。第三次握手的 ACK 报文段可以携带从主机A到主机B的应用层数据。

三次握手

第一次握手：客户端作为连接建立发起端，选择客户端初始序列号x，向服务器发送  (SYN=1,

seq=x)的 SYN段。客户状态由LISTEN进入SYN_SEND 状态，等待服务器确认。

第二次握手：服务器收到客户发送的 SYN 段后，选择服务器初始序列号向客户发送  (SYN=1, ACK=1,  seq=y,  ack_seq=x+1) 的SYNACK段 。同时，服务器状态由LISTEN进入SYN_RCVD 状态。

第三 次 握 手 ： 客 户端 收 到 服 务 器  SYNACK  段 后 ， 向 服 务 器发 送 (ACK=1,  seq=x+1, ack_seq=y+1)的 ACK 段，同时，客户端进入ESTABLISHED 状态，客户端确认连接已建立；当服务器收到ACK段后，也进入ESTABLISHED状态，也确认连接已建立。至此，双方均确认连接建立成功。

 

四次挥手

1）当客户向服务器发送完最后一个数据段后，可以发送一个FIN段(FIN=1, seq=u), 请求

断开客户到服务器的连接，其状态由 ESTABLISHED 进入FIN_WAIT_1,在这一状态下，只

能接收服务器发送过来的数据，而不再发送数据。需要注意的是，FIN段不封装应用层数

据，但是也要消耗掉1个序列号（类似于SYN段）。

2）  服务器收到客户的 FIN 段后，向客户发送一个 ACK 段（ACK=1，seq=v, ack_seq=u+1）,

ACK 段可以封装应用层数据（如果有）。服务器状态由 ESTABLISHED 进入CLOSE_WAIT,

在这一状态下，服务器仍然可以发送数据，但不再接收数据。当客户收到ACK段后，其

状态由FIN_WAIT_1 进入FIN_WAIT_2,仍然可以接收来自服务器的数据。此时的 TCP 连接

已经关闭了客户向服务器方向的数据传输，故也称为半关闭。

3）  当服务器向客户发送完最后一个数据段后，服务器向客户发送FIN段（FIN=1, ACK=1，

seq=w, ack_seq=w+l），同样，该FIN段也不携带应用层数据。服务器状态则由 CLOSE_WAIT

进入LAST_ACK,此时服务器也不再发送数据。

4）  当客户收到服务器发送的 FIN 段后，向服务器发送ACK段（ACK=1，seq=w,

ack_seq=u+1）,其状态由FIN_WAIT_2进入TIME_WAIT，等待2MSL（Maximum Segment

Lifetime）时间，然后进入CLOSED状态，最终释放连接；服务器在收到最后一次ACK段

后，状态由 LAST__ACK 进入CLOSED，最终释放连接。

三、TCP可靠数据传输

TCP 能够提供可靠的数据传输服务，是通过以下工作机制来实现的。

1）  应用数据被分割成 TCP 认为最适合发送的数据块（通常是 MSS）,封装成TCP段，传递给IP。

2） 当TCP发出一个段后，启动一个计时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，则认为该报文段丢失，将重发这个报文段。当 TCP 收到发自 TCP 连接另一端的数据，将发送一个确认段。

3） TCP 首部中设有校验和字段，用于检测数据在传输过程中是否发生差错。如果收到

的报文段通过校验和检测，发现有差错，TCP 将丢弃这个报文段和不确认收到此报文段（希

望发送端超时并重发），而将已连续接收到的应用层数据的最后一个字节的序号加 1，作为

确认序号，向发送方发送确认段。

4） 由于TCP报文段封装到IP数据报中传输，而IP 数据报的到达可能会经过不同的路径从而造成顺序的错乱，因此TCP报文段的到达也可能会失序。如果必要，TCP将根据序号对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。

5） 由于存在网络延迟和重传机制，TCP的接收端有可能会收到多个重复的报文段，这时接收端需要根据序号把重复的报文段丢弃。

6） TCP能够提供流量控制。TCP连接的每一方都在建立连接时分配一定大小的接收缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这可以防止较快主

机发送数据太快，致使较慢主机的缓冲区溢出。

 

 TCP接收方生成ACK的策略主要有4种。

1）  具有所期望序号的报文段（即接收窗口基序号指向的段）按序到达，所有在期望序号

及以前的报文段都已被确认。此时，TCP接收方延迟发送ACK,最多等待 500 ms。如果下

一个按序报文段在这个时间段内没有到达，则发送ACK，对收到的段进行确认。

2）  具有所期望序号的报文段按序到达，且另一个按序报文段在等待ACK传输，TCP接收方立即发送单个累积ACK，以确认以上两个按序到达的报文段。

3）  拥有序号大于期望序号的失序报文段到达，TCP接收方立即发送重复ACK,即对当前

接收窗口基序号进行确认，指示下一个期待接收字节的序号。

4）  收到一个报文段，部分或完全填充接收数据间隔（缺失）。

四、TCP流量控制

流量控制（flow  control）的目的是协调协议发送方与接收方的数据发送与接收速度，避免因发送方发送数据太快，超出接收方的数据接收和处理能力，导致接收方被数据“淹没”，

即数据到达速度超出接收方的接收、缓存或处理能力，致使数据在接收方被丢弃。流量控

制问题不仅存在于端到端的传输层，也存在于数据链路层。

五、TCP拥塞控制

【拥塞】是指太多主机以太快的速度向网络中发送太多的数据，超出了网络处理能力，导致大量数据分组“拥挤”在网络中间设备（如路由器）队列中等待转发，网络性能显著下降的现象。

【拥塞控制】（congestion  control）就是通过合理调度、规范、调整向网络中发送数据的主机数量、发送速率或数据量，以避免拥塞或尽快消除己发生的拥塞。