30道计网常考面试题含答案总结！血赚！

往期热门文章：
1、Spring官方为什么建议构造器注入？
2、还在用 Random生成随机数？试试 ThreadLocalRandom，超好用！
3、这些年 Java8 的 Optional 你用对了吗？
4、当 Docker 遇上 IDEA ，生产力彻底炸裂了
5、如何把Spring Boot的Jar包做成exe？超详细教程来了！

前面已经写过两篇计算机网络文章，涉及内容较多较杂，因此爆肝总结了30道计网常考面试题进行针对性复习，帮助大家更好的理解。

1、为什么TCP连接的时候是3次？2次不可以吗？

考虑丢包问题

1. 因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。

2. 如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

保证序列号双方确认

1. 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
2. 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

2、为什么TCP连接的时候是3次，关闭的时候却是4次？

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

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

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

4、如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

5、time wait过多会出现什么问题？

对于网站来说，这样的time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

所以我们可以通过linux内核进行一些网络调整比如，开启socket重用和快速回收

6、CLOSE_WAIT 过多会出现什么问题？

CLOSE_WAIT 过多导致服务器资源占用，客户端在 FIN_WAIT_2 状态超时大约 60s，自动进入 CLOSED状态， 影响不大。但是服务端在 CLOSE_WAIT 的超时时间默认为 43200秒，所以大量的 CLOSE_WAIT 积压可能造成服务器无法分配出资源给新的连接。一般这种情况都是由于服务器没有调用 close 造成的。程序员应该主动检查代码。

7、什么是HTTP、HTTPS？

1. HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

• 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
• 安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。

2. HTTPS中的S表示SSL或者TLS，就是在原HTTP的基础上加上一层用于数据加密、解密、身份认证的安全层。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

• 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
• 非对称加密：加密和解密使用不同的密钥，这两个密钥形成有且仅有唯一的配对，叫公钥和私钥。数据用公钥加密后必须用私钥解密，数据用私钥加密后必须用公钥解密，相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

8、HTTP 与 HTTPS 的区别？

• https协议需要到ca申请证书，一般免费证书很少，需要交费。
• http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
• http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
• http的连接很简单,是无状态的 。
• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。

9、GET和POST区别？

浏览器和服务器的交互是通过HTTP协议执行的，HTTP全称为Hyper Text Transfer Protocol，中文翻译为超文本传输协议，目的是保证浏览器与服务器之间的通信。而GET和POST也是HTTP协议中的两种方法。

• GET：从服务器上获取数据，也就是所谓的查，仅仅是获取服务器资源，不进行修改。
• POST：向服务器提交数据，这就涉及到了数据的更新，也就是更改服务器的数据。

区别

• get 方法一般用于请求，比如你在浏览器地址栏输入 www.cxuanblog.com 其实就是发送了一个 get 请求，它的主要特征是请求服务器返回资源，而 post 方法一般用于```表单`的提交，相当于是把信息提交给服务器，等待服务器作出响应，get 相当于一个是 pull/拉的操作，而 post 相当于是一个 push/推的操作。
• get 方法是不安全的，因为你在发送请求的过程中，你的请求参数会拼在 URL 后面，从而导致容易被攻击者窃取，对你的信息造成破坏和伪造；而 post 方法是把参数放在请求体 body 中的，这对用户来说不可见。
• get 请求的 URL 有长度限制，这个限制是浏览器或者服务器给添加的，http协议并没有对url长度进行限制，目的是为了保证服务器和浏览器能够正常运行，防止有人恶意发送请求。而 post 请求会把参数和值放在消息体中，对数据长度没有要求。
• get 请求会被浏览器主动 cache，而 post 不会，除非手动设置。
• get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包。对于 get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 post，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

10、浏览器关闭后,session还可以用吗？

当我们重新打开浏览器窗口时，之前的Cookie中存放的Sessionid已经不存在了，此时

服务器从HttpServletRequest对象中没有检查到sessionid，服务器会再发送一个新的存

有Sessionid的Cookie到客户端的浏览器中，此时对应的是一个新的会话，而服务器上

原先的session等到它的默认时间到之后，便会自动销毁。

当在同一个浏览器中同时打开多个标签，发送同一个请求或不同的请求，仍是同一个session;

当不在同一个窗口中打开相同的浏览器时，发送请求，仍是同一个session;

当使用不同的浏览器时，发送请求，即使发送相同的请求，是不同的session;

11、如果客户端禁止 cookie 能实现 session 还能用吗？

