（4）运输层

4.1 运输层概述

4.1.1 进程间基于网络的通信

物理层、数据链路层和网络层共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。------>实际上，计算机网络中通信的真正实体是位于通信两端主机中的进程。

如何为运行在不同的主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

注意：这里的端口并不是指看得见、摸得着的物理端口，而是指用来区分不同应用进程的标识符。

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑，所采用的路由选择协议等），它使应用进程看见的就是在两个运输层实体之间有一条端到端的逻辑通信。

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP。

4.1.2 运输层的两个重要协议

4.1.3 运输层端口号、复用和分用的概念

端口号

运行在计算机上的进程使用进程标识符PID来标志。

------>因特网的计算机不是使用统一的操作系统，不同的操作系统使用不同格式的进程标识符。

------>为了使运行不同的操作系统的计算机的应用进程之间能够进行网络通信，必须使用统一的方法对TCP/IP体系的应用进程来进行标识。

------>TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。 端口号使用16比特表示，取值范围为0~65535

1. 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如：FTP使用21/20，HTTP使用80，DNS使用53.

2. 登记端口号：1024~49151，为没有熟知端口号的应用程序使用，必须在IANA按照规定登记，防止重复，如Microsoft RDP微软远程桌面使用的端口是3389.

3. 短暂端口号：49152~65535，留给客户进程选择暂时使用，当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号，通信结束后，这个端口可供其他进程使用。

端口号只具有本地意义，即端口号只是为了标识本计算机应用层的各进程，在因特网中，不同的计算机中的相同端口号是没有联系的。

发送方的复用和接收方的分用

4.2 UDP和TCP的对比

用户数据报协议 ------> UDP

-->面向无连接的

-->支持单播、多播、广播

-->面向应用报文的

-->UDP向上层提供无连接不可靠的传输服务，适用于IP电话、视频会议等实时应用

-->UDP用户数据报首部仅8字节

传输控制协议 ------> TCP

-->面向连接的

-->仅支持单播

-->面向字节流的

-->TCP向上层提供面向连接的可靠传输服务，适用于要求可靠传输的应用，例如文件传输

-->TCP报文段首部最小20字节，最大60字节（用于流量控制，拥塞控制）

4.3 传输控制协议TCP

4.3.1 TCP的流量控制

流量控制 -->让发送方的发送速率不要太快，要让接收方来得及接收。

滑动窗口技术

TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小

TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

4.3.2 TCP的拥塞控制

拥塞 -->在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况叫做拥塞。

在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等，都是网络的资源。

若出现拥塞不控制，整个网络的吞吐量将随输入负荷的增大而下降。

四种拥塞控制算法

1. 慢开始

   慢开始是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢

   
   重传计时器超时 ------>判断网络可能出现了拥塞，进行以下工作：

   将ssthresh值更新为发生拥塞时cwnd值的一半

   将cwnd值减少为1，并重新开始执行慢开始算法

2. 拥塞避免

   拥塞避免并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为线性规律增长，使网络比较不容易出现拥塞。

慢开始和拥塞控制是1988年提出的（TCP Tahoe版本）

------>存在问题

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。这将导致发送方超时重传，并误以为网络发生了拥塞，发送方把拥塞窗口cwnd又设置为最小值1，并启动慢开始算法，降低了传输效率。

快重传和快恢复是1990年提出的（TCP Reno版本）

1. 快重传

   所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。

   要求接收方不要等待自己发送数据时才进行捎带确认，而是立即发送确认
   即使收到了失序报文段也要立即发出对已收到的报文段的重复确认。

   如1，2号报文段收到了，但是3号报文段因丢失而没收到，接着收到了4号报文段，则接下来重复确认2号报文段。

   发送方一旦收到三个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。

   对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现拥塞，可以使网络吞吐量提高约20%。

   ------>发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段，于是不启动慢开始算法，而执行快恢复算法。

2. 快恢复

   发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。

   也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3。
   既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；

   这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；

   可见现在网络中不是堆积了报文段而是减少了3个报文段，因此可以适当把拥塞窗口扩大些。

4.3.3 TCP超时重传时间的选择

不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO

利用每次测量得到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）

RTTs1 = RTT1

新的RTTs = (1-alpha) * 旧的RTTs + alpha * 新的RTT样本（0<=alpha<1）

若alpha很接近于0，则新的RTT样本对RTTs的影响不大；

若alpha很接近于1，则新的RTT样本对RTTs的影响较大；

已成为建议标准的RFC6298推荐的alpha值为1/8，即0.125。

用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。

显然，超时重传时间RTO应略大于加权平均往返时间RTTs。

RFC6298建议使用下式计算超时重传时间RTO： RTO = RTTs + 4 * RTTD

1. RTTs为加权平均往返时间

2. RTTD为RTT偏差的加权平均

   当测量到第一个样本时，RTTD的值取该样本值一半：RTTD = RTT1 / 2
   以后，每测量一个样本时，按以下公式计算新的RTTD：

   新的RTTD = (1-beta) * 旧的RTTD + beta * |RTTs - 新的 RTT 样本|

   0<= beta < 1

   已成为建议标准的RFC6298推荐的beta值为1/4，即0.25。

往返时间RTT的测量比较复杂

------>针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是说，出现重传时，不重新计算RTTs，进而超时重传时间RTO也不好重新计算。

------>新的问题：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。

------>对Karn算法进行修正：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

4.3.4 TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输。

对按序到达的最高报文段进行确认。

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。

网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。

发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

对于不按序到达的数据应如何处理，TCP并无明确规定。

如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。

TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自已有数据要发送时把确认信息顺便捎带上。 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传。

TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]

捎带确认实际并不经常发生。

TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

4.3.5 TCP的运输连接管理

TCP的运输连接管理就是使运输连接的建立和释放都能正常进行。

TCP 的连接建立 连接建立要解决的三个问题：

使TCP双方能够确知对方的存在；

使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；

使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

采用三报文而不是二报文？

为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误。

TCP 的连接释放

保活计时器

TCP双方已建立了连接 ------>TCP客户进程所在的主机突然出现了故障 ------>TCP服务器进程就不能再收到TCP客户进程发来的数据 ------>TCP服务器进程该如何发现这个情况而不要等待下去呢？

------>TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器(2小时定时)

------>若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后每隔75秒就发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器就认为TCP客户进程所在主机出现了故障，就关闭这个连接。

4.3.6 TCP报文段的首部格式

为了实现可靠传输，TCP采用了面向字节流的方式。

但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。

1. 一个TCP报文段由首部和数据载荷两部分构成；

2. TCP的全部功能都体现在它首部中各字段的作用。