企业官网建设流程全解析

先说明一个现象：我经常被问到“TCP/IP和HTTP到底谁转谁”这种问题，尤其是刚接触网络排查的同学，一说“协议转换”就以为是某个协议变成了另一个协议。实际上，HTTP、TCP、IP、以太网这几层协议不是互相转换，而是层层封装、逐段传输。搞懂了“谁在转谁”的核心逻辑，抓包、排障、看日志都会顺畅很多。

这篇文章我会从协议栈的分层关系讲起，把一次完整网页访问从DNS解析到TCP三次握手、再到HTTP请求响应的整个过程拆开，然后带你在真实环境里用抓包工具把协议交互过程看一遍，最后整理几个日常最常遇到的网络故障案例和排查方法。适合刚入门的运维、后端开发、网络爱好者，也适合想系统理解协议栈关系的人。

1. 一张图看懂：HTTP、TCP、IP、以太网到底谁包谁

1.1 协议不是软件，是各方都遵守的“约定”

很多人把“协议”理解成某个安装包或某条命令，这是误区。协议就是通信双方事先商量好的格式与流程。TCP/IP不是某一个协议，而是整个互联网通信协议家族的统称，里面包含TCP、UDP、IP、ICMP、ARP等一堆协议。HTTP则是跑在TCP/IP之上的一种应用层协议，它规定了浏览器和服务器之间交换数据的报文格式。

这里我直接给你一张分层对应表，先把角色摆清楚：

整条链路往下走的过程，就是每一层给上层数据“加一个头部”，往下传递；到了接收端，再一层层把头剥掉。所以严格说，协议与协议之间不存在“谁变成谁”，而是“谁把谁背在身上”。理解这一点，是理解协议交互的第一步。

1.2 一个HTTP请求从浏览器出发后，包结构长什么样

我们以访问一个普通网页为例，比如在浏览器地址栏输入某个域名然后回车，从网络协议栈的角度看，数据包的构造过程是这样的：

浏览器输入HTTP请求 ↓ 应用层：生成HTTP报文（请求行/头部/空行/消息体） ↓ 传输层：加上TCP头部，生成TCP段 源端口随机高位，目标端口80/443，加上序号、确认号、窗口等 ↓ 网络层：加上IP头部，生成IP包 源IP、目标IP、TTL、协议号（TCP为6，UDP为17） ↓ 链路层：加上以太网头部，生成以太网帧 源MAC、目标MAC，帧尾还有校验码FCS ↓ 物理层：变成一串0101的电信号或光信号发出

接收端方向完全反过来：从网卡收到以太网帧开始，剥掉以太网头，得到IP包；剥掉IP头，得到TCP段；剥掉TCP头，得到HTTP报文；最后交给浏览器解析渲染。发送端一层层“加头”，接收端一层层“去头”，这就是协议交互最底层的逻辑。

有个细节容易漏掉：每一层的头部里都有一个“文体说明”字段。比如IP头里有个协议号字段，值为6表示上层是TCP，值为17表示上层是UDP。TCP头里也有个目标端口字段，值为80表示这是给HTTP服务器进程的，值为443则通常是HTTPS。这些字段就是上层协议被“识别”出来的关键，也是抓包工具能判断“这是HTTP而不是别的什么协议”的依据。

1.3 用快递包裹类比“谁在转谁”

我用快递打比方，可能比直接背书好懂一些。你在网上下单买了个东西，商品本身是业务数据。商家打包时先塞进内包装，贴一张商品标签，这就是应用层的HTTP报文；快递公司再把它装进标准快递袋，打一张快递面单，写明发出地和目的地，这就是传输层和网络层做的事。到了分拨中心，快件还要被贴上“本区域装车”的调度条码，对应链路层的MAC帧头。运输过程中，干线司机只认快递面单上的城市信息，下一站配送员只认末端站点地址，各路人员各读一层信息，最终送到你手上。

所以“谁在转谁”这个说法，准确答案是：DNS帮你把域名“转译”成IP地址；发送端的各层协议把业务数据“封装”成更低层的格式；经过路由器时，路由器根据IP头重新封装链路层帧头，MAC地址会被替换；到达服务器后，各层协议再“解封装”还原出HTTP请求。真正发生“地址翻译”的地方是DNS、NAT这些环节，发生在协议栈里的更多是包络与还原。

