高性能的HTTP服务Nginx还能做什么?

Nginx能做什么?
1、反向代理
2、负载均衡
3、HTTP服务器(包含动静分离)
4、正向代理

以上是Nginx在不依赖第三方模块能处理的事情,下面详细解说一下:

1.反向代理
反向代理应该是Nginx做的最多的一件事了,什么是反向代理呢,以下是百度百科的说法:反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问,所以需要一台代理服务器,而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境,当然也可能是同一台服务器,端口不同而已。

下面贴上一段简单的实现反向代理的代码

server {
        listen       80;                                                         
        server_name  localhost;                                               
        client_max_body_size 1024M;

        location / {
            proxy_pass http://localhost:8080;
            proxy_set_header Host $host:$server_port;
        }
    }

保存配置文件后启动Nginx,这样当我们访问localhost的时候,就相当于访问localhost:8080了;

2.负载均衡
负载均衡也是Nginx常用的一个功能,负载均衡其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。简单而言就是当有2台或以上服务器时,根据规则随机的将请求分发到指定的服务器上处理,负载均衡配置一般都需要同时配置反向代理,通过反向代理跳转到负载均衡。而Nginx目前支持自带3种负载均衡策略,还有2种常用的第三方策略。

  • 2.1 RR(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除,简单配置如下:

upstream test {
    server localhost:8080;
    server localhost:8081;
}
server {
    listen       81;                                                         
    server_name  localhost;                                               
    client_max_body_size 1024M;

    location / {
        proxy_pass http://test;
        proxy_set_header Host $host:$server_port;
    }
}

*注:负载均衡的核心代码:

upstream test {
    server localhost:8080;
    server localhost:8081;
}

这里我配置了2台服务器,当然实际上是一台,只是端口不一样而已,而8081的服务器是不存在的,也就是说访问不到,但是我们访问http://localhost 的时候,也不会有问题,会默认跳转到http://localhost:8080 具体是因为Nginx会自动判断服务器的状态,如果服务器处于不能访问(服务器挂了),就不会跳转到这台服务器,所以也避免了一台服务器挂了影响使用的情况,由于Nginx默认是RR策略,所以我们不需要其他更多的设置。

  • 2.2、权重

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况,例如:

upstream test {
    server localhost:8080 weight=9;
    server localhost:8081 weight=1;
}

解释:那么如果有10次请求进来,一般只会有1次会访问到8081,而有9次会访问到8080

  • 2.3、ip_hash

上面的两种方式都有一个问题,就是下一个请求来的时候请求可能分发到另外一个服务器,当我们的程序不是无状态的时候(采用了session保存数据),这时候就有一个很大的很问题,比如把登录信息保存到了session中,那么跳转到另外一台服务器的时候就需要重新登录了,所以很多时候我们需要一个客户只访问一个服务器,那么就需要用ip_hash了,ip_hash的每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

upstream test {
    ip_hash;
    server localhost:8080;
    server localhost:8081;
}
  • 2.4、fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream backend { 
    fair; 
    server localhost:8080;
    server localhost:8081;
}
  • 2.5、url_hash(第三方)
    按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。 在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法。
upstream backend { 
    hash $request_uri; 
    hash_method crc32; 
    server localhost:8080;
    server localhost:8081;
}

以上5种负载均衡各自适用不同情况下使用,所以可以根据实际情况选择使用哪种策略模式,不过fair和url_hash需要安装第三方模块才能使用。

3.HTTP服务器
Nginx本身也是一个静态资源的服务器,当只有静态资源的时候,就可以使用Nginx来做服务器,同时现在也很流行动静分离,就可以通过Nginx来实现,首先看看Nginx做静态资源服务器。

server {
    listen       80;                                                         
    server_name  localhost;                                               
    client_max_body_size 1024M;


    location / {
           root   e:www;
           index  index.html;
       }
}

这样如果访问http://localhost 就会默认访问到E盘www目录下面的index.html,如果一个网站只是静态页面的话,那么就可以通过这种方式来实现部署。

  • 3.1.动静分离

动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路。

    upstream test{  
       server localhost:8080;  
       server localhost:8081;  
    }   

    server {  
        listen       80;  
        server_name  localhost;  

        location / {  
            root   e:wwwroot;  
            index  index.html;  
        }  

        # 所有静态请求都由nginx处理,存放目录为html  
        location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ {  
            root    e:www;  
        }  

        # 所有动态请求都转发给tomcat处理  
        location ~ .(jsp|do)$ {  
            proxy_pass  http://test;  
        }  

        error_page   500 502 503 504  /50x.html;  
        location = /50x.html {  
            root   e:www;  
        }  
    }

 

这样就可以将HTML以及图片和css以及js放到www目录下,而tomcat只负责处理jsp和请求。例如:当我们后缀为gif的时候,Nginx默认会从www获取到当前请求的动态图文件返回,当然这里的静态文件跟Nginx是同一台服务器,我们也可以在另外一台服务器,然后通过反向代理和负载均衡配置过去就好了,只要搞清楚了最基本的流程,很多配置就很简单了,另外localtion后面其实是一个正则表达式,所以非常灵活

5.正向代理
正向代理,意思是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。当你需要把你的服务器作为代理服务器的时候,可以用Nginx来实现正向代理,但是目前Nginx有一个问题,那么就是不支持HTTPS,虽然我百度到过配置HTTPS的正向代理,但是到最后发现还是代理不了,当然可能是我配置的不对,所以也希望有知道正确方法的同志们留言说明一下。

resolver 114.114.114.114 8.8.8.8;
server {

    resolver_timeout 5s;

    listen 81;

    access_log  e:wwwrootproxy.access.log;
    error_log   e:wwwrootproxy.error.log;

    location / {
        proxy_pass http://$host$request_uri;
    }
}

resolver是配置正向代理的DNS服务器,listen 是正向代理的端口,配置好了就可以在ie上面或者其他代理插件上面使用服务器ip+端口号进行代理了。

6.最后

Nginx是支持热启动的,也就是说当我们修改配置文件后,不用关闭Nginx,就可以实现让配置生效,当然我一般也是使用restart命令重启;从读配置命令:

nginx -s reload

开源的许可证GPL、LGPL、BSD、Apache 2.0的通俗解释

软件开发者要开源软件,不单单是开放源代码就可以了,选择一种许可证很重要,一个许可证之于软件就相当于价值观之于普通人,代表了这个软件的基本品性。一个错误的许可证选择可能会直接导致整个项目的失败。

各种开源的许可证主要的限制还是在redistribution(发布),所以个人/商业公司开发的软件包含了GPL的代码,只要你不发布,是可以任意使用的。

下面是几个开源许可证的区别:

GPL
GPL软件的使用者有权力得到软件的代码,只要使用了GPL,在发布(redistribution)时,整个项目也必须是GPL的,即主程序和静态链接的库(linux的.a和Windows的.lib)必须是GPL的,动态链接库(Linux的.so,Windows的.dll)必须是GPL兼容的。所谓GPL兼容,也就是GPL软件中可以使用的库,这些许可证必须比GPL弱(如LGPL,BSD),而不能是某个商业许可证。正因如此,GPL是带有很强的传染性,只要你的软件使用了GPL的代码,那么就请以GPL开放源代码吧,并且你的项目中也不能有任何和GPL不兼容的库。

LGPL
GPL 带有很强的传染性,那么如果一个库使用GPL发布,那么使用这个库的所有软件也必须使用GPL发布,这对不想开放源代码的商业软件来讲是致命的打击——你可以不使用其他的库,但最基本的libc是无论如何绕不开的,如果libc是以GPL发布,就相当于所有软件必须以GPL发布了。所以,LGPL(Lesser GPL)诞生了。

LGPL定义为,在以LGPL发布的库的基础上开发新的库的时候,新的库必须以LGPL发布,但是如果仅仅是动态链接,那么则不受任何限制。这样商业软件就可以随意的使用LGPL的库了。因此,LGPL也具有传染性,但限制在其基础上开发的库上,而并不限制使用它的程序本身——它的传染性远小于GPL。

BSD、Apache 2.0
相对GPL/LGPL的开放源代码,BSD,Apache 2.0就宽松许多——商业软件可以任意的使用BSD,Apache 2.0发布的软件代码,而不需要开放源代码,只需要提及代码的原出处就可以了。BSD和Apache 2.0提及的方式稍有不同,具体可以参考协议的详细内容。它们是GPL兼容的

 

看看下面选择开源许可证的案例:

andorid 使用宽松的Apache 2.0发布,因为Google作为一个商业公司,并不想失去商业软件的支持,它希望团结一切可以团结的力量加入的Android的开发中来,壮大自己的阵营,使用Apache 2.0就无可厚非了。而Google本身,并没有丧失对Android的控制权,不会担心另外一个公司拿走了Android的代码开发出一个闭源 Android的对手。因为,只要Android不断的出新版,社区不停的跟进,并且不停的修改API,其他基于Android开发的公司不得不把自己的Patch提回到主干上,否则,必然将耗费大量人力物力在维护自己的Patch上(钱这方面你斗得过Google?),得不偿失。而且,闭源之后,与整个社区为敌,作为一个定位软件平台的项目,会流失大量应用软件开发者,以小博大,任何一个商业公司都不会干这种胜算不高的蠢事。
再看以GPL发布的Linux为什么比以BSD发布的FreeBSD成功。其实正是因为GPL的传染性。当一个开发人员在Linux基础上开发一个新功能之后, 不得不以GPL开放源代码,贡献回Linux,这样Linux本身才能越来也越壮大而且留住了相当的开发人员,形成了一个 优秀软件->很多使用者和贡献者->贡献->更优秀的软件->更多的使用者和贡献者… 的良性循环。

 

git使用码云生成并部署SSH key

1.如何生成ssh公钥

你可以按如下命令来生成 sshkey:

ssh-keygen -t rsa -C "xxxxx@xxxxx.com"  

# Generating public/private rsa key pair...
# 三次回车即可生成 ssh key

查看你的 public key,并把他添加到码云(Gitee.com) SSH key添加地址

cat ~/.ssh/id_rsa.pub
# ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6eNtGpNGwstc....

添加后,在终端(Terminal)中输入

ssh -T git@git.oschina.net

若返回

Welcome to Git@OSC, yourname!

则证明添加成功。


2.怎么添加用户 ssh key?

  1. 点击右上角的1502329104-5071-14154017-ogkd标志,进入个人中心,然后点击左侧的 ssh 公钥后在下图位置填写你的 ssh 公钥
  2. 点击确定,然后验证密码(即你的注册账号密码)就完成了ssh 公钥添加。

1502329104-1149-18115822-miTO

3.项目的 ssh key 和用户的 ssh key 两处地方有什么不同?

项目的 sshkey 只针对项目,且我们仅对项目提供了部署公钥,即项目下的公钥仅能拉取项目,这通常用于生产服务器拉取仓库的代码。 而用户的 key 则是针对用户的,用户添加了 key 就对用户名下的项目和用户参加了的项目具有权限,一般而言,用户的key具有推送和拉取的权限,而项目的 key 则只具有拉取权限。

phpstorm使用php7.0开发开启xdebug调试功能

1.去下载xdebug.dll,下载的时候需要注意一下版本的问题,可以使用phpinfo();进行查看php的版本.

下载地址:https://xdebug.org/download.php

接着需要修改php.ini文件,我们开发估计都是在Windows底下吧,反正我的php.ini是没有xdebug的配置文件的,需要自己加上去,

[XDebug]
xdebug.profiler_append = 0
xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = 0
xdebug.profiler_output_dir =”D:\phpStudy\tmp\xdebug”
xdebug.trace_output_dir =”D:\phpStudy\tmp\xdebug”
xdebug.profiler_output_name = “cache.out.%t-%s”
xdebug.remote_enable = 1
xdebug.remote_handler = “dbgp”
xdebug.remote_host = “127.0.0.1”
zend_extension=”D:\phpStudy\php70n\ext\php_xdebug-2.5.4-7.0-vc14-nts.dll”

 

接着….,其实不用配置phpstorm了,直接右键debug,就会有效果了.

http session解释

Web服务器跟踪客户状态通常有四种方法:

1,建立含有跟踪数据的隐藏字段  type=hidden

2,重写包含额外参数的URL

3,使用持续的Cookie

4,使用Servlet API中的Session(会话)机制

Session概念:

Session用于跟踪客户的状态,Session是指在一段时间内,单个客户与WEB服务器一连串相关的交互过程。在一个Session中,客户可能多次请求访问同一个网页,也有可能请求访问各种不同的服务器资源。

Session运行机制:

当一个Session开始时,Servlet容器将创建一个HttpSession对象,在HttpSession对象中可以存放客户的状态信息(例如购物车)。

Servlet容器为HttpSession分配一个唯一标志符,称为SessionID。Servlet容器将SessionID作为Cookie保存在客户的浏览器中。

每次客户发送Http请求时,Servlet容器可以从HttpServletRequest对象中读取SessionID,然后根据SessionID找到对应的HttpSession对象,从而获取客户的状态信息。

Session的接口HttpSession:

getId()   返回session的ID

Invalidate()  让当前session失效,Servlet容器会释放HttpSession对象占用的资源

getAttribut()     setAttribute()

isNew()  判断是否是新创建的session,如果是返回true 否则返回false

setMaxInactiveInterval()  设置session的最大有效时间 单位为秒 如果设置为负数,表示不限制session处于不活动状态的最大有效时间,默认的设置时间为30分钟

Session的生命周期:

当客户第一次访问WEB应用中支持Session的某个页面时,就会开始一个新的session

接下来客户访问这个WEB应用中不同的网页时,都处于同一个session中

默认情况下,JSP页面是支持Session的,如果想不支持Session,可使用标签<%@ page session=”false”%>

在下列情况下,Session将结束生命周期,Servlet容器将释放HttpSession占用的资源:

1,客户浏览器关闭?

2,Session过期

3,服务器端调用了HttpSession的Invalidate()方法

如何做到在浏览器关闭时删除Session?

严格的讲,做不到这一点。可以做的努力的办法是在所有的客户端页面里使用javascript的方法window.onclose来监视浏览器的关闭动作,然后向服务器发送一个请求来删除Session;

但是对于浏览器崩溃或强行杀死进程这种非常规手段仍然无能为力。

实际上我们在项目中也不会这么做,而是让服务器在Session过期时将其删除。