最近对自己的路由器进行了一波小升级，这里记录一下过程。方便以后查询。

背景

• 目前使用的是绿云的东京服务器，走的是软银的线路，但是软银的线路最近对电信十分不友好（下载速度极慢），故专门记录了一波线路排查思路。

问题排查

• 生成一个文件用于测试下载速度：

fallocate -l 100M testfile

• 本机测试：
  • 可以看出下载速度还是很快的

curl -o /dev/null -s -w 'http_code=%{http_code} size=%{size_download} speed=%{speed_download} ttfb=%{time_starttransfer} total=%{time_total}\n' http://127.0.0.1/testfile

# http_code=200 size=104857600 speed=231244018 ttfb=0.000529 total=0.453450

• 外网测试（电信网络）：
  • 由于下载慢，只下载了10M，但是可以看出下载速度只有100KB/s左右，明显不正常。并且这个地方首包时间 TTFB 并不高，这说明：服务器响应以及连接是很快的。
  • 并且可以看出ping响应的速度是很快的。

curl -r 0-10485759 -o /dev/null -s -w 'http_code=%{http_code} size=%{size_download} speed=%{speed_download} ttfb=%{time_starttransfer} total=%{time_total}\n' http://{服务器IP}/testfile

# http_code=206 size=10485760 speed=186540 ttfb=0.178176 total=56.211763

PING {服务器IP} ({服务器IP}) 56(84) bytes of data.
64 bytes from {服务器IP}: icmp_seq=1 ttl=44 time=89.9 ms
64 bytes from {服务器IP}: icmp_seq=2 ttl=44 time=84.5 ms
64 bytes from {服务器IP}: icmp_seq=3 ttl=44 time=85.4 ms

• 然后服务端通过 ss 命令来查看TCP传输情况，然后客户端重新执行下载

# 客户端
curl -r 0-10485759 -o /dev/null -s -w 'http_code=%{http_code} size=%{size_download} speed=%{speed_download} ttfb=%{time_starttransfer} total=%{time_total}\n' http://{服务器IP}/testfile

# 服务端
for i in 1 2 3 4 5 6; do
  date '+-- %H:%M:%S --'
  ss -tin '( sport = :80 )'
  sleep 5
done

# cubic ... cwnd:46 bytes_retrans:52128 delivery_rate 6094840bps
# cubic ... cwnd:9  bytes_retrans:99912 delivery_rate 1131400bps
# cubic ... cwnd:7  bytes_retrans:130320 delivery_rate 1187000bps

• 可以看到，一开始的下载速度 delivery_rate 是很快的，但是后面下载速度降下来了。并且 cwnd 在持续减小。
• cubic是TCP的常见拥塞控制算法，用于在高延迟和高带宽的网络中保持稳定的传输。其他的算法有：Reno、BBR等。cwnd 一直在收缩，则代表当前网络线路不太好，导致一开始发送端发送速率很高，但是慢慢的由于窗口收缩，导致下载速度逐步下降。
• 于是，通过tcpdump来抓包，排查具体原因。

# 客户端，获取当前出口IP
curl ifconfig.me
# 客户端，下载
curl -r 0-10485759 -o /dev/null -s -w 'http_code=%{http_code} size=%{size_download} speed=%{speed_download} ttfb=%{time_starttransfer} total=%{time_total}\n' http://{服务器IP}/testfile
# 服务端，TCPdump抓包
sudo timeout 25 tcpdump -i any -nn host {客户端出口IP} and port 80 -w /tmp/cubic_slow.pcap

• 然后解析抓包出来的内容：

sudo tcpdump -nn -tttt -r /tmp/cubic_slow.pcap

• 结果有点多，让AI帮忙筛了一段关键信息：

29:2026-04-10 11:48:46.277592 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 19121, win 481, options [nop,nop,TS val 2213018799 ecr 3162461646], length 0
33:2026-04-10 11:48:46.277706 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 19121, win 481, options [nop,nop,TS val 2213018799 ecr 3162461646,nop,nop,sack 1 {20569:22017}], length 0
34:2026-04-10 11:48:46.277706 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 19121, win 637, options [nop,nop,TS val 2213018799 ecr 3162461646,nop,nop,sack 1 {20569:30705}], length 0
35:2026-04-10 11:48:46.277735 ens3  Out IP {服务器IP}.80 > {客户端出口IP}.6360: Flags [.], seq 19121:20569, ack 108, win 509, options [nop,nop,TS val 3162461742 ecr 2213018799], length 1448: HTTP
39:2026-04-10 11:48:46.277968 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 19121, win 721, options [nop,nop,TS val 2213018799 ecr 3162461646,nop,nop,sack 2 {37945:39393}{20569:36497}], length 0
45:2026-04-10 11:48:46.278328 ens3  Out IP {服务器IP}.80 > {客户端出口IP}.6360: Flags [.], seq 36497:37945, ack 108, win 509, options [nop,nop,TS val 3162461743 ecr 2213018799], length 1448: HTTP
49:2026-04-10 11:48:46.278628 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 19121, win 721, options [nop,nop,TS val 2213018799 ecr 3162461646,nop,nop,sack 1 {20569:36497}], length 0
57:2026-04-10 11:48:46.379828 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 36497, win 660, options [nop,nop,TS val 2213018895 ecr 3162461742,nop,nop,sack 1 {37945:55321}], length 0
59:2026-04-10 11:48:46.379829 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 36497, win 660, options [nop,nop,TS val 2213018895 ecr 3162461742,nop,nop,sack 1 {37945:48081}], length 0
63:2026-04-10 11:48:46.380143 ens3  In  IP {客户端出口IP}.6360 > {服务器IP}.80: Flags [.], ack 36497, win 660, options [nop,nop,TS val 2213018895 ecr 3162461742,nop,nop,sack 1 {37945:50977}], length 0

