408 知识点笔记——计网（传输层、应用层）

最新推荐文章于 2024-08-14 17:28:59 发布

大白羊_Aries

最新推荐文章于 2024-08-14 17:28:59 发布

阅读量2.8k

点赞数 5

分类专栏：考研笔记

本文链接：https://blog.csdn.net/qq_38204302/article/details/110131321

版权

考研笔记专栏收录该内容

13 篇文章 211 订阅

订阅专栏

文章目录

5 传输层
6 应用层

5 传输层

【传输层的功能】

提供应用进程间的逻辑通信
差错检测
提供无连接或面向连接的服务
复用和分用：复用是指发送方不同的应用进程都可以使用一个传输层协议传输数据；分用是指接收方的传输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程

注意，这里说到的是传输层的功能，当然是包括 UDP 和 TCP

所以说，UDP 提供分用/复用服务是正确的。但是，UDP 虽然有差错检验机制，但是 UDP 的差错检验只是检验数据的传输的过程中有没有出现错误，出错的数据直接丢弃，并没有重传等机制，故不能保证可靠传输

△☼▽

在这里插入图片描述

分析：B，根据上述的分用的定义，显然可知，端口号是传输层服务访问点 TSAP，用来标识主机中的应用进程

【TCP 和 IP 的比较】

TCP 是面向连接的，但 TCP 使用的 IP 却是无连接的
在这里插入图片描述
【常见的几个熟知端口】

熟知端口（保留端口）：数值一般为 0 ~ 1023

在这里插入图片描述

【端到端与点到点的关系】

在 TCP/IP 模型中，网络层及其以下各层所构成的通信子网负责主机到主机或点到点的通信，而传输层的主要作用是实现分布式的进程通信，即在原主机进程与目的主机进程之间提供端到端的数据传输

一般来说，端到端信道是由一段段的点到点信道构成的，端到端协议建立在点到点协议之上，提供应用进程之间的通信手段。相应地，在网络层标识主机的 IP 地址，而在传输层标识进程的是端口号

【可靠传输与不可靠传输】

如果一个协议使用确认机制对传输的数据进行确认，那么可以认为是一个可靠的协议。如果一个协议采用尽力而为的传输方式，那么是不可靠的

【面向连接和无连接的数据传输的速度】

面向连接由于建立了一个虚链路，所以每个数据分组可以省略信源地址，减少了数据冗余，这是速度增加的因素。另外，建立虚链路也要花费一定的时间，就是速度降低的因素。因此，很难说二者速度谁快，但是可以肯定的是大量数据传输时面向连接的方式是有利的

【UDP】

1）基本概念

只提醒一点，对于 UDP，网络出现的拥塞不会使源主机的发送速率降低（没有拥塞控制），这对实时应用（如 IP 电话、实时视频会议）是很重要的

2）UDP 首部

记住，UDP 首部占 8B

在这里插入图片描述
△☼▽

在这里插入图片描述

分析：第 1、2 字节表示源端口，0721H = 1825，得知源端口为 1825；第 3、4 字节表示目的端口，0045H = 69，得知目的端口为 69，是 TFTP 端口，由此可知，该数据报是由客户端发送给服务器的，使用 UDP 的这个服务器程序是 TFTP；第 5、6 字节为 2CH，转换为十进制的数据总长度为 44B，那么数据部分的长度应该等于总长度减去 UDP 首部的 8B，故数据部分的长度为 36B

3）UDP 校验

UDP 校验只提供差错检测，在计算校验和时，要在 UDP 用户数据报之前临时加上 12B 的伪首部
伪首部只用于计算校验和，其既不向下传送，也不向上提交
校验的时候若 UDP 数据报数据部分的长度不是偶数字节，则需要填入一个全 0 字节
如果 UDP 校验和校验出 UDP 数据报有错误，可以丢弃，也可以交付上层，但交付上层需要附上错误报告
通过伪首部，不仅可以检查源端口号、目的端口号和 UDP 用户数据报的数据部分，还可以检查 IP 数据报的源 IP 地址和目的地址
按照二进制反码计算（即异或），当无差错时，其结果应该为全 1

【TCP 首部】

1）TCP 首部默认是 20B

△☼▽

在这里插入图片描述

分析：C，TCP 和 IP 数据报首部都是 20B，60/(60+20+20)×100%

2）格式

在这里插入图片描述
数据偏移：这里的数据偏移和 IP 数据报中分片的那个数据偏移是不一样的内容，这里的数据偏移表示首部长度，占 4 位可表示 0001 ~ 1111 一共 15 中状态，而基本单位是 4B，所以数据偏移确定了首部最长为 60B

URG：URG = 1，表示紧急指针指向报文段内数据段的某个字节（数据从第一字节到指针所指字节就是紧急数据），不会进入缓冲区，直接交付给上层

