题目给出的条件很短

> 如果在网络入口处封锁了 `TCP` 和 `UDP` 端口 `21`、`23` 和 `25`，下面哪种应用可以访问该网络
> A．`FTP`
> B．`DNS`
> C．`SMTP`
> D．`Telnet`

这道题的正确答案是

**B．`DNS`**

判断依据并不复杂。`FTP` 的标准控制连接使用 `TCP 21`，`Telnet` 使用 `TCP 23`，`SMTP` 的标准邮件服务器监听 `TCP 25`，而传统 `DNS` 服务使用的是端口 `53`。题目封锁的是 `21`、`23`、`25`，并没有封锁 `53`，因此四个选项中只有 `DNS` 对应的标准服务端口没有落入封锁范围。

这不是单纯依靠教材里的端口表得出的结论。`IANA` 当前的 Service Name and Transport Protocol Port Number Registry 中，`FTP` 控制服务登记在 `21`，`Telnet` 登记在 `23`，`SMTP` 登记在 `25`，`domain` 也就是 `DNS` 登记在 `53`。

最适合考试时直接记住的对应关系可以压缩成下面这张表。

| 应用协议     | 标准服务端口 | 常见传输层协议     | 本题是否被封锁 |
| -------- | -----: | ----------- | ------- |
| `FTP`    |   `21` | `TCP`       | 是       |
| `DNS`    |   `53` | `UDP`、`TCP` | 否       |
| `SMTP`   |   `25` | `TCP`       | 是       |
| `Telnet` |   `23` | `TCP`       | 是       |

因此看到题干中的三个数字时，实际上已经可以完成匹配

`21 → FTP`

`23 → Telnet`

`25 → SMTP`

而

`53 → DNS`

没有出现在封锁名单中。

这里真正值得深入理解的地方，是所谓封锁一个端口究竟封锁了什么。

在 `TCP/IP` 网络中，一个应用程序并不是简单地依靠目标计算机的 `IP` 地址完成通信。`IP` 地址主要帮助网络把数据送到某一台主机，而端口号进一步告诉操作系统，数据应该交给这台主机中的哪个应用进程。

例如一台服务器地址为

```text
192.168.10.100
```

同一台服务器完全可能同时运行多种服务。

```text
192.168.10.100 TCP 21
192.168.10.100 TCP 23
192.168.10.100 TCP 25
192.168.10.100 UDP 53
192.168.10.100 TCP 53
```

虽然这些连接的目标 `IP` 地址相同，但操作系统看到目标端口不同，就能够把报文交给不同的服务器程序。

这也是端口号存在的重要原因之一。

可以把 `IP` 地址理解为一栋大楼的位置，把端口号理解为大楼内部不同业务窗口的编号。数据包到达大楼还不够，还必须知道应该送到哪个窗口。

因此防火墙完全可以制定这样的策略

```text
阻止 TCP 21
阻止 UDP 21

阻止 TCP 23
阻止 UDP 23

阻止 TCP 25
阻止 UDP 25
```

同时仍然允许

```text
UDP 53
TCP 53
```

这样一来，与 `21`、`23`、`25` 有关的流量被拒绝，而发往 `53` 的流量仍有机会正常通过。

`TCP` 报文头中明确存在 `Source Port` 和 `Destination Port` 两个 `16 bit` 字段，因此网络设备可以根据源端口和目标端口进行过滤。现代 `TCP` 规范 `RFC 9293` 仍然定义了这两个字段。

`UDP` 同样具有源端口和目标端口。`RFC 768` 定义的 `UDP Header` 中就包含 `Source Port` 与 `Destination Port`，所以防火墙不仅能够封锁某个 `TCP` 端口，也能够独立封锁相同号码的 `UDP` 端口。

这里也就能够解释题目为什么故意写成封锁 `TCP` 和 `UDP` 端口 `21`、`23`、`25`。

很多初学者会产生一种错误直觉，认为端口 `21` 本身天然属于 `TCP`，端口 `53` 本身天然属于 `UDP`。

实际上并不是这样。

端口号和传输层协议需要组合起来理解。

`TCP 53` 和 `UDP 53` 是两个不同的传输层通信入口。

同理，从协议栈和防火墙规则的角度看，`TCP 21` 和 `UDP 21` 也是两个不同的匹配对象。

因此一条防火墙规则写成

```text
deny tcp destination-port 21
```

并不会自动等价于

```text
deny udp destination-port 21
```

如果管理员希望两类报文都受到限制，就需要同时覆盖相应的传输层协议，或者采用能够同时匹配两类协议的策略表达方式。

