企业官网建设流程全解析

“网络基础大汇总”这个题目，看着大，其实挺实在。工作了这些年，我发现一个规律：后台出问题、联调不通、线上告警，翻来覆去查到最后，多半不是配置不够高级，而是最底层的那些概念没理顺。很多人不是没学过网络，是学的时候东一块西一块，IP地址懂了，子网掩码会算了，但一到VLAN、路由、抓包就接不上，遇到故障只能靠猜。

这篇内容就是把散落的点串成一条线，从分层模型讲到IP与子网，从网关、DNS讲到VLAN配置和故障排查，每一段都带上实际能用的命令、参数和判断思路。适合刚入行的运维、做后端开发的程序员、准备网络认证考试的考生，也适合那些干了两年活、突然发现自己基础不扎实的“半熟手”。读完你会有一种感觉：网络其实不靠记，靠的是把原理和操作对上号。

1. 为什么我把网络分层的思路放在最前面

1.1 网上零散的知识最大的问题是“接不上”

我见过不少同事，能背出“应用层、传输层、网络层、链路层、物理层”，但真到排障的时候，不知道该从哪层下手。问他“域名解析失败算哪一层的问题”，他愣半天。这就是典型的“知道名词，没有体系”。

其实网络是一个高度结构化的东西。数据从一台设备到另一台设备，要经历封装、寻址、传输、解封装一整套流程。如果你脑子里有一张层级的图，遇到任何故障，第一反应就是“先判断问题出现在哪一层”，范围能立刻缩小一大半。反过来，没有这张图，你就像在一个没有地图的城市里找路，能走到，但效率极低。

所以这篇文章的第一件事，不是讲IP，不是讲VLAN，而是把分层模型这个“骨架”搭起来。后面的所有内容，包括子网计算、路由选路、抓包分析，全都挂在这副骨架上。

1.2 用“寄快递”理解数据封装与解封装

很多人觉得OSI七层很抽象，我习惯用寄快递来打比方。

你写一封信（应用层数据），先要装进信封写上收件人地址（传输层加端口号，TCP/UDP头），然后把信封放进一个快递包裹，写上收件人的小区和门牌号（网络层加IP地址），包裹再贴上快递单，告诉快递员这个包裹在哪个网点上下车（链路层加MAC地址），最后才是真正在路上跑的电瓶车（物理层的比特流）。

收件人收到后，按相反的顺序一层层拆：快递员认门牌（MAC），小区物业认小区（IP），拆开信看是谁收（端口），最后才是信的内容。这里面每一层都有自己独立的任务，层与层之间不越级。

有了这个模型，你再看“网络不通”这个问题就清晰多了。如果门牌号找不到，那是链路层的问题；如果小区不对，那是IP路由的问题；如果信到了但收件人不在，那是传输层或应用层的问题。每一层症状不一样，排查方法也完全不一样。

1.3 TCP/IP四层模型在实际工作中更常用

教科书讲七层，但实际配置、抓包、看日志，用的都是TCP/IP四层模型：应用层、传输层、网络层、网络接口层。

我在学的时候也纠结过，到底该记七层还是四层？后来经验告诉我，四层模型是日常工作语言，七层模型是用来理解细节的。你把四层模型作为主线，遇到模糊地带（比如HTTP到底算哪层、SSL证书属于哪层）再往七层里细化，这样既不累赘，也不会丢细节。

记住一件事：所有网络故障排查，第一步永远都是“先定位是第几层的问题”。这一句话值很多次深夜加班。

2. 真正要刻在脑子里的几个核心概念

2.1 IP地址与子网掩码：不是背概念，是算明白

IP地址和子网掩码是网络基础里的“九九乘法表”。你可以不背协议号，但这两个不会算，后面全是空中楼阁。

先说IP地址的组成。IPv4地址是32位二进制，写成十进制就是常见的192.168.1.1这种四段形式。这32位分成网络位和主机位两部分，网络位表示“你在哪个小区”，主机位表示“你是小区里的哪一栋”。子网掩码的作用就是划出这条分界线：掩码为1的位是网络位，为0的位是主机位。