PUSH：PUSH = 1，不等到整个缓存都填满后再向上交付，但注意，这里的交付仍然是从缓冲区中交付的

RST：RST = 1，表明 TCP 连接中出现严重差错，必须释放连接，然后再重新建立连接

校验和：在计算校验和时，TCP 和 UDP 一样，要在 TCP 报文段的前面加上 12B 的伪首部

△☼▽

在这里插入图片描述

分析：A，TCP 分组报头由定长 20B 与不定长的选项字段和填充字段构成，TCP 报文的首部长度必须是 4B 的整数倍，故 4B×8 = 32B > 29B

△☼▽

在这里插入图片描述

分析：
（1）源端口号为第 1、2 字节，即0d28H = 3368；目的端口号为 0015H = 21
（2）序号为 00 5f a9 06，转十进制为 6269190，确认号为 00 00 00 00，值为 0
（3）数据偏移为第 13 字节的前 4 位，即 7，故 TCP 的首部长为 7×4B =28B，可知有 8B 的选项数据
（4）由目的端口可知，这是一条 FTP 的TCP连接；第 14 字节的最后两位为 10，即 SYN = 1，ACK = 0，这说明是第一次握手时发出的 TCP 连接

【TCP 建立连接和释放连接】

1）建立连接

TPC 连接的端点叫做套接字，端口号拼接到 IP 地址即构成了套接字
TCP 规定，SYN 报文段不能携带数据，但是要消耗一个序号
如果把三次握手改成两次握手会怎么样？可能发生死锁
假设 A 给 B 发送了一个连接请求，B 收到了这个分组，并发送了确认应答分组。按照两次握手协定，B 认为连接已经建立，可以开始发送数据。可是， A 在 B 的应答分组丢失的情况下，将不知道 B 是否准备好了，也不知道 B 发送数据使用的初始序列号，A 甚至会怀疑 B 能否收到自己的连接请求。在这种情况下，A 认为连接还未建立成功，将忽略 B 发来的任何数据分组，只等待连接确认应答分组。而 B 在发出的分组超时后，重复发送同样的分组。因此，形成死锁

在这里插入图片描述
△☼▽（2011 年真题）

在这里插入图片描述

分析：C，SYN = 1，ACK= 1，ack = 11221，seq 任意

△☼▽

在这里插入图片描述

分析：D，第一次握手：甲 → 乙，seq = 2018；第二次握手：乙 → 甲，（seq = 2046，ack = 2019）；第三次握手：甲 → 乙，（seq = 2019，ack = 2047）

△☼▽

在这里插入图片描述

分析：D，（注意，已经建立好连接了）A 发送的报文段的序号为 300 ~ 306，B 在对该报文的确认报文段中的 ACK 应该为 307，又由 A 发送的报文段的确认号可以知道，A 期待下一个收到的 B 的报文段序号为 101，故此时 B 的确认报文段的序号即应该为 101，故 D 正确

2）释放连接

在这里插入图片描述

为什么发送最后一次握手报文后要等待 2MSL 的时间呢？

首先，如果 A 不等待 2MSL，A 返回的最后确认报文段丢失的话，则 B 不能进入正常关闭状态，而 A 此时已经关闭了，也不可能再重传
其次，防止出现已失效的连接请求报文段。A 在发送完最后一个确认报文段后，再经过 2MSL 可保证本连接持续时间内所产生的所有报文段从网络中消失

【假定在一个互联网中，所有的链路的传输都不出现差错，所有的结点也都不会发生故障，试问在这种情况下，TCP 的可靠交付的功能是否就是多余的？】

每个 IP 数据报独立的选择路由，因此在到达目的主机时有可能出现失序
由于路由选择的计算出现错误，导致 IP 数据报在互联网中转圈。最后数据报首部中的生存时间 TTL 的数值下降到零，这个数据报在中途就被丢弃了
在某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报，因此有的数据报被丢弃

以上列举的问题表明，必须依靠 TCP 的可靠交付功能才能保证在目的主机的目的进程中接收到正确的报文

【TCP 重传机制】

计算超时计时器重传时间的自适应算法：

记录每个报文段发出的时间以及收到相应的确认报文段的时间。这两个时间之差就是报文段的往返时延
将各个报文段的往返时延样本加权平均，就得出报文段的平均往返时延（RTT）
每测量到一个新的往返时延样本，就按下式重新计算一次平均往返时延 $RTT=(1-\alpha)\times(旧的 RTT)+\alpha\times(新的往返时延样本)$

△☼▽

在这里插入图片描述

分析：
第 1 个确认到达后：RTT = 0.1×30ms+0.9×26ms = 26.4ms
第 2 个确认到达后：RTT = 0.1×26.4ms+0.9×32ms = 31.44ms
第 3 个确认到达后：RTT = 0.1×31.44ms+0.9×24ms = 24.7ms

