python从零学习搭建测试平台（一）

web框架与web服务、web应用服务概念

概念区分

web服务器：
负责处理htt请求，响应静态文件，常见的有 Apache， Nginx以及微软的IIs

应用服务器：
负责处理逻辑的服务器。比如php、 python的代码，是不能直接通过 nginx这种web服务器来处理的，只能通过应用服务器来处理，常见的应用服务器有中uwsgi、tomcat等。

web应用框架：
一般使用某种语言，封装了常用的web功能的框架就是web应用框架，flask、Django以及Java中的ssH（ Structs2+ Spring3+ Hibernate3）框架都是web应用框架

WEB应用的访问流程

目前的web应用程序都是基于B(客户端-浏览器) / S(web服务器+web应用[框架])结构
模拟一个客户端浏览器访问web服务器的过程

1.用户在浏览器中输入访问地址，也就是提供web应用服务的服务器地址。

• 浏览器本质上是一个socket客户端程序；
• 服务器本质上是一个随时等待客户端来访问连接的socket服务端程序，它会根据客户端的请求进行响应。
• socket就是网络上应用程序之间进行通信的一套机制。

2.web服务器接到客户端的访问请求后，会转发给web应用程序[框架]对请求进行处理，web应用程序[框架]把处理结果返回，web服务器再返回给用户浏览器。

• web服务器本质上是一个随时等待客户端来访问连接的socket服务端程序，它会根据客户端的请求进行响应。
• 在python开发的web应用中，常用的web服务器包括Nginx+uWSGI(组合使用)　　
  

Nginx: 只是一个静态文件服务器或者http请求转发器，nginx实现了uwsgi协议，
通过uwsgi协议将请求转发给uWSGI，它实现了一部分web服务器功能。
Nginx擅长高并发，静态文件，Proxy，gzip压缩等等。
Nginx+uWSGI组合中，Nginx负责处理静态资源，
动态请求转给uWSGI调用Python来完成。

uWSGI: 是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。WSGI是一种Web服务器网关接口。它是一个Web服务器（如nginx，uWSGI等服务器）与web应用（如用Flask框架写的程序）通信的一种规范。

 要注意 WSGI / uwsgi / uWSGI 这三个概念的区分。
- WSGI是一种通信协议。
- uwsgi是一种线路协议而不是通信协议，在此常用于在uWSGI服务器与其他网络服务器的数据通信。
- 而uWSGI是实现了uwsgi和WSGI两种协议的Web服务器。
uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型（type of information），每一个uwsgi packet前4byte为传输信息类型描述，它与WSGI相比是两样东西。

如果使用Nginx+uWSGI组合，uWSGI就是实现了WSGI的一个中间件。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。 
nginx是不能直接部署python web的，因为nginx不支持WSGI规范。 当然nginx也可以实现，不过术业有专攻，nginx没有做。 uWSGI是实现了WSGI接口的，一个完整的http server，可以直接用来部署Python Web的，但为什么还需要Nginx呢？ 因为Nginx擅长高并发，静态文件，gzip压缩等，这些功能是uWSGI不具备的。如果你的网站访问量不大，可以只用uWSGI，完全不需要用Nginx。所以现在流行的使用方法是Nginx+uWSGI (如下图)，Nginx来完成Proxy，静态文件服务等，动态请求转给uWSGI调用Python来完成。 Nginx与uWSGI通过uwsgi(全部小写)协议来完成，uwsgi是一个二进制协议允许uWSGI与Nginx等应用服务器交互。

• WSGI、uwsgi协议

WSGI（Web Server Gateway Interface）：是Python应用程序或框架和Web服务器之间的一种接口，定义web server如何转发请求到Python写的应用中。
就像Java 的servlet API，这样只要实现接口的web server都可以调用遵守此接口的任何Python应用。
WSGI更像一个协议. 只要遵照这些协议,WSGI应用(Application)都可以在任何服务器(Server)上运行, 反之亦然。

WSGI是一个Web服务器（如nginx，uWSGI等服务器）与web应用（如用Django、Flask框架写的程序）通信的一种规范。
WSGI 接口有服务端和应用端两部分，服务端也可以叫网关端，应用端也叫框架端 服务端调用一个由应用端提供的可调用对象。如何提供这个对象，由服务端决定。
例如某些服务器或者网关需要应用的部署者写一段脚本，以创建服务器或者网关的实例，并且为这个实例提供一个应用实例。
另一些服务器或者网关则可能使用配置文件或其他方法以指定应用实例应该从哪里导入或获取。 
WSGI 对于 application 对象有如下三点要求: 必须是一个可调用的对象 接收两个必选参数environ、start_response。 
返回值必须是可迭代对象，用来表示http body。 
WSGI协议主要包括server和application两部分： 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框架，可以根据项目实际情况搭配使用。

uwsgi：uwsgi协议是uWSGI服务器单独使用的协议。
它是一个二进制协议，可以携带任何类型的数据。
一个uwsgi分组的头4个字节描述了这个分组包含的数据类型。
uwsgi通过将消息分片的方式，可以在一个socket上并发传输多个请求。
这样就在fastcgi减轻后端压力好处的基础上，解决了fastcgi一个连接上一次只能传输一个请求的问题。
熟悉HTTP2.0的话会发现这个分片机制跟HTTP2.0很像。

