精华内容
下载资源
问答
  • Tornado Web服务器

    2015-09-04 12:37:34
    Tornado 和现在的主流 Web 服务器框架(包括大多数 Python 的框架)有着明显的区别:它是非阻塞式服务器,而且速度相当快。...我们开发这个 Web 服务器主要目的就是为了处理 FriendFeed 的实时功能

    Tornado 和现在的主流 Web 服务器框架(包括大多数 Python 的框架)有着明显的区别:它是非阻塞式服务器,而且速度相当快。得利于其 非阻塞的方式和对 epoll 的运用,Tornado 每秒可以处理数以千计的连接,这意味着对于实时 Web 服务来说,Tornado 是一个理想的 Web 框架。我们开发这个 Web 服务器的主要目的就是为了处理 FriendFeed 的实时功能 ——在 FriendFeed 的应用里每一个活动用户都会保持着一个服务器连接。


    中文网站:http://www.tornadoweb.cn/

    英文网站:http://www.tornadoweb.org/【建议看英文,时时更新】

    展开全文
  • nginx-web服务器部署

    2020-08-18 10:33:48
    导读:​web服务器也称为www服务器,主要功能是提供网上信息浏览服务, 通俗的说,web服务器是可以向发出请求的浏览器提供文档的程序。nginx是近几年异军突起的一款高性能的轻量级web服务器。本次分享主题是《nginx-...

    导读:​web服务器也称为www服务器,主要功能是提供网上信息浏览服务, 通俗的说,web服务器是可以向发出请求的浏览器提供文档的程序。nginx是近几年异军突起的一款高性能的轻量级web服务器。本次分享主题是《nginx-web服务器部署》,本次分享主要包括基本原理、安装配置及项目部署三部分。

    一. 什么是web服务器

    图1是web服务器的工作原理,可见其根本工作就是接收数据、发送数据和数据处理,高级的服务器就是将这三个部分更加细致的设计。

    nginx就是这样一款高性能服务器,由俄罗斯工程师Igor Sysoev为俄罗斯访问量第二的Rambler.ru站点开发,它的主要功能有:HTTP服务器、反向代理、负载均衡和虚拟主机,主要优点有:高并发、高扩展性、高可靠、低内存消耗、热部署以及低成本等等。

    目前很多大型网站都应用nginx服务器作为后端网站程序的反向代理及负载均衡器,来提升整个站点的负载并发能力。

    图1 web服务器工作原理

    二.如何安装配置nginx

    1.基本功能安装配置

    nginx即可以安装在Windows,也可以安装在linux下,安装的方式有多种。以linux为例,基本安装分为三步:依赖安装、nginx下载、nginx安装。nginx配置主要通过修改配置文件nginx.conf。

    图2 基本安装及常用命令

    2.ssl安装配置

    如果用到https,还需安装ssl模块,ssl模块的配置需要购买相关证书。

    图3 ssl安装配置

    三.解决实际项目部署问题

    1.跨域问题

    现在的web项目多是前后端分离,有着不同的端口或在不同的服务器,所以跨域问题成为web开发中一个很重要的问题。nginx的反向代理功能可以将前端的连接请求转发给后端服务器,并将从后服务器上得到的结果返回给前端,从而表现为一个反向代理服务器。

    2.使用同一个域名配置多个不同的项目

    实际中,一个域名下可能有多个站点,每个站点对应一个小项目,它们通过区分上下文访问,如www.data.com/a和www.data.com/b,这时可以将每个站点分别绑定到不同的端口,并通过nginx反向代理到对应端口,从而通过一个域名不带端口的访问多个项目。

    3.软件负载均衡问题              

    负载均衡在实际项目操作过程中,有硬件负载均衡和软件负载均衡两种,由于硬负载相对造价昂贵,多数公司考虑成本原因会使用软负载。nginx的负载均衡功能可以将数据流量分摊到多个服务器执行,减轻每台服务器的压力,从容应对高并发等情况。

    nginx还有许多其他实用且有趣的功能,大家有兴趣可以具体实践一下。

     

    欢迎大家关注公众号:通信大数据分析及应用

    展开全文
  • 万维网 (WORLD WIDE WEB,WWW)服务器,也称之为WEB服务器主要功能是提供网上信息浏览服务。目前主流的WEB服务器软件包括:Apache、Nginx、Lighttpd、IIS、Resin、Tomcat、WebLogic、Jetty。本章向读者介绍


    万维网 (WORLD WIDE WEB,WWW)服务器,也称之为WEB服务器,主要功能是提供网上信息浏览服务。目前主流的WEB服务器软件包括:Apache、Nginx、Lighttpd、IIS、Resin、Tomcat、WebLogic、Jetty。本章向读者介绍Nginx高性能WEB服务器、Nginx工作原理、安装配置及升级、Nginx配置文件深入剖析、Nginx虚拟主机、Location案例演示、Nginx Rewirte企业案例实战、HTTPS安全WEB服务器及Nginx高性能集群实战等。

    1.1 Nginx WEB入门简介

    Nginx特点是占有内存少,并发能力强,事实上Nginx的并发能力确实在同类型的网页服务器中表现较好。
    Nginx相对于Apache优点如下:

    • 高并发响应性能非常好,官方Nginx处理静态文件并发5w/s;
    • 均衡及反向代理性能非常强;
    • 系统内存和CPU占用率低;
    • 可对后端服务进行健康检查
    • 支持PHP cgi方式和FastCGI方式;
    • 可以作为缓存服务器、邮件代理服务器;
    • 配置代码简洁且容易上手。

    1.2 Nginx工作原理

    Nginx WEB服务器最主要就是各种模块的工作,模块从结构上分为核心模块、基础模块和第三方模块,其中三类模块分别如下:

    • 核心模块:HTTP模块、EVENT模块和MAIL模块等;
    • 基础模块:HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块;
    • 第三方模块:HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块、Limit_req模块等;

    Nginx的模块从功能上分为如下三类。

    • Handlers(处理器模块):此类模块直接处理请求,并进行输出内容和修改headers信息等操作,Handlers处理器模块一般只能有一个;
    • Filters (过滤器模块):此类模块主要对其他处理器模块输出的内容进行修改操作,最后由Nginx输出;
    • Proxies (代理类模块):此类模块是Nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如FastCGI等进行交互,实现服务代理和负载均衡等功能。

    Nginx由内核和模块组成,其中内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端的请求映射到一个location block,而location是Nginx配置中的一个指令,用于访问的URL匹配,而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作,如图14-1所示:
    在这里插入图片描述
    Nginx的高并发得益于其采用了epoll模型,与传统的服务器程序架构不同,epoll是Linux内核2.6以后才出现的,Nginx采用epoll模型,异步非阻塞,而apache采用的是select模型:

    Select特点:select 选择句柄的时候,是遍历所有句柄,也就是说句柄有事件响应时,select需要遍历所有句柄才能获取到哪些句柄有事件通知,因此效率是非常低。
    epoll的特点:epoll对于句柄事件的选择不是遍历的,是事件响应的,就是句柄上事件来就马上选择出来,不需要遍历整个句柄链表,因此效率非常高。
    Nginx默认以80端口监听在服务器上,并且启动一个master进程,同时有master进程生成多个工作进程,当浏览器发起一个HTTP连接请求,每个进程都有可能处理这个连接,怎么做到的呢?怎么保证同一时刻一个HTTP请求被一个工作进程处理呢。
    首先每个worker进程都是从Master进程fork出来,在Master进程里面,建立好需要listen的socket(listenfd)之后,会fork出多个worker进程。
    所有worker进程的listenfd会在新连接到来时变得可读,为保证只有一个进程处理该连接,所有worker进程在注册listenfd读事件前抢accept_mutex,抢到互斥锁的那个进程注册listenfd读事件,在读事件里调用accept接受该连接。
    

    当一个worker进程在accept这个连接之后,就开始读取请求、解析请求、处理请求,产生数据后,再返回给客户端,最后才断开连接,这样形成一个完整的请求流程。如图14-2所示:
    在这里插入图片描述

    1.3 Nginx安装配置

    Nginx WEB安装时可以指定很多的模块,默认需要安装Rewrite模块,也即是需要系统有PCRE库,安装Pcre支持Rewrite功能。如下为安装Nginx WEB服务器方法:源码的路径,而不是编译后的路径,否则会报错。

    #安装PCRE库支持yum install pcre-devel pcre -y
    #下载Nginx源码包
    cd /usr/src wget -c http://nginx.org/download/nginx-1.16.0.tar.gz 
    #解压Nginx源码包
    tar -xzf nginx-1.16.0.tar.gz
    #进入解压目录,然后sed修改Nginx版本信息为JWS
    cd nginx-1.16.0; sed -i -e 's/1.16.0//g' -e 's/nginx\//JWS/g' -e 's/"NGINX"/"JWS"/g' src/core/nginx.h
    #预编译Nginx
    useradd www;./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module
    #.configure预编译成功后,执行make命令进行编译
    make
    #make执行成功后,执行make install 正式安装
    make install
    #至此Nginx WEB服务器安装完毕。
    

    测试Nginx服务安装是否正确,同时启动Nginx WEB 服务,代码命令如下:

    /usr/local/nginx/sbin/nginx  -t  检查nginx配置文件是否正确,返回OK即正确。
    [root@localhost ~]# /usr/local/nginx/sbin/nginx -t
    nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
    nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
    [root@localhost ~]#
    然后启动nginx,/usr/local/nginx/sbin/nginx 回车即可。查看进程是否已启动:
    [root@localhost ~]# ps -ef |grep nginx
    nobody    5381 30285  0 May16 ?        09:04:31 nginx: worker process         
    root     30285     1  0  2017 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
    root     32260 32220  0 12:34 pts/0    00:00:00 grep nginx
    [root@localhost ~]#
    

    通过浏览器访问Nginx默认测试页面,如图14-3所示:
    在这里插入图片描述

    1.4 Nginx管理及升级

    Nginx WEB服务器安装完毕,可以执行如下命令对其进管理和维护,命令如下:

    #查看nginx进程
    ps -ef|grep nginx
    #平滑启动nginx 
    kill -HUP `cat /var/run/nginx.pid` 
    或者
    nginx -s reload
    其中进程文件路径在配置文件nginx.conf中可以找到。
    平滑启动的意思是在不停止nginx的情况下,重启nginx,重新加载配置文件,启动新的工作线程,完美停止旧的工作线程。
    #完美停止nginx 
    kill -QUIT `cat /var/run/nginx.pid`
    #快速停止nginx 
    kill -TERM `cat /var/run/nginx.pid`
    或者
    kill -INT `cat /var/run/nginx.pid`
    #完美停止工作进程(主要用于平滑升级) 
    kill -WINCH `cat /var/run/nginx.pid`
    #强制停止nginx 
    pkill -9 nginx
    #检查对nginx.conf文件的修改是否正确 
    nginx -t -c /etc/nginx/nginx.conf 或者 nginx -t
    #停止nginx的命令
    nginx -s stop或者pkill nginx
    #查看nginx的版本信息
    nginx -v
    #查看完整的nginx的配置信息 
    nginx -V
    

    Nginx WEB服务器定期更新,如果需要将低版本升级或者将高版本降级,升级或者降级方法如下,分为四个步骤,包括软件下载、预编译、编译、配置,具体方法如下:

    wget http://www.nginx.org/download/nginx-1.4.2.tar.gz  
    获取旧版本nginx的configure选项
    /usr/local/nginx/sbin/nginx -V 
    编译新版本的Nginx
    tar  -xvf  nginx-1.4.2.tar.gz 
    cd nginx-1.4.2 
    ./configure --prefix=/usr/local/nginx --user=www --group=www --with-http_stub_status_module --with-http_ssl_module 
    make 
    备份旧版本的nginx可执行文件,复制新版本的nginx这行文件
    mv /usr/local/nginx/sbin/nginx  /usr/local/nginx/sbin/nginx.old 
    cp objs/nginx /usr/local/nginx/sbin/
    测试新版本nginx是否正常
    /usr/local/nginx/sbin/nginx -t
    平滑重启升级nginx
    kill –QUIT `cat /usr/local/nginx/log/nginx.oldbin` ##关闭旧版nginx 
    验证nginx是否升级成功
    /usr/local/nginx/sbin/nginx  -V显示最新编译的版本信息即可。
    

    1.5 Nginx配置文件优化一

    学习Nginx服务的难点在于对配置文件的理解和优化,熟练掌握Nginx配置文件参数的含义可以更快的掌握Nginx,如下为Nginx.conf配置文件常用参数详解:

    #定义Nginx运行的用户和用户组
    user  www  www;
    #启动进程,通常设置成和cpu的数量相等
    worker_processes  8;
    worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
    #为每个进程分配cpu,上例中将8个进程分配到8个cpu,当然可以写多个,或者将一个进程分配到多个cpu。
    worker_rlimit_nofile  102400;
    #该指令是当一个nginx进程打开的最多文件描述符数目,理论值应该是最多打开文件数(ulimit -n)与nginx进程数相除,但是nginx分配请求并不是那么均匀,所以最好与ulimit -n的值保持一致。
    #全局错误日志及PID文件
    error_log  /usr/local/nginx/logs/error.log; 
    #错误日志定义等级,[ debug | info | notice | warn | error | crit ]
    pid        /usr/local/nginx/nginx.pid;
    #工作模式及连接数上限
    events {
    use   epoll;              
    #epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能.
    worker_connections  102400; 
    #单个后台worker process进程的最大并发链接数 (最大连接数=连接数*进程数)
    multi_accept  on; 
    #尽可能多的接受请求.
    }
    #设定http服务器,利用它的反向代理功能提供负载均衡支持
    http {
    #设定mime类型,类型由mime.type文件定义
    include       mime.types;
    default_type  application/octet-stream;
    #设定日志格式
    access_log    /usr/local/nginx/log/nginx/access.log;
    sendfile      on;
    #sendfile 指令指定 nginx 是否调用 sendfile 函数(zero copy 方式)来输出文件,对于普通应用必须设为 on
    #如果用来进行下载等应用磁盘IO重负载应用,可设置为 off,以平衡磁盘与网络I/O处理速度,降低系统的uptime。
    #autoindex  on;  
    #开启目录列表访问,合适下载服务器,默认关闭。
    tcp_nopush on;   
    #防止网络阻塞
    keepalive_timeout 60;
    #keepalive超时时间,客户端到服务器端的连接持续有效时间,当出现对服务器的后继请求时,keepalive-timeout功能可避免建立或重新建立连接。
    tcp_nodelay   on; 
    #提高数据的实时响应性
    #开启gzip压缩
    gzip on;
    gzip_min_length  1k;
    gzip_buffers     4 16k;
    gzip_http_version 1.1;
    gzip_comp_level 2; 
    #压缩级别大小,最大为9,值越小,压缩后比例越小,CPU处理更快。
    #值越大,消耗CPU比较高。
    gzip_types       text/plain application/x-javascript text/css application/xml;
    gzip_vary on;
    client_max_body_size 10m;      
    #允许客户端请求的最大单文件字节数
    client_body_buffer_size 128k; 
    #缓冲区代理缓冲用户端请求的最大字节数.
    proxy_connect_timeout 90;      
    #nginx跟后端服务器连接超时时间(代理连接超时)
    proxy_send_timeout 90;         
    #后端服务器数据回传时间(代理发送超时)
    proxy_read_timeout 90;         
    #连接成功后,后端服务器响应时间(代理接收超时)
    proxy_buffer_size 4k;          
    #设置代理服务器(nginx)保存用户头信息的缓冲区大小
    proxy_buffers 4 32k;           
    #proxy_buffers缓冲区,网页平均在32k以下的话,这样设置
    proxy_busy_buffers_size 64k;   
    #高负荷下缓冲大小(proxy_buffers*2)
    #设定请求缓冲
    large_client_header_buffers  4 4k;
    client_header_buffer_size 4k;
    #客户端请求头部的缓冲区大小,这个可以根据你的系统分页大小来设置,一般一个请求的头部大小不会超过1k
    #不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
    open_file_cache max=102400 inactive=20s;
    #这个将为打开文件指定缓存,默认是没有启用的,max指定缓存数量,建议和打开文件数一致,inactive是指经过多长时间文件没被请求后删除缓存。
    open_file_cache_valid 30s;
    #这个是指多长时间检查一次缓存的有效信息。
    open_file_cache_min_uses 1;
    #open_file_cache指令中的inactive参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive
    #包含其它配置文件,如自定义的虚拟主机
    include vhosts.conf;
    

    1.6 Nginx配置文件优化二

    Nginx WEB默认发布静态页面,也可以均衡后端动态网站,用户发起HTTP请求,如果请求静态页面,Nginx直接处理并返回,如果请求的是动态页面,Nginx收到请求之后会进行判断,转到后端服务器去处理。
    Nginx实现负载均衡需要基于upstream模块,同时需要设置location proxy_pass转发指令实现。
    如下为Ningx应用负载均衡集群配置,根据后端实际情况修改即可,jfedu_www为负载均衡模块的名称,可以任意指定,但必须跟vhosts.conf、Nginx.conf虚拟主机的proxy_pass段保持一致,否则不能将请求转发至后端的服务器,weight表示配置权重,在fail_timeout内检查max_fails次数,失败则剔除均衡。

    upstream jfedu_www {
      server   127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
      server   127.0.0.1:8081 weight=1 max_fails=2 fail_timeout=30s;
     }
       #虚拟主机配置
     server {
      #侦听80端口
            listen       80;
            #定义使用www.jfedu.net访问
            server_name  www.jfedu.net;
            #设定本虚拟主机的访问日志
            access_log  logs/access.log  main;
       root   /data/webapps/www;  #定义服务器的默认网站根目录位置
            index index.php index.html index.htm;   #定义首页索引文件的名称
            #默认请求
            location ~ /{
              root   /data/webapps/www;      #定义服务器的默认网站根目录位置
              index index.php index.html index.htm;   #定义首页索引文件的名称
              #以下是一些反向代理的配置.
        proxy_next_upstream http_502 http_504 error timeout invalid_header;
        #如果后端的服务器返回502、504、执行超时等错误,自动将请求转发到upstream负载均衡池中的另一台服务器,实现故障转移。
              proxy_redirect off;
              #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_pass  http://jfedu_www;     #请求转向后端定义的均衡模块
           }
            # 定义错误提示页面
       error_page   500 502 503 504 /50x.html;  
                location = /50x.html {
                root   html;
            }
      #配置Nginx动静分离,定义的静态页面直接从Nginx发布目录读取。
      location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
      {
       root /data/webapps/www;
       #expires定义用户浏览器缓存的时间为3天,如果静态页面不常更新,可以设置更长,这样可以节省带宽和缓解服务器的压力,在浏览器保存该类型文件的天数。
       expires      3d;
      }
            #PHP脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
            location ~ \.php$ {
                root /root;
               fastcgi_pass 127.0.0.1:9000;
               fastcgi_index index.php;
               fastcgi_param SCRIPT_FILENAME /data/webapps/www$FastCGI_script_name;
                includefastcgi_params;
            }
            #设定查看Nginx状态的地址
            location /NginxStatus {
                stub_status  on;
            }
         }
    }
    

    通过Expires参数设置,可以使浏览器缓存过期时间,减少与服务器之间的请求和流量。具体Expires定义是给一个资源设定一个过期时间,也就是说无需去服务端验证,直接通过浏览器自身确认是否过期即可,所以不会产生额外的流量。
    如果静态文件不常更新,Expires可以设置为30d,表示在这30天之内再次访问该静态文件,浏览器会发送一个HTTP请求,会比对服务器该文件最后更新时间是否有变化,如果没有变化,则不会从服务器抓取,返回HTTP状态码304,如果有修改,则直接从服务器重新下载,返回HTTP状态码200。

    1.7 Nginx虚拟主机实战

    在真实的企业服务器环境中,为了充分利用服务器的资源,单台Nginx WEB服务器同时会配置N个网站,也可称之为配置N个虚拟域名的主机,即多个域名对应同一个80端口。
    在Nginx.conf中加入server代码,Nginx虚拟主机完整代码如下:

    worker_processes  1;
    events {
        worker_connections  1024;
    }
    http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
    #virtual hosts config 2017/5/18
    server {
            listen       80;
            server_name  www.jf1.com;
            access_log  logs/jf1.access.log;
            location / {
                root   html/jf1;
                index  index.html index.htm;
            }
    }
    server {
            listen       80;
            server_name  www.jf2.com;
            access_log  logs/jf2.access.log;
            location / {
                root   html/jf2;
                index  index.html index.htm;
            }
    
     }
    }
    

    创建两个不同的目录mkdir –p /usr/local/nginx/html/{jf1,jf2},然后分别在两个目录创建两个不同的index.html网站页面即可。通过Windows客户端配置hosts绑定IP与两个域名的对应关系,在IE浏览器访问测试效果,如图14-4(a)、14-4(b)所示:
    在这里插入图片描述
    在这里插入图片描述

    1.8 Nginx Location深入剖析

    Nginx由内核和模块组成,其中内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端的请求映射到一个location block,而location是Nginx配置中的一个指令,用于访问的URL匹配,而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
    默认Nginx.conf配置文件中至少存在一个location /,即表示客户端浏览器请求的URL为:域名+/,如果location /newindex/,则表示客户端浏览器请求的URL为:域名+/newindex/。
    

    常见Location匹配URL的方式如下:

    匹配配置 说明
    = 字面精确匹配;
    ^~ 最大前缀匹配;
    / 不带任何前缀:最大前缀匹配;
    ~ 大小写相关的正则匹配;
    ~* 大小写无关的正则匹配;
    @ location内部重定向的变量。
    其中Location =、^~、/属于普通字符串匹配,Location ~、~*属于正则表达式匹配,Location优先级与其在Nginx.conf配置文件中的先后顺序无关。
    Location = 精确匹配会第一个被处理,如果发现精确匹配,Nginx则停止搜索其他任何Location的匹配。
    普通字符匹配,正则表达式规则和完整URL规则将被优先和查询匹配,^~为最大前缀匹配,如果匹配到该规则,Nginx则停止搜索其他任何Location的匹配,否则nginx会继续处理其他location指令。
    正则匹配"~"和"~*",如果找到相应的匹配,则Nginx停止搜索其他任何Location的匹配;当没有正则表达式或者没有正则表达式被匹配的情况下,那么匹配程度最高的逐字匹配指令会被使用。
    

    Location规则匹配优先级总结如下:

    (location =) > (location 完整路径) > (location ^~ 路径) > (location ~|~* 正则顺序) > (location 部分起始路径) > (/)
    

    如下为Nginx Location规则案例演示:

    location  = / {
      [ configuration  L1 ] 
      #只会匹配/,优先级比Location /低。
    }
    location  = /index.html {
      [ configuration  L2 ]  
    #只会匹配/index.html,优先级最高。
    }
    location  / {
      [ configuration L3 ] 
      #匹配任何请求,因为所有请求都是以"/"开始;
      #但是更长字符匹配或者正则表达式匹配会优先匹配,优先级最低。
    }
    location = /images/ {
      [ configuration L4 ] 
      #匹配任何以/images/开始的请求,并停止匹配其它location;
    }
    location ~* \.(html|txt|gif|jpg|jpeg)$ { 
      [ configuration L5] 
      # 匹配以html、txt、gif、jpg、jpeg结尾的URL文件请求; 
      # 但是所有/images/目录的请求将由 [Configuration L4]处理。
    }
    浏览器发起HTTP Request URI案例与Location规则案例匹配如下:
    / ->匹配configuration L3;
    /index.html匹配configuration L2;
    /images/匹配configuration L4;
    /images/logo.png匹配configuration L4;
    /img/test.jpg匹配configuration L5。
    

    企业生产环境中无需在Nginx.conf配置文件中同时添加五种规则匹配,如下为企业生产环境Nginx Location部分配置代码:

    location /
    {
        root /var/www/html/;
    	expires      60d;
    }
    location ~ .*\.(gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
    {
    	root /var/www/html/;
    	expires      60d;      
    }
    location ~ .*\.(jsp|php|cgi|do)$
    {
    	root /var/www/html/;
    	proxy_pass http://linux_web;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host  $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;    
    }
    location =/newindex.html
    {
        root /var/www/newwww/;
    	expires      60d;
    }
    

    1.9 企业实战Nginx动静分离架构

    Nginx动静分离简单来说就是把动态跟静态请求分开,不能理解成只是单纯的把动态页面和静态页面物理分离。严格意义上说应该是动态请求跟静态请求分开,可以理解成使用Nginx处理静态页面,Tomcat、Resin、PHP、ASP处理动态页面。
    动静分离从目前实现角度来讲大致分为两种,一种是纯粹的把静态文件独立成单独的域名,放在独立的服务器上,也是目前主流推崇的方案;另外一种方法就是动态跟静态文件混合在一起发布,通过Nginx来分开。
    

    Nginx线上WEB服务器动静分离及Nginx.conf完整配置文件代码如下:

    user www www;
    worker_processes 8;
    worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
    pid /usr/local/nginx/nginx.pid;
    worker_rlimit_nofile 102400;
    events
    {
    use epoll;
    worker_connections 102400;
    }
    http
    {
      include       mime.types;
      default_type  application/octet-stream;
     fastcgi_intercept_errors on;
      charset  utf-8;
      server_names_hash_bucket_size 128;
      client_header_buffer_size 4k;
      large_client_header_buffers 4 32k;
      client_max_body_size 300m;
      sendfile on;
      tcp_nopush     on;
      keepalive_timeout 60;
      tcp_nodelay on;
      client_body_buffer_size  512k;
      proxy_connect_timeout    5;
      proxy_read_timeout       60;
      proxy_send_timeout       5;
      proxy_buffer_size        16k;
      proxy_buffers            4 64k;
      proxy_busy_buffers_size 128k;
      proxy_temp_file_write_size 128k;
      gzip on;
      gzip_min_length  1k;
      gzip_buffers     4 16k;
      gzip_http_version 1.1;
      gzip_comp_level 2;
      gzip_types       text/plain application/x-javascript text/css application/xml;
      gzip_vary on;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent"  $request_time';
    upstream  jvm_web1 {
        server   192.168.149.130:8080  weight=1  max_fails=2  fail_timeout=30s;
        server   192.168.149.130:8081  weight=1  max_fails=2  fail_timeout=30s;
    }
    include vhosts.conf;
    }
    

    如下为vhosts.conf配置文件中内容:

    server
      {
        listen       80;
        server_name www.jf1.com;
        index  index.jsp index.html index.htm;
        root  /data/webapps/www1;
        location /
        {
             proxy_next_upstream http_502 http_504 error timeout invalid_header;
             proxy_set_header  Host  $host;
             proxy_set_header  X-Real-IP  $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_pass http://jvm_web1;
        }
        location ~ .*\.(php|jsp|cgi|shtml)?$
        {
             proxy_set_header Host  $host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_pass http://jvm_web1;
        }
        location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
        {
    		root /data/webapps/www1;
    		expires      30d;
        }
    		access_log  /data/logs/jvm_web1/access.log main;
    		error_log   /data/logs/jvm_web1/error.log  crit;
    }
    

    配置文件代码中:location ~ ..(php|jsp|cgi|shtml)表示匹配动态页面请求,然后将请求proxy_pass到后端服务器,而location ~ ..(html|htm|gif|jpg|jpeg |ico|txt|js|css)表示匹配静态页面请求本地返回。
    检查Nginx配置是否正确即可,然后测试动静分离是否成功,在192.168.149.130服务器启动8080、8081 Tomcat服务或者LAMP服务,删除后端Tomcat或者LAMP服务器上的某个静态文件,测试是否能访问该文件,如果可以访问说明静态资源Nginx直接返回了,如果不能访问,则证明动静分离不成功。

    展开全文
  • 关键字: tomcat, iis, apache 首先我们应该对应用服务器和web服务器...就是提供了web功能的服务器,主要就是http服务,包括图片的下载,等等一系列和web相关的。 好吧,你会问为什么我们不能直接使用应用服务...
    关键字: tomcat, iis, apache 
    首先我们应该对应用服务器和web服务器有一个清晰的概念。所谓的应用服务器,就是提供应用的服务器,这里的应用有很多,比如java应用,ruby 应用,或者 c#应用。

    那么什么是web服务器呢?就是提供了web功能的服务器,主要就是http服务,包括图片的下载,等等一系列和web相关的。

    好吧,你会问为什么我们不能直接使用应用服务器呢?应用服务器也提供了http服务,比如tomcat。

    那么我们从实际出发。当你浏览一个网页的时候,什么情况下你会觉得速度很慢?我们仅仅考虑页面本身。那当然是图片越多显示得越慢。

    好吧,我们至少认识到一点,一些静态资源,例如图片,会严重影响页面打开的速度。当然,这仅仅是一个方面。

    那么web服务器有什么用呢?web服务器一个优点就是在处理静态信息上。例如一些静态的html,图片,等等其他静态的东西。

    那为什么tomcat不能具备这些优点?这个问题我们可以换一个说法:为什么会计不能做市场营销呢?

    所以嘛,大家要分工明确,应用服务器就做好它该做的:如何解释一个jsp,如何处理java文件等等,做好这一点就足够了。而web服务器也做好它该做的:如何快速向浏览器传递信息,如何快速地让浏览器下载图片。

    那你又问了,那为啥tomcat还提供一个http服务?那不是让你开发方便嘛!千万别把tomcat的http服务当成是一个web服务器。

    说了这么多,那么我们对应用服务器和web服务器的整合也应该心里有数了。就拿tomcat和iis整合来说事吧!

    我们到底想干什么呢?很明显,我们想让tomcat 处理对 java应用的请求,而iis应该处理图片,css 等等其他静态资源的事情。

    具体的细节不谈了,无非就是配置 ispai_redirect 这个东东。因为我们主要说的分工问题,所以还是说说这个 uriworkermap.properties 文件。

    这个文件就是处理分工的用的。例如我定义成如下这个样子:
    /www.abc.com/eshop/*.do=ajp13
    /www.abc.com/eshop/dwr/interface/*=ajp13
    /www.abc.com/eshop/dwr/*=ajp13
    /www.abc.com/eshop/js/*=ajp13

    那么就告诉了 isapi_redirect , 以上4种请求,都交给tomcat处理。
    那么其他的请求呢?当然是交给 iis了。

    如果我定义成这个样子:
    /* = ajp13

    这下可惨了,iis被你浪费了,就好像你招聘了一个会计和一个推销的人员,但是让会计干财务的活之外,还干了推销。而推销人员给闲置了。

    ------------------------------------------------------------
    通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。

    web服务器(web server)

    web服务器可以解析(handles)http协议。当web服务器接收到一个http请求(request),会返回一个http响应 (response),例如送回一个html页面。为了处理一个请求(request),web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如cgi脚本,jsp(javaserver pages)脚本,servlets,asp(active server pages)脚本,服务器端(server-side)javascript,或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个html的响应(response)来让浏览器可以浏览。

    要知道,web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。

    虽然web服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

    应用程序服务器(the application server)

    根据我们的定义,作为应用程序服务器,它通过各种协议,可以包括http,把商业逻辑暴露给(expose)客户端应用程序。web服务器主要是处理向浏览器发送html以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。

    应用程序服务器的客户端(包含有图形用户界面(gui)的)可能会运行在一台pc、一个web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态html,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。

    在大多数情形下,应用程序服务器是通过组件(component)的应用程序接口(api)把商业逻辑暴露(expose)(给客户端应用程序)的,例如基于j2ee(java 2 platform, enterprise edition)应用程序服务器的ejb(enterprise javabean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keeping duties)包括安全(security),事务处理(transaction processing),资源池(resource pooling),和消息(messaging)。就象web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

    一个例子

    例如,设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后,网站会进行查找(lookup)并把结果内嵌在html页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

    情景1:不带应用程序服务器的web服务器

    在此种情景下,一个web服务器独立提供在线商店的功能。web服务器获得你的请求(request),然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file,译者注:flat file是指没有特殊格式的非二进制的文件,如properties和xml文件等)中查找定价信息。一旦找到,服务器端(server-side)程序把结果信息表示成(formulate)html形式,最后web服务器把会它发送到你的web浏览器。

    简而言之,web服务器只是简单的通过响应(response)html页面来处理http请求(request)。

    情景2:带应用程序服务器的web服务器

    情景2和情景1相同的是web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server -side)程序)。然而,你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化,此脚本只是简单的调用应用程序服务器的查找服务(lookup service),而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生html响应(response)时就可以使用该服务的返回结果了。

    在此情景中,应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节,相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时,此服务只是简单的查找并返回结果给客户端。

    通过从响应产生(response-generating)html的代码中分离出来,在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端,例如收款机,也可以调用同样的服务(service)来作为一个店员给客户结帐。相反,在情景1中的定价查找服务是不可重用的因为信息内嵌在 html页中了。

    总而言之,在情景2的模型中,在web服务器通过回应html页面来处理http请求(request),而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。

    警告(caveats)

    现在,xml web services已经使应用程序服务器和web服务器的界线混淆了。通过传送一个xml有效载荷(payload)给服务器,web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。

    另外,现在大多数应用程序服务器也包含了web服务器,这就意味着可以把web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了web服务器的功能,但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有web服务器的功能)。相反,如果需要,他们通常会把web服务器独立配置,和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的web请求(request)就不会影响应用程序服务器了),分开配置(专门的web服务器,集群(clustering)等等),而且给最佳产品的选取留有余地

    -----------------------------------------------


    文章分类:Java编程
    参考:
    http://dawanghai.iteye.com/blog/663927

    What is the difference between an application server and a Web server?
    Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:
    A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

    Let's examine each in more detail.
    The Web server
    A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.
    Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.
    While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.
    The application server
    As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
    Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.
    In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.
    How do Web and application servers fit into the enterprise?
    An example
    As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
    Scenario 1: Web server without an application server
    In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
    To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
    Scenario 2: Web server with an application server
    Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
    In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
    By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.
    Caveats
    Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.
    Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.


    Tomcat Tomcat严格意义上并不是一个真正的App Server,它只是一个可以支持运行Serlvet/JSP的 Web容器,不过Tomcat也扩展了一些App Server的功能,如JNDI,数据库连接池,用户事务 处理等等。

    web服务器:Tomcat
    应用服务器:IBM Websphere,BEA WebLogic,RedHat JBoss
    展开全文
  • WEB服务器主要功能包括提供以HTTP协议为主的静态文件下载与传输、动态服务器脚本文件(如asp、aspx、php、jsp)等的处理前端(注意:不是后端!这些脚本通常是由后端脚本处理程序处理完后,由WEB前端服务器作为...
  • 就是提供了web功能服务器主要就是http服务,包括图片的下载,等等一系列和web相关的。 好吧,你会问为什么我们不能直接使用应用服务器呢?应用服务器也提供了http服务,比如tomcat。 ...
  • Web服务器 - apache篇

    2017-08-20 23:52:37
    目前比较主流的几个Web服务器软件包括世界使用量排名第一的apache,轻量级,提供反向代理功能,支持高并发的nginx,还有微软的iis服务器,今天主要介绍apache服务器。 Apache简介 Apache服
  • 主要功能如下: 使用nio处理socket连接。 提供类似spring mvc的功能, 包括@Controller,@RequestMapping,参数注入等功能。 不用三方库,纯手动解析HTTP协议。 项目总计1700行java代码, {理解原理 + 不实现}三天左右...
  • 关于应用服务器和web服务器的整合,有很多的资料了,可是都讲的半生不熟的。根据这几天整合tomcat 和 iis 的经验,再次聊聊这个话题。...就是提供了web功能的服务器,主要就是http服务,包括图片的
  • 就是提供了web功能服务器主要就是http服务,包括图片的下载,等等一系列和web相关的。 好吧,你会问为什么我们不能直接使用应用服务器呢?应用服务器也提供了http服务,比如tomcat。 那么我们从实
  • Web

    2020-05-21 13:57:39
    题目2 .Web服务器主要功能包括: 存储网站资源文件,代用户发送请求,提供基本的安全功能。( ) 选择一项: 对 错 正确的答案是“错”。 题目3.Web服务端应用程序开发主要可以使用以下几种编程语言: PHP、ASP.NET等...
  • 除此之外,还有两个其他主要项目扩展了其功能: 是一个功能强大,灵活,最受欢迎和最全面的Web托管控制面板,适用于Linux和BSD系统,在全球范围内安装了150,000多个安装。 它有开源社区支持的版本,以及功能更丰富...
  • AtomWeb主要包括:运行在开发环境下的工具:aw-scanner: Web 服务器文件扫描工具。扫描服务器源目录,生成Web文件查找表。aw-converter: Web 页面转换工具。将源文件转换为C文件。目标平台链接库libatomweb.a: 提供...
  • 主函数也有两个主要功能,第一是要对程序进行初始化,其中包括创建监听套接字并且绑定到地址和端口上,第二是创建子进程处理对应的连接请求。 1、主函数 Web服务器的主函数中第一是初始化程序,第二就是创建子...
  • 本文所搭建的是局域网内可访问的web服务器主要功能包括ls目录和cat文件。使用HTTP协议,通过浏览器与服务器进行通信。为防止遗忘,特此写下这篇博客,有不妥之处还望指正。 主要操作 服务器/客户端的模型类似于...
  • 解析如何改善和优化 Web 服务器性能

    千次阅读 2015-07-07 23:46:54
    完整的Web结构应包括:HTTP协议,Web服务器,通用网关接口CGI、Web应用程序接口、Web浏览器。   Web服务器是指驻留在因特网上某种类型计算机的程序。它是在网络中信息提供者基干HTTP的为实现信息发布、资料查询、...
  • 服务器端和监控端可独立运行,也可配合使用服务器主要功能服务器端的主要功能是对服务器自己提供的服务进行实时监控。一旦监控的服务出现问题,监控程序将按事先设定的操作来恢复服务,包括自动重启IIS服务,按...
  • 万维网(world wide web,WWW)服务器,也称之为Web服务器主要功能是提供网上信息浏览服务。WWW是Internet的多媒体信息查询工具,是Internet上飞快发展的服务,也是目前应用最广泛的服务。这是因为有了WWW软件,才...
  • 网络知识--web服务器

    2021-02-26 19:14:03
    服务器和普通计算机的功能是类似的。 只是相对于普通计算机,服务器在稳定性、安全性、性能等方面都要求更高,因此CPU、芯片组、 内存、磁盘系统、网络硬件和普通计算机有所不同。 具体来说,服务器与普通计算机的...
  • 服务器端的主要功能是对服务器自己提供的服务进行实时监控。一旦监控的服务出现问题,监控程序将按事先设定的操作来恢复服务,包括自动重启IIS服务,按要求执行一定的命令序列,当机自动重启服务器,实时记录监控...
  • 1、软件的主要架构软件的文件布局比较清晰,主要分为6个模块,主模块是thttpd.c文件,这个文件中包含了web server的主要逻辑,并调用了其他模块的函数。其他的5个模块都是单一的功能模块,之间没有任何耦合。其中...
  • 引言  目前,网络化控制己成为远程控制的主要研究方向,利用... 嵌入式Web服务器必须具备的基本功能包括:可控制与其连接的设备并获取设备的状态和数据;现场信息可以网页形式发布;可及时响应远程用户的控制命令。
  • 功能说明 作者初衷是编写一个web框架支持...webrouter:接口路由网关服务,对外提供统一的流量入口,主要负责请求分发以及黑白名称配置。 cppweb在读数据采用epoll网络模型,以任务队列的方式处理具体请求,回包也
  • 功能说明 作者初衷是编写一个web框架支持...webrouter:接口路由网关服务,对外提供统一的流量入口,主要负责请求分发以及黑白名称配置。 cppweb在读数据采用epoll网络模型,以任务队列的方式处理具体请求,回包也
  • ASP.NET - EditorZone Web 服务器控件概述

    千次阅读 2010-01-05 16:44:00
    Web 部件的一项主要功能是使最终用户能够个性化网页并保存其个性化设置。修改 Web 部件页的一个方面包括编辑可见 WebPart 控件的外观、布局、行为和其他属性。Web 部件控件集中的几种控件可提供编辑功能。其中包括 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 811
精华内容 324
关键字:

web服务器主要功能包括