计算机网络原理-传输层

传输服务

传输层是整个协议层次结构的核心，传输层位于网络层和应用之间，在终端用户之间提供透明数据传输，向上层提供可靠的数据传输服务，如图所示。网络层是通信子网的最高层，但却无法保证通信子网或路由器提供的面向连接的服务可靠性，而在网络层之上的传输层正好可以解决这一问题，改善了传输质量。

传输层提供的服务

传输层的主要职责是向上层（应用层）提供有效、可靠的服务。

在源端和目的端之间跟踪独立地通信，每台主机同时可能有多个应用进程在通信。

传输层负责协调管理多进程之间的通信流，如果某台计算机正在发送电子邮件和浏览网站，那么传输层会跟踪各个进程会话，保证所有的应用程序能正确地被发送与接收，下图显示了客户传输层通信中的TCP请求。

分段和重组

应用程序由于要向传输层发送大量数据，考虑到信道带宽等因素，传输层必须将数据拆成小的分段，更适合传递。

由此可见，传输层必须为每段应用程序添加报头，关联显示相关通信。反之，若没有分段，那只能有一个应用程序被接受，如进行浏览网页时就不可以同时发送即时消息或观看视频。同时，由于分段过后的数据会经过不同的网络传输路径，数据的到达次序会混乱。通过编号及排序分段，目的端数据的每个分段必须按正确的顺序重组，然后对应相应的应用程序，下图显示了数据报分段的示意图。

• TCP报头包含源端口和目的端口信息、数据段接收确认信息、排序（以安排同一序列处理）信息、流量控制和拥塞控制信息；
• UDP报头包含源端口和目的端口信息。

端口寻址

端口就是传输层服务访问点TSAP，端口的作用就是让应用层的各种应用进程都能将其数据通过端口向下交付给传输层，以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。

为了区分网络应用程序，传输层将给应用程序提供端口，端口用一个16 bit端口号进行标识，每个需要访问的进程会被分配到一个且唯一的端口号，有效的端口号为0～65535。端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程，在因特网中不同计算机的相同端口号是没有联系的。

Internet编号指派机构（IANA）负责分配端口号，IANA组织是负责分配多种地址的标准化团体，端口号有以下三种类型。

• 公认端口（端口0～1023）：用于服务和应用程序，如HTTP、SMTP/POP3等。
• 已注册端口（端口1024～49151）：分配给用户进程，而不是分配给公认端口。
• 动态或私有端口（端口49152～65535）：也称临时端口。端口在应用程序一开始被动态分配给客户端应用，客户端很少使用动态或私有端口。
  
  
  

流量控制及错误恢复

网络内存及带宽是有限的，当传输层发现此类资源过载时就会利用某些传输层协议要求减小数据额流量，流量控制同时可以防止网络丢失分段及分段重传。当然，数据分段在网络中的分段很可能随时会发生错误或丢失，此时传输层能够通过重传保证所有数据的正确性和完整性。

面向连接／面向非连接服务

传输层根据各应用程序不同的协议分为面向连接和面向非连接的两种服务类型。

• 面向连接服务是当发送方必须与接收方进行连接时才进行数据传递，最后释放连接过程。
  • 传输层的TCP（传输控制协议）为面向连接的协议。
  • 提供了进程之间的可靠传递；
• 非连接的传输服务，发送方无须连接直接进行数据传递。
  • UDP（用户数据控制协议）为面向非连接的协议。
  • 提供进程之间高效的数据传递。

传输层通过在应用程序间建立一个会话，提供面向连接的定位服务，在传输数据之前，传输层连接准备好应用程序间的通信准备。这些应用程序通信的数据在会话中严格地被管理。

根据应用程序不同，传输层协议也各不相同。

例如，网页浏览或电子邮件发送要求确保接收和显示信息的完整性，因此即使速度较慢但是需要通过建立连接才进行数据传递。

当今越来越多的融合性网络，包括声音、视频、数据，在共同传输过程中，不同应用对传输层的协议的要求也各不相同。根据应用程序数据的开销、实时性等特征，在此基础上选择满足应用要求的传输协议。

netstat命令

