短连接

• 模式：建立连接 -> 发送数据 -> 关闭连接。
• 背景：早期的 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的作用

• 确保旧连接的所有报文都消失
  • TCP 用四元组标识连接。
  • 如果连接关闭后立即复用相同四元组，网络中旧连接的延迟报文可能会被新连接误接收。
  • 主动关闭方保持 TIME_WAIT（2MSL），确保旧连接中的所有报文都已经从网络中消失，再允许相同四元组建立新连接。
  • 因此，TIME_WAIT 防止的是旧连接的数据污染新连接，而不是防止数据被他人窃取
  • 大白话：防止之前连接的被动关闭方的延迟数据被错认为新链接的数据
• 防止被动关闭方没有收到最后的ACK引起报错
  • 影响：如果被动关闭方没有收到最后的主动关闭方通知的ack，会重发ret 通知给主动关闭方，这时原先的client1 已经关闭，并且新的client2已经建立，它会因为收到server1的ret命令而终止连接
  • 大白话： 被动关闭方发送的fin一直收不到ack

tcp粘包

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

拆包

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

IPC常见方式

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

http2 和http1.1的区别

最本质的区别是http1.1是基于文本、按顺序传输的协议，而http2是基于二进制帧、支持多路复用的协议

• 二进制帧
  • 将所有传输信息分为为更小的二进制帧，将header封装为headers帧，body封装为data帧
• 多路复用
  • http1.1的请求响应是严格排序的，同一条tcp连接上，上一次请求的响应没有安全接手前，下一个请求无法发送，最多只能通过浏览器同一个域名同时建立6-8条tcp连接
  • http2 在单条tcp连接上，不同的请求和响应被切分为带编号的帧，这些帧可以交错乱序发送，到达接收端后再进行组装
• 首部压缩
• 服务端推送