TCP/IP协议

计算机与网络设备之间要实现通信，双方必须遵循统一的规则：如何定位通信目标、由谁发起连接、用什么格式传输数据、何时结束通信…… 不同硬件、不同操作系统之间的所有交互，都需要一套事先约定好的标准，这套规则就称为协议（Protocol）

TCP/IP 是互联网协议族的总称，并非单指 TCP 和 IP 两个协议，而是包含 TCP、UDP、IP、HTTP、FTP、ICMP、DNS、SMTP 等一系列协议的完整体系，是整个互联网通信的基础。

TCP/IP 采用四层分层模型，每层各司其职：

应用层：直接面向用户和应用程序，提供具体的网络服务，典型协议有 HTTP、FTP、DNS、SMTP 等。
传输层：负责端到端的数据传输控制，对数据进行分段、封装与重组，核心协议为 TCP 和 UDP。
网络层：负责路由选择与寻址，将数据包从源主机送达目标主机，核心协议为 IP、ICMP、ARP。
链路层（网络接口层）：负责物理网络上的数据帧封装与传输，处理硬件地址寻址和比特流收发。

然而TCP/IP 中有两个具有代表性的传输层协议----TCP 和 UDP

TCP

两台计算机进行通信时，数据传输必须保证完整、有序、不丢失，才能确保收发内容准确无误。

比如浏览网页、收发邮件时，我们希望内容按顺序完整呈现，不能缺字少页；下载文件时，更需要拿到完整的文件，而不是残缺的片段 —— 一旦数据丢失或顺序错乱，结果都无法使用。TCP 协议正是为解决这一问题而设计的，它提供可靠的端到端数据传输，保证数据按序、完整地送达目的地。

TCP（Transmission Control Protocol，传输控制协议） 是一种面向连接的、可靠的传输层协议，是互联网数据传输的核心基石之一。

核心特点

1. 面向连接

通信前必须通过三次握手建立连接，确认双方收发能力正常后才开始传输数据；传输结束后通过四次挥手有序断开，确保连接生命周期完整可控。

第一次握手：客户端 → 服务端（SYN）

客户端向服务端发送连接请求报文段（SYN），报文中携带客户端的初始序列号 ISN（Client）。发送完成后，客户端进入 SYN-SENT 状态。

作用：

• 客户端向服务端表明 "我想建立连接"；
• 同步客户端的初始序列号，供后续数据传输编号使用；
• 验证服务端是否在线、能否接收数据。

第二次握手：服务端 → 客户端（SYN + ACK）

服务端收到连接请求后，若同意连接，则回复确认应答报文（SYN + ACK）：

• ACK 确认号 = 客户端 ISN + 1，表示已收到客户端的 SYN；
• 同时携带服务端自身的初始序列号 ISN（Server）。

发送完成后，服务端进入 SYN-RECEIVED 状态。

第三次握手：客户端 → 服务端（ACK）

客户端收到服务端的同意应答后，再向服务端发送确认报文（ACK），确认号 = 服务端 ISN + 1。发送完成后，客户端进入 ESTABLISHED 状态；服务端收到该 ACK 后，也进入 ESTABLISHED 状态，连接正式建立。

作用：

• 告诉服务端 "你的应答我收到了"；
• 确认双方的发送、接收能力均正常，双向通道畅通；
• 防止历史失效的连接请求误建连接（迟到的旧 SYN 到达服务端时，第三次握手能甄别并丢弃）。

三次握手的本质是双向确认双方收发能力，同时同步各自的初始序列号，为后续可靠传输打好基础。两次握手只能确认单向通路正常，无法验证客户端的接收能力，也无法抵御过期连接请求的干扰。

2. 可靠交付

TCP 通过一套完整机制保证数据不丢、不乱、不重复：

• 序列号 + 确认应答（ACK）：每个字节都有编号，接收方回复确认，发送方据此判断数据是否成功送达；
• 超时重传：发出的数据段启动计时器，超时未收到确认则自动重发；
• 乱序重排 + 去重：接收端按序列号整理数据，乱序的缓存等待补齐，重复的直接丢弃。

3. 流量控制与拥塞控制

• 滑动窗口：接收方告知自身剩余缓存大小，发送方据此控制发送速率，避免接收端溢出；
• 拥塞控制：通过慢启动、拥塞避免、快重传、快恢复等算法动态调整发送速度，防止网络过载。

TCP特点：

1. 面向连接

发送数据前，两端必须先通过三次握手建立可靠连接，确认双方收发能力正常后再开始传输。连接的建立是数据可靠传输的前提和基础

2. 仅支持单播传输

每条 TCP 连接有且仅有两个端点，只能进行点对点一对一传输，不支持多播和广播。

3. 面向字节流

TCP 不保留应用层报文边界，数据以连续的字节流形式传输；而 UDP 则是面向报文的，每个报文独立发送、独立接收。

4. 可靠传输

TCP 通过序列号 + 确认号 + 超时重传三重机制保障可靠性：

