本讲目的
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

第 3 讲 传输层协议及应用 PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on
  • Presentation posted in: General

本讲目的 : 理解传输层服务的原理 : 复用 / 分用 可靠数据传输 流量控制 拥塞控制 Internet 传输层的实现和实例 教科书参考 第3章. 本讲概述 : 传输层的服务 复用 / 分用 无连接的传输 : UDP 传输控制协议: TCP. 第 3 讲 传输层协议及应用. 传输层与网络层的关系. 因特网中的传输层充当 “ 收发室 ” 的角色 因特网中的网络层充当 “ 邮递业务 ” 的角色 两个层次之间的任务可以互换,但是在实现成本上可能存在巨大差别. 提供运行在不同主机中 进程间 的 逻辑通信 传输协议仅运行在端系统中

Download Presentation

第 3 讲 传输层协议及应用

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


3

本讲目的:

理解传输层服务的原理:

复用/分用

可靠数据传输

流量控制

拥塞控制

Internet传输层的实现和实例

教科书参考

第3章

本讲概述:

传输层的服务

复用/分用

无连接的传输: UDP

传输控制协议:TCP

第3讲传输层协议及应用


3

传输层与网络层的关系

  • 因特网中的传输层充当“收发室”的角色

  • 因特网中的网络层充当“邮递业务”的角色

  • 两个层次之间的任务可以互换,但是在实现成本上可能存在巨大差别


3

提供运行在不同主机中进程间的逻辑通信

传输协议仅运行在端系统中

传输 vs. 网络层服务 :

网络层:在端系统间进行通信

传输层:在进程间进行通信

依赖并加强了网络层的服务

application

transport

network

data link

physical

application

transport

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

logical end-end transport

传输服务和协议


3

Internet 传输服务:

可靠, 按序点对点递交 (TCP)

拥塞控制

流量控制

连接建立

不可靠的 (“尽力而为”), 无序的点对点或广播递交: UDP

不能提供的服务:

实时性

带宽承诺

可靠的广播通信

application

transport

network

data link

physical

application

transport

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

logical end-end transport

传输层协议


3

segment (段)- 传输层实体间交换数据的单位

TPDU: 传输层数据单元

M

M

M

M

application

transport

network

application

transport

network

application

transport

network

H

n

应用层对传输协议的复用/分用

分用:将接收到的段传递给正确的应用层进程

receiver

P3

P4

application-layer

data

segment

header

P1

P2

segment

H

t

M

segment


3

复用/分用:

基于发送方, 接收方的端口号, IP 地址

源, 目的端口 #s 存在于每个段中

用于特定应用的常用端口号(well-known port number):0~1023

复用:

应用层对传输协议的复用/分用

从多个应用进程获取数据, 用首部(便于随后的分用)封装数据

32 bits

源端口#

宿端口#

其他首部字段

应用层数据

(报文)

TCP/UDP 段格式


3

Source IP: C

Dest IP: B

source port: x

dest. port: 80

Source IP: C

Dest IP: B

source port: y

dest. port: 80

Source IP: A

Dest IP: B

source port: x

dest. port: 80

source port:23

dest. port: x

source port: x

dest. port: 23

复用/分用: 举例

Web客户端

主机 C

服务器 B

主机 A

端口的使用: 简单的 telnet 应用

Web

服务器 B

Web客户端

主机 A

端口的使用: Web 服务器


Udp rfc 768

“最简约的”Internet 传输协议

“尽力而为的” 服务, UDP 数据段可以:

丢失

应用数据不按序到达

无连接:

在UDP收发双方之间, 无需握手信号

每个 UDP 数据段的操作都互相独立

为什么需要 UDP?

无需建立连接 (会增加延迟)

简单: 在收发双方之间没有连接状态

段首较短

无拥塞控制: UDP 可按需要随时发送

UDP: 用户数据报协议 [RFC 768]


3

经常为流媒体应用使用

允许数据丢失

对传输速率敏感

其他 UDP用途 :

DNS

SNMP

若需要通过 UDP进行可靠传输:在应用层增加可靠性措施

