企业官网建设流程全解析

1. 开篇聊两句：为什么Linux网络基础这么重要

带过几十个新人，踩过无数次网络坑之后，我想说Linux网络基础真的不是背几条命令那么简单。它是所有上层服务——Web、数据库、容器编排、云原生——能够正常运转的地基。你在服务器上部署一个服务，发现别人访问不到；你搭了一个集群，发现节点之间通信超时；你写了个监控脚本，发现数据上报失败。这些问题到最后，八成都要回到网络基础上去找原因。

这篇《Linux_网络基础(一)》作为系列开篇，我会把Linux下网络相关的核心概念、常用工具链、排查思路和配置方法串起来讲一遍，尽量说人话，不堆术语。适合刚入行的运维、后端开发，也适合那些已经在用Linux但始终对网络一知半解的同行。看完你会对“Linux里网络是怎么工作的”“出了问题该从哪里下手”有一个清晰的框架，而不是遇到问题只会重启服务、重启网卡。

2. 先搞懂Linux网络栈的宏观架构

2.1 从分层模型到Linux内核网络栈

学网络绕不开OSI七层模型和TCP/IP四层模型。但在Linux里，我们真正打交道的是内核网络协议栈——它把应用层、传输层、网络层、链路层串成一条完整的数据通道。你用浏览器访问一个网站，数据从nginx进程写入socket，经过TCP/UDP处理，再走IP层封装路由，最后从网卡发出去；收到的数据包则反过来一路解包，最终把数据交到用户态的应用程序手上。

这个过程看似简单，实际涉及中断、内核缓冲区、软中断（softirq）、协议处理队列等一堆机制。我举一个简化类比：你可以把内核网络栈想象成一个快递分拣中心。应用层是发件人和收件人，传输层是给包裹贴快递单（端口号、序列号、校验信息），网络层是决定包裹从哪个分拨中心走（IP地址、路由表），链路层则是把包裹装进具体的一辆货车（以太网帧、MAC地址）。理解了这层关系，后面看任何网络问题都会顺很多。

从实操角度，我们不需要把内核协议栈每一行代码都看懂，但至少要清楚几个关键文件的位置和作用。它们是理解整个Linux网络状态的“窗口”。

2.2 内核网络模块与关键文件概览

先列几个你必须知道的基础点：

• /proc/net/dev：记录每个网卡的收发包统计、错误包、丢包数，排查网卡层面问题最先看这里。
• /proc/net/tcp和/proc/net/udp：记录当前TCP和UDP连接状态。
• /proc/sys/net/ipv4/：存放TCP/IP相关内核参数，比如转发、超时、缓冲区大小等。
• /etc/services：端口号与服务的映射表，虽然现代程序更多用约定俗成的端口，但它仍是一个很好的查询参考。
• /etc/resolv.conf：DNS客户端配置，指定了系统用哪台DNS服务器解析域名。
• /etc/nsswitch.conf：决定主机名解析的顺序，是先查DNS还是先看本地hosts文件。

另外，netfilter/iptables是Linux内核连接网络包过滤、NAT等机制的关键框架。后面排障或做安全策略时经常要和它打交道。这一篇先记住它的存在，下一篇系列内容再做深入。

3. 查看网络状态：常用命令与实操细节

3.1 网卡与IP地址：ifconfig 和 ip addr

很多老运维习惯用ifconfig，但它所在的net-tools包现在已经不是默认安装，而且它显示的信息相对基础。我强烈建议你把ip命令作为主力工具，它来自iproute2包，在几乎所有现代发行版里默认就有。

# 查看所有网卡及其IP地址、MAC地址、状态 ip addr show # 只看某个网卡 ip addr show eth0 # 查看和修改网卡启停状态 ip link set eth0 up ip link set eth0 down

用ip addr查看一块正常配置了IP的网卡，你会看到类似下面这样的输出。这里最容易被新手忽略的是UP和LOWER_UP两个标志。UP说明网卡管理上启用，LOWER_UP说明物理链路已连接（网线插好、交换机端口正常）。如果只有UP而没有LOWER_UP，大概率是物理链路或对端交换机的问题。

ifconfig也不是完全没用，某些老脚本、老系统还在用它，遇到不支持ip命令的极简容器镜像时可以应急。但从长期来看，涉及网卡配置、路由操作，统一用ip命令能少踩很多兼容性坑。

