1. FTP的端口号,分别是什么作用
控制连接(端口号21)
- 主要用来传送在实际通信过程中需要执行的FTP命令以及命令的响应。
- 只需要很小的网络带宽。
- FTP服务端监听21端口号来等待控制连接建立。
- 建立控制连接后,还需要验证客户身份,决定是否建立数据连接。
- 当需要目录列表,传输文件时,才建立数据连接,并且每次客户端都是用不同的端口号来建立数据连接。数据传输完毕,就中断这条临时的数据连接。
- 在FTP连接期间,控制连接始终保持通常的连接状态。在数据连接存在期间,控制连接必须存在;一旦控制连接断开,数据连接会自动关闭。
数据连接(端口号20)
- FTP服务端监听20端口来等待数据连接。
- 数据连接依赖于控制连接。
- 建立方式(主动被动都是相对服务器而言):主动模式,被动模式

2. FTP的主动模式和被动模式
主动被动都是相对服务器而言
主动模式
- 通过三次握手,建立控制连接;客户端的源端口是高位随机端口,目标端口是21端口
- 控制连接建立后,客户端进行身份验证,协商数据连接采用主动模式;随后客户端会向FTP服
- 务器发送Port报文,表明自己监听的IP+端口,并等待FTP服务器(20端口)向自己监听的
- IP+端口发起数据连接请求。
- 服务端发起数据连接请求,建立数据连接
被动模式
- 通过三次握手,建立控制连接;客户端的源端口是高位随机端口,目标端口是21端口;
- 控制连接建立后,客户端进行身份验证,协商数据连接采用被动模式;随后客户端会向服务器
- 发送PASV报文,表示我们用被动模式
- 服务端收到PASV报文,于是向客户端发送Port报文,表明自己监听的IP+端口
- 客户端发起数据连接请求,建立数据连接
3. HTTP常见的状态码
状态代码有三位数字组成,第一个数字定义了响应的类别,共分五种类别:
- 1xx:指示信息--表示请求已接收,继续处理
- 2xx:成功--表示请求已被成功接收、理解、接受
- 3xx:重定向--要完成请求必须进行更进一步的操作
- 4xx:客户端错误--请求有语法错误或请求无法实现
- 5xx:服务器端错误--服务器未能实现合法的请求
常见状态码
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误,不能被服务器所理解
401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报
头域一起使用
403 Forbidden //服务器收到请求,但是拒绝提供服务
404 Not Found //请求资源不存在,eg:输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
4. http和https的区别以及使用的端口号
(1)HTTPS协议需要到CA申请证书,一般免费证书比较少,因此需要一定的费用;
(2)HTTP是超文本传输协议,信息是明文传输,HTTPS是具有安全性的SSL/TSL加密传输协议;
(3)HTTP的默认端口号是80;HTTPS默认的端口号是443;
(4)HTTP协议是无状态协议。(无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。);HTTPS协议是由SSL/TSL+HTTP协议构成的,可进行加密传输。
5. http处理请求的过程
1.构建请求
2. 查找缓存
3. 准备 IP 地址和端口
4. 等待 TCP 队列
5. 建立 TCP 连接
6. 发送 HTTP 请求
7. 服务器处理请求
8. 服务器响应请求
9. 断开连接
10. 特殊情况 重定向

参考:https://blog.csdn.net/GoodLinGL/article/details/116779848
6. https认证过程
1、客户端向服务器请求CA证书(此处还涉及到数字签名)
2、客户端验证CA证书是否为合法证书
(操作系统内置了权威认证机构的CA与获取的证书进行对比,验证证书是否被修改过)
3、如果找不到或者验证不通过则可能是非法证书,一般会给出提示或者直接屏蔽掉
4、如果是合法的,就使用对应CA的公钥解密出服务器的公钥
5、客户端生成一个随机字符串K作为与服务通信的密钥并使用服务器的公钥加密后发给服务器
6、服务端接收到之后使用私钥解密出随机字符串K并校验
7、服务器通知客户端可以使用字符串K作为对称加密的密钥进行通信
8、此时客户端与服务端之间的通信就使用对称加密算法密钥就是K

