• 计算机网络(自顶向下方法)-传输层


    3.1 概述和传输层服务

    传输服务和协议
     为运行在不同主机上的应用进程提供逻辑通信
     传输协议运行在端系统
     发送方:将应用层的报文分成报文段,然后传递给网络层
     接收方:将报文段重组成报文,然后传递给应用层
     有多个传输层协议可供应用选择
    Internet: TCP和UDP
    在这里插入图片描述

    传输层 vs. 网络层

    网络层服务:主机之间的逻辑通信
    传输层服务:进程间的逻辑通信
     依赖于网络层的服务 • 延时、带宽
     并对网络层的服务进行增强• 数据丢失、顺序混乱、加密
    类比:东西2个家庭的通信
    Ann家的12个小孩给另Bill家的12个小孩发信
     主机 = 家庭
     进程 = 小孩
     应用层报文= 信封中的信件
     传输协议= Ann 和 Bill  为家庭小孩提供复用解复用服务
     网络层协议 = 邮政服务  家庭-家庭的邮包传输服务
    有些服务是可以加强的:不可靠 -> 可靠;安全
    但有些服务是不可以被加强的:带宽,延迟

    Internet传输层协议

    可靠的、保序的传输: TCP
     多路复用、解复用
     拥塞控制
     流量控制
     建立连接
    不可靠、不保序的传输:UDP
     多路复用、解复用
     没有为尽力而为的IP服务添加更多的其它额外服务
    都不提供的服务:
     延时保证
     带宽保证

    3.2 多路复用与解复用

    在这里插入图片描述

    多路解复用工作原理

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    无连接多路复用:例子

    在这里插入图片描述在这里插入图片描述

    TCP套接字:四元组本地标识:
     源IP地址
     源端口号
     目的IP地址
     目的端口号

    解复用:接收主机用这四个值来将数据报定位到合适的套接字
     服务器能够在一个TCP端口上同时支持多个TCP套接字:
     每个套接字由其四元组标识(有不同的源IP和源PORT)
     Web服务器对每个连接客户端有不同的套接字
     非持久对每个请求有不同的套接字

    面向连接的解复用:例子

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3.3 无连接传输:UDP

    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述在这里插入图片描述

    3.4可靠数据传输的原理

    可靠数据传输(rdt)的原理

    在这里插入图片描述

    可靠数据传输:问题描述

    在这里插入图片描述在这里插入图片描述

    解决

    Rdt1.0: 在可靠信道上的可靠数据传输

    在这里插入图片描述

    Rdt2.0:具有比特差错的信道

    下层信道可能会出错:将分组中的比特翻转
     用校验和来检测比特差错
     问题:怎样从差错中恢复:
    确认(ACK):接收方显式地告诉发送方分组已被正确接收
    否定确认( NAK): 接收方显式地告诉发送方分组发生了差错 • 发送方收到NAK后,发送方重传分组
     rdt2.0中的新机制:采用差错控制编码进行差错检测
     发送方差错控制编码、缓存
     接收方使用编码检错
     接收方的反馈:控制报文(ACK,NAK):接收方->发送方
     发送方收到反馈相应的动作

    rdt2.0:FSM描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    rdt2.0的致命缺陷!-> rdt2.1

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    rdt2.2:无NAK的协议

    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述

    rdt3.0:具有比特差错和分组丢失的信道

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述

    流水线协议

    在这里插入图片描述在这里插入图片描述

    滑动窗口(slide window)协议

    发送缓冲区
     形式:内存中的一个区域,落入缓冲区的分组可以发送
     功能:用于存放已发送,但是没有得到确认的分组
     必要性:需要重发时可用
    发送缓冲区的大小:一次最多可以发送多少个未经确认的分组
     停止等待协议=1
     流水线协议>1,合理的值,不能很大,链路利用率不能够超100%
    发送缓冲区中的分组
    未发送的:落入发送缓冲区的分组,可以连续发送出去;
     已经发送出去的、等待对方确认的分组:发送缓冲区的分组只有得到确认才能删除
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    流水线协议:总结

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3.5 面向连接的传输:TCP

    在这里插入图片描述

    段结构

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述在这里插入图片描述

    可靠数据传输

    TCP在IP不可靠服务的基础上建立了rdt
     管道化的报文段
    • GBN or SR
     累积确认(像GBN)
     单个重传定时器(像GBN)
     是否可以接受乱序的,没有规范
    通过以下事件触发重传
     超时(只重发那个最早的未确认段:SR)
     重复的确认 • 例子:收到了ACK50,之后又收到3 个ACK50
    首先考虑简化的TCP发送方:
     忽略重复的确认
     忽略流量控制和拥塞控制

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    TCP:重传

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    流量控制

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    连接管理

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    3.6 拥塞控制原理

    拥塞控制原理

    拥塞:
     非正式的定义: “太多的数据需要网络传输,超过了网 络的处理能力
     与流量控制不同
    拥塞的表现:
     分组丢失 (路由器缓冲区溢出)
     分组经历比较长的延迟(在路由器的队列中排队)
     网络中前10位的问题!

    拥塞的原因/代价:

    场景一

    在这里插入图片描述

    场景2

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    场景3

    在这里插入图片描述在这里插入图片描述

    控制方法

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3.7 TCP 拥塞控制

    TCP 拥塞控制:机制

    端到端的拥塞控制机制
     路由器不向主机有关拥塞的反馈信息
    • 路由器的负担较轻
    • 符合网络核心简单的TCP/IP架构原则
     端系统根据自身得到的信息,判断是否发生拥塞,从而采取动作
    拥塞控制的几个问题
    如何检测拥塞
     轻微拥塞
     拥塞
    控制策略
     在拥塞发送时如何动作,降低速率
    • 轻微拥塞,如何降低
    • 拥塞时,如何降低
     在拥塞缓解时如何动作,增加速率

    拥塞感知

    在这里插入图片描述

    速率控制方法

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    策略概述

    拥塞控制策略:
     慢启动
     AIMD:线性增、乘性减少
     超时事件后的保守策略

    TCP 慢启动

    连接刚建立, CongWin = 1 MSS
     如: MSS = 1460bytes & RTT = 200 msec
     初始速率 = 58.4kbps
    可用带宽可能>> MSS/RTT
     应该尽快加速,到达希望的速率
    当连接开始时,指数性增加发送速率,直到发生丢失的事件
     启动初值很低
     但是速度很快

    在这里插入图片描述

    AIMD

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述

    总结: TCP拥塞控制

     当CongWin<Threshold, 发送端处于慢启动阶段(slow-start), 窗口指数性增长.
     当CongWin〉Threshold, 发送端处于拥塞避免阶段(congestion-avoidance), 窗口线性增长.
     当收到三个重复的ACKs (triple duplicate ACK),Threshold设置成 CongWin/2, CongWin=Threshold+3.
     当超时事件发生时timeout, Threshold=CongWin/2CongWin=1 MSS,进入SS阶段

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    TCP 未来

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

  • 相关阅读:
    CODESYS以文件形式保存RETAIN变量
    深入理解Docker自定义网络:构建高效的容器网络环境
    Java进阶篇--并发容器之ThreadLocal内存泄漏
    应急产业新蓝海,瑞驰的智慧应急解决方案如何打样?
    LeetCode --- 1920. Build Array from Permutation 解题报告
    redis运维(十六) 有序集合
    Mini-dashboard 和meilisearch配合使用
    五胡乱华:汉族历史上的深重创伤
    QT:QML中使用Loader加载界面
    QT实现凸凹边形等距缩放
  • 原文地址:https://blog.csdn.net/m0_46690280/article/details/126509657