关于前端:Nginx学习

配置示例

#user  nobody;worker_processes  1; # 工作过程数量error_log  /etc/nginx/logs/nginx-error.log;error_log  /etc/nginx/logs/nginx-error.log  notice;error_log  /etc/nginx/logs/nginx-error.log  info;#pid        logs/nginx.pid;events {  worker_connections  1024; # 一个过程最多能够解决并发申请下限，number值不能大于操作系统反对关上的最大文件句柄数量  accept_mutex on | off; # 解决“惊群”问题，开启的时候将会对多个Nginx过程接管连贯进行序列化，避免多个过程对连贯的争抢  multi_accept on | off; # 默认为敞开（off）状态，即每个worker process一次只能接管一个新达到的网络连接  use method; # 抉择解决网络音讯的事件驱动模型：select、poll、kqueue、epoll、rtsig、/dev/poll以及eventport}http {  include       mime.types;  index    index.html index.htm index.php;  default_type  application/octet-stream;  server_names_hash_bucket_size 512;  server_tokens off; # 暗藏版本信息  client_max_body_size  400M;  log_format   main '$remote_addr - $remote_user [$time_local]  $status '    '"$request" $body_bytes_sent "$http_referer" '    '"$http_user_agent" "$http_x_forwarded_for"';  access_log  /etc/nginx/logs/nginx-access.log  main;  sendfile        on;  keepalive_timeout  300; # 服务器端对连贯的放弃工夫。默认值为75s。  keepalive_requests number; # Nginx服务器端和用户端建设会话连贯后，用户端通过此连贯发送申请。指令keepalive_requests用于限度用户通过某一连贯向Nginx服务器发送申请的次数  proxy_max_temp_file_size 500M;  gzip on;  gzip_vary on;  gzip_min_length 10240;  gzip_comp_level 4;  gzip_proxied expired no-cache no-store private auth;  gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml application/javascript application/json;  gzip_disable "MSIE [1-6]\.";  server {            server_name  www.ronux.com;        listen       80;        access_log   logs/access.log  main;        root         /usr/share/nginx/html/www/;        index        /index.html;        location ~* ^/community/.+\.(html)$ {            # 针对爬虫的配置，不要去掉            if ( $http_user_agent ~* "(googlebot|bingbot|yandex|baiduspider|twitterbot|facebookexternalhit|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator)") {                rewrite ^/(.*)$ /render/https://$host$request_uri break;                proxy_pass http://ronux-rendertron:3000;            }            index  index.html;            try_files $uri $uri/ /index.html?s=$uri&$args;        }        location / {            index  index.html;            # 配置页面不缓存html和htm结尾的文件            if ($request_filename ~ .*\.(htm|html)$) {              add_header Cache-Control no-store;            }            error_page  404  /404.html;         }    }  include /etc/nginx/conf.d/*.nginx.conf;}

location 匹配规定

location [ = | ～ | ～＊ | ^～ ] uri { ... }
uri分为：规范uri和正则uri

匹配规定：

规范uri与申请字符串相匹配的，如果多个取匹配度最多的1个，这里并没有完结
接着用location块中的正则uri与申请字符串匹配，第一次匹配胜利即完结搜寻
如果正则uri匹配失败，回到1里选中的匹配度最高的规范uri完结搜寻

匹配可选项：
● “=”，用于规范uri前，要求申请字符串与uri严格匹配。如果曾经匹配胜利，就进行持续向下搜寻并立刻解决此申请。
● “～”，用于示意uri蕴含正则表达式，并且辨别大小写。
● “～*”，用于示意uri蕴含正则表达式，并且不辨别大小写。
● “^～”，用于规范uri前，要求Nginx服务器找到标识uri和申请字符串匹配度最高的location后，立刻应用此location解决申请，而不再应用location块中的正则uri和申请字符串做匹配。
如果uri蕴含正则表达式，就必须要应用“～”或者“～*”标识。

location root & alias区别：
root：服务器端设置根目录，用于寻找申请资源

匹配/usr/share/nginx/html/data/下index.html

location /data/ {

root /usr/share/nginx/html;

}

alias：应用alias指令扭转location接管到的URI的申请门路

/data/index.html申请匹配/usr/share/nginx/html/other/index.html