参考:https://blog.csdn.net/u012002125/article/details/118739889
7. 对称加密和非对称加密
对称加密
1、对称加密简介
- 采用单钥密码系统的加密方法,同一个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密,也称为单密钥加密。它要求发送方和接收方在安全通信之前,商定一个密钥。对称算法的安全性依赖于密钥,泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信的安全性至关重要。
- 基于“对称密钥”的加密算法主要有DES、TripleDES、RC2、RC4、RC5和Blow
2、对称加密优缺点
- 优点:算法公开、计算量小、加密速度快、加密效率高,在保证密钥不泄露情况下加密的数据是很难被破解的。
- 缺点:需要管理和分发密钥比较困难,不够安全。在使用对称加密算法时,发送方和接收方必须商定好唯一密钥且必须保管好,一旦密钥泄露加密信息就变得不安全了

非对称加密
1、非对称加密简介
- 非对称加密之所以不对称,指的就是加密用一个密钥,而解密的时候用的是另外一个密钥。 两个密钥都可以实现加密数据,而解密就需要相互解密即一个被一个密钥加密过的数据只有另一个密钥可以解密。
- 主要算法:RSA、Elgamal、背包算法、Rabin、HD,ECC
2、非对称加密优缺点
- 优点:安全性更高,两个密钥,私钥自己保存,公钥时公开的任何人都可以获取
- 缺点:加密和解密花费时间长、速度慢,只适合对少量数据进行加密,一对公私钥只能保障单向通信的数据安全。

