分解与复用

主机使用IP地址&端口号将报文段导向到相应的套接字

具有不同源IP地址和/或源端口号的IP数据报(目的IP地址和端口号相同)定向到相同的套接字

源IP地址和源端口号提供了返回地址


UDP

  • 尽力而为

    • 丢包
    • 对应用程序交付失序
  • 无连接

    • 在UDP发送方和接收方之间无握手
    • 每个UDP段的处理独立于其他段

常用于流媒体应用程序

  • 丢包容忍
  • 速率敏感

UDP报文结构:

[16位]源端口 [16位]目的端口
[16位]长度 [16位]检查和
数据

UDP检查和:

对发送方的UDP报文段的所有16比特字进行求和。当求和遇见溢出的时候,进行回卷。求和结束后再进行反码运算,得到的结果放在UDP报文段中的检验和字段。

UDP检查和举例.png


rdt协议(可靠传输协议)

不可靠信道需要可靠运输协议。

rdt1.0

rdt1.0:完全可靠信道上的可靠数据传输。

  • 底层信道完全可靠

  • 发送方将数据发向底层信道

  • 接收方从底层信道接收数据

rdt1.0.png

rdt2.0

rdt2.0:具有比特差错的信道。

  • 具有比特差错的底层信道

    • 比特差错

    • 分组丢失

  • 数据出错后处理方式

    • 检错重传
  • rdt2.0新增加机制(与rdt1.0比较)

    • 检错

    • 反馈:ACK, NAK

      • ACKnowledge Character

      • Negative Acknowledgment

    • 重传

工作方式

  • 无差错时情况:

    rdt2.0无差错.png

  • 有差错时情况

    rdt2.0有差错.png

流程图:

graph LR

发送方产生数据 --> 发送数据 --> C[接收方接收并分析数据]

C -.-> A((有差错)) -.返回 rdt_rcv & isNAK.-> 发送数据
C --> B((无差错)) --返回 rdt_rcv & isACK--> 发送方产生数据

缺陷

没有考虑ACK、NAK发生缺损的情况。

  • 如果ACK发生翻转,发送方会重传

  • 如果NAK发生翻转,发送方会误以为发送成功而不重传正确数据

rdt2.1

在2.0的基础上,发送方为每个发送出去的数据包添加0或1的序号,接收方只有在按顺序依次接收到0、1、0、1…号数据包时才会接受数据。

假设发送0号数据包:

  1. 接收方成功接受数据包,返回ACK,等待1号数据包;但是ACK发生了翻转,发送方收到NAK:

    发送方重传0号数据包,接收方不接受0号数据包,将数据包丢弃,并再次返回对0号数据包的ACK

    发送方收到NAK,明白自己发出去的0号数据包已经被成功接收了,开始进入下一状态,准备发送1号数据包

  2. 接收方接收到破损数据包,返回NAK,继续等待0号数据包;但是NAK发生了翻转,发送方收到ACK:

    发送方传输1号数据包,由于接收方在等待0号数据包,故接收到此数据包后不接受数据包,继续等待0号数据包,并使用0号数据包的 checksnum 返回对0号数据包的ACK

    发送方收到ACK,发现没有对0号数据包进行确认,明白对方没有收到0号数据包,重传数据包

(这段就这样吧,摆了,反正我考前一晚上是觉得自己弄明白了,至于再过个把俩星期能不能看明白我制造的文字垃圾那就只有马克思知道了)

rdt2.2

rdt2.2与2.1的区别在于去掉了NAK,而在ACK分组中显式指出分组编号。

在收到非期望分组或者收到的分组发生比特差错时,均对上次正确接收的分组反馈一个ACK。

rdt3.0

3.0同时考虑到封包遗失与资料错误的情形,除了使用ACK机制,另外在传送端多了倒数计时器,封包送出去如果超过时间仍未收到ACK或是收到不正确编号的ACK,则再送出封包一次。

  • 无丢包时如图:

    rdt3.0无丢包.png

  • 分组丢失时如图:

    rdt3.0分组丢失.png

  • ACK丢失时如图:

    rdt3.0ACK丢失.png

(写的是些什么寄吧,我在制造文字垃圾)