netstat命令是一个非常实用的网络应用程序，可用来检验连网主机中开放并运行了哪些活动的TCP连接。

netstat命令列出正在使用的协议、本地地址和端口号、外部地址和端口号以及连接的状态。用户可通过检验TCP连接来防范非法TCP连接耗尽网络资源，降低主机的性能。若突然性能下降，可以通过netstat命令来检查主机开放的连接。

传输控制协议（TCP）

传输控制协议（Transmission Control Protocol，TCP）是TCP/IP体系结构中的传输层协议，是面向连接的，用于管理多个应用程序的通信，根据各协议的特点为应用程序提供可靠的全双工数据通信。

TCP协议特点

TCP提供一种面向连接的、全双工的、可靠的字节流服务，具有以下的特点：

• 面向连接的传输，传输数据前需要先建立连接，数据传递完毕后要释放连接；
• 支持端到端通信，不支持广播通信；
• 高可靠性，确保数据传输的正确性，不会出现乱序或丢失；
• 以全双工方式实现数据传输；
• 以字节为单位进行数据传输，若数据过长会将其进行分段传输；
• 提供紧急数据传递功能，需要紧急数据发送时会立即进行进程发送，目的端会暂停当前数据，先进行紧急数据的接受处理。

TCP的段结构

由于TCP应用于大量数据传递的情况，所以对长数据流会进行分段。

在TCP的段结构中，是以“端口”来表示地址的。

• 源端口：16比特，发送方进程端口。
• 目的端口：16比特，接收方进程端口。
• 序列号：32比特。TCP对字节进行编号，例如，某数据段包括2 000字节，若第一个字节编号号为1的话，则下一个数据段字节的序列号为1+2000=2001。
• 确认号：32比特，是准备接收的字节序列号，表示该序列号之前的字节都已正确接收。
• 报头长度：4比特，可随可选项的长度而变化，接收方根据该数据确定TCP的数据起始位置。
• 代码位：6比特，该字段包含对其他字段的说明或对控制功能的标志，常用代码位如下所述。
• URG：紧急比特。当此位设置为1时，表明此报文段中含由发送端应用进程标出的紧急数据，同时用“紧急指针”字段指出紧急数据的末字节。TCP必须通告接收方的应用进程“紧急数据”，并将“紧急指针”传送给应用进程。
• ACK：确认字段（Acknowledgement Number）。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号（X+1，Figure：1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
• PSH：推送功能。在进行 Telnet 或 Rlogin 等交互模式的连接时，该标志总是置位的。该标志置位，数据将尽快交于应用处理。
• RST：重置连接。用于复位相应的TCP连接，当通信过程中出现严重错误时，进行通信的两台主机任意一方发送RST位设置为1的报文段用于终止连接。
• SYN：同步序列号（Synchronize Sequence Numbers）。该标志仅在三次握手建立TCP连接时有效。它负责TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端的初始序列编号。通过 TCP 连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一字节的序列编号。
• FIN：发送方已传输完所有数据。带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。服务端处于监听状态，客户端用于建立连接请求的数据包（IP packet）按照TCP/IP协议堆栈组合成TCP处理的分段（Segment）。

TCP连接管理

应用程序进程都是在服务器上进行的，服务器上运行的每个应用进程都分配了一个相应的端口号，这本由系统默认分配或者系统管理员手工分配。当某动态应用程序“开启”端口时，应用层将接收并处理该端口的数据段，一个服务器可以根据开启的多个不同端口对应多个应用程序。当然，服务器必须只允许授权请求者访问与服务于应用程序的相关端口。

三次握手建立连接

两台主机采用TCP进行通信，交换数据之前需要先建立连接，通信完毕后，将关闭会话并结束连接。
由此可见，连接和会话机制保障了TCP的可靠性。
TCP连接的建立采用三次握手机制，具体实现过程为：数据发送方向数据接收方发送请求，数据接收方回应对连接请求的确认段，数据发送方再发送对对方确认段的确认，其过程如图所示。

在上图所示TCP连接中，A向B发起会话，创建连接过程三个步骤如下所述。

