Ch7_Network
- 格式：pdf
- 大小：685.42 KB
- 文档页数：32
第七章运输层
⏹TCP/IP运输层协议概述
⏹用户数据报协议UDP
⏹传输控制协议TCP
第七章运输层2
请注意：对TCP来说，通信的起点和终点是运输层上面的两个插口(socket)，而应用层的应用进程正是通过应用层和运输层之间的插口来使用TCP提供的服务。
TCP协议根据报文段首部中的端口号（注意：插口是由IP地址和端口号决定的）找到目的端口，将报文段交付给目的进程。
对IP来说，通信的起点和终点是连接在网络上的两个主机。
IP协议根据数据报首部中的目的IP地址找到目的主机，将数据报交付给目的主机。
还应当注意的是：虽然在两个插口之间的通信是面向连接的，但IP数据报在下面的网络中传输时是独立地选择路
由，而不是沿着某一条固定的路径传输。
然而在上面的端口看来，TCP报文段好像都是从一个虚拟的、可靠的通信管道中传输到对方的端口。
第七章运输层6
第七章运输层
⏹TCP/IP运输层协议概述
⏹用户数据报协议UDP
⏹传输控制协议TCP
第七章运输层10
第七章运输层12
UDP checksum
U D P 数据报和T C P 段都包含一个12字节长的伪首部，它是为了计算检验和而设置的，计算检验和覆盖伪首部。
伪首部包含I P 首部一些字段。
其目的是让U D P 两次检查数据是否已经正确到达目的地（例如，I P 没有接受地址不是本主机的数据报，以及I P 没有把应传给另一高层的数据报传给U D P ）。
U D P
数据报中的伪首部格式：
UDP checksum
•U D P检验和覆盖U D P首部和U D P数据。
不同于I P 首部的检验和，它只覆盖I P的首部—并不覆盖I P数据报中的任何数据。
•U D P和T C P在首部中都有覆盖它们首部和数据的检验和。
U D P的检验和是可选的，而T C P的检验和是必需的。
•U D P检验和的基本计算方法与I P首部检验和计算方法相类似，采用16bit的二进制反码和。
•如果接收端检测到检验和有差错，那么U D P数据报就要被悄悄地丢弃。
不产生任何差错报文（当I P层检测到
I P首部检验和有差错时也这样做）
第七章运输层13
第七章运输层
⏹TCP/IP运输层协议概述
⏹用户数据报协议UDP
⏹传输控制协议TCP
第七章运输层14
TCP的数据编号与确认
Seq.#’s:
–报文段的第一个字节
在字节流中的序号ACKs:
–希望收到下一个字节
在对方的流序号
–ACK编号累积
Q:how receiver handles out-of-order segments
–A:TCP spec doesn’t
say,-up to
implementor
Host A Host B
S e q=4
2,A C K
=79,d
a t a=‘
C’
S e q=
79,A
C K=4
3,d a
t a=‘C
’
S e q=4
3,A C K
=80
User
types
‘C’
host ACKs
receipt
of echoed
‘C’
host ACKs
receipt of
‘C’,echoes
back‘C’
time
simple telnet scenario
第七章运输层17
糊涂窗口综合症及其解决方法——发送端产生的症状如果发送端为产生数据很慢的应用程序服务，例如，一次产生一个字节。
这个应用程序一次将一个字
节的数据写入发送端的TCP的缓存。
如果发送端的
TCP没有特定的指令，它就产生只包括一个字节数据
的报文段。
结果有很多41字节的IP数据报就在互连网
中传来传去。
解决的方法是防止发送端的TCP逐个字节地发送
数据。
必须强迫发送端的TCP收集数据，然后用一个
更大的数据块来发送。
发送端的TCP要等待多长时间呢？如果它等待过长，它就会使整个的过程产生较长
的时延。
如果它的等待时间不够长，它就可能发送较
小的报文段。
Nagle找到了一个很好的解决方法。
第七章运输层19
发送端的解决办法——Nagle算法
1.发送端的TCP将它从发送应用程序收到的第一块数据发送
出去，哪怕只有一个字节。
2.在发送第一个报文段（即报文段1）以后，发送端的TCP
就在输出缓存中积累数据，并等待。
当收到接收端的TCP 发送出的一个确认，或者数据已积累到可以装成一个最大的报文段，或者数据已积累到发送窗口的一半，在这个时候，发送端的TCP就立即发送这个报文段。
3.对剩下的传输，重复步骤2。
这就是：如果收到了对报文
段x的确认，或者数据已积累到可以装成一个最大的报文段，那么就发送下一个报文段(x+1)。
Nagle算法的优点就是简单，并且它考虑到应用程序产生数据的速率，以及网络运输数据的速率。
若应用程序比网络更快，则报文段就更大（最大报文段）。
若应用程序比网络慢，则报文段就较小（小于最大报文段）。
第七章运输层20
receiver buffering
接受端的解决办法
1.Clark解决方法Clark解决方法是只要有数据到达就发
送确认，但宣布的窗口大小为零，直到或者缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。
2.延迟的确认第二个解决方法是延迟一段时间后再发送
确认。
这表示当一个报文段到达时并不立即发送确认。
接收端在确认收到的报文段之前一直等待，直到输入缓存有足够的空间为止。
延迟的确认防止了发送端的TCP滑动其窗口。
当发送端的TCP发送完其数据后，它就停下来了。
这样就防止了这种症状。
迟延的确认还有另一个优点：它减少了通信量。
接收端不需要确认每一个报文段。
但它也有一个缺点，就是迟延的确认有可能迫使发送端重传其未被确认的报文段。
可以用协议来平衡这个优点和缺点，例如现在定义了确认的延迟不能超过500毫秒。
第七章运输层23
TCP的重传机制：
RTT（Round Trip Time）and RTO（Retransmission Time-out）
Q:怎样设置TCP的超时重传时延RTO?
•RTO＞RTT
–注意:RTT是离散
的，RTT是一个对网
络自适应的统计值。
•RTO太短:
–导致过多不必要的重
传。
•RTO太长:
–数据段的丢失，重传响应缓慢。
Q:RTO取决于RTT，怎样估计
RTT的值?
•RTT的采集：测量报文段的发
送时间和收到ACK应答时间的差
值。
–RTT采集忽略重传和累积应
答报文段的RTT时延
•RTT的统计：在最近若干次的
RTT采样值加权平均值中，加
入最新一次的RTT的样本值，
以“平滑”RTT的统计值。
第七章运输层24
TCP的重传机制：
RTT（Round Trip Time）and RTO（Retransmission Time-out）EstimatedRTT=α×EstimatedRTT+(1-α)×SampleRTT •加权移动平均计算EstimatedRTT
•使EstimatedRTT不会发生太快的变化
•典型α的值:7/8（0≤α＜1）
RTO（Retransmission Time-out）的估算
RTO=β×RTT
β＞1，一般取值为2报文段重传时间的修正
报文段每重传一次，就将重传时间增大：
New RTT=γ×Old RTT（γ典型值2）
当不再发生报文重传时，才根据报文段的RTT更新平均RTT和RTO
第七章运输层25
Congwin
•W个报文段，每个携带MSS字节在一个RTT中发送。
网络的吞吐量为：
throughput=w*MSS
RTT Bytes/sec
第七章运输层27
TCP congestion control
•拥塞控制的步骤
–慢开始（slow start ）–拥塞避免（congestion avoidance ）
•控制拥塞的重要参数–Congwin——拥塞窗口–threshold——慢开始的门限值
–理想的情况是无丢失发送尽可能的快，即Congwin 尽可能最大–增大Congwin 直到发送拥塞(congestion)丢包现象
–如发生拥塞，减小Congwin 直到，消除拥塞现象
TCP Connection Management
TCP client lifecycle TCP server lifecycle
第七章运输层32。