8. POST和GET请求方式的区别
1.提交的过程
- GET提交,请求的数据会附在URL之后(就是把数据放置在HTTP协议头中),以?分割URL和传输数据,多个参数用&连接
- POST提交:把提交的数据放置在是HTTP包的包体中
2.传输数据的大小
- 首先声明:HTTP协议没有对传输的数据大小进行限制,HTTP协议规范也没有对URL长度进行限制
- GET提交,特定浏览器和服务器对URL长度有限制
- POST提交,由于不是通过URL传值,理论上数据不受限
3.安全性
- POST的安全性要比GET的安全性高
- 登录页面有可能被浏览器缓存,而缓存的是URL
- 其他人查看浏览器的历史记录,那么别人就可以拿到你的账号和密码了
- 使用GET提交数据还可能会造成Cross-site request forgery攻击
9. http请求报文和响应报文头部常见的属性
请求报文头部属性
Accpet
- 告诉服务端,客户端接收什么类型的响应
Referer
- 表示这是请求是从哪个URL进来的,比如想在网上购物,但是不知道选择哪家电商平台,你就去问百度,说哪家电商的东西便宜啊,然后一堆东西弹出在你面前,第一给就是某宝,当你从这里进入某宝的时候,这个请求报文的Referer就是www.baidu.com
Cache-Control
- 对缓存进行控制,如一个请求希望响应的内容在客户端缓存一年,或不被缓可以通过这个报文头设置
Accept-Encoding
- 这个属性是用来告诉服务器能接受什么编码格式,包括字符编码,压缩形式(一般都是压缩形式)
- 例如:Accept-Encoding:gzip, deflate(这两种都是压缩格式)
Host
- 指定要请求的资源所在的主机和端口
User-Agent
- 告诉服务器,客户端使用的操作系统、浏览器版本和名称
响应报文头部属性
Cache-Control
- 响应输出到客户端后,服务端通过该属性告诉客户端该怎么控制响应内容的缓存
ETag
- 表示你请求资源的版本,如果该资源发生了变化,那么这个属性也会跟着变
Location
- 在重定向中或者创建新资源时使用
Set-Cookie
- 服务端可以设置客户端的cookie
10.apache的mpm多路处理模块
httpd 支持三种MPM工作模式:prefork, worker, event
MPM工作模式
- prefork:多进程I/O模型,一个主进程,管理多个子进程,一个子进程处理一个请求。
- worker:复用的多进程I/O模型,多进程多线程,一个主进程,管理多个子进程,一个子进程管理多个线程,每个线程处理一个请求。
- event:事件驱动模型,一个主进程,管理多个子进程,一个进程处理多个请求。跟worker差不多,但是区别在于,如果发生长连接情况下会单独起子进程去处理长连接防止队列排的过长,一个子进程可以处理多个长连接请求,在长连接发起请求的时候,相当于触发了事件,进行处理。
查看centos7中默认的mpm
[root@localhost ~]# cat /etc/httpd/conf.modules.d/00-mpm.conf |grep mpm
#默认是prefork
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
#LoadModule mpm_event_module modules/mod_mpm_event.so
11.什么是长连接,有什么作用
长连接是一种网络通信模式,它允许客户端和服务端在一开始建立连接后,在一定时间内不需要重新建立新的连接来进行数据的传输。这种连接方式适用于那些操作频繁且需要实时反馈的场景,如点对点通讯。长连接可以在连接保持期间,如果没有数据包发送,双方会发送链路检测包以维持连接。这样可以减少建立和关闭连接所带来的开销和时间消耗。
长连接的特点包括:
- 稳定安全:由于连接保持,减少了数据包丢失的风险。
- 节省资源:相比每次操作后都新建连接,长连接可以减少不必要的资源开销。
- 连接数的限制:虽然长连接可以节省资源,但如果连接数量过多,也会影响整体性能。
长连接的应用场景广泛,例如:
- 数据库连接:许多数据库管理系统支持长连接,以便在事务执行过程中能够高效地处理数据。
- Web服务:大多数现代web服务器(如nginx)使用长连接来处理高并发访问,从而提高性能。
- 推送服务:如APNS,通过建立一条连接链路,实现在线设备之间消息的快速传递。
然而,长连接也存在一些缺点,比如可能会增加服务器端的负担,尤其是在并发量大的情况下。因此,选择长连接还是短连接取决于具体的应用需求和环境条件。
总结来说,长连接是一种高效的通信模式,特别适合于需要频繁数据交互和高并发处理的场合,但它也需要考虑连接数量的管理和服务器资源的消耗。
12.nginx如何实现高并发
- 多进程/线程模型:Nginx采用了基于事件的非阻塞I/O模型,使得每个工作进程或者线程都能同时处理大量连接。这样就提高了系统的并发性能。
- 负载均衡:Nginx支持多种负载均衡算法,包括轮询、加权轮询、IP Hash等。通过将流量分配到不同的后端服务器上,可以有效地利用所有服务器的计算资源,从而提高系统的并发处理能力。
- Keep-Alive机制:Nginx默认开启Keep-Alive功能,该功能会在客户端与服务器之间保持长连接,减少TCP建立和关闭的次数,从而节省网络传输时间和资源消耗。
- Gzip压缩:Nginx可以对HTTP响应内容进行Gzip压缩,减小文件体积,提高传输速度。当客户端支持gzip压缩时,Nginx会自动返回经过压缩的页面。
- 反向代理:Nginx可以作为反向代理服务器,将外部的请求转发到后端真正的服务器上。这样可以充分利用后端服务器的计算资源,提供更好的性能和可扩展性。
- 缓存:Nginx可以设置缓存,将常用的静态资源(如图片、CSS、JavaScript)缓存起来,减少对后端服务器的请求,提高响应速度。
- 限流控制:Nginx可以根据需要对请求进行限流控制,避免因单台服务器无法处理过多的请求导致系统崩溃。
此外,还可以结合其他组件和技术来进一步提高Nginx的并发处理能力,比如使用LVS(Linux Virtual Server)作为前端负载均衡器,再结合Nginx作为后端服务器;使用Redis等缓存技术来减轻后端服务器的压力;使用CDN(Content Delivery Network)来加速静态资源的获取等。
13. nginx的进程结构
web请求处理机制
- 多进程方式:服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端,直到用户关闭连接,这样的优势是处理速度快。子进程之间相互独立,但是如果访问过大会导致服务器资源耗尽而无法提供请求。
- 多线程方式:与多进程方式类似,但是每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互,一个线程的开销远远小于一个进程,因此多线程方式在很大程度减轻了web服务器对系统资源的要求,但是多线程也有自己的缺点。即当多个线程位于同一个进程内工作的时候,可以相互访问同样的内存地址空间,所以他们相互影响,一旦主进程挂掉则所有子线程都不能工作了,IIS服务器使用了多线程的方式,需要间隔一段时间就重启一次才能稳定。
Nginx是多进程组织模型,而且是一个由Master主进程和Worker工作进程组成。但是其实Nginx里
也有线程。