回到本题，这一点尤其重要，因为 `DNS` 正是一个同时可能使用 `UDP` 和 `TCP` 的经典应用层协议。

很多教材为了帮助记忆，往往写成

```text
DNS
UDP 53
```

这种写法作为入门记忆并没有太大问题，但严格来说并不完整。

早期核心 `DNS` 规范 `RFC 1035` 已经明确规定，`DNS` 可以通过 `UDP 53` 工作，也可以通过 `TCP 53` 工作。该规范明确描述标准查询通常使用 `UDP`，而使用 `TCP` 时服务器端同样使用端口 `53`。

后来随着 `DNSSEC`、更大的响应报文以及现代网络需求出现，`TCP` 在 `DNS` 中的重要性进一步提高。`RFC 7766` 明确要求通用 `DNS` 实现同时支持 `UDP` 和 `TCP`，并特别指出阻断 `TCP 53` 可能导致名称解析失败或者应用层超时。

因此更加准确的知识应该记成

```text
DNS
UDP 53
TCP 53
```

正常的小型查询往往优先通过 `UDP 53` 完成，而在某些响应过大、需要可靠传输或者协议要求触发的场景中，可以使用 `TCP 53`。

本题恰好没有封锁 `53`。

所以无论从传统考试模型来看，还是从完整的现代 `DNS` 传输机制来看，`DNS` 都是四个选项中唯一没有因为 `21`、`23`、`25` 被直接阻断的协议。

再看 `FTP`。

`FTP` 很容易成为这道题里最具有迷惑性的选项，因为 `FTP` 并不是只建立一条网络连接。

经典 `FTP` 把控制连接和数据连接分开。

控制连接负责发送命令，例如登录、切换目录、请求下载文件等。

数据连接才负责真正传输目录列表或者文件内容。

`RFC 959` 对这一点定义得非常清楚。`FTP` 的控制连接通过 `TCP` 建立，服务器的标准服务端口是 `21`。规范还明确指出，在默认主动模式设计中，服务器的数据端口与控制端口相邻，也就是传统意义上的 `20`。

于是经典记忆通常写成

```text
FTP 控制连接
TCP 21

FTP 主动模式默认数据连接
TCP 20
```

这里会出现一个很典型的考试陷阱。

有人看到题目只封锁了 `21`，却没有封锁 `20`，可能会认为 `FTP` 的数据仍然可以传输，因此选择 `FTP`。

这个判断错在忽略了控制连接。

在正常 `FTP` 工作流程中，客户端需要先与服务器的 `TCP 21` 建立控制连接。登录使用什么用户名，进入哪个目录，下载哪个文件，使用主动模式还是被动模式，这些操作都依赖控制连接。

`RFC 959` 甚至明确要求，在数据传输期间控制连接需要保持打开。

因此 `TCP 21` 一旦被防火墙阻断，普通 `FTP` 会在最前面的控制连接阶段就失败。

即便 `TCP 20` 没有被封锁，也无法据此认定标准 `FTP` 服务可以正常访问。

在 Windows、Linux 或网络实验环境中，这一点很容易观察。使用传统 `FTP` 客户端连接一台监听标准端口的服务器时，客户端通常会尝试建立类似下面的连接关系。

```text
客户端随机端口 → 服务器 TCP 21
```

只要入口防火墙拒绝服务器侧的 `TCP 21`，三次握手就无法正常完成，后面的 `USER`、`PASS`、`LIST`、`RETR`、`STOR` 等 `FTP` 命令自然无从谈起。

因此选项 A 排除。

再看 `Telnet`。

`Telnet` 是经典的远程终端协议，标准服务器端口是 `TCP 23`。

`RFC 854` 对连接建立过程给出了明确说明，用户端使用某个客户端端口连接服务器的 well-known port，而远程终端访问所分配的服务器端口就是 `23`。

典型连接可以写成

```text
客户端临时 TCP 端口 → 服务器 TCP 23
```

例如客户端可能使用

```text
49180
```

作为临时源端口，于是一个连接在概念上可能表现为

```text
192.168.1.20 TCP 49180
        →
192.168.1.100 TCP 23
```

这里的 `49180` 并不是 `Telnet` 的标准服务端口，它只是客户端操作系统临时选择的源端口。

真正决定客户端想访问哪种服务器服务的，是目标服务器一侧的 `TCP 23`。

题目已经明确把 `23` 封锁，因此正常的标准端口 `Telnet` 连接无法通过入口过滤。