顺带说一个排查自动获取IP问题的技巧：如果你用DHCP但没拿到地址，网卡可能会被分配一个169.254.x.x开头的IP，这是系统自分配的链路本地地址。看到这个地址，基本可以断定DHCP流程出了问题，而不是你手滑配错了静态IP。

3.2 路由表与网关：route 和 ip route

路由决定了一个数据包从本机出发后，下一跳该交给谁。理解路由表，比理解复杂路由协议更重要，因为日常排障95%以上都在和直连路由、默认路由打交道。

# 查看路由表 ip route show # 或旧的 route -n

典型的输出大概是这样的：

default via 192.168.1.1 dev eth0 proto dhcp metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

第一行是默认路由，所有不在其他路由表项里的目的地址，都走192.168.1.1这个网关。第二行是直连路由，表示本机所在网段内的地址，直接通过eth0发出去，不需要过网关。你访问一个外网IP时，系统先查路由表，发现没有更精确的匹配，于是走默认路由，把包交给网关，由网关继续向外转发。

排查网络不通时，ip route绝对是第一梯队要看的命令。举个例子：一个服务器配置了静态IP，但只能访问内网，不能上外网。第一反应就是看默认路由是否存在。曾经排查过一个类似案例，发现服务器上默认路由被人为删掉了，导致所有外网访问失败，解决办法就是重新加一条默认路由。

ip route add default via 192.168.1.1 dev eth0

提醒：手动添加的路由重启后通常不会保留，要么写成配置持久化，要么用网络管理工具统一管理，下面配置章节会详细说明。

3.3 连接与监听：netstat 与 ss

检查端口监听状态，是老生常谈的需求。netstat -tlnp是多少人刻在DNA里的命令。但我还是要再推荐一次ss，它在输出速度和信息完整性上都优于netstat，尤其在连接数多的服务器上，netstat甚至会卡顿，ss则快得多。

# 查看所有TCP监听端口及对应进程 ss -tlnp # 查看所有TCP连接 ss -tn state established # 查看socket统计信息 ss -s

ss -s的输出能快速告诉你系统当前有多少TCP连接、多少处于TIME_WAIT状态，非常有诊断价值。举个例子，如果你看到TIME_WAIT数量特别高，同时又有大量短连接请求，这通常是客户端主动关闭连接且服务端处理频繁的典型表现，不一定代表故障，但你需要了解它可能占用端口和内存资源。

关于TIME_WAIT多说一句，它是一个正常状态，目的是确保数据包迟到的部分不会干扰新连接。只要数量不过分夸张，就不用过于紧张。真正的异常连接状态，更多看SYN_SENT堆积、ESTABLISHED异常暴涨等，后面排障章节会讲。

3.4 DNS解析：dig 与 nslookup

DNS问题往往表现诡异——浏览器打不开网页，但ping IP是通的。排查DNS，我推荐用dig，因为它直接、输出清晰、可控字段多。

# 使用默认DNS服务器查询 dig example.com # 指定DNS服务器查询 dig @8.8.8.8 example.com # 只看结果摘要 dig +short example.com

如果解析结果和你预期不一致，接下来要确认系统实际用的哪个DNS服务器：

cat /etc/resolv.conf

这里就踩过不少坑。有些云主机的/etc/resolv.conf会被云平台组件自动覆盖，你手动改了没多久又被改回来。所以排查DNS问题时不能只看文件内容，还要确认是否有系统服务在托管这个文件。

另外，很多人忽视/etc/hosts的优先级问题。由于/etc/nsswitch.conf中hosts行的配置顺序是先文件后DNS，所以当你在hosts里写了一个条目，它就会“屏蔽”DNS里同名域名的正常解析。这是调试中经常遇到的“玄学”根源。

3.5 连通性与路径探测：ping、traceroute

ping是最常用的连通性测试工具，它基于ICMP协议。先看几个实用参数：

# 指定次数和间隔 ping -c 5 -i 0.2 192.168.1.1 # 不反向解析域名 ping -n 192.168.1.1

如果ping不通，也不代表服务一定不可用。有些服务器在防火墙层面屏蔽了ICMP，但TCP端口实际是正常的。所以判断可靠性，我一般习惯用tcping方式测TCP端口连通性，或者直接用下面的方法：