rdt3.0窗口太窄_过早重传.png

协议性能

停等协议

每发送一个分组,都要等待接收方回应。

停等协议.png

记分组长度为L,信道速率为R,则传输单个分组时间为:

$$\frac{L}{R}+RTT$$

信道利用率为:

$$\frac { \frac{L}{R} } {RTT + \frac{L}{R}}$$

流水线协议

序号范围增加、发送方与接收方设置缓存。

假设每次连续传输3个分组:

流水线协议.png

信道利用率为:

$$\frac { 3\frac{L}{R} } {RTT + \frac{L}{R}}$$

是停等协议的三倍。

滑动窗口协议

为了提高效率填满管道,在发送方等待确认时,应当有多个分组正在传送中。也就是说我们需要让多个分组处于等待确认的状态,以便在发送方等待确认的同时,信道也能保持忙碌状态。

  • 发送方和接收方都具有一定容量的缓冲区(即窗口),允许发送方连续发送多个帧而不需要等待应答。

  • 发送窗口就是发送端允许连续发送的帧的序号表,发送端可以不等待应答而连续发送的最大帧数称为发送窗口的尺寸

  • 接收窗口是接收方允许接收的帧的序号表,凡落在接收窗口内的帧,接收方都必须处理,落在接收窗口外的帧被丢弃。接收方每次允许接收的帧数称为接收窗口的尺寸

Go-Back-N协议

返回N协议(GO-Back-N GBN)的关键是发送方能够在收到确认之前发送多个分组,但接收方只能缓存一个分组。发送方为发送出去的分组保留副本,直到来自接收方确认达到。

GBN协议.png

GBN发送窗口.png

  • ACK机制:

    确认ACK(n): 确认到序列号n(不含n)的分组均已被正确接收,可能收到重复ACK。

  • 累积确认:

    发送拥有最高序列号的、已被正确接收的分组的ACK。

    接收方不需要给收到的数据分组逐个发送确认,而是可以在收到几个数据分组后对按序到达的最后一个数据分组发送确认,ACK(n)表示序号n之前的所有数据分组都已经成功接收

示例:

GBN示例

解释:窗口大小为4,发送方发送数据包0,1,2,3,然后进入等待状态,其中数据包2丢失,接收方返回Ack0,1,窗口滑动继续发送包4,5,此时包2计时超时,默认数据包2没有收到,按照GBN,发送方重新发送数据包2,3,4,5。

这里可以看出数据包重复了。

选择重传 SR

在GBN中,使用累积确认,为整个分组中最后一个得到确认的数据包发送ACK;

而在选择重传中,为每个数据包单独发布ACK。同时发送端也为每个分组单独配置计时器,当时间结束仍未收到ACK时,单独重传该分组。

选择重传示例

窗口长度选择

窗口长度小于等于序号空间的一半。


TCP

  • 面向连接

  • 流量控制

  • 拥塞控制

TCP报文结构

TCP报文结构.png

[2字节/16位]源端口 [16位]目的端口
[32位]序号seq
[32位]确认号ack
[4位]数据偏移 [6位]保留位 [6位]tcp flags 窗口
URG ACK PSH RST SYN FIN
检验和 紧急指针
TCP选项
应用层数据(变长)

序号:对数据字节计数(并非对报文段计数)
URG:紧急数据(一般不用)
ACK:ACK序号
PSH:立即提交数据(一般不用)
RST,SYN,FIN:连接建立(建立和拆连)
接收窗口:接收方允许的字节数

序号和确认号

    sequenceDiagram
    participant sender as 发送方
    participant reciver as 接收方

    activate sender
    Note left of sender: 用户键入c
        sender ->> reciver: seq=42, ack=79, data = ‘C’
    deactivate sender

    activate reciver
    Note right of reciver: 主机对收到的‘C’
给出确认
回显 ‘C’ reciver ->> sender: seq=79, ack=43, data = ‘C’ deactivate reciver activate sender Note left of sender: 主机对收到的回显‘c’
给出确认 sender ->> reciver: seq=43, ack=80 deactivate sender
  • 序号seq

    报文段中第一个数据字节在字节流中的位置编号

  • 确认号ack

    期望从对方收到下一个字节的序号,如果一切正常,应为对方发送过来的(seq+1)

