一文读懂网络通信传输层与应用层

一：传输层 TCP UDP

UDP很快但是不可靠 于是tcp出来了

TCP 模拟通信过程 tcp的连接三次握手 与 断开连接四次握手

A：您好，我是 A
B：您好 A，我是 B
A：您好 B

A：B 啊，我不想玩了
B：哦，你不想玩了啊，我知道了
这个时候，只是 A 不想玩了，即不再发送数据，但是 B 可能还有未发送完的数据，所以需要等待 B 也主动关闭。
B：A 啊，好吧，我也不玩了，拜拜
A：好的，拜拜

TCP与UDP区别总结

1. TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付
3. TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
   UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5. TCP首部开销20字节;UDP的首部开销小，只有8个字节
6. TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道 支持单工或半双工
   全双工（Full Duplex）​ 指通信双方能够同时进行双向数据传输，即发送和接收操作可并行执行
   单工（Simplex）​：数据单向传输（如广播、遥控器）。
   ​半双工（Half Duplex）​：双向交替传输（如对讲机，需切换方向）

二：众多应用层协议

http与https

1. 什么是https 协议？ http与https有啥区别？
   https协议就是 客户端与服务器端 数据交流的一个协议
   http是明文传输，容易被劫持不安全；https是加密后传输的相对较安全
   HTTPS = HTTP +== 加密== + 认证 + 完整性保护 HTTPS 是身披SSL外壳的HTTP

2. 怎么进行安全传输的？https 安全为什么就安全了呢？
   以下介绍 客户端为A 服务器为B 带有数据的内容C
   安全关键点：AB之间不能有第三者插足捣乱。
   原理：对称加密，非对称加密，密钥，公钥，私钥，数字证书。
   1、 正常传C的话，A-B 但是可能中间有第三者去截获 为了不让第三者捣乱，就有个密钥。
   密钥采用对称加密的话，A这边加密，B这边对称解密。
   2、但是如果第三者拦截了密钥，对称解密还是会知道数据，所以不能对称加密，要非对称加密。
   3、非对称加密，这样就分为一套 公钥和私钥 ，可以保证第三者即使知道公钥也需要一个对应的私钥去解密。这样可以解决2的问题
   但是还有一个问题就是，公钥如果被第三者掉包了，那么对应的创建的私钥并不知道是假的还是会解密然后这样就会把数据给持有冒牌公钥的第三者。
   4、为了确保公钥正常，数字证书就出现了，由权威机构认证这样公钥就安全了。

3. 所以总结来讲：
   安全的实现：1：数据的来源是安全的 由权威机构认证的公钥 数字证书2：数据的处理是安全的 由自己对应的私钥处理 别人不可能有的
   实现过程：B带有安全的公钥-A A私钥处理过后-B
   安全还是因为有了数字证书保证了可信度.

http1.0/1.1/2

http1.0 （1996年）

HTTP/1.0

1. 核心特点
   短连接（Short-Lived Connections）
   每次请求需重新建立TCP连接，请求完成后立即关闭。
2. 问题：高延迟（三次握手开销），频繁连接影响性能。
   无状态协议
   无Cookie机制，服务器无法跟踪会话状态。
   简单缓存
   仅支持Expires和Last-Modified头实现基础缓存
3. 性能瓶颈
   多资源页面需多次TCP握手/挥手，导致队头阻塞（Head-of-Line Blocking）。
   无虚拟主机支持，同一IP无法托管多个域名

GET /index.html HTTP/1.0
User-Agent: Mozilla/4.0
Accept: text/html
(请求后连接关闭)

http1.1（1997年）

1. 核心改进
   ​持久连接（Keep-Alive）​
   默认复用TCP连接，减少频繁握手开销（通过Connection: keep-alive实现）。
   支持管道化（Pipelining），允许客户端连续发送多个请求，但响应仍需按序返回。

2. 虚拟主机与Host头
   通过Host字段支持同一IP托管多个域名，解决虚拟主机问题。

3. 分块传输与缓存优化
   分块编码（Chunked Encoding）支持流式传输大文件。
   引入Cache-Control、ETag等缓存控制头，提升资源复用效率。

4. ​断点续传与范围请求
   通过Range头实现部分资源请求，支持断点续传。

5. 遗留问题
   管道化仍存在队头阻塞。
   头部冗余（未压缩）与低效的多连接管理

GET /search?q=HTTP+1.1 HTTP/1.1 （含 Host 头）​
Host: www.example.com
User-Agent: Chrome/97.0
Accept-Encoding: gzip

HTTP/2（2015年）

革命性改进

1. 二进制分帧（Binary Framing）
   将报文拆分为HEADERS帧和DATA帧，实现多路复用。
   对比HTTP/1.1的文本格式，解析效率更高。
2. 多路复用（Multiplexing）
   单连接并行处理多个请求/响应，彻底解决队头阻塞。
   示例：浏览器加载页面时，CSS、JS、图片同时传输。
3. 头部压缩（HPACK）
   使用静态哈夫曼编码压缩头部，减少冗余数据传输。
   客户端和服务端维护头部表，复用历史头部字段。
4. 服务器推送（Server Push）
   服务器可主动推送资源（如推送CSS文件给尚未请求的HTML页面）。
   需谨慎使用：避免推送客户端已缓存的资源。
