不止端口数量：一台 Linux 服务器能扛多少连接，看这几个数

线上有人问“这台服务器最多能接多少 TCP 连接”，最常见的回答是 65535。这个数字只说明 TCP/UDP 端口字段是 16 位，并不等于整机连接上限。服务器能否继续接入新连接，取决于连接四元组、文件描述符、内核内存、监听队列、网卡与 CPU、应用工作模型，以及链路上的防火墙、NAT 和负载均衡器。任何一层先耗尽，用户看到的都可能只是超时、连接重置或 502。

真正可操作的问题应拆成三个：这台机器当前有多少连接；下一批连接会先撞上哪一种资源；在业务要求的延迟和错误率内，它能稳定维持多少连接。第三个数字必须通过贴近生产模型的压测得到，不能由一个内核参数推算出来。

先明确“连接”是哪一种连接

TCP 连接由源地址、源端口、目的地址、目的端口组成四元组。只要四元组不同，连接就不同。服务端监听 10.0.0.10:443 时，可以同时接收来自许多客户端地址和端口的连接，因此并不会因为只监听一个 443 端口就限制为一个连接。理论空间很大，工程上先耗尽的通常是资源，而不是四元组编码空间。

客户端主动连接却可能先受临时端口范围约束：同一个源 IP 到同一个目的 IP、目的端口时，每条并发连接需要不同的源端口。反向代理、网关和压测机都属于高风险角色。增加源 IP、增加上游目的地址或使用连接复用，往往比盲目扩大端口范围更有效。

先把问题边界写清楚：长连接还是短连接；TCP、TLS 还是 HTTP/2；空闲连接还是持续传输；服务器是最终服务端、四层代理，还是大量主动连出的七层代理。下面的只读清单用于保留环境基线。

uname -r
cat /etc/os-release
nproc
free -h
ip -br addr
ethtool "$(ip route show default | awk '{print $5; exit}')" 2>/dev/null
ss -s
ss -Htan state established | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state syn-recv | wc -l

nproc、内存和网卡速率决定容量量级，内核版本决定可用的观测字段和网络栈实现。ethtool 可能因虚拟网卡或权限失败，不应把失败解释为网卡异常。后四条同时给出 socket 汇总和关键 TCP 状态数。

用四个视角盘点当前状态

不要用一次 netstat | wc -l 作为连接数。它混入标题行、Unix socket，状态也不清楚。ss -s 的汇总开销较低，适合事故现场先看全局。

ESTAB 是已建立连接，TIME-WAIT 是已关闭但仍保留的四元组，SYN-RECV 是握手尚未完成。要区分“机器上的连接”和“本服务的连接”，按本地端口过滤。sport = :443 是服务端 443，不能误写成 dport。

ss -Htan '( sport = :443 )' | awk '{n[$1]++} END {for (s in n) print s,n[s]}' | sort
ss -Htan state established '( sport = :443 )' | head
ss -lntp '( sport = :443 )'

第二个视角是进程。连接是 socket，socket 是文件描述符的一种。系统总量尚有余量，不代表目标进程没有撞到自己的 soft limit。

pid=$(systemctl show -p MainPID --value nginx)
printf 'pid=%s\n' "$pid"
cat "/proc/$pid/limits" | sed -n '/open files/p'
printf 'fd_total='; find "/proc/$pid/fd" -mindepth 1 -maxdepth 1 -printf '.' 2>/dev/null | wc -c
printf 'socket_fd='; find "/proc/$pid/fd" -lname 'socket:*' 2>/dev/null | wc -l

这里以 Nginx 为例。LimitNOFILE 应查看实际主进程，而不是只看交互 shell 的 ulimit -n。多 worker 服务还应分别统计每个进程，避免总数掩盖单 worker 不均衡。

for p in $(pgrep -x nginx); do
  sockets=$(find "/proc/$p/fd" -lname 'socket:*' 2>/dev/null | wc -l)
  total=$(find "/proc/$p/fd" -mindepth 1 -maxdepth 1 2>/dev/null | wc -l)
  printf '%-8s total_fd=%-8s socket_fd=%s\n' "$p" "$total" "$sockets"
done