• 每个字节都分配唯一序号，确保接收端按序交付；
• 接收端对已收到的数据回复 ACK 确认；
• 发送端若在合理往返时延（RTT）内未收到确认，则判定数据丢失并自动重传。

典型应用场景

HTTP/HTTPS 网页浏览、文件下载、邮件收发、远程登录 SSH 等对数据完整性要求高的场景，底层均基于 TCP 传输

一句话总结：TCP 像 "打电话"—— 先接通再说话，说的每一句对方都要回应，没听清就重说，确保信息完整准确地传达到位

UDP

UDP（User Datagram Protocol，用户数据报协议） 是一种无连接的传输层协议，与 TCP 同处 OSI 模型第四层，位于 IP 协议之上，同样用于处理网络数据包的传输。

与 TCP 不同，UDP 不提供分组组装、顺序控制、确认应答和重传机制 —— 报文发出后，无法得知对方是否收到、数据是否完整到达，因此不保证可靠交付。

它有以下几个特点：

1. 无连接

发送数据前不需要建立连接，直接发包即可，也没有断开连接的过程。启动快、开销小，想发就发。

2. 不可靠交付

没有确认应答（ACK）、没有超时重传、没有序列号排序：

• 发出去的包丢了就丢了，发送方不会重发；
• 数据包到达顺序乱了，UDP 也不会整理，直接交给应用层；
• 不保证数据一定完整送达。

3. 面向报文

对应用层交下来的报文，直接封装成 UDP 报文段后下发，保留报文边界—— 发几次就是几个包，不会合并也不会拆分。（对比 TCP 是面向字节流，没有边界）

4. 支持多种通信方式

TCP 只能一对一单播，而 UDP 支持：

• 单播：一对一
• 多播（组播）：一对多
• 广播：一对全体

5. 头部开销小

UDP 首部仅 8 字节（源端口、目的端口、长度、校验和），而 TCP 首部最少 20 字节。UDP 额外负担极小，传输效率高。

6. 没有拥塞控制和流量控制

发送速率完全由应用层决定，不管网络堵不堵、对方收不收得下，该发多少就发多少。网络拥塞时不会主动降速。

UDP 像 "寄明信片"：写好直接投，不用提前打招呼，也不管对方收没收到、有没有损坏，但速度快、成本低、形式灵活。

	TCP	UDP
是否连接	面向连接	无连接
是否可靠	可靠传输，不使用流量传输和拥塞控制	不可靠传输，不使用流量传输和拥塞控制
连接对象个数	只能一对一	支持一对一，一对多，多对一，多对多交互通信
传输方式	面向字节流	面向报文
首部开销	首部最小20字节，最大60字节	首部开支小，只有8字节
适用场景	适用于要求可靠传输	适用于实时应用

总结

• TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。
• 虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
• 对数据准确性要求高，速度可以相对较慢的，可以选用TCP

HTTP和HTTPS

HTTP（超文本传输协议）与 HTTPS（超文本传输安全协议）作为应用层核心协议，基于 TCP/IP 协议栈构建，是浏览器等客户端与服务器之间实现数据通信的基础架构。

一、HTTP（超文本传输协议）

HTTP（HyperText Transfer Protocol，超文本传输协议） 是一种无状态的应用层协议，用于在客户端与服务器之间传输超文本资源（如 HTML 文档、图片、接口数据等）。它定义了客户端如何发起资源请求、服务器如何返回响应，是万维网数据通信的基础。

---

1. 核心工作流程

HTTP 基于 TCP/IP 协议栈构建，采用经典的请求 - 响应模型，完整流程分为四个阶段：

1. 连接建立：客户端通过 DNS 解析获取服务器 IP，与服务端完成 TCP 三次握手，建立可靠传输通道。
2. 请求发送：客户端构造 HTTP 请求报文，由请求行、请求头、空行、请求体四部分组成。
3. 服务端处理：服务器解析请求、定位资源、执行业务逻辑，生成响应报文返回。
4. 连接关闭：HTTP/1.0 默认短连接（请求完即断开）；HTTP/1.1 起默认支持持久连接（Keep-Alive），可复用 TCP 连接发送多次请求。

2. 协议作用

• 请求与响应：客户端（浏览器、APP 等）通过 HTTP 请求获取网页、图片、接口等资源，服务端通过 HTTP 响应返回数据。
• 简单灵活：协议格式简洁，支持 GET、POST、PUT、DELETE 等多种请求方法，可传输任意类型的数据。
• 缓存机制：内置缓存策略，可大幅减少重复请求，降低网络流量、提升响应速度。

3. 核心特性

• 无状态：每个请求相互独立，服务器默认不保存客户端上下文；通过 Cookie / Session 机制实现状态保持。
• 明文传输：请求与响应以 ASCII 文本形式传输，可被抓包工具直接读取，存在安全隐患。
• 可扩展：支持自定义请求头（如 X-Forwarded-For），方便扩展业务能力。
• 多级缓存：通过 Cache-Control、ETag、Last-Modified 等头部字段实现协商缓存与强制缓存策略。

二、HTTPS（超文本传输安全协议）

