前端面试题--计算机网络

1. 七层网络协议体系结构的理解

学习计算机网络时我们一般采用折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。

• 应用层：为操作系统或网络应用程序提供访问网络服务的接口；
• 表示层：将应用处理的信息转换为适合网络传输的格式，或将来自下一层的数据转换为上层能处理的格式；主要负责数据格式的转换；
• 会话层：进行通讯管理，负责建立和断开通讯连接；
• 传输层：负责向两台不同网络下主机进程之间的通信提供通用的数据传输服务。
• 网络层：提供逻辑地址(IP)，为不同局域网的主机通讯提供路由寻址，将数据传输到目标地址；
• 数据链路层：管理相邻节点之间的数据通信；
• 物理层： 将数据转化为比特流，设备之间的比特流传输。

2. 五层协议中各自对应的网络协议

计算机五层网络体系中涉及的协议非常多，下面就常用的做了列举：

• 应用层：
  • 超文本传输协议：HTTP，HyperText Transfer Protocol
  • 文件传输协议：FTP，File Transfer Protocol
  • 域名系统：DNS，Domain Name System
  • 安全外壳协议：SSH，Secure Shell
  • 动态主机配置协议：DHCP，Dynamic Host Configuration Protocol
  • 远程登录协议：TELNET
• 传输层
  • 传输控制协议：TCP，Transmission Control Protocol
  • 用户数据报文协议：UDP，User Datagram Protocol
• 网络层
  • 网际协议：IP，Internet Protocol
  • 地址转换协议：ARP，Address Resolution Protocol
  • 反地址转换协议：RARP，Reverse Address Resolution Protocol
  • 控制报文协议：ICMP，Internet Control Message Protocol
  • 网际组管理协议：IGMP，Internet Group Management Protocol
  • 路由信息协议：RIP，Routing Information Protocol
  • 路由器选择协议：OSPF，Open Shortest Path First
  • 边界网关协议：BGP，Border Gateway Protocol
• 数据链路层
  • 自动重传请求协议：ARQ，Automatic Repeat-reQuest
  • 停止等待协议：CSMA/CD，Carrier Sense Multiple Access with Collision Detection
  • 点对点协议：PPP，Point to Point Protocol

3. ARP 协议的工作原理

网络层的 ARP 协议完成了 IP 地址与物理地址(MAC地址)的映射。

解释：ARP(Address Resolution Protocol)

首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。

此 ARP 请求数据包里包括：源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

RARP（Reverse Address Resolution Protocol），逆地址解析协议，根据MAC地址来获取IP地址

4. IP 地址分类的理解

IP 地址是指互联网协议地址，是 IP 协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP 地址编址方案将 IP 地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。

每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID。同一个物理网络上的所有主机都使用同一个网络 ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：

A 类地址：以 0 开头，第一个字节范围：0~127；

B 类地址：以 10 开头，第一个字节范围：128~191；

C 类地址：以 110 开头，第一个字节范围：192~223；

D 类地址：以 1110 开头，第一个字节范围为 224~239；

E 类地址：以 1111 开头，保留地址

5. TCP 的主要特点 ❗️❗️Transmission Control Protocol

1. TCP 是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；
2. 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）；
3. TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达；
4. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
5. TCP面向字节流。TCP 中的“流”（Stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

6. UDP 的主要特点

1. UDP 是无连接的；
2. UDP 支持一对一、一对多、多对一和多对多的交互通信；
3. UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
4. UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如：直播，实时视频会议等）；
5. UDP 是面向报文的；
6. UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

7. TCP 和 UDP 的区别

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会四次挥手断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。且 TCP 不提供广播或多播服务。

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如：QQ 语音、 QQ 视频 、直播等等。

8. TCP & UDP 对应的常见应用层协议

• TCP 对应的应用层协议

FTP(File Transfer Protocol)：定义了文件传输协议，使用 21 端口。 常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。

HTTP(Hyper Text Transfer Protocol)：超文本传输协议，使用80端口，从 Web 服务器传输超文本到本地浏览器的传送协议。

SMTP(Simple Mail Transfer Protocol)：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。

POP3(Post Office Protocol - Version 3)：邮局协议版本3，它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163 邮箱就没有必要先进入网易网站，再进入自己的邮箱来收信）。

2. UDP 对应的应用层协议

DNS(Domain Name System)：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

SNMP：Simple Network Management Protocol 简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

9. TCP 三次握手的过程

