C#中自己动手创建一个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开发者，了解这些几乎用不到的知识也是必需的。
源码下载：https://files.cnblogs.com/xiaozhi_5638/HTTP_Web_Server.rar
转发请保留原文链接地址。
