3传输层

字数 5672阅读 79

3.1传输层服务

3.1.1传输层服务概述

传输层服务和协议

■传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制

■端系统运行传输层协议§ 发送方:将应用递交的消息分成一个或多个的Segment,并向下传给网络层。

§ 接收方:将接收到的segment组装成消息,并向上交给应用层。

■传输层可以为应用提供多种协议§Internet上的TCP§Internet上的UD

传输层vs.网络层

v■网络层:提供主机之间的逻辑通信机制v■传输层:提供应用进程之间的逻辑通信机制§ 位于网络层之上

§ 依赖于网络层服务§ 对网络层服务进行(可能的)增强

Internet传输层协议

v■可靠、按序的交付服务(TCP)§ 拥塞控制§ 流量控制§ 连接建立v■不可靠的交付服务(UDP)§ 基于“尽力而为(Best-effort)”的网络层,没有做(可靠性方面的)扩展■v两种服务均不保证§ 延迟§ 带宽

3.2多路复用和多路分用

Why?v 如果某层的一个协议对应直接上层的多个协议/实体,则需要复用/分用



分用如何工作?

v■主机接收到IP数据报(datagram)

§ 每个数据报携带源IP地址、目的IP地址。§ 每个数据报携带一个传输层的段(Segment)。

§ 每个段携带源端口号和目的端口号

v■主机收到Segment之后,传输层协议提取IP地址和端口号信息,将Segment导向相应的Socket

