TTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
1、HTTP 工作原理
-
HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
-
Web服务器有：Nginx，Apache服务器，IIS服务器（Internet Information Services）等。
-
Web服务器根据接收到的请求后，向客户端发送响应信息。
-
HTTP默认端口号为80，但是你也可以改为8080或者其他端口。
-
客户端进行DNS域名解析，得到对应的IP地址
-
根据这个IP，找到对应的服务器建立连接（三次握手）
-
建立TCP连接后发起HTTP请求（一个完整的http请求报文）
-
服务器响应HTTP请求，客户端得到html代码
-
客户端解析html代码，用html代码中的资源(如js,css,图片等等)渲染页面。
-
服务器关闭TCP连接（四次挥手）
-
HTTP三点注意事项：
-
HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
-
HTTP是媒体独立的：只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
-
HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
以下图表展示了HTTP协议通信流程：
2、HTTP 消息结构
HTTP是基于客户端/服务端（C/S）的架构模型，通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。
一个HTTP"客户端"是一个应用程序（Web浏览器或其他任何客户端），通过连接到服务器达到向服务器发送一个或多个HTTP的请求的目的。
一个HTTP"服务器"同样也是一个应用程序（通常是一个Web服务，如Nginx、Apache Web服务器或IIS服务器等），通过接收客户端的请求并向客户端发送HTTP响应数据。
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。
URL：统一和资源定位符
3、客户端请求消息
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
(QQ音乐_百度搜索,此链接可看请求头的内容)
4、服务器响应消息
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
实例
下面实例是一点典型的使用GET来传递数据的实例：
客户端请求：
Connected to www.testpm.cn (47.244.247.240) port 80 (#0) > GET /hello.txt HTTP/1.1 # 请求方式与版本协议。 > User-Agent: curl/7.29.0 #用什么客户端访问 > Host: www.testpm.cn #主机名，域名。主机和端口号， > Accept: */* #匹配什么文件类型，“*” 是通用匹配。匹配所有类型
服务端响应:
< HTTP/1.1 200 OK #请求返回的状态码 < Server: nginx/1.16.0 #请求的服务和版本号 < Date: Thu, 04 Jul 2019 08:19:40 GMT < Content-Type: text/plain #文本类型，有html，plain:普通文本 < Content-Length: 12 < Last-Modified: Thu, 04 Jul 2019 08:13:25 GMT < Connection: keep-alive #是否支持长连接 < ETag: "5d1db525-c" #标识，每次访问与第一次访问的值进行校验一致返回304否则返回200 < Accept-Ranges: bytes
输出结果:
hello world
5、HTTP 请求方法
根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
重点方法：
GET：单纯获取数据（获取一个index.html页面）
POST：上传/创建文件（会产生新的数据）
PUT：保存数据（覆盖/更新文件、图片等，不会产生新的数据）
DELETE：删除
6、HTTP 响应头信息
HTTP请求头提供了关于请求，响应或者其他的发送实体的信息。
在本章节中我们将具体来介绍HTTP响应头信息。
| 应答头 | 说明 |
|---|---|
| Allow | 服务器支持哪些请求方法（如GET、POST等）。 |
| Content-Encoding | 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。 |
| Content-Length | 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。 |
| Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。 |
| Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ |
| Last-Modified | 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 |
| Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
| Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。 注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。 注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV="Refresh" ...＞。 注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。 |
| Server | 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。 |
| Set-Cookie | 设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。 |
7、HTTP 状态码
当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。
HTTP状态码的英文为HTTP Status Code。
下面是常见的HTTP状态码：
-
200 - 请求成功
-
301 - 资源（网页等）被永久转移到其它URL
-
302 - 资源（网页等）临时转移到其它URL
-
404 - 请求的资源（网页等）不存在
-
403 - 服务器理解请求客户端的请求，但是拒绝执行此请求
-
500 - 内部服务器错误
HTTP状态码分类
HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：
HTTP状态码列表:
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
HTTPS
https 介绍
HTTPS（全称：HyperText Transfer Protocol over Secure Socket Layer），其实 HTTPS 并不是一个新鲜协议，Google 很早就开始启用了，初衷是为了保证数据安全。 近些年，Google、Baidu、Facebook 等这样的互联网巨头，不谋而合地开始大力推行 HTTPS， 国内外的大型互联网公司很多也都已经启用了全站 HTTPS，这也是未来互联网发展的趋势。
1、加密算法
-
对称加密
A要给B发送数据
1、A做一个对称密钥 2、使用密钥给文件加密 3、发送加密以后的文件和钥匙 4、B拿钥匙解密
加密和解密都是使用的同一个密钥。
-
非对称加密 ---- 公钥加密，私钥解密
A要给B发送数据
1、B做一对非对称的密钥（公钥、私钥）
2、发送公钥给A
3、A拿公钥对数据进行加密
4、发送加密后的数据给B
5、B拿私钥解密
-
哈希算法 将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多。
例如：MD5、SHA-1、SHA-2、SHA-256 等
-
数字签名 签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。
2、HTTPS 协议介绍
HTTP 协议（Hyper Text Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。
-
HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。
-
如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS
SSL/TLS :SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层为数据通讯进行加密提供安全支持。
SSL协议可分为两层： SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。相当于连接
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 相当于通信
SSL协议提供的服务主要有：
ssl:身份认证和数据加密。保证数据完整性 1）认证用户和服务器，确保数据发送到正确的客户机和服务器；
2）加密数据以防止数据中途被窃取；
3）维护数据的完整性，确保数据在传输过程中不被改变。
3、HTTPS 原理
1、HTTP 访问过程
如上图所示，HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程，数据全部明文传输，“裸奔”在互联网上，所以很容易遭到黑客的攻击，如下：
可以看到，客户端发出的请求很容易被黑客截获，如果此时黑客冒充服务器，则其可返回任意信息给客户端，而不被客户端察觉。
所以 HTTP 传输面临的风险有：
-
窃听风险：黑客可以获知通信内容。
-
篡改风险：黑客可以修改通信内容。
-
冒充风险：黑客可以冒充他人身份参与通信。
那有没有一种方式既可以安全的获取公钥，又能防止黑客冒充呢？ 那就需要用到终极武器了：SSL 证书（申购）
-
证书：.crt, .pem
-
私钥：.key
-
证书请求文件：.csr
如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有：
（1）证书的发布机构(CA认证中心)
（2）证书的有效期
（3）公钥
（4）证书所有者
（5）签名 ----- 签名就可以理解为是钞票里面的一个防伪标签。
客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
(8）client与web协商对称加密算法，client生成一个对称加密密钥并使用web公钥加密，发送给web服务器，web服务器使用web私钥解密
(9)使用对称加密密钥传输数据，并校验数据的完整性
所以相比HTTP，HTTPS 传输更加安全
（1） 所有信息都是加密传播，黑客无法窃听。
（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。
（3） 配备身份证书，防止身份被冒充。
3、HTTPS 总结
综上所述，相比 HTTP 协议，HTTPS 协议增加了很多握手、加密解密等流程，虽然过程很复杂，但其可以保证数据传输的安全。
HTTPS 缺点：
-
SSL 证书费用很高，以及其在服务器上的部署、更新维护非常繁琐
-
HTTPS 降低用户访问速度（多次握手）
-
网站改用HTTPS 以后，由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）
-
HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加大量机器（https访问过程需要加解密）
4、Nginx HTTPS 部署实战
-
申请证书与认证
-
证书下载与配置
-
问题分析与总结
1、申请证书与认证
要搭建https服务首先需有SSL证书，证书通常是在第三方申请，在阿里云的安全服务中有SSL证书这一项，可以在里面申请免费的证书；
也可以在自己电脑中生成，虽然也能完成加密，但是浏览器是不认可的，因此最好还是去第三方申请
1、证书申请
阿里云提供免费的证书，不需要人工审核，用来做测试是非常不错的选择，申请地址如下URL。
https://yundunnext.console.aliyun.com/?p=casnext#/certExtend/free
点击购买阿里免费SSL证书
选择之后，一直点击下一步，便可购买完成，免费购买证书之后笔者需要回到证书控制台，在控制台点击证书申请。
2、域名验证
补全个人信息之后，还需要给阿里云验证当前域名是属于本人的，验证方式有两种，第一种是通过dns解析认证，第二种是通过上传验证文件认证，这里采用的dns解析认证，如下图
2、通过阿里云来验证
在确保文件放置正确之后，关键的是能让阿里云能访问到，阿里云这里提供了一个检查配置的功能，在下载验证文件页面，有一个检测配置的链接，单击之后便可进行检查，如下图。
当点击 检查配置 之后，如果阿里云能够正常访问，则会在左侧给出提示，现在可以返回证书列表，在列表中可以看到当前状态为审核中
审核因为不需要人为干预，所以很快就能下发证书，下发证书的时间大约是2分钟左右。
2、证书下载与配置
1、证书下载
证书签发之后，可以在列表中可以看到状态栏中为 已签发 ，同时操作栏可以下载以及查看详情等，如下图所示
点击下载后，会跳转到下载详情页面，在下载详情页可以选择自己相对应的web服务，比如使用nginx，当选择nginx之后，下方还会很贴心的提示如何配置，下载nginx配置文件。
下载配置文件之后，需要将其解压，解压之后可以看见里面包含了两个证书文件
xxx.key
xxx.pem
接着需要把这两个证书文件给复制到服务器当中去，首先需要在服务器创建对应的文件夹，参考命令如下
[root@xiaoxuan ~]# cd /etc/nginx/ && mkdir cert
在服务器创建完成对应文件夹之后，将证书文件复制到服务器中
[root@xiaoxuan ~]# ls 8160397_www.amylife.online_nginx.zip [root@xiaoxuan ~]# unzip 8160397_www.amylife.online_nginx.zip Archive: 8160397_www.amylife.online_nginx.zip Aliyun Certificate Download inflating: 8160397_www.amylife.online.pem inflating: 8160397_www.amylife.online.key [root@xiaoxuan ~]# ll -rw-r--r-- 1 root root 1675 Jul 22 15:29 8160397_www.amylife.online.key -rw-r--r-- 1 root root 4170 Jul 22 15:30 8160397_www.amylife.online_nginx.zip -rw-r--r-- 1 root root 3834 Jul 22 15:29 8160397_www.amylife.online.pem [root@xiaoxuan ~]# cp *.key *.pem /etc/nginx/cert/ [root@xiaoxuan ~]# cd /etc/nginx/cert/ [root@xiaoxuan cert]# mv 8160397_www.amylife.online.key www.amylife.online.key [root@xiaoxuan cert]# mv 8160397_www.amylife.online.pem www.amylife.online.pem
2、证书配置
证书复制完成之后，可以对nginx配置文件进行更改，使用vim命令编辑nginx配置文件，参考命令如下：
[root@xiaoxuan ~]# cd /etc/nginx/conf.d/
[root@xiaoxuan conf.d]# cp default.conf default.conf.bak
[root@xiaoxuan conf.d]# mv default.conf nginx_ssl.conf
[root@xiaoxuan conf.d]# vim nginx_ssl.conf
[root@xiaoxuan conf.d]# cat /etc/nginx/conf.d/nginx_ssl.conf
server {
listen 443 ssl;
server_name www.testpm.cn;
access_log /var/log/nginx/https_access.log main;
#ssl on;
ssl_certificate /etc/nginx/cert/www.amylife.online.pem;
ssl_certificate_key /etc/nginx/cert/www.amylife.online.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
3、重启Nginx
修改配置文件之后，需要测试nginx配置文件是否正确
[root@xiaoxuan cert]# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful [root@xiaoxuan cert]# nginx -s reload
如果看到浏览器，展示安全，并且显示绿色就说明大功告成了!
5、Nginx 性能优化
当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下几个方面进行探讨
-
当前系统结构瓶颈
-
了解业务模式
-
性能与安全
1、当前系统结构瓶颈
首先需要了解的是当前系统瓶颈，用的是什么，跑的是什么业务。里面的服务是什么样子，每个服务最大支持多少并发。比如针对Nginx而言，我们处理静态资源效率最高的瓶颈是多大？
可以通过查看当前cpu负荷，内存使用率，进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈，如分析对应的日志，查看请求数量。也可以通过nginx http_stub_status_module模块来查看对应的连接数，总握手次数，总请求数。也可以对线上进行压力测试，来了解当前的系统的性能，并发数，做好性能评估。
2、了解业务模式
虽然我们是在做性能优化，但还是要熟悉业务，最终目的都是为业务服务的。我们要了解每一个接口业务类型是什么样的业务，比如电子商务抢购模式，这种情况平时流量会很小，但是到了抢购时间，流量一下子就会猛涨。也要了解系统层级结构，每一层在中间层做的是代理还是动静分离，还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理
3、性能与安全
性能与安全也是一个需要考虑的因素，往往大家注重性能忽略安全或注重安全又忽略性能。比如说我们在设计防火墙时，如果规则过于全面肯定会对性能方面有影响。如果对性能过于注重在安全方面肯定会留下很大隐患。所以大家要评估好两者的关系，把握好两者的孰重孰轻，以及整体的相关性。权衡好对应的点。
4、系统与Nginx性能优化
大家对相关的系统瓶颈及现状有了一定的了解之后，就可以根据影响性能方面做一个全体的评估和优化。
-
网络（网络流量、是否有丢包，网络的稳定性都会影响用户请求）
-
系统（系统负载、饱和、内存使用率、系统的稳定性、硬件磁盘是否有损坏）
-
服务（连接优化、内核性能优化、http服务请求优化都可以在nginx中根据业务来进行设置）
-
程序（接口性能、处理请求速度、每个程序的执行效率）
-
数据库、底层服务
上面列举出来每一级都会有关联，也会影响整体性能，这里主要关注的是Nginx服务这一层。
1、文件句柄
在linux/unix操作系统中一切皆文件，我们的设备是文件，文件是文件，文件夹也是文件。当我们用户每发起一次请求，就会产生一个文件句柄。文件句柄可以简单的理解为文件句柄就是一个索引。文件句柄就会随着请求量的增多,进程调用频繁增加，那么产生的文件句柄也就会越多。
系统默认对文件句柄是有限制的，不可能会让一个进程无限制的调用句柄。因为系统资源是有限的，所以我们需要限制每一个服务能够使用多大的文件句柄。操作系统默认使用的文件句柄是1024个句柄。
2、设置方式
-
系统全局性修改
-
用户局部性修改
-
进程局部性修改
3、系统全局性修改和用户局部性修改
[root@nginx-server ~]# vim /etc/security/limits.conf
#* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 #root只是针对root这个用户来限制，soft只是发提醒，操作系统不会强制限制,一般的站点设置为一万左右就ok了 root soft nofile 65535 root hard nofile 65535 # *代表通配符 所有的用户 * soft nofile 25535 * hard nofile 25535
可以看到root和*，root代表是root用户，*代表的是所有用户，后面的数字就是文件句柄大小。大家可以根据个人业务来进行设置。
4、进程局部性修改
[root@nginx-server ~]# vim /etc/nginx/nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_rlimit_nofile 65535; #进程限制
events {
worker_connections 1024; #最大连接数
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'"$args" "$request_uri"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
worker_rlimit_nofile 是在进程上面进行限制。
5、cpu的亲和配置
cpu的亲和能够使nginx对于不同的work工作进程绑定到不同的cpu上面去。就能够减少在work间不断切换cpu，把进程通常不会在处理器之间频繁迁移，进程迁移的频率小，来减少性能损耗。nginx 亲和配置
查看cpu核心数
[root@nginx-server ~]# cat /proc/cpuinfo|grep "cpu cores"|uniq
查看cpu使用率
[root@nginx-server ~]#top 回车后按 1
6、配置worker_processes
[root@nginx-server ~]# vim /etc/nginx/nginx.conf 将刚才查看到自己cpu * cpu核心就是worker_processes worker_processes 2; #根据自己cpu核心数配置/这里也可以设置为auto
7、cpu
假设 配置是2cpu，每个cpu是8核，配置如下：
worker_processes 16; worker_cpu_affinity 1010101010101010 0101010101010101;
在nginx 1.9版本之后，就帮我们自动绑定了cpu;
worker_cpu_affinity auto;
8、nginx通用配置优化
#将nginx进程设置为普通用户，为了安全考虑
user nginx;
#当前启动的worker进程，官方建议是与系统核心数一致
worker_processes 2;
#方式一，就是自动分配绑定
worker_cpu_affinity auto;
#日志配置成warn
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
#针对 nginx 句柄的文件限制
worker_rlimit_nofile 35535;
#事件模型
events {
#使用epoll内核模型
use epoll;
#每一个进程可以处理多少个连接，如果是多核可以将连接数调高 worker_processes * 1024
worker_connections 10240;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
charset utf-8; #设置字符集
#设置日志输出格式，根据自己的情况设置
log_format main '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'"$args" "$request_uri"';
access_log /var/log/nginx/access.log main;
sendfile on; #对静态资源的处理比较有效
#tcp_nopush on; #如果做静态资源服务器可以打开
keepalive_timeout 65;
########
#Gzip module
gzip on; #文件压缩默认可以打开
include /etc/nginx/conf.d/*.conf;
}
6、ab接口压力测试工具
ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。
[root@nginx-server ~]# yum install httpd-tools -y [root@nginx-server ~]# ab -n 2000 -c 2 http://127.0.0.1/ -n 总的请求数 -c 并发数
1、参数选项
-n：即requests，用于指定压力测试总共的执行次数 -c：即concurrency，用于指定的并发数 -t：即timelimit，等待响应的最大时间(单位：秒) -b：即windowsize，TCP发送/接收的缓冲大小(单位：字节) -p：即postfile，发送POST请求时需要上传的文件，此外还必须设置-T参数 -u：即putfile，发送PUT请求时需要上传的文件，此外还必须设置-T参数 -T：即content-type，用于设置Content-Type请求头信息，例如：application/x-www-form-urlencoded，默认值为text/plain -v：即verbosity，指定打印帮助信息的冗余级别 -w：以HTML表格形式打印结果 -i：使用HEAD请求代替GET请求 -x：插入字符串作为table标签的属性 -y：插入字符串作为tr标签的属性 -z：插入字符串作为td标签的属性 -C：添加cookie信息，例如："Apache=1234"(可以重复该参数选项以添加多个) -H：添加任意的请求头，例如："Accept-Encoding: gzip"，请求头将会添加在现有的多个请求头之后(可以重复该参数选项以添加多个) -A：添加一个基本的网络认证信息，用户名和密码之间用英文冒号隔开 -P：添加一个基本的代理认证信息，用户名和密码之间用英文冒号隔开 -X：指定使用的和端口号，例如:"126.10.10.3:88" -V：打印版本号并退出 -k：使用HTTP的KeepAlive特性 -d：不显示百分比 -S：不显示预估和警告信息 -g：输出结果信息到gnuplot格式的文件中 -e：输出结果信息到CSV格式的文件中 -r：指定接收到错误信息时不退出程序 -H：显示用法信息，其实就是ab -help
2、内容解释
Server Software: nginx/1.10.2 (服务器软件名称及版本信息) Server Hostname: 192.168.1.106(服务器主机名) Server Port: 80 (服务器端口) Document Path: /index1.html. (供测试的URL路径) Document Length: 3721 bytes (供测试的URL返回的文档大小) Concurrency Level: 1000 (并发数) Time taken for tests: 2.327 seconds (压力测试消耗的总时间) Complete requests: 5000 (的总次数) Failed requests: 688 (失败的请求数) Write errors: 0 (网络连接写入错误数) Total transferred: 17402975 bytes (传输的总数据量) HTML transferred: 16275725 bytes (HTML文档的总数据量) Requests per second: 2148.98 [#/sec] (mean) (平均每秒的请求数) 这个是非常重要的参数数值，服务器的吞吐量 Time per request: 465.338 [ms] (mean) (所有并发用户(这里是1000)都请求一次的平均时间) Time request: 0.247 [ms] (mean, across all concurrent requests) (单个用户请求一次的平均时间) Transfer rate: 7304.41 [Kbytes/sec] received 每秒获取的数据长度 (传输速率，单位：KB/s) ... Percentage of the requests served within a certain time (ms) 50% 347 ## 50%的请求在347ms内返回 66% 401 ## 60%的请求在401ms内返回 75% 431 80% 516 90% 600 95% 846 98% 1571 99% 1593 100% 1619 (longest request)
3、示例演示
注意事项
● 测试机与被测试机要分开
● 不要对线上的服务器做压力测试
● 观察测试工具ab所在机器，以及被测试的机器的CPU、内存、网络等都不超过最高限度的75%
[root@nginx-server ~]# ab -n 50 -c 2 http://www.testpm.cn/ This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.testpm.cn (be patient).....done Server Software: nginx/1.16.0 Server Hostname: www.testpm.cn Server Port: 80 Document Path: / Document Length: 612 bytes Concurrency Level: 2 Time taken for tests: 2.724 seconds Complete requests: 50 Failed requests: 0 Write errors: 0 Total transferred: 42250 bytes HTML transferred: 30600 bytes Requests per second: 18.35 [#/sec] (mean) Time per request: 108.968 [ms] (mean) Time per request: 54.484 [ms] (mean, across all concurrent requests) Transfer rate: 15.15 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 42 52 17.3 46 137 Processing: 43 54 20.8 47 170 Waiting: 42 53 20.7 47 170 Total: 84 106 28.9 93 219 Percentage of the requests served within a certain time (ms) 50% 93 66% 96 75% 101 80% 130 90% 153 95% 161 98% 219 99% 219 100% 219 (longest request)
扫一扫
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
