spdyIE11浏览器怎么样？

IE11正式版什么时候更新？

9月18日消息，微软刚刚面向Windows7平台发布了IE11 RP发行预览版，系统要求是Win7 SP1。

IE11是Windows 8.1系统的默认浏览器，微软决定向Win7用户也提供IE11体验，尚不知正式版的发布时间表，微软7月底曾发布过IE11开发者预览版 for Win7。

快速：IE11可挖掘电脑未开发的强大功能，在网页上展现逼真的图片、更流畅的视频和互动内容。

简单：使用固定网站、内置拼写检查和无缝集成与运行Windows 7的电脑一起体验Web。

更安全：增强的功能（如SmartScreen筛选器和跟踪保护）可让您更加注意对电脑和隐私的威胁。

如何设计好的RESTful API

安全是恒久的话题，对于基于WSDL和SOAP的Web Service，我们有WS-Security这样的安全规范来指导实现认证、授权、身份管理等安全需求。

那么，RESTful API有无成熟可用规范或实现框架呢？如何保证RESTful API的安全性呢？ 如何对RESTful API进行版本控制，请分享您认为实用的做法？ HTTP1.1规范中给出的动词对于设计RESTful API够用吗？您在实际项目中会扩展自己的动词吗？在什么情况下需要扩展？ 今年5月份发布的JAX-RS 2.0规范对于RSTfulAPI的设计最有价值的特性是哪个（些）? 它（们）用于解决什么问题？ 能否为InfoQ的读者们推荐一款实用的RESTful API开发框架，并说明您的推介理由。

HTTP2.0规范正在制定当中，您对它的期待是什么？ InfoQ：什么是好的RESTful API？相信每个人都有自己的评判标准。

那么，您认为一个好的RESTful API应该具有哪些特征呢？ 李锟：一个好的RESTful API，应该具备以下特征： 这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。

浏览器是最常见和最通用的REST客户端。

好的RESTful API应该能够使用浏览器+HTML完成所有的测试（不需要使用编程语言）。

这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。

Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTful API的功能组合起来，建造Mashup类的应用。

这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。

REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTful API的核心内容。

RESTful API建模的过程与面向对象建模类似，是以名词为核心的。

这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。

而HTTP协议并不是一种传输协议，它实际提供了一个操作资源的统一接口。

对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。

所以RESTful API建模的过程，可以看作是具有统一接口约束的面向对象建模过程。

按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。

将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。

如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。

设计出更多资源（以及相应的URI）对于RESTful API来说并没有什么害处。

这个API应该是松耦合的。

RESTful API的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。

正是这三个层次确保了RESTful API的松耦合性。

当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。

紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。

尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。

REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。

感兴趣的读者可以参考《REST实战》。

这个API中所使用的表述格式应该是常见的通用格式 在RESTful API中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。

资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。

GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。

这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。

所以除非有很合理的要求，通常不需要使用自定义的私有格式。

使用HTTP响应状态代码来表达各种出错情况 HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。

响应状态代码分成两部分：status code和reason phase。

两部分都是可定制的，也可以使用标准的status code，只定制reason phase。

如果一个所谓的“RESTful API”对于任何请求都返回200 OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。

这个API应该对于HTTP缓存是友好的 充分利用好HTTP缓存是RESTful API可伸缩性的根本。

HTTP协议是一个分层的架构，从两端的user agent到origin server之间，可以插入很多中间组件。

而在整个HTTP通信链条的很多位置，都可以设置缓存。

HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。

如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。

李建业：首先说明一下，对REST这个概念，我一般把它理解为REST风格的架构，但是现在实践中最为广泛认知的是HTTP，而它是REST的一个实现，所以RESTful API也可以不太严格的指基于HTTP的API——当然，即使是不严格的时候，API本身也应该力求遵循REST架构风格。

我认为，一个RESTful API最重要的一点应该是——“尽可能少的先验信息”，这一条也同时是我判断一个好的RESTful API的标准。

比如HTTP动词，在实践中，大家可能会常常纠结于有效利用 HTTP 动词，但这却并不是特别重要的事情——除非你理解这么做的价值。

