发送请求

“98/485，约20%”。

这是BlueSpike声称持有的美国专利数量与小米已获得授权的中国专利数量之比。单纯从数据来看，两者之间的差距似乎很大，而小米持有的专利规模要远大于BlueSpike。不过，BlueSpike却将小米起诉至美国法院，指责小米涉嫌侵犯其专利权。

11月19日，一家名为BlueSpike的NPE将小米东德州联邦地区法院马歇尔分院，诉至美国东德州联邦地区法院马歇尔分院，指责小米通过Tomtop销售的智能通信设备涉嫌侵犯其在美国拥有的专利权。

按照过往经验，伴随小米布局美国市场的步伐不断提速，自然会有越来越多NPE把小米当作攻击的“靶心”，那么，怀揣“美梦”的小米，到底该如何应对来自NPE的专利侵权诉讼“围剿”?

缘起：NPE诉讼策略坚持“冒头就打”?

众所周知，包括专利在内的各类知识产权保护具有较强的地域或国别属性。简单说，只有产品进入一国市场，才可能发生侵犯该国特定权利人知识产权的可能。

所谓NPE，是英文Non-Practicing Entity的缩写，中文名称为“非专利实施实体”或“非生产专利实体”。简单说，NPE是指代那些拥有专利但不从事专利产品生产的机构。

最常见的NPE应该算是科研机构，当然，还有一些NPE主要以专利授权许可为其主要盈利模式，同时以发起专利诉讼作为主要促成合作手段。

而作为一家NPE，BlueSpike对外宣称拥有98项专利，主要集中在“数据安全、深度检测、软件签名”等诸多领域。

美国专利商标局网站的统计数据显示，截止12月1日，BlueSpike的专利检索量为47件，小米手机的专利检索量为5件。

显然，仅从专利持有数量来看，BlueSpike并不算一家大型的NPE机构。但是，与小米相比，其专利规模优势还是比较领先的。

更重要的是，作为一家NPE机构，其以专利许可为核心业务，并不直接从事商品生产，势必增加了小米与其谈判合作的难度。

而从发起的专利诉讼来看，BlueSpike确实一家久经沙场的老手。比如，在2012年至2013年间，不到两年时间，BlueSpike曾以其持有的四项与信号提取(signal abstracting)相关的专利，前后在德州联邦地院提起超过70起的专利侵权诉讼，被告中不乏大众所熟知的Google、Yahoo、Adobe等公司。

根据一份哈佛大学的研究显示，从2001年到2011的十年之内，在美国内被NPE发起诉讼的企业从11家激增到336家。

而PatentFreedom2014年所作的统计显示，被NPE起诉的对象高达50%以上都是高科技产业。

事实上，大多数NPE机构多采取“冒头就打”的策略，通常会把知名公司列为靶心，有的会先发送侵权警告函，促使双方谈判，如果对方不予理会则会发起专利侵权诉讼。有的则跳过通知，直接发起专利诉讼。

教训：黑莓手机曾赔偿NPE6亿多美金

谈及NPE与实业公司之间的专利侵权纠纷，最著名的案例应该是发生在2000年-2006年间的黑莓手机被诉无线接收邮件专利侵权案。

当时，生产黑莓手机RIM公司的(全称“ResearchinMotion”)被一家名为NTP公司的NPE机构诉至美国弗吉尼亚东区联邦地区法院。

事实上，NTP公司也是一家小型NPE机构，其持有的专利仅有25件。但是，这家公司最终让黑莓支付了高达6.12亿美金的和解费用。

那么，这家小公司是如何让当时鼎鼎大名的黑莓手机付出了堪称天价的和解费用呢?究其原因有二，其一，该公司持有的专利含金量高;其二，黑莓历经6年还是无法赢得诉讼。

在该案中，NTP公司诉黑莓手机侵权的专利为“整合既存电子邮件系统(网络线系统，wireline systems)与广播频率(RF)无线通信网络”的系统科技，通过该技术可让手机用户通过无线网络接收电子邮件。