在应用程序中-专门的出错恢复机制!

UDP: (续)

32 bits

源端口 #

宿端口 #

长度, UDP

段的字节数,

包括首部

checksum

length

应用层数据

(报文)

UDP 数据报格式


Udp checksum

发送方:

将段的内容看作一串16位整数

checksum: 作段内容的加法(补码和)

发送方将补码和放入 UDP checksum 字段

接收方:

对接收到的段内容进行补码和计算

检查计算结果是否与收到的校验和相等:

NO –查出错误

YES –没查出错误. 但是仍有可能存在错误?

UDP 校验和(checksum)

目标:检测传输段中的“错误”(e.g., 位错)


Tcp rfcs 793 1122 1323 2018 2581

全双工数据传输:

在同一连接上双向传输

MSS: maximum segment size(最大段字节数-1500,536,512)

面向连接:

握手过程 (交换控制信息) 在交换数据前初始化收发双方的状态,“三次握手”

流量控制:

发送方的发送速度不得超过接收方的处理速度

点对点:

一个发送方, 一个接收方

可靠, 按序的字节流 :

无 “报文边界”,无结构但有顺序

流水式控制:

TCP的拥塞和流量控制,设置窗口大小

发送& 接收缓存

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


Tcp p80

32 bits

source port #

dest port #

sequence number

acknowledgement number

head

len

not

used

rcvr window size

U

A

P

R

S

F

checksum

ptr urgent data

Options (可变长度-MSS)

应用数据

(可变长度)

TCP 段格式(p80)

URG: urgent data

(一般不用)

按发送数据的字节计算

(不是按段数!)

ACK: ACK #

valid

PSH: push data now

(一般不用)

# bytes

接收方愿意接受的

RST, SYN, FIN:

connection estab

(setup, teardown

commands)

Internet

checksum

(as in UDP)


Tcp seq s acks

Seq. #’s:

该数据段第一个字节在(整个报文)字节流中 “编号”

ACKs:

seq #为预期从对方发来的“下一个”字节的编号

积累的 ACK

Q:接收方如何接受失序的数据段

A: TCP 没有定义, - 由程序设计者决定

time

TCP seq. #’s 和 ACKs

Host B

Host A

User

types

‘C’

Seq=42, ACK=79, data = ‘C’

host ACKs

receipt of

‘C’, echoes

back ‘C’

Seq=79, ACK=43, data = ‘C’

host ACKs

receipt

of echoed

‘C’

Seq=43, ACK=80

简单的 telnet 场景


3

TCP: 可靠数据传输

event: data received

from application above

简化的发送方, 假设

  • 单向数据传输

  • 无流量, 拥塞控制

create, send segment

wait

for

event

event: timer timeout for

segment with seq # y

wait

for

event

retransmit segment

event: ACK received,

with ACK # y

ACK processing


3

TCP: 可靠数据传输

00sendbase = initial_sequence number

01 nextseqnum = initial_sequence number

02

