一个做运维的老朋友前两天找我说家里网络突然卡成幻灯片他折腾了半天路由器重启了、网线也换了甚至连光猫都恢复出厂了问题还在。我让他打开命令行敲了两条命令三分钟定位到是某台设备占了IP把那个设备的网络断开就好了。他感慨说自己搞了这么多年IT理论知识都在脑子里真到排障的时候反倒手忙脚乱。这其实就是典型的“概念都会实战就废”。很多人对网络基础的认知停留在“知道有TCP/IP”“听过三次握手”可真要处理断网、慢、丢包、IP冲突这类日常问题根本不知道从哪里下手。这篇“网络基础详细版”要做的就是把那些零散的概念串成一条线从分层模型、IP寻址、DNS解析到TCP机制一路讲到抓包排障让你学完不是“懂概念”而是“能干活”。内容面向刚入行的运维、开发也适合需要自己处理家庭和办公网络问题的普通用户我会把所有原理都用实际场景讲透配合可以直接照抄的命令和排查思路。1. 网络基础到底在学什么先说清楚主线1.1 我给“详细版”划的五条主线我在给团队做内训的时候一向不主张按教科书的目录一章一章啃。网络基础这个领域知识点多而杂如果脑子里没有主线学一个忘一个。我会把整个网络基础拆成五条主线第一是分层模型也就是网络是怎么组织起来的。第二是寻址包括IP地址、子网掩码、MAC地址这些东西解决的是“数据往哪送”的问题。第三是域名解析解决的是“名字怎么变成地址”的问题。第四是传输控制也就是TCP和UDP解决的是“数据怎么可靠地送”的问题。第五是生命周期与排障从设备上电、获取地址、发起连接到数据交互、连接关闭整个链条上的每个环节都可能出问题排障就是顺着这条链子去检查。这个顺序是有讲究的。先看全局结构再解决定位问题再看命名问题再看传输可靠性最后把前四部分串成完整的排障思路。好比学开车先知道方向盘、油门、刹车在哪再学怎么起步、换挡最后上路处理各种路况。顺序反了或者只学其中一段都会卡在半路。1.2 一条数据从浏览器到服务器的完整旅程为了让你对后面要讲的内容有个整体画面我先走一遍最经典的场景你在浏览器地址栏输入一个网址按下回车到页面显示出来中间发生了什么。第一步浏览器要查这个域名对应的IP地址这个动作叫DNS解析。查不到就去递归DNS服务器问查到以后才进入下一步。第二步浏览器发起TCP连接这就是传说中的三次握手。建立连接后浏览器把HTTP请求封装成数据包交给操作系统网络协议栈。第三步数据包在网络层被加上源IP和目标IP然后到数据链路层被加上源MAC和目标MAC变成一帧一帧的数据通过网卡发出去。第四步数据在局域网里经过交换机在网络之间经过路由器逐跳转发最终到达服务器所在的机房。第五步服务器收到请求处理完把响应内容按同样路径返回。浏览器拿到HTML、CSS、JS渲染出页面。这个过程里任何一个环节出了差错表现都是“打不开网页”但原因可能完全不同。DNS挂了会解析失败TCP被防火墙拦截会一直连接超时IP配错了数据根本出不了网卡路由不对数据会绕远甚至丢包。所以网络基础的核心不是记住某个协议的名字而是建立一条完整的数据流转链路知道你的数据每一跳都在干什么。2. 网络为什么分层从OSI到TCP/IP的取舍2.1 分层不是为了考试是为了承包责任制很多初学者一看到OSI七层模型就头疼七个层次、每个层又有自己的协议和格式背了又忘。我要换个说法帮你理解分层就是“承包责任制”。每一层只干自己那一摊活上层不用管下层怎么实现下层也不用管上层的数据内容是什么。网络工程师只需要跟自己负责的那一层打交道出了问题也能快速定位责任范围。举个例子。你用快递寄东西整个过程可以分成几个环节你负责打包写地址快递员负责取件和派送物流车辆负责转运机场或中转站负责分拣。你不需要知道快递员开什么车、走了哪条路你只需要保证包裹上的地址写对了。网络分层也是这个逻辑应用层关心的是“我要传输什么内容”传输层关心的是“怎么保证内容完整到达”网络层关心的是“下一跳往哪走”链路层关心的是“怎么在同一个网段里把帧送到邻居手里”。TCP/IP模型把OSI的七层压缩成了四层应用层、传输层、网络层、网络接口层。实际工作中你打交道最多的就是这四层。去看一个数据包Wireshark里每一行协议标签本质上就是某一层给自己添加的“快递单”。2.2 数据链路层和ARP最容易忽视的暗坑TCP/IP模型里最底层是网络接口层但日常排障中这一层的坑最多也最容易被忽视。这一层干的事包括把上层传来的IP数据报封装成帧通过网卡发到物理介质上同时处理同一网段内设备之间的通信。这里必须提到一个关键协议ARP地址解析协议。玩过网络的人都知道设备之间通信靠IP但数据真正发出去之前网卡只认MAC地址。IP是逻辑地址用来在网络上定位MAC是物理地址像身份证一样烧在网卡里用来在同一个局域网里找到具体设备。当你往同一网段的另一台设备发数据时系统先查ARP缓存表看看目标IP对应的MAC地址有没有记过。没有的话就发一个ARP广播问整个局域网谁是192.168.1.100请把你的MAC告诉我。目标设备收到后回复自己的MAC发送方把它写进ARP缓存然后才能封装以太网帧发出去。这一段听着简单实际维护和故障排查里暗坑很多。最常见的坑是ARP缓存过期或错误。设备换了网卡、IP被别的机器占用、或者有人手动改了IP都可能让ARP缓存里的映射失效导致数据包发到了错误的设备上。排这种问题的时候敲一条arp -d清理缓存或者arp -a看看缓存内容往往是第一条命令。另一个坑是ARP洪泛和ARP欺骗。在规模比较大的局域网里如果大量ARP广播同时出现交换机的CPU会被打满整个网段都会变慢。严格一点的网络会启用动态ARP检测或者端口安全防止有人伪造ARP应答。做运维的人脑子里必须有“ARP也会出问题”这根弦。2.3 用Wireshark把分层“看”出来我在培训时最常推荐的一招是用Wireshark抓包把分层模型从抽象的图变成看得见的协议树。随便抓一个DNS查询或者HTTP请求展开包头层次极其清楚最外层是以太网帧头里面有源MAC、目标MAC这是第二层的信息。往上一层是IP头里面有源IP、目标IP、TTL、协议号这是第三层的信息。再往上是TCP或者UDP头里面有源端口、目标端口、序号、确认号这是第四层的信息。最上层才是应用层的数据内容。这种一层包一层的结构就是网络分层的实物证据。以后每学一个协议都去抓包看一眼比背十遍格式定义都有用。而且对排障来说抓包能看到一个数据包从发出到返回的完整过程能定位到问题到底出在哪一层。提示抓包最好在测试环境练别直接在核心业务服务器上长时间抓。流量大的时候抓包文件会膨胀得很快几十秒钟就能攒出几个GB容易把磁盘填满。3. 理解IP与寻址子网划分和公网私网3.1 IPv4地址分类与CIDR的本质IP地址是网络层的核心你要想真正理解网络IP这一关必须过。IPv4地址是32位二进制数为了人眼方便通常写成点分十进制的形式比如192.168.1.100。最早设计者把IP地址分成了A、B、C三类按前几位区分网络规模。A类地址第一位是0网络号8位适合超大规模网络B类地址前两位是10网络号16位适合中等规模C类地址前三位是110网络号24位适合小网络。这种分类法在早期还能用后来发现太死板要么地址不够分要么浪费严重。于是出现了CIDR无类别域间路由。它的核心思想是不再按A/B/C类死板划分而是用“IP地址/前缀长度”来表示网络范围。192.168.1.0/24的意思就是前24位是网络号后8位是主机号这个网段里可用的地址范围是192.168.1.1到192.168.1.254其中192.168.1.0是网络地址192.168.1.255是广播地址。CIDR的好处是灵活。你家里可能只需要几十个地址用/24有点浪费那就用/2732个地址就够了。骨干网路由汇总也用CIDR可以把一堆小网段合并成一个大前缀让路由器上的路由表瘦身。3.2 子网掩码、网关与路由数据往哪儿走与CIDR紧密相关的一个概念是子网掩码。子网掩码的作用就是告诉设备“哪些位是网络号哪些位是主机号”。/24对应的子网掩码是255.255.255.0/16对应255.255.0.0/27对应255.255.255.224。设备拿到一个IP之后会做一件非常重要的事用自己的IP和子网掩码做与运算得出自己的网络号。发数据的时候再把目标IP和自己的子网掩码做与运算看目标设备和自己是不是同一个网段。如果是直接走ARP找到目标MAC地址如果不是就把数据交给默认网关处理。默认网关是什么它就是本网段通往外部世界的“关口”通常是一台路由器的LAN口地址。家里最常见的配置是192.168.1.1路由器收到你的数据后查看自己的路由表决定下一跳往哪走。路由表里匹配规则用最长的前缀优先也就是说掩码越长、范围越精确优先级越高。现实中我接过很多“网通但网页不开”的工单查到最后都是网关配错了或者路由器的路由表被人改乱了。所以排查网络第一问永远是网关能通吗ping一下默认网关通则说明局域网内没问题问题在出口不通问题就在本段链路。3.3 局域网排障必备IP冲突和NAT说一个几乎每位运维都遇到过的经典场景某台设备突然掉线重启后能连上路由器但上不了网一查系统日志提示IP地址冲突。所谓IP冲突就是同一个网段中有两台设备用了相同的IP。发生冲突时设备会收到一个免费的ARP通告告诉你这个地址已经被别人用了。后果就是似乎网络不稳定时好时坏因为交换机不知道把数据帧究竟转给谁。排查这种问题最笨但有效的方法是一台一台断开网线或者断Wi-Fi确定嫌疑人高效一点的做法是查路由器或交换机的DHCP租约表看哪个IP被分配了多次再通过接入层交换机查端口对应的设备。网络稍微大点的规划好DHCP静态保留和VLAN隔离是降低冲突概率的最好办法。这里还要连带提一下NAT网络地址转换。家用宽带出口只有一个公网IP但全家可能有十几台设备全靠NAT把私网IP映射成公网IP干活。NAT的出现缓解了公网IPv4地址枯竭的问题但也给P2P通信、游戏的联机带来了各种麻烦。你在路由器上配置端口映射就是手动建立一条NAT规则把公网的一个端口映射到内网某台机器的某一端口让外部流量能找到内部的服务。4. 域名解析与TCP核心机制4.1 DNS解析全流程与TTL网络基础里没有哪个环节像DNS一样明明人人都在用却总是被忽略。你访问一个网站输入的是域名但TCP/IP通信必须用IP地址把域名翻译成IP的这套机制就是DNS。简单说一下解析的全流程。你的电脑首先查本地DNS缓存不知道就去查hosts文件再不知道就把请求发给本地配置的DNS服务器。这个DNS服务器如果是递归解析模式你不需要知道它内部如何一步步问询它会帮你查完整个链条然后把最终结果返回给你。互联网上的实际解析过程是分层的根服务器管顶级域顶级域服务器管二级域权威服务器管具体的记录。你查某个域名的时候递归服务器会从根服务器一路问到权威服务器拿到答案后缓存起来等下一次查询直接用缓存返回。这里必须说一个和实际排障非常相关的东西TTL缓存生存时间。每条DNS记录都有一个TTL值单位是秒意思是这条记录可以在缓存里活多久。TTL设得太短查询压力大设得太长IP更换后客户端可能迟迟刷新不到新地址。我自己改服务器IP的时候通常提前1-3天把TTL调低让解析变更尽快生效等稳定后再调回来。家庭和办公场景最常见的DNS故障有几种表现能上微信但打不开网页、网页反复提示找不到服务器、间歇性网页打开慢。遇到这类问题先把DNS临时换成公共DNS服务试一下如果能恢复说明运营商默认DNS可能出了状况。再用nslookup或者dig工具直接查域名解析是否正常看返回的IP和TTL值是否符合预期。注意修改DNS之前先记录原来的配置排查结束后恢复。很多临时改完DNS忘了改回去之后出了问题又是一头雾水。4.2 TCP建立连接三次握手背后的状态管理TCP是一个面向连接的可靠传输协议。所谓面向连接就是通信双方在传数据之前要先通过一个握手过程建立连接。这个过程就是闻名遐迩的三次握手。我用寄包裹来类比。你给远方的朋友寄东西第一件事不是直接发货而是先打个电话确认对方在不在、能不能收货。打电话这个动作在TCP里就是客户端发送SYN报文里面带一个初始序号。服务器收到后如果能接受连接就回复一个SYNACK报文表示我听到了我也准备好了同时带上自己的初始序号。最后客户端再回复一个ACK表示确认收到服务器准备好了。此后双方进入ESTABLISHED状态开始正式传数据。三次握手看起来挺好理解但实际中藏着很多细节坑。一个常见问题是SYN洪水攻击攻击者发送大量伪造源IP的SYN报文服务器回复SYNACK后等待对方确认永远等不到半连接队列被占满正常用户连接不进来。这也是为什么生产环境的服务器要调TCP半连接队列大小、开启SYN Cookie防护。另一个现实问题是防火墙对TCP连接的拦截。很多企业防火墙默认只放行“从内到外”的会话。外部主动连内网的端口如果没有例外规则直接拒绝。你排查连不上服务器的时候不光要看服务器本身端口有没有监听还要看中间链路上防火墙是否放行。我自己的一个排障习惯是先telnet或者nc测一下目标端口通不通再用tcpdump或者Wireshark看有没有收包回包。这能帮你快速区分问题在中间链路还是在对端服务。4.3 四次挥手与TIME_WAIT关闭比建立更讲究如果说握手是建立连接的仪式那挥手就是关闭连接的仪式它由四次报文交换完成。主动关闭方发送FIN对方回复ACK接着对方发送自己的FIN主动方再回复ACK连接才算彻底关闭。为什么要四次因为TCP允许半关闭也就是说一端停止发送数据但还可以继续接收数据。被动关闭方要先回复ACK表示知道你要关了等自己把数据发完了再发FIN告诉对方我也要关了。所以多了一次报文交互。与挥手相关的一个状态叫TIME_WAIT这是主动关闭方在发出最后一个ACK之后进入的状态要保持一段时间。很多刚入行的同学会疑惑连接都关了为什么端口还占着这个状态的设计是为了防止最后一个ACK丢失保证网络中残留的迟到数据包不会干扰新连接。TIME_WAIT如果大量堆积会出现端口不够用的问题尤其是在高并发的短连接场景下。默认TIME_WAIT等待时间是2MSLMSL是最长报文段寿命加起来大概60秒。如果每秒创建的连接数非常多客户端或服务端的端口池可能被占满。调整net.ipv4.tcp_tw_reuse等内核参数可以缓解但前提是要清楚原理盲目开启可能带来数据错乱的风险。另外服务端大量出现TIME_WAIT一般不需要过分紧张更多的是排查CLOSE_WAIT状态。CLOSE_WAIT表示对方已经关了连接但本地程序迟迟没有调用close来关闭套接字这通常是程序代码没处理好连接释放属于应用层问题。4.4 滑动窗口与可靠传输TCP的可靠传输靠的是序号、确认号和重传机制。发送方给每个字节编上序号接收方收到数据后返回确认号表示“这个序号之前的我都收到了”。发送方如果在超时时间内没收到确认就重传数据。但TCP不能发一个等一个那样效率太低。于是有了滑动窗口机制。窗口大小决定了发送方在没有收到确认的情况下最多还能发多少数据。窗口越大网络吞吐率越高但也要考虑接收方的处理能力和网络拥塞情况。实际排障中网络慢最典型的指标就是TCP重传。用Wireshark抓包后菜单里的统计功能可以直接看到重传包的数量。如果重传占比高通常意味着网络存在丢包或者线路质量差。另一种情况是窗口太小表现是吞吐率上不去抓包会看到接收窗口反复收缩到很小的值相当于接收方的缓冲区快满了处理不过来。关于“网络慢”这个症状我见过的原因五花八门有Wi-Fi信号弱导致速率暴跌的有网线是劣质线跑不满千兆的有出口带宽被某台设备占满的有服务器网卡跑满中断的。所以别一上来就怪带宽先用数据说话把丢包率、重传率、窗口大小、链路速率逐项排查基本都能找到真正的瓶颈。5. 基础排障实战从现象到定位5.1 一张排查命令速查表网络基础要落到实操命令是基本功。我把平时最常用的一套排查命令整理成了表格每一条都写了典型用途和判断方法。你把这些命令练熟大部分常见网络问题都能快速定位到具体环节。命令用途关键判断点ipconfig / ifconfig查看本机IP配置确认IP、子网掩码、网关、DNS是否正常ping 127.0.0.1验证本机协议栈通说明网卡驱动和协议栈基本正常ping 网关验证局域网链路通说明本段链路和交换机正常。不通查网线、Wi-Fi、交换机端口ping 域名验证DNS与出口链路通说明出口和解析正常不通再ping对端IP区分是DNS还是链路tracert / traceroute查看路由路径看哪些跳超时、延迟高定位瓶颈段nslookup / dig查域名解析看返回的IP、TTL、解析耗时是否异常netstat / ss查看本机端口和连接状态确认端口监听、连接状态分布、TIME_WAIT数量arp -a查看ARP缓存确认局域网内IP与MAC映射是否正常这套命令的先后顺序是有逻辑的本质上是从本机出发一层一层向外探测逐步缩小问题范围。5.2 一个真实的“网页打不开”排障实录为了让你把前面的知识串起来我完整跑一遍经典的排障过程场景是办公网某台电脑打开网页很慢有时候直接超时。第一步ipconfig看IP配置。发现这台机器的IP是自动获取网关正常DNS是两个内网地址。于是先ping网关通说明局域网内链路没问题。再ping一个公网IP比如直接ping某个知名网站的IP发现也通说明出口链路没有断。第二步问题可能是DNS。用nslookup查刚才打不开的域名结果发现解析超时。这说明本地配置的DNS服务器响应有问题。临时把DNS改成公共DNS测试网页立刻能开了。到这里基本定位到是DNS服务器的问题跟ISP和运营商默认DNS有关。我直接把这个问题报给网络管理员让他们去查内网DNS服务状态。第三步如果想要更细的现场用Wireshark抓包再看一眼DNS请求的响应耗时能直观看到丢了几次重试才拿到结果。这种证据比口头描述“网页打不开”要有力得多。这个案例想说明一个道理排障不是碰运气而是一条链路一条链路地排除。每一步都问自己一个问题这个环节通不通通了就往下走不通就在这一层停留。5.3 抓包定位网络慢从TCP握手到应用层再分享一个偏进阶的场景两台服务器之间传数据速度一直上不去直观感觉是“网络不好”。但你ping发现延迟很低丢包为零那问题在哪这时抓包是最好的手段。抓包看TCP握手阶段如果三次握手都慢基本是链路问题或中间设备处理慢如果握手很快传数据阶段出现大量重传基本可以确定存在丢包如果重传不多但吞吐率低看接收窗口是否被收缩得非常小这是接收方处理能力的信号如果TCP层面都很正常但业务仍然慢那问题就可能出现在应用层的协议交互上比如HTTP请求排队、数据库查询慢。我自己抓包的习惯是先过滤出TCP流的首包和返回包右键“追踪TCP流”能直接看到应用层的完整请求和响应。再配合时序图和统计功能看重传率、RTT变化就能把一条链路里各个节点的表现量化出来排障的时候有理有据不做“看看是不是换根网线试试”这种碰运气的事。6. 常见问题速查与避坑清单日常网络排障有些问题是高频中的高频我直接整理成速查表方便你平时遇到问题随手查阅。症状最大嫌疑快速验证方式解决方向完全没网物理链路或IP获取失败看网卡状态、ipconfig是否拿到地址换网线、检查交换机端口、手动配IP试一下能上微信网页打不开DNS解析异常nslookup查域名换公共DNS、检查DNS服务器状态网速忽快忽慢无线信号干扰或链路拥塞ping网关看延迟抖动换频段、查上行带宽占用特定设备频繁掉线IP冲突或DHCP租约问题看系统日志和DHCP租约表设置静态保留、排查冲突设备外网能通内网服务连不上防火墙或服务未监听ss命令看端口监听状态检查防火墙规则、确认服务进程下载速度远低于带宽TCP窗口或线路质量抓包看重传率和接收窗口优化MTU、排查线路质量再补充几条我长期总结出来的避坑经验。第一条不要盲目重启设备和改配置。先记录现状再动手改一项验证一项避免问题没找到反而改出新问题。第二条判断网络问题一定先分层。本机协议栈、局域网、网关、出口、域名解析一个环节一个环节排除不要上来就怀疑总带宽。第三条日志和抓包是排障最有力的证据别靠感觉。第四条接手别人的网络环境花点时间看拓扑、VLAN和IP规划避免在错误的前提上做正确的事情。关于网络基础的学习路径我个人建议学完这些内容之后立刻在自家网络环境里做实验。改一改路由器的DHCP地址池搭一台小服务器用Wireshark观察TCP握手和DNS查询用命令行模拟一次完整的排障过程。网络基础最奇妙的地方在于它不需要昂贵设备你手边的电脑和路由器就是最好的实验室。把这些实验都亲手跑过一遍之后你对网络的理解会彻底从“听过”变成“会用”以后再遇到各种网络问题也就有了真正能依靠的判断力。
网络基础实战指南：从TCP/IP分层到DNS与抓包排障
一个做运维的老朋友前两天找我说家里网络突然卡成幻灯片他折腾了半天路由器重启了、网线也换了甚至连光猫都恢复出厂了问题还在。我让他打开命令行敲了两条命令三分钟定位到是某台设备占了IP把那个设备的网络断开就好了。他感慨说自己搞了这么多年IT理论知识都在脑子里真到排障的时候反倒手忙脚乱。这其实就是典型的“概念都会实战就废”。很多人对网络基础的认知停留在“知道有TCP/IP”“听过三次握手”可真要处理断网、慢、丢包、IP冲突这类日常问题根本不知道从哪里下手。这篇“网络基础详细版”要做的就是把那些零散的概念串成一条线从分层模型、IP寻址、DNS解析到TCP机制一路讲到抓包排障让你学完不是“懂概念”而是“能干活”。内容面向刚入行的运维、开发也适合需要自己处理家庭和办公网络问题的普通用户我会把所有原理都用实际场景讲透配合可以直接照抄的命令和排查思路。1. 网络基础到底在学什么先说清楚主线1.1 我给“详细版”划的五条主线我在给团队做内训的时候一向不主张按教科书的目录一章一章啃。网络基础这个领域知识点多而杂如果脑子里没有主线学一个忘一个。我会把整个网络基础拆成五条主线第一是分层模型也就是网络是怎么组织起来的。第二是寻址包括IP地址、子网掩码、MAC地址这些东西解决的是“数据往哪送”的问题。第三是域名解析解决的是“名字怎么变成地址”的问题。第四是传输控制也就是TCP和UDP解决的是“数据怎么可靠地送”的问题。第五是生命周期与排障从设备上电、获取地址、发起连接到数据交互、连接关闭整个链条上的每个环节都可能出问题排障就是顺着这条链子去检查。这个顺序是有讲究的。先看全局结构再解决定位问题再看命名问题再看传输可靠性最后把前四部分串成完整的排障思路。好比学开车先知道方向盘、油门、刹车在哪再学怎么起步、换挡最后上路处理各种路况。顺序反了或者只学其中一段都会卡在半路。1.2 一条数据从浏览器到服务器的完整旅程为了让你对后面要讲的内容有个整体画面我先走一遍最经典的场景你在浏览器地址栏输入一个网址按下回车到页面显示出来中间发生了什么。第一步浏览器要查这个域名对应的IP地址这个动作叫DNS解析。查不到就去递归DNS服务器问查到以后才进入下一步。第二步浏览器发起TCP连接这就是传说中的三次握手。建立连接后浏览器把HTTP请求封装成数据包交给操作系统网络协议栈。第三步数据包在网络层被加上源IP和目标IP然后到数据链路层被加上源MAC和目标MAC变成一帧一帧的数据通过网卡发出去。第四步数据在局域网里经过交换机在网络之间经过路由器逐跳转发最终到达服务器所在的机房。第五步服务器收到请求处理完把响应内容按同样路径返回。浏览器拿到HTML、CSS、JS渲染出页面。这个过程里任何一个环节出了差错表现都是“打不开网页”但原因可能完全不同。DNS挂了会解析失败TCP被防火墙拦截会一直连接超时IP配错了数据根本出不了网卡路由不对数据会绕远甚至丢包。所以网络基础的核心不是记住某个协议的名字而是建立一条完整的数据流转链路知道你的数据每一跳都在干什么。2. 网络为什么分层从OSI到TCP/IP的取舍2.1 分层不是为了考试是为了承包责任制很多初学者一看到OSI七层模型就头疼七个层次、每个层又有自己的协议和格式背了又忘。我要换个说法帮你理解分层就是“承包责任制”。每一层只干自己那一摊活上层不用管下层怎么实现下层也不用管上层的数据内容是什么。网络工程师只需要跟自己负责的那一层打交道出了问题也能快速定位责任范围。举个例子。你用快递寄东西整个过程可以分成几个环节你负责打包写地址快递员负责取件和派送物流车辆负责转运机场或中转站负责分拣。你不需要知道快递员开什么车、走了哪条路你只需要保证包裹上的地址写对了。网络分层也是这个逻辑应用层关心的是“我要传输什么内容”传输层关心的是“怎么保证内容完整到达”网络层关心的是“下一跳往哪走”链路层关心的是“怎么在同一个网段里把帧送到邻居手里”。TCP/IP模型把OSI的七层压缩成了四层应用层、传输层、网络层、网络接口层。实际工作中你打交道最多的就是这四层。去看一个数据包Wireshark里每一行协议标签本质上就是某一层给自己添加的“快递单”。2.2 数据链路层和ARP最容易忽视的暗坑TCP/IP模型里最底层是网络接口层但日常排障中这一层的坑最多也最容易被忽视。这一层干的事包括把上层传来的IP数据报封装成帧通过网卡发到物理介质上同时处理同一网段内设备之间的通信。这里必须提到一个关键协议ARP地址解析协议。玩过网络的人都知道设备之间通信靠IP但数据真正发出去之前网卡只认MAC地址。IP是逻辑地址用来在网络上定位MAC是物理地址像身份证一样烧在网卡里用来在同一个局域网里找到具体设备。当你往同一网段的另一台设备发数据时系统先查ARP缓存表看看目标IP对应的MAC地址有没有记过。没有的话就发一个ARP广播问整个局域网谁是192.168.1.100请把你的MAC告诉我。目标设备收到后回复自己的MAC发送方把它写进ARP缓存然后才能封装以太网帧发出去。这一段听着简单实际维护和故障排查里暗坑很多。最常见的坑是ARP缓存过期或错误。设备换了网卡、IP被别的机器占用、或者有人手动改了IP都可能让ARP缓存里的映射失效导致数据包发到了错误的设备上。排这种问题的时候敲一条arp -d清理缓存或者arp -a看看缓存内容往往是第一条命令。另一个坑是ARP洪泛和ARP欺骗。在规模比较大的局域网里如果大量ARP广播同时出现交换机的CPU会被打满整个网段都会变慢。严格一点的网络会启用动态ARP检测或者端口安全防止有人伪造ARP应答。做运维的人脑子里必须有“ARP也会出问题”这根弦。2.3 用Wireshark把分层“看”出来我在培训时最常推荐的一招是用Wireshark抓包把分层模型从抽象的图变成看得见的协议树。随便抓一个DNS查询或者HTTP请求展开包头层次极其清楚最外层是以太网帧头里面有源MAC、目标MAC这是第二层的信息。往上一层是IP头里面有源IP、目标IP、TTL、协议号这是第三层的信息。再往上是TCP或者UDP头里面有源端口、目标端口、序号、确认号这是第四层的信息。最上层才是应用层的数据内容。这种一层包一层的结构就是网络分层的实物证据。以后每学一个协议都去抓包看一眼比背十遍格式定义都有用。而且对排障来说抓包能看到一个数据包从发出到返回的完整过程能定位到问题到底出在哪一层。提示抓包最好在测试环境练别直接在核心业务服务器上长时间抓。流量大的时候抓包文件会膨胀得很快几十秒钟就能攒出几个GB容易把磁盘填满。3. 理解IP与寻址子网划分和公网私网3.1 IPv4地址分类与CIDR的本质IP地址是网络层的核心你要想真正理解网络IP这一关必须过。IPv4地址是32位二进制数为了人眼方便通常写成点分十进制的形式比如192.168.1.100。最早设计者把IP地址分成了A、B、C三类按前几位区分网络规模。A类地址第一位是0网络号8位适合超大规模网络B类地址前两位是10网络号16位适合中等规模C类地址前三位是110网络号24位适合小网络。这种分类法在早期还能用后来发现太死板要么地址不够分要么浪费严重。于是出现了CIDR无类别域间路由。它的核心思想是不再按A/B/C类死板划分而是用“IP地址/前缀长度”来表示网络范围。192.168.1.0/24的意思就是前24位是网络号后8位是主机号这个网段里可用的地址范围是192.168.1.1到192.168.1.254其中192.168.1.0是网络地址192.168.1.255是广播地址。CIDR的好处是灵活。你家里可能只需要几十个地址用/24有点浪费那就用/2732个地址就够了。骨干网路由汇总也用CIDR可以把一堆小网段合并成一个大前缀让路由器上的路由表瘦身。3.2 子网掩码、网关与路由数据往哪儿走与CIDR紧密相关的一个概念是子网掩码。子网掩码的作用就是告诉设备“哪些位是网络号哪些位是主机号”。/24对应的子网掩码是255.255.255.0/16对应255.255.0.0/27对应255.255.255.224。设备拿到一个IP之后会做一件非常重要的事用自己的IP和子网掩码做与运算得出自己的网络号。发数据的时候再把目标IP和自己的子网掩码做与运算看目标设备和自己是不是同一个网段。如果是直接走ARP找到目标MAC地址如果不是就把数据交给默认网关处理。默认网关是什么它就是本网段通往外部世界的“关口”通常是一台路由器的LAN口地址。家里最常见的配置是192.168.1.1路由器收到你的数据后查看自己的路由表决定下一跳往哪走。路由表里匹配规则用最长的前缀优先也就是说掩码越长、范围越精确优先级越高。现实中我接过很多“网通但网页不开”的工单查到最后都是网关配错了或者路由器的路由表被人改乱了。所以排查网络第一问永远是网关能通吗ping一下默认网关通则说明局域网内没问题问题在出口不通问题就在本段链路。3.3 局域网排障必备IP冲突和NAT说一个几乎每位运维都遇到过的经典场景某台设备突然掉线重启后能连上路由器但上不了网一查系统日志提示IP地址冲突。所谓IP冲突就是同一个网段中有两台设备用了相同的IP。发生冲突时设备会收到一个免费的ARP通告告诉你这个地址已经被别人用了。后果就是似乎网络不稳定时好时坏因为交换机不知道把数据帧究竟转给谁。排查这种问题最笨但有效的方法是一台一台断开网线或者断Wi-Fi确定嫌疑人高效一点的做法是查路由器或交换机的DHCP租约表看哪个IP被分配了多次再通过接入层交换机查端口对应的设备。网络稍微大点的规划好DHCP静态保留和VLAN隔离是降低冲突概率的最好办法。这里还要连带提一下NAT网络地址转换。家用宽带出口只有一个公网IP但全家可能有十几台设备全靠NAT把私网IP映射成公网IP干活。NAT的出现缓解了公网IPv4地址枯竭的问题但也给P2P通信、游戏的联机带来了各种麻烦。你在路由器上配置端口映射就是手动建立一条NAT规则把公网的一个端口映射到内网某台机器的某一端口让外部流量能找到内部的服务。4. 域名解析与TCP核心机制4.1 DNS解析全流程与TTL网络基础里没有哪个环节像DNS一样明明人人都在用却总是被忽略。你访问一个网站输入的是域名但TCP/IP通信必须用IP地址把域名翻译成IP的这套机制就是DNS。简单说一下解析的全流程。你的电脑首先查本地DNS缓存不知道就去查hosts文件再不知道就把请求发给本地配置的DNS服务器。这个DNS服务器如果是递归解析模式你不需要知道它内部如何一步步问询它会帮你查完整个链条然后把最终结果返回给你。互联网上的实际解析过程是分层的根服务器管顶级域顶级域服务器管二级域权威服务器管具体的记录。你查某个域名的时候递归服务器会从根服务器一路问到权威服务器拿到答案后缓存起来等下一次查询直接用缓存返回。这里必须说一个和实际排障非常相关的东西TTL缓存生存时间。每条DNS记录都有一个TTL值单位是秒意思是这条记录可以在缓存里活多久。TTL设得太短查询压力大设得太长IP更换后客户端可能迟迟刷新不到新地址。我自己改服务器IP的时候通常提前1-3天把TTL调低让解析变更尽快生效等稳定后再调回来。家庭和办公场景最常见的DNS故障有几种表现能上微信但打不开网页、网页反复提示找不到服务器、间歇性网页打开慢。遇到这类问题先把DNS临时换成公共DNS服务试一下如果能恢复说明运营商默认DNS可能出了状况。再用nslookup或者dig工具直接查域名解析是否正常看返回的IP和TTL值是否符合预期。注意修改DNS之前先记录原来的配置排查结束后恢复。很多临时改完DNS忘了改回去之后出了问题又是一头雾水。4.2 TCP建立连接三次握手背后的状态管理TCP是一个面向连接的可靠传输协议。所谓面向连接就是通信双方在传数据之前要先通过一个握手过程建立连接。这个过程就是闻名遐迩的三次握手。我用寄包裹来类比。你给远方的朋友寄东西第一件事不是直接发货而是先打个电话确认对方在不在、能不能收货。打电话这个动作在TCP里就是客户端发送SYN报文里面带一个初始序号。服务器收到后如果能接受连接就回复一个SYNACK报文表示我听到了我也准备好了同时带上自己的初始序号。最后客户端再回复一个ACK表示确认收到服务器准备好了。此后双方进入ESTABLISHED状态开始正式传数据。三次握手看起来挺好理解但实际中藏着很多细节坑。一个常见问题是SYN洪水攻击攻击者发送大量伪造源IP的SYN报文服务器回复SYNACK后等待对方确认永远等不到半连接队列被占满正常用户连接不进来。这也是为什么生产环境的服务器要调TCP半连接队列大小、开启SYN Cookie防护。另一个现实问题是防火墙对TCP连接的拦截。很多企业防火墙默认只放行“从内到外”的会话。外部主动连内网的端口如果没有例外规则直接拒绝。你排查连不上服务器的时候不光要看服务器本身端口有没有监听还要看中间链路上防火墙是否放行。我自己的一个排障习惯是先telnet或者nc测一下目标端口通不通再用tcpdump或者Wireshark看有没有收包回包。这能帮你快速区分问题在中间链路还是在对端服务。4.3 四次挥手与TIME_WAIT关闭比建立更讲究如果说握手是建立连接的仪式那挥手就是关闭连接的仪式它由四次报文交换完成。主动关闭方发送FIN对方回复ACK接着对方发送自己的FIN主动方再回复ACK连接才算彻底关闭。为什么要四次因为TCP允许半关闭也就是说一端停止发送数据但还可以继续接收数据。被动关闭方要先回复ACK表示知道你要关了等自己把数据发完了再发FIN告诉对方我也要关了。所以多了一次报文交互。与挥手相关的一个状态叫TIME_WAIT这是主动关闭方在发出最后一个ACK之后进入的状态要保持一段时间。很多刚入行的同学会疑惑连接都关了为什么端口还占着这个状态的设计是为了防止最后一个ACK丢失保证网络中残留的迟到数据包不会干扰新连接。TIME_WAIT如果大量堆积会出现端口不够用的问题尤其是在高并发的短连接场景下。默认TIME_WAIT等待时间是2MSLMSL是最长报文段寿命加起来大概60秒。如果每秒创建的连接数非常多客户端或服务端的端口池可能被占满。调整net.ipv4.tcp_tw_reuse等内核参数可以缓解但前提是要清楚原理盲目开启可能带来数据错乱的风险。另外服务端大量出现TIME_WAIT一般不需要过分紧张更多的是排查CLOSE_WAIT状态。CLOSE_WAIT表示对方已经关了连接但本地程序迟迟没有调用close来关闭套接字这通常是程序代码没处理好连接释放属于应用层问题。4.4 滑动窗口与可靠传输TCP的可靠传输靠的是序号、确认号和重传机制。发送方给每个字节编上序号接收方收到数据后返回确认号表示“这个序号之前的我都收到了”。发送方如果在超时时间内没收到确认就重传数据。但TCP不能发一个等一个那样效率太低。于是有了滑动窗口机制。窗口大小决定了发送方在没有收到确认的情况下最多还能发多少数据。窗口越大网络吞吐率越高但也要考虑接收方的处理能力和网络拥塞情况。实际排障中网络慢最典型的指标就是TCP重传。用Wireshark抓包后菜单里的统计功能可以直接看到重传包的数量。如果重传占比高通常意味着网络存在丢包或者线路质量差。另一种情况是窗口太小表现是吞吐率上不去抓包会看到接收窗口反复收缩到很小的值相当于接收方的缓冲区快满了处理不过来。关于“网络慢”这个症状我见过的原因五花八门有Wi-Fi信号弱导致速率暴跌的有网线是劣质线跑不满千兆的有出口带宽被某台设备占满的有服务器网卡跑满中断的。所以别一上来就怪带宽先用数据说话把丢包率、重传率、窗口大小、链路速率逐项排查基本都能找到真正的瓶颈。5. 基础排障实战从现象到定位5.1 一张排查命令速查表网络基础要落到实操命令是基本功。我把平时最常用的一套排查命令整理成了表格每一条都写了典型用途和判断方法。你把这些命令练熟大部分常见网络问题都能快速定位到具体环节。命令用途关键判断点ipconfig / ifconfig查看本机IP配置确认IP、子网掩码、网关、DNS是否正常ping 127.0.0.1验证本机协议栈通说明网卡驱动和协议栈基本正常ping 网关验证局域网链路通说明本段链路和交换机正常。不通查网线、Wi-Fi、交换机端口ping 域名验证DNS与出口链路通说明出口和解析正常不通再ping对端IP区分是DNS还是链路tracert / traceroute查看路由路径看哪些跳超时、延迟高定位瓶颈段nslookup / dig查域名解析看返回的IP、TTL、解析耗时是否异常netstat / ss查看本机端口和连接状态确认端口监听、连接状态分布、TIME_WAIT数量arp -a查看ARP缓存确认局域网内IP与MAC映射是否正常这套命令的先后顺序是有逻辑的本质上是从本机出发一层一层向外探测逐步缩小问题范围。5.2 一个真实的“网页打不开”排障实录为了让你把前面的知识串起来我完整跑一遍经典的排障过程场景是办公网某台电脑打开网页很慢有时候直接超时。第一步ipconfig看IP配置。发现这台机器的IP是自动获取网关正常DNS是两个内网地址。于是先ping网关通说明局域网内链路没问题。再ping一个公网IP比如直接ping某个知名网站的IP发现也通说明出口链路没有断。第二步问题可能是DNS。用nslookup查刚才打不开的域名结果发现解析超时。这说明本地配置的DNS服务器响应有问题。临时把DNS改成公共DNS测试网页立刻能开了。到这里基本定位到是DNS服务器的问题跟ISP和运营商默认DNS有关。我直接把这个问题报给网络管理员让他们去查内网DNS服务状态。第三步如果想要更细的现场用Wireshark抓包再看一眼DNS请求的响应耗时能直观看到丢了几次重试才拿到结果。这种证据比口头描述“网页打不开”要有力得多。这个案例想说明一个道理排障不是碰运气而是一条链路一条链路地排除。每一步都问自己一个问题这个环节通不通通了就往下走不通就在这一层停留。5.3 抓包定位网络慢从TCP握手到应用层再分享一个偏进阶的场景两台服务器之间传数据速度一直上不去直观感觉是“网络不好”。但你ping发现延迟很低丢包为零那问题在哪这时抓包是最好的手段。抓包看TCP握手阶段如果三次握手都慢基本是链路问题或中间设备处理慢如果握手很快传数据阶段出现大量重传基本可以确定存在丢包如果重传不多但吞吐率低看接收窗口是否被收缩得非常小这是接收方处理能力的信号如果TCP层面都很正常但业务仍然慢那问题就可能出现在应用层的协议交互上比如HTTP请求排队、数据库查询慢。我自己抓包的习惯是先过滤出TCP流的首包和返回包右键“追踪TCP流”能直接看到应用层的完整请求和响应。再配合时序图和统计功能看重传率、RTT变化就能把一条链路里各个节点的表现量化出来排障的时候有理有据不做“看看是不是换根网线试试”这种碰运气的事。6. 常见问题速查与避坑清单日常网络排障有些问题是高频中的高频我直接整理成速查表方便你平时遇到问题随手查阅。症状最大嫌疑快速验证方式解决方向完全没网物理链路或IP获取失败看网卡状态、ipconfig是否拿到地址换网线、检查交换机端口、手动配IP试一下能上微信网页打不开DNS解析异常nslookup查域名换公共DNS、检查DNS服务器状态网速忽快忽慢无线信号干扰或链路拥塞ping网关看延迟抖动换频段、查上行带宽占用特定设备频繁掉线IP冲突或DHCP租约问题看系统日志和DHCP租约表设置静态保留、排查冲突设备外网能通内网服务连不上防火墙或服务未监听ss命令看端口监听状态检查防火墙规则、确认服务进程下载速度远低于带宽TCP窗口或线路质量抓包看重传率和接收窗口优化MTU、排查线路质量再补充几条我长期总结出来的避坑经验。第一条不要盲目重启设备和改配置。先记录现状再动手改一项验证一项避免问题没找到反而改出新问题。第二条判断网络问题一定先分层。本机协议栈、局域网、网关、出口、域名解析一个环节一个环节排除不要上来就怀疑总带宽。第三条日志和抓包是排障最有力的证据别靠感觉。第四条接手别人的网络环境花点时间看拓扑、VLAN和IP规划避免在错误的前提上做正确的事情。关于网络基础的学习路径我个人建议学完这些内容之后立刻在自家网络环境里做实验。改一改路由器的DHCP地址池搭一台小服务器用Wireshark观察TCP握手和DNS查询用命令行模拟一次完整的排障过程。网络基础最奇妙的地方在于它不需要昂贵设备你手边的电脑和路由器就是最好的实验室。把这些实验都亲手跑过一遍之后你对网络的理解会彻底从“听过”变成“会用”以后再遇到各种网络问题也就有了真正能依靠的判断力。
