从零开始搭建论坛(二):Web服务器网关接口

简介:

【引自selfboot的博客】在 从零开始搭建论坛(一):Web服务器与Web框架 中我们弄清楚了Web 服务器、Web 应用程序、Web框架的概念。对于 Python 来说,越来越多的 Web 框架面世,在给我们更多选择机会的同时,也限制了我们对于 Web Server 的选择。同样是有着很多 Web 框架的Java,因为有着 servlet API 的存在,任何Java Web框架写的应用程序都可以运行在任意一个 Web Server 上。

Python 社区当然也需要这样一套 API,来适配Web服务器和应用程序,这套 API 就是 WSGI(Python Web Server Gateway Interface),在 PEP 3333 里有详细的说明。简单来说,WSGI是连接Web服务器和Web应用程序的桥梁,一方面从Web server 拿到原始 HTTP 数据,处理成统一格式后交给 Web 应用程序,另一方面从应用程序/框架这边进行业务逻辑处理,生成响应内容后交给服务器。

Web服务器和框架通过 WSGI 来进行耦合的详细过程如下图所示:

 WSGI Server 适配

具体解释如下:

  • 应用程序(网络框架)提供一个命名为application的可调用对象(WSGI协议并没有指定如何实现这个对象)。
  • 服务器每次从HTTP客户端接收请求之后,调用可调用对象application,调用时传递一个名叫environ的字典作为参数,以及一个名为start_response的可调用对象。
  • 框架/应用生成HTTP状态码以及HTTP响应报头,然后将二者传递至start_response,等待服务器保存。此外,框架/应用还将返回响应的正文。
  • 服务器将状态码、响应报头和响应正文组合成HTTP响应,并返回给客户端(这一步并不属于WSGI协议)。

下面分别从服务器端和应用程序端来看看 WSGI 是如何做适配的。

服务器端

我们知道客户端(通常是浏览器)发出的每个HTTP请求由请求行、消息报头、请求正文三部分组成,里面包含了本次请求的相关细节内容。比如:

  • Method:指出在由Request-URI标识的资源上所执行的方法,包括GET,POST 等
  • User-Agent:允许客户端将它的操作系统、浏览器和其它属性告诉服务器;

服务器从客户端接收HTTP请求之后,WSGI 接口必须要对这些请求字段进行统一化处理,方便传给应用服务器接口(其实就是给框架)。Web服务器具体传递哪些数据给应用程序,早在CGI(Common Gateway Interface,通用网关接口)里就有详细规定,这些数据被叫做 CGI 环境变量。WSGI 沿用了 CGI 环境变量的内容,要求 Web 服务器必须创建一个字典用来保存这些环境变量(一般将其命名为 environ)。除了 CGI 定义的变量,environ 还必须保存一些WSGI定义的变量,此外还可以保存一些客户端系统的环境变量,可以参考environ Variables 来看看具体有哪些变量。

接着 WSGI 接口必须将 environ 交给应用程序去处理,这里 WSGI 规定应用程序提供一个可调用对象 application,然后服务器去调用 application,获得返回值为HTTP响应正文。服务器在调用 application 的时候,需要提供两个变量,一个是前面提到的变量字典environ,另一个是可调用对象 start_response,它产生状态码和响应头,这样我们就得到了一个完整的HTTP响应。Web 服务器将响应返回给客户端,一次完整的HTTP请求-响应过程就完成了。

wsgiref 分析