第三个视角是系统文件句柄。file-max 是系统级上限，file-nr 的第一个数是已分配句柄；不同内核对中间字段的含义有差异，判断时以当前内核文档为准，不做简单三字段相减。

sysctl fs.file-max fs.nr_open
cat /proc/sys/fs/file-nr
sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches

第四个视角是 socket 内存与协议计数器。大量空闲 TCP 连接也会占用内核对象、接收/发送缓冲和应用层状态；活跃 TLS 连接还占用户态会话内存。

cat /proc/net/sockstat
cat /proc/net/sockstat6
slabtop -o | head -n 25

sockstat 中 TCP: inuse、orphan、tw 和 mem 应结合趋势看。slabtop 的 TCP、sock_inode_cache 等对象只能用于定位内核对象增长，不能直接乘一个固定值推导单连接内存。

连接建立阶段：两个队列和一次握手

客户端发送 SYN 后，服务端先维护未完成握手队列；三次握手完成后，连接进入 accept 队列，等待应用调用 accept()。监听程序跟不上时，即使 CPU 看起来不高，队列也会溢出。

listen(backlog) 的参数、net.core.somaxconn 与应用配置共同限制 accept 队列。SYN 队列还受 tcp_max_syn_backlog 等机制影响。先看参数与监听 socket 的实时队列。

sysctl net.core.somaxconn \
       net.ipv4.tcp_max_syn_backlog \
       net.ipv4.tcp_syncookies \
       net.ipv4.tcp_synack_retries
ss -lnt '( sport = :443 )'

对 LISTEN socket，Recv-Q 表示等待应用 accept 的连接数，Send-Q 通常表示 backlog 上限。它们持续接近而不是偶发触碰上限，才说明应用接收能力可能不足。内核计数器能验证是否真实丢队列。

nstat -az TcpExtListenOverflows TcpExtListenDrops \
          TcpExtSyncookiesSent TcpExtSyncookiesRecv \
          TcpExtTCPReqQFullDoCookies TcpExtTCPReqQFullDrop

计数器是自启动以来的累计值，应看差分。下面脚本每 5 秒采一轮，适合在流量尖峰中观察增量，不修改系统。

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

interval=${1:-5}
prev_over=0
prev_drop=0

whilesleep"$interval"; do
read -r over drop < <(
    nstat -az 2>/dev/null |
      awk '$1=="TcpExtListenOverflows"{o=$2}
           $1=="TcpExtListenDrops"{d=$2}
           END{print o+0,d+0}'
  )
printf'%(%F %T)T overflow_delta=%d drop_delta=%d\n' -1 \
    "$((over-prev_over))""$((drop-prev_drop))"
  prev_over=$over
  prev_drop=$drop
done

首次输出是从 0 到累计值，不作告警依据；第二轮起才是区间增量。若增量上升，同时监听 Recv-Q 高，优先检查 worker 是否阻塞、事件循环延迟和应用 backlog，再考虑调大上限。只调 somaxconn 会把问题变成更长的排队。

已建立连接阶段：文件描述符只是入场券

提高文件描述符需要同时覆盖 systemd、应用和内核三层。以下变更会影响 Nginx，下发前先执行 nginx -t，并通过灰度节点验证。reload 通常保留现有连接，但仍应确认业务的优雅退出配置。

# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=262144

# nginx.conf 中的相关片段
worker_processes auto;
worker_rlimit_nofile 262144;

events {
    use epoll;
    worker_connections 65536;
    multi_accept off;
}

sudo systemctl daemon-reload
sudo nginx -t
sudo systemctl reload nginx
pid=$(systemctl show -p MainPID --value nginx)
grep -E 'Max open files' "/proc/$pid/limits"
sudo nginx -T 2>/dev/null | grep -E 'worker_(connections|rlimit_nofile)'

回滚时恢复 drop-in 和 Nginx 配置的上一版本，daemon-reload、nginx -t 后再 reload。不要把 worker_connections × worker_processes 直接当成客户端连接数：代理连接会同时占客户端和上游 socket，日志文件、监听 socket、缓存文件也占 FD；HTTP/2 多条请求可复用一个 TCP 连接，含义又不同。

