《计算机网络 自顶向下方法》笔记 第三章 运输层

3.1 概述和运输层服务

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

运输层协议为运行在不同主机上的应用程序之间提供了逻辑通信功能。
从应用程序的角度看，通过逻辑通信，运行不同进程的主机好像可以直接连接，实际上，这些主机可能位于地球的两侧，通过很多路由器以及多种不同类型的链路相连。应用进程使用运输层提供的逻辑通信功能可以彼此发送报文，而无需考虑承载这些报文的物理基础设施的实现

运输层协议是在端系统中而不是路由器中实现的，在发送端，运输层将从发送应用程序进程接收到的报文转换成运输分组(运输层报文段)，实现的方法可能是将应用报文划分为较小的块，并为每块加上一个运输层首部以生成运输层报文段。然后在发送端系统中，运输层将这些报文段传递给网络层，网络层将其封装成网络层分组(数据报)，并向目的地发送

网络路由器仅作用于该数据报的网络层字段，它们不会检查封装在该数据报的运输层报文段的字段。在接收端，网络层从数据中心提取运输层报文段，并将该报文段上交给运输层，运输层则处理接收到的报文段，使该报文段中的数据为接收应用进程使用

因特网有两种协议，即TCP和UDP，每种协议都能为调用的应用程序提供一组不同的运输层服务

3.1.1 运输层和网络层的关系

运输层位于网络层之上，网络层提供了主机之间的逻辑通信，而运输层为运行在不同主机上的进程之间提供了逻辑通信
类比：

在上面的过程中，小王与小赵都是在自己家中工作，他们没有参加邮政服务的工作。同理，运输层协议只工作在端系统中，在端系统中，有关这些报文在网络核心如何移动并不做任何规定，事实上，中间路由器既不处理也不识别运输层加在应用层报文的任何信息。

运输层协议常常受制于底层网络协议的服务模型，如果网络层协议无法为主机之间发送的运输层报文段提供时延或者带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或者带宽保证。
然而，即使底层网络协议不能在网络层提供相应的服务，运输协议也能提供某些服务。即使底层网络是不可靠的，也就是说网络层协议会使分组丢失，篡改和冗余，运输协议也能为应用程序提供可靠数据传输服务，即使网络层不能保证运输层报文段的机密性，运输层协议也能使用加密来确保应用程序报文不被入侵者读取

3.1.2 因特网运输层概述

因特网为应用层提供了两种截然不同的可用运输协议，这些协议一种是UDP(用户数据报协议)，它为调用它的应用程序提供了一种不可靠的，无连接的服务，一种是TCP(传输控制协议)，它为调用它的应用程序提供了一种可靠的，面向连接的服务。这里将TCP和UDP的分组称为报文段，网络层分组称为数据段

因特网网络层协议有一个名字叫IP(网际协议)，IP为主机之间提供了逻辑通信。IP的服务模型是尽力而交付的服务，这意味着IP尽它的最大努力，但不做任何确保。它不确保报文段的交付，不保证报文段的按序交付，不保证报文段中数据的完整性，由于这些原因，也被称为不可靠服务。每台主机至少有一个网络层地址(IP地址)

UDP和TCP最基本的责任是，将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程之间的交付服务。将主机间交付扩展到进程间交付被称为运输层的多路复用与多路分解。UDP和TCP还可以通过在其报文段首部中包括差错检查字段而提供完整性检查，进程到进程的数据交付和差错检查是两种最低限度的运输层服务，也是UDP仅能提供的两项服务。与IP一样，UDP也是一种不可靠的服务，它无法保证数据完整到达目的进程

TCP为应用程序提供了几种附加服务，首先它提供可靠数据服务，通过使用流量控制，序号，确认和定时器，TCP确保正确地，按序的将数据从发送进程交付给接收进程，这样TCP就将两个端系统的不可靠IP服务转换成了一种进程间的可靠数据传输服务。

拥塞控制：TCP还提供拥塞控制，拥塞控制可以说是提供给整个因特网的服务，这是一种带来通用好处的服务。TCP拥塞控制防止任何一条TCP连接用过多流量来淹没通信主机间的链路和交换设备。TCP力求为每一个通过一条拥塞网络链路的连接平等地共享网络链路带宽，这可以通过调节TCP连接的发送端发送进网络的流量速率来做到。另一方面，UDP流量是不可调节的，使用UDP传输的应用程序可以根据其需要以其愿意的任何速率发送数据

3.2 多路复用和多路分解