• A向B发送包含初始序列SYN标志数据段，开启连接会话。如图所示，在T1时刻，A向另一端B请求建立连接，序列号为X。
• 在T2时刻，B发送包含确认值SYN+ACK的数据段，值为A的序列号X值加1，并产生其自身的同步序列值Y。
• 在T3时刻，A发送带确认值的ACK响应，发送值等于B的序列号Y加1。由此连接结束。
  通过三次握手，连接建立成功。三次握手机制通过请求、响应、确立保证了连接的顺利完成，接下来A、B分别发送数据段。
  为了清楚了解TCP三次握手过程，搭建如下图所示的TCP实验拓扑。
  
  配置好基本信息，将Packet Tracer模拟器切换到Simulation模式，打开主机Web Browser，输入IP192.168.1.2，观察结果。因为HTTP服务是基于TCP协议的，所以当申请网页前会建立TCP连接，下图所示为主机发送的第一次握手的TCP请求。
  
  从数据包中看出，HTTP使用TCP端口号80，序列号为0，此时客户第一次发送TCP连接请求，应答号是0，同时SYN同步比特应该是1。下图所示为第二次握手的TCP响应。
  
  从数据包中可知，服务器第一次发送响应，序列号为0，应答号为1，同时发送SYN+ACK。
  下图所示为第三次握手的TCP确认。
  
  此时客户端第二次发送数据报序列号为1，应答号为1，同时发送ACK。三次握手建立连接后可以发送HTTP请求申请网页文件。

TCP连接释放

在数据传输结束后，通信的双方都可以发出释放连接的请求。

TCP连接释放采用文雅释放过程，TCP连接的释放是两个方向分别释放连接，每个方向上连接的释放，只终止本方向的数据传输。

当一个方向的连接释放后，TCP的连接就称为“半连接”或“半关闭”；当两个方向的连接都已释放后，TCP连接才完全释放，下图显示了TCP连接的释放过程。

由图可知，两端数据通信选择双工通信，双方必须等数据库都发送完毕才终止连接，所以，TCP连接释放采用对称释放方式，其释放过程如下所述。

• 在T1时刻，A收到应用层的终止请求，发送带释放标志FIN的连接段。
• 在T2时刻，B收到A发送的释放请求并发送ACK应答段，确认收到并通知应用层A已结束数据发送请求释放。
• B在T3时刻收到无数据传输的通知，并向A发送带释放标志FIN的连接段。
• 在T4时刻，A收到B的释放连接信息，A向B发送ACK应答段，确认释放并中断连接。
• 在T5时刻B收到A的确认信息，释放连接。

TCP数据传输机制

TCP滑动窗口

TCP采用滑动窗口控制管理数据队列发送，发送数据方不需要在应用层开始发送数据时就立刻发送数据，可以等待数据累积到一定数量后一并发送；接收方同样也可以等待接收的数据达到一定数量后一起发送确认。

滑动窗口顾名思义是指接收窗口的大小可以随着已经接收的数据量变化，在TCP 会话中，窗口大小是动态协商的。

滑动窗口是一种数据流控制机制，允许发送端在向目标端发送一定数量的数据之后接收一个确认滑动窗口协议，是TCP使用的一种流量控制方法。

TCP允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不需要每次发一个分组就停下来等待确认，因此TCP可以加速数据的传输。

收发两端的窗口不断滑动，因此这种协议又称为滑动窗口协议。

滑动窗口协议的基本原理就是在任何时刻，发送方都能发送连续帧数据段，称为发送窗口；同时，接收方也可以连续接收多个帧数据段，称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送但是还没有被确认的帧，或者是那些可以被发送的帧。

如图所示，假定数据接收方有2 048字节的缓冲区。此处有三种标志要介绍：ACK为确认标志；WIN为可以接收的窗口大小；SEQ是发送数据段的起始字节号，称为序列器。

