计算机网络第5章（传输层）_4

总结

---

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

为什么用端口号

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

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）发送数据称为 复用

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）接收时叫做 分用。

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

运输层传输流程

举例

在浏览器输入域名，回车浏览

然后用户PC中的DNS客户端进程会发送一个DNS查询请求报文

DNS查询请求报文需要使用运输层的UDP协议

首部中的源端口字段的值，在短暂端口号49151~65535中挑选一个未被占用的，用来表示DNS客户端进程

首部中的目的端口字段的值：53，是DNS服务器端进程所使用的熟知端口号

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器

DNS服务器收到该IP数据报后，从中解封出UDP用户数据报

UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程

DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址

之后，会给用户PC发送DNS响应报文，DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报

其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号

将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC

用户PC收到该数据报后，从中解封出UDP用户数据报

UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程

DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的IP地址

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

---

5.3、UDP和TCP的对比

概念

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

可靠信道与不可靠信道

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

UDP的通信是无连接的，不需要套接字（Socket）

TCP是面向连接的，TCP之间的通信必须要在两个套接字（Socket）之间建立连接

用户数据报协议UDP（User Datagram Protocol）

可以发送广播

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

还可以发送单播

UDP 支持单播、多播以及广播

换句话说，UDP支持一对一，一对多，以及一对全的通信

运输过程

UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界

换句话说，UDP是面向应用报文的

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

UDP结构

传输控制协议TCP（Transmission Control Protocol）

使用TCP协议的通信双方，在进行数据传输之前，必须使用“三报文握手”建立TCP连接

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

很显然，TCP仅支持单播，也就是一对一的通信

运输过程

发送方

• TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP并不知道这些待传送的字节流的含义
• 并将他们编号，并存储在自己发送缓存中
• TCP会根据发送策略，提取一定量的字节构建TCP报文并发送

接收方

• 一方面从所接受到的TCP报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程
• TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系（例如，发送方应用进程交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样）
• 接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

本图只画了一个方向的数据流，在实际网络中，基于TCP连接的两端，可以同时进行TCP报文段的发送和接收

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

TCP结构

总结

---

5.4、TCP的流量控制(丢包处理)

概念

举例

具体流程的视频

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

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

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

上图如果零窗口探测报文在发送过程中如果丢失，还是能打破死锁局面

因为零窗口探测报文段也有重传计时器，重传计时器超时后，零窗口探测报文段会被重传

总结

---

5.5、TCP的拥塞控制

概念

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

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

拥塞控制的一般原理

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

开环控制和闭环控制

监测网络的拥塞

主要指标有：

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

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

拥塞控制的算法

真正的发送窗口值 = Min (接收方窗口值，拥塞窗口值)

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

传输轮次：

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

拥塞窗口：

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

慢开始和拥塞避免

慢开始（slow-start）

• 目的：用来确定网络的负载能力或拥塞程度。
• 算法的思路：由小到大逐渐增大拥塞窗口数值。
• 两个变量：
  • 拥塞窗口（cwnd）：初始拥塞窗口值：2 种设置方法。窗口值逐渐增大。
    • 1 至 2 个最大报文段 （旧标准）
    • 2 至 4 个最大报文段 （RFC 5681）
  • 慢开始门限（ssthresh）：防止拥塞窗口增长过大引起网络拥塞。

图中swnd是发送窗口

每经过一个传输轮次，拥塞窗口就加倍

窗口大小按指数增加，2的n-1次方

拥塞避免（congestion avoidance）

• 思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
• 每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
• 使拥塞窗口 cwnd 按线性规律缓慢增长。
• 在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

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

这个时候又回到了慢开始

两个算法完整示意图

快重传和快恢复

快重传（fast retrasmit）

快恢复（fast recovery）

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

---

5.6、TCP超时重传时间的选择

如果超时重传时间RTO的值设置得比RTT0的值小很多，这会引起报文段不必要的重传，使网络负荷增大

如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率

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

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

TCP超时重传的计算

举例

总结

---

5.7、TCP可靠传输的实现

本集具体讲解

---

5.8、TCP的运输连接管理

概念

TCP的连接建立

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

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

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

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

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

过程

最初两端的TCP进程都处于关闭状态

一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等

之后，就准备接受TCP客户端进程的连接请求

此时，TCP服务器进程就进入监听状态，等待TCP客户端进程的连接请求

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

TCP客户进程也是首先创建传输控制块

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

然后，在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态

TCP连接请求报文段首部中

• 同步位SYN被设置为1，表明这是一个TCP连接请求报文段
• 序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号

请注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！

客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

[外链图片转存中…(img-0NZ8WqZF-1715799288537)]

[外链图片转存中…(img-X9nUmWBw-1715799288539)]

[外链图片转存中…(img-Y5WlmHLY-1715799288540)]

[外链图片转存中…(img-CLOE05Kp-1715799288541)]

[外链图片转存中…(img-XzXHDFZ5-1715799288541)]

[外链图片转存中…(img-Tg0Esxax-1715799288542)]

[外链图片转存中…(img-VA2c8ksP-1715799288542)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！