IT瘾下载推荐

Meta 从盗版电子书库下载了逾百 TB 的电子书

Fri, 07 Feb 2025 23:48:52 CST

图书作者指控社交巨头 Meta 下载了盗版电子书去训练其 AI 模型，最新证据显示 Meta 的盗版规模惊人。Meta 通过安娜的档案（Anna's Archive）下载了至少 81.7 TB 的数据，其中包括来自 Z-Library 和 LibGen 的至少 35.7 TB 的数据(安娜的档案包含了 Z-Lib、Sci-Hub 和 LibGen 的镜像站)。Meta 之前还从 LibGen 下载了 80.6 TB 的数据。图书作者称，Meta 非法的电子书库种子下载规模惊人，认为这只是冰山一角，这些盗版电子书库仅占 Meta 盗版版权作品数量的 0.008%。

免费可商用开源GPT模型问世，50G权重直接下载，性能不输GPT-3

Sun, 02 Apr 2023 16:21:11 CST

萧箫发自凹非寺
量子位 | 公众号 QbitAI

真·开源GPT模型，终于来了。

参数量级130亿，大小比肩最近Meta开放的LLaMA-13B，但从数据集、模型权重到计算优化训练， 全部开源。

最关键的是， 可商用。

没错，虽然就GPT-3而言，之前DeepMind、Meta等组织陆陆续续开源过几个模型，不过基本都是半遮半掩。

尤其最接近GPT-3的Meta OPT模型，不仅权重只开放给研究者，而且不可商用：

这意味着之前企业就算能抄作业，抄来的也没办法直接用。

现在，一家名叫Cerebras的公司开源了这一系列GPT模型，业界终于有机会追赶了。

模型性能如何？

Cerebras一共开源了7个GPT模型，参数量分别达到1.11亿、2.56亿、5.9亿、13亿、27亿、67亿和130亿。

据Cerebras公司表示，他们开放出来的模型不仅包含数据集，可用于研究也可商用，而且关键是预训练模型权重开放（从下图来看文件大小近50G）。

基于他们公开的预训练模型，大伙儿只需要用少量的数据对对模型进行微调，就能构建出效果不错的模型来。

除此之外，这次GPT模型的训练还额外考虑到了 计算优化训练 （Compute-Optimal Training）。

这个方法最早由DeepMind在2022年提出，名叫Chinchilla，它认为大语言模型的语料数量和模型效果之间符合一个凸曲线，因此模型参数量和训练程度成一定比例。

依据这个方法，DeepMind认为，包括GPT-3在内的超大参数LLM模型，有很多都是 训练不足的。

基于此，Cerebras搞出了这一系列GPT模型，并将背后的流程进行了开源。

所以，Cerebras-GPT系列模型性能如何呢？

团队将Cerebras-GPT系列和LLaMA、GPT-3等模型的性能进行了对比。

这是包括GPT-3、Gopher、Chinchilla和LLaMA在内的其他GPT模型，在完成句子、问答等特定任务上表现的效果。

这是不同大小的Cerebras-GPT模型零次学习（0-shot）的效果：

数据对比不是特别直观，团队还将结果进行了可视化。

可以看出，在最终性能相差不大的情况下，Cerebras-GPT的 训练效率要更高一些。

曾开发最大AI芯片

其实，Cerebras的“本职”是一家AI芯片公司。

Cerebras公司由Sean Lie和Andrew Feldman等人于2016年创立。

其中，Andrew Feldman曾创建微型服务器公司SeaMicro，并以3.34亿美元的价格出售给AMD。

与其他AI芯片公司不同，Cerebras开发的芯片超大，像晶圆一样（但确实是芯片）：

他们当年做出来过一个名叫“晶圆级引擎”（Cerebras Wafer Scale Engine，简称WSE）的AI芯片，将逻辑运算、通讯和存储器集成到单个硅片上，一口气创下了 4项世界纪录：

晶体管数量最多的运算芯片：总共包含1.2万亿个晶体管。虽然三星曾造出2万亿个晶体管的芯片，却是用于存储的eUFS。
芯片面积最大：尺寸约20厘米×23厘米，总面积46,225平方毫米。面积和一块晶圆差不多。
片上缓存最大：包含18GB的片上SRAM存储器。
运算核心最多：包含40万个处理核心。

后来这个超大WSE又升级了二代，然后团队基于WSE-2打造出了一个名叫Cerebras CS-2的AI超算。

这次的Cerebras-GPT系列模型，就是在这个Cerebras CS-2的AI超算中训练出来的。对此这家公司表示：

虽然训练这么大体量的模型通常需要几个月时间，但我们几周就能搞定。

Cerebras还表示，虽然很多硬件公司都声称训练效果能接近 英伟达GPU的水平，但他们还没看到任何一家亲自推动开源LLM的硬件公司，这势必不利于开源LLM的发展。

这波啊，这波Cerebras格局大了（手动狗头）

模型地址：
https://huggingface.co/cerebras/Cerebras-GPT-13B

参考链接：
https://www.cerebras.net/blog/cerebras-gpt-a-family-of-open-compute-efficient-large-language-models/

PDF 预览和下载你是怎么实现的？ - 掘金

Mon, 06 Mar 2023 13:47:10 CST

前言

在开发过程中要求对 PDF类型的发票提供预览和下载功能， PDF类型文件的来源又包括 H5 移动端和 PC 端，而针对这两个不同端的处理会有些许不同，下文会有所提及。

针对 PDF 预览的文章不在少数，但似乎都没有提及可能遇到的问题，或是提供对应的具体需求场景下如何选择，因此，本文的核心就是结合实际需求场景下，看看目前各种实现方案到底哪一个更适合，当然希望大家可以在评论区对文中的内容进行斧正，或是提供更优质的方案。

基本要求：

支持 pdf 文件内容的 完整预览
多页 pdf 文件支持 分页查看
PC 端和 移动端都需支持下载和预览

产品要求：

PC 端的预览要支持在 当前页进行预览
pdf 文件预览时的字体要和实际文件的 字体保证一致性

PDF 预览

先抛开上面的各种要求，咱们先总结下目前实现 PDF预览的几种常用方式：

借助各种类库，基于代码实现预览，如基于 pdfjs-dist的包
直接基于各个浏览器内置的 PDF预览插件，如 <iframe src="xxx">、<embed src="xxx" >
服务端将 PDF文件转换成图片

接下来分别看看以上方案如何实现，以及是否符合上述提供的要求！

`<embed> / <iframe>`实现预览

`<embed>`标签

<embed> 元素将外部内容嵌入文档中的指定位置，此内容由 外部应用程序或 其他交互式内容源（如 浏览器插件）提供。

说简单点，就是使用 <embed>来展示的资源是完全交由它所在的环境提供的展示功能，即如果当前的应用环境支持这个资源的展示那么就可以正常展示，如果不支持那就无法展示。

使用起来也是非常简单：

      <embed
 type="application/pdf":src="pdfUrl"width="800"height="600"/>复制代码

多数现代浏览器已经弃用并取消了对浏览器插件的支持，现在已经不建议使用 <embed>标签，但可以使用 <img>、<iframe>、<video>、<audio>等标签代替。

`<iframe>`标签

基于 <iframe>的方式和以上差不多，整体效果也一致，这里这就不在额外展示：

      <iframe
 :src="pdfUrl"width="800"height="600"/>复制代码

值得注意的是，即便使用的是 <iframe>但实际展开其内层结构后你会发现：

其内部还是 <embed>标签？这是怎么回事，不是说最好不建议使用 <embed>吗？

首先来在 caniuse查看兼容情况，如下：

我们再找一个不支持 <embed>的浏览器，比如 IE，来试试效果：

换成 <iframe>试试，如下：

显然， <embed>在不兼容的环境直接无法显示，而 <iframe>是能够正常识别的，只不过 <iframe>加载的资源无法被 IE浏览器处理，即本质原因是 IE浏览器根本就不支持对类似 PDF等文件的预览，比如当尝试直接在地址栏中输入 http://127.0.0.1:3000/src/assets/2.pdf时会得到：

因此，通常情况下当浏览器不支持内联 PDF时，应该提供一个 PDF的回退链接，即以下载的方式来实现，而这就是 pdfobject做的事情，实际上它的源码内容比较简单，核心就是 PDFObject 会检测浏览器对内联/嵌入 PDF 的支持，如果支持嵌入，则嵌入 PDF，如果浏览器不支持嵌入，则不会嵌入 PDF，并提供一个指向 PDF 的回退链接，例如在 IE中的表现：

事实上，这其实只是帮我们少写了一些兼容性的代码而已，也不一定符合大部分人的场景，在这里提到只是因为其与 <embed>之间存在的联系。

vue3-pdfjs 实现预览

为什么不直接使用 `pdfjs-dist`?

pdf.js几个明显的可吐槽的点：

包名称不统一， npm上的包名叫 pdfjs-dist，然而在 Readme中自己又称其为 pdf.js
没有清晰的文档作为指引，只能通过其仓库中的 examples目录的内容作为参考
官方示例不够友好，例如没有提供 vue/react等相关的示例
直接使用需要引入很多文档没有指明的内容
有时展示的 pdf内容文字模糊或缺少部分等
...

因此，既然已经有基于 vue/react封装好的包，这里就直接用来作为演示。

具体使用

安装和使用过程可参考 vue3-pdfjs，具体 Vue3示例代码如下：

      <script setup lang="ts">import{ onMounted, ref }from'vue'import{VuePdf, createLoadingTask }from'vue3-pdfjs/esm'importtype {VuePdfPropsType}from'vue3-pdfjs/components/vue-pdf/vue-pdf-props'// Prop type definitions can also be importedimporttype {PDFDocumentProxy}from'pdfjs-dist/types/src/display/api'importpdfUrlfrom'./assets/You-Dont-Know-JS.pdf'constpdfSrc = ref<VuePdfPropsType['src']>(pdfUrl)constnumOfPages =ref(0)onMounted(() =>{constloadingTask =createLoadingTask(pdfSrc.value)
  loadingTask.promise.then((pdf: PDFDocumentProxy) =>{
    numOfPages.value= pdf.numPages})
})
</script><template><VuePdfv-for="page in numOfPages":key="page":src="pdfSrc":page="page"/></template><style>@import'@/assets/base.css';</style>复制代码

效果如下：

存在问题

看上去加载正常的 pdf 文档似乎没啥大问题，来试试加载 pdf 发票看看，但由于实际发票敏感信息较多，这里就不贴出原本的发票内容，直接来看预览后的发票内容：

显然整体发票的 内容缺失得非常多，虽然某些发票大部分能够展示，但如 发票抬头和印章部分可能无法正常显示等

【注意】无法显示完整的内容是因为 pdf.js是需要一些字体库的支持，如果 原 PDF 文件中部分字体没有匹配到字体库将无法在 pdf.js中显示，而字体库存放在 cmaps文件夹下

另外， 预览的字体和 实际的字体是 不一致的，而由于发票的特殊性，对字体的一致性是有较大的要求，毕竟如果同一张发票字体不一致会缺乏规范性和合法性（ 被要求字体一致时的说法）

常见的解决方案： 解决 pdf.js 无法完全显示 pdf 文件内容的问题，实际上还是根据执行环境的错误信息进行分析，需要强行修改源码内容。

Mozilla Firefox（火狐浏览器）

Mozilla Firefox 内置的 PDF 阅读器实际就是 pdf.js，你可以直接用火狐浏览器预览一下 pdf文件，如下：

并且大多基于 pdf.js二次封装的库 vue-pdf、vue3-pdfjs等在预览 pdf文件的发票时通常无法显示完整内容，需要或多或少的涉及对源码的更改，而在 Firefox中内置的 pdf.js却能够完整的显示对应的 pdf文件的内容。

`PDF`转 `图片`实现预览

这种方式应该不用多说了，核心是服务端在响应 pdf文件时，先转换成图片类型再返回，前端直接展示具体图片内容即可。

具体实现

下面通过用 node来模拟：

      constpdf =require('pdf-poppler')constpath =require('path')constKoa=require('koa')constkoaStatic =require('koa-static')constcors =require('koa-cors')constapp =newKoa()// 跨域app.use(cors())// 静态资源app.use(koaStatic('./server'))functiongetFileName(filePath) {returnfilePath
    .split('/')
    .pop()
    .replace(/\.[^/.]+$/,'')
}functionpdf2png(filePath) {// 获取文件名constfileName =getFileName(filePath);constdir = path.dirname(filePath);// 配置参数constoptions = {format:'png',out_dir: dir,out_prefix: fileName,page:null,
  }// pdf 转换 pngreturnpdf
    .convert(filePath, options)
    .then((res) =>{console.log('Successfully converted ！')return`http://127.0.0.1:4000${dir.replace('./server','')}/${fileName}-1.png`})
    .catch((error) =>{console.error(error)
    })
}// 响应app.use(async(ctx) => {if(ctx.path.endsWith('/getPdf')){consturl =awaitpdf2png('./server/pdf/2.pdf')
        ctx.body= { url }
    }else{
        ctx.body='hello world!'}
})

app.listen(4000)复制代码

避免踩一些坑

坑一：不推荐 pdf-image

在实现服务端将 pdf文件转换成图片时需要依赖到一些第三方包，一开始使用了 pdf-image这个包，但在实际转换时发生较多的异常错误，顺着错误查看源码后发现其内部需要依赖一些额外的工具，因为其中需要使用 pdfinfo xxx相关命令，并且其对应的 issue上也存在着一些类似问题，但都试了试最后还是没有成功！

因此，更推荐使用 pdf-poppler其中附带了一个 pdftocairo的程序可以实现 pdf到图片的转换能力，不过它目前版本支持 Windows和 Mac OS，如下：

坑二：path.basename not a function

在上述的代码内容中需要获取文件的名称，实际上我们可以简单直接的使用 Node Api中 path.basename(path[, suffix])来达到目的：

但是在程序运行时发生了如下异常，对应的代码内容和运行结果如下:

      // 配置参数constoptions = {format:'png',out_dir: dir,out_prefix: path.baseName(filePath, path.extname(filePath)),// 发生异常page:null,
  }复制代码

这个暂时没有找到是什么原因（ 有知道的在评论区告知一二），只能自己简单实现了一个 getFileName方法用于获取文件的名称。

坑三：细节

上述内容通过 koa启动模拟业务服务，由于 业务服务（ http://127.0.0.1:4000）和 应用服务 ( http://127.0.0.1:3000)间的端口不一致，因此会产生跨域，此时可以通过 koa-cors来解决，值得注意的是有时候的那个业务服务器重启时 koa-cors可能不起作用。

由于响应的内容直接在 koa通用中间件中返回，因此，如果你需要支持业务服务提供 静态资源的访问能力，就可以通过 koa-static来实现，值得注意的是，当你通过 koa-static指定静态文件资源后，如 app.use(koaStatic('./static'))，此时如果你直接通过 http://127.0.0.1:4000/static/pdf/xxx.png时，那么会得到 404 Not Found的错误，原因在于 koa-static是直接把 /static/设置成了 根路径，因此正确的访问路径为： http://127.0.0.1:4000/pdf/xxx.png。

效果演示

发票内容不方便展示这里就不直接展示了，只需要关注生成的图片和路径即可：

PDF 下载

这里的下载实际不仅指 pdf的下载，而是客户端方面所能支持的下载方式，最常见的如下几种：

a 标签，例如 <a href="xxxx" download="xxx">下载</a>
location.href，例如 window.location.href = xxx
window.open，例如 window.open(xxx)
Content-disposition，例如 Content-disposition：attachment；filename="xxx"

`<a>`实现下载

<a>的 download属性用于指示浏览器 下载 href 指定的 URL，而不是导航到该资源，通常会提示用户将其保存为本地文件，如果 download属性有指定内容，这个值就会在下载保存过程中作为 预填充的文件名，主要是因为如下原因：

这个值可能会通过 JavaScript进行动态修改
或者 Content-Disposition中指定的 download属性优先级高于 a.download

这种应该是大家最熟悉的方式了，但熟悉归熟悉，还有一些值得注意的点：

download属性只适用于 同源 URL
- 同源 URL会进行下载操作
- 非同源 URL会进行导航操作
- 非同源的资源仍需要进行下载，那么可以将其转换为 blob: URL 和 data: URL形式
若 HTTP响应头中的 Content-Disposition 属性中指定了一个不同的文件名，那么会优先使用 Content-Disposition中的内容
HTTP 若 HTTP响应头中的 Content-Disposition 被设置为 Content-Disposition='inline'，那么在 Firefox 中会优先使用 Content-Disposition的 download属性

静态方式:

      <a href="http://127.0.0.1:4000/pdf/2-1.png"download="2.pdf">下载</a>复制代码

动态方式:

      functiondownload(url, filename){consta =document.createElement("a");// 创建 a 标签a.href= url;// 下载路径a.download= filename;// 下载属性，文件名a.style.display="none";// 不可见document.body.appendChild(a);// 挂载a.click();// 触发点击事件document.body.removeChild(a);// 移除}复制代码

Blob 方式

      if(reqConf.responseType=='blob') {// 返回文件名letcontentDisposition = config.headers['content-disposition'];if(!contentDisposition) {
      contentDisposition =`;filename=${decodeURI(config.headers.filename)}`;
    }constfileName =window.decodeURI(contentDisposition.split(`filename=`)[1]);// 文件类型constsuffix = fileName.split('.')[1];// 创建 blob 对象constblob =newBlob([config.data], {type:FileType[suffix],
    });constlink =document.createElement('a');
    link.style.display='none';
    link.href=URL.createObjectURL(blob);// 创建 url 对象link.download= fileName;// 下载后文件名document.body.appendChild(link);
    link.click();document.body.removeChild(link);// 移除隐藏的 a 标签URL.revokeObjectURL(link.href);// 销毁 url 对象}复制代码

`Content-disposition`和 `location.href/window.open`实现下载

这看似是三种下载方式，但实际上就是一种，而且还是以 Content-disposition为准。

Content-Disposition响应头 指示回复的内容该以何种形式展示，是以内联的形式（即网页或页面的一部分）展示，还是以附件的形式下载并保存到本地，如下：

inline: 是 默认值，表示回复中的消息体会以页面的一部分或者整个页面的形式展示
```
          Content-Disposition:inline复制代码
```
attachment: 设置为此值意味着消息体应该被下载到本地，大多数浏览器会呈现一个 "保存为" 的对话框，并将 filename 的值预填为下载后的文件名
```
          Content-Disposition: attachment; filename="filename.jpg"复制代码
```

因此，基于 location.href='xxx'和 window.open(xxx)的方式能实现下载就是基于 Content-Disposition: attachment; filename="filename.jpg"的形式，又或者说是触发了浏览器本身的下载行为，满足了这个条件，无论是通过 a标签跳转、 location.href 导航、 window.open 打开新页面、 直接在地址栏上输入 URL等都可以实现下载。

H5 移动端的下载

H5移动端针对于预览操作而言基于以上的方式都是可以实现，但是下载操作可就不同了，因为这是要区分场景：

基于 手机浏览器
基于 微信内置浏览器

基于 手机浏览器的下载方式和上述提到的内容大致上也是一致的，本质上只要所在的客户端支持下载那就没有问题，然而在 微信内置浏览器中你使用常规的下载方式可能达不到预期：

在 Android中使用常规的下载方式，通常会弹出对话框，询问你是否需要唤醒 手机浏览器来实现对应资源的下载，部分机型却不会
在 IOS中以上方式都 无法实现下载，因此通常情况下会打开一个新的 webview来提供预览，部分机型在新的页面中支持 长按屏幕的方式进行保存操作，但并不是所有机型都支持

本质原因是在 微信内置浏览器中屏蔽任何的 下载链接，如 APP 的下载链接、 普通文件的下载链接等等。

H5 移动端的下载还能怎么做？

由于这是 微信内置浏览器环境对下载功能的屏蔽，因此不用再考虑（ 想都不敢想）基于 微信内置浏览器来实现下载功能，转而应该考虑的是如何实现 间接下载：

判断当前是否是属于 微信内置浏览器，若是则帮助用户自动唤起 手机浏览器实现下载，但并不是所有机型都支持唤起操作，因此最好是提示使用用户直接通过 手机浏览器实现下载，为了方便用户，可以实现 一键复制的功能进行辅助
另一种就直接提示只支持 PC端下载，放弃对移动端的下载操作

最后

综上所述，实际在实现 pdf预览的过程中可能暂时没有办法达到完美的方式，特别是针对类似 发票类的 pdf文件，仍存在如下的问题：

无法保证 h5移动端都具备下载功能
无法保证 pdf预览时，预览的字体和实际发票字体保持一致

现有大部分的预览方式都基于 pdf.js的方式实现，而 pdf.js内部通过 PDFJs.getDocument(url/buffer)的方式基于 文件地址或 数据流来获取内容，再通过 canvas处理渲染 pdf文件，感兴趣可以去研究 pdf.js源码。

pdf.js带来相关问题就是如果对应的 pdf文件中包含了 pdf.js中不存在的字体，那么就无法完整渲染，另外渲染出来的字体和原本的 pdf文件字体会存在差异。

针对这两点，目前发现谷歌内置的 pdf插件似乎提供了很好的支持，意味着其他浏览器如果包含了谷歌相关的插件（如：Edge、QQ Browser），就可以直接基于 <iframe>的方式实现预览，又或者为了更严谨字体一致性只能通过下载的方式来查看源文件。

实现不了产品的要求怎么办？

例如上述探讨的方案其实无法满足文章开头提到的部分要求。产品提出需求的目的也是为了提供更好的用户体验（ 正常情况下），但是这些要求仍然要落实到技术上，而技术支持程度如何需要我们及时反馈（ 除非你的产品是技术经验），因此作为开发者你需要提供充足的内容向产品证明，然后自己再给出一些间接实现的方案（ 又或者产品自己就给出新的方案），看是否符合 第二预期，核心就是 合理沟通 + 其他方案（ 每个人的处境不同，实际情况也许 ... 懂得都懂）。

以上是个人的一些看法和理解，有不当之处，可以在评论区指正！！！

希望本文对你有所帮助！！！

Motrix下载器

Wed, 27 Oct 2021 17:54:00 CST

Motrix是一款基于Aria2的下载管理工具，支持几乎所有下载方式，支持Windows、Mac、Linux主流操作系统。

官网

https://motrix.app/zh-CN/

Motrix支持自动同步热门的 Tracker服务器，这个功能对于经常下载 bt资源的朋友很有用。并且在批量下载上稳定性不错。

常见问题解决

https://www.yuque.com/moapp/help/issues

掌握这些窍门，下载文献更容易！

Sat, 25 Sep 2021 06:36:00 CST

不论是在「微信群」还是「文献互助QQ群」，几乎每天我会要给青柠er下载文献。

尽管利用我所在学校的数据库优势，能下载到绝大部分文献。

但是，我依然发现， 其实有部分文献在网上是能找到开放资源的，不过一些青柠er因为没掌握诀窍，没找到链接，才因此在群里求助文献。

今天， 我就把这些原本很简单但是却被忽视的窍门总结一下。

Google Scholar 优先

根据我的经验，Google Scholar永远都是下载文献的优先选择渠道。

有不少朋友可能喜欢在Web of Science检索并下载文献，但是这些文献的下载渠道通常都是跳转到期刊网站上的。

一旦所在单位没有订购该期刊数据库，就会以为无法下载该文献了。

我个人使用Google Scholar要比Web of Science多得多。

以下面这篇文献为例，可以看到Google Scholar通常能够解析出该文献在互联网上的开放下载链接。

通常这些开放下载链接来源于ResearchGate、高校网站等等。

此时，直接点击右侧的PDF即可下载。

如果右侧未出现开放资源，不妨点击文献标题跳转到相应期刊网站，看看本单位有没有购买数据库。

善用 Google

如果上述方法还不能帮你找到该文献，也不要灰心。

别忘了Google。（很容易被大家忽视）

在Google官网，输入 标题 + .pdf进行搜索。

依然以上面那篇文献为例，我们试试看。

专门从搜索结果中找到包含 PDF标识的记录，比如第三条搜索结果就是。

点击它，惊喜地发现可以下载。

归纳一句： 相比Google Scholar，Google能够检索到更多结果，这意味着有更大几率找到开放下载资源。

SciHub

自前阵子SciHub回归后，下载文献变得更加容易了，特别是最新的2020/2021年文献。

通常来说，如果上述方法都行不通，我会拷贝文献DOI到SciHub检索试试，惊喜还是有的。

汇总几个可用的SciHub域名。

https://sci-hub.ee

https://sci-hub.se

https://sci-hub.ru

https://sci-hub.st

https://sci-hub.ren

熟知本校已购数据库使用方法

建议大家到学校图书馆网站，了解下本单位所购数据库资源的使用方法。

为什么这么说呢？

通常来说，如果你在校内，这些数据库网站可以通过IP来判定你是否具备下载权限。

但是如果你在校外（比如寒暑假在家），此时想获取下载权限的话，不同数据库的方法差异还挺大。

而这些方法，图书馆网站往往都会介绍得很详细。

比如，浙大图书馆就总结得很全面细致。

根据我的经验， 我举几个校外获取数据库权限的常见方法。

第一：RVPN

有些学校会提供RVPN，只要你登录了RVPN，很多数据库就会自动识别到你所在单位的图书馆账号，此时就可以下载了。

比如Wiley Online Library。

第二：登录机构号

还有一种情况是：就算登录了RVPN，也无法自动识别图书馆信息，而是得手动登录机构（Institution）账号。

比如下面这篇，我们点击PDF。

然后在Search for your Institution下方输入你的单位英文名，比如 Zhejiang University。

此时会 自动跳转到统一身份认证，登录账号即可。

第三：知网 http://fsso.cnki.net

在校外，通常可以通过下面这个网站登录知网，获取数据库权限。

在搜索框输入你的单位名称，看看有没有吧！？

这种方式一般也是跳转到统一身份认证实现登录。

另外， 通过该网站登录知网后，不影响Zotero Connector的文献抓取。（有些其他方式会导致网址改变，从而Zotero Connector无法抓取文献）

善用「原文传递」

有些朋友遇到下面的情况，可能会以为无法下载该文献了。

其实不然。以万方数据的一篇文献为例，可以看到「 原文传递」，点击它。

按照要求，我输入了浙大邮箱和手机号。

一般来说，数小时内邮箱就能收到文献了。

近日，我就通过「原文传递」，帮师兄下载了好几篇文献。

文献互助群

如果用尽以上办法都不能下载文献，那么只能求助了。

比如，青柠学术则为大家提供了两种渠道：

文献互助QQ群：免费加入，响应略有延迟。

微信群：会员专享，第一时间响应。

学生党最应该知道的资源---技能/软件/编程/英语/二外/计算机二级/其他学习/论文下载/电子书/PPT模板_哔哩哔哩_bilibili

Sun, 25 Jul 2021 23:13:24 CST