Python 中内置了一个实现了WSGI接口的 Web 服务器,在模块wsgiref中,它是用纯Python编写的WSGI服务器的参考实现,我们一起来简单分析一下它的实现。首先假设我们用下面代码启动一个 Web 服务器:


 
 
  1. # Instantiate the server 
  2. httpd = make_server( 
  3.     'localhost',    # The host name 
  4.     8051,           # A port number where to wait for the request 
  5.     application     # The application object namein this case a function 
  6. # Wait for a single request, serve it and quit 
  7. httpd.handle_request()  

然后我们以Web服务器接收一个请求、生成 environ,然后调用 application 来处理请求这条主线来分析源码的调用过程,简化如下图所示:

 WSGI Server 调用流程

这里主要有三个类,WSGIServer,WSGIRequestHandler,ServerHandle。WSGIServer 是Web服务器类,可以提供server_address(IP:Port)和 WSGIRequestHandler 类来进行初始化获得一个server对象。该对象监听响应的端口,收到HTTP请求后通过 finish_request 创建一个RequestHandler 类的实例,在该实例的初始化过程中会生成一个 Handle 类实例,然后调用其 run(application) 函数,在该函数里面再调用应用程序提供的 application对象来生成响应。

这三个类的继承关系如下图所示:

 WSGI 类继承关系图

其中 TCPServer 使用 socket 来完成 TCP 通信,HTTPServer 则是用来做 HTTP 层面的处理。同样的,StreamRequestHandler 来处理 stream socket,BaseHTTPRequestHandler 则是用来处理 HTTP 层面的内容,这部分和 WSGI 接口关系不大,更多的是 Web 服务器的具体实现,可以忽略。

微服务器实例

如果上面的 wsgiref 过于复杂的话,下面一起来实现一个微小的 Web 服务器,便于我们理解 Web 服务器端 WSGI 接口的实现。代码摘自 自己动手开发网络服务器(二),放在 gist 上,主要结构如下:


 
 
  1. class WSGIServer(object): 
  2.     # 套接字参数 
  3.     address_family, socket_type = socket.AF_INET, socket.SOCK_STREAM 
  4.     request_queue_size = 1 
  5.     def __init__(self, server_address): 
  6.         # TCP 服务端初始化:创建套接字,绑定地址,监听端口 
  7.         # 获取服务器地址,端口 
  8.     def set_app(self, application): 
  9.         # 获取框架提供的 application 
  10.         self.application = application 
  11.     def serve_forever(self): 
  12.         # 处理 TCP 连接:获取请求内容,调用处理函数 
  13.     def handle_request(self): 
  14.         # 解析 HTTP 请求,获取 environ,处理请求内容,返回HTTP响应结果 
  15.         env = self.get_environ() 
  16.         result = self.application(env, self.start_response) 
  17.         self.finish_response(result) 
  18.     def parse_request(self, text): 
  19.         # 解析 HTTP 请求 
  20.          
  21.     def get_environ(self): 
  22.         # 分析 environ 参数,这里只是示例,实际情况有很多参数。 
  23.         env['wsgi.url_scheme']   = 'http' 
  24.         ... 
  25.         env['REQUEST_METHOD']    =  self.request_method    # GET 
  26.         ... 
  27.         return env 
  28.     def start_response(self, status, response_headers, exc_info=None): 
  29.         # 添加响应头,状态码 
  30.         self.headers_set = [status, response_headers + server_headers] 
  31.     def finish_response(self, result): 
  32.         # 返回 HTTP 响应信息 
  33. SERVER_ADDRESS = (HOST, PORT) = '', 8888 
  34. # 创建一个服务器实例 
  35. def make_server(server_address, application): 
  36.     server = WSGIServer(server_address) 
  37.     server.set_app(application) 
  38.     return server  

目前支持 WSGI 的成熟Web服务器有很多,Gunicorn是相当不错的一个。它脱胎于ruby社区的Unicorn,成功移植到python上,成为一个WSGI HTTP Server。有以下优点:

  • 容易配置
  • 可以自动管理多个worker进程
  • 选择不同的后台扩展接口(sync, gevent, tornado等)

应用程序端(框架)

和服务器端相比,应用程序端(也可以认为框架)要做的事情就简单很多,它只需要提供一个可调用对象(一般习惯将其命名为application),这个对象接收服务器端传递的两个参数 environ 和 start_response。这里的可调用对象不仅可以是函数,还可以是类(下面第二个示例)或者拥有 __call__ 方法的实例,总之只要可以接受前面说的两个参数,并且返回值可以被服务器进行迭代即可。

Application 具体要做的就是根据 environ 里面提供的关于 HTTP 请求的信息,进行一定的业务处理,返回一个可迭代对象,服务器端通过迭代这个对象,来获得 HTTP 响应的正文。如果没有响应正文,那么可以返回None。

同时,application 还会调用服务器提供的 start_response,产生HTTP响应的状态码和响应头,原型如下:


 
 
  1. def start_response(self, status, headers,exc_info=None):  

Application 需要提供 status:一个字符串,表示HTTP响应状态字符串,还有 response_headers: 一个列表,包含有如下形式的元组:(header_name, header_value),用来表示HTTP响应的headers。同时 exc_info 是可选的,用于出错时,server需要返回给浏览器的信息。

到这里为止,我们就可以实现一个简单的 application 了,如下所示:


 
 
  1. def simple_app(environ, start_response): 
  2.     """Simplest possible application function""" 
  3.     HELLO_WORLD = "Hello world!\n" 
  4.     status = '200 OK' 
  5.     response_headers = [('Content-type''text/plain')] 
  6.     start_response(status, response_headers) 
  7.     return [HELLO_WORLD]  

或者用类实现如下。


 
 
  1. class AppClass: 
  2.     """Produce the same output, but using a class""" 
  3.     def __init__(self, environ, start_response): 
  4.         self.environ = environ 
  5.         self.start = start_response 
  6.     def __iter__(self): 
  7.         ... 
  8.         HELLO_WORLD = "Hello world!\n" 
  9.         yield HELLO_WORLD  

注意这里 AppClass 类本身就是 application,用 environ 和 start_response 调用(实例化)它返回一个实例对象,这个实例对象本身是可迭代的,符合 WSGI 对 application 的要求。

如果想使用 AppClass 类的对象作为 application,那么必须给类添加一个 __call__ 方法,接受 environ 和 start_response 为参数,返回可迭代对象,如下所示:


 
 
  1. class AppClass: 
  2.     """Produce the same output, but using an object""" 
  3.     def __call__(self, environ, start_response):  

这部分涉及到python的一些高级特性,比如 yield 和 magic method,可以参考我总结的python语言要点来理解。

Flask 中的 WSGI

flask 是一个轻量级的Python Web框架,符合 WSGI 的规范要求。它的最初版本只有 600 多行,相对便于理解。下面我们来看下它最初版本中关于 WSGI 接口的部分。


 
 
  1. def wsgi_app(self, environ, start_response): 
  2.     """The actual WSGI application. 
  3.     This is not implemented in `__call__` so that middlewares can be applied: 
  4.         app.wsgi_app = MyMiddleware(app.wsgi_app) 
  5.     ""
  6.     with self.request_context(environ): 
  7.         rv = self.preprocess_request() 
  8.         if rv is None: 
  9.             rv = self.dispatch_request() 
  10.         response = self.make_response(rv) 
  11.         response = self.process_response(response) 
  12.         return response(environ, start_response) 
  13. def __call__(self, environ, start_response): 
  14.     """Shortcut for :attr:`wsgi_app`""" 
  15.     return self.wsgi_app(environ, start_response)  

这里的 wsgi_app 实现了我们说的 application 功能,rv 是 对请求的封装,response 是框架用来处理业务逻辑的具体函数。这里对 flask 源码不做过多解释,感兴趣的可以去github下载,然后check 到最初版本去查看。

中间件

前面 flask 代码 wsgi_app 函数的注释中提到不直接在 __call__ 中实现 application 部分,是为了可以使用中间件。 那么为什么要使用中间件,中间件又是什么呢?

回顾前面的 application/server 端接口,对于一个 HTTP 请求,server 端总是会调用一个 application 来进行处理,并返回 application 处理后的结果。这足够应付一般的场景了,不过并不完善,考虑下面的几种应用场景:

  • 对于不同的请求(比如不同的 URL),server 需要调用不同的 application,那么如何选择调用哪个呢;
  • 为了做负载均衡或者是远程处理,需要使用网络上其他主机上运行的 application 来做处理;
  • 需要对 application 返回的内容做一定处理后才能作为 HTTP 响应;

上面这些场景有一个共同点就是,有一些必需的操作不管放在服务端还是应用(框架)端都不合适。对应用端来说,这些操作应该由服务器端来做,对服务器端来说,这些操作应该由应用端来做。为了处理这种情况,引入了中间件。

中间件就像是应用端和服务端的桥梁,来沟通两边。对服务器端来说,中间件表现的像是应用端,对应用端来说,它表现的像是服务器端。如下图所示:

 中间件

中间件的实现

flask 框架在 Flask 类的初始化代码中就使用了中间件:


 
 
  1. self.wsgi_app = SharedDataMiddleware(self.wsgi_app, { self.static_path: target })  

这里的作用和 python 中的装饰器一样,就是在执行 self.wsgi_app 前后执行 SharedDataMiddleware 中的一些内容。中间件做的事,很类似python中装饰器做的事情。SharedDataMiddleware 中间件是 werkzeug 库提供的,用来支持站点托管静态内容。此外,还有DispatcherMiddleware 中间件,用来支持根据不同的请求,调用不同的 application,这样就可以解决前面场景 1, 2 中的问题了。

下面来看看 DispatcherMiddleware 的实现:


 
 
  1. class DispatcherMiddleware(object): 
  2.     """Allows one to mount middlewares or applications in a WSGI application. 
  3.     This is useful if you want to combine multiple WSGI applications:: 
  4.         app = DispatcherMiddleware(app, { 
  5.             '/app2':        app2, 
  6.             '/app3':        app3 
  7.         }) 
  8.     ""
  9.     def __init__(self, app, mounts=None): 
  10.         self.app = app 
  11.         self.mounts = mounts or {} 
  12.     def __call__(self, environ, start_response): 
  13.         script = environ.get('PATH_INFO'''
  14.         path_info = '' 
  15.         while '/' in script: 
  16.             if script in self.mounts: 
  17.                 app = self.mounts[script] 
  18.                 break 
  19.             script, last_item = script.rsplit('/', 1) 
  20.             path_info = '/%s%s' % (last_item, path_info) 
  21.         else
  22.             app = self.mounts.get(script, self.app) 
  23.         original_script_name = environ.get('SCRIPT_NAME'''
  24.         environ['SCRIPT_NAME'] = original_script_name + script 
  25.         environ['PATH_INFO'] = path_info 
  26.         return app(environ, start_response)  

初始化中间件时需要提供一个 mounts 字典,用来指定不同 URL 路径到 application 的映射关系。这样对于一个请求,中间件检查其路径,然后选择合适的 application 进行处理。

关于 WSGI 的原理部分基本结束,下一篇我会介绍下对 flask 框架的理解。


作者:selfboot

来源:51CTO

相关文章
|
14天前
|
Java PHP
PHP作为广受青睐的服务器端脚本语言,在Web开发中占据重要地位。理解其垃圾回收机制有助于开发高效稳定的PHP应用。
【10月更文挑战第1天】PHP作为广受青睐的服务器端脚本语言,在Web开发中占据重要地位。其垃圾回收机制包括引用计数与循环垃圾回收,对提升应用性能和稳定性至关重要。本文通过具体案例分析,详细探讨PHP垃圾回收机制的工作原理,特别是如何解决循环引用问题。在PHP 8中,垃圾回收机制得到进一步优化,提高了效率和准确性。理解这些机制有助于开发高效稳定的PHP应用。
30 3
|
2月前
|
JavaScript 搜索推荐 前端开发
从零搭建到部署:Angular与Angular Universal手把手教你实现服务器端渲染(SSR),全面解析及实战指南助你提升Web应用性能与SEO优化效果
【8月更文挑战第31天】服务器端渲染(SSR)是现代Web开发的关键技术,能显著提升SEO效果及首屏加载速度,改善用户体验。Angular Universal作为官方SSR解决方案,允许在服务器端生成静态HTML文件。本文通过具体示例详细介绍如何使用Angular Universal实现SSR,并分享最佳实践。首先需安装Node.js和npm。
44 1
|
2月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
92 0
|
2月前
|
Rust 安全 开发者
惊爆!Xamarin 携手机器学习,开启智能应用新纪元,个性化体验与跨平台优势完美融合大揭秘!
【8月更文挑战第31天】随着互联网的发展,Web应用对性能和安全性要求不断提高。Rust凭借卓越的性能、内存安全及丰富生态,成为构建高性能Web服务器的理想选择。本文通过一个简单示例,展示如何使用Rust和Actix-web框架搭建基本Web服务器,从创建项目到运行服务器全程指导,帮助读者领略Rust在Web后端开发中的强大能力。通过实践,读者可以体验到Rust在性能和安全性方面的优势,以及其在Web开发领域的巨大潜力。
35 0
|
2月前
|
Java 数据库 API
JSF与JPA的史诗级联盟:如何编织数据持久化的华丽织锦,重塑Web应用的荣耀
【8月更文挑战第31天】JavaServer Faces (JSF) 和 Java Persistence API (JPA) 分别是构建Java Web应用的用户界面组件框架和持久化标准。结合使用JSF与JPA,能够打造强大的数据驱动Web应用。首先,通过定义实体类(如`User`)和配置`persistence.xml`来设置JPA环境。然后,在JSF中利用Managed Bean(如`UserBean`)管理业务逻辑,通过`EntityManager`执行数据持久化操作。
46 0
|
2月前
|
JavaScript 前端开发 UED
服务器端渲染新浪潮:用Vue.js和Nuxt.js构建高性能Web应用
【8月更文挑战第30天】在现代Web开发中,提升应用性能和SEO友好性是前端开发者面临的挑战。服务器端渲染(SSR)能加快页面加载速度并改善搜索引擎优化。Vue.js结合Nuxt.js提供了一个高效框架来创建SSR应用。通过安装`create-nuxt-app`,可以轻松创建新的Nuxt.js项目,并利用其自动路由功能简化页面管理。Nuxt.js默认采用SSR模式,并支持通过`asyncData`方法预取数据,同时提供了静态站点生成和服务器端渲染的部署选项,显著提升用户体验。
71 0
|
2月前
|
数据可视化 Python
通过python建立一个web服务查看服务器上的文本、图片、视频等文件
通过python建立一个web服务查看服务器上的文本、图片、视频等文件
47 0
|
6天前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
35 3
|
11天前
|
设计模式 测试技术 持续交付
开发复杂Web应用程序
【10月更文挑战第3天】开发复杂Web应用程序
25 2
|
1月前
|
数据可视化 图形学 UED
只需四步,轻松开发三维模型Web应用
为了让用户更方便地应用三维模型,阿里云DataV提供了一套完整的三维模型Web模型开发方案,包括三维模型托管、应用开发、交互开发、应用分发等完整功能。只需69.3元/年,就能体验三维模型Web应用开发功能!
194 8
只需四步,轻松开发三维模型Web应用