计算机网络（高频面试题27问）

1.什么是网络协议，为什么要对网络协议分层

• 网络协议是计算机在通信过程中要遵循的一些约定好的规则。

网络分层的原因：

• 易于实现和维护，因为各层之间是独立的，层与层之间不会收到影响。
• 有利于标准化的制定
  
• 应用层
  应用层的任务是通过应用进程之间的交互来完成特定的网络作用，常见的应用层协议有域名系统DNS，HTTP协议等。
• 表示层
  表示层的主要作用是数据的表示、安全、压缩。可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
• 会话层
  会话层的主要作用是建立通信链接，保持会话过程通信链接的畅通，同步两个节点之间的对话，决定通信是否被中断以及通信中断时决定从何处重新发送。
• 传输层
  传输层的主要作用是负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
• 网络层
  网络层的主要作用是选择合适的网间路由和交换结点，确保数据及时送达。常见的协议有IP协议。
• 数据链路层
  数据链路层的作用是在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动作系列。 常见的协议有SDLC、HDLC、PPP等。
• 物理层
  物理层的主要作用是实现相邻计算机结点之间比特流的透明传输，并尽量屏蔽掉具体传输介质和物理设备的差异。

2. 浏览器键入一个网址都经历了哪些过程？

简单的分析，从输入 URL到回车后发生的行为如下：

• URL解析
• DNS 查询
• TCP 连接
• HTTP 请求
• 响应请求
• 页面渲染

详细分析

1. URL解析

首先判断你输入的是一个合法的URL 还是一个待搜索的关键词，并且根据你输入的内容进行对应操作
URL的解析第过程中的第一步，一个url的结构解析如下：

2. DNS查询
   整个查询过程如下图所示：

最终，获取到了域名对应的目标服务器IP地址

3. TCP连接

tcp是一种面向有连接的传输层协议在确定目标服务器服务器的IP地址后，则经历三次握手建立TCP连接，流程如下：

4. 发送 http 请求
   当建立tcp连接之后，就可以在这基础上进行通信，浏览器发送 http 请求到目标服务器

请求的内容包括：

• 请求行
• 请求头
• 请求主体

5. 响应请求
   当服务器接收到浏览器的请求之后，就会进行逻辑操作，处理完成之后返回一个HTTP响应消息，包括：

• 状态行
• 响应头
• 响应正文

在服务器响应之后，由于现在http默认开始长连接keep-alive，当页面关闭之后，tcp链接则会经过四次挥手完成断开

6. 页面渲染
   当浏览器接收到服务器响应的资源后，首先会对资源进行解析：

• 查看响应头的信息，根据不同的指示做对应处理，比如重定向，存储cookie，解压gzip，缓存资源等等

• 查看响应头的 Content-Type的值，根据不同的资源类型采用不同的解析方式
  关于页面的渲染过程如下：

• 解析HTML，构建 DOM 树

• 解析 CSS ，生成 CSS 规则树

• 合并 DOM 树和 CSS 规则，生成 render 树

• 布局 render 树（ Layout / reflow ），负责各元素尺寸、位置的计算

• 绘制 render 树（ paint ），绘制页面像素信息

• 浏览器会将各层的信息发送给 GPU，GPU 会将各层合成（ composite ），显示在屏幕上
  

总结：

1. 解析URL得到发送给web的信息，并生产 HTTP 请求信息
2. 询服务器域名对应的 IP 地址，这个过程中涉及到DNS解析。
3. 通过 DNS 获取到 IP 后，就可以把 HTTP 的传输⼯作交给操作系统中的协议栈。
4. 经过TCP三次握手建立连接进行数据传输。
5. TCP 模块在执行连接、收发、断开等各阶段操作时，都需要委托 IP 模块将数据封装成网络包发送给通信对象。
6. 生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 MAC 头部。
7. 后续还会经过网卡、交换机和路由器到对端，然后就是一个反向的过程

1. 对输入到浏览器的url进行DNS解析，将域名转换为IP地址。
2. 和目的服务器建立TCP连接
3. 向目的服务器发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析并渲染页面

点击查看详细过程

3.DNS的工作流程

DNS的定义：DNS的全称是domain name system，即域名系统。DNS是因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的去访问互联网而不用去记住能够被机器直接读取的IP地址。

比如大家访问百度，更多地肯定是访问www.baidu.com，而不是访问112.80.248.74，因为这几乎无规则的IP地址实在太难记了。DNS要做的就是将www.baidu.com解析成112.80.248.74。

