关于面试问题:网络面试题集锦

关注公众号: 高性能架构摸索。后盾回复【材料】，能够收费支付

笔者从事后端技术十余年，期间也面试他人，也有被他人面试，明天特意将这些面试的知识点总结下，心愿可能在工作或者面试中帮忙到大家。

说说 OSI 模型和 TCP/IP 模型

OSI(Open System Interconnection，开放式通信互联) 是由 ISO(International Organization for Standardization，国际标准化组织) 制订的规范模型。旨在将世界各地的各种计算机互联。然而，OSI 模型过于宏大、简单。参照此模型，技术人员开发了 TCP/IP 协定栈，简化 OSI 七层模型为 TCP/IP 四层模型。取得了更宽泛的应用。

OSI 模型和 TCP/IP 模型比照：

什么是 TCP

TCP(Transmission Control Protocol 传输控制协议)是一种面向连贯 (连贯导向) 的、牢靠的、基于 IP 的传输层协定。

TCP 是如何保证数据牢靠的

• 通过数据流的形式传输，将数据截成正当的长度；
• 对每段报文进行编号，保障数据流的程序；
• 收到数据进行重排序，并且抛弃反复数据；
• 收到报文后，给出确认响应；
• 超时重发；
• 校验和；
• 流量管制（针对本程序的承受能力）和拥塞管制（针对整个网络）。

说说 TCP 和 UDP 的区别

协定差异

区别总结：

• TCP 的面向连贯的，在发送数据之前要建设连贯；UDP 是无连贯的，即发送数据之前不须要建设连贯；
• TCP 提供牢靠的服务，通过 TCP 连贯传送的数据，不失落，不反复，且按序达到。UDP 尽最大致力交付，不保障牢靠交付；
• TCP 面向字节流，把数据看成一连串无构造的字节流；UDP 是面向报文的，对应用程序的报文既不拆分也不合并；
• TCP 有流量管制和拥塞管制，UDP 没有拥塞管制；
• TCP 连贯只能是点到点的，UDP 反对一对一，一对多，多对一和多对多的交互通信；
• TCP 首部至多开销 20 字节，UDP 的首部构造简略，开销小，只有 8 个字节；
• 因为 TCP 要保护连贯和保障可靠性，所以对系统资源的要求较多，UDP 绝对要小得多。

TCP 建设连贯的过程

TCP 建设连贯产生在 client 端调用 connect 零碎调用的时候。其目标是为了对每次发送的数据量进行跟踪与协商（即替换单方窗口大小），确保数据段的发送和接管同步，依据所接管到的数据量而确认数据发送、接管结束后何时吊销分割，并建设虚连贯。

TCP 建设连贯的过程，是一个三次握手的过程。

• 第一次握手：client 端向 server 发送连贯申请，SYN=1(SYN 示意发送端与接收端要建设连贯)，seq = x。此时 client 端进入 SYN_SENT 阶段
• 第二次握手：server 在收到 client 端的申请后，向 client 回复 SYN = 1（SYN 示意发送端与接收端要建设连贯）和 ACK = 1（示意对发送端申请进行应答），seq = y, ack = x + 1。此时 server 端进入 SYN_RCVD 阶段
• 第三次握手：client 端收到 server 端的申请和响应之后，同样须要向 server 端回复音讯。向 server 端发送 ACK = 1(示意对 server 端的响应)，seq = x + 1，ack = y + 1. 此时客户端进入 ESTABLISH 阶段。server 端在收到该 ACK 后，也进入 ESTABLISH 阶段。

艰深了解：

• A 想要和 B 通信，首先跟 B 说：“我想和你通信”；
• B 收到这条信息之后，回复 A 说：“收到。我也想和你通信”；
• A 收到之后就晓得，原来 B 也想通信，回复 B 说：“收到”。

上述三次握手过程，咱们用图示意为。

为什么建设连贯是 3 次，而不是 2 次或者 4 次

按理说，在客户端收到服务器发过来的确认报文后（第二次握手后），通信单方就能够确定对方的申请建设连贯的用意了，那为什么客户端还要再发送一次 ACK 报文呢？

次要是避免曾经生效的连贯申请报文又达到服务器端这种状况。

“曾经生效的连贯申请报文”是这样产生的：当网络环境差的时候，客户端发送的连贯申请报文可能失落，也有可能滞留在某个节点。当客户端期待肯定工夫后，没有收到服务器发送的确认报文，就认为之前发送的连贯申请报文生效了。客户端会再次发送连贯申请报文。

然而如果滞留在某个节点的报文通过长时间延迟后达到了服务器端，服务器并不知道这是一个生效的报文，它认为是客户端的失常连贯申请，就会返回确认报文，批准连贯建设。

如果采纳 2 次握手的办法，这时新的连贯曾经建设了。然而实际上，客户端并没有发动申请，它不会对服务端的确认报文做出反馈，更不会发送数据给服务端。而服务端却认为新的连贯曾经建设，始终再期待客户端发送数据，这样就造成了资源的节约。