03 loop (forever) {

04 switch(event)

05 event: data received from application above

06 create TCP segment with sequence number nextseqnum

07 start timer for segment nextseqnum

08 pass segment to IP

09 nextseqnum = nextseqnum + length(data)

10 event: timer timeout for segment with sequence number y

11 retransmit segment with sequence number y

12 compue new timeout interval for segment y

13 restart timer for sequence number y

14 event: ACK received, with ACK field value of y

15 if (y > sendbase) { /* cumulative ACK of all data up to y */

16 cancel all timers for segments with sequence numbers < y

17 sendbase = y

18 }

19 else { /* a duplicate ACK for already ACKed segment */

20 increment number of duplicate ACKs received for y

21 if (number of duplicate ACKS received for y == 3) {

22 /* TCP fast retransmit */

23 resend segment with sequence number y

24 restart timer for segment y

25 }

26 } /* end of loop forever */

简化的

TCP

发送方


Tcp ack

TCP ACK 规则

TCP 接收方的动作

延迟 ACK. 等待 500ms

看是否还有数据段到达. 如果没有,

发送ACK

立即发送一个

积欠的 ACK

发送重复的 ACK, 说明 seq. #

为下一个期望的字节

立即 ACK,如果数据段处于缺失的段的较低端

事件

有序数据段到达,

没有缺失的段,

所有其他数据段已经 ACKed

有序数据段到达,

没有缺失的段,

有一个延迟 ACK 等待

失序数据段到达

seq. # 高于预期值

测到间隔

到达的数据段部分或全部填满了缺失的段


3

Host A

Host B

Seq=92, 8 bytes data

ACK=100

timeout

X

loss

Seq=92, 8 bytes data

ACK=100

time

time

丢失 ACK 场景

TCP: 重传场景

Host A

Host B

Seq=92, 8 bytes data

Seq=100, 20 bytes data

Seq=92 timeout

ACK=100

ACK=120

Seq=100 timeout

Seq=92, 8 bytes data

ACK=120

过早超时,

积欠 ACKs


3

接收端:显式通知发送端 (动态变化中的) 自由缓存空间

RcvWindowTCP 数据段的字段

发送端:需要保存已经发送, unACKed 数据可少于最近收到的RcvWindow

流量控制

TCP 流量控制

发送端不可发送的太多、太快以至于使得接收端的缓存溢出

RcvBuffer= 接收端的 TCP 缓存大小

RcvWindow = 缓存中空闲的部分

接收端缓存


3

TCP 收发双方在数据交换开始之前需要建立连接

初始化 TCP变量:

seq. #s

缓存, 流量控制信息 (e.g. RcvWindow)

客户端:连接的发起者

Socket clientSocket = new Socket("hostname","port number"); -JAVA

服务器:接受客户端的连接

Socket connectionSocket = welcomeSocket.accept();

(建立连接)三次握手:

Step 1:客户端的end system向服务器发送 TCP SYN 控制数据段

定义并初始化 seq #

Step 2:服务器的end system接收 SYN, 用SYNACK控制数据段回答

ACKs 接收到的 SYN

分配缓存

定义 server-> receiver 初始化 seq. #

Step 3:客户端的end system向服务器发送ACK

ACKs 接收到的连接承诺

分配缓存

TCP 连接管理


3

关闭连接:

客户端关闭插口:clientSocket.close();

Step 1:客户端 发送 TCP FIN 控制段给服务器

Step 2:服务器 收到 FIN, 用 ACK应答. 关闭连接, 发送 FIN.

client

server

close

FIN

ACK

close

FIN

ACK

timed wait

closed

TCP 连接管理 (续)


3

Step 3:客户端 收到 FIN, 用 ACK进行应答.

随着对接收到的FIN发送ACK-同时进入“timed wait(计时等待)”

Step 4:服务器, 接收 ACK. 连接关闭.

注意: 稍加修改,即可管理同时发生的多个FINs.

TCP 连接管理 (续)

client

server

closing

FIN

ACK

closing

FIN

ACK

timed wait

closed

closed


3

TCP 连接管理 (续)

TCP 服务进程的生命周期

TCP 客户端实例的生命周期


3

拥塞:

非正式的说法: “过多信源以过快的速率发送了过多的数据、导致网络穷于应付”

不同于流量控制!

后果:

丢失数据分组 (路由器缓存溢出)

长时间的延迟 (在路由器的缓存中排队)

在网络发展的技术中的a top-10 problem!

拥塞控制原理


3

两个发送端, 两个接收端

一个路由器, 有限缓存

无重传机制

发生拥塞时的延迟

可达到的最大吞吐量

缘由/代价-拥塞问题:场景1


3

四个发送端

多步跳路径

超时/重传

l

l

in

in

缘由/代价-拥塞问题: 场景 2

Q:当 和 增加时发生了什么?


3

缘由/代价-拥塞问题 : 场景 2

拥塞的“代价”:

  • 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了!


3

端对端的拥塞控制:

没有来自网络的反馈信息

对拥塞问题的了解来自于对数据丢失和延迟的推断

由 TCP来解决

网络辅助的拥塞控制:

路由器向端系统提供反馈

用一比特位说明 (SNA, DECNet, TCP/IP ECN, ATM)

显式告知发送方所应采用的数据速率

拥塞问题的解决方案

两大类拥塞控制的办法:


Atm abr

ABR: available bit rate(可用数据速率):

“弹性服务”

如果发送方的路径“欠负载”

发送端应该把带宽用足

如果发送端路径拥塞:

发送端将其数据速率约束到最小承诺速率

RM (resource management) cells(资源管理信元):

由发送端发送, 掺和在数据信元一起

在 RM 信元中的数据位由交换机设定 (“网络辅助”)

NI bit:不得增加发送速率 (轻微拥塞)

CI bit:拥塞指示

RM信元由接收端返回给发送端, 所有数据位保持原样

案例研究: ATM ABR 拥塞控制


Atm abr1

在RM信元中有2字节的 ER (explicit rate) 字段

处于拥塞的交换机可降低信元中的ER 值

发送端的发送速率可以在路径上得到最低程度的支持

数据信元的EFCI 位: 在拥塞的交换机中被设成 1

如果在RM信元之前的数据信元的EFCI置1, 发送端将在返回的 RM的RM信元中将CI置1

案例研究: ATM ABR 拥塞控制


3

端到端的控制 (无需网络协助)

传输速率限制由建立在数据段之上的拥塞窗口尺寸Congwin决定:

w * MSS

吞吐量 =

Bytes/sec

RTT

TCP 拥塞控制

Congwin

  • w=数据段数量, 每个具有 MSS字节,在一个 RTT周期内发送:


3

两个 “阶段”

slow start(慢启动)

congestion avoidance(拥塞避免)

重要变量:

Congwin

threshold:定义两个慢启动之间,拥塞控制阶段的门限值

“刺探” 可用带宽:

理想情况:全速传输 (Congwin越大越好) 没有数据丢失

增加Congwin直到出现数据丢失 (拥塞)

数据丢失: 减小Congwin, 然后重新开始进行刺探(增加Congwin)

TCP 拥塞控制:


Tcp slowstart

窗口尺寸按指数递增 (每隔 RTT) (不算太慢!)

丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP)

