如何用 python 搭建一个邮件服务器

如何用 python 搭建一个邮件服务器,第1张

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

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

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

框架与底层

在当今Python服务器框架 (framework, 比如Django, Twisted, web.py等等) 横行的时代,从底层的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:

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

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

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

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

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

(如果没有两台计算机做实验,也可以将客户端IP想要connect的IP改为"127.0.0.1",这是个特殊的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/1.x表示所使用的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,它通常指向一个资源(服务器上的资源或者其它地方的资源)。像现在这样,就是指向当前服务器的当前目录的test.jpg。

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

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

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

使用浏览器实验

为了配合上面的服务器程序,我已经在放置Python程序的文件夹里,保存了一个test.jpg图片文件。

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

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

在浏览器的地址栏输入:

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

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

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

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

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

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

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

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

探索的方向

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

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

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

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

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

我以前的项目里面用到的

"""setting 配置文件""" gmail默认端口是25

EMAIL_HOST = 'smtp.gmail.com'

EMAIL_PORT = '25'

EMAIL_HOST_USER = ''

EMAIL_HOST_PASSWORD = ''

UserEmail=''

EMAIL_USE_TLS = True

"""调用django email方法"""

targetEmails 可以是一个email 也可以是多个 targetEmails 为一个list

send_mail(unicode('标题',"GBK"),unicode(content,"GBK"),setting.UserEmail, targetEmails,fail_silently=True)

通过Nginx部署Django(基于ubuntu)

Django的部署可以有很多方式,采用nginx+uwsgi的方式是其中比较常见的一种方式。

在这种方式中,我们的通常做法是,将nginx作为服务器最前端,它将接收WEB的所有请求,统一管理请求。nginx把所有静态请求自己来处理(这是NGINX的强项)。然后,NGINX将所有非静态请求通过uwsgi传递给Django,由Django来进行处理,从而完成一次WEB请求。

可见,uwsgi的作用就类似一个桥接器。起到桥梁的作用。

Linux的强项是用来做服务器,所以,下面的整个部署过程我们选择在Ubuntu下完成。

一、安装Nginx

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好。

Nginx同样为当前非常流行的web服务器。利用其部署Django,我们在此也做简单的介绍。

Nginx官网:http://nginx.org/

打开ubuntu控制台(ctrl+alt+t)利用Ubuntu的仓库安装。

fnngj@ubuntu:~$ sudo apt-get install nginx #安装

启动Nginx:

fnngj@ubuntu:~$ /etc/init.d/nginx start #启动

fnngj@ubuntu:~$ /etc/init.d/nginx stop #关闭

fnngj@ubuntu:~$ /etc/init.d/nginx restart #重启

修改Nginx默认端口号,打开/etc/nginx/nginx.conf 文件,修改端口号。

复制代码

server {

listen 8088 # 修改端口号

server_name localhost

#charset koi8-r

#access_log logs/host.access.log main

location / {

root html

index index.html index.htm

}

复制代码

大概在文件36行的位置,将默认的80端口号改成其它端口号,如 8088。因为默认的80端口号很容易被其它应用程序占用。

然后,通过上面命令重启nginx。访问:http//127.0.0.1:8088/

如果出现如上图,说明Nginx启动成功。

二、安装uwsgi

通过pip安装uwsgi。

root@ubuntu:/etc# python3 -m pip install uwsgi

测试uwsgi,创建test.py文件:

def application(env, start_response):

start_response('200 OK', [('Content-Type','text/html')])

return [b"Hello World"]

通过uwsgi运行该文件。

fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --wsgi-file test.py

接下来配置Django与uwsgi连接。此处,假定的我的django项目位置为:/home/fnngj/pydj/myweb

fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --chdir /home/fnngj/pydj/myweb/ --wsgi-file myweb/wsgi.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191

常用选项:

http : 协议类型和端口号

processes : 开启的进程数量

workers : 开启的进程数量,等同于processes(官网的说法是spawn the specified number ofworkers / processes)

chdir : 指定运行目录(chdir to specified directory before apps loading)

wsgi-file : 载入wsgi-file(load .wsgi file)

stats : 在指定的地址上,开启状态服务(enable the stats server on the specified address)

threads : 运行线程。由于GIL的存在,我觉得这个真心没啥用。(run each worker in prethreaded mode with the specified number of threads)

master : 允许主进程存在(enable master process)

daemonize : 使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(daemonize uWSGI)。实际上最常用的,还是把运行记录输出到一个本地文件上。

pidfile : 指定pid文件的位置,记录主进程的pid号。

vacuum : 当服务器退出的时候自动清理环境,删除unix socket文件和pid文件(try to remove all of the generated file/sockets)

三、Nginx+uwsgi+Django

接下来,我们要将三者结合起来。首先罗列一下项目的所需要的文件:

myweb/

├── manage.py

├── myweb/

│ ├── __init__.py

│ ├── settings.py

│ ├── urls.py

│ └── wsgi.py

└── myweb_uwsgi.ini

在我们通过Django创建myweb项目时,在子目录myweb下已经帮我们生成的 wsgi.py文件。所以,我们只需要再创建myweb_uwsgi.ini配置文件即可,当然,uwsgi支持多种类型的配置文件,如xml,ini等。此处,使用ini类型的配置。

复制代码

# myweb_uwsgi.ini file

[uwsgi]

# Django-related settings

socket = :8000

# the base directory (full path)

chdir = /home/fnngj/pydj/myweb

# Django s wsgi file

module = myweb.wsgi

# process-related settings

# master

master = true

# maximum number of worker processes

processes = 4

# ... with appropriate permissions - may be needed

# chmod-socket= 664

# clear environment on exit

vacuum = true

复制代码

这个配置,其实就相当于在上一小节中通过wsgi命令,后面跟一堆参数的方式,给文件化了。

socket 指定项目执行的端口号。

chdir 指定项目的目录。

module myweb.wsgi ,可以这么来理解,对于myweb_uwsgi.ini文件来说,与它的平级的有一个myweb目录,这个目录下有一个wsgi.py文件。

其它几个参数,可以参考上一小节中参数的介绍。

接下来,切换到myweb项目目录下,通过uwsgi命令读取myweb_uwsgi.ini文件启动项目。

复制代码

fnngj@ubuntu:~$ cd /home/fnngj/pydj/myweb/

fnngj@ubuntu:~/pydj/myweb$ uwsgi --ini myweb_uwsgi.ini

[uWSGI] getting INI configuration from myweb_uwsgi.ini

*** Starting uWSGI 2.0.12 (32bit) on [Sat Mar 12 13:05:06 2016] ***

compiled with version: 4.8.4 on 26 January 2016 06:14:41

os: Linux-3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015

nodename: ubuntu

machine: i686

clock source: unix

detected number of CPU cores: 2

current working directory: /home/fnngj/pydj/myweb

detected binary path: /usr/local/bin/uwsgi

!!! no internal routing support, rebuild with pcre support !!!

chdir() to /home/fnngj/pydj/myweb

your processes number limit is 15962

your memory page size is 4096 bytes

detected max file descriptor number: 1024

lock engine: pthread robust mutexes

thunder lock: disabled (you can enable it with --thunder-lock)

uwsgi socket 0 bound to TCP address :8000 fd 3

Python version: 3.4.3 (default, Oct 14 2015, 20:37:06) [GCC 4.8.4]

*** Python threads support is disabled. You can enable it with --enable-threads ***

Python main interpreter initialized at 0x8b52dc0

your server socket listen backlog is limited to 100 connections

your mercy for graceful operations on workers is 60 seconds

mapped 319920 bytes (312 KB) for 4 cores

*** Operational MODE: preforking ***

WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x8b52dc0 pid: 7158 (default app)

*** uWSGI is running in multiple interpreter mode ***

spawned uWSGI master process (pid: 7158)

spawned uWSGI worker 1 (pid: 7160, cores: 1)

spawned uWSGI worker 2 (pid: 7161, cores: 1)

spawned uWSGI worker 3 (pid: 7162, cores: 1)

spawned uWSGI worker 4 (pid: 7163, cores: 1)

复制代码

注意查看uwsgi的启动信息,如果有错,就要检查配置文件的参数是否设置有误。

再接下来要做的就是修改nginx.conf配置文件。打开/etc/nginx/nginx.conf文件,添加如下内容。

复制代码

……

server {

listen 8099

server_name127.0.0.1

charset UTF-8

access_log /var/log/nginx/myweb_access.log

error_log /var/log/nginx/myweb_error.log

client_max_body_size 75M

location / {

include uwsgi_params

uwsgi_pass 127.0.0.1:8000

uwsgi_read_timeout 2

}

location /static {

expires 30d

autoindex on

add_header Cache-Control private

alias /home/fnngj/pydj/myweb/static/

}

}

……

复制代码

listen 指定的是nginx代理uwsgi对外的端口号。

server_name 网上大多资料都是设置的一个网址(例,wwwexamplecom),我这里如果设置成网址无法访问,所以,指定的到了本机默认ip。

在进行配置的时候,我有个问题一直想不通。nginx到底是如何uwsgi产生关联。现在看来大概最主要的就是这两行配置。

include uwsgi_params

uwsgi_pass 127.0.0.1:8000

include 必须指定为uwsgi_params;而uwsgi_pass指的本机IP的端口与myweb_uwsgi.ini配置文件中的必须一直。

现在重新启动nginx,翻看上面重启动nginx的命令。然后,访问:http//127.0.0.1:8099/

通过这个IP和端口号的指向,请求应该是先到nginx的。如果你在页面上执行一些请求,就会看到,这些请求最终会转到uwsgi来处理。


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/495817.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-06-15
下一篇2023-06-15

发表评论

登录后才能评论

评论列表(0条)

    保存