主进程(master process)的功能:
- 对外接口:接收外部的操作(信号)对内转发:根据外部的操作的不同,通过信号管理worker
- 监控:监控worker进程的运行状态,worker进程异常终止后,自动重启worker进程
- 读取Nginx配置文件并验证其有效性和正确性
- 建立、绑定和关闭socket连接
- 按照配置生成、管理和结束工作进程
- 接受外界指令,比如重启、升级及退出服务器等指令
- 不中断服务,实现平滑升级,重启服务并应用新的配置
- 开启日志文件,获取文件描述符
- 不中断服务,实现平滑升级,升级失败进行回滚处理
- 编译和处理perl脚本
工作进程(worker process)的功能:
- 所有Worker进程都是平等的
- 实际处理:网络请求,由Worker进程处理
- Worker进程数量:在nginx.conf 中配置,一般设置为核心数,充分利用CPU资源,同时,避免
- 进程数量过多,避免进程竞争CPU资源,增加
- 上下文切换的损耗
- 接受处理客户的请求
- 将请求依次送入各个功能模块进行处理
- I/O调用,获取响应数据
- 与后端服务器通信,接收后端服务器的处理结果
- 缓存数据,访问缓存索引,查询和调用缓存数据
- 发送请求结果,响应客户的请求
- 接收主程序指令,比如重启、升级和退出等


14. select,poll,epoll的区别
多路I/O复用是一种用于实现同时监视多个文件描述符(sockets,pipes,files等)的I/O操作的技术。这种技术允许一个进程同时监视多个文件描述符,直到其中一个或多个文件描述符准备好执行 I/O 操作,然后进行相应的处理。
select
,poll
和 epoll
都是用于实现多路I/O复用的系统调用,它们之间有一些区别和差异:
select
:
select
是最古老的多路I/O复用机制之一,通常被用于实现 I/O 多路复用。select
调用会阻塞当前进程,直到监视的文件描述符之一准备好进行 I/O,或者超时。select
的一个缺点是,其时间复杂度为 O(n),因此当需要监视的文件描述符数量变大时,性能下降较为明显。
poll
:
poll
与select
类似,但相对于select
而言,poll
提供了更好的性能。poll
与select
一样,也需要轮询所有文件描述符来检查是否准备好进行 I/O。
epoll
:
epoll
是 Linux 特有的多路I/O复用机制,它具有更好的性能和伸缩性。epoll
使用事件通知的方式,当有文件描述符准备好进行 I/O 时,会注册一个事件,而不需要像select
和poll
那样轮询文件描述符。epoll
支持边缘触发模式(edge-triggered)和水平触发模式(level-triggered)。
总的来说,epoll
是相对于 select
和 poll
更高效的多路I/O复用技术,特别是在需要监视大量文件描述符时。它使用事件通知的模式,减少了轮询的开销,并提供了更好的性能和伸缩性。
select、poll、epoll 区别总结:
1、支持一个进程所能打开的最大连接数
- select
- 单个进程所能打开的最大连接数有FD_SETSIZE宏定义,其大小是32个整数的大小(在32位的机器上,大小就是3232,同理64位机器上FD_SETSIZE为3264),当然我们可以对进行修改,然后重新编译内核,但是性能可能会受到影响,这需要进一步的测试。
- poll
- poll本质上和select没有区别,但是它没有最大连接数的限制,原因是它是基于链表来存储的
- epoll
- 虽然连接数有上限,但是很大,1G内存的机器上可以打开10万左右的连接,2G内存的机器可以打开20万左右的连接
2、FD剧增后带来的IO效率问题
- select
- 因为每次调用时都会对连接进行线性遍历,所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。
- poll
- 同上
- epoll
- 因为epoll内核中实现是根据每个fd上的callback函数来实现的,只有活跃的socket才会主动调用callback,所以在活跃socket较少的情况下,使用epoll没有前面两者的线性下降的性能问题,但是所有socket都很活跃的情况下,可能会有性能问题。
3、 消息传递方式
- select
- 内核需要将消息传递到用户空间,都需要内核拷贝动作
- poll
- 同上
- epoll
- epoll通过内核和用户空间共享一块内存来实现的。
参考博客:https://www.cnblogs.com/lixuejian/p/13354036.html
15. nginx是多线程还是单线程
Nginx采用的是多进程单线程和多路IO复用模型。

