服务器与客户端通信图是理解网络请求全过程的路线图，核心在于客户端发起请求、服务器响应数据，中间经过DNS解析、TCP连接、HTTP传输等环节。这张图把看不见的网络交互变成一条清晰的链路，无论是排查网页打不开，还是优化接口响应速度,都离不开它。
服务器与客户端通信图怎么画：跟着一次访问走一遍
画通信图不需要专业工具，拿一张纸或白板，按顺序把数据流经的节点画出来就行，以你在浏览器输入网址访问一个购物网站为例,整个过程分六步。
- 第一步，解析域名，浏览器收到网址后，先问本地DNS服务器：“www.example.com的IP地址是多少？”DNS服务器层层查询，最终返回一个数字IP，比如203.0.113.5。
- 第二步，建立TCP连接，客户端拿到IP地址，向服务器发起三次握手请求，相当于先敲敲门,确认服务器在家。
- 第三步，发送HTTP请求，连接建立后，浏览器发送GET请求，内容包含路径、请求头、Cookie等信息。
- 第四步，服务器处理请求，服务器上的Nginx或Apache接收请求，转发给后端应用，应用查询数据库,生成HTML页面。
- 第五步，返回响应数据，服务器把状态码（如200 OK）和页面内容打包,通过TCP连接传回客户端。
- 第六步，浏览器渲染页面，浏览器收到HTML，解析CSS和JavaScript,最终在屏幕上画出完整页面。
把这三个角色和六步画在图上，就得到一张标准的服务器与客户端通信图，注意在图上标注每个环节的协议名称，比如DNS走UDP，HTTP走TCP，传输层用IP地址,这样图才完整。
服务器与客户端通信原理是什么：三个角色一台戏
通信图里只有两个主要节点，但真正参与对话的至少有三个角色，客户端负责发起请求，服务器负责提供资源，中间网络负责搬运数据，用一个生活场景类比：客户端是点菜的食客，服务器是后厨,网络是传菜的服务员。
客户端：那个总是主动开口的角色
客户端常见形式是浏览器、手机App、桌面软件，它不一定是人，但行为模式很像一个急性子先问路（DNS解析），再敲门（TCP握手），然后递菜单（HTTP请求），最后等着上菜，同一个客户端可以同时和多个服务器通信,就像一个人同时给好几家餐厅打电话订餐。
服务器：等待被敲门的守夜人
服务器通常是一台配置更高的计算机，常年运行在机房，监听固定端口（默认80或443），它不会主动联系客户端，只有收到请求后才开始工作，服务器端常见的软件栈包括Nginx、Apache、Tomcat、Node.js等，行业共识认为，服务器性能瓶颈往往在数据库查询和磁盘I/O,而不是网络带宽。
中间网络：默默无闻的搬运工
通信图上那条连接两个节点的线，实际由路由器、交换机、防火墙、DNS服务器、CDN节点组成，每一次数据包转发，都要经过这些设备，所以通信图里应该把中间网络画成一个虚线框，里面标注“公网”或“内网”,而不是简单画一条直线。
通信图中的三次握手与四次挥手：连接的生命周期
TCP协议是通信图里最核心的传输层协议，它用三次握手建立连接，用四次挥手断开连接,每次信号交换都对应图上的一个箭头。
三次握手到底在说什么
第一次握手：客户端发送SYN包，带着一个随机序号x，意思是“我想跟你说话”。
第二次握手：服务器回复SYN+ACK包，序号y，确认号x+1，意思是“我收到了，我也想跟你说话”。
第三次握手：客户端发送ACK包，确认号y+1，意思是“好，那咱们开始吧”。
画图时，这三个箭头必须按顺序标注，方向分别是客户端到服务器、服务器到客户端、客户端到服务器，如果只画两次握手，服务器无法确认客户端是否真的收到了自己的回复,可能造成半连接状态。
四次挥手：说再见也要讲礼貌
断开连接时，因为TCP允许双向独立关闭,所以需要四次挥手：
- 客户端发送FIN，表示“我这边的话说完了”。
- 服务器回复ACK，表示“知道了，但我的话还没说完”。
- 服务器发送FIN，表示“我这边也说完了”。
- 客户端回复ACK，表示“好，那咱们都闭嘴”。
在通信图上，这两个过程通常用竖线表示时间，用箭头表示报文方向，形成经典的时序图，看懂这个时序图,就能理解为什么网络抓包工具里那么多SYN和ACK。
用通信图对比HTTP与HTTPS：安全与否的差别
很多人在看通信图时，会纠结HTTP和HTTPS在图上有什么区别，其实两者的通信流程几乎一样,差别只在第三步到第四步之间多了一层TLS握手。
- HTTP
：客户端和服务器之间直接传输明文数据,图中的请求和响应都是透明可见的。
- HTTPS：在TCP三次握手之后，额外进行一次TLS握手，协商加密密钥,之后所有HTTP报文都变成密文。
具体到图上，HTTPS的时序比HTTP多出四个箭头：客户端发送ClientHello，服务器返回ServerHello和证书，客户端验证证书并生成密钥，双方完成加密确认，如果画一张完整的服务器与客户端通信图,HTTPS的箭头数量大约是HTTP的两倍。
从性能角度看，HTTPS额外消耗约1到2个RTT（往返时间），但现代网站普遍启用，据工信部等机构近年来的统计，国内主流网站HTTPS覆盖率已经相当高，业内专家指出，在没有HTTPS的网站上输入密码,等同于在通信图上给黑客留了一扇门。
| 对比项 | HTTP | HTTPS |
|---|---|---|
| 通信图额外环节 | 无 | TLS握手 |
| 数据可见性 | 明文 | 密文 |
| 默认端口 | 80 | 443 |
| 连接建立时间 | 较快 | 多1-2个RTT |
| 适用场景 | 公开信息 | 登录、支付、隐私数据 |
服务器与客户端通信图解读：从图里看出性能瓶颈
通信图不只是用来画给领导看的，它更是排查问题的地图，当网站变慢或打不开时,按图索骥能快速定位问题出在哪个环节。
用浏览器开发者工具看真实通信图
打开Chrome的开发者工具（F12），切到Network标签页，刷新页面，就能看到每一个资源的加载时间线,注意看以下几项：
- DNS Lookup：如果超过100ms，说明DNS解析慢,可能是本地DNS服务器配置不当。
- Initial Connection：如果TCP握手时间过长,可能是服务器负载高或网络丢包。
- TTFB（Time to First Byte）：服务器处理请求并返回第一个字节的时间，如果这个值大,说明后端逻辑或数据库查询是瓶颈。
- Content Download：下载时间过长,可能是文件太大或带宽不足。
用命令行工具验证通信图上的每个节点
在Windows或Linux终端里,可以执行以下命令逐段排查：
ping 域名：检查客户端到服务器IP的连通性和延迟。tracert 域名（Windows）或traceroute 域名（Linux）：看数据包经过哪些路由器,定位在哪一跳丢包。curl -v 网址：显示完整的HTTP请求和响应头，包括DNS解析时间、TCP连接时间、TLS握手时间。tcpdump -i eth0 port 80：抓包查看实际传输的SYN、ACK、HTTP数据包,和通信图逐条比对。
如果通信图上显示客户端已经发送了SYN，但迟迟收不到SYN+ACK，大概率是防火墙拦截或服务器端口未开放，如果三次握手都成功，但HTTP请求没有响应,问题可能出在服务端应用进程崩溃。
常见的画图误区
很多初学者画出来的通信图，要么把DNS解析省略了，要么把TCP连接画成一条直线，正确的做法是：DNS解析画在TCP连接之前，每次请求和响应都要有箭头和协议标注，不要把CDN漏掉如果网站用了CDN，客户端实际连接的是CDN节点，而不是源站服务器,通信图里要额外画一个CDN层。
Q&A：服务器与客户端通信图常见问题解答
通信图里的TTL是什么？为什么我ping的时候数字会变？
TTL是IP数据包里的一个字段，全称Time To Live，表示数据包最多能经过多少个路由器，每经过一个路由器，TTL减1，减到0时数据包被丢弃并返回ICMP超时消息，你ping时看到的TTL值，是响应数据包里的初始TTL减去经过的路由器数量，不同操作系统初始TTL不同，Linux一般是64，Windows一般是128，所以看到TTL小于64时,说明数据包绕了远路。
通信图有必要把TCP三次握手和四次挥手都画出来吗？
有必要，但要分场景，如果是给非技术同事看整体流程，画三次握手就够了，四次挥手可以省略，如果是排查连接关闭异常或抓包分析，必须把四次挥手画全，因为很多网络问题恰恰出在TIME_WAIT或CLOSE_WAIT状态上，画图时记住一个原则：关键状态和关键报文不能少,辅助细节可以合并。
用通信图能直接判断是服务器慢还是网络慢吗？
可以，在通信图上找到“服务器处理”这个节点，看它之前的网络传输时间（TTFB减去TCP连接时间）和之后的下载时间，如果TTFB很大但TCP连接时间正常，说明服务器处理慢；如果TCP连接时间本身很大，说明网络链路有问题，更精确的做法是在服务器本地用curl测试，对比客户端和服务器两端的耗时差异，差异越大,网络问题越明显。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/553077.html