# 用bash /dev/tcp测端口连通性 timeout 3 bash -c 'echo > /dev/tcp/192.168.1.10/22' && echo "port open"

路径探测用traceroute，它显示数据包到目标主机经过了哪些跳点。注意它默认用UDP探测，有些节点出于安全策略不响应UDP，导致中间跳点显示*，这并不代表链路断了。可以加-T改用TCP，或者-I改用ICMP，再对比一次。

traceroute -T -p 443 example.com

还有一种情况，内网环境禁用了ICMP，但允许特定TCP端口，用traceroute -T就合理很多。工具没有绝对好坏，关键看场景适配。

3.6 抓包利器：tcpdump

抓包是网络排障的终极手段。当所有表面信息都正常，但问题就是复现时，抓包往往能帮你看到客户端和服务端之间到底“谈了些什么”。最常用的抓包姿势：

# 监听指定网卡上、指定端口的数据包 tcpdump -i eth0 -nn port 8080 # 抓取后保存到文件，再用wireshark分析 tcpdump -i eth0 -w /tmp/capture.pcap port 8080 # 抓取并显示数据包内容 tcpdump -i eth0 -A -nn port 8080

抓包的时候还是要强调几个细节：-nn表示不解析域名和端口为服务名，能显著提升性能并减少误判概率。线上服务器生产环境如果并发较高，尽量用-w保存pcap文件，别直接打印到屏幕，否则高流量下终端输出本身会成为瓶颈。抓包贵在“看完第一眼信息”，比如SYN包是否发出去、SYN-ACK是否回来、还是RST立刻出现，基本就能定位故障大方向。

提示：抓包是最后使用的综合手段。正常排查路径应先看路由、连通性、端口监听，这些筛选不掉问题，再上tcpdump。一上来就抓包，效率和针对性都很差。

4. Linux网络配置实操：从临时修改到持久化

4.1 临时更改IP地址与路由

有些调试场景需要临时给网卡加一个IP，验证某个功能。这种修改重启网络服务或网卡后就会消失，但它胜在即时生效，不污染配置文件。

# 添加临时IP ip addr add 192.168.100.10/24 dev eth0 # 删除临时IP ip addr del 192.168.100.10/24 dev eth0 # 添加临时路由 ip route add 10.10.0.0/16 via 192.168.100.1 dev eth0 # 删除临时路由 ip route del 10.10.0.0/16

这里要注意子网掩码的写法。/24换算成传统掩码就是255.255.255.0，/16对应255.255.0.0。这种CIDR写法不仅在ip命令里常用，在很多网络配置中也是主流，建议养成使用CIDR的习惯。

我自己的调试习惯是，凡是临时操作，命令前都标注当前便于回滚的操作，并且先在测试环境验证，因为生产环境上一旦误操作，影响范围不可控。比如给一个正在提供服务的网卡加错IP，可能导致路由冲突、网关漂移，业务瞬间中断。

4.2 在主流发行版中做持久化配置

不同发行版的网络配置方式差异挺大，这也是初学者最容易混乱的地方。我把主流的CentOS/RHEL系和Ubuntu/Debian系分开讲。

CentOS / RHEL 系（NetworkManager与network脚本）

在CentOS 7及之前，配置文件放在/etc/sysconfig/network-scripts/下，一个网卡对应一个ifcfg-eth0文件。CentOS 8/9后，NetworkManager成为默认，但很多习惯直接改配置文件，然后通过nmcli重新加载。这两种方式都可以，但要注意别同时手动改文件又用NetworkManager图形工具，容易互相覆盖。

一个典型的静态IP配置示例：

# /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet BOOTPROTO=static NAME=eth0 DEVICE=eth0 ONBOOT=yes IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=8.8.8.8 DNS2=114.114.114.114

改完配置后，你可以用下面的方式让配置生效：

# 重新加载NetworkManager nmcli connection reload nmcli connection up eth0

对于不熟悉NetworkManager命令的朋友，最稳妥的办法其实是重启网络服务，但在远程操作的服务器上要格外小心，一旦网卡配置有误，连接直接就断了。所以我更推荐先改配置，再用nmcli方式重载，至少别断得快到连不上。

Ubuntu / Debian 系（netplan与/etc/network/interfaces）