Cookie 与 Session，一般认为是两个独立的东西，Session采用的是在服务器端保持状态的方案，而Cookie采用的是在客户端保持状态的方案。

但为什么禁用Cookie就不能得到Session呢？因为Session是用Session ID来确定当前对话所对应的服务器Session，而Session ID是通过Cookie来传递的，禁用Cookie相当于失去了Session ID，也就得不到Session了。

假定用户关闭Cookie的情况下使用Session，其实现途径有以下几种：

• 最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。
• 用文件、数据库等形式保存Session ID，在跨页过程中手动调用

12、介绍下了解的通信协议？

FTP    文件传输协议（File Transfer Protocol）

SMTP：邮件传送协议，

ARP    协议是正向地址解析协议（Address Resolution Protocol），通过已知的 IP，寻找对应主机的 MAC 地址

RARP  协议是方向地址解析协议，通过 MAC 地址确定 IP地址

13、什么是ARP/RARP协议？

地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

逆地址解析协议，即RARP，功能和ARP协议相对，其将局域网中某个主机的物理地址转换为IP地址，比如局域网中有一台主机只知道物理地址而不知道IP地址，那么可以通过RARP协议发出征求自身IP地址的广播请求，然后由RARP服务器负责回答。

14、地址栏输入 URL 发生了什么

“

常考面试题，回答注意两点，1是注意回答的条理性，2是注意回答内容尽量详细，展现知识的宽度和深度

• 首先，你需要在浏览器中的 URL 地址上，输入你想访问的地址，比如www.baidu.com

• 然后，浏览器会根据你输入的 URL 地址，去查找域名是否被本地 DNS 缓存，不同浏览器对 DNS 的设置不同，如果浏览器缓存了你想访问的 URL 地址，那就直接返回 ip。如果没有缓存你的 URL 地址，浏览器就会发起系统调用来查询本机 hosts 文件是否有配置 ip 地址，如果找到，直接返回。如果找不到，就向网络中发起一个 DNS 查询。在由根域名服务器 -> 顶级域名服务器 -> 权威 DNS 服务器后，由权威服务器告诉本地服务器目标 IP 地址，再有本地 DNS 服务器告诉用户需要访问的 IP 地址。

• “

  DNS是域名系统(DomainNameSystem)的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务，可以简单地理解为将URL转换为IP地址。

• 第三步，浏览器需要和目标服务器建立 TCP 连接，需要经过三次握手的过程，TCP/IP 分为四层，在发送数据时，每层都要对数据进行封装：

• 将数据段打包，并加入源及目标的IP地址，并且负责寻找传输路线。
• 判断目标地址是否与当前地址处于同一网络中，是的话直接根据 Mac 地址发送，否则使用路由表查找下一跳地址，以及使用 ARP 协议查询它的 Mac 地址。
• 传输层会发起一条到达服务器的 TCP 连接，为了方便传输，会对数据进行分割（以报文段为单位），并标记编号，方便服务器接受时能够准确地还原报文信息。
• 请求报头（Request Header）：请求方法、目标地址、遵循的协议等等
• 请求主体（其他参数）
• 1. 应用层：发送 HTTP 请求
• 在前面的步骤我们已经得到服务器的 IP 地址，浏览器会开始构造一个 HTTP 报文，其中包括：
• 2. 传输层：TCP 传输报文
• 3. 网络层：IP协议查询Mac地址
• 4. 链路层：以太网协议

• 在建立连接后，浏览器会向目标服务器发起 HTTP-GET 请求，包括其中的 URL，HTTP 1.1 后默认使用长连接，只需要一次握手即可多次传输数据。

• 如果目标服务器只是一个简单的页面，就会直接返回。但是对于某些大型网站的站点，往往不会直接返回主机名所在的页面，而会直接重定向。返回的状态码就不是 200 ，而是 301,302 以 3 开头的重定向码，浏览器在获取了重定向响应后，在响应报文中 Location 项找到重定向地址，浏览器重新第一步访问即可。

• 然后浏览器重新发送请求，携带新的 URL，返回状态码 200 OK，表示服务器可以响应请求，返回报文。

• 渲染页面

15、中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

16、中间人有可能把证书掉包吗？

1. 假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，会导致上文提到的漏洞。
2. 其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

17、为什么制作数字签名时需要hash一次？

“

我初学HTTPS的时候就有这个问题，似乎以上过程中hash有点多余，把hash过程去掉也能保证证书没有被篡改。

最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。

18、http协议实现了什么？

