nginx1.20.2 编译安装-支持https正向代理

朱清震

已于 2022-06-12 18:16:59 修改

阅读量4.8k

点赞数

分类专栏： linux nginx 文章标签： nginx linux

于 2018-10-10 21:14:20 首次发布

本文链接：https://blog.csdn.net/zqz_zqz/article/details/83003268

版权

linux 同时被 2 个专栏收录

18 篇文章 3 订阅

订阅专栏

nginx

1 篇文章 0 订阅

订阅专栏

需要root权限安装gcc

yum install -y gcc gcc-c++

依赖以下三方库

rewrite 模块需要 pcre 库 ( 下载: http://www.pcre.org/ )
gzip 模块需要 zlib 库 ( 下载: http://www.zlib.net/ )
ssl 功能需要 openssl 库 ( 下载: http://www.openssl.org/ )
支持https正向代理模块（下载：https://github.com/chobits/ngx_http_proxy_connect_module#configuration-example）

下载nginx及其三方库
http://nginx.org/en/download.html



wget http://nginx.org/download/nginx-1.20.2.tar.gz
wget https://nchc.dl.sourceforge.net/project/libpng/zlib/1.2.11/zlib1211.zip --no-check-certificate
wget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz 
wget https://www.openssl.org/source/openssl-1.1.1o.tar.gz --no-check-certificate
wget 
https://github.com/chobits/ngx_http_proxy_connect_module/archive/refs/heads/master.zip --no-check-certificate

下载后的文件

[root@iZj5ebasf81hz5x9xqo6wgZ nginx]# ll
total 13416
-rw-r--r-- 1 root root   51135 Jun 12 11:57 master.zip
-rw-r--r-- 1 root root 1062124 Nov 16  2021 nginx-1.20.2.tar.gz
-rw-r--r-- 1 root root   10289 Jun 12 10:21 ngx_http_proxy_connect_module-master.zip
-rw-r--r-- 1 root root 9856386 May  3 22:02 openssl-1.1.1o.tar.gz
-rw-r--r-- 1 root root 1996552 Apr  9  2014 pcre-8.35.tar.gz
-rw-r--r-- 1 root root  747422 Jan 16  2017 zlib1211.zip

解压下载的文件

tar -zxvf nginx-1.20.2.tar.gz
tar -zxvf pcre-8.35.tar.gz
tar -zxvf openssl-1.1.1o.tar.gz
unzip zlib1211.zip
unzip master.zip

解压后的文件如下：

执行以下命令编译安装：

cd ./nginx-1.20.2

patch -p1 < ../ngx_http_proxy_connect_module-master/patch/proxy_connect_rewrite_1018.patch 


./configure --prefix=./nginx-1.20.2  --add-module=../ngx_http_proxy_connect_module-master  --with-pcre=../pcre-8.35 --with-zlib=../zlib-1.2.11 --with-openssl=../openssl-1.1.1o  --with-http_stub_status_module --with-pcre --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module  --with-stream

make 

make install

http与https正向代理配置

http正向代理配置

server {
        listen 8777;
        #resolver  223.5.5.5;  如果不是纯ip访问，使用域名或localhost，必须要指定DNS服务器IP地址
        location / {
                proxy_pass http://$http_host$request_uri; 
        }
}

https正向代理配置

server {
  
    # resolver  223.5.5.5; 如果不是纯ip访问，使用域名或localhost，必须要指定DNS服务器IP地址
    #监听8444
    listen 8444;
    #正向代理转发https请求
    proxy_connect;
    # 只允许代理443与563端口
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_read_timeout     10s;
    proxy_connect_send_timeout     10s;
    location / {
        proxy_pass http://$host;
        proxy_set_header Host $host;
    }
}

检查配置文件

./nginx -t

nginx -t -c /path/to/nginx.conf

修改配置文件后重新加载

./nginx -s reload

关闭nginx

nginx -s stop :快速停止

nginx quit ：完整有序的停止nginx

开启gzip ，http配置：

    gzip on;                            #开启Gzip
    gzip_min_length 1k;                 #大于1K的文件才压缩
    gzip_buffers 4 16k;                 #压缩文件的buffer 
    gzip_comp_level 3;                  #压缩级别，1-10，数字越大压缩的越好，时间也越长
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;   
   #压缩的文件Content-type列表，如果发现某种文件没有被压缩，只要看下请求中的Content-type字段是什么，加到这里即可
    gzip_vary off;                           #跟Squid等缓存服务有关，on的话会在Header里增加"Vary: Accept-Encoding"，这里没有用到
    gzip_disable "MSIE [1-6]\.";     #IE6不支持Gzip

验证是否成功

curl -I -H "Accept-Encoding: gzip, deflate" "http://172.31.14.63:8000/MyApp/resources/fastclick/fastclick.js"

[work@iZj5eh1b7ra872hrrqqlvgZ sbin]$ curl -I -H "Accept-Encoding: gzip, deflate" "http://172.31.14.63:8000/MyApp/resources/fastclick/fastclick.js"
HTTP/1.1 200 OK
Server: nginx/1.9.15
Date: Wed, 10 Oct 2018 12:37:57 GMT
Content-Type: application/javascript
Content-Length: 26875
Last-Modified: Thu, 20 Sep 2018 10:18:18 GMT
Connection: keep-alive
ETag: "5ba373ea-68fb"
Expires: Fri, 09 Nov 2018 12:37:57 GMT
Cache-Control: max-age=2592000
Accept-Ranges: bytes

压缩失败

[work@iZj5eh1b7ra872hrrqqlvgZ sbin]$ curl -I -H "Accept-Encoding: gzip, deflate" "http://172.31.14.63:8000/MyApp/resources/fastclick/fastclick.js"
HTTP/1.1 200 OK
Server: nginx/1.9.15
Date: Wed, 10 Oct 2018 12:40:25 GMT
Content-Type: application/javascript
Last-Modified: Thu, 20 Sep 2018 10:18:18 GMT
Connection: keep-alive
ETag: W/"5ba373ea-68fb"
Expires: Fri, 09 Nov 2018 12:40:25 GMT
Cache-Control: max-age=2592000
Content-Encoding: gzip

Content-Encoding: gzip 代表压缩成功

预压缩：static_gzip模块

需要在编译的时候添加以下参数：
--with-http_gzip_static_module

接到请求后，会到url相同的路径的文件系统去找扩展名为“.gz”的文件
比如：http://localhost/js/base.css
nginx就会先查找 js/base.css.gz 这个文件，如果存在直接发送.gz文件，若不存在，则对文件gzip压缩，再发送，这样避免重复的压缩无谓的消耗资源，这个模块不受gzip_types限制，会对所有请求有效。所以建议不要在全局上使用，因为一般来说大部分都是动态请求，是不会有.gz这个文件的，建议只在局部我们确认有.gz的目录中使用。
Nginx不会自动的将压缩结果写入文件系统，这点不同于lighttpd，所以如果想使用static_gzip模块，需要自己写脚本生成.gz文件。

预压缩文件：

gzip -c -9 com.ronghui.sibada.apk > com.ronghui.sibada.apk.gz

开启动静分离：

        #静态内容从本地磁盘加载
        location ~ .*\.(apk|appcache|css|eot|gif|html|ico|jpg|js|json|png|ttf|woff) {
            root /home/work/apps/tomcat-app/webapps/ROOT;
            expires 30d; #缓存30天
        }
        #动态内容从服务器上请求
        location ~ .*$ {
                index index;
                proxy_pass http://localhost:9000;
        }

配置静态内容时要统计有哪些静态文件类型需要配置,以下脚本可以统计当前路径下全部文件扩展名：

通过源码统计文件扩展名

find ./ -type f | sed -e 's/.*\.//' | sort | uniq -c | sort -n



通过tomcat access日志来统计要下载的静态文件扩展名

grep "GET " localhost_access_log.2018-10*.txt |grep " 200 " | awk -F ' HTTP/1.1' '{print $1}' | awk -F '?' '{print $1}' | awk -F '\.' '{print $(NF)}'| grep -v '\- \-'|sort |uniq > a.txt

以下内容转载自：

文章-阿里云开发者社区-云计算社区-阿里云

Nginx 默认不压缩 HTTP/1.0 是因为这个指令，将它的值改为 1.0 就能解决问题。

对于文本文件，GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3。这么好的事情，Nginx 改一下配置就可以支持，为什么它默认不开启？

Nginx 对于满足条件（请求头中有 Accept-Encoding: gzip，响应内容的 Content-Type 存在于 gzip_types 列表）的请求会采用即时压缩（On-The-Fly Compression），整个压缩过程在内存中流式完成。也就是说，Nginx 不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB（Time To First Byte，首字节时间，WEB 性能优化重要指标）。这样唯一的问题是，Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。

我们还知道，HTTP/1.1 默认支持 TCP 持久连接（Persistent Connection），HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。
HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性，要想提高 HTTP 性能，启用持久连接就显得尤为重要。

明白以上两点，马上就能水落石出了：对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置。而在 HTTP/1.0 中，这种机制只有 Content-Length。
于是，对于本文前面提出的情况，HTTP Server 只能要么不压缩，要么不启用持久连接（对于非持久连接，TCP 断开就可以认为 HTTP 报文结束），而 Nginx 默认选择的是前者。

那么在 HTTP/1.1 中，这个问题解决了吗？当然！我在之前的文章中讲过，HTTP/1.1 新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。有兴趣的同学可以查看我的这篇文章：HTTP 协议中的 Transfer-Encoding。

在很久以前，我们为了降低服务端的 CPU 压力，往往会把静态资源预先压缩为 .gz 文件，这样 HTTP Server 不需要即时压缩文件，也就不会遇到本文提到的这个问题。但随着时间的推移，现在几乎没人会这么干了，想要了解预先压缩细节的同学可以看下 Nginx 的 ngx_http_gzip_static_module 模块。

理论知识先写到这里，最后用实践来验证一下：

首先，不启用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 请求报文测试：

可以看到，尽管我的请求报文中指明了可以接受 GZip，但是返回的内容依然是未压缩的；同时服务端响应了 Content-Length 和 Connection: keep-alive，连接并没有断开。也就是说对于 HTTP/1.0 请求，Nginx 为了尽可能启用持久连接，放弃了 GZip，这是 Nginx 的默认策略。
然后，启用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 请求报文测试：

可以看到，这次的请求报文与上次完全一样，但是结果截然不同：虽然返回的内容被压缩了，但是连接也被断开了，服务端返回了 Connection: close。原因就是之前说过的，动态压缩导致无法事先得知响应内容长度，在 HTTP/1.0 中只能依靠断开连接来让客户端知道响应结束了。

最后，使用 HTTP/1.1 请求报文测试：

可以看到，由于请求报文是 HTTP/1.1 的，Nginx 能知道这个客户端支持 HTTP/1.1 的 Transfer-Encoding: chunked，于是通过分块传输解决了所有问题：既启用了压缩，也启用了持久连接。

那么，对于 HTTP/1.0 请求，我们是让 Nginx 放弃持久连接好，还是放弃 GZip 好呢？

实际上，由于 HTML 文档或 JSON 接口一般都是用 PHP、Node.js 等服务端语言动态输出，即使不压缩，Nginx 也无法事先得知它的 Content-Length，在 HTTP/1.0 中无论如何都无法启用持久连接，这时还不如启用 GZip 省点流量。

对于 JS、CSS 等事先可以知道大小的静态文本文件，我的建议是，移动端首次访问把重要的 JS、CSS 都内联在 HTML 中，然后存入 localStorage，后续不输出；不重要的 JS、CSS 通过外链引入，启用 GZip，牺牲 keep-alive 来达到减少流量的目的。

而对于图片类静态资源，由于主流图片格式都已经经过高度压缩，实在没必要再浪费服务端 CPU 来开启 GZip，这样也不会对 keep-alive 机制产生影响。

本文先写到这里，欢迎来博客原文进行评论、交流。浏览器的 GZip 其实还有很多有趣的小故事，先卖个关子，以后有空再写。

本文链接：从 Nginx 默认不压缩 HTTP/1.0 说起 | JerryQu 的小站

在http 的响应头中有时会见到这样的字段：Transfer-Encoding: chunked，这是一种分段传输数据的方式。如果对此格式不了解，直接将响应体以某一编码转换成字符串，就会出现乱码。result = new String(data, "utf-8");data为接受的数据。
分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网
页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。

通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。
然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。

格式
如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），然后是数据本身，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。

最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。

消息最后以CRLF结尾。

例子

编码的应答

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

编码应答的解释
前两个块的数据中包含有显式的\r\n字符。

"This is the data in the first chunk\r\n"      (37 字符 => 十六进制: 0x25)
"and this is the second one\r\n"               (28 字符 => 十六进制: 0x1C)
"con"                                          (3  字符 => 十六进制: 0x03)
"sequence"                                     (8  字符 => 十六进制: 0x08)

应答需要以0长度的块（ "0\r\n\r\n".）结束。

解码的数据

This is the data in the first chunk
and this is the second one
consequence

https://zh.wikipedia.org/wiki/%E5%88%86%E5%9D%97%E4%BC%A0%E8%BE%93%E7%BC%96%E7%A0%81

朱清震

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
nginx1.20.2 编译安装-支持https正向代理

需要root权限安装gccyum install -y gcc gcc-c++依赖以下三方库rewrite 模块需要 pcre 库 ( 下载: http://www.pcre.org/ )gzip 模块需要 zlib 库 ( 下载: http://www.zlib.net/ )ssl 功能需要 openssl 库 ( 下载: http://www.openssl.org/ ).........
复制链接

扫一扫

专栏目录