主机向本地域名服务器的查询一般是采用递归查询，而本地域名服务器向根域名的查询一般是采用迭代查询。递归查询主机向本地域名发送查询请求报文，而本地域名服务器不知道该域名对应的IP地址时，本地域名会继续向根域名发送查询请求报文，不是通知主机自己向根域名发送查询请求报文。迭代查询是，本地域名服务器向根域名发出查询请求报文后，根域名不会继续向顶级域名服务器发送查询请求报文，而是通知本地域名服务器向顶级域名发送查询请求报文。

简单来说

• 递归查询就是
  小明问了小红一个问题，小红不知道，但小红是个热心肠，小红就去问小王了，小王把答案告诉小红后，小红又去把答案告诉了小明。
• 迭代查询就是
  小明问了小红一个 问题，小红也不知道，然后小红让小明去问小王，小明又去问小王了，小王把答案告诉了小明。

1. 在浏览器中输入www.baidu.com域名，操作系统会先检查自己本地的hosts文件是否有这个域名的映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2. 如果hosts文件中没有，则查询本地DNS解析器缓存，如果有，则完成地址解析。
3. 如果本地DNS解析器缓存中没有，则去查找本地DNS服务器，如果查到，完成解析。
4. 如果没有，则本地服务器会向根域名服务器发起查询请求。根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器。
5. 本地域名服务器向顶级域名服务器发起查询请求，顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器。
6. 本地域名服务器向权限域名服务器发起查询请求，权限域名服务器告诉本地域名服务器www.baidu.com所对应的IP地址。
7. 本地域名服务器告诉主机www.baidu.com所对应的IP地址

4.说一下ping的过程

ping是ICMP(网际控制报文协议)中的一个重要应用，ICMP是网络层的协议。ping的作用是测试两个主机的连通性。
ping的工作过程：

1. 向目的主机发送多个ICMP回送请求报文
2. 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。

在规定的时候间内，源主机如果没有接到 ICMP 的应答包，则说明目标主机不可达；如果接收到了 ICMP 回送响应消息，则说明目标主机可达。此时，源主机会检查，用当前时刻减去该数据包最初从源主机上发出的时刻，就是 ICMP 数据包的时间延迟

5.Cookie的作用是什么?和Session有什么区别？什么是Token

• session 在服务器端，cookie 在客户端（浏览器）
• session 默认被存储在服务器的一个文件里（不是内存）
• session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
• session 可以放在 文件、数据库、或内存中都可以。用户验证这种场合一般会用 session

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不 太一样。 Cookie 一般用来保存用户信息 比如

①我们在 Cookie 中保存已经登录过得用户信 息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是 因为用户登录的时候我们可以存放了一个 Token 在Cookie中，下次登录的时候只需 要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通 过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时 候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。 Cookie 数据保存在客户端(浏览器端)，Session数据保存在服务器端。 Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更 高。如果要在Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
【摘自JavaGuide】

• Token
  客户端在浏览器第一次访问服务端时，服务端生成的一串字符串作为Token发给客户端浏览器，下次浏览器在访问服务端时携带token即可无需验证用户名和密码，省下来大量的资源开销。

	存放位置	占用空间	安全性	应用场景
Cookie	客户端浏览器	小	较低	一般存放配置信息
Session	服务端	多	较高	存放较为重要的信息

6.GET和POST区别

	GET	POST
作用	GET用于获取资源	POST用于传输实体主体
参数位置	GET的参数放在URL中，，并且GET方法提交的请求的URL中的数据 最多是2048字节	POST的参数存储在实体主体中，POST请求没有大小限制。
安全性	GET方法因为参数放在URL中，安全性相对于POST较差一些	较高
幂等性	GET方法是具有幂等性	POST方法不具有幂等性

这里幂等性指客户端连续发出多次请求，收到的结果都是一样的.

从w3schools得到的标准答案的区别如下：

• GET在浏览器回退时是无害的，而POST会再次提交请求。
• GET产生的URL地址可以被Bookmark，而POST不可以。
• GET请求会被浏览器主动cache，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制的，而POST没有。
  对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
• GET参数通过URL传递，POST放在Request body中

7.TCP的三次握手及四次挥手

以往博客 TCP的三次握手及四次挥手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包

主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备

