用户输入的项目标题是“笔记网络核心协议与DNS,CND”这里“CND”应该就是CDN的意思估计是随手打的缩写。热搜词里也明确出现了“CDN”所以这篇笔记的核心就是网络核心协议、DNS、CDN这三块内容。很久没认真梳理过这块知识了。平时排查网络问题绕不开协议绕不开DNS也绕不开CDN这三者表面上是独立的技术话题实际工作中却紧紧咬合在一起。我先把思路理清楚然后按一套实际可落地的顺序来写。先说这篇博文面向谁网络运维、后端开发、刚入门的学生都适合。它不是什么高深理论课而是我这些年踩坑、排障过程中沉淀下来的核心总结围绕“怎么理解、怎么配置、怎么排查”来展开。我会尽量把底层原理讲得通俗再把实操步骤给足确保看完能直接用在日常工作中。开头部分直接用从业者视角切入讲一讲为什么这三块东西一体认识很重要。然后分几个大章节先讲网络核心协议的骨架TCP/IP、HTTP/HTTPS再讲DNS的解析链路与多场景配置接着是CDN的加速逻辑与接入细节最后用一个“从输入域名到渲染页面”的完整链路把三者串起来再用速查表和排障习惯收尾。以下是我整理好的正文内容。 搞网络这么多年我最大的体会是很多人排查问题习惯“头痛医头”页面打不开就查服务器接口报错就盯日志但真正卡住你的往往是更底层的那三件事——网络核心协议、DNS解析、CDN调度。协议决定数据怎么传DNS决定你去哪台服务器CDN决定谁来接你的请求。这三者不是独立的知识点而是一条完整的链路。这篇笔记就是围绕这条链路展开的把“底层规则”和“实际排障”串起来适合网络运维、后端开发和刚入门的学生反复阅读。我会把原理讲透把配置步骤给足也把我踩过的一些坑原原本本写出来大家照着做就能少走弯路。1. 网络核心协议互联网通信的底层骨架1.1 协议分层四层模型与一次请求的“寄快递”过程我们常说的网络协议最实用的理解方式是分成四层链路层、网络层、传输层、应用层。不用纠结七层模型实际排查问题时四层够用了。链路层管物理网卡和局域网通信网络层管IP寻址与路由传输层管端口和连接状态应用层管HTTP、DNS、FTP这些具体业务协议。用寄快递来类比链路层就是包裹从小区快递站到城市集散点的这段路网络层负责规划“从北京到上海走哪条高速”传输层相当于快递单上的“收件人姓名电话”应用层则是包裹里装的东西本身。当你访问一个网站数据包会从应用层往下逐层封装每层都把自己的头信息加上到对端再逐层拆开。排查丢包、延迟问题的时候就要明确问题出在哪个“快递环节”而不是一上来就怀疑应用层。排障时最常用的分层思路是这样的先看链路层通不通ping网关再看网络层通不通ping对端IP然后确认传输层连接是否建立telnet端口最后才轮到应用层HTTP状态码、返回内容。90%的初级排查问题都是因为跳过了前两层直接定位到应用层才把方向带偏的。1.2 TCP连接机制三次握手与四次挥手到底在干嘛TCP最核心的两个机制是可靠传输和连接管理。建立连接时用三次握手目的不只是打招呼而是要让双方确认彼此的收发能力都正常。三次握手的过程客户端发SYN服务端回SYNACK客户端再回ACK。为什么非要三次因为只有三次才能让双方都确认“你能收到我的消息我也能收到你的消息”。如果只有两次握手服务端无法确认客户端的接收能力半开连接积累多了就是连接数被打满的前兆。挥手的理论是四次因为TCP可以半关闭——一端发送FIN只代表“我不再发了”不代表“我不再接收”所以需要两个方向的FINACK。实际工作中三次握手状态能帮你快速判断问题SYN_SENT卡住客户端发出去的SYN没回应方向是防火墙拦了出站或目标端口不存在。SYN_RECV大量堆积半连接队列满了服务端来不及处理。此时压测最容易被误判为“高并发导致的全量拒绝”其实有时只是队列参数太小。TIME_WAIT过多主动关闭方大量出现如果服务端主动断开连接容易积累TIME_WAIT。优化方式不是盲目调小TIME_WAIT而是先排查为什么服务端在主动断开——许多时候是应用层没设置Keep-Alive。TCP还有个容易被忽略的点是缓冲区与重传机制。早期排障遇到大文件传输很慢我会习惯性怀疑带宽抓包一看是TCP重传风暴——丢包重传占了大量窗口实际有效吞吐极低。这类问题往往出在物理链路质量、防火墙连接跟踪表溢出或网卡驱动层面。不要只看带宽RTT与重传率才是TCP性能的关键指标。1.3 HTTP与HTTPS应用层协议的业务规则应用层最核心的协议就是HTTP。HTTP本身是无状态协议靠Header和Cookie来实现状态维持。平时排查接口问题时我第一件事就是打开F12看请求头、响应头和状态码。状态码是最高效的定位工具2xx成功不用看。301/302有跳转注意Location是否指向了外网部分内网环境会因跳转失败导致“页面打不开”。401/403鉴权或权限问题不是网络问题别跑偏。404资源不存在先查路由配置、静态资源路径。5xx服务端问题连接本身通的要去查应用日志。499客户端断开了连接常见于代理服务器超时或用户主动取消。HTTPS就是在HTTP和TCP之间加了TLS层作用是加密传输、验证身份、防篡改。很多运维会忽略TLS握手细节——握手需要多次RTT往返离用户较远时延迟会很明显。这也是为什么CDN调度和协议优化能直接影响响应速度握手交到离用户最近的边缘节点去完成RTT就低了。HTTP/2和HTTP/3这两年普及率越来越高。HTTP/2的多路复用解决了队头阻塞问题HTTP/3则把传输层换成UDP上的QUIC协议连接建立更快、弱网抗性更好。如果你发现自己的接口毫秒级延迟但带宽充足可以检查是否已经支持HTTP/2——有些旧Nginx配置默认还是HTTP/1.1升级后延迟效果改善非常明显。2. DNS互联网的地址簿2.1 从域名到IP一次完整解析过程DNS做的事情很简单把域名解析成IP。解析过程分为递归查询和迭代查询。客户端拿到一个域名时会先查本地缓存再查hosts文件最后才请求配置的DNS服务器递归服务器。递归服务器替你一层层问根DNS服务器告诉它“.com”在哪顶级域服务器告诉它“example.com”在哪权威服务器才告诉它最终的A记录IP。把这几个角色理顺排查问题的思路会清晰很多。实际排查时**判断“域名解析到哪”**非常关键。在Linux上我会习惯性用dig而不是nslookup因为dig trace可以看到完整的递归过程能瞬间定位是哪一层出了问题。曾经遇到一次内部系统间歇性无法访问dig结果显示同时返回了两个IP一个通一个不通——配置了多条A记录但其中一台服务器已下线。这种情况在云环境做多活部署时特别容易出现切流量前一定要对DNS记录做一次可用性检查。DNS还有不少运维细节容易被忽略TTL生存时间控制缓存时长修改解析记录后不会立即全球生效各地缓存要等TTL过期。计划内切流量应提前把TTL调低再操作。hosts文件的优先级通常最高排障时碰到“浏览器能打开服务器上curl却报错”先看看hosts里是不是写了旧IP。DNS劫持问题在国内网络现实中确实存在常见的表现是解析结果被换成了某个运营商的缓存IP。这个时候需要自建可信递归或者用DoHDNS over HTTPS来规避。2.2 解析记录类型速查不是只有A记录很多人对DNS记录的理解停留在“把域名变成IP”但实际配置时你会发现至少有六七种记录常打交道。我整理了一张速查表记录类型作用典型场景A域名指向IPv4地址基本的主机解析AAAA域名指向IPv6地址IPv6网络环境CNAME域名指向另一个域名CDN接入、多域名指向MX指定邮件服务器企业邮箱配置TXT任意文本信息域名验证、SPF反垃圾邮件NS指定域名的权威服务器域名托管切换PTRIP反向解析IP指向域名反垃圾邮件、日志溯源配置上的几个常见坑CNAME和A记录不能共存于同一主机名。如果你需要同时配置就得用A记录加多个IP或者换子域名。MX记录不要指向CNAME。RFC明确不推荐不少邮件服务商也做了限制最好直接指向A记录的域名。NS记录修改影响巨大。NS记录指向的服务器决定整个域名的解析结果必须确认新NS服务器已正常加载区域数据再切换否则全球解析直接挂掉。2.3 多环境下的DNS配置实操DNS配置在不同环境里差异很大我把高频场景都整理了出来。Linux场景传统方式是直接编辑/etc/resolv.conf两三行就能搞定nameserver 223.5.5.5 nameserver 114.114.114.114 options timeout:2 attempts:1但很多新系统用上了systemd-resolved直接改resolv.conf重启网络后就被还原。这个问题热搜里也反复出现——正确做法有两种要么systemctl disable systemd-resolved后手动管控要么通过/etc/systemd/resolved.conf配置DNS并ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf让resolv.conf实时指向systemd生成的结果。options timeout:2 attempts:1是我特别推荐的配置避免默认的DNS超时重试把应用卡住。Windows与AD域场景Windows主机一般用DHCP自动获取DNS但域控环境更特殊。AD域内多台DC域控制器时DC网卡的首选DNS必须指向自己或另一台DC绝不能指向外部公网DNS或运营商DNS否则域解析会乱套用户登录会卡组策略下发会失败。具体配置原则是每台DC首选DNS指向自身备选指向另一台DC形成互备。AD域的_msdcs.zone区域里包含大量关键服务定位记录这些数据只在域控制器之间复制。麒麟系统部署DNS服务国产麒麟系统部署DNS服务和CentOS很接近安装bind后配置/etc/named.conf创建区域文件即可。有一点要特别提醒firewalld默认会拦截53端口配置完服务后必须放行否则外部永远解析不了。麒麟系统的selinux也要检查setsebool -P named_write_master_zones 1在部分版本里是必需的否则写区域文件会报权限错误。公共DNS选型国内外常用几个公共DNS223.5.5.5阿里、119.29.29.29腾讯、114.114.114.114114DNS、1.2.4.8CNNIC、8.8.8.8和1.1.1.1国外。国内业务选国内DNS延迟低安全敏感场景选DoH加密多线路容错时可以把主备配成不同厂商避免单一故障点。2.4 DNS排障实用指南高频DNS问题的排查思路下面这几类是我遇到最多的。Chrome提示“无法找到DNS地址”先ping网关确认网络没断再nslookup域名看解析是否正常如果nslookup正常但浏览器不行大概率是Chrome内置的DNS缓存或DoH配置出了毛病——关掉“安全DNS”选项或者重启浏览器进程就恢复了。这种情况经常被误判为“我们服务器挂了”实际上跟服务器一毛钱关系没有。Linux修改DNS后重启网络就还原前面说过了systemd-resolved接管后直接改resolv.conf无效。更隐蔽的一种情况是DHCP client在续约时强制覆盖了DNS配置需要同时修改dhclient的配置文件把supersede domain-name-servers写上。Windows DNS Client事件ID 1012这个事件代表DNS客户端解析超时或配置异常。出现大量1012时通常是企业网络中DNS服务器压力过大或者防火墙丢包导致DNS请求被丢弃不只是“网络慢”这么简单。解决思路是优化DNS服务器性能增加节点或缓存、检查防火墙是否拦截UDP 53、给客户端批量指定备用DNS。3. CDN内容分发网络的加速逻辑3.1 CDN解决的核心矛盾CDN要解决的问题本质上是内容离用户太远。用户从北京访问上海源站走公网来回延迟几十毫秒是常态加上丢包率、跨运营商互联瓶颈体验就会很差。CDN的做法是在各地部署边缘节点把源站内容提前缓存到离用户近的节点上用户访问时直接命中边缘节点省去跨地域绕路。理解CDN时要从两个维度看千万别一把抓静态加速图片、CSS、JS、视频这类很少变的内容适合边缘缓存。命中率高了回源就少速度自然快。动态加速API接口、登录请求这类不能被缓存的内容CDN做的是路由优化——利用节点之间探测到的优质链路替代公网绕行。很多人要求“CDN别缓存我的API”本质上是没区分角色动态加速不缓存但链路确实被优化了。CDN不是万能的。网站本身下载慢源站带宽打满CDN反而会因为回源超时导致“越加速越慢”。所以接入CDN前我一般会先测源站单机性能确认瓶颈不在源站自身处理能力上。3.2 CDN接入与调度原理CNAME只是第一步CDN接入的标配方式是把域名配一条CNAME记录指向CDN厂商提供的域名比如cdn.example.com.cname.cdnprovider.com。但这里有个理解难点CDN收到请求时是怎么知道该给你返回哪个节点IP的答案在GSLB全局负载均衡调度。CDN厂商在全球部署了调度中心DNS解析CNAME时调度中心会依据两条核心信息返回IP请求来源的运营商和地理位置。边缘节点的实时负载与可用性。这套机制也解释了几个经典运维现象为什么老觉得CDN“不生效”本机DNS缓存了旧IP。必须等TTL过期或者主动刷新DNS缓存否则你看到的永远是调度前的旧节点。为什么同一个域名不同地区解析结果不同这是CDN的本职工作——各回各家各找各最近的节点。如果你在成都和上海分别dig同一个域名返回了不同节点IP那是正常现象。回源配置是个关键动作尤其做HTTPS时。边缘节点的证书必须和源站域名匹配原则是要么边缘节点用同一张泛域名证书要么源站放行CDN回源IP段。我曾经踩过这个坑边缘节点回源用HTTP源站只开了443端口结果大量缓存失效时所有回源请求全部失败前端表现为“整站间歇性打不开”3天。最后查清楚是回源协议没有同步改成HTTPS。3.3 缓存策略与命中率优化CDN缓存的生命周期由HTTP头控制最核心的是Cache-Control和Expires。源站下发Cache-Control: max-age3600CDN边缘节点就会缓存1小时。但静态资源我建议在源站把max-age设大一些一年甚至更久配合文件名内容hash来做“永久缓存”这样版本更新时URL变化CDN自动视为新资源处理不需要手动刷新还能把命中率拉到极高。另外几个优化方向按优先级排序将静态资源和动态接口分离域名。别混用混用会导致缓存策略互相妥协静态资源缓存时间被拉低。定期看命中率指标。低于90%先自查源站头信息是不是带了no-cache再检查URL中是否有时间戳参数——带随机参数的请求永远无法命中。合理使用刷新与预热。版本更新后用API刷新对应URL大促前主动预热热点资源把流量提前“塞”进边缘节点避免集中回源打垮源站。在我的经验里CDN问题定位最快的方法是“对比法”找一个最近本地的非CDN域名测速再走CDN测一次。两者差异巨大那就先怀疑CDN链路几乎没有差异就回头检查源站和业务逻辑别在CDN配置上死磕。3.4 前端CDN使用场景公共资源引入与版本管理CDN在纯前端场景也有不少应用最常见的就是公共库引入。比如Vue直接走官方CDN、企业微信JS-SDK走CDN加载。这里给一个真实坑企业微信JS-SDK应使用不低于2.3.2的版本老版本存在兼容性和安全漏洞风险如果不锁定版本或者用了太旧的缓存会出现莫名其妙的invalid signature错误和初始化失败。公共CDN引入JS-SDK时一定要锁定版本号别用latest否则CDN缓存更新或上游发布新版本业务直接受到不可控影响。锁版本的方式很简单把URL中的2.3.2写死即可。另外公共CDN域名要与业务接口域名分开防止业务接口的cookie带上JS请求并造成跨域问题。企业内网环境如果访问不了外网公共CDN就需要搭私有化代理把常用公共库缓存到内网否则页面加载会卡在某个静态资源上一直转圈。4. 从输入域名到看到页面一次真实访问的全链路解析4.1 全流程串联没有CDN与有CDN的对比把协议、DNS、CDN串起来看一遍完整流程理解就会落地很多。无CDN场景用户在浏览器输入www.example.com时实际发生的事情依次是浏览器查本地DNS缓存和hosts向本地DNS服务器发起递归解析拿到源站IP发起TCP三次握手建立连接协商TLS加密发送HTTP请求服务端返回数据浏览器渲染页面。有CDN场景只有一个关键动作变了DNS解析那一步返回的不是源站IP而是CDN的边缘节点IP。后续TCP握手、TLS协商、HTTP请求全部打到边缘节点上边缘节点若命中缓存就直接返回若未命中则由边缘节点向源站发起回源请求拿回内容后缓存在本地并返回给用户。用户从头到尾接触不到源站IP源站只需要对CDN节点网段放行即可天然隐藏了源站真实地址顺带获得一层防攻击保护。4.2 DNS、CDN、协议三者如何互相影响这三者在业务层面上不是孤立存在的任何一个配置失误都会拖累其他环节。DNS的TTL直接影响CDN切流的效率。早期某次我临时调低TTL准备切换CDN厂商结果忘了源站那边DNS记录仍指向老厂商流量被调度到了即将下线的节点上等TTL彻底生效已经是半小时以后期间的访问全走了旧链路。现在凡是涉及CDN切换我都会提前24小时把所有解析记录的TTL调成60秒切换完成后观察一天再调回正常值这个习惯救了我很多次。协议层的TLS证书也和CDN强相关。CDN边缘节点承接用户的大部分TLS握手后证书实际上是CDN厂商签发的回源时若源站证书链不完整会引发边缘节点到源站的握手失败。表面上看用户访问是正常的但源站日志里充满了TLS报警记录。启用CDN前一定要检查证书链完整性用openssl s_client去看看回源链路能不能建立完整信任链。4.3 物联网设备IP直连还是DNS解析物联网场景选择IP直连还是DNS解析是个现实问题。IP直连最大的优势是省去DNS解析耗时和依赖设备固件里写死IP控制逻辑简单但升级和迁移时非常痛苦——一旦服务器IP变了所有设备必须OTA更新固件。我的建议分场景而论大规模消费级设备智能家居、可穿戴必须用DNS域名。设备厂商希望灵活迁移机房、切换线路IP直连会把这些都锁死。好在设备数量大本身就是天然的分布式场景加一层域名解析带来的延迟微不足道。小型私有化项目园区网关、工厂设备设备数量少、网络环境可控用IP直连更省事。安全性要求高的设备不管是域名还是IP都要做双向认证。推荐使用证书或预置密钥绑定域名防止中间人伪造解析结果。只用DNS不校验证书容易被劫持到假服务器上造成数据泄露。生产环境的物联网设备上电后要尽快联网DNS解析失败会导致设备“假死”几分钟。我建议在设备固件里内置至少两个不同厂商的DNS地址并且对DNS响应做超时兜底超过2秒就走备用通道。5. 常见问题速查表与我的排障习惯5.1 高频问题速查表整理了一份我日常排障高频使用的对照表直接按表排查能省不少时间。问题现象常见原因优先排查方向网页时而打开时而不行CDN边缘节点回源失败检查回源协议、源站防火墙是否放行CDN IP段nslookup有解析浏览器打不开Chrome内置DNS缓存或DoH配置异常关闭“安全DNS”后重试重启浏览器进程Linux改完DNS重启又还原systemd-resolved或DHCP client覆盖修改/resolved.conf确认DHCP supersede配置域名切换CDN后部分地域仍是旧IP本地或递归DNS缓存未过期提前调低TTL切换后用dig按地域验证接口慢但带宽和CPU都不高TCP重传率异常或TLS握手RTT过高抓包看重传测试TLS握手时间访问返回499大量客户端主动断开/代理超时检查业务处理耗时区分是网络问题还是代码问题企业微信号签名失败JS-SDK版本过旧升级到不低于2.3.2的版本并锁版本号5.2 我的排障工具与习惯排障工具的底牌其实就三个dig、curl、tcpdump但不同场景用法有讲究。DNS类问题用dig trace example.com看递归完整过程比单纯nslookup多看到一步“哪层出了异常”。再配合dig 223.5.5.5 example.com对比不同递归服务器的解析结果如果结果不一致基本就是DNS劫持或缓存污染需要换可信DNS或启用DoH。HTTP类问题用curl -w看耗时拆解把dns_time、connect_time、starttransfer_time分开看。一条命令就能定位延迟是发生在DNS解析、TCP连接还是内容传输阶段不用盲猜curl -o /dev/null -s -w DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s 首字节:%{time_starttransfer}s 总耗时:%{time_total}s\n https://example.com网络层问题tcpdump -i eth0 host 目标IP and port 443抓包看TCP握手次数和重传标志配合ss -s看系统连接状态统计。要注意抓包是生产环境的“手术刀”高峰期慎用可以先看监控指标缩小范围再抓包。我的排障习惯总结起来就一句话先分层定位再动手操作。从物理链路到应用层逐步过滤确认层级之后再用对应工具深挖而不是上来就重启、刷新缓存、改配置——大多数“拍脑袋式”操作只会掩盖问题让故障在几个小时后换个方式重新冒出来。这套方法论在协议、DNS、CDN的问题上都一致适用养成了这个习惯排障效率至少翻一倍而且处理完的问题不容易复发。