`TCP做更多处理



无连接分用

■利用端口号创建

SocketDatagramSocket mySocket1 = new DatagramSocket(99111);

DatagramSocket mySocket2 = new DatagramSocket(99222);

■UDP的Socket用二元组标识§(目的IP地址,目的端口号)

■主机收到UDP段后§ 检查段中的目的端口号§ 将UDP段导向绑定在该端口号的Socket

■来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket (源端口号提供返回地址)



面向连接的分用

■TCP的Socket用四元组标识

§ 源IP地址

§ 源端口号

§ 目的IP地址

§ 目的端口号

■接收端利用所有的四个值将Segment导向合适的Socketv

■服务器可能同时支持多个TCP Socket

§ 每个Socket用自己的四元组标识

■Web服务器为每个客户端开不同的Socket



面向连接的分用:多线程Web服务器



3.3无连接传输协议-UDP

UDP: User Datagram Protocol [RFC 768]

v ■基于Internet IP协议§ 复用/分用§ 简单的错误校验

(端到端的原则:不能保证下面各层都有错误检测机制,也不能保证在各层传输过程中不会出错,所以需要在靠近应用层做一个错误校验。)

■“Best effort”服务,UDP段可能

§ 丢失

§ 非按序到达

■无连接

§UDP发送方和接收方之间不需要握手

§ 每个UDP段的处理独立于其他段

UDP为什么存在?

无需建立连接(减少延迟)

实现简单:无需维护连接状态

 头部开销少

没有拥塞控制:应用可更好地控制发送时间和速率

v■常用于流媒体应用

§ 容忍丢失

§ 速率敏感

v■UDP还用于

§DNS

§SNMP

v■在UDP上实现可靠数据传输?

§ 在应用层增加可靠性机制§ 应用特定的错误恢复机制



UDP校验和(checksum)

目的:检测UDP段在传输中是否发生错误(如位翻转)

v■发送方

§ 将段的内容视为16-bit整数

§ 校验和计算:计算所有整数的和,进位加在和的后面,将得到的值按位求反,得到校验和

§ 发送方将校验和放入校验和字段

v■接收方§ 计算所收到段的校验和

§ 将其与校验和字段进行对比

• 不相等:检测出错误

• 相等:没有检测出错误(但可能有错误)



3.4可靠数据传输的原理

■什么是可靠?

§ 不错、不丢、不乱

■可靠数据传输协议

§ 可靠数据传输对应用层、传输层、链路层都很重要

§ 网络Top-10问题

§ 信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

可靠数据传输协议基本结构:接口



可靠数据传输协议

v■渐进地设计可靠数据传输协议的发送方和接收方

v■只考虑单向数据传输

§ 但控制信息双向流动

v■利用状态机(Finite State Machine, FSM)刻画传输协议



Rdt 1.0:可靠信道上的可靠数据传输

v■底层信道完全可靠

Ø不会发生错误(bit error)

Ø不会丢弃分组

v■发送方和接收方的FSM独立



Rdt 2.0:产生位错误的信道(会有位错误)

v ■底层信道可能翻转分组中的位(bit)§ 利用校验和检测位错误

v■如何从错误中恢复?

§ 确认机制(Acknowledgements, ACK):接收方显式地告知发送方分组已正确接收

§NAK:接收方显式地告知发送方分组有错误§ 发送方收到NAK后,重传分组

v ■基于这种重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议

v ■Rdt 2.0中引入的新机制

§ 差错检测

§ 接收方反馈控制消息: ACK/NAK

§ 重传



停等协议:发送方没有收到接收方的确认ACK不会发送下一个分组。

Rdt 2.0有什么缺陷?

v ■如果ACK/NAK消息发生错误/被破坏(corrupted)会怎么样?Ø 为ACK/NAK增加校验和,检错并纠错(花销较大)

Ø 发送方收到被破坏ACK/NAK时不知道接收方发生了什么,添加额外的控制消息(额外消息任然可能会坏掉)

Ø 如果ACK/NAK坏掉,发送方重传

Ø 不能简单的重传:产生重复分组

v ■如何解决重复分组问题?

§序列号(Sequence number):发送方给每个分组增加序列号§ 接收方丢弃重复分组





Rdt 2.1 vs. Rdt 2.0

v■发送方:·p为每个分组增加了序列号·p两个序列号(0, 1)就够用,为什么?(因为使用了停等协议)·p需校验ACK/NAK消息是否发生错误·p状态数量翻倍p状态必须“记住”“当前”的分组序列号v■接收方p·需判断分组是否是重复p当前所处状态提供了期望收到分组的序列号p·注意:接收方无法知道ACK/NAK是否被发送方正确收到

Rdt 2.2:无NAK消息协议

v ■与rdt 2.1功能相同,但是只使用ACK

v ■如何实现?

Ø 接收方通过ACK告知最后一个被正确接收的分组Ø 在ACK消息中显式地加入被确认分组的序列号(发送确定收到最后一个分组的序列号)

v ■发送方收到重复ACK之后,采取与收到NAK消息相同的动作Ø 重传当前分组



Rdt 3.0

■如果信道既可能发生错误,也可能丢失分组,怎么办?

§ “校验和+序列号+ ACK +重传”够用吗?加定时器

v■方法:发送方等待“合理”时间§ ·如果没收到ACK,重传

§ ·如果分组或ACK只是延迟而不是丢了

•重传会产生重复,序列号机制能够处理

•接收方需在ACK中显式告知所确认的分组

§ ·需要定时器



Rdt 3.0性能分析

v■Rdt 3.0能够正确工作,但性能很差

v■示例:1Gbps链路,15ms端到端传播延迟,1KB分组



§ 发送方利用率:发送方发送时间百分比



§ 在1Gbps链路上每30毫秒才发送一个分组è33KB/sec§ 网络协议限制了物理资源的利用

3.5流水线机制与滑动窗口协议





流水线协议

■允许发送方在收到ACK之前连续发送多个分组§ 更大的序列号范围§ 发送方和/或接收方需要更大的存储空间以缓存分组



滑动窗口协议



v■滑动窗口协议: Sliding-window protocol

v■窗口§ 允许使用的序列号范围§ 窗口尺寸为N:最多有N个等待确认的消息

v■滑动窗口

§ 随着协议的运行,窗口在序列号空间内向前滑动

v■滑动窗口协议:GBN, SR

Go-Back-N(GBN)协议:发送方

■分组头部包含k-bit序列号

v■窗口尺寸为N,最多允许N个分组未确认(累积N确认,N之前的全部都确认收到了)



v■ACK(n):确认到序列号n(包含n)的分组均已被正确接收§ 可能收到重复ACK

■为空中的分组设置计时器(timer)

v■超时Timeout(n)事件:重传序列号大于等于n,还未收到ACK的所有分组





■ACK机制:发送拥有最高序列号的、已被正确接收的分组的ACK§ 可能产生重复ACK

§ 只需要记住唯一的expectedseqnum

v■乱序到达的分组:

§ 直接丢弃

è接收方没有缓存

§ 重新确认序列号最大的、按序到达的分组



Selective Repeat协议

v■GBN有什么缺陷?

v■接收方对每个分组单独进行确认

§ 设置缓存机制,缓存乱序到达的分组

v■发送方只重传那些没收到ACK的分组

§ 为每个分组设置定时器

v■发送方窗口

§N个连续的序列号

§ 限制已发送且未确认的分组



SR协议

■发送方的时间和动作

从上层收到数据:检查下一个可用分组的序号,如果序号是在窗口内则打包发送,

超时:重发分组,重新定时

收到ACK(n),在窗口内,就会将已确认的分组标记为已接收。如果这个分组是该窗内最小分组即send_base就挪动窗口,发送窗口内为发送的分组。

■接收方的时间和动作

分组序号在[rcvbase, rcvbase+N-1]:发送ACK(n),超过则缓冲,在序号内,滑动窗口,并且将已经确认有序的分组交付给上层。

序号在[rcvbase-N,rcvbase-1]:发送ACK(n)。

■其他情况:忽略



问题:序列号空间大小与窗口尺寸需满足什么关系?§N_send+N_recv<=2k

3.6面向连接传输协议-TCP

TCP概述: RFCs-793, 1122, 1323, 2018, 2581

v■点对点§ 一个发送方,一个接收方

v■可靠的、按序的字节流v■流水线机制

§TCP拥塞控制和流量控制机制设置窗口尺寸

v■发送方/接收方缓存

v■全双工(full-duplex)§ 同一连接中能够传输双向数据流

v■面向连接§ 通信双方在发送数据之前必须建立连接。

§ 连接状态只在连接的两端中维护,在沿途节点中并不维护状态。

§TCP连接包括:两台主机上的缓存、连接状态变量、socket等

v■流量控制机制

TCP段结构



TCP:序列号和ACK

序列号:§ 序列号指的是segment中第一个字节的编号,而不是segment的编号

§ 建立TCP连接时,双方随机选择序列号ACKs:

§ 希望接收到的下一个字节的序列号

§ 累计确认:该序列号之前的所有字节均已被正确接收到Q:接收方如何处理乱序到达的Segment?

§A: TCP规范中没有规定,由TCP的实现者做出决策

TCP可靠数据传输概述

v■TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务

v■流水线机制

v■累积确认

v■TCP使用单一重传定时器

v■触发重传的事件

§ 超时

§ 收到重复ACK

v■渐进式

§ 暂不考虑重复ACK

§ 暂不考虑流量控制

§ 暂不考虑拥塞控制

TCP RTT和超时

v■问题:如何设置定时器的超时时间?

v■大于RTT§ 但是RTT是变化的

v■过短:

§ 不必要的重传

v■过长:

§ 对段丢失时间反应慢

v■问题:如何估计RTT?

v■SampleRTT:测量从段发出去到收到ACK的时间

§ 忽略重传

v■SampleRTT变化

§ 测量多个SampleRTT,求平均值,形成RTT的估计值EstimatedRTT





TCP发送方事件

v■从应用层收到数据§ 创建Segment§ 序列号是Segment第一个字节的编号

§ 开启计时器§ 设置超时时间:TimeOutInterval

v■超时

§ 重传引起超时的Segment

§ 重启定时器(只重传一个超时的那个)

v■收到ACK

§ 如果确认此前未确认的Segment

• 更新SendBase

• 如果窗口中还有未被确认的分组,重新启动定时器

TCP发送端程序 (伪码)









快速重传机制

v■TCP的实现中,如果发生超时,超时时间间隔将重新设置,即将超时时间间隔加倍,导致其很大

§ 重发丢失的分组之前要等待很长时间

v■通过重复ACK检测分组丢失

§Sender会背靠背地发送多个分组

§ 如果某个分组丢失,可能会引发多个重复的ACK

v■如果sender收到对同一数据的3个ACK,则假定该数据之后的段已经丢失

§ 快速重传:在定时器超时之前即进行重传



TCP流量控制





TCP连接管理

v■TCP sender和receiver在传输数据前需要建立连接

v■初始化TCP变量

§Seq. #

§Buffer和流量控制信息

v■Client:连接发起者Socket clientSocket = new Socket("hostname","port number");

v■Server:等待客户连接请求Socket connectionSocket = welcomeSocket.accept();

三次握手协议:


(1)[endif]第一次握手:Client将标志位SYN置为1,随机产生一个值seq=client_isn,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。

(2)第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=client_isn+1,随机产生一个值seq=server_isn,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。(3)第三次握手:Client收到确认后,检查ack是否为client_isn+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=server_isn+1,并将该数据包发送给Server,Server检查ack是否为server_isn+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。

TCP为什么是三次握手,为什么不是两次或四次?

如果两次握手的话,客户端有可能因为网络阻塞等原因会发送多个请求报文,这时服务器就会建立连接,浪费掉许多服务器的资源.如果四次握手:三次已经互相确认了可以进行连接了,在来一次确认浪费资源



TCP连接管理:关闭

Step 1: client向server发送TCP FIN控制segment

Step 2: server收到FIN,回复ACK.关闭连接,发送FIN.

Step 3: client收到FIN,回复ACK.

§ 进入“等待” –如果收到FIN,会重新发送ACK

Step 4: server收到ACK.连接关闭







3.7拥塞控制原理

拥塞(Congestion)

v■非正式定义:“太多发送主机发送了太多数据或者发送速度太快,以至于网络无法处理”

v■表现:§ 分组丢失(路由器缓存溢出)

§ 分组延迟过大(在路由器缓存中排队)

v■拥塞控制vs.流量控制











拥塞控制的方法

v■端到端拥塞控制:

§ 网络层不需要显式的提供支持

§ 端系统通过观察loss,delay等网络行为判断是否发生拥塞

§TCP采取这种方法

v■网络辅助的拥塞控制:

§ 路由器向发送方显式地反馈网络拥塞信息§ 简单的拥塞指示(1bit):SNA,DECbit, TCP/IP ECN, ATM)

§ 指示发送方应该采取何种速率

案例:ATM ABR拥塞控制

v■ABR:available bit rate

§ ·“弹性服务”

§· 如果发送方路径“underloaded”•使用可用带宽

§ ·如果发送方路径拥塞•将发送速率降到最低保障速率

v■资源管理单元RM(resource management cells)

§ 发送方发送§ 交换机设置RM cell位(网络辅助)

•NI bit: rate不许增长

•CI bit:拥塞指示§RM cell由接收方返回给发送方



v ■在RM cell中有显式的速率(ER)字段:两个字节

§ 拥塞的交换机可以将ER置为更低的值

§ 发送方获知路径所能支持的最小速率

v ■数据cell中的EFCI位:拥塞的交换机将其设为1

§ 如果RM cell前面的data cell的EFCI位被设为1,那么发送方在返回的RM cell中置CI位

3.8TCP拥塞控制

TCP拥塞控制的基本原理

v■Sender限制发送速率LastByteSent-LastByteAcked<= CongWin.



v■CongWin:§ 动态调整以改变发送速率§ 反映所感知到的网络拥塞

■问题:如何感知网络拥塞?

Loss事件=timeout或3个重复ACKv发生loss事件后,发送方降低速率

■如何合理地调整发送速率?

加性增—乘性减: 

AIMDv慢启动: SS

加性增—乘性减: AIMD

v■原理:逐渐增加发送速率,谨慎探测可用带宽,直到发生lossv

■方法: AIMD§Additive Increase:每个RTT将CongWin增大一个MSS——拥塞避免

§Multiplicative Decrease:发生loss后将CongWin减半



TCP慢启动: SS

v■TCP连接建立时,CongWin=1

§ 例:MSS=500 byte,RTT=200msec

§ 初始速率=20k bps

■可用带宽可能远远高于初始速率:

§ 希望快速增长

v■原理:

§ 当连接开始时,指数性增长



v■指数性增长§ 每个RTT将CongWin翻倍

§ 收到每个ACK进行操作v

■初始速率很慢,但是快速攀升



Threshold变量

■Q:何时应该指数性增长切换为线性增长(拥塞避免)?

A:当CongWin达到Loss事件前值的1/2时.

■实现方法:v 变量ThresholdvLoss事件发生时, Threshold被设为Loss事件前CongWin值的1/2。



Loss事件的处理

v ■3个重复ACKs:

§CongWin切到一半

§ 然后线性增长v

 ■Timeout事件:

§CongWin直接设为1个MSS

§ 然后指数增长

§ 达到threshold后,再线性增长

注:3个重复ACKs表示网络还能够传输一些segments,timeout事件表明拥塞为严重

TCP拥塞控制:总结

■当congwin小于Threadhold,发送方处于满启动状态,congwin以指数增长。

■当congwin在Threadhold以上,发送方处于拥塞避免阶段,congwin以线性增长

■当出现拥塞事件的时候,Threadhold更新为congwin/2,congwin为Threadhold大小

■当出现超时事件时,Threadhold更新为congwin/2,congwin设置为1





TCP性能分析

TCP throughput:吞吐率

v■给定拥塞窗口大小和RTT,TCP的平均吞吐率是多少?

§ 忽略掉Slow start

■假定发生超时时CongWin的大小为W,吞吐率是W/RTT

v■超时后,CongWin=W/2,吞吐率是W/2RTT

v■平均吞吐率为:0.75W/RTT





TCP的公平性



TCP是公平的


连接1,2的速率增加到拥塞时同时减半,然后有增加,最终会收敛于45°斜线

v■公平性与UDP

§ 多媒体应用通常不使用TCP,以免被拥塞控制机制限制速率

§ 使用UDP:以恒定速率发送,能够容忍丢失

§ 产生了不公平

v■公平性与并发TCP连接

§ 某些应用会打开多个并发连接§Web浏览器§ 产生公平性问题v

■例子:链路速率为R,已有9个连接

§ 新来的应用请求1个TCP,获得R/10的速率

§ 新来的应用请求11个TCP,获得R/2的速率

推荐阅读更多精彩内容