计算机网络 - 传输层

Transport-Layer Services

Transport layer, 传输层主要是完成进程(proces)到进程(process)之间的通讯的. 在传输层之下的IP协议, 提供的是best-effort的传输, 也就是对信息的正确性没有保证, 也就是IP的协议是unreliable的,

1. TCP的协议是在IP协议至少提供可靠的数据传输. UDP没有提供
2. 因为IP协议是主机到主机的, 所以Transport Layer的协议具有multiplexing以及demultiplexing的, 也就是多路复用与解复用

多路解复用的原理

TCP或者UDP将报文的数据部分交给正确的socket, 从而交给正确的进程. (主机联合使用ip地址和端口号将报文段发送给合适的套接字)

UDP

UDP比较简单, 基本上就是多路复用跟解复用, 再没有更多的功能了, 所以也可以理解成application跟IP层的通讯

为什么要有UDP

• 不需要要链接
• 简单
• 没有拥塞控制, 所以可以尽快地发送报文

checksum

• 每两个16bit的整数相加
• 进位回滚获得checksum
• 验证的时候, 所有的16的数据还有checksum相加, 如果为1, 则通过验证

可靠数据传输rdt的原理 (划重点🔥🔥🔥)

rdt1.0

下层的通信完全可靠

那么发送方跟接收方都是可以等待上层调用就好了

rdt2.0

下层可能会出现比特差错, 就是checksum不对. 这时候需要发送ACK

• 发送方发完之后需要等待ACK/NAK
• 接收方需要发送ACK/NAK确认

rdt2.1

如果ACK/NAK出错怎么办?

需要添加序号

发送方

有两个state: 0和1, 发送之后进入0 state的确认, 然后进入1 state等待调用, 如此重复

接收方

rdt2.2 无NAK协议

功能同rdt2.1, 但只使用ACK, 带编号的ack

rdt3.0 具有比特差错和分组丢失

下层可能会丢失分组

那么就等待ACK一段时间, 超时重传

rdt3.0的性能

可以工作, 但是在链路容量比较大的时候, 性能很差

Usender指的是利用率, 如果发一个等回复再发, 利用率就是取决于RTT

提高利用率可以使用流水线的发生方法

流水线协议

允许发送方在未得到对方确认的情况下一次发送多个分组

• 必须增加序号的范围
• 发送方/接收方需要有缓存区

两个通用的协议: GBN(Go back N - 退回N步)和SR(Select repeart - 选择重传)

滑动窗口(slide window)协议

其实就是缓存, 比如缓存容量是5个数据, 那么一次可以发5个数据到对方的缓存, 如果对方确认了, 那么滑动窗口移动1步, 发送方可以继续发送一个数据

这里有一点需要注意的就是滑动窗口向右移动需要最左边的数据确认才能移动, 如果3先确认了, 窗口还是不能移动的, 这样保证了左边的数据都是确认过的

GBN vs SR

GBN: 接收端的窗口尺寸=1, 也就是一旦一个分组没有发送成功, 如0,1,2,3,4, 如果1未成功的话,234都需要再发送. 因为如果接收方收到的分组是乱序的, 是直接丢弃掉的

SR: 接收窗口>1, 发送0,1,2,3,4，一旦1未成功，2,3,4,已发送，无需重发，选择性发送1

TCP

overview

• 点对点通讯, 一个发送方, 一个接收方
• 可靠有序的字节流
• 管道化(流水线)
• 双向数据流动
• 面向连接 - 三次握手的链接
• 流量控制

TCP往返演示(RTT)和超时

1. 怎么评估RTT (round trip time)?

EstimatedRTT = (1- a)*EstimatedRTT + a * SampleRTT

推荐值: a = 0.125 R

这个EstimatedRTT 就是指数加权移动平均

1. 怎么设置超时?

EstimtedRTT + 安全边界时间

DevRTT = (1-b)*DevRTT + b*|SampleRTT-EstimatedRTT|
推荐值: b=0.25

imeoutInterval = EstimatedRTT + 4*DevRTT

可靠数据传输

rdt

• 管道化的报文段 (缓存)
• 累积确认(像GBN)
• 单个重传定时器(像GBN)

重传

• 超时
• 重复确认 (收到了ACK之后之后又收到了3个相同的ACK)

快速重传

快速重传是避免超时周期过长

流量控制

通过接收方在发送方的TCP段头部的rwnd字段通告空闲buffer大小告诉发送方发送的速率

链接管理

三次握手

• 前面两次的握手有SYNbit, 第三次就不需要了
• Sequence number client跟server是不一样的
• Client再个server发送ack的时候, ack的number是y+1, 也就是用了server上一次发过来的sequence number + 1

关闭链接

• Client跟server发送关闭链接
• Serverack ack client的关闭请求之后就会主动关闭
• Client再发出关闭链接之后, timeout关闭链接, 就是client需要等待timeout才能关闭链接

拥塞控制

太多的数据需要网络传输，超过了网络的处理能力

拥塞的表现

• 分组丢失 (路由器缓冲区溢出)
• 分组经历比较长的延迟(在路由器的队列中排队)

拥塞控制的方法

端到端的控制 - TCP采用

网络辅助

拥塞感知

1. 超时: 拥塞
2. 3次重复ACK: 轻微拥塞

维持一个拥塞窗口的值: CongWin, 发送端限制已发送但未确认的数据量的上限

LastByteSent-LastByteAcked ≤ CongWin

速率控制方法

超时: CongWin降为1MSS,进入SS阶段然后再倍增到CongWin/2(每个RTT)，从而进入CA阶段

超过3个重复ACK: CongWin降为CongWin/2, CA阶段

否则(正常收到Ack，没有发送以上情况):CongWin跃跃欲试↑

• SS阶段:加倍增加(每个RTT) • CA阶段:线性增加(每个RTT)
• CA阶段:线性增加(每个RTT)

TCP的公平性

如果K个TCP会话分享一个链路带宽为R的瓶颈, 每个会话的有效带宽为R/K

如果2个竞争的TCP会话

总结

传输层是process to process的链接, 其中TCP能够保证数据的可靠性, 实现这种可靠性需要ACK, 编号, 超时重发的机制, 而流水线协议, GBN或者是SR提高的通道的利用率. TCP同样也支持流量控制以及拥塞控制, 其中拥塞控制是端到端的控制, 通过检测重传以及重复的ACK控制流量, 方法包括了SS(slow start)以及CA(congestion avodidance)实现的