【八股cover#3】计网 Q&A与知识点

计网知识点Q&A

简历cover

1、TCP/IP网络模型

网络模型

​ TCP/IP 协议族，它是一个分层、多协议的通信体系。

​ TCP/IP协议族是一个四层协议系统，自底而上分别是数据链路层、网络层、传输层和应用层。

​ 在 TCP/IP 协议中，OSI 模型被简化为了四个层次。

​ 应用层是网络的最高层，它提供用户接口和服务，比如HTTP、FTP和SMTP等协议。

​ 传输层主要负责数据的可靠传输和错误检测，其中最常见的协议为TCP和UDP。

​ 网络层则负责数据包的路由和寻址，常用的协议有IP、ICMP和IGMP等。

​ 数据链路层则负责物理传输介质的访问和帧同步，常用的协议包括ARP协议和PPP等

IP协议

​ IP协议是网络层的协议，主要负责将数据报从发送端传输到接收端，它只关心源地址和目标地址的传输。

TCP协议和UDP协议

​ TCP协议和UDP协议则位于传输层，是在IP协议之上的协议。

​ TCP协议提供面向连接的可靠数据传输，而UDP协议则提供无连接的不可靠数据传输。

​ 应用程序可以根据需要选择使用TCP或UDP来进行数据传输。

HTTP/HTTPS协议

​ HTTP协议【明文传输】则是应用层的协议，它基于TCP协议或UDP协议传输数据，用于在Web浏览器和Web服务器之间传输超文本（HTML）文档和其他文件。

​ HTTPS【加密传输】是在HTTP之上加入了SSL（安全套接字层）或TLS（传输层安全）协议，以提供加密和身份验证功能。

​ HTTP/HTTPS协议定义了客户端和服务器之间的请求和响应消息格式，以及如何处理这些消息。

​ 因此，在进行Web通信时，通常使用TCP协议作为底层传输协议，然后使用HTTP/HTTPS协议来处理具体通信内容。

TCP和UDP的区别

​ TCP和UDP都是网络传输协议，二者最大的区别在于TCP提供可靠的数据传输服务，而UDP则不保证数据传输的可靠性。

​ TCP是面向连接的，需要经过三次握手建立连接，只能支持一对一点对点通信，保证数据可靠交付，具有确认应答和重传机制。TCP基于字节流传输，没有边界，但保证传输顺序和可靠性。数据大于MSS(最大报文段长度)时会在TCP层将数据进行分片传输，到达目的地后同样在传输层进行合并；如果有某个片丢失，则只需要重传丢失的分片即可。

​ UDP不需要连接，可以即刻传输数据，支持一对一、一对多、多对多通信，但不保证可靠性。UDP继承了IP层特性，基于数据包传输，有边界，可能出现乱序和丢包。UDP首部固定长度为8字节，数据大于MTU(最大传输单元)时会在IP层分片，也需要在目的IP层合并，但如果某个分片丢失，则需要将所有分片都进行重传，开销大。

细节：

1、连接

TCP是面向连接的，在传输前需要三次握手建立连接，UDP不需要连接，即刻传输数据

2、服务形式

TCP只能一对一，点对点服务，UDP支持一对一、一对多、多对多通信.

3、可靠性

TCP保证数据可靠交付，拥有确认应答和重传机制，无重复、不丢失、按序到达:UDP尽可能交付，不保证可靠性。

4、连接控制机制

TCP拥有流量控制、拥塞控制，保证传输安全性等，UDP在网络拥堵情况下不会降低发送速率

5、首部大小

TCP首部长度不适用选项字段是20字节，使用选项字段长度增加(可变)，UDP首部固定8字节。

6、传输方式

TCP基于字节流，没有边界，但是保证传输顺序和可靠性;UDP继承了IP层特性，基于数据包，有边界可能出现乱序和丢包

7、分片方式

TCP数据大于MSS时会在TCP层将数据进行分片传输，到达目的地后同样在传输层进行合并如果有某个片丢失则只需要重传丢失的分片即可;

