Python Web開發最難懂的WSGI協議，到底包含哪些內容？
我想大部分Python開發者最早接觸到的方向是WEB方向（由於老是有開發者但願立刻給本身作個博客出來，例如我），既然是WEB，免不了接觸到一些WEB框架，例如Django,Flask,Torando等等，在開發過程當中，看過一些文檔總會介紹生產環境和開發環境服務器的配置問題，服務器又設計web服務器和應用服務器，總而言之，咱們碰到最多的，一定是這個詞 --- WSGI。
接下來的文章，會分爲如下幾個部分：html
開始
1 WSGI介紹
1.1 什麼是WSGI
首先介紹幾個關於WSGI相關的概念
WSGI：全稱是Web Server Gateway Interface，WSGI不是服務器，python
模塊，框架，API或者任何軟件，只是一種規範，描述web server如何與web application通訊的規範。server和application的規範在PEP 3333中有具體描述。要實現WSGI協議，必須同時實現web server和web application，當前運行在WSGI協議之上的web框架有Torando,Flask,Djangogit
uwsgi：與WSGI同樣是一種通訊協議，是uWSGI服務器的獨佔協議，用於定義傳輸信息的類型(type of information)，每個uwsgi packet前4byte爲傳輸信息類型的描述，與WSGI協議是兩種東西，聽說該協議是fcgi協議的10倍快。github
uWSGI：是一個web服務器，實現了WSGI協議、uwsgi協議、http協議等。web
WSGI協議主要包括server和application兩部分：django
WSGI server負責從客戶端接收請求，將request轉發給application，將application返回的response返回給客戶端； WSGI application接收由server轉發的request，處理請求，並將處理結果返回給server。application中能夠包括多個棧式的中間件(middlewares)，這些中間件須要同時實現server與application，所以能夠在WSGI服務器與WSGI應用之間起調節做用：對服務器來講，中間件扮演應用程序，對應用程序來講，中間件扮演服務器。
WSGI協議實際上是定義了一種server與application解耦的規範，便可以有多個實現WSGI server的服務器，也能夠有多個實現WSGI application的框架，那麼就能夠選擇任意的server和application組合實現本身的web應用。例如uWSGI和Gunicorn都是實現了WSGI server協議的服務器，Django，Flask是實現了WSGI application協議的web框架，能夠根據項目實際狀況搭配使用。服務器
以上介紹了相關的常識，接下來咱們來看看如何簡單實現WSGI協議。cookie
1.2 怎麼實現WSGI
上文說過，實現WSGI協議必需要有wsgi server和application，所以，咱們就來實現這兩個東西。app
咱們來看看官方WSGI使用WSGI的wsgiref模塊實現的小demo框架
有關於wsgiref的快速入門能夠看看這篇博客
def demo_app(environ,start_response):
from StringIO import StringIO
stdout = StringIO()
print >>stdout, "Hello world!"
print >>stdout
h = environ.items(); h.sort()
for k,v in h:
print >>stdout, k,'=', repr(v)
start_response("200 OK", [('Content-Type','text/plain')])
return [stdout.getvalue()]
httpd = make_server('localhost', 8002, demo_app)
httpd.serve_forever() # 使用select
實現了一個application，來獲取客戶端的環境和回調函數兩個參數，以及httpd服務端的實現，咱們來看看make_server的源代碼
def make_server(
host, port, app, server_class=WSGIServer, handler_class=WSGIRequestHandler
):
"""Create a new WSGI server listening on `host` and `port` for `app`"""
server = server_class((host, port), handler_class)
server.set_app(app)
return server
接受一系列函數，返回一個server對象,實現仍是比較簡單，下面咱們來看看在django中如何實現其自身的wsgi服務器的。
下面咱們本身來實現一遍：
WSGI 規定每一個 python 程序（Application）必須是一個可調用的對象（實現了__call__ 函數的方法或者類），接受兩個參數 environ（WSGI 的環境信息） 和 start_response（開始響應請求的函數），而且返回 iterable。幾點說明：
environ 和 start_response 由 http server 提供並實現 environ 變量是包含了環境信息的字典 Application 內部在返回前調用 start_response start_response也是一個 callable，接受兩個必須的參數，status（HTTP狀態）和 response_headers（響應消息的頭） 可調用對象要返回一個值，這個值是可迭代的。
# 1. 可調用對象是一個函數
def application(environ, start_response):
response_body = 'The request method was %s' % environ['REQUEST_METHOD']
# HTTP response code and message
status = '200 OK'
# 應答的頭部是一個列表，每對鍵值都必須是一個 tuple。
response_headers = [('Content-Type', 'text/plain'),
('Content-Length', str(len(response_body)))]
# 調用服務器程序提供的 start_response，填入兩個參數
start_response(status, response_headers)
# 返回必須是 iterable
return [response_body]
# 2. 可調用對象是一個類
class AppClass:
"""這裏的可調用對象就是 AppClass 這個類，調用它就能生成能夠迭代的結果。
使用方法相似於：
for result in AppClass(env, start_response):
do_somthing(result)
"""
def __init__(self, environ, start_response):
self.environ = environ
self.start = start_response
def __iter__(self):
status = '200 OK'
response_headers = [('Content-type', 'text/plain')]
self.start(status, response_headers)
yield "Hello world!\n"
# 3. 可調用對象是一個實例
class AppClass:
"""這裏的可調用對象就是 AppClass 的實例，使用方法相似於：
app = AppClass()
for result in app(environ, start_response):
do_somthing(result)
"""
def __init__(self):
pass
def __call__(self, environ, start_response):
status = '200 OK'
response_headers = [('Content-type', 'text/plain')]
self.start(status, response_headers)
yield "Hello world!\n"
服務器程序端
上面已經說過，標準要可以確切地實行，必需要求程序端和服務器端共同遵照。上面提到， envrion 和 start_response 都是服務器端提供的。下面就看看，服務器端要履行的義務。
準備 environ 參數 定義 start_response 函數 調用程序端的可調用對象
import os, sys
def run_with_cgi(application): # application 是程序端的可調用對象
# 準備 environ 參數，這是一個字典，裏面的內容是一次 HTTP 請求的環境變量
environ = dict(os.environ.items())
environ['wsgi.input'] = sys.stdin
environ['wsgi.errors'] = sys.stderr
environ['wsgi.version'] = (1, 0)
environ['wsgi.multithread'] = False
environ['wsgi.multiprocess'] = True
environ['wsgi.run_once'] = True
environ['wsgi.url_scheme'] = 'http'
headers_set = []
headers_sent = []
# 把應答的結果輸出到終端
def write(data):
sys.stdout.write(data)
sys.stdout.flush()
# 實現 start_response 函數，根據程序端傳過來的 status 和 response_headers 參數，
# 設置狀態和頭部
def start_response(status, response_headers, exc_info=None):
headers_set[:] = [status, response_headers]
return write
# 調用客戶端的可調用對象，把準備好的參數傳遞過去
result = application(environ, start_response)
# 處理獲得的結果，這裏簡單地把結果輸出到標準輸出。
try:
for data in result:
if data: # don't send headers until body appears
write(data)
finally:
if hasattr(result, 'close'):
result.close()
2 由Django框架分析WSGI
下面咱們以django爲例，分析一下wsgi的整個流程
django WSGI application
WSGI application應該實現爲一個可調用iter對象，例如函數、方法、類(包含**call**方法)。須要接收兩個參數：一個字典，該字典能夠包含了客戶端請求的信息以及其餘信息，能夠認爲是請求上下文，通常叫作environment（編碼中多簡寫爲environ、env），一個用於發送HTTP響應狀態（HTTP status）、響應頭（HTTP headers）的回調函數,也就是start_response()。經過回調函數將響應狀態和響應頭返回給server，同時返回響應正文(response body)，響應正文是可迭代的、幷包含了多個字符串。
下面是Django中application的具體實現部分：
class WSGIHandler(base.BaseHandler):
initLock = Lock()
request_class = WSGIRequest
def __call__(self, environ, start_response):
# 加載中間件
if self._request_middleware is None:
with self.initLock:
try: # Check that middleware is still uninitialized.
if self._request_middleware is None:
self.load_middleware()
except: # Unload whatever middleware we got
self._request_middleware = None raise
set_script_prefix(get_script_name(environ)) # 請求處理以前發送信號
signals.request_started.send(sender=self.__class__, environ=environ)
try:
request = self.request_class(environ)
except UnicodeDecodeError:
logger.warning('Bad Request (UnicodeDecodeError)',exc_info=sys.exc_info(), extra={'status_code': 400,}
response = http.HttpResponseBadRequest()
else:
response = self.get_response(request)
response._handler_class = self.__class__ status = '%s %s' % (response.status_code, response.reason_phrase)
response_headers = [(str(k), str(v)) for k, v in response.items()] for c in response.cookies.values(): response_headers.append((str('Set-Cookie'), str(c.output(header=''))))
# server提供的回調方法，將響應的header和status返回給server
start_response(force_str(status), response_headers)
if getattr(response, 'file_to_stream', None) is not None and environ.get('wsgi.file_wrapper'):
response = environ['wsgi.file_wrapper'](response.file_to_stream)
return response
能夠看出application的流程包括:加載全部中間件，以及執行框架相關的操做，設置當前線程腳本前綴，發送請求開始信號；處理請求，調用get_response()方法處理當前請求，該方法的的主要邏輯是經過urlconf找到對應的view和callback，按順序執行各類middleware和callback。調用由server傳入的start_response()方法將響應header與status返回給server。返回響應正文
django WSGI Server
負責獲取http請求，將請求傳遞給WSGI application，由application處理請求後返回response。以Django內建server爲例看一下具體實現。經過runserver運行django
項目，在啓動時都會調用下面的run方法，建立一個WSGIServer的實例，以後再調用其serve_forever()方法啓動服務。
def run(addr, port, wsgi_handler, ipv6=False, threading=False):
server_address = (addr, port)
if threading:
httpd_cls = type(str('WSGIServer'), (socketserver.ThreadingMixIn, WSGIServer), {})
else:
httpd_cls = WSGIServer # 這裏的wsgi_handler就是WSGIApplication
httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
if threading:
httpd.daemon_threads = True httpd.set_app(wsgi_handler)
httpd.serve_forever()
下面表示WSGI server服務器處理流程中關鍵的類和方法。
WSGIServerrun()方法會建立WSGIServer實例，主要做用是接收客戶端請求，將請求傳遞給application，而後將application返回的response返回給客戶端。
建立實例時會指定HTTP請求的handler：WSGIRequestHandler類
經過set_app和get_app方法設置和獲取WSGIApplication實例wsgi_handler
處理http請求時，調用handler_request方法，會建立WSGIRequestHandler
實例處理http請求。
WSGIServer中get_request方法經過socket接受請求數據
WSGIRequestHandler由WSGIServer在調用handle_request時建立實例，傳入request、cient_address、WSGIServer三個參數，__init__方法在實例化同時還會調用自身的handle方法handle方法會建立ServerHandler實例，而後調用其run方法處理請求
ServerHandlerWSGIRequestHandler在其handle方法中調用run方法，傳入self.server.get_app()參數，獲取WSGIApplication，而後調用實例(__call__
)，獲取response，其中會傳入start_response回調，用來處理返回的header和status。經過application獲取response之後，經過finish_response返回response
WSGIHandlerWSGI協議中的application，接收兩個參數，environ字典包含了客戶端請求的信息以及其餘信息，能夠認爲是請求上下文，start_response用於發送返回status和header的回調函數
雖然上面一個WSGI server涉及到多個類實現以及相互引用，但其實原理仍是調用WSGIHandler，傳入請求參數以及回調方法start_response()，並將響應返回給客戶端。
3 實際環境使用的wsgi服務器
由於每一個web框架都不是專一於實現服務器方面的，所以，在生產環境部署的時候使用的服務器也不會簡單的使用web框架自帶的服務器，這裏，咱們來討論一下用於生產環境的服務器有哪些？
1.
gunicorn
Gunicorn（從Ruby下面的Unicorn獲得的啓發）應運而生：依賴Nginx的代理行爲，同Nginx進行功能上的分離。因爲不須要直接處理用戶來的請求（都被Nginx先處理），Gunicorn不須要完成相關的功能，其內部邏輯很是簡單：接受從Nginx來的動態請求，處理完以後返回給Nginx，由後者返回給用戶。
因爲功能定位很明確，Gunicorn得以用純Python開發：大大縮短了開發時間的同時，性能上也不會很掉鏈子。同時，它也能夠配合Nginx的代理以外的別的Proxy模塊工做，其配置也相應比較簡單。
配置上的簡單，大概是它流行的最大的緣由。
2.
uwsgi
由於使用C語言開發，會和底層接觸的更好，配置也是比較方便，目前和gunicorn兩個算是部署時的惟二之選。
如下是一般的配置文件
[uwsgi] http = $(HOSTNAME):9033 http-keepalive = 1 pythonpath = ../ module = service master = 1 processes = 8 daemonize = logs/uwsgi.log disable-logging = 1 buffer-size = 16384 harakiri = 5 pidfile = uwsgi.pid stats = $(HOSTNAME):1733 運行：uwsgi --ini conf.ini
3.
fcgi
很少數，估計使用的人也是比較少，這裏只是提一下
4.
bjoern
Python WSGI界最牛逼性能的Server其中一個是bjoern，純C，小於1000行代碼，就是看不慣uWSGI的冗餘自寫的。
4 WSGI服務器比較
綜合廣大Python開發者的實際經歷，咱們能夠得出，使用最廣的當屬uWSGI以及gunicorn，咱們這裏來比較比較二者與其餘服務器的區別。
1.gunicorn自己是個多進程管理器，須要指定相關的不一樣類型的worker去工做，使用gevent做爲worker時單機大概是3000RPS Hello World，賽過torando自帶的服務器大概是2000左右，uWSGI則會更高一點。
2.相比於tornado對於現有代碼須要大規模重構才能用上高級特性，Gevent只須要一個monkey，容易對代碼進行快速加工。
3.gunicorn 能夠作 pre hook and post hook.
下面來對比如下uWSGI和gunicorn的速度差比
能夠看到，若是單純追求性能，那uWSGI會更好一點，而gunicorn則會更易安裝和結合gevent。
結合這篇文章,咱們也能夠得出相同結論，在阻塞響應較多的狀況下，gunicorn的gevent模式無疑性能會更增強大。
功能實現方面，無疑uWSGI會更多一些，配置也會更加複雜一些，能夠看看uWSGI的配置和gunicorn的配置
至於怎麼去選擇，就看你們的項目結構怎麼樣了。
最後，宣傳一下咱們的開源組織，PSC開源組，但願以開源項目的方式讓每一個人都能更有融入性的去學習，公開化你的學習。
github地址：https://github.com/PythonScie...
官方論壇：http://www.pythonscientists.com
- 1. Python Web開發最難懂的WSGI協議，到底包含哪些內容？
- 2. 轉載：Python Web開發最難懂的WSGI協議，到底包含哪些內容？
- 3. WEB開發——Python WSGI協議詳解
- 4. JavaWeb包含哪些內容
- 5. Javascript包含哪些內容
- 6. Python-WSGI協議
- 7. python - wsgi協議
- 8. Python的WSGI協議
- 9. Web前端開發難嗎？都要學習哪些內容？
- 10. STM32Cube到底包含哪些工具？
- 更多相關文章...
- • 數據庫涉及到哪些技術？ - MySQL教程
- • Eclipse 內容輔助 - Eclipse 教程
- • PHP開發工具
- • Docker容器實戰(七) - 容器眼光下的文件系統
-
每一个你不满意的现在，都有一个你没有努力的曾经。