1、技能学习平台：哔哩哔哩、中国大学慕课、coursera、edX
2、软件操作：up主：oeasy、doyoudo、星月兮、Genji是真想教会你、旁门左道PPT、Excel自学成才、我是于干，+实战演练
3、编程：基础：菜鸟教程、进阶：CSDN、Github、stackoverflow、leetcode
4、英语：四六级尽早考+买真题，进阶：扇贝、中国日报网英语点津、Italki、Audible、NPR.org、考满分
5、二外：最好找老师，入门：多邻国
6、计算机二级：学校基础课、买题库，up主：小黑课堂计算机二级
7、其他：学吧导航
8、论文下载：学校图书馆或省市图书馆，知网、Web of Science、图书馆官网直接检索、SCI-HUB、Library Genesis、Z-Library
9、电子书：某宝、读秀、超星、书格、七彩英语、古腾堡计划、manybooks、鸠摩搜索、Library Genesis
10、PPT模板：OfficePLUS、PPT超级市场、51PPT模板、PPT汇、优品PPT、HiPPTer

磁力链接BT种子电驴搜索下载网站合集 | 合集网

Mon, 26 Oct 2020 11:39:57 CST

国内磁力搜索

磁力爬永久地址： https://www.cilipa.com（被墙）
- 备用域名： https://www.cilipapa.com
- 地址发布页： https://www.cilipa.net
熊猫磁力： https://xiongmao23.icu/
- 地址发布页： https://xiongmaocl.fun（被墙）
磁力巴士永久地址： http://www.bvbus.com
磁力狗： http://ciligou.app/
- 备用地址： http://0200.org
BT-btt永久地址： https://u3c3.com/ （被墙）
- 备用地址： https://u9c9.com/ https://u7c7.com/
- 地址发布页： https://github.com/u3c3/bt-btt
Push BT平台： http://m.pushbt.top/ 只有用手机浏览器才显示网站内容
- 网址防丢失邮箱pushbtwebsite@gmail.com
BT1207： https://bt1207.fun/
- 备用地址： https://bt1207cl.icu/
SkrBT： https://sktbtcil.buzz/
- 备用地址： https://skrbt.fun/
MAG磁力站永久地址： http: //cili001.com
Sobt永久地址： http://sobt.me/
- 备用地址： http://www.sobt5.pw/
Btdad： http://www.btdad.xyz/
- 备用地址： http://www.btdad.life
雨花阁地址发布页1 ： https://www.yuhuage.club/
- 地址发布页2： https://www.btcherries.xyz/
- 备用地址发布页： https://github.com/yuhuage/dizhi/blob/master/README.md
- 发邮件到dxj880@gmail.com获取最新地址
磁力宝： http://www.clb.biz/
- 备用地址： http://9321.org
巴士资源搜索： http://5338.org
磁力天堂永久地址： https://www.cltt.me
Bthub： https://bthub.site/ （被墙）
- 备用地址： https://bth01278213.monster/
- 地址发布页1 ： https://github.com/fwonggh/Bthub
- 地址发布页2： https://gitlab.com/fwonggh/Bthub/-/blob/master/README.md
btfox： http://btfox0.net
BT精灵： https://btring.com
magnetW： https://github.com/xiandanin/magnetW
- 聚合搜索，目前只更新软件版， win和mac下载
老王磁力： https://laowang.fun/

国外磁力搜索

RARBG： https://rarbgaccess.org/
BTSOW： https://btos.pw/
Data-Iceberg： https://data-iceberg.com/
AIO Search： https://www.aiosearch.com/ 磁力聚合搜索网站
东京图书馆： https://www.tokyotosho.info/
海盗湾： https://thepiratebays.info/ 永久发布页
ØMagnet： https://0mag.net 正经资源搜不到

磁力下载站

MP4吧： http://mp4ba.cc/
- 提供下载方式：磁力链接、BT种子、百度网盘
人人影视： http://www.zmz2019.com/
- 磁力、电驴
美剧天堂： https://www.meijutt.com/
- 磁力、电驴
一站搜： http://videos.yizhansou.com/
- 磁力、电驴
片源网： http://www.pianyuan.la/
- BT、磁力
中国高清网： http://gaoqing.la/
- 磁力

种子下载站

耐卡影音论坛： http://mcar.co/
- BT种子、网盘
BT之家： https://www.88btbtt.com/
- BT种子

电驴下载站

电波字幕组： http://dbfansub.com/
- 电驴、网盘。提供单独字幕下载

公共 BitTorrent Tracker

下载前记得更新下公共 BitTorrent Tracker 列表

使用说明
- https://github.com/XIU2/TrackersListCollection/blob/master/README-ZH.md
Aria2 Tracker
- https://trackerslist.com/all_aria2.txt
BitTorrent Tracker
- https://trackerslist.com/all.txt

下载工具 Aria2 (几乎全能的下载神器) - 简书

Sun, 18 Aug 2019 10:30:08 CST

一.介绍

说完了前面一堆BT/PT客户端，现在终于轮到Aria2了，关于这个我就不介绍太多了，自从百度限速以来我觉得这个快变成众所周知的了，我平时也收集了各种和Aria2相关的插件或者是辅助软件之类的，就等着全部丢出来，下面请看我的表演。

二.安装

安装Aria2确实是个麻烦事，特别是要安装新的版本，我之前也写过编译安装最新版本的，看的人挺多的，就是还是麻烦了点，这次顺便给出个别人静态编译的地址，作者更新的挺勤的，基本上新版本出了很快就会跟进。

①.手动编译安装

这个翻我以前的文章就行了——> 传送门

②.静态编译下载

GNU/Linux:

32位: https://github.com/q3aql/aria2-static-builds/releases/download/v1.32.0/aria2-1.32.0-linux-gnu-32bit-build1.tar.bz2

64位: https://github.com/q3aql/aria2-static-builds/releases/download/v1.32.0/aria2-1.32.0-linux-gnu-64bit-build1.tar.bz2

ARM树莓派: https://github.com/q3aql/aria2-static-builds/releases/download/v1.32.0/aria2-1.32.0-linux-gnu-arm-rbpi-build1.tar.bz2

Windows:

32位: https://github.com/q3aql/aria2-static-builds/releases/download/v1.32.0/aria2-1.32.0-win-32bit-build1.7z

64位: https://github.com/q3aql/aria2-static-builds/releases/download/v1.32.0/aria2-1.32.0-win-64bit-build1.7z

还有个改版的，把并发线程提到了128，暴力下载

GNU/Linux 64位: https://github.com/xzl2021/aria2-static-builds-with-128-threads/releases/download/v1.32.0/aria2-1.32.0-linux-gnu-64bit-build1.tar.bz2

安装方法没啥说的，找地方解决直接用就行，静态编译就是这么牛逼，不需要额外安装库

③.集成版下载

因为Aria2很强大，同时因为强大又没那么容易上手，所以有些人就想办法把Aria2集成到其他软件或者封装成图形界面，使得它能够更方便使用。

1. Persepolis Download Manager(Windows/Linux/macOS)

官网: https://persepolisdm.github.io

下载：

Debian/Ubuntu: https://github.com/persepolisdm/persepolis/releases/download/2.4.2/persepolis_2.4.2.1_all.deb

macOS: https://github.com/persepolisdm/persepolis/releases/download/2.4.2/persepolis_2_4_2_mac.dmg

Windows 32位: https://github.com/persepolisdm/persepolis/releases/download/2.4.2/persepolis_2_4_2_windows_32bit.exe

Windows 64位: https://github.com/persepolisdm/persepolis/releases/download/2.4.2/persepolis_2_4_2_windows_64bit.exe

纯粹的套壳之作，开箱即用，虽然目前还有些问题，但是还是挺好的

2. PanDownload(Windows)

下载地址: https://github.com/cherryljr/PanDownload/raw/master/PanDownload.exe

将Aria2用于百度云下载，无需浏览器插件，无需复制粘贴，登录账户一点即下

3.Aria2GUI(macOS)

下载地址: https://github.com/yangshun1029/aria2gui

就是单纯的Yaaw+内置Aria2，但是效果其实挺好，配合自带的浏览器插件还是不错的

3.Maria(macOS)

下载地址: https://github.com/shincurry/Maria

这个集成了Aria2，也能用You-Get来进行部分下载，也是不错的

三. 客户端(类)

安卓:

Aria2APP: 这个是远程控制

下载地址: https://www.coolapk.com/apk/com.gianlu.aria2app (请在手机访问，PC会404)

神奇磁力: 这玩意本质上是个搜索资源的，能够Aria2 RPC远程下载

下载地址: https://www.coolapk.com/apk/com.magicmagnet(请在手机访问，PC会404)

IOS:

曾经有个avee，后来下架了... 不过还是能用各种web来控制的，也凑合

PC:

AriaNG Native: (将AriaNG封装在Web容器中的版本)

下载地址: https://github.com/mayswind/AriaNg-Native/releases/download/0.2.0/AriaNg-0.2.0.exe

macOS:

AriaNG Native: (将AriaNG封装在Web容器中的版本)

下载地址: https://github.com/mayswind/AriaNg-Native/releases/download/0.2.0/AriaNg-0.2.0.dmg

AMM: 全称Aria2 Menubar Monitor，在任务栏中管理监控Aria2

下载地址: https://github.com/15cm/AMM/

四.浏览器插件

Safari2Aria: 在Safari中管理Aria2，并且劫持默认下载方式

下载地址: https://github.com/miniers/safari2aria

115: 使用Aria2下载115资源

下载地址: https://github.com/acgotaku/115/

BaiduExporter: 网盘助手, 使用Aria2下载百度网盘资源，这个因为被Chrome商店下架了，所以需要安装说明，请参考我写的文章——> 传送门

下载地址: https://github.com/acgotaku/BaiduExporter

YAAW for Chrome: 在chrome中直接内置一个YAAW，用于直接管理Aria2

下载地址: https://chrome.google.com/webstore/detail/yaaw-for-chrome/dennnbdlpgjgbcjfgaohdahloollfgoc

五.各种WebGUI

YAAW:

下载地址: https://github.com/binux/yaaw

webgui- aria2:

下载地址: https://github.com/ziahamza/webui-aria2

AriaNG:

下载地址: https://github.com/mayswind/AriaNg

Glutton:

下载地址: https://github.com/NemoAlex/glutton

AI领域必看的45篇论文（附下载地址）

Thu, 25 Jul 2019 11:37:00 CST

而AI领域的发展会是IT中最快的。我们所看到的那些黑客技，其后面无不堆积了大量的论文。而且都是最新、最前沿的论文。

从某种调度来讲，他们所用的技术跟书籍里的内容确实不是一个时代。要想与时俱进，就必须改变思路——从论文入手。

今天给大家介绍45篇让你跟上AI时代的论文。

一、神经网络基础部分

No1 wide_deep模型论文：

关于神经元、全连接网络之类的基础结构，想必每个AI学者都有了解。那么你是否真的了解全连接网络中深层与浅层的关系呢？来看看wide_deep模型吧。这篇论文会使你对全连接有个更深刻的理解。

关于该模型的更多介绍可以参考论文：

https://arxiv.org/pdf/1606.07792.pdf

在wide_deep模型中，wide模型和deep模型具有各自不同的分工。

—wide模型：一种浅层模型。它通过大量的单层网络节点，实现对训练样本的高度拟合性。它的缺点是泛化能力很差。
—deep模型：一种深层模型。它通过多层的非线性变化，使模型具有很好的泛化性。它的缺点是拟合度欠缺。

将二者结合起来——用联合训练方法共享反向传播的损失值来进行训练—可以使两个模型综合优点，得到最好的结果。

No2 wide_deep模型论文：

为什么Adam被广泛使用？光会用可不行，还得把原理看懂。这样出去喷一喷，才会显得更有面子。

Adam的细节请参阅论文《Adam: A Method for Stochastic Optimization》，该论文的链接网址是：

https://arxiv.org/pdf/1412.6980v8.pdf

No3 Targeted Dropout模型论文：

你还再用普通的Dropout吗？我已经开始用Targeted Dropout了。比你的又快，又好。你不知道吧，赶紧学习一下。

Targeted Dropout不再像原有的Dropout那样按照设定的比例随机丢弃部分节点，而是对现有的神经元进行排序，按照神经元的权重重要性来丢弃节点。这种方式比随机丢弃的方式更智能，效果更好。更多理论见以下论文：

https://openreview.net/pdf?id=HkghWScuoQ

二、图像分类部分

No4 Xception模型论文：

在那个图像分类的时代，谷歌的Xception系列，像x战警一样，一个一个的打破记录。其中的技术也逐渐成为AI发展的知识体系。有必要看一下。或许会对自己的工作有所启发。

详细情况请查看原论文《Xception: Deep Learning with Depthwise Separable Convolutions》，该论文网址是：

https://arxiv.org/abs/1610.02357

No5 残差结构论文：

运气好到没朋友，现有模型，后完善理论指的就是残差结构这哥们。他的传奇导致即使到今天的AI技术，也无法将它割舍，就来常微分方程都得拿它比肩。快来学学吧。用处大着呢。好多模型都拿他当先锋。

利用残差结构，可以使得网络达到上百层的深度。详情请参阅原始论文《Deep ResidualLearning for Image Recognition》，该论文网址是：

https://arxiv.org/abs/1512.03385

No6 空洞卷积论文：

NasNet的招牌动作，虽然不是出于NASNet，但是却被人家用得如火纯青。有时不得不惊叹，机器设计出来的模型还真实跟人设计的不一样！

想知道空洞卷积的感受野为什么与层数呈指数级关系吗？

细节请查看原论文《Multi-scale context aggregation by dilated convolutions》，该论文网址是：

https://arxiv.org/abs/1511.07122v3

No7 DenseNet论文：

这个模型使我想到了“一根筋”，再次证明了只有轴的人才能成大事！令类的模型，神奇的效果，快来体验一下吧。这可是比华佗还牛的神医哦！

有关DenseNet模型的细节，请参考原始论文《Densely Connected Convolutional Networks》，该论文的连接是：

https://arxiv.org/abs/1608.06993

No8 EfficientNet模型论文：

知道目前位置图像分类界谁是老大吗？来，看看这个！

EfficientNet模型的论文地址如下：

https://arxiv.org/pdf/1905.11946.pdf

No9 Grad-CAM模型论文：

如果你能把神经元搞得透彻，你也会想到这个点子。不想聊太多！一个字“绝”！这TMD才叫卷积网络的可视化！

详细情况请参阅论文《Grad-CAM:Visual Explanations from Deep Networks via Gradient-based Localization》，该论文的链接网址是：

https://arxiv.org/pdf/1610.02391.pdf

No10 分类模型泛化能力论文：

知道为啥都喜欢使用ResNet模型当先锋吗？运气好就是运气好！好到大家都喜欢用它，还说不出为啥它那么好！反正就是好，不信的话看看这篇论文的实验结果。

论文中，在选取模型的建议中，多次提到了ResNet模型。原因是，ResNet模型在Imgnet数据集上输出的特征向量所表现的泛化能力是最强的。具体可以参考以下论文：

https://arxiv.org/pdf/1805.08974.pdf

三、批量正则化部分

No11 批量正则化论文：

这个没的说，必修课，不懂的化，会被鄙视成渣渣！

论文《Batch Normalization Accelerating Deep Network Training by Reducing Internal Covariate Shift》，该论文网址是：

https://arxiv.org/abs/1502.03167

No12 实例归一化论文：

时代不同了，批量归一化也升级了，赶紧学学新的归一化吧。

在对抗神经网络模型、风格转换这类生成式任务中，常用实例归一化取代批量归一化。

因为，生成式任务的本质是——将生成样本的特征分布与目标样本的特征分布进行匹配。生成式任务中的每个样本都有独立的风格，不应该与批次中其他的样本产生太多联系。所以，实例归一化适用于解决这种基于个体的样本分布问题。详细说明见以下链接：

https://arxiv.org/abs/1607.08022

No13 ReNorm算法论文：

ReNorm算法与BatchNorm算法一样，注重对全局数据的归一化，即对输入数据的形状中的N维度、H维度、W维度做归一化处理。不同的是，ReNorm算法在BatchNorm算法上做了一些改进，使得模型在小批次场景中也有良好的效果。具体论文见以下链接：

https://arxiv.org/pdf/1702.03275.pdf

No14 GroupNorm算法论文：

GroupNorm算法是介于LayerNorm算法和InstanceNorm算法之间的算法。它首先将通道分为许多组（group），再对每一组做归一化处理。

GroupNorm算法与ReNorm算法的作用类似，都是为了解决BatchNorm算法对批次大小的依赖。具体论文见下方链接：

https://arxiv.org/abs/1803.08494

No15 SwitchableNorm算法论文：

我们国人做产品都喜欢这么干！all in one ,好吧。既然那么多批量归一化的方法。来，来，来，我们来个all in one吧。不服来辩，我这啥都有！

SwitchableNorm算法是将BN算法、LN算法、IN算法结合起来使用，并为每个算法都赋予权重，让网络自己去学习归一化层应该使用什么方法。具体论文见下方链接：

https://arxiv.org/abs/1806.1077

四、注意力部分

No16 大道至简的注意力论文：

把AI搞成玄学也就算了！居然还扯到道家了！谷歌的工程师真实中外通吃啊！搞出来了一个只用注意力就能做事的模型，连卷积都不要了！你所好玩不好玩！至简不至简！刺激不刺激！

大名鼎鼎的Attention is All You Need 注意力机制论文，注意力机制因2017年谷歌的一篇论文Attention is All You Need而名声大噪。下面就来介绍该技术的具体内容。如果想了解更多，还可以参考原论文，具体地址如下：

https://arxiv.org/abs/1706.03762

No17-18 孪生注意力论文：

好比LSTM与GRU一样，注意力他们家也除了一对双胞胎，长得略微有点不同。但是功能一样，都能吃能喝，还能注意。老虎老鼠傻傻的不清楚！

—BahdanauAttention：https://arxiv.org/abs/1409.0473。

—LuongAttention：https://arxiv.org/abs/1508.04025。

No19 各自升级的孪生注意力论文：

话说这对双胞胎，出生后就分开了。各自学的不同的语言，一个学习汉语，一个学习中文。若干年后，见面，发现二者的能力还是一样！

BahdanauAttention注意力升级成了normed_BahdanauAttention，而LuongAttention注意力升级成了scaled_LuongAttention。都一样的效果，你爱用哪个用哪个吧！

例如：

在BahdanauAttention类中有一个权重归一化的版本（normed_BahdanauAttention），它可以加快随机梯度下降的收敛速度。在使用时，将初始化函数中的参数normalize设为True即可。

具体可以参考以下论文：

https://arxiv.org/pdf/1602.07868.pdf

No20 单调注意力机制论文：

老公主动表忠心，我以后不看别的美女。老婆觉得不够，再加个限制：你以后不准看别的女人！于是单调注意力就出来了。

单调注意力机制（monotonic attention），是在原有注意力机制上添加了一个单调约束。该单调约束的内容为：

假设在生成输出序列过程中，模型是以从左到右的方式处理输入序列的。
当某个输入序列所对应的输出受到关注时，在该输入序列之前出现的其他输入将不能在后面的输出中被关注。

即已经被关注过的输入序列，其前面的序列中不再被关注。

更多描述可以参考以下论文：

https://arxiv.org/pdf/1704.00784.pdf

No21 混合注意力机制论文：

这个注意力很强大，比一般的注意力专注的地方更多，信息更丰富。我已经注意你很久了！呵呵呵~~~

因为混合注意力中含有位置信息，所以它可以在输入序列中选择下一个编码的位置。这样的机制更适用于输出序列大于输入序列的Seq2Seq任务，例如语音合成任务。

具体可以参考以下论文：

https://arxiv.org/pdf/1506.07503.pdf

五、高级的卷积网络知识

No22 胶囊网络与动态路由的论文：

这是一股为图像分类降温的寒风，深刻而又尖锐的点出了卷积网络的硬伤！从事最大池化再无翻身之日。

虽然胶囊网络再实际应用中，不像它的理论那么牛，但是对AI的帮助，卷积的理解是革命性的。非常值得一读。另外，这也是一篇绝对让你对数学彻底绝望的论文。花几根白头发把里面的算法啃下来吧。这样你与大神就能更近一步。

胶囊网络分为主胶囊与数字胶囊，主胶囊与数字胶囊之间的耦合系数是通过训练得来的。在训练过程中，耦合系数的更新不是通过反向梯度传播实现的，而是采用动态路由选择算法完成的。该算法来自以下论文链接：

https://arxiv.org/pdf/1710.09829.pdf

目前胶囊网络的研究还处于初级阶段，随着人们研究的深入，相信这些问题会得到解决。

No23 矩阵胶囊网络与EM路由算法：

如果你觉得不过瘾，那么还可以再看一篇。继续自虐一下。

带有EM（期望最大化）路由的矩阵胶囊网络是动态路由胶囊网络的一个改进版本。论文链接如下：

https://openreview.net/pdf?id=HJWLfGWRb

No24 胶囊网络的其它用处：

胶囊网络混身是宝，但就是自己不争气。这也说明还有上升的空间。就拿其中一个动态路由算法来讲，居然比普通的注意力还好。

看完之后，相信你一定会手痒！要不要也试试？把你的注意力换一下。值得你尝试，会有彩蛋的！

该论文的实践也证明，与原有的注意力机制相比，动态路由算法确实在精度上有所提升。具体介绍可见以下论文：

https://arxiv.org/pdf/1806.01501.pdf

No25 卷积网络新玩法TextCNN模型：

早先小编在一个项目中，自己用卷积网络处理字符数据。自己感觉很Happy。没想到，无意间居然发现了一篇同样这么干的论文。居然还有个名字，叫TextCNN。哎！可惜啊！小编文化少，只会写代码，不会写论文。

TextCNN模型是利用卷积神经网络对文本进行分类的算法，由 Yoon Kim 在 Convolutional Neural Networks for Sentence Classification 一文中提出。论文地址：

https://arxiv.org/pdf/1408.5882.pdf

六、图像内容处理部分

No26 FPN模型论文（包含了ROIAlign的匹配算法）：

要是搞计算机视觉，还是要建议看一下。非常的基础。也是图像分割方面的用得最多得模型。

FPN的原理是：将骨干网络最终特征层和中间特征层的多个尺度的特征以类似金字塔的形式融合在一起。最终的特征可以兼顾两个特点——指向收敛目标的特征准确、特征语义信息丰富。更多信息可以参考论文：

ROIAlign层中的匹配算法也来自于这篇FPN论文，链接如下：

https://arxiv.org/abs/1612.03144

No27 Mask R-CNN模型论文：

效果好，代码多！硬货！来啃吧！

Mask R-CNN模型是一个简单、灵活、通用的对象实例分割框架。它能够有效地检测图像中的对象，并为每个实例生成高质量的分割掩码，还可以通过增加不同的分支完成不同的任务。它可以完成目标分类、目标检测、语义分割、实例分割、人体姿势识别等多种任务。具体细节可以参考以下论文：

https://arxiv.org/abs/1703.06870

No28 YOLO V3模型论文：

这个模型的提点就是快！

目标识别强烈推荐，YOLO V3模型的更多信息可以参考以下链接中的论文：

https://pjreddie.com/media/files/papers/YOLOv3.pdf

No29 Anchor-Fress模型--FCOS模型论文：

随着AI技术的进步Anchor-Fress模型死灰复燃（早先是YOLO V1那一批模型），这次不一样的是彻底干掉带Anchor的模型。训练起来那就一个爽！妈妈再也不用为我准备单独的Anchor标签了。

与YOLO V1相比， FCOS模型的思想与YOLO V1模型非常相似，唯一不同的是FCOS模型没有像YOLOv1那样只考虑中心附近的点，而是利用了ground truth边框中所有的点来进行预测边框。并且通过 center-ness 分支来抑制那些效果不行的检测边框。这样FCOS 就可以改善YOLO V1模型总会漏掉部分检测边框的缺点。

七、循环神经网络部分

No33 QRNN模型论文：

在RNN模型的cell里，如果还只知道LSTM和GRU。那就太low了。快了补补吧：

如果想更多了解QRNN，可以参考以下论文：

https://arxiv.org/abs/1611.01576

No34 SRU模型论文：

接着来，各种RNN的Cell。又漂亮，又好吃！

SRU单元在本质上与QRNN单元很像。从网络构建上看，SRU单元有点像QRNN单元中的一个特例，但是又比QRNN单元多了一个直连的设计。

若需要研究SRU单元更深层面的理论，可以参考如下论文：

https://arxiv.org/abs/1709.02755

No35 IndRNN模型论文：

再补一个，这可都是好cell啊！

将IndRNN单元配合ReLu等非饱和激活函数一起使用，会使模型表现出更好的鲁棒性。

有关IndRNN单元的更多理论，可以参考论文：

https://arxiv.org/abs/1803.04831

No36 IndRNN模型论文：

最后，再来一个cell，如想要了解更多关于JANET单元的内容，可以参考以下论文：

https://arxiv.org/abs/1804.04849

八、AI合成部分

No37-38 Tacotron与Tacotron-2模型论文：

AI合成部分的经典模型，以上结构来自Tacotron与Tacotron-2两个结构，更多内容可以参考以下两篇论文：

https://arxiv.org/pdf/1703.10135.pdf

https://arxiv.org/pdf/1712.05884.pdf

No39 DeblurGAN模型论文：

图片合成的论文太多了。这里简单列几个，大体原理和思路了解，即可。

DeblurGAN模型是一个对抗神经网络模型，由生成器模型和判别器模型组成。

—生成器模型，根据输入的模糊图片模拟生成清晰的图片。
—判别器模型，用在训练过程中，帮助生成器模型达到更好的效果。

具体可以参考论文：

https://arxiv.org/pdf/1711.07064.pdf

No40 AttGAN模型论文：

同样，这也是个图片合成的。不同的是多属性合成，相对比较有意思。

AttGAN模型由两个子模型组成：

利用编码器模型将图片特征提取出来。
将提取的特征与指定的属性值参数一起输入编码器模型中，合成出最终的人脸图片。

更多细节可以参考论文：

https://arxiv.org/pdf/1711.10678.pdf

No41 RNN.WGAN模型论文：

可以合成文本的GAN。离散数据也能干！

RNN.WGAN模型使用了WGAN模型的方法进行训练。详细做法可以参考如下论文：

https://arxiv.org/abs/1704.00028

九、多任务学习

No42 MKR模型论文：

多任务学习模型有必要了解一下。这里推荐一个论文给你看看。

MKR是一个多任务学习的端到端框架。该框架能够将两个不同任务的低层特征抽取出来，并融合在一起实现联合训练，从而达到最优的结果。有关MKR的更多介绍可以参考以下链接：

https://arxiv.org/pdf/1901.08907.pdf

十、NLP部分

No43 BERT模型论文：

