首先，对于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个步骤：
- 因为http是构建在TCP之上，那么自然是要经过3次握手创建连接。
- 创建连接后，服务器会根据url请求中的信息进行处理，作出响应，一般来说是找到一个html文件返回给客户端。
- 客户端即浏览器得到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实现最重要的有两点：
- 路由匹配，http请求的path中就不需要指定到具体的视图位置，而是按照我们制定的规则进行匹配，这样就有了很大的灵活性，可编程性。
- 模板技术，一般来说我们最后返回给客户端的是一个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流进入网络环境中。到达主机后在一层层解封装，最后把内容交给服务器程序。
再比如这个过程中的认证，加密，安全，编码等问题都会有一定的处理，不过这些内容我就不是很了解。
从数据传输的角度：
第一步：在浏览器中输入地址
第二步：浏览器查找域名的Ip地址---DNS查找
浏览器缓存--由浏览器自己决定，而不是操作系统决定
系统缓存--系统调用，查看系统缓存的记录
路由器缓存
ISP DNS缓存--如果还找不到就递归，知道顶级域名服务器
第三步：浏览器给Web服务器发送HTTP请求
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]GET 这个请求定义了要读取的URL： “http://facebook.com/”。 浏览器自身定义 (User-Agent 头)， 和它希望接受什么类型的相应 (Accept andAccept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP连接。
请求中也包含浏览器存储的该域名的cookies。可能你已经知道，在不同页面请求当中，cookies是与跟踪一个网站状态相匹配的键值。这样cookies会 存储登录用户名，服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里，每次请求时发送给服务器。
除了获取请求，还有一种是发送请求，它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送 请求在请求正文头之后发送其参数。
像“http://facebook.com/”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http: //example.com/folderOrFile”这样的 地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加 斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重 定向，结果造成一次不必要的握手。
第四步：facebook的永久重定向相应
服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。
为什么服务器一定要重定向而不是直接发会用户想看的网页内容呢？这个问题有好多有意思的答案。
其中一个原因跟搜索引擎排名有 关。你看，如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是 两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是 什么意思，这样就会把访问带www的和不带www的地址归 到同一个网站排名下
还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。
第五步：浏览器跟踪永久重定向地址
现在，浏览器知道了“http://www.facebook.com/”才是要访问的正确地址，所以它会发送另一个获取请求
第六步：服务器“处理请求”
服务器接收到获取请求，然后处理并返回一个响应。
这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西- 就像简单的网站，何况像facebook那样访问量大的网站呢！
Web 服务器软件
web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应 的程序（像ASP.NET,PHP,RUBY...）。
举个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地址会映射/httpdocs/folder 1/page1.aspx这个文件。web服务器软件可设置成为地址人工的对应请求处理这样page1.aspx的发布地址就可以是http://example.com/folder1/page1。
请求处理
请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。
所有动态网站都面临一个有意思的难点-如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办 法把数据库分配到多台机器上。解决方案 有：sharding （基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库。
第七步：服务器发回HTML响应
第八步：浏览器显示HTML
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了
第九步：浏览器发送获取嵌入在HTML中的对象
在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。
下面是几个我们访问facebook.com时需要重获取的几个URL：
图片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gifhttp://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式样表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等...
但不像动态页面那样，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取。服务器的响应中包含了静态文 件保存的期限信息，所以浏览器知道要把它们缓存多长时间。还有，每个响应都可能包含像版本号一样工作的ETag头（被请求变量的实体值），如果浏览 器观察到文件的版本 ETag信息已经存在，就马上停止这个文件的传输。
试着猜猜看“fbcdn.net”在地址中代表什么？聪明的答案是"Facebook内容分发网络"。Facebook利用内容分发网络（CDN）分发像图片，CSS表和Java Script文件这些静态文件。所以，这些文件会在全球很多CDN的数据中心中留下备份。
举例来讲，当你试着ping static.ak.fbcdn.net的时候，可能会从某个akamai.net服务器上获得响应。有意思的是，当你同样再ping一次的时候，响 应的服务器可能就不一样，这说明幕后的负载平衡开始起作用了
第十步：浏览器发送异步（AJAX）请求
在Web 2.0伟大精神的指引下，页面显示完成后客户端仍与服务器端保持着联系。
以 Facebook聊天功能为例，它会持续与服务器保持联系来及时更新你那些亮亮灰灰的好友状态。为了更新这些头像亮着的好友状态，在浏览器中执行 的JavaScript代码会给服务器发送异步请求。这个异步请求发送给特定的地址，它是一个按照程式构造的获取或发送请求。还是在Facebook这个例子中， 客户端发送给http://www.facebook.com/ajax/chat/buddy_list.php一个发布请求来获取你好友里哪个在线的状态信息。
提起这个模式，就必须要讲讲"AJAX"-- “异步JavaScript 和 XML”，虽然服务器为什么用XML格式来进行响应也没有个一清二白的原因。再举个例子 吧，对于异步请求，Facebook会返回一些JavaScript的代码片段
除了其他，fiddler这个工具能够让你看到浏览器发送的异步请求。事实上，你不仅可以被动的做为这些请求的看客，还能主动出击修改和重新发送它 们。AJAX请求这么容易被蒙，可着实让那些计分的在线游戏开发者们郁闷的了。
Facebook聊天功能提供了关于AJAX一个有意思的问题案例：把数据从服务器端推送到客户端。因为HTTP是一个请求-响应协议，所以聊天服务器不能把 新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。
这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息，它就不理这个客户端。而当尚未超时的情况下收到了 该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。
《你刚在淘宝上买了一件衣服---详细解析技术流程》
你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了www.taobao.com。这时你的浏览器首先查询DNS服务器，将www.taobao.com转换成ip地址。不过首先你会发现，你在不同的地区或者不同的网络（电信、联通、移动）的情况下，转换后的IP地址很可能是 不一样的，这首先涉及到负载均衡的第一步，通过DNS解析域名时将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个 (这和后文的CDN不一样)。
你通过这个入口成功的访问了www.taobao.com的实际的入口IP地址。这时你产生了一个PV，即Page View，页面访问。每日每个网站的总PV量是形容一个网站规模的重要指标。淘宝网全网在平日（非促销期间）的PV大概是16-25亿之间。同时作为一个独立的用户，你这次访问淘宝网的所有页面，均算作一个UV（Unique Visitor用户访问）。最近臭名昭著的12306.cn的日PV量最高峰在10亿左右，而UV量却远小于淘宝网十余倍，这其中的原因我相信大家都会知道。
因为同一时刻访问www.taobao.com的人数过于巨大，所以即便是生成淘宝首页页面的服务器，也不可能仅有一台。仅用于生成www.taobao.com首页的服务器就可能有成百上千台，那么你的一次访问时生成页面给你看的任务便会被分配给其中一台服务器完成。这个过程要保证公正、公平、平均（暨这成百上千台服务器每台负担的用户数要差不多），这一很复杂的过程是由几个系统配合完成，其中最关键的便是LVS(Linux Virtual Server)，世界上最流行的负载均衡系统之一，正是由目前在淘宝网供职的章文嵩博士开发的。
经过一系列复杂的逻辑运算和数据处理，用于这次给你看的淘宝网首页的HTML内容便生成成功了。对web前端稍微有点常识的童鞋都应该知道，下一步浏览器会去加载页面中用到的css、js、图片、脚本和资源文件。但是可能相对较少的同学才会知道，你的浏览器在同一个域名下并发加载的资源数量是有限制的，例如IE6-7是两个，IE8是6个，Chrome各版本不大一样，一般是4-6个。我刚刚看了一下，我访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在好多个域名下，变相的绕过浏览器的这个限制，同时也为下文的CDN工作做准备。
据不可靠消息，在双十一当天高峰，淘宝的访问流量最巅峰达到871GB/S。这个数字意味着需要178万个4Mb带宽的家庭宽带才能负担的起，也完全有能力拖垮一个中小城市的全部互联网带宽。那么显然，这些访问流量不可能集中在一起。并且大家都知道，不同地区不同网络（电信、联通等）之间互访会非常缓慢，但是你却发现很少发现淘宝网访问缓慢。这便是CDN(Content Delivery Network)，即内容分发网络的作用。淘宝在全国各地建立了数十上百个CDN节点，利用一些手段保证你访问的（这里主要指js、css、图片等）地方是离你最近的CDN节点，这样便保证了大流量分散在各地访问的加速节点上。
这便出现了一个问题，那就是假若一个卖家发布了一个新的宝贝，上传了几张新的宝贝图片，那么淘宝网如何保证全国各地的CDN节点中都会同步的存在这几张图 片供用户使用呢？这里边就涉及到了大量的内容分发与同步的相关技术。淘宝开发了分布式文件系统TFS(Taobao File System)来处理这类问题。
好了，这时你终于加载完了淘宝首页，那么你习惯性的在首页搜索框中输入了'毛衣'二字并敲回车，这时你又产生了一个PV，然后，淘宝网的主搜索系统便开始为你服务了。它首先对你输入的内容基于一个分词库进行分词操作。众所周知，英文是以词为单位的，词和词之间是靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子I am a student，用中文则为：“我是一个学生”。计算机可以很简单通过空格知道student是一个单词，但是不能很容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。我是一个学生，分词的结果是：我 是 一个 学生。
进行分词之后，还需要根据你输入的搜索词进行你的购物意图分析。用户进行搜索时常常有如下几类意图：（1）浏览型：没有明确的购物对象和意图，边看边买，用户比较随意和感性。Query例如：”2010年10大香水排行”，”2010年流行毛衣”， “zippo有多少种类？”；（2）查询型：有一定的购物意图，体现在对属性的要求上。Query例如：”适合老人用的手机”，”500元 手表”；（3）对比型：已经缩小了购物意图，具体到了某几个产品。Query例如：”诺基亚E71 E63″，”akg k450 px200″；（4）确定型：已经做了基本决定，重点考察某个对象。Query例如：”诺基亚N97″，”IBM T60″。通过对你的购物意图的分析，主搜索会呈现出完全不同的结果来。
之后的数个步骤后，主搜索系统便根据上述以及更多复杂的条件列出了搜索结果，这一切是由一千多台搜索服务器完成。然后你开始逐一点击浏览搜索出的宝贝。你开始查看宝贝详情页面。经常网购的亲们会发现，当你买过了一个宝贝之后，即便是商家多次修改了宝贝详情页，你仍然能够通过‘已买到的宝贝’查看当时的快照。这是为了防止商家对在商品详情中承诺过的东西赖账不认。那么显然，对于每年数十上百亿比交易的商品详情快照进行保存和快速调用不是一个简单的事情。这 其中又涉及到数套系统的共同协作，其中较为重要的是Tair，淘宝自行研发的分布式KV存储方案。
然后无论你是否真正进行了交易，你的这些访问行为便忠实的被系统记录下来，用于后续的业务逻辑和数据分析。这些记录中访问日志记录便是最重要的记录之一， 但是前边我们得知，这些访问是分布在各个地区很多不同的服务器上的，并且由于用户众多，这些日志记录都非常庞大，达到TB级别非常正常。那么为了快速及时 传输同步这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，交给后端系统进行计算报表等操作。
你的浏览数据、交易数据以及其它很多很多的数据记录均会被保留下来。使得淘宝存储的历史数据轻而易举的便达到了十数甚至更多个 PB(1PB=1024TB=1048576GB)。如此巨大的数据量经过淘宝系统1:120的极限压缩存储在淘宝的数据仓库中。并且通过一个叫做云梯的，由2000多台服务器组成的超大规模数据系统不断的进行分析和挖掘。
从这些数据中淘宝能够知道小到你是谁，你喜欢什么，你的孩子几岁了，你是否在谈恋爱，喜欢玩魔兽世界的人喜欢什么样的饮料等，大到各行各业的零售情况、各类商品的兴衰消亡等等海量的信息。
说了这么多，其实也只是叙述了淘宝上正在运行的成千上万个系统中的寥寥几个。即便是你仅仅访问一次淘宝的首页，所涉及到的技术和系统规模都是你完全无法想 象的，是淘宝2000多名顶级的工程师们的心血结晶，其中甚至包括长江学者、国家科学技术最高奖得主等众多大牛。同样，百度、腾讯等的业务系统也绝不比淘宝简单。你需要知道的是，你每天使用的互联网产品，看似简单易用，背后却凝聚着难以想象的智慧与劳动。