运输层的多路复用与多路分解，也就是将由网络层提供的主机到主机的交付服务延伸到为运行在主机上的应用程序提供进程到进程的交付服务，多路复用和多路分解服务是所有计算机网络都需要的

在目的主机，运输层从紧邻其下的网络层接收报文段，运输层负责将这些报文段中的数据交付给在主机上运行的适当的应用程序进程。一个进程有一个或多个套接字，它相当于从网络向进程传递数据和从进程向网络传递数据的门户。在接收主机中的运输层实际上并没有直接将数据交付给进程，而是将数据交给了一个中间的套接字，每个套接字都有唯一的标识符

主机将一个到达运输层报文段定向到适当套接字的过程：每个运输层报文段中具有几个字段，在接收端，运输层检查这些字段，标识出接收套接字，进而将报文段定向到该套接字。在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息(用于以后分解)从而生成报文段，然后将这些报文段传递到网络层，这些工作叫多路复用，将运输报文段中的数据交付到正确的套接字的工作称为多路分解

运输层多路复用的要求：1，套接字有唯一标识符，2，每个报文段有特殊字段来指示该报文段索要交付到的套接字。这些特殊字段是源端口号字段和目的端口号字段。端口号是一个16比特的数，大小在0~65535之间，0-1023范围的端口号称为周知端口号是受限制的，这是指它们保留给诸如HTTP和FTP之类的周知应用层协议来使用

主机上每一个套接字能分配一个端口号，当报文段到达主机时，运输层检查报文段中的目的端口号，并将其定向到相应的套接字，然后报文段中的数据通过套接字进入其所连接的进程，UDP大体是这样做的，但TCP中的多路分解和多路复用更加复杂

无连接的多路复用和多路分解:

上图，主机B能够运行多个进程，每个进程有自己的UDP套接字及相应的端口号，当UDP报文段从网络到达时，主机B检查该报文段中的目的端口号，将每个报文段定向分解到相应的套接字。

一个UDP套接字是由一个二元组全面标识的，该二元组包含一个目的IP地址和一个目的端口号，因此，如果两个UDP报文段有不同的IP地址和/或源端口号，但具有相同的IP地址和目的地端口号，那么这两个报文段将通过相同的目的地套接字被定向到相同的目的进程

源端口号的作用：在A到B的报文中，源端口号作用“返回地址”的一部分，即当B需要发送一个报文段给A时，B到A的报文段中的目的端口号便从A到B的报文段中的源端口号中取值

面向连接的多路复用和多路分解：

TCP套接字是由一个四元组(**源IP地址，源端口号，目的IP地址，目的端口号)**识别的，当一个TCP报文段到达一台主机时，该主机使用全部4个值来将报文段定向分解到相应的套接字，与UDP不同的是，两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字

服务器主机可以支持很多并行的TCP套接字，每个套接字与一个进程相联系，并由其其四元组来标识每个套接字，当一个TCP报文段到达主机时，所有4个字段被用来将报文段定向分解到相应的套接字
服务器能正确地分解这两个具有相同源端口号地连接，因为这两条连接具有不同地源IP地址

Web服务器与TCP：连接套接字与进程之间并非总是有着一一对应地关系，事实上，当今地高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程(线程可看作一个轻量级的子进程)，对于这样一台服务器，在任意时间内都有可能有具有不同标识的许多套接字连接到相同的进程
如果客户与HTTP使用持续HTTP报文，则在整条连接持续时间，客户与服务器之间由同一个服务器套接字交换HTTP报文。然而当使用非持续HTTP时，每一个请求/响应都创建一个新的TCP连接并在随后关闭，因此对每一对请求/响应创建一个新的套接字并在随后关闭，这种套接字的频繁创建和关闭会严重影响到一个繁忙的Web服务器的性能

3.3 无连接运输 UDP

运输层最低限度必须提供一种复用/分解服务，以便在网络层与正确的应用级进程之间传递数据，如果开发者选择UDP而不是TCP，则该应用程序差不多就是直接和IP打交道。DNS通常使用UDP的应用层协议