如果你搞NLP，那么这个就不用我来介绍了。如果你准备搞NLP,那么赶紧来看看这个，跟上时代。

BERT相关论文链接

https://arxiv.org/abs/1810.04805

在BERT之后，又出了好多优秀的模型。但是，还是先把这个啃下来，再看别的才不费劲。

十一、模型攻防

No44 FGSM模型论文：

攻击模型的经典方法。值得掌握。

FGSM（Fast Gradient Sign Method）是一种生成对抗样本的方法。该方法的描述如下：

将输入图片当作训练的参数，使其在训练过程中可以被调整。
在训练时，通过损失函数诱导模型对图片生成错误的分类。
当多次迭代导致模型收敛后，训练出来的图片就是所要得到的对抗样本。

具体可以参考论文：

https://arxiv.org/pdf/1607.02533.pdf

No45 黑箱攻击论文：

基于雅可比（Jacobian）矩阵的数据增强方法，是一种常用的黑箱攻击方法。该方法可以快速构建出近似于被攻击模型的决策边界，从而使用最少量的输入样本。即：构建出代替模型，并进行后续的攻击操作。

详细请见如下链接：

https://arxiv.org/abs/1602.02697

这里只是列了一些基础的论文。如果这45篇论文看完。可以保证你再看到大厂的产品时，不会感觉有代沟。

谷歌拼音输入法离线包下载

Sat, 13 Apr 2019 12:38:23 CST

由于谷歌拼音输入法无法在中国大陆下载，因此提供文件来源于谷歌官方网站的谷歌拼音输入法离线包（Windows 10/8.1/8/7 64 位）下载。

下载谷歌拼音输入法离线包

谷歌拼音输入法是由谷歌中国实验室开发，于2007年4月2日发布 [2]的汉语拼音输入法。10月25日成为Google的正式产品之一 [3]。

谷歌拼音输入法1.0.15.0版盗用了搜狗拼音输入法的词库 [4]，随后谷歌发布致歉声明。并于2007年4月9日发布1.0.17.0版，称改用了自家的词库。

随后， Google在其博客“Google 黑板报”上发布有两份声明，第一份是对盗用词库表示致歉明白卡 [5]，第二份则称输入法中包含 Google工程师申请的专利。

谷歌拼音输入法在PC端已经停止更新。2018年6月，下载页面完全从网站撤下，而文件则至2019年3月仍未撤下。用户在PC上使用已安装的谷歌拼音输入法无法登录Google账号和使用其自动同步功能。

谷歌浏览器Chrome离线包下载

Sat, 13 Apr 2019 12:31:55 CST

由于谷歌浏览器Chrome无法在中国大陆下载，因此提供文件来源于谷歌官方网站的谷歌浏览器Chrome离线包（Windows 10/8.1/8/7 64 位）下载。

下载谷歌浏览器Chrome离线包

Google Chrome是由 Google开发的免费网页浏览器 ^[9]。Chrome是化学元素“ 铬”的英文名称，过去也用Chrome称呼浏览器的外框 ^[10] ^[11] ^[12] ^[13]。Chrome相应的开放源代码计划名为 Chromium ^[14] ^[15]，而Google Chrome本身是非自由软件，未开放全部源代码 ^[9] ^[16]。

Chrome代码是基于其他开放源代码软件所编写，包括 Apple WebKit和 Mozilla Firefox，并开发出称为“ V8”的高性能 JavaScript引擎 ^[17]。Google Chrome的整体发展目标是提升稳定性、速度和安全性，并创造出简单且有效率的用户界面 ^[18]。 CNET旗下的 Download.com网站评出的2008年6月最佳Windows应用程序，其中Google Chrome排名首位 ^[19]。

据 StatCounter统计，截至2018年第一季度，Google Chrome在全球桌面浏览器的网页浏览器的使用分布为66% ^[20]。

Chrome 50结束了对 Windows XP与 Windows Vista系统的支持 ^[21]，这两个系统上的最后版本为49.0.2623.112 ^[22]

转载：腾讯评级罕见遭券商下调国金证券称市场预期和估值偏高

Wed, 06 Mar 2019 20:45:45 CST

腾讯评级罕见遭券商下调国金证券称市场预期和估值偏高

来源：国金证券裴培

2019-03-06 13:45

国金证券认为，市场可能忽略了手游产品线青黄不接、广告主需求不振、销售费用上升等因素对腾讯业绩的影响，目前腾讯的估值偏高、预期偏强。因此，下调腾讯目标价至365港元，调降评级至“中性”。

投资逻辑

别误会，我们毫不担心腾讯的战略地位：我们不赞成“腾讯的流量基础受到了短视频冲击”的说法，而且短视频增长最快的时期已经过去。我们通过监测数据和问卷调查得知，QQ、QQ音乐深受95后消费者欢迎，下一代用户仍然是腾讯的基本盘。除了游戏业务，腾讯在视频、音乐、电竞、动漫、文学等娱乐内容领域的布局非常完善，足以支撑下一个十年的增长。

2019年，腾讯主营业务面临着压力：虽然《王者荣耀》的收入居高不下，但是缺乏手游爆款新品，仍然给腾讯游戏业务蒙上了阴影，《刺激战场》在短期内也难以获得版号；广告业务虽然可以扩大供给，但是经济放缓将不可避免地影响广告主需求，影响广告价格和负载率；支付业务维持着收入高增长，但是备付金上缴将对利润率产生显著压制。

关键问题不仅在于监管，也在于经济：腾讯面临的问题有一部分来自监管，例如游戏版号控制、互联网金融监管趋严；还有一部分来自宏观经济。我国的“流量红利”已经用完，经济处于“调结构”时期，广告主和企业用户都非常谨慎。虽然有人认为个人用户将出于“口红效应”而增加互联网娱乐开支，但是我们此前的研究证明“口红效应”并不存在。

投资建议

我们认为目前对腾讯的市场预期偏高。我们对腾讯2018/2019/2020年营业收入的预期比彭博一致预期低1.5%/5.1%/8.6%，对同期Non-GAAP净利润的预期比彭博一致预期低5.4%/9.0%/11.6%。市场可能忽略了手游产品线青黄不接、广告主需求不振、销售费用上升等因素对腾讯业绩的影响。

调整EPS及目标价，调降评级至“中性”。我们将腾讯2018/2019/2020年的Non-GAAP EPS预期下调至7.62/8.81/10.90元（此前为8.40、10.68、13.16元）；基于DCF模型，为我们将目标价下调至365港元，将评级从“买入”下调至“中性”。在长期，腾讯仍然是投资者布局中国互联网行业的最佳选择之一，但是目前市场预期偏高、估值处于高位，我们建议保持谨慎。

风险因素：监管风险，新业务风险，技术替代风险，战略投资风险。

正文

不要误会：我们毫不担心腾讯的长期战略地位

与市场普遍存在的担心相反，我们认为腾讯的长期战略地位非常稳固。在十年之后，它应该仍然是中国最大的互联网公司之一（而它的竞争对手不一定能熬到那时）。我们担心的是腾讯的短期业绩，尤其是2019年。在讨论各项业务的收入和利润趋势之前，让我们先看看腾讯为未来做了哪些准备——投资者往往忽略或低估了这些准备。

短视频冲击了腾讯的流量基础？也不是完全没有道理

自从2017年下半年抖音崛起以来，许多投资者担心：短视频可能是移动互联网最后的杀手级应用，它将对腾讯的“流量壁垒”构成冲击。市面上流行的短视频App不仅有抖音，还有同属“头条系”的西瓜、火山，以及腾讯战略投资的快手。至于腾讯自己开发的微视、Yoo视频，以及微信自带的“时刻视频”功能，并未吸引足够的用户兴趣。

问题在于：短视频App对腾讯乃至整个移动市场的“流量冲击”有多大？这个过程还在持续吗？国金证券研究创新中心的独家监测数据显示，截止2019年1月，抖音的MAU仍在增长，但是环比增速已经大幅放缓；西瓜、火山的MAU早在2018年2-3月就已见顶。“头条系”三款短视频App的MAU之和，过去半年内稳定在4-4.5亿之间；这个数字不算特别大——略微超过新浪微博的MAU，低于三大长视频App的MAU。更重要的是，整个短视频行业用户增速最快的时期，已经结束了。

有一种观点认为，短视频App占据了大量的用户时长，对微信、QQ构成了严重冲击。我们的数据不支持以上观点：2019年1月，微信月活用户的月均使用时长为1380分钟，是抖音的4.4倍；月均打开次数为241次，是抖音的6.2倍。在过去12个月内，微信、QQ的月均使用时长基本保持稳定。抖音的月均使用时长，在大部分时间都低于腾讯视频等长视频App。有趣的是，在“头条系”短视频App中，月均使用时长最高的是西瓜，因为它具备发达的长视频和游戏直播功能；可惜，西瓜视频的用户基数较小。当然，抖音在短短两年之内迅速上升为现象级App，对“腾讯系”肯定产生了影响；然而，这种影响并没有很多人想象的那么大。

总而言之，“短视频是否冲击了腾讯的流量基础”这个问题，其实可以拆分为三个问题，我们都此都可以做出明确的回答：

问题1：腾讯是否错误判断了短视频的机遇？是。2017年3月，腾讯投资快手之后，认为短视频行业大局已定，基本放弃了自家的微视。在抖音崛起之后，腾讯没有及时利用微信对微视、快手导流，坐视对方抢占一二线城市及白领市场。直到2018年9月以后，腾讯才在短视频市场投入足够资源，用微信向微视导流、推出Yoo视频、在微信中加入时刻视频等，可惜已经为时过晚。

问题2：错过短视频对腾讯是致命的问题吗？不是。短视频是一个重要赛道，但是我们估计它在巅峰期也仅能占据全部用户时长的5-10%。在错过短视频的同时，腾讯在长视频、音乐、直播、动漫等赛道上都取得了巨大进展；而且，它投资的快手仍然是最大的短视频应用之一。腾讯不可能赢得所有战役，有所得必有所失。

问题3：短视频的崛起对长视频、游戏构成了冲击吗？至少在2018年，这种冲击不明显。腾讯视频、爱奇艺的MAU和付费用户均创历史新高，月均使用时长未见下降。游戏行业的问题主要是版号停发、“吃鸡”无法变现，以及端游IP移植手游的枯竭。从我们的监测数据和行业调研看，短视频并未对腾讯的核心业务构成根本性的冲击。

抖音等短视频App崛起，对腾讯的收入最直接的冲击是：它们分流了广告主的预算，可能对腾讯广告业务（尤其是社交广告）构成影响。但是，我们认为受影响最大的是百度、微博，其次才是腾讯。此外，外界可能高估了抖音在2018-2019年的广告收入水平，尽管它在长期不失为有吸引力的广告平台。我们将在后续章节详细讨论腾讯的广告业务。

重要的问题是下一代用户：95后还会是腾讯的基本盘吗？

对于腾讯这种重量级的互联网巨头来说，重要的问题不是抓住某一个细分赛道——在历史上，它曾经错过了电商、微博、搜索引擎等多个重要赛道，但还是维持了全局优势。重要的问题是跟上时代发展、理解并满足下一代消费者的需求。现在，95后群体普遍已经进入大学甚至踏入社会；00后群体已经或即将成年；谁也不能阻挡他们成为新一代主力消费者。所有互联网巨头都在争夺他们，那么，腾讯做好准备了吗？

2018年12月，国金证券研究创新中心利用自有监测数据，结合大范围问卷调查，对95后-05后用户的互联网使用习惯进行了深入研究。我们发明了“95后指数”：以95后用户的日均使用时长，除以全部用户的日均使用时长，得到的比值。这个指数往往大于1，因为95后一般会把更多时间花在互联网上；指数越大，说明该App越受95后用户欢迎。

我们的数据显示：虽然微信的“95后指数”较低，但是QQ、QQ音乐、腾讯视频的“95后指数”都很高，在同类应用中处于领先水平，更不用说游戏App了。总体看来，“腾讯系”比“百度系”“阿里系”“头条系”都更受95后欢迎。抖音当然也很吸引年轻用户，但是其“95后指数”没有明显超过QQ；就连哔哩哔哩的“95后指数”也没有超过QQ。

在95后的网络惯用缩略语（“黑话”）当中，QQ占据着非常重要的地位：QQ消息的提示音被用来打招呼，交朋友的第一步被称为“处Q友”，点赞QQ空间被称为“暖说说”，转发QQ空间则是“k说说”；微信反而居于不太重要的地位。我们发现：95后的网络缩略语里很少出现QQ之外的App，更不要说“腾讯系”之外的App了；虽然抖音、贴吧等也在95后的生活中占据重要地位，但是对他们的文化影响力远不及QQ。

有趣的是，市场似乎没有意识到腾讯在95后群体中的“流量壁垒”和“文化壁垒”。在微信崛起之后，QQ在产品设计上主动“低龄化”，现在已经成为了以年轻人为主要目标用户、主打酷炫功能和趣味社交的App。投资者很少使用QQ、QQ空间、兴趣部落等，无法形成直观印象。我们的草根调研显示，QQ对95后用户的游戏导流效果也明显强于微信，构成了腾讯游戏的“半壁江山”。只要QQ存在，下一代用户就仍然属于腾讯

互联网娱乐内容这碗饭，腾讯可以吃很多很多年

2018年，“产业互联网”或“B端互联网”成为了热门名词，腾讯、阿里均进行了内部改组，以强化B端业务。在云计算领域，腾讯的市场份额远远落后于阿里；在行业软件和解决方案上，腾讯谈不上什么优势。归根结底，腾讯的基因属于“消费互联网”，企业用户资源是其短板。现在，它清楚地认识到了这一短板，但是能否补上短板呢？

让我们换几个问题：如果腾讯一直未能成为“产业互联网”的领导者，在这个领域长期屈居二流，它就会受到致命打击吗？在B端业务上输给阿里、百度和新兴巨头，是否意味着腾讯会满盘皆输？腾讯在娱乐内容、小程序、金融等领域的庞大布局，是否都会变得毫无意义？

如果你对以上问题都做出了肯定的回答，那么，我们还想问一个问题：中国今后是不是只能有一种互联网公司？或者说，互联网公司是不是只能有一种发展轨迹、一种战略，那就是产业互联网？说好的百花齐放、百家争鸣呢？要知道，在美国，既有Amazon、Microsoft、Google这样拥有强大B端业务的科技公司，也有Apple、Facebook、Netflix这样聚焦于C端的巨头；在中国，为什么腾讯就一定要变成阿里、百度的样子呢？

腾讯有可能在产业互联网领域取得胜利。就算不能，它在消费端仍然有巨大的空间，尤其是娱乐内容。迄今，腾讯涉足了几乎所有互联网娱乐内容领域，但是只有游戏成为了强劲的增长引擎。未来几年，长视频也会成为新的增长引擎。然后呢？我们预计，下一个成熟的内容领域，要么是电竞（包括但不限于直播），要么是音乐（包括基于音乐的社交）。

截止2018年，腾讯已经全面、彻底地控制了中国电竞市场。在游戏产品端，腾讯手握几乎所有热门电竞游戏的运营权；在赛事端，腾讯旗下的LPL、KPL赛事的关注度不逊于许多传统体育项目；在直播端，腾讯投资了斗鱼、虎牙，自家旗下还有企鹅电竞。毫不夸张地说，整条电竞产业链都被牢牢掌握在腾讯手中。在亚运会、英雄联盟中国代表队连续夺金之后，电竞的关注度继续攀升。电竞将是腾讯的下一个金矿。

目前，电竞赛事和直播平台的盈利能力仍然很差，电竞还停留在“为游戏产品造势输血”的阶段。然而，电竞产业的巨大用户基础，决定了它总有一天能实现持续、稳定的盈利，就像网络文学和音乐产业已经做到的一样。腾讯要做的，无非是建立良好的规则、掌握绝对的话语权、在产业链的关键节点进行投资并购，耐心等待瓜熟蒂落。2019年2月，腾讯通过知识产权诉讼阻止西瓜视频直播《王者荣耀》，这对全体竞争对手敲响了警钟：掌握强大知识产权资源的腾讯，在这一领域是难以战胜的。

早在2018年上市之前，腾讯音乐就在移动在线音乐市场建立了不可撼动的优势：全国MAU最高的4款音乐App均隶属于腾讯，只有网易云音乐还能勉强与其分庭抗礼。腾讯对于音乐市场的统治是全方位的：在版权音乐方面，它掌握了绝大部分版权资源、拥有最多的订阅用户；在音乐直播方面，它通过旗下的酷狗、酷我、全民K歌的直播功能获得了大量收入；在偶像粉丝经济方面，它是毛不易、火箭少女101等“腾讯系”偶像的出道之地，而且吸引了鹿晗等一大批偶像发布数字专辑。总而言之，腾讯至少能够从三个方向实现音乐变现：第一是版权音乐用户的订阅；第二是直播观众的打赏；第三是偶像粉丝的追星式购买。

投资者将会一直争论下去：腾讯的音乐业务到底应该跟谁对标？是Apple Music、Spotify等欧美版权音乐平台，还是YY、陌陌等秀场直播平台？甚至微博、抖音等内容社交平台？对于腾讯来说，这个问题并不重要，重要的是：音乐是一种重要的娱乐形式，而且它不用“刚性”地占领用户时间，这在流量红利耗尽的时代非常重要。与长视频、短视频行业的群雄逐鹿不同，腾讯通过一系列资本运作，很早就实现了在线音乐市场的统一。这个市场的长期战略价值，很容易被投资者低估。

在互联网巨头之中，“腾讯系”擅长娱乐内容，而且投入了足够资本。相比之下，“阿里系”在娱乐内容领域投资巨大，但是战绩尚不能令人非常满意；“百度系”只拥有长视频平台爱奇艺，而且后者处于独立运营状态；“头条系”的娱乐内容业务主要集中在短视频；“网易系”除了游戏之外的娱乐内容尝试都不甚成功。我们不能武断地低估娱乐内容业务的“技术含量”或“进入门槛”，从而低估腾讯的战略地位。从PC时代开始，娱乐和社交就一同构成了腾讯的优势基因，它们将一直被传承下去。

2019年，主营业务有哪些实质性亮点？不是很多

无论腾讯的长期战略地位有多么稳固，投资者都需要看到短期业绩。2018年二季度以来，腾讯的大部分主营业务都陷入了乏善可陈的低潮期。这背后的原因，一部分在于监管，一部分在于产品周期，但是更多的在于宏观经济。腾讯的规模太大，对于经济周期绝不是免疫的。在中国经济仍然处于“调结构”的情况下，很难指望腾讯在2019年交出一份满意的答卷。

游戏：《王者荣耀》逆势上攻，但是新游戏产品线很弱

2019年1月，《王者荣耀》引入了“战令”系统，它模仿了《堡垒之夜》成功的Battle Pass系统，开启了一个新的“付费深坑”。尤其是对于那些已经审美疲劳、缺乏挑战的老玩家而言，“战令”提供了一个新的刺激点。在春节档，《王者荣耀》进行了大规模活动，旨在全面提升付费率。我们的行业调研显示，该游戏的收入很可能在2月创造了历史新高。

“《王者荣耀》还能火多久”是一个老生常谈的话题。事实上，我们一直对这款游戏的生命周期抱有信心：作为MOBA游戏，它的生命周期本来就应该很长（同类的《DOTA2》《英雄联盟》都是著名的常青树）；它的运营团队非常聪明、富有经验，能够做到细水长流；它的IP号召力强大，电竞赛事和周边产品均能起到支撑作用；它的玩法、付费模式还存在许多创新空间。只要《王者荣耀》团队愿意，收入创新高不是什么难事。问题在于：对于腾讯游戏业务来说，《王者荣耀》一款游戏就够了吗？

答案显然是“不够”。2018年1-3季度，腾讯手游总收入为588亿元（包括计入社交网络增值服务的收入），我们估计《王者荣耀》只贡献了其中的30-35%。按照我们的测算，《王者荣耀》的月均流水可以维持在20亿以上，寒暑假月均流水可以突破30亿；如果进一步提升，就会损害长期价值。所以，腾讯必须源源不断地推出手游新品，才能拉动收入增长。不幸的是，自2018年4季度以来，腾讯就处于手游产品低谷期，只有《红警OL》《火影忍者OL》《侍魂》等少数新品在畅销榜上取得了佳绩，而且这些新品的生命周期普遍不长。2019年1-2月，腾讯甚至没有推出一个新爆款；3月预约上线的产品，也只有《完美世界》具备爆款潜力。

为什么腾讯的手游产品呈现青黄不接？我们认为有三个原因。首先，2018年中国手游玩家规模、付费率和ARPU都已经比较高，“流量红利时代”结束了，现在玩家普遍比较成熟，对新产品也更加挑剔。其次，版号发放暂停9个月，现在仍然处于“消化历史遗留问题”的阶段，一批具备爆款潜力的产品无法上线。再次，《绝地求生：刺激战场》吸走了宝贵的用户资源，成为腾讯体系内的“流量黑洞”，却又因为拿不到版号而无法变现；《刺激战场》给腾讯乃至整个手游市场制造了巨大的压力。

根据我们的监测数据，自2018年7月以来，《刺激战场》的MAU稳定在9000万左右，迄今没有明显下降。我们的草根调研显示，《刺激战场》不但分流了《王者荣耀》等电竞游戏的玩家，也分流了MMORPG、SLG乃至休闲等游戏的玩家。除非出现下一个超级爆款，或者腾讯主动关闭《刺激战场》，否则这个局面很难改变。我们预计，目前在海外大热的端游Apex Legends可能被腾讯引进国内，但是最早也要到下半年，登陆移动端就更晚了。未来几个月的手游新品仍将生存在《刺激战场》的阴影下。在下半年以前，我们看不到《刺激战场》获得版号的希望。

今年，腾讯等待发行的手游新品不少，MMORPG、SLG、电竞、沙盒等品类都不乏潜在佳作。然而，真正具备“现象级”潜力的大作并不多，我们认为主要有《地下城与勇士》(DNF)《指尖江湖》《权力的游戏》《我的起源》等。其中，DNF面临版号风险，而且不一定能在年内满足上线条件；《指尖江湖》仍在反复内测之中，其横版2.5D玩法存在一定的不确定性；《权力的游戏》将是一款生命周期较长的SLG，但是很难贡献爆发性的流水；《我的起源》离产品成熟也还有不小的距离。

在《完美世界》《指尖江湖》《剑歌行》上线之后，手游市场的“端转手”红利就基本用完了。腾讯在想方设法寻找新的IP来源，包括日本动漫、国漫、网络小说、主机游戏等。然而，从2018年的经验看，这些IP改编手游的效果良莠不齐，生命周期往往不长。在玩法上，也缺乏新的刺激点——直到现在，手游厂商还在想方设法地复制“吃鸡”！端游市场就更不用说了，在《绝地求生》无法上线、《堡垒之夜》不温不火、Apex Legends尚未引进中国的情况下，这个市场继续萎缩已成定局。

腾讯游戏业务的长期希望在于海外，可是这个希望难以在1-2年内兑现。2018年，腾讯在东南亚、北美等多个市场对《王者荣耀海外版》《PUBG Mobile》进行了大规模推广。然而，根据公司披露的数据，前者的最高月流水仅为3000万美元，后者仅为2000多万美元。腾讯的老对手网易，在海外市场（尤其是日本）推出了多个爆款手游，2018年4季度来自海外的游戏收入占比也不过提升到了10%左右。腾讯的游戏业务体量远大于网易，想通过发展海外市场拉动整体增长，在短期是不现实的。

广告：需求不振、单价下滑，提高供给真的有用吗？

市场一直对腾讯的广告业务寄予厚望：它还有许多广告位没有开发出来，历史上的广告销售效率不高，内部数据也没有打通。在2018年10月成立AMS（广告业务线）之后，以上问题有望得到解决。然而，广告业务的发展是由供给和需求共同决定的。在经济持续减速、广告主预算吃紧的情况下，仅仅提高广告位的供给，真的有用吗？

国金证券研究创新中心的独家监测数据显示，2018年8月以来，移动广告的流量价格（CPM和CPC）就进入了下滑轨道，到年底已经基本跌回2016年的水平。我们认为，流量价格下跌是需求不足导致的：在主要广告主当中，汽车、地产受到宏观经济影响最严重；互联网金融受到了监管收紧的影响；游戏受到了版号瓶颈的影响；新兴“独角兽”公司受到了融资环境紧张的影响。进入2019年，除了游戏行业由于版号恢复发放，需求可能有边际恢复之外，其他广告主的需求仍然增长乏力。

腾讯旗下的广告载体主要有三种：以微信、QQ为代表的社交平台；以腾讯新闻、天天快报、QQ浏览器为代表的资讯与分发平台；以腾讯视频、QQ音乐为代表的娱乐内容平台。无论是哪一种，都面临着流量价格下跌的趋势。我们的数据显示，这一轮流量价格回落是全行业性的，任何类型的移动App都不能免俗，而且PC端流量也出现了回落。除非腾讯能在2019年创造一个新的超级App，或者能够显著拉高已有App的MAU和DAU水平，否则广告主需求很难出现爆发性增长。

在广告供给端，腾讯手里可打的牌也不一定有市场想象的那么多。2018年，腾讯已经推出了QQ看点、增加了微信公众号和朋友圈广告位、设立了小程序广告位、大力发展了腾讯视频的创意中插广告。现在，腾讯还可以开启的广告位，主要集中在微信：朋友圈还可以插入第三条甚至更多的广告；公众号可以增加一条中插广告；订阅号和看一看尚未插入信息流广告；搜一搜尚未推出关键词广告。此外，微信小程序现在的广告以Banner为主，今后可以增加定制广告甚至与交易撮合有关的广告等。看样子，腾讯尚未利用的广告资源，确实比大部分竞争对手更多。

问题在于：腾讯不可能激进地增加广告供给。首先，微信团队不会容忍损害用户体验的现象，增加任何广告位都要慎之又慎；在2019年1月的微信公开课上，张小龙已经彻底阐述了他的产品开发理念，短期广告变现绝不是现在的工作重点。其次，在需求不振的情况下，就算增加广告供给，变现效率也不会太高——根据我们的草根调研，微信朋友圈第二条广告开启之后，广告填充率甚至有过明显的下降。大部分公众号和小程序都属于微信生态系统内部的“长尾流量”，需要精耕细作地逐步开发，而不是像某些竞争对手一样不计后果地增加广告。

增值服务：长视频是唯一能“挑大梁”的，但是不宜期望过高

腾讯的社交网络增值服务（除游戏之外）主要包括：QQ付费会员收入；视频平台付费会员收入；版权音乐与直播付费收入；动漫、文学等内容付费收入，等等。其中，我们对版权音乐、电竞直播和动漫的未来寄予厚望，但是它们的体量尚小、商业模式尚不十分成熟。在2019-20年，唯一能够挑起重担的是长视频的付费会员收入。

