面试经验｜计算机网络面试相关知识

1.OSI七层模型

• 1.物理层：定义接口特性、传输模式（单工、半双工、双工）、传输速率、比特同步、比特编码（曼彻斯特编码）。

802.3、Rj45

• 2.数据链路层：成帧、流量控制、差错控制、访问控制（对信道的控制）

SDLC、HDLC、PPP、STP

• 3.网络层：提供点到点通信。流量控制、差错控制、路由选择、拥塞控制。

IP、IPX、ICMP、IGMP、ARP、RARP、OSPF

• 4.传输层：提供端到端通信。流量控制、差错控制、复用分用、可靠传输（TCP）与不可靠传输（UDP）

1）复用：多个应用层进程可以同时使用下面运输层的进程

2）分用：运输层把收到的信息分别交付给上面应用层中相应的进程。

• 5.会话层：建立、管理、终止会话。使用校验点可以使得在通信失效时从校验点回复通信。

ASP、ADSP

• 6.表示层：数据的压缩与恢复、数据的加密与解密、数据格式变换。 JEPG、ASCII
• 7.应用层：所有能同用户交互产生网络流量的程序。HTTP(万维网) FTP(文件传输) SMTP(电子邮件)

2.TCP/IP参考模型与五层参考模型

• TCP/IP参考模型：网络接口层、网际层、传输层、应用层
• 实际的五层参考模型：物理层、数据链路层、网络层、传输层、应用层

3.简述TCP三次握手过程

为什么需要三次握手？最主要的目的是双方确认自己与对方的发送与接受都是正常的。

1.第一次握手：客户端将SYN=1，随意产生一个序列号seq=x，将该数据包发送给服务端，客户端等待服务端确认

2.第二次握手：服务端收到标志位SYN=1知道客户端请求建立连接，将SYN和ACK置为1，随机生成一个值seq=y，并发送ack=x+1

3.第三次握手：客户端收到后确认检查，将ACK=1，ack=y+1，seq=x+1，并将数据包发送给服务端，服务端进行检查如果正确则连接建立成功，之后可以开始传输数据。

4.两次握手行不行？

不行。主要是防止已经失效的链接请求报文又传送到服务器，产生错误，客户端发送的第一个链接请求可能没有丢失，只是因为在网络中滞留的时间过长。

1）由于TCP客户端没有收到确认报文，以为服务器没有收到，此时重新给服务器发送报文，服务器与客户端两次握手建立连接，传输数据然后关闭链接

2）此时滞留的连接请求到达服务器端，本身应该失效，但由于两次握手机制客户端与服务端再次建立连接，导致不必要的错误与资源的浪费

3）如果是三次握手，失效的报文到达服务端，服务端会向客户端发送确认，但客户端不会再次确认，由于服务端没有收到确认，并不会建立连接

5.SYN洪泛攻击

利用TCP协议缺陷，发送大量的伪造TCP连接请求，常用假冒的IP和IP段发来海量的第一个握手包（SYN包），被攻击的服务端发送SYN/ACK包，等待客户端发送第三个握手包，但由于对方是假冒的IP，永远不会接受到第三个握手包，使得服务器的正常业务受到影响。

解决方法：SYNcookies技术

SYNcookies技术

当服务端收到SYN请求连接时，不直接为TCP分配资源，而是打开一个半开的套接字，使用SYN报文的源ID、目的ID、端口号和加密函数生成一个cookie，将cookie作为序列号发送给客户端。如果是正常链接，客户端会发送cookie+1的报文段，服务器会进行计算检查，如果正确则证明是正常的连接请求，此时才分配TCP资源

6.三次握手的最后一次回复丢失会发生什么？

如果第三次ACK在网络中丢失，服务器端会保持半连接状态，根据超时重传机制服务端会等待3、6、12s重新发送SYN/ACK包，如果指定次数之后还未收到应答，服务端就关闭链接。但客户端会认为此时连接已建立，如果发送数据，服务端会返回RESET包，客户端就知道第三次握手失败了。

