最近在一家云计算公司实习，做一些技术支持。经常会接触网络相关知识，但是我是软件工程出身，后来转学人工智能，对网络协议不是很了解，只接触过MQTT和简单使用了一下。
目前经常使用ICMP、TCP、UDP这三种协议。
使用ping命令检查服务器是否能够正常联通，使用ssh或者RDP远程连接服务器，物联网设备通过MQTT交换数据。这些操作看起来没有多大的关联。但实际上都离不开网络协议的支持。
刚开始接触的时候我对他们只有一些模糊的理解，比如TCP是可靠传输、UDP速度快，ICMP用于网络检测、MQTT用于物联网通信。随着学习的深入我发现他们其实并不属于同一层次，各自承担不同的职责。
网络协议
在介绍具体协议之前，需要理解什么是网络协议。
简单的说，就是网络设备之间的进行通信共同遵守的一套规则。
两台设备想要交换数据，必须明确数据应该如何封装，如何发送。如何接收。以及出现问题时应该如何处理。如果没有这套规则，即使两台设备之间已经建立了物理连接，也无法保证它们能够正确理解对方发送的数据。
目前互联网通信主要建立在TCP/IP协议体系之上。为了便于理解，通常将其划分为四层：
ICMP 与 TCP、UDP 并不处于同一层次。TCP 和 UDP 属于传输层协议，而 ICMP 是与 IP 配合工作的网络控制协议，通常归入网络层。MQTT 则属于应用层协议。
ICMP（互联网控制消息协议）
ICMP是什么
ICMP 的全称是 Internet Control Message Protocol，中文名称为互联网控制消息协议。
它主要用于网络设备之间传递控制信息、错误报告以及网络诊断信息。
在日常使用电脑或服务器时，最常见的 ICMP 应用就是 Ping 命令。
例如，当我们想检查自己的服务器是否能够正常访问时，可以执行：
ping 8.8.8.8如果目标设备允许ICMP Echo Requset，通常会返回类型下面的结果：
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=200ms TTL=108
来自 8.8.8.8 的回复: 字节=32 时间=199ms TTL=108
来自 8.8.8.8 的回复: 字节=32 时间=199ms TTL=108
来自 8.8.8.8 的回复: 字节=32 时间=199ms TTL=108这些信息表示目标地址返回了 ICMP 响应报文，同时给出了报文序号、TTL 值和往返时间。
ping的工作原理
Ping不是简单地向目标服务器发送一个普通的数据包，而是利用ICMP协议的两种报文：
Echo Request：回显请求。
Echo Reply：会显应答。
其工作过程大致如下：
本地计算机向目标IP地址发送ICMP Echo Request。
目标设备收到请求后，如果允许响应，则返回ICMP Echo Reply。
本地计算机收到响应后，计算报文往返时间。
如果在规定时间内没有收到响应，则认为本次请求超时。
通过这种方式，我们可以初步判断目标设备能否通过当前网络路径响应ICMP请求。
ICMP在实际运维中的应用
除了Ping，ICMP还经常用于Traceroute路由追踪。
Linux下可以执行
tranceroute 8.8.8.8WIndows下可以执行
tracert 8.8.8.8如果设备可以响应，就会显示相关信息，如果不能响应就会隐藏相关信息 ** 并且显示请求超时
通过最多 30 个跃点跟踪
到 dns.google [8.8.8.8] 的路由:
1 * * * 请求超时。
2 1 ms <1 毫秒 <1 毫秒 iKuaiOS [192.168.2.1]
3 3 ms 2 ms 3 ms 100.65.0.1
4 3 ms * * 189.83.208.222.broad.nc.sc.dynamic.163data.com.cn [222.208.83.189]
5 8 ms * * 110.188.6.241
6 * * * 请求超时。
7 * * * 请求超时。
8 * * 37 ms 202.97.12.21
9 36 ms 37 ms 36 ms 202.97.116.6
10 48 ms 46 ms 46 ms CT163.CN.HKG.CTGNet [203.22.178.189]
11 192 ms 183 ms 190 ms Google.CN.HKG.CTGNet [203.22.178.22]
12 200 ms * 193 ms 108.170.231.19
13 196 ms 201 ms 199 ms 142.251.253.105
14 199 ms 198 ms * dns.google [8.8.8.8]
15 199 ms 199 ms 199 ms dns.google [8.8.8.8]
跟踪完成。可以帮助我们观察数据包从本地设备到目标地址经过的网络节点。
例如，当访问某个服务器出现延迟过高或者连接异常时，可以通过路由追踪初步观察问题可能出现在网络路径的哪个位置。
这里需要特别注意一个问题：
Ping 不通，并不代表目标服务器一定无法访问。
有些服务器或防火墙会主动限制 ICMP 请求，但仍然允许 HTTP、HTTPS、SSH 等 TCP 服务正常运行。
因此，在实际排查网络问题时，不能只依赖 Ping，还需要结合端口检测、路由追踪和服务状态进行判断。
TCP（传输控制协议）
TCP是什么
TCP 的全称是 Transmission Control Protocol，中文名称为传输控制协议。
TCP 是一种面向连接的、可靠的传输层协议。
与 UDP 相比，TCP 更加注重数据传输的可靠性。它通过序列号、确认应答、超时重传、流量控制和拥塞控制等机制，尽可能保证数据能够按照正确的顺序到达接收端。
我们平时使用的很多网络服务都离不开 TCP，例如：
我们平时使用的很多网络服务都离不开 TCP，例如：
HTTP/1.1 和 HTTP/2。
HTTPS（通常基于 TCP）。
SSH 远程连接。
FTP 文件传输。
RDP 远程桌面。
TCP 三次握手
TCP 最大的特点之一就是建立连接之前需要进行三次握手。
为什么需要三次握手？
主要是为了让通信双方确认彼此的发送和接收能力正常，并同步初始序列号。
整个过程可以分为三个阶段：
第一次握手：SYN
客户端向服务器发送一个 SYN 报文，表示希望建立 TCP 连接，同时携带自己的初始序列号。
第二次握手：SYN + ACK
服务器收到 SYN 报文后，返回 SYN + ACK 报文，表示已经收到客户端的请求，同时告知自己的初始序列号。
第三次握手：ACK
客户端收到服务器的响应后，再发送一个 ACK 报文进行确认。
至此，TCP 连接建立完成，双方可以开始进行数据传输。
客户端 服务器
| |
| -------- SYN --------------> |
| |
| <------ SYN + ACK -----------|
| |
| -------- ACK --------------> |
| |
| 连接建立完成 |TCP四次挥手
当通信双方不再需要传输数据时，就需要释放TCP连接。
TCP通常通过四次挥手完成连接关闭
客户端发送 FIN，表示自己已经没有数据需要发送。
服务器返回 ACK，确认收到关闭请求。
服务器处理完剩余数据后发送 FIN。
客户端返回 ACK，确认服务器的关闭请求。
客户端发送 FIN，表示自己已经没有数据需要发送。
服务器返回 ACK，确认收到关闭请求。
服务器处理完剩余数据后发送 FIN。
客户端返回 ACK，确认服务器的关闭请求。
客户端 服务器
| |
| -------- FIN --------------> |
| |
| <------- ACK --------------- |
| |
| <------- FIN --------------- |
| |
| -------- ACK --------------> |
| |
| 连接关闭 |实际过程中，服务器收到 FIN 后不一定会立即发送自己的 FIN，因为它可能还有数据需要处理和发送。
这也是 TCP 四次挥手与三次握手有所不同的原因之一。
TCP可靠传输
TCP 并不是简单地发送数据后就不再关心结果，而是通过一系列机制来保证数据传输的可靠性。
主要包括：
序列号：TCP 会为发送的数据分配序列号，用于标识数据的位置，接收端可以根据序列号重新组织数据。
确认应答：接收端收到数据后，会向发送端返回 ACK，表示已经成功接收相应的数据。
超时重传：如果发送端在规定时间内没有收到确认信息，就可能重新发送相关数据。
流量控制：TCP 通过接收窗口控制发送速度，避免发送端发送的数据超过接收端的处理能力。
拥塞控制：TCP 会根据网络拥塞情况动态调整发送速率，避免大量数据同时进入网络造成严重拥塞。
TCP检测服务器端口
在服务器运维中，我们经常需要判断某个 TCP 端口是否能够正常连接。
例如，检测一台服务器的 443 端口：
Test-NetConnection 服务器IP -Port 443如果返回：
TcpTestSucceeded : True说明本次 TCP 连接测试成功。
如果返回 False，则可能是以下原因：
服务器没有启动对应服务。
服务没有监听目标端口。
服务器防火墙限制了连接。
云平台安全组没有放行端口。
网络路径存在问题。
UDP（用户数据报协议）
UDP是什么
UDP 的全称是 User Datagram Protocol，中文名称为用户数据报协议。
UDP 同样属于传输层协议，但与 TCP 不同，它采用无连接的通信方式。
UDP 不需要在传输数据之前建立连接，也不提供 TCP 那样的确认应答、超时重传和流量控制机制。
因此，UDP 的协议开销比较小，适合对实时性要求较高的应用场景。
例如，发送端连续发送三个数据报：
数据报 A
数据报 B
数据报 C接收端可能按照正常顺序收到：
A → B → C也可能出现：
A → C甚至有些数据报完全丢失。
UDP 本身不会负责重新发送丢失的数据。
UDP经典应用
UDP 常见于以下场景：
1. DNS 查询
DNS 通常使用 UDP 的 53 端口进行普通查询，但在某些情况下也会使用 TCP。
2. 在线游戏
游戏需要持续传输玩家的位置、操作和状态信息。对于一些实时数据来说，及时获取最新状态可能比重新发送旧数据更加重要。
3. 音视频通信
实时语音和视频通信通常更关注延迟。如果每个丢失的数据包都需要等待重传，可能会影响整体通信体验。
4. QUIC 协议
HTTP/3 使用 QUIC 协议，而 QUIC 建立在 UDP 之上。它在 UDP 的基础上实现了可靠传输、拥塞控制、加密等能力。
UDP与TCP区别
需要注意的是，UDP虽然协议本身开销较小，但不是传输较快。传输速度是一个复杂环境下的产物。受网络环境，数据大小、应用程序实现以及拥塞情况等因素的影响
MQTT（消息队列遥测传输协议）
MQTT是什么
MQTT 的全称是 Message Queuing Telemetry Transport，中文通常称为消息队列遥测传输协议。
MQTT 是一种轻量级的应用层消息协议，主要采用发布/订阅模式，常用于物联网设备之间的消息通信。
与传统的客户端直接向服务器发送请求不同，MQTT 引入了一个重要角色：Broker，也就是消息代理服务器。
通过 Broker，多个设备不需要直接建立通信关系，就可以实现消息交换。
MQTT的三个核心角色
MQTT 主要涉及三个核心角色：
1. Publisher（发布者）
负责向指定主题发布消息的设备或程序。
例如，一个温度传感器定时采集室内温度，并将数据发送出去。
2. Subscriber（订阅者）
负责订阅指定主题，并接收对应消息的设备或程序。
例如，手机应用订阅温度主题，实时获取传感器发送的数据。
3. Broker（消息代理）
负责接收发布者发送的消息，并根据主题将消息转发给对应的订阅者。
它是整个 MQTT 通信体系中的核心。
MQTT发布/订阅模式
假设我们搭建了一个简单的智能家居系统。
房间内有一个温度传感器，手机需要实时查看室内温度。
整个通信过程如下：
温度传感器连接 MQTT Broker。
手机应用也连接到同一个 Broker。
手机订阅主题
home/room/temperature。温度传感器向该主题发布消息。
Broker 收到消息后，将消息转发给订阅该主题的客户端。
手机收到消息并显示当前温度。
例如，发布的消息可以是：
{
"device": "temperature_sensor",
"temperature": 26.5,
"unit": "C"
}MQTT 的这种通信方式具有较好的灵活性，发布者和订阅者不需要知道彼此的具体地址，只需要通过 Broker 和主题完成消息交换。
MQTT的QoS服务质量等级
MQTT 提供了三种 QoS（Quality of Service）服务质量等级，用于控制消息交付的可靠程度。
QoS 0：至多一次
消息发送后不需要等待确认，不保证一定送达。
优点是开销较小，适合允许少量消息丢失的场景。
QoS 1：至少一次
发送方需要等待接收方确认，如果没有收到确认，可能重新发送消息。
因此，接收方可能收到重复消息，需要应用程序考虑去重问题。
QoS 2：恰好一次
通过更复杂的握手机制，保证协议层面的消息交付恰好一次。
它的通信开销也相对更大。
简单总结：
需要注意，MQTT 的 QoS 保证的是协议层面的消息交付行为，并不意味着业务操作一定只执行一次。例如，收到一条控制指令后，设备是否重复执行，还需要结合业务设计进行处理。
四种协议之间的区别与联系
经过前面的学习，可以发现 ICMP、TCP、UDP 和 MQTT 虽然都与网络通信有关，但它们解决的问题并不相同。
从实际网络通信的角度来看，它们之间还存在一定的联系。
例如，当一个物联网温度传感器通过 MQTT 向服务器发送数据时，通常会经历以下过程：
MQTT 在应用层组织消息。
TCP 在传输层提供可靠传输。
IP 负责寻址和路由。
网络接口层负责实际的数据发送。
而 ICMP 则可以在网络通信过程中辅助完成错误报告和网络诊断。