应用层协议很多，HTTP、WebSocket、SMTP、POP3/IMAP、FTP、Telnet、SSH、RTP、DNS 这些名字也经常一起出现。
这些协议不需要每一个都学到实现细节，但如果只记协议名，很容易在“用途、底层传输协议、典型场景”这几个点上混在一起。
这篇文章主要回答几个问题：
HTTP、WebSocket、SMTP、FTP、SSH、DNS 等协议分别解决什么问题？
这些协议通常基于 TCP 还是 UDP，常见端口和使用场景是什么？
哪些协议最容易混淆，面试和实践中应该怎么区分？
HTTP：超文本传输协议
超文本传输协议（HTTP，HyperText Transfer Protocol） 是一种用于传输超文本和多媒体内容的应用层协议，最常见的使用场景就是 Web 浏览器与 Web 服务器之间的通信。
当我们在浏览器里访问一个网页时，浏览器会向服务器发送 HTTP 请求，服务器处理后返回 HTTP 响应。页面中的 HTML、CSS、JavaScript、图片、视频等资源，很多都是通过 HTTP 加载的。
HTTP 使用客户端-服务器模型，客户端发送 HTTP Request（请求），服务器返回 HTTP Response（响应），整个过程如下图所示。
需要注意的是，HTTP 是应用层协议，它本身不直接负责可靠传输。不同版本的 HTTP 底层依赖也不完全一样：
HTTP/1.1：基于 TCP。
HTTP/2：通常也基于 TCP，但引入了多路复用、头部压缩等能力。
HTTP/3：基于 QUIC，而 QUIC 基于 UDP，主要用于降低连接建立开销，并缓解 TCP 队头阻塞带来的影响。
在 HTTP/1.1 中，默认开启 Keep-Alive，也就是长连接。这样同一个 TCP 连接可以被多个 HTTP 请求复用，避免每次请求都重新建立 TCP 连接，从而减少三次握手带来的开销。
从连接复用角度看，HTTP/1.1 的 Keep-Alive 解决的是“同一个 TCP 连接复用多个请求”的问题，但同一连接上的请求处理仍然可能受到队头阻塞影响。
HTTP/2 在一个 TCP 连接上引入多路复用，可以并行传输多个请求和响应，减少了 HTTP 层面的队头阻塞。但由于底层仍然是 TCP，一旦某个 TCP 包丢失，整个连接上的数据仍然会受影响。
HTTP/3 基于 QUIC，QUIC 在 UDP 之上实现多路复用和可靠传输。不同流之间相互独立，可以缓解 TCP 层队头阻塞问题。
另外，HTTP 是一种无状态协议。服务端不会天然记住“上一次请求是谁发的、处于什么状态”。因此，在实际 Web 开发中，通常需要借助 Cookie、Session、Token（包括 JWT）等机制来维护用户登录态和会话状态。
WebSocket：全双工通信协议
WebSocket 是一种基于 TCP 连接的全双工通信协议，客户端和服务器可以在同一条连接上同时发送和接收数据。
它的典型特点是：连接建立后，服务端也可以主动向客户端推送消息。这正好弥补了传统 HTTP 请求-响应模型在实时通信场景下的不足。
WebSocket 协议在 2008 年诞生，2011 年成为国际标准，现代主流浏览器基本都已经支持。WebSocket 不只用于浏览器场景，很多编程语言、框架和服务器也都提供了对应支持。
WebSocket 本质上仍然是应用层协议。它通常先通过一次 HTTP 请求发起协议升级，升级成功后，客户端和服务端之间会建立一条持久连接，后续就可以进行双向数据传输。
WebSocket 的常见应用场景包括：
视频弹幕
实时消息推送，详见Web 实时消息推送详解
实时游戏对战
多用户协同编辑
在线客服 / 社交聊天
股票行情、体育比分等实时数据更新
WebSocket 的工作过程可以简单分为下面几步：
客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key 等字段，表示希望把当前连接升级为 WebSocket。
Upgrade: websocketConnection: UpgradeSec-WebSocket-Key服务器收到请求后，如果支持 WebSocket，会返回 HTTP 101 Switching Protocols 状态码，响应头中包含 Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Accept 等字段，表示协议升级成功。
101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept协议升级后，客户端和服务器之间就建立了一条 WebSocket 连接，双方可以进行双向通信。
WebSocket 数据以帧（Frame）的形式传输。一条完整消息可能会被拆分成多个帧发送，接收端再重新组装成完整消息。
客户端或服务器都可以主动发送关闭帧，另一方收到后也会回复关闭帧，然后双方关闭 TCP 连接。
另外，WebSocket 连接通常会配合心跳机制使用。比如定期发送 Ping/Pong 帧，或者在业务层发送心跳包，用来检测连接是否仍然可用，避免连接假死。
SMTP：简单邮件传输协议
简单邮件传输协议（SMTP，Simple Mail Transfer Protocol） 是一种基于 TCP 的应用层协议，主要用于发送和转发电子邮件。
这里要注意一个容易混淆的点：
SMTP 负责邮件发送和邮件服务器之间的转发；POP3/IMAP 负责用户从邮箱服务器收取邮件。
也就是说，邮件从你的邮箱服务器发送到对方邮箱服务器，这个过程通常还是 SMTP；而用户使用客户端查看邮箱里的邮件，通常使用 POP3 或 IMAP。
常见 SMTP 相关端口有 25、465、587，三者用途不完全一样：
端口常见用途说明25邮件服务器之间转发邮件主要用于 MTA 到 MTA 的投递，很多云厂商或 ISP 会限制 25 端口出站，防止垃圾邮件587客户端提交邮件标准的 Message Submission 端口，通常配合 STARTTLS 和身份认证使用465隐式 TLS 的邮件提交客户端连接时直接建立 TLS 加密通道，很多邮件服务商仍然支持
端口常见用途说明
端口
常见用途
说明
25邮件服务器之间转发邮件主要用于 MTA 到 MTA 的投递，很多云厂商或 ISP 会限制 25 端口出站，防止垃圾邮件
25
邮件服务器之间转发邮件
主要用于 MTA 到 MTA 的投递，很多云厂商或 ISP 会限制 25 端口出站，防止垃圾邮件
587客户端提交邮件标准的 Message Submission 端口，通常配合 STARTTLS 和身份认证使用
587
客户端提交邮件
标准的 Message Submission 端口，通常配合 STARTTLS 和身份认证使用
465隐式 TLS 的邮件提交客户端连接时直接建立 TLS 加密通道，很多邮件服务商仍然支持
465
隐式 TLS 的邮件提交
客户端连接时直接建立 TLS 加密通道，很多邮件服务商仍然支持
电子邮件的发送过程
比如我的邮箱是 <dabai@cszhinan.com>，我要向 <xiaoma@qq.com> 发送邮件，整个过程可以简单理解为：
<dabai@cszhinan.com><xiaoma@qq.com>我通过邮箱客户端或网页邮箱写好邮件。
邮件客户端通过 SMTP 协议，把邮件提交给 cszhinan.com 对应的邮件服务器。
cszhinan.com发送方邮件服务器根据收件人域名 qq.com 查询对应的邮件服务器地址。
qq.com发送方邮件服务器再通过 SMTP，把邮件投递到 QQ 邮箱服务器。
QQ 邮箱服务器接收邮件并保存。
用户 <xiaoma@qq.com> 通过 POP3 或 IMAP 协议从 QQ 邮箱服务器读取邮件。
<xiaoma@qq.com>如何判断邮箱是否真正存在？
一些场景下，我们可能需要判断某个邮箱地址是否真实存在。常见思路是基于 SMTP 做探测：
查询邮箱域名对应的 MX 记录，找到邮件服务器。
尝试连接目标邮件服务器。
使用 SMTP 命令模拟投递流程。
根据服务器返回结果判断邮箱地址是否可能存在。
不过，这种方式并不总是可靠。
很多邮件服务商为了防止垃圾邮件、撞库和隐私泄露，会屏蔽邮箱存在性探测，或者统一返回模糊结果。因此，SMTP 探测只能作为参考，不能 100% 判断邮箱一定存在或不存在。
推荐几个在线邮箱有效性检测工具：
https://verify-email.org/
http://tool.chacuo.net/mailverify
http://tool.chacuo.net/mailverify
https://www.emailcamel.com/
POP3/IMAP：邮件接收协议
POP3 和 IMAP 都是用于接收邮件的协议，二者也都是基于 TCP 的应用层协议。
需要注意的是：SMTP 主要负责邮件发送和转发，POP3/IMAP 主要负责用户从邮箱服务器读取邮件。
POP3 的设计比较简单，常见模式是把邮件从服务器下载到本地。它适合单设备收信，但多设备同步体验较差。
IMAP 是更现代、更常用的邮件接收协议。它支持在服务器端管理邮件，能够同步邮件状态，比如已读、未读、删除、归档、文件夹分类等。因此，如果你同时在手机、电脑、网页端查看同一个邮箱，IMAP 的体验通常会更好。
简单对比一下：
协议主要用途特点POP3接收邮件偏下载到本地，多设备同步能力弱IMAP接收和管理邮件支持多设备同步、搜索、标记、归档SMTP发送和转发邮件负责邮件投递链路
协议主要用途特点
协议
主要用途
特点
POP3接收邮件偏下载到本地，多设备同步能力弱
POP3
接收邮件
偏下载到本地，多设备同步能力弱
IMAP接收和管理邮件支持多设备同步、搜索、标记、归档
IMAP
接收和管理邮件
支持多设备同步、搜索、标记、归档
SMTP发送和转发邮件负责邮件投递链路
SMTP
发送和转发邮件
负责邮件投递链路
FTP：文件传输协议
FTP（File Transfer Protocol，文件传输协议） 是一种基于 TCP 的应用层协议，用于在客户端和服务器之间传输文件。
FTP 采用客户端-服务器模型。它比较特殊的一点是：FTP 通常会建立两条 TCP 连接。
FTP 与很多应用层协议不同，它在客户端和服务器之间使用两条连接：控制连接：用于传输命令和响应，例如登录、切换目录、删除文件等。数据连接：用于真正传输文件内容或目录列表。
FTP 与很多应用层协议不同，它在客户端和服务器之间使用两条连接：
控制连接：用于传输命令和响应，例如登录、切换目录、删除文件等。
数据连接：用于真正传输文件内容或目录列表。
这种将命令和数据分开传输的设计，能够让控制命令和文件数据互不干扰。
FTP 有主动模式（PORT）和被动模式（PASV）两种数据连接方式：
主动模式：客户端通过控制连接告诉服务端自己监听的端口，服务端再主动连接客户端的这个端口建立数据连接。由于服务端要主动连接客户端，如果客户端在 NAT 或防火墙后面，很容易连接失败。
被动模式：客户端请求服务端开放一个数据端口，然后由客户端主动连接服务端的数据端口。因为连接方向仍然是客户端到服务端，更容易穿过 NAT 和防火墙，所以实际生产环境中更常用被动模式。
注意：FTP 本身是不安全的。它默认不会加密传输内容，用户名、密码和文件数据都可能被窃听或篡改。
因此，传输敏感文件时不建议使用普通 FTP，可以选择：
SFTP：基于 SSH 的安全文件传输协议。
FTPS：在 FTP 基础上增加 TLS/SSL 加密。
其中，SFTP 和 FTPS 名字相似，但不是同一个协议。SFTP 基于 SSH，FTPS 是 FTP over TLS。
Telnet：远程登录协议
Telnet 是一种基于 TCP 的远程登录协议，默认端口是 23。它允许用户通过终端远程登录到服务器，并在远程机器上执行命令。
Telnet 最大的问题是：明文传输。
用户名、密码、命令内容和返回结果都不会加密，攻击者如果能监听网络流量，就可能直接看到敏感信息。
因此，Telnet 现在已经很少用于真正的远程管理。实际生产环境中，通常使用 SSH 替代 Telnet。
SSH：安全的网络传输协议
SSH（Secure Shell） 是一种基于 TCP 的安全网络协议，默认端口是 22。它通过加密和认证机制，为远程登录、命令执行和文件传输提供安全保障。
SSH 最经典的用途是登录远程服务器：
ssh user@server_ipssh user@server_ip除了远程登录，SSH 还支持：
远程执行命令
端口转发
隧道代理
X11 转发
基于 SFTP 或 SCP 的安全文件传输
SSH 使用客户端-服务器模型。SSH Server 监听客户端连接请求，SSH Client 发起连接。双方会先协商加密算法，并通过密钥交换生成后续通信使用的对称加密密钥。之后的通信内容都会被加密传输。
需要注意的是，SSH 的安全性不仅来自加密传输，也来自身份认证机制。常见认证方式包括：
密码认证
公钥认证
多因素认证
实际生产环境中，更推荐使用公钥认证，并关闭弱密码登录。
RTP：实时传输协议
RTP（Real-time Transport Protocol，实时传输协议） 是一种用于传输音频、视频等实时数据的协议。它通常运行在 UDP 之上。在 TCP/IP 分层模型中，UDP 之上就是应用层，所以 RTP 按分层规则被归入应用层。但它承担的职责（序列号、时间戳、同步、质量反馈）更接近传输层功能，RFC 3550 也说它“通常会集成到应用处理中，而不是作为独立层实现”。
RTP 主要用在语音通话、视频会议、直播等实时场景。它本身不保证可靠传输，也不保证按时到达，而是通过序列号、时间戳等信息帮助接收端进行排序、同步和播放控制。虽然也存在 RTP over TCP 的封装方式（如 RFC 4571），但更多用于穿越防火墙或兼容特定协议栈等特殊场景，实际实时音视频场景中 RTP 仍以 UDP 为主。
RTP 通常会和 RTCP 配合使用：
RTP：负责传输实时音视频数据。
RTCP（RTP Control Protocol）：负责传输控制信息和统计信息，比如丢包率、延迟、抖动等。
在 WebRTC 中，RTP/RTCP 是实时音视频传输的重要基础。WebRTC 还会结合 SRTP 加密、拥塞控制、抖动缓冲、NACK、FEC 等机制，提升实时通信的安全性和质量。
需要注意的是，RTP 本身不负责资源预留，也不保证实时传输质量。它提供的是实时媒体传输的基础能力，具体的质量控制需要依赖上层机制配合完成。
DNS：域名系统
DNS（Domain Name System，域名系统） 用于解决域名和 IP 地址之间的映射问题。
我们访问网站时，通常输入的是域名，例如：
www.javaguide.cnwww.javaguide.cn但网络通信实际需要的是 IP 地址。DNS 的作用就是把域名解析成对应的 IP 地址。
DNS 通常使用 UDP，默认端口是 53。之所以优先使用 UDP，是因为大多数 DNS 查询和响应都比较小，不需要 TCP 三次握手，响应更快。
在早期 DNS 规范中，UDP DNS 消息大小限制为 512 字节（不包含 IP 和 UDP 头）。如果响应过大，服务器会设置截断标志，客户端再通过 TCP 重试。
后来 EDNS0 扩展了 DNS over UDP 的报文大小上限，使 DNS 能承载更大的响应，比如 DNSSEC 相关数据。但如果响应超过协商的 UDP 大小，或者发生区域传送（DNS 服务器之间同步整域数据，普通域名解析几乎不会触发），仍然会使用 TCP。
现代网络中还出现了更安全的 DNS 方案，比如：
DoH（DNS over HTTPS）
DoT（DNS over TLS）
它们的目的都是减少 DNS 明文查询带来的隐私和安全问题。
常见应用层协议端口总结
协议默认端口传输层协议主要用途HTTP80TCPWeb 页面访问HTTPS443TCP / QUIC加密 Web 访问WebSocket80 / 443TCP双向实时通信SMTP25 / 465 / 587TCP邮件发送和转发POP3110 / 995TCP邮件接收IMAP143 / 993TCP邮件接收和同步FTP20 / 21TCP文件传输SSH22TCP安全远程登录和文件传输Telnet23TCP明文远程登录DNS53UDP / TCP域名解析RTP动态端口（偶数），RTCP 用相邻奇数UDP 为主实时音视频传输
协议默认端口传输层协议主要用途
协议
默认端口
传输层协议
主要用途
HTTP80TCPWeb 页面访问
HTTP
80
TCP
Web 页面访问
HTTPS443TCP / QUIC加密 Web 访问
HTTPS
443
TCP / QUIC
加密 Web 访问
WebSocket80 / 443TCP双向实时通信
WebSocket
80 / 443
TCP
双向实时通信
SMTP25 / 465 / 587TCP邮件发送和转发
SMTP
25 / 465 / 587
TCP
邮件发送和转发
POP3110 / 995TCP邮件接收
POP3
110 / 995
TCP
邮件接收
IMAP143 / 993TCP邮件接收和同步
IMAP
143 / 993
TCP
邮件接收和同步
FTP20 / 21TCP文件传输
FTP
20 / 21
TCP
文件传输
SSH22TCP安全远程登录和文件传输
SSH
22
TCP
安全远程登录和文件传输
Telnet23TCP明文远程登录
Telnet
23
TCP
明文远程登录
DNS53UDP / TCP域名解析
DNS
53
UDP / TCP
域名解析
RTP动态端口（偶数），RTCP 用相邻奇数UDP 为主实时音视频传输
RTP
动态端口（偶数），RTCP 用相邻奇数
UDP 为主
实时音视频传输
这里 HTTPS 写成 TCP / QUIC，是因为传统 HTTPS 通常基于 TLS over TCP，而 HTTP/3 场景下会基于 QUIC。
小结
这篇文章只做了常见应用层协议的快速梳理，没有展开到协议报文和具体实现细节。
复习时可以重点记住几个容易混淆的点：
HTTP 是应用层协议，HTTP/1.1 和 HTTP/2 通常基于 TCP，HTTP/3 基于 QUIC。
HTTP/1.1 通过 Keep-Alive 复用 TCP 连接，HTTP/2 在一个 TCP 连接上做多路复用，HTTP/3 基于 QUIC 缓解 TCP 队头阻塞。
WebSocket 通过 HTTP 升级建立连接，之后支持双向通信。
SMTP 负责邮件发送和服务器间转发，POP3/IMAP 负责用户收取邮件。
SMTP 常见端口包括 25、587、465，分别对应服务器间转发、客户端提交和隐式 TLS 提交等场景。
FTP 有主动模式和被动模式，实际生产环境中被动模式更常见。
FTP、SFTP、FTPS 不是一回事，FTP 明文传输，SFTP 基于 SSH，FTPS 基于 TLS。
Telnet 明文传输，不适合生产环境远程管理，实际更常用 SSH。
DNS 通常基于 UDP，但响应过大、发生截断、区域传送等场景下也会使用 TCP。
RTP 运行在 UDP 之上，按分层规则归入应用层，但职责更接近传输层；RTP 用偶数端口，配套 RTCP 用相邻奇数端口。
参考
《计算机网络：自顶向下方法》（第七版）
RTP 协议介绍：https://mthli.xyz/rtp-introduction/
https://mthli.xyz/rtp-introduction/
RFC 6455：The WebSocket Protocol
RFC 9110：HTTP Semantics
RFC 8446：TLS 1.3
RFC 9000：QUIC
RFC 3550：RTP: A Transport Protocol for Real-Time Applications
RFC 4571：Framing Real-time Transport Protocol（RTP） and RTP Control Protocol（RTCP） Packets over Connection-Oriented Transport
RFC 6891：Extension Mechanisms for DNS (EDNS(0))
写在最后
如果内容对你有帮助的话，欢迎顺手给 JavaGuide 点一个免费的 Star 支持一下：GitHub | Gitee。
JavaGuide 已持续维护近七年，累计 6100+ 次提交，来自 620+ 位贡献者共同完善。你的 Star、反馈和 PR，都是这个项目继续更新的动力。
如果你正在准备后端/AI 应用开发面试，也可以了解一下我的知识星球，里面包括后端和 AI 实战项目、简历优化、一对一提问和高频考点资料，已经持续维护六年。