TCP提供可靠数据传输服务，但仍有许多应用使用UDP原因主要有：
1，关于发送什么数据以及何时发送的应用层控制更为精细，对这些应用来说，由于TCP的拥塞控制机制，当链路变得极为堵塞时它会遏制运输层TCP发送方，从而降低传输效率。
2，无须建立连接，TCP在开始数据传输前需要三次握手，而UDP却不需要任何准备即可进行数据传输，所以UDP不会引入建立连接的时延。HTTP使用TCP而不是UDP，因为对具有文本数据的Web网页来说，可靠性是至关重要的
3，无连接状态，TCP需要在端系统中维护连接状态，此连接状态包括接收和发送缓存，拥塞控制参数，以及序号和确认号的参数。要实现TCP的可靠数据传输服务并提供拥塞控制，这些状态信息是必要的。而UDP不维护连接状态，也不跟踪这些参数，某些程序运行在UDP之上而不是TCP之上时，一般可以支持更多的活跃用户
4，分组首部开销小，每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的开销

对于电子邮件，远程终端访问，Web及文件传输都运行在TCP之上，它们需要TCP提供的可靠数据传输服务。UDP用于承载网络管理数据，在这种场合下，UDP要优于TCP，因为网络管理应用程序通常必须在该网络处于重压状态时运行，而正是这个时候，可靠的，拥塞受控的数据传输难以实现。DNS运行在UDP之上，从而避免了TCP的连接创建时延

TCP的拥塞控制机制会导致如因特网电话，视频会议之类的实时应用性能变得很差，由于这些原因，多媒体开发者常将这些应用运行在UDP之上。

UDP没有拥塞控制，但是需要拥塞控制来预防网络进入一种拥塞状态，如果每个人都启动流式高比特率视频而不使用任何拥塞控制的话，就会使路由器中有大量的分组溢出，伴随着拥塞，TCP的发送速率也会被降低。UDP中缺乏拥塞控制能够导致UDP发送方和接收方之间的高丢包率，并挤跨TCP会话

UDP应用是可能实现可靠数据传输的，这可以通过在应用程序自身中建立可靠性进制来完成(如可通过增加确认与重传机制来实现)，将可靠性直接构建于应用程序中可以使TCP兼具良好性能，此时应用程序可以进行可靠数据传输且无须受制于TCP拥塞控制机制强加的传输速率限制

3.3.1 UDP报文段结构

UDP首部只有4个字段，每个字段由两个字节组成。应用层数据占用UDP报文段的数据字段，对于DNS而言，数据字段要么包含一个查询文件，要么包含一个响应文件，对于流式音频而言，音频抽样数据填充到数据字段。长度字段指示了在UDP报文段中的字节数(首部加数据)，接收方使用检验和来检查在该报文段中是否出现了差错。

3.3.2 UDP检验和

UDP检验和提供了差错检测功能，检验和用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了变化。由于无法确保源到目的地之间的所有链路都提供差错检测，所以UDP提供了检验和，这是一种端到端原则但是它对恢复差错无能为力。

3.4 可靠数据传输原理

可靠数据传输的实现问题不仅在运输层中出现，也会在链路层及应用层出现

可靠数据传输的框架：数据可以通过一条可靠的信道进行传输，借助于可靠信道，传输数据比特就不会受到损坏或丢失，而且所有数据都是按照其发送顺序进行交付，这恰好就是TCP向调用它的因特网应用提供的服务模型

3.4.1 构造可靠数据传输原理

经完全可靠信道的可靠数据传输 ：rdt1.0：

首先考虑最简单的情况，即底层信道是完全可靠的，称该协议为rdt 1.0，上图显示了rdt 1.0发送方和接受方的有限状态机 FSM的定义。a中FSM定义了发送的操作，b中FSM定义了接收的操作。箭头指示了协议从一个状态变迁到另一种状态。在这个简单的协议中，一个分组和数据没有差别，而且所有的分组从发送方流向接收方，有了完全可靠的信道，接收端就不需要提供任何反馈信息给发送方，因为不必担心差错。这里假定了接收速率和发送速率一样快。

经具有比特差错信道的可靠数据传输 ：rdt2.0：

底层信道更为实际的模型是分组中的比特可能受损的模型。在分组的传输，传播或缓存的过程中，这种比特差错通常会出现在网络的物理部件中。

当你通过电话和某人交流，接收他向你传来的一系列报文时，当你理解了听清楚后，你可能会说ok，当没听明白，可能会让他再说一次。这个过程使用了肯定确认 ACK和否定确认 NAK，这些控制报文使得接收方可以让发送方知道哪些内容被正确接收，哪些内容有误需要重复。再计算机网络中，基于这样的重传机制的可靠数据传输协议称为自动重传请求协议 ARQ。

