应用层 — DNS、Web、邮件与 DHCP¶

这一章讲你每天上网真正摸到的那些协议。 传输层之下解决「数据怎么可靠地到那台机器的那个程序」; 应用层解决「到了之后,双方说什么语言」——查地址簿的(DNS)、取网页的(HTTP)、传文件的(FTP)、遥控机器的(Telnet/SSH)、送信的(SMTP/POP)、发地址的(DHCP)。学完这章,你可以把「浏览器敲一个网址到页面显示」的每一步,按协议逐层点名。

1. 应用层的组织方式:两种模型¶

应用层的协议都是为了解决某类应用问题而设计的,问题的解决靠不同主机上的多个进程协同工作——所以每个应用协议都得先回答「谁找谁、怎么协同」¹。

客户/服务器(C/S)模型:一台总是开着的主机做服务器,服务许多客户端的请求; 服务器在线等待 → 客户端发出请求 → 服务器处理并回送结果²。特征:

地位不平等:服务器可以借权限管理客户端;管理集中在少数服务器上;
客户端之间不直接通信(两个浏览器从不说话);
可扩展性不佳:服务器是瓶颈——硬件与带宽都有限。

Web、FTP、邮件、DNS 全是这个模型。

P2P 模型:没有固定的服务器,每个结点既下载也上传,既是客户也是服务器 (对等方 peer)³。优点正好对着 C/S 的短板:计算与带宽压力分摊到所有结点 (没有单一瓶颈)、扩展性好(用户越多资源越多)、健壮(单个结点失效无碍大局)。代价:为别人服务占自己的内存与带宽;且需要额外的发现机制找到资源在哪 (BitTorrent 的 tracker、DHT,本章只到概念)。

主线例子(贯穿本章): 你在浏览器输入 www.xaut.edu.cn 回车,到页面显示为止的完整旅程——这是把全章所有协议串起来的那根绳。

2. 顶层全景:一次网页访问的协议接力¶

  ① 浏览器拿到域名 —— 先问 DNS:这名字是哪个 IP?(3.2)
  ② DNS 服务器之间递归/迭代协作查域(根→cn→edu.cn→授权服务器)(3.2)
  ③ 浏览器与服务器 80 端口建 TCP 连接(第 09 章三次握手)
  ④ HTTP:GET /index.html → 200 OK + 页面(3.3)
  ⑤ 页里引用的每张图:再请求——持久连接里复用同一条 TCP(3.3)
  (旁路:你的电脑开机时 DHCP 已自动配好 IP/网关/DNS;3.7)

3. 核心原理¶

3.1 应用层怎么坐传输层的车¶

应用层进程通过 socket 上 TCP 或 UDP 的车。区分一条通信靠三参数: 目的 IP、传输层协议(TCP/UDP)、端口号——三者绑定到一个 socket, 应用层与传输层就凭 socket 互相认账⁴。

选 TCP 还是 UDP,书里的对照表一眼看清:DNS、流式多媒体、IP 电话坐 UDP; Web、邮件、文件传输、远程登录坐 TCP⁵。应用层协议大多数是「ASCII 明文 + 请求/应答」的形状——FTP、HTTP、SMTP 全是,这为调试带来极大便利 (telnet 手工模拟协议交互),也是安全问题的温床(第 11 章)。

3.2 DNS:互联网的电话簿¶

要解决的问题:IP 地址好定位、不好记;1983 年起 Internet 用层次结构的命名树 做主机名,用 DNS 负责「名字 ↔ IP」的转换⁶。DNS 是应用层协议,跑在 UDP 53 端口, 本质是一个分布式数据库——域名数据不集中存,而是分层分布在很多域名服务器上⁷。

域名的层次结构:从右往左读,级级细分。www.sina.com.cn 中, cn 是最高域(国家域,中国)、com 是二级域(机构性质)、sina 是单位名、www 是主机名。最高域分两族:按机构分的通用域(com 公司、edu 教育、gov 政府、org 非营利、net 网络中心、 mil 军事、int 国际组织)与按地理分的国家域(cn 中国、uk 英国、jp 日本……)⁸。域名不区分大小写。整个域名空间倒过来看是一棵树,根在上面。

三类服务器(查询链上的角色)⁹:

本地域名服务器:主机第一个问的;答不出就替主机往上问;
根域名服务器:知道所有顶级域的授权服务器在哪——查询链的入口;
授权域名服务器:主机名「登记」的地方,握有这个名字的确切记录; (书里注明:授权服务器与本地服务器通常是同一个的两种说法—— 本地是从查询者角度说的,授权是从数据主权角度说的。)

两种解析方式¹⁰:

	递归解析	迭代(重复)解析
问不到时	服务器替你接着问到底,把最终结果带回来	服务器回你一句「去问那台」,你自己去问
干活的是	服务器系统	发起查询的主机
类比	委托办事	问路

主线例子走一遍(主机 comp.xaut.edu.cn 查 comp.xjtu.edu.cn)——递归版: 主机问本地 dns.xaut.edu.cn → 本地问根 → 根把请求转给负责 edu.cn 的授权服务器 → 再转给 dns.xjtu.edu.cn → IP 沿路返回。迭代版:本地服务器每步都拿到「下一台该问谁」的引荐,自己一步步走下去¹¹。 实际工程是混合的:主机到本地服务器递归(省心),本地服务器往外迭代(别甩锅)。

反向解析:IP → 域名。用一个特殊域 in-addr.arpa,把 IP 倒着写成域名 (ddd.ccc.bbb.aaa.in-addr.arpa)再查——因为域名是自底向上而 IP 是自顶向下, 不倒过来就配不上树的结构¹²。

资源记录(RR):数据库里的条目是四元组 (Name, Value, Type, TTL),常用四种类型¹³:

A:主机名 → IPv4 地址(www.edu.cn, 202.205.10.1, A);
NS:域名 → 该域的授权服务器主机名(edu.cn, dns.edu.cn, NS);
CNAME:别名 → 规范主机名;
MX:域名 → 邮件服务器的规范主机名。

DNS 报文只有两种:查询与回答,格式相同(12B 头 + 问题 + 回答 + 权威 + 附加)¹⁴。 TTL 字段让解析结果可以缓存——这是 DNS 扛住全球查询量的关键设计: 解析一次缓存一会儿,缓存命中就不用再走路查询链。

3.3 Web 与 HTTP:请求与应答的语言¶

Web 是 C/S 模式:HTML 写页面、HTTP 搬页面、URL 定位页面,浏览器解释渲染¹⁵。 HTTP 是无状态的——服务器不记得上一个请求是谁(「每次都当第一次见」), 为减轻服务器负担、加快响应;需要状态的地方(登录)由应用层会话机制(如 Cookie)补, 那是本书范围之外的话题。

HTTP 报文(ASCII 明文)两种¹⁶:

请求报文 = 请求行 + 首部 + 实体:

  GET /index.html HTTP/1.1        ← 请求行:方法 + 路径 + 版本
  Host: www.xaut.edu.cn            ┐
  User-Agent: Mozilla/5.0          ├ 首部:一行一个「名字: 值」
  Accept: text/html                ┘
  (空行)
  (实体:GET 通常为空;POST 的表单数据在这里)

方法记住四个:GET(取资源,浏览器地址栏访问就是)、POST(往资源附加数据,表单提交)、 HEAD(只要响应头不要正文——测链接有效性)、PUT(存资源)。

响应报文 = 状态行 + 首部 + 实体:

  HTTP/1.1 200 OK                  ← 状态行:版本 + 状态码 + 描述
  Date: ...  Server: Apache/2.0
  Content-Length: 119
  Content-Type: text/html
  (空行)
  <HTML>...</HTML>

状态码按首位分类,常考的七个¹⁷:200 OK(成功)、400 Bad Request(语法错)、 401 Unauthorized(未授权)、403 Forbidden(拒绝服务)、404 Not Found(没有此资源)、 500 Internal Server Error(服务器内部错)、503 Service Unavailable(暂不可用)。

连接方式:RTT 的账怎么算。定义 RTT = 从发出请求到收到响应的时间。 非持久连接(HTTP/1.0):每个对象一条 TCP 连接,取完就关。一个对象的完整时间 = 2 RTT + 传输时间:1 个 RTT 建连(三次握手), 1 个 RTT 请求+响应¹⁸。 主线例子算账: 页面 = 1 个 HTML + 5 张 JPEG。非持久连接串行 = 6 × 2 = 12 RTT; 浏览器实际开 5~10 条并行连接,压到约 3~4 轮,但每条连接都要重新慢启动、重新维持缓冲区——服务器负担很重。