注意一点，只有 TCP 才需要计算 RTT，而 UDP 不需要计算 RTT

【TCP 中活动窗口值的设置】

TCP 使用滑动窗口机制来进行流量控制，其窗口尺寸的设置很重要，

如果滑动窗口的值设置太小，会产生过多的 ACK （如果窗口大小可以累积确认，这样就将产生更少的 ACK）
如果设置太大，又会由于传送的数据过多而使路由器变得拥挤，导致主机可能丢失分组

△☼▽

在这里插入图片描述

分析：A，理论如上所述

【TCP 流量控制】

△☼▽（2011 年真题）

在这里插入图片描述

分析：B，第 3 个段的序号为 900，那么第 2 个段的序号即为 500，主机乙期望收到第 2 个段，故确认序号为 500（第一个段的序号是 200 ~ 499，第二个段的序号为 500 ~ 899）

△☼▽（2009 年真题）

在这里插入图片描述

分析：D，第一段的序列号为 200 ~ 499，第二个段的序列号为 500 ~ 999，乙正确接收这两个段后，应该希望主机甲接下来发送 1000 号帧，故发送给主机甲的确认序列号为 1000

△☼▽

在这里插入图片描述

分析：C，TCP 通过滑动窗口实现了以字节为单位的确认，因此窗口大小的单位为字节。假设发送窗口的大小为 N，这意味着发送端在没有收到确认的情况下可以连续发送 N 个字节

△☼▽
在这里插入图片描述

分析：B，当序列号循环使用时，具有相同序列号的 TPDU 应该从网络中已经消失。既然使用 8 位序列号，也就是序列号可以从 0 ~ 255，现在存活时间是 20s，也就是 20s 的时间内发送方的 TPDU 的数据不能多于 255 个。所以，最大数据率为 255×256×8bit/20s = 26112 bit/s

△☼▽

在这里插入图片描述

分析：
（1）99-70+1 = 30，故第一个报文段携带了 30B 数据
（2）ack = 100
（3）179-100+1 = 80，故第二个报文段携带了 80B 数据
（4）ack = 70

【TCP 拥塞控制】

1）慢开始、快恢复
在这里插入图片描述

2）快重传

首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接受方。发送方只要连续收到 3 个重复确认就应当立即重传对方尚未收到的报文段

△☼▽

在这里插入图片描述

分析：C，理论如上所述

3）发送窗口的确定

理论： $发送窗口的上限值\mathbf{=min\left\{rwnd, cwnd\right\}}$

△☼▽

分析：A，发送窗口的上限值 = min {4000，2000} = 2000，而甲向乙连续发送两个最大段后，只收到第一个段的确认，故此时甲还可以向乙发送的最大季节数位 2000 - 1000 = 1000

4）慢启动时轮次的问题

先举个例子，1 $\rightarrow$ 2 $\rightarrow$ 4 $\rightarrow$ 8，经历了 3 个轮次（即 3 个 RTT），为什么呢？

在这里插入图片描述
注意，是每收到 1 个对新报文的确认就使发送方的拥塞窗口加 1，所以第一个轮次结束，发送方收到 1 个确认，拥塞窗口加 1，故第二轮次中发送两个报文，而第二轮次结束时收到 2 个确认，拥塞窗口加 2，依次类推

5）若干相关习题

① 基础

△☼▽

在这里插入图片描述

分析：C，新 ssthresh = 8KB，1、2、4、8、9，故第 4 个RTT后，拥塞窗口的大小为 9KB

△☼▽（2014 年真题）
在这里插入图片描述

分析：A，当 t 时刻发生超时时，把 ssthresh 设为 8 的一半，即为 4，且拥塞窗口设为 1KB，然后经历 10 个 RTT 后，拥塞窗口的大小依次为 1、2、4、5、6、7、8、9、10、11、12，而发送窗口取当时的拥塞窗口和接收窗口的最小值，而接收窗口始终为 10KB，所以此时的发送窗口为 10KB

△☼▽

在这里插入图片描述

分析：B，新 ssthresh = 6，1→2→4→8→9→10→11→12→1→2→4→6（注意，是第 12 次传输开始时，不是第 12 轮次结束）

△☼▽

在这里插入图片描述

分析：D，新 ssthresh = 16，1、2、4、8、16，共经过 4 个 RTT

△☼▽

在这里插入图片描述

分析：新的 ssthresh = 32，1、2、4、8、16、32，共经过 5 个 RTT，拥塞窗口的大小变为 32 达到新的 ssthresh，即该链接在超时处理后处于慢开始阶段的时间为 3×5s = 15s

△☼▽

在这里插入图片描述

