万维网 的核心语言、 标准通用标记语言 下的一个应用 超文本标记语言 （ HTML ）的第五次重大修改（这是一项推荐标准、外语原文： W3C Recommendation、见本处 参考资料 原文内容：[1]
）。
2014年10月29日， 万维网联盟 宣布，经过接近8年的艰苦努力，该标准规范终于制定完成。
发展历程
标准通用标记语言 下的一个应用 HTML 标准自1999年12月发布的HTML4.01后，后继的HTML5和其它标准被束之高阁，为了推动Web标准化运动的发展，一些公司联合起来，成立了一个叫做 Web Hypertext Application Technology Working Group （Web 超文本 应用技术工作组 - WHATWG ） 的组织。WHATWG 致力于 Web 表单和应用程序，而 W3C （World Wide Web Consortium， 万维网 联盟） 专注于 XHTML 2.0。在 2006 年，双方决定进行合作，来创建一个新版本的 HTML。
HTML5草案的前身名为 Web Applications 1.0，于2004年被WHATWG提出，于2007年被W3C接纳，并成立了新的 HTML 工作团队。
HTML 5 的第一份正式草案已于2008年1月22日公布。HTML5 仍处于完善之中。然而，大部分 现代浏览器 已经具备了某些 HTML5 支持。
2012年12月17日， 万维网联盟 （W3C）正式宣布凝结了大量网络工作者心血的HTML5规范已经正式定稿。根据W3C的发言稿称：“HTML5是开放的Web网络平台的奠基石。”
2013年5月6日， HTML 5.1正式草案公布。该规范定义了第五次重大版本，第一次要修订 万维网 的核心语言：超文本标记语言（ HTML ）。在这个版本中，新功能不断推出，以帮助Web应用程序的作者，努力提高新元素互 *** 作性。
本次草案的发布，从2012年12月27日至今，进行了多达近百项的修改，包括HTML和XHTML的标签，相关的 API 、 Canvas 等，同时HTML5的图像img标签及svg也进行了改进，性能得到进一步提升。
支持Html5的浏览器包括 Firefox （火狐浏览器）， IE9 及其更高版本， Chrome （谷歌浏览器）， Safari ，Opera等；国内的傲游浏览器（Maxthon），以及基于IE或 Chromium （Chrome的工程版或称实验版）所推出的 360浏览器 、 搜狗浏览器 、 QQ浏览器 、 猎豹浏览器 等国产浏览器同样具备支持HTML5的能力。
在移动设备开发HTML5应用只有两种方法，要不就是全使用HTML5的语法，要不就是仅使用JavaScript引擎。
JavaScript 引擎的构建方法让制作手机网页游戏成为可能。由于界面层很复杂，已预订了一个 UI 工具包去使用。
纯HTML5手机应用运行缓慢并错漏百出，但优化后的效果会好转。尽管不是很多人愿意去做这样的优化，但依然可以去尝试。
HTML5手机应用的最大优势就是可以在网页上直接 调试 和修改。原先应用的开发人员可能需要花费非常大的力气才能达到HTML5的效果，不断地重复编码、调试和运行，这是首先得解决的一个问题。因此也有许多手机杂志客户端是基于HTML5标准，开发人员可以轻松调试修改。
2014年10月29日，万维网联盟泪流满面地宣布，经过几乎8年的艰辛努力，HTML5标准规范终于最终制定完成了，并已公开发布。
在此之前的几年时间里，已经有很多开发者陆续使用了HTML5的部分技术， Firefox 、 Google Chrome 、Opera、Safari 4+、Internet Explorer 9+都已支持HTML5，但直到今天，我们才看到“正式版”。
HTML5将会取代1999年制定的HTML 4.01、XHTML 1.0标准，以期能在互联网应用迅速发展的时候，使网络标准达到符合当代的网络需求，为桌面和移动平台带来无缝衔接的丰富内容。
W3C CEO Jeff Jaffe博士表示：“HTML5将推动Web进入新的时代。不久以前，Web还只是上网看一些基础文档，而如今，Web是一个极大丰富的平台。我们已经进入一个稳定阶段，每个人都可以按照标准行事，并且可用于所有浏览器。如果我们不能携起手来，就不会有统一的Web。”
HTML5还有望成为梦想中的“开放Web平台”(Open Web Platform)的基石，如能实现可进一步推动更深入的跨平台Web应用。
接下来，W3C将致力于开发用于实时通信、 电子支付 、应用开发等方面的标准规范，还会创建一系列的隐私、安全防护措施。
W3C还曾在2012年透露说，计划在2016年底前发布HTML 5.1。
HTML介绍分为3部分，第一部分是HTML简介及历史，第二部分是HTML元素，第三部分是实战及学习笔记。
以下是第一部分：
参考资料：
w3.org, html 文档
HTML，即Hypertext markup language是万维网的核心标记语言，最初HTML被设计作为一门语言，用于语言描述科学文档，后续则被拓展用于描述一系列不同类型的文档，甚至应用。
1990-1995，迅速发展，从CERN到IETF(国际互联网工作组)接管.
1995-1997, 随着W3C建立，又变成由W3C主导，期间推出了HTML 3.2 和HTML 4.01
1998-2000，W3C停止HTML版本推进，开始研究XHTML 1.0（XML-based HTML 4.01), 其没有添加任何新特性，反而更加地长篇累牍，更严格的检测标准等。后续发布了XHTML 2.0，其与XHTML 1.0，HTTP 4.01不兼容。
期间直到2003，HTML没有版本的变化，但期间出现了 DOM Level 1 &2，提高了客户端的使用体验以及功能拓展。
2003，XForms(定位于下一代Web form)发布，其证明了很多它所拥有的新特性能拓展到HTML 4.01，Mozilla及Opera借此于2004年向W3C提出了更新HTML版本的提议，但W3C选择继续发展XML-based作为替代HTML。
于是Mozilla, Opera联合Apple组成新实体WHATWG，发展HTML 的Living document，对HTML继续进行拓展及新特性添加，直到后期W3C才转回HTML标准的制定，多谢WHATWG，才有了我们今天基本采用的HTML 5。
W3C与WHATWG于2008年一起发布了第一份草案，2014年正式发布HTML 5。
*MDN Web Docs 简介：Mozilla Developer Network的后续，致力于Web标准文档的发展以及Web开发资料分享，包括HTML5, JavaScript, CSS, Web APIs, Node.js以及网络扩展等
*HTML/XML/DOM等的语法上的一些区别：
namespaces不能用在HTML语法中，但可用作DOM及XHTML里；
<noscript>可被用在HTML里，但不能用在DOM,XHTML里，
-->仅仅能用在DOM里。
*Text: in the context of content models, means either nothing, or Text nodes. Text is sometimes used as a content model on its own, but is also phrasing content, and can be inter-element white space
Text nodes and attribute values must consist of Unicode characters
*<html>end tag, <head>start tag, end tag, <body>start tag, end tag等在满足一定条件情况下可以省略，更多可以省略的可以参考 这里 。
*块级及内联元素
块级元素会以可见的块呈现在页面上，其显示会与其前后的content有一行的间距，常用于呈现结构化的elements，如paragraph, list, nav, footer等，块级元素不能被内嵌在内联元素之中，块通常只出现在<body>里。
内联元素是包含在块里的，仅仅只包含一小部分内容，常呈现在段落里，如<a>, <em>, <strong>等。其存在将不会导致新的一行的产生。
注意可以使用css display 属性，设置inline为block。
*HTML parsing model
*<audio>, <canvas>, <embed>, <iframe>, 及MathTL, SVG里的元素为embeded元素
*元素是大小写不敏感的
WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）
首先HTTP有 1.1 和 1.0 之说，也就是所谓的 keep-alive，把多个HTTP请求合并为一个，但是 Websocket 其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充
他们有交集，但是并不是全部。
另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。通俗来说，你可以用HTTP协议传输非Html数据，就是这样=。=
再简单来说，层级不一样。
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。
HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。
教练，你BB了这么多，跟Websocket有什么关系呢？ (:з」∠) 好吧，我正准备说Websocket呢。。
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
首先我们来看个典型的 Websocket 握手（借用Wikipedia的。。）
熟悉HTTP的童鞋可能发现了，这段类似HTTP协议的握手请求中，多了几个东西。我会顺便讲解下作用。
这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。
首先， Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：泥煤，不要忽悠窝，我要验证尼是不是真的是Websocket助理。
然后， Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~
最后， Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft（协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦 大家都使用的一个东西 脱水： 服务员，我要的是13岁的噢→_→
然后服务器会返回下列东西，表示已经接受到请求， 成功建立Websocket啦！
这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~
Upgrade: websocket
Connection: Upgrade
依然是固定的，告诉客户端即将升级的是 Websocket 协议，而不是mozillasocket，lurnarsocket或者shitsocket。
然后， Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。 服务器：好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。。
后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。
至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。
——————技术解析部分完毕——————
你TMD又BBB了这么久，那到底Websocket有什么鬼用， http long poll ，或者ajax轮询 不都可以实现实时信息传递么。
好好好，年轻人，那我们来讲一讲Websocket有什么用。来给你吃点胡（苏）萝（丹）卜（红）
在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。
ajax轮询
ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
场景再现：
long poll
long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
场景再现：
从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。
何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。
简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。
说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）
从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。
ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
所以 ajax轮询 和 long poll 都有可能发生这种情况。
言归正传，我们来说Websocket吧
通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。
一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。
哦对了，忘记说了HTTP还是一个状态协议。
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。
就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你 ）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。
本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。
这样就可以解决客服处理速度过慢的问题了。
同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。
虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。
但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。
同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了
——————–
至于怎么在不支持Websocket的客户端上使用Websocket。。答案是： 不能
但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）