学会python能干嘛

有人说表示只学Python没有用，必须学会一个框架(比如Django和webpy)才能找到工作。

其实掌握一个类似于框架的高级工具是有用的，但是基础的东西可以让你永远不被淘汰，不要被工具限制了自己的发展。

今天不使用框架，也不使用Python标准库中的高级包，只使用标准库中的socket接口写一个Python服务器。

框架与底层

在当今Python服务器框架 (framework, 比如Django, Twisted, webpy等等) 横行的时代，从底层的socket开始写服务器似乎是一个出力不讨好的笨方法。

框架的意义在于掩盖底层的细节，提供一套对于开发人员更加友好的API，并处理诸如MVC的布局问题。

框架允许我们快速的构建一个成型而且成熟的Python服务器。然而，框架本身也是依赖于底层(比如socket)。对于底层socket的了解，不仅可以帮助我们更好的使用框架，更可以让我们明白框架是如何设计的。

更进一步，如果拥有良好的底层socket编程知识和其他系统编程知识，你完全可以设计并开发一款自己的框架。

如果你可以从底层socket开始，实现一个完整的Python服务器，支持用户层的协议，并处理好诸如MVC(Model-View-Control)、多线程(threading)等问题，并整理出一套清晰的函数或者类，作为接口(API)呈现给用户，你就相当于设计了一个框架。

socket接口是实际上是操作系统提供的系统调用。

socket的使用并不局限于Python语言，你可以用C或者Java来写出同样的socket服务器，而所有语言使用socket的方式都类似(Apache就是使用C实现的服务器)。

但是你不能跨语言的使用框架。

框架的好处在于帮你处理了一些细节，从而实现快速开发，但同时受到Python本身性能的限制。

我们已经看到，许多成功的网站都是利用动态语言(比如Python, Ruby或者PHP，比如twitter和facebook)快速开发，在网站成功之后，将代码转换成诸如C和JAVA这样一些效率比较高的语言，从而让服务器能更有效率的面对每天亿万次的请求。

在这种情况下，底层的重要性，就远远超过了框架。

TCP/IP和socket简介

回到我们的任务。

我们需要对网络传输，特别是TCP/IP协议和socket有一定的了解。

socket是进程间通信的一种方法，它是基于网络传输协议的上层接口。

socket有许多种类型，比如基于TCP协议或者UDP协议(两种网络传输协议)，其中又以TCP socket最为常用。

TCP socket与双向管道(duplex PIPE)有些类似，一个进程向socket的一端写入或读取文本流，而另一个进程可以从socket的另一端读取或写入，比较特别是，这两个建立socket通信的进程可以分别属于两台不同的计算机。

TCP协议，就是规定了一些通信的守则，以便在网络环境下能够有效实现上述进程间通信过程。

双向管道(duplex PIPE)存活于同一台电脑中，所以不必区分两个进程的所在计算机的地址，而socket必须包含有地址信息，以便实现网络通信。

一个socket包含四个地址信息: 两台计算机的IP地址和两个进程所使用的端口(port)。IP地址用于定位计算机，而port用于定位进程 (一台计算机上可以有多个进程分别使用不同的端口)。

TCP socket

在互联网上，让某台计算机作为服务器。

服务器开放自己的端口，被动等待其他计算机连接。

当其他计算机作为客户，主动使用socket连接到服务器的时候，服务器就开始为客户提供服务。

在Python中，我们使用标准库中的socket包来进行底层的socket编程。

首先是服务器端，我们使用bind()方法来赋予socket以固定的地址和端口，并使用listen()方法来被动的监听该端口。

当有客户尝试用connect()方法连接的时候，服务器使用accept()接受连接，从而建立一个连接的socket：

socketsocket()创建一个socket对象，并说明socket使用的是IPv4(AF_INET，IP version 4)和TCP协议(SOCK_STREAM)。

然后用另一台电脑作为客户，我们主动使用connect()方法来搜索服务器端的IP地址(在Linux中，你可以用$ifconfig来查询自己的IP地址)和端口，以便客户可以找到服务器，并建立连接:

在上面的例子中，我们对socket的两端都可以调用recv()方法来接收信息，调用sendall()方法来发送信息。

这样，我们就可以在分处于两台计算机的两个进程间进行通信了。

当通信结束的时候，我们使用close()方法来关闭socket连接。

(如果没有两台计算机做实验，也可以将客户端IP想要connect的IP改为"127001"，这是个特殊的IP地址，用来连接当地主机。)

基于TCP socket的HTTP服务器

上面的例子中，我们已经可以使用TCP socket来为两台远程计算机建立连接。

然而，socket传输自由度太高，从而带来很多安全和兼容的问题。

我们往往利用一些应用层的协议(比如HTTP协议)来规定socket使用规则，以及所传输信息的格式。

HTTP协议利用请求-回应(request-response)的方式来使用TCP socket。

客户端向服务器发一段文本作为request，服务器端在接收到request之后，向客户端发送一段文本作为response。

在完成了这样一次request-response交易之后，TCP socket被废弃。

下次的request将建立新的socket。

request和response本质上说是两个文本，只是HTTP协议对这两个文本都有一定的格式要求。

Request <——> Response

现在，我们写出一个HTTP服务器端：

HTTP服务器程序的解释

如我们上面所看到的，服务器会根据request向客户传输的两条信息text_content和pic_content中的一条，作为response文本。

整个response分为起始行(start line), 头信息(head)和主体(body)三部分。起始行就是第一行:

它实际上又由空格分为三个片段，HTTP/1x表示所使用的HTTP版本，200表示状态(status code)，200是HTTP协议规定的，表示服务器正常接收并处理请求，OK是供人来阅读的status code。

头信息跟随起始行，它和主体之间有一个空行。

这里的text_content或者pic_content都只有一行的头信息，text_content用来表示主体信息的类型为html文本：

而pic_content的头信息(Content-Type: image/jpg)说明主体的类型为jpg(image/jpg)。

主体信息为html或者jpg文件的内容。

(注意，对于jpg文件，我们使用"rb"模式打开，是为了与windows兼容。因为在windows下，jpg被认为是二进制(binary)文件，在UNIX系统下，则不需要区分文本文件和二进制文件。)

我们并没有写客户端程序，后面我们会用浏览器作为客户端。

request由客户端程序发给服务器。

尽管request也可以像response那样分为三部分，request的格式与response的格式并不相同。

request由客户发送给服务器，比如下面是一个request：

起始行可以分为三部分，第一部分为请求方法(request method)，第二部分是URL，第三部分为HTTP版本。

request method可以有GET， PUT， POST， DELETE， HEAD。最常用的为GET和POST。

GET是请求服务器发送资源给客户，POST是请求服务器接收客户送来的数据。

当我们打开一个网页时，我们通常是使用GET方法；当我们填写表格并提交时，我们通常使用POST方法。

第二部分为URL，它通常指向一个资源(服务器上的资源或者其它地方的资源)。像现在这样，就是指向当前服务器的当前目录的testjpg。

按照HTTP协议的规定，服务器需要根据请求执行一定的操作。

正如我们在服务器程序中看到的，我们的Python程序先检查了request的方法，随后根据URL的不同，来生成不同的response(text_content或者pic_content)。

随后，这个response被发送回给客户端。

使用浏览器实验

为了配合上面的服务器程序，我已经在放置Python程序的文件夹里，保存了一个testjpg文件。

我们在终端运行上面的Python程序，作为服务器端，再打开一个浏览器作为客户端。

(如果有时间，你也完全可以用Python写一个客户端。原理与上面的TCP socket的客户端程序相类似。)

在浏览器的地址栏输入:

(当然，你也可以用令一台电脑，并输入服务器的IP地址)

OK，我已经有了一个用Python实现的，并从socket写起的服务器了。

从终端，我们可以看到，浏览器实际上发出了两个请求。

第一个请求为 (关键信息在起始行，这一个请求的主体为空):

我们的Python程序根据这个请求，发送给服务器text_content的内容。

浏览器接收到text_content之后，发现正文的html文本中有<IMG src="textjpg" />，知道需要获得textjpg文件来补充为，立即发出了第二个请求:

我们的Python程序分析过起始行之后，发现/testjpg符合if条件，所以将pic_content发送给客户。

最后，浏览器根据html语言的语法，将html文本和图画以适当的方式显示出来。

探索的方向

1) 在我们上面的服务器程序中，我们用while循环来让服务器一直工作下去。

实际上，我们还可以根据多线程的知识，将while循环中的内容改为多进程或者多线程工作。

2) 我们的服务器程序还不完善，我们还可以让我们的Python程序调用Python的其他功能，以实现更复杂的功能。比如说制作一个时间服务器，让服务器向客户返回日期和时间。你还可以使用Python自带的数据库，来实现一个完整的LAMP服务器。

3) socket包是比较底层的包。Python标准库中还有高层的包，比如SocketServer，SimpleHTTPServer，CGIHTTPServer，cgi。这些都包都是在帮助我们更容易的使用socket。如果你已经了解了socket，那么这些包就很容易明白了。利用这些高层的包，你可以写一个相当成熟的服务器。

4) 在经历了所有的辛苦和麻烦之后，你可能发现，框架是那么的方便，所以决定去使用框架。或者，你已经有了参与到框架开发的热情。

PythonWeb程序的部署方案

综合而言,高性能的Pythonweb站点部署方式首推nginx+uwsgi

apache+mod_wsgi是简单稳定但性能一般的方式

API服务器可以直接使用tornado或者gevent

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用Apache部署是一个不错的选择。较早的时候，使用mode_python部署python的web应用十分流行,在Django096的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apacheserver,以提供一个访问Apacheserver内部的接口。mod_python在现在看来性能是不佳的，每一个http请求mod_python都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI全称是WebServerGatewayInterface,由PEP-333定义。基本上所有的pythonweb框架都实现了wsgi接口，用mod_wsgi能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署pythonweb程序，推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点：不建议用fastcgi的方式部署Pythonweb。

前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCPconnection（FastCGI进程在远端的serverfarm）传递给FastCGI进程。

主流的web服务器，Apache,lighttpd,nginx都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。

fastcgi并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署pythonweb程序，fastcgi都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能pythonweb程序的部署方式了。

在1U的四核XEON服务器上，一个简单的wsgihandler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP1U服务器上，基本不用管它。

上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。

tornado

tornado号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx114以后的版本反向代理支持长连接，配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。

gevent

gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。

很多种方法,例如:

rpc远程调用通过ip地址,远程指定python文件,直接调用

写一个简单的socket,进行通信,发送命令,根据命令启动python文件

通过http协议,建立简单的web服务,通过http请求调用

通过消息队列,例如zmq,rabbitmq,amq,发送消息或者命令,由消费者调用python文件