TCP往返时延的估计与超时

如何设置TCP超时值?

  • 应大于RTT

  • 太短:过早超时,不必要重传

  • 太长:对报文段丢失的响应太慢,效率太低

如何估计RTT?

  • SampleRTT

    • RTT测量值

    • 从发送报文段到接收到ACK的测量时间

    SampleRTT会变化 –> 平均最近的测量值

  • EstimatedRTT

    *
    $$ EstimatedRTT = (1-α) * EstimatedRTT + α * SampleRTT $$



    $$ EstimatedRTT = EstimatedRTT + α * (SampleRTT-EstimatedRTT) $$

    • 典型 α=0.125
  • TimeoutInterval

    • EstimtedRTT加“安全余量”

    • 首先估算EstimtedRTT与真实RTT之间的差值

      $$ DevRTT = (1-β) * DevRTT + β * (|SampleRTT - EstimtedRTT|) $$

    • 最后计算TimeoutInterval

      *
      $$ TimeoutInterval = μ * EstimtedRTT + δ * DevRTT $$

      • 通常情况下,μ=1,δ=4,即

        $$ TimeoutInterval = EstimtedRTT + 4*DevRTT $$

    • 典型地,β=0.25

TCP可靠数据传输

  • TCP在IP不可靠服务的基础上创建可靠数据传输服务

  • 流水线发送报文段

  • 累计确认

  • TCP使用单个重传计时器

  • 重传被下列事件触发:

    • 超时事件

    • 重复ACK

TCP可靠数据传输属于滑动窗口方法

  • 发送方

    • 收到累积ACK,窗口向右滑动

    • 单个重传计时器,超时仅重传导致超时的报文段

    • 快速重传:冗余ACK

  • 接收方

    • 对收到的报文段进行缓存

    • 收到任何报文段时,均发出正确的累计确认

      • 即 举例:

        累计收到了1~8、11~12的报文段,则正确的累计确认为ACK=8

        • 若收到4~6报文,或12~14报文,均回复ACK=8

        • 若收到9~10报文,则正确的累计回复为ACK=12

TCP重传情况

丢失确认的情况.png

过早超时的情况.png

累计确认情况.png

快速重传

  • 超时间隔常常相对较长

    • 重传丢失报文段以前有长时延
  • 通过冗余ACK,检测丢失的报文段

    • 发送方经常一个接一个地发送报文段

    • 如果报文段丢失,将会收到很多重复ACK

  • 如果发送方连续收到3个相同ACK,便可以假定被确认的报文段之后的报文段丢失了,此时即使没有达到定时器超时时间,也采取重传措施

    • 快速重传:在定时器超时之前重传

TCP流量控制

  • TCP接收方有1个接收缓冲区

  • 应用进程可能从缓冲区读取数据缓慢

  • 匹配速度服务:发送速率需要匹配接收方应用程序的提取速率

TCP流量控制:发送方发送数据太快,导致接收方来不及接收时,需要进行流量控制

工作原理

TCP流量控制通过接收窗口字段来实现

  • 接收方计算缓存区的剩余空间——即接收窗口大小

  • RcvWindow= RcvBuffer-[LastByteRcvd -LastByteRead]

  • 接收方通过TCP首部的接收窗口字段反馈给发送方

  • 发送方根据接收窗口字段来限制发送窗口大小,以保证接收方缓存不溢出

TCP连接管理

TCP是面向连接的协议,TCP连接的建立和释放是每次TCP传输中必不可少的过程

TCP的连接传输包括三个状态

  • 连接建立

  • 数据传输

  • 连接释放

建立连接(三次握手)

第一次握手过程:

    sequenceDiagram
    participant sender as 客户机
    participant receiver as 服务器

    Note over sender,receiver: 第一次握手:连接请求报文
        sender ->> receiver: SYN=1,seq=X

SYN:同步序列编号
SEQ:序列号,表示当前数据传输字节的编号为X

语句含义:请求建立连接

目前字节编号:X

下一次编号:X+1