Nginx 自己实现了对epoll的封装,是多进程单线程的典型代表。使用多进程模式,不仅能提高并发率,而且进程之间是相互独立的,一 个worker进程挂了不会影响到其他worker进程。
master进程管理worker进程:
接收来自外界的信号。
向各worker进程发送信号。
监控woker进程的运行状态。
当woker进程退出后(异常情况下),会自动重新启动新的woker进程。
注意worker进程数,一般会设置成机器cpu核数。因为更多的worker只会导致进程之间相互竞争cpu,从而带来不必要的上下文切换。
16.正向代理和反向代理的区别
正向代理和反向代理的主要区别在于它们在客户端和服务器之间的位置、代理的对象、用途以及安全性。
- 正向代理位于客户端和目标服务器之间,它代表客户端向服务器发送请求,并接收服务器的响应,然后将响应返回给客户端,客户端通常需要配置正向代理的地址、端口、账号密码等信息,正向代理的主要用途包括访问被限制的资源、数据缓存、加速访问和隐藏客户端身份。
- 反向代理位于服务器端,它代表服务器接收客户端的请求,并将请求转发给内部服务器,同时将内部服务器的响应返回给客户端,客户端通常无法感知反向代理的存在,反向代理的主要用途包括负载均衡、数据缓存、安全防护和隐藏服务器身份。
17.什么是惊群以及如和解决惊群
惊群效应是什么
惊群效应(thundering herd)是指多进程(多线程)在同时阻塞等待同一个事件的时候(休眠状态),如果等待的这个事件发生,那么他就会唤醒等待的所有进程(或者线程),但是最终却只能有一个进程(线程)获得这个事件的“控制权”,对该事件进行处理,而其他进程(线程)获取“控制权”失败,只能重新进入休眠状态,这种现象和性能浪费就叫做惊群效应。
解决方法参考博客:https://zhuanlan.zhihu.com/p/51251700
18. nginx处理请求的过程
HTTP 连接建立和请求处理过程如下:
- Nginx 启动时,Master 进程,加载配置文件。
- Master 进程,初始化监听的 Socket。
- Master 进程,Fork 出多个 Worker 进程。
- Worker 进程,竞争新的连接,获胜方通过三次握手,建立 Socket 连接,并处理请求。
基本的 HTTP Web Server 工作模式:
- 接收请求:逐行读取请求行和请求头,判断段有请求体后,读取请求体。处理请求。返回响应:根据处理结果,生成相应的 HTTP 请求(响应行、响应头、响应体)。
Nginx 也是这个套路,整体流程一致,只不过nginx内部又细化为了11个函数阶段:

具体阶段可参考博客:https://www.cnblogs.com/imcati/p/11681392.html
19. 为什么需要做动静分离
在我们的软件开发中,有些请求是需要后台处理的(如:.jsp
,.do
等等),有些请求是不需要经过后台处理的(如:css、html、jpg、js 等等文件),这些不需要经过后台处理的文件称为静态文件,否则动态文件。
在我们对资源的响应速度有要求的时候,我们应该使用这种动静分离的策略去解决动、静分离将网站静态资源(HTML,JavaScript,CSS,img等文件)与后台应用分开部署,提高用户访问静态代码的速度,降低对后台应用访问
这里我们将静态资源放到 Nginx 中,动态资源转发到 Tomcat 服务器中去;
主流的做法,是把静态资源缓存到 CDN 服务中,从而提升访问速度;
1、 相比本地的 Nginx 来说,CDN 服务器由于在国内有更多的节点,可以实现用户的就近访问;
2、 并且,CDN 服务可以提供更大的带宽,不像我们自己的应用服务,提供的带宽是有限的;
20. 如何查看服务响应时间,响应过慢应该怎么办
通过nginx日志查看接口响应时间
可参考博客:https://blog.csdn.net/meimeib/article/details/124383197
假如你的网站打开很久,什么原因呢,先从最外层排查。
浏览器按F12,看看Network哪个文件时间最长,这个是为了排查有可能css或者js插件引用了一些被国内墙住的地址,一直请求不到,所以时间很久。找到相关的地方注释,或者引用本地的。
如果文件引用什么的都没问题,看接口吧。
先自己写个脚本访问内网访问一下接口,看看是否时间很长,如果很长,追进接口,逐条分析,找到sql去MySQL执行一下,看看时间是否很久,如果很久,就要优化SQL问题了,expain一下SQL看看索引情况啥的,针对性优化。数据量太大的能分表就分表,能分库就分库。如果SQL没啥问题,那可能就是写的逻辑代码的问题了,一行行审代码,找到耗时的地方改造,优化逻辑。
如果引用文件,和接口访问都没问题,那可能是网络问题。
比如你们用的是电信机房,用户在联通访问,很慢。你换个其他教育网,联通网啥的环境试一下看看是否慢,如果慢,那你们就要采用CDN加速策略,或者想其他办法了。
可参考博客:https://www.cnblogs.com/111testing/p/7119113.html
21. 网站压力测试的时候关心哪些数据,如何判断已过载
1. 一般衡量网站性能有哪些指标?
性能指标主要有响应时间,吞吐量,并发量,性能计数器。
1)响应时间
指应用执行一个操作需要的时间,即从发出请求到最后收到响应数据所需要的时间。
系统常用操作响应时间表
操作 | 响应时间 |
打开一个网站 | 几秒 |
数据库查询一条记录(有索引) | 十几毫秒 |
机械磁盘一次寻址定位 | 4毫秒 |
从机械磁盘顺序读取1M数据 | 2毫秒 |
从SSD磁盘顺序读取1M数据 | 0.3毫秒 |
从远程分布式换成Redis读取一个数据 | 0.5毫秒 |
从内存读取1M数据 | 十几微秒 |
Java程序本地方法调用 | 几微秒 |
网络传输2Kb数据 | 1微秒 |
实践中通常采用的办法是重复请求,比如一个请求操作重复执行1万次,测试一万次执行的总响应时间之和,然后除以1万,就得到单次请求的响应时间。
2)吞吐量
指单位时间内系统处理的请求数量,体现系统的整体处理能力。对于网站,可用“请求数/秒”、“页面数/秒”或“访问人数/天”、“处理业务数/小时”等来衡量。重要指标有TPS(每秒处理的事物数)、QPS(每秒查询的请求数)、HPS(每秒HTTP请求数)等。
3)并发量
指系统能够同时处理的请求的数目,这个数字反映了系统的负载性能。对于网站而言,并发数指网站用户同时提交请求的用户数目。
4)性能计数器
描述服务器或操作系统性能的一些数据指标。如System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等使用情况。通过对这些指标设置报警阈值,当监控系统发现性能计数器超过阈值时,就向开发人员和运维报警,及时发现异常并处理。
2. 怎么测试网站性能?
性能测试具体可以细分为性能测试、负载测试、压力测试、稳定性测试。
1)性能测试
以系统设计初期规划的性能指标为预期目标,对系统不断施加压力,验证系统在资源可接受范围内是否能达到预期。
2)负载测试
对系统不断增加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值,这时继续对系统施加压力,系统的处理能力不但不会提高,反而会下降。
3)压力测试
超过安全负载的情况下,对系统施加压力,直到系统崩溃或不能再处理任何请求,以此获得系统最大压力承受能力。
4)稳定性测试
被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检验系统是否稳定。
3. 怎么进行压力测试?
压力测试工具有http_load、apache ab、siege。
1)http_load
下载:http://acme.com/software/http_load/(点击Fetch the software即可)
安装:
yum -y install gcc gcc-c++ #安装GCC编辑器--若已安装请忽略
tar xzvf http_load-09mar2106.tar.gz #解压http_load压缩包
cd http_load-12mar2006 #进入http_load目录
mkdir /usr/local/man #创建目录
make && make install #编译并安装
命令格式:
http_load -p 并发访问进程数 -f 访问总数 需要访问的URL文件
http_load -r 每秒访问频率 -s 访问时间 需要访问的URL文件
// 参数说明:通常参数pf一起使用,参数rs一起使用。
-parallel 简写 -p :并发的用户进程数。
-fetches 简写 -f : 总计的访问次数。
-rate 简写 -r : 每秒的访问频率。
-seconds 简写 -s :总计的访问时间。
使用:
新建一个urls.txt,urls.txt 是一个url 列表,每个url 单独的一行。
在文件中加入一行:http:/.wwwkwx.gd/(不能有任何空格存在,否则会报unknown protocol )
① 测试网站是否能承受住预期的访问压力
执行http_load -rate 5 -seconds 10 urls.txt,含义为在10秒内保持一定的频率访问目标url。
结果分析:
41 fetches, 1020 max parallel, 851898 bytes, in 10.0008 seconds
# 一共请求连接41次,最大并发线程1020个,持续10.0008秒内,总传输速率为 851898bytes
20778 mean bytes/connection
#每次请求连接平均数据量(851898÷41)
4.09969 fetches/sec, 85183.3 bytes/sec
#每秒的响应请求连接数为4.09969个,每秒传输的数据为85183.3btyes/毫秒
msecs/connect: 264.607 mean, 269.482 max, 262.187 min
#每次连接平均响应时间:264.607毫秒,最大时间:269.482毫秒,最小时间:262.187毫秒
msecs/first-response: 1949.27 mean, 5394.21 max, 380.501 min
#每次连接平均返回时间:1949.27毫秒,最大时间:5394.21毫秒,最小时间:380.501毫秒
HTTP response codes:
code 200 -- 41
#HTTP返回码:200 ,一共41次。
主要参考fetches/sec、msecs/connect数值, 前者对应QPS,表示每秒的响应请求数,后者对应response time,表示每个连接的响应时间。
可参考博客:https://www.cnblogs.com/ivy-zheng/p/10941185.html
22. 部署一个lnmp的步骤,以及数据的传输流程
参考博客:https://qxblog.top/%e5%88%a9%e7%94%a8lnmp%e6%90%ad%e5%bb%bawordpress%e7%bd%91%e7%ab%99/
23. apache和nginx的区别,优缺点,如何选择
优缺点分析:
Nginx优点:
1.Nginx有很好的并发性,Nginx再Linux中以epoll作为事件驱动模型,处理请求的方式是异步非阻塞的,负载能力要比Apache高跟多,而Apache则是阻塞型的,在高并发的情况下,Nginx能很简单的保持低资源消耗和高性能,而Apache在PHP处理慢或者前端压力很大的情况下,很容易出现进程数飙升,从而拒绝服务的现象
2.nginx处理静态文件的性能相对于Apache更好
3.nginx涉及高度模块化,编写模块相对比较简单
4.nginx配置简洁,配置完成后能使用-t测试配置有没有问题
5.nginx可以作为负载均衡器,支持7层的负载
6.nginx本身就是一个反向代理服务器,而且可以作为非常优秀的邮件代理服务器
7.nginx可以实现热重启
缺点:1.nginx处理动态文件即和后端PHP服务器交互的能力一般,而Apache对处理动态请求的效率非常高
二.Apache优点:
1.Apache的rewrite要比Nginx强大,在rewrite频繁的情况下,使用Apache
2.因为Apache出现的时间要比Nginx时间长,所以他可能出现的bug也会更少,更加的稳定
3.Apache的PHP的支持比较简单,因为PHP之前就算是Apache架构中的一个模块,而Nginx则需要配合其他后端使用(比如FastCGI)
4.Apache处理动态请求的能力比较强,nginx在这方面做的不好
缺点:1.Apache相对nginx来说更加笨重,其应对高并发的能力要弱于nginx
