Download
1 / 97
970 likes | 1.09k Views
The Transport Layer. Chapter 6. Content. 传输服务 传输协议的要素 一个简单的传输协议 Internet 传输协议－ UDP Internet 传输协议－ TCP 性能问题 本章小结. 传输层服务. 提供给高层的服务 传输层服务原语 Berkeley 套接字 套接字编程示例 : 文件服务器. 向上层提供的服务. 传输协议数据单元. 传输实体 1) 服务 2) 存在的原因 3) 获得的好处. The network, transport, and application layers. TPDU.
E N D
The Transport Layer Chapter 6
Content • 传输服务 • 传输协议的要素 • 一个简单的传输协议 • Internet传输协议－UDP • Internet传输协议－TCP • 性能问题 • 本章小结
传输层服务 • 提供给高层的服务 • 传输层服务原语 • Berkeley 套接字 • 套接字编程示例: • 文件服务器
向上层提供的服务 传输协议数据单元 传输实体 1)服务 2)存在的原因 3)获得的好处 The network, transport, and application layers.
TPDU TPDU、分组、和帧的嵌套
传输层服务原语 一套简单的传输层服务原语 基本使用过程。。。
传输层服务原语 一个简单的连接管理方案 右侧是客户机状态图 左侧是服务器状态图
Berkeley Sockets The socket primitives for TCP.
传输协议的要素 • 编址 • 建立连接 • 释放连接 • 流控和缓存 • 复用 • 崩溃恢复
概述 传输服务是通过两个传输实体间的传输协议实现的 与链路层类似，需要处理错误控制、顺序管理、流管理等 两者运行环境不同 (a)数据链路层协议的运行环境. (b)传输层协议的运行环境.
编址 端口：指定应用的进程 术语：传输服务访问点 必要性：需要区分应用的进程 TSAPs, NSAPs 和传输层连接.
编址 避免打开过多端口：初始连接协议（进程服务） 一些常用的服务：名字服务/目录服务
建立连接 • 考虑网络层是不可靠的，导致了复杂的建立连接的过程 • 例如：子网拥塞，导致发送方重传N次数据后才完成与接收方的连接。连接释放后，拥塞在网络中的数据却又到达了接收方。。。 • 如何处理延迟的重复分组？ • 标识符的方法导致历史数据存储 • 可以使用限制生存期上限的方法（在网络层实现） • 在已知子网规模的条件下限制分组生命期 • 每个分组放置跳计数器 • 为分组打上时间戳 • 假设每台主机都有时钟机制，并且保证单调递增，然后就可以设计一些方法来保证两个相同编号的TPDU永远不会同时有效（只要知道网络层实现的生存期上限的数值即可） • 让时钟的低k位表示序号 • 此时时钟和序号形成了周期的线性信号
考虑主机崩溃 • 在使用时钟的低k位来对序号赋值以后，需要考虑主机崩溃的情况 • 一种方法是崩溃后等着所有的分组全部过期 • 另一种方法设置禁止区域 • 无禁止区域情况下碰撞的示例 • T=60s • T=30s时，发送了某个序号为80的分组X（注意时间是连续的，有很多30s。。。），然后主机崩溃 • 然后重新启动，在t=70s时为分组X所属连接开始发送新的分组，第一个序号为70 • 然后t=85秒时，又一个80分组出现了。。。（这里暗含15秒发送10个分组） • 禁止区域：对于任何一个序列号，在其有可能被用作初始序号之前的T秒时间内，禁止使用该序列号 • 例如序列号80，用于初始序列号的时间是t=80s，T=60，则在t=20s到t=80这T秒时间内，应该禁止使用该序列号
禁止区域 分组可能会进入禁止区域的两种情况： 1.发送数据太快，超过了一个时钟滴答一个TPDU，序号会很快进入禁止区域 2.即使是正常情况，也会因为周期的关系导致序号进入禁止区域 解决方法： 在任何连接上，发送任何TPDU之前，传输实体必须读取时钟的信息，并检查这个TPDU是否落在禁止区域中
三次握手 • 目的： • 双方确认初始序列号 • 如果不确认初始序列号？ • 确认数据传输的起点会比较麻烦，例如使用累积确认的时候 • 其目的应该是保证从一开始就是无错传输 • 三次握手的三个场景 • 正常的三次握手 • 双方分别就x y达成一致 • 出现旧的连接请求 • 拒绝 • 出现旧的数据 • 拒绝
释放连接 • 非对称方式释放连接可能会导致数据丢失 这里的问题在于释放连接的一方不是数据的发送方
释放连接 两军问题 对称方式释放连接时要求发起释放连接的一方是数据的发送方，可以避免非对称的方式造成的问题。 此时新的问题在于数据的发起方不能确认接收方是否接收到了最后一条数据。。。接收方不能确认发起方是否收到了最后一条数据的响应。。。发起方不能确认接收方是否收到了关于接收方响应的响应。。。 Perfect：所有的工作都已经完成并且连接应该被终止
三次握手释放连接 6-14, a, b 对称方式释放连接 第二个DR隐含的表示对第一个DR的确认 这种工作方式要求当一方释放连接的时候，另一方也马上准备释放连接 图(a)表示双方正常释放连接。图(b)中host2超时后释放连接
三次握手释放连接 6-14, c,d 图(c)中host1有一次超时。图(b)中双方N此重传后释放连接 半开连接及其处理P429-P430
流控和缓冲 • 在使用连接的时候，需要流控和缓冲来协调通信双方的速率 • 缓冲的必要性及其策略 • 链路层缓冲因为物理链路不可靠，传输层缓冲因为网络不可靠 • 链路层的流控是通过分配缓存，使用滑窗来完成的 • 然而链路层分配缓存的策略在主机的传输层不合适 • 如果每个连接MAX_SEQ+1个缓冲区，64个连接使用4位序列号就绪要很多缓冲区才行 • 传输层缓冲的策略需要根据流量的类型动态调整 • 低带宽突发流量最好在发送方缓存 • 高带宽平滑流量最好在接收方缓存 • 传输层的缓冲区大小应该是可变的（与流量类型相关）
流控和缓冲 (a)固定大小缓存链. (b)可变大小的缓存链（低带宽突发模式）. (c)缓存池（高带宽平滑流量较合适）.
流控和缓冲示例 4位序列号，数据报子网，动态窗口管理 可以看到缓冲过程与确认机制分离开
流控和缓冲示例 • 死锁 • 第16行出现死锁 • 为了避免发送方认为接收方一直没有缓冲区的情况，由发送方定期发送一些小数据包，以获得新的缓冲区空间 • 影响流控的第二个因素是子网的承载能力 • 如果主机的相邻路由器最多每秒传输x个分组，共有k的相邻路由器，则传输层总共每秒发送的TPDU数不超过kx • 此时的流控由发送方动态调整，通过监视一段时间内被确认的TPDU的数量，发送方可以确定子网的承载能力，根据该能力计算发送方窗口的大小，实现流控
多路复用 (a)向上多路复用. (b)向下多路复用.
崩溃恢复 • 路由器崩溃 • 可以恢复，传输层可以通过序列号，超时等机制实现 • 主机崩溃 • 困难！ • 考虑客户A给服务器B发送文件。B的传输层把接收到的TPDU解复用给相应进程 • 突然B崩溃，然后重启，此时B可以广播给所有客户B的崩溃事件，要求客户提供状态信息S0，S1； • S1表示有一个没有完成的TPDU，S0表示没有未完成的TPDU • 如何恢复呢？ • 如果客户处于状态S1，那么客户重传没有完成的TPDU。。。 • 考虑服务器B完好接收一个TPDU之后，发送确认和写该TPDU到某个进程是独立的事件，那么如果服务器先确认后写会怎么样？如果先写后确认会怎么样？
崩溃恢复 客户和服务器各种策略的不同组合 左侧表为主机策略，其它为服务器策略及其后果，其中C代表Crash.
崩溃恢复 • 通过遍历所有可能，我们看到，主机崩溃后，传输层不存在合适的解决方案来防止传输层出现错误 • 一般化为： • 从N的崩溃中恢复过来的工作只能由N+1层来完成，并且仅当N+1层保留了足够的状态信息时才有可能恢复 • 进一步：端到端确认到底意味着什么？ • 并不意味着应用程序的功能是否成功完成 • 只意味着传输层有一个TPDU确实被接收方收到了。。。至于该TPDU的数据和前一个TPDU的数据在应用层是否连续并没有提供100%的担保
一个简单的传输层实体 • 该传输层实体所用的原语 • 该传输层实体 • 该传输层实体的有限状态机
概述 • 该示例涉及五个原子操作 • S_conn=Listen(port) • C_conn=Connect(localprot, remoteport) • Status=Send(C(S)_conn, buffer, bytes) • Status=Recieve(C(S)_conn, buffer, bytes) • Status=Disconnect(C(S)_conn) • 该传输层示例不是TCP! • 该传输层示例假设了网络层是可靠的面向连接的网络 • 该示例关注 建立连接，传输数据，拆除连接这些基本过程
概述 • 该示例涉及的网络层分组类型有六种 • 该示例可以在不同端口号建立多个连接 • 该示例的每个连接涉及7种状态 • …
7种状态 Each connection is in one of seven states: • Idle – Connection not established yet. • Waiting – CONNECT has been executed, CALL REQUEST sent. • Queued – A CALL REQUEST has arrived; no LISTEN yet. • Established – The connection has been established. • Sending – The user is waiting for permission to send a packet. • Receiving – A RECEIVE has been done. • DISCONNECTING – a DISCONNECT has been done locally.
The Example Transport Entity (3) 该示例的每个连接都保存在这样一个数组类型的全局变量中
The Example Transport Entity (4) 在服务器listen该端口之前，已经有客户机在该端口发起请求 阻塞监听
The Example Transport Entity (5) 使用连接数组中的某个空闲连接
The Example Transport Entity (9) 解除listen阻塞 解除connect阻塞 在执行send、recieve 、conncet原语时，对方关闭了连接 解除send阻塞 解除Receive阻塞
The Example Transport Entity (10) 仅对conncet时进入队列的连接请求有效
示例的 Finite State Machine-矩阵图 Each entry has an optional predicate, an optional action, and the new state. The ~ indicates that no major action is taken. An — above a predicate indicate the negation of the predicate. Blank entries correspond to impossible or invalid events.
基于矩阵图的事件驱动编程 • 死循环等待发生的事件 • 事件发生时根据状态来定位需要使用的程序段 • 每个程序段处理矩阵图中的一个表项 评注： 更加规范化和系统化
示例的 Finite State Machine –状态图 The example protocol in graphical form. Transitions that leave the connection state unchanged have been omitted for simplicity.
因特网的传输层协议: UDP • 介绍 UDP • Remote Procedure Call • Real-Time Transport Protocol
Introduction to UDP RFC768 UDP传输数据段segment UDPsegment格式如图，其中校验和可选 UDP的价值在于提供一个接口，并在接口中增加解复用的特性 UDP的典型应用是在C/S架构下进行Request/Reply这样的Transaction，如果Reply没有到来，Client可以重新发送Request 例：域名系统
Remote Procedure Call • 相似性 • sending a message to a remote host and getting a reply back • making a function call • 这促使人们把Request/Reply交互 按照函数调用的方式处理 • 例如get_IP_address (host_name) • works by sending a UDP packet to a DNS server and waiting for the reply, timing out and trying again if one is not forthcoming quickly enough • 好处 • all the details of networking can be hidden from the programmer
Remote Procedure Call Client Server Blocked Request Blocked Computing Reply Blocked • Birrell and Nelson (1984)做了主要的工作 • 简单说是允许程序调用处于远端主机的过程. • RPC的基本执行过程如图.