所以 D 排除。

再看 `SMTP`。

`SMTP` 是电子邮件体系中用于邮件传输的重要协议。传统服务器间邮件传输的标准端口是 `TCP 25`。

`RFC 5321` 对 `SMTP` 服务器的要求中明确提到，服务器应该保持对 `SMTP` 端口的监听，而 `IANA` 指定的这个端口就是 `25`，其处理对象是传入的 `TCP` 连接。

因此典型邮件服务器之间的连接可以抽象为

```text
邮件服务器 A 临时端口
        →
邮件服务器 B TCP 25
```

题目已经封锁 `TCP 25`，所以传统的 `SMTP 25` 连接会被防火墙规则命中。

于是 C 也排除。

到这里四个选项已经只剩下 B。

但还有一个经常引起困惑的问题。

题目写的是封锁了 `TCP` 和 `UDP` 的 `21`、`23`、`25`，而 `FTP`、`Telnet`、`SMTP` 在日常协议介绍中主要使用 `TCP`。既然如此，为什么题目还要专门写 `UDP`。

这里更适合从防火墙的视角理解。

网络设备并不会看到数字 `23` 就自动知道它一定是 `Telnet`。

防火墙实际看到的，是一组协议字段。

一个流量匹配条件可能包含

```text
协议 TCP
目标端口 23
```

也可能包含

```text
协议 UDP
目标端口 23
```

这两个规则并不是同一个规则。

`IANA` 的端口登记表甚至会分别按不同 Transport Protocol 展示相同端口号的登记情况。端口号码的意义必须和所处的传输层协议空间结合起来看。

因此题目写 `TCP` 和 `UDP` 都封锁，更像是在告诉我们，不需要讨论某个相同编号是否还可能借助另一种传输层协议绕过过滤。`21`、`23`、`25` 这三个号码在这里被全面排除。

但 `53` 完全没有被列入封锁范围。

这才是答案 B 最直接的逻辑基础。

说到网络入口处这个表述，还需要把源端口和目标端口区分开，否则后续做防火墙和访问控制列表题目时很容易继续混淆。

假定内部有一台 `DNS` 服务器

```text
10.0.0.53
```

外部客户端地址为

```text
203.0.113.10
```

客户端准备查询一个域名时，可能形成下面这样的 `UDP` 报文。

```text
源 IP
203.0.113.10

源端口
53021

目标 IP
10.0.0.53

目标端口
53

协议
UDP
```

这里客户端的 `53021` 是临时端口，服务器的 `53` 才是标准服务端口。

DNS 服务器返回响应时，方向会发生变化。

```text
源 IP
10.0.0.53

源端口
53

目标 IP
203.0.113.10

目标端口
53021

协议
UDP
```

可以看到，同一场通信中，端口并不会永远固定出现在源端口字段或者目标端口字段。

查询请求进入服务器时，`53` 通常表现为目标端口。

服务器回复客户端时，`53` 通常表现为源端口。

状态防火墙还会记录连接或会话状态，因此现实环境中的策略通常比教材里一句封锁某端口更加精细。

不过本题显然不是考查复杂的状态防火墙实现，而是在考查 well-known ports 与常见应用协议之间的对应关系。

从考试角度看，看到

```text
封锁 21
```

应该立刻关联到

```text
FTP
```

看到

```text
封锁 23
```

应该关联到

```text
Telnet
```

看到

```text
封锁 25
```

应该关联到

```text
SMTP
```

而看到 `DNS`，应该想到

```text
53
```

这样根本不需要在四个选项之间反复比较。

还有一个需要避免的误区，是把应用协议名称与某个固定端口绝对绑定。

在现实网络中，服务器程序完全可以修改监听端口。

一台 `FTP` 服务器理论上可以被管理员配置到 `2121`。

一台 `Telnet` 服务理论上也可以被放到其他 `TCP` 端口。

开发者编写自己的服务器程序时，更可以自由选择没有冲突并且满足系统权限要求的端口。

因此防火墙只封锁 `TCP 21`，并不能从理论上证明世界上所有采用 `FTP` 语义的通信都绝对不可能发生。

但是计算机网络考试问这种问题时，默认依据标准服务端口进行判断，而不是人为修改后的非标准端口。

否则绝大多数端口类选择题都会失去确定答案。

题目中的 `FTP` 就应理解为标准 `FTP` 服务，`Telnet` 理解为标准 `Telnet` 服务，`SMTP` 理解为标准邮件传输服务，`DNS` 理解为标准 `DNS` 服务。