而如果采纳 4 次握手的状况，就是将第二次 SYN 和 ACK 分成两步来操作，这样会浪费资源以及性能节约。

采纳 3 次握手就能够防止这样状况。上述的情景下，服务器没有收到客户端对本人发送过来的确认报文的 ACK 报文，就晓得客户端没有申请建设连贯。

TCP 断开连接的过程

当 client 端和 server 端的数据传输实现之后，就须要断开连接，以节俭资源。断开连接的过程，咱们个别称之为四次挥手(与建设连贯的三次握手绝对应)。

• 第一次挥手：client 端向 server 端发送断开连接的申请，通知 server 端，我这边不再须要跟你传输数据。发送 FIN=1(示意发送断开连接申请)，seq=x，此时 client 端处于 FIN_WAIT_1 阶段
• 第二次挥手：server 端在收到 client 端的断开申请后，须要通知客户端曾经收到申请。因而向 client 端回复 ACK=1，seq=y，ack=x+1(示意对 client 发送的 seq= x 进行确认)。此时 client 端处于 FIN_WAIT_2 阶段,server 端处于 CLOSE_WAIT 阶段。
• 第三次挥手：当 server 端不再须要与 client 端传输数据，就向 client 端发送断开连接的申请。FIN=1(示意发送断开连接申请)，ACK=1（示意对 client 端的上一次断开连接应答）。seq=z,ack=x+1(上一次断开连接申请时候 seq=x)。此时 server 端处于 LAST_ACK 阶段。
• 第四次挥手：client 端收到 server 端断开连接的申请后，需作出应答，因而 ACK=1.seq=x+1,ack=w+1（示意对上一次申请的应答）

艰深了解：

• A 没有数据发送，就和 B 说：“我没有数据给你了，然而如果你还有数据没发送完，则不用急着断开，还能够持续发送数据”；
• B 收到后，会通知 A 说：“收到。”，而后持续发送数据给 A；
• 当 B 端确定数据已发送实现，则通知 A：“好了，我这边数据发完了，筹备好敞开连贯了”；
• A 听到后，和 B 说：“好的，你断开吧。”，而后在期待 2MSL 工夫后断开。

至此，断开连接的过程解说结束，用图的形式如下：

为什么 client 要期待 2MSL 后才断开连接？

网络的状态是不确定的，最初 Client 发送的确认报文可能失落。如果确认报文失落并且 Client 不期待，间接断开连接。此时 Server 端在发送 FIN 报文后，不会收到任何响应。期待一段时间后，会重发 FIN 报文，但此时 Client 端曾经敞开。Server 就会始终重发 FIN 报文。而如果 Client 端处于期待状态时，就会回复确认报文给 Server，让 Server 敞开。同时，在 2MSL 内没有收到 FIN 报文，阐明 Server 端收到了确认报文，曾经敞开，这样本人也能够敞开了。2MSL 是从 Client 到 Server 工夫的 2 倍，也就是发送确认报文和承受 FIN 报文的工夫。

为什么 TCP 断开连接是 4 次

因为 TCP 是全双工，在一端断开连接之后，另外一端在须要的时候，也须要断开连接。每一端的断开须要两次，即 FIN 和 ACK，所以整个过程就是四次。

TCP 是怎么进行流量管制

TCP 必须要解决的牢靠传输以及包乱序的问题，所以，TCP 必须要晓得网络理论的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包。这就引入了滑动窗口和拥塞窗口。

在发送端通过拥塞窗口，在接收端通过滑动窗口。

滑动窗口协定是传输层进行流控的一种措施，接管方通过通告发送方本人的能够承受缓冲区大小（这个字段越大阐明网络吞吐量越高），从而管制发送方的发送速度，不过如果接收端的缓冲区一旦面临数据溢出，窗口大小值也会随之被设置一个更小的值告诉给发送端，从而控制数据发送量（发送端会依据接收端批示，进行流量管制）。

避免过多的数据注入到网络中，这样能够使网络中的路由器或链路不致过载。拥塞管制所要做的都有一个前提：网络可能接受现有的网络负荷。拥塞管制是一个全局性的过程，波及到所有的主机、路由器，以及与升高网络传输性能无关的所有因素。

在浏览器中输出一个 url 后，浏览器的行为

浏览器自身是一个客户端，当你输出 URL 的时候，首先浏览器会去申请 DNS 服务器，通过 DNS 获取相应的域名对应的 IP，而后通过 IP 地址找到 IP 对应的服务器后，要求建设 TCP 连贯，等浏览器发送完 HTTP Request（申请）包后，服务器接管到申请包之后才开始解决申请包，如果申请的资源蕴含有动静语言的内容，那么服务器会调用动静语言的解释引擎负责解决“动静内容”，并将解决失去的数据装在 HTTP Response（响应）包返回给客户端；客户端收到来自服务器的响应后开始渲染这个 Response 包里的主体（body），等收到全副的内容随后断开与该服务器之间的 TCP 连贯。