ARQ中需要三种协议功能来处理存在比特误差的情况：
差错检测：需要一种机制以使接收方检测何时出现了比特差错，UDP使用因特网检验和字段正是为了这个目的
接收方反馈：由于发送方和接收方在不同端系统上执行，发送方要了解接收方情况(发出的分组是否被正确接收)的唯一途径就是让接收方提供明确的反馈信息发给对方。rdt 2.0协议接受方向发送方回送ACK和NAK分组，理论上这些分组只需要一个字节，如用0表示NAK，用1表示ACK
重传：接收方收到有差错的分组时，发送方将重传该分组

rdt 2.0接收方的FSM只有一个状态，当分组到达时，接收方要么回答一个ACK，要么回答一个NAK，这取决于分组是否受损
发送方协议等待来自接收方的ACK和NAK分组，如果收到一个ACK分组，则发送方知道最近发送的分组已经被正确接收，如果接收到一个NAK分组，该协议重新上传一个分组并等待接收方为响应重传分组回送的NAK和ACK。当发送方在等待ACK或NAK时，它不会发送新的数据，这种协议称为停等

但是rdt 2.0没有考虑到ACK或NAK分组受损的可能性，解决这个问题的方法(几乎所有现有的数据传输协议中，包括TCP都采用)是在数据分组中添加一个新字段，让发送方对其数据分组编号，即将发送数据分组的序号放在该字段，于是接收方只需要检查序号即可确定收到的分组是否需要一次重传

改进后的rdt 2.0：

经具有比特差错的丢包信道的可靠数据传输：rdt3.0：
现在假定除了比特受损外，底层信道还会丢包，为了解决它，我们让发送方负责检测和恢复丢包工作。假定发送方传输一个数据分组，该分组或者接收方对该分组的ACK发生了丢失，在这两种情况下，发送方都收不到应当来的接收方的响应。如果发送方愿意等待足够长的时间以确定分组已丢失，则它只需要重传该数据分组即可

实践中，发送方明智的选择一个时间值，以判定可能发生了丢包(尽管不能确保)。如果这个时间内没有收到ACK，则重传该分组。注意如果一个分组经历了一个特别大的时延，发送方可能会重传该分组，即使该数据分组和ACK都没有丢失，这就在发送方和接收方的信道中引入了冗余数据分组

为了实现基于时间的重传机制，需要一个倒计数定时器，在一个给定的时间量过期后，可中断发送方。因此，发送方需要能做到，1，每次发送一个分组时，便启动一个定时器，2，响应定时器中断，3，终止定时器

由于分组序号在0和1之间交替，rdt 3.0也称比特交替协议：

一个可靠数据传输协议中需要 检验和，序号，定时器，肯定和否定确认分组这些技术，每种机制都在协议的运行中起到了必不可少的作用

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

在今天的高速网络中，rdt 3.0性能问题的核心在于它是一个停等协议，受到这个机制本身的影响，需要更好的传输协议

这种特殊的性能问题的一个简单解决方法就是，不以停等方式运行，允许发送方发送多个分组而无须等待确认，如果发送方可以在等待前发送3个报文，其利用率也基本提高三倍。这种技术称为流水线

流水线对可靠传输协议带来如下影响：
1，必须增加序号范围，因为每个输送中的分组(不算重传的)必须有一个唯一的序号，而且也许有多个在输送中的未确认报文
2，协议的发送方和接收方两端不得不缓存多个分组，发送方最低限度应当缓存那些已经发送但没有确认的分组，接收方也许需要缓存那些已经正确接收的分组
3，所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失，损坏及时延过大的分组，解决流水线的差错恢复有两种基本方法：回退N步和选择重传

3.4.3 回退N步 GBN

在回退N步 GBN协议中，允许发送方选择多个分组而不需要等待确认，但它也受限于流水线中未确认的分组数不能超过某个最大允许数N

下图中，base定义为最早未确认分组的序号，nextseqnum定义为最小的未使用序号，[0, base-1]段内的序号对应已经发送并被确认的分组，[base-1, nextsequnm-1]段内对应已经发送但未被确认的分组，[nextsequnm, base+N-1]段内的序号用于将要发送的分组。如果大于或等于base+N的序号是不能使用的，直到当前流水线中未被确认的分组已经得到确认为止

那些已经发送但还未被确认的分组的许可序号范围可以被看成一个在序号范围内长度为N的窗口，随着协议的运行，该窗口在序号空间向前滑动，因此，N常被称为窗口长度，GBN协议也常被称为滑动窗口协议