7.TCP四次挥手

A为主动断开方，B为被动断开方

a向b发送FIN用来关闭之间的数据连接，b收到之后返回ACK报文，确认序号为收到的信号+1。b向a发送FIN表示关闭链接，a向b发送ACK报文表示确认，并将确认序号设置为收到序号+1.

为什么连接是三次握手？断开是四次挥手

1）在建立连接时，服务端处于listen状态下，把SYN与ACK放在一个报文段里发送给客户端。

2）关闭链接时，服务端接收到对方发送的FIN报文，仅表明对方不发送数据，服务端仍然可以发送数据，等数据发送完之后，再发送FIN报文告诉对方同意关闭，因此服务器的FIN与ACK是分开发送的，多了一次。

为什么TCP挥手每两次之间有一个wait等待时间？

主动关闭的一方再发送完数据之后进入wait状态，等待接收数据，如果此时被动关闭一方由于宕机等原因，使得主动关闭方不能收到被动关闭一方的FIN，就需要一个定时器，如果超时直接释放这个链接。

为什么客户端最后还要等2MSL?为什么还要TIME-WAIT等待时间

1）MSL是最大报文生存时间，一个MSL是30s，两个是60s

2）为了保证客户端发送的最后一个ACK报文发送到服务端，因为服务端在发送完ACK+FIN报文请求断开连接之后，客户端发送的ACK报文丢失，因此服务端会再次向客户端发送一次，而客户端就会在这个2MSL中收到这个重传报文，给出回应。

3）防止已经失效的连接请求报文段重新出现在连接中，客户端发送完ACK报文之后，可以使在该链接内产生的所有报文段都从网络中消失，保证新的连接不会出现旧连接的请求报文段

TIME-WAIT状态过多会产生什么后果 ？

短时间过多的短链接，会消耗服务端的资源/消耗客户端的端口，使得部分客户端连接不上，客户端无法发起新的链接。

在高并发短连接的TCP服务器上，可能会出现大量socket处在TIME_WAIT状态，如果并发量持续很高，部分客户端就会显示连接不上。高并发会让服务器短时间内占用大量端口，但是端口范围是0～65536，是有限的。短连接表示业务处理和传输数据的时间远小于TIMEWAIT超时的时间都连接。

解决办法：负载均衡；强制关闭，发送RST越过TIMEWAIT状态，直接CLOSE；设置SO_REUSEADDR套接字选项避免TIME_WAIT状态。

8.TCP流量控制与拥塞控制

• 流量控制：接收方控制发送方发送数据的速率，确保接收方来得及接收。接收方通过发送的确认报文的窗口字段来控制发送方窗口的大小，从而影响发送速率。
• 滑动窗口：窗口是缓存的一部分，用来暂时存放字节流，发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其他信息设置自己的窗口大小。
• 拥塞控制：发送方设置拥塞窗口的值，防止过多的数据注入到网络中，使得网络中的路由器或链路不至于过载。是一个全局宏观调控的过程。
• 慢开始与拥塞避免：发送方最开始执行慢开始算法，拥塞窗口为1，收到确认后，拥塞窗口大小加倍。当拥塞窗口大小大于等于门限值时，使用拥塞避免算法，每个轮次只将拥塞窗口+1，如果出现超时，就让门限值等于当前拥塞窗口的1/2，并重新执行慢开始。
• 快重传与快回复：在接收方，每次收到报文段都应该对最后一个已经收到的有序报文段进行确认。发送方如果连续三次收到三个重复的确认，说明下一个报文段是丢失的，此时执行快重传算法，立即重传下一个报文段，在这种情况下只是丢失个别报文段，而不是网络拥塞。此时执行快恢复算法，令门限值为拥塞窗口的二分之一，并让拥塞窗口等于新的慢开始门限，执行拥塞避免算法。

9.HTTP与HTTPS的区别

