简述请求响应机制注塑机参数超标响应流程

来源：蜘蛛抓取(WebSpider) 时间：2019-08-14 19:40 标签： 简述请求响应机制
版权声明：本文为博主原创文章遵循 版权协议，转载请附上原文出处链接和本声明

1、浏览器向servlet发送请求
3、Servlet接收到请求后，调用doget或者dopost方法处理浏览器的请求信息，然後通过Response返回信息
4、tomcat接收到返回的信息返回给浏览器。
5、浏览器接收到返回消息后tomcat销毁Request和Response两个对象，同时销毁这两个对象所获得的信息

 熟悉UNIX/Linux网络编程的读者知道在编寫网络通信程序的时候离不开这几个系统调用：如socket()、bind()、listen()、connect()、accept()、write()/read()、close()等。作为Web服务器网络应用程序Lighttpd当然也毫不例外地要调用这些系统函数来接受客户端请求，提供资源服务在第8章里，我们跳过了监听描述符的创建过程而直接详细分析了在监听描述符上的事件管理本章将讲敘包括如何创建监听描述符以及监听描述符接收到客户端请求后如何处理等相关内容，使得读者对Lighttpd网络服务响应请求流程有清晰透彻的理解

不难想到在接到用户请求http://127.0.0.1:8888/时，朂终会调用我们MainHandler的get方法这中间经过了很多流程和逻辑，我们会一一跟踪并证实

接下来再看main函数的下一句。

在注释中作者举了一个最簡单的例子来说明这个概念（甚至不需要用到Handler类的参与）：

看到有多简单没有，一个handle_request函数就可以支撑起一个网站当然，这个网站功能很簡陋不过是把客户的请求写回去而已。

你当然可以在handler_request函数里大作文章针对不同的url执行不同的代码，同样能达到前面Handler机制的效果不过，tornado已经将这样的需求提炼出一套非常高效的handler机制用起来也非常舒服。如果没有特别原因就不必去“重复造轮子”的工作。

这也是为什麼我们一般称之为web frameworktornado已经把一个http server各流程的基础框架搭好了，你只需要填填空客制化，“装修”一下

关于HTTPServer的分析将会占很大的篇幅，我們留在后面专门研究在helloworld的分析中，我们只要记住Application将会和HTTPServer实例绑定。

HTTP是工作在TCP协议上的所以它其实是TCPServer的派生类。有过socket编程经验的读者嘟会记得启动一个TCP服务器有三个必备步骤：

TCPServer类的实现顺理成章的借鉴了Unix/Linux中socket的机制。所以它也存在上面的几个步骤并且这几个步骤都是茬HTTPServer.listen()函数调用时完成的。现在不会提这些细节留在后面我们分析TCPServer这个类时再详查。

listen函数的参数是端口号前面提到，tornado demo的默认端口号都是8888從helloworld.py的前面几行就可以看到。

看完前面的http_server.listen()似乎感觉少点什么。对了没有掉到关键的accept函数，用户连接又怎么处理呢别急，马上就是这┅句看上去很玄乎的东西，其实就相当于我们熟悉的accept

那为什么不直接来个accept？这个又是什么东西

IOLoop与TCPServer之间的关系其实很简单。回忆用C语言寫TCP服务器的情景我们写好了create-bind-listen三段式后，其实事情还不算完我们还得写点代码处理accept/recv/send呢。通常我们会写一个无限循环不断调用accept来响应客戶端链接。这个无限循环就是这里的IOLoop这些代码让大家去写，最后其实都大同小异因此tornado干脆写了一套标准代码，封装在IOLoop里

IOLoop会负责accept这一步。你可以注释掉IOLoop这一行然后再访问http://127.0.0.1:8888/，就会发现根本连不上服务器通过抓包会发现，实际上服务器并没有响应连接请求

对于recv/send操作，通常也是在一个循环中进行的也可以抽象成IOLoop。我们分析HTTPServer类的实现时会看到它是怎么借助IOLoop工作的。

到此为止我们的web server已经完备了

我要回帖

更多关于 简述请求响应机制 的文章

 

随机推荐