我们的自有监测数据显示：在三大视频平台中，优酷的MAU和DAU明显逊色一筹，而腾讯视频和爱奇艺一直难分伯仲。在《延禧攻略》《青春有你》等热门节目上映时，爱奇艺的DAU往往能甩开腾讯视频一截。2019年，我们估计阿里不会出售或放弃优酷，三大视频平台的缠斗仍将继续下去。与此同时，我们观察到芒果TV的DAU在2019年初有明显的上升势头。总而言之，腾讯视频面临的竞争格局，在短期内不会有明显好转。

2018年底，爱奇艺宣布订阅会员达到8740万，我们估计腾讯视频的订阅会员数与此相仿。根据我们的测算，腾讯视频的付费渗透率已经接近20%，虽然仍有上升空间，但是增长最快的时期可能快要过去了。在市场竞争激烈的情况下，视频平台的ARPU很难在短期内有显著提升。除非腾讯视频能开发出新的付费模式，或者能够实现行业整合，否则在2019年要继续实现付费收入的爆发性增长，难度会很大。

2018年下半年以来，随着影视行业“限薪令”推出、影视明星补缴所得税、流量明星路线受到质疑，头部影视剧价格的疯涨势头得到了抑制，这肯定有利于腾讯视频的成本控制。但是，2019年出现“剧荒”已成定局，这无疑也会影响流量增长和观众的付费意愿。结果，腾讯视频可能面临亏损率大幅收窄（甚至在某个季度实现盈利）、收入和付费会员增长乏力的局面。虽然我们相信，这项业务在长期必将成为腾讯娱乐内容战略的重要支点，但是无法指望它在2019年作出较大的业绩贡献。

其他业务：移动支付高歌猛进，可惜利润率大受影响

我们估计，腾讯的“其他业务”收入有85%以上来自第三方支付等互联网金融业务。根据公司公布的2018年客户投诉情况，可以推断出当年支付宝总交易笔数为1975亿笔，财付通为4665亿笔。虽然我们估计支付宝的交易金额仍然略大于财付通，但是毫无疑问，腾讯已经在支付领域取得了很大的成功。这一成功，很大程度上归功于微信的流量优势：虽然2018年以来，支付宝的渠道下沉和获客也很成功，但是毕竟无法与微信相提并论。在三线以下城市的蓝海市场，微信的优势非常明显。

遗憾的是，腾讯在高附加值的金融业务方面，仍然远远落后于蚂蚁金服。后者是全国最大的第三方基金销售渠道之一，而且是天弘基金的第一大股东；蚂蚁花呗、蚂蚁借呗都是举足轻重的互联网消费信贷平台；芝麻信用在“阿里系”的新零售版图中扮演着重要角色。相比之下，腾讯的脚步非常缓慢：与蚂蚁“余额宝”对标的“零钱通”直到2018年11月才上线（此前推出的“理财通”没有支付功能）；腾讯没有与“蚂蚁花呗”对标的产品，与“蚂蚁借呗”对标的“微粒贷”归属于微众银行而非腾讯自身；迄今腾讯还没有开通个人征信分数。

当然，在央行重视金融风险、提倡互联网金融机构缩表的情况下，腾讯的谨慎是有道理的。但是，缺乏高利润业务，却让规模庞大的“其他业务收入”很难贡献实质性的利润。我们估计，此前“其他业务”的毛利有一半以上来自微信支付备付金的利息，而所有第三方支付机构的备付金已经于2019年1月上缴央行，这将对毛利率构成巨大压力。

我们认为，腾讯可以通过三种方式弥补备付金上缴所损失的利润：第一是减少支付补贴，今年春节微信支付就基本没有参与全国性的“红包大战”；第二是向微众银行等合作伙伴收取更高的服务费或利息分账；第三是积极开拓高利润业务，例如基金分销、消费信贷乃至中小企业贷等。就算三管齐下，2019年“其他业务”毛利率仍然会不可避免地下滑。

从长期看，移动支付对新零售至关重要，蚂蚁金服绝不会坐视微信支付坐大。因此，2019年的移动支付“补贴战”很难停下来。与此同时，银联还没有放弃争夺移动支付市场，京东、美团等巨头也还维持着对金融业务的投入。我们估计，即便到了2021-22年，互联网金融业务也不可能成为腾讯的主要利润来源，因为竞争将一直非常激烈。

除了营业收入，投资者还应关注哪些方面？

对于腾讯，乃至对于大部分成熟的互联网公司，投资者最关心的都是扣非(Non-GAAP)净利润。扣非净利润最重要的驱动力固然是营业收入，但是成本费用控制、分占联营公司利润等也非常重要。此外，投资者还需要考虑投资收益，或者投资对象（不包括联营公司）的市场价值，尽管它们不会影响扣非净利润。在这些方面，腾讯有一些亮点。

联营公司范围不断扩大，下一步是并表范围扩大吗？

在历史上，腾讯的战略投资非常频繁、涉及面广，甚至被戏称为“投行化”。一般而言，它倾向于担任消极投资者，不参与被投对象管理。在2017年以前，被腾讯纳入联营范围内的大型公司，只有京东等寥寥几个。现在，情况发生了戏剧性变化：2018年前三季度，腾讯对5家重要联营公司进行了投资或增持，我们估计其身份分别是：拼多多、快手、斗鱼、盛大游戏、万达商业地产。此外，腾讯还在其他联营公司上投资196亿元之多。

“联营公司”与“投资对象”最大的区别是：前者的利润按比例划归腾讯的“分占联营公司利润”，并计入扣非净利润；后者则只为腾讯提供投资收益或公允价值变动收益，一般不计入扣非净利润。腾讯对联营公司往往具备一定的影响力，例如参与董事会、提供流量入口、进行业务联动等。如果腾讯持股比例较高，而且联营公司并未接受阿里、百度等其他互联网巨头的投资，那么腾讯的影响力可能是举足轻重的。

扩大联营公司范围，在短期内对腾讯的利润影响有限：它的联营公司大部分还处于亏损或微利阶段。但是，随着时间推移，大部分联营公司终将盈利。更重要的是：腾讯会不会向阿里一样，走上收购控股以扩大并表范围的道路？例如，腾讯对虎牙的投资协议规定腾讯有权在公开市场增持至控股；根据《韩国经济日报》报道，腾讯正在参与对韩国游戏巨头Nexon的收购竞标。2018年以来，国内创业融资环境恶化，新兴“独角兽”们也更渴望来自互联网巨头的资金，这是腾讯的良机。

对腾讯来说，一旦扩大联营公司乃至并表公司范围，管理本身不会是难题：它一贯采取“赛马”机制，鼓励内部竞争，而不是实施中央集权。腾讯就像是一系列“竞争合作”的业务实体组成的联邦。只要能出业绩，业务实体享有较大的自由权——微信事业群就是最好的例子。虽然扩大并表范围会加剧“大企业病”的风险，但是这种风险是可控的。

即便不扩大并表范围，腾讯现有的战略投资组合也值得市场认真研究。在MAU 5000万以上的移动互联网“独角兽”当中，腾讯投资了8个，其中搜狗、拼多多、美团、趣头条与腾讯都构成了共生关系。在海外、在线下，腾讯的投资范围就更广阔了。我们预计，今后腾讯的投资并购将指向三个战略方向：第一是新零售和O2O；第二是海外互联网与本地生活服务；第三是内容生产（包括游戏、影视、动漫等）。至于已经进行的战略投资的市场价值到底有多少？这个问题有待公司进一步的信息披露。

控制薪酬就是控制费用，但是有些费用无法控制

2012年以来，腾讯每一年的员工人数增速都低于收入增速，因此人均产出是不断增加的。在持续的规模效应下，公司的销售管理费率基本呈现下降的势头。2019年，在不利的经济形势下，我们预计腾讯将严格控制人数，实行内部调整，这也是大部分互联网公司正在做的事情。当然，腾讯的员工人数可能随着收购而增长，但是我们预计内生增长率会很低。

与大部分互联网公司一样，员工薪酬是腾讯成本开支当中最高的一项。2014年以来，由于规模效应，员工薪酬与营业收入的比例一直在缓慢下降（如果排除股权激励，下降势头会减缓）；2018年上半年，这个势头仍在持续。我们估计，腾讯将量入为出，严格控制现有员工的薪酬福利。在互联网行业整体不景气的情况下，腾讯的发展潜力、品牌和工作稳定性对从业人员很有吸引力，就算控制薪酬也不太可能导致人才流失。

问题在于：有些开支是不能削减的。首先是推广与广告费用，它占营业收入的比例在2018年上半年有显著上升。腾讯正在进军产业互联网，需要在企业用户中树立品牌形象；它的海外扩张也需要大量市场营销开支；在游戏行业，由于流量红利耗尽，广告所起的作用也会越来越大。我们估计这项费用会持续增长，推动销售费用率在2019年攀升。

其次是研发费用，绝大部分体现为研发人员的薪酬。无论是新兴的产业互联网还是传统的消费互联网业务，都需要投入大量基础研发和产品研发经费。腾讯的研发费用率在BAT当中本来就处于最低水平，削减研发投入无疑会削弱长期竞争力。因此，腾讯不太可能控制研发费用。

总而言之，腾讯可以通过控制员工人数、控制薪酬水平来压制成本费用率，但是效果有限。管理费用率（不含研发费用）可能有一定的压缩空间，但是销售费用率和研发费用率都可能在2019年有所上升。我们认为，腾讯在未来几年不太可能像2013-17年一样享受持续的规模效应。

财务预测与估值

我们认为市场对腾讯的一致预期偏高

我们认为，彭博一致预期对腾讯过于乐观；我们对2018-2021年的营业收入、EBIT和Non-GAAP净利润的估计均低于一致预期。当然，彭博一致预期不一定能反映投资者在这个时间点的真实预期。

我们认为一致预期可能在以下几个方面高估了腾讯未来几年的业绩潜力：首先是游戏业务，虽然2019年春节期间《王者荣耀》的表现很好，但是市场可能忽略了腾讯缺乏重量级手游新品的事实。其次是广告业务，市场可能只注意到腾讯尚有很多广告位可以供给，没有考虑到经济增速放缓导致的广告主需求不足。第三是其他业务，虽然市场普遍认识到了备付金上缴将对支付业务的利润造成压力，但是可能低估了其影响力。最后是费用，市场可能错误地认为过去几年的规模效应还能持续。

我们对腾讯2018-20年财务业绩的核心预测假设如下：

游戏业务：

端游收入在2018-19年都将下滑。但是，我们预计新一代电竞端游（例如Apex Legends、刀塔自走棋或其同类产品）将于2019年下半年引进国内，从而遏制下滑势头；2020年，端游市场可能出现反弹，因为玩家流失已经告一段落，付费将维持较高水平。

手游收入在2018年四季度和2019年一季度都将出现5-10%的同比下滑；虽然《王者荣耀》的收入非常坚挺，还是无法完全抵消手游新品缺乏的影响。但是，从二季度开始，腾讯将进入一个新的产品周期。最大的不确定性在于：《刺激战场》能否获得版号，DNF手游能否在年内上线？我们认为，《刺激战场》在2019年三季度以前获得版号的希望非常渺茫，而DNF手游最早也要到2019年四季度上线。所以，2020年腾讯手游收入的增速反而可能提升。与此同时，海外市场能够在一定程度上拉动手游业务。

社交网络增值服务业务：

手游分账收入增速将比手游业务稍微慢一些，因为来自海外的手游收入不会向社交网络应用（微信和QQ）进行分账。

其他增值服务收入最大的增长引擎是长视频，但是该项业务面临着爱奇艺、优酷的激烈竞争，而且2019年仍将处于亏损状态。在线音乐（包括版权音乐、直播和社交）是第二大增长引擎，而且将在腾讯的网红产业链中扮演重要角色。网络文学、动漫、电竞直播等业务也将高速增长，但是基数较低。还有一大块收入来自QQ会员付费，由于QQ的总用户正在下跌（虽然它深受95后用户欢迎），我们预计该项收入未来几年会略有下滑。

广告业务：

媒体广告收入将呈现温和增长，因为长视频的商业模式重心向会员付费转移，而腾讯新闻、天天快报对广告主缺乏新的吸引力。

社交广告收入将呈现较快增长，但是我们只能保持谨慎乐观：腾讯尚未开启的广告位主要在微信，而微信团队绝不会进行过于激进的广告变现；指望微信的广告负载率达到微博、今日头条或新闻门户的水平，是不现实的。更重要的问题在需求端：宏观经济放缓将抑制广告主的需求，腾讯不可能在这种局面下实现爆发性增长。

其他业务：

第三方支付收入将继续较快增长，但是随着基数变大，增速会不断放缓。移动支付向四线以下城市下沉、零钱通等新业务的发展，是这项业务的主要推动力；但是，备付金上缴会影响收入和利润。

云计算和智慧产业收入将在较低的基数之上实现较快增长，不过在2-3年内还不会是一项重要业务。目前，我们尚缺乏足够的信息。

毛利率与费用率：

我们预计，2019-20年，社交网络增值服务（包括游戏）的毛利率将基本持平；广告业务的毛利率会略有上升，主要受益于视频内容采购成本的缓解；其他业务的毛利率会有大幅度下降，主要受到备付金上缴的影响。总体上，2019年的毛利率会下降，2020年持平。

销售费率在2018年前三季度已经呈现同比上升的势头，我们预计腾讯将在云计算、产业互联网、海外市场等方面投入巨额推广费用。2018-19年，该项费率会继续上涨；2020年这个势头可能结束。

管理费率在控制人员薪酬的前提下，可以得到削减；但是，其中包含的研发费率很难有削减空间。我们预计该项费率基本保持稳定。

估值与目标价调整

我们以DCF作为腾讯估值的基础。我们认为，DCF能够全面反映公司的战略地位、长期增长空间和抗风险能力，从而最适合为腾讯这样的互联网平台型公司估值。此外，我们加回战略投资、公允价值投资等“非核心业务”的价值，但是不包括“对联营或合营公司投资”的价值，因为它们的利润贡献已经体现在损益表之内。

我们的DCF基本假设是：9.0%的WACC、3年的第一阶段成长期、10年的第二阶段成长期、15.0%的第二阶段增长率、5%的永续增长率和10%的永续ROIC。腾讯并未详细披露战略投资的市场价值，但是我们估计其中很多投资对象的估值都已经大幅提升，所以我们赋予其2倍P/B的估值；此外，净现金价值也按照账面价值加回。

综上所述，我们得出的腾讯目标价为365港元，对应40.9倍/35.4倍/28.6倍2018E/2019E/2020E Non-GAAP P/E。这个估值水平在所有港股及中概股互联网公司中处于较高水平，也是腾讯历史上的较高水平。我们并不担心腾讯的战略地位——它仍然是投资者长期布局中国互联网行业的最佳选择之一。但是，鉴于市场一致预期偏高，而且估值处于高位，我们建议投资者在短期保持谨慎。下调评级至“中性”。

风险因素

作为互联网公司，监管风险是不可忽视的。游戏、视频、第三方支付等都属于国家严格监管的行业，政策变化可能难以预知。

腾讯正在拓展包括金融支付、云计算、人工智能等在内的新业务，在这些领域已经存在强大的竞争对手，公司可能无法达到战略预期。

技术是互联网公司的生命线，而腾讯的基础研究水平并不明显高于同行，因此存在技术进步带来的业务和产品替代风险。

腾讯对外进行大量战略投资，而且信息披露细节较少；虽然腾讯每年都进行大量投资减值拨备，但是仍不能忽略战略投资减值的风险。

网易云音乐下载接口加密破解思路及步骤（附 Python 源码）

Sun, 10 Feb 2019 00:00:00 CST

故事起因

很喜欢网易云音乐，甚至剁手开了年费会员，我这么爱它，所以就很想破解它，控制不住自己，然后就有了这篇文章。

初步探索

寻找目标 URL

我随便找到一首歌，然后打开开发者工具，清空记录，按照下图设置：

然后我点击网页的播放按钮，查看输出，等几秒之后，暂停播放，开始检查得到的 URL 及其响应结果，当我看到下图的 URL 时，已经可以确定这个就是我要找的目标 URL 了。

寻找目标 JS

和往常一样，我打开 URL 的参数检查，如下图所示。

可以看到此 URL 有一个 csrf_token 查询字符串，以及两个需要 POST 的数据：params 和 encSecKey。

由于平时经常写爬虫，所以我对 URL 的查询字符串异常敏感，我尝试去掉 csrf_token 重新 POST，如图：

发现得到的结果和之前一样，故得出结论 csrf_token 这个东西没有用，我接着看两个 POST 的数据，按照以往的经验，这么长这么重要而且还是 POST，一定是经过 JS 加密的，所以我要找到那个目标 JS，但是假如盲目的寻找肯定找上几个小时也不得行，所以我选择“投机取巧”，直接搜索表单的 key，搜索 params 得到了很多结果，所以我搜索的是 encSecKey，如图：

那么现在，我的目标 JS 也找到了

初步分析 JS

我打开 JS ，搜索 encSecKey，跳到图中位置：

显然，我需要的两个参数都和 bUK5P 有关，所以我需要知道 bUK5P 是如何计算得到的，那么所有问题就都解决了，所以我在图六画圈的位置打了一个断点进行调试。

详细的调试技巧各位朋友如果不熟悉请自行谷歌，毕竟我最讨厌那些以干货自居的科普文了。

刷新网页，进入调试界面，点击恢复或者摁下 F8 ，然后一直点跨越或者步进或者摁 F10/F11，直到当前代码运行位置到达断点之后的语句，如图：

然后我进入 console 开始进一步检查，我依次向 console 发送图中的消息，得到的结果如图：

初步总结

根据以往的经验以及以上的初步分析，我得到以下结论，朋友们也可以认真思索一下：

encSecKey = bUK5P.encSecKey，params = bUK5P.encText

bUK5P 是由函数 window.asrsea 计算得到的

e5j 是获取歌曲 URL 的详细方式

函数 window.asrsea 需要传入四个参数，具体四个参数的分析下面会接触到

最关键的是 function d() 就是函数 window.asrsea

得到以上结论之后，我开始进行更加深入地探索

深入探索

分析参数

点击 console 的 function d()进入 d 在 JS 中的位置：

简单浏览函数可以看到：函数 d 调用了 a，b，c 三个函数，a，b，c 的内容如图：

简单阅读代码可以知道：

函数 a 是产生随机的16为字符串

函数 b 是 AES 对称加密过程

函数 c 是 RSA 非对称加密过程

看到这里，我的心里关于网易处理歌曲加载请求的流程已经有了一个大概，卖个关子，继续往下看。

为了详细的探索这四个函数首先我要知道函数 d 的四个参数都是什么，我依旧在图七中的位置打上断点：

第一次经过断点，各个变量的值如图：
第二次经过断点，各个变量值如图：

我得到结论： 传入函数 d 的四个参数都是常量

分析函数

知道了参数是什么，我开始分析四个函数，我在图示的位置打上断点，至于为什么这么打，请朋友你自行思索：

然后开始调试，经过三个断点，h 的变化情况及各参数的值如图：

好的，调试到这里，我觉得我已经彻底搞清楚这四个函数了，下面我想结合 JS 代码分析一下：

// 函数 a 产生随机 a 位字符串      
functiona(a){      
vard,      
e,      
b ='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789',      
c ='';      
for(d =0; a > d; d +=1) e =Math.random() * b.length,      
e =Math.floor(e),      
c += b.charAt(e);      
returnc      
}      
// 函数 b 为 AES 对称加密过程，返回值为加密结果字符串，      
// 参数 a：待加密内容，分别为"{\"ids\":\"[32835565]\",\"br\":128000,\"csrf_token\":\"\"}"和 h.encText；      
// 参数 b：密钥，长度 16*2=32 bytes，分别为brA7t(['爱心','女孩','惊恐','大笑'])和 i；      
functionb(a, b){      
varc = CryptoJS.enc.Utf8.parse(b),      
d = CryptoJS.enc.Utf8.parse('0102030405060708'),      
e = CryptoJS.enc.Utf8.parse(a),      
// c 是key，也就是密钥，长度为32*4=128 bits，所以可知函数 b 加密方式为 AES-128；      
// d 是iv，也就是初始向量；e 是待加密的内容；      
// f 是加密结果；mode 是加密模式为 CBC      
f = CryptoJS.AES.encrypt(e, c, {      
iv: d,      
mode: CryptoJS.mode.CBC      
});      
returnf.toString()      
}      
// 函数 c 为 RSA 非对称加密过程      
// 参数 a：16位随机字符串 为 i；      
// 参数 b：6位2进制数字 为brA7t(['流泪','强'])；      
// 参数 c：很长的一串，为brA7t(WU9L.md)      
functionc(a, b, c){      
vard,      
e;      
returnsetMaxDigits(131),      
// c 作为公钥 public_key      
// b 是指数      
d =newRSAKeyPair(b,'', c),      
// a 是待加密的字符串      
e = encryptedString(d, a)      
}      
// 函数 d 得到 h 结果，即 bUK5P 的结果      
// 对照图五及图七可以知道函数 d 的每一个参数都是什么，因为每个参数都是固定的      
functiond(d, e, f, g){      
varh = {      
},      
// 调用函数 a 得到参数 i      
// i 的结果为一个16位的随机字符串      
i = a(16);      
      
// 下面的代码为：两次调用函数 b 得到 encText，一次调用函数 c 得到 encSecKey，最后返回结果 h      
returnh.encText = b(d, g),      
// 第一次调用 b      
h.encText = b(h.encText, i),      
// 第二次调用 b      
h.encSecKey = c(i, e, f),      
// 调用 c      
h      
}

深入总结

调试了这么久，我就通过猜测网易云音乐处理加载音乐请求的过程来总结一下我得到的所有结论吧：

处理过程

传输的内容经过 AES 和 RSA 两次加密，每次请求随机产生 16 位随机字符串。

首先对歌曲ID等等信息进行两次 AES-128 加密作为 params

第一次常量加密

第二次随机产生 16 位字符串加密

然后对 16 位密钥进行 RSA 加密作为 encSecKey

最后将 encSecKey、params等等传送给服务端

服务端 RSA 解密 encSecKey 得到 16位密钥，再通过密钥解密 params 得到请求信息

服务端返回结果

终极结论

首先随机产生的 16 位密钥是随机的，也是网易控制不了的，所以我相信认真阅读的朋友应该也已经恍然大悟了。

我可以一直使用相同的 16 位字符串，那么 encSecKey 也就成了常量，然后我只需要写一个进行 AES加密的函数就可以了。

Python 实现

加密模块实现

首先我规定密钥为：

1	ryPnuAVT5RtiIWNi

encSecKey为：

a71973af53caae445b554150da52e75ba5687609d28013aacea03e9ef07169560f156ca76be9ac8df7bb204e05b864756aa3dd2274a65d5be964f118f6d075006695059e10cdcc806306e9a5f2f36f5bf0379f511cd13a600a6cc7031c814583863ea84d3373dea69f74354cd2dc3af61d58eeb43b1de06f588ef361ebc1eed6

然后 Python 实现的 AES-128 加密函数为：

fromCrypto.CipherimportAES      
importbase64      
importjson      
key1 =b'0CoJUm6Qyw8W8jud'      
key2 =b'ryPnuAVT5RtiIWNi'      
content = {"ids":"[32835565]","br":128000,"csrf_token":""}      
encSecKey ='a71973af53caae445b554150da52e75ba5687609d28013aacea03e9ef07169560f156ca76be9ac8df7bb204e05b864756aa3dd2274a65d5be964f118f6d075006695059e10cdcc806306e9a5f2f36f5bf0379f511cd13a600a6cc7031c814583863ea84d3373dea69f74354cd2dc3af61d58eeb43b1de06f588ef361ebc1eed6'      
bs =16# block size      
# 填充方式为：PKCS5      
pad =lambdas: s + (bs - len(s) % bs) * chr(bs - len(s) % bs)      
encrypt_token =lambdakey, content: AES.new(key=key, mode=AES.MODE_CBC, IV=b'0102030405060708').encrypt(pad(content).encode())      
if__name__ =='__main__':      
str_content = json.dumps(content)      
tmp = base64.b64encode(encrypt_token(key1, str_content)).decode()      
params = base64.b64encode(encrypt_token(key2, tmp)).decode()      
print(params)

计算得到的 params 为：

1	9c3ailRGd3aMtbgRQFsMT6ezDBrVvgP9ENnHgTloTgDKutNCCUxwU8qugl7OFqOY6QumjhXlhqTEV4fp4DeoiMoiMSLZFj0t8pbq7rV8Xt/i/ulXVGvKTaN10KfF8QVs

接下来使用火狐插件 RESTClient 自行 POST 数据进行验证，如图：

简易接口实现

不多说什么，上完整代码，此代码扩展性很强，记得给我点赞哦~

fromCrypto.CipherimportAES      
importbase64      
importjson      
importrequests      
      
# 常量      
headers = {      
'User-Agent':      
'Mozilla/5.0 (Windows NT 10.0; WOW64; rv:65.0) Gecko/20100101 Firefox/65.0',      
'Referer':      
'https://music.163.com/',      
'Content-Type':      
'application/x-www-form-urlencoded',      
}      
post_url ='https://music.163.com/weapi/song/enhance/player/url'      
content = {"ids":"","br":128000,"csrf_token":""}      
key1 =b'0CoJUm6Qyw8W8jud'      
key2 =b'ryPnuAVT5RtiIWNi'      
encSecKey ='a71973af53caae445b554150da52e75ba5687609d28013aacea03e9ef07169560f156ca76be9ac8df7bb204e05b864756aa3dd2274a65d5be964f118f6d075006695059e10cdcc806306e9a5f2f36f5bf0379f511cd13a600a6cc7031c814583863ea84d3373dea69f74354cd2dc3af61d58eeb43b1de06f588ef361ebc1eed6'      
      
# 加密      
pad =lambdas: s + (16- len(s) %16) * chr(16- len(s) %16)      
encrypt_token =lambdakey, content: AES.new(key=key, mode=AES.MODE_CBC, IV=b'0102030405060708').encrypt(pad(content).encode())      
      
      
# 接口      
defmusic_interface(song_id):      
content["ids"] ="[{}]".format(song_id)      
str_content = json.dumps(content)      
tmp = base64.b64encode(encrypt_token(key1, str_content)).decode()      
params = base64.b64encode(encrypt_token(key2, tmp)).decode()      
post_data = {      
'params': params,      
'encSecKey': encSecKey,      
}      
resp = requests.post(url=post_url, headers=headers, data=post_data)      
js = json.loads(resp.content)      
song_url = js['data'][0]['url']      
returnsong_url      
      
      
if__name__ =='__main__':      
song_url = music_interface('32835565')      
print(song_url)

后话

最后，我想说一下我的感想。

各位朋友在看到本文之前可能会疑问为什么网易云音乐网页版无法听无损音质的歌，看完之后各位应该了解了，其实这也是网易为了版权保护而采取的下策。

