目录

• 介绍
• Web Server在Web架构系统中的作用
• Web Server与Web网站程序的交互
• HTTPListener与Socket两种方式的差异
• 附带Demo源码概述
• Demo效果截图
• 总结

 

介绍

本篇文章主要介绍使用HTTPListener类型自己动手创建一个Web Server，创建的Web Server能够接收来自浏览器端的HTTP请求，并且能够传递给对应的Web站点进行处理，最后将处理结果（Html或者其他格式）返回给浏览器。

博主前面曾经介绍过使用Socket模拟Web Server的运行过程、Socket模拟浏览器发送HTTP请求过程。分别参见：

• socket请求Web服务器过程
• Socket实现简单Web服务器

本篇文章并没有使用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

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