GBN发送方必须响应三种类型的事件：
1，上层的调用：当上层调用时，发送方首先检查发送窗口是否已满(是否已经有N个已经发送但未被确认的分组)，如果窗口未满，则产生一个分组并将其发送，并相应的更新变量。如果窗口已满，发送方只需将窗口返回上层，隐式的指示当前窗口已满。在实际实现中，发送方更可能缓存这些数据，或者使用同步机制允许上层仅当窗口不满时才可调用
2，收到一个ACK：在GBN协议中，对序号未n的分组的确认采取累积确认的方式，表明接收方已正确接收到序号为n的以前的所有分组
3，超时事件：协议的名字‘回退N步’来源于出现丢失和时延过长分组时发送方的行为。就像在停等协议中，定时器将再次用来恢复数据或确认分组的丢失，如果出现超时，发送方重传所有已经发送但未被确认过的分组

在GBN中，如果一个序号为n的分组被正确接收到，并且按序(上次交付给上层的数据序号是n-1)，则接收方为分组n发送一个ACK，并将该分组中的数据交付给上层。在所有其它情况下，接收方丢弃该分组，并为最近按序交付的分组重新发送ACK，注意到因为一次交付给上层一个分组，如果分组n已经接收并交付，那么所有序号比n小的分组也已经交付，使用累积确认是GBN一个自然的选择

在GBN协议中，接收方丢弃所有的失序分组，接收方必须按序将数据交给上层。发送方必须维护窗口的上下边界及nextseqnum在该窗口中的位置，但是接收方需要维护的唯一信息就是下一个按序接收的分组的序号

如发送方发送序号为0-3的三个分组，然后在继续发送之前，必须等待一个或多个分组被确认，每接收一个或多个ACK时，窗口向前滑动，发送方便可以发送新的分组。在接收方如果分组2丢失，分组3，4，5被发现是失序分组并被丢弃

3.4.4 选择重传 SR

GBN协议潜在地允许发送方用多个分组‘填充流水线’，因此避免了停等协议中所提到地信道利用率问题。然而GBN也有一些问题，当窗口长度过长和带宽时延丢很大时(流水线中有很多分组更是如此)，单个分组地差错就会引起GBN重传大量分组，许多分组没有必要重传，随着信道差错率地提升，流水线可能会被这些不必要重传地分组所充斥

通过选择重传 SR，协议通过让发送方仅重传那些它怀疑在接收方出差错(丢失或损坏)的分组而避免了不必要的重传。这种个别的，按需的重传要求接收方逐个地确认正确接收地分组。再次用窗口长度N限制流水线中未完成地，未被确认的分组数，然而与GBN不同的是，发送方已经接收到了对窗口中某些分组的ACK

3.5 面向连接的运输：TCP

TCP是因特网运输层的面向连接的可靠的运输协议，其中包括差错检查，重传，累积确认，定时器，以及用于序号和确认号的首部字母段

3.5.1 TCP连接

TCP的连接的组成包括：一台主机上的缓存，变量与进程连接的套接字，以及另一台主机上的另一组缓存，变量和与进程连接的套接字，这两台主机间的网络元素(路由器，交换机，中继器)，没有为该连接分配任何缓存和变量

TCP被称为面向连接的，这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先相互‘握手’，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数，作为TCP连接建立的一部分，连接的双方都将初始化与TCP连接相关的许多TCP状态变量

TCP连接不是物理上，而是一条逻辑连接，其共同状态仅保留在两个通信端系统的TCP程序中，由于TCP协议只在端系统中运行，而不在中间的网络元素(路由器和链路层交换机)中运行，所以中间的网络元素不会维持TCP的连接状态。事实上，中间路由器对TCP连接完全视而不见，它们看到的是数据报，而不是连接

TCP连接提供的是全双工服务，进程A和进程B可以同时双向交流，TCP连接也是点对点的，是在单个发送方和单个接收方间的连接。发起连接的叫客户进程，另一个则叫服务器进程，该客户进程首先要通知客户运输层，它想与服务器上的一个进程建立一条连接。

客户首先发送一个特殊的TCP报文段，服务器用另一个特殊的TCP报文段来响应，最后客户再用第三个特殊报文段作为响应，前两个报文段不承载有效载荷，也就是不包含应用层数据，而第三个报文段可以承载有效载荷。由于在这两个主机间发送了3个报文段，所以这个建立连接的过程通常被称为三次握手