我想，假如非要破解网易云的无损音质下载，那么可能需要逆向网易云音乐的 APK/EXE 构造请求，或者对软件本身进行 Hook 才可以做到吧，等以后有机会有能力我一定会填上这个坑。

生活愉快~

aria2 多协议和多源命令行下载实用程序

Sun, 20 Jan 2019 11:13:18 CST

aria2是一个 轻量级的多协议和多源命令行 下载实用程序。它支持 HTTP / HTTPS， FTP， SFTP， BitTorrent和 Metalink。aria2可以通过内置的 JSON-RPC和 XML-RPC接口进行操作。

下载

下载版本1.34.0。在那里，您可以下载OS X，Windows和Android的源代码分发和二进制文件。

这里提供了早于1.19.1的旧版本。

特征

多连接下载。aria2可以从多个源/协议下载文件，并尝试利用您的最大下载带宽。真正加快您的下载体验。
轻量级。aria2不需要太多内存和CPU时间。当磁盘缓存关闭时，物理内存使用量通常为4MiB（正常HTTP / FTP下载）到9MiB（BitTorrent下载）。下载速度为2.8MiB /秒的BitTorrent的CPU使用率约为6％。
功能齐全的BitTorrent客户端。您可以在BitTorrent客户端中使用所有功能：DHT，PEX，加密，磁体URI，Web种子，选择性下载，本地对等发现和UDP跟踪器。
Metalink已启用。aria2支持 Metalink下载格式（又名Metalink v4），Metalink版本3和 Metalink / HTTP。Metalink提供文件验证，HTTP / FTP / SFTP / BitTorrent集成以及语言，位置，操作系统等的各种配置。
遥控器。aria2支持RPC接口来控制aria2进程。支持的接口是JSON-RPC（通过HTTP和WebSocket）和XML-RPC。

用法示例

命令行吓跑了你？不，aria2真的很容易使用!!

从WEB下载：

1	`$ aria2c http://example.org/mylinux.iso`

从2个来源下载：

1	`$ aria2c http://a/f.iso ftp://b/f.iso`

每个主机使用2个连接下载：

1	`$ aria2c -x2 http://a/f.iso`

BitTorrent的：

1	`$ aria2c http://example.org/mylinux.torrent`

BitTorrent磁铁URI：

1	`$ aria2c 'magnet:?xt=urn:btih:248D0A1CD08284299DE78D5C1ED359BB46717D8C'`

Metalink知识库：

1	`$ aria2c http://example.org/mylinux.metalink`

下载文本文件中的URI：

1	`$ aria2c -i uris.txt`

UI Frontends

webui-aria2： aria2的 Web浏览器界面（2012 GSOC项目）
uGet：Linux下载管理器

如何把多个网页合并下载为 PDF

Thu, 17 Jan 2019 12:11:09 CST

来自微博的问题：有没有什么软件可以把多个网页合并下载为 PDF，比如我想把图上的域名下的所有网页合并下载为一个 PDF 文件。@小众软件

这是一个非常经典的问题，关乎两种文档格式的不同特性。因为 HTML 的离线不可用性，和 PDF 的任何情况下的完整性，所以将需要离线阅读的内容 PDF 化是一个非常不错的主意。

最终 @ 剑心_h 同学推荐了一款命令行工具： wkhtmltopdf（在 GitHub 开源），青小蛙研究了一下，似乎可行，简单易用。

wkhtmltopdf 全称 WK<html>TOpdf，是一个专门用来转换网页到 PDF 的工具，唯一的门槛就是没有图形化界面，需要使用命令行。

在使用之前需要安装，Windows 用户需要进入安装目录后，在地址栏输入 cmd 以打开当前目录的命令行，然后就可以使用了。其他系统用户相信会很熟悉命令行。

  wkhtmltopdf https://www.appinn.com/ appinn.pdf

上面就是最近的将网页转换为 pdf 的命令，而如果你想添加目录，或者禁用 js，还可以使用参数:

  wkhtmltopdf toc https://www.appinn.com/ appinn.pdf #生成目录
wkhtmltopdf -n https://www.appinn.com/ appinn.pdf #禁用 js

这样就能非常方便的将网页转换为 pdf 了，还有参数可以设置分辨率、页面边距、是否压缩、是否显示图片等等，更多可以参考这篇文章。

有了 PDF，合并就容易了，这里推荐 SmallPDF 在线工具，很方便就合并了。

如果，你有更好的将图片转换成 PDF 的工具，欢迎留言推荐。

Redis 高负载下的中断优化

Sat, 17 Mar 2018 03:30:00 CST

背景

2017年年初以来，随着Redis产品的用户量越来越大，接入服务越来越多，再加上美团点评Memcache和Redis两套缓存融合，Redis服务端的总体请求量从年初最开始日访问量百亿次级别上涨到高峰时段的万亿次级别，给运维和架构团队都带来了极大的挑战。

原本稳定的环境也因为请求量的上涨带来了很多不稳定的因素，其中一直困扰我们的就是网卡丢包问题。起初线上存在部分Redis节点还在使用千兆网卡的老旧服务器，而缓存服务往往需要承载极高的查询量，并要求毫秒级的响应速度，如此一来千兆网卡很快就出现了瓶颈。经过整治，我们将千兆网卡服务器替换为了万兆网卡服务器，本以为可以高枕无忧，但是没想到，在业务高峰时段，机器也竟然出现了丢包问题，而此时网卡带宽使用还远远没有达到瓶颈。

定位网络丢包的原因

从异常指标入手

首先，我们在系统监控的net.if.in.dropped指标中，看到有大量数据丢包异常，那么第一步就是要了解这个指标代表什么。

这个指标的数据源，是读取/proc/net/dev中的数据，监控Agent做简单的处理之后上报。以下为/proc/net/dev 的一个示例，可以看到第一行Receive代表in，Transmit代表out，第二行即各个表头字段，再往后每一行代表一个网卡设备具体的值。

其中各个字段意义如下：

字段	解释
bytes	The total number of bytes of data transmitted or received by the interface.
packets	The total number of packets of data transmitted or received by the interface.
errs	The total number of transmit or receive errors detected by the device driver.
drop	The total number of packets dropped by the device driver.
fifo	The number of FIFO buffer errors.
frame	The number of packet framing errors.
colls	The number of collisions detected on the interface.
compressed	The number of compressed packets transmitted or received by the device driver. (This appears to be unused in the 2.2.15 kernel.)
carrier	The number of carrier losses detected by the device driver.
multicast	The number of multicast frames transmitted or received by the device driver.

通过上述字段解释，我们可以了解丢包发生在网卡设备驱动层面；但是想要了解真正的原因，需要继续深入源码。

/proc/net/dev的数据来源，根据源码文件net/core/net-procfs.c，可以知道上述指标是通过其中的dev_seq_show()函数和dev_seq_printf_stats()函数输出的：

  static int dev_seq_show(struct seq_file *seq, void *v)
{
    if (v == SEQ_START_TOKEN)
        /* 输出/proc/net/dev表头部分   */
        seq_puts(seq, "Inter-|   Receive                            "
                  "                    |  Transmit\n"
                  " face |bytes    packets errs drop fifo frame "
                  "compressed multicast|bytes    packets errs "
                  "drop fifo colls carrier compressed\n");
    else
        /* 输出/proc/net/dev数据部分   */
        dev_seq_printf_stats(seq, v);
    return 0;
}

static void dev_seq_printf_stats(struct seq_file *seq, struct net_device *dev)
{
    struct rtnl_link_stats64 temp;

    /* 数据源从下面的函数中取得   */
    const struct rtnl_link_stats64 *stats = dev_get_stats(dev, &temp);

    /* /proc/net/dev 各个字段的数据算法   */
    seq_printf(seq, "%6s: %7llu %7llu %4llu %4llu %4llu %5llu %10llu %9llu "
           "%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n",
           dev->name, stats->rx_bytes, stats->rx_packets,
           stats->rx_errors,
           stats->rx_dropped + stats->rx_missed_errors,
           stats->rx_fifo_errors,
           stats->rx_length_errors + stats->rx_over_errors +
            stats->rx_crc_errors + stats->rx_frame_errors,
           stats->rx_compressed, stats->multicast,
           stats->tx_bytes, stats->tx_packets,
           stats->tx_errors, stats->tx_dropped,
           stats->tx_fifo_errors, stats->collisions,
           stats->tx_carrier_errors +
            stats->tx_aborted_errors +
            stats->tx_window_errors +
            stats->tx_heartbeat_errors,
           stats->tx_compressed);
}

dev_seq_printf_stats()函数里，对应drop输出的部分，能看到由两块组成：stats->rx_dropped+stats->rx_missed_errors。

继续查找dev_get_stats函数可知，rx_dropped和rx_missed_errors 都是从设备获取的，并且需要设备驱动实现。

  /**
 *  dev_get_stats   - get network device statistics
 *  @dev: device to get statistics from
 *  @storage: place to store stats
 *
 *  Get network statistics from device. Return @storage.
 *  The device driver may provide its own method by setting
 *  dev->netdev_ops->get_stats64 or dev->netdev_ops->get_stats;
 *  otherwise the internal statistics structure is used.
 */
struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
                    struct rtnl_link_stats64 *storage)
{
    const struct net_device_ops *ops = dev->netdev_ops;
    if (ops->ndo_get_stats64) {
        memset(storage, 0, sizeof(*storage));
        ops->ndo_get_stats64(dev, storage);
    } else if (ops->ndo_get_stats) {
        netdev_stats_to_stats64(storage, ops->ndo_get_stats(dev));
    } else {
        netdev_stats_to_stats64(storage, &dev->stats);
    }   
    storage->rx_dropped += (unsigned long)atomic_long_read(&dev->rx_dropped);
    storage->tx_dropped += (unsigned long)atomic_long_read(&dev->tx_dropped);
    storage->rx_nohandler += (unsigned long)atomic_long_read(&dev->rx_nohandler);
    return storage;
}

结构体 rtnl_link_stats64 的定义在 /usr/include/linux/if_link.h 中：

  /* The main device statistics structure */
struct rtnl_link_stats64 {
    __u64   rx_packets;     /* total packets received   */
    __u64   tx_packets;     /* total packets transmitted    */
    __u64   rx_bytes;       /* total bytes received     */
    __u64   tx_bytes;       /* total bytes transmitted  */
    __u64   rx_errors;      /* bad packets received     */
    __u64   tx_errors;      /* packet transmit problems */
    __u64   rx_dropped;     /* no space in linux buffers    */
    __u64   tx_dropped;     /* no space available in linux  */
    __u64   multicast;      /* multicast packets received   */
    __u64   collisions;

    /* detailed rx_errors: */
    __u64   rx_length_errors;
    __u64   rx_over_errors;     /* receiver ring buff overflow  */
    __u64   rx_crc_errors;      /* recved pkt with crc error    */
    __u64   rx_frame_errors;    /* recv'd frame alignment error */
    __u64   rx_fifo_errors;     /* recv'r fifo overrun      */
    __u64   rx_missed_errors;   /* receiver missed packet   */

    /* detailed tx_errors */
    __u64   tx_aborted_errors;
    __u64   tx_carrier_errors;
    __u64   tx_fifo_errors;
    __u64   tx_heartbeat_errors;
    __u64   tx_window_errors;

    /* for cslip etc */
    __u64   rx_compressed;
    __u64   tx_compressed;
};

至此，我们知道rx_dropped是Linux中的缓冲区空间不足导致的丢包，而rx_missed_errors则在注释中写的比较笼统。有资料指出，rx_missed_errors是fifo队列（即rx ring buffer）满而丢弃的数量，但这样的话也就和rx_fifo_errors等同了。后来公司内网络内核研发大牛王伟给了我们点拨：不同网卡自己实现不一样，比如Intel的igb网卡rx_fifo_errors在missed的基础上，还加上了RQDPC计数，而ixgbe就没这个统计。RQDPC计数是描述符不够的计数，missed是fifo满的计数。所以对于ixgbe来说，rx_fifo_errors和rx_missed_errors确实是等同的。

通过命令ethtool -S eth0可以查看网卡一些统计信息，其中就包含了上文提到的几个重要指标rx_dropped、rx_missed_errors、rx_fifo_errors等。但实际测试后，我发现不同网卡型号给出的指标略有不同，比如Intel ixgbe就能取到，而Broadcom bnx2/tg3则只能取到rx_discards（对应rx_fifo_errors）、rx_fw_discards（对应rx_dropped）。这表明，各家网卡厂商设备内部对这些丢包的计数器、指标的定义略有不同，但通过驱动向内核提供的统计数据都封装成了struct rtnl_link_stats64定义的格式。

在对丢包服务器进行检查后，发现rx_missed_errors为0，丢包全部来自rx_dropped。说明丢包发生在Linux内核的缓冲区中。接下来，我们要继续探索到底是什么缓冲区引起了丢包问题，这就需要完整地了解服务器接收数据包的过程。

了解接收数据包的流程

接收数据包是一个复杂的过程，涉及很多底层的技术细节，但大致需要以下几个步骤：

网卡收到数据包。
将数据包从网卡硬件缓存转移到服务器内存中。
通知内核处理。
经过TCP/IP协议逐层处理。
应用程序通过read()从socket buffer读取数据。

将网卡收到的数据包转移到主机内存（NIC与驱动交互）

NIC在接收到数据包之后，首先需要将数据同步到内核中，这中间的桥梁是rx ring buffer。它是由NIC和驱动程序共享的一片区域，事实上，rx ring buffer存储的并不是实际的packet数据，而是一个描述符，这个描述符指向了它真正的存储地址，具体流程如下：

驱动在内存中分配一片缓冲区用来接收数据包，叫做sk_buffer;
将上述缓冲区的地址和大小（即接收描述符），加入到rx ring buffer。描述符中的缓冲区地址是DMA使用的物理地址;
驱动通知网卡有一个新的描述符;
网卡从rx ring buffer中取出描述符，从而获知缓冲区的地址和大小;
网卡收到新的数据包;
网卡将新数据包通过DMA直接写到sk_buffer中。

当驱动处理速度跟不上网卡收包速度时，驱动来不及分配缓冲区，NIC接收到的数据包无法及时写到sk_buffer，就会产生堆积，当NIC内部缓冲区写满后，就会丢弃部分数据，引起丢包。这部分丢包为rx_fifo_errors，在 /proc/net/dev中体现为fifo字段增长，在ifconfig中体现为overruns指标增长。

通知系统内核处理（驱动与Linux内核交互）

这个时候，数据包已经被转移到了sk_buffer中。前文提到，这是驱动程序在内存中分配的一片缓冲区，并且是通过DMA写入的，这种方式不依赖CPU直接将数据写到了内存中，意味着对内核来说，其实并不知道已经有新数据到了内存中。那么如何让内核知道有新数据进来了呢？答案就是中断，通过中断告诉内核有新数据进来了，并需要进行后续处理。

提到中断，就涉及到硬中断和软中断，首先需要简单了解一下它们的区别：

硬中断：由硬件自己生成，具有随机性，硬中断被CPU接收后，触发执行中断处理程序。中断处理程序只会处理关键性的、短时间内可以处理完的工作，剩余耗时较长工作，会放到中断之后，由软中断来完成。硬中断也被称为上半部分。
软中断：由硬中断对应的中断处理程序生成，往往是预先在代码里实现好的，不具有随机性。（除此之外，也有应用程序触发的软中断，与本文讨论的网卡收包无关。）也被称为下半部分。

当NIC把数据包通过DMA复制到内核缓冲区sk_buffer后，NIC立即发起一个硬件中断。CPU接收后，首先进入上半部分，网卡中断对应的中断处理程序是网卡驱动程序的一部分，之后由它发起软中断，进入下半部分，开始消费sk_buffer中的数据，交给内核协议栈处理。

通过中断，能够快速及时地响应网卡数据请求，但如果数据量大，那么会产生大量中断请求，CPU大部分时间都忙于处理中断，效率很低。为了解决这个问题，现在的内核及驱动都采用一种叫NAPI（new API）的方式进行数据处理，其原理可以简单理解为中断+轮询，在数据量大时，一次中断后通过轮询接收一定数量包再返回，避免产生多次中断。

整个中断过程的源码部分比较复杂，并且不同驱动的厂商及版本也会存在一定的区别。以下调用关系基于Linux-3.10.108及内核自带驱动drivers/net/ethernet/intel/ixgbe：

注意到，enqueue_to_backlog函数中，会对CPU的softnet_data 实例中的接收队列（input_pkt_queue）进行判断，如果队列中的数据长度超过netdev_max_backlog ，那么数据包将直接丢弃，这就产生了丢包。netdev_max_backlog是由系统参数net.core.netdev_max_backlog指定的，默认大小是 1000。

   /*
 * enqueue_to_backlog is called to queue an skb to a per CPU backlog
 * queue (may be a remote CPU queue).
 */
static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
                  unsigned int *qtail)
{
    struct softnet_data *sd;
    unsigned long flags;

    sd = &per_cpu(softnet_data, cpu);

    local_irq_save(flags);

    rps_lock(sd);

    /* 判断接收队列是否满，队列长度为 netdev_max_backlog  */ 
    if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) {


        if (skb_queue_len(&sd->input_pkt_queue)) {
enqueue:
            /*  队列如果不会空，将数据包添加到队列尾  */
            __skb_queue_tail(&sd->input_pkt_queue, skb);
            input_queue_tail_incr_save(sd, qtail);
            rps_unlock(sd);
            local_irq_restore(flags);
            return NET_RX_SUCCESS;
        }   

        /* Schedule NAPI for backlog device
         * We can use non atomic operation since we own the queue lock
         */
        /*  队列如果为空，回到 ____napi_schedule加入poll_list轮询部分，并重新发起软中断  */ 
        if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
            if (!rps_ipi_queued(sd))
                ____napi_schedule(sd, &sd->backlog);
        }   
        goto enqueue;
    }

    /* 队列满则直接丢弃，对应计数器 +1 */ 
    sd->dropped++;
    rps_unlock(sd);

    local_irq_restore(flags);

    atomic_long_inc(&skb->dev->rx_dropped);
    kfree_skb(skb);
    return NET_RX_DROP;
}

内核会为每个CPU Core都实例化一个softnet_data对象，这个对象中的input_pkt_queue用于管理接收的数据包。假如所有的中断都由一个CPU Core来处理的话，那么所有数据包只能经由这个CPU的input_pkt_queue，如果接收的数据包数量非常大，超过中断处理速度，那么input_pkt_queue中的数据包就会堆积，直至超过netdev_max_backlog，引起丢包。这部分丢包可以在cat /proc/net/softnet_stat的输出结果中进行确认：

其中每行代表一个CPU，第一列是中断处理程序接收的帧数，第二列是由于超过 netdev_max_backlog 而丢弃的帧数。第三列则是在 net_rx_action 函数中处理数据包超过 netdev_budget 指定数量或运行时间超过2个时间片的次数。在检查线上服务器之后，发现第一行CPU。硬中断的中断号及统计数据可以在/proc/interrupts中看到，对于多队列网卡，当系统启动并加载NIC设备驱动程序模块时，每个RXTX队列会被初始化分配一个唯一的中断向量号，它通知中断处理程序该中断来自哪个NIC队列。在默认情况下，所有队列的硬中断都由CPU 0处理，因此对应的软中断逻辑也会在CPU 0上处理，在服务器 TOP 的输出中，也可以观察到 %si 软中断部分，CPU 0的占比比其他core高出一截。

到这里其实有存在一个疑惑，我们线上服务器的内核版本及网卡都支持NAPI，而NAPI的处理逻辑是不会走到enqueue_to_backlog 中的，enqueue_to_backlog主要是非NAPI的处理流程中使用的。对此，我们觉得可能和当前使用的Docker架构有关，事实上，我们通过net.if.dropped 指标获取到的丢包，都发生在Docker虚拟网卡上，而非宿主机物理网卡上，因此很可能是Docker虚拟网桥转发数据包之后，虚拟网卡层面产生的丢包，这里由于涉及虚拟化部分，就不进一步分析了。

驱动及内核处理过程中的几个重要函数：
(1)注册中断号及中断处理程序，根据网卡是否支持MSI/MSIX，结果为：MSIX → ixgbe_msix_clean_rings，MSI → ixgbe_intr，都不支持 → ixgbe_intr。

  /**
 * 文件：ixgbe_main.c
 * ixgbe_request_irq - initialize interrupts
 * @adapter: board private structure
 *
 * Attempts to configure interrupts using the best available
 * capabilities of the hardware and kernel.
 **/
static int ixgbe_request_irq(struct ixgbe_adapter *adapter)
{
    struct net_device *netdev = adapter->netdev;
    int err;

    /* 支持MSIX，调用 ixgbe_request_msix_irqs 设置中断处理程序*/
    if (adapter->flags & IXGBE_FLAG_MSIX_ENABLED)
        err = ixgbe_request_msix_irqs(adapter);
    /* 支持MSI，直接设置 ixgbe_intr 为中断处理程序 */
    else if (adapter->flags & IXGBE_FLAG_MSI_ENABLED)
        err = request_irq(adapter->pdev->irq, &ixgbe_intr, 0,
                  netdev->name, adapter);
    /* 都不支持的情况，直接设置 ixgbe_intr 为中断处理程序 */
    else 
        err = request_irq(adapter->pdev->irq, &ixgbe_intr, IRQF_SHARED,
                  netdev->name, adapter);

    if (err)
        e_err(probe, "request_irq failed, Error %d\n", err);

    return err;
}

/**
 * 文件：ixgbe_main.c
 * ixgbe_request_msix_irqs - Initialize MSI-X interrupts
 * @adapter: board private structure
 *
 * ixgbe_request_msix_irqs allocates MSI-X vectors and requests
 * interrupts from the kernel.
 **/
static int (struct ixgbe_adapter *adapter)
{
    …
    for (vector = 0; vector < adapter->num_q_vectors; vector++) {
        struct ixgbe_q_vector *q_vector = adapter->q_vector[vector];
        struct msix_entry *entry = &adapter->msix_entries[vector];

        /* 设置中断处理入口函数为 ixgbe_msix_clean_rings */
        err = request_irq(entry->vector, &ixgbe_msix_clean_rings, 0,
                  q_vector->name, q_vector);
        if (err) {
            e_err(probe, "request_irq failed for MSIX interrupt '%s' "
                  "Error: %d\n", q_vector->name, err);
            goto free_queue_irqs;
        }
    …
    }
}

(2)线上的多队列网卡均支持MSIX，中断处理程序入口为ixgbe_msix_clean_rings，里面调用了函数napi_schedule(&q_vector->napi)。

  /**
 * 文件：ixgbe_main.c
 **/
static irqreturn_t ixgbe_msix_clean_rings(int irq, void *data)
{
    struct ixgbe_q_vector *q_vector = data;

    /* EIAM disabled interrupts (on this vector) for us */

    if (q_vector->rx.ring || q_vector->tx.ring)
        napi_schedule(&q_vector->napi);

    return IRQ_HANDLED;
}

(3)之后经过一些列调用，直到发起名为NET_RX_SOFTIRQ的软中断。到这里完成了硬中断部分，进入软中断部分，同时也上升到了内核层面。

  /**
 * 文件：include/linux/netdevice.h
 *  napi_schedule - schedule NAPI poll
 *  @n: NAPI context
 *
 * Schedule NAPI poll routine to be called if it is not already
 * running.
 */
static inline void napi_schedule(struct napi_struct *n)
{
    if (napi_schedule_prep(n))
    /*  注意下面调用的这个函数名字前是两个下划线 */
        __napi_schedule(n);
}


/**
 * 文件：net/core/dev.c
 * __napi_schedule - schedule for receive
 * @n: entry to schedule
 *
 * The entry's receive function will be scheduled to run.
 * Consider using __napi_schedule_irqoff() if hard irqs are masked.
 */
void __napi_schedule(struct napi_struct *n)
{
    unsigned long flags;

    /*  local_irq_save用来保存中断状态，并禁止中断 */
    local_irq_save(flags);
    /*  注意下面调用的这个函数名字前是四个下划线，传入的 softnet_data 是当前CPU */
    ____napi_schedule(this_cpu_ptr(&softnet_data), n);
    local_irq_restore(flags);
}


/* Called with irq disabled */
static inline void ____napi_schedule(struct softnet_data *sd,
                     struct napi_struct *napi)
{
    /* 将 napi_struct 加入 softnet_data 的 poll_list */
    list_add_tail(&napi->poll_list, &sd->poll_list);

    /* 发起软中断 NET_RX_SOFTIRQ */
    __raise_softirq_irqoff(NET_RX_SOFTIRQ);
}

(4)NET_RX_SOFTIRQ对应的软中断处理程序接口是net_rx_action()。

  /*
 *  文件：net/core/dev.c
 *  Initialize the DEV module. At boot time this walks the device list and
 *  unhooks any devices that fail to initialise (normally hardware not
 *  present) and leaves us with a valid list of present and active devices.
 *
 */

/*
 *       This is called single threaded during boot, so no need
 *       to take the rtnl semaphore.
 */
static int __init net_dev_init(void)
{
    …
    /*  分别注册TX和RX软中断的处理程序 */
    open_softirq(NET_TX_SOFTIRQ, net_tx_action);
    open_softirq(NET_RX_SOFTIRQ, net_rx_action);
    …
}

(5)net_rx_action功能就是轮询调用poll方法，这里就是ixgbe_poll。一次轮询的数据包数量不能超过内核参数net.core.netdev_budget指定的数量（默认值300），并且轮询时间不能超过2个时间片。这个机制保证了单次软中断处理不会耗时太久影响被中断的程序。

  /* 文件：net/core/dev.c  */
static void net_rx_action(struct softirq_action *h)
{
    struct softnet_data *sd = &__get_cpu_var(softnet_data);
    unsigned long time_limit = jiffies + 2;
    int budget = netdev_budget;
    void *have;

    local_irq_disable();

    while (!list_empty(&sd->poll_list)) {
        struct napi_struct *n;
        int work, weight;

        /* If softirq window is exhuasted then punt.
         * Allow this to run for 2 jiffies since which will allow
         * an average latency of 1.5/HZ.
         */

        /* 判断处理包数是否超过 netdev_budget 及时间是否超过2个时间片 */
        if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))
            goto softnet_break;

        local_irq_enable();

        /* Even though interrupts have been re-enabled, this
         * access is safe because interrupts can only add new
         * entries to the tail of this list, and only ->poll()
         * calls can remove this head entry from the list.
         */
        n = list_first_entry(&sd->poll_list, struct napi_struct, poll_list);

        have = netpoll_poll_lock(n);

        weight = n->weight;

        /* This NAPI_STATE_SCHED test is for avoiding a race
         * with netpoll's poll_napi().  Only the entity which
         * obtains the lock and sees NAPI_STATE_SCHED set will
         * actually make the ->poll() call.  Therefore we avoid
         * accidentally calling ->poll() when NAPI is not scheduled.
         */
        work = 0;
        if (test_bit(NAPI_STATE_SCHED, &n->state)) {
            work = n->poll(n, weight);
            trace_napi_poll(n);
        }

        ……
    } 

}