Slowstart 算法

time

TCP Slowstart(慢启动)

Host A

Host B

one segment

RTT

initialize: Congwin = 1

for (each segment ACKed)

Congwin++

until (loss event OR

CongWin > threshold)

two segments

four segments


3

TCP 拥塞避免

拥塞避免

/* slowstart is over */

/* Congwin > threshold */

Until (loss event) {

every w segments ACKed:

Congwin++

}

threshold = Congwin/2

Congwin = 1

perform slowstart

1

1: 在出现三次重复的ACK后,TCP Reno 将跳过 slowstart (快速恢复 )

在此阶段,Congwin以线性方式增长,发生超时,门限值减半


3

TCP 拥塞避免策略:

AIMD:

additive increase(加法形式增加); multiplicative decrease(倍数形式减少)

每个RTT将窗口尺寸加1

当发生数据丢失时用2除窗口尺寸

AIMD

教科书:p90-91


3

TCP 公平性

公平性目标:如果 N TCP 会话共享瓶颈链路, 每个应该分得 1/N 链路传输能力

TCP connection 1

bottleneck

router

capacity R

TCP

connection 2


3

两个竞争性的会话:

当吞吐量增加时,加法的结果斜率为 1

而成倍递减则会等比减少连接的吞吐量

为什么说TCP是公平的?

带宽的

充分使用

同等的带宽共享

R

丢包: 以2为除数减小窗口来进行

拥塞避免: 加法形式增加窗口尺寸

连接 2 的吞吐量

loss: decrease window by factor of 2

congestion avoidance: additive increase

连接 1 的吞吐量

R


3

传输层服务原理:

复用/分用

可靠数据传输

流量控制

拥塞控制

因特网传输层的实现和实例

UDP

TCP

下一步:

离开网络的“边缘” (应用/ 传输层)

进入网络的 “核心”

本讲小结


  • Login