过程如下：

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©，此时客户端处于 SYN_SENT 状态

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，为了确认客户端的 SYN，将客户端的 ISN+1作为ACK的值，此时服务器处于 SYN_RCVD 的状态

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，值为服务器的ISN+1。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接
  上述每一次握手的作用如下：

• 第一次握手：客户端发送网络包，服务端收到了 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

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

• 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常
  通过三次握手，就能确定双方的接收和发送能力是正常的。之后就可以正常通信了

四次挥手

tcp终止一个连接，需要经过四次挥手

过程如下：

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

8.TCP与UDP有什么区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

TCP

UDP

9.TCP协议如何保证可靠传输

主要有校验和、序列号、超时重传、流量控制及拥塞避免等几种方法。

• 校验和：在发送算和接收端分别计算数据的校验和，如果两者不一致，则说明数据在传输过程中出现了差错，TCP将丢弃和不确认此报文段。
• 序列号：TCP会对每一个发送的字节进行编号，接收方接到数据后，会对发送方发送确认应答(ACK报文)，并且这个ACK报文中带有相应的确认编号，告诉发送方，下一次发送的数据从编号多少开始发。如果发送方发送相同的数据，接收端也可以通过序列号判断出，直接将数据丢弃。
• 超时重传：在上面说了序列号的作用，但如果发送方在发送数据后一段时间内（可以设置重传计时器规定这段时间）没有收到确认序号ACK，那么发送方就会重新发送数据。这里发送方没有收到ACK可以分两种情况，如果是发送方发送的数据包丢失了，接收方收到发送方重新发送的数据包后会马上给发送方发送ACK；如果是接收方之前接收到了发送方发送的数据包，而返回给发送方的ACK丢失了，这种情况，发送方重传后，接收方会直接丢弃发送方冲重传的数据包，然后再次发送ACK响应报文。如果数据被重发之后还是没有收到接收方的确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长，直到最后关闭连接。
• 流量控制：如果发送端发送的数据太快，接收端来不及接收就会出现丢包问题。为了解决这个问题，TCP协议利用了滑动窗口进行了流量控制。在TCP首部有一个16位字段大小的窗口，窗口的大小就是接收端接收数据缓冲区的剩余大小。接收端会在收到数据包后发送ACK报文时，将自己的窗口大小填入ACK中，发送方会根据ACK报文中的窗口大小进而控制发送速度。如果窗口大小为零，发送方会停止发送数据。
• 拥塞控制：如果网络出现拥塞，则会产生丢包等问题，这时发送方会将丢失的数据包继续重传，网络拥塞会更加严重，所以在网络出现拥塞时应注意控制发送方的发送数据，降低整个网络的拥塞程度。拥塞控制主要有四部分组成：慢开始、拥塞避免、快重传、快恢复

10.为什么TCP连接的时候是3次？两次或者四次是否可以？

不可以，主要从以下两方面考虑（假设客户端是首先发起连接请求）：

1. 假设建立TCP连接仅需要两次握手，那么如果第二次握手时，服务端返回给客户端的确认报文丢失了，客户端这边认为服务端没有和他建立连接，而服务端却以为已经和客户端建立了连接，并且可能向服务端已经开始向客户端发送数据，但客户端并不会接收这些数据，浪费了资源。如果是三次握手，不会出现双方连接还未完全建立成功就开始发送数据的情况。
2. 如果服务端接收到了一个早已失效的来自客户端的连接请求报文，会向客户端发送确认报文同意建立TCP连接。但因为客户端并不需要向服务端发送数据，所以此次TCP连接没有意义并且浪费了资源。

简单来说：

• TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。
• 不使用两次和四次的原因：

1. 两次：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
2. 四次：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

11.为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

MSL的意思是报文的最长寿命，可以从两方面考虑：

1. 客户端发送第四次挥手中的报文后，再经过2MSL，可使本次TCP连接中的所有报文全部消失，不会出现在下一个TCP连接中。
2. 考虑丢包问题，如果第四挥手发送的报文在传输过程中丢失了，那么服务端没收到确认ack报文就会重发第三次挥手的报文。如果客户端发送完第四次挥手的确认报文后直接关闭，而这次报文又恰好丢失，则会造成服务端无法正常关闭。

12. 说一下ping的过程

ping是ICMP(网际控制报文协议)中的一个重要应用，ICMP是网络层的协议。ping的作用是测试两个主机的连通性。

ping的工作过程：

