Download presentation
Presentation is loading. Please wait.
1
传输层是整个协议层次的核心，其任务是在源机器和目标机器之间提供可靠的、性价比合理的数据传输功能，并与当前所使用的物理网络完全独立
第8章 传输层 传输层是整个协议层次的核心，其任务是在源机器和目标机器之间提供可靠的、性价比合理的数据传输功能，并与当前所使用的物理网络完全独立
2
目录 传输服务 传输协议的要素 传输层协议
3
传输层的位置 图8-1 传输层在OSI模型中的位置 介于通信子网和资源子网之间，对高层用户屏蔽了通信的细节
弥补了通信子网所提供服务的差异和不足，提供端到端之间的无差错保证 传输层工作的简繁取决于通信子网提供服务的程度
4
传输实体 在传输层内部，完成该项工作的硬件和（或）软件称为传输实体（Transport Entity）。传输实体可能在下列软、硬件环境中：
（1）操作系统的内核中； （2）一个单独的用户进程中； （3）网络应用的程序库中； （4）网络接口卡上。 传输实体要为很多应用程序服务，所以对每一个应用程序在传输层都有一个标识，这个标识就叫做传输地址。
5
传输层提供的传输服务 图8-2 网络层、传输层和应用层
6
传输层提供的传输服务 面向连接的服务：通信可靠对数据有校验和重发 面向非连接的服务：对数据无校验和重发，通信速率高
7
传输服务原语 传输服务原语是应用程序和传输服务之间的接口 TPDU 传输协议数据单元
8
TPDU的发送过程 图8-3 TPDU、分组和帧的嵌套关系
9
伯克利套接字（Berkeley Socket）
10
Socket Programming Example: Internet File Server
6-6-1 Client code using sockets.
11
Socket Programming Example: Internet File Server (2)
Server code using sockets.
12
典型的套接字应用过程 图8-4 典型的套接字应用过程
13
传输协议的要素 寻址 连接建立 释放连接 流量控制和缓冲策略 多路复用 崩溃的恢复
14
寻址 两个程序要建立连接时必须指明对方是哪一个应用程序，这个标记称为传输层地址，也称为传输服务访问点TSAP 在TCP协议中即TCP的端口号
网络层地址称为网络服务访问点NSAP(Network Service Access Point)在IP协议中即IP地址
15
TSAP & NSAP 图8-5 TSAP、NSAP和连接
16
如何知道对方的TSAP 图8-6 主机1的用户进程如何与主机2的时间服务器建立连接 初始连接协议，由进程服务器代理转接多种不同的服务请求
17
连接建立 连接的建立：需要解决网络上的延迟与丢失引起的重复分组 常用的方法：三次握手
18
三次握手 CR=CONNECTION REQUEST. (a) 正常的连接建立过程 (b)由于延迟而重复的TPDU的连接过程 (c) 过期的CONNECTION REQUEST 和过期的 ACK都出现
19
释放连接 非对称释放 一方中止连接则连接即告中断 对称释放 A提出中止请求，B同意即中止
20
非对称释放 突然释放连接将造成数据丢失
21
对称释放 a) 三次握手释放连接 b) 最后的确认丢失，定时器超时自动放弃连接
22
对称释放(2) c) 应答丢失，发送端重发DR d) 应答丢失，重发的DR也丢失
23
消除半接通连接的方法 当第一个DR和所有N次重发都丢失的情况下，协议失败 解决方法：如果在一段时间内没有收到任何TPDU，连接便自动释放。
24
流量控制和缓冲策略 流量控制是发送方和接收方之间的传输速率上的匹配 为使没有得到确认的TPDU在超时后的重发，通常必须在缓冲区中暂存
25
流量控制和缓冲策略举例 图8-10 利用滑动窗口机制进行流量控制举例
26
必须考虑传输速率 应用进程把数据传送到TCP的发送缓存后，就由TCP来控制发送任务。可以用不同的机制来控制TCP报文段的发送时机。例如：
1）TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。 2）由发送方的应用进程指明要求发送报文段，即TCP支持的推送( push )操作。 3）发送方的一个计时器期限到了，这时就把已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。
27
Nagle算法 描述如下： 若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方接收对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段再发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle算法还规定：当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。
28
糊涂窗口综合症 如：TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节）。接着，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。
29
糊涂窗口综合症 要解决这个问题，可让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小。
30
多路复用 向上多路复用：多个传输层的连接公用一个网络层的连接,将提高网络层连接的利用率
向下多路复用：一个传输层的连接通过多个网络层连接来发送,可增加其有效带宽传送,速率将得到提高
31
崩溃的恢复 （1）网络崩溃的恢复 1）数据报子网
数据报子网是不可靠的，在传输层有一个缓冲区用来保存所有已发送的但还没收到确认的数据。如果传输层对丢失的TPDU留有副本，可以通过重发来解决。 2）虚电路子网 虚电路子网不保存发送数据的副本，在网络恢复后重新建立连接，并询问远端的传输实体哪些TPDU已经收到（只需知道最后收到的数据的序号就可以知道接收方哪些数据收到了，哪些没有收到），没有收到的则必须重发。
32
主机崩溃的恢复 服务器崩溃然后很快重新起动，所有连接登记表都已经初始化 重新连接后客户端可能处于两种状态之一
S1—有一个未被确认的TPDU S0—没有未被确认的TPDU 在一般情况下，远端服务器的传输实体在接收到一个客户端的TPDU后先发送一个确认，当确认发生后又对应用进程执行一个写操作，如存盘或交上层，向输出流写一个TPDU和发送一个确认是两个不同的而又不可分的事件，但两者不能同时进行
33
确认和写操作的问题 发送确认然后再进行写操作，中间发生崩溃 先进行写操作然后再发送确认，中间发生崩溃
此时客户端将收到这个确认，当崩溃恢复声明到达时，它处于状态S0，客户端将因此不再重发，因为它错以为那个TPDU已经到达服务器端，客户端的这种决定会导致丢失一个TPDU 先进行写操作然后再发送确认，中间发生崩溃 设想已经完成了写操作，但在确认发出前系统发生了崩溃，此时客户端将处于状态S1，并因此重传数据，从而会导致在服务器应用进程的输出流上出现一个无法检测的重复的TPDU 无论怎样对发送方和接收方的协议进行编程，总是存在协议不能正确地从故障中恢复的情况 传输层无法彻底解决该问题将由高一层协议处理
34
传输层协议 TCP和UDP都是Internet提供的传输层协议
TCP(RFC 793)是面向连接的 UDP(RFC 768)是面向非连接的 TCP协议是面向连接的传输层协议，其数据段的传输不会发生丢失、重复、乱序等情况，是提供可靠性传输的协议，所以其协议开销也较大 UDP协议是无连接的数据报协议，它不提供可靠性服务，但其相应的协议开销也较小，效率较高
35
UDP的主要特点 1）UDP是无连接的传输层协议 2）UDP是面向报文的 3）UDP没有拥塞控制 4）UDP使用尽最大努力交付
6）UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短
36
UDP报文格式 UDP源端口：UDP端口号，当不需要返回数据时源端口域置0 UDP目的端口：UDP端口号
37
UDP 的封装与协议的分层 应用层 UDP TCP IP 与各种网络接口 图8-12 分层模型中的 UDP 层
38
UDP 的封装与协议的分层 UDP头部 UDP数据区 IP头部 IP数据区 图8-13 UDP 的封装
39
UDP 的复用、分解与端口 图8-14 UDP的分解操作
40
RPC（Remote Procedure Call，远过程调用）
RPC是UDP的一个重要应用，它对程序员屏蔽了网络运作的细节。RPC的思想是尽可能地使一个远过程调用看起来像本地过程调用一样。将网络中的请求-应答交互表示成过程调用形式，例如：调用get-IP-address（主机名）将发送一个UDP包给DNS服务器，并等待回答。
41
RTP（Real-Time Transport Protocol，实时传输协议）
UDP的另一个重要应用是多媒体数据的传输，RTP是专门用于多媒体传输的一个协议，它基于UDP协议。RTP被放在用户空间中，并且通常运行在UDP之上。它的操作方式如下：多媒体应用通常包含多个音频、视频、文字流、可能还包括其他的流。这些流被送入到RTP库中，而RTP库位于多媒体应用的用户空间中。然后，这些RTP分组被填充到一个套接字中。在套接字的另一端生成UDP分组，这些UDP分组被嵌入到IP分组中。如果当前计算机是在以太网上，则这些IP分组被放到以太网帧中以便传输出去。
42
RTP（Real-Time Transport Protocol，实时传输协议）
43
RTP（Real-Time Transport Protocol，实时传输协议）
UDP净荷 IP净荷 以太网净荷 以太网头 IP头 UDP头 RTP头 图8-16 分组的嵌套情况
44
RTP头的结构
45
TCP提供的服务 面向连接(Connection Orientation) 端到端的服务(End-to-End Communication)
完全可靠性服务(Complete Reliability) 全双工服务(Full Duplex Communication) 流接口(Stream Interface) 可靠的连接建立(Reliable Connection Startup) 完美的连接终止(Graceful Connection Shutdown)
46
TCP 提供的可靠传输服务有如下五个特征 1）面向字节流 2）虚电路连接 3）有缓冲的传输 4）全双工连接 5）点对点的传输
47
滑动窗口概念 图8-18 带重传功能的肯定确认协议 图8-19 分组丢失引起超时和重传
48
滑动窗口概念 图 8-20 (a) 窗口内包括 8 个分组的滑动窗口协议
(b) 收到对 1 号分组的确认信息后，窗口滑动，使得 9 号分组也能被发送
49
滑动窗口概念 图 8-21 使用窗口大小为 3 的滑动窗口协议传输分组示例
50
目的端口（ destination port ）号 确认号（ acknowledgement number ）
TCP 报文格式 源端口（ source port ）号 目的端口（ destination port ）号 顺序号（ sequence number ） 确认号（ acknowledgement number ） TCP报头长度 保留 URG ACK P S H R T YN F IN 窗口大小（ window size ） 校验和（ checksum ） 紧急指针（ urgent pointer ） 可选项（ 0 或多个 32 位字） 数据（ 0 或多个字节）
51
TCP 连接建立与关闭 图8-23 TCP建立连接的三次握手报文序列
52
TCP 连接建立与关闭 图8-24 用于TCP关闭连接的修改的三次握手报文序列
53
TCP 连接建立与关闭 从一方的 TCP 来说，连接的关闭有三种情况： 1）本方启动关闭 2）对方启动关闭 3）双方同时启动关闭
54
TCP状态机
55
TCP 状态表 状 态 描 述 CLOSED LISTEN SYN RCVD SYN SENT ESTABLISHED FIN WAIT 1
关闭状态，没有连接活动或正在进行 LISTEN 监听状态，服务器正在等待连接进入 SYN RCVD 收到一个连接请求，尚未确认 SYN SENT 已经发出连接请求，等待确认 ESTABLISHED 连接建立，正常数据传输状态 FIN WAIT 1 （主动关闭）已经发送关闭请求，等待确认 FIN WAIT 2 （主动关闭）收到对方关闭确认，等待对方关闭请求 TIMED WAIT 完成双向关闭，等待所有分组死掉 CLOSING 双方同时尝试关闭，等待对方确认 CLOSE WAIT （被动关闭）收到对方关闭请求，已经确认 LAST ACK （被动关闭）等待最后一个关闭确认，并等待所有分组死掉
56
（1）正常状态转换 图8-26 TCP正常连接建立和终止所对应的状态
57
（2）同时打开 图 8-27 同时打开期间报文段的交换
58
（3）同时关闭 图 8-28 同时关闭期间的报文段交换
59
（4）其它情况 1）服务方打开：从 LISTEN 到 SYN_SENT 的变迁是正确的，它由服务器端主动发出 SYN 报文段，但 Berkeley 版的 TCP 软件并不支持它。 2）重置连接（复位）：只有当 SYN_RCVD 状态是从 LISTEN 状态（正常情况）进入，而不是从 SYN_SENT 状态（同时打开）进入时，从 SYN_RCVD 回到 LISTEN 的状态变迁才是有效的。这意味着如果我们执行被动打开（进入 LISTEN ），收到一个 SYN ，发送一个带 ACK 的 SYN （进入 SYN_RCVD ），然后收到一个 RST ，而不是一个 ACK ，便又回到 LISTEN 状态并等待另一个连接请求的到来。 3）快速关闭：在主动关闭后的 FIN_WAIT_1 状态，如果收到的报文段不仅是 ACK ，而且还包括对方的 FIN 信号，则直接进入 TIME_WAIT 状态，给对方发送 ACK 报文段，然后等待超时。
60
TCP重传策略 TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重发定时器，如果在定时器超时前收到确认，就关闭此定时器；如果定时器超时前未收到确认，则重传该数据段。
61
TCP重传策略 这种重传策略的关键是对定时器初值的设定。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs（又称为平滑的往返时间，S表示Smoothed。因为进行的是加权平均，所以得出的结果更加平滑）。每当第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs： 新的RTTs = (1-α)×(旧的RTTs)+ α×（新的RTT样本） (8-1)
62
TCP重传策略 在上式中，0 ≤α< 1。若α很接近于零，表示新的RTTs值和旧的RTTs值相比变化不大，而对新的RTT样本影响不大(RTT值更新较慢)。若α接近于1，则表示新的RTTs值受新的RTT样本的影响较大(RTT值更新较快)。RFC 2988推荐的α值为1/8，即0.125。用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。 显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out)应略大于上面得出的加权平均往返时间RTTs。RFC 2988建议使用下式计算RTO: RTO = RTTs + 4×RTTd (8-2)
63
TCP重传策略 而RTTd是RTT的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。RFC 2988建议这样计算RTTd。当第一次测量时，RTTd值取为测量到的RTT样本值的1/2。在以后的测量中，则使用下式计算加权平均的RTTd: 新的RTTd = （1-β）× (旧的RTTd) + β × |RTTs - 新的RTT样本| (8-3) 这里β是个小于1的系数，它的推荐值是1/4，即0.25。
64
TCP拥塞控制 （1）慢开始和拥塞避免 （2）快重传和快恢复
65
（1）慢开始和拥塞避免 发送 M1 确认 M1 发送 M2~M3 确认 M2~M3 发送 M4~M7 确认 M4~M7 cwnd = 1
… 轮次 1 轮次 2 轮次 3 发送方 接收方
66
（1）慢开始和拥塞避免 22 16 “乘法减小” 2 4 6 8 10 12 14 18 20 24 网络拥塞 指数规律增长 慢开始
24 网络拥塞 指数规律增长 慢开始 拥塞避免 “加法增大” ssthresh的初始值 新的 ssthresh 值
67
（2）快重传和快恢复 发送方 接收方 发送 M1 发送 M2 确认 M1 发送 M3 确认 M2 丢失 ？ 发送 M4 重复确认 M2
t 确认 M2 发送 M2 发送 M3 发送 M4 ？ 发送 M5 发送 M6 重复确认 M2 立即重传 M3 发送 M7 收到三个连续的 对 M2 的重复确认 丢失
68
（2）快重传和快恢复 快恢复算法与快重传配合使用，其过程有以下两个要点：
1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。 2）由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连有好几个报文段连续到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
69
快重传和快恢复的示意图 24 2 4 6 8 10 12 14 16 18 20 22 传输轮次 拥塞窗口 cwnd 收到 3 个重复的确认
传输轮次 拥塞窗口 cwnd 收到 3 个重复的确认 执行快重传算法 慢开始 “乘法减小” 拥塞避免 “加法增大” TCP Reno 版本 TCP Tahoe 版本 (已废弃不用） 新的 ssthresh 值 快恢复 ssthresh的初始值
Similar presentations