HTTP：超文本传输协议。设计HTTP最初的目的是为了提供一种发布和接受HTML页面的方法，使浏览器更加高效。HTTP协议以明文的方式发送信息，如果黑客截取了Web浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

HTTPS：以安全为目标的HTTP通道，安全基础是SSL协议。HTTPS的设计目标是数据完整性、数据保密性、身份校验安全性。

HTTP与HTTPS的区别

1）HTTP以明文的方式发送数据，HTTPS则是具有安全性的SSL加密传输协议。

2）HTTPS协议需要使用到CA认证证书

3）HTTP简单连接无状态。（无状态是指数据包的发送、接收、传输都是相互独立的，通信双方都不长久的维持对方的信息）

10.简述DNS解析过程

DNS：基于UDP的应用层协议，功能是根据用户输入输入的域名，解析出该域名对应的IP地址，从而给客户端访问。

递归方式：

1）客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会将请求发送给本地dns服务器

2）本地dns服务器会在自己的区域里面查找，找到即根据此记录进行解析，若没有找到，就会在本地的缓存里面查找

3）本地服务器没有找到客户机查询的信息，就会将此请求发送到根域名dns服务器

4）根域名服务器查找对应的顶级域名服务器

5）顶级域名服务器查找对应的权限域名服务器

6）权限域名服务器查找到对应的IP地址，并将该地址返还给主机

递归与迭代相结合：

1）客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会递归查询将请求发送给本地dns服务器

2）本地域名服务器迭代查询根域名服务器，根域名服务器返回对应的顶级域名服务器地址

3）本地域名服务器查询顶级域名服务器，顶级域名服务器返回对应的权限域名服务器

4）本地域名服务器查询权限域名服务器，权限域名服务器返回相应的IP地址

5）本地域名服务器将IP地址返回给本地主机进行解析

为了提高DNS查询效率，并减轻服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

11.简述HTTP协议

超文本传输协议，它是基于TCP协议的应用层传输协议，是一种无状态的传输协议。

无状态：是指客户机与服务器之间不需要建立持久的连接，当客户机向服务器发送请求，服务器返回响应，连接就关闭了，在服务端不保留连接的有关信息。

报文结构：

1）请求报文：

• 请求行：方法、url、版本、回车换行
• 首部行：说明浏览器、服务器和报文主体的一些信息
• 实体主体：通常不用

2）响应报文：

• 状态行：版本、状态码、短语
• 首部行：说明浏览器、服务器和报文主体的一些信息
• 实体主体：有些响应报文不用

12.简述cookie

http协议本身是无状态的，为了使其能处理更加复杂的逻辑，http1.1引入cookie来保存状态信息。

cookie由服务端产生，在发送给客户端保存，当客户端再次访问时，服务端可以通过cookie识别客户端，以此可以做个性化推送等。

13.简述session

session是记录客户状态的另一种机制，不同的是cookie存储在客户端浏览器中，而session存储在服务器上。当客户机以某种状态访问服务器时，服务器把客户端的信息以某种形式记录在服务器上，这就是session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

14.cookie与session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上.

2.cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。

3.设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。

4.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。

两者最大的区别在于生存周期，一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)

15.简述http状态码以及对应信息

• 1XX：接收到的信息正在处理
• 2XX：请求正常处理完毕
• 3XX：重定向
• 4XX：客户端出错
• 5XX：服务端错误

常见错误码：

• 301：永久重定向
• 302：临时重定向
• 400：客户端请求的报文有错误
• 403：服务器禁止访问资源
• 404：请求的资源在服务器中不存在或未找到

16.转发与重定向的区别

转发是服务器行为。服务器直接向目标地址访问url，并将获取到的内容发送给浏览器，用户浏览器地址的url保持不变，转发页面可以共享request里的数据

重定向是服务端给客户端发送状态码，如果服务器返回301、302，浏览器收到消息之后会跳转到新的网址寻求资源。用户栏的url会改变，且不能共享数据。

17.http1.0、http1.1与http2.0的区别

