计算机网络运输层笔记

 2020-06-11 /  IOAOl

`运输层

运输层.png

运输层协议概述

进程之间端到端的逻辑通信

复用

· 发送方不同的应用进程都可以使用同一个运输层协议传送数据

分用

· 是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

差错检测

运输层的端口

属性

· 软件端口

· 16位65535

分类

· 服务端端口

• 熟知端口号（0-1023）

• 登记端口号（1024-49151）

· 客户端端口（短暂端口号）（49152-65535）

UDP(User Datagram Protocol）用户数据报协议

属性

不需要先建立连接（不可靠）

相比ip数据报增加的功能

· 复用和分用

· 差错检测

面向报文（直接使用应用层报文）

没有拥塞控制（用于多媒体通信）

n对n通信（n=1或多）

首部（8字节）开销小

不用套接字

首部

源端口2位

目的端口2位

长度2位

校验和2位

· 首部和数据部分一起校验

伪首部12位

· 计算校验和

· 不传输

TCP（Transmission Control Protocol）传输控制协议

特点

提供面向连接的服务（不多播或广播）

· 只能点对点

可靠交付的服务

全双工通信

面向字节流

· 随时截断发送给上层

• 根据拥塞情况和窗口值决定发送大小

连接

连接的端点：套接字socket

· TCP 连接：：= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

可靠传输的工作原理（使用协议降低出错）

停止等待协议

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

· 情况

•

• A只要超过了一段时间（超时计时器）仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。

• 注意事项

• 发送方暂存已发送分组

• 分组标号

• 设计重传时间长于往返时间

• 确认丢失和确认迟到

• 重复的确认收下就丢弃

• 重复的分组收到后丢弃，然后发送确认

· 信道利用率

•

连续ARQ协议

• 累积确认

• 接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认

• 缺点

• 不能向发送方反映出接收方已经正确收到的所有分组的信息。

• go-back-N

• 优点

• 容易实现，即使确认丢失也不必重传。

TCP报文段的首部格式

报文段

· TCP报文段首部的前20个字节是固定的（图5-14), 后面有4n字节是根据需要而增加
的选项(n是整数）。因此TCP首部的最小长度是20字节。

• 源端口和目的端口各占 2 个字节，

• 序号占 4 字节。

• 确认号占 4 字节=序号+长度+1

• 希望下一个发送分组的序号

• 数据偏移占 4 位（0-15）可加长到60字节

• 首部长度

• 保留占 6 位，保留为今后使用，但目前应置0。

• 紧急 URG

• 当 URG 置 l 时，发送应用进程就告诉发送方的 TCP 有紧急数据要传送。千是发送方TCP 就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。这时要与首部中紧急指针(Urgent Pointer)字段配合使用。

• 确认 ACK (ACKnowledgment) 仅当 ACK= 1 确认号字段才有效。当 ACK=0时，确认号无效。

• 推送PSH (PuSH)

• 不等缓存满直接向上交付

• 复位RST ( ReSeT)

• 当RST= 1时，表明 TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。RST置l还用拒绝一个非法的报文段或拒绝打开一个连接。RST 也可称为重建位或重置位。

• 同步SYN

• 同步SYN ( SYNchron ization) 在连接建立时用来同步序号。当SYN = 1 而 ACK= 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN= 1 和ACK= 1。

• 终止FIN

• 终止连接

• 窗口占2字节

• 窗口字段明确指出了现在允许对方发送的数据量

• 检验和

• 跟udp的伪首部一样

• 伪首部第4 个字段中的 17 改为6
(TCP 的协议号是 6),

• 紧急指针占2字节

• 紧急指针仅在URG= 1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。无视窗口

• 选项最长40字节

• TCP 最初只规定了一种选项，即最大报文段长度MSS (Maximum Segment Size)

• 窗口扩大选项 3字节（16+s）偏移量

• 时间戳选项 10字节

• 计算往返时间RTT

• 防止序号绕回(处理序号超过2^32的情况)

• 选择确认选项

• 待续

TCP 可靠传输的实现

以字节为单位的滑动窗口

· 根据窗口值构造发送窗口

•

• P3 -P1 =A 的发送窗口
P2 -P1 =已发送但尚未收到确认的字节数
P3 -P2 =允许发送但当前尚未发送的字节数（又称为可用窗口或有效窗口）

• 时延影响，发送窗口一般小于窗口值

• 对于不按序到达的数据应如何处理， TCP 标准并无明确规定，若丢弃，增加网络负担

• 第三， TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销，可以将要发送的数据合并确认信息，但不应推迟太久

超时重传时间的选择

· 自适应算法

• TCP保留了RTT的一个加权平均往返
时间RTTs( 这又称为平滑的往返时间，

• 新的RTTs = (1 -a) x (旧的RTTs) + a x ( 新的RTT样本）0<=a< 1

• 报文段的往返时间RTT

• 超时重传时间RTO

• RTO = RTTs + 4 x RTTD

• RTTD 是RTT 的偏差的加权平均值

• 新的RTTD = (1 - β) x (旧的RTTo)+βx|RTTs-新的RTT样本|
这里β是个小于 1 的系数，它的推荐值是1/4

• 往返时间的测量

• Kam算法

• 在计算加权平均 RTTS时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均RTTS和RTO就较准确。

• 修正

• 文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为旧的重传时间的 2 倍。当不再发生报文段的重传时，才计算超时重传时间。

选择确认SACK

· 解决接收到的字节流序号不连续的问题

· 如果要使用选择确认 SACK, 那么在建立 TCP 连接时，就要在 TCP 首部的选项中加上“ 允许 SACK” 的选项

· 由千首部选项的长度最多只有 40 字节，而指明一个边界就要用掉4字节（因为序号有 32 位，需要使用4个字节表示），因此在选项中最多只能指明 4 个字节块的边界信息。这是因为 4 个字节块共有 8 个边界，因而需要用 32 个字节来描述。另外还需要两个字节。一个字节用来指明是 SACK 选项，另一个字节是指明这个选项要占用多少字节。如果要报告五个字节块的边界信息

· 4个边界，两个块用了4*4字节+2字节（sack+sack长度）

TCP的流量控制

发送方的发送速率不要太快，要让接收方来得及接收。

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

· 通过控制窗口值控制速率

· 发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意， TCP 的窗口单位是字节，不是报文段。

· 为了防止0窗口后的新窗口丢失

• 发送方持续计时器

• 发送一个零窗口探测报文段

• 若为窗口仍为0

• 持续探测

• 若为窗口不为0

• 继续传输

TCP 的传输效率

· 发送时机机制

• 第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS 字节时，就组装成一个TCP 报文段发送出去。

• 第二种机制是由发送方的应用进程指明要求发送报文段，即TCP支持的推送(push)操作。

• 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS) 发送出去。

· Nagle 算法

• 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段

• 规定：当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，就可以有效地提高网络的吞吐量。

· 糊涂窗口综合征

• 现象

• TCP 接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1个字节（这样就使接收缓存空间仅腾出1个字节），然后向发送方发送确认，把窗口设置为1个字节（但发送的数据报是40字节长）。接着，发送方又发来l个字节的数
据（请注意，发送方发送的IP数据报是41字节长）。接收方发回确认，仍然将窗口设置为
l 个字节。这样进行下去，使网络的效率很低。

• 解决

• 接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

TCP的拥塞控制

拥塞控制的一般原理

· 拥塞

• 定义

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

• 任意增加一些资源不但不能解决拥塞问题，而且还可能使网络的性能更坏。拥塞常常趋千恶化。

• 原因

• 复杂

• 某个结点缓存的容量太小时，到达该结
点的分组因无存储空间暂存而不得不被丢弃。

• 理机处理的速率太慢可能引起网络的拥塞。简单地将处理机的速率提高，可能会使上述情况缓解一些，但往往又会将瓶颈转移到其他地方。

· 拥塞控制

• 定义

• 防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

• 是一个全局性的过程

• 拥塞控制与流量控制的关系

• 关系密切

• 流量控制往往是指点对点通信量的控制，是个端到端的问题

•

• 方法

• 开环控制

• 在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。

• 闭环控制

• 监测网络系统以便检测到拥塞在何时、何处发生。

• 把拥塞发生的信息传送到可采取行动的地方。

• 调整网络系统的运行以解决出现的问题。

TCP的拥塞控制方法

· 四种方法共同使用

• 慢开始(slow-start)

• 由小到大逐渐增大发送窗口（指数增加）

• 拥塞窗口cwnd每次的增加量=min (N, SMSS )

• N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。

• 拥塞避免(congestion avoidance)

• 拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口 cwnd 加1,而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大” AI (Additive Increase)的特点。这表明在拥塞避免阶段，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

• 快重传(fast retransmit)

• 发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段M3, 因而应当立即进行重传

•

• 快重传可以使整个网络的吞吐量提高约20%。

• 快恢复(fast recovery)

• 发送方调整门限值ssthresh = cwnd / 2

• 拥塞窗口cwnd= ssthresh

• 开始执行拥塞避免算法

• 概要发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

• 发送方又是如何知道网络发生了拥塞

• 判断网络拥塞的依据就是出现了超时。

• 慢开始门限 ssthresh

• cwnd< ssthresh时，使用上述的慢开始算法。

• cwnd> ssthresh时，停止使用慢开始算法而改用拥塞避免算法。

• cwnd= ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

•

· 流程图

•

主动队列管理AQM

· 略

TCP的运输连接管理

运输连接

· 连接建立

• 要解决的问题

• 要使每一方能够确知对方的存在

• 要允许双方协商一些参数

• 能够对运输实体资源

• 主动发起连接建立的应用进程叫做客户(client),
而被动等待连接建立的应用进程叫做服务器(server)。

• 过程

• 三次握手

· 数据传送

· 连接释放