其实普通web应用，实际上就是对http的应用，http是一种基于TCP协议的网络传输协议，工作在应用层，作为web开发者，我主要从http的角度来看待这个问题：
- 首先，对于http肯定是有客户端和服务器的，在这个语境中，客户端和服务器本质上也都是一个软件，实现了http协议相关标准的软件。
- 客户端一般由都是由浏览器充当，也就是说，在浏览器中实现了http客户端的相关功能。
- 而服务器的实现就多种多样啦，我们可以用java写servlet，c#写ASP.net,还有php，ruby，Python，nodejs等。
实际上我想，http服务在操作系统底层应该有实现，而这些语言只不过是利用操作系统的http服务封装成自己的接口供开发人员编写web服务器程序。
而我们熟悉的IIS，Tomcat，Apache，Web logic，都是能够作为某些web服务器容器的大型服务器平台，它们都会包括很多更为强大的功能。一般来说，我们这里所说的服务器指的是自己用特定语言写的web应用服务器程序。nodejs不需要web容器，本身就有对http的直接应用模块，所以用nodejs创建一个web服务器是很方便的。
整体通信
有了客户端和服务器，就可以开始通信了，整体上分为3个步骤：
1. 因为http是构建在TCP之上，那么自然是要经过3次握手创建连接。
2. 创建连接后，服务器会根据url请求中的信息进行处理，作出响应，一般来说是找到一个html文件返回给客户端。
3. 客户端即浏览器得到html，进行渲染。
下面详细说下这3个步骤：
创建连接
这个跟网络关联多一些，我网络学的马马虎虎，只能大体说一下。
- 对于http的客户端，它的输入就是一个url，
- 而对于创建连接，它需要的只是url的host（主机）部分，
- 而主机地址一般是网站的域名，所以第一步肯定是域名解析，也就是要通过DNS服务器进行域名解析得到网站的ip地址，然后向这个ip地址发送一个连接建立的请求，如果服务器接收到请求会返回一个确认，客户端得到确认再次发送确认，连接建立成功。
当然在这个过程中还会涉及到很多细节，这是网络中的知识，在这里不多讲。
服务器处理
建立好连接后，客户端就会发送http请求，请求信息包含一个头部和一个请求体，
一般的web技术都会把请求进行封装然后交给我们的服务器进行处理，比如servlet会把请求封装成httpservletrequest对象，把响应封装成httpsevletresponse对象。nodejs的http模块，当你创建服务器的时候会写一个回调函数，回调的参数用来接受http请求对象和响应对象，然后在回调函数中对请求进行处理。
在请求对象中我们可以得到path（路径），queryString（查询字符串），body（post请求中提交的数据）等。
对请求的处理就可以很复杂，也可以很简单。
我们可以根据path找到客户端想要的文件，读取这个文件，然后通过响应对象把内容返回给客户端，这个过程，不同的技术提供的api可能不同，尤其是用惯了MVC框架的人，可能只是指定一个文件，或者在配置文件中设置一下就好了。
但是最终的实现肯定是符合http响应标准的，也就是要有一个响应头和一个响应体。
我一般接触到的设置响应头就是设置content-type来决定MIME类型，设置Cache-Control，last-modify等缓存内容。
一般来说返回给客户端的内容是一个html字符串，然后content-type设为text/html。
当然也可能客户端请求的是一个image文件，那么就是读取image文件后，content-type可能设为image/png,image/jpg等,然后把内容返回给客户端。
这样一次对请求的处理就结束了。
当然这个过程太单一，而且处理过程也可能很复杂，又有数据的操作，又有页面的构建，又有路径的查找匹配，又有文件的读取等等，于是就出现了MVC框架以及后来演变出的各种MV框架。这里不细讲MVC的内容，因为需要很长的篇幅。
只是概述一下MVC主要做了什么，在我看来最重要的就是解耦和模块化。我认为MVC实现最重要的有两点：
1.路由匹配，http请求的path中就不需要指定到具体的视图位置，而是按照我们制定的规则进行匹配，这样就有了很大的灵活性，可编程性。
2.模板技术，一般来说我们最后返回给客户端的是一个html字符串，而有时候这个字符串往往不是静态单一的，有的时候需要和数据进行结合，需要拼接。这就带来了很大的麻烦，模板技术为解决这个问题带来很大的便利性，同时又能够把视图和数据进行解耦。
客户端渲染
客户端接收到服务器传来的响应对象，从中得到html字符串和MIME，根据MIME知道了要用页面渲染引擎来处理内容即html字符串，于是进入页面渲染阶段，这又是一个很庞杂的体系。我只能大体上说一下：
从浏览器的角度讲，它包含几大组件，网络功能（比如http的实现）算是其中之一，渲染引擎也是其中之一，还有其它的一些比如自己UI界面，javascript解释器，客户端数据存储等等。在这里我们主要关注渲染引擎和javascript解释器，对于web开发者来说，这才是浏览器的核心。
我们能够在浏览器中看到一个页面，那么这个页面是怎么出现的呢？实际上就是调用底层绘图API给画出来的。不同的渲染引擎，它的实现也不同，主流的引擎包括IE的Trident，chrome和safary的webkit，firefox的Gecko，chrome又出了一个Blink，放弃webkit。于是乎才有了让人头疼的各种兼容性问题。
整体上页面渲染的过程大致是这样的：
渲染引擎得到html字符串作为输入，然后对html进行转换，转化成能够被DOM处理的形式，接着转换成一个dom树，在解析html的过程，解析到<link>,<script>,<img>等一些请求标签时，会发送请求把对应的内容获取到。这时又会同步进行css的解析，构建出css样式规则应用到dom树上，然后进行一定的布局处理，比如标记节点块在浏览器中的坐标等形成最终的渲染树，最后根据这棵渲染树在浏览器窗口中进行绘制。
最终我们就看到了页面的样子。
当然在页面渲染过程中还会同步进行javascript的解析，而且这两者是在同一个线程中的，所以一旦javascript死循环，页面的渲染也就进行不下去了。
以上是我从一个web开发者的角度思考的整个过程。如果从别的角度更细化的去想，还包括许多内容：
比如整个网络通信中协议的封装：
在本机中，把要传输的内容即请求对象在应用层上加上App首部，传递到传输层加上TCP首部，到网络层加上IP首部，数据链路层加上以太网的首部和尾部，然后转换成bit流进入网络环境中。到达主机后在一层层解封装，最后把内容交给服务器程序。
再比如这个过程中的认证，加密，安全，编码等问题都会有一定的处理，不过这些内容我就不是很了解。