事件模型也决定容量。一个连接一个线程的阻塞模型通常先耗线程栈、调度和进程限制；epoll/kqueue 事件模型更适合大量大部分时间空闲的连接，但业务回调阻塞仍会拖住整条事件循环。检查线程与上下文切换，不要只看平均 CPU。

pid=$(systemctl show -p MainPID --value myapp.service)
ps -o pid,ppid,nlwp,%cpu,%mem,rss,vsz,cmd -p "$pid"
pidstat -p "$pid" -t -u -w 1 10

如果是 JVM、Go 或 Node.js，用户态堆、协程/线程、TLS 缓冲、连接池对象各有自己的成本。必须在目标应用和实际加密配置下测 RSS、GC、调度延迟，而不是套用“一个 TCP 连接占几 KB”的固定结论。

TLS 还把“连接容量”拆成稳态容量和握手容量。大量已经建立且复用的 TLS 连接，主要承担记录层加解密；突发新建连接还要做非对称密码运算、证书链处理和随机数生成。服务在 5 万条稳定 keepalive 下可能很轻松，却在每秒数千次完整握手时 CPU 打满。会话恢复和 TLS 1.3 能降低握手成本，但恢复票据的密钥轮换、有效期和跨节点共享都会影响命中率，不能只在单机压测中假定全部恢复成功。

HTTP/2 又改变连接与请求的关系：一个连接承载多条并发 stream，TCP 连接数下降，但单连接故障域、流控与队头阻塞影响扩大。反向代理统计到 2 万连接，并不能说明后端只有 2 万并发请求；应同时记录活跃 stream、请求排队和上游连接。WebSocket 则常表现为长时间低流量连接，真正的拐点可能出现在广播事件：同一条消息向大量客户端扇出，瞬时发送缓冲、带宽和事件循环延迟一起升高。

因此容量测试至少要分三轮：只建连并保持，用来测状态成本；按真实速率持续请求，用来测稳态；在已有长连接基础上制造一次登录、重连或广播尖峰，用来测瞬态。三轮的最大连接数往往不同。容量档案应明确采用的是哪一种，而不是把最好看的空闲连接结果当成业务承诺。

主动连接：临时端口与 TIME_WAIT

反向代理连接上游时是客户端。默认临时端口范围可以直接查看。端口数量只约束同一源 IP 到同一目标四元组组合；多个源 IP、多个上游地址都会扩大空间。

sysctl net.ipv4.ip_local_port_range \
       net.ipv4.ip_local_reserved_ports \
       net.ipv4.tcp_fin_timeout \
       net.ipv4.tcp_tw_reuse

排查端口耗尽要按“本地源 IP + 上游 IP:端口”聚合，而不是只数全机 TIME_WAIT。

upstream=10.20.30.40
port=8080
ss -Htan "( dst $upstream and dport = :$port )" |
  awk '{print $1, $4, $5}' |
  sort | uniq -c | sort -nr | head -n 30

EADDRNOTAVAIL、Cannot assign requested address 是典型信号，但也可能来自绑定了不存在的地址。把应用日志与内核状态关联起来。

journalctl -u myproxy.service --since '-15 min' --no-pager |
  grep -Ei 'EADDRNOTAVAIL|cannot assign requested address|connect.*(timeout|failed)'
nstat -az TcpActiveOpens TcpAttemptFails TcpEstabResets

治理顺序通常是启用上游 keepalive、HTTP/2 或数据库连接池，降低短连接速率；然后分散上游目的地址或源 IP；最后在确认保留端口不冲突后调整临时端口范围。tcp_tw_reuse 的语义随内核版本变化，不应复制过时的 tcp_tw_recycle 调优方案，后者早已移除且会破坏 NAT 客户端。

以下 sysctl 只是示例变更流程，不代表所有机器都应使用这个范围。先记录当前值，检查 ip_local_reserved_ports，在一台代理节点灰度，持续验证连接错误。

sudo install -m 0644 /etc/sysctl.d/90-proxy-ports.conf \
  "/var/tmp/90-proxy-ports.conf.$(date +%s).bak" 2>/dev/null || true
cat <<'EOF' | sudo tee /etc/sysctl.d/90-proxy-ports.conf
net.ipv4.ip_local_port_range = 10000 60999
EOF
sudo sysctl --system
sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_reserved_ports

