当前位置: 首页 > news >正文

5.运输层

5. 运输层

1. 概述

  • 第2~4章依次介绍了计算机网络体系结构中的物理层数据链路层网络层,它们共同解决了将主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信
  • 然而在计算机网络中实际进行通信的真正实体,是位于通信两端主机中的进程
  • 如何为运行在不同主机上的应用进程提供直接的逻辑通信服务,就是运输层的主要任务,运输层协议又称为端到端协议

2. 端口号,复用和分用

1. 运输层端口号
  • 运行在计算机上的进程是使用进程标识符(Process ldentification,PID)来标识的。
    • 然而,因特网上的计算机并不是使用统一的操作系统,而不同操作系统(Windows、Linux、.MacOS)
      使用不同格式的进程标识符
    • 为了使运行不同操作系统的计算机的应用进程之间能够基于网络进行通信,就必须使用统一的方法
      对TCPP体系的应用进程进行标识
  • TCP/IP体系结构的运输层使用端口号来标识和区分应用层的不同应用进程。端口号的长度为6比特,取
    值范围是0~65535

端口号只具有本地意义,即端口号只是为了标识本计算机网络协议栈应用层中的各应用进程。在因特网中,不同计算机中的相同端口号是没有关系的,即相互独立。另外,TCPUDP端口号之间也是没有关系的

2. 发送方的复用和接收方的分用
  1. 复用(Multiplexing):
    • 定义: 复用是指将多个应用程序的数据流合并到一个共享的通信通道上
    • TCP中的复用: 在TCP中,复用通过源端口号来实现。TCP连接的两端使用IP地址和端口号来唯一标识。源端口号表示发送端的应用程序,目的端口号表示接收端的应用程序。这样,在单个TCP连接中,多个应用程序的数据可以共享同一个物理通信通道
    • UDP中的复用: 在UDP中,复用同样通过源端口号来实现。UDP报文的源端口号用于标识发送端的应用程序,目的端口号用于标识接收端的应用程序
  2. 分用(Demultiplexing):
    • 定义: 分用是指根据数据流中的标识信息将合并的数据流分发给正确的应用程序
    • TCP中的分用: 在TCP中,分用通过目的端口号来实现。接收端根据目的端口号将接收到的数据分发给相应的应用程序。这样,TCP层能够将数据正确地传递给目标应用程序
    • UDP中的分用: 在UDP中,同样通过目的端口号来实现分用。接收端通过目的端口号确定应该将数据交付给哪个应用程序

常见协议的分类

运输层端口号应用举例

3. TCPUDP的对比

注意

  • TCP面向连接是逻辑连接,并非真实物理连接
  • TCP面向字节流,UDP面向应用报文(只是给数据报添加一个UDP首部)
  • TCP只支持单播,UDP支持单播、多播和广播
  • TCP提供可靠服务,UDP提供不可靠服务

4. TCP的流量控制

1. 概述

TCP为应用程序提供了流量控制Flow Control)机制,以解决因发送方发送数据太快而导致接收方来不及接收,造成接收方的接收缓存溢出的问题

流量控制的基本方法:接收方根据自己的接收能力(接收缓存的可用空间大小)控制发送方的发送速率

2. 流量控制方法
  1. 流程

  1. 例题

5. TCP的拥塞(se)控制

1. 基本概念
2. 4种拥塞控制方法

1. 慢开始、拥塞避免

2. 快重传、快恢复

快重传算法和快恢复算法(改进TCP性能,1990年Reno版本)

  1. 问题:只是个别报文丢失,没有出现拥塞,这种情况下还是会将拥塞窗口设置为1,降低了网络利用率

  1. 快重传

    • 采用快重传算法可以让发送方尽早知道发生了个别TCP报文段的丢失
    • “快重传”是指使发送方尽快(尽早)进行重传,而不是等重传计时器超时再重传
      • 这就要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
      • 发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的重传计时器超时再重传

  2. 快恢复

与快重传算法配合使用的是快恢复算法发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段,于是不启动慢开始算法,而是执行快恢复算法

  • 快恢复算法:发送方将慢开始门限ssthresh的值和拥塞窗口cwnd的值都调整为当前cwnd值的一半,并开始执行拥塞避免算法
  • 也有的快恢复实现是把快恢复开始时的cwnd值再增大一些,即cwnd=新ssthresh+3

