关于前端: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

匹配规定：

1. 规范 uri 与申请字符串相匹配的，如果多个取匹配度最多的 1 个，这里并没有完结
2. 接着用 location 块中的正则 uri 与申请字符串匹配，第一次匹配胜利即完结搜寻
3. 如果正则 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 的过程就是地址重定向的过程。

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

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