• 其中ack：代表已经确认收到的信息偏移量；sack：{a:b}代表a-b之间的信息已经确认收到。
• 这里sack一直出现，则代表后面一段数据已经拿到，但是中间有一段数据没有收到，需要重传缺失的部分，而不需要重复发送我已经收到的部分。
• 并且这里面有很多的包都出现了这种现象，因此几乎可以确认是电信到绿云软银的这条线路丢包比较严重。

解决方案

• 既然知道是因为这条线路丢包严重的问题，而 cubic 会很容易将这个丢包当成严重阻塞，从而反复降低发送窗口。这样即使延迟不高，吞吐仍然会很差（事实上服务器的网络是很充足的）。
  • cubic、reno：
    • 有包丢了，就认为网络已经拥塞了，然后明显降速，再慢慢试探增大。
  • bbr：
    • 估计链路的瓶颈带宽、最小 RTT，让发送速率尽量接近链路能承载的贷款。
• 因此，直接切换bbr就行了。
• 切换脚本：

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_VERBOSE=0
algorithm=""
sysctl_config_file="/etc/sysctl.d/99-tcp-congestion-control.conf"
module_config_file="/etc/modules-load.d/tcp_bbr.conf"
legacy_sysctl_config_file="/etc/sysctl.d/99-bbr.conf"
legacy_module_config_file="/etc/modules-load.d/bbr.conf"

usage() {
  cat <<'USAGE'
Usage: switch_tcp_congestion_control.sh --algorithm NAME [--verbose]

Purpose:
  Switch the system TCP congestion control algorithm.

Required inputs:
  --algorithm   bbr | cubic | reno

Optional inputs:
  --verbose     print debug logs
  --help        show this message

Default behavior:
  No interactive mode. The script fails if --algorithm is missing.

Side effects:
  Writes /etc/sysctl.d/99-tcp-congestion-control.conf.
  When --algorithm bbr is used, writes /etc/modules-load.d/tcp_bbr.conf and loads tcp_bbr.
  When --algorithm cubic or reno is used, removes the tcp_bbr module auto-load file.
  Legacy files /etc/sysctl.d/99-bbr.conf and /etc/modules-load.d/bbr.conf are removed if present.

Examples:
  sudo script/switch_tcp_congestion_control.sh --algorithm bbr
  sudo script/switch_tcp_congestion_control.sh --algorithm cubic
USAGE
}

die() {
  echo "ERROR: $*" >&2
  exit 1
}

debug() {
  if [[ "${SCRIPT_VERBOSE:-0}" -eq 1 ]]; then
    echo "DEBUG: $*" >&2
  fi
}

require_cmd() {
  local cmd="$1"
  command -v "$cmd" >/dev/null 2>&1 || die "required command not found: $cmd"
}

validate_algorithm() {
  case "$1" in
    bbr|cubic|reno) ;;
    *)
      die "unsupported algorithm: $1"
      ;;
  esac
}

require_root_user() {
  if [[ "$EUID" -ne 0 ]]; then
    die "this script must be run as root, for example: sudo $0 --algorithm ${algorithm:-bbr}"
  fi
}

parse_args() {
  while [[ $# -gt 0 ]]; do
    case "$1" in
      --algorithm)
        [[ $# -ge 2 ]] || die "--algorithm requires a value"
        algorithm="$2"
        shift 2
        ;;
      --verbose)
        SCRIPT_VERBOSE=1
        shift
        ;;
      -h|--help)
        usage
        exit 0
        ;;
      *)
        die "unknown argument: $1"
        ;;
    esac
  done

  [[ -n "$algorithm" ]] || die "--algorithm is required"
  validate_algorithm "$algorithm"
}

ensure_supported_algorithm() {
  local available

  available="$(sysctl -n net.ipv4.tcp_available_congestion_control 2>/dev/null || true)"
  [[ " $available " == *" $algorithm "* ]] || die "algorithm not available in kernel: $algorithm"
}

remove_legacy_configs() {
  rm -f "$legacy_sysctl_config_file" "$legacy_module_config_file"
}

configure_bbr_module() {
  if [[ "$algorithm" == "bbr" ]]; then
    require_cmd modprobe
    modprobe tcp_bbr
    printf 'tcp_bbr\n' > "$module_config_file"
  else
    rm -f "$module_config_file"
  fi
}

write_sysctl_config() {
  cat > "$sysctl_config_file" <<EOF2
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=$algorithm
EOF2
}

apply_runtime_settings() {
  require_cmd sysctl
  sysctl -w net.core.default_qdisc=fq >/dev/null
  sysctl -w net.ipv4.tcp_congestion_control="$algorithm" >/dev/null
}

print_status() {
  sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc net.ipv4.tcp_available_congestion_control
}

main() {
  parse_args "$@"
  require_root_user
  debug "selected algorithm: $algorithm"
  configure_bbr_module
  ensure_supported_algorithm
  remove_legacy_configs
  write_sysctl_config
  apply_runtime_settings
  print_status
}

main "$@"

• 然后执行切换成bbr，既可。

• 以下是切换后的对比，可见，下载速度提升了很多：

  算法	速度	总耗时	TTFB
  cubic	78358 B/s	133.82s	0.158s
  reno	128833 B/s	81.39s	0.174s
  bbr	2406963 B/s	4.36s	0.179s