Daily Study

更新: 2/2/2026 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• 看一下black widow

流式协议

了解的有WebSocket，SSE，Streamable。其中针对AI Agent，SSE是最主流的，Streamable是SSE的升级（见MCP最新的协议中MCP）

SSE的优点：

• 单向流：Agent 的响应通常是用户发一句，AI 回一大堆。不需要全双工。
• HTTP 兼容性：SSE 本质是 HTTP 长连接，对防火墙、Nginx 负载均衡更友好。
• 断线重连：协议原生支持。
• 数据结构实现细节：结构化的事件流，返回的是JSON事件。

在我的 AKSK-Agent 项目中，为了解决告警研判等待时间长的问题，我设计了一套基于 SSE (Server-Sent Events) 的结构化流式传输方案。

1. 协议选择：我使用了 SSE 而不是 WebSocket，因为 Agent 的交互主要是‘一问多答’的单向流，且 SSE 对云网关更友好。
2. 事件分发：利用 LangGraph 的 astream_events 接口，我将流分成了三类事件：
   • Thought Event：实时展示 Agent 的 CoT 思考过程（如‘正在生成 SQL...’）。
   • Tool Event：可视化工具调用状态（如‘查询数据库中，耗时 2s...’），缓解用户的等待焦虑。
   • Answer Event：最后将 LLM 的总结以打字机效果推送到前端。
3. 用户体验优化：这让原本需要等待 10 秒甚至更久的复杂研判任务，变成了实时的动态反馈，极大地提升了系统的交互体验。”

WebSocket和SSE的对比：

特性	WebSocket	SSE (Server-Sent Events)
通信方向	双向 (Client ⇄ Server)全双工	单向 (Server → Client)
底层协议	独立的 TCP 协议 (ws:// 或 wss://)	标准 HTTP 协议 (http:// 或 https://)
数据格式	文本 或 二进制 (Blob/ArrayBuffer)	仅支持 文本 (UTF-8)
连接建立	需 HTTP 握手升级 (101 Switching Protocols)	普通 HTTP 请求 (Content-Type: text/event-stream)
断线重连	需要手动实现 (写心跳、重连逻辑)	浏览器原生支持 (自动重连)
防火墙/代理	容易被企业防火墙拦截 (非标准 HTTP)	极好 (就是普通 HTTP，畅通无阻)
复杂度	高 (需专门的协议处理库)	低 (服务器 print, 客户端 onmessage)

网络八股回顾

第一阶段：浏览器解析与DNS查找（本地与边缘）

当我们在浏览器输入URL并回车时：

1. URL解析与检查：

   • 浏览器先解析URL（协议、域名、路径、端口）。
   • 安全加分项：浏览器会检查该URL是否在HSTS（HTTP Strict Transport Security）列表中，如果是，强制转换为HTTPS。同时检查是否在Google Safe Browsing等恶意网址黑名单中。

2. DNS解析（域名 -> IP）：

   • 查询顺序：浏览器缓存 -> 操作系统缓存（Hosts文件） -> 路由器缓存 -> ISP DNS服务器（递归查询）。
   • 递归查询流程：根域名服务器 -> 顶级域名服务器(.com) -> 权威域名服务器。
   • SRE/性能加分项：如果使用了CDN，DNS会根据用户的地理位置返回最近的边缘节点IP（GSLB 全局负载均衡）。

第二阶段：建立连接

拿到IP地址后，开始建立连接：

1. TCP三次握手（建立可靠传输）：

   • SYN -> SYN-ACK -> ACK。
   • 网络专业加分项：这里可以简述为什么是三次（防止已失效的连接请求传送到服务端，产生错误）。

2. TLS/SSL握手（安全层的核心，必讲！）：

   • 由于现在基本都是HTTPS，TCP握手后进入TLS握手（以TLS 1.2/1.3为例）。
   • Client Hello：客户端发送支持的加密套件、随机数。
   • Server Hello：服务端确认加密套件、发送证书（公钥）、随机数。
   • 证书验证：客户端验证证书的合法性（CA签名、有效期、吊销列表CRL/OCSP）。这是中间人攻击（MITM）防护的关键。
   • 密钥交换：利用非对称加密（如RSA或ECDHE）协商出会话密钥（Symmetric Key）。
   • Finished：后续通信全部使用会话密钥进行对称加密传输。

第三阶段：HTTP请求与传输

1. 构建HTTP请求：

   • 浏览器构建报文（Request Line, Headers, Body）。
   • 安全加分项：携带Cookie/Token。如果是POST请求，这里可能涉及CSRF Token的校验。

2. 网络传输（封包与路由）：

   • OSI模型下沉：HTTP -> TCP段 -> IP包 -> MAC帧。
   • ARP协议：如果目标在局域网，通过ARP找到MAC地址；如果在外网，发给默认网关。
   • 路由转发：经过无数路由器（OSPF/BGP协议），最终到达腾讯云的机房入口。

第四阶段：服务端处理（你的主场：后端与SRE）

数据包到达服务器机房后，并不是直接给到你的Go/Python程序：

1. 接入层与防火墙：

   • DDoS防护/WAF：流量先经过高防IP或WAF（Web应用防火墙），清洗恶意流量（SQL注入、XSS特征识别）。

2. 负载均衡（Load Balancer）：

   • L4 LB（LVS/DPDK）做传输层转发 -> L7 LB（Nginx/Tengine）做应用层分发。
   • SRE加分项：LB根据算法（轮询、加权、一致性哈希）将请求分发给健康的后端Pod/服务器。

3. 应用服务处理（Backend）：

   • 请求到达你的 Go-zero / Gin 服务。
   • 业务逻辑：中间件处理（鉴权、限流）-> 业务代码 -> 数据库（MySQL）/ 缓存（Redis）/ 消息队列（Kafka）。

第五阶段：服务器响应与浏览器渲染

1. HTTP响应：

   • 服务器返回状态码（200 OK, 301 Moved, 404 Not Found, 500 Error）和响应体（HTML/JSON）。

2. 断开连接：

   • TCP四次挥手（或是HTTP/1.1 Keep-Alive保持连接，HTTP/2 多路复用）。

3. 浏览器渲染（前端视角）：

   • 解析HTML构建DOM树。

   • 解析CSS构建CSSOM树。

   • 执行JavaScript（可能阻塞渲染）。

   • Layout（布局） -> Paint（绘制） -> Composite（合成）

主机A给主机B发包什么情况会被拦截

从三个层面考虑：出发地，传输途中，目的地

出发地：主机A本身

• 本地防火墙：配置了出站规则
• ARP解析失败，主机A知道B的IP，但是不知道下一条的MAC地址

传输途中被拦截

• 路由器/交换机的访问控制列表（ACL），中间的路由配置了相应的规则或者有网络隔离的设置
• 运营商封锁：家用宽带通常无法访问80/443/8080端口作为服务器
• IPS/IDS：入侵防御系统检测到数据包中的内容包含了攻击特征
• MTU问题：包太大了，但是设置了不允许分片
• TTL耗尽：数据包在网络中传输遇到了路由回路，TTL减为0

目的地被拦截

• 主机B的防火墙或者安全设备
• 端口并未监听：A给B的8080端口发包，但是B没有程序监听
• 黑白名单的限制