一旦建立起一条TCP连接，两个应用进程之间就可以互相发送数据了，客户进程通过套接字传递数据流，数据一旦通过套接字，他就由客户主机中运行的TCP控制了。TCP将这些数据引导至该连接的发送缓存，发送缓存是三次握手期间设置的缓存之一，接下来TCP就会不时从发送缓存中取出一块数据，并将数据传递到网络层。

TCP可以从缓存中取出并放入报文段中的数据量受限于最大报文段长度 MSS,MSS 通常根据最初确定的由本地发送主机发送的最大链路层长度(即最大存储单元 MTU)来设置，MSS的典型值为1460字节，MSS是指在报文段里应用层数据的最大长度，而不是包括首部的TCP报文段的最大长度

TCP为每块客户数据配上一个TCP首部，从而形成多个TCP报文段，这些报文段被下传给网络层，网络层将其分别封装在网络层IP数据报中，然后这些IP数据包被发送到网络中，当TCP在另一端收到一个报文后，应用程序从此缓存中读取数据流，该连接的每一端都有各自的发送缓存和接收缓存

3.5.2 TCP报文段结构

TCP报文段结构图：

TCP报文段由首部字段和一个数据字段组成，数据字段包含一块应用程序
首部字段包括源端口号和目的端口号用来进行多路复用/分解来自或送到上层应用的数据，除了这两个端口,TCP报文段还包括：
32比特的 序号字段 和 32比特的 确认号字段：这些字段被TCP发送方和接收方用来实现可靠数据传输服务
16比特的 接收窗口字段：该字段用于流量控制，指示接收方愿意接收的字节数量
4比特的 首部长度字段：该字段指示了以32比特的字节为单位的TCP首部长度字段，由于TCP选项字段的原因，TCP首部的长度是可变的
可选与变长的 选项字段：该字段用于发送方和接收方协商最大报文段长度MSS时，或在高速网络环境下作用窗口调节因子使用
6比特的 标志字段：ACK比特用于指示确认字段中的值是有效的，RST，SYN，FIN比特将用于连接的建立和拆除，CWR和ECE比特用于明确拥塞通告，PSH比特被置位时，就指示接收方立即将数据交给上层，UGR比特用于指示报文段里存在着被发送端的上层实体位置为‘紧急’的数据

序号和确认号：TCP报文段首部中最重要的两个字段是序号字段和确认号字段，这两个字段是TCP可以提供可靠数据传输服务的关键。
TCP把数据看成一个无结构的，有序的字节流，序号建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。一个报文段的序号因此是该报文段首字节的字节流编号

序号：假设主机A向主机B发送一个500000字节的文件，其MSS为1000字节，A中的TCP隐式的对数据流中每个字节编号，将数据流构建成500个报文段，每个报文段1000字节，TCP给第一个报文段分配序号0，给第二个报文段分配序号1000，依次类推，每一个序号被填入到相应TCP报文段首部的序号字段中

确认号：由于TCP是全双工的，A向B发送数据的同时，B也可能向A发送数据，从主机B到达的每一个报文段中都有一个序号用于从B流向A的数据
A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号
假设主机A已经收到了来自B的编号为0~535的所有字节，同时假设它打算发送一个报文段给主机B，主机A等待主机B的数据流中字节536及之后的所有字节，所以主机A就会在它发往主机B的报文段的确认号字段上填上536

Telent 序号和确认的一个例子：Telent是一个用于远程登录的流行应用层协议，它运行在TCP上，被设计成可以在任意一对主机间工作。但许多用户现在更愿意使用SSH协议而不是Telent，因为在Telent连接中所发送的数据(包括口令)是没有加密的，使得Telent容易受到窃听

一个报文段的序号就是该报文段数据首字节的序号，确认号就是主机正在等待的数据的下一个字节序号

3.5.3 往返时间的估计与超时

TCP采用超时/重传机制来处理报文段的丢失问题，但最为明显的就是一个问题就是超时间隔长度的设置，显然超时间隔必须要大于该连接的往返时间(RTT,从一个报文段发出到它被确认的时间)，否则会造成不必要的重传

估计往返时间：
报文段的样本RTT 即SampleRTT，是从某报文段被发出(交给IP)到对该报文段的确认被收到之间的时间量

TCP维持一个SampleRTT的均值即*EstimatedRTT，EstimatedRTT是一个SampleRTT的加权平均值

RTT偏差DevRTT，用于估算SampleRTT一般会偏离EstimatedRTT的程度