SEQ=X:身份标识

第二次握手过程:

    sequenceDiagram
    participant sender as 客户机
    participant receiver as 服务器

    sender ->> receiver: SYN=1,seq=X

    note over sender,receiver: 第二次握手:确认报文
        receiver ->> sender: SYN=1,seq=Y,ack=X+1

SYN:同步序列编号
SEQ:序列号
ACK:确认编号

目前字节编号:Y

下一次编号:Y+1

SEQ=Y:身份标识

第三次握手过程

    sequenceDiagram
    participant sender as 客户机
    participant receiver as 服务器

    sender ->> receiver: SYN=1,seq=X

    receiver ->> sender: SYN=1,ack=X+1,seq=Y

    note over sender,receiver: 第三次握手:确认报文
        sender ->> receiver: ack=Y+1,seq=X+1

SYN:同步序列编号
SEQ:序列号
ACK:确认编号

释放连接(四次挥手)

  • 第一次挥手:客户机向服务器发送FIN标识位

  • 第二次挥手:服务器收到FIN,回复ACK,并开始等待数据传输完毕。

  • 第三次挥手:服务器确认所有向客户机发送的数据传输完毕,同意断开连接,发送FIN标识位 她同意了

  • 第四次挥手:客户机收到FIN标识位,返回ACK

  • 第四次挥手之后:

    • 服务器方面:收到ACK后关闭连接

    • 客户机方面:发出ACK后等待2MSL时间,若没有收到新的响应信号则也关闭连接

  • MSL:Maximum Segment Lifetime,报文最大生存时间。
    • 如果在这个时间段内,服务器没有收到ACK应答报文段,会重发FIN报文段
    • 如果客户端收到了FIN报文段,那么2MSL的时间将会被重置。
    • 如果在2MSL时间段内,没有收到任何数据报,客户端会进入CLOSE状态。
    sequenceDiagram
    participant sender as 客户机
    participant receiver as 服务器

    activate sender
    note left of sender: 主动方发送FIN报文
并置发送序号为X
进入FIN-WAIT-1状态 sender ->> receiver: FIN=1,seq=X,ack deactivate sender activate receiver note right of receiver: 被动方发送ACK
并置发送序号
seq为Y,ack为X+1
服务器进入CLOSE_WAIT
等待关闭状态 receiver ->> sender: ACK=1,seq=Y,ack=X+1 deactivate receiver activate receiver note left of sender: 客户端进入FIN_WAIT_2 状态 note right of receiver: 服务器端确认所有
传输到客户端的数据传输完毕
发送[FIN,ACK]报文
随机生成序列号seq=Z
ack值不变,依然为X+1
服务器进入LASK_ACK
最后确认状态 receiver ->> sender: FIN=1,ACK=1,seq=Z,ack=X+1 deactivate receiver activate sender note left of sender: 客户端收到[FIN]后
返回ACK、seq、ack
seq为刚刚返回的ack
ack为刚刚返回的seq+1 sender ->> receiver: ACK=1,seq=X+1,ack=Z+1 deactivate sender note right of receiver: 服务器收到ACK后关闭连接 note left of sender: 发送ACK后,客户机进入
TIME_WAIT时间等待状态
等待2MSL后关闭连接

注:

  • 小写ack为TCP首部中的[确认号]部分,占32位
  • 大写ACK为TCP首部中tcp flags部分中的ACK标志位,占1位

简化版:

    sequenceDiagram
    participant sender as 客户机
    participant receiver as 服务器

    sender ->> receiver: FIN=1

    receiver ->> sender: ACK=1

    receiver ->> sender: FIN=1,ACK=1

    sender ->> receiver: ACK=1

拥塞控制原则

拥塞控制原理

  • 当大量分组进入网络,超出网络处理能力,会引起网络局部或整体性能下降,这种现象成为拥塞。不加控制的拥塞会导致整个网络瘫痪。

  • 与流量控制不同

    • 流量控制是端到端的控制

    • 拥塞控制是全局性的过程,涉及整个网络

  • 表现

    • 丢包

    • 长时延

拥塞控制起的作用

拥塞控制起的作用.png

拥塞控制的原因与开销

