前端必备 Nginx 配置，kafka 原理解析
proxy_pass dev.server.com;
}
}
这样可以完美绕过浏览器的同源策略：fe.server.com 访问 nginx 的 fe.server.com 属于同源访问，而 nginx 对服务端转发的请求不会触发浏览器的同源策略。
请求过滤
根据状态码过滤
error_page 500 501 502 503 504 506 /50x.html;
location = /50x.html {
#将跟路径改编为存放 html 的路径。
root /root/static/html;
}
根据 URL 名称过滤，精准匹配 URL，不匹配的 URL 全部重定向到主页。
location / {
rewrite ^.*$ /index.html redirect;
}
根据请求类型过滤。
if ( r e q u e s t m e t h o d ! ? ( G E T ∣ P O S T ∣ H E A D ) request_method !~ ^(GET|POST|HEAD) requestm?ethod!?(GET∣POST∣HEAD) ) {
return 403;
}
配置 gzip
GZIP 是规定的三种标准 HTTP 压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTML、CSS、JavaScript 等资源文件。
对于文本文件，GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3。
并不是每个浏览器都支持 gzip 的，如何知道客户端是否支持 gzip 呢，请求头中的 Accept-Encoding 来标识对压缩的支持。
image
启用 gzip 同时需要客户端和服务端的支持，如果客户端支持 gzip 的解析，那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了,我们可以通过 nginx 的配置来让服务端支持 gzip。下面的 respone 中 content-encoding:gzip，指服务端开启了 gzip 的压缩方式。
gzip on;
gzip_http_version 1.1;
gzip_comp_level 5;
gzip_min_length 1000;
gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;
gzip
开启或者关闭 gzip 模块
默认值为 off
可配置为 on / off
gzip_http_version
启用 GZip 所需的 HTTP 最低版本
默认值为 HTTP/1.1
这里为什么默认版本不是 1.0 呢？
HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性。
启用持久连接情况下，服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。
为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。
HTTP/1.1 默认支持 TCP 持久连接，HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置，而在 HTTP/1.0 中，这种机制只有 Content-Length。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。
nginx 同样有着配置 chunked 的属性 chunked_transfer_encoding，这个属性是默认开启的。
Nginx 在启用了 GZip 的情况下，不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB(Time To First Byte，首字节时间，WEB 性能优化重要指标)。这样唯一的问题是，Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。
所以，在 HTTP1.0 中如果利用 Nginx 启用了 GZip，是无法获得 Content-Length 的，这导致 HTTP1.0 中开启持久链接和使用 GZip 只能二选一，所以在这里 gzip_http_version 默认设置为 1.1。
gzip_comp_level
压缩级别，级别越高压缩率越大，当然压缩时间也就越长（传输快但比较消耗 cpu）。
默认值为 1
压缩级别取值为 1-9
gzip_min_length
设置允许压缩的页面最小字节数，Content-Length 小于该值的请求将不会被压缩
默认值:0
当设置的值较小时，压缩后的长度可能比原文件大，建议设置 1000 以上
gzip_types
要采用 gzip 压缩的文件类型(MIME 类型)
默认值:text/html(默认不压缩 js/css)
负载均衡
什么是负载均衡
如上面的图，前面是众多的服务窗口，下面有很多用户需要服务，我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口，来达到资源的充分利用以及更少的排队时间。
把前面的服务窗口想像成我们的后端服务器，而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器，以达到服务端资源的充分利用和更少的请求时间。
nginx 如何实现负载均衡
Upstream 指定后端服务器地址列表
upstream balanceServer {
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
在 server 中拦截响应请求，并将请求转发到 Upstream 中配置的服务器列表。
server {
server_name fe.server.com;
listen 80;
location /api {
proxy_pass http://balanceServer;
}
}
上面的配置只是指定了 nginx 需要转发的服务端列表，并没有指定分配策略。
nginx 实现负载均衡的策略
轮询策略
默认情况下采用的策略，将所有客户端请求
轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。
upstream balanceServer {
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
最小连接数策略
将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。
upstream balanceServer {
least_conn;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
最快响应时间策略
依赖于 NGINX Plus，优先分配给响应时间最短的服务器。
upstream balanceServer {
fair;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
客户端 ip 绑定
来自同一个 ip 的请求永远只分配一台服务器，有效解决了动态网页存在的 session 共享问题。
upstream balanceServer {
ip_hash;
server 10.1.22.33:12345;
server 10.1.22.34:12345;
server 10.1.22.35:12345;
}
静态资源服务器
location ~* .(png|gif|jpg|jpeg)$ {
root /root/static/;
autoindex on;
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论