计算机网络——运输层

本章重点

1、运输层为相互通信的应用进程提供逻辑通信
2、端口和套接字的意义
3、无连接的 UDP的特点
4、面向连接的 TCP的特点
5、在不可靠的网络上实现可靠传输的工作原理，停止等待协议和 ARQ协议
6、TCP的滑动窗口、流量控制、拥塞控制和连接管理

一、运输层协议概述

1.1进程之间的通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，也是用户功能中的最底层
从运输层的角度看，通信的端点并不是主机而是主机中的进程
真正进行通信的实体是在主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换数据
IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程
一个主机中经常有多个应用进程同时分别和另一个主机中的多个应用进程通信
运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就像是在两个运输层实体之间有一条端到端的逻辑通信信道

当运输层采用面向连接的 TCP协议时，尽管下面的网络是不可靠的，这种逻辑信道仍相当于一条全双工的可靠信道
当运输层采用无连接的 UDP协议时，这种逻辑信道仍是一条不可靠信道

1.2运输层的两个主要协议

用户数据报协议 UDP，传输控制协议 TCP

按照 OSI术语，两个对等运输实体在通信时传送的数据单位叫运输协议数据单元 TPDU；在 TCP/IP体系中根据使用的协议是 TCP或 UDP分别叫做 TCP报文段或 UDP用户数据报

UDP在传送数据之前不需要先建立连接，远地主机的运输层在收到 UDP报文后不需要给出确认
TCP提供面向连接的服务，传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务

1.3运输层的端口

运输层具有复用和分用的功能
复用：应用层所有的应用进程都可以通过运输层再传送到 IP层
分用：运输层从 IP层收到发送给各应用进程的数据后，必须分别交付知名的各应用进程

为了使发送方识别对方机器上的进程，需要在运输层使用协议端口号。通信的终点是应用进程，把所传送的报文交到目的主机的某个合适的目的端口，剩下的工作（最后交付目的进程）由 TCP或 UDP完成
在协议栈层间的抽象的协议端口是软件端口。硬件端口是不同硬件设备进行交互的接口，软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址
互联网上的计算机通信是采用客户-服务器方式，客户在发起通信请求时，必须先知道对方服务器的 IP地址和端口号

1. 服务器端使用的端口号：分为熟知端口号（数值0~1023）和登记端口号（数值1024~49151）
2. 客户端使用的端口号：数值49152 ~ 65535。仅在客户进程运行时才动态选择，通信结束后，刚才已使用过的客户端口号就不复存在

二、用户数据报协议 UDP

2.1 UDP概述

用户数据报协议 UDP只是在 IP的数据报服务上增加一点功能，即服用、分用和差错检测
特点：尽最大努力交付（不保证可靠传输），面向报文，没有拥塞控制，支持一对一、一对多、多对一、多对多的交互通信，首部开销小

2.2 UDP的首部格式

当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的终点——应用进程

如果接收方 UDP发现收到的报文中的目的端口号不正确（不存在对应于该端口号的应用进程）就丢弃该报文，并由网际控制报文协议 ICMP发送“端口不可达”差错报文给发送方
虽然在 UDP之间的通信要用到其端口号，但由于 UDP的通信是无连接的，不需要使用套接字（TCP之间的通信必须要在两个套接字之间建立连接）
IP数据报的检验和只检验 IP数据报的首部，但 UDP的检验和是把首部和数据部分一起都检验

三、可靠传输的工作原理

3.1停止等待协议

“停止等待”是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组

3.1.1无差错情况

A 发送分组 M1，发完就暂停发送，等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送  ACK。A 在收到了对 M1 的确认后，就再发送下一个分组  M2

3.1.2出现差错

B接收 M1时检测出了差错而丢弃 M1，或者 M1在传输过程中丢失，出现这两种情况时 B都不会发送任何信息
解决方法：A只要超过了一段时间仍没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，这就叫超时重传

注意

• 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发
• 分组和确认分组都必须进行编号
• 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

3.1.3确认丢失和确认迟到

1、确认丢失
若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1
假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动：

1. 丢弃这个重复的分组 M1，不向上层交付
2. 向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认

2、确认迟到
传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了
A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃
B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组

3.1.4信道利用率

停止等待协议的优点是简单，缺点是信道利用率太低

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输

3.2连续 ARQ协议

发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置
接收方一般采用累积确认的方式，在收到几个分组后，对按需到达的最后一个分组发送确认
优点：容易实现，即使确认丢失也不必重传
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息

四、传输控制协议 TCP概述

4.1 TCP最主要的特点