持久连接(HTTP/1.1 默认):一条 TCP 连接传多个对象,服务器发完响应不关连接¹⁹。

不带流水线:收一个响应才能发下一个请求,每对象 1 RTT(共 1 建连 + 6 = 7 RTT);
带流水线(默认模式):浏览器见到引用就立刻连续发请求,服务器连续回—— 全部对象合计约 1 个 RTT(理论上)加一次建连,服务器空等时间也最少; 且只经历一次慢启动,后续对象以第一对象跑出来的速率发送²⁰。

HTML 与 URL 只做工具级介绍:HTML 用标记组织文本/图像/超链接 (<A href=…> 是链接);URL 的格式 协议://主机/路径,http、ftp、telnet 各协议的 URL 例子书里都有²¹。Web 的历史一笔:1989 年欧洲粒子物理实验室为全球物理学家交换信息而发明,浏览器 Mosaic 让它起飞²²。

3.4 FTP:两条连接的分工¶

FTP(文件传输协议,RFC 959)是上古但长寿的文件搬运协议,跑在 TCP 上。它的标志性设计:用两条 TCP 连接²³:

控制连接(端口 21):整个会话期间一直开着,传送命令与服务器的应答 (USER/PASS 登录、LIST 列目录、RETR 取文件……);
数据连接(端口 20):每传一个文件建一条,传完即关。

「控制与数据分离」的好处书里点明:工作效率高——命令通道随时可以发新命令, 不用等数据传完;也方便协议扩展(每个命令配一个数字应答码:331 请输入密码、 125 数据连接已开、425 数据连接打不开……)²⁴。今天看,这个设计还有个副作用: 数据连接由服务器反向连客户端,穿过 NAT/防火墙极其痛苦——主动模式的 FTP 在 NAT 时代成了反面教材,被动模式(PASV)就是为它打的补丁(书里只提了命令名)。

匿名 FTP:公共文件服务器的惯例——用 anonymous 当用户名、Email 地址当口令即可登录²⁵。

3.5 远程登录:Telnet 与 SSH¶

Telnet 的思想:本地键盘显示器操纵远程计算机,像坐在远程机器面前一样²⁶。它要解决的真问题是异构性:不同系统的行结束符、字符编码各不相同 (CR vs LF)。Telnet 的解法是网络虚拟终端(NVT):双方都不说自己方言, 统一翻译成 NVT 标准格式再传——又一个「加个中间层抹平差异」的经典案例(对照 IP 抹平异构网络)²⁷。Telnet 跑 TCP 23 端口,流程:建连 → 输用户名口令 → 像在本地一样工作。

SSH(安全外壳)是 Telnet 的加密接班人——因为 Telnet 致命的缺陷书里说得直白: 明文传送数据、账号和口令,极易被窃听与中间人攻击²⁸。SSH 的体系(RFC 4251~4256):

传输层协议:服务器认证、数据机密性、信息完整性;
用户认证协议:向服务器证明客户端身份;
连接协议:把加密隧道复用成多条逻辑通道,各种高层应用(Telnet、FTP 的安全版 SFTP/SCP) 都从通道里过²⁹。

两级安全验证:基于口令(知道账号密码就能上,仍可能被冒充服务器的中间人骗); 基于密钥(客户端持有私钥,服务器用预存的公钥发「质询」验证——公钥对不上, 冒充者立即露馅)³⁰。今天登录任何云服务器,这条密钥机制就是默认姿势。

3.6 电子邮件:三个协议接力¶

电子邮件是异步系统:邮件投进收件人的邮箱,对方随时来取³¹。涉及三个协议、两台服务器、两个客户端:

  发件方 ──SMTP──▶ 发送方邮件服务器 ──SMTP──▶ 接收方邮件服务器
                                                        │
  收件方 ◀─POP3/IMAP(取信)─────────────────────────────┘

地址与格式:邮箱地址 = 用户名@主机名。邮件分信封与内容, 内容又分头部(To/From/Cc/Subject/Date)和主体(正文)³²。

