1. 基本概念

1.1 主要内容

  • 传输层功能
  • 无连接的UDP

  • 面向连接的TCP协议

    1.2 传输层的功能

  • 传输协议transport protocol 是整个网络体系结构中的关键协议之一

  • 实现进程到进程的可靠/不可靠通信服务
  • 可将多对进程通信复用到一条网络连接上

  • 传输层为应用进程治安提供了逻辑通信，网络层为主机之间提供了逻辑通信

  • 在OSI模型中的层次

image.png

  • 运输层进程提供逻辑通信

image.png

  • 传输层主要功能

    • 连接管理：定义允许两个用户像直接连接一样交谈的规则
    • 流量控制：传输层定义了端用户之间的流量控制，数据链路协议定义了两个邻接点的流量控制
    • 差错控制：帧丢失，帧重复、帧失序
    • 建立无连接和面向连接的通信
    • 拥塞控制

      2. 进程通信

      2.1 单机OS的进程通信

      image.png

      2.2 分布式进程通信

  • 分布式进程通信和单机进程通信的主要区别：网络中主机的高度自治性

  • 不同的主机系统之间，没有一个统一的高层操作系统进行全局控制、调度和管理
  • 网络中一台主机对其他主机的 活动状态 和 希望与什么进程通信 无从知道
  • 需要解决的问题
    • 进程命名与寻址方法
    • 多重协议的识别
    • 要建立一个机制，为准备通信的进程建立连接

2.3 C/S模式

  • 客户/服务器模式

image.png

C/S模式中的五元组

  • 每一项网络服务都对应一个“服务程序”进程
  • “服务程序”进程要为每一个获准的网络用户请求执行一组规定的动作，以满足用户网络资源共享的需要
  • 客户与服务器分别表示相互通信的两个应用程序的进程

  • 网络环境中一个完美的进程间通信标识需要一个五元组来表示

    • 协议类型
    • 本地地址、本地端口号
    • 远程地址、远程端口号

      3. 传输层的端口

      3.1 Bind：绑定

  • image.png

    3.2 端口号定义

    image.png常用端口号
    image.png

    3.3 传输层的逻辑信道

  • 通信的真正端点不是主机而是主机中的进程。

  • 端到端的通信end to end是应用进程之间的通信
  • 传输层向高层用户屏蔽了网络核心的细节，它使应用进程好像在两个传输层实体之间有一条端到端的逻辑通信信道

    3.4 传输层的复用与分用

    image.png

基于端口的复用/分用
image.png

4. Internet中的传输层协议

  • 用户数据报协议UDP和传输控制协议TCP
  • UDP和TCP都使用IP协议，即他们的协议数据单元都作为IP数据报的数据
  • UDP是无连接的，TCP提供面向连接的服务

image.png

5. UDP：User Datagram Protocol

image.png

5.1 UDP的主要特点

  • UDP是无连接的，即发送数据之前不需要建立连接
  • UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制
  • UDP支持一对一、一对多、多对一和多对多的交互、实时交互

  • UDP的首部开销小，只有八个字节

    5.2 面向报文的UDP

    image.png

  • 发送方UDP：对应用程序交下来的报文，既不合并，也不拆分，添加首部之后就向下交付IP层，即一次发送一个报文

  • 接收方UDP：对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文

    5.3 UDP的首部

    image.png

    5.3.1伪首部计算校验和

    image.png
    image.png
    image.png

6. TCP：Transmission Control Protocol

image.png

6.1 TCP的主要特点

  • TCP是面向连接的传输层协议
    • 每一条TCP连接只能有两个端点endpoint
    • 每一条TCP连接只能是点对点的（一对一）
  • TCP提供可靠交付的服务
  • TCP提供全双工通信
  • TCP面向字节流
    • TCP的“流”指的是流入或流出进程的字节序列，接收方应用程序接受到的字节流必须和发送方应用程序发出的字节流完全一样
    • “面向字节流”：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流

image.png

6.2 运行过程

image.png

6.3 面向报文流 vs 面向字节流

image.png
TCP面向流的概念

  • TCP根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节

image.png

6.4 TCP报文段的首部

  • TCP虽然是面向字节流的，但TCP传送的数据单元是报文段segment
  • TCP报文段分为首部和数据两部分，功能体现在它首部各个字段的作用
  • TCP报文的首部前20个字节是固定的，后面有4n字节是根据需要而增加的选项。因此TCP首部的最小长度为20字节。最大60字节

image.png

  • 数据偏移：即首部长度，4bit，指出TCP报文段的数据起始处离TCP报文段的起始处有多远。以4字节为计算单位
  • 序号：4字节。TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值表示的是本报文段所发送的数据的第一个字节的序号
  • 确认号：4字节。若是N，则表示序号N-1为止的所有数据均已收到，也是期望对方下一个报文段的第一个字节的序号

image.png

  • 紧急URG：URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）
  • 确认ACK：当ACK=1时，确认号才有效
  • 推送PSH：接受方TCP收到PSH=1的报文段，就尽快地交付接受应用进程，而不用等整个缓存都填满了再向上交付
  • 复位RST：RST=1时，表明TCP连接出现了严重差错，必须释放连接，然后重新建立传输连接
  • 同步SYN：SYN=1时，表明这是一个连接请求或连接接受报文
  • 终止FIN：FIN=1时，表明此报文段的发送端端数据已发送完毕，并要求释放传输连接
  • 窗口：2字节。作为接收方目前允许对方发送的数据量，运行用来让对方设置发送窗口的依据，单位是字节
  • 检验和：2字节。检验和字段检验的范围包括首部和数据两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部

