web应用开发浅聊--从tcp到mvc

毕业到现在，在web开发这条路上，算起来也是走了三年多了。

自己主要是做.net/c# 方向的web开发，一值以来，磕磕碰碰，在不断的挖坑填坑中成长。在web程序开发这件事上，有自己的感悟和理解。

 

在我们学习web应用原理时，大部分的文章或者老师都会提到说，web请求基于 http通讯，浏览器向服务端发起请求，然后服务端响应数据，好一点的老师会通过 tcp 响应demo跟浏览器交互，模拟响应。接着老师就会给我们讲使用XXXweb框架来创建应用。至此，我们创建应用时，只需要套用某个框架，然后按照框架的规范来调用就好了。这其实是没有问题的。

但是在工作期间，就会遇到一些来自朋友的问题：

1.说是做过 webform/mvc，但是不知道怎么写webapi，也不懂怎么通过后台代码去调用 webapi

2.文件下载要构造文件路径地址，不会通过流数据返回

3.觉得 java 和 c# 开发web程序是很不一样的

4.说到爬虫框架就推荐使用 python

...

然而实际上，哪那么多事，只不过是不同语言的不同用法实现以及框架丰富易用程度而已，原理上没什么区别。会出现这样的问题，大多是因为知道某些框架的使用，但没有真正去深究其原理。

这个原理不说深的（再深一点，底层都最后转为二进制，这个就没意思了），也就是 http协议。

那这个http在web框架中是怎么处理的呢？

在这里我们就简单的聊聊web开发的“原理”，聊聊我们的web框架是怎么回事。而在这个讲述过程将尽量的讲内容讲的简单，直白。

1.socket

socket或者说套接字，如果有做过通讯相关应用的朋友应该不会默认，但如果没做的朋友呢，这个是什么呢？

简单的理解socket是应用层提供通讯的“底层”服务。

也就是说应用层的协议都是建立在在socket的基础上。而socket通讯分为 tcp和udp,具体 tcp和udp的区别需要自行了解了。

而http 则是基于 tcp通讯

2.http

那 http协议到底是个什么东西呢？

要详细说清楚http，一两段也是说不清，但是我们可以来说下“协议”是个什么东西。

协议：一种格式规范。

对我们来说，直观的说，就是“有固定格式的字符串”。就我们所能看到的，确实就是字符串。比如说下面的报文：

 

POST /test/test3/idddddd?p=test2ppppppppppp HTTP/1.1
Host: 127.0.0.1:8885
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: 46d812fe-a996-4381-9b35-4a4f631b2eb7

b=truea=123456

 

这时候，解析协议内容就可以认为是解析字符串，怎么解析呢？当然是按照“协议”规范了。

至此，先有这个解析的概念，后面会用到。

 

3.常规web开发和部署

通常我们开发web程序的过程是这样的：

a.创建web项目

b.引入web框架。像 .net 的 system.web/system.web.mvc，或者说 java 的spring mvc

c.基于框架进行业务逻辑的编码

d.发布部署。比如.net web程序部署到iis，而 java web部署到 tomcat或者apache，而这个部署操作通常是将发布后的代码放到指定目录或者放到自定义目录后，再配置程序路径，然后指定端口。

 

那么，这几步中，system.web.mvc/spring mvc，和 iis/tomcat 分别扮演着什么样的角色呢？

通常，

a.iis/tomcat/apache 这类程序在启动web程序时会根据配置找到程序所在目录。

b.找到程序的启动程序并载入。这个启动程序是怎么回事呢？我们在设计和使用框架时估计都会听到这样一句话“约定大于配置”，通常web框架会根据约定好启动入口，而服务程序只需要找到约定好的入口程序并调用即可，而这个调用，对于java和c#，我们可以通过反射来调用这个启动程序（很多语言都会有反射）。

c.根据配置的端口启动相应的 tcp端口来监听，同时将web程序跟端口绑定。

这样，当某个端口收到请求时，将调用绑定的web程序来处理请求。

 

4.web框架

通常我们开发web程序时我们只需要编写我们的业务代码，无需关心框架时如何解析http报文。而我们通常会通过 请求上下文 httpcontext（不同语言不同web框架命名不同） 获取到请求信息request或者返回响应信息response。

那这个 httpcontext 是怎么来的呢？

其实，这些都是我们所引入的web框架帮我们处理好的。

在我们的编写业务代码处理之前，tcp服务接到的请求数据先通过web框架进行加工。怎么加工呢？

开篇我们提到了 http协议的解析，没错了，web框架先将接收到的请求报文按照http协议进行解析，然后将这些解析得到的内容打包成 request对象，我们在开发中需要获取请求的信息时，我们直接直接通过request对象获取即可。

而对于response，则是用来保存我们开发中要返回的数据，也是按照http协议进行封装。当我们的业务代码处理完之后，框架就从response对象中将信息重新拼接起来，成为响应的http报文，然后通过 tcp服务程序响应到浏览器。

比如 .net 中的 system.web/system.http 或者是 java 的 servlet 

5.session

在web应用中，我们多少都会设计到session，特别是用来保存用户状态，那这个session是怎么回事，为什么它能保存不同用户的状态呢？

其实这个session就是个缓存cache，之所以能够保存不同的用户状态，是因为，当浏览器第一次请求应用时，框架自动给响应加上cookie：sessionid，之后每次请求进来时，都会带上这个sessionid，如果将sessionid作为cache的固定前缀,那么每个浏览器所保存的状态就可以区分开（当然还有其它方式）。

6.mvc框架

mvc框架通常是基于语言的原生web框架进一步封装，以便提高开发效率。

mvc框架通过引入控制器，将业务行为跟视图分离，除了简化开发，结构上可读性更高。

前面说mvc基于语言原生web框架开发，那么mvc是对哪个部分进行扩展了呢？

是response！

基于传统（原生）的web框架我们经常会在写入响应数据时调用请求上下文httpcontext的response对象，然后往response上赋值，而到了mvc，我们的action通常返回一个对象，即我们期望返回的结果，mvc框架再自动将我们的结果写入response，使得我们的代码能够专注于业务并且简化重复代码（无需重复的调用response写入，交给了框架）

同时引入了mvc后，我们的程序将提供一个统一的入口，这样对于我们进行aop编程提供极大的便利，轻松实现各种过滤器。

 

至此，这篇文章主要的内容差不多就完了。感觉讲了很多，但又感觉讲的不清不楚，对于我们开发来说，如果有代码参考的话，那是极好的了。实际上自己好早之前就想整一个demo,然后整一个系列详细的讲，但是工作比较忙，下班后也没多余的精力，所以不确定能否搞好一个系列。而自己倒是按照自己文章所说的，将这个过程通过程序直白的实现，抛开各种细节问题，基本实现了一套从服务程序到web mvc 的demo，有兴趣的朋友可以前往 github:

https://github.com/mengtoumingren/webframework

简单说下项目结构

项目	描述
AebApp	app,即基于webclient开发的程序（应当于引入web框架）
WebClient	相当web框架的实现，引入中间件，同时实现了mvc中间件
WebClientSDK	作为接口约束web程序，作为请求处理入口（web程序实现该接口才能被服务程序发现和载入）
WevServer	服务程序，可配置程序路径和端口，启动时自动载入程序，收到请求调用相应的服务，充当iis/tomcat