1. 客户与服务器建立连接tcp
2. 客户向服务器提出请求
3. 服务器接受请求，并根据请求返回相应的文件作为应答
4. 客户与服务器关闭连接。

19、什么是无状态协议，HTTP 是无状态协议吗，怎么解决？

1. 无状态协议(Stateless Protocol) 就是指浏览器对于事务的处理没有记忆能力。举个例子来说就是比如客户请求获得网页之后关闭浏览器，然后再次启动浏览器，登录该网站，但是服务器并不知道客户关闭了一次浏览器。

2. HTTP 就是一种无状态的协议，他对用户的操作没有记忆能力。可能大多数用户不相信，他可能觉得每次输入用户名和密码登陆一个网站后，下次登陆就不再重新输入用户名和密码了。这其实不是 HTTP 做的事情，起作用的是一个叫做 小甜饼(Cookie)的机制。它能够让浏览器具有记忆能力。

3. 那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态session登录的认证方案是看，用户从客户端传递用户名和密码登录信息，服务端认证后将信息储存在session中，将session_id放入cookie中，以后访问其他页面，服务器都会带着cookie，服务端会自动从cookie中获取session_id,在从session中获取认证信息。

4. 在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

20、为什么使用非对称加密和对称加密？

对称加密的问题在于这个密钥怎么让传输的双方知晓，同时不被别人知道，依赖于非对称加密将秘钥进行传输，非对称加密耗时，所以采用非对称加密和对称加密组合的方式

21、TCP粘包是什么？

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

22、什么时候需要考虑粘包问题？

1. 如果利用tcp每次发送数据，就与对方建立连接，然后双方发送完一段数据后，就关闭连接，这样就不会出现粘包问题（因为只有一种包结构,类似于http协议）。

• 关闭连接主要是要双方都发送close连接（参考tcp关闭协议）。如：A需要发送一段字符串给B，那么A与B建立连接，然后发送双方都默认好的协议字符如"hello give me sth abour yourself"，然后B收到报文后，就将缓冲区数据接收，然后关闭连接，这样粘包问题不用考虑到，因为大家都知道是发送一段字符。

2. 如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包

3. 如果双方建立连接，需要在连接后一段时间内发送不同结构数据，如连接后，有好几种结构，一般可能会在头加一个数据长度之类的包，以确保接收

23、粘包出现原因？

出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。简单得说，在流传输中出现，UDP不会出现粘包，因为它有消息边界(参考Windows网络编程)

1. 发送端需要等缓冲区满才发送出去，造成粘包

2. 接收方不及时接收缓冲区的包，造成多个包接收

具体来讲：

1. 发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。

2. 接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。

3. 粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。

4. 不是所有的粘包现象都需要处理，若传输的数据为不带结构的连续流数据（如文件传输），则不必把粘连的包分开（简称分包）。但在实际工程应用中，传输的数据一般为带结构的数据，这时就需要做分包处理。

5. 在处理定长结构数据的粘包问题时，分包算法比较简单；在处理不定长结构数据的粘包问题时，分包算法就比较复杂。特别是粘在一起的包有不完整的包的粘包情况，由于一包数据内容被分在了两个连续的接收包中，处理起来难度较大。实际工程应用中应尽量避免出现粘包现象。

24、如何避免粘包问题？

1. 对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；

2. 对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；

3. 由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。

以上提到的三种措施，都有其不足之处。

1. 第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。

2. 第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。

3. 第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。

一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。

25、讲一讲拆包？

对于拆包目前最常用的是以下两种方式：

1、动态缓冲区暂存方式。

之所以说缓冲区是动态的是因为当需要缓冲的数据长度超出缓冲区的长度时会增大缓冲区长度。大概过程描述如下:

1. 为每一个连接动态分配一个缓冲区,同时把此缓冲区和SOCKET关联,常用的是通过结构体关联.

2. 当接收到数据时首先把此段数据存放在缓冲区中.

3. 判断缓存区中的数据长度是否够一个包头的长度,如不够,则不进行拆包操作.

4. 根据包头数据解析出里面代表包体长度的变量.

5. 判断缓存区中除包头外的数据长度是否够一个包体的长度,如不够,则不进行拆包操作.

6. 取出整个数据包.这里的"取"的意思是不光从缓冲区中拷贝出数据包,而且要把此数据包从缓存区中删除掉.删除的办法就是把此包后面的数据移动到缓冲区的起始地址.

这种方法有两个缺点：

1. 为每个连接动态分配一个缓冲区增大了内存的使用.