SMTP(简单邮件传输协议,TCP 25 端口):只干一件事——把邮件从发送方推到接收方邮件服务器,服务器之间也是它³³。简单到骨子里:ASCII 命令对话 (HELO、MAIL FROM、RCPT TO、DATA……),只传可打印 ASCII—— 非英语世界的附件问题由此而来,解法是 MIME(多用途互联网邮件扩展): 头部声明数据类型(文本/声音/图像/视频),正文按编码(Base64 等)打包, 一个邮件里可以同时带多种类型的数据³⁴。

POP3(邮局协议第 3 版):收件方客户端从服务器拉邮件的默认协议(TCP 110)。默认行为是「取走即删」——像去邮局取信。IMAP(第 4 版)是更现代的选择: 邮件保留在服务器上,客户端可以浏览摘要(主题、发件人、大小)后选择性下载, 本地与服务器文件夹随意拖放³⁵。一个邮箱在多台设备(手机+电脑+平板)上保持一致, 靠的是 IMAP 而不是 POP3。

3.7 DHCP:开机自动领装备¶

没有 IP 地址、网关、DNS 服务器,主机连第一步都迈不出;手工配置每台机器是管理噩梦。 DHCP(动态主机配置协议)做集中式自动发放:管理员在 DHCP 服务器上设好可分配的范围, 客户机开机广播请求,领回一整套参数(还附租约期限)³⁶。

主线例子的开机前传:你的电脑其实先演了这一幕才轮得到浏览器出场——

  ① 客户端广播 DHCP 请求:源 0.0.0.0 → 目的 255.255.255.255(我还没地址,只能吼)
  ② 服务器响应:查 MAC——有登记就给固定 IP,没有就从空闲池挑一个,
     附租约期限一起回
  ③ 客户端先发 ARP 确认这个 IP 没被占用:被占了就拒收重申请;
     没被占用就发确认,服务器记账
  ④ 失去地址的两种情形:离线(关机/断网,服务器收回备用)与租约到期

跑在 UDP 上(客户端 68、服务器 67),天生 C/S。适用场合书里点了两类: 移动办公(笔记本到处走,每换一个网络重配一次太烦)与主机数量大的局域网³⁷。租约机制让地址「用着用着还回去」,一个 C 类网段轻松周转几百台机器—— DHCP 与 NAT 联手,是私有地址体系能运转的两块基石。

3.8 应用层协议的报文级细节¶

DNS 报文的十二个首部字节(前 3.2 讲了查询链,这里补报文本身)⁴¹: 标识(2B,客户端设置、服务器原样带回——匹配请求与回答的号码牌)、标志(16 位, 含「是查询还是回答」「是否递归」等开关)、四个计数(问题数、回答 RR 数、权威 RR 数、附加 RR 数)。之后四段变长:问题(被查的名字 + 想查的类型)、回答(资源记录)、权威(其他授权服务器的记录)、附加(顺带有用的记录,典型如 NS 记录配套附带的 A 记录)。「查一个名字」最常见的完整收获是一组:A 记录给答案、NS 记录指路、附加段把那台 NS 的 IP 也附赠——一次查询,链路全齐。

HTTP 连接过程的五步(书里的图 8-10)⁴²:① 客户端发建连请求 → ② 服务器接受、TCP 连接建立(三次握手,第 09 章)→ ③ 客户端发请求块 → ④ 服务器返回请求的页面 → ⑤ 关闭连接。朴素得不像一个「协议」—— HTTP 的全部智慧都在「请求块和响应块里写什么」以及「这条连接用完是关是留」(3.3)。

FTP 的应答码文化:每个命令配一个三位数字应答,百位表类别——1xx 准备中、 2xx 成功(230 登录成功、226 传送完成)、3xx 需要进一步信息(331 请发密码)、 4xx 暂时失败(425 数据连不上)、5xx 永久失败(530 登录失败)⁴³。「命令可读 + 数字应答」的设计让脚本自动化成为可能——今天的 API 设计里「机器可读的码 + 人可读的消息」双轨,源头之一就在这。