分析：新 ssthresh = 9，1、2、4、8、9，故在第 4 次突发传输成功后，拥塞窗口的大小将变成 9KB

△☼▽

在这里插入图片描述

分析：
（1）初始阈值为 16，因为拥塞窗口达到 16KB 之后呈线性增长
（2）有超时发生，在传输轮次为 12 时发生了超时，从图中可以看出拥塞窗口在传输轮次 12 之后变为 1KB
（3）采用了慢开始和拥塞避免算法

△☼▽

在这里插入图片描述

分析：
（1）忽略第一问没啥价值
（2）慢开始时间间隔为 [1, 6] 和 [23, 26]
（3）拥塞避免时间间隔为 [7, 16] 和 [17, 22]
（4）第 16 轮次检测到丢失报文段时使用的是快恢复算法，故此时发送方是通过收到了 3 个重复的确认检测到报文段丢失的；第 22 轮次之后是恢复到慢开始，故此时是通过超时检测到报文段丢失的
（5）第 1 轮时，ssthresh = 32,；第 18 轮次时，ssthresh = 21；第 24 轮次时，ssthresh = 13
（6）cwnd = 4，新的 ssthresh = 4

② 加了缓存的情况

△☼▽（2015 年真题）

在这里插入图片描述

分析：4 个 RTT 后，乙收到的数据全部存入缓存，不被取走，接受窗口只剩下 1KB（ $16 - 1 - 2 - 4 - 8$ ）缓存，使得甲的发送窗口为 1KB

△☼▽ （完全窗口的概念）

在这里插入图片描述

分析：B，这里根据解析来看，发送方发出一个完全窗口，是指发送窗口达到 24KB，并且注意，这里最大报文段长度为 2KB，按照 MSS = 1KB 的情况的电话是 1→2→4→8→16，将每个阶段都乘以 2，于是 2→4→8→16→min{32, 24} = 24，共经过 4 个轮次

△☼▽（2017 年真题）
在这里插入图片描述

分析：A，1+2+4+8+16 = 31，经过 4 个 RTT 后，接收窗口已经缓存了 31KB 数据，此时接收窗口为 64KB-31KB = 33KB，下一个 RTT 发送窗口达到 32KB（ < 33B），故总共经过 5×5ms

△☼▽（2016 年真题）

在这里插入图片描述

分析：

（1）第二次握手 TCP 的 SYN = 1，ACK = 1，确认序号 ack = 100+1 = 101

（2）注意是确认段，第一轮次收到 1 个确认，第二轮次收到 2 个确认，第三轮次收到 4 个确认，第四轮次应该收到 8 个确认，此时 H3 收到的第 8 个确认即是第四轮次中的第一个确认，每收到 1 个对新报文的确认就使发送方的拥塞窗口加 1，因此拥塞窗口为 9，而 S 收到了 8KB 数据，接收缓冲还剩 12KB，故此时的接收窗口为 12，发送窗口 = min{9，12} = 9KB

（3）当 H3 的发送窗口等于 0 时，已经发送了 20KB 数据，故下一个待发段的序号为 20K+100+1=20581；根据第（2）问的描述，第四轮次过后，S 收到了 15KB 数据，接收窗口为 5KB，第四轮结束拥塞窗口为 16，此时发送窗口 = min{16，5}，故在第五轮次结束，H3 的发送窗口等于 0，因此平均数据传输速率为 20KB/(5×200ms)=20KB/s=20.48kbps

（4）通信结束后，H3 向 S 发送连接释放报文段，S 收到 H3 的连接释放报文段后，马上发出确认报文，此时 S 已经没有数据需要传输，于是也马上发出连接释放报文段，H3 在收到 S 的连接释放报文段后，发出确认，S 在收到 H3 的确认后就释放 TCP 连接了。因此，S 释放该连接的最短时间为：1.5RTT = 300ms（注意是最短，所以我们视 S 发送确认报文和紧接着发送连接释放报文段只占用了 0.5RTT）

【为什么说 UDP 是面向报文的，TCP 是面向字节流的？】

发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文，所以说 UDP 是面向报文的
而发送方 TCP 对应用程序交下来的报文数据块，视为无结构的字节流，无边界约束，但维持各字节，所以说 TCP 是面向字节流的

【如果用户要传送的数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，问还能否TCP来传送？】

即使用户要传送的数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，也还可以使用 TCP 来传送。当今的因特网用户速率还不是那么高到离谱，且分组的生命期受限。TCP 的序列字段有32位，可以循环使用序列号，这样就可保证当序号重复使用时，旧序号的数据早已通过网络到达终点了

【TCP 未按序号到达怎么处理？】

如果收到的报文段无差错，只是未按序号，则 TCP 对此未作明确规定，而是让 TCP 的实现者自行确定。试讨论两种可能的方法的优劣：

