文章目录
一、传输层概述
-
为运行在不同host上的进程了一种逻辑通信机制
-
端系统运行传输层协议
- 发送方:将应用递交消息分成n个Segment,向下传给网络层
- 接收方:将segment 组成消息 传给 应用层
-
TCP
-
UDP
1.1 网络层 vs 传输层
网络层 :提供了主机之间的通信机制 HTTP
传输层 :应用进程之间的通信机制 ,由Socket控制 给 不同的进程
二、多路复用 多路分用
多路分用:传输层依据头部信息讲收到的Segment交给正确的Socket,即不同的进程
多路复用:从多个Socket接受数据,为每块数据封装上头部信息,生成Segment,交给网络层
Socket标识 = IP + Port
DUP用 二元组 来标识(目的IP + 目的Port)
SP:源port DP:目的port
TCP 用四元组来标识:(源IP 源port 目的IP 目的port)
可以多线程优化一下:
三、UDP
User Datagram Protocol
基于IP,添加了 复用/分用、简单的错误检测
丢失
非按序到达
不需要握手
每个UDP段独立于其他段
3.1 RDT
可靠的数据传输RTP:不错、不丢、不乱
控制信息时双向流动的
利用状态机FSM 刻画传输协议
3.1.1 Rdt
在计算机网络中,RDT是可靠数据传输(Reliable Data Transfer)的缩写,其作用是保证数据在传输过程中不会出错或丢失。RDT协议可以分为多个版本,其中比较常见的有Rdt1.0、Rdt2.0、Rdt2.1和Rdt3.0。
Rdt1.0是非常简单的RDT协议,它只能在无差错信道上工作(理论上存在),不能保证在出现错误时的可靠传输。
Rdt2.0是对Rdt1.0的改进,它通过校验和技术检测数据报文是否有误,并在发现错误时使用ACK和NAK进行重传,以实现可靠传输。
Rdt2.1在Rdt2.0的基础上增加了超时重传机制,当发送方在一定时间内没有收到确认消息时,将对数据进行重传,从而提高了传输的可靠性。
Rdt3.0是对Rdt2.1的改进,主要针对网络中可能出现的乱序、重复和丢失等问题进行优化,使用了序号和确认号来保证数据的正确性和可靠性。
总之,随着RDT协议版本的不断升级,计算机网络中的可靠数据传输逐渐变得更加健壮和可靠,可以满足更加复杂的传输需求。
3.1.1.1 Rdt1.0
可靠信道上的可靠数据传输
底层信号完全可靠:
- 不会发生错误
- 不会丢失分组
发送方和接收方FSM独立
3.1.1.2 Rdt2.0
- 不可靠信道,底层信道可能翻转分组中的位bit
- 利用校验和检测
- 恢复正确数据
- ACK(Acknowledgements)确认机制:接受方 告诉 发送方是否正确接受
- NAK:接收方 告诉 发送方 分组有错
- 发送方收到NAK后,重传
基于这种ACK NAK机制的称为ARQ(Automatic Repeat reQuest)协议
3.1.1.3 Rdt2.1
Rdt2.0 如果ACK NAK消息发送错误,那么无法重传
增加序列号Sequence number
在Rdt2.0的基础上 加入了 超时重传
3.1.1.4 Rdt2.2
去掉了NAK
错误后,接收方 重复发送ACK
接收方 接收到 重复的ACK 那么人为NAK
3.11.5 Rdt 3.0
校验和 + 序列号 + Ack + 重传
会导致 中途丢失 ,双方都在等待
需要定时器
四、滑动窗口协议
Rdt3.0 性能影响太大
4.1 流水线机制
同时发送 检测 三个分组
于是 性能就是dbt3 的3倍
- 需要更大的序列号范围
- 发送方、接收方需要更大的缓存
4.1.2 滑动窗口协议
想要实现流水线机制 就需要 滑动窗口协议
GBN
Go Back N
资源浪费:多发未收到的ACK所有分组
乱序也会丢弃
SR
Selective Report 协议
GBN: 重传太多 资源浪费
SR:单个确认,可以接受乱序到达
原理:接收方也+窗口
五、TCP
- 点对点
- 可靠的 按序的字节流
- 流水线机制
- 发送方、接受方都有缓存
- 全双工full duplex
- 双向的数据流传输
- 面向连接
- 发送数据前必须建立连接
- 连接状态只在连接的两端中维护,在沿途节点不维护
- TCP连接:主机上的缓存、连接状态、socket等
- 流量控制机制
5.1 可靠数据传输
5.1.1 RTT和超时
TCP 是 超时重传的,为了确定这个超时的限制
就需要对RTT进行测量
sender若收到对同一个数据的3个ACK,那么就假定这个数据丢失,进行重传了
5.2 流量控制
接收方会有buffer,提供给上层
速度太快,buffer就会满了
所以需要流量控制
通过RevWindow 告诉发送方 buffer还剩多少
5.3 连接管理
5.3.1 三次握手建立连接
需要提前建立连接 三次握手🤝 建立连接
- Sever创建传输控制块TCB,Server就进入了Listen监听状态
- Client也创建TCB,发送链接请求
- 发送 SYN = 1给服务器
- 初试设定的 seq=x 序列号
- Client进入SYN-Sent(同步发送状态)
- TCP规定:SYN不能携带数据,但需要消耗一个序列号
- Server 收到后若同意连接,则发送确认报文
- ACK = 1,SYN = 1,ack = x + 1
- 为自己初始化一个序列号seq=y
- Server进入SYN-RCVD(同步收到)装填
- TCP规定,这个报文也不能携带数据,消耗一个序号
- Client收到确认后,还需要再向Server给出确认
- ACK = 1; ack = y + 1;seq = x + 1
- Client 进入 ESTABLISHED 已经连接状态
- TCP规定,ACK报文段可以携带data,不携带data就不消耗seq
- Server收到Client确认后也进入ESTABLiSHED状态,双方开始通信
5.3.2 四次握手释放连接
- Client发送连接释放报文
- FIN = 1,seq = u(前面最后一个+1)
- Client进入FIN-WAIT-1终止等待状态
- TCP规定:FIN 即使不携带数据,也要消耗一个seq
- Server收到FIN请求,发出确认报文
- ACK =1 ;ack = u+1;seq=v
- Server进入CLOSE-WAIT关闭等待状态
- Client收到确认信息后,
- Client进入FIN-WAIT2终止等待2状态
- 等待Server发送最后连接释放报文
- Server将最后的data都发送完了后,就会发送连接释放报文
- FIN = 1;ack = u+1
- 半关闭状态,Server很可能又发送一些数据,假定此时seq=w
- Server 进入Last-ACK最后确认状态,等待客户端确认
- Client收到连接释放,发出确认
- ACK = 1;ack = w+1;seq = u+ 1
- Client进入TimeWAIT 时间等待状态
- 此时TCP还没释放,必须等2*MSL(最长报文段寿命)的时间后,客户端撤销响应的TCB后,才进入CLOSE状态
- Server 收到 确认释放连接后,立即Close
- 撤销TCB ,TCP连接结束
- 撤销TCB ,TCP连接结束
六、拥塞控制
拥塞Congestion:太多Client发送了太多data,网络无法处理
表现:
1.分组丢失(路由器缓存溢出)
2.分组延迟过大(路由器缓存中排队)
端到端拥塞控制
- 网络层不需要显式提供支持
- 端系统通过观察loss,delay等网络行为来判断是否发生拥塞
- TCP就这种
网络辅助的拥塞控制
- 路由器发送方显示的反馈网络拥塞信息
- 简单的拥塞指示1bit:SNA、DECbit、TCP/IP ECN ATM
6.1 TCP拥塞控制
Sender限制发送速率
CongWin:发送窗口
- 动态调整改变发送速率
- 感知网络拥塞
6.1.1 加性增–乘性减 AIMD
原理:逐渐增加发送速率,谨慎探测可用带宽,直到发生loss
6.1.2 TCP慢启动SS
当连接开始时,指数性增长