HTTP 动词最重要的地方在于它是标准阐明了的行为，也就是说，如果我们的“客户端”遵循约定，那么就不必要发明新的动词，也就不必增加“先验信息”；但是，所谓“先验信息”，针对的是客户端——对API来说就是调用者，对于一些企业内部系统，或者一些传统系统，由于“资源”很稳定，对资源的操作也很稳定，这些系统的“调用客户端”不是浏览器而是另一个系统，此时如果强制对应到HTTP动词，反而会变成额外的“先验信息”，这时我就不会太拘泥HTTP动词，自己制定一套动词放在参数中也可以接受——只要动词不变化，这个系统依然是REST风格的。

再比如Response里面的Content-Type，这个有时会被新手忽略，但这其实很重要，因为一般涉及到系统间协同的API，往往不会使用普通的文本，比较常见的是使用json表达复杂结构，而这与通常的缺省理解不同（缺省一般会认为是text/plain和text/html），所以如果在API中忘记用Content-Type进行区分的话，后续对多种类型的客户端接入的支持就会变成陷阱（我们多次遇到过这个问题）。

而如果一开始就检查是否增加先验知识（缺省Content-Type为plain或者允许指定Content-Type），那这一困难就可以避免了。

丁雪丰：首先，应该正确地使用HTTP的统一接口，比如HTTP的动词，如果不分青红皂白清一色POST那显然还有改进的余地； 其次，资源有合适的粒度，可以从三个方面来评判资源的粒度是否合理——网络的效率、表述的大小以及客户端使用时的易用程度； 最后，是表述的设计，除了表述的正文内容，还有其中的URI和链接，这些都是评判一个RESTful API好坏的标准。

马钧：在我看来，一个好的API标准，就是能尽量利用到HTTP协议的特性，将HTTP当成一种转移协议，而不是传输协议。

包括但不限于：利用HTTP的各种动词来明确操作；包含有内容协商，可以根据请求头提供的参数选择一个资源最合适的媒体类型、语言、字符集和编码的表现；使用不同的返回代码来描述各种状态。

但实际上见到过的很多声称RESTful API，包括国内的和国外的，能符合这些条件的并不多。

提供的API是我见到过的较为不错的RESTful API，可以作为范例参考。

InfoQ：安全是恒久的话题，对于基于WSDL和SOAP的Web Service，我们有WS-Security这样的安全规范来指导实现认证、授权、身份管理等安全需求。

那么，RESTful API有无成熟可用规范或实现框架呢？如何保证RESTful API的安全性呢？ 李锟：保证RESTful API的安全性，主要包括三大方面： a) 对客户端做身份认证 b) 对敏感的数据做加密，并且防止篡改 c) 身份认证之后的授权 对客户端做身份认证，有几种常见的做法： 在请求中加签名参数 为每个接入方分配一个密钥，并且规定一种签名的计算方法。

要求接入方的请求中必须加上签名参数。

这个做法是最简单的，但是需要确保接入方密钥的安全保存，另外还要注意防范replay攻击。

其优点是容易理解与实现，缺点是需要承担安全保存密钥和定期更新密钥的负担，而且不够灵活，更新密钥和升级签名算法很困难。

使用标准的HTTP身份认证机制 HTTP Basic身份认证安全性较低，必须与HTTPS配合使用。

HTTP Digest身份认证可以单独使用，具备中等程度的安全性。

HTTP Digest身份认证机制还支持插入用户自定义的加密算法，这样可以进一步提高API的安全性。

不过插入自定义加密算法在面向互联网的API中用的不是很多。

这个做法需要确保接入方“安全域-用户名-密码”三元组信息的安全保存，另外还要注意防范replay攻击。

优点：基于标准，得到了广泛的支持（大量HTTP服务器端、客户端库）。

在服务器端做HTTP身份认证的职责可以由Web Server（例如Nginx）、App Server（例如Tomcat）、安全框架（例如Spring Security）来承担，对应用开发者来说是透明的。

