【巨人的肩膀】计算机网络面试总结（一）

💪

1、OSI的七层模型分别是？各自的功能是什么🔥

• 物理层：底层数据传输，如网线；网卡标准。
• 数据链路层：定义数据的基本格式，如何传输，如何标识；如网卡MAC地址。
• 网络层：定义IP编址，定义路由功能；如不同设备的数据转发。
• 传输层：端到端传输数据的基本功能；如 TCP、UDP。
• 会话层：控制应用程序之间会话能力；如不同软件数据分发给不同软件。
• 表示层：数据格式标识，基本压缩加密功能。
• 应用层：各种应用软件，包括 Web 应用。

口诀：物联网淑慧试用

• 一层物理层时数据被称为比特流
• 二层数据链路层时数据被称为帧
• 三层网络层数据被称做包
• 在四层传输层数据被称作段

总结：

• 网络七层模型是一个标准，而非实现。
• 网络四层模型是一个实现的应用模型。
• 网络四层模型由七层模型简化合并而来。

2、为什么需要三次握手？两次不行？🔥

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后：

1. 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 seq。此时客户端处于 SYN_Send 状态。
2. 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 seq，同时会把客户端的 seq + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。
3. 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 seq+ 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 established 状态
4. 服务器收到 ACK 报文之后，也处于 established 状态，此时，双方以建立起了链接

三次握手的作用是为了确认双份的接收与发送能力是否正常。解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以：

• 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

三次握手的作用

1. 确认双方的接受能力、发送能力是否正常。
2. 指定自己的初始化序列号，为后面的可靠传送做准备。

什么是半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

3、为什么需要四次挥手？三次不行🔥

刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

1. 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号seq。此时客户端处于FIN_WAIT1状态。
2. 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 seq + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
3. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 seq + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
5. 服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

这里特别需要主要的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。

至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

4、TCP与UDP有哪些区别？各自应用场景🔥

TCP协议的主要特点：

1. TCP是面向连接的运输层协议；所谓面向连接就是双方传输数据之前，必须先建立一条通道，例如三次握手就是建议通道的一个过程，而四次挥手则是结束销毁通道的一个其中过程。
2. 每一条TCP连接只能有两个端点（即两个套接字），只能是点对点的
3. TCP提供可靠的传输服务。传送的数据无差错、不丢失、不重复、按序到达
4. TCP提供全双工通信。允许通信双方的应用进程在任何时候都可以发送数据，因为两端都设有发送缓存和接受缓存
5. 面向字节流。虽然应用程序与TCP交互是一次一个大小不等的数据块，但TCP把这些数据看成一连串无结构的字节流，它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系

UDP协议的特点：

1. UDP是无连接的传输层协议
2. UDP使用尽最大努力交付，不保证可靠交付
3. UDP没有拥塞控制，因此即使网络出现拥塞也不会降低发送速率
4. UDP支持一对一　一对多　多对多的交互通信

TCP和UDP的区别：

1. TCP是可靠传输,UDP是不可靠传输
2. TCP面向连接,UDP无连接
3. TCP传输数据有序,UDP不保证数据的有序性
4. TCP不保存数据边界,UDP保留数据边界
5. TCP传输速度相对UDP较慢
6. TCP有流量控制和拥塞控制,UDP没有
7. TCP是重量级协议,UDP是轻量级协议
8. TCP首部较长２０字节,UDP首部较短８字节

常用协议：

• HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议)协议基于可靠的TCP协议。
• DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP基于不可靠的UDP协议

TCP和UDP应用场景

• TCP应用场景：效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
• UDP应用场景：效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题

5、TCP可靠传输的原理🔥

1. 首先，采用三次握手来建立TCP连接，四次挥手来释放TCP连接，从而保证建立的传输信道是可靠的
2. 其次，TCP采用了滑动窗口协议来保证接收方能够及时处理所接收到的数据，进行流量控制
3. 最后，TCP使用慢开始、拥塞避免、快重传和快恢复来进行拥塞控制，避免网络拥塞

6、HTTP1.0、1.1、2.0的版本区别

• HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接。我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。

• HTTP/1.1引入了持久连接，所谓的持久连接即TCP连接默认不关闭，可以被多个请求复用。同时还引入了管道机制，即在同一个TCP连接里面，客户端可以同时发送多个请求。

• HTTP/2采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

7、POST和GET有哪些区别？各自应用场景

使用场景：GET 用于获取资源，而 POST 用于传输实体主体。

• 参数：GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。
• 安全性：GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。
  • 安全的方法除了 GET 之外还有：HEAD、OPTIONS。
  • 不安全的方法除了 POST 之外还有 PUT、DELETE。
• 幂等性：幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。
• 可缓存：如果要对响应进行缓存，需要满足以下条件
  • 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
  • 响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
  • 响应报文的 Cache-Control 首部字段没有指定不进行缓存。