1）将不按序的报文段丢弃
2）先将不不按序的报文段暂存于接收缓存内，待所缺序号的报文段收齐后再一起上交应用层

答：第一种方法其实就是后退 N 帧协议所使用的处理方式，这种方法将不按序的报文段丢弃，会引起被丢弃报文段的重复传送，增加对网络带宽的消耗，但由于用不着将该保报文段暂存，可以避免对接收方缓冲区的占用

第二种方法就是选择重传协议所使用的处理方式，该方法不按序的报文段暂存于接收缓存内，待所缺序号的报文段收齐后再一起上交应用层，这样有可能避免发送方对已经被接收方接收的不按序的报文段的重传，减少了对网络带宽的消耗，但增加了接收方缓冲区的开销

6 应用层

【客户/服务器模型】

客户机的作用是根据用户的任务需求向后端服务器发出服务请求，并将服务器返回的结果呈现给前端客户机用户。所以，客户机是面向用户的，服务器是面向任务的
客户机与服务器的通信需要借助网络环境，否则无法工作

【P2P】

所谓 P2P 体系结构就是在这样的网络应用中，没有（或只有极少数的）固定的服务器，而绝大多数的交互都是使用对等方式进行的

实际上，P2P 模型从本质上来看仍然是客户/服务器方式，只是对等连接中的每一个主机既是客户又是服务器

P2P 模型带来的好处是，任何一台主机都可以成为服务器，改变了原来需要专用服务器的模式，很显然，多个客户机之间可以直接共享文档。此外，可以借助 P2P 网络模型解决专用服务器的性能瓶颈（如播放流媒体时对服务器的压力过大，而通过 P2P 模型，可以利用大量的客户机来提供服务）

P2P模型主要特点如下：

繁重的计算任务可以被分配到各个结点上，利用每个结点空闲的计算能力和存储空间，聚合实现强大的服务
系统可扩展性好，传统的服务器有连接带宽的限制，只能达到一定的客户端连接数，但是在 P2P 模型中，能避免这个问题
网络更加健壮，不存在中心结点失效的问题，当一部分结点连接失败之后，其余的结点仍然能够形成完整的网络

△☼▽（2019 年真题）

在这里插入图片描述

分析：B，通过上述理论可知，A）、D）选项正确；在 C/S 模型中，客户是服务发起方，服务器被动接受各地客户的请求，但客户之间不能直接通信，例如 Web 应用中两个浏览器之间并不能直接通信

【DNS 系统】

1）域名

任何一个连在因特网上的主机和路由器都有一个唯一的层次结构，即域名

尽管 DNS 能够完成域名到 IP 地址的映射，但实际上 IP 地址和域名并非一一对应。如果一个主机通过两块网卡连接在两个网络上，则具有两个 IP 地址，但这两个 IP 地址可能就映射到同一个域名上。如果一个主机具有两个域名管理机构分配的域名，则这两个域名就可能具有相同的 IP 地址。显然，域名和 MAC 地址也不是一一对应的，因为一个主机可以通过两块网卡连接在两个网络上，所以有两个 MAC 地址

2）域名服务器

DNS 服务器管辖的范围不是以域为单位，而是以区为单位，区一定小于域

根域名服务器，不管是哪一个本地域名服务器，若要对因特网上任何一个域名进行解析，只要自己无法解析，就首先求助于根域名服务器（注意，根域名服务器用来管辖顶级域名服务器，它并不直接把待查询的域名转换成 IP 地址，而是告诉本地域名服务器下一步应当找哪一个顶级域名服务器进行查询）
顶级域名服务器，其给出的回答可能是最后的结果，也可能是下一步应当找的域名服务器的 IP 地址
授权域名服务器（权限域名服务器），每一台主机都必须在授权域名服务器处注册登记，授权域名服务器一定能够将其管辖的主机名转换为该主机的 IP 地址。如果授权域名服务器还不能给出最后的查询回答时，就会告诉发出请求的 DNS 客户，下一步应当找哪一个授权域名服务器
本地域名服务器，当一个主机发出 DNS 查询请求时，这个查询报文就发送给本地域名服务器

3）主域名服务器与辅助域名服务器

DNS 服务器把数据复制到几个域名服务器来保存，其中一个是主域名服务器，其他的是辅助域名服务器。当主域名服务器出现故障时，辅助域名服务器可以保证 DNS 的查询工作不会中断。主域名服务器定期把数据复制到辅助域名服务器中，而更改数据只能在主域名服务器中进行，这样就保证了数据的一致性。所以，辅助域名服务器既可以运行域名服务器软件，也有域名数据库。另外，一个域名有且只有一个主域名服务器

4）域名解析过程

① 迭代查询
在这里插入图片描述
△☼▽