Ubuntu 18.04之后默认使用netplan，配置文件是YAML格式，放在/etc/netplan/目录下。一个重启后不会丢掉的静态IP配置长这样：

# /etc/netplan/01-netcfg.yaml network: version: 2 ethernets: eth0: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 8.8.8.8 - 114.114.114.114

这里重点注意格式缩进。YAML对缩进极其敏感，少一个空格或多了Tab，netplan apply会报语法错误。很多新手第一次配netplan，九成错误都是格式问题。

# 应用配置 netplan apply # 测试配置（自动回滚） netplan try

netplan try是个非常好用的安全网，它会在指定时间内确认配置是否生效，超时或收到中断会自动回滚。生产环境上远程改配置时，务必用try而不是apply。

在更老的Debian/Ubuntu系统上，你还会遇到/etc/network/interfaces这种风格，配置基本是：

auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8

现在新装系统都很少遇到了，但维护老设备翻车概率不小，所以我还是要提一嘴，至少看到这类配置不陌生。

补充一个通用原则：不管哪种系统，改网络配置前先备份原文件。这是一条成本极低、收益极高的习惯。命令行下cp一个备份文件只要一秒，网络断了回不去的时候，它就是救命稻草。

4.3 网卡bond配置与VLAN子接口

现在生产环境里，网卡bond（绑定）是非常常见的高可用诉求。把两块物理网卡绑成一块逻辑网卡，提供冗余或带宽聚合。配置bond前先确认网卡驱动支持，然后再看用的bond模式。

常用的bond模式有：

• mode 1（active-backup）：主备模式，只有一块网卡在工作，另一块备用，出现故障时切换，主要用于冗余。
• mode 4（802.3ad，LACP）：链路聚合，需要交换机侧配合配置动态链路聚合，能同时使用多块网卡的带宽。

一个比较典型的Netplan配置bond示例：

network: version: 2 renderer: networkd ethernets: eth0: dhcp4: false eth1: dhcp4: false bonds: bond0: interfaces: [eth0, eth1] addresses: [192.168.10.10/24] parameters: mode: active-backup mii-monitor-interval: 100

如果你的是多VLAN环境，比如同一个物理端口上要同时传办公网和业务网，VLAN子接口也是常用手段。在Linux中创建一个VLAN子接口的命令很直接：

# 基于eth0创建VLAN 100子接口 ip link add link eth0 name eth0.100 type vlan id 100 ip addr add 192.168.100.10/24 dev eth0.100 ip link set eth0.100 up

不考虑上层业务需求时，没有特殊要求别给服务器加太多VLAN，每个子接口都会占用协议栈处理资源，排障复杂度也会上升。vconfig、bridge-utils这些老工具在自动化和云环境里逐渐被替代，但它们管理传统网络设备互通时的价值依然存在。

4.4 配置永久路由的方法

有些多网卡服务器需要配多种路由，比如“去往某个内部网段走特定出口”。临时没问题，关键要持久化。

在CentOS系中，可以在/etc/sysconfig/network-scripts/route-eth0文件里写：

10.20.0.0/16 via 192.168.1.1 dev eth0

在netplan里，可以把静态路由写在对应网卡的routes下，已展示过default路由的方式。多网卡场景还可以用routing-policy（策略路由）来配合源地址选路。

策略路由在复杂多线服务器上特别好用。比如两个公网网卡，分别连接到不同运营商，你想让访问某个目的网段时走特定网卡出外网，就需要policy routing。基本做法是用ip rule加规则，配合ip route建独立路由表，但这已经属于进阶内容，这篇先知道有这个概念，后续系列再展开。

多网卡选择问题时要注意：Linux默认情况下只使用一条默认路由，但多条直连路由可以用策略路由公平分配到不同网卡，避免出现一条通一条不通的现象。

5. 网络故障排查思路与典型问题实录

5.1 排查方法轮：从底层到应用一层层来

网络排查最忌讳一上来就猜。你猜可能是DNS问题，改了DNS还是不通，又猜是防火墙，关了防火墙还不行，最后发现是网卡没写默认路由。这样浪费大量时间。我习惯按“物理链路 → 网卡地址 → 路由 → DNS → 端口服务 → 防火墙策略 → 抓包”的固定顺序排查。