• http1.0只能使用短连接，客户端与服务端每进行一次http连接操作，就进行一次TCP连接，连接结束关闭TCP
• http1.1默认使用长链接，在一个TCP请求上可以传送多个http请求与响应。改善了http1.0短链接造成的性能开销
• http2.0 支持多路复用，即同一个连接能并发处理多个请求。引入了二进制数据帧，对数据顺序进行标识，从而可以并行传输数据。

18.http中短链接与长连接的区别

• http中短链接与长连接是指http底层的TCP连接
• 短链接：客户端与服务端每进行一次http连接操作，就进行一次TCP连接，连接结束关闭TCP
• 长链接：在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。

19.https的连接过程

1.浏览器将支持的加密算法信息发送给服务器

2.服务器选择一套浏览器支持的加密算法，以证书的形式发送给浏览器

3.客户端解析证书验证证书的合法性，生成对称加密的密钥，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密

4.客户端发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器

5.服务器接收到客户端发送的密文，使用自己的私钥对其进行非对称解密，解密之后获得客户端的密钥，使用客户端密钥对数据进行加密，这样数据就变成了密文

6.服务端将加密后的密文发送给客户端

7.客户端收到服务器发送的密文，使用客户端密钥进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成

20.浏览器输入一个网址，具体发生了什么？

1.进行DNS解析操作，根据DNS解析的结果查找服务器IP地址

2.通过IP与ARP，找到服务器，三次握手建立连接

3.浏览器生成HTTP报文，发送HTTP请求，等待服务器响应

4.服务器处理请求，并返回给浏览器

5.根据HTTP是否开启长连接，进行TCP挥手过程

6.浏览器根据收到的静态资源进行页面渲染

7.页面显示完成后，浏览器发送异步请求

8.浏览器关闭TCP连接

21.TCP粘包现象

发送端为了将多个发往接收端的包，更高效的发送给接收端，于是采用优化算法（Nagle算法），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，然后进行封包，接收端必须使用拆包机制来分辨数据。

1.什么是TCP粘包问题

TCP粘包就是发送端发送的若干包数据到达接收端时粘成了一包，从接收缓冲区看，后一包的数据紧接着前一包的数据尾，出现原因可能是发送方，也可能是接收方。

2.造成TCP粘包的原因

1）发送方原因

TCP默认使用Nagle算法，减少网络中的报文数，Nagle算法主要做两件事：

1.只有上一个分组得到确认，才会发送下一个分组

2.收集多个小分组，在一个确认到来时一起发送

Nagle算法造成了发送方会出现粘包问题

2）接收方原因

TCP接收到数据包时，并不会马上交付应用层处理，或者说应用层并不会立即处理。TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存中的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相连的粘包。

3.什么时候需要处理粘包现象？

1.如果发送方发送的多组数据本来就是同一块数据的不同部分，此时不需要处理粘包现象

2.如果多个分组毫不相干，甚至是并列关系，此时必须处理粘包现象。

4.如何处理粘包现象？

1）发送方

对于发送方造成的粘包问题，可以关闭Nagle算法解决。

2）接收方

接收方没法处理粘包现象，只能交给应用层处理。

3)应用层处理

解决方式：循环处理。应用程序从缓存中读取数据时，读完一条数据，循环读取下一条数据，知道所有数据都被处理完成。

判断数据的长度？

1.格式化数据：每条数据有固定的格式：开始符与结束符，但要保证数据内部不能包含开始符与结束符

2.发送长度：发送数据时，将数据的长度一并发送，例如规定数据的前四位是数据长度

5.UDP会不会产生粘包？

TCP为了保证可靠传输并减少额外的开销，采用基于流的传输，基于流的传输并不认为消息是一条一条的，是无保护消息边界的（保护消息边界：传输协议将数据当做一条独立的消息在网上传输，接收端一次性只能接受一条独立的信息）

UDP是面向消息传输的，有保护消息边界，接收方一次只接受一条独立信息，不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。