TCP/IP协议的应用层与传输层

TCP/IP协议簇是互联网的核心通信框架，定义了数据如何在网络中封装、寻址、传输和路由（确定数据包从源主机到目标主机的传输路径的过程）。

|-----|--------------------------------------------|
| 应用层 | 直接面向用户和应用，负责实现网络服务的具体功能（如网页浏览、文件传输、电子邮件等）。 |
| 传输层 | 负责端到端的数据传输控制。确保数据可靠、有效到达。 |
| 网络层 | 负责实现跨网络的端到端数据路由与转发。 |
| 链路层 | 负责在物理介质上直接传输数据帧，实现相邻设备间的可靠通信。 |

表 TCP/IP 协议簇的四层模型

1 应用层

提供给用户与网络接口。例如：浏览器如何请求网页、邮件客户端如何发送邮件。
数据格式标准化。规定数据的编码方式（如JSON、XML）、传输格式（如HTTP报文、SMTP命令）。

|------|----------------------------------------|
| HTTP | 超文本传输协议。无状态协议，依赖Cookie或Session传递及保存状态。 |
| FTP | 文件传输，有状态协议。 |
| SMTP | 电子邮件 |
| SSH | 安全远程登录。 |

表应用层的部分协议

1.1 安全机制

TLS/SSL:为HTTP(HTTPS)、SMTP(SMTPS)提供端到端加密。

1.1.1 CSRF

Cross-Site Request Forgery 跨站请求伪造。

攻击场景：恶意网站诱导用户在已登录的目标网站（如银行）上执行非预期的操作（如转账）。

核心漏洞：浏览器保存了目标网站的Cookie（包括Session ID），攻击者利用这个Cookie伪造用户身份发起请求。

防御手段：1）服务端生成唯一Token，嵌入表单或请求头（如X-CSRF-Token）,服务端验证请求是否携带有效Token。2）设置Cookie的SameSite=Strict或Lax，限制第三方网站发起请求时携带Cookie。3）检查请求头中的来源是否合法（这个字段能被篡改）。

1.1.2 CORS

Cross-Origin Resource Sharing 跨源资源共享。

浏览器默认会阻止前端脚本跨域访问资源（同源策略），通过在服务端设置HTTP请求头，来明确允许特定域、方法或头部的跨域请求。

|-------|-------------------|------------------|
| 特性 | CSRF | CORS |
| 攻击类型 | 利用用户已认证状态发起请求。 | 绕过同源策略限制访问资源。 |
| 浏览器行为 | 自动携带Cookie。 | 阻止跨域脚本访问响应数据。 |
| 关注点 | 请求的合法性（是否用户真实意图）。 | 资源访问的合法性（是否允许跨域） |

表 CSRF 与 CORS的对比

2 传输层

|-----|------------------------------------------|
| TCP | 可靠，面向连接（三次握手），头部开销较大，可进行流量控制，拥塞控制。 |
| UDP | 不可靠，无连接（无须握手，直接发送数据报），轻量（头部仅8字节）。适合音视频流。 |

表传输层的TCP与UDP协议

安全措施：1）通过防火墙过滤端口。2）限制特定端口入站/出站流量。

2.1 TCP 三次握手

确保客户端和服务端双向通信通道的可靠建立，解决网络不可靠性问题（如丢包、重复包、乱序包）。

三次握手流程：

1.客户端 -> 服务端，客户端发送SYN=1(位于TCP报文头部的Flags字段)的报文，携带随机生成的客户端初始序列号seq=x。（SYN，Synchronize,同步位，SYN=1用于表示该报文为连接请求）。

第一次握手验证的是客户端的发送能力。

2.服务端 -> 客户端，服务端发送SYN=1,ACK=1的报文，并携带随机生成的服务端初始序列号seq=y及确认号(期望接收的下一个字节序号)ack=x+1（ACK，Acknowledgment，表示报文携带的确认号有效。）

第二次握手验证的是服务端的接收与发送能力。

3.客户端 -> 服务端，客户端发送ACK的报文，并携带序列号seq=x+1及确认号ack=y+1。

第三次握手验证的是客户端的接收能力。

连接正式建立后，后续的报文seq从x+1开始，且ACK=1。

2.1.2 TCP 四次挥手

是连接终止的标准流程，确保双方安全关闭连接并释放资源，解决数据传输的完整性和网络延迟带来的问题。

四次挥手流程：

主动关闭方 -> 被动关闭方，发送FIN=1的报文并携带当前序列号seq=u。
被动关闭方 -> 主动关闭方，发送ACK=1的报文并携带确认号seq=u+1。
被动关闭方 -> 主动关闭方，发送FIN=1，seq=v(可能携带剩余数据)。
主动关闭方 -> 被动关闭方，发送ACK=1的报文并携带确认号seq=v+1。

主动方先发送FIN来终止发送方向，但仍可接收数据（处理被动方的剩余数据）。

被动方确认FIN后继续发送剩余数据，最终关闭自己的发送方向（发送FIN）。

2.1.2 HTTP 协议的Keep-Alive

HTTP协议的Keep-Alive(持久连接，通过请求头Connection: keep-alive)是一种优化技术，用于在单个TCP连接上处理多个HTTP请求（避免为每个请求重复三次握手）和响应，从而减少建立和断开连接的开销。

|--------|---------------------------------------------------------------------|
| 无（短连接） | 1）用户访问含10个资源的网页。 2）每个资源需独立完成：TCP三次握手 -> HTTP请求 -> 响应 -> TCP四次挥手。 |
| 有（长连接） | 1. 用户访问同一网页。 2. 仅需1次TCP三次握手，所有资源通过同一连接顺序传输。 |

表有无Keep-Alive 的场景分析

实际应用场景：

静态资源加载，网页包含多个CSS、JS、图片文件，复用连接加载所有资源。
高频调用内部服务，减少连接开销，提升吞吐量。
实时消息推送，保持连接活跃，避免频繁重建。