HTTP身份认证机制（RFC 2617）非常好地体现了“分离关注点”的设计原则，而且保持了操作语义的可见性。

缺点：这类基于简单用户名+密码机制的安全性不可能高于基于非对称密钥的机制（例如数字证书）。

使用OAuth协议做身份认证 OAuth协议适用于为外部应用授权访问本站资源的情况。

其中的加密机制与HTTP Digest身份认证相比，安全性更高。

需要注意，OAuth身份认证与HTTP Digest身份认证之间并不是相互取代的关系，它们的适用场景是不同的。

OAuth协议更适合于为面向最终用户维度的API提供授权，例如获取隶属于用户的微博信息等等。

如果API并不是面向最终用户维度的，例如像七牛云存储这样的存储服务，这并非是OAuth协议的典型适用场景。

对敏感的数据做加密，并且防止篡改，常见的做法有： 部署SSL基础设施（即HTTPS），敏感数据的传输全部基于SSL。

仅对部分敏感数据做加密（例如预付费卡的卡号+密码），并加入某种随机数作为加密盐，以防范数据被篡改。

身份认证之后的授权，主要是由应用来控制。

通常应该实现某种基于角色+用户组的授权机制，这方面的框架有不少（例如Spring Security），不过大多数开发团队还是喜欢自己来实现相关功能。

李建业：我不认为安全是RESTful API需要考虑的问题，事实上我觉得这是两个正交的问题。

当然，如果使用RESTful API来提供认证、授权和身份管理，那也算是双方有关系，但是这和其它风格的API设计所要考虑的问题似乎没什么区别，不值得特别注意。

但是在具体设计层面，这两者的“正交点”上似乎确实有些问题，因为REST是一个推崇状态无关原则的架构风格，而认证和授权通常基于第三方解决方案，所以往往会出现违背有状态约束的问题，这个地方我也没有特别的想法，当然这个困难和原问题关系不大。

至于WS-族的协议，我不太了解，不太能参与讨论。

丁雪丰：对于RESTful API，常见的安全措施都是可以继续使用的。

例如，为了防篡改，可以对全部参数进行签名；为了防范重放攻击可以在请求中增加一次性的Token，或者短时间内有效的Token；对内容加密可以实现数据防泄露……；对于DDoS攻击，各种HTTP流量清洗策略，都可以继续发挥作用，因为这就是基本的HTTP请求。

在授权和认证方面，OAuth 2.0已经基本成熟了，并且得到了广泛地应用。

如果可以，接入第三方账户体系是个不错的选择，比如Google和Facebook的，国内的当然也有几个候选。

马钧：个人认为RESTful的安全性分为几个层次，在安全要求较高的场合，可以通过HTTPs这样的加密协议来保证网络层的安全，应用层的安全可以通过OAuth实现认证，而对于资源的访问授权，则只能依靠应用程序来实现了。

InfoQ：如何对RESTful API进行版本控制，请分享您认为实用的做法？ 李锟：一个比较简单实用的做法是直接在URI中插入版本号，这样做允许多个版本的API并行运行。

另一个做法是在HTTP请求中加入自定义头信息，标明使用的版本号。

不过这个做法其实对浏览器不够友好，简单地使用浏览器+HTML无法测试。

李建业：目前比较好的方式还是在uri设计中添加版本信息，其它方法都不如这个实用。

丁雪丰：个人认为最好的版本化，就是没有明显的版本。

在对已发布的服务进行变更时，要尽量做到兼容，其中包括URI、链接和各种不同的表述的兼容，最关键的就是在扩展时不能破坏现有的客户端。

例如，要变更一个参数，可以选择同时兼容新旧两种输入，或者保持老参数不动，提供一个新的参数，在文档中必须做出说明，不推荐新用户再继续使用之前的参数。

如果必须要进行不兼容的变更，那么可以选择标记不同的版本号，这时可以选择在路径或参数中增加版本信息。

也有做法是增加HTTP标头，只是在调用时会稍有不便，推荐前两种方法。