按照这个考试语境，答案就是唯一的。

再从协议栈角度梳理一遍，会更容易建立长期记忆。

`FTP`、`DNS`、`SMTP` 和 `Telnet` 都属于应用层协议。

它们自己并不负责在不同主机之间完成底层分组转发，而是依赖传输层。

经典 `FTP` 依赖 `TCP`。

经典 `Telnet` 依赖 `TCP`。

标准 `SMTP` 邮件传输依赖 `TCP`。

`DNS` 则同时使用 `UDP` 和 `TCP`。

传输层下面还有网络层 `IP`。

因此一条典型的 `DNS` 查询可以理解成这样的协议封装关系。

```text
DNS 数据
↓
UDP
↓
IP
↓
Ethernet 或其他链路层协议
```

另一些 `DNS` 通信则可能表现为

```text
DNS 数据
↓
TCP
↓
IP
↓
Ethernet 或其他链路层协议
```

而 `Telnet` 通常是

```text
Telnet
↓
TCP
↓
IP
↓
链路层
```

防火墙检查 `TCP` 或 `UDP` 端口时，主要是在传输层字段上进行策略匹配。

所以这道题表面在问应用层协议，实际把应用层和传输层联系到了一起。

这也是端口题最重要的学习方法。

不能只记

```text
21 FTP
23 Telnet
25 SMTP
53 DNS
```

还要脑中形成完整关系

```text
应用层协议
↓
选择传输层协议
↓
使用服务器端标准端口
↓
防火墙检查协议号和端口
↓
决定允许还是拒绝
```

按照这一条链路再走一遍本题。

外部主机尝试访问标准 `FTP` 服务。

数据包到达网络入口，目标服务是 `TCP 21`。

过滤规则中存在对 `TCP 21` 的封锁。

流量被拒绝。

外部主机尝试访问标准 `Telnet` 服务。

目标服务是 `TCP 23`。

过滤规则封锁 `TCP 23`。

流量被拒绝。

外部邮件服务器尝试通过标准 `SMTP` 连接访问邮件服务。

目标服务是 `TCP 25`。

过滤规则封锁 `TCP 25`。

流量被拒绝。

外部主机向标准 `DNS` 服务发送普通查询。

目标服务通常是 `UDP 53`。

过滤规则中没有 `UDP 53`。

从题目给出的条件看，这个通信不会因为 `21`、`23`、`25` 的规则而被阻止。

即使某次 `DNS` 解析需要切换到 `TCP 53`，题目也没有封锁 `TCP 53`。

因此仍然符合 B。

这道题还有一个非常实用的记忆技巧，可以把几个端口按早期互联网服务的发展顺序连成一小段。

```text
20 FTP Data
21 FTP
22 SSH
23 Telnet
25 SMTP

53 DNS
```

其中 `20` 到 `25` 附近聚集了多个非常经典的远程访问、文件传输和邮件服务。

`22` 是现在运维工作中非常常见的 `SSH`。

它刚好夹在 `FTP 21` 和 `Telnet 23` 中间。

因此可以记成

```text
21 FTP
22 SSH
23 Telnet
```

这是一个连续的三连号。

邮件再跳到

```text
25 SMTP
```

域名解析则单独记

```text
53 DNS
```

这样遇到类似题目时，识别速度会非常快。

例如题目未来改成

```text
封锁 TCP 21、22、23
```

那么标准 `FTP`、`SSH`、`Telnet` 都会受到影响。

如果题目改成

```text
封锁 UDP 53 和 TCP 53
```

那才是在传统 `DNS` 传输层入口上进行了全面阻断。现代 `RFC 7766` 要求通用 `DNS` 实现支持两种传输方式，因此只开放 `UDP 53` 而长期封锁 `TCP 53` 并不是完整、稳妥的 `DNS` 网络策略。

如果题目改成

```text
只封锁 TCP 25
```

那么主要受影响的是标准 `SMTP` 的 `TCP 25` 服务，而不能看到数字 `25` 就认为整个电子邮件体系中的所有协议、所有端口都被封锁。

电子邮件体系本身还存在其他协议和端口，例如邮件客户端提交、邮件读取等场景使用的机制并不全部等于 `SMTP TCP 25`。

这也说明了一个很关键的考试原则。

题目写的是端口过滤，就按被过滤的具体传输层端口判断，不要把某个应用领域扩大成所有相关网络通信。

题目只封锁 `21`、`23`、`25`。

没有 `53`。

所以 `DNS` 仍然保留标准通信入口。

