自己动手创建一个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 ServerWeb架构系统中的作用

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 ServerWeb网站程序的交互

每个网站就像一个个“插件”,只要网站开发过程中遵循了Web Server提出的规则,那么该网站就可以“插”在Web Server上,我们便可以通过浏览器访问网站。

理论上讲,每个Web Server均是一个宿主,而每个网站均是一个插件(plug-in)。Web Server主要负责通讯等功能,网站程序主要负责数据处理。

至于“宿主”怎样与“插件”通信,请参见博主前面的一篇文章“应用程序扩展”。

由于每个Web Server均能持续接收HTTP请求,因此每个Web Server中均应该存在一个类似下图所示的循环结构:

如上图,为了提高Web Server接收HTTP请求的效率,图中虚线框一般采用异步处理,请求处理过程不会影响整个循环。

 

HTTPListenerSocket两种方式的差异

事实上,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

转发请保留原文链接地址。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。