web服务

web服务

 

　　学写python的时候，我们多多少少都接触到了web程序，然而你有没有想过，当浏览器发送了一个http请求时，等待接收这个请求的后端代码是一种什么样的思想感情？

　　就像下面这张图里画的一样，后端也许是一段java代码，也许是php代码，当然，如果代码出自我手，最可能的还是一段python代码。这就好比，当你在社交软件上给一个陌生人发了一条消息，对面这个人可能是英国人、印度人也有可能是一只羊或者一只狗。。。那么问题来了，他们怎么知道你在说啥？当然了，在web服务的世界里没有现实中那么复杂，我们不需要考虑后台接收请求的是一只羊。。。接下来我们就来看看，在url和代码之间到底发生了什么见不得人的事儿~

　　

　　首先，当我们写了一段代码可以被http访问的时候，我们就建立了一个webserver。从下图中我们不难看出，这就是浏览器和web服务器之间的日常工作，对于服务器来说，要做的5件事情中，只有第3件是根据请求的不同在发生变化的：

　　

　

　　因此，本着解耦的思想，就有人提出了新的方案，将服务器端反复做的事情独立出来，封装起来，对于程序员来说，我们只需要关注处理请求的部分，有专门的逻辑替我们处理这万年不变的4步，是不是就使得代码简洁了很多？

　　然而，当我们这么做之后，服务器和app之间就不再是紧密团结在一起的整体，服务器必须知道要讲接收到的请求、参数以什么方式传达到app端，这就是我们在django中可以使用request.method、request.POST.get等方法的原因——约好了呀，说高大上点儿，这种约定就叫做协议！

　　

　　下图是我们在写django时经常做的事情，左侧是一个http请求，右侧是python代码，我们只需要在代码里写一个函数，url配一配，就可以使用左侧的url请求到后端的代码，为什么如此顺利，是什么让http和python代码之间的代沟消失了？

　　　

　　

　　

　　以Django框架为例，Django在这个过程中做了哪些事儿呢？它就是很贴心的把整个服务器要做的事情以及服务器和app交互的过程给封装起来了呀~~~

　　这么说起来，Django对我们的代码来说，真是又当爹又当妈的模范家长啊！

　　

　　当然啦！除了Django之外，python还有很多其他的web框架、模块都做了同样的封装，他们也能对http请求进行分析，并承担起和后台代码交互的重任，然而我们知道人与人之间即便是交流同样的事情也有很多种不同的表达方式，因此，我们说，虽然同样是做http和代码的交互工作，但对协议的定义可能不尽相同。

　　下面列举一些常见的 Python HTTP 服务器，以及它们目前的大致发展情况，以便用户的对比选择：

Name	Version	http 1.1	Flavour	Repo.	Community
Gunicorn	0.6.4	No	processor/thread	GIT	#gunicorn
uWSGI	Trunk (253)	Yes	processor/thread	repo	Mailing List
FAPWS3	0.3.1	No	processor/thread	GIT	Google Groups
Aspen	0.8	No	processor/thread	SVN	Google Groups
Mod_WSGI	3.1	Yes	processor/thread	SVN	Google Groups
wsgiref	Py 2.6.4	No	processor/thread	SVN	Mailing List
CherryPy	3.1.2	Yes	processor/thread	SVN	Planet, IRC
Magnum Py	0.2	No	processor/thread	SVN	Google Groups
Twisted	10.0.0	Yes	processor/thread	SVN	Community
Cogen	0.2.1	Yes	callback/generator	SVN	Google Groups
GEvent	0.12.2	Yes	lightweight threads	Mercurial	Google Groups
Tornado	0.2	Yes	callback/generator	GIT	Google Groups
Eventlet	0.9.6	Yes	lightweight threads	Mercurial	Mailinglist
Concurrence	tip	Yes	lightweight threads	GIT	Google Groups

参考：http://www.nowamagic.net/academy/detail/1330308