2. 关键协议交互拆解：从DNS解析到三次握手，再到HTTP请求

2.1 DNS把域名转成IP，是整个会话的“开场白”

你不可能在HTTP请求里只填一个“域名：端口”就让TCP开跑，因为TCP/IP底层的寻址靠的是IP地址，不是域名。所以在建立TCP连接之前，系统必须先从DNS拿到域名对应的IP地址。

一次常规DNS查询流程是：浏览器先查本地DNS缓存，再查操作系统hosts文件，都没有的话，本地配置的DNS服务器开始迭代查询，最终拿到A记录或AAAA记录。这个过程通常走UDP协议的53端口，请求报文很短，一个往返就能完成，可靠性由应用层重试机制兜底。只有当响应数据特别大、超过UDP能承载的大小时，DNS才会改用TCP 53端口传输。很多人以为DNS一定是UDP，其实TCP和UDP都在DNS里用，只是场景不同。

本地排查时可以用dig或nslookup直接查询结果。比如dig example.com A能看到查询过程、权威服务器和TTL缓存时长。排网络故障的顺序一般是“域名能不能解析”排第一位，因为如果DNS解析失败，后面TCP握手和HTTP请求根本无从谈起。我见过不少“页面打不开”的工单，最后发现是内网DNS服务器故障或hosts被改，而不是服务器或防火墙的问题。

2.2 TCP三次握手让通信双方对齐状态，然后HTTP才上场

拿到IP地址后，浏览器开始发起TCP连接。这里一定要理解：HTTP本身可不管你数据怎么到达、有没有丢失或者乱序，这些脏活累活全部由TCP负责。三次握手就是TCP建立连接的关键流程：

1. 客户端发送SYN包，随机初始化一个序列号；
2. 服务端收到后回复SYN+ACK，既确认上次的序列号，也同步自己的序列号；
3. 客户端再发ACK确认，双方进入连接建立状态。

为什么是三次，不是两次？因为TCP是全双工的，双方都要确认对方的发送和接收能力都正常。两次交换只能让客户端确认服务端能收能发，却无法让服务端确认客户端的接收能力也没问题。三次握手之后，双方都知道“我能发、你能收、我的序列号起点是多少、你的序列号起点是多少”，之后才有资格传HTTP数据。

序列号是TCP头里的核心字段，很多人背了概念但不理解用途。它相当于每个字节数据的编号，接收端根据这个编号排序重组，不连续的编号就意味着丢包或乱序，所以TCP的可靠性很大程度建立在序列号和确认号体系上。抓包时你会看到，第一次SYN包的序列号往往不是从0开始的，这是为了防止历史连接中的旧包被误认为新包。

2.3 HTTP请求与响应的完整生命周期

TCP连接建立后，真正承载业务的是HTTP报文。一个标准HTTP/1.1 GET请求长这样：