举例来说，255.255.255.0写成二进制就是24个1加8个0，对应/24。192.168.1.0/24这个网络里，前三段是网络位，最后一段是主机位。可用地址范围是192.168.1.1到192.168.1.254，一共254个，因为主机位全0（192.168.1.0）代表网络本身，全1（192.168.1.255）代表广播地址，都不能配给设备。

很多人在子网划分的时候才开始头疼。比如给你一个192.168.1.0/24的网段，要求划分成4个子网，每个子网能容纳至少50台设备。

计算过程是这样的：需要从主机位借2位（2的2次方等于4，正好4个子网）。原来的主机位是8位，借走2位之后，每个子网的主机位变成6位。每个子网可用的主机数是2的6次方减2，也就是64减2，等于62台，满足50台的要求。子网掩码从/24变成/26，也就是255.255.255.192。

四个子网分别是：

• 192.168.1.0/26，可用地址1-62
• 192.168.1.64/26，可用地址65-126
• 192.168.1.128/26，可用地址129-190
• 192.168.1.192/26，可用地址193-254

这种计算在实际工作中非常高频。你帮客户规划办公网、给监控单独划网段、给服务器和打印机分VLAN，全靠这个基本功。别急着打开计算器工具，建议先自己手动算几遍，算熟了再用工具提速。

2.2 网关与路由：数据从你家到对方到底怎么走

网关这个概念，配置网络的人天天见，但很多人其实没想明白它到底干了什么。

简单说，网关就是你所在网段的“大门”。当你访问的地址不在自己这个网段内，设备就会把数据包交给网关，由网关帮你转发到别的网段。这也是为什么配IP的时候一定要配默认网关，没配网关，你只能和同网段的设备通信，出不了门。

网关的IP地址一般取网段里的第一个可用地址或最后一个可用地址，比如192.168.1.0/24这个网段，网关常用192.168.1.1。这是约定俗成的习惯，方便记忆和管理，也有用中间地址的，看实际需要。

路由则是网关要做的决策工作。路由器维护一张路由表，里面写着“去哪些网段走哪个接口”。数据包到路由器之后，路由器根据目的IP查路由表，找到最匹配的条目，再从对应接口转发出去。

查看路由表的命令，Windows下是route print，Linux下是ip route。我个人更喜欢ip route，输出干净，一眼能看到默认路由和静态路由。

实际排查中，遇到“能ping通网关但ping不通外网”的情况，问题大概率不在你的设备上，而在网关设备的路由表或上联链路。这时候去网关上看路由表、看接口状态，比在原地瞎试有用得多。

2.3 DNS与DHCP：两个天天用却被忽略的角色

DNS和DHCP，一个管“名字怎么变IP”，一个管“IP怎么自动分配”，平时安静得像不存在，一出问题整个网络就直接瘫痪。

DNS全称是域名系统，它解决的是“记住名字比记住数字容易”这个需求。你访问一个网站，浏览器先问DNS服务器“这个域名对应哪个IP”，拿到答案之后才发起真正的连接。整个查询过程是递归加迭代的：你的电脑问本地DNS，本地DNS再一步步往上查根服务器、顶级域服务器，直到拿到最终答案。

生产环境中DNS问题特别常见。我曾经遇到一个情况，某台服务器能ping通外网IP，但访问域名就是不通。排查下来发现是本地DNS配置指向了一个已经下线的服务器。把DNS改成公共DNS之后，问题立刻消失。

这里有个判断技巧：如果ping一个IP地址是通的，但ping域名不通，问题基本锁定在DNS。如果ping域名和pingIP都不通，那DNS先放一边，去查网络连通性。

DHCP负责自动分配IP地址。设备启动后发一个广播请求，DHCP服务器从地址池里挑一个IP租给设备，租约到期再续租。常见问题包括地址池耗尽、租约冲突、中继配置错误。排查DHCP问题最快的方式是看客户端有没有拿到IP，以及拿到的IP是不是在正常网段内。如果设备拿到了169.254开头的地址，说明DHCP服务器压根没应答，这就是“自动配置地址”——Windows在找不到DHCP时给自己临时分配的地址段，看到这个基本就能确定是DHCP层面的故障。