1. 向目的主机发送多个ICMP回送请求报文
2. 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。

13.HTTP常见的请求头有哪些

HTTP头字段（HTTP header fields）,是指在超文本传输协议（HTTP）的请求和响应消息中的消息头部分

它们定义了一个超文本传输协议事务中的操作参数

HTTP头部字段可以自己根据需要定义，因此可能在 Web服务器和浏览器上发现非标准的头字段

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

14.SYN洪泛攻击如何避免

概述：SYN洪泛攻击是只发起SYN请求后对服务端的应答不会发送确认报文，通过来消耗服务端的内核资源来达到攻击目的

• 预防
  加防火墙，对一些疑似攻击者的IP地址过滤
  降低SYN timeout的时间

15. HTTP 与 HTTPS 的区别

	HTTP	HTTPS
端口	80	443
安全性	无加密，安全性较差	有加密机制，安全性较高
资源消耗	较少	由于加密处理，资源消耗更多
是否需要证书	不需要	需要
协议	运行在TCP协议之上	运行在SSL协议之上，SSL运行在TCP协议之上

16. 什么是对称加密与非对称加密

• 对称加密
  对称加密指加密和解密使用同一密钥，优点是运算速度快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有DES、AES等等。
• 对称加密
  非对称加密指的是加密和解密使用不同的密钥，一把公开的公钥，一把私有的私钥。公钥加密的信息只有私钥才能解密，私钥加密的信息只有公钥才能解密。优点解决了对称加密中存在的问题。缺点是运算速度较慢。常见的非对称加密算法有RSA、DSA、ECC等等。非对称加密的工作流程：A生成一对非堆成密钥，将公钥向所有人公开，B拿到A的公钥后使用A的公钥对信息加密后发送给A，经过加密的信息只有A手中的私钥能解密。这样B可以通过这种方式将自己的公钥加密后发送给A，两方建立起通信，可以通过对方的公钥加密要发送的信息，接收方用自己的私钥解密信息。

17.什么是HTTPS协议

数字证书：服务器生成一对公钥和私钥，然后将公钥交给CA，CA对公钥以及服务器域名等信息加密形成数字证书，然后对证书进行哈希形成摘要，然后用CA私钥加密形成数字签名

• 客户端向服务器发起请求
• 服务端将数字证书发给客户端
• 客户端对数字证书哈希，然后与数字签名解开后的摘要进行对比，若不一致则终止请求，一致则表示数字证书未被篡改(防篡改)
• 客户端拿到信息后使用CA的公钥(一般存放在浏览器中，防止被中间人替换)解析数字证书，若不合法则停止https请求，合法性包括(防替换)
• 证书是否过期
• CA是否权威可靠
• CA的公钥能否解开数字签名，以及数字签名解开后的域名是否和真实域名一致
• 若一致，则客户端产生一个对称加密秘钥，并用服务器公钥加密后传输给服务端
• 服务端用自己的私钥解开，此后用对称加密秘钥传输数据
• 此处的中间人攻击：客户端向服务端发送https请求后，中间人截取到请求，然后转发给服务端，然后中间人将自己的自签名证书发给客户端(此时客户端会弹窗警告自签名证书)，若客户端无视弹窗，即认可该证书，会将产生的对称秘钥通过自签名证书中的中间人公钥加密传输，然后中间人截取到信息并窃取到对称秘钥，然后再将对称秘钥用服务端公钥加密后转发该请求给服务器，此后双方的所有数据传输在中间人面前都和明文一样
• 如何避免：选择权威的CA机构签名的证书，不要信任自签名证书

18.https设计时的两个要点

1. 防止篡改：使用数字签名来保证，对信息做哈希，然后用私钥加密，形成摘要，在请求方收到后，用对方公钥解开拿到摘要，然后自己再对信息做一次哈希，若一样则没有篡改
2. 防止冒充：使用数字证书来保证，请求方收到数字证书并解开后，里面会标识该证书对应的域名，可以防止中间人攻击

19.websocket协议

可以使得服务端主动向客户端传输数据

20.HTTP报文解析

https://blog.csdn.net/kongmin_123/article/details/82154780

21.常用HTTP状态码

1XX

• 100 Continue：表示正常，客户端可以继续发送请求
• 101 Switching Protocols：切换协议，服务器根据客户端的请求切换协议。

2XX