这里的 cat | tee 是可审阅的配置写入流程。回滚时恢复备份；若原文件不存在，则删除新文件后执行 sysctl –system，并用已记录的旧值立即 sysctl -w。调整不会为已经失败的请求自动重试。

TIME_WAIT 不是应当清零的垃圾

主动关闭连接的一方通常进入 TIME_WAIT，用于避免迟到报文污染同一四元组的新连接，并保证最后 ACK 丢失时能够重传。服务端若频繁主动关闭短连接，也会积累 TIME_WAIT；这通常暴露连接复用或关闭策略问题，而不是要求“清理连接”。

ss -Htan state time-wait |
  awk '{peer=$5; sub(/:[^:]*$/,":*",peer); n[peer]++}
       END{for (p in n) print n[p],p}' |
  sort -nr | head -n 20

IPv6 地址的文本切分比 IPv4 复杂，上述聚合仅用于快速观察；需要精确自动化时应使用 ss –json（若当前 iproute2 支持）或 eBPF 工具。不能用发送 RST、缩短所有超时等激进手段代替连接复用。

内核内存、队列、包率与带宽

“一百万空闲连接”与“一百万持续传输连接”是完全不同的负载。空闲连接主要消耗状态和保活检查；活跃连接受包率、带宽、软中断、拥塞控制、复制次数和应用计算限制。小包 PPS 可能比链路带宽更早打满 CPU。

sar -n DEV,EDEV,TCP,ETCP 1 10
mpstat -P ALL 1 10
softnet_stat=$(cat /proc/net/softnet_stat)
printf '%s\n' "$softnet_stat" | head

sar -n EDEV 看丢包和错误，mpstat 看软中断是否集中在少数 CPU。/proc/net/softnet_stat 是十六进制且字段随内核演进，不应直接凭某一列下结论；应结合对应内核文档或使用现成监控采集器。

查看网卡队列与丢弃计数，确认瓶颈是否已经在驱动层出现。

dev=$(ip route show default | awk '{print $5; exit}')
ip -s link show dev "$dev"
ethtool -S "$dev" 2>/dev/null | grep -Ei 'drop|miss|error|timeout|no.?buffer'
ethtool -l "$dev" 2>/dev/null

若要改 RSS/RPS、ring buffer、IRQ affinity，必须基于网卡驱动、NUMA 拓扑与基准测试灰度实施。错误调优可能使包乱序、缓存局部性变差或中断更集中，不能在事故中批量套参数。

TCP 缓冲区采用自动调节。最大值不是每条连接启动时立即预留的内存，但把最大值无限放大仍可能提高内存压力。先观测单连接的 skmem、拥塞窗口和 RTT。

ss -tinm state established '( sport = :443 )' | head -n 80
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem \
       net.core.rmem_max net.core.wmem_max

ss -m 的 skmem 能看到该 socket 缓冲使用，ss -i 提供 RTT、拥塞窗口和重传信息。抽样不能替代分位数监控，但能识别“连接很多却不传数据”和“发送队列堆积”这两类不同问题。

链路上的状态设备可能先失败

主机能容纳连接，不等于用户能建立连接。云负载均衡器、NAT 网关、conntrack、防火墙和 Service Mesh 都维护状态。特别是 Kubernetes 节点、NAT 出口与四层网关，常先撞到 conntrack 表。

sysctl net.netfilter.nf_conntrack_count \
       net.netfilter.nf_conntrack_max 2>/dev/null
conntrack -S 2>/dev/null
dmesg --ctime | grep -i 'nf_conntrack.*table full'

nf_conntrack_count / nf_conntrack_max 只是占用率；还要看插入失败、drop 和早期丢弃。调大表会消耗更多内核内存，且不能修复不合理的超时、短连接风暴或 NAT 单目的端口耗尽。变更前要估算内存、确认哈希表参数与内核版本，并在节点级灰度。

抓包用于回答握手在哪一步丢失。生产上先限制接口、端口、包数和快照长度，避免抓包文件吃满磁盘或暴露载荷。

sudo timeout 30 tcpdump -ni any 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)' \
  -c 2000 -s 128 -w /var/tmp/handshake.pcap
capinfos /var/tmp/handshake.pcap 2>/dev/null || ls -lh /var/tmp/handshake.pcap