5. 流优先级（Stream Prioritization）
   客户端可指定资源加载优先级（如优先加载HTML骨架）。
6. 流量控制（Flow Control）
   基于信用机制控制单个流的传输速率，防止接收方过载

:method: GET
:scheme: https
:path: /index.html
:authority: www.example.com
user-agent: Mozilla/5.0
(通过二进制帧传输，与其他请求交织)

如何知道当前使用的http协议是什么版本

F12 然后网络选项 在名称右边勾选上协议就会显示在列表内容中

FTP/FTPS

1. 功能：文件上传、下载及目录管理。
2. 特点：
   支持主动/被动模式，适用于大文件传输和断点续传。
   安全性通过 SSL/TLS（FTPS）或 SFTP（SSH）增强。
3. ​C# 实现：
   FtpWebRequest 和 FtpWebResponse 类。
   第三方库（如 FluentFTP）简化复杂操作

SMTP/IMAP/POP3

1. ​功能：邮件发送（SMTP）与接收（IMAP/POP3）。
2. ​特点：
   SMTP 基于文本命令（如 MAIL FROM、RCPT TO）。
   支持身份验证（如 OAuth2）和加密（SSL/TLS）。
3. ​C# 实现：
   System.Net.Mail.SmtpClient（已过时，建议改用 MailKit 库）。
   MailKit 提供完整的 IMAP/POP3 支持

MQTT/CoAP

1. ​功能：物联网（IoT）场景下的轻量级消息传输。
2. ​特点：
   ​MQTT：发布-订阅模型，低带宽消耗，适合设备间异步通信。
   ​CoAP：基于 UDP 的 RESTful 协议，支持资源发现和块传输。
3. ​C# 实现：
   MQTTnet 库实现 MQTT 客户端/服务端。
   CoAP.NET 或第三方库支持 CoAP

WebSocket

1. ​功能：全双工实时通信（如聊天室、实时数据推送）。
2. 特点：
   基于 HTTP 升级握手建立持久连接，避免轮询开销。
   支持二进制和文本帧传输，延迟低。
3. ​C# 实现：
   System.Net.WebSockets 命名空间提供原生支持。

SignalR

1. 协议基础
   SignalR 支持多种传输协议，按优先级降序排列如下：
   WebSocket
   全双工通信，低延迟，性能最优，适用于现代浏览器和服务器环境。
   Server-Sent Events (SSE)
   单向通信（仅服务端到客户端），基于 HTTP 流，适用于不支持 WebSocket 的客户端（如部分移动端）
   长轮询（Long Polling）
   模拟实时通信的兼容性方案，客户端定期发送请求，服务器在数据就绪时响应，适用于老旧浏览器或严格网络限制的环境
2. .NET生态专属，自动选择最佳传输协议（WebSocket > Server-Sent Events > Long Polling）
   内置连接管理、分组广播
3. 适用场景
   实时Web应用（如在线会议系统）
   需要兼容老旧浏览器的场景

gRPC

1. 协议基础
   基于HTTP/2和Protobuf，支持四种调用模式（Unary/Streaming）
   C#需引用 Grpc.AspNetCore 包，通过 .proto 文件生成代码
2. 适用场景
   微服务间高效通信
   跨语言服务调用（如Go调用C#服务）

原生TCP/UDP

1. 协议基础
   完全自定义协议，需处理粘包、心跳、重试等机制
   TCP使用 TcpListener/TcpClient，UDP使用 UdpClient
2. 适用场景
   高频交易系统（自定义二进制协议）
   实时视频流传输（UDP）

Modebus

1. ​定位：通用型应用层协议，支持串行（RTU/ASCII）和以太网（TCP）传输，以简单、开放、低成本著称。
2. ​功能：主要用于设备级数据采集（如传感器、PLC寄存器读写）。
3. ​局限性：不支持位级写入、数据分组限制（单次最多读取127个寄存器）、缺乏安全性设计
4. 在工业自动化领域，Modbus、S7（西门子PLC协议）、MC（三菱PLC协议）及OPC协议各自承担不同角色，既有功能重叠又有互补协作
   

关键对比与选型建议

选型决策

1. 是否需要浏览器支持？
   是 → HTTP（传统API）、WebSocket（实时）、SignalR（.NET全栈）
   否 → 进入下一步

2. 是否要求极致性能？
   是 → gRPC（服务间）、TCP/UDP（自定义协议）
   否 → 进入下一步

3. 是否涉及物联网设备？
   是 → MQTT
   否 → 根据场景选择 HTTP 或 gRPC

三、协议间的联系与协作

1. 底层依赖：
   所有协议均依赖传输层（TCP/UDP），如 HTTP 和 WebSocket 基于 TCP，CoAP 基于 UDP。
   安全性通过 TLS/SSL 统一增强（如 HTTPS = HTTP + TLS）。
2. ​混合应用场景：
   Web 应用：HTTP 提供 API，WebSocket 处理实时交互。
   ​IoT 系统：MQTT 用于设备通信，HTTP 用于云端数据聚合。
   ​邮件系统：SMTP 发送邮件，IMAP/POP3 同步收件箱。
3. C# 开发建议：
   ​优先选择成熟类库​（如 HttpClient、MQTTnet），避免重复造轮子。
   ​协议网关：使用 Ocelot 或自定义中间件整合不同协议（如 HTTP 转 MQTT）