• 200 OK：请求成功
• 201 Created：已创建，表示成功请求并创建了新的资源
• 202 Accepted：已接受，已接受请求，但未处理完成。
• 204 No Content：无内容，服务器成功处理，但未返回内容。
• 205 Reset Content：重置内容，服务器处理成功，客户端应重置文档视图。
• 206 Partial Content：表示客户端进行了范围请求，响应报文应包含Content-Range指定范围的实体内容

3XX

zy Moved Permanently：永久性重定向

• 302 Found：临时重定向
• 303 See Other：和zy功能类似，但要求客户端采用get方法获取资源
• 304 Not Modified：所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。
• 305 Use Proxy：所请求的资源必须通过代理访问
• 307 Temporary Redirect： 临时重定向，与302类似，要求使用get请求重定向。

4XX

• 400 Bad Request：客户端请求的语法错误，服务器无法理解。
• 401 Unauthorized：表示发送的请求需要有认证信息。
• 403 Forbidden：服务器理解用户的请求，但是拒绝执行该请求
• 404 Not Found：服务器无法根据客户端的请求找到资源。
• 405 Method Not Allowed：客户端请求中的方法被禁止
• 406 Not Acceptable：服务器无法根据客户端请求的内容特性完成请求
• 408 Request Time-out：服务器等待客户端发送的请求时间过长，超时
  5XX
• 500 Internal Server Error：服务器内部错误，无法完成请求
• 501 Not Implemented：服务器不支持请求的功能，无法完成请求

22.TCP粘包问题及解决方案

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

（1）发送方原因

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

只有上一个分组得到确认，才会发送下一个分组
收集多个小分组，在一个确认到来时一起发送
Nagle算法造成了发送方可能会出现粘包问题

（2）接收方原因

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

(https://blog.csdn.net/weixin_41047704/article/details/85340311)

23.UDP会不会产生粘包问题呢？

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

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

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

24.常见的HTTP状态码

1开头：（被接受，需要继续处理。）

2开头 （请求成功）
这一类型的状态码，代表请求已成功被服务器接收、理解、并接受

3开头 （请求被重定向）
这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

4开头：（请求错误）
这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

5开头：（服务器错误）
这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

状态码	含义
1xx	请求正被处理
2xx	请求成功处理
3xx	请求需要附加操作，常见的比如重定向
4xx	客户端出错导致无法被处理
5xx	服务端处理出错

(https://vue3js.cn/interview/http/status.html#%E4%BA%8C%E3%80%81%E5%88%86%E7%B1%BB)

25.http1.0和http1.1、http2.0的区别

HTTP1.0：

• 浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接

HTTP1.1：

• 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
• 在同一个TCP连接里面，客户端可以同时发送多个请求
• 虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理特别慢，后面就会有许多请求排队等着
• 新增了一些请求方法
• 新增了一些请求头和响应头

HTTP2.0：

• 采用二进制格式而非文本格式
• 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
• 使用报头压缩，降低开销
• 服务器推送

26.TIME_WAIT和CLOSE_WAIT的区别在哪?

默认客户端首先发起断开连接请求

• CLOSE_WAIT是被动关闭形成的，当客户端发送FIN报文，服务端返回ACK报文后进入CLOSE_WAIT。
• TIME_WAIT是主动关闭形成的，当第四次挥手完成后，客户端进入TIME_WAIT状态。

27.三挥四握异常处理

• 第一次握手丢失：客户端会触发重传，根据不同的操作系统有不同的时机，有1秒有3秒，默认最大重传次数为5，并且每次超时时间是上一次的两倍，如1s、2s、4s…
• 第二次握手丢失：客户端由于没有收到ACK，以为自己的请求丢失了，于是客户端会重传第一次握手报文，同时服务端收不到确认，会触发重传第二次握手报文，即双方都会重传
• 第三次握手丢失：服务端一直收不到确认，将会触发超时重传，重传第二次握手的报文直到最大重试次数
• 第一次挥手丢失：由于收不到服务端的ACK，客户端将会重传直到最大重试次数
• 第二次挥手丢失：客户端会一直重传直到收到ACK或者达到最大重传次数
• 第三次挥手丢失：由于收不到客户端的ACK，服务端将会重传直到收到ACK或者达到最大重传次数
• 第四次挥手丢失：仍然是服务端重发第三次挥手报文

(https://blog.csdn.net/yyc1023/article/details/80242815)
(https://zhuanlan.zhihu.com/p/398890723https://zhuanlan.zhihu.com/p/398890723)