马钧：RESTfulAPI的版本升级，尽量兼容之前的版本，保证原有的API都能正常工作，可以通过HTTP 301转跳到新的资源。

另外一种实用的做法就是在url中保留版本号，同时提供多个版本供客户端使用，如 或者 /v1/ 这样。

InfoQ：HTTP1.1规范中给出的动词对于设计RESTful API够用吗？您在实际项目中会扩展自己的动词吗？在什么情况下需要扩展？ 李锟：这个问题取决于设计者如何看待和设计资源。

如果资源抽象做的很好，对于某个资源的任何操作，通常都能够映射到CRUD四个类别中。

CRUD四个类别对于操作资源来说，绝大多数情况下是完备的。

HTTP的GET/POST/PUT/DELETE四个方法，对于CRUD四个类别的操作来说是足够的，映射关系是Create-POST/Retrieve-GET/Update-PUT/Delete-DELETE。

我们通常不会选择创建自己的动词，这样做对于客户端开发者来说，需要更多的学习成本。

如果在资源上定义的操作过多，我们会选择拆分出更多的资源。

李建业：一般是够用的，有时一些“不够用”的场景是由于我们没有设计出合理的资源，比如批量操作。

但是，正如之前所说的那样，对于某些内部的、传统的（因此模型稳定且已知）系统，API提供者和调用者会有自已的固定动词表，此时没必要拘泥。

另外，我不建议扩展动词，一旦扩展了动词，其实已经破坏了我之前说的*“尽可能少的先验信息”*，那么，扩展动词和重新设计动词的成本差别不大。

基于这个考虑，我建议尽可能保持动词不变，除非你想重新设计动词表。

丁雪丰：一般情况下，常用的HTTP动词是够用的，并没有出现一定要自己扩展动词的情况。

其实，最常用的也就是GET、POST、DELETE和PUT，而HEAD、OPTIONS、TRACE则基本用不太到。

如果出现一时找不到合适的动词，安全幂等的操作用GET，其他都可以用POST，在设计资源时稍加考虑即可。

马钧：在我的实际项目中，只用到了POST，PUT，DELETE，GET这四个动词。

InfoQ：今年5月份发布的JAX-RS 2.0规范对于RSTfulAPI的设计最有价值的特性是哪个（些）? 它（们）用于解决什么问题？ 李锟：REST开发框架RESTEasy项目负责人Bill Burke，去年写了一篇文章介绍JAX-RS 2.0。

我同意Bill在文章中的观点，在JAX-RS 2.0增加的内容中，最重要的三部分为： a) Client API——用来规范化JAX-RS客户端的开发方式。

b) Server-side Asynchronous HTTP——用来实现服务器端推送功能，而不需要依靠低效的轮询方式。

c) Filters and Interceptors——用来分离关注点，将鉴权、日志等逻辑与业务逻辑分离开，更好地实现代码重用。

这三部分的内容对于开发者来说都很有用。

遵循JAX-RS规范做开发，可以确保服务器端以及客户端代码的可移植性。

李建业：我个人关注异步API这部分，主要是因为流式服务将会越来越多，那将大量需要这类支持。

InfoQ：能否为InfoQ的读者推荐一款实用的RESTful API开发框架，并说明您的推介理由。

李锟：这个问题我就不详细回答了。

不同的编程语言有不同的REST开发框架，对于REST的支持程度也不同。

开发RESTful API的需求范围很广，可选择的开发框架的范围也很广。

保持多样性是繁荣生态环境的基础。

像Java就有支持JAX-RS规范的Jersey、RESTEasy、Restlet、Apache CXF，和不支持JAX-RS规范的Spring MVC等等很多框架。

这些框架目前都做的不错。

我对框架的选择没有倾向性。

RESTful API设计的最佳实践应该是通用的，而不是必须依赖某种特定的开发框架。

李建业：不好意思，这个我不太重视，没法推荐，不过我可以解释一下为什么对RESTful API框架不感冒的原因。

