浏览器抓取网页(4.facebook服务的永久重定向响应的难点-如何存储数据 )

　　浏览器抓取网页(4.facebook服务的永久重定向响应的难点-如何存储数据

)

　　除了get请求之外，还有一个send请求，常用于提交表单。发送通过 URL 传递其参数的请求

　　(e.g.: RoboZZle stats for puzzle 85)

　　. 发送请求在请求正文标头之后发送其参数。

　　图片

　　“http://facebook.com/”

　　斜线很关键。在这种情况下，浏览器可以安全地添加斜杠。和喜欢

　　“http: //example.com/folderOrFile”

　　这样的地址不能自动加斜杠，因为浏览器不知道folderOrFile是文件夹还是文件。这时候浏览器直接访问不带斜线的地址，服务器响应重定向，导致不必要的握手。

　　4. 来自 facebook 服务的永久重定向响应

　　

　　图为 Facebook 服务器返回给浏览器的响应：

　　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.facebook.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.facebook.com/

　　“ 而不是

　　“http://facebook.com/”

　　.

　　为什么服务器要重定向而不是直接发送用户想看的网页内容？这个问题有很多有趣的答案。

　　原因之一与搜索引擎排名有关。你看，如果一个页面有两个地址，比如

　　http://www.igoro.com/ 和http://igoro.com/

　　，搜索引擎会认为它们是两个网站，导致每个搜索链接较少，排名较低。并且搜索引擎知道 301 永久重定向的含义，因此它们会将访问带有和不带有 www 的地址分配到相同的 网站 排名。

　　另一个是使用不同的地址会导致缓存友好性差。当一个页面有多个名称时，它可能会多次出现在缓存中。

　　5. 浏览器跟踪重定向地址

　　

　　现在，浏览器知道

　　“http://www.facebook.com/”

　　是要访问的正确地址，因此它会发送另一个 get 请求：

　　GET http://www.facebook.com/ HTTP/1.1

 Accept: application/x-ms-application, p_w_picpath/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: *敏*感*词*=XW[...]; c_user=21[...]; x-referer=[...]

 Host: www.facebook.com

　　标头信息与前一个请求中的含义相同。

　　6. 服务器“处理”请求

　　

　　服务器接收到 get 请求，对其进行处理，然后返回响应。

　　表面上看，这似乎是一个定向任务，但实际上中间发生了很多有趣的事情——简单的网站如作者的博客，更不用说访问量大的网站如facebook ！

　　所有动态的网站 都面临一个有趣的难题——如何存储数据。小型 网站 一半将有一个 SQL 数据库来存储数据，而 网站 拥有大量数据和/或大量访问将不得不找到某种方法将数据库分布在多台机器上。解决方案包括：分片（根据主键值将数据表分散到多个数据库中）、复制、使用弱语义一致性的简化数据库。

　　将工作委派给批处理是一种保持数据更新的廉价技术。例如，Facebook 需要及时更新其新闻提要，但数据支持的“你可能认识的人”功能只需要每晚更新一次（作者猜测是这样，如何改进功能是未知）。批量作业更新会导致一些不太重要的数据变得陈旧，但会使数据更新农业更快、更清洁。

　　7. 服务器发回一个 HTML 响应

　　

　　下图展示了服务器生成并返回的响应：

　　HTTP/1.1 200 OK

 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,

 pre-check=0

 Expires: Sat, 01 Jan 2000 00:00:00 GMT

 P3P: CP="DSP LAW"

 Pragma: no-cache

 Content-Encoding: gzip

 Content-Type: text/html; charset=utf-8

 X-Cnection: close

 Transfer-Encoding: chunked

 Date: Fri, 12 Feb 2010 09:05:55 GMT

 2b3Tn@[...]

　　整个响应大小为 35kB，其中大部分在排序后以 blob 形式传输。

　　Content-Encoding 标头告诉浏览器使用 gzip 算法压缩整个响应正文。解压 blob 块后，您可以看到预期的 HTML，如下所示：

　　

 

 

 

 

 ...