image.png

  • 紧急指针：2字节。指出在本报文段中紧急数据共有多少字节（紧急数据放在本报文段数据的最前面）
  • 选项：长度可变。TCP最初只规定一种选项，即最大报文段长度MSS。
    • MSS：告诉对方TCP，我的缓存所能接收的报文段的数据字段的最大长度。MSS默认值为536字节


6.5 TCP 连接管理

  • TCP传输连接有三个连接：连接建立、数据传送、连接释放
  • 传输连接的管理确保传输连接的建立和释放都能正常进行

image.png

6.5.1 连接建立

解决三个问题

  • 三次握手：使每一方都能确切感知对方的存在
  • 要允许双方协商一些参数，如最大报文段长度，最大窗口大小等
  • 能够对传输实体资源（如缓存大小）进行分配

image.png
image.png
image.png
image.png

6.5.2. 释放连接

image.png
过程

  • A的进程首先向TCP发出连接释放报文段，并停止发送数据，主动关闭TCP连接
    • A将FIN=1，其序号为u，等待B的确认
  • B发出确认号，确认号ack=u+1，而这个报文段自己的序号seq=v
    • TCP 服务器进程告知高层应用进程
    • 从A到B这个方向的连接就释放了，TCP连接处于半关闭状态，B若发送数据，A仍要接收
  • B已经没有要向A发送的数据，其应用进程就通知TCP释放连接
  • A收到连接释放报文段后，必须发出确认

  • A还需要等待2MSL：https://blog.csdn.net/qq_41878620/article/details/105628943

    • 为了保证A发送的最后一个ACK报文能够到达B
    • 防止“已失效的连接请求报文段”出现在本连接中
    • RFC建议，MSL：Maximum Segment Lifetime = 2min

      6.6 TCP可靠传输

  • TCP使用流水线传输和滑动窗口协议实现高效、可靠的传输

  • TCP的滑动窗口是以字节为单位
  • 发送方A和接受方B分别维持一个发送窗口和一个接受窗口
  • 发送窗口：在没有收到确认的情况下，可以连续把窗口内的数据全部发送出去
  • 接收窗口表示：只允许接收落入窗口内的数据

image.png
image.png

6.6.1 滑动窗口

  • 根据B给出的窗口值，A构造出自己的发送窗口
  • 发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去
  • 发送窗口里面的序号表示允许发送的序号
  • 窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率

image.png

  • 发送窗口后延不能向后收缩，因为此时的已发送且已收到确认的数据不能撤销确认，而且确认后的数据没有保留
  • 发送窗口前延不能向后收缩，因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，会产生错误

image.png

  • TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程

image.png

  • TCP要求接受方必须要有累积确认的功能，这样可以减小传输开销

6.7 流量控制

6.7.1 传统的流量控制：停止等待

  • 停止等待：每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组
  • 全双工通信的双方既是发送方也是接受方
  • 只考虑A发送数据，B接受数据并发出确认

image.png
image.png
image.png
image.png
image.png

6.7.2 停等ARQ

  • ARQ：自动请求重发

image.png

  • 四种情况

image.png
image.png

6.7.3 连续ARQ Go Back N

image.png
image.png
image.png
image.png
image.png

6.7.4 选择重传ARQ

image.png
image.png
image.png

6.7.5 总结

image.png

6.8. TCP报文段的发送时机

6.8.1 三种机制

  • 第一种：TCP维持一个变量，为最大报文段长度MSS，只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去
  • 第二种：由发送方的应用进程指明要求发送报文段，即TCP支持的PSH操作
  • 第三种：发送方的一个计时器期限到了，这是就把当前已有的缓存数据装入报文段（不超过MSS）发送出去

特殊情况处理

  • 发送窗口的有效窗口WIN= 0

    • 正常情况下，发送方不能再发送TCP数据
    • 例外
      • 紧急数据
      • B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间，B向A发一个非0窗口的通知，但丢失了，双方互等而死锁。为防止死锁，TCP 为每一个连接设有一个持续计时器 (persistence timer)。

        6.8.2 计时器

  • 持续计时器

image.png

  • 重传计时器

image.png

  • 时间等待计时器

image.png

  • 保活计时器

image.png

6.8.3 TCP重传时间

  • TCP超时计时器采用了一种自适应的算法

image.png
image.png
存在问题
image.png

  • Karn算法

image.png

  • 修正的Karn算法

image.png

6.9 TCP传输效率问题

6.9.1 糊涂窗口综合症

image.png

  • 方法

image.png
image.png

6.9.2 其他问题

image.png
image.png

image.png
image.png
image.png

6.10 拥塞控制

6.10.1 基本概念

  • 拥塞：在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种现象就称为拥塞（congestion）
  • 最坏结果：系统崩溃
  • 网络拥塞往往是由许多因素引起的
    • 端点缓存的容量太小
    • 链路的容量不足
    • 处理机处理的速率太慢
    • 拥塞本身会进一步加剧拥塞

image.png
image.png
image.png
image.png

6.10.2 TCP的拥塞控制

image.png

  • TCP采用基于窗口的方法进行拥塞控制，属于闭环控制方法
  • TCP发送方维持一个拥塞窗口cwnd（Congestion Window）
  • 发送端利用拥塞窗口，根据网络的拥塞情况调整发送的数据量
  • 发送窗口的大小不仅取决于接受方窗口，还取决于网络的拥塞状况

image.png
image.png

  • 控制拥塞窗口的原则

image.png

6.10.3 拥塞算法的四种算法

  • 假设：数据是单方向传送的，对方只传送确认报文，接受方总有足够大的缓存空间
  • 四种拥塞控制算法
    • 慢开始
    • 拥塞避免
    • 快重传
    • 快恢复

image.png

  • 慢开始和拥塞避免

image.png
image.png
image.png

  • 慢启动

image.png
image.png
image.png

  • 快重传算法

image.png

  • 快恢复

image.png
image.png