Appearance
FTP 与 DHCP
2026 大纲 六（三）1 FTP 的工作原理、六（三）2 控制连接与数据连接；另承载 四（三）4 DHCP——大纲把它编排在「网络层 → IPv4」条目下，与 ARP、ICMP 列在一起；但那是大纲的目录归属，不是分层判定：DHCP 自身是应用层协议（报文由 UDP 67/68 承载），它分发的只是网络层配置参数。本篇按协议实际所在的层次收在应用层。
速查
FTP
| 要解决什么 | 减少或消除不同操作系统下处理文件的不兼容性——存储格式／目录结构与命名／命令／访问控制四类差异 |
| 🔴 属"复制整个文件"这一类 | 要存取就必须先获得一个本地副本，改完再整份传回；对照 NFS 那类联机访问只在网络上传送少量修改数据 |
| 服务器进程结构 | 主进程打开熟知端口 21 接活后立刻回到监听，从属进程（控制进程 + 数据传送进程）干活、完事即终止，两者并发进行 |
| 🔴 控制连接 21、数据连接 20 | 控制连接整个会话保持打开、只传命令与响应、不传文件；数据连接每次传送才建立、传完就关闭 |
| 🔴 主动／被动说的是服务器的姿态 | 判据是"数据连接的 SYN 由谁发"：主动（PORT）服务器从 20 端口连向客户；被动（PASV）服务器开一个随机端口等客户来连，能穿 NAT，实际更常用 |
| 🔴 列目录也要开数据连接 | LIST 与 RETR 同类（都要回传一批内容）；CWD、登录鉴别这类只交换命令应答的不开。故 |
| 带外控制的独有价值 | 控制信息不被数据阻塞——传输途中客户还能发"请求终止传输"；单连接时这条命令会排在没传完的文件数据后面 |
| FTP 有状态 | 服务器要维护当前目录、认证状态（对照 HTTP 无状态）；明文传输，SFTP/FTPS 是安全替代 |
DHCP
| 为什么不能出厂烧死 IP | IP 地址不仅包括主机号，还包括网络号——它指出这台计算机连在哪个网络上，出厂时无法知道。MAC 标识设备本身，IP 标识接入位置 |
| 要配的四项 | IP 地址、子网掩码、默认路由器的 IP 地址、域名服务器的 IP 地址 |
| 端口 67／68 | 服务器 67、客户 68，都是熟知端口。不用 TCP 有两条理由：客户此时连自己的 IP 都没有（TCP 四元组要源 IP）；需要广播而 TCP 不支持广播 |
| 第一个报文怎么发出去 | 源 IP 设为全 0 0.0.0.0、目的 IP 设为全 1 255.255.255.255；本地网络所有主机都收得到，但只有 DHCP 服务器才对它回答 |
| 🔴 Request 已经选定仍用广播 | 为的是让落选的服务器立刻把预留地址收回地址池；若用单播，它们只能干等到超时才敢回收 |
| 🔴 广播／单播要分两层看 | Discover 与 Request 在两层上都必须广播；Offer／ACK 常见组合是 IP 广播 + MAC 单播（用 Discover 带来的客户 MAC）。先分清问的是 IP 还是 MAC |
| 🔴 两个计时器都以租期起点为原点 | |
🔴 收到 DHCPNACK 要立即停用 | 这与"两次续租都超时"是两条不同的失败路径，不能等到租期届满 |
| 租用期 | 用 4 字节二进制表示、单位秒，范围 1 秒到 136 年；协议不规定取多长，由服务器决定，客户也可在报文里提出要求 |
| 🔴 中继代理不是 DHCP 服务器 | 它只把广播转成单播转发、等回答再发回主机，自己不分配地址、不维护地址池 |
第一部分：FTP 文件传送协议
一、两条连接的分工
图源：谢希仁《计算机网络》（第 8 版）「FTP 使用的两个 TCP 连接」，印刷 p270。图中椭圆表示进程；两条连接分别连着两对不同的进程——控制进程对控制进程、数据传送进程对数据传送进程，不是同一个进程开的两个 socket。
工作次序：客户向服务器的熟知端口 21 发出连接请求，同时告诉服务器自己的另一个端口号；服务器的控制进程据此创建数据传送进程和数据连接，用自己的熟知端口 20 与客户提供的端口建立数据连接；传送完毕后数据传送进程关闭数据连接并结束运行，而控制连接仍然保持。
为什么非要两条。 教材给的两条好处里，第一条（协议更简单：命令和数据不必在同一条字节流里混着走，就不需要转义或长度前缀来区分"这是命令还是文件内容"——对照组帧的透明传输问题，单连接必须解决它，双连接直接绕开）只是省事；真正独有的是第二条：传输文件时还可以利用控制连接对文件的传输进行控制。而两个不同的端口号保证了数据连接与控制连接不会发生混乱。
| 主动模式（PORT） | 被动模式（PASV） | |
|---|---|---|
| 数据连接发起方 | 服务器（从端口 20 连向客户指定的端口） | 客户 |
| 服务器端数据端口 | 20 | 服务器打开的一个随机端口，通过控制连接告知客户 |
| 谁把端口号告诉对方 | 客户告诉服务器自己的数据端口 | 服务器告诉客户自己的数据端口 |
| NAT／防火墙友好性 | 差——客户在 NAT 后面时服务器连不进来 | 好，实际中更常用 |
传输模式另有两种：ASCII 模式传文本文件、自动做换行符转换，二进制模式逐字节传输不做任何转换（图片、视频、压缩包用它）。
一次会话中的 TCP 连接数怎么数（想把"几条连接、最多几条并存"数到不出错时展开）
某用户登录 FTP 服务器后先执行 2 次 ls（列目录），再下载 3 个文件，最后退出。
第 1 步：控制连接。 整个会话期间只建立一次、一直保持到退出，共 1 条。
第 2 步：数据连接。 判据是"这次操作要不要通过网络回传一批内容"——LIST（列目录）回传的是目录列表、RETR（取文件）回传的是文件，两者同类，都要开数据连接；而 CWD（改变目录）、登录鉴别这类只交换命令与应答的操作不开。所以
容易漏掉列目录那 2 条。教材只写到"数据传送进程实际完成文件的传送"，没有细到命令一级，这条判据要自己补上。
第 3 步：合计与并发数。 总计
一般化：完成
反面参照：TFTP 为什么可以不要这两条连接（大纲外，只作对照，不必背细节）
TFTP（简单文件传送协议）也用客户服务器方式，但使用 UDP，因此需要有自己的差错改正措施。
| 对比项 | FTP | TFTP |
|---|---|---|
| 传输层 | TCP | UDP（熟知端口 69） |
| 连接数 | 两条（控制 + 数据） | 无连接 |
| 交互 | 支持（列目录、改目录、鉴别） | 不支持交互，无命令集、不能列目录、不能鉴别用户 |
| 可靠性 | 由 TCP 提供 | 自己实现，工作很像停止-等待协议 |
| 数据单元 | 字节流 | 每次 512 字节，最后一次可不足 512 |
TFTP 的可靠机制与停止-等待协议同构：发完一个文件块就等确认，确认时指明所确认的块编号（从 1 开始按序编号），超时未收到确认就重发。它的结束判据很巧妙：若文件长度不是 512 字节的整数倍，最后一个数据报文一定不满 512 字节，这本身就是结束标志；若文件长度恰好是 512 的整数倍，传完后还必须再发一个只含首部、无数据的报文，否则接收方无法判断结束。
它仍然存在的两个理由：可用于 UDP 环境（同时向许多机器下载时很有用）；代码所占内存小——无盘设备只要固化 TFTP + UDP + IP 的小容量只读存储器，通电后就能广播一个 TFTP 请求把可执行程序拉下来。
把两者对照着看，FTP 用两条 TCP 连接换来的正是 TFTP 缺的那些：交互、鉴别、目录操作、可靠传输不用自己写。
第二部分：DHCP 动态主机配置协议
二、DORA 四步
DHCP 提供的这套机制称为即插即用连网（plug-and-play networking）——主机接上网线就能自动拿到全部配置，不需要人工干预。
Offer 里有一处次序值得单独记：服务器先在其数据库中查找该计算机的配置信息，找到则返回找到的信息，找不到才从服务器的 IP 地址池中取一个地址分配给它——这正是"位置固定的服务器能拿到永久地址"的实现方式。Offer 的内容包括分配的 IP 地址、子网掩码、默认网关、DNS 服务器地址与租约期限。
三、租约机制
DHCP 分配的 IP 地址是临时的，可用时间称为租用期
| 时刻 | 事件 | 客户做什么 | 服务器可能的回应 |
|---|---|---|---|
| 租用期过半 | 向原服务器发 DHCPREQUEST 请求更新租用期 | 同意 → DHCPACK，得到新租用期并重设计时器；不同意 → DHCPNACK | |
收到 DHCPNACK | 被拒 | 必须立即停止使用原来的 IP 地址，回到第一步重新申请 | — |
| 原服务器一直不响应 | 重新发送 DHCPREQUEST，然后继续后面的步骤 | — | |
| 任意时刻 | 想提前退租 | 发送 DHCPRELEASE | — |
两个系数不是随手取的：
把租约时刻算成钟表时间（想确认自己没把 T2 当成叠加关系时展开）
某服务器把租用期设为 2 小时，客户在 09:00:00 收到 DHCPACK 并开始使用地址。
第 1 步：统一单位。
第 2 步：第一次续租。 DHCPREQUEST。
第 3 步：第二次续租。 DHCPREQUEST。注意
第 4 步：失效时刻。
另一条失败路径要分清：若服务器明确回了 DHCPNACK，客户必须立即停止使用原地址、马上重新申请，不能等到 11:00:00。
四、DHCP 中继代理
DHCP 用广播，而广播不能跨越路由器。解决方案不是每个子网都放一台服务器（数量太多），而是让每一个网络至少有一个中继代理，通常就是一台配置了 DHCP 服务器 IP 地址的路由器。
它把"广播 → 单播"这一步做了，正好抵消了"广播不能跨路由器"的限制。顺带一条封装上的提醒：DHCP 报文只是 UDP 用户数据报的数据，还要加上 UDP 首部、IP 数据报首部以及以太网 MAC 帧的首部和尾部，才能在链路上传送。
本节小结
- FTP 的两条连接分工固定：控制连接（21，整个会话保持，只传命令与响应，不传文件）+ 数据连接（20 或随机端口，每次传送建立、传完关闭）。带外控制真正独有的价值是控制信息不被数据阻塞——传输途中还能下"请求终止传输"。主动／被动看数据连接由谁发起；
次数据传送（含列目录）共需 条连接，任一时刻最多 2 条并存。 - DHCP 的存在理由是 IP 地址含网络号：它标识接入位置而非设备本身，出厂时无法确定，只能动态配置。它用 UDP 67/68，因为客户此时还没有 IP、且需要广播；第一个报文靠源 IP 全 0、目的 IP 全 1 发出去，只有 DHCP 服务器才回答。
- DORA 四步：Discover 广播找服务器 → Offer 先查数据库、查不到再从地址池取 → Request 仍用广播，为的是让落选服务器收回预留地址 → ACK 进入已绑定状态。租约两个计时器
、 均以租期起点为原点，收到 DHCPNACK要立即停用；跨子网靠中继代理把广播转成单播，它自己不分配地址。
教材出处
- 谢希仁《计算机网络》（第 8 版）印刷 p269，6.2.1 节：「FTP 提供交互式的访问，允许客户指明文件的类型与格式（如指明是否使用 ASCII 码），并允许文件具有存取权限」；以及文件共享协议的两大类划分——「它们都是文件共享协议中的一大类，即复制整个文件，其特点是：若要存取一个文件，就必须先获得一个本地的文件副本」，与联机访问（NFS）的对照。
- 印刷 p270，6.2.2 节：FTP 面临的四类不兼容（存储格式、目录结构与命名、命令、访问控制）与「FTP 的主要功能是减少或消除在不同操作系统下处理文件的不兼容性」；主进程四步工作步骤（打开熟知端口 21 / 等待请求 / 启动从属进程 / 回到等待状态）与「主进程与从属进程的处理是并发进行的」；双连接原文——「在进行文件传输时，FTP 的客户和服务器之间要建立两个并行的 TCP 连接：『控制连接』和『数据连接』。控制连接在整个会话期间一直保持打开……但控制连接并不用来传送文件。实际用于传输文件的是『数据连接』」「由于 FTP 使用了一个分离的控制连接，因此 FTP 的控制信息是带外(out of band)传送的」；端口与好处——「服务器进程用自己传送数据的熟知端口 20 与客户进程所提供的端口号建立数据传送连接。由于 FTP 使用了两个不同的端口号，所以数据连接与控制连接不会发生混乱」「使用两个独立的连接的主要好处是使协议更加简单和更容易实现，同时在传输文件时还可以利用控制连接对文件的传输进行控制。例如，客户发送『请求终止传输』」。本篇引用的图即此页的「FTP 使用的两个 TCP 连接」。
- 印刷 p271，6.2.3 节：TFTP 的全部对照材料——「虽然 TFTP 也使用客户服务器方式，但它使用 UDP 数据报，因此 TFTP 需要有自己的差错改正措施。TFTP 只支持文件传输而不支持交互。TFTP 没有一个庞大的命令集，没有列目录的功能，也不能对用户进行身份鉴别」；五条特点（每次 512 字节、按序编号从 1 开始、支持 ASCII 或二进制、可读可写、首部很简单）；「TFTP 的工作很像停止等待协议」；熟知端口 69；以及文件长度是否为 512 整数倍时的两种结束判据。
- 印刷 p304，6.6 节：协议配置的概念与四个配置项目（IP 地址、子网掩码、默认路由器的 IP 地址、域名服务器的 IP 地址）；不能出厂烧死 IP 的理由——「这是因为 IP 地址不仅包括了主机号，而且还包括了网络号。一个 IP 地址指出了一台计算机连接在哪一个网络上。当计算机还在生产时，无法知道它在出厂后将被连接到哪一个网络上」；「即插即用连网(plug-and-play networking)」；Discover 的两个特殊地址——「需要 IP 地址的主机在启动时就向 DHCP 服务器广播发送发现报文(DHCPDISCOVER)（将目的 IP 地址置为全 1，即 255.255.255.255）……这台主机目前还没有自己的 IP 地址，因此它将 IP 数据报的源 IP 地址设为全 0……但只有 DHCP 服务器才对此广播报文进行回答」；Offer 的取址次序「DHCP 服务器先在其数据库中查找该计算机的配置信息。若找到，则返回找到的信息。若找不到，则从服务器的 IP 地址池(address pool)中取一个地址分配给该计算机」；以及中继代理的引入。
- 印刷 p304–p305，6.6 节：中继代理的动作（p304）——「当 DHCP 中继代理收到主机 A 以广播形式发送的发现报文后，就以单播方式向 DHCP 服务器转发此报文，并等待其回答」；封装提醒「DHCP 报文只是 UDP 用户数据报的数据，它还要加上 UDP 首部、IP 数据报首部，以及以太网的 MAC 帧的首部和尾部后，才能在链路上传送」；租用期——「DHCP 协议称这段时间为租用期(lease period)，但并没有具体规定租用期应取为多长或至少为多长，这个数值应由 DHCP 服务器自己决定……按照 RFC 2132 的规定，租用期用 4 字节的二进制数字表示，单位是秒。因此可供选择的租用期范围从 1 秒到 136 年。DHCP 客户也可在自己发送的报文中（例如，发现报文）提出对租用期的要求」；端口「DHCP 客户使用的 UDP 端口是 68，而 DHCP 服务器使用的 UDP 端口是 67。这两个 UDP 端口都是熟知端口」。
- 印刷 p306，6.6 节：工作过程逐条注释——「凡收到 DHCP 发现报文的 DHCP 服务器都发出 DHCP 提供报文，因此 DHCP 客户可能收到多个 DHCP 提供报文」「被选择的 DHCP 服务器发送确认报文 DHCPACK。从这时起，DHCP 客户就可以使用这个 IP 地址了。这种状态叫作已绑定状态，因为在 DHCP 客户端的 IP 地址和 MAC 地址已经完成绑定」；两个计时器——「DHCP 客户现在要根据服务器提供的租用期 T 设置两个计时器 T1 和 T2，它们的超时时间分别是 0.5T 和 0.875T。当超时时间到了就要请求更新租用期」；
DHCPNACK的处理「这时 DHCP 客户必须立即停止使用原来的 IP 地址，而必须重新申请 IP 地址」；以及「若 DHCP 服务器不响应……的请求报文 DHCPREQUEST，则在租用期过了 87.5% 时，DHCP 客户必须重新发送请求报文 DHCPREQUEST」和「DHCP 客户可以随时提前终止服务器所提供的租用期，这时只需向 DHCP 服务器发送释放报文 DHCPRELEASE 即可」。
说明：两个折叠块里的场景与数值（2 次列目录 + 3 个文件；租用期 2 小时）均为自造；能与教材对账的是"数据连接每次传送建立、传完关闭""
、 ""87.5% 时重发请求"三项，已核对印刷 p270 与 p306 原文。 秒 ≈ 136 年这一项与教材"1 秒到 136 年"的表述一致。广播标志位等实现细节教材未展开，本篇按"分两层看"这一判据表述，不给绝对结论。
相关知识
网络应用模型｜TCP 连接管理｜UDP 用户数据报协议｜HTTP 协议｜ARP 地址解析协议｜ICMP 网际控制报文协议｜IPv4 地址与子网划分