一、传输层概述

• 为运行在不同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 三次握手建立连接

需要提前建立连接 三次握手🤝 建立连接

1. Sever创建传输控制块TCB，Server就进入了Listen监听状态
2. Client也创建TCB，发送链接请求
   • 发送 SYN = 1给服务器
   • 初试设定的 seq=x 序列号
   • Client进入SYN-Sent(同步发送状态)
   • TCP规定：SYN不能携带数据，但需要消耗一个序列号
3. Server 收到后若同意连接，则发送确认报文
   • ACK = 1，SYN = 1，ack = x + 1
   • 为自己初始化一个序列号seq=y
   • Server进入SYN-RCVD(同步收到)装填
   • TCP规定，这个报文也不能携带数据，消耗一个序号
4. Client收到确认后，还需要再向Server给出确认
   • ACK = 1； ack = y + 1；seq = x + 1
   • Client 进入 ESTABLISHED 已经连接状态
   • TCP规定，ACK报文段可以携带data，不携带data就不消耗seq
5. Server收到Client确认后也进入ESTABLiSHED状态，双方开始通信

5.3.2 四次握手释放连接

1. Client发送连接释放报文
   • FIN = 1，seq = u(前面最后一个+1)
   • Client进入FIN-WAIT-1终止等待状态
   • TCP规定：FIN 即使不携带数据，也要消耗一个seq
2. Server收到FIN请求，发出确认报文
   • ACK =1 ；ack = u+1；seq=v
   • Server进入CLOSE-WAIT关闭等待状态
3. Client收到确认信息后，
   • Client进入FIN-WAIT2终止等待2状态
   • 等待Server发送最后连接释放报文
4. Server将最后的data都发送完了后，就会发送连接释放报文
   • FIN = 1；ack = u+1
   • 半关闭状态，Server很可能又发送一些数据，假定此时seq=w
   • Server 进入Last-ACK最后确认状态，等待客户端确认
5. Client收到连接释放，发出确认
   • ACK = 1；ack = w+1；seq = u+ 1
   • Client进入TimeWAIT 时间等待状态
   • 此时TCP还没释放，必须等2*MSL(最长报文段寿命)的时间后，客户端撤销响应的TCB后，才进入CLOSE状态
6. Server 收到 确认释放连接后，立即Close
   • 撤销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

当连接开始时，指数性增长