UDP数据大于MTU时会在IP层分片，同样也在目的IP层合并，如果某个IP分片丢失，则需要将

所有分片都进行重传，开销大。

2、TCP三次握手四次挥手

过程

​ 在建立连接时【三次握手】，客户端首先向服务端发送一个SYN包，表示请求建立连接；服务端收到SYN包后回复一个ACK包，表示确认收到了客户端的请求，并且也发送一个SYN包给客户端，表示服务端也愿意建立连接；最后客户端收到服务端的SYN+ACK包后，回复一个ACK包给服务端，表示连接已经成功建立。

​ 而在关闭连接时【四次挥手】，客户端发送一个FIN包，表示请求关闭连接；服务端在收到FIN包后回复一个ACK包，确认收到了客户端的请求；然后服务端发送一个FIN包给客户端，表示服务端也愿意关闭连接；最后客户端收到服务端的FIN包后回复一个ACK包，确认收到了服务端的请求，并且连接已经彻底关闭了。

更详细的见：举例说明

三次握手过程如下：

1.客户端向服务端发送一个SYN包，其中SYN标识位被设置为1，表示请求建立连接。

2.服务端接收到客户端的SYN包后，回复一个ACK包，其中ACK标识位被设置为1，表示确认收到了客户端的请求，并且同时也发送一个SYN包给客户端，表示服务端也愿意建立连接。

3.客户端收到服务端的SYN+ACK包后，回复一个ACK包给服务端，表示客户端已经收到了服务端的确认，并且连接已经建立成功。

四次挥手过程如下：

1.客户端完成数据传输后，发送一个FIN包，其中FIN标识位被设置为1，表示请求关闭连接。

2.服务端收到客户端的FIN包后，回复一个ACK包，确认收到了客户端的请求。

3.服务端再发送一个FIN包给客户端，表示服务端也愿意关闭连接。

4.客户端收到服务端的FIN包后，回复一个ACK包，确认收到了服务端的请求，并且连接已经关闭。此时客户端和服务端的连接就彻底关闭了。

为什么需要三次握手？

​ TCP三次握手的主要目的是确保双方建立了可靠的通信连接，并且互相确认对方的身份，从而确保数据的安全性和准确性。采用三次握手可以达到以下目标：

1. 确认双方通信的能力。
2. 确认服务器和客户端的身份以及防止历史连接重复初始化。(主要原因)
3. 同步双方的初始序列号，确保数据按顺序接收。
4. 避免资源浪费，防止在有消息滞留时重复分配资源或无限制的建立连接。

相比于两次握手，三次握手可以更加严格地控制连接的建立过程，从而保证数据传输的可靠性和安全性。

如果使用的是两次握手，那么在收到服务器的相应后，客户端会立刻发送数据，就不能判断该连接是否存在问题

详细解释

什么是半连接队列？

服务器第一次收到客户端的SYN之后，就会处于SYN_RCVD状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

当服务器发送完 SYN-ACK 包后，如果未收到客户端的确认包，会进行重传，重传的等待时间通常是指数增长的。如果重传次数超过系统规定的最大重传次数，系统将从半连接队列中删除该连接信息。

这里在补充一点关于SYN-ACK 重传次数的问题： 服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。 注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s......

ISN(Initial Sequence Number)是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果ISN是固定的，攻击者很容易猜出后续的确认号，因此ISN是动态生成的。

三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。（客户端已经ESTABLISHED）但是，第一次、第二次握手不可以携带数据

第一次握手不可以放数据，如果允许携带数据会让服务器更加容易受到攻击。

而第二次不让带数据是为了处理逻辑一致，确保连接的可靠性和一致性。

SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。

SYN攻击是一种典型的DoS/DDoS攻击，它利用TCP三次握手过程中的漏洞来消耗服务器资源。攻击者伪造大量不存在的IP地址，并向服务器发送大量SYN包，服务器回复确认包并等待客户端确认，但由于源地址不存在，服务器需要不断重发直至超时。这些伪造的SYN包占用了服务器的未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。

