精华内容
下载资源
问答
  • 输入网址到浏览器渲染页面的过程

    千次阅读 2018-07-31 08:00:47
    1) 在客户端浏览器中输入网址URL。 2) 发送DNS(域名服务器)获得域名对应的WEB服务器的IP地址。 3) 客户端浏览器与WEB服务器建立TCP(传输控制协议)连接。 4) 客户端浏览器向对应IP地址的WEB服务器发送相应的...

    1) 在客户端浏览器中输入网址URL。

    2) 发送到DNS(域名服务器)获得域名对应的WEB服务器的IP地址。

    3) 客户端浏览器与WEB服务器建立TCP(传输控制协议)连接。

    4) 客户端浏览器向对应IP地址的WEB服务器发送相应的HTTP或HTTPS请求。

    5) WEB服务器响应请求,返回指定的URL数据或错误信息;如果设定重定向,则重定向到新的URL地址。

    6) 客户端浏览器下载数据,解析HTML源文件,解析的过程中实现对页面的排版,解析完成后,在浏览器中显示基础的页面。

    7) 分析页面中的超链接,显示在当前页面,重复以上过程直至没有超链接需要发送,完成页面的全部显示。

    1、输入地址

    当我们开始在浏览器中输入网址的时候,浏览器其实就已经在智能的匹配可能得 url 了,他会从历史记录,书签等地方,找到已经输入的字符串可能对应的 url,然后给出智能提示,让你可以补全url地址。对于 google的chrome 的浏览器,他甚至会直接从缓存中把网页展示出来,就是说,你还没有按下 enter,页面就出来了。

     

    2、浏览器查找域名的 IP 地址  

    1) 请求一旦发起,浏览器首先要做的事情就是解析这个域名,一般来说,浏览器会首先查看本地硬盘的 hosts 文件,看看其中有没有和这个域名对应的规则,如果有的话就直接使用 hosts 文件里面的 ip 地址。

    2) 如果在本地的 hosts 文件没有能够找到对应的 ip 地址,浏览器会发出一个 DNS请求到本地DNS服务器 。本地DNS服务器一般都是你的网络接入服务器商提供,比如中国电信,中国移动。

    3) 查询你输入的网址的DNS请求到达本地DNS服务器之后,本地DNS服务器会首先查询它的缓存记录,如果缓存中有此条记录,就可以直接返回结果,此过程是递归的方式进行查询。如果没有,本地DNS服务器还要向DNS根服务器进行查询。

    4) 根DNS服务器没有记录具体的域名和IP地址的对应关系,而是告诉本地DNS服务器,你可以到域服务器上去继续查询,并给出域服务器的地址。这种过程是迭代的过程。

    5) 本地DNS服务器继续向域服务器发出请求,在这个例子中,请求的对象是.com域服务器。.com域服务器收到请求之后,也不会直接返回域名和IP地址的对应关系,而是告诉本地DNS服务器,你的域名的解析服务器的地址。

    6) 最后,本地DNS服务器向域名的解析服务器发出请求,这时就能收到一个域名和IP地址对应关系,本地DNS服务器不仅要把IP地址返回给用户电脑,还要把这个对应关系保存在缓存中,以备下次别的用户查询时,可以直接返回结果,加快网络访问。

    知识扩展:

    1)什么是DNS?

    DNS(Domain Name System,域名系统),因特网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。通过主机名,最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析)。

    通俗的讲,我们更习惯于记住一个网站的名字,比如www.baidu.com,而不是记住它的ip地址,比如:167.23.10.2。而计算机更擅长记住网站的ip地址,而不是像www.baidu.com等链接。因为,DNS就相当于一个电话本,比如你要找www.baidu.com这个域名,那我翻一翻我的电话本,我就知道,哦,它的电话(ip)是167.23.10.2。

    2)DNS查询的两种方式:递归查询和迭代查询

    1、递归解析

     当局部DNS服务器自己不能回答客户机的DNS查询时,它就需要向其他DNS服务器进行查询。此时有两种方式,如图所示的是递归方式。局部DNS服务器自己负责向其他DNS服务器进行查询,一般是先向该域名的根域服务器查询,再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器,再由局部DNS服务器返回给客户端。

    2、迭代解析

    当局部DNS服务器自己不能回答客户机的DNS查询时,也可以通过迭代查询的方式进行解析,如图所示。局部DNS服务器不是自己向其他DNS服务器进行查询,而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序,客户端DNS程序再继续向这些DNS服务器进行查询,直到得到查询结果为止。也就是说,迭代解析只是帮你找到相关的服务器而已,而不会帮你去查。比如说:baidu.com的服务器ip地址在192.168.4.5这里,你自己去查吧,本人比较忙,只能帮你到这里了。

     

    3、浏览器向 web 服务器发送一个 HTTP 请求

    拿到域名对应的IP地址之后,浏览器会以一个随机端口(1024<端口<65535)向服务器的WEB程序(常用的有httpd,nginx等)80端口发起TCP的连接请求。这个连接请求到达服务器端后(这中间通过各种路由设备,局域网内除外),进入到网卡,然后是进入到内核的TCP/IP协议栈(用于识别该连接请求,解封包,一层一层的剥开),还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终到达WEB程序,最终建立了TCP/IP的连接。

    建立了TCP连接之后,发起一个http请求。一个典型的 http request header 一般需要包括请求的方法,例如 GET 或者 POST 等,不常用的还有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法,一般的浏览器只能发起 GET 或者 POST 请求。

     

    客户端向服务器发起http请求的时候,会有一些请求信息,请求信息包含三个部分:

    | 请求方法URI协议/版本

    | 请求头(Request Header)

    | 请求正文:

     

    下面是一个完整的HTTP请求例子:

    GET/sample.jsp

    HTTP/1.1   Accept:image/gif.image/jpeg,*/*   

    Accept-Language:zh-cn   

    Connection:Keep-Alive   

    Host:localhost   

    User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)   

    Accept-Encoding:gzip,deflate   

     

    username=jinqiao&password=1234

     注意:最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头。

    (1)请求的第一行是“方法URL议/版本”:GET/sample.jsp HTTP/1.1

    (2)请求头(Request Header)

    请求头包含许多有关的客户端环境和请求正文的有用信息。例如,请求头可以声明浏览器所用的语言,请求正文的长度等。

    Accept:image/gif.image/jpeg.*/*   

    Accept-Language:zh-cn   

    Connection:Keep-Alive   

    Host:localhost   

    User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)   

    Accept-Encoding:gzip,deflate.

    (3)请求正文

    请求头和请求正文之间是一个空行,这个行非常重要,它表示请求头已经结束,接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息:

    username=jinqiao&password=1234

    知识扩展:

    1)TCP三次握手

     

    第一次握手:客户端A将标志位SYN置为1,随机产生一个值为seq=J(J的取值范围为=1234567)的数据包到服务器,客户端A进入SYN_SENT状态,等待服务端B确认;

     

    第二次握手:服务端B收到数据包后由标志位SYN=1知道客户端A请求建立连接,服务端B将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给客户端A以确认连接请求,服务端B进入SYN_RCVD状态。

     

    第三次握手:客户端A收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务端B,服务端B检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户端A和服务端B进入ESTABLISHED状态,完成三次握手,随后客户端A与服务端B之间可以开始传输数据了。

     

    2)TCP四次挥手

     

    第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。

     

    第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。

     

    第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。

     

    第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。

     

    3)为什么建立连接是三次握手,而关闭连接却是四次挥手呢?

     

    这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

     

    4、服务器的永久重定向响应

    服务器给浏览器响应一个301永久重定向响应,这样浏览器就会访问“http://www.google.com/” 而非“http://google.com/”。

     

    为什么服务器一定要重定向而不是直接发送用户想看的网页内容呢?其中一个原因跟搜索引擎排名有关。如果一个页面有两个地址,就像http://www.yy.com/和http://yy.com/,搜索引擎会认为它们是两个网站,结果造成每个搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思,这样就会把访问带www的和不带www的地址归到同一个网站排名下。还有就是用不同的地址会造成缓存友好性变差,当一个页面有好几个名字时,它可能会在缓存里出现好几次。

     

    扩展知识

     

    1)301和302的区别。

    301和302状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)——这是它们的共同点。

     

    301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;

     

    302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。 SEO302好于301

     

    2)重定向原因:

    (1)网站调整(如改变网页目录结构);

    (2)网页被移到一个新地址;

    (3)网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

    这种情况下,如果不做重定向,则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息,访问流量白白丧失;再者某些注册了多个域名的网站,也需要通过重定向让访问这些域名的用户自动跳转到主站点等。

     

    3)什么时候进行301或者302跳转呢?

     当一个网站或者网页24—48小时内临时移动到一个新的位置,这时候就要进行302跳转,而使用301跳转的场景就是之前的网站因为某种原因需要移除掉,然后要到新的地址访问,是永久性的。

    清晰明确而言:使用301跳转的大概场景如下:

    1、域名到期不想续费(或者发现了更适合网站的域名),想换个域名。

    2、在搜索引擎的搜索结果中出现了不带www的域名,而带www的域名却没有收录,这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。

    3、空间服务器不稳定,换空间的时候。

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

     现在浏览器知道了 "http://www.google.com/"才是要访问的正确地址,所以它会发送另一个http请求。这里没有啥好说的

     

    6、服务器处理请求

    经过前面的重重步骤,我们终于将我们的http请求发送到了服务器这里,其实前面的重定向已经是到达服务器了,那么,服务器是如何处理我们的请求的呢?

     

    后端从在固定的端口接收到TCP报文开始,它会对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成HTTP Request对象,供上层使用。

     

    一些大一点的网站会将你的请求到反向代理服务器中,因为当网站访问量非常大,网站越来越慢,一台服务器已经不够用了。于是将同一个应用部署在多台服务器上,将大量用户的请求分配给多台机器处理。此时,客户端不是直接通过HTTP协议访问某网站应用服务器,而是先请求到Nginx,Nginx再请求应用服务器,然后将结果返回给客户端,这里Nginx的作用是反向代理服务器。同时也带来了一个好处,其中一台服务器万一挂了,只要还有其他服务器正常运行,就不会影响用户使用。

    通过Nginx的反向代理,我们到达了web服务器,服务端脚本处理我们的请求,访问我们的数据库,获取需要获取的内容等等,当然,这个过程涉及很多后端脚本的复杂操作。由于对这一块不熟,所以这一块只能介绍这么多了。

     

    扩展阅读:

    1)什么是反向代理?

    客户端本来可以直接通过HTTP协议访问某网站应用服务器,网站管理员可以在中间加上一个Nginx,客户端请求Nginx,Nginx请求应用服务器,然后将结果返回给客户端,此时Nginx就是反向代理服务器。

     

    7、服务器返回一个 HTTP 响应 

    经过前面的6个步骤,服务器收到了我们的请求,也处理我们的请求,到这一步,它会把它的处理结果返回,也就是返回一个HTPP响应。

     

    HTTP响应与HTTP请求相似,HTTP响应也由3个部分构成,分别是:

    l 状态行

    l 响应头(Response Header)

    l 响应正文

     

    HTTP/1.1 200 OK   

    Date: Sat, 31 Dec 2005 23:59:59 GMT   

    Content-Type: text/html;charset=ISO-8859-1   Content-Length: 122   

    <html>   

    <head>   

    <title>http</title>   

    </head>   

    <body>   

    <!-- body goes here -->   

    </body>   

    </html>

     

    状态行由协议版本、数字形式的状态代码、及相应的状态描述,各元素之间以空格分隔。

    格式:    HTTP-Version Status-Code Reason-Phrase CRLF

    例如:    HTTP/1.1 200 OK \r\n

    -- 协议版本:是用http1.0还是其他版本

    -- 状态描述:状态描述给出了关于状态代码的简短的文字描述。比如状态代码为200时的描述为 ok

    -- 状态代码:状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。如下

     

    1xx:信息性状态码,表示服务器已接收了客户端请求,客户端可继续发送请求。

     

    100 Continue

     

    101 Switching Protocols

     

    2xx:成功状态码,表示服务器已成功接收到请求并进行处理。200 OK 表示客户端请求成功

     

    204 No Content 成功,但不返回任何实体的主体部分

     

    206 Partial Content 成功执行了一个范围(Range)请求

     

    3xx:重定向状态码,表示服务器要求客户端重定向。

     

    301 Moved Permanently 永久性重定向,响应报文的Location首部应该有该资源的新URL

     

    302 Found 临时性重定向,响应报文的Location首部给出的URL用来临时定位资源

     

    303 See Other 请求的资源存在着另一个URI,客户端应使用GET方法定向获取请求的资源

     

    304 Not Modified 服务器内容没有更新,可以直接读取浏览器缓存

     

    307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET,但实际使用时并不一定,307则更多浏览器可能会遵循这一标准,但也依赖于浏览器具体实现

     

    4xx:客户端错误状态码,表示客户端的请求有非法内容。

     

    400 Bad Request 表示客户端请求有语法错误,不能被服务器所理解

     

    401 Unauthonzed 表示请求未经授权,该状态代码必须与 WWW-Authenticate 报头域一起使用

     

    403 Forbidden 表示服务器收到请求,但是拒绝提供服务,通常会在响应正文中给出不提供服务的原因

     

    404 Not Found 请求的资源不存在,例如,输入了错误的URL

     

    5xx:服务器错误状态码,表示服务器未能正常处理客户端的请求而出现意外错误。

     

    500 Internel Server Error 表示服务器发生不可预期的错误,导致无法完成客户端的请求

     

    503 Service Unavailable 表示服务器当前不能够处理客户端的请求,在一段时间之后,服务器可能会恢复正常

     

    8、浏览器显示 HTML

    在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了,浏览器是如何把页面呈现在屏幕上的呢?不同浏览器可能解析的过程不太一样,这里我们只介绍webkit的渲染过程,下图对应的就是WebKit渲染的过程,这个过程包括:

     

    解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树

     

    浏览器在解析html文件时,会”自上而下“加载,并在加载过程中进行解析渲染。在解析过程中,如果遇到请求外部资源时,如图片、外链的CSS、iconfont等,请求过程是异步的,并不会影响html文档进行加载。

     

    解析过程中,浏览器首先会解析HTML文件构建DOM树,然后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念: reflow(回流)和repain(重绘)。

     

    DOM节点中的各个元素都是以盒模型的形式存在,这些都需要浏览器去计算其位置和大小等,这个过程称为relow;当盒模型的位置,大小以及其他属性,如颜色,字体,等确定下来之后,浏览器便开始绘制内容,这个过程称为repain。

     

    页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

     

    当文档加载过程中遇到js文件,html文档会挂起渲染(加载解析渲染同步)的线程,不仅要等待文档中js文件加载完毕,还要等待解析执行完毕,才可以恢复html文档的渲染线程。因为JS有可能会修改DOM,最为经典的document.write,这意味着,在JS执行完成前,后续所有资源的下载可能是没有必要的,这是js阻塞后续资源下载的根本原因。所以我明平时的代码中,js是放在html文档末尾的。

     

    JS的解析是由浏览器中的JS解析引擎完成的,比如谷歌的是V8。JS是单线程运行,也就是说,在同一个时间内只能做一件事,所有的任务都需要排队,前一个任务结束,后一个任务才能开始。但是又存在某些任务比较耗时,如IO读写等,所以需要一种机制可以先执行排在后面的任务,这就是:同步任务(synchronous)和异步任务(asynchronous)。

     

    JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务,异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行,形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件;脚本运行时先依次运行执行栈,然后会从任务队列里提取事件,运行任务队列中的任务,这个过程是不断重复的,所以又叫做事件循环(Event loop)。

     

    9、浏览器发送请求获取嵌入在 HTML 中的资源(如图片、音频、视频、CSS、JS等等)

    其实这个步骤可以并列在步骤8中,在浏览器显示HTML时,它会注意到需要获取其他地址内容的标签。这时,浏览器会发送一个获取请求来重新获得这些文件。比如我要获取外图片,CSS,JS文件等,类似于下面的链接:

     

    图片:http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

     

    CSS式样表:http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

     

    JavaScript 文件:http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

     

    这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名,发送请求,重定向等等...

    不像动态页面,静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯,而从缓存中直接读取,或者可以放到CDN中

    展开全文
  • 作为网络专栏的开篇导文,本文概况介绍下经典案例:从输入一个网址到浏览器显示页面的全过程。 步骤概要介绍如下: 1、输入网址 2、DNS解析获取域名对应的IP地址 3、建立TCP连接 4、web浏览器向web服务器发送...

    作为网络专栏的开篇导文,本文概况介绍下经典案例:从输入一个网址到浏览器显示页面的全过程。

    步骤概要介绍如下:

    • 1、输入网址
    • 2、DNS解析获取域名对应的IP地址
    • 3、建立TCP连接
    • 4、web浏览器向web服务器发送HTTP请求
    • 5、服务器的永久重定向响应
    • 6、浏览器跟踪重定向地址
    • 7、web服务器做出应答
    • 8、浏览器显示 HTML
    • 9、浏览器发送请求获取其他嵌入在 HTML 中的资源
    • 10、web服务器关闭TCP连接

    1、输入网址

    当在浏览器中输入网址时,浏览器其实就已在智能匹配 url 了,他会从历史记录,书签等地方,找到已经输入的字符串可能对应的 url,然后给出智能提示,让你可以补全url地址。

    对于 google的chrome 的浏览器,他甚至会直接从缓存中把网页展示出来,就是说,你还没有按下 enter,页面就出来了。

     

    2、DNS解析获取域名对应的IP地址

    请求一旦发起,浏览器首先要做的事情就是解析这个域名。

    • 1、一般来说,浏览器会首先查看本地硬盘的 hosts 文件,看看其中有没有和这个域名对应的规则,如果有的话就直接使用 hosts 文件里面的 ip 地址。
    • 2、如果在本地的 hosts 文件没有能够找到对应的 ip 地址,浏览器会发出一个 DNS请求到本地DNS服务器 。本地DNS服务器一般都是你的网络接入服务器商提供,比如中国电信,中国移动。
    • 3、查询你输入的网址的DNS请求到达本地DNS服务器之后,本地DNS服务器会首先查询它的缓存记录,如果缓存中有此条记录,就可以直接返回结果,此过程是递归的方式进行查询。如果没有,本地DNS服务器还要向DNS根服务器进行查询。
    • 4、根DNS服务器没有记录具体的域名和IP地址的对应关系,而是告诉本地DNS服务器,你可以到域服务器上去继续查询,并给出域服务器的地址。这种过程是迭代的过程。
    • 5、本地DNS服务器继续向域服务器发出请求,在这个例子中,请求的对象是.com域服务器。.com域服务器收到请求之后,也不会直接返回域名和IP地址的对应关系,而是告诉本地DNS服务器,你的域名的解析服务器的地址。
    • 6、最后,本地DNS服务器向域名的解析服务器发出请求,这时就能收到一个域名和IP地址对应关系,本地DNS服务器不仅要把IP地址返回给用户电脑,还要把这个对应关系保存在缓存中,以备下次别的用户查询时,可以直接返回结果,加快网络访问。

     

    3、建立TCP连接

    在HTTP工作开始之前,web浏览器首先要通过网络与web服务器建立连接,该连接是通过TCP来完成的。

    PS1:为什么要先建立TCP呢?

    因为HTTP是比TCP更高层次的应用层协议,根据规则,只有低层协议建立之后才能进行更高层次协议的连接,因此要先建立TCP连接,一般TCP连接的端口号是80

    PS2:扩展知识点:

    TCP连接的三次握手和断开的四次挥手 参照站内文章:TCP 三次握手和四次挥手

     

    4、web浏览器向web服务器发送HTTP请求

    建立了TCP连接之后,web浏览器就会向web服务器发起一个http请求。

    一个典型的 http request header 一般需要包括请求的方法,例如 GET 或者 POST 等,不常用的还有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法,一般的浏览器只能发起 GET 或者 POST 请求。

    客户端向服务器发起http请求的时候,会有一些请求信息,请求信息包含三个部分:

    • 请求方法URI协议/版本
    • 请求头(Request Header)
    • 请求正文:

    下面是一个完整的HTTP请求例子:

    GET/sample.jspHTTP/1.1
    Accept:image/gif.image/jpeg,*/*
    Accept-Language:zh-cn
    Connection:Keep-Alive
    Host:localhost
    User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
    Accept-Encoding:gzip,deflate
    
    username=jinqiao&password=1234

    4.1、请求行

    请求的第一行是“方法URL议/版本”:GET/sample.jsp HTTP/1.1

    4.2、请求头(Request Header)

    请求头包含许多有关的客户端环境和请求正文的有用信息。例如,请求头可以声明浏览器所用的语言,请求正文的长度等。

    Accept:image/gif.image/jpeg.*/*
    Accept-Language:zh-cn
    Connection:Keep-Alive
    Host:localhost
    User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
    Accept-Encoding:gzip,deflate.
    

    4.3、请求正文

    请求头和请求正文之间是一个空行,这个行非常重要,它表示请求头已经结束,接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息:

    username=jinqiao&password=1234

    5、服务器的永久重定向响应

    服务器给浏览器响应一个301永久重定向响应,这样浏览器就会访问“http://www.google.com/” 而非“http://google.com/”。

    为什么服务器一定要重定向而不是直接发送用户想看的网页内容呢?其中一个原因跟搜索引擎排名有关。如果一个页面有两个地址,就像http://www.yy.com/和http://yy.com/,搜索引擎会认为它们是两个网站,结果造成每个搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思,这样就会把访问带www的和不带www的地址归到同一个网站排名下。还有就是用不同的地址会造成缓存友好性变差,当一个页面有好几个名字时,它可能会在缓存里出现好几次。

    重定向原因:

    • 1、网站调整(如改变网页目录结构);
    • 2、网页被移到一个新地址;
    • 3、网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

    这种情况下,如果不做重定向,则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息,访问流量白白丧失;再者某些注册了多个域名的网站,也需要通过重定向让访问这些域名的用户自动跳转到主站点等。

     

    6、浏览器跟踪重定向地址

    现在浏览器知道了 "http://www.google.com/"才是要访问的正确地址,所以它会发送另一个http请求。这里没有啥好说的

     

    7、web服务器做出应答

    经过前面的步骤,服务器收到了我们的请求,也处理我们的请求,到这一步,它会把它的处理结果返回,也就是返回一个HTPP响应。

    HTTP响应与HTTP请求相似,HTTP响应也由3个部分构成,分别是:

    • 状态行
    • 响应头(Response Header)
    • 响应正文
    HTTP/1.1 200 OK
    Date: Sat, 31 Dec 2005 23:59:59 GMT
    Content-Type: text/html;charset=ISO-8859-1
    Content-Length: 122
    
    <html>
    <head>
    <title>http</title>
    </head>
    <body>
    <!-- body goes here -->
    </body>
    </html>

    7.1、状态行:

    状态行由协议版本、数字形式的状态代码、及相应的状态描述,各元素之间以空格分隔。

    格式: HTTP-Version Status-Code Reason-Phrase CRLF

    例如: HTTP/1.1 200 OK \r\n

    -- 协议版本:是用http1.0还是其他版本

    -- 状态描述:状态描述给出了关于状态代码的简短的文字描述。比如状态代码为200时的描述为 ok

    -- 状态代码:状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。

    状态代码具体协议定义如下:

    1xx:信息性状态码,表示服务器已接收了客户端请求,客户端可继续发送请求。
    100 Continue
    101 Switching Protocols
    
    2xx:成功状态码,表示服务器已成功接收到请求并进行处理。
    200 OK 表示客户端请求成功
    204 No Content 成功,但不返回任何实体的主体部分
    206 Partial Content 成功执行了一个范围(Range)请求
    
    3xx:重定向状态码,表示服务器要求客户端重定向。
    301 Moved Permanently 永久性重定向,响应报文的Location首部应该有该资源的新URL
    302 Found 临时性重定向,响应报文的Location首部给出的URL用来临时定位资源
    303 See Other 请求的资源存在着另一个URI,客户端应使用GET方法定向获取请求的资源
    304 Not Modified 服务器内容没有更新,可以直接读取浏览器缓存
    307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET,但实际使用时并不一定,307则更多浏览器可能会遵循这一标准,但也依赖于浏览器具体实现
    
    4xx:客户端错误状态码,表示客户端的请求有非法内容。
    400 Bad Request 表示客户端请求有语法错误,不能被服务器所理解
    401 Unauthonzed 表示请求未经授权,该状态代码必须与 WWW-Authenticate 报头域一起使用
    403 Forbidden 表示服务器收到请求,但是拒绝提供服务,通常会在响应正文中给出不提供服务的原因
    404 Not Found 请求的资源不存在,例如,输入了错误的URL
    
    5xx:服务器错误状态码,表示服务器未能正常处理客户端的请求而出现意外错误。
    500 Internel Server Error 表示服务器发生不可预期的错误,导致无法完成客户端的请求
    503 Service Unavailable 表示服务器当前不能够处理客户端的请求,在一段时间之后,服务器可能会恢复正常

    7.2、响应头:

    响应头部:由关键字/值对组成,每行一对,关键字和值用英文冒号":"分隔。

    Date: Sat, 31 Dec 2005 23:59:59 GMT
    Content-Type: text/html;charset=ISO-8859-1
    Content-Length: 122

    典型的响应头字段:

    从输入一个网址到浏览器显示页面经历的全过程

     

    7.3、响应正文

    包含着我们需要的一些具体信息,比如cookie,html,image,后端返回的请求数据等等。这里需要注意,响应正文和响应头之间有一行空格,表示响应头的信息到空格为止。

     

    8、浏览器显示 HTML

    在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了,浏览器是如何把页面呈现在屏幕上的呢?

    不同浏览器可能解析的过程不太一样,这里我们只介绍webkit的渲染过程。下图对应的就是WebKit渲染的过程,这个过程包括:

    解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树:

     

    9、浏览器发送请求获取嵌入在 HTML 中的资源(如图片、音频、视频、CSS、JS等等)

    其实这个步骤可以并列在步骤8中,在浏览器显示HTML时,它会注意到需要获取其他地址内容的标签。这时,浏览器会发送一个获取请求来重新获得这些文件。比如我要获取外图片,CSS,JS文件等,类似于下面的链接:

    图片:http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

    CSS式样表:http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

    JavaScript 文件:http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

    这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名,发送请求,重定向等等...

    不像动态页面,静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯,而从缓存中直接读取,或者可以放到CDN中

     

    10、web服务器关闭TCP连接

    一般情况下,一旦web服务器向浏览器发送了请求数据后,它就要关闭TCP连接,然后如果浏览器或者服务器在其头信息加入这行代码:

    connection:keep-alive

    这样TCP连接将依然保持打开状态,浏览器可以继续通过相同的连接发送请求,保持连接,节省了为每个请求建立新连接所需要的的事件,同时节省了宽带

    实际上,在HTTP 1.1 版本的新特性中有一点是:默认持久连接节省通信量,只要客户端、服务端任意一端没有明确断开TCP连接,可以发送多次HTTP请求。

    从输入一个网址到浏览器显示页面经历的全过程

     

    展开全文
  • 1,在浏览器中输入网址 用户输入网址URL,比如http://www.baidu.com,其中http为协议,www.baidu.com为网络地址,网络地址可以为域名或IP地址,使用域名是为了方便记忆,但是为了让计算机理解这个地址还需要把它...

    1,在浏览器中输入网址

    用户输入网址URL,比如http://www.baidu.com,其中http为协议,www.baidu.com为网络地址,网络地址可以为域名或IP地址,使用域名是为了方便记忆,但是为了让计算机理解这个地址还需要把它解析为IP地址。

    2,浏览器查找域名的IP地址

    导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下:

    • 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是,操作系统没有告诉浏览器储存DNS记录的时间,这样不同浏览器会储存个自固定的一个时间(2分钟到30分钟不等)。
    • 系统缓存 – 如果在浏览器缓存里没有找到需要的记录,浏览器会做一个系统调用(windows里是gethostbyname)。这样便可获得系统缓存中的记录。
    • 路由器缓存 – 接着,前面的查询请求发向路由器,它一般会有自己的DNS缓存。
    • ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
    • 递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索,从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名,所以到顶级服务器的匹配过程不是那么必要了。

    DNS有一点令人担忧,这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好,有几种方法可以消除这个瓶颈:

    • 循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说,Facebook.com实际上就对应了四个IP地址。
    • 负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。
    • 地理 DNS 根据用户所处的地理位置,通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态,但映射静态内容的话非常好。
    • Anycast 是一个IP地址映射多个物理主机的路由技术。 美中不足,Anycast与TCP协议适应的不是很好,所以很少应用在那些方案中。

    大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。

    这个过程就是客户端先检查本地是否有对应的IP地址,若找到则返回响应的IP地址。若没找到则请求上级DNS服务器,直至找到或到根节点。

    3,浏览器给web服务器发送一个HTTP请求

    因为像Facebook主页这样的动态页面,打开后在浏览器缓存中很快甚至马上就会过期,毫无疑问他们不能从中读取。

    所以,浏览器将把一下请求发送到Facebook所在的服务器:

    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 and Accept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP连接。

    请求中也包含浏览器存储的该域名的cookies。可能你已经知道,在不同页面请求当中,cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名,服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里,每次请求时发送给服务器。

    用来看原始HTTP请求及其相应的工具很多。作者比较喜欢使用fiddler,当然也有像FireBug这样其他的工具。这些软件在网站优化时会帮上很大忙。

    除了获取请求,还有一种是发送请求,它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=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的和不带www的地址归到同一个网站排名下。

    还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时,它可能会在缓存里出现好几次。

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

    现在,浏览器知道了“http://www.facebook.com/”才是要访问的正确地址,所以它会发送另一个获取请求:

    GET http://www.facebook.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.facebook.com

    头信息以之前请求中的意义相同。

    6,服务器“处理”请求

    服务器接收到获取请求,然后处理并返回一个响应。

    这表面上看起来是一个顺向的任务,但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站,何况像facebook那样访问量大的网站呢!

    • 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。
    • 请求处理
      请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据,并讲数据存储在服务器上。然后,需求处理会生成一个HTML响应。

    所有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据,存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案 有:sharding (基于主键值讲数据表分散到多个数据库中),复制,利用弱语义一致性的简化数据库。

    委托工作给批处理是一个廉价保持数据更新的技术。举例来讲,Fackbook得及时更新新闻feed,但数据支持下的“你可能认识的人”功能只需要每晚更新 (作者猜测是这样的,改功能如何完善不得而知)。批处理作业更新会导致一些不太重要的数据陈旧,但能使数据更新耕作更快更简洁。

    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类型传输。

    内容编码头告诉浏览器整个响应体用gzip算法进行压缩。解压blob块后,你可以看到如下期望的HTML:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"    
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
     lang="en" id="facebook" class=" no_js">
     <head>
     <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
     <meta http-equiv="Content-language" content="en" />
     ...

    关于压缩,头信息说明了是否缓存这个页面,如果缓存的话如何去做,有什么cookies要去设置(前面这个响应里没有这点)和隐私信息等等。

    请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现,而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应,不过同时也会考虑像URL扩展内容等其他因素。

    8,浏览器开始显示HTML

    在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了。

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

    在浏览器显示HTML时,它会注意到需要获取其他地址内容的标签。这时,浏览器会发送一个获取请求来重新获得这些文件。

    下面是几个我们访问facebook.com时需要重获取的几个URL:

    • 图片
      http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
      http://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表和JavaScript文件这些静态文件。所以,这些文件会在全球很多CDN的数据中心中留下备份。

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

    举例来讲,当你试着ping static.ak.fbcdn.net的时候,可能会从某个akamai.net服务器上获得响应。有意思的是,当你同样再ping一次的时候,响应的服务器可能就不一样,这说明幕后的负载平衡开始起作用了。

    10,浏览器发送异步(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是一个请求-响应协议,所以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。

    这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息,它就不理这个客户端。而当尚未超时的情况下收到了该客户的新消息,服务器就会找到未完成的请求,把新消息做为响应返回给客户端。


    展开全文
  • rss、网址储存浏览器

    2010-07-22 05:09:54
    平常上网会不会有很多网址记不住,浏览器中的收藏夹一旦不小心被清除就在也找不以前浏览过的有价值的东西了 这个东西是我遇到了上面的问题而改写我以前写的一个rss聚合器扩展改变而成的 具有储存和浏览rss信息...
  • 本文将更深入的研究当你输入一个网址的时候,后台到底发生了一件件什么的事~1. 首先嘛,你得在浏览器里输入要网址:2. 浏览器查找域名的IP地址导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下:* ...
    作为一个软件开发者,你一定会对网络应用如何工作有一个完整的层次化的认知,同样这里也包括这些应用所用到的技术:像浏览器,HTTP,HTML,网络服务器,需求处理等等。
    
    本文将更深入的研究当你输入一个网址的时候,后台到底发生了一件件什么样的事~
    1. 首先嘛,你得在浏览器里输入要网址:



    2. 浏览器查找域名的IP地址


    导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下:
    * 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是,操作系统没有告诉浏览器储存DNS记录的时间,这样不同浏览器会储存个自固定的一个时间(2分钟到30分钟不等)。
    * 系统缓存 – 如果在浏览器缓存里没有找到需要的记录,浏览器会做一个系统调用(windows里是gethostbyname)。这样便可获得系统缓存中的记录。
    * 路由器缓存 – 接着,前面的查询请求发向路由器,它一般会有自己的DNS缓存。
    * ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
    * 递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索,从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会 有.com域名服务器中的域名,所以到顶级服务器的匹配过程不是那么必要了。

    DNS递归查找如下图所示:
    500pxAn_example_of_theoretical_DNS_recursion_svg.png


    DNS有一点令人担忧,这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好,有几种方法可以消除这个瓶颈:
    * 循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说,Facebook.com实际上就对应了四个IP地址。
    * 负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。
    * 地理 DNS 根据用户所处的地理位置,通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态,但映射静态内容的话非常好。
    * Anycast 是一个IP地址映射多个物理主机的路由技术。 美中不足,Anycast与TCP协议适应的不是很好,所以很少应用在那些方案中。

    大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。
    3. 浏览器给web服务器发送一个HTTP请求

    因为像Facebook主页这样的动态页面,打开后在浏览器缓存中很快甚至马上就会过期,毫无疑问他们不能从中读取。
    所以,浏览器将把一下请求发送到Facebook所在的服务器
    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 and Accept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP连接。
    请求中也包含浏览器存储的该域名的cookies。可能你已经知道,在不同页面请求当中,cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名,服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里,每次请求时发送给服务器
    用来看原始HTTP请求及其相应的工具很多。作者比较喜欢使用fiddler,当然也有像FireBug这样其他的工具。这些软件在网站优 化时会帮上很大忙。
    除了获取请求,还有一种是发送请求,它常在提交表单用到。发送请求通过URL传递其参数(e.g.:HTTP://robozzle.com/puzzle.aspx?id=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的和不带www的地址归到同一个网站排名下。
    还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时,它可能会在缓存里出现好几次。
    5. 浏览器跟踪重定向地址


    现在,浏览器知道了 “HTTP://www.facebook.com/”才是要访问的正确地址,所以它会发送另一个获取请求:
    GET HTTP://www.facebook.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.facebook.com

    头信息以之前请求中的意义相同。
    6. 服务器“处理”请求


    服务器接收到获取请求,然后处理并返回一个响应。
    这表面上看起来是一个顺向的任务,但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站,何况像facebook那样访问量大的网站呢!
    * 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* 请求处理请求处理阅读 请求及它的参数和cookies。它会读取也可能更新一些数据,并讲数据存储在服务器上。然后,需求处理会生成一个HTML响应。
    所 有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据,存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案有:sharding (基于主键值讲数据表分散到多个数据库中),复制,利用弱语义一致性的简化数据库。
    委托工作给批处理是一个廉价保持数据更新的技术。举例来讲,Fackbook得及时更新新闻feed,但数据支持下的“你可能认识的人”功能只需要每晚更新(作者猜测是这样的,改功能如何完善不得而知)。批处理作业更新会导致一些不太重要的数据陈旧,但能使数据更新耕作更快更简洁。7. 服务器发回一个HTML响应


    图中为服务器生成并返回的响应:
    HTTP/1.1 200 OKCache-Control: private, no-store, no-cache, must-revalidate, post-check=0,pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTP3P: CP=”DSP LAW”Pragma: no-cacheContent-Encoding: gzipContent-Type: text/html; charset=utf-8X-Cnection: closeTransfer-Encoding: chunkedDate: Fri, 12 Feb 2010 09:05:55 GMT
    2b3Tn@[...]
    整个响应大小为35kB,其中大部分在整理后以blob类型传输。
    内容编码头告诉浏览器整个响应体用 gzip算法进行压缩。解压blob块后,你可以看到如下期望的HTML:
    HTTP://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>lang=”en” id=”facebook”>

    关于压缩,头信息说明了是否缓存这个页面,如果缓存的话如何去做,有什么cookies要去设置(前面这个响应里没有这点)和隐私信息等 等。
    请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现,而不是以文件形式下 载它。浏览器会根据报头信息决定如何解释该响应,不过同时也会考虑像URL扩展内容等其他因素。8. 浏览器开始显示HTML
    在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了:


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


    在浏览器显示HTML时,它会注意到需要获取其他地址内容的标签。这时,浏览器会发送一个获取请求来重新获得这些文件。
    下面是几个我们访问facebook.com时需要重获取的几个URL:
    * 图片
    HTTP://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
    HTTP://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表和 JavaScript文件这些静态文件。所以,这些文件会在全球很多CDN的数据中心中留下备份。
    静态内容往往代表站点的带宽大小,也能通过CDN轻松的复制。通常网站会使用第三方的CDN。例如,Facebook的静态文件由最大的 CDN提供商Akamai来托管。
    举例来讲,当你试着ping static.ak.fbcdn.net的时候,可能会从某个akamai.net服务器上获得响应。有意思的是,当你同样再ping一次的时候,响应的 服务器可能就不一样,这说明幕后的负载平衡开始起作用了。10. 浏览器发送异步(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是一个请求-响应协议,所 以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。
    这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息,它就不理这个客户端。而当尚未超时的情况下收到了 该客户的新消息,服务器就会找到未完成的请求,把新消息做为响应返回给客户端。总结一下
    希望看了本文,你能明白不同的网络模块是如何协同工作的
    本篇文章来源于 站长资讯网 原文链接:http://www.chinahtml.com/1007/127890385919293_2.html

     

     

     

     

    我们似乎每天都要做这样一件事情,打开一个浏览器,输入网址,回车,一个空白的页面顿时有了东西,它可能是百度之类的搜索页面,或是一个挤满了文字和图片的门户网站。从我们打开浏览器,到我们看到我们想看的内容,这过程究竟发生了什么?
    下面我们就从三个方面理解这个过程,一个是浏览器,二个是服务器,第三个是浏览器和服务器之间通信的协议。在理解这三方面之前我们必须先搞明白将这三方面联系起来的一个词:web。 

    1,world wide web 
    我们通常所说的web就是指world wide web。一般来讲,这一种通过浏览器来访问资源的技术。我们经常说的上网,应该大部都是指的是上万维网(web),但是我们经常将万维网和因特网(Internet)搞混。因特网是一种网络互连的技术,它更指的是物理层面上的互连,而万维网应该算是跑在因特网上的一种服务。
    我们通常通过浏览器还访问web,我们常见到的网页中包含超文本,图片,视频音频等各项内容。向我们提供这些资源的是一个一个的站点,通过互联网,这些站点相互连接起来。我们通过超链接从一个网页访问到另外一个网页,从一个站点到另外一个站点,所有的这一切组成一个庞大的网,这就是web。
    支持web的技术,首先是底层的网络,因为web就是建立在Internet之上,web的基本协议是HTTP协议,它跑在TCP上的协议之上,而TCP协议又需要IP协议的支持,IP协议又要由底层链路来支撑,所以我们可以从高到第看到这样一个协议栈 http->tcp->ip->连路层协议。要理解web到ip就已经足够了。
    我们可以想一想web上的资源有哪些? 首先是文本,后来添加了图片,到现在的各种音频视频资源,所有互联网上的资源都要通过一个叫做URI的东西还标记,当然了我们更常见是URL。现在也不必纠结于两者有何不同,URL就是URI的一个子集,URL给了我们资源的地址,所以我们能够找到它。
    现在看一个URL:这是一个图片的url。它是按照这样的语法来定义:scheme://domain:port/path?query_string#fragment_id.scheme就是协议,在浏览器里通常是http,例子中的是https是一种由HTTP和SSL/TLS组合起来的应用,用以提供加密通信和对网络服务器的身份验证(http://zh.wikipedia.org/zh/HTTPS )。然后就是域名,每个站点都至少有一个域名,上面例子上的域名部分是www.google.com.hk,这个域名也是分为三部分的,www是主机名,com.hk算是顶级域名,除了com还有cn,net等。域名后面是端口号默认为80,通常被省略,这是服务器端服务器软件侦听的端口,也是TCP里面一个端口号的值。然后就是path,资源在服务器上的路径。最后问号部分的客户端利用url传给服务器的一些参数值,通常值比较少,不太重要时这么做。
    2,协议
    (1)HTTP协议
    web里最重要的协议就是HTTP协议,对于经典的ISO七层网络模型来说, HTTP处于最高层--应用层。HTTP应用的模型是client/server模型。因此对应着两种HTTP消息类型,request和response。客户端向服务器发出请求,服务器向客户端发回请求。下面看一下两种类型消息的格式:



     
    下面分别进行解释。
    首先是HTTP Request Message
    请求行:请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本。请求方法常见的有:GET POST HEAD PUT等。
    消息报头:在普通报头中,有少数报头域用于所有的请求和响应消息,但并不用于被传输的实体,只用于传输的消息。 请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。 请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成,但并不是说实体报头域和实体正文要在一起发送,可以只发送实体报头域。实体报头定义了关于实体正文(eg:有无实体正文)和请求所标识的资源的元信息。 POST请求的内容放在实体正文中。 
    HTTP Response Message
    状态行:最主要的一个字段是服务器响应代码。比如,200 OK ,400 Bad Request ,401 Unauthorized ,403 Forbidden ,404 Not Found ,500 Internal Server Error ,503 Server Unavailable
    消息报头:普通报头和实体报头与 请求报头的类似。有区别的在于响应包头,响应报头允许服务器传递不能放在状态行中的附加响应信息,以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
    (这部分说的比较粗略,网上的资源比较多,可以参考这一篇:http://blog.csdn.net/gueter/article/details/1524447 和http://book.51cto.com/art/200902/109036.htm )
    下面是ethereal抓到的一个get报文,post报文和响应报文,可以大概看一下。
     
     
     
    (2)TCP协议
    HTTP协议基于TCP协议,也就是HTTP的所有内容将作为TCP的实体被封装到TCP报文里面。TCP协议是面向连接,可靠的传输机制。也就是说客户端在与服务器交互数据的过程中会有一个连接建立和释放的过程,看上面的Http头部字段可以看到相关的字段。TCP有强大的窗口机制能够适应发送方和接收方的发送接收能力,也能根据整个网络状况进行调整。
    (3)IP协议
    IP协议处于整个TCP/IP协议族的承上启下地位。我们知道因特网上主机是靠一个32位的ip地址来定位的,HTTP用的URL也算是地址,但是比较高级,IP协议是理解不了的,所以需要一个从URL到IP的转换,这个过程通过DNS(域名查询系统)协议完成。我们用的每一台电脑上都配置了DNS服务器的地址,如果没有配置那么你的网关默认充当了,当我们有一个URL想知道对应的IP时就需要向DNS服务器发送查询请求了,它会把查询的结果发回。
    2,浏览器
    在web的世界里最不能少的角色就是浏览器。前面我们说到HTTP协议,HTTP消息有两种,request和response。浏览器的主要工作就是发送http request报文和接收处理http response报文。没有看过浏览器的开源文档,但是我觉得一个软件只要完成下面几件事,基本上就可以称的上一个浏览器了。
    (1)能够根据用户的请求生成合适的HTTP REQUEST报文。比如用户在浏览器地址栏上输入地址进行访问,浏览器要能够生成HTTP GET报文,表单的发送生成POST报文等等。
    (2) 能够对各种的RESPONSE进行处理。
    (3)渲染Html文档,生成文档树,能够解释css,还要有个javascript引擎。
    (4)能够发起dns查询得到ip地址。
    浏览器是个非常复杂的软件,当然现在的浏览器对http协议的支持应该不是问题,它们主要纠结于html文档渲染部分,对于用户层出不穷的新需求,w3c层出不穷的新标准,浏览器的路应该才刚刚开始。 
    3, 服务器
    服务器有两个层级的概念,它可以是机器,它上面存着一个站点的所有东西,也可以是软件,安装在一个也叫做服务器的机器上,帮助这个机器分发用户想要的东西。 我对服务器研究不多,只是用过几次apache。所以只是简单的谈谈我的认识。
    服务器最基本的功能就是响应客户端的资源请求。服务器首先会侦听80端口,来了http请求,就根据请求进行处理,请求一个图片那就根据路径找到资源发回,请求静态html页面也是如此,如果请求的是像php这样的动态页面应该先调用php编译器(或是解释器吧)生成html代码,然后返回给客户端。当然还要解决的一个问题就是并行问题以应对大访问量。
    因为对这方面不太了解,只想到了这么多。

    先说到这里, 有了新的认识再写。


    来源:http://www.cnblogs.com/orchid/archive/2012/04/21/2461442.html

     

     

    来源:从输入网址到显示网页的全过程分析
    http://www.itmian4.com/forum.php?mod=viewthread&tid=1655&fromuid=1931

    展开全文
  • 首先,你得在浏览器里输入要网址: 例如百度或者facebook。 第二步过程 浏览器查找域名的IP地址(域名就是指输入的网址浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是,操作系统没
  • How can I access the Safari browser from C# to get the current URL?解决方案It's not exactly the best answer, but I've accomplished this by bringing focus to the safari window, and then using SendKeys ...
  • 满意答案如何在360浏览器、傲游、搜狗浏览器中设hao123为首页?1. 在360浏览器里如何将hao123设为主页?2. 在傲游浏览器里如何将hao123设为主页?3. 在搜狗浏览器里如何将hao123设为主页?-------------------------...
  • 浏览器输入一个网址到得到页面的过程(详细) 2018年01月18日 16:52:06 阅读数:2422 作为一个软件开发者,你一定会对网络应用如何工作有一个完整的层次化的认知,同样这里也包括这些应用所用到的技术:像...
  • 如何找回保存浏览器保存的密码

    千次阅读 2018-11-20 09:54:40
    隐私与安全(或者直接在网址输入栏输入 about:preferences#privacy 也可以进入隐私与安全这里),往下拉找到表单与密码,点击已保存的登录信息 在弹出来的页面中点击显示/隐藏密码即可找到你曾经保存...
  • 网站首次设置的密码,让...chrome浏览器: 进入设置->自动填充->密码,或在地址栏输入:chrome://settings/passwords 在搜索密码输入框输入网址,点对应网址的密码右侧眼睛图标,输入电脑密码即可查看 ...
  • 浏览器中输入网址到看到网页内容经历了哪些过程! 1.在浏览器地址栏中输入网址 2.浏览器获取这个网址之后,会先去缓存中看看有没有要访问的资源,从浏览器缓存-系统缓存-路由缓存中查看,如果有就不再进行hhtp请求...
  • 浏览器输入网址后台怎么运行

    千次阅读 2015-07-11 10:33:31
    1. 首先,在浏览器里输入要网址: 2. 浏览器查找域名的IP地址 导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下: 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是,操作系统没有告诉...
  • 充值4折起我们经常在电脑上的浏览器上进行网页的搜索,有时候我们会对经常使用的网页输入密码并保存,以方便每次快速登录,那么我们怎么查看电脑浏览器保存的密码呢,接下来就让小编来教你们吧。具体如下:1.第...
  • 当你输入一个网址的时候,实际会发生什么?... 本文将更深入的研究当你输入一个网址的时候,后台到底发生了一件件什么的事~ 1. 首先嘛,你得在浏览器里输入要网址: 2. 浏览器查找域名的I...
  • 浏览器离线保存数据

    2016-06-19 14:44:02
    先找到 网址,然后google 浏览器访问,fiddler2 里面 just url 复制txt,然后java 读取 --处理代码 /** * 功能:Java读取txt文件的内容 步骤:1:先获得文件句柄 2:获得文件句柄当做是输入一个字节码流,需要...
  • 1. 首先,在浏览器里输入网址 2. 浏览器查找域名的IP地址 DNS查找过程如下: 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 操作系统没有告诉浏览器储存DNS记录的时间,所以不同浏览器会储存各自固定的一个时间(2...
  • 今天有人问我怎么查看别人保存浏览器上的密码,学士研究了下进入正题:第一步:打开你需要获取保存浏览器上的密码网址第二步:我们把鼠标放在密码上面,右键审核元素或者检查都可以然后我们会看到...
  • 怎么查看别人保存浏览器上的密码 进入正题: 第一步:打开你需要获取保存浏览器上的密码网址 第二步:我们把鼠标放在密码上面,右键审核元素或者检查都可以 然后我们会看到右边有一个"password" 把他...
  • 作为一个完全浏览的网站,可以保存在本地可与任何浏览器(如Internet浏览网站资源管理器,网景,歌剧等),或者他们可以保存到Internet Explorer缓存,请使用IE的脱机模式下,仿佛你会冲浪“手”的网站。使用...
  • 微软 Edge 浏览器自发布...“保存网页本地”是一项比较普遍的浏览器功能,甚至连微软 IE 浏览器都具备该属性,故 Edge 浏览器缺失该功能也让人感到不能理解。不过今天外媒也为我们推荐了一款名为《在 Edge 中保存 ...
  • 浏览器从输入网址到显示都发生了些什么? 1、输入网址 输入网址有啥好说的…… 2、浏览器查找域名的IP地址 这个过程呢其实就是应用层DNS解析的过程,上图: DNS的查找有以下过程: 浏览器缓存:...
  • 怎么浏览器的数据保存成csv格式

    千次阅读 2019-03-23 20:47:00
    怎么浏览器的数据保存成csv格式我是win10的系统,把浏览器上面保存下来的时候在编码方式中没有找到ANSI编码方式,发现一个在我的电脑上把数据保存成csv格式的方法,来记录一下,免的忘了。下面是两个在浏览器上...
  • 插件安装到浏览器

    千次阅读 2012-01-16 17:23:38
    我以前只用360浏览器的,因为买火车票就接触火狐,谷歌,以及360极速浏览器   下面就介绍如何在谷歌浏览器或者360极速浏览器上安装脚本(下面链接是买票程序的网址以及脚本下载地址)   ...
  • 保存浏览器控件中的网页 分类: HTML编程(IEProgramming)2007-09-03 06:01 2723人阅读 评论(3) 收藏 举报 如果需要调用默认的保存对话框,可以调用IDM_SAVE命令保存网页 。由于安全原因,这个命令会...
  • 本文深入的研究了浏览器从输入网址到显示页面之间发生的事情。本文内容面向对网络应用相关技术,如浏览器、HTTP、HTML、网络服务器、需求处理等方面有一定了解的软件开发人员。  浏览器缓存 – 浏览器会缓存DNS...
  • 浏览器获取了这个url,当然就去解析了,它先去缓存当中看看有没有,从 浏览器缓存-系统缓存-路由器缓存 当中查看,如果有从缓存当中显示页面,然后没有那就进行步骤三; 缓存就是把你之前访问的web资源,比如一些js...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 80,673
精华内容 32,269
关键字:

怎样保存网址到浏览器