8、HTTP哪些常用的状态码及使用场景

1. 1xx：表示目前是协议的中间状态，还需要后续请求
2. 2xx：表示请求成功
3. 3xx：表示重定向状态，需要重新请求
4. 4xx：表示请求报文错误
5. 5xx：服务器端错误

常用状态码：

状态码	含义
101	切换请求协议，从HTTP切换到WebSocket
200	请求成功，有响应体
301	永久重定向：会缓存
302	临时重定向：不会缓存
304	协商缓存命中
400	请求错误
403	服务器禁止访问
404	资源未找到
500	服务器端错误
503	服务器繁忙

9、HTTP状态码301和302的区别，都有哪些用途

301重定向的概念：301重定向，指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。网页开发过程中，时常会遇到网站目录结构的调整，将页面转移到一个新地址；网页扩展名的改变，这些变化都会导致网页地址发生改变，此时用户收藏夹和搜索引擎数据库中的旧地址是一个错误的地址，访问之后会出现404页面，直接导致网站流量的损失，或者是我们需要多个域名跳转至同一个域名时也是需要进行301重定向。

301重定向的优点：提升网站权重

302重定向：302重定向指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。

10、什么是SQL注入？举个例子🔥

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

应对方法：

1. 参数绑定：使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用 # 和$来获取参数值。

   当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用$时，变量就是直接追加在sql中，一般会有sql注入问题。

2. 使用正则表达式过滤传入的参数

11、谈一谈XSS攻击🔥

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

原因解析：过于信任客户端提交的数据！

解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

具体的解决办法：将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）

12、HTTPS和HTTP的区别

Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份。Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

1. 端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443
2. 资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源
3. 开销：Https通信需要证书，而证书一般需要向认证机构购买

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制

13、对称加密与非对称加密的区别

• 对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方
• 而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

14、简单说下每一层对应的网络协议有哪些

• 物理层：IEE802.3协议
• 数据链路层：CSMA/CD、PPP
• 网络层：IP、ARP、ICMP、RIP、OSPF、BGP
• 传输层：TCP、UDP
• 应用层：HTTP、FTP、SMTP、DNS、DHCP

15、ARP协议的工作原理

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

16、TCP和UDP分别对应的常见应用层协议有哪些🔥

TCP对应的应用层协议：FTP、SMTP、POP3、HTTP

UDP对应的应用层协议：DNS

17、为什么time-wait状态必须等待2msl的时间呢

1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
2. 防止已失效的连接请求报文段出现在本连接中。

18、谈谈你对停止等待协议的理解

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认

19、谈谈你对ARQ协议的理解

自动重传请求 ARQ 协议：停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，这种自动重传方式常称为自动重传请求 ARQ。

20、谈谈你对滑动窗口的了解

TCP 利用滑动窗口实现流量控制的机制。滑动窗口是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。

21、谈谈你对流量控制的理解

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。

22、什么是粘包

在进行 Java NIO 学习时，可能会发现：如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

1. 在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难，因为无法区分一个完整的数据包。

怎么解决拆包和粘包

分包机制一般有两个通用的解决方法：

1. 特殊字符控制
2. 在包头首都添加数据包的长度

UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。

23、HTTP方法有哪些

客户端发送的 请求报文 第一行为请求行，包含了方法字段：

• GET：获取资源，当前网络中绝大部分使用的都是 GET
• HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分
• POST：传输实体主体
• PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法
• Delete：删除文件

24、在浏览器中输入URL地址到显示主页的过程🔥

1. DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址：具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等
2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手
3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求
4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
5. 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

25、DNS的解析过程

1. 主机向本地域名服务器的查询一般都是采用递归查询
2. 本地域名服务器向根域名服务器的查询是迭代查询

26、什么是数字签名

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

27、什么是数字证书

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的

28、Keep-Alive和非Keep-Alive有什么区别

在早期的 HTTP/1.0 中，浏览器每次 发起 HTTP 请求都要与服务器创建一个新的 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，服务器不跟踪每个客户也不记录过去的请求。

在 HTTP/1.1 版本中默认使用持久连接，在此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流

• 对于非 Keep=Alive 来说，必须为每一个请求的对象建立和维护一个全新的连接。
• 在 Keep-Alive 方式下，服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。

然而，Keep-Alive 并不是没有缺点的，当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若对 Keep-Alive 模式配置不当，将有可能比非 Keep-Alive 模式带来的损失更大。

29、URI和URL的区别是什么

• URI：是统一资源标志符，可以唯一标识一个资源
• URL：是统一资源定位符，可以提供该资源的路径。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。

30、HTTP是不保存状态的协议，如何保存状态

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie被禁用怎么办？

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。