短连接

• 模式：建立连接 -> 发送数据 -> 关闭连接。
• 背景：早期的 HTTP/1.0。每请求一个网页上的图片或 CSS，都要经历一次 TCP 三次握手和四次挥手。
• 缺点：开销极大。频繁地创建和销毁连接非常耗费 CPU 和内存资源。

长连接

• 模式：建立连接 -> 发送数据 -> 保持连接 -> 发送数据 -> ... -> 关闭连接。
• 背景：HTTP/1.1 默认开启。在 HTTP Header 中加入 Connection: keep-alive。
• 特点：
  • 复用：同一个 TCP 连接可以发送多个 HTTP 请求。
  • 半双工：虽然连接没断，但依然是“请求-响应”模式。必须客户端先问，服务端才能答。
  • 阻塞：前面的请求没处理完，后面的请求就得排队（Head-of-line blocking）

WebSocket (全双工长连接)

• 模式：HTTP 握手升级 -> 建立持久 TCP 连接 -> 双向实时传输。
• 背景：为了解决“服务端主动推送到客户端”的问题（如聊天、实时股票）。
• 特点：
  • 全双工：客户端和服务器可以同时给对方发消息，不需要等对方回应。
  • 协议升级：它开始时借用 HTTP 的 80/443 端口进行握手，握手成功后就“脱离” HTTP，转为 WebSocket 协议。
  • 轻量：数据头非常小，适合频繁发送短消息。

tcp time_wait的作用

• 确保旧连接的所有报文都消失
  • 大白话：防止之前连接的被动关闭方的延迟数据被错认为新链接的数据
• 防止被动关闭方没有收到最后的ACK引起报错
  • 大白话： 被动关闭方发送的fin一直收不到ack

tcp粘包

• tcp本身是面向流的协议，是没有消息边界的
• TCP 为了效率，会把多个小的数据包合并成一个大的发出去（Nagle 算法）；
• 接收方处理不够快，多个包积压在接收缓冲区里，一次性读出来了

拆包

• 数据包太大，超过了 MSS（最大报文段长度），
• IP 层进行了分片，导致一个完整的消息被切断成两半发送。
• 解决方案
  • 包设置固定长度
  • 增加分隔符
  • 消息头带长度（Length Field Based）（把包分成“头”和“体”）
  • 自定义序列化协议
    • 使用 Protobuf、JSON 等。虽然它们本身不解决粘包，但通常配合方案3使用

IPC常见方式

• ipc的常见方式有信号量、pipe（管道）、消息队列、共享内存、套接字等
• 不同ipc方式的优缺点和场景
  • pipe ： 优点是简单， 缺点是半双工，只能单向传输
  • 共享内存：