值得一提的是，NTP公司当时没有任何员工，而且诉争专利也非NTP公司直接发明。只不过，与电子邮件系统相关的五件美国专利后来都转至NTP公司名下。

2000年，NTP公司向RIM公司发出警告信函，索取授权金，RIM公司没有响应，随后，2001年11月13日， NTP公司将RIM公司诉至法院，声称黑莓手机侵犯了其五项专利中的40个系统请求项和方法请求项。

案件审理过程中，针对14件请求是否构成侵权，曾进入陪审团审理环节。陪审团于2002年11月21日作出裁决，认定RIM公司构成侵权，应赔偿约2300万美金。但RIM公司不服，要求法院直接判决，法院于2003年8月5日作出判决，认定RIM公司侵权，需支付约5300万赔偿金。

对此，RIM公司不服提起上诉，联邦巡回上诉法院作出判决，部分维持地区法院判决。此后，RIM公司试图上诉到联邦最高法院，但最高法院拒绝受理其案件。

专利诉讼期间，RIM公司也在通过申请专利无效试图“釜底抽薪”。但在联邦巡回上诉法院作出判决后，专利商标局才作出认定，认为该案系争专利全部无效。而NTP公司明确表示不服，将对专利无效认定向联邦巡回上诉法院提起诉讼。

至此，黑莓手机已基本穷尽了所有法律救济手段。迫不得已，RIM公司与NTP公司开始和解谈判，并于2006年达成和解，最终的和解费用高达6.12亿美金。包括：支付侵权的损害赔偿费用和未来永久使用的许可费用。

应对：针对不同NPE应采取差别策略

在美国，包括苹果、三星、HTC等在内的诸多知名企业，常常成为NPE机构发起的专利诉讼被告。

2015年2月25日，在Apple Watch以及新Macbook发布会前夕，苹果被美国联邦法院判决侵犯了Smartflash所拥有的三项专利，必须支付其5亿多美元的赔偿金。与此同时，这家名为Smartflash的NPE机构也将三星、谷歌、HTC起诉至法院。

显然，小米手机进军美国市场，面临的最大诉讼压力未必是来自同业竞争对手，而更多是NPE机构。那么，磨刀霍霍欲抢滩美国的小米，该如何应对来自NPE的“围剿”?

一般来说，根据NPE的运作模式或诉求不同，可以分为三类：1)研究型NPE机构，主要以科研机构为主，一般不以盈利为目的，侧重于科技创新，比如一些高校或科研院所;2)营利性NPE机构，主要通过许可授权或诉讼获得收入，由于自己不从事商品生产，不担心被诉也无专利交叉许可需求，比如高智公司，以及前文提到的BlueSpike、NTP、Smartflash等;3)联盟型NPE机构，此类NPE相当于特定领域或行业的联盟机构，通过汇集成员专利或购买专利，方便成员使用，比如美国专利公司RPX(Rational PatentExchange)。

由于不同NPE机构的诉求不同，面对来自NPE机构发起的专利诉讼，需要采取不同的策略。

首先，对于研究型NPE机构，应该加强合作。通过项目资助等方式，提早获得一些前瞻性技术专利的许可授权;

其次，对于联盟型NPE机构，可选择性加入。则需要根据自身的专利积累情况，结合所处行业的特点，选择加入一些NPE机构，通过支付少量的费用，获得大量的专利授权许可使用。

最后，对于营利性NPE机构，则需多加小心。从市场竞争的角度，可以在适当的时候，通过投资或入股的方式，掌握一定的NPE机构资源，藉此可以遏制竞争对手。而一旦被此类机构起诉，则需要综合考虑通过投资、谈判、诉讼以及无效认定等手段，有效化解一些风险。