分析：C，最少情况下：当本机 DNS 高速缓存中存有该域名的 DNS 信息时，则不需要查询任何域名服务器，这样最少发出 0 次 DNS 查询；最多情况下：因采用迭代查询方式，在最坏情况下，需要依次迭代向本地域名服务器、根域名服务器（.com）、顶级域名服务器（xyz.com）、权限域名服务器（abc.xyz.com）发出 DNS 查询请求，因此最多发出 4 次 DNS 查询

② 递归查询
在这里插入图片描述

△☼▽（2010 年真题）

在这里插入图片描述

分析：A，如果主机所询问的本地域名服务器不知道被查询域名的 IP 的地址，那么本地域名服务器就以 DNS 客户的身份向其他服务器继续发出查询请求报文，而不是让该主机自己进行下一步的查询，所以主机只需向本地域名服务器发送一条域名请求即可；其次，因为递归查询一定要查到主机需要的 IP 地址才返回，所以本地域名服务器只需发送一条域名请求给根域名服务器即可

【FTP】

1）基本工作原理

FTP 的服务器进程由两大部分组成：一个主进程，负责接受新的请求；另外有若干个从属进程，负责处理单个请求

主进程的工作步骤如下：

打开熟知端口 21，使客户进程能够连接上
等待客户进程发出连接请求
启动从属进程处理客户进程发来的请求。 从属进程对客户进程的请求处理完毕后即终止，但从属进程在运行期间根据需要还可能创建其他一些子进程
回到等待状态，继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发进行的

（考虑一个 FTP 服务器同时服务多个客户进程，那么服务器在收到客户机的请求后会和客户机重新商议端口的问题，即考虑使用临时端口来替换出 20 号、21 号端口，因此，服务器就可以继续使用 20 号端口和 21 号端口进行监听，所以不存在端口被一直占用的问题）

当客户进程向服务器进程发出建立连接请求时，要寻找连接服务器进程的熟知端口 21，同时还要告诉服务器进程自己的另一个端口号码，用于建立数据传送连接。接着，服务器进程用自己传送数据的熟知端口 20 与客户进程所提供的端口号建立数据传送连接

△☼▽（2017 年真题）

在这里插入图片描述

分析：C，注意上面加粗的语句的表述，客户端用于建立数据连接的端口是客户进程告诉服务器进程的，也就是说客户端是否使用 20 号端口不一定，但服务器是使用 20 号端口与客户端提供的一个端口进行数据传送的

2）为什么 FTP 要需要两个独立的连接，即控制连接和数据连接？

在 FTP 的实现中，客户与服务器之间采用了两条传输连接，其中控制连接用于传输各种 FTP 命令，而数据连接用于文件的传送。之所以这样设计，是因为使用两条独立的连接可以使 FTP 变得更加简单、更容易实现、更有效率；同时在文件传输过程中还可以利用控制连接控制传输过程，如客户可以请求终止传输

3）细节理解

FTP 在传输层需要使用 TCP，FTP 本身是不具备差错控制能力，它使用 TCP 的可靠传输来保证数据的正确性
在同一会话期间，如果用户还需要传输另外一个文件，FTP 则会打开另一个数据连接。对 FTP 传输而言，控制连接贯穿了整个用户会话期间，但是对会话中的每一次文件传输都需要建立一个新的数据连接，传输结束就结束（即数据连接是非持续的）
FTP 并非对所有的数据传输都是最佳的。例如，计算机 A 上运行的运用程序要在远地计算机 B 的一个很大的文件末尾添加一行信息。若使用 FTP，则应先将此文件从 B 传送到 A，A 添加后，再用 FTP 将此文件传送回 B，如此的来回传送这样大的文件是很低效的。而此时则推荐使用 NFS，NFS 允许应用进程打开一个远地文件，并能在该文件的某一特定的位置上开始读写数据

△☼▽

在这里插入图片描述

分析：C，记住就行

△☼▽

在这里插入图片描述

分析：D，FTP 的数据端口号是控制端口号 - 1

【为什么在服务器端除了使用熟知端口外，还需要使用临时端口？】

TCP/IP 只能有一个熟知端口，这样才能使各地的客户机找到这个服务器，但建立多条连接又必须有多个端口。因此，在按照并发方式工作的服务器中，主服务器进程在熟知端口等待客户机发来的请求。主服务器进程一旦接收到客户机的请求，就立即创建一个从属服务器进程，并指明从属服务器进程使用一个临时端口和该客户机建立 TCP 连接，然后主服务器进程继续在原来的熟知端口等待，向其他客户及提供服务

【主机 A 向下载文件 ftp://ftp.abc.eu.cn/file，大概描述下载过程中主机和服务器的交互过程】

