自己动手创建一个Web Server(非Socket实现)
目录
- 介绍
- Web Server在Web架构系统中的作用
- Web Server与Web网站程序的交互
- HTTPListener与Socket两种方式的差异
- 附带Demo源码概述
- Demo效果截图
- 总结
介绍
本篇文章主要介绍使用HTTPListener类型自己动手创建一个Web Server,创建的Web Server能够接收来自浏览器端的HTTP请求,并且能够传递给对应的Web站点进行处理,最后将处理结果(Html或者其他格式)返回给浏览器。
博主前面曾经介绍过使用Socket模拟Web Server的运行过程、Socket模拟浏览器发送HTTP请求过程。分别参见:
本篇文章并没有使用Socket去实现,而是使用另外一种封装程度更高、更抽象的System.Net.HTTPListener类型实现。
Web Server在Web架构系统中的作用
Web Server在一个B/S架构系统中起到的作用不仅多而且相当重要,Web开发者大部分时候并不需要了解它的详细工作机制。虽然不同的Web Server可能功能并不完全一样,但是以下三个功能几乎是所有Web Server必须具备的:
- 接收来自浏览器端的HTTP请求
- 将请求转发给指定Web站点程序(后者由Web开发者编写,负责处理请求)
- 向浏览器发送请求处理结果
下图显示Web Server在整个Web架构系统中所处的重要位置:
如上图,Web Server起到了一个“承上启下”的作用(虽然并没有“上下”之分),它负责连接用户和Web站点。
我们可以看到,Web Server默认情况下需要与Web开发者编写的Web网站程序“通信”(图中假设三个网站均在一个Web Server上),那么这里怎么处理呢?实时上,任何Web开发者在使用某个平台开发Web程序时,必须遵守某些“规则”,比如使用到某些框架等。遵守了这些规则,开发出来的网站就可以放到Web Server上,这是不是有点像“程序扩展”的意思?
Web Server与Web网站程序的交互
每个网站就像一个个“插件”,只要网站开发过程中遵循了Web Server提出的规则,那么该网站就可以“插”在Web Server上,我们便可以通过浏览器访问网站。
理论上讲,每个Web Server均是一个宿主,而每个网站均是一个插件(plug-in)。Web Server主要负责通讯等功能,网站程序主要负责数据处理。
至于“宿主”怎样与“插件”通信,请参见博主前面的一篇文章“应用程序扩展”。
由于每个Web Server均能持续接收HTTP请求,因此每个Web Server中均应该存在一个类似下图所示的循环结构:
如上图,为了提高Web Server接收HTTP请求的效率,图中虚线框一般采用异步处理,请求处理过程不会影响整个循环。
HTTPListener与Socket两种方式的差异
事实上,HTTP协议是应用层协议。数据在传输层上依然是采用TCP进行传输的,因此,自己动手采用Socket方式完全能够模拟出Web Server的工作过程(正如文章开头讲到的)。博主前面有一篇博客讲述“使用Socket请求Web Server”,其实就是使用Socket来模拟浏览器的通讯行为。在.NET中的System.Net命名空间中,包含一些更高层次、更抽象的类型也可以完成对浏览器的模拟,如System.Net.HTTPWebRequest和System.Net.HTTPWebResponse等类型,至于它们和直接使用Socket有什么区别,请参见下表:
分类 |
Web Server端 |
浏览器端 |
优点 |
缺点 |
Socket方式 |
Socket.Accept: 负责接收浏览器端的Socket连接请求
Socket.Receive: 负责接收浏览器发送的数据
Socket.Send: 负责向浏览器发送数据 |
Socket.Connect: 负责向Web Server发送连接请求
Socket.Receive: 负责接收Web Server发来的回复
Socket.Send: 负责向Web Server发送请求 |
更底层,灵活性更强 |
更底层,需要充分了解HTTP协议、TCP/IP协议 |
System.Net命名空间中的类型 |
HTTPListener.GetContext: 负责接收浏览器端的HTTP请求
HTTPListenerRequest: 该类负责接收浏览器端的请求(Request)数据
HTTPListenerResponse: 该类负责向浏览器发送回复(Response)数据 |
HTTPWebRequest: 该类负责向Web Server发送HTTP请求
HTTPWebResponse: 该类负责接收来自Web Server发来的回复 |
更高层级别的抽象,不需要过多的了解HTTP、TCP等通讯知识 |
更抽象,用法固定(不过需要的都已经包含) |
可以看到,以上两种方式最终达到的效果其实是一样的。
注:请区分HTTPWebRequest与Asp.NET中的HTTPRequest。后者只能用在Asp.NET中,属于Asp.NET中的核心对象。同理请区分HTTPWebResponse与Asp.NET中的HTTPResponse。它们的命名空间分别为:System.NET和System.Web。
附带Demo源码概述
源码包含三个项目,分别为:
- HTTPServer:模拟的一个Web Server(不足70行代码)
- HTTPUtility:一个抽象层,专门为了Web Server与网站程序之间的交互。这里充分应用了“依赖倒置原则(DIP)”,目的就是降低Web Server与网站程序之间的耦合度。
- MyWebsite:一个(模拟的)网站程序,需要依赖HTTPUtility。
如果将Demo中的三块与现实一一类比,那么HTTPServer便是IIS/Apache,HTTPUtility便是我们开发Web程序时需要使用到的框架/原则,MyWebsite便是我们开发出来的Web网站程序。
将编译之后的MyWebsite项目DLL文件拷贝到HTTPServer可执行程序同一目录下的web文件夹中即可(类似一个网站发布的过程)。打开HTTPServer.exe文件运行,即可在浏览器中访问MyWebsite网站。
源码中注释比较详细,在此就不多说源码的事情。
Demo效果截图
总结
两种方式实现的过程、代码结构均类似。主要掌握两点:
- Web Server中的循环结构(泵),负责持续接收请求
- Web Server与网站程序(Plug-in)之间的交互
作为一个Web开发者,了解这些几乎用不到的知识也是必需的。
源码下载:http://files.cnblogs.com/xiaozhi_5638/HTTP_Web_Server.rar
转发请保留原文链接地址。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。