TCP实战抓包分析

TCP实战抓包分析

学习资源 小林coding 2022.4.8

显形网络包

• tcpdump 仅支持命令行使用 常在linux种抓取和分析网络包
• Wireshark 除了可以抓包 还提供了可视化分析网络包的图形界面

三次握手分析

• TCP第一次握手 SYN丢包 RTO翻倍增长

  

• TCP第二次握手 SYN ACK丢包

  • 客户端发起SYN后 防火墙屏蔽数据包 超时 重传SYN包
  • 客户端收到客户的SYN包后 回SYN ACK包 客户端一直没有回ACK 服务端超时重传 SYN ACK
  • 客户端超时重传的SYN又到达服务器 服务端收到后 回SYN ACK
  • SYN ACK重传定时器没有充值 持续重传 超过最大次数

  第二次挥手的SYN ACK丢包时 客户端会超时重发SYN 服务端也会超时重传SYN ACK

  客户端SYN超时重传的最大次数 是由tcp_syn_retries决定的

  服务端SYN ACK包重传的最大次数 是由 tcp_synack_retries 决定

  默认5次

• TCP第三次握手 ACK丢包

  • 客户端发送SYN包 服务端发送SYN ACK 服务端处于SYN_RECV状态
  • 客户端收到SYN ACK 给服务端发送ACK TCP连接处于ESTABLISHED状态
  • 屏蔽ACK 服务端一直处于SYN_RECV状态
  • 服务端超时重传SYN ACK包 重传4次 没有继续重传 服务端TCP主动连接断开
  • 服务端TCP断开 但是发现客户端仍然处于建立状态 在客户端的telnet发送123456会话
  • 客户端发送的数据报文一直在重传 RTO指数增长

  TCP建立连接后最大超时重传次数是由tcp_retries2指定默认15次

  如果客户端不发送数据 什么时候才会断开处于ESTABLISHED状态的连接

  TCP的保活机制

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9

保活时间 2h 两小时内如果没有任何连接相关的活动 则会启动保活i价值

每次检查间隔75s 9次没响应 就中断连接

TCP快速建立连接

客户端在向服务端发起HTTP GET请求的时候 一个完整的交互过程 需要2.5RTT

第三次握手可以携带数据 第三次握手携带数据 需要2RTT

Linux3.7 提供了 TCP Fast Open 功能 可以减少TCP连接建立的时延

• 在第一次建立连接的时候 服务端在第二次握手产生一个Cookie并通过SYN ACK包一起发送客户端 客户端缓存Cookie 第一次发起HTTP Get 请求的时候 需要2RTT的时延
• 下次请求的时候 客户端在SYN包带上Cookie发给客户端 Cookie中维护了一些信息 服务端可以从Cookie 获取TCP相关的信息 此时发起的HTTP GET请求只需要1个RTT的时延

TCP重复确认和快速重传

当接收方收到乱序数据包时 会发送重复的ACK 以便告知发送方要重传该数据包 当发送方收到3个重复ACK 就会触发快速重传 立即重发丢失包

启用SACK -> 重传丢失的数据包

TCP流量控制

通过滑动窗口机制 利用接收方的接受窗口来控制发送方要发送的数据量

接收窗口时由接收方指定的值 存储在TCP头部中 可以告诉发送方自己的TCP缓冲空间区大小

整个缓冲区给应用程序读取数据的空间

• 如果应用程序读取了缓存区的数据 那么缓冲空间区就会把读取的数据移除
• 如果应用程序没有读取数据 则数据会一直滞留在缓冲区

现实中服务器会出现繁忙的情况 当应用程序读取慢 缓存空间逐渐会被占满 于是为了保证发送方发送端数据不会超过缓冲区大小

服务器则会调整窗口大小的值 接着通过ACK报文通知对方 告知窗口大小

零窗口通知与窗口检测

假设接收方处理数据的速度跟不上接受数据的速度 缓存就会被占满 从而导致接收窗口为0 当发送方接收到零窗口通知时 就会停止发送数据

发送方会定时发送窗口大小探测报文 以便及时知道接收方窗口大小的变化

窗口探测报文 超时时间翻倍递增

发送窗口的分析

win 在向对付声明自己的接受窗口

发送窗口 min（拥塞窗口 接受窗口）

发送窗口与MSS关系

发送窗口决定了一口气发多少字节

MSS决定这些字节要分多少包才能发完

发送方在一个窗口发出n个包 是不是需要n个ACK确认报文

不一定 TCP由累计确认机制 当收到多个数据包时 只需要应答最后一个数据包的ACK报文就可以了

TCP延迟确认与Nagle算法

• 延迟确认
• Nagle算法

Nagle算法 如何避免大量TCP小数据报文的传输

Nagle算法做了一些策略来避免过多的小数据报文发送 可以提高传输效率

• 没有已发送未确认报文时 立即发送数据
• 存在未确认报文 直到没有已发送未确认报文或数据长度达到MSS大小时再发送数据
• 只要没满足上面条件中的一条 发送方一直在囤积数据 直到满足发送条件

延迟确认

没有携带数据的ACK网络效率很低

40个字节的IP头和TCP头 但却没有携带数据报文

衍生出了TCP延迟确认

• 当有相应数据要发送时 ACK会随着响应数据一起立刻发送
• 没有相应数据发送时 ACK将会延迟一段时间 等待是否有相应数据可以一起发送
• 如果在延迟等待发送ACK期间 第二个数据报文到达 立即发送ACK