建立一个 TCP 连接到 ftp.abc.eu.cn 的 21 端口，然后发送登录账号和密码；
服务器返回登录成功信息后，主机 A 打开一个随机端口，并将该端口发送给服务器
主机 A 发送读取文件命令，内容为 get file，服务器使用 20 号端口建立一个 TCP 连接到主机 A 的随机打开的端口
服务器把文件内容通过数据连接发送给主机 A，传输完毕连接关闭

【SMTP】

SMTP 是一个基于 ACSII 码的协议，它只能够传送 7 比特的 ACSII 码，如果要传输非 ACSII 码的数据，需要使用 MIME 协议来将数据转换成 ACSII 码的形式

从下图可知，SMTP 协议用于用户代理向邮件服务器发送邮件，或在邮件服务器之间发送邮件

在这里插入图片描述

【POP3】

POP3 是使用明文来传输密码的，并不对密码进行加密
POP3 是基于 ACSII 码的，如果要传输非 ACSII 码的数据，需要使用 MIME 协议来将数据转换成 ACSII 码的形式
POP3 的一个特点是只要用户从 POP 服务器读取了邮件，POP 服务器就将该邮件删除
（区别一个说法：POP3 是由客户端决定是否将已收取的邮件保留在服务器的，怎么理解？POP 服务器会将用户的邮件从服务器上的信箱下载到客户端的计算机上，并且在服务器删除这些邮件。虽然现在有些客户端通过设置可以在服务器上保留这些邮件，但是这些邮件只是作为副本被保存）

【MIME】

1）quoted-printable 编码

ACSII 码字符保持不变，非 ACSII 码字符用 =XX 表示，其中 XX 是该字符的十六进制值，具体编码规则如下：

在这里插入图片描述

△☼▽

在这里插入图片描述

分析：0100 1100 和 0011 1100 是可打印的 ASCII 编码，将 1001 1101 表示为十六进制是 9D，在前面加上等号得 =9D，其 ASCII 编码为 00111101 00111001 01000100（需要查 ASCII 表对应转换），因此最后传送的 ASCII 数据为 01001100 00111101 00111001 01000100 00111001

2）base64 编码

不管是否是 ACSII 码字符，每 3 个字符用另 4 个 ACSII 码字符表示，具体编码规则如下：

在这里插入图片描述

△☼▽

在这里插入图片描述

分析：B
0 ~ 25 (011001)：A ~ Z，26 (011010) ~ 51(110011)：a ~ z，52 (110100) ~ 61 (111101)：0 ~ 9，62 (111110)：+，63 (111111)：/

110011 001000 000100 111000 $\rightarrow$ z I E 4 $\overset{转 ASCII 码}{\rightarrow}$ 122 73 69 52 $\overset{转二进制}{\rightarrow}$ (0111 1010) (0100 1001) (0100 0101) (0011 0100)

△☼▽

在这里插入图片描述

分析：C，根据上述理论描述可以得到如下的计算式 $\frac{99\times8}{6}\times8bit$

【WWW】

WWW 不是一种协议，而是应用层提供的一种最为重要和普及的服务
如果用户直接使用域名去访问一个 WWW 服务器，那么首先需要完成对该域名的解析任务。只有获得服务器的 IP 地址后，WWW 浏览器才能与 WWW 服务器建立连接，开始后续的交互。因此从协议执行过程来说，访问 WWW 服务器的第一步是域名解析
WWW 服务器是等待客户请求的一个自动程序。WWW 服务器接受请求后执行相应的动作，并把所要求的数据发送给客户机
WWW 服务器不要求具备网页的编辑功能，故用于编辑网页的计算机不能称为 WWW 服务器
虽然用户已创建的网页，并且有了国际互联网络连接，但并不意味着用户的网页就已经自动成为 WWW 的一部分了，故任何一台连入 Internet 并存储了网页的计算机也不能称为 WWW 服务器
如果没有进行正确的配置也不能完成WWW 服务器的功能，故我们装了 WWW 服务器程序的计算机亦不能叫做 WWW 服务器

△☼▽

在这里插入图片描述

分析：C，http 是内容标识符，表示使用的是 HTTP，http://www.zju.edu.cn 为域名或称主机名，/docs/cindex.html 为特定 web 资源名，即主机上的 web 文件

△☼▽

在这里插入图片描述

分析：D，即超链接

【HTTP】

1）持久连接/非持久连接

Connection：连接方式，Close 表示为非持续连接方式，keep-alive 表示持续连接方式

非持久连接：每一个网页元素对象的传输都需要单独建立一个 TCP 连接，换句话说，每请求一个万维网文档所需的时间是该文档的传输时间加上两倍往返时间（一个 RTT 用于 TCP 连接，另一个 RTT 用于请求和接收文档）