2. 有三个地方需要拷贝数据,一个地方是把数据存放在缓冲区,一个地方是把完整的数据包从缓冲区取出来,一个地方是把数据包从缓冲区中删除.第二种拆包的方法会解决和完善这些缺点.

可以采用环形缓冲进行改善，环形缓冲实现方案是定义两个指针,分别指向有效数据的头和尾.在存放数据和删除数据时只是进行头尾指针的移动。但是这种改进方法还是不能解决第一个缺点以及第一个数据拷贝,只能解决第三个地方的数据拷贝(这个地方是拷贝数据最多的地方).第2种拆包方式会解决这两个问题.

2、利用底层的缓冲区来进行拆包

1. 由于TCP也维护了一个缓冲区,所以我们完全可以利用TCP的缓冲区来缓存我们的数据，这样一来就不需要为每一个连接分配一个缓冲区了。另一方面我们知道recv或者wsarecv都有一个参数,用来表示我们要接收多长长度的数据。利用这两个条件我们就可以对第一种方法进行优化。

2. 对于阻塞SOCKET来说，我们可以利用一个循环来接收包头长度的数据，然后解析出代表包体长度的那个变量，再用一个循环来接收包体长度的数据。

26、讲一下HTTP 请求页面的过程？

• 有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
• 在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
• HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
• 连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
• HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
• 浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。

27、有哪些方面的因素会导致网站访问慢？

1. 服务器出口带宽不够用

1. 本身服务器购买的出口带宽比较。一旦并发量大的话，就会造成分给每个用户的出口带宽就小，访问速度自然就会慢。

2. 跨运营商网络导致带宽缩减。例如，公司网站放在电信的网络上，那么客户这边对接是长城宽带或联通，这也可能导致带宽的缩减。

2. 服务器负载过大，导致响应不过来

可以从两个方面入手分析：

1. 分析系统负载，使用 w 命令或者 uptime 命令查看系统负载。如果负载很高，则使用 top 命令查看 CPU ，MEM 等占用情况，要么是 CPU 繁忙，要么是内存不够。
2. 如果这二者都正常，再去使用 sar 命令分析网卡流量，分析是不是遭到了攻击。一旦分析出问题的原因，采取对应的措施解决，如决定要不要杀死一些进程，或者禁止一些访问等。

3. 数据库瓶颈

1. 如果慢查询比较多。那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
2. 如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等。然后，也可以搭建 MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。

4. 网站开发代码没有优化好

例如 SQL 语句没有优化，导致数据库读写相当耗时。

28、针对网站访问慢，怎么去排查？

1. 首先要确定是用户端还是服务端的问题。当接到用户反馈访问慢，那边自己立即访问网站看看，如果自己这边访问快，基本断定是用户端问题，就需要耐心跟客户解释，协助客户解决问题。

“

不要上来就看服务端的问题。一定要从源头开始，逐步逐步往下。

2. 如果访问也慢，那么可以利用浏览器的调试功能，看看加载那一项数据消耗时间过多，是图片加载慢，还是某些数据加载慢。

3. 针对服务器负载情况。 查看服务器硬件(网络、CPU、内存)的消耗情况。如果是购买的云主机，比如阿里云，可以登录阿里云平台提供各方面的监控，比如 CPU、内存、带宽的使用情况。

4. 如果发现硬件资源消耗都不高，那么就需要通过查日志，比如看看 MySQL慢查询的日志，看看是不是某条 SQL 语句查询慢，导致网站访问慢。

29、怎么去解决访问慢问题？

1. 如果是出口带宽问题，那么久申请加大出口带宽。
2. 如果慢查询比较多，那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
3. 如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等等。然后也可以搭建MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。
4. 申请购买 CDN 服务，加载用户的访问。
5. 如果访问还比较慢，那就需要从整体架构上进行优化咯。做到专角色专用，多台服务器提供同一个服务。

最近热文阅读：
1、Spring官方为什么建议构造器注入？
2、还在用 Random生成随机数？试试 ThreadLocalRandom，超好用！
3、这些年 Java8 的 Optional 你用对了吗？
4、当 Docker 遇上 IDEA ，生产力彻底炸裂了
5、如何把Spring Boot的Jar包做成exe？超详细教程来了！
6、彻底搞懂 Nginx 的五大应用场景
7、推荐60个相见恨晚的神器工具
8、为什么有些大公司技术弱爆了？
9、这 40 道 Redis 面试题让你不再慌（附答案）
10、优秀的代码都是如何分层的？
关注公众号，你想要的Java都在这里