简单说，链路层不通，上面一切免谈。先看网卡有没有LOWER_UP；没链路，查网线/交换机/光模块。链路通了，看IP地址配置对不对。IP对了，看路由是否正确。路由正确了，再看DNS能否解析目标域名。域名能解析，再看端口监听和进程状态。端口没问题，再检查防火墙是否拦截。全都没问题但业务还是不通，这时候才上tcpdump看细节。

我把这个排查顺序整理成了一张速查表：

5.2 高延迟与丢包排查实录

线上应用突然变卡，但服务器负载很低，第一反应看网络延迟和丢包率。

# 连续ping 100个包，看丢包和RTT抖动 ping -c 100 -i 0.2 192.168.1.1

丢包率超过0.1%就要警觉了。之前遇到过一个情况：某应用内网互访延迟正常，但外网访问经常超时。带着疑问先ping网关，丢包率很高，初步怀疑网卡或者链路质量问题。查看网卡的错误统计，ip -s link show eth0能看到网卡收发包统计。进一步发现RX errors数值持续增长，顺着查下去，发现交换机端口模式配置错误，协商成了半双工，导致严重冲突丢包。

恢复后一切正常。由此总结，当你发现网络质量异常时，除了看连通性，收集丢包、错误计数指标同样关键，否则很容易误判成应用层问题。

5.3 端口不通，但Ping得通

这种情况是最常见的“服务好像活着但其实连不上”场景。你ping通了一台服务器，但telnet ip 端口不通，或者curl一直超时。

首先要确认服务进程是不是真的在监听外部接口。有时候服务配置监听在了127.0.0.1，外部自然访问不到，但本机curl能通，给人造成“服务正常”的错觉。查监听地址：

ss -tlnp | grep 8080

其次看本机防火墙：

iptables -L -n

再者如果是云服务器，还要看安全组是否放行了源IP和端口。云环境下的安全组拦截甚至比本地防火墙更隐蔽，因为它完全不影响本机访问，但外网就进不来。

如果本机和服务端看起来都正常，就用抓包在同一时间两端都抓。之前遇到过这样一例：客户端发出SYN，服务端看到了，但服务端回的SYN-ACK客户端收不到，初步怀疑中间网络设备丢包或NAT问题。一链路排查，最后发现是网络设备的会话表老化机制过于激进，把长连接给掐了。这类问题只有抓包对比才能定位。

5.4 TIME_WAIT与连接数异常

高并发服务经常出现TIME_WAIT堆积，前面提过它本身不是祸。如果连接数异常增长，先看：

ss -s ss -tan state time-wait

如果TIME_WAIT数量达到几万个，同时系统端口资源被耗尽，那确实需要处理。常见处理方式有调整内核参数，比如：

sysctl -w net.ipv4.tcp_tw_reuse=1

再说一点，tcp_tw_reuse和tcp_tw_recycle不要混为一谈。tcp_tw_recycle在NAT环境下容易出兼容性问题，极易导致部分用户连接不上，网络上有大量事故记录，我本人不建议开启。现代内核版本对time wait的处理也发生了变化，新内核中很多旧调优手段意义不大，调整前先确认内核版本。

5.5 DNS缓存的坑

DNS排查时还要留意本地缓存问题。你改了/etc/resolv.conf指向新DNS服务器，但因为本地有systemd-resolved或dnsmasq缓存，老的解析结果还会继续被返回。

# 查看缓存统计 systemd-resolve --statistics # 清缓存 resolvectl flush-caches

这个问题在一些长期运行的服务器上特别隐蔽。有一次子域解析记录已经更新了半小时，但业务还在请求旧IP，排查到最后发现是本地dnsmasq缓存TTL设置太长导致的。所以改完DNS后要主动验证，系统解析器的缓存机制绕不开。

6. 进阶理解：从数据处理视角重新看网络性能

6.1 缓冲区与队列机制

所有数据收发都存在缓冲区。发送有发送队列，接收有接收队列，队列里有数据会触发中断和软中断告知内核处理。如果队列满了，新来的数据包就会被丢掉，这就是网卡层面丢包的一个重要来源。

# 查看网卡的缓冲区和丢包统计 ethtool -S eth0 | grep -i drop

处理大量数据包时，如果系统CPU资源不足，软中断处理不过来，接收队列就会溢出，大量数据被丢弃。高频场景下你会看到接受方向丢包数字快速上涨。这时期最简单的手段是加大网卡队列长度，或者用CPU绑核方式把软中断分散到多核处理。

