代理,负载均衡
代理
buffer 写缓存
cache 读缓存
反向代理
访问代理服务器时会返回webserver的内容
在app.conf中
server {
listen 192.168.122.101:80;
server_name www.app1.com;
root /usr/share/nginx/app1;
access_log /var/log/www.app1.com.log main;
error_log /var/log/www.app1.com.error.log;
set_real_ip_from 192.168.122.105; #谁代理了我
location / {
index index.html;
}
}
在proxy.conf中
server {
listen 192.168.122.105:80;
server_name proxy3;
root /usr/share/nginx/proxy3;
access_log /var/log/proxy3.log main;
error_log /var/log/proxy3.error.log;
location / {
proxy_pass http://192.168.122.101:80; #我代理了谁
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_connect_timeout 30;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 4 128k;
proxy_busy_buffers_size 256k;
proxy_max_temp_file_size 256k;
}
}
在app.conf的日志中
10.0.122.109 - - [09/Oct/2019:12:09:18 +0800] "GET / HTTP/1.0" 304 0 "-" "Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36" "10.0.122.188, 10.0.122.109"
第一个ip地址为客户端的ip，后面的ip为经过的ip，因此，后边的ip是不会出现webserver紧临的代理服务器的ip
双层代理：另一个服务器代理了代理服务器，配置与服务器代理相同
负载均衡
基于7层模型的负载均衡(http)
#在proxy.conf中（反向代理的主机同时负责负载均衡）
upstream myapp{
server 192.168.122.101 weight=1; (加权轮询，权重越大,
server 192.168.122.102 weight=1; 被分配的请求越多)
server 192.168.122.103 weight=2;
server 192.168.122.104 backup; (热备,当其他的机器宕掉才会使用)
}
server {
listen 192.168.122.105:80;
server_name proxy1;
root /usr/share/nginx/proxy1;
access_log /var/log/proxy1.log main;
error_log /var/log/proxy1.error.log;
location / {
proxy_pass http://myapp;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_connect_timeout 30;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 4 128k;
proxy_busy_buffers_size 256k;
proxy_max_temp_file_size 256k;
}
}
webserver是正常配置
upstream 支持4种负载均衡调度算法:
A、轮询(默认):每个请求按时间顺序逐一分配到不同的后端服务器; 加权论询
B、ip_hash:每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。
C、url_hash 按访问url的hash结果来分配请求，使每个url 定向到同一个后端服务器。后台服务器为缓存的时候效率。
D、fair:这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持 fair的，如果需要使用这种调度算法，必须下载Nginx的 upstream_fair模块。
nginx负载均衡配置状态参数：
down，表示当前的server暂时不参与负载均衡。
backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
max_fails，允许请求失败的次数，默认为1。当超过最大次数时，返回 proxy_next_upstream 模块定义的错误。
fail_timeout，在经历了max_fails次失败后，暂停服务的时间。max_fails 可以和 fail_timeout一起使用。
ip_hash 简单易用,但有如下问题:
当后端服务器宕机后,session会丢失;
来自同一局域网的客户端
会被转发到同一个后端服务器,可能导致负载失衡;
不适用于CDN网络,不适用于前段还有代理的情况(这样来源ip只会是外层代理服务器的ip因此会无法负载)。
基于四层的负载均衡(tcp)
在nginx.conf中，与http平级
stream {
upstream mytest1 {
server 192.168.152.100:80;
server 192.168.152.101:80;
}
server {
listen 192.168.152.192:80;
proxy_connect_timeout 10s;
proxy_timeout 30s;
proxy_pass mytest1;
}
upstream mytest2 {
server 192.168.152.102:80;
server 192.168.152.103:80;
}
server {
listen 192.168.152.192:8080;
proxy_connect_timeout 10s;
proxy_timeout 30s;
proxy_pass mytest2;
}
}
nginx 会话保持：
1、ip_hash
使用源地址哈希算法，将同一客户端的请求总是发往同一个后端服务器，除非该服务器不可用。
2、sticky_cookie_insert
使用 sticky_cookie_insert 启用会话亲缘关系，这会导致来自同一客户端的请求被传递到一组服务器的同一台服务器。
与ip_hash不同之处在于，它不是基于IP来判断客户端的，而是基于cookie 来判断。
因此可以避免上述 ip_hash 中来自同一局域网的客户端和前端代理导致负载失衡的情况
3、jvm_route 方式
jvm_route是通过 session_cookie 这种方式来实现 session 粘性。将特定会话附属到特定 tomcat 上，
从而解决 session 不同步问题，但是无法解决宕机后会话转移问题。如果在 cookie 和 url 中并没有 session，
则这只是个简单的 round robin （轮巡） 负载均衡。
jvm_route的原理
一开始请求过来，没有带 session 的信息，jvm_route 就根据 round robin （轮巡）的方法，发到一台 Tomcat 上面
Tomcat 添加上 session 信息，并返回给客户
用户再次请求，jvm_route 看到 session 中有后端服务器的名称，他就把请求转到对应的服务器上
对于某个特定用户，当一直为他服务的 Tomcat 宕机后，默认情况下它会重试max_fails 的次数，
如果还是失败，就重新启用 round robin 的方式，而这种情况下就会导致用户的 session 丢失。
4、使用后端服务器自身通过相关机制保持 session 同步，如：使用数据库 redis、memcached 等做 session 复制
http常见状态码
1xx（临时响应）
100 （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101 （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。
2xx（成功）
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求
3xx（重定向）
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
4xx（请求错误）
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
5xx（服务器错误）
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本
计算机常见端口
HTTP：80：www服务
DHCP：服务器端的端口号是67，客户机端的端口号是68
POP3：POP3仅仅是接收协议，POP3客户端使用SMTP向服务器发送邮件。端口号是110。
SMTP：端口号是25。
Telnet：端口号是23。“电信网络协议（Telecommunication Network Protocol）”
FTP：20端口用于数据传输，21端口用于控制信令的传输，FTP采用的是TCP连接。
TFTP：端口号69，使用的是UDP的连接。
DNS:53，名称服务
SNMP（简单网络管理协议）:161端口
HTTPS：端口号是443
远程桌面 ：3389端口