REST作为一个架构风格，对我们的系统开发有很大影响，但是这些影响一般是针对架构（例如状态无关）或者设计（例如资源识别）上的，所以一旦涉及到具体实现，主要工作就基本结束了，此时开发框架能做的事也就只有简化编程了（相较而言，有的框架还能起到引导设计的作用），而由于RESTful会抽象动词，所以实现层面中和API规范相关的工作本来就不多，那么框架的价值就更小了。

当然，我们也不可能直接基于servlet/rakc/wsgi来开发，不过一般的编程语言都会提供一些简单的url route/match策略，我们使用这些就足够了。

另外，有些框架能帮我们生成全部的动词支持，但这也未必是好事，我一般倾向于按需实现——用到了再支持，这就更不需要太关注开发框架对RESTful的支持了。

丁雪丰：由于本人是Spring的拥护者，工作中也一直在使用Spring，所以在选择框架时会更多地倾向Spring MVC（并不是说别的框架不好，这里有些个人主观的成份）。

如果一定要选择其他框架，也要选择能够方便与Spring集成的框架。

如果在项目中已经使用了Spring，那么没有什么理由不选择Spring MVC，鉴于目前Spring在各种项目中的高出镜率，相信一般情况下都会选择Spring MVC。

REST的成熟度模型中，第三层就是HATEOAS，Spring目前还提供了Spring Hateoas子项目，对链接、资源等方面的支持都做了一定的增强。

马钧：我目前在实际项目中使用的是Spray，这是一个开源的 REST/HTTP 工具包和底层网络 IO 包，基于 Scala 和 Akka 构建。

轻量级、异步、非堵塞、基于 actor 模式、模块化和可测试是Spray的特点。

InfoQ：HTTP2.0规范正在制定当中，您对它的期待是什么？ 李锟：我的期待包括两个方面：应该做的和不应该做的。

HTTP/2.0规范应该做的： 与HTTP/1.1协议保持兼容。

兼容的含义是说两者可以并存，客户端应用可以根据服务器端的能力，自由地选择使用HTTP/2.0还是HTTP/1.1，而且选择过程对应用来说是透明的。

改进HTTP协议（作为资源的统一接口）之中操作语义表达方式的语法，提高网络传输效率。

更好地模块化，这样HTTP/2.0协议的实现能够更好地模块化。

应用程序可根据需要选择适当的模块，而不是要么全有、要么全无。

废弃掉HTTP/1.1协议中一些很少有人用到的部分，例如采用管道（pipelining）方式发送请求。

增加更多的动词，以适应除CRUD之外的其他场景。

HTTP/2.0规范不应该做的： HTTP/2.0协议不应该把底层的数据加密机制（即SSL）作为必选项。

HTTP/2.0协议不应该背离REST架构风格的约束，尤其是要确保操作语义对于中间组件的可见性。

在上面这两个方面，Roy Fileidng曾经与SPDY协议设计者Mike Belshe发生过激烈争论，详情请看：Roy Fielding谈Google SPDY协议 李建业：对此规范关注不多，不知道会不会有对于流的支持，目前我所知道的只有chunk方式进行简单的支持，但是真正的流需要区分数据通道和控制通道——哪怕是逻辑上的区分，这样就直接对REST风格产生了很大冲击，考虑到流式服务在未来的发展潜力，我特别期待业界在这方面有所进展。

丁雪丰：HTTP 2.0很大程度上是借鉴了Google的SPDY，就我而言，首先，希望这个规范能做到与HTTP 1.1的兼容，使用者如果只认识1.1，那么2.0能优雅“降级”；其次，希望2.0能带来更好的性能，SPDY在这方面还是有所改进的，希望HTTP 2.0能再接再厉；最后，希望这个规范能在最终定稿时附带一个最佳实践，正确引导人们合理地使用HTTP 2.0。

马钧：没研究过，估计即使出来，1.1还有很长的生命周期，不会很快被取代。

正式版IE11功能有什么变化？

IE11新增的功能选项 后台加载站点 IE11新增了一项提高用户体验的功能，在后台加载站点和内容以优化性能。

这是一项通过智能预判页面上用户最有可能点击的链接从而预先在后台加载的技术，可以有效提高页面打开和加载速度。