(6)ixgbe_poll之后的一系列调用就不一一详述了，有兴趣的同学可以自行研究，软中断部分有几个地方会有类似if (static_key_false(&rps_needed))这样的判断，会进入前文所述有丢包风险的enqueue_to_backlog函数。这里的逻辑为判断是否启用了RPS机制，RPS是早期单队列网卡上将软中断负载均衡到多个CPU Core的技术，它对数据流进行hash并分配到对应的CPU Core上，发挥多核的性能。不过现在基本都是多队列网卡，不会开启这个机制，因此走不到这里，static_key_false是针对默认为false的static key 的优化判断方式。这段调用的最后，deliver_skb会将接收的数据传入一个IP层的数据结构中，至此完成二层的全部处理。

  /**
 *  netif_receive_skb - process receive buffer from network
 *  @skb: buffer to process
 *
 *  netif_receive_skb() is the main receive data processing function.
 *  It always succeeds. The buffer may be dropped during processing
 *  for congestion control or by the protocol layers.
 *
 *  This function may only be called from softirq context and interrupts
 *  should be enabled.
 *
 *  Return values (usually ignored):
 *  NET_RX_SUCCESS: no congestion
 *  NET_RX_DROP: packet was dropped
 */
int netif_receive_skb(struct sk_buff *skb)
{
    int ret;

    net_timestamp_check(netdev_tstamp_prequeue, skb);

    if (skb_defer_rx_timestamp(skb))
        return NET_RX_SUCCESS;

    rcu_read_lock();

#ifdef CONFIG_RPS
    /* 判断是否启用RPS机制 */
    if (static_key_false(&rps_needed)) {
        struct rps_dev_flow voidflow, *rflow = &voidflow;
        /* 获取对应的CPU Core */
        int cpu = get_rps_cpu(skb->dev, skb, &rflow);

        if (cpu >= 0) {
            ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
            rcu_read_unlock();
            return ret;
        }
    }
#endif
    ret = __netif_receive_skb(skb);
    rcu_read_unlock();
    return ret;
}

TCP/IP协议栈逐层处理，最终交给用户空间读取

数据包进到IP层之后，经过IP层、TCP层处理（校验、解析上层协议，发送给上层协议），放入socket buffer，在应用程序执行read() 系统调用时，就能从socket buffer中将新数据从内核区拷贝到用户区，完成读取。

这里的socket buffer大小即TCP接收窗口，TCP由于具备流量控制功能，能动态调整接收窗口大小，因此数据传输阶段不会出现由于socket buffer接收队列空间不足而丢包的情况（但UDP及TCP握手阶段仍会有）。涉及TCP/IP协议的部分不是此次丢包问题的研究重点，因此这里不再赘述。

网卡队列

查看网卡型号

    # lspci -vvv | grep Eth
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 03)
        Subsystem: Dell Ethernet 10G 4P X540/I350 rNDC
01:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 03)
        Subsystem: Dell Ethernet 10G 4P X540/I350 rNDC