持久连接：万维网服务器在发送响应后仍然保持这条连接，同一个客户和服务器可以继续在这条连接上传送后续的 HTTP 请求和响应报文。持久连接又分为流水线和非流水线两种方式。对于非流水线方式，客户只能在收到前一个请求的响应后才能发送新的请求。而流水线方式是 HTTP 客户每遇到一个对象引用就立即发出一个请求，因而 HTTP 客户可以一个接一个连续第发出各个引用对象的请求。如果所有的请求和响应都是连续发送的，那么所有引用到的对象共经历一个 RTT 延迟

△☼▽（2015 年真题）

在这里插入图片描述

分析：C，根据上述理论，该浏览器请求使用的应是非持续连接方式；Cookie 值是由服务器产生的，HTTP 请求报文中有 Cookie 报头表示曾经访问过 www.test.edu.cn 服务器

△☼▽

在这里插入图片描述

分析：

（1）首先要指出的是图 6-18 中每行前面的 0000，0010，0020，0030，0040 不属于以太网帧的内容

IP 地址在 IP 报文中，应先找到 MAC 帧的数据部分，在按 IP 分组首部结构找到目的 IP 地址，即 40 aa 62 20，转换为十进制为 64.170.198.32

目的 MAC 地址为前 6 字节，即 00-21-27-21-51-ee，由于下一跳即为默认网关 10.2.128.1，故此时的目的 MAC 地址即为默认网关 10.2.128.1 端口的物理地址

（2）使用 ARP 协议确定目的 MAC地址，封装该协议请求报文的以太网帧的目的 MAC 地址为 ff-ff-ff-ff-ff-ff

（3）采用非流水线方式，客户机在收到一个请求响应后才能发送下一次请求，第一个请求用于请求 web 页面，后有 5 个小图像，故一共经过了 6 个RTT

（4）10.2.128.100 为私有地址，经路由器转发时源 IP 地址要发生变化，即变成 NAT 路由器的一个全球 IP 地址，也就是将 IP 地址 10.2.128.100 改为 101.12.123.15，即源 IP 地址 0a 02 80 64 改为 65 0c 7b 0f；另外，IP 分组每经过一个路由器，生存时间 TTL 减一，故生存时间字段由 80 改为 7f；当然，此时还需要重新计算首部校验和；最后，如果 IP 分组的长度超过链路所要求的最大长度，则 IP 分组就需要分片，此时 IP 分组的总长度字段、标志字字段以及片偏移字段都要发生改变

△☼▽

在这里插入图片描述

分析：
（1）非持续

因 web 页面的基本 HTML 文件、HTTP 请求报文、TCP 握手报文大小可忽略不计，所以不计发送时延。TCP 前两次握手消耗 $1 R T T$ ，第三次握手捎带一个 HTTP 请求，消耗 $0.5 R T T$ ，传送 HTML 文件消耗 $0.5 R T T$ ，到此为止共消耗 $2 R T T = 300 m s$ ，接着传送 $10$ 个 gif，需 $10$ 次 TCP 连接，传 $1$ 个gif 消耗 $(150 + 150 + 35) m s = 335 m s$ ，故，总共消耗 $300ms+335ms\times10 = 3650ms$

（2）持续

在此模式下，不管传输多少数据，只需要建立一次 TCP连接，故，总共消耗 $150ms\times2+(150ms+35ms)\times10$

△☼▽

在这里插入图片描述

分析：
IP 地址解析需要 $RTT_1+RTT_2+\cdots+RTT_n$
建立 TCP 连接和请求网页需要 $2RTT_w$
故，一共经过 $RTT_1+RTT_2+\cdots+RTT_n+2RTT_w$ 的时间

△☼▽

在这里插入图片描述

分析：首先要知道的是这 4 个对象不是同一层次的，应该是一个树的结构，树高为 2，如下所示：

（1）对于没有并行 TCP 连接的非持续 HTTP，每访问一个 URL 对象就要建立一个 TCP 连接，故总的所需时间为 $RTT_1+RTT_2+\cdots+RTT_n+8RTT_w$

（2）对于使用并行 TCP 连接的非持续 HTTP，对一级建立一个 TCP，耗时 $1RTT_w$ ，向二级并发建立 TCP，耗时 $1RTT_w$ ，再向每一级请求 www 文档，各耗时 $1RTT_w$ （注意是向每一级请求，这里有两级，所以是 $2RTT_w$ ），故总的所需时间为 $RTT_1+RTT_2+\cdots+RTT_n+4RTT_w$

（3）对于使用流水线方式的持续 HTTP，计算机只需建立一个对象流水线的连接，耗时 $1RTT_w$ ，并保持，向一级对象请求万维网文档耗时 $1RTT_w$ ，向二级对象请求万维网文档耗时 $1RTT_w$ ，故总的所需时间为 $RTT_1+RTT_2+\cdots+RTT_n+3RTT_w$