TCP
2025-01-21 11:44:46
TCP 四次挥手，在实际中可能只能抓到 3 个包
TCP flag：
- SYN：建立连接
- FIN：断开连接
- ACK：响应
- PSH：有 DATA数据传输
- RST：连接重置
- URG：紧急
PSH 和 ACK 是通用的组合 ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应， RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。
PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。
https://zh.wikipedia.org/wiki/TCP%E5%BB%B6%E8%BF%9F%E7%A1%AE%E8%AE%A4 https://www.cnblogs.com/Xinenhui/p/17982452 https://zyy.rs/post/tcp-flags-psh-and-urg/ https://www.cnblogs.com/diegodu/p/4213799.html high: https://writings.sh/post/network-tcp http://timd.cn/tcp-window/
TCP 的接收方在收到数据后，需要回复 ACK 数据包，表示已经确认接收到 ACK 确认号前面的所有数据。
ACK 机制：接收方在接收到数据后，不会立即发送ACK的原因：
- 收到数据包的序号签名还有需要接收的数据包。
- 为了降低网络流量，ACK 有延迟确认机制
- ACK 的值到达最大值，从0开始
Nagle 算法（发送角度）
综合 累计发送 + 延迟发送 这两个策略
避免小数据传输（发送角度）
- 没有已发送未确认的报文时，马上发送数据
- 存在未确认数报文时，直接没有已发送未确认报文或数据长度达到MSS大小时再发送数据
- 不满足上面的条件，那么发送方会囤积数据直到条件满足
Delay ACK（接收角度）
TCP有两种确认方式：
- 快速 ACK：本端收到数据包后，立即发送ACK给对端
- 延迟 ACK：本端收到数据包后，等待一段时间再发送ACK
- 如果需要发送数据，那么ACK在发送数据包中携带
- 否则，发送一个累计确认的ACK给对端(收到的最大seq+1)
在实现中，使用 pingpong 来区分 延迟确认：控制累计确认的时机
TCP 传输的数据流：
- TCP 交互数据流：一般情况下数据总是以小于 MSS 的分组发送，做的是小流量的数据交互，如 SSH、Telnet
- TCP 成块数据流：TCP 尽最大能力传输数据，数据按照 MSS 发送，如 FTP
Delay Ack：延迟发送ACK
- 延迟一段时间后再发送ACK，系统有一个固定的定时器每隔200ms来检查是否需要发送ACK包
- ACK可以合并，如果连续收到两个TCP包，只需要回复最终的ACK（累计确认机制）
- 接收方有数据要发送，那么可以在发送数据的TCP包里面带上ACK信息，避免单独发送ACK包
参考：
- https://www.kawabangga.com/posts/5845
- https://blog.csdn.net/wdscq1234/article/details/52430382
- https://blog.csdn.net/2303_77208351/article/details/137938001
有延迟确认，那么接收方会累计ACK，而发送方在延迟的时间内收不到AK，就不会发送小的数据包，而是留在缓冲中。
- 两个一起使用的时候会影响性能
TCP 对 HTTP 性能的影响
- 建立连接，三次握手
- TCP 慢启动：TCP拥塞控制手段，在TCP刚建立好之后的最初传输阶段会限制连接的最大传输速度，后续逐步提高
- TCP 延迟确认
- Nagle 算法
- TIME_WAIT积累与端口耗尽
- 服务端端口耗尽
- 服务端HTTP进程打开文件数量达到最大
HTTPS，还需要加上 TLS 的影响
https://www.cnblogs.com/rexcheny/p/10777906.html
HTTP 协议
https://byvoid.com/zhs/blog/http-keep-alive-header/
公共语义
HTTP1
基本格式
HTTP2
基本格式
Hpack
流量控制
HTTP3
HTTPS
TLS/SSL 证书
https://blog.laisky.com/p/https-in-action/#gsc.tab=0 https://www.kawabangga.com/posts/5330
证书透明度： https://certificate.transparency.dev/howctworks/