你以为 WebSocket 是 HTTP 的升级版？其实它像寄生虫一样依附在 Socket 的躯壳上，这个隐秘的底层依赖藏着多少你不知道的网络玄机？
你有没有想过，为什么 WebSocket 要用 HTTP 协议做"伪装"？这个看似简单的协议切换背后，藏着操作系统内核与应用层的微妙博弈。我们来剥开这个通信协议的洋葱，看看那些被忽视的细节。
Socket 是操作系统内核提供的网络编程接口，它像一把瑞士军刀般锋利。当你用 socket() 函数创建连接时，实际上是在调用内核的 sys_socket() 系统调用，这个调用会返回一个文件描述符，而这个文件描述符本质上是内核维护的 file 结构体。有趣的是，TCP/IP 协议栈的实现其实就藏在这个文件描述符的底层结构里。
WebSocket 的诞生堪称一场"伪装秀"。它通过 HTTP 协议发起连接，但实际建立的是 TCP 全双工通道。这个过程就像在 HTTP 请求头里藏了颗定时炸弹：GET /chat HTTP/1.1 请求中携带的 Upgrade: websocket 字段，实际上是向服务器发出"我要改换通信模式"的暗号。当服务器响应 101 Switching Protocols 时，TCP 连接就完成了从 HTTP 到 WebSocket 的蜕变。
但这种蜕变并不彻底。WebSocket 的帧格式依然保留着 HTTP 的影子，比如 16 位的 payload length 字段，这让人想起 HTTP 的 content-length 头。更微妙的是，WebSocket 的握手过程必须经过 TLS 握手的洗礼——这可不是简单的加密需求，而是现代网络架构对 安全传输的强制要求。
在内核层面，Socket 缓冲区的管理堪称艺术。当 WebSocket 连接建立后，内核会为每个连接维护 sendmsg() 和 recvmsg() 的缓冲区，这些缓冲区的大小直接影响着 吞吐量。我曾经在调试一个实时游戏服务器时，发现将 SO_SNDBUFF_SZ 从默认的 20KB 调整到 64KB，能让帧传输延迟降低 30%。
说到性能优化，epoll 的魔力不容小觑。当处理大量 WebSocket 连接时，epoll ET 模式的使用能显著减少 IO 轮询开销。但要注意，LT 模式在某些场景下反而更稳定，这需要根据你的业务模型来取舍。就像在 Linux 内核中，select() 系统调用的线性复杂度，让它的存在变得有些尴尬。
QUIC 协议的出现让这种关系更复杂了。它直接在 UDP 层实现多路复用，绕过了 TCP 的拥塞控制。但即便如此，QUIC 的连接建立依然需要 Socket API 的支持。这让我不禁思考：当 HTTP/3 与 WebSocket 交织在一起时，网络协议栈的边界究竟在哪里？
尝试用 Wireshark 抓包分析一个 WebSocket 连接，你会发现 TCP 的三次握手和 TLS 的 handshake 交织在一起，像一幅复杂的网络画卷。而 WebSocket 帧的解析，需要特别注意 fin 和 rsv 位的组合——这些位字段的设置，决定了数据传输的模式。
关键字：Socket, WebSocket, TCP/IP, HTTP/3, QUIC, TLS, epoll, eBPF, DPDK, 协议栈, 全双工通信