location ～ ^/data/(.+.(htm|htm))$ {

alias /usr/share/nginx/html/other/$1;

}

罕用变量
// 以 https://www.ronux.com/communi... 申请为例

$request // 申请行信息 'GET /community/homePage/?from=mainEntrance HTTP/1.1'
$uri // 这里做了默认文件补全 '/community/homePage/index.html'
$request_filename // '/Users/xxx/homepage/dist/community/homePage/index.html'
$request_method // 'GET'

网络服务器常见几种申请解决机制

多过程：
服务器每当接管到一个客户端时，就由服务器主过程生成一个子过程进去和该客户端建设连贯进行交互，直到连贯断开，该子过程就完结了。
代表：apache
多线程：
服务器每当接管到一个客户端时，会由服务器主过程派生一个线程进去和该客户端进行交互。操作系统创立线程的开销远小于创立过程。
代表：tomcat，IIS
异步IO：
次要指异步非阻塞。即发送方向接管方发送申请后，不必期待响应，能够持续其余工作；接管方解决申请时进行的IO操作如果不能马上失去后果，也不期待，而是马上返回去做其余事件。当IO操作实现当前，将实现状态和后果告诉接管方，接管方再响应发送方。
代表：nginx，node

Nginx的事件处理机制
Nginx服务器的工作过程调用IO后，就去进行其余工作了；当IO调用返回后，会告诉工作过程。这里有一个问题，IO调用是如何把本人的状态告诉给工作过程的呢？
个别解决这个问题的计划有两种。
一是，让工作过程在进行其余工作的过程中距离一段时间就去检查一下IO的运行状态，如果实现，就去响应客户端，如果未实现，就持续正在进行的工作；
二是， IO调用在实现后能被动告诉工作过程。对于前者，尽管工作过程在IO调用过程中没有期待，但一直的查看依然在工夫和资源上导致了不小的开销，最现实的解决方案是第二种。
具体来说，select/poll/epoll/kqueue等这样的零碎调用就是用来反对第二种解决方案的。这些零碎调用，也常被称为事件驱动模型，它们提供了一种机制，让过程能够同时解决多个并发申请，不必关怀IO调用的具体状态。IO调用齐全由事件驱动模型来治理，事件筹备好之后就告诉工作过程事件曾经就绪。

select / poll: 过程被动轮询
epoll：内核轮询，并告诉过程。Linux 2.5.44中引入的，在Linux 2.6及以上的版本都能够应用它。epoll库在Linux平台上是高效的。它反对一个过程关上大数目的事件描述符，下限是零碎能够关上文件的最大数目；同时，epoll库的IO效率不随描述符数目减少而线性降落，因为它只会对内核上报的“沉闷”的描述符进行操作。
rtsig: Real-time signal。信号队列长度限度，溢出后降级应用poll。直到rtsig信号队列全副清空。rtsig模型在Linux 2.2.19及以上的版本中能够应用。

Nginx过程架构
主过程
工作过程
过程之间如何通信？
主过程 => 工作过程：单向管道
工作过程 <==> 工作过程：管道
run-loops事件处理循环模型

地址重写与地址转发

地址重写：
其实就是重定向
实际上是为了实现地址标准化。那么，什么是地址标准化呢？咱们来举一个例子。比方在拜访Google首页的时候，咱们在地址栏中能够输出www.google.com，也能够输出google.cn，它们都可能精确地指向Google首页，从客户端来看，Google首页同时对应了两个地址，实际上，Google服务器是在不同的地址中抉择了确定的一个，即www.google.com，进而返回服务器响应的。这个过程就是地址标准化的过程。google.cn这个地址在服务器中被扭转为www.google.com的过程就是地址重定向的过程。

地址转发：
“转发”的概念最后和网页的拜访并没有太大关系，它是指在网络数据传输过程中数据分组达到路由器或者桥接器后该设施通过查看分组地址并将数据转到相邻局域网上的过程。起初该概念被用在网页拜访中，呈现了“地址转发”的说法。“地址转发”，是指将一个域名指到另一个已有站点的过程。

正向代理与反向代理
正向代理服务器与反向代理服务器的概念很简略，归纳起来就是：
正向代理服务器用来让局域网客户机接入外网以拜访外网资源
反向代理服务器用来让外网的客户端接入局域网中的站点以拜访站点中的资源