在 Linux/Unix 上可以使用系统自带的netstats命令来检测SYN攻击。

常见的防御手段：缩短超时时间、增加最大半连接数、过滤网关防护、SYN cookies技术

为什么需要四次挥手？

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

TCP四次挥手是指在客户端和服务端断开连接时，需要进行的一系列通信过程，以保证数据传输的完整性和可靠性。

​ 其中，客户端发送FIN报文表示不再发送数据，但仍可以接收数据；服务端先回复一个ACK应答报文，等待处理未发送完成的数据后再发送自己的FIN报文。这种分开发送ACK和FIN的方式能够让服务端充分利用网络资源，并保证已经发送的数据都能够被接收方处理完毕。

​ 另外还有延迟确认机制，即接收方在收到包后，如果暂时没有内容回复给发送方，则延迟一段时间再确认。这样可以减轻网络负担，但有些情况下会影响网络性能。

​ 因此，TCP四次挥手是为了保证数据传输的可靠性和完整性，同时通过合理的机制让网络资源得到最优化利用。

2MSL等待状态

TIME_WAIT状态，也称为2MSL等待状态，是TCP连接关闭过程中的一个状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它限制了任何报文段在网络内传输的最长时间。

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

当TCP执行主动关闭并回复最后一个ACK时，连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样做的目的是为了确保对方收到最后的ACK，以防止ACK丢失，导致对方超时并重发最后的FIN。

2MSL等待的另一个结果是，在这段等待期间，定义连接的插口（客户端的IP地址和端口号，服务器端的IP地址和端口号）不能再被使用。只有在2MSL结束后，该连接的插口才能再次被使用。

TIME_WAIT状态的存在是为了保证连接关闭的可靠性，并在一段时间内防止重复使用相同的连接插口。

四次挥手释放连接时，等待2MSL的意义?

在TCP四次挥手释放连接过程中，等待2MSL的意义是为了确保客户端发送的最后一个ACK报文段能够到达服务器，防止可能丢失的ACK导致服务器无法正常关闭连接。

同时，等待2MSL还可以防止已失效的连接请求报文段在下一个新的连接中出现。这样，经过2MSL的时间，本连接产生的所有报文段都会从网络中消失，确保连接释放的可靠性和稳定性。如果客户端不等待2MSL，可能会导致服务器无法正确关闭连接，或者出现旧连接请求的问题。

因此，等待2MSL是为了确保连接释放过程的有效性和网络的稳定性。

为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

2.5、简述从输入URL到页面展示，这中间发生了什么

1、用户输入url并回车

2、浏览器进程检查url，组装协议，构成完整的url

3、浏览器进程通过进程间通信（IPC）把url请求发送给网络进程

4、网络进程接收到url请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程

5、如果没有，网络进程向web服务器发起http请求（网络请求），请求流程如下：

​ 5.1 进行DNS解析，获取服务器ip地址，端口

​ 5.2 利用ip地址和服务器建立tcp连接

​ 5.3 构建并发送 请求头信息

​ 5.4 服务器响应后，网络进程接收响应头和响应信息，并解析响应内容

6、网络进程解析响应流程；

​ 检查状态码，做对应的处理

如果是301/302，则需要重定向，从Location自动中读取地址，重新进行第4步，如果是200，则继续处理请求。

200响应处理：检查响应类型Content-Type，如果是字节流类型，则将该请求提交给下载管理器，该导航流程结束，不再进行后续的渲染，如果是html则通知浏览器进程准备渲染进程准备进行渲染。

7、准备渲染进程

​ 浏览器进程检查当前url是否和之前打开的渲染进程根域名是否相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程

8、传输数据、更新状态

​ 8.1 渲染进程准备好后，浏览器向渲染进程发起“提交文档”的消息，渲染进程接收到消息和网络进程建立传输数据的“管道”