对于小米来说，如果想好了要抢滩美国市场，也必须有全面的应对NPE机构策略，否则，稍有不慎，就可能为名所累，成为各路NPE机构争相起诉的对象，而一旦陷入诉讼泥潭中，漫长的诉讼周期以及高额的赔偿费用，都有可能把自己拖垮。

作者：李俊慧|来源：iDoNews专栏

DDoS攻击素来以成本低廉（相比防御）、效果显著、影响深远为攻击者所青睐，经过长时间的发展，DDoS攻击方式有很多种，最基本的DoS攻击利用单个合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。DoS攻击通常采用一对一的方式，在目标系统带宽、内存、CPU等各项性能指标都不高时，具有明显的效果。随着网络技术的发展，计算机的处理能力迅速增长，内存大大增加，千兆级别的网络出现，目标系统的“消化能力”倍增，这时候，分布式的拒绝服务攻击手段——DDoS就出现了。

利用网络上已被攻陷的电脑作为“肉鸡”，通过一定方式组合形成数量庞大的“僵尸网络”，采用一对多的方式进行控制，向目标系统同时提出服务请求，杀伤力大幅度增加。DDoS攻、防对抗多年，从DoS到DDoS，从以流量取胜到以技巧取胜，从单一攻击到混合攻击，攻击手段正不断进化，本文将一一介绍最常见、最具代表性的攻击方式，企业运营者做到知己知彼，才能有备无患。

一、攻击带宽：以力取胜

如同城市堵车一样，当数据包超过带宽上限，就会出现网络拥堵、响应缓慢的情况。流量型DDoS攻击就是如此，发送海量数据包，顷刻占满目标系统的全部带宽，正常请求被堵在门外，拒绝服务的目的达成。

ICMPFlood

ICMP（Internet控制报文协议）用于在IP主机、路由器之间传递控制消息，控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息，虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。通过对目标系统发送海量数据包，就可以令目标主机瘫痪，如果大量发送就成了洪水攻击。

UDPFlood

UDP协议是一种无连接的服务，在UDPFlood中，攻击者通常发送大量伪造源IP地址的小UDP包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。100kbps的UDPFlood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。

上述传统的流量型攻击方式技术含量较低，伤人一千自损八百，攻击效果通常依赖受控主机本身的网络性能，而且容易被查到攻击源头，单独使用的情况已不常见。于是，具有四两拔千斤效果的反射型放大攻击就出现了。

NTPFlood

NTP是标准的基于UDP协议传输的网络时间同步协议，由于UDP协议的无连接性，方便伪造源地址。攻击者使用特殊的数据包，也就是IP地址指向作为反射器的服务器，源IP地址被伪造成攻击目标的IP，反射器接收到数据包时就被骗了，会将响应数据发送给被攻击目标，耗尽目标网络的带宽资源。一般的NTP服务器都有很大的带宽，攻击者可能只需要1Mbps的上传带宽欺骗NTP服务器，就可给目标服务器带来几百上千Mbps的攻击流量。

因此，“问-答”方式的协议都可以被反射型攻击利用，将质询数据包的地址伪造为攻击目标地址，应答的数据包就会都被发送至目标，一旦协议具有递归效果，流量就被显著放大了，堪称一种“借刀杀人”的流量型攻击。

面对洪水般的流量，花高价进行抗D带宽扩容和多运营商链路冗余，虽一定程度可提升抗D能力，但面对大量攻击仍旧于事无补，而且浪费资源。知道创宇旗下抗DDoS云防御平台——抗D保，横跨全国的分布式数据中心，600G以上带宽抗DDoS，并可随时应急调用腾讯自有带宽1.5Tb，这使得抗D保拥有超过2个Tb的防御能力。 

二、攻击系统/应用：以巧取胜

这类型的DDoS攻击走的是巧劲，利用各种协议的行为特性、系统的缺陷、服务的脆弱性、软件的漏洞等等发起攻击，不断占用目标系统的资源以阻止它们处理正常事务和请求。