若看到客户端反复 SYN 而服务端没有 SYN-ACK，检查路由、防火墙、监听和 SYN 队列；有 SYN-ACK 却无 ACK，检查回程路径与客户端；握手完成后立即 RST，再看应用 accept、TLS 与代理健康状态。抓包结束后按数据分级及时转移或安全删除文件。

容量测试：把连接数变成一条可验证曲线

容量测试必须复制关键特征：连接建立速率、连接保持时间、每连接请求率、请求/响应大小、TLS 版本、keepalive、HTTP/2 多路复用比例，以及上游依赖延迟。只建立空连接会严重高估业务容量。

先定义停止条件，例如错误率超过 0.1%、P99 超过 SLO、CPU 持续超过 75%、内存进入持续 reclaim、重传/丢包明显上升，或监听队列溢出。测试流量不得直接从未知压测机冲击生产；应在隔离环境或一组可摘流的灰度实例上进行，并设置自动停止。

一个分阶段测试流程可以写成可审阅脚本。这里假设已安装 wrk，目标 URL 和总时长由参数传入；timeout 是最后一道保险。

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

target=${1:?usage: $0 https://host/path}
for connections in 100 500 1000 2000 5000; do
  echo "stage connections=$connections"
  timeout 75s wrk -t4 -c "$connections" -d60s --latency "$target" \
    | tee "wrk-${connections}.log"
  sleep 30
done

wrk 更偏 HTTP 请求吞吐，不适合精确模拟海量低频 WebSocket 或任意 TCP 协议。压测机自身同样受 FD、CPU 和临时端口限制。执行前验证它不会先成为瓶颈。

ulimit -n
sysctl net.ipv4.ip_local_port_range
ss -s
mpstat 1 5
sar -n DEV,TCP,ETCP 1 5

长连接可用协议专用工具，或用小型程序建立并保持连接。下面的 Python 仅适合受控环境的 TCP/TLS 连通与保持测试，不发送业务协议，不应对未授权目标运行。

#!/usr/bin/env python3
import asyncio, ssl, sys

host, port, count = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
ctx = ssl.create_default_context() if port == 443elseNone

asyncdefopen_one(i):
    reader, writer = await asyncio.open_connection(host, port, ssl=ctx,
                                                    server_hostname=host if ctx elseNone)
    return reader, writer

asyncdefmain():
    conns = []
    for start inrange(0, count, 100):
        batch = await asyncio.gather(*(open_one(i) for i inrange(start, min(start+100, count))))
        conns.extend(batch)
        await asyncio.sleep(0.2)
    print(f"established={len(conns)}")
    await asyncio.sleep(60)
    for _, writer in conns:
        writer.close()
    await asyncio.gather(*(w.wait_closed() for _, w in conns))

asyncio.run(main())

该程序没有重连、请求负载和结果分位数，只能验证建连路径。连接数量提高前要调整压测进程 FD，并监控客户端和服务端两侧。TLS 证书校验默认开启，测试私有 CA 时应把 CA 加入信任库，而不是在脚本中关闭校验。

服务端同时采样，避免事后只有一个吞吐数字。

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

out=${1:-capacity-$(date +%Y%m%d-%H%M%S)}
mkdir -p "$out"
for i in $(seq 1 120); do
  ts=$(date --iso-8601=seconds)
  estab=$(ss -Htan state established '( sport = :443 )' | wc -l)
  synrecv=$(ss -Htan state syn-recv '( sport = :443 )' | wc -l)
  fd=$(cat /proc/sys/fs/file-nr)
  mem=$(awk '/MemAvailable|Slab|SReclaimable/ {printf "%s=%s ",$1,$2}' /proc/meminfo)
printf'%s estab=%s synrecv=%s file_nr="%s" %s\n'"$ts""$estab""$synrecv""$fd""$mem" \
    >> "$out/host.log"
sleep 5
done

最终容量不是“最后成功建立的连接数”，而是停止条件首次被突破前、还能保持目标持续时间的最大档位，再乘以安全系数。还要给故障切流留余量：两台节点各跑 80% 容量，一台故障时另一台不可能接住全部流量。

监控应覆盖耗尽链条

节点监控至少包括：按状态的 TCP 数、进程 FD 占比、系统 file-nr、内存与 slab、监听溢出、重传与 reset、conntrack 占比、网卡丢包、软中断、应用 accept/TLS/请求错误、P95/P99 延迟。只告警连接总数会在正常业务增长时产生噪声。

使用 node_exporter 时，指标名和是否启用 conntrack/netstat collector 需以当前版本为准。可先在采集端确认实际暴露的指标。

curl -fsS http://127.0.0.1:9100/metrics |
  grep -E '^node_(filefd|sockstat|netstat|nf_conntrack|network_)' | head -n 80

根据实际指标可建立组合告警，而非猜测指标存在。示例 PromQL 表示 conntrack 使用率高，需要再加 for 和节点角色过滤。

# conntrack 占用率
100 * node_nf_conntrack_entries
  / clamp_min(node_nf_conntrack_entries_limit, 1) > 80

# 监听队列溢出/丢弃速率
sum by (instance) (
  rate(node_netstat_TcpExt_ListenOverflows[5m])
  + rate(node_netstat_TcpExt_ListenDrops[5m])
) > 0

进程 FD 最好由 process-exporter 或应用自身暴露，并用最大值与 limit 比较。监听溢出应看速率。两条查询都应加上持续时间和节点角色过滤，避免瞬时采集抖动或无关节点触发告警。

故障现场的判断顺序

新连接失败时，按路径从外到内排查：DNS/负载均衡是否把流量发到本机；端口是否监听；SYN 是否到达并完成握手；监听队列是否溢出；进程 FD 是否接近限制；应用是否卡在 CPU、锁、GC 或上游；主机是否有端口、conntrack、内存、网卡和软中断压力。

下面的巡检脚本只读，便于在十分钟内收集证据。它不替代应用日志和链路指标。

#!/usr/bin/env bash
set -u

port=${1:-443}
echo'## time'; date --iso-8601=seconds
echo'## load/memory'; uptime; free -h
echo'## socket summary'; ss -s
echo'## listener'; ss -lntp "( sport = :$port )"
echo'## states'
for state in established syn-recv time-wait close-wait; do
printf'%-12s '"$state"
  ss -Htan state "$state""( sport = :$port )" | wc -l
done
echo'## limits'; sysctl fs.file-max net.core.somaxconn net.ipv4.tcp_max_syn_backlog
echo'## file-nr'; cat /proc/sys/fs/file-nr
echo'## sockstat'; cat /proc/net/sockstat
echo'## listen counters'
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpRetransSegs TcpEstabResets
echo'## conntrack'
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max 2>/dev/null || true

若大量 CLOSE-WAIT，说明对端已经关闭而本应用迟迟没有 close，通常是应用泄漏或阻塞；调内核超时不能解决。若 SYN-RECV 和 ListenDrops 上升，看握手与队列。若已建立连接稳定但请求超时，问题更可能在应用处理、上游或发送队列。若客户端报临时端口错误而服务端正常，则回到主动连接端检查四元组与连接复用。

一台服务器“能扛多少连接”最终应交付为容量档案：负载模型、软件与内核版本、实例规格、关键配置、稳定连接数、建连速率、吞吐与延迟分位数、资源拐点、停止条件、安全余量和回滚阈值。这个档案经过每次内核、TLS 库、应用版本或实例规格变更后都要复测。65535 只是字段宽度带来的数字，容量工程关心的是整条链路中第一个变红的资源，以及它变红前业务是否仍然达标。

文末福利

今天给大家分享一份超级牛掰的Linux学习笔记，足足有1456页！是一位Linux运维大佬整理分享的，分享是获得大佬同意的，大家有需要的尽管收藏起来！

笔记介绍

这份笔记非常全面且详细，从Linux基础到shell脚本，再到防火墙、数据库、日志服务管理、Nginx、高可用集群、Redis、虚拟化、Docker等等，与其说Linux学习笔记，不如说是涵盖了运维各个核心知识。

并且图文并茂，代码清晰，每一章下面都有更具体详细的内容，十分适合Linux运维学习参考！

笔记展示

笔记下载

扫描下方二维码，回复暗号“1456页Linux笔记“，即可100%免费领取成功

本文链接：https://www.yunweipai.com/archives/49448