#不用Nginx，uWSGI也可以单独作为web服务器使用，流程如图。

Web 服务器

简单来说，Web服务器是在运行在物理服务器上的一个程序，它永久地等待客户端（主要是浏览器，比如Chrome，Firefox等）发送请求。当收到请求之后，它会生成相应的响应并将其返回至客户端。Web服务器通过HTTP协议与客户端通信，因此也被称为HTTP服务器。

Web服务器的工作原理并不复杂，一般可分成如下4个步骤：

• 建立连接：客户机通过TCP/IP协议建立到服务器的TCP连接。
• 请求过程、应答过程
  • 请求过程：客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档。
    应答过程：服务器向客户机发送HTTP协议应答包，如果请求的资源包含有动态语言的内容，那么服务器会调用动态语言的解释引擎负责处理“动态内容”，并将处理得到的数据返回给客户端。由客户端解释HTML文档，在客户端屏幕上渲染图形结果。
• 关闭连接：客户机与服务器断开。

虽然说web服务器的主要工作是根据request返回response，但是实际中的 Web 服务器远远比上面示例的复杂的多，因为要考虑的因素实在是太多了，比如：

缓存机制：讲一些经常被访问的页面缓存起来，提高响应速度；
安全：防止黑客的各种攻击，比如 SYN Flood 攻击；
并发处理：如何响应不同客户端同时发起的请求；
日志：记录访问日至，方便做一些分析。
目前在UNIX和LINUX平台下使用最广泛的免费 Web 服务器有Apache和Nginx。

Web 应用程序

Web 服务器接受 Http Request，返回 Response，很多时候 Response 并不是静态文件，因此需要有一个应用程序根据 Request 生成相应的 Response。这里的应用程序主要用来处理相关业务逻辑，读取或者更新数据库，根据不同 Request 返回相应的 Response。注意这里并不是 Web 服务器本身来做这件事，它只负责 Http 协议层面和一些诸如并发处理，安全，日志等相关的事情。

应用程序可以用各种语言编写（Java, PHP, Python, Ruby等），这个应用程序会从Web服务器接收客户端的请求，处理完成后，再返回响应给Web服务器，最后由Web服务器返回给客户端。整个架构如下：

Web 框架

早期开发站点确做了许多重复性劳动，后来为了减少重复，避免写出庞杂，混乱的代码，人们将 Web 开发的关键性过程提取出来，开发出了各种 Web 框架。有了框架，就可以专注于编写清晰、易维护的代码，无需关心数据库连接之类的重复性工作。

其中一种比较经典的Web框架采用了MVC架构，如下图所示：

用户输入 URL，客户端发送请求，控制器（Controller）首先会拿到请求，然后用模型（Models）从数据库取出所有需要的数据，进行必要的处理，将处理后的结果发送给视图（View），视图利用获取到的数据，进行渲染生成 Html Response返回给客户端。

以 python web 框架 flask 为例，框架本身并不限定我们用哪种架构来组织我们的应用，不过 flask 可以很好地支持以 MVC 方式组织应用。

Web 服务器网关接口

我们知道Python有着许多的 Web 框架，而同时又有着许多的 Web 服务器（Apache, Nginx, Gunicorn等），框架和Web服务器之间需要进行通信，如果在设计时它们之间不可以相互匹配的，那么选择了一个框架就会限制对 Web 服务器的选择，这显然是不合理的。

那么，怎样确保可以在不修改Web服务器代码或网络框架代码的前提下，使用自己选择的服务器，并且匹配多个不同的网络框架呢？答案是接口，设计一套双方都遵守的接口就可以了。对python来说，就是WSGI（Web Server Gateway Interface，Web服务器网关接口）。其他编程语言也拥有类似的接口：例如Java的Servlet API和Ruby的Rack。

Python WSGI的出现，让开发者可以将 Web 框架与 Web 服务器的选择分隔开来，不再相互限制。现在，你可以真正地将不同的 Web 服务器与Web框架进行混合搭配，选择满足自己需求的组合。例如，可以使用 Gunicorn 或Nginx/uWSGI来运行Django、Flask或web.py应用。

总结：web服务器和web应用(框架)的关系

.web 服务器 和 web 应用[框架]，分工不同，职责不同（web 服务器专注于接收并解析请求以调用的方式将请求的内容传web框架），缺一不可，可以说它们是两个组件，共同协作才能实现web网页的访问。
.web服务器端程序有Nginx+uWSGI的组合使用，如访问量少可单独使用uWSGI。
.web应用（框架）有python开发的应用，或者使用python框架django、flask、Tornado等开发的应用。
.用户浏览器，通过访问web服务器获取web应用（框架）提供的后台服务。下面用三个图反复描述他们之间的关系。

感谢原作者：
https://www.cnblogs.com/yanjidong/articles/13198697.html
https://www.csdn.net/tags/Mtzakg3sMzI2MzMtYmxvZwO0O0OO0O0O.html