三次握手：TCP 建立连接的过程叫做握手，握手需要在客户端和服务器之间交换三个 TCP 报文段。

服务端的 TCP 服务器进程首先创建传输控制块 TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。

是为了在不可靠的信道中建立可靠的连接

第一次握手：

1. 客户端创建传输控制块，向服务器端发出请求报文段；
2. 报文段中包括：同步位 SYN=1，初始序号 seq = x；
3. TCP 客户端进程进入 SYN-SEND（同步已发送）状态。

第二次握手：

1. 服务端收到连接请求报文后，向客户端发送确认报文段；
2. 报文段中：同步位 SYN=1，确认位 ACK =1，选择一个初始序号 seq = y，确认号 ack = x + 1；
3. 服务端进程进入 SYN-RCVD（同步收到）状态

第三次握手：

1. 客户端收到服务端的确认后，再向服务端发出确认应答报文；
2. 确认报文段：确认位 ACK =1，确认号 ack = y + 1，自己的序号 seq = x + 1
3. 这时，TCP 连接已经建立，客户端进入 ESTABLISHED（已建立连接）状态；
4. 服务器端收到这个信号后也进入 ESTABLISHED（已建立连接）状态。

10. 两次握手不可以理由

为了防止已经失效的连接请求报文段突然又传送到了，因而产生错误。

比如下面这种情况：客户端发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达服务端。本来这是一个早已失效的报文段。但是服务端收到此失效的链接请求报文段后，就误认为客户端又发出一次新的连接请求。于是就向客户端发出确认报文段，同意建立连接。

对于上面这种情况，如果不进行第三次握手，服务端发出确认后就认为新的传输连接已经建立了，并一直等待客户端发来数据。这样服务端的许多资源就这样白白浪费了。

如果采用了三次握手，由于客户端实际上并没有发出建立连接请求，所以不会理睬服务端的确认，也不会向服务端发送数据。服务端由于收不到确认，就知道客户端并没有要求建立连接。

11. 不需要四次握手的理由

有人可能会说客户端发出第三次握手的信息后在没有接收到服务器端的确认请求就已经进入了连接状态，那如果客户端的这个确认包丢失或者滞留了怎么办？

我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。

12. 关于SYN的进一步说明

服务端收到客户端的 SYN 后需要传回 SYN 理由？

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

SYN 是 TCP / IP 建立连接时使用的握手信号。 在客户端和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN+ACK 应答表示接收到了这个消息，最后客户机再以 ACK 消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

Acknowledgement，确认字符，在数据通信传输中，接收端发给发送端的一种传输控制字符。它表示确认发来的数据已经接受无误

传了 SYN 还要传 ACK 理由？

双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

13. TCP 四次挥手的过程

据传输结束后，通信的双方都可以释放连接。现在 客户端 和 服务端 都处于 ESTABLISHED 状态。

seq：sequence Number；ack：acknowledge Number

第一次挥手：

1. 客户端向服务器端发送连接释放报文段，主动关闭连接；

2. 报文段中：终止控制位 FIN = 1，序号 seq = u；

   seq 等于前面已传送过的数据的最后一个字节的序号加 1

3. 客户端进入 FIN-WAIT-1（终止等待-1）状态，等待服务端的确认。

第二次挥手：

1. 服务端接受到连接释放报文段后立即发出确认；

2. 报文段中：确认位ACK =1，序号 seq = v，确认序列号ack = u + 1；

3. 服务端进入 CLOSE-WAIT（关闭等待）状态

   TCP 服务端进程这时应通知高层应用进程，因而从客户端到服务端这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即客户端已经没有数据要发送了，但服务端若发送数据，客户端仍要接收。也就是说，从服务端到客户端这个方向的连接并未关闭，这个状态可能会持续一段时间。

4. 客户端收到来自服务端的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待服务端发出的连接释放报文段。

第三次挥手：

1. 服务端已经没有要向客户端发送的数据，服务端发出的连接释放报文段；
2. 报文段：终止控制位 FIN = 1，确认位ACK =1，序号 seq = w，确认序列号是 ack = u + 1；
3. 服务端就进入LAST-ACK(最后确认)状态，等待客户端的确认。

第四次挥手：

1. 客户端在收到服务端的连接释放报文后，必须对此发出确认；
2. 报文段：确认位ACK =1，序号seq = u + 1，确认序列号是 ack = w + 1；
3. 进入TI