3. 实操：把知识点变成能复现的命令与配置

3.1 手把手配置一个VLAN环境

VLAN翻译过来是虚拟局域网，作用是在一台交换机上把端口划分成多个逻辑隔离的网络。不同VLAN之间默认不能通信，必须经过三层设备（路由器或三层交换机）才能互访。

我模拟一个最常见的办公网场景，两台交换机，一台核心交换机，一台接入交换机，要求划分两个VLAN，VLAN 10是办公区，VLAN 20是访客区。

接入交换机上的配置逻辑如下：

• 创建VLAN 10和VLAN 20
• 连接办公电脑的端口划入VLAN 10
• 连接访客区域的端口划入VLAN 20
• 上联到核心交换机的端口配置为Trunk模式，允许VLAN 10和VLAN 20通过

核心交换机上要做的事：

• 创建VLAN 10和VLAN 20
• 给两个VLAN分别配置SVI（交换机虚拟接口）地址，比如VLAN 10的网关是192.168.10.1，VLAN 20的网关是192.168.20.1
• 开启IP路由功能，让两个VLAN之间可以互访

这里面最容易踩坑的是Trunk配置。如果你忘了允许VLAN 20通过，或者两端Trunk的VLAN列表不一致，数据在链路上直接就被丢弃了。很多人查了半天，最后发现是Trunk允许列表的问题。

VLAN配置完成后，验证方法很简单：电脑A（VLAN 10）和电脑B（VLAN 20）互ping，通不通？不同VLAN之间要ping通，必须有三层网关且路由开启；同VLAN内ping不通，那就要查交换机端口状态、VLAN划分和线缆了。

3.2 抓包看三次握手和HTTP请求

抓包是理解网络最有效的方式，没有之一。之前背了无数遍的TCP三次握手，不如亲自抓一次包印象深刻。

我用最常见的抓包工具Wireshark举例，操作过程非常简单：

1. 打开Wireshark，选择要抓包的网卡（无线网卡或有线网卡）
2. 在过滤栏输入tcp.port == 80，只显示HTTP相关的TCP流量
3. 打开浏览器访问一个普通网站
4. 停止抓包，找到访问站点时建立的TCP连接

你会看到下面这个顺序：

• 客户端发一个SYN标志位的数据包，主动发起连接
• 服务器回一个SYN+ACK的数据包，表示“收到，而且我也准备好了”
• 客户端再发一个ACK的数据包，确认“好的，开始传数据”

这就是三次握手。你可以展开数据包看TCP头部里的Sequence Number和Acknowledgment Number，它们不是随便的随机数，而是有严格对应关系的。客户端发出的SYN里有一个初始序列号，服务器的SYN+ACK里会把客户端的序列号加1作为确认号，同时带上自己的序列号。

看完握手再看HTTP请求，你会发现应用层的数据其实是被“切”在TCP段里的。下载一个文件，可能要拆成很多个TCP段，每个段都有序号，接收方靠序号重组数据。哪个段丢了，就重传哪个，效率和准确性都兼顾了。

给新手的建议：Wireshark别一上来就去研究那些复杂协议，先从HTTP和TCP开始，配合ping、telnet这些简单工具理解链路。抓包这件事，抓一百次和抓一次，理解深度完全不同。

3.3 一组随时能背的排查配置清单

工具和命令用熟了，排查效率提升非常明显。下面这份清单是我在实际工作中反复使用、觉得最顺手的一批，按排查顺序排列：

在第一层物理层面，先看网卡指示灯是否正常、网线是否松动、交换机端口状态是不是UP。物理层没通，后面全白搭。

在链路和IP层面，Windows用ipconfig，Linux用ip addr，重点看三件事：IP地址是否正常、子网掩码是否正确、默认网关有没有配。没有IP就先检查DHCP，IP不在同一网段就去查VLAN划分。

