网页访问的幕后工作

àì夳堔傛蜴生んèń 2022-06-18 08:55 153阅读 0赞

一、在浏览器输入：baidu.com，最后，浏览器呈现出相应网页，这个过程究竟发生了什么？  
  
第一步，解析域名，找到主机IP  
（1）浏览器会缓存DNS一段时间，一般2-30分钟不等。如果有缓存，直接返回IP，否则下一步。  
（2）缓存中无法找到IP，浏览器会进行一个系统调用，查询hosts文件。如果找到，直接返回IP，否则下一步。（在计算机本地目录etc下有一个hosts文件，hosts文件中保存有域名与IP的对应解析，通常也可以修改hosts科学上网或破解软件。）  
（3）进行了（1）（2）本地查询无果，只能借助于网络。路由器一般都会有自己的DNS缓存，ISP服务商DNS缓存，这时一般都能够得到相应的IP。如果还是无果，只能借助于DNS递归解析了。  
（4）这时，ISP的DNS服务器就会开始从根域名服务器开始递归搜索，从.com顶级域名服务器，到baidu的域名服务器。  
DNS有一点令人担忧，这就是像wikipedia.org 或者 baidu.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：  
（1）循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说，Facebook.com实际上就对应了四个IP地址。  
（2）负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。  
（3）地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。  
到这里，浏览器就获得了IP。在DNS解析过程中，常常会解析出不同的IP。比如，电信的是一个IP，网通的是另一个IP。这是采取了智能DNS的结果，降低运营商间访问延时，在多个运营商设置主机房，就近访问主机。电信用户返回电信主机IP，网通用户返回网通主机IP。当然，劫持DNS，也可以屏蔽掉一部分网点的访问。  
  
第二部，浏览器与网站建立TCP连接  
浏览器利用IP直接与网站主机通信。浏览器发出TCP（SYN标志位为1）连接请求，主机返回TCP（SYN，ACK标志位均为1）应答报文，浏览器收到应答报文发现ACK标志位为1，表示连接请求确认。浏览器返回TCP（ACK标志位为1）确认报文，主机收到确认报文，三次握手，TCP链接建立完成。  
  
第三部分，浏览器发起GET请求

GET http://baidu.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: baidu.com
     Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL，也就是http://www.baidu.com/ ，还有User-Agent用户浏览器操作系统信息，编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip，压缩之后传输html文件。Cookies如果是首次访问，会提示服务器建立用户缓存信息，如果不是，可以利用Cookies对应键值，找到相应缓存，缓存里面存放着用户名，密码和一些用户设置项。  
像“http://www.baidu.com/”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http: //example.com/folderOrFile”这样的地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手。  
  
  
第四部分，baidu服务的永久重定向响应

HTTP/1.1 301 Moved Permanently
     Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
     pre-check=0
     Expires: Sat, 01 Jan 2000 00:00:00 GMT
     Location: http://www.baidu.com/
     P3P: CP="DSP LAW"
     Pragma: no-cache
     Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
     path=/; domain=.facebook.com; httponly
     Content-Type: text/html; charset=utf-8
     X-Cnection: close
     Date: Fri, 12 Feb 2010 05:09:51 GMT
     Content-Length: 0

服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.baidu.com/” 而非“http://baidu.com/”。  
为什么服务器一定要重定向而不是直接发给用户想看的网页内容呢？这个问题有好多有意思的答案。  
其中一个原因跟搜索引擎排名有关。如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。  
还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。  
  
第五部分，浏览器跟踪重定向地址  
现在，浏览器知道了“http://www.baidu.com/”才是要访问的正确地址，所以它会发送另一个获取请求：

GET http://www.baidu.com/ HTTP/1.1
     Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
     Accept-Language: en-US
     User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
     Accept-Encoding: gzip, deflate
     Connection: Keep-Alive
     Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
     Host: www.baidu.com

头信息以之前请求中的意义相同。  
  
第六部分，服务器“处理”请求  
服务器接收到获取请求，然后处理并返回一个响应。这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西。  
（1）Web 服务器软件  
web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序（像ASP.NET,PHP,RUBY...）。  
举个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件可以设置成为地址人工的对应请求处理，这样 page1.aspx的发布地址就可以是http://example.com/folder1/page1。  
（2）请求处理  
请求处理会接受请求及它的参数和cookies。它会读取也可能更新一些数据，并将数据存储在服务器上。然后，需求处理会生成一个HTML响应。  
所有动态网站都面临一个难点：如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案有：sharding（基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库等解决方案。  
  
第七部分，显示页面或返回其他  
返回状态码200 OK，表示服务器可以相应请求，返回报文，由于在报头中Content-type为“text/html”，浏览器以HTML形式呈现，而不是下载文件。  
但是，对于大型网站存在多个主机站点，往往不会直接返回请求页面，而是重定向。返回的状态码就不是200，而是301,302以3开头的重定向码，浏览器在获取了重定向响应后，在响应报文中Location项找到重定向地址，浏览器重新第一步访问即可。  
补充一点的就是，重定向是为了负载均衡或者导入流量，提高SEO排名。利用一个前端服务器接受请求，然后负载到不同的主机上，可以大大提高站点的业务并发处理能力；重定向也可将多个域名的访问，集中到一个站点；由于baidu.com，www.baidu.com会被搜索引擎认为是两个网站，造成每个的链接数都会减少从而降低排名，永久重定向会将两个地址关联起来，搜索引擎会认为是同一个网站，从而提高排名。  
  
二、我们在淘宝上买东西时发生了什么？（节选自<淘宝技术这十年>）  
你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了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多台服务器组成的超大规模数据系统不断的进行分析和挖掘。  
  
从这些数据中淘宝能够知道小到你是谁，你喜欢什么，你的孩子几岁了，你是否在谈恋爱，喜欢玩魔兽世界的人喜欢什么样的饮料等，大到各行各业的零售情况、各类商品的兴衰消亡等等海量的信息。