从工程上再看，这类规则实际上也体现了早期边界防火墙非常常见的一种访问控制方法，也就是依据五元组中的若干字段决定放行还是丢弃。

网络流经设备时，常见识别信息包括

```text
源 IP
目标 IP
源端口
目标端口
传输层协议
```

也就是常说的五元组。

假如某条规则对应

```text
协议 TCP
目标端口 23
动作拒绝
```

那么发往 `TCP 23` 的连接就会被拦截。

若另有

```text
协议 UDP
目标端口 23
动作拒绝
```

`UDP 23` 也会被拒绝。

与此同时

```text
协议 UDP
目标端口 53
```

并不匹配前面的 `23` 规则，因此在没有其他拒绝规则的前提下仍可能继续被允许。

从这个角度看，题目中的三个端口就像三个被关闭的入口。

```text
21 关闭
23 关闭
25 关闭
```

`DNS` 走的是另一个入口。

```text
53
```

那个入口没有出现在题目的封锁条件中。

因此它可以通过。

当然，真实生产网络中的判断还会受到默认策略、状态检测、应用识别、`NAT`、连接跟踪、区域策略以及更上层安全设备的影响。一台企业级防火墙也可能使用应用识别技术，不再仅仅依赖端口号判断协议。例如某种应用即便跑在非标准端口上，设备仍可能根据协议特征识别出来。

这些现实因素不改变本题答案，因为题目明确采用的是经典端口过滤模型。

从考试解题方法看，最稳妥的推理过程并不是背下答案 B，而是形成一个三步心算。

看到 `21`，想到 `FTP`。

看到 `23`，想到 `Telnet`。

看到 `25`，想到 `SMTP`。

剩下 `DNS` 对应 `53`。

所以答案为 B。

如果需要写成考试中的简答题答案，可以压缩成这一段。

`FTP` 的标准控制端口为 `TCP 21`，`Telnet` 的标准服务端口为 `TCP 23`，`SMTP` 的标准邮件传输端口为 `TCP 25`，这三个端口均处于题目给出的封锁范围。`DNS` 使用标准端口 `53`，普通查询通常使用 `UDP 53`，同时完整的 `DNS` 实现也支持 `TCP 53`。由于题目只封锁 `21`、`23`、`25`，没有封锁 `53`，所以 `DNS` 仍可以访问该网络，正确答案为 B。`RFC 1035` 和后续 `RFC 7766` 都确认了 `DNS` 对 `UDP` 与 `TCP 53` 的使用，而 `RFC 959`、`RFC 854`、`RFC 5321` 分别给出了 `FTP 21`、`Telnet 23`、`SMTP 25` 的标准协议依据。

因此这道题真正应该记住的，并不仅仅是一个 B，而是一整条网络通信逻辑。

应用程序通过端口找到目标进程，防火墙通过传输层协议和端口识别流量，`21` 对应标准 `FTP` 控制服务，`23` 对应标准 `Telnet`，`25` 对应标准 `SMTP`，`53` 对应标准 `DNS`。题目把前三个入口关掉，却留下了 `53`，于是四个选项中能够通过题目所给端口过滤条件的就是 `DNS`。

**最终答案，B．`DNS`。**


如果在网络入口处封锁了 TCP 和 UDP 端口 21、23 和 25，下面哪种应用可以访问该网络 A．FTP B．DNS C．SMTP D．Telnet

封锁 21、23、25 端口后谁还能通行，从 FTP、DNS、SMTP、Telnet 看懂端口过滤的真正逻辑

紫薇堂堂主

网络与通信

安全

运维

网络入口封锁TCP和UDP端口21、23、25，分别对应FTP控制连接、Telnet和SMTP标准服务，这些应用均受影响。DNS使用标准端口53，且未被封锁，普通查询经UDP53，亦可支持TCP53。因此，唯一可正常访问的应用是DNS，答案选B。

访问控制列表

边界防火墙

代码解释

文件传输

防火墙

服务器

Windows

Linux

热销域名限时优惠，新客首年免费！


domain

DNS解析新购特惠59元起，续费优惠低至5.3折！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

封锁 21、23、25 端口后谁还能通行，从 FTP、DNS、SMTP、Telnet 看懂端口过滤的真正逻辑-腾讯云开发者社区-腾讯云

封锁 21、23、25 端口后谁还能通行，从 FTP、DNS、SMTP、Telnet 看懂端口过滤的真正逻辑

封锁 21、23、25 端口后谁还能通行，从 FTP、DNS、SMTP、Telnet 看懂端口过滤的真正逻辑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