面向连接的传输：TCP
TCP：概述
点对点
- 一个发送方、一个接收方
可靠的、按顺序的字节流
- 没有报文边界
管道化（流水线）
- TCP拥塞控制和流量控制设置窗口大小
发送和接收缓存
全双工数据
- 在同一连接中数据流双向流动
- MSS：最大报文段大小
面向连接
- 在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量
有流量控制
- 发送方不会淹没接收方
TCP报文段结构
TCP序号，确认号
序号
- 报文段首字节的在字节流的编号
确认号
- 期望从另一方收到的下一个字节的序号
- 累计确认
接收方如何处理乱序的报文段-没有规定
TCP往返延时（RTT）和超时
怎样设置TCP超时
- 比RTT要长
- 但RTT是变化的
- 太短：太早超时
- 不必要的重传
- 太长：对报文段丢失反应太慢，消极
怎样估计RTT
-
SampleRTT：测量从报文段发出到收到确认的时间
- 如果有重传，忽略此次测量
-
SampleRTT会变化，因此估计的RTT应该比较平滑
- 对几个最近的测量值求平均，而不是仅用当前的SampleRTT
TCP序号和确认号
TCP往返延时和超时
E s t i m a t e d R T T = ( 1 − a ) ∗ E s t i m a t e d R T T + a ∗ S a m p l e R T T EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT EstimatedRTT=(1−a)∗EstimatedRTT+a∗SampleRTT
- 指数加权移动平均
- 过去样本的影响呈指数衰减
- 推荐值： a = 0.125 a = 0.125 a=0.125
设置超时
-
E
s
t
i
m
t
e
d
R
T
T
EstimtedRTT
EstimtedRTT + 安全边界时间
- E s t i m a t e d R T T EstimatedRTT EstimatedRTT变化大(方差大) → 较大的安全边界时间
-
S
a
m
p
l
e
R
T
T
SampleRTT
SampleRTT会偏离
E
s
t
i
m
a
t
e
d
R
T
T
EstimatedRTT
EstimatedRTT多远：
- D e v R T T = ( 1 − β ) ∗ D e v R T T + β ∗ ∣ S a m p l e R T T − E s t i m a t e d R T T ∣ DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT| DevRTT=(1−β)∗DevRTT+β∗∣SampleRTT−EstimatedRTT∣
- 推荐值： β = 0.25 β = 0.25 β=0.25
超时时间间隔设置为：
- T i m e o u t I n t e r v a l = E s t i m a t e d R T T + 4 ∗ D e v R T T TimeoutInterval = EstimatedRTT + 4*DevRTT TimeoutInterval=EstimatedRTT+4∗DevRTT
TCP：可靠数据传输
- TCP在IP不可靠服务的基础上建立了rdt
- 管道化的报文段
- GBN or SR
- 累计确认
- 单个重传定时器
- 是否可以接受乱序的，没有规范
- 管道化的报文段
- 通过以下事件触发重传
- 超时（只重发那个最早的未确认段：SR）
- 重复的确认
- 首先考虑简化的TCP发送方：
- 忽略重复的确认
- 忽略流量控制和拥塞控制
TCP发送方（简化版）
TCP发送方事件
<font color=red从应用层接收数据：
- 用nextseq创建报文段
- 序号nextseq为报文段首字节的字节流编号
- 如果还没有运行，启动定时器
- 定时器与最早未确认的报文段关联（单个重传定时器）
- 过期间隔：TimeOutInterval
超时：
- 重传后沿最老的报文段
- 重新启动定时器
收到确认：
- 如果是对尚未确认的报文段确认
- 更新已被确认的报文序号（后沿移动）
- 如果当前还有未被确认的报文段，重新启动定时器 (发完，就关掉定时器)
伪代码
上述操作的伪代码
// 初始化
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
// 一直循环
loop (forever) {
// 判断事件
switch(event)
// 如果收到了应用层的数据
event: data received from application above
// 用NextSeqNum创建TCPsegment
create TCP segment with sequence number NextSeqNum
// 如果定时器不在运行的话，开始
if (timer currently not running)
start timer
// 传给IP
pass segment to IP
// 前沿移动
NextSeqNum = NextSeqNum + length(data)
event: timer timeout
retransmit not-yet-acknowledged segment with
smallest sequence number
start timer
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
} /* end of loop forever */
注释：
- SendBase-1: 最后一个累积确认的字节
- 例：
- SendBase-1 = 71；y= 73, 因此接收方期望73+ ; y是ACK的值
- y > SendBase，因此新的数据被确认
TCP：重传
接收方产生TCP ACK的建议
| 接收方的事件 | TCP接收方动作 | 补充 |
|---|---|---|
| 所期望序号的报文段按序到达。所有在期望序号之前的数据都已经被确认 | 延迟发送ACK（提高效率，少发一个ACK）。对另一个按序报文段的到达最多等待500ms。如果下一个报文段在这个时间间隔内没有到达，则发送一个ACK。 | 就是当接受到y0之后，不发送ACK=y0+1，而是当顺序接受到y1之后，发送ACK=y1+1注意必须是顺序接受到，如果是乱序，仍然请求y0+1,如果超时还未接受到，再发y0+1 |
| 有期望序号的报文段到达。 另一个按序报文段等待发送ACK | 立即发送单个累积ACK，以确认两个按序报文段。 | 就是上一条说的情况 |
| 比期望序号大的报文段乱序到达。 检测出数据流中的间隔 | 立即发送重复的ACK，指明下一个期待字节的序号 | 如果收到了y0，然后乱序收到了y2，那么重新请求ACK=y0 + 1 |
| 能部分或完全填充接收数据间隔 的报文段到达 | 若该报文段起始于间隔（gap）的低端，则立即发送ACK（给确认。反映下一段的需求）。 | 请求ACK=y0+1，此时已经乱序收到了y2的内容请求之后得到的gap并不能填充y0到y2的空间，只能达到y1，因此重新请求ACK=y1 + 1 |
快速重传
- 超时周期往往太长
- 在重传丢失报文段之前的延时太长
- 通过<font color=red重复的ACK来检测 报文段丢失
- 发送方通常连续发送大量 报文段
- 如果报文段丢失，通常会引起多个重复的ACK
- 如果发送方收到同一数据 的3个冗余ACK，重传最 小序号的段：
- 快速重传：在定时器过时之前重发报文段
- 它假设跟在被确认的数据 后面的数据丢失了
- 第一个ACK是正常的；（比如第一个ACK=50，表明收到了49，是正常的，请求50）
- 收到第二个该段的ACK，表 示接收方收到一个该段后的乱序段； （因为再次请求50）
- 收到第3，4个该段的ack，表 示接收方收到该段之后的2个 ，3个乱序段，可能性非常大段丢失了
快速重传算法
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else { // 已确认报文段的一个重复确认
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y // 快速重传
}
TCP 流量控制
接收方控制发送方，不让发送方发送的太多、太快以至于让 接收方的缓冲区溢出
- 接收方在其向发送方的TCP段 头部的rwnd字段“通告”其空闲buffer大小
- RcvBuffer大小通过socket选项设置 (典型默认大小为4096 字节)
- 很多操作系统自动调整 RcvBuffer
- 发送方限制未确认(“inflight”)字节的个数≤接收 方发送过来的 rwnd 值
- 保证接收方不会被淹没
TCP连接管理
在正式交换数据之前，发送方和接收方握手建立通信关系:
- 同意建立连接（每一方都知道对方愿意建立连接）
- 同意连接参数
同意建立连接
在网络中，2次握手建 立连接总是可行吗？
- 变化的延迟（连接请求的段没有丢，但可能超时）
- 由于丢失造成的重传 (e.g. req_conn(x))
- 报文乱序
- 相互看不到对方
以下是两次握手的问题：
- 半连接
- 接受老数据问题
三次握手
三次握手解决：半连接和接收老数据问题
TCP三次握手 FSM
TCP关闭连接
- 客户端，服务器分别关闭它自己这一侧的连接
- 发送FIN bit = 1的TCP段
- 一旦接收到FIN，用ACK回应
- 接到FIN段，ACK可以和它自己发出的FIN段一起发 送
- 可以处理同时的FIN交换
接收老数据问题
[外链图片转存中…(img-IY4eQv16-1708397928036)]
TCP三次握手 FSM
[外链图片转存中…(img-JuahJ8RB-1708397928036)]文章来源：https://www.toymoban.com/news/detail-834276.html
TCP关闭连接
- 客户端，服务器分别关闭它自己这一侧的连接
- 发送FIN bit = 1的TCP段
- 一旦接收到FIN，用ACK回应
- 接到FIN段，ACK可以和它自己发出的FIN段一起发 送
- 可以处理同时的FIN交换
文章来源地址https://www.toymoban.com/news/detail-834276.html
到了这里，关于计算机网络——20面向连接的传输：TCP的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![[计算机网络]第三章——传输层](https://imgs.yssmx.com/Uploads/2024/01/404515-1.png)
