Transcript 第六章：传输层

Chapter 6
The Transport Layer
Content
•
•
•
•
•
•
•
传输服务
传输协议的要素
一个简单的传输协议
Internet传输协议－UDP
Internet传输协议－TCP
性能问题
本章小结
传输层服务
•
•
•
•
提供给高层的服务
传输层服务原语
Berkeley 套接字
套接字编程示例:
–
文件服务器
向上层提供的服务
传输协议
数据单元
传输实体
1)服务
The network, transport, and application layers.
2)存在的原因
3)获得的好处
TPDU
TPDU、分组、和帧的嵌套
传输层服务原语
一套简单的传输层服务原语
基本使用过程。。。
传输层服务原语
一个简单的连接管理方案
右侧是客户机状态图
左侧是服务器状态图
Berkeley Sockets
The socket primitives for TCP.
Socket
Programming
Example:
Internet File
Server
6-6-1
客户端.
Socket
Programming
Example:
Internet File
Server (2)
服务器端.
传输协议的要素
•
•
•
•
•
•
编址
建立连接
释放连接
流控和缓存
复用
崩溃恢复
概述
传输服务是通过两个传输实体间的传输协议实现的
与链路层类似，需要处理错误控制、顺序管理、流管理等
两者运行环境不同
(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:
1. Idle – Connection not established yet.
2. Waiting – CONNECT has been executed, CALL REQUEST sent.
3. Queued – A CALL REQUEST has arrived; no LISTEN yet.
4. Established – The connection has been established.
5. Sending – The user is waiting for permission to send a packet.
6. Receiving – A RECEIVE has been done.
7. 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 (6)
The Example Transport Entity (7)
The Example Transport Entity (8)
The Example Transport Entity (9)
解除listen阻塞
解除connect阻塞
解除send阻塞
解除Receive阻塞
在执行send、
recieve 、
conncet原语时，
对方关闭了连接
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.
基于矩阵图的事件驱动编程
a)
b)
c)
死循环等待发生的事件
事件发生时根据状态来定位需要使用的程序段
每个程序段处理矩阵图中的一个表项
评注：
更加规范化和系统化
示例的 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
•
•
•
Birrell and Nelson (1984)做了主要的工作
简单说是允许程序调用处于远端主机的过程.
RPC的基本执行过程如图.
Client
Server
Blocked
Blocked
Computing
Blocked
Remote Procedure Call
•
•
•
•
呼叫方通过参数向被呼叫方传递信息；被呼叫方通过过程
的返回值向呼叫方传递信息.
消息的传输过程对程序员是不可见的.
呼叫方可以称为客户（发起连接），被呼叫方称为服务器
RPC基本思想是使得远程调用与本地调用类似。为了实现
这一基本思想，需要在客户机绑定到一个client stub，代表
服务器程序. client stub是一个小的库过程，作用就是隐藏
实际的计算过程是在服务器完成的。类似的，存在server
stub，隐藏远程调用这一事实
Remote Procedure Call
Step 1 客户进程调用client stub，本地执行，参数进入堆栈.
Step 2 client stub 把参数打包成消息，并通过系统调用发送消息。参数打包成
消息称为marshaling
Step 3 系统完成实际消息传输
Step 4 服务器系统把消息传给server stub.
step 5 server stub 使用unmarshaled parameters 来调用服务器过程
The reply traces the same path in the other direction.
Remote Procedure Call
•
通过上述过程我们看到，对于在客户机上编写程序的用户来说，
只是简单的发起了一次正常的对client stub的函数调用，并且调
用的过程名与服务器器端的名字一样
对于服务器过程，情况类似，只不过是被本机的其它过程正常
调用了一次而已
结果：
•
•
–
网络通信不是直接通过Sockets来实现，而是通过了一个伪造的“正常”
过程调用
Remote Procedure Call
•
问题
•
the use of pointer parameters
•
•
the use of pointer parameters .
•
•
•
例如不知道大小的两个向量内积
it is not always possible to deduce the types of the parameters
•
•
指向某些常规类型的指针可以传递
例如客户调用的printf函数的参数
global variables
实现
•
•
广泛应用
底层通信机制可以是UDP或者TCP
RTP
•
•
•
为多媒体应用定制的实时传输协议
使用UDP协议
可以描述为应用层上实现的传输协议：多媒体应用的各
种流首先送到RTP库，该库负责把多个流复用到RTP分组，
这些分组通过某个套接字传输出去。
The Real-Time Transport Protocol (2)
The RTP header.
Real-Time Transport Protocol
•
•
•
•
•
•
•
•
•
•
V：版本 2比特
P：填充标志（该分组是否被填充为4的倍数），实际的
填充数在padding counter中查看
X：扩展标志。被置位表示出现了扩展头
CC：CSRC 计数器
M：Marker，应用相关标记
Payload type：指明该分组使用的编码算法
sequence number：用编号来检测丢失的分组
Timestamp：用时戳来决定播放的时机
synchronization source (SSRC) identifier：指明该分组所属
的流，使得RTP得以完成其复用/解复用的功能
contributing source (CSRC) identifiers：使用混合器时在这
里列出各种应该被混合的流
Real-Time Transport Control Protocol
•
实时传输控制协议
•
•
•
•
向源提供有关延迟、抖动、带宽、拥塞和其它网络特性的反馈
信息
处理流同步
提供了一种命名各个源的方法
RTCP消息的种类和组成
•
•
•
•
•
SR(Sender Report)
RR(Receiver Report)
SDES(Source DEScription)
BYE
APP
•
在没有加密的情况下，每一个RTCP复合消息至少
由一个SR/RR加上一个包含了CNAME的SDES组成
RTCP SR消息格式
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|
RC
|
PT=SR=200
|
length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SSRC of sender
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |
NTP timestamp, most significant word
|
info
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
NTP timestamp, least significant word
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
RTP timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's packet count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's octet count
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |
SSRC_1 (SSRC of first source)
|
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
| fraction lost |
cumulative number of packets lost
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
extended highest sequence number received
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
interarrival jitter
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
last SR (LSR)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
delay since last SR (DLSR)
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
RTCP SR消息格式
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |
SSRC_2 (SSRC of second source)
|
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2
:
...
:
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
profile-specific extensions
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RC: reception report count
RTCP SDES消息格式
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|
SC
| PT=SDES=202 |
length
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk |
SSRC/CSRC_1
|
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SDES items
|
|
...
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk |
SSRC/CSRC_2
|
2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SDES items
|
|
...
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
a)
SDES item的种类
CNAME NAME EMAIL PHONE LOC
TOOL NOTE PRIV
实际的RTCP复合消息
因特网传输协议: TCP
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
TCP概述
TCP 服务模型
TCP 协议
TCP Segment 头部
TCP 建立连接
TCP 释放连接
TCP 连接管理模型
TCP Transmission Policy
TCP 拥塞控制
TCP Timer Management
无线 TCP and UDP
Transactional TCP
TCP简介
•
在不可靠的互联网络上提供一个可靠的端到端字节流
•
互联网络
•
•
•
•
•
•
拓扑，带宽，延迟，分组大小等
不可靠的互联网络
• 超时、重传、乱序
RFC 793、1122、1323
TCP传输实体 接受用户数据流，分割为数据段、以IP
数据报的形式发送每一个数据段；
TCP传输实体把IP层递交的TCP数据段重构为用户数据
流
TCP数据段大小取决于实现，受限于IP最大载荷和链路
的MTU
The TCP Service Model
Port
21
23
25
69
79
80
110
119
Protocol
FTP
Telnet
SMTP
TFTP
Finger
HTTP
POP-3
NNTP
Use
File transfer
Remote login
E-mail
Trivial File Transfer Protocol
Lookup info about a user
World Wide Web
Remote e-mail access
USENET news
套接字：套接字地址（端口）；可用于多个连接；知名端口；
守护进程Internet daemon（inetd）；分叉（fork）；
连接：全双工、点到点；字节流（下页图）
发送和接收：PUSH（不要缓存发送\递交），Urgent data（立即
发送，立即接收），基本协议为“滑动窗口协议”
The TCP Service Model (2)
(a) 以单独IP数据报的形式发送4个512字节的数据段
(b) 在1次Read调用中，2048字节被一次递交给应用程序
TCP的每个字节都有其独特的32位序列号
The TCP Segment Header
TCP Header.
The TCP Segment Header
在TCP校验和计算中的伪头部
The TCP Segment Header
•
•
•
选项允许主机指定其愿意接收的最大TCP净荷长度
如果最大的Windows SIZE64KB依旧不满足需要，可考
虑Windows scale(RFC1323)
滑动窗口+(选择重传、NAK)（RFC1106）
TCP Connection Establishment
6-31
(a) TCP connection establishment in the normal case.
(b) Call collision.
TCP连接的释放
a)
b)
看做一对单工连接来释放连接
需要定时器（2倍最大分组生存期）
TCP Connection Management Modeling
TCP连接管理的11种状态
TCP Connection Management Modeling (2)
TCP connection
management finite state
machine. The heavy solid
line is the normal path for a
client. The heavy dashed
line is the normal path for a
server. The light lines are
unusual events. Each
transition is labeled by the
event causing it and the
action resulting from it,
separated by a slash.
TCP Transmission Policy
确认+窗口
紧急数据&1字节数据段
传输策略
•
发送方可以根据接收方的接收窗口缓存
•
考虑telnet
•
•
•
为了避免数据太少的情况，考虑Nagle算法：
•
•
•
•
•
如果不缓存：发送、确认、窗口更新、回显
如果缓存：发送、确认+窗口更新+回显
首字节进入TCP，发送
其它字节，缓存等待首字节的确认
新的字节，缓存等待第二次发送数据的确认。。。
数据大于窗口一半，可以立即发送
愚笨窗口综合症
•
接收端应用每次读取一个字节
TCP Transmission Policy (2)
考虑Clark的解决方案：禁止接收方发送单字节的窗口更新数据段，应该有
了一定数量的可用空间之后再告诉发送方。这里的一定数量min{接收
方允许的最大数据段，缓冲区的一半}
TCP拥塞控制
•
•
•
针对拥塞的真正解决方案是减慢数据发送速率
原则上，分组守恒法则可以控制拥塞
检测拥塞
•
•
•
超时
控制拥塞
发送方尽量少发数据。。。
•
•
Min{拥塞窗口，接收窗口}
拥塞窗口变化
•
•
•
初始为MSS（最大数据段长度），然后指数增加，直到发生了超时
或者大于了接收窗口
超时后拥塞窗口重置为1个MSS，然后指数增加，直到大于阀值，然
后线性增长
阀值：初始64KB，超时后设置为超时的时侯拥塞窗口的一半
两个窗口
(a) A fast network feeding a low capacity receiver.
(b) A slow network feeding a high-capacity receiver.
慢启动、加性增、乘性减
An example of the Internet congestion algorithm.
TCP重传定时器
•
超时间隔应该有多长？
链路层和传输层确认到达时间的概率密度
TCP重传定时器
•
解决方案
•
`Jacobson：对于每一个连接，TCP维护一个变量RTT，表示该连接实际
所需RTT的估值
•
•
•
• RTT=RTT+(1 )M， 典型情况下=7/8
估值基本上是移动平均的概念，但是我们需要的是安全边际，RTT？
•
•
•
•
在每发送一个分段后，TCP启动一个定时器，既用于重传，
也用于测量实际RTT
以M表示某次测量所得RTT，则RTT的更新如下所示
Jacobson建议使用平均偏差D作为标准偏差的估计
D=D+(1  )|RTT  M|
实际中使用的超时间隔Timeout=RTT+4D
考虑重传对估值的影响（确认是对第一次的还是重传的？）
•
Karn建议已被重传的数据，不更新RTT，而是把Timeout
加倍
TCP其它定时器管理
•
持续定时器
•
•
用于流控，处理更新窗口的通知消息丢失的情况
保活定时器
•
•
源于杀死半开连接的方法。。。在规定时间内没有TPDU到来，则连接
被自动断开
TIMED WAIT 定时器
•
两倍最大分组生存时间，确保连接关闭后，连接上的分组都过期
无线TCP和UDP
•
按照分层设计的思想，无线TCP和UDP应该不存在问题，但
是。。。TCP实现通常都针对网络特性进行了“优化”，优化
的时候对网络存在一些基本假设。。。不幸的是，这些假设在
无线环境可能不满足
基本的问题是拥塞控制
有线超时通常因为网络拥塞，所以要少发；无线超时通常因为
信道错误，应该重传数据
解决方案
•
•
•
•
间接TCP，无线用一个TCP，有线用另外一个（下页图）；基站在两个
方向上拷贝数据
•
•
好处：可以区别对待
缺点：违反端到端的语义，例如确认不再意味着数据已
经被通信对方收到
Wireless TCP and UDP
Splitting a TCP connection into two connections.
无线TCP和UDP
•
解决方案
•
•
•
•
不破坏TCP语义的方法
在基站的网络层增加 监视代理：如果基站给主机发送了数据段，监视
代理缓存数据段；如果监视代理的定时器过期，基站没有收到确认，则
会重传；如果监视代理收到了主机的重传请求（重复的确认），也会重
传；监视代理过滤主机发送的一些重传请求（重复的确认）， 避免发送
方收到造成误判
如果无线链路很糟糕，源端在等待确认的时候会超时，从而再次启动拥
塞控制（注意到监视代理并不主动返回确认给源端）
上述方法可以进一步完善，让监视代理通过选择重传获得连续的TCP数
据段，从而可以过滤所有的来自主机的重传请求。
无线TCP和UDP
•
UDP的问题
•
•
有线上UDP是理论上消息可能会丢失但实际上很少丢失
无线UDP则是真的会丢失消息
Transitional TCP
(a) RPC using normal TPC.
(b) RPC using T/TCP. RFC1379 1644，实验性
性能问题
•
•
•
•
•
Performance Problems in Computer Networks
Network Performance Measurement
System Design for Better Performance
Fast TPDU Processing
Protocols for Gigabit Networks
千兆网带来的问题
The state of transmitting one megabit from San Diego to Boston
(a) At t = 0, (b) After 500 μsec, (c) After 20 msec, (d) after 40 msec.
改进网络性能的基本方法
The basic loop for improving network performance.
1. Measure relevant network parameters, performance.
2. Try to understand what is going on.
3. Change one parameter.
获得好的性能的设计原则
Rules:
1. CPU speed is more important than network speed.
2. Reduce packet count to reduce software overhead.
3. Minimize context switches.
4. Minimize copying.
5. You can buy more bandwidth but not lower delay.
6. Avoiding congestion is better than recovering from it.
7. Avoid timeouts.
响应时间与负载间的非线性关系
Response as a function of load.
环境切换造成的性能下降
Four context switches to handle one packet
with a user-space network manager.
Fast TPDU Processing
The fast path from sender to receiver is shown with a heavy line.
The processing steps on this path are shaded.
Fast TPDU Processing (2)
(a) TCP header. (b) IP header. In both cases, the shaded fields are taken
from the prototype without change.
Fast TPDU Processing (3)
时间轮
Protocols for Gigabit Networks
Time to transfer and acknowledge a 1-megabit file over a 4000-km line.