6. TCP超时重传时间的选择

TCP超时重传时间RTO的选择是TCP最复杂的问题之一

问题:

  • 超时重传时间设置过小,在确认报文段发送给接收方的过程中,发送方重传数据报文,增大了网络负荷
  • 超时重传时间设置过大,需要重传数据报文时,推迟时间太长,网络空闲时间大,降低了传输效率
  • 超时重传时间RTO应略大于往返时间RTT
RTO的选择
1. RTTs的计算

2. RRTd和RTO的计算

发生超时重传时无法测准RTT

通过上述两个例子可以看出:当发送方出现超时重传后,收到确认报文段时是无法判断出该确认到底是对原数据报文段的确认还是对重传数据报文段的确认,也就是无法准确测量出RTT,进而无法正确计算RTO

Karn算法及修正

总结

7. TCP可靠传输的实现

  • TCP的窗口以字节为单位

  • 发送方
    • 发送窗口内的已发送数据如果迟迟未收到确认,会发生超时重传
    • 只有处于发送窗口内的数据才能发送

  • 接收方
    • 接收方只能对按序收到的数据中的最高序号给出累计确认,3次重复确认会导致发送方快重传
    • 序号落入接收窗口内的数据是允许接收的数据

  • 总结

8. TCP的运输连接管理

1. TCP连接的建立

TCP双方连接的建立要解决的三个问题

2. 三报文握手

思考:第三次确认是否多余,能不能两报文握手?

答案:不能,如下图所示

3. 四报文挥手

思考:为什么客户端发送完最后一个确认报文段后不立刻关闭而是等待2个MSL时间后才关闭?

答案:如图所示

image-20241104141359755

TCP保活计时器的作用

9. TCP、UDP报文段首部格式对比

参阅思维导图1

img

10. UDP的校验

[!IMPORTANT]

伪首部只是计算校验和的时候添加的,计算完后会拆除,不参与运输!

UDP校验

11. 思维导图和习题

第5章 运输层(思维导图)-1 (kdocs.cn)

第5章 运输层(思维导图)-2 (kdocs.cn)

第5章 运输层 习题 (kdocs.cn)

相关文章:

  • 使用skywalking进行go的接口监控和报警
  • Galini AI 技术实现方案及 GitHub 开源库推荐
  • EchoMimic 阿里开源数字人项目的复现过程
  • Vue 项目中运行 `npm run dev` 时发生的过程
  • 【优选算法 | 前缀和】前缀和算法:高效解决区间求和问题的关键
  • VR汽车线束:汽车制造的新变革
  • 改进系列(10):基于SwinTransformer+CBAM+多尺度特征融合+FocalLoss改进:自动驾驶地面路况识别
  • 【Bootstrap V4系列】学习入门教程之 加载必要文件和入门模板
  • IDEA git配置[通俗易懂]
  • 网络原理 - 12(HTTP/HTTPS - 3 - 响应)
  • Spring Boot 中 `@EnableConfigurationProperties` 注解
  • 【c++】【STL】list详解
  • python-docx清空段落样式的方法有哪些
  • Java学习手册:Spring 中常用的注解
  • 全面解析SimHash算法:原理、对比与Spring Boot实践指南
  • 决策树在电信客户流失分析中的实战应用
  • 基于C++的IOT网关和平台5:github项目ctGateway开发指南
  • 「动态规划」线性DP:最长上升子序列(LIS)|编辑距离 / LeetCode 300|72(C++)
  • 景联文科技牵头起草的《信息技术 可扩展的生物特征识别数据交换格式 第4部分:指纹图像数据》国家标准正式发布
  • LeetCode路径总和系列问题解析:I、II、III的解决方案与优化
  • 全文丨中华人民共和国民营经济促进法
  • 【社论】人工智能,年轻的事业
  • 首映|“凤凰传奇”曾毅:拍电影,我是认真的
  • 外交部:美方应在平等、尊重和互惠的基础上同中方开展对话
  • “上报集团文化助力区域高质量发展赋能平台”揭牌
  • 法院为“外卖骑手”人身权益撑腰:依法认定实际投保人地位