在连通性层面，ping网关验证本网段是否通，ping远端IP验证跨网段路由是否通，ping域名验证DNS是否正常。这一步能快速把故障范围缩小到链路层、网络层还是应用层。

在端口层面，Windows用telnet IP 端口，Linux用nc -vz IP 端口。端口不通但不代表主机不通，要么服务没起，要么被防火墙挡了。

在抓包分析层面，Wireshark抓包看数据包有没有到、有没有回包、回包是不是RST或超时。这一步能确认前面的判断，定位到具体是哪个环节在丢包。

这些命令不需要背全，理解每一步在验证什么，比死记命令有价值。我自己的习惯是，先给自己设一个排查路径，然后不断用实际故障去校正这个路径，慢慢地就形成了肌肉记忆。

4. 故障排查：我踩过的坑和常用思路

4.1 三层网络不通的定位顺序

网络故障排查，最忌讳的就是没有章法。我见过很多人，一上来就绕来绕去乱试，最后才发现是线没插好。

我自己的排查顺序是这样的：

先从物理层开始。网线、光纤、光模块、电源，这些都是最基础但最容易被忽略的。尤其是光模块和光纤，稍微脏一点、弯折角度大一点，都可能光衰严重导致链路不通。先看端口状态，交换机上接口没有亮或显示Down，就说明物理层有隐患。

再查链路层。看交换机端口的VLAN、Trunk、STP状态，特别是STP（生成树协议），如果端口被阻塞了，同样会造成信号过不去。

然后是网络层。查IP、掩码、网关、路由表。这个环节最常见的问题是IP地址冲突，两台设备抢同一个IP，表现就是时而通时而不通，非常迷惑人。

再往上是传输层。端口通不通、防火墙有没有放行。尤其是防火墙，很多公司内部策略特别多，别人能通你不能通，十有八九是防火墙策略。

最后才是应用层。服务有没有启动、配置有没有错误、DNS解析是否正确。

这套顺序的价值在于，每一层都有对应的验证手段，一层层排除，不到十分钟就能定位。省下的时间，足够你看好几集剧。

4.2 几个高频问题速查表

工作中遇到的网络故障，高频的就那么几类，做成速查表放心里，遇到直接对照。

这张表我建议你截图保存，或者自己照着整理一份。每个问题后面都有一条明确的排查路径，比盲目百度要快得多。

4.3 排查之外：那些文档里一般不写的经验

踩坑踩多了，有一些体会是教程里不讲的，但对效率影响巨大。

第一，改配置之前一定要先备份。有一次我在值班时调整一个交换机接口的VLAN，没备份配置，结果命令敲错了，把整个业务VLAN搞乱，花了半个小时才恢复。从那以后，凡是动生产设备，必先save配置截屏留底。

第二，抓包前先把问题复现条件想清楚。抓包不是全程开着录，那样包太多反而看不出问题。先想明白触发故障的动作是什么，然后精准地抓那一段时间，你会轻松很多。

第三，换一个角度看问题：先看对端状态，再看本端状态。很多时候你觉得自己的配置没问题，但对方设备关了服务、路由没配、防火墙拦截，你在本端查再多也查不出结果。直接登到对端看一眼，往往一眼就明白。

另外一个小技巧：日志时间戳一定要对齐。排查问题时，经常需要对比多台设备的日志。如果各台设备时间不一样，你根本没法判断事件发生的先后顺序。平时就要配好NTP时间同步，关键时刻能救命。

最后分享一点个人的体会

把网络基础系统过了一遍之后，最大的感受是：很多看起来复杂的问题，底层原理并不复杂。你觉得自己缺的是“高级技术”，其实缺的是把基础概念串成体系的能力。每遇到一个故障，先定位是哪一层，再想这一层有哪些工具可以验证，思路立刻清晰。

我自己一直保留一个习惯：持续刷新对基础协议的理解。每隔一段时间，回看TCP握手、DHCP交互、路由选路，总能发现之前忽略的细节。基础这个东西，不是学一次就完事的，它值得你反复回来打磨。希望这篇汇总，能帮你少走点弯路。