GET /index.html HTTP/1.1 Host: example.com User-Agent: curl/7.68.0 Accept: */* Connection: close

第一行是请求行，包含方法、URI、协议版本；后面是若干请求头，用空行与消息体隔开。服务器响应时则是状态行、响应头、空行、响应体。注意HTTP报文里这些换行是CRLF，也就是\r\n，不能用单个\n代替，否则一些严格的服务器会直接报错。这是初学者手写HTTP报文时最容易踩的坑。

HTTP协议本身无状态，服务器不记得你上一次请求了什么。为了提升效率，HTTP/1.1引入了Keep-Alive长连接，让多个请求复用同一个TCP连接，避免每次请求都重新握手三次。HTTP/2更进一步做了多路复用，把多个逻辑请求交错塞进同一条TCP连接里，解决队头阻塞问题。到了HTTP/3，干脆底层改用基于UDP的QUIC协议，把传统TCP+TLS的整个传输路径重写了一遍，所以现在再讲“HTTP底层必须是TCP”已经过时了。这个变化也印证了前面说的核心：业务数据描述归HTTP，传输方式归传输层，不同版本可以重新选择传输机制。

2.4 别把TCP和UDP一刀切，该用谁由业务决定

TCP提供可靠、有序、字节流式的传输，适合HTTP、FTP、SMTP这类不能容忍丢数据的业务；UDP无连接、开销小、延迟低，适合DNS查询、实时音视频、在线游戏等场景。这里没有必要把UDP说得一无是处。

重点在于协议交互时不要犯一个错误：以为应用层封上TCP头就万事大吉。TCP只保证“把应用层数据可靠送到”，但数据的语义、格式、完整性校验依然由HTTP自己负责。打个比方，TCP是运输公司，只能把箱子完整送到；箱子里面装的是不是合格商品，运输公司不关心，HTTP才关心。所以排查问题时，如果HTTP返回的状态码说明业务异常，那十有八九不是TCP重传能解决的，要往应用层日志查。

3. 实操：抓包看协议转换全过程

3.1 先把抓包环境准备好

协议交互光靠脑补不够，我建议你在自己机器上实际抓一次包。Linux环境用tcpdump最轻量，需要root权限；Windows或Mac下用Wireshark更方便，支持图形化展示。这里我在Linux上演示，因为命令行操作适合直接写进脚本和远程排查。

先确认抓包接口：普通上网的接口一般是eth0或ens33，抓本机访问本机时要抓环回接口lo。用ip addr或ifconfig查看。抓包前还要确认目标主机可达，用ping快速验证，但记住：ping通只代表ICMP通，不代表HTTP端口通，两者不能划等号。

我常用的抓包命令是：

sudo tcpdump -i any -w http.pcap -s 64 port 80

参数含义：-i any抓所有接口，-w http.pcap把原始包写入文件，-s截取每个包的前64字节，避免抓包文件过大。攒够数据后，把pcap文件拖到Wireshark里分析，比直接看tcpdump命令行输出直观得多。如果只想实时看文本输出，直接去掉-w就行，但输出会比较乱。

3.2 用curl和nc手动模拟HTTP请求

抓包前最好能触发一个干净、可控的HTTP请求。最简单的方式是：

curl -v http://example.com/

-v把握手和请求细节打印在标准错误里，能看到TCP连接建立、TLS协商、请求头发送的过程。如果想更“原始”一点，可以先用nc手动拼HTTP请求：

printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80

注意我特意写了\r\n，这是HTTP协议要求的换行符。如果手写单\n，某些服务器可能不认。返回内容会包含响应头和HTML原文，发完Connection: close，服务器会主动关闭TCP连接，这样四次挥手也会一起发生。

有些系统没装nc，可以用bash内置的/dev/tcp伪设备：

exec 3<>/dev/tcp/example.com/80 printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' >&3 cat <&3

这种方法不依赖额外工具，在排查临时问题时非常管用。手动构造HTTP请求能帮你理解报文格式，不要光依赖curl替你干活。

3.3 抓包观察：先看到SYN，再看到HTTP包

现在我们同时开两个终端。终端A执行：

sudo tcpdump -i any -w web.pcap port 80

终端B执行：

curl -v http://example.com/

过几秒后按Ctrl+C停止抓包，然后用Wireshark打开web.pcap。你在包列表里会看到这样一串典型事件序列：

1. No.1：客户端发起SYN，目标端口80，源端口是一个临时高位端口，比如52340；
2. No.2：服务端回SYN+ACK；
3. No.3：客户端回ACK；
4. No.4：客户端发出HTTP GET请求报文，Wireshark的协议识别为HTTP；
5. No.5开始：响应报文可能被拆成多个TCP段返回；
6. 后续：连接关闭，出现FIN、ACK、FIN、ACK。

这组事件就是前面讲的“协议交互”在真实环境里的模样。你可以在Wireshark的“分析”菜单里选“Follow TCP Stream”，把整个HTTP请求和响应拼在一起看，能直接看到明文HTTP内容。注意这个操作只在HTTP明文场景有效，HTTPS抓包看到的是TLS加密密文，这是后话。

3.4 记住这几个关键过滤器，排障够用了

Wireshark过滤器很多，但日常排查记住几个就够。我整理了一个速查表：

实际工作中，我会先用ip.addr把范围圈住，再用tcp.analysis.retransmission看重传率。如果重传很多，优先怀疑链路丢包、带宽跑满或MTU问题，而不是急着看应用层。记住这个顺序，网络排障能少走很多弯路。

4. 常见问题与排查技巧实录

4.1 日常网络故障速查表

我把这半年在项目中遇到的高频问题整理成了一张表，方便直接对照：

这张表里最容易被忽略的是MTU问题。以太网链路默认MTU是1500字节，但TCP头部20字节、IP头部20字节之后，单包能承载的最大应用数据是1460字节，也就是MSS。如果HTTP响应比较大，TCP就会按MSS拆分数据段，每个数据包超过MTU时会被分片甚至被网络设备丢弃。遇到“大包不通、小包正常”的故障，先做MTU探测，方法是用ping -M do -s 1472 host看能不能通，1472加上28字节IP和ICMP头正好是1500。不能通的话，逐步减小-s参数找临界值。

4.2 三个真实场景排查案例

案例一：某服务偶发超时。我用tcpdump抓包发现大量tcp.analysis.retransmission和Dup ACK，说明链路里有丢包。链路层最常见的原因有三种：网线接触不良、交换机端口协商成半双工、带宽被打满。先看网卡状态ethtool eth0，确认速度和双工模式；再用sar -n DEV看带宽占用；最后检查交换机和网线。很多时候问题不在协议栈，而在物理链路，别一上来就怀疑TCP协议。

案例二：客户端报“连接被拒”，但服务端明明在监听。排查过程分三步：先在该服务器上用ss -lntp确认端口监听；再在同网段机器上用nc -zv 目标IP 端口探测；最后在目标服务器上用tcpdump看有没有SYN包进入。如果SYN包到了但没有SYN+ACK返回，基本可以锁定本地防火墙或安全组规则。有个坑是云平台的安全组和主机防火墙层层叠加，漏看一层就会被拒。这种情况要先看主机外部防火墙，再看本机iptables/firewalld规则。

案例三：应用启动后访问时好时坏，抓包发现大量SYN重传但没有SYN+ACK。除了防火墙丢弃，还有一个可能：服务端的半连接队列已满。TCP连接建立前的SYN队列和全连接队列都有上限，应用accept得慢，队列就容易被填满。查队列可以用ss -lnt，重点看Recv-Q和Send-Q。对大规模并发服务，需要调整应用监听参数和系统参数，但不要盲目调大somaxconn，队列太大反而会让等待变长、超时更多。

4.3 抓包排障的几条经验笔记

第一，抓包一定要抓“起点和终点”。如果你只抓客户端本机，只能看到发送端发出的包和收到的响应，看不到网络中间的丢弃点；如果方便，在客户端和服务器两端同时抓包，对比同一个报文是否到达，能很快定位是客户端的出口问题还是服务端的入口问题。

第二，用Wireshark打开pcap后，不要只看第一屏。打开“Statistics -> Conversations”，看TCP会话的数量、时长、重传次数，比翻一个个数据包高效得多。面对上千个包时，先统计再定点查看，效率翻倍。

第三，HTTPS环境下不要急着看明文。Wireshark默认无法解密TLS流量，但可以在Wireshark的TLS协议设置里配置SSLKEYLOGFILE，把浏览器或curl导出的会话密钥文件填进去，很多版本都能直接解密HTTPS流量。这个方法建议只在你自己控制的测试环境里用，不要随意抓生产环境的业务流量，涉及隐私和合规问题的时候要多留意。

第四，配置curl自带的跟踪输出，比抓包更快。排HTTP类问题时，我经常先跑一次：

curl -v --trace-ascii - http://example.com/

这个命令会在终端直接输出TCP和HTTP头的完整过程，不用开抓包工具就能看个七八分。等到需要深入看丢包、重传、队列这些链路层或传输层问题时，再用tcpdump和Wireshark。

写到这里，再回到标题的问题上：谁在转谁？我的理解是，DNS把域名转成IP，NAT把私有地址转成公网地址，代理或网关在边界处做请求转发，而位于协议栈中间的HTTP、TCP、IP、以太网，它们之间更像是套娃式的封装与解封装，不是相互转变。每次抓包看到SYN、ACK、HTTP GET这些包时，我都会想起这层关系。如果这篇内容能帮你少绕几个弯，那我写它的目的就达到了。最后建议新手别急着背协议头部的每个字段，先花半小时抓一次自己访问网页的包，把三次握手和HTTP请求对应起来看一眼，很多以前记不住的概念，一下子就通了。