设置和管理重传超时间隔：假设已经给出了EstimatedRTT和DevRTT，那么超时间隔应该大于EstimatedRTT，否则会进行不必要的重传，但也不可以比EstimatedRTT大太多，否则报文段丢失时，TCP不能很快的重传该报文段，导致数据传输时延大
所以采用：TimeoutInterval = EstimatedRTT + 4*DevRTT

3.5.4 可靠数据传输

因特网的网络层服务(IP服务)是不可靠的，IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性，由于运输层报文段是被IP地址数据报携带着在网络中传输的，所以运输层的报文段也会遇到这些问题。由于TCP的可靠数据传输服务确保了一个进程从其接收方缓存中读出的数据流是无损坏，无间隙，非冗余和按序的数据流，即该字节流与连接在另一方端系统发送出的字节流是完全相同的

TCP使用超时/重传机制，使用到了计时器，但计时器的管理却需要很大的开销，因此，推荐的定时器管理过程仅使用单一的重传计时器

TCP发送方有三个与发送和重传有关的重要事件：
1，TCP从应用程序接收数据，将数据封装在一个报文段中，并把该报文段交给IP，如果定时器还没有为某些其它报文段而运行，则当报文段被传给IP时，TCP就启动该定时器
2，超时，TCP通过重传引起超时的报文段来响应超时事件，然后TCP重启定时器
3，收到一个来自接收方的ACK，比较ACK和TCP状态变量的值，确认是否重启定时器

一些有趣的情况：
1，主机A向主机B发送报文段，但从主机B发向主机A的ACK丢了，在这种情况下，超时事件就会发生，主机A会重传相同的报文段，而当主机B收到该重传的报文段时，它将通过序号辨别出它已经接收到过相同的数据，因此主机B将丢弃该重传的报文段中的这些字节
2，当主机A连续发送两个报文段时，第一个报文段序号是92包含8字节数据，第二个报文段序号是100包含20字节数据，当它们完好的到达主机B时，主机B为每个报文段发送一个ACK，第一个ACK的确认号是100，第二个ACK的确认号是120，假设在超时之前这两个ACK没有一个回到了A，当超时事件发生时，主机A重传序号为92的报文段，并重启计时器，只要第二个报文段的ACK在新的超时发生前到达，则第二个报文段就不会被重传
3，假设主机A与第二种情况一样，发送两个报文段。第一个报文段的ACK在网络中丢失，但在超时之前主机A收到一个确认号为120的ACK，主机A因而知道了主机B已经收到了序号119及之前的所有报文段，则主机A不会重传这两个报文段中的任何一个

超时间隔加倍：每当超时事件发生时，TCP重传具有最小序号的还未被确认的报文段，只是每次TCP重传都将下一次的超时间隔设置为先前值的两倍。这种修改提供了一个形式受限的拥塞控制，定时器过期很可能是由网络拥塞引起的，即太多的分组到达源与目的地之间路径上的一台(或多台)路由器的队列中，造成分组丢失或长时间的排队时延。在拥塞的时候，如果源持续重传分组，会使拥塞更严重。TCP使每个发送方的重传都是经过越来越长的时间间隔后进行的

冗余ACK：再次确认某个报文段的ACK，发送方先前已经接收到对该报文的确认

快速重传：超时触发重传的问题之一是超时周期可能相对较长，当一个报文段丢失时，这种长超时周期迫使发送方延迟重传丢失的分组，因而增加了端到端时延。发送方通常可以在超时事件发生前通过注意所谓冗余ACK来较好的检测到丢包情况。因为发送方经常一个接一个的发送大量的报文段，如果一个报文段丢失，就很可能引起许多一个接一个的冗余ACK，如果TCP发送方收到对相同数据的三个冗余ACK，它把这当作一种指示，说明这个报文段之后的报文段已经全部丢失。一旦收到三个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段

是回退N步还是选择重传：TCP看起来像一个GBN风格的协议，但是TCP和GBN协议有着一些显著的区别，许多TCP实现会将正确接收但失序的报文段缓存起来。对TCP提出的一种修改意见是所谓的选择确认，它允许TCP接收方有选择地确认失序报文段，而不是累积地确认最后一个正确接收的报文段。当将该机制与选择重传机制结合起来时，TCP更像SR协议
因此，TCP的差错恢复机制最好被分为GBN和SR协议的混合体

3.5.5 流量控制

一条TCP连接的每一侧主机都为该连接设置了接收缓存，当该TCP连接收到正确，按序的字节后，它就将数据放入接收缓存。但如果某应用程序读取数据时相对缓慢，而发送方发送的太多，太快，发送的数据会很容易使该连接的接收缓存溢出