• TCP 是面向连接的运输层协议
• 每一条 TCP 连接只能有两个端点 ，每一条 TCP 连接只能是点对点的（一对一）
• TCP 提供可靠交付的服务
• TCP 提供全双工通信
• 面向字节流：

1. TCP 中的“流”指的是流入或流出进程的字节序列
2. “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流
3. TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样

4.2 TCP的连接 

每一条 TCP连接有两个端点，叫套接字或插口
套接字的表示方法是在点分十进制的 IP地址后面写上端口号，中间用冒号或逗号隔开
每一条 TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定
同一个 IP地址可以有多个不同的 TCP连接，而同一端口号也可以出现在多个不同的 TCP连接中

4.3 TCP报文段的首部格式

五、TCP可靠传输的实现

假定数据传输只在一个方向进行，A发送数据，B给出确认

5.1以字节为单位的滑动窗口

根据 B 给出的窗口值，A 构造出自己的发送窗口
发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去
发送窗口里面的序号表示允许发送的序号
显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率

发送窗口的位置由窗口前沿和后沿的位置共同确定

• 后沿的变化情况分不动（没有收到新的确认）和前移（收到新的确认）
• 前沿通常是不断向前移动（没有收到新的确认），也可能不动（收到新的确认但对方通知的窗口变小）

图解发送方发送数据过程



发送缓存用来暂时存放

• 发送应用程序传送给发送方 TCP 准备发送的数据
• TCP 已发送出但尚未收到确认的数据

发送缓存和发送后沿是重合的

接收缓存用来暂时存放

• 按序到达的、但尚未被接收应用程序读取的数据
• 不按序到达的数据

注意

1. A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）
2. TCP 标准通常把不按序到达的数据临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
3. TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销

5.2超时重传时间的选择

TCP记录一个报文段发出的时间，以及收到相应的确认的时间，时间差就是报文段的往返时间 RTT，TCP保留了加权平均往返时间 RTTs
第一次测量到 RTT 样本时，RTTs 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTs：
新的RTTs  =  (1 - a) * (旧的RTTs) + a * (新的RTT样本)
式中 0 <= a < 1。若 a 很接近于零，表示 RTT 值更新较慢。若选择 a 接近于 1，则表示 RTT 值更新较快
超时重传时间 RTO略大于加权平均往返时间 RTTs：RTO = RTTs + 4 * RTTd（RTTd 是 RTT 的偏差的加权平均值）
第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：
新的 RTTd = (1 - b) * (旧的RTTd) + b * ½RTTs - 新的 RTT 样本½
Karn算法
如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

报文段每重传一次，就把 RTO 增大一些：
新的 RTO = g * (旧的 RTO) ，系数 g 的典型值是 2 
当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值

六、 TCP的流量控制

6.1利用滑动窗口实现流量控制

流量控制是让发送方的发送速率不要太快，要让接收方来得及接收
TCP的窗口单位是字节，不是报文段

从图看出，接收方的主机 B进行了三次流量控制，窗口最终减小到0，即不允许发送方再发送数据。这种使发送方暂停发送的状态将持续到主机 B重新发出一个新的窗口值为止
考虑一种情况。B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。为了解决这个问题，TCP 为每一个连接设有一个持续计时器
只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。

6.2 TCP的传输效率

用不同的机制来控制 TCP 报文段的发送时机

1. TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去
2. 由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送操作
3. 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去
    

七、TCP的拥塞控制

7.1拥塞控制的一般原理

拥塞控制是防止过多的数据注入到网络中，这样可能使网络中的路由器或链路不致过载。前提是网络能承受现有的网络负荷
拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器以及与降低网络传输性能有关的所有因素。流量控制往往是指点对点通信量的控制，是端到端的问题

在许多情况下，甚至是拥塞控制机制本身成为引起网络性能恶化甚至发生死锁的原因。这点应引起重视

拥塞控制可分为开环控制和闭环控制

• 开环控制是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞
• 闭环控制是基于反馈环路的概念。属于闭环控制的有以下几种措施：

1. 监测网络系统以便检测到拥塞在何时、何处发生
2. 将拥塞发生的信息传送到可采取行动的地方
3. 调整网络系统的运行以解决出现的问题

7.2 TCP的拥塞控制方法

四大算法进行拥塞控制：慢开始，拥塞避免，快重传，快恢复
现假定：

1. 数据是单方向传送的，对方只传送确认报文
2. 接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度决定

7.2.1四大算法