HTTPS 是 HTTP 的安全版本，在 HTTP 的基础上加入 SSL/TLS 层来 提供数据加密 和 身份验证功能 ，即 HTTPS = HTTP + SSL/TLS 。

1. HTTPS 协议作用

HTTPS（HyperText Transfer Protocol Secure，超文本传输安全协议） 是在 HTTP 基础上加入 SSL/TLS 安全层的加密传输协议，核心解决 HTTP 明文传输的安全隐患：

• 数据加密：传输全程加密，防止数据被中途窃取、窃听；
• 身份验证：通过数字证书验证服务器真实身份，防止中间人伪装攻击；
• 完整性校验：数据一旦被篡改可立即识别，确保内容完整可信；
• 隐私保护：密码、银行卡号、个人信息等敏感数据传输全程加密，不被泄露。

---

2. SSL/TLS 安全层

SSL/TLS 是位于 HTTP 与 TCP 之间的安全协议层。SSL（Secure Sockets Layer，安全套接字层） 是早期版本，其继任者 TLS（Transport Layer Security，传输层安全） 是当前主流标准，二者统称 SSL/TLS。

防护能力	实现方式
加密传输	对称加密（AES）+ 非对称加密（RSA/ECC）混合加密
身份认证	基于 X.509 数字证书的信任链验证
完整性校验	HMAC 消息认证码，检测数据是否被篡改
防重放攻击	序列号 + 随机数机制，保障数据新鲜

工作流程：两大阶段

① 握手阶段（协商密钥）

客户端与服务器通过多轮交互完成：

• 协商加密算法与协议版本
• 交换随机数与证书
• 验证服务器身份
• 协商并生成会话密钥（对称密钥）

② 数据传输阶段（加密通信）

握手完成后，双方使用协商好的会话密钥：

• 发送方：用会话密钥加密业务数据 → 附加 HMAC 校验码 → 发出
• 接收方：校验 HMAC 完整性 → 用同一会话密钥解密 → 交付上层应用

整个过程确保通信内容机密、完整、可信，在 HTTP 明文传输的基础上构建了完整的安全保障。

三、HTTP vs HTTPS 全面对比

1. 安全维度对比

表格

安全属性	HTTP	HTTPS
数据加密	明文传输，抓包可直接读取	AES-256 对称加密，全程密文
身份验证	无，无法确认对方真伪	X.509 数字证书验证服务器身份
完整性保护	无，数据可被篡改不被察觉	HMAC-SHA256 校验，篡改即失效
防中间人攻击	完全不可防护	证书信任链可抵御中间人攻击

• HTTP：数据以明文形式在网络中传输，任何经过的网络节点都能查看甚至篡改内容，不适合传输密码、银行卡号等敏感信息。
• HTTPS：通过 SSL/TLS 对数据加密并校验完整性，即使数据被截获也无法解密或篡改，有效抵御窃听、篡改、伪装三类攻击。

---

2. 其他维度对比

表格

对比项	HTTP	HTTPS
URL 前缀	http:// 开头	https:// 开头
默认端口	80	443
证书要求	无需证书	必须部署有效的 SSL/TLS 证书
浏览器标识	地址栏无特殊标记，部分浏览器标 "不安全"	地址栏显示锁形图标，标注 "安全"
性能开销	无额外加密损耗	握手与加解密有少量计算开销

---

3. HTTPS 性能优化实践

HTTPS 的加密计算确实会带来一定开销，但通过以下优化手段，实际性能损耗可控制在 5% 以内，现代硬件下几乎无感知：

• TLS 1.3 协议：简化握手流程，从 2-RTT 降至 1-RTT，甚至支持 0-RTT 恢复；
• 会话恢复：通过 Session ID / Session Ticket 复用之前的加密参数，跳过完整握手；
• OCSP Stapling：服务器主动附带证书状态，免去客户端单独查询 OCSP 的延迟；
• HTTP/2 多路复用：头部压缩 + 单连接并发，减少连接数与传输数据量；
• 硬件加速：支持 AES-NI 指令集的 CPU 可硬件级加速加密运算。

依赖关系

HTTP → TCP

• HTTP 明文直接跑在 TCP 上，靠 TCP 的可靠传输保证请求响应不丢不乱
• 公式：HTTP = 请求响应规则 + TCP 可靠传输

HTTPS → TLS → TCP

• HTTPS 比 HTTP 多了一层 TLS 加密，先做 TLS 握手协商密钥，再传 HTTP 数据
• 公式：HTTPS = HTTP + TLS 加密 + TCP 可靠传输

UDP 独立于 HTTP 体系外

• HTTP / HTTPS 只基于 TCP，不使用 UDP
• UDP 用于直播、语音通话、游戏、DNS 等对实时性要求高、可容忍少量丢包的场景

HTTP 和 HTTPS 是应用层的两套 "对话规则"，都跑在 TCP 这条 "可靠管道" 上；HTTPS 比 HTTP 多套了一层 TLS 加密 "保险箱"；UDP 是另一条 "快速但不保送达" 的管道，走的是另一类业务。