SYNFlood

这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。建立TCP连接，需要三次握手——客户端发送SYN报文，服务端收到请求并返回报文表示接受，客户端也返回确认，完成连接。

SYNFlood就是用户向服务器发送报文后突然死机或掉线，那么服务器在发出应答报文后就无法收到客户端的确认报文（第三次握手无法完成），这时服务器端一般会重试并等待一段时间后再丢弃这个未完成的连接。一个用户出现异常导致服务器的一个线程等待一会儿并不是大问题，但恶意攻击者大量模拟这种情况，服务器端为了维护数以万计的半连接而消耗非常多的资源，结果往往是无暇理睬客户的正常请求，甚至崩溃。从正常客户的角度看来，网站失去了响应，无法访问。

CC 攻击

CC攻击是目前应用层攻击的主要手段之一，借助代理服务器生成指向目标系统的合法请求，实现伪装和DDoS。我们都有这样的体验，访问一个静态页面，即使人多也不需要太长时间，但如果在高峰期访问论坛、贴吧等，那就很慢了，因为服务器系统需要到数据库中判断访问者否有读帖、发言等权限。访问的人越多，论坛的页面越多，数据库压力就越大，被访问的频率也越高，占用的系统资源也就相当可观。

CC攻击就充分利用了这个特点，模拟多个正常用户不停地访问如论坛这些需要大量数据操作的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的请求，网络拥塞，正常访问被中止。这种攻击技术性含量高，见不到真实源IP，见不到特别大的异常流量，但服务器就是无法进行正常连接。

之所以选择代理服务器是因为代理可以有效地隐藏自己的身份，也可以绕开防火墙，因为基本上所有的防火墙都会检测并发的TCP/IP连接数目，超过一定数目一定频率就会被认为是Connection-Flood。当然也可以使用肉鸡来发动CC攻击，攻击者使用CC攻击软件控制大量肉鸡发动攻击，肉鸡可以模拟正常用户访问网站的请求伪造成合法数据包，相比前者来说更难防御。

CC攻击是针对Web服务在第七层协议发起的攻击，在越上层协议上发动DDoS攻击越难以防御，上层协议与业务关联愈加紧密，防御系统面临的情况也会更复杂。比如CC攻击中最重要的方式之一HTTPFlood，不仅会直接导致被攻击的Web前端响应缓慢，对承载的业务造成致命的影响，还可能会引起连锁反应，间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务。

由于CC攻击成本低、威力大，知道创宇安全专家组发现80%的DDoS攻击都是CC攻击。带宽资源严重被消耗，网站瘫痪；CPU、内存利用率飙升，主机瘫痪；瞬间快速打击，无法快速响应。知道创宇顶级安全研究团队为抗D保自主研发的Anti-CC防护引擎可以根据访问者的URL、频率、行为等访问特征，智能识别CC攻击，迅速识别CC攻击并进行拦截，在大规模CC攻击时可以避免源站资源耗尽，保证企业网站的正常访问。

抗D保-抗CC攻击数据（监控）

DNSQueryFlood

DNS作为互联网的核心服务之一，自然也是DDoS攻击的一大主要目标。DNSQueryFlood采用的方法是操纵大量傀儡机器，向目标服务器发送大量的域名解析请求。服务器在接收到域名解析请求时，首先会在服务器上查找是否有对应的缓存，若查找不到且该域名无法直接解析时，便向其上层DNS服务器递归查询域名信息。

通常，攻击者请求解析的域名是随机生成或者是网络上根本不存在的域名，由于在本地无法查到对应的结果，服务器必须使用递归查询向上层域名服务器提交解析请求，引起连锁反应。解析过程给服务器带来很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS服务器的脆弱性。

抗D保在全国多个城市采用分布式集群方式部署了上千台高效DNS服务器，从而保证各个地区的查询响应速度。抗D保的高防DNS服务，可有效解决突发的上亿级别的随机HOSTA记录查询攻击、递归DNS穿透攻击、DNS流量攻击等多种针对域名解析的攻击请求。