• 在T1时刻，发送方的应用层有1024字节的数据，发送方将数据段的起始序号设为0。
• 在T2时刻，接收方收到发送方的数据段后并不立刻提交给应用层，缓冲区还有1 024字节空闲，接收方发送ACK=1 024，WIN=1 024。
• 在T3时刻，若发送方应用层有2 KB数据发送，但接收方的缓冲空闲只有1 KB数据，因此发送方将1 KB数据发送，SEQ=1 024。（注释：1 KB=1 024字节）
• 在 T4时刻，接收方完成数据接收发现缓冲区被占满，接收方向发送方发确认段，ACK=2 048，WIN=0。
• 在T5时刻，接收方向应用层提交数据段，缓冲区释放1 KB，接收方向发送方发送确认段。借此发送方知道现在接收方有1 KB空闲缓冲区。
  
• 在T6时刻，发送方将刚才剩下的没发完的1 KB发送。发送完发现还有1 KB空闲缓冲区。

TCP重传策略

TCP协议提供了管理数据段丢失的方法，当数据在传输过程中发送丢失时，TCP设计一种方法就是重新发送未确认的数据段，下图所示为数据发送常见情况。

重传的基本是设立重传定时器，该定时器在开始发送数据的同时被启动，如果在定时器超时前收到确认数据段，定时器将被关闭，否则，就重传数据段。

大部分情况下，TCP只确认相邻序列的数据段。当一个或多个数据段丢失时，只有确认已传输完成的数据段。例如，当接收序列号为1200到2000和3000到4000的数据段，那确认号为1201。中间空白的数据段被认为没有收到。

重传策略的关键就是对定时器的设定。影响超时重传机制协议效率的一个关键参数是重传超时时间（Retransmission TimeOut，RTO）。

RTO的值设置得过大过小都会对协议造成不利影响。如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失，降低了连接数据传输的吞吐量；另一方面，若RTO过小，发送端尽管可以很快检测出报文段的丢失，但也可能将一些延迟大的报文段误认为是丢失，造成不必要的重传，浪费了网络资源。

因此，从上面看来，若在建立连接前，首先设计两点间的传输往返时间（Round Trip Time，RTT），则可根据RTT来设置一合适的RTO。显然，在任何时刻连接的RTT都是随机的，无法预先知道。TCP可以通过测量来获取当前RTT的一个估计值，并以该RTT估计值为基准来设置当前的RTO。自适应重传算法的关键就在于对当前RTT的准确估计，以便适时调整RTO。

TCP拥塞控制

无论网络设计多优秀，网络资源都会有耗尽导致网络拥塞的可能。

网络资源一般包括网络带宽、节点的缓存或处理机等。在某一时刻，网络资源的需求过载，超过可用范围，那么网络性能就会变坏，造成网络拥塞。

在Internet网中，拥塞控制主要是由TCP完成的。控制拥塞的有效方法很多，其中最常用的有效方法就是降低数据传输速率。

早期的TCP协议只有基于窗口的流控制（Flow Control）机制而没有拥塞控制机制，因而易导致网络拥塞。流量控制功能通过调整会话过程中两个服务之间的数据流速率，以保证TCP的可靠性。当发送方被通知已收到的数据段中指定数量的数据时，它就可以继续发送更多的数据。

1988年Jacobson针对TCP在网络拥塞控制方面的不足，提出了“慢启动”（Slow Start）等算法。
慢启动“Slow Start”：
TCP在连接建立成功后在网络中产生大量数据包，由此网络中设备缓存会被耗尽，很容易发生网络拥塞。

所以新建立的连接并不在一开始就大量发送数据包，而是根据网络情况逐步增加每次发送的数据量，这样能够避免网络拥塞。

网络拥塞窗口（CWND）在新建立连接时，初始化为1个最大报文段（MSS）大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认时，CWND就增加1个MSS大小。CWND随着网络往返时间（Round Trip Time，RTT）呈指数级增长，本质上慢启动发送起点较低，之后发送速度一点也不慢。在开始时，CWND值为1；经过1个RTT后，CWND值为1×2=2；经过2个RTT后，CWND值为2×2=4。如果带宽为W，那么经过RTT×lg2W时间就可以占满带宽。当然CWND也不能一直这样增长下去，一定需要某些限制。TCP使用慢启动门限（ssthresh）变量，当CWND超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65 536（同样以字节计算）。拥塞避免的主要思想是加法增大，也就是CWND的值不再指数级往上升，转而利用增加值，此时当窗口中所有的报文段都被确认时，CWND 的大小加1，CWND的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢地增加调整到网络的最佳值，下图显示了慢启动的拥塞指数。

