0
点赞
收藏
分享

微信扫一扫

计算机网络——运输层【重点】

独兜曲 2022-12-05 阅读 117

运输层概述

概念

进程之间的通信

image-20221126234333735

  • 从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层
  • 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到三层(到网络层)的功能。

image-20221126234610158

进程之间通信流程

image-20221126234850381

“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据,但事实上,这两条数据并没有一条水平方向的物理连接,要传送的数据是沿着图中上下多次的虚线方向传送的

image-20221126235101091

总结

image-20221126235203290

端到端通信

image-20221126235243139

运输层端口号、复用与分用的概念

为什么用端口号

image-20221127234150885

发送方的复用和接收方的分用

image-20221127234250624

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

image-20221127234457336

运输层传输流程(端口号作用)

image-20221127234540682

image-20221127234629910

image-20221127234706741

image-20221127234809274

image-20221127234843463

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文(和DNS发送和接收流程差不多)

image-20221127235015740

image-20221127235030654

image-20221127235056241

image-20221127235120496

image-20221127235135982

UDP和TCP的对比

概念

  • UDPTCP 是TCP/IP体系结构运输层中的两个重要协议
  • 当运输层采用面向连接的 TCP 协议时,尽管下面的网络是不可靠的(只提供尽最大努力服务),但这种逻辑通信信道就相当于一条全双工的可靠信道
  • 当运输层采用无连接的 UDP 协议时,这种逻辑通信信道是一条不可靠信道

可靠信道与不可靠信道

image-20221127235514714

  • 两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。
  • TCP 传送的数据单位协议是 TCP 报文段(segment)。
  • UDP 传送的数据单位协议是 UDP 报文用户数据报

image-20221127235609698

image-20221127235630333

UDP的通信是无连接的,不需要套接字(Socket)

TCP是面向连接的,TCP之间的通信必须要在两个套接字(Socket)之间建立连接

用户数据报协议UDP(User Datagram Protocol)

可以发送广播

image-20221127235731429

可以向某个多播组发送多播

image-20221127235759356

还可以发送单播

image-20221127235839304

运输过程

image-20221127235930932

UDP向上层提供无连接不可靠传输服务

image-20221128000009306

UDP结构

image-20221128000054420

传输控制协议TCP(Transmission Control Protocol)

使用TCP协议的通信双方,在进行数据传输之前,必须使用“三报文握手”建立TCP连接(TCP连接是虚拟连接,并不是真实存在的物理连接)

image-20221128000214760

TCP连接建立成功后,通信双方之间就好像有一条可靠的通信信道,通信双方使用这条基于TCP连接的可靠信道进行通信

image-20221128000239388

运输过程

image-20221128000315751

TCP向上层提供面向连接的可靠传输服务

image-20221128000450676

TCP结构

image-20221128000516620

总结

image-20221128000546902

TCP流量控制

概念

image-20221128231304945

例子

具体流程的视频

假设主机A和B是因特网上的两台主机,它们之间已经建立了TCP连接,A给B发送数据,B对A进行流量控制。假设主机A发送的每个TCP数据报文段可携带100字节数据。因此图中每个小格子表示100字节数据的序号。

image-20221128231239582

在主机A和B建立TCP连接时,B告诉A:”我的接收窗口为400“。因此主机A将自己的发送窗口也设置为400。这意味着主机A在未收到主机B发来的确认时,可将序号落入发送窗口中的全部数据发送出去。

上图主机A现在可将发送缓存中序号1~200的字节数据全部删除,因为已经收到了主机B对它们的累计确认

image-20221128234340419

上图主机A现在可将发送缓存中序号201~500的字节数据全部删除,因为已经收到了主机B对它们的累计确认

image-20221128234508058

image-20221128234541881

上图主机A现在可将发送缓存中序号501~600的字节数据全部删除,因为已经收到了主机B对它们的累计确认

image-20221128234613273

image-20221128234641378

零窗口检测报文能打破上述死锁局面

总结

image-20221128234742131

TCP的拥塞控制

概念

image-20221203173424947

网络拥塞往往是由许多因素引起的。例如:

  1. 点缓存的容量太小;
  2. 链路的容量不足;
  3. 处理机处理的速率太慢;
  4. 拥塞本身会进一步加剧拥塞;

拥塞控制的一般原理

  • 拥塞控制的前提:网络能够承受现有的网络负荷。
  • 实践证明,拥塞控制是很难设计的,因为它是一个动态问题
  • 分组的丢失是网络发生拥塞的征兆而不是原因。
  • 在许多情况下,甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

监测网络的拥塞

主要指标有:

  1. 由于缺少缓存空间而被丢弃的分组的百分数;
  2. 平均队列长度;
  3. 超时重传的分组数;
  4. 平均分组时延;
  5. 分组时延的标准差,等等。

上述这些指标的上升都标志着拥塞的增长。

拥塞控制的算法

image-20221203173916181

image-20221203173948006

慢开始和拥塞避免

