Skip to main content

网络篇

sip协议​

image-20250527102847353

Alice → Proxy → Bob

1. Alice 发送 INVITE 请求到 Bob
2. Bob 响铃，返回 180 Ringing
3. Bob 接听，返回 200 OK
4. Alice 发送 ACK 确认
5. 会话建立，RTP 开始传输语音
6. 会话结束，Alice 或 Bob 发 BYE
7. 对方回应 200 OK，通话结束

FreeSWITCH 和 Kamailio 是两个在 SIP 通信系统中常用的开源组件，它们分别承担不同的角色

FreeSwitch可以完成 语音通话，媒体服务器，呼叫控制功能 SIP、RTP、WebRTC、mod_sofia，媒体转码
kamailio主要用来处理信令
需求建议使用
需要 SIP 路由、注册、鉴权、负载均衡Kamailio
需要语音/视频处理（通话、会议、录音）FreeSWITCH
构建高并发 VoIP 平台Kamailio 前端 + FreeSWITCH 后端
构建 PBX 或 IVR 系统FreeSWITCH 单独即可
构建运营商级 SIP 中继网关Kamailio 更合适

image-20250527102656385

Kamailio 作为前端 SIP 入口：处理注册、鉴权、呼叫路由
FreeSWITCH 作为后端媒体服务器：负责媒体处理和通话逻辑
优势是：分离信令和媒体，提高系统扩展性和性能

kamailio和freeswitch工作流程

image-20250527102751091

TCP协议​

三次握手

其目的是确保客户端与服务端都准备好通信，并交换初始序号（SEQ），为后续数据传输做好准备。

image-20250527103612268

① 第一次握手（客户端 → 服务端）
客户端发送一个 SYN 报文，表示请求建立连接
设置初始序列号 SEQ = x
状态变为：SYN_SENT

② 第二次握手（服务端 → 客户端）
服务端收到 SYN 后，确认收到，返回一个 SYN+ACK 报文：
ACK = 1，确认客户端的序列号 x
自己也发一个 SYN，带上自己的初始序列号 SEQ = y
状态变为：SYN_RECEIVED

③ 第三次握手（客户端 → 服务端）
客户端收到 SYN+ACK 后，发出最终确认 ACK
ACK = 1，确认服务端的序列号 y

此时，客户端和服务端都进入 ESTABLISHED 状态，连接建立完成

第一次： 客户端告诉服务端“我要连接”（SYN）
第二次： 服务端确认客户端的请求，同时告诉客户端“我也准备好了”（SYN+ACK）
第三次： 客户端再次确认服务端状态正常（ACK），避免“伪连接”

四次挥手

image-20250527103136732

第一次挥手（FIN）

主动关闭方（Client）发送 FIN 报文
表示：“我不再发送数据了，但还可以接收”
报文头部：FIN=1，SEQ=x

第二次挥手（ACK）
被动关闭方（Server）收到 FIN 后，发送 ACK
表示：“知道了，你不发了，我还可能要继续发”
报文头部：ACK=1，SEQ=y，ACK=x+1

第三次挥手（FIN）
被动关闭方处理完数据后，发送自己的 FIN
表示：“我也不再发送数据了”
报文头部：FIN=1，SEQ=z

第四次挥手（ACK）
主动关闭方确认收到对方的 FIN，回 ACK
然后进入 TIME_WAIT 状态，等待 2 倍 MSL 后彻底关闭连接
报文头部：ACK=1，SEQ=x+1，ACK=z+1

三次握手建立连接，四次挥手断开它。
先发 FIN 表关闭，后发 ACK 表收到。
对方发 FIN 表完结，再发 ACK 表结束。

面试题

问题解答
为什么不是两次握手？服务端无法确认客户端是否能收数据。需三次确认
第三次握手可以携带数据吗？✅ 可以，很多系统为了效率就这么做
SYN Flood 是什么？客户端只发第 1 次 SYN，拒绝完成三次握手，造成服务端资源耗尽攻击

SYN Flood（SYN 洪泛攻击） 是一种典型的 拒绝服务攻击（DoS / DDoS），利用了 TCP 三次握手的机制缺陷，向目标服务器发送大量伪造的 SYN 请求，从而耗尽其资源，使合法用户无法建立连接。

image-20250527104014520

攻击者大量伪造 IP 地址发送 SYN 请求
服务端响应 SYN-ACK 并进入 SYN_RECV 状态
等待最终 ACK 超时前不释放资源
每个未完成连接会占用服务器的连接队列（backlog）资源

如何防御SYN Flood

image-20250527104141300

image-20250527104201965

流量进入Linux防火墙的过程​

             [INTERNET]
                 |
        --> eth0 网卡接收到数据包 -->
        内核：数据包进入 Netfilter 框架
                 |
          ┌─────────────────────────────┐
          │     Netfilter 五大链（hooks） │
          └─────────────────────────────┘
                 ↓
    ┌──────────── PREROUTING ────────────┐
    │ 修改目的地址（DNAT）                 │
    └────────────┬───────────────────────┘
                 ↓
        是否是发给本机？ (local delivery)
               /   \
            是     否
           /         \
 INPUT链            FORWARD链
 本地处理         转发到其他主机
（可以阻止）       （常用于网关）
           \         /
            └──→ 路由处理
                 ↓
            POSTROUTING 链
        （修改源地址：SNAT/MASQUERADE）
                 ↓
              网卡发送

Netfilter 的五个 Hook 点（链)

image-20250527105904230

举例说明

假设外网有用户访问你服务器的 Web 服务：

示例：外部请求访问服务器 80 端口（HTTP）

客户端 --> 服务器公网IP:80

数据包在 Linux 中的流转路径如下：

进入网卡（如 eth0）
进入 PREROUTING 链 → 判断是否要修改目标地址（DNAT）
经过内核路由判断：目的地址就是本机 → 转入 INPUT 链
在 INPUT 链判断是否允许访问这个端口（80）
允许后，交给用户空间（nginx、httpd）应用处理

3表5链

image-20250527110232259

总结一句话

Linux 的防火墙不是“先接收到包再处理”，而是在内核层收到包时就立刻进入防火墙钩子链处理流程，不同链负责不同阶段。