抗D保防御DNS攻击效果示意

三、混合攻击：流量与技巧并用

在实际情况中，攻击者只求达到打垮对方的目的，发展到现在，高级攻击者已经不倾向使用单一的攻击手段作战了，而是根据目标系统的具体环境灵动组合，发动多种攻击手段，既具备了海量的流量，又利用了协议、系统的缺陷，尽其所能地展开攻势。

对于被攻击目标来说，需要面对不同协议、不同资源的分布式的攻击，分析、响应和处理的成本就会大大增加。

抗D保拥有国内最大的抗D集群，使用腾讯宙斯盾流量清洗设备并结合由知道创宇研发的Anti-DDoS引擎，5秒发现恶意攻击，10秒快速阻断，2T带宽储备，通过多种防御手段，防御各种类型、形态的DDoS攻击，包括基于网络层的攻击，如TCPFlood、UDPFlood、ICMPFlood，以及应用层攻击，类似HTTPFlood这种试图耗尽服务器资源的攻击，同时可以有效防御各种反射攻击和僵尸网络攻击。

面对一次次攻击，即使是去年10月让美国半个互联网瘫痪的DDoS攻击事件，也只是让很多人小心脏稍微颤抖了几下，在大家的印象中，DDoS只是一阵海啸，很快就能恢复了往日的平静。但是，DDoS在互联网发展进程中已经留下了太多不可磨灭的破坏，许多企业就此一蹶不振。而且随着互联网+的不断推进，商业竞争的愈演愈烈，它的危害越来越大，任何企业组织都应该考虑自己的DDoS防护方案，而不是成为攻击的炮灰，也尽量避免遭受攻击后再亡羊补牢。

相关新闻

2016-12-20

2017-03-06

2017-07-28

2017-08-17

2017-09-04

随着互联网的发展，越来越多的业务不仅仅由单一节点（或是单一语言）就可承载，而是趋向多语言分布式协同开发（如接入层由Node.js完成，逻辑（数据）层由C++/GO/Python实现）并由此组成大型异构系统。

我们（现SuperTeam）基于 Tars 体系研发出 Tars.js 以便用户在不改变异构系统整体架构的情况下快速搭建（迁移）Node.js服务，并可非常方便的将原来的单一服务拆分为多个（逻辑）子服务。

Tars.js在腾讯内部经过5年多的沉淀与迭代（Node.js@0.10版本即提供支持），广泛运用于腾讯QQ浏览器、腾讯桌面浏览器、腾讯地图、应用宝、腾讯手机管家、互联网+、腾讯医疗、腾讯觅影、保险、彩票等几十个重要业务中，日承担了上百亿流量。

Tars.js包含下述特性：

l 100%由JavaScript编写，不包含任何C/C++代码。

l 多进程负载均衡与管理。

l 代码异常监控与重启。

l 服务日志搜集与处理。

l HTTP(s)服务监控与用量自动上报，并支持用户自定义维度上报（PP监控）。

l 符合 Tars(IDL)规范的编解码模块。

l 支持 TarsRPC调用与染色（模调自动上报）。

l 支持在线发送管理命令、拉取服务配置。

l 独创 LongStackTrace™异常跟踪机制。

l …… 更多特性可访问 @tars/node-agent 了解

设计理念：

»A．高自由度：

l 兼容所有（≥0.10）官方Node.js版本。

l 对 Node.js源码无侵入无修改。

l 底层对上层完全透明，支持各种上层框架，无需变更。

也就是说：

您可以使用任何您熟悉的框架（如 Express.js/Koa.js等，包括但不仅限于Web框架），也无需对框架进行任何修改（无需引入任何中间件）。即可通过Tars.js运行，享受平台提供的各种监控与管理特性。

与此同时，Tars.js所提供的模块，也可以根据您的需求引入（如未使用到则可不引入）。

