计算机网络开荒3-传输层

一、传输层概述

  • 为运行在不同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

当连接开始时,指数性增长
在这里插入图片描述

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

oifengo

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值