邮件信封与头部的分工:用户只写 To/Subject 这些内容头;信封(真正用于路由的信息:MAIL FROM/RCPT TO)由系统从头部分拣生成——SMTP 对话用的是信封, 用户看到的头部是内容。这个「信封—内容」分离解释了邮件系统一个著名的宽容: 头部里的 From 和信封 From 可以不一致,垃圾邮件伪造正是钻的这个缝 (SPF/DKIM 反伪造协议就是补这个缝,本书范围之外,但读信封概念时要知道它存在)。

IMAP 比 POP3 多什么:POP3 默认把邮件取走删库——服务器只是中转站; IMAP 把邮箱留在服务器上,客户端可以只读摘要(到达时间、主题、发件人、大小) 再决定下不下载,支持选择性下载附件、本地与服务器文件夹双向拖动⁴⁴。「一个邮箱多台设备保持一致」这个今天天经地义的功能,背后是 IMAP 的功劳; POP3 只适合「一台设备收信」的老场景。

DHCP 的两个魔鬼细节:其一,请求报文源地址是 0.0.0.0、目的地址是 255.255.255.255——还没拿到 IP,只能用全 0 表示自己、全 1 广播喊话; 其二,拿到地址后先用 ARP 探一下这个地址有没有人占——DHCP 服务器偶尔会把正在用的地址再发一份,客户端这道自检防的就是这种撞车⁴⁵。另外「租约」不是惩罚而是周转设计:IP 池按「同时在线」而不是「在编设备」配置即可, 离线即还、到期再租,几百人的单位一个 C 类段绰绰有余。

3.9 P2P 的两种经典形状¶

P2P 不是只有「大家互传文件」一个样子:

BitTorrent 式(分片交换):文件切成块,每个下载者手里有不同的块, 互相补缺——「下的人越多,每人手上的块越全,下载越快」,用经济学里的「以块换块」激励上传;
PPlive/电驴式(目录+中继):有中心目录或索引告诉你要的资源在哪个(些)结点, 之后点对点直连⁴⁶。 P2P 的老大难是发现:结点们互相看不见对方(NAT 与动态 IP),所以需要 tracker、 DHT 这类「撮合」机制——C/S 的影子其实从没离开过 P2P。

4. 作者的判断与证据¶

「无状态是为了快」:HTTP 无状态的设计动机书里明写为减轻服务器负担、加快响应³⁸——性能优先于功能,是互联网协议的典型价值取向;
「明文的代价」:Telnet 的不安全性与 SSH 的替代关系是全书少见的「安全问题直接决定技术生死」的案例³⁹;
「C/S 的可扩展性不佳 vs P2P 的健壮」:两种模型的优缺点并列成文⁴⁰, 没有押注谁赢——虽然本章的协议几乎全是 C/S,这个对照更像给读者的思维工具。

5. 边界与局限¶

HTTP 一节停在 HTTP/2 的名词(RFC 7540),HTTP/2 的二进制分帧、HTTP/3(QUIC) 不在书中;持久连接与流水线的 RTT 账是按 HTTP/1.1 教学模型算的。
Cookie/会话与 Web 安全(注入、XSS) 未提;HTTPS 只出现在 SSL 一节(第 11 章) 的应用举例里。
电子邮件只到协议级:垃圾邮件、SPF/DKIM 反伪造、HTML 邮件这些现实问题没有涉及。
DNS 安全(DNSSEC、DNS 劫持)未提——而「本地 DNS 被污染」是许多网络故障的真实原因。
DHCP 的跨网段中继(DHCP Relay) 没讲,大网络里 DHCP 服务器不在本网段时如何工作, 需要额外资料。

判断(我们的,不是书里的): 应用层是「协议可读性」的最佳教学现场: 拿 telnet 主机 80 手敲一个 GET,整个 HTTP 就活了。本章每个协议都建议动手敲一遍——这是网络课里性价比最高的实验。另外,这章协议的选择本身就是一堂「工程取舍」课:HTTP 用无状态换伸缩、FTP 用双连接换灵活、SMTP 用 ASCII 换简单、 DHCP 用租约换周转——每一个「当年合理的选择」都在今天留下一笔账(状态靠 Cookie 补、 NAT 穿透靠 PASV、国际化靠 MIME、地址靠续租),读懂这些账,比背协议号值钱。 如果错,会错在: 应用层的半壁江山正在搬到加密与二进制之下(HTTPS 成为默认、 HTTP/2 分帧、DoH 把 DNS 也塞进 HTTPS),「明文可敲」的教学窗口正在关闭—— 但报文的逻辑结构没变,学到的仍是活的。