# lspci -vvv
07:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
        Subsystem: Dell Gigabit 4P X540/I350 rNDC
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 128 bytes
        Interrupt: pin D routed to IRQ 19
        Region 0: Memory at 92380000 (32-bit, non-prefetchable) [size=512K]
        Region 3: Memory at 92404000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 92a00000 [disabled] [size=512K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
                Address: 0000000000000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [70] MSI-X: Enable+ Count=10 Masked-
                Vector table: BAR=3 offset=00000000
                PBA: BAR=3 offset=00002000

可以看出，网卡的中断机制是MSI-X，即网卡的每个队列都可以分配中断（MSI-X支持2048个中断）。

网卡队列

   ...
 #define IXGBE_MAX_MSIX_VECTORS_82599    0x40
...




  u16 ixgbe_get_pcie_msix_count_generic(struct ixgbe_hw *hw)
 {
     u16 msix_count;
     u16 max_msix_count;
     u16 pcie_offset;

     switch (hw->mac.type) {
     case ixgbe_mac_82598EB:
         pcie_offset = IXGBE_PCIE_MSIX_82598_CAPS;
         max_msix_count = IXGBE_MAX_MSIX_VECTORS_82598;
         break;
     case ixgbe_mac_82599EB:
     case ixgbe_mac_X540:
     case ixgbe_mac_X550:
     case ixgbe_mac_X550EM_x:
     case ixgbe_mac_x550em_a:
         pcie_offset = IXGBE_PCIE_MSIX_82599_CAPS;
         max_msix_count = IXGBE_MAX_MSIX_VECTORS_82599;
         break;
     default:
         return 1;
     }
 ...

根据网卡型号确定驱动中定义的网卡队列，可以看到X540网卡驱动中定义最大支持的IRQ Vector为0x40(数值:64)。

   static int ixgbe_acquire_msix_vectors(struct ixgbe_adapter *adapter)
 {
     struct ixgbe_hw *hw = &adapter->hw;
     int i, vectors, vector_threshold;

     /* We start by asking for one vector per queue pair with XDP queues
      * being stacked with TX queues.
      */
     vectors = max(adapter->num_rx_queues, adapter->num_tx_queues);
     vectors = max(vectors, adapter->num_xdp_queues);

     /* It is easy to be greedy for MSI-X vectors. However, it really
      * doesn't do much good if we have a lot more vectors than CPUs. We'll
      * be somewhat conservative and only ask for (roughly) the same number
      * of vectors as there are CPUs.
      */
     vectors = min_t(int, vectors, num_online_cpus());

通过加载网卡驱动，获取网卡型号和网卡硬件的队列数；但是在初始化misx vector的时候，还会结合系统在线CPU的数量，通过Sum = Min(网卡队列，CPU Core) 来激活相应的网卡队列数量，并申请Sum个中断号。

如果CPU数量小于64，会生成CPU数量的队列，也就是每个CPU会产生一个external IRQ。

我们线上的CPU一般是48个逻辑core，就会生成48个中断号，由于我们是两块网卡做了bond，也就会生成96个中断号。

验证与复现网络丢包

通过霸爷的一篇文章，我们在测试环境做了测试，发现测试环境的中断确实有集中在CPU 0的情况，下面使用systemtap诊断测试环境软中断分布的方法:

  global hard, soft, wq

probe irq_handler.entry {
hard[irq, dev_name]++;
}

probe timer.s(1) {
println("==irq number:dev_name")
foreach( [irq, dev_name] in hard- limit 5) {
printf("%d,%s->%d\n", irq, kernel_string(dev_name), hard[irq, dev_name]);      
}

println("==softirq cpu:h:vec:action")
foreach( [c,h,vec,action] in soft- limit 5) {
printf("%d:%x:%x:%s->%d\n", c, h, vec, symdata(action), soft[c,h,vec,action]);      
}


println("==workqueue wq_thread:work_func")
foreach( [wq_thread,work_func] in wq- limit 5) {
printf("%x:%x->%d\n", wq_thread, work_func, wq[wq_thread, work_func]); 
}

println("\n")
delete hard
delete soft
delete wq
}

probe softirq.entry {
soft[cpu(), h,vec,action]++;
}

probe workqueue.execute {
wq[wq_thread, work_func]++
}


probe begin {
println("~")
}

下面执行i.stap 的结果:

  ==irq number:dev_name
87,eth0-0->1693
90,eth0-3->1263
95,eth1-3->746
92,eth1-0->703
89,eth0-2->654
==softirq cpu:h:vec:action
0:ffffffff81a83098:ffffffff81a83080:0xffffffff81461a00->8928
0:ffffffff81a83088:ffffffff81a83080:0xffffffff81084940->626
0:ffffffff81a830c8:ffffffff81a83080:0xffffffff810ecd70->614
16:ffffffff81a83088:ffffffff81a83080:0xffffffff81084940->225
16:ffffffff81a830c8:ffffffff81a83080:0xffffffff810ecd70->224
==workqueue wq_thread:work_func
ffff88083062aae0:ffffffffa01c53d0->10
ffff88083062aae0:ffffffffa01ca8f0->10
ffff88083420a080:ffffffff81142160->2
ffff8808343fe040:ffffffff8127c9d0->2
ffff880834282ae0:ffffffff8133bd20->1

下面是action对应的符号信息：

  addr2line -e /usr/lib/debug/lib/modules/2.6.32-431.20.3.el6.mt20161028.x86_64/vmlinux ffffffff81461a00
/usr/src/debug/kernel-2.6.32-431.20.3.el6/linux-2.6.32-431.20.3.el6.mt20161028.x86_64/net/core/dev.c:4013

打开这个文件，我们发现它是在执行 static void net_rx_action(struct softirq_action *h)这个函数，而这个函数正是前文提到的，NET_RX_SOFTIRQ 对应的软中断处理程序。因此可以确认网卡的软中断在机器上分布非常不均，而且主要集中在CPU 0上。通过/proc/interrupts能确认硬中断集中在CPU 0上，因此软中断也都由CPU 0处理，如何优化网卡的中断成为了我们关注的重点。

优化策略

CPU亲缘性

前文提到，丢包是因为队列中的数据包超过了 netdev_max_backlog 造成了丢弃，因此首先想到是临时调大netdev_max_backlog能否解决燃眉之急，事实证明，对于轻微丢包调大参数可以缓解丢包，但对于大量丢包则几乎不怎么管用，内核处理速度跟不上收包速度的问题还是客观存在，本质还是因为单核处理中断有瓶颈，即使不丢包，服务响应速度也会变慢。因此如果能同时使用多个CPU Core来处理中断，就能显著提高中断处理的效率，并且每个CPU都会实例化一个softnet_data对象，队列数也增加了。

中断亲缘性设置

通过设置中断亲缘性，可以让指定的中断向量号更倾向于发送给指定的CPU Core来处理，俗称“绑核”。命令grep eth /proc/interrupts的第一列可以获取网卡的中断号，如果是多队列网卡，那么就会有多行输出：

中断的亲缘性设置可以在 cat /proc/irq/${中断号}/smp_affinity 或 cat /proc/irq/${中断号}/smp_affinity_list 中确认，前者是16进制掩码形式，后者是以CPU Core序号形式。例如下图中，将16进制的400转换成2进制后，为 10000000000，“1”在第10位上，表示亲缘性是第10个CPU Core。

那为什么中断号只设置一个CPU Core呢？而不是为每一个中断号设置多个CPU Core平行处理。我们经过测试，发现当给中断设置了多个CPU Core后，它也仅能由设置的第一个CPU Core来处理，其他的CPU Core并不会参与中断处理，原因猜想是当CPU可以平行收包时，不同的核收取了同一个queue的数据包，但处理速度不一致，导致提交到IP层后的顺序也不一致，这就会产生乱序的问题，由同一个核来处理可以避免了乱序问题。

但是，当我们配置了多个Core处理中断后，发现Redis的慢查询数量有明显上升，甚至部分业务也受到了影响，慢查询增多直接导致可用性降低，因此方案仍需进一步优化。

Redis进程亲缘性设置

如果某个CPU Core正在处理Redis的调用，执行到一半时产生了中断，那么CPU不得不停止当前的工作转而处理中断请求，中断期间Redis也无法转交给其他core继续运行，必须等处理完中断后才能继续运行。Redis本身定位就是高速缓存，线上的平均端到端响应时间小于1ms，如果频繁被中断，那么响应时间必然受到极大影响。容易想到，由最初的CPU 0单核处理中断，改进到多核处理中断，Redis进程被中断影响的几率增大了，因此我们需要对Redis进程也设置CPU亲缘性，使其与处理中断的Core互相错开，避免受到影响。

使用命令taskset可以为进程设置CPU亲缘性，操作十分简单，一句taskset -cp cpu-list pid即可完成绑定。经过一番压测，我们发现使用8个core处理中断时，流量直至打满双万兆网卡也不会出现丢包，因此决定将中断的亲缘性设置为物理机上前8个core，Redis进程的亲缘性设置为剩下的所有core。调整后，确实有明显的效果，慢查询数量大幅优化，但对比初始情况，仍然还是高了一些些，还有没有优化空间呢？

通过观察，我们发现一个有趣的现象，当只有CPU 0处理中断时，Redis进程更倾向于运行在CPU 0，以及CPU 0同一物理CPU下的其他核上。于是有了以下推测：我们设置的中断亲缘性，是直接选取了前8个核心，但这8个core却可能是来自两块物理CPU的，在/proc/cpuinfo中，通过字段processor和physical id 能确认这一点，那么响应慢是否和物理CPU有关呢？物理CPU又和NUMA架构关联，每个物理CPU对应一个NUMA node，那么接下来就要从NUMA角度进行分析。

NUMA

SMP 架构

随着单核CPU的频率在制造工艺上的瓶颈，CPU制造商的发展方向也由纵向变为横向：从CPU频率转为每瓦性能。CPU也就从单核频率时代过渡到多核性能协调。

SMP(对称多处理结构)：即CPU共享所有资源，例如总线、内存、IO等。

SMP 结构：一个物理CPU可以有多个物理Core，每个Core又可以有多个硬件线程。即：每个HT有一个独立的L1 cache，同一个Core下的HT共享L2 cache，同一个物理CPU下的多个core共享L3 cache。

下图(摘自内核月谈)中，一个x86 CPU有4个物理Core，每个Core有两个HT(Hyper Thread)。

NUMA 架构

在前面的FSB(前端系统总线)结构中，当CPU不断增长的情况下，共享的系统总线就会因为资源竞争(多核争抢总线资源以访问北桥上的内存)而出现扩展和性能问题。

在这样的背景下，基于SMP架构上的优化，设计出了NUMA(Non-Uniform Memory Access)—— 非均匀内存访问。

内存控制器芯片被集成到处理器内部，多个处理器通过QPI链路相连，DRAM也就有了远近之分。(如下图所示：摘自 CPU Cache)

CPU 多层Cache的性能差异是很巨大的，比如：L1的访问时长1ns，L2的时长3ns...跨node的访问会有几十甚至上百倍的性能损耗。

NUMA 架构下的中断优化

这时我们再回归到中断的问题上，当两个NUMA节点处理中断时，CPU实例化的softnet_data以及驱动分配的sk_buffer都可能是跨node的，数据接收后对上层应用Redis来说，跨node访问的几率也大大提高，并且无法充分利用L2、L3 cache，增加了延时。

同时，由于Linux wake affinity 特性，如果两个进程频繁互动，调度系统会觉得它们很有可能共享同样的数据，把它们放到同一CPU核心或NUMA Node有助于提高缓存和内存的访问性能，所以当一个进程唤醒另一个的时候，被唤醒的进程可能会被放到相同的CPU core或者相同的NUMA节点上。此特性对中断唤醒进程时也起作用，在上一节所述的现象中，所有的网络中断都分配给CPU 0去处理，当中断处理完成时，由于wakeup affinity特性的作用，所唤醒的用户进程也被安排给CPU 0或其所在的numa节点上其他core。而当两个NUMA node处理中断时，这种调度特性有可能导致Redis进程在CPU core之间频繁迁移，造成性能损失。

综合上述，将中断都分配在同一NUMA Node中，中断处理函数和应用程序充分利用同NUMA下的L2、L3缓存、以及同node下的内存，结合调度系统的wake affinity特性，能够更进一步降低延迟。

参考文档

作者简介

骁雄，14年加入美团点评，主要从事MySQL、Redis数据库运维，高可用和相关运维平台建设。

春林，17年加入美团点评，毕业后一直深耕在运维线，从网络工程师到Oracle DBA再到MySQL DBA 多种岗位转变，现在美大主要职责Redis运维开发和优化工作。

美团点评DBA团队招聘各类DBA人才，Base北京上海均可。我们致力于为公司提供稳定、可靠、高效的在线存储服务，打造业界领先的数据库团队。这里有基于Redis Cluster构建的大规模分布式缓存系统Squirrel，也有基于Tair进行大刀阔斧改进的分布式KV存储系统Cellar，还有数千各类架构的MySQL实例，每天提供万亿级的OLTP访问请求。真正的海量、分布式、高并发环境。欢迎各位朋友推荐或自荐至jinlong.cai#dianping.com。

如何下载网页上的视频？ - 知乎

Thu, 19 Jul 2018 11:44:37 CST

2017.1.13

pc端软件

适用场景：优酷，土豆1080p视频，腾讯视频等

1.硕鼠。我比较常用的一类软件，能够进行 清晰度解析下载，用过很长一段时间了，需要下载视频的就会找到它。今天发现硕鼠没有以前强大了...以前还能下载优酷视频专辑。

类似的有猎影，以前没用过，今天试用了一下，很好用。能够下载优酷和土豆1080p的视频。很棒的软件。

" width="547">

2.IDM下载器。平时代替浏览器下载器使用，有视频和音频嗅探功能，可以下载在线视频，一个好用的地方是：百度 贴吧的语音，能够嗅探并且下载下来，而有些扩展插件是不能嗅探到的。

扩展插件

适用场景：秒拍，微博视频等

我平时用chrome和360极速浏览器； 360极速上安装有 FVD Video downloader；这款扩展的作用也是嗅探网页上的视频，嗅探到后有图标显示，直接点击即可下载，使用很方便。

youtube视频

对于youtube视频，我的方法是一个油猴脚本：Download YouTube Videos as MP4；在视频播放页面会出现下载按钮，可选清晰度至720p。下载地址： Download YouTube Videos as MP4（在chrome上先安tampermonkey脚本管理器）；

如果需要下载youtube 1080p的视频，可以用 Gihosoft TubeGet；

" width="578"> 其他

VIP解析，支持爱奇艺，优酷，腾讯，搜狐，芒果等；地址： https://pan.baidu.com/s/1qYLbfvI密码: ikm6

审查元素，在线解析视频的网站，google。

网友推荐： You-Get——基于Python3的媒体下载工具

原文在这里： https://zhuanlan.zhihu.com/p/24861140

作为使用过N种下载网页视频的实践者，郑重推荐几乎能下载网页全部视频的浏览器插件： FVD Downloader（基本上可以下载绝大部分常规和非常规视频网站的视频）。

（PS:此插件不仅能够下载网页上的视频， 还可以支持下载音频网站的音乐哦）

只需要2步就可以轻松快速的把网页中的内容保存下来。
下面是具体的操作步骤：
第一步： 安装FVD Downloader插件（以360浏览器为例）

大家点击浏览器中的“拓展”

然后在应用市场中找到FVD Downloader，点击“安装”（这里我已经安装好了）。

安装好后，你的浏览器搜索框附近会出现FVD Downloader的图标。

第二步： 打开视频播放页面，点击插件，选择下载并保存

这里我们以“新浪视频”为例。（经测试：爱奇艺也可以，非常规视频网站也可以，具体请自行测试。）

打开新浪视频，输入你想下载的视频名称，这里我输入：PPT，得到以下结果，我们就下载：PPT场景—5公里。

从网页中看到可以，该视频是不提供下载的，因为根本就找不到下载的按钮。

点开后，可以看到FVD Downloader图标是有颜色的，代表该页面有视频可以提供下载。假如该网站没有可提供的视频下载的话，该图标将会呈现灰色并且有一个×。

点击图标，可以看到以下界面

最后一步点击下载。

下载下来后用视频播放器播放，就可以离线观看该视频。

如果你使用该插件后，可以看到有很多可以下载的视频内容，而且视频的格式为：ts，原因是该视频被分成了很多小段，只需要用命令行拼接一些就可以了。可以在windows的命令行中输入：copy/b （文件保存地址）\*.ts （文件保存地址）\new.ts 这样就可以

注意：请勿用此方法下载收费或者有版权视频，毕竟原创者付出了大量的时间和精力制作视频，还望大家保护版权！

——————分割线————————

对于大家在评论区说的问题进行统一回答：

（1）如果在插件下，一个网页内提示有多个视频文件，如何下载高清版本

首先如果你想下载网页内高清版视频，首先你得把网页内视频的清晰度选择为高清的，因为插件是需要网页加载视频后才会识别是否有视频可以下载

接着再次点击插件，就可以发现插件视频比原来多个视频了，选择大的文件就是高清版本的了

（2）ts格式要用什么播放器看

只要用常规的播放器就可以了，ts只是整个视频一小段，需要拼接起来才是一个完整的视频，具体拼接方法看我的之前的方法。播放器我建议用QQ影音，因为它没有广告而且体积小启动速度快

——————分割线——————

如果你对于这次讲解还有什么问题的话，可以随时在公众号【 印象演示】发消息给我。

或者加我的个人微信：rsmshuzhou

http://weixin.qq.com/r/kcAsNFfE6AqXrRNX95WD (二维码自动识别)

自然语言处理最新教材开放下载，乔治亚理工大学官方推荐

Sun, 03 Jun 2018 16:06:00 CST

开放地址：https://github.com/jacobeisenstein/gt-nlp-class/tree/master/notes

Eisenstein 将这一本非常完善的教材称之为「Notes」，它是在乔治亚理工大学学习自然语言处理相关领域所需要了解的基础。例如在介绍自然语言处理理论与方法的课程 CS4650/7650 中，这本开放书籍就作为标准的课程教材。

CS4650/7650 2018 春季课程需要阅读 GitHub 目录下 eisenstein-nlp-notes-jan-10-2018.pdf 文件，而另外一个文件 eisenstein-nlp-notes.pdf 会包含一些章节上的更新，不过它会在整个学期内进行。Eisenstein 表示这本开放书籍也可以用于其它研究或课程，书籍上的任何误差或反馈都能直接发邮件给作者。

自然语言处理是令计算机能访问人类语言的一组方法。在过去的十年中，自然语言处理已经深入了我们的日常生活：自动机器翻译在网站和社交媒体中已经无处不在、文本分类确保了电子邮箱在海量垃圾邮件中屹立不倒、搜索引擎已经不再只是字符匹配与网络分析，它已经能理解高维度的复杂语言，还有近来对话系统的兴起也令信息的分享与交互更高效。

这些强大的应用其实都基于一套通用的思想，即利用算法、语言规则、逻辑和统计知识理解自然语言。这本书的目的是提供这些思想与技术的基础，并应用于各种实际的任务中。此外，这本书除了详细的概念与算法，同时还包括一些高阶主题，读者可按需求学习与阅读。

这本书的主要章节如下可分为四部分：

学习：这一章节介绍了一套机器学习工具，它也是整本教科书对不同问题建模的基础。由于重点在于介绍机器学习，因此我们使用的语言任务都非常简单，即以词袋文本分类为模型示例。第四章介绍了一些更具语言意义的文本分类应用。
序列与树：这一章节将自然语言作为结构化的数据进行处理，它描述了语言用序列和树进行表示的方法，以及这些表示所添加的限制。第 9 章介绍了有限状态自动机（finite state automata）。
语义：本章节从广泛的角度看待基于文本表达和计算语义的努力，包括形式逻辑和神经词嵌入等方面。
应用：最后一章介绍了三种自然语言处理中最重要的应用：信息抽取、机器翻译和文本生成。我们不仅将了解使用前面章节技术所构建的知名系统，同时还会理解神经网络注意力机制等前沿问题。

自然语言处理其实与很多学科都有关系，包括最直接的计算语言学、机器学习和统计学等。其实计算语言学基本上就等同于自然语言处理，它关注于设计并分析表征人类自然语言处理的算法。而我们熟知的机器学习正好为这些「表征」提供算法支持，例如在自然语言建模中，机器学习提供了 n-gram 和循环神经网络等多种方法预测最自然的语句。

在 Eisenstein 的这本书中，有非常多值得我们仔细探讨的主题，例如如何基于简单的感知机或支持向量机进行线性文本分类、如何使用循环网络实现语言建模，以及序列标注任务中的维特比算法和隐马尔科夫链等知识。但限于本文只简要介绍这本书，因此我们主要介绍 Eisenstein 所述的自然语言处理三大主题。

自然语言处理的三大主题

自然语言处理涵盖了非常多的任务、方法和语言现象。虽然很多任务之间都无法进行比较，但还是有一些公共的主题。基本上，自然语言处理包括学习与知识、搜索和学习以及 NLP 中关系式、组合式和分布式的观点。

学习与知识

近来深度模型在计算机视觉和语音识别等方面取得的成果促进了端到端学习方法的发展，传统机器学习中基于光学和音韵学等经过特征工程的特定表示方法已经不再流行。但是，很多机器学习基本只逐元素地处理自然语言，语法解析树等语言学表征仍然没有像视觉中的边缘检测器那样有高效的表示方法。语言学家也通常会讨论能编码一组专门用来促进语言理解和生成抽象概念的「语言能力」，但不管这些是不是合理，在训练数据有限的情况下语言结构尤其重要。

现在其实有很多方法将自然语言处理中的知识与学习结合在一起，很多监督式的学习系统利用工程化的特征，将数据转化为有利于学习的表征。例如在文本分类任务中，识别每一个词的词干可能会非常有用，因此这样的学习系统可以更容易概括相关术语，例如鲸鱼和捕鲸等。这在很多复杂语言中非常有用，因为复杂的词缀通常都添加在词干的后面。这些特征可以从手工处理的数据中获得，例如将每个单词映射到单一表单的字典。此外，特征也可以从一般任务的语言处理系统获得，例如从建立在有监督机器学习的语法解析或词性标注等模型获取。

学习和知识的另一项结合即体现在模型结构：我们建立的机器学习模型架构受语言理论的影响。例如在自然语言中，句子的组织通常描述为构成性的，语义较小的单位逐渐构成语义较大的单位。这个想法可以加入深度神经网络体系架构中，并使用当代技术进行训练（Dyer et al., 2016）。

目前，有关机器学习与语言知识相对重要性的争论愈演愈烈。没有机器学习研究者愿意听到他们的工程学方法是不科学的炼金术，语言学家也不希望听到他们所寻找的一般语言学结构与原理和大数据无关。然而这两种类型的研究显然都各有发展空间，我们需要知道端到端的学习还能走多远，同时还需要继续研究能泛化到各种应用、场景和语言的语言学表征。

搜索和学习

很多自然语言处理问题在数学上都可以表述为最优化问题的形式：

其中 x 是属于集合 X 的输入；y 是属于集合 Y 的输出；φ是评分函数，将集合 X*Y 映射到实数上；θ是φ的参数向量；y hat 是预测输出，其值的选择需要使评分函数最大化。这种形式化定义在通常的监督机器学习问题中是很普遍的，而在自然语言处理中，输入-输出对可能是文本-情感，或不同语言的翻译等。

在这种形式化定义下，语言处理算法有两个不同的模块，即搜索和学习：

搜索模块即找到使评分函数φ最大化的预测输出，当搜索空间足够小（即数据量较小）或评分函数能分解成几个较容易处理的部分时，这很容易。但通常情况下，评分函数的结构复杂得多，并且在语言处理算法中，输出通常是离散型的，这时搜索通常依赖于组合优化机制。

学习模块即寻找参数向量θ，一般通过处理标记数据对得到。和搜索一样，学习也是通过优化框架进行。但由于参数通常是连续的，因此学习算法依赖于数值优化。

将自然语言处理算法分成两种不同的模块可以使我们能重用多种不同任务和模型的通用算法，既聚焦于模型设计，同时又能利用过去在搜索、优化和学习问题的研究成果。

当模型能分辨细微的语言差异时，称为具有表达性（expressive）。表达性通常需要在学习和搜索的效率之间进行权衡。很多自然语言处理的重要问题都需要表达性，其计算复杂度随收入数据的增加指数式增长。在这些模型中，确定性的搜索通常是不可行的。其难解性使得明确分离搜索和学习模块变得很困难：如果搜索需要一系列启发式近似，那么学习在这些特定的启发式下工作良好的模型会更有利。这启发了一些研究者在搜索和学习中采用更加集成化的方法。

关系式、组合式和分布式的观点

任何语言元素（例如单词、句子、段落甚至发音）都可以至少用三个观点来描述。考虑单词「记者」：「记者」是「职业」的子范畴，「主持人」是「记者」的子范畴；此外，记者执行的是「新闻工作」，这又是「写作」的子范畴。这种对意义的关系式的观点是语义本体论的基础，例如 Word-Net 枚举了单词和其它基本语义单元之间的关系。关系式的观点具有强大的推理能力，但在计算上很难形式化，通常单词的含义是不独立于具体场景的。

某些单词之间的关系可以通过书写上的相似性和组合性而互相联系，例如复数形式、组合型单词等。进一步，在对句子和段落的分析中，通过单词的组合和句子的组合来得到完整含义。此即组合式的观点。组合观点的威力在于它为理解完整文本和对话提供了路线图，通过单一的解析透镜，从最小的部分开始逐步得到完整的含义。

对于某些不可分解的单词，组合观点不能提供很多帮助，但可以通过上下文来确定其含义。此即分布式的观点。它还可以帮助找到意义相似的不同单词。分布式的观点可以从未标记的数据中学习含义。和关系式以及组合式的语义不同，其并不需要手动标注或专家知识。因此，分布式语义覆盖了很大范围的语言现象，但是精确度不高。

关系式、组合式和分布式的观点对于语言含义的理解都有贡献，三者对于自然语言处理都是很重要的。目前，它们之间的协作并不容易，各自使用的表征和算法较难兼容。

最后，Eisenstein 表示阅读这本书也需要一些背景知识：

数学与机器学习：这本书需要多元微分学和线性代数的基础知识，包括函数微分、偏微分与向量和矩阵的运算等。读者也应该熟悉概率论与统计学，包括基本分布、数字特征、参数估计和假设检验等。
语言学：除了语法基本概念，如名词和动词等，这本书并不要求我们接受过语言学方面的训练。整本书会根据需要在各章节中引入语言学概念，包括形态和句法学（第 9 章）、语义学（第 12、13 章）和语篇学（第 16 章）。
计算机科学：这本书主要面向计算机科学的学生与研究者，读者应该了解一些关于算法和复杂性理论分析的入门课程。此外，读者也需要了解一些算法时间和内存成本的渐进分析，即简单的动态规划内容。

百度网盘下载限速如何破解？ - 知乎

Wed, 21 Feb 2018 21:12:18 CST

我们都知道百度云是我们经常使用的软件之一，但是现在使用它，下载速度确实很感人，就算是你买了会员，速度也并不是很快，所以今天教大家几个方法，不管你是手机还是电脑，都可以轻松下载百度云。

Android：ES 文件管理器 + ADM Pro

ADM Pro

打开ADM，【设置】-->【下载】-->【找下面的选项】

【User-Agent】 -->选择【Custom】
【Custom User-Agent】
填写：netdisk;5.2.7;PC;PC-Windows;6.2.9200;WindowsBaiduYunGuanJia

ES 文件管理器

打开ES文件浏览器，登录百度云盘，侧滑点击【网络】--> 【网盘】，点击啊【+】，登录百度云

下载

把要下载的文件选中，打开为【视频】，选择【ADM下载】，开始

PS：下载的时候，ADM和ES文件浏览器不要关闭，等下载完成就好了。

方法二：油猴脚本 + 百度网盘下载助手脚本

百度网盘直接下载助手

http://dwz.cn/dupanzhushou

" width="640">

因为这个要安装油猴脚本，所以可以参考这个来安装下载： http://mp.weixin.qq.com/s/3EkJcdhlxLLyIMw86E0ARw。

或者在百度云下载：链接: https://pan.baidu.com/s/1jIDqnT8密码: ksrb。

这个插件，你可以使用它可以直接获取文件原始链接，这样你就可以使用第三方（IDM，Folx）下载了，再也不用使用百度云客户端的龟速了。

还可以多个文件选择，批量下载。

解决百度云大文件下载限制： http://dwz.cn/3EiCAf

推荐第三方下载工具

下面推荐很多，不同平台的都有，大家对号入座啊，这样就可以轻松高速下载百度云啦。通过上面脚本获取到链接，使用下面下载工具就可以下载了。原始链接也不会限制下载。

IDM：Windows

Folx 2：Mac

Aria2：Mac / Win

ADM：Android

迅雷：全平台

Village 山寨云

" width="1920">

Village 是一款第三方百度云客户端。

尤其是现在百度云没个会员就下载不了东西的情况下，这样一个工具的出现真是太及时了。

它支持网盘搜索功能，支持查看，分享，下载功能，主要是速度还不错。

但愿能活的更久一点。

只有Android 版本。

" width="1178">

上面提到的软件和App ，关注公众号： 高效率工具搜罗（gongju006），回复： 百度云，即可打包下载。

PS：收藏都快破千了，点赞还是寥寥数几，大家还是点个赞再走。

B站下载助手 – 地铁族必备，离线缓存 B 站视频 [Chrome]

Tue, 30 Jan 2018 10:18:13 CST

B站下载助手是一款在 Chrome 上辅助下载哔哩哔哩网站视频的工具，只要能播放就能下载，格式为 flv。@Appinn

来自发现频道，作者 @ indooorsman 同样是 Anything to QRcode – 给 Chrome 内容生产二维码[Chrome]、微信备份 – 备份与删除微信、朋友圈、公众号的照片和视频[Android] 的开发者。

B站下载助手是这样描述自己的：

帮助你下载你能在 Bilibili 网站播放的视频（所以前提是你能在网站上播放），适用于某些番剧可以看却不能离线缓存的场景，比如我本人购买了 B 站大会员，能直接看大部分番剧，但还是有很多不能离线缓存，对于地铁族来说很难受。。。所以就做了这个扩展，用来在 PC 上下载这些番剧，然后传到手机上，在上下班路上看。。。希望对大家也有所帮助✧(≖ ◡ ≖✿)

嗯，使用方法如下，请根据步骤来：

0. 安装本扩展（废话。。。
1. 打开你要播放的视频页面，必须是有播放器的那个页面
2. 在页面空白处点击右键，然后点右键菜单中的“检查元素” / “检查”
3. 在弹出的开发者工具中，点击 “B站下载助手”标签，找不到的看扩展的屏幕截图去。。。
4. 然后按“B站下载助手”中的说明操作即可

正常情况下，应该能看到下面的蓝色长条按钮：

然后就可以下载了，下载后的格式为 flv。

而在手机端，能够播放 flv 的播放器，比如 VLC、 MX Player、 nPlayer 等等常见的播放器都可以播放。

Chrome 商店 | ChromeFor（可直接下载 .crx 扩展文件）

德勤咨询：人工智能与商业应用研究报告（附下载）

Thu, 03 Aug 2017 00:56:41 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【人工智能与商业应用研究报告】即可

商业机构中的领导者对人工智能的商业影响力感到既担忧又兴奋。全球各地的公司正逐渐意识到这一新技术的力量，并开始探索如何应用人工智能提升企业竞争力。

本文基于Efma和德勤联合进行的EMEA（欧洲、中东、非洲三地区） FSI（金融服务业）调查结果，并引用了业内多家公司的见解和案例研究，分析了人工智能的逻辑建模、行业现状以及理解和利用人工智能技术所需要采取的行动。

1. 人工智能应用领域

人工智能有三大主要应用领域：认知自动化，认知参与和认知洞察力。

认知自动化

在这一领域，人工智能的主要领域是机器学习，机器人流程自动化（RPA），和其他能够自动化深层领域知识开发的认知工具。我们已经看到人工智能设备自动化了那些传统上需要训练有素的工人才能完成的任务。

手写和字符识别是认知自动化应用的最佳范例，它可以支持高强度、复杂繁琐的办公业务，以帮助企业降低风险和成本。例如，可以使用自然语言处理和OCR技术从文档中提取关键信息。

认知参与

人工智能的下一阶段是认知技术“代理”：系统通过认知技术与人类建立密切关系。

认知系统开启了文本/图像/视频等“非结构化”数据的力量，为银行和客户提供定制化的产品和服务并创造新的收益流。

最常见的例子是语音识别接口，它可以执行语音指令，降低温控器或打开电视频道。同时，也出现了一些使用认知参与的新型应用领域，这些领域需要人工智能接触到更复杂的信息并执行数字化任务。比如接收病人入院，或者推荐产品和服务。

认知洞察力

认知洞察力是指从各种数据流中提取概念和关系，用来生成隐藏在大量“结构化”和“非结构化”数据中的相关答案。

总的来说，认知洞察力可以检测来自多个数据源数据的关键内容和相关联系，从而获得更深入和可操作的洞见。

随着处理数据量的增加，观察和预测的准确性得到了提高。人工智能不仅可以深入了解已经发生的事情，而且还能分析正在发生的事情，以及预测接下来可能发生的事情。这可以帮助商业领袖制定计划，帮助员工提高他们的业绩。例如，在全球呼叫中心，客服人员使用多功能客户支持程序来回答产品提问，接受订单，调查账单问题，并解决客户的其他困扰。

根据斯坦福大学主题为“2030年的人工智能与生活”的调查研究，专家预测人工智能将在以下八大领域发挥重要作用：交通，服务型机器人，医疗，教育，低资源社区，公众安全，就业与工作以及娱乐产业。另一方面，美国劳动部在2016年发布的报告中提到“65%的在校学生未来将被雇佣于现在尚未存在的工作岗位”。这些预测告诉我们，在不久的将来，人工智能技术将与我们的生活产生紧密联系，对工作和生活等多方面造成深远影响。

2. 人工智能中的监管问题

接下来的问题是:经济发展和社会各界需要做出哪些准备来迎接人工智能光明的未来？

在2017年初，欧洲议会提出一系列管理人工智能的法规，用来规定相关道德准则，以及人工智能犯错的责任归属问题。

议会调查员Mady Delvax强调了建立一个欧洲机器人监管机构的重要性，该机构将通过提供技术支持来协助政府部门。他还建议起草一份道德行为准则，用以指导机器人工程项目并确定他们的行为责任。

事实上，问责权或法律责任是人工智能争议中的关键问题。自动驾驶汽车的兴起就是最明显的例子，相关各方有必要去定义具体的保险计划，并确定损害赔偿的责任。在未来，智能自动化机器人将被赋予某种“法律人格”。最后 Delvaux的报告强调，机器人可能会对社会产生长期影响，政府部门需要密切关注这些趋势，创造新的就业岗位和税收模式。

3. 人工智能发展现状

为了了解金融服务行业在人工智能应用方面的现状和前景，Efma和德勤联合进行了一项大型调查, 调查范围涉及超过3000人, 受访者主要为金融服务公司技术和业务方面的高管，大多受访者表示，新认知技术的应用将增强工作的可控性，并减轻员工的工作负担，而不是将人们的劳动力完全替代。

对于“贵公司在人工智能应用领域处于什么阶段”这一问题，约90%的公司表示已经开始在他们的工作中使用人工智能技术，或正处于对这一新技术的学习中。

从下面的调查结果可以看出，数据安全(网络犯罪)、组织影响(人才需求和人员分配)、技术实施、控制权丢失和可持续性等问题是企业考虑人工智技术时可能产生的困扰。

调查数据显示，一个公司越处在认知技术实现的前沿阶段，就越难找到合适的人才。这可能是因为在技术越成熟的阶段，就越需要受过高级培训并有特定技能的专家。而在初始阶段，通用的知识就足够了。另一个重要事实是，在初始阶段，企业应用认知技术的主要障碍是缺乏组织。

有很多人担心人工智能技术可能会抢走人类的工作。然而，调查中91%的受访者认为新型认知技术可以协助或支持员工工作，而不是替代他们。

同时，调查显示大多数组织需要通过外聘来弥补人工智能技术的人才空缺，但是在聘请合适的专业人才时他们大多会遇到困难，所以未来在员工培训领域也将会产生大量投资机会。

至于人工智能的应用价值，不同的行业似乎都在寻找不同的技术解决方案。因此，有必要进行多元化的技术供应来扩大市场份额，满足更多的消费者需求。

4. 德勤观点

“一些认知技术供应商和客户正在越过“科学研究项目”的阶段，使用人工智能技术来优化业务流程。现在是时候帮助企业寻找适合使用人工智能技术的业务领域，并且思考如何使用这一新技术来优化核心流程。”

这是德勤美国高级顾问，Tom Davenport教授在2015年底对认知技术发展的看法。德勤调查显示， 86%的受访企业高管从2014年开始对认知技术有所获悉。从那时起，认知创新浪潮就已从美国向海外发展。这一事实表明，人工智能正在从一个初步构建的理念发展为可以实际操作的商业应用。

尽管人工智能技术的发展十分迅速，但是在技术应用落地时仍然会面临企业文化和组织架构带来的阻碍和挑战。一些管理层人员青睐于存在巨大机遇的发展机会，而另一些管理者更希望采取渐进的方式进行发展。企业中推动人工智能技术实施的领导者需要意识到，目前并不存在一个万能的解决方案。从德勤的调查中可以看出人工智能领域存在着多样化的应用案例，企业可以选择构建一个具有突破创新意义的人工智能客户服务体系，于此同时也可以选择一个低风险的解决方案，如后台流程自动化。

报告下载：添加199IT官方微信【i199it】，回复关键词【人工智能与商业应用研究报告】即可

您可能也喜欢的文章：
以改革为动力砥砺前行：汽车行业国企改革研究（附报告下载）	揭秘人工智能：商业领袖需要了解的认知技术	德勤咨询：2017年度足球财务报告（附下载）	德勤咨询：开展商业地产创新准备迎接未来城市（附下载）	德勤咨询：2017年欧洲、中东和非洲(EMEA)地区保险数据分析研究（附下载）
无觅

2017雷达报告：影响未来旅游业发展的九大科技趋势（附下载）

Thu, 03 Aug 2017 00:59:43 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【2017雷达报告】即可

Sabre研究报告评估了九大新兴科技对旅游行业的影响。

人工智能（AI）

在2011年，Gartner的研究曾经预测，到2020年，客户无需与人交流就可以完成与企业85％的交互过程。最近，Servion consulting也发布了一项预测：到2025年，AI将支持95％的客户交互。

最高效的服务和支持团队通常有一个能够理解和回应大多数基本问题的AI层，只有当AI对答案不太确定时，人工服务才会介入。对于旅游行业来说，AI可以提醒客人酒店退房时间或推荐当地餐厅，而当客人需要特殊要求或想要分享个人体验则可以提供人工服务。

AI可以大大减少重复性任务的负担，无论是体力还是数字方面的，使人类可以完成更有价值、更有创意的工作。例如，AI在翻译领域的应用正在迅速提升，这有助于简化旅行、改善人与人之间的交流。

增强现实(AR)

去年，AR技术领域发布了三项应用：微软HoloLens，Google Tango和Pokemon Go，这是三个完全不同的项目，分别展示了AR的不同潜力。另外，AR技术还增加了在Snapchat和Facebook上实时视频过滤和互动自拍动画的功能。今年，苹果公司发布了ARKit，这是一个可以供开发人员创建AR App的工具，这是为了今年秋天即将推出的iOS 11系统专门设计的。

AR技术已经在翻译等领域投入了使用，能够实时读取并翻译一些标志或文档。另外，还可以作为现实世界的视觉维基百科使用，即可以把每个建筑、街道和地标都映射出丰富的内容。而在日常生活中，AR技术可以记住所有的名字及交流内容，航空公司或酒店可以直呼其名来问候每位乘客或客人，并且在看到客户的第一眼就知道客户的旅行信息。

自主配送

今年早些时候，Starship Technologies和美国同城快递公司Postmates在华盛顿特区启动了机器人送货服务。这些机器人看起来像是放在六个轮子上的冰箱，并且获准在华盛顿特区和邻近的弗吉尼亚州的人行道上行动。它们使用GPS和九台相机的组合进行导航。这些机器人虽然不能帮你购买所有的日用品，但它们可以从当地便利店取快餐或送行李。

当自主配送技术与其他技术（如生物识别）结合使用时，旅行几乎就成为了一种全程自助的体验。一款自助手提箱和自助搬运工具目前已经投入生产，很快就可以在机场、火车站和城市街道看到小型机器人跟在主人身后服务。未来，行李甚至可以自助检查，并在下飞机后主动找到主人。甚至，到达目的地之后，你还有可能使唤行李帮你跑腿，比如去拿干洗衣服或者买点小吃。如果你出城时把手机或太阳镜落在了酒店，不用担心，这些东西都可以被自主配送。

区块链

目前，旅游业中的区块链原型：

1. Webjet正在利用区块链试验酒店库存管理，通过每一次预订记录收集大量的数据，并确保及时向各方全额付款。

2. 很多创业公司正在密切关注利用区块链进行数字化身份管理。结合生物识别技术与区块链可以提供比传统方法（例如护照）更安全的数字身份证明。

3. 酒店和航空公司的忠诚度计划可能会过渡到区块链，以简化跟踪忠诚度积分，简化与所有合作伙伴之间转换和兑换积分的过程。

4. 空客公司也在探究区块链应用的可能性，他们也是Hyperledger区块链联盟的参与者; 他们的测试项目是利用区块链监测全行业数据。

5. Moog Aircraft正在利用区块链进行零件监测，以及对3D打印的飞机零部件进行数字验证并提供权限管理。

神经界面

6月份，美国能源部投入2.58亿美元以支持一项计划，此计划旨在追赶中国在2020年之前拥有一台超级计算机的目标。

超级计算机可以解密人脑的复杂性，因此可以深入模拟大脑的内部运作，以更好地了解其工作原理。

去年秋天，Saber实验室针对iOS系统设计了一个以EEG为基础的飞行购物App。佩戴EEG头带之后，用户只需要观看海滩和山脉的图像建立基线脑电波，就可以完成培训。之后，在头脑中设想一个目的地（无论是山脉还是海滩），就可以进行所希望的主题飞行的搜索。

量子计算

随着量子计算机的发展，我们更多地发现它们的潜力，其首个“超级App”可以以最有效的方法绘制路径或设计系统。这对于旅游行业而言具有巨大的潜力！

和互联网搜索及社交媒体等其他事情一样，许多旅行依赖于大型数据阵列的优化。航班计划编排、机组配置、飞机路线、旅行行程等都是充满变量的优化问题。传统的计算机只能以有限的工具处理这些问题，而量子计算机可能会找到全新的解决方案。

太空旅游

目前正在开发的一些飞机技术（特别是近太空飞机）可能会在未来十年内实现更广泛的商业应用。现在，超音速飞机的各种专利申请和原型试验正在进行中。超音速飞机的速度可以达到Mach 5或以上，比空中巴士A380或波音787的最高速度至少快7倍。这种速度可以将横穿大西洋的时间缩短到1小时，伦敦到悉尼的时间缩短到2小时，彻底拉近世界之间的距离，重塑全球商业形态。

信任构建

旅游行业是建立信任的行业，随时掌握乘客和行李的位置及身份是最重要的工作内容之一。

EasyPASS（德国）、Smart Entry System（韩国）和Global Entry（美国）等旅行计划旨在通过身份预审来简化旅行。调查问卷、背景调查和访谈都可以为乘客建立信任档案，这种体系一旦建立，乘客在旅行时就会自动展示信任度。

实现旅途畅通无阻地秘诀在于在旅途中的每个节点快速准确地识别身份。如今，与亚马逊Go平台上所提供的工具相似的技术正在开发和部署，以帮助在旅行过程中实现身份认证。最快速的应用将会是在机场。澳大利亚已经宣布了一个雄心勃勃的目标，那就是：使用面部识别、指纹和虹膜扫描等技术组合的方式，到2020年自动识别90％的国际航班到达旅客身份，用户无需出示护照。

虚拟现实（VR）

Sabre团队相信VR不可能取代实际旅行，但会增强旅行体验。

VR是一种激发真实旅行和提升体验的技术。在某种程度上，VR使得新的体验成为可能，尤其是关于教育方面的。

例如，模拟罗马帝国的VR旅游可以提供深刻的历史背景，使得旅客感觉访问现在的罗马更有意义。VR还可以帮助激发当地的旅游机会，例如与鲨鱼一起潜水或在悬崖体验滑翔伞，这种VR体验容易操作，也可以为人们在现实世界中挑战极限做好心理准备。

但是，在现实世界中旅行的最重要的原因就是真实感。对千禧年代和Z一代的消费者来说，真实体验尤其重要。随着VR体验的内容无论在数量和影响力方面越来越强大，真实体验将会受到越来越多的重视。

报告下载：添加199IT官方微信【i199it】，回复关键词【2017雷达报告】即可

您可能也喜欢的文章：
Sabre：影响未来旅游业发展的九大科技趋势	2016年中国互联网金融发展历程及未来趋势衍变研究报告（附下载）	2014年15大科技发展趋势	TNS：2014年中国科技行业趋势报告（附下载）	爱立信：2016年ICT产业发展趋势报告（附下载）
无觅

百度网盘助手-获取网盘文件的下载地址，破解限速

Fri, 09 Jun 2017 13:26:36 CST

本文由 @91yun发布

众所周知，百度网盘的文件已经对非会员进行了各种限速。不过由于国内其他网盘基本都残废了，百度网盘作为仅存的少数几个，需求还是很大的，经常会碰到别人分享的百度网盘文件夹。

今天介绍的这种方法就是通过 chrome 的插件 网盘助手 来获得文件的下载地址，然后大家可以自由选择 aria2 ， idm 或者迅雷进行下载。

这种方法通用性强，无论是在 windows 还是 mac 下都可以这样获得下载地址后用下载工具下载

安装 chrome 的百度网盘助手插件

第一步：下载插件

由于很早以前百度的干涉，现在这款插件已经在扩展程序商城找不到了，我们要把他源码下下来，然后通过开发者模式加上去。

插件的 GitHub 地址： https://github.com/acgotaku/BaiduExporter

按照图片所指示的，下载代码的 zip 包

第二步：解压

第三步：加载扩展程序

勾选 开发者模式
选择 加载已解压的扩展程序
选择你刚才解压出来的扩展程序目录

这样你就可以在 chrome 上看到这个扩展程序的图标了。

导出百度网盘的文件下载地址

如果安装成功，那么在百度网盘的下载界面，你就会看到“导出下载”的按钮：

选择 导出下载 后就可以看到下载地址了：

这时候我一般会选择 拷贝下载地址 ，然后用迅雷下载，当然你看也可以直接用 aria2 或者 idm 或者其他工具下载：

百度网盘助手-获取网盘文件的下载地址，破解限速，首发于 91云(91yun.org)。

未来简史-话题报告（附下载）

Fri, 09 Jun 2017 01:03:22 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【未来简史话题报告】即可

新锐历史学家尤瓦尔·赫拉利在畅销书《人类简史》中提出，人类社会三大旧议题——“瘟疫、饥荒、战争”已被消灭，21世纪人类社会三大新议题将会是“追求永生”、“追求幸福”、“追求成神”。同时还提出，人类对新议题的求索不会停止，新议题必然会实现并伴随着巨大的代价，即人文主义将会崩塌，数据主义取而代之，意义将不复存在。

那么，数据主义是否真的会战胜一切？步入数据主义，人类社会又将发生哪些巨大的变化？

近日，百分点通过抓取全网舆情数据，采用文本分析、情感分析等方法对关注者讨论的话题、观点进行分类，并借鉴作者的分析思路，形成“《未来简史》话题报告”，展现了关注者对书中论点的关注及情感倾向状况。

报告下载：添加199IT官方微信【i199it】，回复关键词【未来简史话题报告】即可

您可能也喜欢的文章：
企鹅智酷：“解剖”95后——私享未来10年消费红利报告	爱立信：2017自动驾驶未来报告（附下载）	未来工场：天使轮教育创业趋势报告（附下载）	2016年中国互联网金融发展历程及未来趋势衍变研究报告（附下载）	新浪新闻：2017未来媒体趋势报告（附下载）
无觅

Android通过HTTP协议实现多线程下载

Mon, 20 Feb 2017 17:58:26 CST

import java.io.File;

import java.io.InputStream;

import java.io.RandomAccessFile;

import java.net.HttpURLConnection;

import java.net.URL;

public class MulThreadDownload {

/**

* @param args

public static void main(String[] args) {

String path = "http://net.itcast.cn/QQWubiSetup.exe";

try {

new MulThreadDownload().download(path, 3);

} catch (Exception e) {

e.printStackTrace();

}

/**

* 从路径中获取文件名称

* @param path 下载路径

* @return

public static String getFilename(String path){

return path.substring(path.lastIndexOf('/')+1);

}

/**

* 下载文件

* @param path 下载路径

* @param threadsize 线程数

public void download(String path, int threadsize) throws Exception{

URL url = new URL(path);

HttpURLConnection conn = (HttpURLConnection)url.openConnection();

conn.setRequestMethod("GET");

conn.setConnectTimeout(5 * 1000);

int filelength = conn.getContentLength();//获取要下载的文件的长度

String filename = getFilename(path);//从路径中获取文件名称

File saveFile = new File(filename);

RandomAccessFile accessFile = new RandomAccessFile(saveFile, "rwd");

accessFile.setLength(filelength);//设置本地文件的长度和下载文件相同

accessFile.close();

//计算每条线程下载的数据长度

int block = filelength%threadsize==0? filelength/threadsize : filelength/threadsize+1;

for(int threadid=0 ; threadid < threadsize ; threadid++){

new DownloadThread(url, saveFile, block, threadid).start();

}

private final class DownloadThread extends Thread{

private URL url;

private File saveFile;

private int block;//每条线程下载的数据长度

private int threadid;//线程id

public DownloadThread(URL url, File saveFile, int block, int threadid) {

this.url = url;

this.saveFile = saveFile;

this.block = block;

this.threadid = threadid;

}

@Override

public void run() {

//计算开始位置公式：线程id*每条线程下载的数据长度= ？

//计算结束位置公式：（线程id +1）*每条线程下载的数据长度-1 =?

int startposition = threadid * block;

int endposition = (threadid + 1 ) * block - 1;

try {

RandomAccessFile accessFile = new RandomAccessFile(saveFile, "rwd");

accessFile.seek(startposition);//设置从什么位置开始写入数据

HttpURLConnection conn = (HttpURLConnection)url.openConnection();

conn.setRequestMethod("GET");

conn.setConnectTimeout(5 * 1000);

conn.setRequestProperty("Range", "bytes="+ startposition+ "-"+ endposition);

InputStream inStream = conn.getInputStream();

byte[] buffer = new byte[1024];

int len = 0;

while( (len=inStream.read(buffer)) != -1 ){

accessFile.write(buffer, 0, len);

}

inStream.close();

accessFile.close();

System.out.println("线程id:"+ threadid+ "下载完成");

} catch (Exception e) {

e.printStackTrace();

}

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

谷歌键盘下载量突破5亿创下应用商店下载新纪录

Mon, 02 Jan 2017 23:56:59 CST

上个月，谷歌在应用商店推出了一款重新设计的谷歌键盘（Google keyboard）APP，更名为 Gboard，带有新的功能和几项升级。而现在，这款应用的下载量已经突破 5 亿，创下了应用商店的下载新记录。Gboard 是一款全功能键盘应用，支持超过 120 种语言输入，能在多种语言间随意切换。另外，它还具备自动更正功能以及手动在个人词典中添加新单词的功能。

谷歌键盘现已进入“5 亿下载量应用家族”，这一“家族”成员还包括 Google Photos、Dropbox、YouTube 和 Skype，而谷歌的 Allo 的下载量则还未超过 5 千万。

显然，在两周前 Gboard 的下载量都还没有达到 5 亿，而最新的这次升级则是促使下载量上升的一大动力。和 Gboard 下载量十分接近的是 GO 键盘，它的特色是具备 emoji 和贴纸功能。

Gboard 支持 GIF 和 emoji 功能，用户可以使用该键盘应用搜索、使用和分享动态图片。你只需输入描述所需图片的文字即可，无需在图片框内左右滑动来寻找图片。这次升级还带来了全新的“滑动输入”，用户可以简单地在键盘上滑动手指，该应用即可根据你在字母和字母间的滑动来预测你想要输入的词语。另外，用户还可以通过 Gboard 在谷歌上搜索或分享视频、图片、文章等内容。

本文链接

iiMedia Research：2016年中国微信小程序专题研究（附下载）

Sat, 31 Dec 2016 21:15:19 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【2016年中国微信小程序专题研究】即可

报告显示，82.6%手机应用开发者已经开始关注小程序。21.8%手机应用开发者明确表示愿意接入小程序，53.9%开发者正在持观望状态，24.3%开发者则暂时没有考虑接入小程序。

以下为报告详细内容：

艾媒咨询分析师认为，小程序作为一种新型手机服务方式，将对人类生活各方面造成一定程度影响，移动端服务消费将为用户提供更大的便利性，更会对传统手机应用开发商造成流量冲击。

iiMedia Research(艾媒咨询)数据显示，82.6%手机应用开发者已经开始关注小程序。21.8%手机应用开发者明确表示愿意接入小程序，53.9%开发者正在持观望状态，24.3%开发者则暂时没有考虑接入小程序。

iiMedia Research(艾媒咨询)数据显示，52.1%开发者因为接入小程序后，整体太过封闭化而暂时不愿接入小程序，47.6%开发者由于支付门槛高而影响其小程序的接入，另外，用户使用过程中场景化提供、小程序内容丰富度低等原因也在一定程度上降低了开发者使用小程序的意愿。

艾媒咨询分析师认为，虽然小程序主张轻量化、便捷式特点，但应用开发者对于用户体验满意度存在担忧。用户越来越重视应用内容丰富度、良好的用户体验，小程序作为轻量级应用，在交互、视觉等用户体验上难以保证满足用户高要求。

iiMedia Research(艾媒咨询)数据显示，不同行业商家接入小程序程度中，餐饮、快递、美业等交互相对简单的商家接受小程序意愿较为强烈。艾媒咨询分析师认为，微信作为巨大流量端口，能为变现能力较快的服务商家提供巨大用户流量，帮助其完成交易过程。资讯作为依靠流量来变现、且变现速度较慢的行业，小程序开发会带走其部分用户流量，导致其接受小程序意愿相对较弱。

微信小程序发展前景预测

巨头进驻动力缺乏小程序服务范围受限

由于小程序在微信生态上的封闭性，当前应用市场内的流量巨头以及对安全性，隐私性要求较高的应用服务商，其进驻的动力严重缺乏。另外，小程序作为服务平台，不具有跳转到独立APP的功能，用户在使用时会遇到服务范围受限的问题，例如，支付工具、第三方工具方面，可选范围可能只局限在腾讯公司产品内，第三方服务形成强势垄断，影响微信生态圈发展。

小程序激发应用长尾流量价值

小程序在全面放开申请后，个人、企业、政府、媒体或其他开发者均可以申请注册。作为以微信为支撑的超级流量入口，小程序成本低廉，能做到免安装服务即得，对大部分中小应用厂商及开发者来说，降低应用开发门槛，有效节省开发以及推广成本，充分实现应用流量以及服务价值。

小程序辅助提升微信用户活跃度

据公开资料显示，微信已经占到手机用户在线时间的三成以上，作为不同于微信的应用服务，小程序在社交传播方面着手打造用户轻便体验，即用户可以将小程序分享给好友或微信群中，进而提升微信用户使用粘性及体验时间。

小程序打造O2O服务模式新升级

小程序以二维码为服务扫描端口，将满足更多的线上服务与线下场景相结合，旅行、餐饮、购物等线下场景的打通，将会颠覆传统行业O2O模式，作为无处不在又随时可用的小程序，未来将满足微信用户更多的O2O服务模式体验。

　市场盈利状况缺乏第三方机构监测

不同于原有微信公众号，能将其基本指标数据公开化，小程序不存在订阅粉丝数量，完全依赖用户场景化体验来保持用户使用频率，对于微信巨大流量端口所转化的变现能力、用户使用权重、搜索次数等具体数据，目前缺乏第三方监测机构对其进行监测。

辅助微信迎来消费结构新生态

小程序的产生是对微信生态圈的洗牌及变革，虽然微信带有高流量，但目前仍没有很好的分发机制，广告转化率不高。小程序的投入使用会帮助微信大幅度提升程序点击率和转化率。市场积累成熟后，微信将为用户和商家提供一个超级应用平台。

报告下载：添加199IT官方微信【i199it】，回复关键词【2016年中国微信小程序专题研究】即可

您可能也喜欢的文章：
iiMedia Research：2016中国在线直播行业专题研究（附下载）	iiMedia：2016年中国在线直播行业专题研究（附下载）	iiMedia Research：2014-2015年中国微商研究报告	iiMedia Research：2014年上半年中国无线音乐市场研究	iiMedia Research：2014年上半年中国打车应用市场研究
无觅

埃森哲：2016零售业消费者研究（附下载）

Mon, 19 Dec 2016 01:05:10 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【2016零售业消费者研究】即可

近日，埃森哲发布了《2016零售业消费者研究——消费者在呼求，零售够“灵”》(Retail Consumer Research 2016)研究报告。我们的研究显示，千禧一代消费者将主导整个亚洲消费市场。因此，零售商和消费品企业必须积极采用数字解决方案，才能为千禧一代消费者提供其所需的互联、整合的购物体验。

为了完成《2016零售业消费者研究》报告，埃森哲共调研了来自13个国家的1万多名消费者。作为该项研究的一部分，埃森哲从中选取了来自中国和日本的746名千禧一代消费者，这些受访者在2015年第四季度曾在网上和实体店中购物。调研反馈者从面板数据中选择，并且经过了欧洲民意与市场调查协会（ESOMAR）的审核，严格遵守市场研究的各项国际准则。购物者样本均衡地分布在七个行业，分别为：服饰、消费电子产品、百货商场、折扣店、大众商店和大卖场、日用杂货品商店、药店和家装店。同时，样本还覆盖了不同性别、年龄、家庭收入水平和居住地区。本次调研从所有购物者中筛选出了经常使用互联网和智能手机的个人，其置信度为95%，误差范围±3.6%。

机遇就在眼前

埃森哲的分析显示，到2020年，亚太地区电子商务销售总额有望增长三倍，达到2.6万亿美元。同时，亚洲地区千禧人群的消费能力会超过以往任何一代人，到2020年，其可支配收入将增加至6万亿美元。届时，全球60%的千禧一代消费者将生活在亚洲，占本地区人口的45%以上。因此，零售商和消费品企业必须深入解读这一精通技术、实时互联的群体，充分挖掘潜藏的巨大机遇，牢牢把握这一强大的消费群体。

埃森哲消费品与服务业资深董事总经理特奥·科雷亚（Teo Correia）表示：“数字化正在改变全球消费品行业，并赋予消费者更多的选择权、洞察力和控制力。千禧一代消费者希望获得简单愉悦、根据其兴趣和生活方式量身定制的购物体验。他们变得越来越难以预测，并形成了更多细分消费群，同时他们还是强大品牌和互动购物体验的拥趸者。为了赢得其忠诚度，各品牌的当务之急就是利用数据驱动型的应用，为其提供简明而极具个性化的体验。”

千禧一代热衷移动购物

数字技术与服务正逐步成为消费者日常生活的组成部分。如今，亚洲地区拥有全球半数以上的智能手机用户，其中新加坡和澳大利亚的智能手机普及率均已超过80%，居世界首位。与此同时，亚洲地区千禧一代消费者平均每天使用智能手机达2.8个小时（即每年42.5天），他们中的四成以上曾通过智能手机购物。

埃森哲的分析表明，相较其他消费者群体，千禧一代对他人建议持更加开放的态度。零售商和消费品企业正努力通过个性化服务满足该群体需求，但前提是必须确保其方式能够为消费者所接受，例如：

• 为了获取更加个性化的体验，60%的受访中国和日本的千禧一代消费者允许零售商获取其个人信息，而整体消费群体中具有同样想法的比例仅为47%。

• 在实体门店中，77%的中国和日本千禧一代赞同用忠诚度积分和折扣券自动抵减商品价格，不过只有37%的受访者欢迎销售人员询问其近期购买记录。

• 61%的中日千禧一代希望通过网络收到他们正考虑购买商品的促销信息。

科雷亚补充道：“我们看到，成功的品牌正通过提升数据分析能力，着力打造个性化的客户体验，并从忠诚度、购买历史和人口地理特征等维度出发精准定价。他们越来越多地运用预测分析来提供定制产品服务，同时透过基于定位的服务，将自身紧密融合到消费者的生活方式当中。而企业制胜的关键则是在各个渠道与客户进行沟通，确保消费者自始至终获得心满意足的品牌体验。”

报告下载：添加199IT官方微信【i199it】，回复关键词【2016零售业消费者研究】即可

您可能也喜欢的文章：
埃森哲：2014年中国消费者洞察洞察报告全篇（附下载）	埃森哲：调研发现消费者愿意为车联网额外付费	埃森哲：在互联新世界与数字消费者互动	埃森哲：2016年技术展望报告（附下载）	百度：移动互联时代消费者决策研究（附下载）
无觅

贝恩咨询：2016年中国购物者报告（附下载）

Tue, 09 Aug 2016 01:49:39 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【2016年中国购物者报告】即可

2015年中国快速消费品市场的销售额增速达到3.5%，为五年来的最低点。贝恩公司与凯度消费者指数连续第五年合作发布的《中国购物者报告：如何把握双速前进中的中国购物者》指出，这一数据背后掩盖了一个重要的特征。尽管经济环境整体萧条，但有一些品类仍然保持较快的增速，凸显了中国快速消费品和其他消费行业在快慢迥异的两种增速下的运行轨迹。

“中国经济不断地变化和发展以适应放缓的GDP增长，经济重心也开始从制造业向服务业转移，并努力推动创新引导的增长取代投资引导的增长，”凯度消费者指数中国区总经理虞坚先生说，“我们对中国消费者的购物行为进行了跟踪，发现上述转变以及其他一些重大的经济变化对中国购物者的消费模式产生了显著的影响。”

在过去的四年中，贝恩公司和凯度消费者指数对个人护理、家庭护理、饮料和包装食品（占快速消费品销售总额的80%左右）这四大领域中的26个品类进行了深入的分析。报告详细介绍了中国市场的两种增速对快速消费品品类、零售渠道以及跨国品牌和本地品牌之间持久战的影响。

产品品类

国内服务行业的兴起以及较高薪酬职位的出现推动了酸奶、宠物食品等高端品类以及大部分品类中高端单品的增长。

“快速消费品企业已经建立了庞大的分销网络，将他们的产品介绍给中国消费者。目前，大多数品类已经达到了它们在中国所需的分销规模，各大品牌开始面临新的挑战，需要提高各个分销点的销售率方可实现增长，”贝恩公司大中华区消费品及零售业务主席、本报告联合作者布鲁诺（Bruno Lannes）先生说，“由于很难推动消费者提高购买频率，且很多品类的购买频率很低，各大品牌通常会投资推出高端产品。经实践证明，在渗透率停滞或下降的情况下，这一方法可成功地实现销售增长。”

与此同时，由于大量制造业岗位转移至人工成本更低的海外国家，在方便面、平价啤酒等传统上以“蓝领”为主要顾客的品类中，各大品牌也陷入困境。2015年，方便面的销量下降了12.5%，啤酒下降了3.6%。中国整体工人人口的数量于2012年达到高峰，之后逐渐减少，低收入退休人员增多，加剧了增速的放缓。

零售渠道

根据我们对中国购物者行为的研究，全国零售市场格局正在不断发生变化。小型门店业态将继续保持强劲增长。值得注意的是，便利店在去年的销售额增长了13.2%，在全国的渗透率增加8.5%，吸引现金充裕、但时间较少的城市消费者。

与此同时，网上购物将继续主导中国现代零售环境。在过去4年，中国电子商务市场的年增长率在37%左右，创造了近4万亿元的收入，使中国一跃成为全球最大的电商市场。贝恩公司和凯度消费者指数的联合调查发现，婴儿用品和护肤品继续主导电商市场，而口香糖、衣物柔顺剂和大多数饮料品类的网购渗透率较低。大部分个人护理、家庭护理和包装食品等品类的渗透率在中等水平，增长率较高。

相反地，过去十年重塑中国零售环境的大卖场，2015年首次出现负增长，在城市快速消费品市场的销售额下跌0.2%，客流减少4.6%，家庭平均购物量降低4.7%。超市/小超市的增长也颇为乏力，增速从9.5个%降低至4%。

外资和本土品牌

中国消费者市场的双速发展尤其体现在中外品牌之间的持久战。2015年，本土公司继续从外资竞争对手手中抢占大量份额。在贝恩公司和凯度消费者指数的调查的品牌中，本土公司的市场销售额增长率为7.8%，对市场增长的贡献为109%。这些公司在护肤品、婴儿纸尿片、护发素、牙膏和洗发水品类中的增长最多。

外资公司在衣物柔顺剂、婴儿配方奶粉、方便面和啤酒品类中的增长最多，因为外资品牌大力投资营销活动，而且消费者对本土产品有食品安全的担忧，因此转投外资品牌的怀抱。然而在2015年，外资品牌整体依然下跌了1.4%。

在去年，地区增长格局也有很大变化。在过去，城市级别是销售增长的主要影响因素之一。如今，各个城市层级的增速均向3-5%的区间靠拢，因此品牌商不能假设下线城市继续保持高速的增长。

在中国双速前行的快消品市场中取得成功
即便是在这样双速前行的环境下，我们发现购物者仍然表现出了可以预测的购买行为模式，品牌可以通过认清这些模式来超越竞争对手。根据报告，公司和品牌可以采取 4个步骤在市场中实现成功：

1. 检查自身 成本结构和运营模型，提高灵活性及其决策制定和执行的速度，以及积极接受数字化发展对自身所在品类的颠覆方式；
2. 先培养市场及销售团队的 数字化能力和思维模式，并逐渐推广至所有职能；
3. 关注零售业的巨大变化，以及由整体市场增长放缓和线上竞争导致的分销商经济效益下跌，适时调整市场通路模式。专注于致胜渠道，同时选择性投资其他渠道；
4. 打造领先品牌的关键仍然是渗透率，必须有效的结合店内推广和线上数字营销活动

报告下载：添加199IT官方微信【i199it】，回复关键词【2016年中国购物者报告】即可

您可能也喜欢的文章：
贝恩咨询：2014年中国购物者报告（二）	贝恩咨询：数字化是战略还是工具？	Kantar Worldpanel&贝恩咨询：2013年中国购物者报告	贝恩咨询：2015年中国购物者报告（二）	贝恩咨询：2015年中国私人财富报告
无觅

软负载--springmvc+dubbox+zookeeper，分享下

Wed, 03 Aug 2016 09:42:07 CST

第一步：下载
maven： https://maven.apache.org/download.cgi#
dubbox： https://github.com/dangdangdotcom/dubbox，
      介绍：http://www.open-open.com/lib/view/open1417426480618.html
      dubbox：是一波大牛在dubbo的基础上的扩展，比如加入的rest，升级了spring版本等等。
下载：zookeeper 我这下载的3.4.6 http://apache.fayea.com/zookeeper/zookeeper-3.4.6/
eclipse：要装下maven插件。

第二部：安装
maven：安装使用自己百度吧，其实就是配置下环境变量，修改下jar包的存放位置
dubbox：用CMD命令到解压出来的dubbox目录执行mvn install -Dmaven.test.skip=true来尝试编译一下dubbo（并将dubbo的jar安装到本地maven库），这样导入eclipse里面就可测试自带的demo了
zookeeper：解压之后到conf目录新建个zoo.cfg,其实就是zoo_sample.cfg上修改的，主要修改两个地方就行
1、# 存储内存中数据库快照的位置，如果不设置参数，更新事务日志将被存储到默认位置。
dataDir=D:\\apache-zookeeper-3.4.6\\dataDir
2、# 错误日志的存放位置
dataLogDir=D:\\apache-zookeeper-3.4.6\\dataLogDir

第三步用eclipse 创建自己的项目，这里我直接把我搭建的项目上传。大家可以自己看下
spring-dubbo-demo-provider.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
 - Copyright 1999-2011 Alibaba Group.
 -  
 - Licensed under the Apache License, Version 2.0 (the "License");
 - you may not use this file except in compliance with the License.
 - You may obtain a copy of the License at
 -  
 -      http://www.apache.org/licenses/LICENSE-2.0
 -  
 - Unless required by applicable law or agreed to in writing, software
 - distributed under the License is distributed on an "AS IS" BASIS,
 - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 - See the License for the specific language governing permissions and
 - limitations under the License.
-->
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
	http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <dubbo:application name="demo-provider" owner="programmer" organization="dubbox"/>
  

    <dubbo:registry protocol="zookeeper" file="C://Users/Administrator//dubbo//output//p1.cache" address="zookeeper://127.0.0.1:2181"/>

<!-- 	<dubbo:registry address="multicast://224.5.6.7:1234?unicast=false"/> -->

<!-- 	<dubbo:registry address="192.168.1.104:9090"/> -->
	
    <!--uncomment this if you want to test dubbo's monitor-->
<!--     <dubbo:monitor protocol="registry"/> -->

    <!-- here we demonstrate both annotation-based and xml-based configs -->
    <dubbo:annotation package="com.alibaba.dubbo.demo.user.facade" />

    <dubbo:protocol name="dubbo" serialization="kryo" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl" port="20880" />
    <!--<dubbo:protocol name="dubbo" serialization="fst" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl"/>-->

    <!--<dubbo:protocol name="dubbo" serialization="nativejava"/>-->
    <!--<dubbo:protocol name="dubbo" serialization="hessian2"/>-->
    <!--<dubbo:protocol name="dubbo" serialization="fastjson"/>-->
    <!--<dubbo:protocol name="dubbo" serialization="dubbo"/>-->


    <!--TODO according to the spring convention, we should use something like keep-alive-->
    <!-- use netty server -->
    <!--<dubbo:protocol name="rest" port="8888" keepalive="true" server="netty" iothreads="5" threads="100" contextpath="services"/>-->

    <!-- use tjws server -->
    <!--<dubbo:protocol name="rest" port="8888" server="tjws" contextpath="services"/>-->

    <!-- use tomcat server -->
    <dubbo:protocol name="rest" port="8888" threads="500" contextpath="services" server="tomcat" accepts="500"
                    extension="com.alibaba.dubbo.demo.extension.TraceInterceptor,
                    com.alibaba.dubbo.demo.extension.TraceFilter,
                    com.alibaba.dubbo.demo.extension.ClientTraceFilter,
                    com.alibaba.dubbo.demo.extension.DynamicTraceBinding,
                    com.alibaba.dubbo.demo.extension.CustomExceptionMapper,
                    com.alibaba.dubbo.rpc.protocol.rest.support.LoggingFilter"/>

    <!-- use the external tomcat or other server with the servlet approach; the port and contextpath must be exactly the same as those in external server -->
    <!--<dubbo:protocol name="rest" port="8888" contextpath="services" server="servlet"/>-->

<!--     <dubbo:protocol name="http" port="8889"/> -->
<!--     <dubbo:protocol name="hessian" port="8890"/> -->
<!--     <dubbo:protocol name="webservice" port="8892"/> -->

	<dubbo:service interface="com.alibaba.dubbo.demo.bid.BidService" ref="bidService"  protocol="dubbo"/>

    <!-- we add the group property since there's another annotation-configured service impl: com.alibaba.dubbo.demo.user.facade.AnnotationDrivenUserRestServiceImpl -->
    <dubbo:service interface="com.alibaba.dubbo.demo.user.UserService" ref="userService"  protocol="dubbo" group="xmlConfig"/>

	<dubbo:service interface="com.alibaba.dubbo.demo.user.facade.UserRestService" ref="userRestService"  protocol="rest" validation="true"/>
	<dubbo:service interface="com.alibaba.dubbo.demo.user.facade.AnotherUserRestService" ref="anotherUserRestService"  protocol="rest"  timeout="2000" connections="100" validation="true"/>

    <bean id="bidService" class="com.alibaba.dubbo.demo.bid.BidServiceImpl" />

    <bean id="userService" class="com.alibaba.dubbo.demo.user.UserServiceImpl" />

    <bean id="userRestService" class="com.alibaba.dubbo.demo.user.facade.UserRestServiceImpl">
        <property name="userService" ref="userService"/>
    </bean>

    <bean id="anotherUserRestService" class="com.alibaba.dubbo.demo.user.facade.AnotherUserRestServiceImpl">
        <property name="userService" ref="userService"/>
    </bean>
</beans>

spring-dubbo-demo-consumer.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
	http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd" >

    <dubbo:application name="opspeedc" owner="programmer" organization="dubbox"/>
    
	<dubbo:registry protocol="zookeeper" file="C://Users/Administrator//dubbo//output//c1.cache" address="zookeeper://127.0.0.1:2181"/>
	
<!-- 	<dubbo:registry address="multicast://224.5.6.7:1234?unicast=false" /> -->

<!-- 	<dubbo:registry address="192.168.1.104:9090"/> --> 
    <!--uncomment this if you want to test dubbo's monitor-->
    <!--<dubbo:monitor protocol="registry"/>-->

    <dubbo:reference id="bidService" interface="com.alibaba.dubbo.demo.bid.BidService"/> <!-- sticky="true" --> 
    
    <dubbo:reference id="anotherUserRestService" interface="com.alibaba.dubbo.demo.user.facade.AnotherUserRestService"/>

    <!-- directly connect to provider to simulate the access to non-dubbo rest services -->
<!--     <dubbo:reference id="anotherUserRestService" interface="com.alibaba.dubbo.demo.user.facade.AnotherUserRestService" url="rest://localhost:8888/services/"/> -->
</beans>

我消费者和提供者都是web项目直接上传到附近，大家下载下来后倒入eclipse就可以跑了，
消费者是springMVC 解析器配置的jsp和freemarker。

opspeed-parent.zip (221.2 KB)

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

IT瘾下载推荐

Meta 从盗版电子书库下载了逾百 TB 的电子书

免费可商用开源GPT模型问世，50G权重直接下载，性能不输GPT-3

模型性能如何？

曾开发最大AI芯片

PDF 预览和下载你是怎么实现的？ - 掘金

前言

PDF 预览

<embed> / <iframe>实现预览

<embed>标签

<iframe>标签

vue3-pdfjs 实现预览

为什么不直接使用 pdfjs-dist?

具体使用

存在问题

Mozilla Firefox（火狐浏览器）

PDF转 图片实现预览

具体实现

避免踩一些坑

效果演示

PDF 下载

<a>实现下载

Content-disposition和 location.href/window.open实现下载

H5 移动端的下载

H5 移动端的下载还能怎么做？

最后

Motrix下载器

官网

掌握这些窍门，下载文献更容易！

Google Scholar 优先

善用 Google

SciHub

熟知本校已购数据库使用方法

善用「原文传递」

文献互助群

学生党最应该知道的资源---技能/软件/编程/英语/二外/计算机二级/其他学习/论文下载/电子书/PPT模板_哔哩哔哩_bilibili

磁力链接BT种子电驴搜索下载网站合集 | 合集网

国内磁力搜索

国外磁力搜索

磁力下载站

种子下载站

电驴下载站

公共 BitTorrent Tracker

下载工具 Aria2 (几乎全能的下载神器) - 简书

AI领域必看的45篇论文（附下载地址）

一、神经网络基础部分

二、图像分类部分

三、批量正则化部分

四、注意力部分

五、高级的卷积网络知识

六、图像内容处理部分

七、循环神经网络部分

八、AI合成部分

九、多任务学习

十、NLP部分

十一、模型攻防

谷歌拼音输入法离线包下载

下载谷歌拼音输入法离线包

谷歌浏览器Chrome离线包下载

下载谷歌浏览器Chrome离线包

转载：腾讯评级罕见遭券商下调国金证券称市场预期和估值偏高

网易云音乐下载接口加密破解思路及步骤（附 Python 源码）

故事起因

初步探索

寻找目标 URL

寻找目标 JS

初步分析 JS

初步总结

深入探索

分析参数

分析函数

深入总结

Python 实现

加密模块实现

简易接口实现

后话

aria2 多协议和多源命令行 下载实用程序

下载

特征

用法示例

`<embed> / <iframe>`实现预览

`<embed>`标签

`<iframe>`标签

为什么不直接使用 `pdfjs-dist`?

`PDF`转 `图片`实现预览

`<a>`实现下载

`Content-disposition`和 `location.href/window.open`实现下载

aria2 多协议和多源命令行下载实用程序

谷歌键盘下载量突破5亿创下应用商店下载新纪录