​ 8.2 渲染进程接收完数据后，向浏览器发送“确认提交”

​ 8.3 浏览器进程接收到确认消息后更新浏览器界面状态：安全、地址栏url、前进后退的历史状态、更新web页面。

2.6、一个完整HTTP请求从客户端到后端再到客户端过程中，对应的7层模型的协议有哪些

OSI七层模型分别是：物理层、数据链路层、网络层、传输层、会话层、表示层以及应用层

一个完整的HTTP请求主要涉及了数据链路层、网络层、传输层和应用层。

在数据链路层中通过以太网协议将数据封装为帧进行物理传输，网络层则使用IP协议在网络中寻址和路由，确保数据包正确到达目的地。传输层中使用了TCP协议是数据在客户端和服务器之间可靠传输，同时确保数据顺序和完整性。最后，应用层中则使用HTTP协议在客户端和服务器之间进行超文本数据传输。

因为HTTP本身已经对数据进行了编码和解码处理，所以在HTTP请求中，一般没有特定的表示层协议。

且HTTP是无状态的，每个请求都是独立的，所以也没有专用的会话层协议。

综上，HTTP请求使用的更多是TCP/IP网络模型

表示层/会话层协议举例：FTP（文件传输协议）、SMTP（简单邮件传输协议）

3、流量控制

​ 流量控制是指在通信过程中，通过一定的机制控制数据发送方和接收方之间的数据传输速率，以避免网络拥塞、数据丢失和延迟等问题。

其中，滑动窗口就是流量控制中常用的一种机制。滑动窗口协议的优点是能够在保证数据可靠性的前提下实现高效的数据传输。

通过使用滑动窗口，发送方可以根据接收方的当前状态进行数据发送，而接收方也能够控制自己能够处理的数据块数量，从而避免了资源浪费和性能下降的问题。

滑动窗口机制中什么是"窗口"？

​ 滑动窗口是一种解决TCP通信过程中数据确认应答效率低下的机制。

​ 它通过指定一个窗口大小来实现，窗口大小即为可以连续发送数据而无需等待确认应答的最大值。

​ 操作系统会开辟一个缓存空间作为窗口，发送方主机必须在缓存区中保留已发送的数据直到收到确认应答。如果确认应答按期返回，数据就可以从缓存区清除。这样即使往返时间较长，也不会降低网络通信效率。

什么决定窗口的大小？

​ TCP头部中的window字段代表接收端可以接收多少数据。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据，因此发送端就可以根据接收端的处理能力来发送数据，而不会导致接收端处理不过来。窗口大小通常由接收方的窗口大小来确定。

简单来说，窗口大小是滑动窗口机制中用来调节数据传输速率和防止网络拥塞的重要参数，它能够提高通信效率并优化网络性能。

滑动窗口机制中的发送方与接收方

​ 发送方和接收方都可以使用滑动窗口协议来进行数据传输。在这种协议中，发送方将数据分成固定大小的数据块，并按顺序发送到接收方。接收方通过使用滑动窗口来控制它所期望接收的数据块。

​ 在发送方，滑动窗口是指已经发送但尚未被确认的数据块序列。发送方通过不断地向接收方发送新的数据块并等待确认消息，来逐步扩大它的滑动窗口。如果发送方收到了确认消息，则可以将对应的数据块从滑动窗口中删除。

​ 在接收方，滑动窗口是指已经接收但尚未被处理的数据块序列。接收方通过维护一个期望接收的下一个数据块编号以及一个可接受的最大编号来限制滑动窗口的大小。接收方会发送确认消息，告诉发送方它已经成功接收了某个数据块，同时也会更新其期望接收的下一个数据块编号。

4、阻塞控制

拥塞控制是防止网络过载的重要机制，通过调整发送方维护的状态变量（拥塞窗口cwnd），来适应网络拥塞程度。