慢开始(slow-start)

  • 目的:用来确定网络的负载能力或拥塞程度。

  • 算法的思路:由小到大逐渐增大拥塞窗口数值。

  • 两个变量:

    • 拥塞窗口(cwnd)

      :初始拥塞窗口值:2 种设置方法。窗口值逐渐增大。

      • 1 至 2 个最大报文段 (旧标准)
      • 2 至 4 个最大报文段 (RFC 5681)
    • 慢开始门限(ssthresh):防止拥塞窗口增长过大引起网络拥塞。


    下图的实例横纵坐标的意思

    传输轮次:

    • 发送方给接收方发送数据报文段后,接收方给发送方发发回相应的确认报文段
    • 一个传输轮次所经历的时间其实就是往返时间,往返时间并非是恒定的数值
    • 使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去,并受到了对已发送的最后一个报文段的确认

    拥塞窗口:

    • 它会随网络拥塞程度,以及所使用的拥塞控制算法动态变化

image-20221203174207598

image-20221203174236902

拥塞避免(congestion avoidance)

  • 思路:当拥塞窗口经过慢开始算法达到慢开始门限ssthresh值,继续让拥塞窗口 cwnd 缓慢地增大,避免出现拥塞。
  • 每经过一个传输轮次,拥塞窗口 cwnd = cwnd + 1
  • 使拥塞窗口 cwnd 按线性规律缓慢增长。
  • 在拥塞避免阶段,具有 “加法增大” (Additive Increase) 的特点。

image-20221203175023359

如果在发送过程中出现部分报文段丢失,这必然会造成发送方对这些丢失报文段的超时重传image-20221203175118290

这个时候又回到了慢开始算法

image-20221203175204828

达到慢开始门限值后,又开始拥塞避免算法

image-20221203175311164

两个算法完整示意图

image-20221203175340373

快重传和快恢复

image-20221203175553444

快重传(fast retrasmit)

image-20221203175813979

快恢复(fast recovery)

image-20221203180217507

改进后的整体算法的示意图

image-20221203180307382

TCP超时重传时间的选择

image-20221203180424286

image-20221203180527404

image-20221203180612491

image-20221203180833256

RFC6298建议使用下式计算超时重传时间RTO

image-20221203181017989

往返时间RTT的测量比较复杂

image-20221203181051567

image-20221203181105852

TCP超时重传的计算

举例

image-20221203181140907

总结

TCP超时重传时间RTO计算

image-20221203181243125

TCP可靠传输的实现

本小节具体讲解

image-20221203181954640

image-20221203192601883

image-20221203192642677

TCP的运输连接管理(三报文握手,四报文挥手)

概念

image-20221203192751069

TCP的连接建立

  • TCP 建立连接的过程叫做握手
  • 握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手
  • 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了,因而产生错误。

TCP的连接建立要解决以下三个问题

image-20221203192938770

TCP使用“三报文握手”建立连接

  • TCP 连接的建立采用客户服务器方式
  • 主动发起连接建立的应用进程叫做TCP客户 (client)。
  • 被动等待连接建立的应用进程叫做TCP服务器 (server)。

“握手”需要在TCP客户端和服务器之间交换三次TCP报文段

过程

image-20221203193057671

image-20221203193124541

TCP服务器进程是被动等待来自TCP客户端进程的连接请求,因此称为被动打开连接

image-20221203193255378

由于TCP连接建立是由TCP客户端主动发起的,因此称为主动打开连接

image-20221203193351278

image-20221203193524702

image-20221203193714037

image-20221203193910819

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段?能否使用“两报文握手”建立连接?

下图实例是“两报文握手”

image-20221203194022913

总结

image-20221203195310091

TCP的连接释放

  • TCP 连接释放过程比较复杂。
  • 数据传输结束后,通信的双方都可释放连接。
  • TCP 连接释放过程是四报文握手

TCP通过“四报文挥手”来释放连接

  • TCP 连接的建立采用客户服务器方式
  • 主动发起连接建立的应用进程叫做TCP客户 (client)。
  • 被动等待连接建立的应用进程叫做TCP服务器 (server)。
  • 任何一方都可以在数据传送结束后发出连接释放的通知

过程

image-20221203195446460

image-20221203195718157

image-20221203195842487

image-20221203195951017

image-20221203200212487

image-20221203200257565

TCP客户进程在发送完最后一个确认报文后,为什么不直接进入关闭状态?而是要进入时间等待状态?

image-20221203200440955

TCP保活计时器的作用

TCP双方已经建立了连接,后来,TCP客户进程所在的主机突然出现了故障

TCP服务器进程以后就不能再收到TCP客户进程发来的数据

因此,应当有措施使TCP服务器进程不要再白白等待下去

image-20221203201149947

TCP报文段的首部格式

image-20221203205755577

TCP首部各字段的作用

源端口和目的端口

image-20221203205919613

简化实例:

image-20221203205956019

序号、确认号和确认标志位

image-20221203210031300

image-20221203210130279

数据偏移、保留、窗口和校验和

image-20221203210158433

image-20221203210238163

image-20221203204853540

image-20221203210301150

同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

image-20221203210359344

image-20221203210425648

image-20221203210442961

image-20221203210505219

image-20221203205314311

选项和填充

image-20221203210605248

举报

相关推荐

0 条评论