第六章 传输层(二)
三、Internet的传输协议
- TCP和UDP都是Internet提供的传输层协议
- UDP (User Datagram Protocol)
- TCP (Transmission Control Protocol)
UDP (User Datagram Protocol)
UDP简介
- UDP协议是无连接的数据报协议,它不提供可靠性服务,但其相应的协议开销也较小、效率较高
- 域名系统DNS、简单网络管理协议SNMP使用的传输层协议是UDP
UDP提供的服务
- UDP是面向非连接的,与IP协议相比,它唯一增加的能力是提供端口协议(就是添加了一个端口号),以保证进程通信,传输的可靠性要靠应用程序来解决,但效率高
- 适应的范围:
- 传输质量不是要求很高的
- 文本信息(其可靠性有传输层来保证)
- UDP的数据报格式
- UDP源端口:(发送方的进程)UDP端口号,当不需要返回数据时,源端口域置0
- UDP目的端口:UDP端口号(接收方的应用进程)
- UDP长度:整个数据段的长度,包括头部和数据部分以字节计,最小值为8(仅头部长度)
- UDP校验和:可选域,全0为未选,全1表示校验和为0
- UDP数据段的封装
- 当一个应用进程要用UDP来传输数据时
- 首先这个应用进程把数据交给UDP
- UDP把这个数据进行封装
- 就是在数据段前面加上UDP的头部,就是上面数据报的4个字节的内容
- UDP交给IP协议,整个UDP的PDU作为IP的数据包,封装在IP的数据区
- 然后IP协议在前面加上一个IP的报头
- 最后这个数据包通过IP协议传递出去了
UDP提供服务的应用
- 常用哪些形式?
- 传输信息量很少的
- 实时信息的传输
RPC(Remote Procedure Call)(信息量少)
- 传输信息很少的应用,通常我们把它看成是一个函数,传一个参数,返回一个返回值,区别就是函数调用在本地,而这种方式调用时在远程
- 远程过程调用RPC
- 将网络中的请求-应答交互表示成过程调用形式(就是想函数调用一样),例如:调用get-IP-address(主机名)将发送一个UDP包给DNS服务器,并等待回答
- RPC对程序员屏蔽了网络运作的细节
- RPC是UDP的一个重要应用
-
一次RPC的过程
- 客户机通过在本地调用Client stub,使用常规的方法将参数压栈
- Client stub把参数封装(marshal)成消息并通过系统调用进行发送
- 客户机操作系统内核通过网络发送消息到服务器
- 服务器操作系统内核通过网络从客户机接收消息
- Server stub调用服务器进程对参数进行拆封
- 应答即为同一路径的逆向过程
- 注意:Stub是一个程序模块,用于在客户机和服务器之间传输远程过程调用和响应的承接程序
- RPC的应用
- RPC是客户机/服务器模式中实现分布式计算的通信协议
- RPC采用非连接对话方式,具有错误控制能力
- RPC使服务器系统使用客户机提供的参数,执行客户机指定的规程并返回结果
- 从逻辑上看,按OSI的七层构架,RPC属会话层协议,但有些功能属应用层
RTP(Real-Time Transport Protocol)(实时传输)
- 实时传输的特点:
- 丢失了一个包没关系,但是必须保证时间的实时性
- 实时传输协议RTP
- 由于不需要连接的时间,可以保证实时性
- UDP的另一个重要应用是RTP
- RTP是一个传输层协议,但在应用层实现
- RTP是用于多媒体数据传输的协议
- 啥是多媒体传输?
- 就比如直播,在直播的过程中,要传输声音、图像、屏幕上面的信息等等多种媒体,同时传播过去
- 这几种数据流传播过去都是要有机的结合起来的,声音、头像、图片要同步,所以多个数据流之间就有一定的关系,那么怎么处理这些关系呢?
- RTP就支持这种传输,在一个UDP流当中,即一个应用进程到另一个应用进程当中及时传递各种各样的数据
- RTP协议就是基于UDP接口上面的协议。
- 因此做一个多媒体应用,这种传输的协议就是RTP传输
- RTP的功能
- 将多个实时数据流多路复用到一个UDP流上,UDP流能被送给某个地址(单址传输)或多个地址(多址传输)
- 每个RTP流的数据包有一个连续的编号,接收方可以根据此编号确定是否有数据包丢失
- RTP没有流量控制、差错控制、应答以及重传机制
- RTP的载荷可以是不同的多媒体信息,如单个的音频流,可以是8 bit-8 kHz的PCM编码,也可以是GSM、MP3等,那么也就必须把这个编码方式传给对方,才能解码
- 编码方式在RTP的包头上指出
- 实时应用的另一个特征是需要时间戳,时间戳是相对于流的第一个数据包的,这有助于在接收方消除抖动,以及多个流的同步(如数字电视中的视频流和两个音频流)(就是保证声音和视频的同步)
- 将多个实时数据流多路复用到一个UDP流上,UDP流能被送给某个地址(单址传输)或多个地址(多址传输)
- RTP的头部格式
- RTP的头部字段
- P:指出数据包是否被填充为4字节的整倍数
- X:是否有扩展头
- CC:有多少个有效源(0-15),用于多路复用;(就是有几种媒体流传输)
- M:应用指定的标记位,如表示video帧的开始、音频通道中文字的开始或其它可理解的应用
- 载荷类型:信息的编码方式(如非压缩的8 bit音频、MP3等)
- 顺序号:RTP包的序号,以此检查是否丢包
- 时间戳:由发送源产生,表示与第一个包的时间间隔
- 同步源标记:数据包属于哪个流,用于多路复用或解多路复用
- 有效源标记:用于混合数据源,如果该字段出现,则该混合源是同步数据源,每个分数据源被列在这里
- RTP的姐妹协议RTCP (略)
- RTCP(Realtime Transport Control Protocol) 实时传输控制协议
- RTCP处理反馈、同步和用户接口,而不传输数据
- 反馈消息包括延时、抖动、带宽、拥塞以及其它网络性能,可协调源端的传输速率、编码方式等,以适应当前的传输环境,得到最好的服务质量
- 同步是指不同的流数据可以用不同的时钟、不同的颗粒度、不同的速率进行传输,而RTCP可使其保持同步
- RTCP提供一种对不同的源端进行命名的方法,这将使接收方可在屏幕上显示当前谁在发送数据
TCP (Transmission Control Protocol)
- TCP提供的服务
- 面向连接(Connection Orientation)
- 端到端的服务(End – to – End Communication)(每个端表示一个应用进程)
- 就是应用进程到应用进程之间的服务
- 完全可靠性服务(Complete Reliability)
- IP协议不提供可靠性服务,而TCP将在IP的基础上提供可靠性服务并保证数据发送和接收次序一致
- 全双工服务(Full Duplex Communication)
- 就是连接建立起来以后双方都可以发送和接收数据
- 流接口(Stream Interface)(TCP/UDP的不同之处)
- 不是像IP一样每个数据包标识是数据包的编号,而TCP是字节流的序号
- 可靠的连接建立(Reliable Connection Startup) (三次握手)
- 完美的连接终止(Graceful Connection Shutdown) (三次握手)
- TCP协议将讨论:
- TCP服务模型
- TCP数据段头
- TCP连接和释放管理
- TCP传输策略
- TCP拥塞控制
- TCP定时器管理
TCP服务模型
- 端口port
- 应用进程的标识
- TCP的TSAP,与某一个应用程序相关
- 通用端口(well-known port) 端口号小于1024
- 其他可由各主机自己定义
- 套接字socket
- 传输层的通信端点,它由 IP地址 + 端口号 组成,internet中的唯一套接字
- 准确的说套接字就是: IP地址 + 端口号
- 常用TCP端口表
- 套接字举例
- 一个套接字允许被多个连接同时使用,即多个连接可同时连接到同一个套接字上
- 一个套接字允许被多个连接同时使用,即多个连接可同时连接到同一个套接字上
TCP数据段头
- TCP数据段头及说明
- 也分为段头+数据部分
- 端口:每个端口对应一个应用程序
- 序号:发送的字节序号(32位表示)
- 确认号:接收到的字节序号 ,与序号是对应的,稍待确认。
- 段头长度:段头中包含多少个32位字,即以32位为单位(就是这个图中有多少行)
- 保留:以备扩展之用
- 码位:
- URG: 紧急指针有效
- ACK: 确认号有效
- PSH: 请求接收方,数据一到,立即送往应用程序
- RST: 复位由于主机崩溃或其他原因而出现的错误的连接
- SYN: 用于建立连接
- FIN: 用于断开连接
- 窗口:接收方窗口大小(流量控制)
- 校验和:包括报头、数据和伪段头
- 紧急指针:当前序号到紧急位置的偏移量
- 数据:真正要传输的数据
- 选项字段:用于提供一种增加额外设置的方法,如连接建立时,双方说明最大的负载能力
- 常用的选项字段
- 最大数据段长度MSS
- 目的站可接收的最大的数据段长度,这个值在0到65535之间,默认值是536字节
- 窗口扩大因子n(n<=14) (RFC1323)
- 窗口的大小=首部中定义的窗口大小*2(指数形式 : 窗口扩大因子)
- 选择性重发协议(RFC1106)
- 引入了NAK机制
- 最大数据段长度MSS
TCP连接和释放管理
TCP连接管理
- TCP连接的建立
- 采用三次握手(3-way handshake)的方法
- 用TCP包头中的同步位(SYN)和结束位(FIN)描述连接建立和终止时的三次握手消息
- 主机1向主机2发送一个段,这个段同步码位(SYN)置1,同时为自己选择一个初始的序号x
- 主机2同意建立连接,也发送一个段,这个段的同步码(SYN)位置1,而且为自己选择一个初始序号y,同时确认号有效,并且告诉对方x数据都接收到了,下一次发送的数据是从x+1个字节开始发送
- 主机1收到主机2的同意,再次发送请求,同时把数据带过去。。。
- 情况:
- 主机1上面的进程想跟主机2上面的进程建立连接,同时主机2也要跟主机1上面的进程建立连接,他俩同时发送请求,会不会同时建立2个连接?
- 答案是不会的
- TCP的连接是一对socket作为标志的,这一对socket之前之能建立一个连接
- 连接以端地址 ~ 端地址为标识
- 即使两边发起同一连接,也不会建立两个连接,还是1个连接
- 建立过程
- 主机1上的进程发送一个连接请求给主机2,并选择自己的初始化序号x
- 主机1的请求还没到达之前,主机2也向主机1发送了一个连接请求并选择自己的初始化序号y
- 主机1上面的请求到达主机2,此时主机2的处理就不跟前面一样了,主机2发先主机1的信号来了,此时他正想跟主机1建立连接,而且也发送了一个请求,那么,此时他就
- 同意主机1,并且发送一个请求给主机1,但是他不会给自己选择一个新的初始化序号了,而是任然然选择之前发送给主机1的那个请求建立选择的序号,也就是任然是y
- 同时主机1这是也接收到了主机2发来的建立连接的请求,他的处理情况也同主机2一样,不会再选择新的初始化序号了,任然为x
- 因此,这任然是一个连接。
连接释放
- TCP A的用户打算关闭它在TCP B中对等的上层协议的操作
- TCP A发送一个FIN位置1的段,SEQ=151是上一次操作的继续,是TCP模块要求传输的下一个序号
- TCP B确认TCP A的FIN SEQ151,它的SEQ=188、ACK=152
- TCP B向其用户发出一个close原语
- TCP B用户应用程序确认同意关闭
- TCP B再发出最后一个段,FIN位置1并SEQ=188、ACK=152同上
- TCP A确认,ACK=189
- TCP A连接关闭
- TCP B连接关闭
- 注:握手用的报文长度仅一个字节
TCP传输策略
- TCP使用与数据链路层不同的窗口协议来实现流量控制
- 数据链路层:在数据链路层的滑动窗口协议中,发送窗口的滑动依赖于确认的到达
- TCP层:TCP的窗口大小是其缓冲区的尺寸,建立连接的双方都将分配一个缓冲区作为接收数据的存放空间,并相互通知对方,此后,每次对接收数据确认的同时发布一个窗口公告(window advertisement),报告剩余窗口的大小,任何时刻,剩余的缓冲区空间的数量叫窗口大小
- 零窗口公告
- 发送方收到一个零窗口公告时,必须停止发送,直到接收方重新发送一个非零的窗口公告,但有两种情况可以除外
- 发送紧急数据,如允许用户终止(kill)当前正在远端机上运行的进程
- 发送方可以发送一个字节的数据段通知对方,要求接收方重申希望接收的下一字节及当前的窗口大小,以防止可能的窗口公告丢失而导致的死锁
- 发送方收到一个零窗口公告时,必须停止发送,直到接收方重新发送一个非零的窗口公告,但有两种情况可以除外
TCP拥塞控制
- 数据的丢失有两种情况
- 接收方的容量太小(接收缓冲区)
- 网络的容量太小(网络带宽)
- 源主机如何知道拥塞
- 收到IP层的ICMP的源抑制报文
- 因报文丢失引起的超时(重发计时器)
- 差错控制可以用重发机制来解决,流量控制可以用接收方的接收窗口也可以解决,但是网络的拥塞呢? 如何解决?
- 发送方和接收方经过的不是一个网络,那么我怎么知道某段网络的容量是多少?我发送的容量不能超过他的容量
- 更何况TCP的数据是封装在IP包中的,IP包每次走的路径又不一样,这条不通过,下条也许就可以通过。
- 综合上面的问题,在TCP里面用一个拥塞窗口来表示
拥塞窗口
- 即TCP中发送方和接收方之间除了有接收方的接收窗口之外,还有一个拥塞窗口: 网络能够为我传递数据量的一个衡量标志
- 因此为了确保数据包的不丢失,我发送方的数据量必须小于你的接收窗口大小(这是流量控制的要求),同时也必须小于拥塞窗口,使得网络又能力帮我发送数据。
- 网络拥塞造成数据包丢失,重发机制进一步加剧了拥塞
- TCP的拥塞控制方案应将由接收方的容量和由网络的容量所产生的拥塞问题分别处理,除了已定义的接收窗口外,还定义了拥塞窗口,拥塞窗口的动态调整:一旦发现数据包丢失,则降低重发数据包的速率
- 接收方承认的接收窗口表示接收缓冲区的容量
- 拥塞窗口表示网络的容量
- 接收窗口和拥塞窗口,两者取其小
- TCP的拥塞控制方案应将由接收方的容量和由网络的容量所产生的拥塞问题分别处理,除了已定义的接收窗口外,还定义了拥塞窗口,拥塞窗口的动态调整:一旦发现数据包丢失,则降低重发数据包的速率
- 拥塞窗口的具体实现
- 拥塞窗口的初始化
- 连接建立时,发送方将拥塞窗口的初始大小设置为最大的数据段长度,并随后发一个最大长度的数据段,如该数据段在定时器超时前得到了确认,发送方在原来的拥塞窗口的基础上再增加一倍长度,发送两个数据段,如两个数据段都得到了确认,则再增加一倍长度,直到数据传输超时或到达接收方的窗口大小为止
- 当拥塞窗口的大小为n个数据段时,如果发送的n个数据段都得到了确认,那么此时拥塞窗口的大小即为n个数据段对应的字节数
- 拥塞窗口大小的修正
- 除接收窗口和拥塞窗口外,拥塞控制时还需指定一个临界值,临界值的初始值为64K,如果发生数据传输超时,则将临界值置为当前拥塞窗口的1/2,并使拥塞窗口恢复到最大的数据段长度,成功的传输使拥塞窗口按指数增加(成倍),到达临界值后将按线性增加(按最大的数据段长度)
- 选择发送数据量
- 取两个窗口的最小值作为可以发送的数据量
- 拥塞窗口的初始化
TCP定时器管理
- “ 保活 ”定时器
- 一旦建立连接,双方都将启动“ 保活 ”定时器,当连接长时间无数据传输,所设定的“ 保活 ”定时器超时,超时一方会发送一个探测报文检查对方是否存在,如没有得到响应,则终止连接
- 重发定时器(非常重要的一个定时器)
- TCP在发送一个数据段的同时,启动一个数据重发定时器,如果在定时器超时前该数据段被确认,则关闭该定时器
- 如果在确认到达之前定时器超时,则需要重发该数据段(并且该定时器重新开始计时)
- 重发定时器初始值的设定(就是定时的长度应该设置为多少)
- 与数据链路层点对点的情况不同,在TCP层,源站点与目的站点之间的网络距离是动态变化的,数据传输和信号传播时间的离散性很大,线路的状态更是瞬息万变
- 所以,重发定时器的初始值不宜设定为固定大小
- 重发定时器初始值的设定方法(经过一堆分析得到下面2种方法)
- 固定为βRTT
- 固定为往返时间估计值RTT的β倍,初期β= 2,但经验表明常量是很不灵活的,当环境发生变化时不能很好地适应
- 偏差值方法
-
偏差值D =αD0 + ( 1 -α) RTT0 - M0 - 超时值 = RTT + 4*D
-
- 固定为βRTT
- 持续定时器(解决流量控制当中的死锁问题)
- 如接收方向发送方发出一个零窗口公告,发送方当即停止发送,当接收方的上层处理了所收到的数据并释放了全部的缓冲区后,将向发送方发出一个新的窗口公告,以通知发送方可继续发送,如果此更新公告丢失,双方将相互等待,出现死锁
- 为防止死锁,每当发送方收到一个零窗口公告,即启动一个持续定时器,如持续定时器超时,发送方将向接收方发一探测报文(仅一字节) ,接收方的应答报文将避免相互等待(这正是上面所说:即使在发送方已收到一个零窗口通告,也允许发送一个字节的数据报询问对方)