发送方会根据接收方反馈的窗口值和自身的拥塞窗口值，选择较小的值作为发送窗口的大小。如果发送方在规定时间内没有接收到ACK应答报文，即发生了超时重传，就认为网络出现了拥塞，并减小拥塞窗口cwnd的值，以缓解网络拥塞情况。

常见的拥塞控制方法有以下几种：

1. 慢启动：在开始传输数据之前，发送方会发送一些小的数据包进行测试，并逐渐增加发送速率，以确定网络的容量。
2. 拥塞避免：当发送方确定了网络的容量后，它会逐渐增加数据包的大小和发送速率，直到网络出现拥塞的迹象。
3. 快重传：在接收方发现缺失的数据包时，会通知发送方并请求重新发送，发送方则会马上重传该数据包，从而避免了缺失数据包的重复发送和拥塞突发。
4. 快恢复：当发送方接收到接收方的缺失数据包的三次冗余确认时，会认为网络已经过载，并减少发送数据包的数量，等待网络空闲时再逐渐增加发送速率。

举例

假设有一个视频直播平台，用户可以通过该平台观看直播视频。在这个场景中，存在大量的用户同时观看不同的直播内容，导致网络可能会出现拥塞现象。此时就可以使用阻塞控制的方法来缓解该问题

**慢启动**：当一个用户刚开始观看直播时，发送方会以较小的发送速率发送数据包，以测试网络的容量。随着时间的推移，发送方逐渐增加发送速率，确保网络能够承载更多的数据流量。

**拥塞避免**：发送方通过观察接收方返回的窗口值和自身的拥塞窗口值，逐渐增加数据包的大小和发送速率。当网络出现拥塞的迹象时，发送方会适时减少发送速率，避免造成更严重的网络拥塞。

**快重传和快恢复**：在视频直播过程中，如果接收方发现有丢失的数据包，它会立即通知发送方请求重新发送这些数据包。发送方会快速响应，重传丢失的数据包，并不断调整发送速率，以适应网络的实际情况。

通过这些拥塞控制机制，视频直播平台能够在高并发的情况下，保持网络的稳定性和可靠性，确保用户能够流畅观看直播内容，同时避免网络过载导致的延迟和数据丢失问题。

补充问题（也重要）

网络传输的时候什么时候用大端什么时候用小端？

​ 当进行网络传输时，通常会使用大端字节序，因为它可以保证数据在不同计算机之间的一致性。（因为发送方按一定顺序发送，而接收方按规定顺序解包）

​ 而对于某些特定的硬件设备或协议，我们需要了解其所使用的字节序，并在必要时进行字节序转换。（如小端字节序）

NAT技术有了解吗?

​ NAT（Network Address Translation）是一种网络地址转换技术，用于在私有网络和公共网络之间转换网络地址。它通常用于家庭或小型办公室网络中，使得多个设备可以通过单个公共IP地址访问互联网。用于解决IP地址不足的问题.

​ NAT技术主要有三种类型：静态NAT、动态NAT和PAT（Port Address Translation）。

​ 静态NAT将一个内部IP地址映射到一个特定的公共IP地址，而动态NAT则根据需要分配公共IP地址。PAT使用单个公共IP地址来代表多个内部IP地址，通过端口号来区分这些内部地址。

​ 除了用于连接互联网外，NAT还可以用于连接两个私有网络。在此情况下，NAT被称为网关NAT（Gateway NAT），因为它充当两个网络之间的网关。总的来说，NAT技术是一种重要的网络技术，尤其是在面对IP地址不足的问题时，能够帮助解决连接问题。

如何探知一个tcp连接是否存活？

​ 你可以通过发送一个TCP Keep-Alive包来检测一个TCP连接是否存活。Keep-Alive是一种特殊的TCP数据包，用于在没有数据传输的情况下保持TCP连接的活性。当服务器收到客户端发送的Keep-Alive包时，它会响应一个ACK（确认）包，这表明该连接仍然处于活动状态。

如果服务器在一定时间内没有收到客户端的Keep-Alive包，则认为该连接已经死亡，并关闭连接。