还有一个常见参数是net.core.netdev_max_backlog，它定义了设备接收队列最大长度。当单位时间数据包数量突发超过处理能力时，这个参数可能成为瓶颈。

sysctl -w net.core.netdev_max_backlog=4096

6.2 MTU：链路层一次能装多少货

MTU是网卡在链路层一次最多能传的字节数，以太网默认是1500。如果你发现某些网站能打开、某些打开不了，或者传输大文件时卡顿，可能是MTU不一致导致的。

典型症状：ping小包通，ping大包不通。用指定包大小测试可以复现：

# 指定包大小为1500字节，且禁止分片 ping -M do -s 1472 192.168.1.1

1472的来源要理解：ICMP负载加ICMP头8字节，加IP头20字节，正好等于1500。如果这个包不通，说明链路中某个设备限制了MTU更小，数据报无法顺利通过。常见的解决手段是调小接口MTU或开启PMTU发现，云环境内如果传输NFS/大文件类应用，经常遇到需要降低MTU到1400以下来适配虚拟化网络的情况。

6.3 TCP握手状态与常见异常

TCP三次握手是网络基础中的基础。排查连接状态时，最常看到的异常状态分布：

• 大量SYN_RECV堆积：收到SYN没成功回ACK，可能是半连接队列满。
• 大量SYN_SENT堆积：客户端发出SYN但一直没收到应答，可能是目标不可达或中间丢包。
• 大量RST：连接被强制重置，常见于端口未监听或被防火墙规则主动拒绝。

手动模拟排查一下：用curl -v访问一个不存在的端口，你会看到connect返回connection refused，抓包看到的正是RST。这是最直观的“端口不存在”验证方式。

半连接队列满的典型调优参数是net.ipv4.tcp_max_syn_backlog和net.core.somaxconn，但这两个参数仅在服务确实存在瞬时大量并发SYN时才有调整意义，盲目调大并不能掩盖应用性能不足的真相，反而可能加剧资源消耗，所以先做流量分析再动参数。

7. 常见问题速查与经验杂谈

把平时踩过的坑整理成一张表，方便直接查：

几个实操经验，可以重点关注：

第一，生产环境远程操作网络配置，一定要考虑“断了之后怎么回来”。你有带外管理（如远程管理卡、控制台）才能大胆改，没有的话就谨慎一点。如果只有SSH一个通道，我习惯先写一个定时恢复脚本，比如5分钟后自动恢复原配置，把改操作风险兜底。

第二，云服务器上修改网络配置前先看云平台是否提供“允许不保留MAC地址/自定义网卡”的能力。有些云环境的网络虚拟化对相同MAC、不同网卡的处理很敏感，乱改有可能直接把实例网络搞挂。

第三，养老系统上尽量别一次性升级全套网络工具包。有些旧系统依赖net-tools内部的输出格式，换掉后脚本解析直接崩，引出一堆无关故障。

8. 从抓包到理解的个人体会

最后分享一点个人感触，这也是我在实际抓包排障中反复验证出来的经验：网络排障真正难的不是命令不会敲，而是脑子里没有“包是怎么走”的完整画面。tcpdump输出那么多行，每一行对应的是哪个环节，都要能对上号。

比如你看到：

14:23:01.123456 IP 192.168.1.100.54321 > 192.168.1.10.8080: Flags [S] 14:23:01.123489 IP 192.168.1.10.8080 > 192.168.1.100.54321: Flags [S.] 14:23:01.123567 IP 192.168.1.100.54321 > 192.168.1.10.8080: Flags [.]

这种一来一回的SYN、SYN-ACK、ACK基本完成了三次握手。如果你只看到SYN一直在发，但没看到SYN-ACK，说明包可能死在半路或者目标根本没处理。如果看到目标发回了RST，则说明端口没监听或者被安全策略拒绝。

要练出这种画面感，没有捷径，平时多看多抓多分析。建议在搭建的实验环境里，自己写一个小HTTP服务，然后用tcpdump抓一次完整访问，把数据包一行一行理解透。坚持几次之后，你对Linux网络栈的理解会有一个质的提升，很多“玄学网络问题”在你眼里会变成有章可循的常规问题。