TCP 与 UDP
TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是两个广泛使用的传输层协议，它们在数据传输的方式、可靠性和应用场景方面有显著的区别。
TCP
特点：
- 面向连接：TCP是面向连接的协议，传输数据前需建立连接（三次握手）。
- 可靠传输：TCP通过确认（ACK）、序列号、重传和校验机制确保数据包的正确性和完整性。
- 顺序保证：TCP保证数据包按顺序到达，即使数据包乱序到达，也会在接收端进行排序。
- 流量控制：TCP有流量控制机制，避免发送方发送数据过快，导致接收方处理不过来。
- 拥塞控制：TCP有拥塞控制机制，检测并应对网络拥塞，调整发送速率。
应用场景：
- 需要可靠传输的应用，如网页浏览（HTTP/HTTPS）、文件传输（FTP）、远程登录（SSH）等。
UDP
特点：
- 无连接：UDP是无连接的协议，传输数据前不需建立连接。
- 不保证可靠性：UDP不保证数据包的传输成功，不进行确认、重传和顺序控制。
- 无序传输：UDP数据包可能乱序到达，接收方无法确保数据包的顺序。
- 无流量控制：UDP没有流量控制机制，发送方可以随时发送数据。
- 低开销：由于UDP头部开销小，传输速度快，适合实时性要求高的应用。
应用场景：
- 需要快速传输且对丢包不敏感的应用，如视频会议、实时游戏、直播、DNS查询等。
比较总结
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠（确认、重传、校验、排序） | 不可靠（不确认、不重传、不排序） |
| 传输顺序 | 保证顺序到达 | 不保证顺序 |
| 流量控制 | 有 | 无 |
| 拥塞控制 | 有 | 无 |
| 头部开销 | 较大 | 较小 |
| 速度 | 较慢（但可靠） | 较快（但不可靠） |
| 典型应用场景 | HTTP/HTTPS、FTP、SMTP、SSH | DNS、视频会议、在线游戏 |
实例分析
TCP实例（HTTP/HTTPS）：
在浏览网页时，浏览器使用HTTP/HTTPS协议，这些协议基于TCP。由于网页内容需要可靠传输且必须按顺序呈现，TCP的可靠性和顺序控制非常重要。
UDP实例（视频会议）：
在视频会议应用中，数据包的实时性比可靠性更重要。即使丢失少量数据包，视频和音频流的播放不会受到显著影响，因此UDP更适合这类应用。
总结
TCP和UDP各有优劣，选择使用哪种协议取决于具体的应用需求。如果需要数据可靠性和顺序性，TCP是更好的选择；如果对传输速度和实时性要求高，且能容忍部分数据丢失，则UDP更为适合。
HTTP 与 HTTPS
HTTP（Hypertext Transfer Protocol）是用于万维网的数据传输协议。随着互联网的发展，HTTP经历了多个版本的演变，以提升性能、安全性和用户体验。下面是HTTP/1.0、HTTP/1.1、HTTP/2.0、HTTP/3.0以及HTTPS的介绍。
HTTP/1.0
特点：
- 无状态协议：每个请求/响应对是独立的，不保留任何状态。
- 短连接：每次请求需要建立一个新的TCP连接，响应完毕后连接关闭。
- 简单的请求/响应模型：请求包括方法、URL和协议版本，响应包括状态码、响应头和实体内容。
局限性：
- 每个请求需要建立新的TCP连接，效率较低。
- 没有专门的头字段用于描述内容的长度（引入了
Content-Length头）。 - 不支持持久连接和请求管道化。
HTTP/1.1
特点：
- 持久连接：默认使用持久连接（Keep-Alive），在一个TCP连接上可以传输多个请求/响应对，减少连接建立和关闭的开销。
- 请求管道化：允许在一个连接上发送多个请求，而不必等待响应，从而提高传输效率（虽然实际应用中并不广泛）。
局限性：
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩
Body的部分； - 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应
HTTP/2.0
特点：
- 二进制传输：使用二进制格式传输数据，而不是文本格式，提高了传输效率。
- 多路复用：在一个TCP连接上可以并发多个请求和响应，解决了HTTP/1.1的队头阻塞问题。
- 头部压缩：使用HPACK算法对头部进行压缩，减少传输的数据量。
- 服务器推送：服务器可以主动将资源推送到客户端缓存中，而不需要客户端显式请求。
优势：
- 显著提高了传输效率和性能。
- 减少了延迟和带宽消耗。
- 更适合现代网页应用的需求。
缺点：
HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在"队头阻塞"的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。
HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。
HTTP/3.0
特点：
- 基于QUIC协议：HTTP/3基于UDP而不是TCP，使用QUIC协议提供传输层服务。
- 减少延迟：QUIC集成了TCP的多路复用和TLS的加密功能，减少了握手延迟。
- 连接迁移：QUIC支持连接迁移，客户端可以在网络条件变化时无缝切换连接。
- 更快的恢复机制：QUIC可以更快地恢复丢失的数据包，提高传输效率。
优势：
- 更低的延迟和更高的传输效率。
- 更好的用户体验，特别是在移动网络和不稳定网络环境下。
HTTPS（HTTP Secure）
特点：
- 加密通信：HTTPS使用 TLS/SSL 对数据进行加密，保护数据的机密性和完整性。
- 身份验证：通过数字证书验证服务器的身份，防止中间人攻击。
- 数据完整性：保证数据在传输过程中未被篡改。
优势：
- 提高了数据传输的安全性和隐私性。
- 是现代网络应用（如电子商务、网上银行等）的安全基石。
工作流程：
- 握手阶段：客户端和服务器建立安全连接，包括协议协商、证书交换、密钥生成等步骤。
- 数据传输阶段：在建立的安全连接上进行加密的数据传输。
版本对比总结
| 特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2.0 | HTTP/3.0 | HTTPS |
|---|---|---|---|---|---|
| 连接方式 | 短连接 | 持久连接 | 持久连接，多路复用 | 基于QUIC的持久连接 | 基于TLS/SSL的持久连接 |
| 数据传输 | 文本格式 | 文本格式 | 加密的二进制格式 | 加密的二进制格式 | 加密的二进制格式 |
| 多路复用 | 不支持 | 支持，但有队头阻塞 | 支持，解决队头阻塞 | 支持，解决队头阻塞 | 支持，解决队头阻塞 |
| 头部压缩 | 不支持 | 不支持 | 支持 | 支持 | 支持（TLS压缩） |
| 服务器推送 | 不支持 | 不支持 | 支持 | 支持 | 支持 |
| 安全性 | 无 | 无 | 有 | 有 | 高（基于TLS/SSL） |
总结
HTTP协议的发展反映了对性能、安全性和用户体验的不断追求。HTTP/1.1的持久连接和缓存控制，HTTP/2的多路复用和头部压缩，以及HTTP/3基于QUIC的低延迟连接，都是为了解决前一版本中的不足。而HTTPS则通过加密通信和身份验证，提供了必要的安全保障，使得HTTP协议更加可靠和安全。