用户数据报协议（UDP）

根据RFC768，用户数据报传输协议（UDP）提供了无连接的数据报服务。

UDP（User Datagram Protocol，用户数据报协议）是OSI（Open System Interconnection，开放式系统互联）参考模型中的一种无连接传输层协议，提供面向事务的简单不可靠信息传送服务，UDP采用“尽力”方式传送数据报。

UDP服务模型

UDP提供的服务主要有以下几种特征。

• 传输数据前无须连接，应用进程可以直接进行数据报发送。
• 不对数据报进行检查与修改。
• 无须等待对方确认。
• 效率高，实效性好。
  根据以上特征，UDP 数据报在发送过程中可能会出现丢失、乱序等情况，它应用于传送数量较少或者无须应答的进程中。

当然，UDP也避免了建立和释放连接段麻烦。例如，像DNS这样的应用，如果收不到应答，它就再次发出请求，因此不需要TCP的可靠性。另外，使用UDP协议的应用还包括视频流和IP语音等。

UDP的段结构

UDP是面向无连接的，它的格式与TCP相比少了很多字段，也简单了很多。

用户数据报协议由数据和首部两部分组成。UDP的首部只有8字节，共4段，格式如图所示。

UDP功能简单，它的段结构如上图所示，各段结构的含义如下所述。

• 源端口：16比特，表明发送端地址。
• 目的端口：16比特，表明接收端地址。
• 长度：16比特，表明包括UDP头在内的数据段的总长度。
• 校验和：16比特，该字段可选，不用时可置0。

UDP数据报重组

由于UDP是无连接协议，因此在通信发生之前不会进行会话。也就是说，UDP是一旦应用程序有数据发送就直接发送。

根据UDP的特点，一般UDP发送的数据段比较小，但是也会有需要分段数据的情况。UDP的数据协议单元（PDU）实际意义就是发送数据报。

当多个数据发送到目的主机时，它们可能使用不同的路径，到达顺序也可能跟发送时的数据不同。

UDP不会对数据报进行重组，因此也不会将数据恢复原先的顺序。所以，UDP只按数据的先来后到转发给应用程序。如果对数据顺序有要求，那么应用程序只能自己标志数据的正确顺序，并按次序去处理数据，下图显示了UDP用户数据报重组的过程。

UDP的服务器进程与请求

基于UDP的服务器应用程序和TCP一样也被分配了公认端口或已注册的端口。当基于UDP协议的应用程序或进程运行时，它们就会接收与所分配端口相匹配的数据；当UDP收到用于某个端口的数据报时，它就会按照应用程序的端口号将数据发送到相应的应用程序。

UDP客户端进程

TCP使用客户端／服务器模式通信，初始化采用由客户端应用程序向服务器进程请求数据的形式；UDP客户端进程则是从动态可用端口中随机挑选一个端口号，用来作为会话的源端口，而目的端口通常都是分配给服务器进程的公认端口或已注册的端口。客户端选择源端口和目的端口，通信事务中的所有数据报文头都采用固定的端口对，对于从服务器到达客户端的数据来说，数据报头所含的源端口和目的端口进行了互换。
为了查看UDP报文结构，搭建如图所示拓扑验证DNS服务如何使用UDP协议。将Packet Tracer模拟器切换到Simulation模式，客户端在浏览器中输入WWW.CISCO.COM，访问Cisco网站页面，首先DNS服务器会根据域名找到相关的服务器IP地址所在位置。

如图所示，分析DNS服务器收到的DNS数据报，客户端自选随机源端口1025，目的端口使用DNS服务器的公认端口53。

详细的UDP数据报格式如图所示：

由此可见，UDP数据报源端口是客户端随机自选的，目的端口使用服务公认端口。这样做的目的很明显安全性能比较高。如果目的端口的选择方式容易预测，那么网络入侵者很容易就可以通过尝试最可能开放的端口号访问客户端。由于UDP不建立会话，因此一旦数据和端口号准备就绪，UDP就可以生成数据报并递交给网络层，同时在网络上寻址和发送。