你在浏览器里点开一个网页、发一条微信、传一个文件，背后跑的东西完全不是一回事。很多新手能说出「HTTP」，但被问到邮件、DNS、文件传输、视频通话分别用什么协议时就卡住了。这篇按服务类型分门别类，把常见互联网服务和对应协议做成一张能随手查的对照表，并给出一套自己判断协议归属的排查顺序。
你在浏览器里点开一个网页、发一条消息、传一个文件，背后跑的东西完全不是一回事。很多新手能说出「HTTP」，但被问到邮件、域名解析、文件传输、视频通话分别用什么协议时就卡住了。这篇按服务类型分门别类，把常见互联网服务和对应协议整理成一张能随手查的对照表，并给出一套自己判断协议归属的排查顺序。
先记住一句话：协议不是一个平面上的清单，而是分层的。同样叫「协议」，有的负责找地址，有的负责把字节从这头送到那头，有的只规定两头该怎么对话。搞混层次，后面所有判断都会乱。下面从最底层的「找路」开始，一层层往上捋。
先分清层次：协议不是一个平面上的清单
把协议想成寄快递：IP 相当于写清楚收件地址和分拣路线，TCP 相当于保证包裹按顺序、不丢件地送达，HTTP 相当于规定包裹里那张纸该用什么格式写。这三件事完全不在一个层面上，所以「HTTP 和 TCP 谁更快」这种问法本身就是错的。判断一个服务用什么协议，先问它在干哪一层的活。
- 寻址与转发
- 负责把数据送到正确的机器，回答「送到哪」
- 传输控制
- 负责把数据切成块、按顺序可靠送达，回答「怎么送」
- 应用层对话
- 规定两头该用什么格式和顺序交流，回答「说什么」
- 应用之上的约定
- 在应用层之上再定一层规范，比如工具之间的对接方式，回答「谁来调、怎么调」
关键动作是：看到一个服务，先别急着报协议名，先问它在干嘛。找地址、传字节、还是规定内容格式？答案定下来，协议归属基本就清晰了。一个服务往往同时踩好几层，比如看网页就是「应用层协议跑在传输层之上、再跑在网络层之上」，缺一层都跑不通。
找路这一类：DNS、DHCP、ARP 这些服务在干什么
这一类协议的共同点是：它们发生在你「还没开始正常通信」之前。把域名换成机器能识别的地址是域名解析的活；把你手写或记忆的地址换成网卡地址是地址解析的活；开机自动拿到网络配置是自动配置的活。它们出问题时的表现通常是「完全连不上」，而不是「连上了但很慢」。
- 先确认能不能连通目标地址直接用地址而不是域名去访问。能通说明链路和地址没问题，问题多半在解析环节。
- 再确认域名能不能解析把域名和对应地址对一下。解析拿不到结果，就先查本机配置的解析服务器是否可达。
- 最后确认自己有没有拿到网络配置看本机有没有有效地址和网关。拿不到就检查自动获取配置是否被关掉或冲突。
不适用的情况也要说清楚：如果只是某一个网站打不开、其他都正常，那通常不是这层的问题，而是对方服务端或链路中间的问题，别再往域名解析上使劲。
看网页、调接口：HTTP 与 HTTPS 到底管什么
浏览器打开页面、程序调用接口，绝大多数走的是 HTTP 或它的加密版本。两者差别不在于「是不是同一个协议」，而在于中间有没有加一层加密。方法和状态码、请求头、请求体这些属于 HTTP 层面的约定，跟底层地址、端口没有关系。
- 先看是不是「一次请求、一次响应」的模型，是的话基本就在 HTTP 系里
- 再看有没有加密层：地址栏、报错信息、抓包里的握手过程都能给线索
- 方法（GET、POST 这类）管的是「这次想干什么」，跟权限、安全不是一回事
- 状态码管的是「服务端怎么回你」，看到非成功码先去查服务端日志而不是改客户端
什么时候不适用：长连接推送、实时协作、持续双向通信这类场景，HTTP 也能硬做，但通常要换成更适合的通道，或者叠加别的机制。别拿「HTTP 也能实现」当成「HTTP 最合适」。
传文件、发邮件：FTP、SFTP、SMTP、POP3、IMAP 各自负责哪一段
传文件类协议关注的是「把一整块字节搬过去」，和看网页那种「一次请求一次响应」是两种思路。邮件更特殊：往外发是一套，往回收又是另一套，收发用的往往不是同一个协议。把这两类混在一起讲，新手最容易晕。
| 服务类型 | 在干什么 | 判断线索 |
|---|---|---|
| 文件传输 | 把整块文件从一端搬到另一端 | 关注断点续传、目录浏览、是否加密 |
| 邮件发送 | 把一封信交给对方服务器 | 关注发件方认证、投递失败原因 |
| 邮件收取 | 把信从服务器拉到本地 | 关注是否把信从服务器删掉 |
| 邮件同步 | 在多设备间保持状态一致 | 关注已读、文件夹、删除是否各端同步 |
这里最容易搞混的是「能收邮件」和「能同步邮件状态」。前者只保证你看到这封信，后者才保证你在手机上标了已读，电脑上也变成已读。选邮箱客户端或排查同步问题时，先分清你要的是哪一个，再决定用哪类协议。
看视频、语音通话：为什么它们不直接用 HTTP
直播、视频会议这类场景对延迟极其敏感，通常走专门为实时设计的传输方式，而不是普通网页请求。原因是普通请求强调完整和可靠，实时场景宁可丢一点也不能卡住等重传。选型前先分清你要的是点播还是直播。
| 场景 | 能不能接受缓冲 | 传输思路 |
|---|---|---|
| 点播 | 能，先缓冲几秒再播问题不大 | 偏可靠传输，完整性优先 |
| 直播 | 不能，延迟高就没人看 | 偏实时传输，延迟优先 |
| 语音通话 | 不能，卡顿比杂音更难受 | 实时传输，允许少量丢包 |
不适用的情况：如果只是偶尔传一个录播文件、给同事发个视频，用普通请求就够了，上实时协议只是徒增复杂度。判断标准很简单——用户能不能接受「等几秒再开始」。
远程登录与加密通道：SSH、VPN、代理各解决什么问题
远程登录关心的是「我拿到一台机器的命令行」；加密通道关心的是「我的流量从哪出去、有没有被人看见」。这两件事经常被混着说，但目标完全不同。再加一个代理，问题就从「控制一台机器」变成「控制这台机器的流量走哪条路」。
- 先问目标：是要操作某一台机器，还是让整台机器的流量都改道
- 再看范围：只对某个应用生效，还是全局生效
- 再看是否加密：流量路径变了不等于内容被保护，这是两件事
- 最后看权限边界：能登进去不等于能改配置，很多故障是权限不够导致的
遇到没见过的服务，怎么自己判断它用什么协议
碰到一个没见过的服务，别急着搜协议名，按下面的顺序走一遍，大多数情况能自己推出来。这套顺序的价值在于：即使结论不确定，你也能知道下一步该查什么。
- 看端口常见服务往往用约定俗成的端口号，但端口只是线索不是身份证，同一协议可以换端口跑。
- 看客户端提示抓包工具、浏览器开发者工具、程序日志里的协议字段都会直接告诉你正在用什么。
- 做排除先确认是不是 HTTP 系，不是再往传输层和专用协议方向找，逐层缩小范围。
- 查术语拿不准时到站内术语库对照，比凭印象猜靠谱，也能顺带搞清上下游概念。
想更系统地对照，可以到 /ai-dict 和 /ai-dict/category/infra 把相关术语过一遍。另外如果你在排查的是某个中转站或工具的实际表现，站内 /tools/speed-test 也能给你一组可复现的观测结果，比单凭感觉判断稳。
新手最容易搞混的四组概念
| 容易混的一对 | 区别在哪 | 怎么快速分 |
|---|---|---|
| 应用层协议与传输层协议 | 一个管怎么说话，一个管怎么送到 | 问它是在规定格式还是规定送达 |
| 端口与协议 | 同一个协议能换端口，同一端口也能跑不同服务 | 看端口只是参考，别当身份证 |
| 加密与协议 | 加了一层加密不等于换了个协议 | 看握手过程，不是看名字 |
| 实时与请求响应 | 模型不同，一个求快一个求全 | 问用户能不能接受等几秒 |
这四组搞清楚了，你再去看任何一份协议清单，都能自己判断哪些是同一层、哪些不是同一层。判断类的东西都有边界：如果你是在做线上故障排查，优先信日志和抓包，概念对照只用来帮你缩小怀疑范围。
下一步把这套「看端口 → 看客户端提示 → 做排除 → 查术语」的顺序用在下一个你没见过的服务上，同时到站内术语库和中转站检测页核对当时的实际数字和表现，比死记协议名有用得多。→常见问题
HTTP 和 HTTPS 是两个不同的协议吗？
可以理解成同一套对话规则的两个版本，区别在于中间有没有一层加密。对开发者来说，请求方法、状态码、请求头这些写法基本一致，主要差别在证书、端口和排查方式。判断一个接口是哪个，看地址前缀和端口通常就够了。
为什么有的服务用 UDP 有的用 TCP？
核心看能不能容忍丢一点数据。要求每个字节都不能少的场景，比如传文件、看网页，通常选能保证顺序和重传的那类；要求延迟低、丢一点也能继续的场景，比如语音和实时画面，往往选另一类。选型时先问「丢一帧会怎样」。
端口号和协议是一一对应的吗？
不是。端口只是约定了「敲门敲哪一间」，很多服务有习惯用法，但完全可以改到别的端口上跑。看到 8080 就跑的未必是网页服务，看到 443 也未必一定是加密网页。真正判断协议还是要看实际收发的内容。
我怎么知道自己电脑上的程序在用哪个协议？
最直接的办法是抓包或看连接列表，观察目标地址、端口和收发内容的形态。也可以从客户端本身入手，看它有没有提供设置代理、超时、重连这类选项，这些选项的名字往往就暴露了底层协议。别只看端口就下结论。
学这些协议对用 AI 接口有帮助吗？
有，但主要是排查用途。调用大模型接口本质上也是发一个请求等一个响应，超时、连接被拒、证书报错这些问题的定位思路和普通网络服务一样。先搞清自己卡在哪一层，再去查对应的报错，比直接怀疑模型有效得多。