6. 可带走的¶

C/S:服务器是瓶颈;P2P:压力分摊、规模自增、结点健壮;
DNS:UDP 53;分布式树状数据库;本地/根/授权三类服务器;
递归 = 替你问到底;迭代 = 告诉你去问谁;实际是「内递归外迭代」;
四类资源记录:A(名字→IP)、NS(域→授权服务器)、CNAME(别名)、MX(邮件服务器);
HTTP:GET/POST/HEAD/PUT;200/400/401/403/404/500/503;
非持久连接每对象 2RTT;持久连接 1 条 TCP 传全部;流水线把 N 个对象压到 1 个 RTT;
FTP:控制连接(21,常开)+ 数据连接(20,用完即关);命令与应答都是 ASCII;
Telnet 的 NVT 抹平终端差异;Telnet 明文送口令,所以 SSH 全面取代;
邮件三件套:SMTP 推(25)、POP3/IMAP 拉(110/143);MIME 让 SMTP 能带二进制附件;
DHCP:广播请求(0.0.0.0→255.255.255.255)→ 服务器发 IP+租约 → ARP 验证 → 确认;租约到期要续。

7. 原文地图¶

主题	原书章	原文位置
应用层任务与 socket 三参数	第8章应用层	`text/18-ch08.txt:12`(搜「应用进程」) · `text/18-ch08.txt:32`(搜「3 个参数」)
C/S 模型与特征	第8章应用层	`text/18-ch08.txt:78`(搜「工作流程」) · `text/18-ch08.txt:90`(搜「可扩展性不佳」)
P2P 模型与优缺点	第8章应用层	`text/18-ch08.txt:92`(搜「P2P」) · `text/18-ch08.txt:113`(搜「减轻了服务器的计算压力」)
各应用的传输层选择	第8章应用层	`text/18-ch08.txt:54`(搜「表 8-1」)
DNS 定位与 UDP 53	第8章应用层	`text/18-ch08.txt:126`(搜「1983 年」) · `text/18-ch08.txt:137`(搜「53 号端口」)
域名层次与最高域	第8章应用层	`text/18-ch08.txt:148`(搜「层次结构」) · `text/18-ch08.txt:168`(搜「两大类」)
三类域名服务器与两种解析	第8章应用层	`text/18-ch08.txt:210`(搜「3 类域名服务器」) · `text/18-ch08.txt:222`(搜「递归解析」) · `text/18-ch08.txt:226`(搜「重复解析」)
递归/迭代解析实例	第8章应用层	`text/18-ch08.txt:232`(搜「comp.xaut.edu.cn」)
反向解析 in-addr.arpa	第8章应用层	`text/18-ch08.txt:247`(搜「in-addr.arpa」)
资源记录四种类型	第8章应用层	`text/18-ch08.txt:258`(搜「四元组」)
DNS 报文结构	第8章应用层	`text/18-ch08.txt:281`(搜「12B」)
Web 三要素与历史	第8章应用层	`text/18-ch08.txt:310`(搜「HTML」) · `text/18-ch08.txt:342`(搜「1989 年」)
HTTP 版本沿革	第8章应用层	`text/18-ch08.txt:358`(搜「RFC 1945」) · `text/18-ch08.txt:361`(搜「无状态」)
请求/响应报文与状态码	第8章应用层	`text/18-ch08.txt:377`(搜「请求报文」) · `text/18-ch08.txt:416`(搜「状态码」)
非持久连接 2RTT 与缺点	第8章应用层	`text/18-ch08.txt:456`(搜「非持久」) · `text/18-ch08.txt:480`(搜「totaltime」) · `text/18-ch08.txt:526`(搜「缺点」)
持久连接与流水线	第8章应用层	`text/18-ch08.txt:533`(搜「持久性连接」) · `text/18-ch08.txt:546`(搜「带流水线」)
HTML 与 URL	第8章应用层	`text/18-ch08.txt:558`(搜「HTML 是」) · `text/18-ch08.txt:579`(搜「资源传递协议」)
FTP 两条连接	第8章应用层	`text/18-ch08.txt:601`(搜「FTP」) · `text/18-ch08.txt:618`(搜「两个连接」)
FTP 命令与回答、匿名	第8章应用层	`text/18-ch08.txt:630`(搜「USER」) · `text/18-ch08.txt:669`(搜「anonymous」)
Telnet 与 NVT	第8章应用层	`text/18-ch08.txt:678`(搜「远程登录」) · `text/18-ch08.txt:698`(搜「网络虚拟终端」)
SSH 三协议与两级验证	第8章应用层	`text/18-ch08.txt:737`(搜「SSH 协议框架」) · `text/18-ch08.txt:746`(搜「基于密码」)
邮件系统组成与 SMTP/POP	第8章应用层	`text/18-ch08.txt:766`(搜「E-mail」) · `text/18-ch08.txt:829`(搜「SMTP」) · `text/18-ch08.txt:847`(搜「POPv3」)
MIME 与 IMAP	第8章应用层	`text/18-ch08.txt:776`(搜「MIME」) · `text/18-ch08.txt:857`(搜「IMAP」)
DHCP 过程与租约	第8章应用层	`text/18-ch08.txt:866`(搜「DHCP」) · `text/18-ch08.txt:884`(搜「0.0.0.0」) · `text/18-ch08.txt:897`(搜「失去」)
DHCP 使用场合	第8章应用层	`text/18-ch08.txt:907`(搜「移动办公」)

