一、http协议
1、为何要学http协议？
用户用浏览器访问网页，默认走的都是http协议，所以要深入研究web层，必须掌握http协议
2、什么是http协议
1、全称Hyper Text Transfer Protocol（超文本传输协议）
### 一个请求得到一个响应包
普通文本：文件内存放的是一些人类认识的文字符号（汉字、英语、阿拉伯数字）
超级文本：除了普通文本内容之外，还有视频、图片、语音、超链接
超文本包含：html文件、css、js、图片、视频、语音
http协议都能传输上述内容，所以说http协议是专用于传输超文本的协议
2、http主要用于B/S架构
3、http是基于tcp协议的
强调：基于http协议发包之前，必须先建立tcp协议的双向通路
应用层协议：依赖于 TCP/IP 协议来实现数据的传输，规定数据传输的格式—-HTTP 协议主要用于在客户端（如浏览器）和服务器之间进行信息交互，规定了请求和响应消息的格式、内容以及交互的规则。
http协议的发展史
网景浏览器（万能客户端）——》各种各样的服务端
http0.9
请求方法：只支持GET方法
请求头：不支持
响应信息：只支持纯文本，不支持图片
无连接/短连接/非持久连接：利用完tcp连接之后会立即回收，所以无连接指的不是说没有连接，而是说没有持久连接/长连接
http协议通信，先建立tcp连接，然后客户端发请求包，服务端收到后发送响应包，服务端一旦发送完响应包之后，服务端会立即主动断开tcp连接，下次http通信还需要重新建立tcp连接
无状态:（一个http协议的请求无法标识自己的身份）
http无法保存状态，比如登录状态—-登录之后再次发送的请求无法识别身份
总结：（0.9的时代，下面两个问题都不是问题）
无连接/短连接/非持久连接—->引发的问题
同一个用户在短期内访问多次服务端，那大量的时候都会消耗在重复创建tcp连接上
在高并发场景下，对服务端是非常大的消耗，客户端的访问速度也会非常的慢
无状态：一个http协议的请求无法标识自己的身份—》引发的问题
如果是登录状态的话，http协议无法保存，那意味着每次请求都需要重新输出一次账号 密码来认证
http1.0
请求方法：支持GET（查）、POST（改）、DELETE（删）、PUT（增）
请求头：支持
响应信息：支持超文本
支持缓存
无连接/短连接/非持久连接
问题：
同一个用户在短期内访问多次服务端，那大量的时候都会消耗在重复创建tcp连接上
在高并发场景下，对服务端是非常大的消耗，客户端的访问速度也会非常的慢
目标：
同一个用户在短期内访问多次服务端，不要重复建立tcp连接，而是能够共用一个tcp链接
解决方案：支持持久连接/长连接 keep-alive
前提：
发送完http响应包之后，服务端立即断tcp连接，这是服务端的默认行为
要改变这种默认行为，要客户端通知服务端才行
实现：
客户端在发送http的请求时，需要再请求头里带上connection: keep-alive这个参数
服务端的keepalive_timeout设置要大于0
服务端收到后读取该参数，服务端会保持与这一个客户端tcp连接一段时间，响应时也会响应头里放connection: keep-alive这个参数
该tcp会保持一段时间 直到达到服务端设置的keepalive_timeout时间
补充：
在http1.0协议例还需要你发请求时你自己加上connection: keep-alive这个参数
在http1.1协议里所有的请求都会自动加上connection: keep-alive，也就是说在http1.1客户端默认就开启了长连接支持
配套的服务端也要开启（服务端的keepalive_timeout设置要大于0,等于0相当于关掉）
—-如果用的是nginx 修改/etc/nginx/nginx.conf
http1.1(主要)
1、默认所有请求都启用长连接，对应服务端需要设置keepalive_timeout大于0
2、Pipelining（请求流水线化/管道化）—–可以连续发送多个请求，但响应也必须按照顺序来
3、分块传输编码chunked—-不使用分块传输：先告知规定大小，当数据包大小到达指定值后就能知道到这里一个包的内容就结束了
使用分块传输：允许服务器在不知道全部响应大小的情况，(比如由数据库动态产生的数据)通过多个小”块”的形式逐步发送HTTP响应给客户端的技术。除非使用了分块编码Transfer-Encoding: chunked，否则响应头首部必须使用Content-Length首部
http2.0（未来）
http协议的格式
储备知识：什么是URI、URL
URI：统一资源标识符
# Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URL：统一资源定位服务，是uri的一种具体实现
http://192.168.71.10:8080/a/b/1.txt?x=1&y=2&page=10#_label5
所有部分：
http:// 协议部分
不写协议，默认http协议
192.168.71.10:8080 ip+port部分
不写端口默认服务端的端口是80
/a/b/1.txt 路径部分
不写路径，默认加一个/结尾
?x=1&y=2&page=10 请求参数部分 通常用于get请求
#_label5 锚 直接跳转到页面的某个部分
一个url地址的路径部分也称之为uri路径
URN：也是uri的一种具体实现 例如：mailto:java-net@java.sun.com。
请求request
包含四部分：
请求首行
GET /a.txt HTTP/1.1
请求方法 请求的路径部分及后续部分 使用http协议版本
请求头
都是key:value格式，用来定制一些参数
空行 # 后面两部分浏览器不可查
请求体数据
请求方法：
GET（查）———-》请求的数据可以放在url地址的？号后
POST（改）———》挟带请求体数据（存入重要数据） # 例如账户的登录
DELETE（删）
PUT（增）
HEAD：类似get请求，不一样的是不会获取响应的数据，但是会获取响应头，而响应头包含着状态码，状态码代表着本次访问是否成功，所以head主要用来检测某个资源是否可以正常访问
OPTIONS 一般用作预检请求，在发真正请求之前先发个options请求预检一下服务端支持哪些http方法、跨域检测等
最常用：
GET
POST
区别：
1、挟带数据的方式不同
2、挟带数据的话post更安全
3、传输数据大小
get与post这两个方法本身没有限制
但因为get方法的数据都放在url地址中，而url地址的长度在一些浏览器中是有限制
所以如果要传一些较大的数据，不能用get方法应该用post方法把数据放入请求里传输
# 在nginx的访问日志中（详情见nginx的基础配置），当浏览器发送一条请求后，在GET日志后往往会跟一个”GET /favicon.icn HTTP/…”的日志，这是浏览器在访问到一个网页后往往会要求在获得一个网站图标进行标识
响应response
四部分：
响应首行
HTTP/1.1 200 OK
协议 状态码
状态码——————–>依赖nginx的return指令响应
2xx：代表访问成功
3xx：本次请求被重定向 301–永久重定向 302–临时重定向
4xx：客户端错误
404：客户端访问的资源不存在
403：客户端没有对目标资源的访问权限
5xx: 服务端错误
503服务端故障
响应头
set-cookie: 要求浏览器把cookie信息存入本地
cache-control: 要求浏览器把一些文件缓存到本地
connection: keep-alive 要求浏览器保持长链接
Content-Type: text/html 告诉浏览器本次返回内容的格式，浏览器会调取相应的功能对相应的内容进行特定格式的解析呈现
text/plain 告诉浏览器本次返回的内容格式是普通文本
空行
响应体
http协议完整的请求与响应流程
浏览器访问一个url地址：http://egonlin.com:80/a/b/1.html
1、浏览器会先问本地dns把域名egonlin.com解析为ip地址
2、浏览器作为客户端会与目标ip:port建立tcp三次握手
3、浏览器会基于http协议封装请求包（osi七层的封包流程）
4、服务端收到包（osi七层的解包流程），拿到一个http协议的请求包，按照http协议来解析请求
会拿到请求路径部分：/a/b/1.html
服务端会打开该文件（对应一个文件描述符）把文件内容从硬盘读入内存
然后服务端程序会基于http协议封装读入内存的数据，形成一个响应包，发给客户端浏览器
5、浏览器收到http协议的响应包之后
先解析响应头，看到响应的状态码，知道本次是否成功
在解析响应头，可以拿到Content-Type就知道该用什么方法来解析内容，如果值为text/html就会
按照html代码的方式来解析返回的内容
再读取内容部分，当成html代码来解析
6、在解析html代码的过程中，有可能遇到css、jss、图片、视频等资源，会发起二次、三次。。。请求
直到把整个页面都渲染完毕
补充：http1.1默认是开启长连接的—》（核心是请求与响应头里都带着connection：keep-alive）
http协议特点
1、无连接
在完成http响应的情况下，http协议默认不会让tcp协议保持链接
问题：高并发场景下，同一个客户端可能在短时间内会重复多次请求服务，无连接会导致大量开销都浪费在重复创建与断开tcp连接上
解决：开启keepalive长连接
在请求与响应头里加上：connection：keep-alive
http1.1默认请求头里就加上了connection：keep-alive
2、无状态
http协议无法保存上一次访问的状态（用户登录信息、权限）
问题：如果后续处理需要前面信息，那必须重传
二、负载均衡—-会话保持（****）
解决方案：cookie session jwt
cookie：由服务端产生，存入客户端浏览器
问题：
1、cookie存的是明文，容易泄露
2、cookie是可以被客户自己篡改
总结：cookie本身没问题，但是单用cookie就有问题，问题如上
session：由服务端产生，存在服务端称之为session(会话)
然后服务端会将该session做一个加密，得到一串加密字符，这串加密字符与 session信息相对应，我们将这串加密字符称之为session id
key-value key–session id value–session
然后服务端会把这个session id存入客户端浏览器的cookie中
优点：
1、客户端无法篡改，更安全
问题：
1、在负载均衡的场景下，需要做会话共享（session存到哪由应用程序代码决定）
2、需要把会话共享的组件例如redis做成集群
增加了管理成本
3、应程序都要依赖redis，意味着redis的性能
会限制整个集群的规模
能不能有一种方案，即能防篡改，也能保持状态、会话———-于是诞生了jwt方案
jwt：由服务端产生，存入客户端——json web token(令牌)
jwt=header+payload+signatrue
header：指定hash算法与类型—-经过base64url算法转换的字符串
payload：状态信息—-经过base64url算法转换的字符串
signature：存放”header+payload+口令”通过hash算法的hash值
# 防篡改—-口令内容只有服务端才知道，所以一旦hash值对不上，一定是前两部分发生了篡改
# base64url不是加密算法，可以进行反解
补充：1、hash算法的特点（文件校验）：
1、只要源内容一样、相同hash算法算出来的结果一定一样，反之亦然
2、不能通过hash值反推出内容
2、cookie是与域有关的，不能跨域，每个域都有自己的cookie,但是jwt可以跨域
使用方式：
1、存储到cookies中
2、存储在localstorage，下次与服务端通信的时候从中取出来放到http请求头的authorization字段中，或者放在post请求的请求体里
优点与缺点：
优点—-支持无状态认证与跨域认证，以及比较容易实现的分布式系统认证
缺点—-无法在使用的过程中废止某个token，jwt一旦发出在到期前都会生效
客户端的存储容易受到xss(跨站脚本攻击)的攻击
了解—-XSS
负载均衡与会话保持案例
1、nfs共享存储（太慢）：把多台后端服务器session文件目录挂载到NFS同一目录
2、mysql（也慢）：通过程序将session存储到mysql数据库，需要程序本身支持
3、redis（块）：通过程序将session存储到redis缓存，需要程序本身支持
1、机器规划
负载均衡：192.168.71.116:9090
web01: 192.168.71.112:8888
web02: 192.168.71.113:8888
mysql数据库：192.168.71.116:3306
2、环境准备
关selinux、firewalld
配置静态ip
时间同步
3、安装数据库
yum remove mysql* mariadb* -y
wget -i -c http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm
yum -y install mysql57-community-release-el7-10.noarch.rpm # 安装
yum -y install mysql-community-server –nogpgcheck
rm -rf /var/lib/mysql/*（仅测试环境使用）
systemctl restart mysqld
grep 'temporary password' /var/log/mysqld.log
[root@db ~]# mysql -uroot -p'+eg31Fdhd/Ft'
mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'Egon@666';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
4、部署两台web：nginx+php-fpm
yum -y install epel-release
yum -y install http://rpms.remirepo.net/enterprise/remi-release-7.rpm #
yum -y install yum-utils
yum -y install php74-php-gd php74-php-pdo php74-php-mbstring php74-php-cli php74-php-fpm php74-php-mysqlnd
# 配置信息（如果是centos9默认以socket方式启动，想用端口方式，需要改listen=127.0.0.1:9000）
cat /etc/opt/remi/php74/php-fpm.d/www.conf |grep -v '^;' |grep -v '^$'
systemctl start php74-php-fpm
systemctl enable php74-php-fpm
systemctl status php74-php-fpm
5、安装nginx对接php
yum install nginx -y
cat > /etc/nginx/conf.d/web.conf << “EOF”
server {
listen 8888;
location / {
root /usr/share/nginx/html;
index index.php index.html index.htm a.txt;
}
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
include fastcgi_params;
}
}
EOF
systemctl restart nginx
6、在两台web上部署应用程序
wget https://files.phpmyadmin.net/phpMyAdmin/5.2.1/phpMyAdmin-5.2.1-all-languages.zip
unzip phpMyAdmin-5.2.1-all-languages.zip
mv phpMyAdmin-5.2.1-all-languages /usr/share/nginx/html/php
cd /usr/share/nginx/html/php
cp config.sample.inc.php config.inc.php
vi config.inc.php # 修改连接数据库的代码
$cfg['Servers'][$i]['host'] = '192.168.71.16';
chown -R nginx.nginx /usr/share/nginx/html/php
7、数据库中创建登录账号密码
create user 'root'@'192.168.71.%' identified by 'Egon@666';
grant all on *.* to 'root'@'192.168.71.%';
flush privileges;
8、用nginx做七层负载均衡
yum install nginx -y
[root@web03 ~]# cat /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
upstream webserver {
server 192.168.71.112:8888 max_fails=3 fail_timeout=5s;
server 192.168.71.113:8888 max_fails=3 fail_timeout=5s;
}
server {
listen 9090;
location / {
proxy_pass http://webserver;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_403 http_404;
}
}
}
9、会话共享方案
不做会话共享的方案：
ip_hash算法（违背了负载均衡的初衷）
会话共享的方案：
(1)nfs共享存储
# 1、nfs服务器
yum -y install nfs* -y
[root@lb ~]# cat /etc/exports
/data 192.168.71.0/24(rw,sync,no_root_squash)
[root@lb ~]# mkdir /data
[root@lb ~]# exportfs -a ;systemctl restart nfs
# 2、所有web
yum install nfs* -y
# 3、web01挂载
[root@web01 ~]# mount -t nfs 192.168.71.11:/data/ /var/opt/remi/php74/lib/php/session
[root@web01 ~]# chmod o+rwx /var/opt/remi/php74/lib/php/session
[root@web02 ~]# mount -t nfs 192.168.71.11:/data/ /var/opt/remi/php74/lib/php/session
[root@web02 ~]# chmod o+rwx /var/opt/remi/php74/lib/php/session
(2)redis
yum install -y redis
vim /etc/redis.conf
找到配置项 bind 127.0.0.1，然后将 127.0.0.1 修改为 0.0.0.0 或者你想让其绑定的具体IP，以允许远程访问。
找到protected-mode yes，并将其更改为 protected-mode no 这样可以允许非本地客户端连接。
增加设置密码：requirepass 123
systemctl restart redis # 端口默认6379—-重启redis,并用客户端命令测试
# 我们用redis-cli客户端命令测试，redis-cli并部署php程序要使用的客户端，php程序中有自己的客户端模块，需要在程序运行环境为php语言准备好相应的模块
[root@lb ~]# redis-cli -h 192.168.71.11 -p 6379 -a 123
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.71.11:6379> keys *
(empty array)
192.168.71.11:6379> set name egon
OK
192.168.71.11:6379> get name
“egon”
192.168.71.11:6379> keys *
1) “name”
192.168.71.11:6379>
#修改web上的php配置文件
[root@localhost session]# cat /etc/opt/remi/php74/php-fpm.d/www.conf
…………..
php_value[session.save_handler] = redis
php_value[session.save_path] = “tcp://192.168.71.11:6379?auth=123”
;php_value[session.save_path] = “tcp://192.168.2.11:6379” # 如果redis不带密码，则使用这种配置
;php_value[session.save_handler] = files
;php_value[session.save_path] = /var/opt/remi/php74/lib/php/session
…………..
#重启
systemctl restart php74-php-fpm
#在web服务器上安装php程序依赖的连接redis的模块
systemctl list-unit-files|grep php
wget http://pecl.php.net/get/redis-5.3.5.tgz
tar -zxvf redis-5.3.5.tgz
cd redis-5.3.5
# 1、必须下面命令
yum -y install php74-php-devel
/opt/remi/php74/root/usr/bin/phpize
—-查找php-config的位置
#find / -name php-config
/opt/remi/php74/root/usr/bin/php-config
—-运行configure
./configure –with-php-config=/opt/remi/php74/root/usr/bin/php-config –enable-redis
—-编译
make
—-编译安装：提示安装后的目标目录
[root@web01 ~/redis-5.3.5]# make install
Installing shared extensions: /opt/remi/php74/root/usr/lib64/php/modules/
[root@web01 ~/redis-5.3.5]# ls /opt/remi/php74/root/usr/lib64/php/modules/ |grep redis
redis.so
—增加配置加载redis.so
[root@web01 ~/redis-5.3.5]# cat /etc/opt/remi/php74/php.d/redis.ini
;redis
extension=redis.so
—重启
systemctl restart php74-php-fpm
—查看
[root@web01 ~/redis-5.3.5]# php74 -m |grep redis
redis
进行测试 http://192.168.71.12:9090/php
三、ssl介绍
ssl是什么？
ssl是一种加密协议，可以防窃听、篡改、伪装/冒充
为何要用ssl？
1、为了弥补http协议明文传输不安全的特点
http+ssl====》https
默认端口： http—-80 https—-443
2、从通信的维度看
通信安全的三大问题：
如何防止窃听
如何防止篡改
如何防止伪装/冒充
如何用ssl？ssl协议是如何做到防窃听、篡改、伪装/冒充
1、如何防止窃听：密文传输（客户端拿到真正的公钥—-加密的根基）
非对称加密：
公钥—》客户端
私钥—》服务端
公钥加密私钥解密，私钥加密公钥解密
但其实ssl中还会用到对称加密
2、如何防止篡改/丢失
把包的内容做hash校验得到的hash值称之为摘要->digest
服务端用自己的私钥对digest进行加密—》得到东西叫数字签名signature
客户端收到包之后先用公钥解开得到digest—》重新hash，验证是否被篡改
3、如何防止伪装/冒充
客户端去向ca中心验证自己得到的公钥是否正确
ca中心用自己的私钥把服务端提交过来服务端公钥进行加密—》数字证书
数字证书就是加了密的服务端公钥
——SSL通信的前置工作，确认了服务端的身份（非对称加密）
四、ssl详解
储备知识：
1、数字证书、数字签名、ca中心
2、
非对称加密
两个密码（公钥、私钥）：公钥加密用私钥解密，私钥加密用公钥解密
优点：
公私分明，公钥任何人都可以获取，而私钥只有服务端自己手里有
安全性更高一些，只要私钥不泄露，就没法解开包
缺点：
非对称加密的速度慢，不适合大规模数据加解密
对称加密
只有一个秘钥，加解密用的都是同一套秘钥
优点：加解密效率高
缺点：秘钥的泄露几率高，一旦某一方泄露秘钥，则加密信息就无法得到安全保障
问题ssl协议用对称还是非对称？
ssl协议通信过程中即用了非对称加密，又用了对称加密
### 加密算法—-不能根据结果反推出原始值（例如hash）
加密算法可以被暴力破解—-通过截取加密后的信息，不断地使用加密算法对预测的明文进行加密，得到的结果对截取的信息进行对比从而得出结论
ssl协议的通信流程—单向认证（******）
客户端验证服务端的真假，防止有人冒充服务端
1、2、3均为ssl通信的前置工作（确认服务端身份）
1 ~ 8为非对称加密
ssl协议的通信流程—双向认证（******）
客户端验证服务端的真假，防止有人冒充服务端
服务端也要认证客户端的真假，防止有人冒充客户端
1 ~ 10 为非对称加密
![图片[1] - http协议、全站https - 宋马](https://pic.songma.com/blogimg/20250430/819759483b264f9a8d7ee3620cfa73f4.png)
总结：
无论单向还是双向，前面节点是非对称，后续通信的环节都是对称
五、tls协议
tls协议就是一个升级版的ssl
由于 SSL 这一术语更为常用，所以我们通常仍将我们的安全证书称作 SSL
六、网站的冒充/劫持
站点的安全问题—》劫持 ——-》属于冒充身份的一种方式（配置ssl加密解决此问题）
# 配置反向代理实现
正常站点
[root@web01 ~]# vim /etc/nginx/conf.d/www.egon.com.conf
server {
listen 80;
server_name www.egon.com 192.168.71.16;
location / {
root /code;
index index.html;
}
}
[root@web01 ~]# systemctl restart nginx
劫持的站点
[root@lb01 ~]# vim /etc/nginx/conf.d/www.egon.com.conf
server {
listen 80;
server_name www.egon.com 192.168.71.15;
location / {
proxy_pass http://192.168.71.16:80; # 指向被劫持/冒充的站点
}
}
[root@lb01 ~]# systemctl restart nginx
篡改hosts
192.168.71.15 www.egon.com
进行网站的篡改
七、证书的类型介绍
![图片[2] - http协议、全站https - 宋马](https://pic.songma.com/blogimg/20250430/be276307aad2494fa32c7046e3fb847e.png)
八、配置https
单节点配置
自己给自己认证（既当CA中心，又当服务端）
生成私钥—-CA的私钥也是服务端的私钥
# 使用openssl命令制作给服务端用的私钥，2048位的密钥长度在目前的标准下是安全的。如果你需要更高的安全级别，可以考虑使用3072或4096位的长度。
[root@web01 ssl_key]# openssl genrsa -out server.key 2048
[root@web01 ssl_key]# ll
total 4
-rw-r–r–. 1 root root 1739 Dec 9 11:27 server.key
创建证书请求
# 接下来,使用私钥创建一个新的证书签名请求（CSR）。这个CSR内包含了公钥以及其他一些附加信息。
openssl req -new -key server.key -out server.csr
对请求进行签名生成证书
openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650
# 这样就生成了有效期为：10年的证书文件，对于自己内网服务使用足够。
配置nginx使用证书并设置http自动跳转https
[root@rockylinux ssl_key]# cat /etc/nginx/conf.d/www.egonlin.com.conf
server {
listen 443 ssl;
server_name www.egon.com 192.168.71.16;
ssl_certificate /etc/nginx/ssl_key/server.crt;
ssl_certificate_key /etc/nginx/ssl_key/server.key;
location / {
root /code;
index index.html;
}
}
server {
listen 80;
server_name www.egon.com 192.168.71.16;
rewrite (.*) https://$server_name$1;
}
集群中配置
web配置
[root@web01 ~]# cat /etc/nginx/conf.d/web01.conf
server {
listen 8080;
server_name linux.web01.com;
location / {
root /web01;
index index.html;
}
}
[root@web01 ~]# systemctl restart nginx
[root@web01 ~]# mkdir /web01 && echo 11111 > /web01/index.html
负载均衡
制作密钥/证书
mkdir /etc/nginx/ssl_key/
cd /etc/nginx/ssl_key/
openssl genrsa -out server.key 2048
openssl req -new -x509 -days 3650 -key server.key -out server.crt -subj “/C=CH/ST=mykey/L=mykey/O=mykey/OU=mykey/CN=domain1/CN=www.egon.com/CN=domain3”
配置
[root@localhost ~]# cat /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
upstream webserver {
server 192.168.71.14:8080;
server 192.168.71.15:8080;
}
server {
listen 443 ssl;
server_name www.egon.com 192.168.71.13;
ssl_certificate /etc/nginx/ssl_key/server.crt;
ssl_certificate_key /etc/nginx/ssl_key/server.key;
location / {
proxy_pass http://webserver; # 这里是内网通信，所以简单用http协议就行，如果你用https协议那后端web是无法解析加密数据的，需要你在负载均衡与后端的web之间再做证书，就非常麻烦了，意义不是特别大，毕竟都是内网
}
}
server {
listen 80;
server_name www.egon.com 192.168.71.13;
rewrite (.*) https://$server_name$1;
}
}
配置本地解析
192.168.71.13 www.egon.com
补充
服务器为纯静态依照以上配置没有影响
一般情况下服务器存在业务逻辑，涉及动态,负载均衡服务器会将https请求转换为http,需要告知服务器原始的请求究竟是http还是https转换来的http
在web服务器的nginx配置fastcgi_param HTTPS on
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
# 开启https模式
fastcgi_param HTTPS on;
include fastcgi_params;
}
含义：
通过设置 fastcgi_param HTTPS on;，就可以让后端的应用知道这个http请求实际上原始是一个HTTPS请求。
### SSL为传输过程的加密协议，cookie session jwt属于对数据本身的加密
暂无评论内容