IE11的新功能：后台加载 使用SPDY/3 这也是IE11的一项新功能，SPDY是 Google 开发的基于传输控制协议 (TCP) 的应用层协议，类似我们常说的HTTP协议，但是它要比HTTP更快更安全。

IE11支持SPDY/3协议 64位增强保护模式 IE11针对增强保护模式额外提供了64位进程的支持。

注，该选项只有在64位Windows 8.1的IE11里才可见。

更强大的64位进程 IE11删除的功能选项 选项卡功能 在IE11中，选项卡功能将不再是可选项，而是固定为始终启用，这也意味着今后选项卡浏览彻底成为IE的标准配置。

从IE7到IE10，选项卡都是可以选择开启或关闭的 IE11不再能关闭选项卡功能 再次使用窗口来启动快捷方式(当选项卡浏览关闭时) 这是和启动选项卡相呼应的一个选项，既然IE11中不再能关闭选项卡功能，那么这个选项也就没有存在的必要了。

IE11不再需要这个选项 兼容性视图自动恢复页面布局错误 IE有一个使用“兼容性视图”自动回复页面布局错误的选项，通过引入“兼容性视图”功能来解决一些不支持新标准的老网站在新版浏览器中出现显示布局错误的问题。

不过在IE11中，这个选项被取消了。

或许微软认为时至今日，不支持新标准的老网站已经消失的差不多了吧。

IE11和老版本IE的选项对比 使网站可以使用搜索窗格 这个选项和上面提到的兼容性视图选项相似(选项位置也很接近)，都被IE11删除了。

备注： 如果你暂时没有升级到Windows 8/Windows 8.1的想法，但又想试一下IE11的话，也可以单独下载IE11 for Windows 7版本。

浏览器是IE11版本，在网上报名时，提示使用的不是IE浏览器？

1.首先将我们的浏览器的主页面打开，尽量选择电脑本身自带的IE浏览器，以免其他的不能兼容。

2.点击浏览器右上角的设置按钮，在设置中我们可以找到有兼容模式，如果更改IE版本失败我们就只能尝试更改兼容模式。

3. 弹出的对话框中我们看见了最下端有兼容的勾选，建议大家可以将下面的选择都进行勾选上。

4.勾选完成之后我们还需要将上部的已经填写好的浏览器添加到下方的框中，全都选择好后就可以直接将其关掉即可。

5.最后我们将浏览器重新刷新一下就会看到报名的界面出来了。

扩展资料： IE11在IE10的基础上再次扩大对HTML5和CSS 3的支持，且添加的这些新特性多数均是非常新潮的特性(如HTML5拖放，HTML5全屏，CSS边框图，视频码率控制，视频字幕隐藏，媒体加密，WebGL等等)，使得IE11在显示HTML5网页时基本不出现到处不支持的问题。

IE11在功能上新增对Google的SPDY协议的支持，对Chakra进行了更多优化，硬件加速渲染相比IE9和IE10更快，在同样多加载项的情况下，IE11网页加载速度已超过WebKit和Blink内核浏览器，支持在后台智能预判并迅速在内存中取出已经看过的网页而不需要重新连接网站加载。

IE11浏览器怎么样？

IE11浏览器全新功能介绍： 1.IE11浏览器将会增加一个点击通话功能。

既IE11浏览器可以识别页面中的手机号码，并可以通过点击直接呼叫 2.IE11浏览器或将支持由Google主导的一款新型Web传输控制协议SPDY 3.可以让桌面版IE11浏览器用户在触屏设备上左右滑动实现后退和前进的操作。

4.在Metro版IE11浏览器中添加了下载管理器，可对下载文件进行移动、运行、查看下载状态或者删除下载等操作。

这对于不想在桌面上使用ie11的用户来说，是一个非常有帮助的功能 5.在Metro版IE11浏览器的选项中新增了追踪保护功能，在Metro版IE10浏览器下你想要更改追踪保护设置需要返回桌面版IE10浏览器中进行设置，在Metro版中加入该设置可以更方便的启用或禁用追踪保护