参考文章:TCP/IP之拥塞控制

情况一

拥塞原因与开销情况一.png

路由器速率有限制,故拥塞发生时,时延无限增大。

情况二

拥塞控制的原因与开销.png

  • 通常:λinout

  • 仅当丢包时,需要“完美的”重传:λ^’^inout

  • 迟延的分组(而不是丢失)的重传使得λ^’^in比(同完美情况相比)λout更大

拥塞的“代价”:

  • 比额定的吞吐量做更多的工作(重传)

  • 不必要重传:链路承载分组的多个拷贝

情况三

拥塞原因与开销情况三

  • 当分组被丢失时,任何用于传输该分组的上游传输能力都被浪费

拥塞控制的两类方法

  • 端到端的拥塞控制

    • 不能从网络得到明确的反馈

    • 从端系统根据观察到的时延和丢失现象推断出拥塞

    • TCP采取

  • 网络辅助的拥塞控制

    • 路由器为端系统提供反馈

    • 一个bit指示一条链路出现拥塞

    • 指示发送方按照一定速率发送

案例:ATM ABR拥塞控制

  • 通信过程简要描述

    • 发送方沿(建立好连接的)路径上不断传输数据信元管理信元,到达接收方

    • 接收方将管理信元(内容修改调整后)研路径返回(反馈)到发送方

TCP拥塞控制

  • 端到端控制

  • 发送方限制传输:滑动窗口法

  • 速率 = $\frac{CongWin}{RTT}(Bytes/sec)$

  • 拥塞窗口是动态的,具有感知到网络拥塞的函数

  • 发送方如何感知网络拥塞 ?

    • 丢失事件:超时或3个重复ACK

    • 发生丢失事件后,TCP发送方降低速率(拥塞窗口)

  • 三个机制

    • AIMD(加增倍减算法)

    • 慢启动

    • 超时事件后的保守机制

TCP加减倍增 AIMD

  • 乘性减:

丢包事件后,拥塞窗口值减半。

  • 加性增:

如没有检测到丢包时间,每个RTT时间拥塞窗口值增加一个MSS(最大报文段长度)

AIMD.png

TCP慢启动

概述:

  • 在连接开始时,拥塞窗口值 = 1 MSS

    • 例如: MSS = 500 bytes & RTT = 200 msec

    • 初始化速率 = 20 kbps

  • 可获得宽带可能 >> $\frac{MSS}{RTT}$

    • 希望尽快达到期待的速率
  • 当连接开始,以指数快地增加速率,直到第一个丢失事件发生

具体:

  • 当连接开始的时候,速率呈指数式上升,直到第1次报文丢失事件发生为止:

    • 每RTT倍增拥塞窗口值

    • 每收到ACK,增加拥塞窗口

TCP慢启动.png

总结:初始效率很低,但以指数快地增长

超时后的保守机制

  • 基本思想

    • 三个冗余ACK指示网络还具有某些传送报文段的能力

    • 直接超时,则更为“严重”

  • 收到三个冗余确认

    • CongWin减半

    • 窗口再线性增加

  • 但是超时事件以后

    • CongWin值设置为1 MSS

    • 窗口再指数增长

    • 到达一个阈值后,再线性增长

如图

TCP拥塞控制.png

①处,慢启动达到阈值,进入拥塞避免阶段,CongWin线性增长

②处,遭遇超时事件,CongWin设为1 MSS,重新慢启动,并且将阈值设为发生事件时CongWin的一半,即12

③处,达到②中设定的阈值,开始线性增长

④处,遭遇3 ACK事件,CongWin减半,来到⑤处,并且将阈值也设为原CongWin的一半

⑤处,窗口线性增长

TCP吞吐量

TCP平均吞吐量是窗口长度和RTT的函数

  • 设:窗口长度为W,则$ 吞吐量 = \frac{W}{RTT} $

  • 当丢包发生后,窗口降为$ \frac{W}{2} $,于是吞吐量降为$ \frac{W}{2RTT} $

  • 一个连接的平均吞吐量为$ \frac{0.75W}{RTT} $

实际网络性能分析中TCP吞吐量是复杂函数