出处:「概述」第 8–12 段(text/18-ch08.txt:12,搜「应用进程」;text/18-ch08.txt:12,搜「遵循的协议」)。 ↩
出处:「网络应用模型」第 75–85 段(text/18-ch08.txt:75,搜「客户/服务器模型」;text/18-ch08.txt:82,搜「客户是服务请求方」)。 ↩
出处:「网络应用模型」第 92–118 段(text/18-ch08.txt:110,搜「对等方」;text/18-ch08.txt:115,搜「可扩展性好」)。 ↩
出处:「概述」第 29–35 段(text/18-ch08.txt:32,搜「3 个参数」)。 ↩
出处:「概述」表 8-1(text/18-ch08.txt:54,搜「表 8-1」)。 ↩
出处:「DNS」第 120–127 段(text/18-ch08.txt:126,搜「1983 年」;text/18-ch08.txt:127,搜「DNS 中的主机名字即为域名」)。 ↩
出处:「DNS」第 128–131 段(text/18-ch08.txt:128,搜「专门的服务器」;text/18-ch08.txt:137,搜「53 号端口」)。 ↩
出处:「域名系统的结构」第 146–170 段(text/18-ch08.txt:150,搜「www.sina.com.cn」;text/18-ch08.txt:168,搜「两大类」)。 ↩
出处:「域名解析」第 208–219 段(text/18-ch08.txt:210,搜「3 类域名服务器」)。 ↩
出处:「域名解析」第 221–231 段(text/18-ch08.txt:222,搜「递归解析」;text/18-ch08.txt:226,搜「重复解析」)。 ↩
出处:「域名解析」第 232–242 段(text/18-ch08.txt:234,搜「递归域名解析过程」;text/18-ch08.txt:240,搜「重复域名解析」)。 ↩
出处:「域名解析」第 244–251 段(text/18-ch08.txt:247,搜「in-addr.arpa」)。 ↩
出处:「DNS 记录与报文」第 254–274 段(text/18-ch08.txt:258,搜「四元组」)。 ↩
出处:「DNS 记录与报文」第 276–301 段(text/18-ch08.txt:281,搜「12B」)。 ↩
出处:「万维网」第 303–312 段(text/18-ch08.txt:85,搜「客户/服务器模型」)。 ↩
出处:「HTTP 格式」第 374–434 段(text/18-ch08.txt:377,搜「请求报文」;text/18-ch08.txt:407,搜「响应报文」)。 ↩
出处:「HTTP 格式」表 8-4(text/18-ch08.txt:417,搜「状态码」)。 ↩
出处:「HTTP 的连接方式」第 456–481 段(text/18-ch08.txt:458,搜「每个 TCP 连接传送至多」;text/18-ch08.txt:480,搜「totaltime」)。 ↩
出处:「HTTP 的连接方式」第 533–545 段(text/18-ch08.txt:534,搜「多个 Web 对象」)。 ↩
出处:「HTTP 的连接方式」第 546–554 段(text/18-ch08.txt:546,搜「带流水线」;text/18-ch08.txt:549,搜「1 个 RTT」)。 ↩
出处:「HTML」与「URL 与信息定位」第 556–590 段(text/18-ch08.txt:561,搜「<html>」;text/18-ch08.txt:579,搜「资源传递协议」)。 ↩
出处:「Web 的发展历史」第 340–346 段(text/18-ch08.txt:342,搜「1989 年」;text/18-ch08.txt:344,搜「Mosaic」)。 ↩
出处:「FTP 的工作原理」第 601–622 段(text/18-ch08.txt:614,搜「默认端口号为 21」;text/18-ch08.txt:618,搜「两个连接」)。 ↩
出处:「FTP 命令和回答」第 624–640 段(text/18-ch08.txt:630,搜「USER」;text/18-ch08.txt:636,搜「331」)。 ↩
出处:「FTP 的应用」第 665–670 段(text/18-ch08.txt:669,搜「anonymous」)。 ↩
出处:「远程登录」第 676–679 段(text/18-ch08.txt:678,搜「用自己的键盘」)。 ↩
出处:「Telnet 协议」第 692–706 段(text/18-ch08.txt:698,搜「网络虚拟终端」)。 ↩
出处:「远程登录」第 682–684 段(text/18-ch08.txt:683,搜「明文」)。 ↩
出处:「SSH 协议」第 729–744 段(text/18-ch08.txt:737,搜「3 个协议」)。 ↩
出处:「SSH 协议」第 745–760 段(text/18-ch08.txt:746,搜「基于密码」;text/18-ch08.txt:752,搜「质询」)。 ↩
出处:「概述」第 762–765 段(text/18-ch08.txt:767,搜「可随时进行读取」)。 ↩
出处:「电子邮件的格式」第 795–800 段(text/18-ch08.txt:797,搜「信封和内容」)。 ↩
出处:「电子邮件传输协议」第 827–846 段(text/18-ch08.txt:831,搜「负责服务器之间的邮」;text/18-ch08.txt:838,搜「默认端口号为 25」)。 ↩
出处:「概述」第 775–778 段(text/18-ch08.txt:776,搜「MIME」)。 ↩
出处:「电子邮件传输协议」第 847–865 段(text/18-ch08.txt:851,搜「邮局」;text/18-ch08.txt:858,搜「IMAP」)。 ↩
出处:「DHCP 的基本概念」第 866–877 段(text/18-ch08.txt:870,搜「集中和动态分配」)。 ↩
出处:「DHCP 的运作方式」第 878–902 段(text/18-ch08.txt:884,搜「0.0.0.0」;text/18-ch08.txt:890,搜「租约期限」);「DHCP 的使用场合」第 904–912 段(text/18-ch08.txt:907,搜「移动办公」)。 ↩
出处:「万维网」第 3 节(text/18-ch08.txt:361,搜「无状态的协议机制」)。 ↩
出处:「远程登录」第 682–685 段(text/18-ch08.txt:682,搜「本质上是不安全的」)。 ↩
出处:「网络应用模型」第 86–90 段(text/18-ch08.txt:90,搜「可扩展性不佳」)与第 112–118 段(text/18-ch08.txt:116,搜「网络健壮性强」)。 ↩
出处:「DNS 记录与报文」第 276–301 段(text/18-ch08.txt:290,搜「12B」)。 ↩
出处:「HTTP」第 361–372 段(text/18-ch08.txt:363,搜「连接过程」)。 ↩
出处:「FTP 命令和回答」第 630–640 段(text/18-ch08.txt:636,搜「331」)。 ↩
出处:「电子邮件传输协议」第 855–865 段(text/18-ch08.txt:860,搜「摘要浏览」)。 ↩
出处:「DHCP 的运作方式」第 878–896 段(text/18-ch08.txt:884,搜「255.255.255.255」;text/18-ch08.txt:892,搜「ARP」)。 ↩
出处:「网络应用模型」第 92–118 段(text/18-ch08.txt:111,搜「PPlive」)。 ↩