»B．高性能：

Tars.js为高性能与大并发量而设计，使用了大量的前端（V8）优化技巧（如FlattenString/FastProperties等）尽量降低所提供的能力对于业务性能的影响。

经过我们测试（WebServer），默认的旁路上报与监控对服务性能的影响≤5%，常用模块（RPC、日志等）性能位于业界前列。

»C．差异化：

Tars.js根据不同的业务类型提供差异化运营方案：

l 高流量业务：尽力降低框架对业务性能的影响。

l 低流量业务：充分利用硬件资源提升开发体验。

HelloWorld

我们来看Node.js官网的 例子 (如下)，无需任何变更，直接通过Tars.js进行部署，它会拥有哪些特性？

✓ 进程管理

默认基于 cluster 模块进行负载均衡，进程数可以配置为1~max（CPU核心数）、还可配置为auto（物理核心数相同）以减小内存压力提升“性价比”。

与此同时，进程僵死检测也会同时启动，实时监控业务进程。

»案例说明

某服务在论坛UBB代码转HTML时，使用未优化的正则表达式进行XSS攻击过滤，但由于用户发帖时图片采用BASE64编码，导致正则表达式计算时间过长，CPU使用率飙涨到100%：

开启僵死检测后，Tars.js监控到业务进程僵死时，自动重启业务进程，从而缩短了业务无响应时间：

Tars.js虽然无法解决业务代码的问题（BUG），但会尽最大努力保证业务的可用性。

✓ 服务监控

以服务名、接口名（URL-PATH节）为纬度，统计总流量、平均耗时、超时率、异常率：

其中返回码大于400（可配置）作为异常进行上报。

»监控说明

Web服务一般由静态与动态资源（接口）组成，由于静态资源（本地文件）的请求耗时远低于动态资源（业务逻辑），请求量往往又很高，拉低了服务整体耗时。

基于此，Tars.js将请求URL中的PATH节作为接口，每个接口均可查看其总流量、平均耗时、异常率，便于用户全面了解服务性能。

✓ 特性监控

无论您服务的类型是什么，总是会上报下述特性，便于回溯问题与评估性能：

l memUsage：内存用量，将会上报rss、heapUsed、heapTotal这三个用量（单位为字节）

l cpuUsage：CPU用量，将会上报CPU使用率，数据汇总为逻辑单核（单位为百分比）

l eventloopLag：（任务）队列延迟，每隔2秒采样（单位为毫秒）

l libuv：I/O用量，将会上报activeHandles、activeRequests这两个用量

各策略以平均值（Avg）、最大值（Max）、最小值（Min）分节点进行统计：

✓ 日志输出

所有通过Console模块（如console.log）输出的日志，都会输出到服务本地文件内。并附加相关信息（如下），方便定位问题。

日志格式：日期时间|进程PID|日志级别|输出文件名与行号|日志内容

2018-07-0112:00:00|332|DEBUG|app.js:13|Serverrunningathttp://127.0.0.1:3000/

✓ LongStackTrace™

由于Node.js采用异步机制，在发生异常时堆栈不完整，导致定位问题复杂。

鉴于此，我们提供了长链路跟踪技术在产生异常时自动附加前序调用堆栈，同时还支持在异常堆栈中过滤出用户代码部分。

由于开启此特性时会造成性能损耗，故默认关闭，管理平台等性能不敏感业务可直接通过配置开启。

»案例说明

执行上述代码会抛出下述异常：

ReferenceError:ThisMayThrowErrorisnotdefined

atTimeout.setTimeoutas_onTimeout

at_disibledevent="http://superzheng.com/">@SuperZheng 创立于2017年。团队成员均为全栈架构师（Super寓意Superman——无所不能），熟知Web(3D)、终端、后端与大数据计算，并由传统前端向互联网从业者方向发展。欢迎前端牛人加入，共创前端美好未来。