下面讨论的拥塞控制也叫基于窗口的拥塞控制
发送方维持一个叫拥塞窗口 CWND的状态变量，它的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口等于拥塞窗口
控制拥塞窗口的原则：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞
判断网络拥塞的依据是出现超时

慢开始
算法思路：由小到大逐渐增大拥塞窗口数值
初始拥塞窗口 cwnd 设置：不超过2至4个 SMSS的数值
在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值，即拥塞窗口cwnd每次的增加量 = min (N, SMSS)（N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数）
使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 而一个传输轮次所经历的时间其实就是往返时间 RTT

为防止拥塞窗口cwnd 增长过大引起网络拥塞，需设置一个慢开始门限

• 当 cwnd < ssthresh 时，使用慢开始算法
• 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法
• 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法

拥塞避免
每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始阶段那样加倍增长
在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多

快重传
让发送方尽早知道发生了个别报文段的丢失
首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”）

快恢复
当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此不执行慢开始算法，而执行快恢复算法：

1. 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2
2. 新拥塞窗口 cwnd = 慢开始门限 ssthresh
3. 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大

慢开始和拥塞避免算法的实现举例

为了便于理解，图中的窗口单位不使用字节而使用报文段
发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值
当 TCP 连接进行初始化时，将拥塞窗口置为 1。慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16

1. 在执行慢开始算法时，拥塞窗口 cwnd=1，发送第一个报文段
2. 发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1，然后开始下一轮的传输（请注意，横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
3. 当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（图中的点 圈1，此时拥塞窗口 cwnd = 16），就改为执行拥塞避免算法，拥塞窗口按线性规律增长
4. 当拥塞窗口 cwnd = 24 时，网络出现了超时（图中的点 圈2），发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd / 2 = 12，同时设置拥塞窗口 cwnd = 1，进入慢开始阶段
5. 按照慢开始算法，发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值加1
6. 当拥塞窗口cwnd = ssthresh = 12时（图中的点 圈3，这是新的ssthresh值），改为执行拥塞避免算法，拥塞窗口按线性规律增大
7. 当拥塞窗口cwnd = 16时（图中的点 圈4），出现了一个新的情况，就是发送方一连收到 3 个对同一个报文段的重复确认（图中记为3-ACK）。发送方改为执行快重传和快恢复算法
8. 因此，在图的点 圈4，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值ssthresh = cwnd / 2 = 8，同时设置拥塞窗口cwnd = ssthresh = 8（见图中的点 圈5），并开始执行拥塞避免算

TCP拥塞控制流程图

如果把拥塞控制和接收方对发送方的流量控制一起考虑，发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即 发送窗口的上限值 = Min [rwnd, cwnd]

• 当 rwnd < cwnd 时，接收方的接收能力限制发送窗口的最大值
• 当 cwnd < rwnd 时，网络的拥塞限制发送窗口的最大值

7.2.2主动队列管理 AQM

网络层的策略对 TCP 拥塞控制影响最大的是路由器的分组丢弃策略
路由器的队列通常都是按照“先进先出”FIFO的规则处理到来的分组。当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。这就叫做尾部丢弃策略在网络中通常有很多的 TCP 连接，这些连接中的报文段通常是复用在网络层的 IP 数据报中传送的。在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条 TCP 连接，结果使这许多 TCP 连接在同一时间突然都进入到慢开始状态。TCP称其为全局同步

 

八、TCP的运输连接管理

运输连接有三个阶段：连接建立，数据传送，连接释放
TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户，被动等待连接建立的应用进程叫做服务器

8.1 TCP的连接建立

TCP 建立连接的过程叫做握手。握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手

1. A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x
2. B 的 TCP 收到连接请求报文段后，如同意，则发回确认。B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x + 1，自己选择的序号 seq = y
3. A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。A 的 TCP 通知上层应用进程，连接已经建立
4. B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立

8.2 TCP的连接释放

TCP 连接释放过程是四报文握手
数据传输结束后，通信的双方都可释放连接

1. 现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接
2. A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认
3. B 发出确认，确认号 ack = u + 1，而这个报文段自己的序号 seq = v
4. TCP 服务器进程通知高层应用进程
5. 从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收
6. 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接
7. A 收到连接释放报文段后，必须发出确认
8. 在确认报文段中 ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1

TCP 连接必须经过时间 2MSL 后才真正释放掉

1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B
2. 防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段

8.3 TCP 的有限状态机

粗实线箭头表示对客户进程的正常变迁
粗虚线箭头表示对服务器进程的正常变迁
细线箭头表示异常变迁

转载于:https://www.cnblogs.com/xxwang1018/p/11546701.html