流量控制服务：TCP为它的应用程序提供了流量控制服务以消除发送方使接收方缓存溢出的可能性。流量控制因此是一个速度匹配服务，即发送方的发送速率与接收方的应用程序的速率相匹配。TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制，接收窗口用于给发送方一个指示–接收方还有多少可用的缓存空间

TCP发送方也可能因为IP网络的拥塞而被遏制，即使流量控制和拥塞控制采取的行动非常相似(遏制发送方)，但是它们显然是针对完全不同的原因而采取的措施。UDP并不提供流量控制，报文段由于缓存溢出可能在接收方丢失

3.5.6 TCP连接管理

TCP的连接建立(三次握手)：客户应用进程首先通知客户TCP，它想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下的方式与服务器中的TCP建立一条TCP连接
第一步：客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段，该报文段中不包含应用层数据，但是该报文段首部中的SYN比特被置为1，该报文段会被封装到一个IP数据报中，并发送给服务器
第二步：一旦包含TCP SYN报文段的IP数据报到达服务器主机，服务器将会从该数据报中提取出TCP SYN报文段，为该TCP连接分配缓存和变量，并向该客户TCP发送允许连接的报文段，该报文段被称为SYNACK报文段
第三步：在收到SYNACK后，客户也要给该连接分配缓存和变量，客户主机则向服务器发送另一个报文段，这最后一个报文段对服务器的允许连接的报文段进行了确认，在第三步中，可以在报文段负载中携带客户到服务器的数据

一旦完成着三个步骤，客户和服务器主机就可以互相发送包括数据的报文段了，以后的每个报文段中，SYN比特被置0，这种连接创建被称为三次握手

TCP的连接关闭：当连接接收后，主机中的缓存和变量将被释放。客户应用进程发出一个关闭连接命令，这会引起客户TCP向服务器进程发送一个特殊的TCP报文段。最后，该客户对这个服务器的终止报文段进行确认，此时，在两台主机上用于该连接的所有资源都被释放，连接断开

3.6 拥塞控制原理

可靠数据传输服务中的丢包一般是当网络变得拥塞时由于路由器缓存溢出所引起的，分组重传因此作为网络拥塞的征兆，但却无法处理导致网络拥塞的原因，因为有太多的源想以过高的速率发送数据，为了处理网络拥塞原因，需要一些机制以在面临网络拥塞时遏制发送方

3.6.1 拥塞原因与代价

两个发送方和一台具有无穷大缓存的路由器：当分组的到达速率接近链路容量时，分组经理巨大的排队时延

两个发送方和一台具有有限缓存的路由器：发送方遇到大时延时所进行的不必要的重传会引起路由器利用其链路带宽来转发不必要的分组副本

四个发送方和具有有限缓存的多台路由器及多条路径：当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费了

3.6.2 拥塞控制方法

在最为宽泛的级别上，我们可以根据网络层是否为运输层拥塞控制提供了显示帮助，来区分拥塞控制方法
端到端拥塞控制：在端到端拥塞控制方法中，网络层没有为运输层拥塞控制提供显示支持，即使网络中存在拥塞，端系统也必须通过对网络行为的观察(如分组时延)来推断
网络辅助的拥塞控制：在网络辅助的拥塞控制中，路由器向发送方提供关于网络中拥塞状态的显示反馈信息，这种反馈可以简单地用一个比特来指示链路中地拥塞情况，拥塞信息从网络反馈到发送方有两种方式，1，经有接收方地网络反馈，2，直接网络反馈

3.7 TCP拥塞控制

TCP为运行在两个不同主机上地两个进程提供了可靠数据传输服务，TCP的另一个关键部分就是其拥塞控制机制。TCP必须使用端到端拥塞控制，因为IP层不能向端系统提供显示的网络拥塞反馈

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

TCP如何设置其发送速率：1，一个丢失的报文段意味着拥塞，因此当丢失包文段时应当降低TCP发送方的速率
2，一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此，当对先前未确认报文段的确认到达时，能够增加发送方的速率
3，带宽检测，给定ACK指示源到目的地路径无拥塞，则丢包事件表示路径拥塞，TCP调节其传输速率的策略是增加其速率影响到达的ACK，除非出现丢包事件，才减小传输速率

TCP拥塞控制算法：慢启动，拥塞避免，快速恢复，回顾，对TCP吞吐量的宏观描述，经高带宽路径的TCP