　　关于压缩，header信息表示是否缓存页面，如果缓存了怎么做，设置什么cookies（没有在之前的响应中）和隐私信息等。

　　请注意，标头中的 Content-type 设置为“text/html”。标头告诉浏览器将响应内容呈现为 HTML，而不是将其下载为文件。浏览器根据标头信息决定如何解释响应，但也会考虑其他因素，例如 URL 扩展的内容。

　　8. 浏览器开始显示 HTML

　　在浏览器完全接受整个 HTML 文档之前，它已经开始显示这个页面：

　　

　　9. 浏览器发送以获取嵌入在 HTML 中的对象

　　

　　当浏览器显示 HTML 时，它会注意到需要获取其他地址内容的标签。此时，浏览器将发送获取请求以检索文件。

　　以下是我们在访问时需要重新获取的一些 URL：

　　这些地址会经历类似于 HTML 读取的过程。所以浏览器会在 DNS 中查找这些域，发送请求，重定向等……

　　但与动态页面不同的是，静态文件允许浏览器缓存它们。有些文件可能不需要与服务器通信，而是直接从缓存中读取。服务器的响应包括有关静态文件保留多长时间的信息，因此浏览器知道将它们缓存多长时间。此外，每个响应可能收录一个 ETag 标头（请求变量的实体值），其作用类似于版本号，如果浏览器观察到文件的版本 ETag 信息已经存在，它会立即停止文件的传输。

　　猜猜地址中的“”代表什么？聪明的答案是“Facebook 内容交付网络”。Facebook 利用内容分发网络 (CDN) 分发静态文件，如图像、CSS 表格和 JavaScript 文件。因此，这些文件将备份在全球许多 CDN 的数据中心中。

　　静态内容通常代表网站的带宽，也可以通过 CDN 轻松复制。通常网站使用第三方CDN。例如，Facebook 的静态文件由最大的 CDN 提供商 Akamai 托管。

　　例如，当您尝试时，您可能会从某个服务器获得响应。有趣的是，当你再次 ping 相同时，响应的服务器可能不同，这表明后台的负载均衡正在工作。

　　10. 浏览器发送异步（AJAX）请求

　　

　　在Web2.0伟大精神的指引下，页面显示后客户端仍然与服务器保持联系。

　　以 Facebook 聊天功能为例，它与服务器保持联系以更新您的亮灰色朋友的状态。为了更新这些头像的好友状态，在浏览器中执行的 JavaScript 代码会向服务器发送一个异步请求。这个异步请求被发送到一个特定的地址，它是一个以编程方式构造的get或send请求。仍然在 Facebook 示例中，客户端发送

　　http://www.facebook.com/ajax/chat/buddy_list.php

　　获取有关您的哪些朋友在线的状态信息的发布请求。

　　说到这种模式，就不得不说“AJAX”——“异步 JavaScript 和 XML”，虽然服务器以 XML 格式响应并没有明确的原因。再举一个例子，对于异步请求，Facebook 将返回一些 JavaScript 片段。

　　除其他外，fiddler 是一种工具，可让您查看浏览器发送的异步请求。实际上，您不仅可以被动地观看这些请求，还可以主动修改并重新发送它们。对于得分的网络游戏开发者来说，如此容易被AJAX请求所欺骗，真是令人沮丧。（当然，不要这样骗人~）

　　Facebook 聊天功能提供了一个有趣的 AJAX 问题示例：将数据从服务器推送到客户端。由于 HTTP 是一种请求-响应协议，聊天服务器无法向客户端发送新消息。相反，客户端必须每隔几秒钟轮询一次服务器以查看它是否有新消息。

　　当这些情况发生时，长轮询是一种减少服务器负载的有趣技术。如果服务器在轮询时没有新消息，它会忽略客户端。当超时前收到来自客户端的新消息时，服务器会找到未完成的请求，并将新消息作为响应返回给客户端。

　　综上所述

　　希望看完这篇文章，你可以了解不同的网络模块是如何协同工作的

　　引用的部分内容

　　http://blog.jobbole.com/33951/