分类目录归档：WEB服务

fredzneg与你一起对apache,nginx,squid,trafficserver学习相关知识及探讨！

H5性能优化方案

H5性能优化方案

H5性能优化意义

对于一个H5的产品，功能无疑很重要，但是性能同样是用户体验中不可或缺的一环。原本H5的渲染性能就不及native的app，如果不把性能优化做起来，将极大地影响用户使用产品的积极性。

用户感受

当用户能够在1-2秒内打开H5页面，看到信息的展示，或者能够开始进行下一步的操作，用户会感觉速度还好，可以接受；而页面如果在2-5秒后才进入可用的状态，用户的耐心会逐渐丧失；而如果一个界面超过5秒甚至更久才能显示出来，这对用户来说基本是无法忍受的，也许有一部分用户会退出重新进入，但更多的用户会直接放弃使用。

一秒钟法则

移动互联网的架构、通讯机制，与有线网络有着巨大的差异，这也给H5的开发带来了很大的挑战。

10.jpg

这是一张手机端接入服务器的流程。

首先，手机要通过无线网络协议，从基站获得无线链路分配，才能跟网络进行通讯。 无线网络基站、基站控制器这方面，会给手机进行信号的分配，已完成手机连接和交互。 获得无线链路后，会进行网络附着、加密、鉴权，核心网络会检查你是不是可以连接在这个网络上，是否开通套餐，是不是漫游等。核心网络有SGSN和GGSN，在这一步完成无线网络协议和有线以太网的协议转换。 再下一步，核心网络会给你进行APN选择、IP分配、启动计费。 再往下面，才是传统网络的步骤：DNS查询、响应，建立TCP链接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，开始UI展现。

可见，通过运营商的网络上网，情况比较复杂，经过的节点太多；运营商的网络信号强度变化频繁，连接状态切换快；网络延迟高、丢包率高；网络建立连接的代价高，传输速度快慢不等（从2G到4G，相差很大）。

而我们优化的目标，就是所谓的一秒钟法则，即达成以下的标准：

  • 2g网络：1秒内完成dns查询、和后台服务器建立连接
  • 3g网络：1秒内完成首字显示（首字时间）
  • wifi网络：1秒内完成首屏显示（首屏时间）

优化方案

资源加载

首屏加载

用户从点击按钮开始载入网页，在他的感知中，什么时候是“加载完成”？是首屏加载，即在可见的屏幕范围内，内容展现完全，loading进度条消失。因此在H5性能优化中，一个很重要的目的就是尽可能提升这个“首屏加载”的时间，让它满足“一秒钟法则”。

按需加载

首先要明确，按需加载虽然能提升首屏加载的速度，但是可能带来更多的界面重绘，影响渲染性能，因此要评估具体的业务场景再做决定。

Lazyload

Lazyload，即延迟加载，这并不是一个新的技术，在PC时代也是非常常用的一种性能优化手段。这个方案的原则是让屏幕外，或者不影响整体效果显示的图片、背景等资源，在界面就绪之后再进行网络加载。

滚屏加载

滚屏加载是一种常见的无刷新动态加载数据的方案，通常用在列表形式数据展示中。一方面，数据不是通过翻页进行加载，这样就避免了再一次请求和渲染整个页面；另一方面，数据显示的数量是受限的，例如第一次只请求了10条数据，也就只需要渲染这10条数据，下拉滚屏的时候，再去获得下面10条数据。

Media Query（响应式加载）

响应式设计是现在网站设计的一个流行趋势，随着移动互联网的发展，这项技术也越来越受到重视。通过这项技术，我们能够方便地控制资源的加载与显示，例如说在分辨率不同的手机上，分别使用不同的css，加载不同大小的图片资源。 方案参考： http://www.poluoluo.com/jzxy/201206/167034.html

第三方资源异步加载

第三方资源有的时候不可控，比如说页面统计、地图显示、分享组件等，这些第三方资源使用的时候要慎重选择，充分考察它们对于性能的影响，使用异步加载的方式进行，防止第三方资源的使用影响到页面本身的功能。

Loading进度条

在加载时间较长的时候，务必要让用户明确感知到加载完成的提示，通常是在加载过程中显示Loading的进度条，加载完成的时候隐藏它。从心理上，这会让用户有一种“期盼感”，而不至于太过枯燥。

对于一些重量级的H5应用，例如游戏，开始前需要加载很多资源才能让后面的游戏过程更为流畅，一个带百分比进度显示的进度条就更加重要。

避免30*/40*/50*的http status

  • 200是一个正常的response，我们在浏览器中打开一个网页（后面会讲如何针对移动端进行调试），还会看到304，即命中浏览器缓存。这两种状态是正常的http status。

  • 302、301跳转是常见的跳转，尤其前一种，在我们进行鉴权的时候有时会用到，但这个做法要尽可能地优化，一个页面访问，最多只进行一次302跳转即可，切忌频繁地跳转。

  • 404、500，我们对自己开发的代码比较注意，一般不会发生，但是有的时候，加载第三方库，尤其是第三方库中有自己load组件的操作，这时，404和500错误可能会在你不知不觉的时候发生。例如钉钉的第三方微应用中，就遇到过dojo的组件加载问题，加载的一些子组件失败了，但是又没有影响页面显示，这就很容易被忽略。后面也会再讲，如何去测试和发现这样的隐患。

Favicon.ico

如果我们没有设置图标ico，则会加载默认的图标：域名目录下的favicon.ico。很多开发者没有注意到这一点，就会导致这个请求404或者500。

通常，我们在应用内部打开网页，不会显示这个图标出来（除非放到浏览器中显示网页），我们需要保证这个图标存在，尽可能地小（一般4KB以下），并且设置一个较长的缓存过期时间。

图片的使用

格式选择

显示效果较好的图片格式中，有webp、jpg和png24/32这几种常见的图片格式。一般来说，webp的图片最小，但在iOS或者android4.0以下的系统中可能会有兼容性问题需要解决。

  • Jpg是我们最常使用的方案，大小适中，解码速度快，兼容性问题也基本不存在，是我们在H5的应用中使用起来性价比最高的方案。

  • Png24或png32，一般来说，显示效果肯定会比jpg更好，但是实际上人眼很难感知出来，所以在H5应用中要避免这种格式的大图片。

对于少量的图片，推荐用智图或者tinypng等工具来帮助自己选择合适的大小、格式。

像素控制

在H5应用中，图片的像素要严格控制，一般来说不建议宽度超过640px。

小图片合并

在html网页中，如果有多个小图片需要加载，不妨试试CSS Sprites方案，尤其是一些基本不变，大小差不多的操作类型图标。

避免html代码中的大小重设

在html或者css中，如果有类似width: **px这样的代码，就要注意看一看了，如果说图片显示的效果是宽度100px，而下载的图片却是200px宽度，那这大小基本上就是所需要的4倍面积了，所以在H5应用中，使用图片的一个原则就是需要显示成多大，就下载多大的资源。

避免DataURL

DataURL是用Base64的方式，将图片变成一串文本编码放入代码的方式。这种方式有好处，因为它可以减少一次http交互的请求，对于一些体积特别小的图片，或者是动态生成的图片可以考虑使用。但在H5应用中，一般情况下，我们都是需要避免DataURL的，因为它的数据体积通常比二进制图片的格式大1/3，而且它不会被浏览器缓存，每次页面刷新都需要重新加载这部分数据。

使用图片的替代(css3, svg, iconfont)

CSS3和svg可以更好地使用GPU进行渲染加速，而且会避免增加图片资源导致的http请求增加。例如一些div的圆角效果，就完全可以用用css来实现。

Iconfont，可以认为是一种矢量类型的操作字体。如果页面中有较多的操作图标，可以考虑使用iconfont来替代图片资源。

域名/服务端部署

Gzip

服务端要开启Gzip压缩。

资源缓存，长cache

合理设置资源的过期时间，尤其对一些静态的不需要改变的资源，将其缓存过期时间设置得长一些。

分域名部署(静态资源域名)

将动态资源和静态资源放置在不同的域名下，例如图片，放在自己特定的域名下。这样的好处是，静态资源请求时，不会带上动态域名中所设置的cookie头信息，从而减少http请求的大小。

减少Cookie

尽量减少Cookie头信息的大小，因为这部分数据使用的是上行流量，上行带宽更小，所以传输速度更慢，因此要尽量精简其大小。

CDN加速

部署CDN服务器，或者使用第三方的CDN加速服务，优化不同地域接入网站的带宽速度。

代码资源

Javascript, CSS合并

尽量将所有的js和css合并，减少资源请求的次数。

外联使用js, css

外联使用js和css，这样可以有效地利用缓存，避免html页面刷新后重新加载这部分代码。

压缩html, js, css

压缩代码，尤其是js和css资源，压缩后的大小可以降低至原来的1/3以下，有效节约流量。

资源的版本更新

库js、css通常不会更新，但是我们的业务js和css可能会有更新，如果命中浏览器缓存，可能会让一些新的特性不能及时展现，甚至可能导致逻辑上的冲突。

因此对于这些js、css的资源引入，最好用版本号或者更新时间来作为后缀，这样的话，后缀不变，命中缓存；后缀改变，浏览器自动更新最新的代码。

Css位置

CSS要放到html代码的开头的head标签结束前。如果网页是动态生成的，那么在head代码完成后可以强制输出（例如php的flush()操作），这样的话，浏览器就会更快地解析出来head中的内容，开始下载css文件资源。

Js位置

Js放到前，这样的话，js的加载不会影响初始页面的渲染。

代码规范

避免空src

图片设置为空的src地址，在某些浏览器中可能会导致增加一个无效的http请求，因此要避免。

避免css表达式

可能会让页面多次执行计算，造成卡顿等性能问题。

避免空css规则

降低css渲染计算的成本

避免直接设置元素style

直接设置style属性，一方面在html代码中不利于缓存，另一方面也不利于样式的复用，因此要避免，通过指定id或者class的方式，在css代码块中进行样式调整。

服务端接口

接口合并

如果页面需要请求两部分以上的数据接口，建议将其合并，否则会增加一次http请求。

减少接口数据量

有的时候，服务端会把一些无关紧要的数据返回回来，尤其是类似于更新时间、状态等信息，如果在客户端不影响内容的逻辑展示，不妨在接口返回的数据中直接去掉这些内容。

缓存

缓存接口数据，在一些数据新旧敏感性不高的场景下很有作用，在非首次加载数据时候优先使用上次请求来的缓存数据，可以让页面更加快速地渲染出来，而不用等待一个新的http请求结束之后再渲染。这一点我们在后面还会再次提及。

其他一些建议

  • 合理使用css

    • 正确使用Display属性 Display属性会影响页面的渲染，因此请合理使用
    • display:inline后不应该再使用width、height、margin、padding以及float
    • display:inline-block后不应该再使用float
    • display:block后不应该再使用vertical-align
    • display:table-*后不应该再使用margin或者float
    • 不滥用float
    • 不声明过多的font-size
    • 值为0时不需要单位
    • 标准化各种浏览器前缀
    • 无前缀应放在最后
    • CSS动画只用 （-webkit- 无前缀）两种即可
    • 其它前缀为 -webkit- -moz- -ms- 无前缀 四种，（-o-Opera浏览器改用blink内核，所以淘汰）
  • 选择器

    • 避免让选择符看起来像是正则表达式。高级选择器不容易读懂，执行耗时也长
    • 尽量使用ID选择器
    • 尽量使用css3动画
  • 资源加载

    • 使用srcset
    • 首次加载不超过1024KB（或者可以说是越小越好）
  • html和js

    • 减少重绘和回流
    • 缓存dom选择和计算
    • 缓存列表.length
    • 尽量使用事件代理,避免批量绑定事件
    • 使用touchstart，touchend代替click
    • Html使用viewport
    • 减少dom节点
    • 合理使用requestAnimationFrame动画代替setTimeOut
    • 适当使用Canvas动画
    • TouchMove, Scroll事件会导致多次渲染

更快一步

前面的很多建议与普通的PC端web网页的开发是一致的，但是在移动互联网应用下，仅仅做到这些，可能只有60分，那么怎样才能得到80分甚至更高？

单页应用

钉钉的审批微应用，使用的就是单页架构。在这种架构下，基本不存在页面跳转的等待时间，只需要执行js逻辑触发界面变化，最多进行一次网络请求，获得服务端数据，其他资源均不需要再次请求。

资源离线

再快的网络交互，毕竟也是跨越了数个网络节点，因此一张图片、一个js，优化到了极致，也照样可能需要几百毫秒的时间来获得。因此想要打破这个极限，就要使用资源离线的策略。

在钉钉的微应用中，就使用了这样的一个“离线包”策略。一些固定的图片、js库等，被打包放入app中（或根据需要，在app启动的时候进行下载更新）。

微应用中，网页代码里面加载网络资源的需求，就变成了直接加载本地文件，速度自然得到再一次巨大的提升。

本地数据持久化和更新机制(版本管理)

对于一些时效性没有那么高的数据，可以考虑将接口数据缓存。那么页面的渲染将变成这样的流程：

20.png

而非首次进入界面，流程如下：

30.png

可以看出，在非首次进入界面的时候，页面不需要等待网络数据返回，就可以进行界面渲染，渲染的初始数据来自于本地的缓存，页面可以“秒开”。而当服务端的数据返回之后，本地的渲染会再次更新，缓存也被更新。

采用这样的方案有利有弊，好处显而易见，首屏加载的速度简直太快了——静态资源来自本地，数据接口来自本地，这在2G、3G或者其他网络速度较慢的时候，也可以让用户在极短的时间内就看到内容。但是这种方案也并非万能。

  1. 首次加载不可避免，还是会请求网络。
  2. 服务端有更新的时候，客户端不能够快速感知，页面可能还停留在一个“旧的版本”上，尤其是网络速度较慢时，可能还是需要经过好几秒，页面才会更新至最新版本。因此如果应用对数据的新旧很敏感的话，这种方案就不适合
  3. 数据更新后，需要重新渲染界面，界面刷新的性能消耗比正常情况更多，而且增加了程序的复杂度，容易出错。

预加载

有时，我们能够通过用户的行为统计，预判出用户下一步可能进行的操作。假设，我们统计出来针对某个微应用，用户首页渲染完成之后，大部分会点击列表中的第一个项目查看详情。那么在首页渲染完成之后，我们就可以先预先加载第一个项目的部分内容，那么针对这部分用户，他们实际点击之后，立即就能看到新的页面中的内容。

当然，这个方式也并不是在所有场景下都使用。一方面，需要做好充分的用户调研，掌握用户的使用习惯；另一方面，对于小部分用户而言，预加载所带来的就是不必要的流量消耗。

测试方案

工具准备

Chrome

在功能测试中，我们通常可以用chrome来测试不同的分辨率下，或是不同的设备上，网页的展现情况。在我们做性能优化的时候，也可以用这种方式来进行调试，方便地观察在特定设备上，静态资源是否按照我们想象的那样去加载了。40.png

例如，我们想看下百度首页在某个设备下的表现。 通过F12进入控制台，点击图中的短箭头标示出来的那个设备图标，然后就可以在Device和Network中选择不同的设备和网络状况。50.png

例如iphone5下，这个地图的图标，明显就可以看到是用iconfont来实现的效果。

当然，这个功能也仅仅是一种模拟，通过控制屏幕分辨率、UserAgent等来模拟设备请求，在实际的设备上，又该怎么查看呢？

还是Chrome，我们在地址栏中输入chrome://inspect （注意：Android版本需要是4.4+，并且应用中的WebView必须进行相应的调试声明配置）60.png

在这里点击inspect，则可进入我们熟悉的F12控制台界面，只不过debug的对象变成了我们在手机应用中的网页。70.png

输入performance.timing.domComplete – performance.timing.navigationStart，就可以打印出网页加载的时间，domComplete表示所有的处理都已完成并且所有的附属资源都已经下载完毕。navigationStart表示开始加载新页面。两者相减，就代表这个网页完成渲染所需要的时间了。

同样地，我们可以在Elements tab中，debug网页，查看各个资源的使用，在Network中，看看加载了哪些资源，是否都做过了压缩。

然而，这种方式，还是有一定缺陷。 1. 如果打开网页经过了跳转，那么我们只能在这里看到最后一个url页面的加载情况。 2. 第一次打开页面的时候，在Network中，默认是不显示请求的详情的，当我们选择了preserve log upon navigation之后才会捕获，因此首次进入页面的加载情况，我们就很难获得了。

那么有没有一种方法，让我们能够更方便地去查看首次访问时，各种资源的加载使用情况呢？

Charles

Charles Proxy，可以说是H5测试的一个神器。 它的作用是在PC端开启一个代理服务器，手机连到这个代理服务器上之后，所有的http请求就都可以在这里看得清清楚楚。经过配置证书选项，https的请求也可以正常查看。80.png

从图中，我们明显可以看到，有一些404的异常请求，这些都将对我们H5应用的性能造成影响。 如果我们发现有一些资源的Duration比较大，那这些可能是服务端响应太慢，自然也可以作为我们优化的依据。

测试标准

在钉钉的测试中，形成了一套标准。

|指标项|遵循的原则|优先级|检查项|说明| |:-|:-|:—|:—|:–| |内存|内存无泄漏|P0|主功能页面反复打开，功能的重复调用，内存无泄漏| 可以使用sysdump,也可以用我们开发的perfeasy工具进行观察| | | |P1|主功能页面，持续操作，退出后，内存占用不超过总内存的5%|perfeasy| |CPU|减少无端的CPU使用|P1|灭屏，静置2分钟，在5分钟内CPU使用平均1%|adb连接后, 使用top命令| ||||主干功能正常操作CPU占用不超过60%, 持续5秒|perfeasy| |电量|避免无端电量消耗|P0|灭屏状态下，无线程持续运行|一般来说, 静置cpu正常, 这一项就没有问题| ||||灭屏，window.setTimeout()方法停止|一般来说, 静置cpu正常, 这一项就没有问题同上| ||||灭屏，window.setInterval()方法停止|同上| ||||ajax超时时间设置为5000ms以内|结合代码| ||||ajax无retry逻辑|结合代码| |资源|资源的正确使用|P0|是否存在资源的重复拉取|charles| |||P1|H5页面首屏总大小不超过200K|charles, chrome| |||P1|抓包检查(js/css/html)代码去除了空格/注释，JS文件变量名变成a/b等代替|charles, chrome| |||P1|H5引用的单张图片小于60K|charles, chrome

如果影响了显示质量, 可酌情调整| |流畅度|确保给到用户流畅的展示体验|P1|流畅的实时动画展示，avgFPS>=45|perfeasy| |时延|确保给到用户流畅的切换体验|P0|wifi网络下，首次进入页面onload时间<1000ms|Chrome| |时延|确保给到用户流畅的切换体验|P0|wifi网络下，首次进入页面onload时间<1000ms|Chrome| ||||wifi网络下，非首次进入页面onload时间<500ms|Chrome| ||||3G正常网络， 首次进入页面onload时间<2000ms|chrome, 树莓派模拟3G| ||||3G正常网络， 非首次进入页面onload时间<1000ms|chrome, 树莓派模拟3G|

经典案例

图片未优化

通过charles可以方便地进行测试。 从请求监控的情况看，有一张图片超过了60KB，宽度640px，但是在应用中，实际显示的是一张小缩略图，是通过代码控制让它显示成小图的，因此修改方案很简单，将所有头像的图片均改为获取120px宽度的即可。90.png

按需加载

  • 钉钉的教学页面

    • 多个slide页面, 每个页面有2-3个图片, 其中有一个是大图显示
    • 图片是客户提供的, 最大的图片大约是300KB以上
    • 第一次进入页面后, 所有slide的图片均进行加载
    • 3G网络下, loading的图标大约持续6000ms后才会消失

  • 优化方案

    • 尽可能优化图片, 但是压缩后发现噪点明显增加, 影响了显示效果
    • 修改加载方案, 第一次进入后, 只加载本页的图片
    • loading时间降低至1秒左右

最后插播一条广告：）

钉钉开放平台招聘微应用容器iOS工程师 负责钉钉客户端微应用iOS容器开发，参与钉钉iOS容器研发/发布/监控平台建设，建造航母级H5应用基础设施，保障线上产品质量；

需要你:

  • 精通iOS开发，熟练掌握Objective-C语言，C/C++ 语言；熟悉Cocoa开发框架，了解业界技术发展状况；
  • 熟悉iOS开发工具和相关开发测试工具的使用
  • 熟悉HTML5、CSS3和JavaScript，掌握HTTP及相关网络协议，熟悉跨终端、跨浏览器的开发模式和平台特性；

把php5.3升级成5.6 并开启opcache

原来的php都打包成rpm 后 直接安装的，可以免去安装扩展

今天想把机器上面的php5.4 升级到5.6去 为了防止漏掉参数就直接在info上面复制的 Configure Command 编译参数 

'./configure' '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php/etc' '--bindir=/usr/local/php/bin' '--sbindir=/usr/local/php56/sbin' '--sysconfdir=/usr/local/php56/etc' '--localstatedir=/usr/local/php56/var' '--with-exec-dir=/usr/local/php56/bin' '--with-mysql' '--with-iconv-dir' '--with-freetype-dir' '--with-jpeg-dir' '--with-png-dir' '--with-zlib' '--with-libxml-dir=/usr' '--enable-xml' '--disable-rpath' '--enable-magic-quotes' '--enable-safe-mode' '--enable-bcmath' '--enable-shmop' '--enable-sysvsem' '--enable-inline-optimization' '--with-curl' '--with-curlwrappers' '--enable-mbregex' '--enable-fpm' '--enable-mbstring' '--with-mcrypt' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-openssl' '--with-mhash' '--enable-pcntl' '--enable-sockets' '--with-xmlrpc' '--enable-zip' '--enable-soap' '--with-gettext' '--with-pdo' '--with-pdo-mysql' '--with-mysqli' '--without-pear'

本来以为不用安装扩展了 发现还是需要把扩展安装好后才能安装 

yum -y install libxml2-devel openssl-devel curl-devel libjpeg-devel freetype-devel libpng-devel

因为rpm源里面没有libmcrypt-devel 所以使用源码安装 

wget ftp://mcrypt.hellug.gr/pub/crypto/mcrypt/attic/libmcrypt/libmcrypt-2.5.7.tar.gz
./configure make make install

扩展安装好后就可以编译过了 

make make install 后把php-5.6.29/php.ini-development 复制到 /usr/local/php/etc/php.ini

php-fpm.conf 就从原来的地方复制过来，把启动脚本改下就可以了

这样可以启动php5.6了 然后给它加上opcache 加速

因为我们在编译的时候没有加上–enable-opcache 所以要到 

cd php-5.6.29/ext/opcache /usr/local/php/bin/phpize
./configure --with-php-config=/usr/local/php/bin/php-config 
make 
make install

然后到php.ini里面加上扩展和配置 

[opcache] ; so地址 注意这里和别的so直接extension不一样 要zend_extension才行
zend_extension = "/usr/local/php/lib/php/extensions/no-debug-non-zts-20131226/opcache.so" ; 开关打开
opcache.enable=1
; 开启CLI
opcache.enable_cli=1
; 可用内存, 酌情而定, 单位为：Mb
opcache.memory_consumption=512
; Zend Optimizer + 暂存池中字符串的占内存总量.(单位:MB) opcache.interned_strings_buffer=8
; 对多缓存文件限制, 命中率不到 100% 的话, 可以试着提高这个值
opcache.max_accelerated_files=10000
; Opcache 会在一定时间内去检查文件的修改时间, 这里设置检查的时间周期, 默认为 2, 定位为秒
opcache.revalidate_freq=1
; 打开快速关闭, 打开这个在PHP Request Shutdown的时候回收内存的速度会提高
opcache.fast_shutdown=1
重启php后在phpinfo里面能看到

Zend OPcache 一栏

php获取文件mime类型Fileinfo等方法

php如何获取文件(图片)的mime 类型呢？可以使用php mime_content_type()函数，使用开发用的ubuntu server lamp的默认配置测试后完全支持，返回了正确的文件mime type。但是将该API项目移植到Centos 5.2(内核2.6) LAMP环境时，出现了如下错误提示：
Fatal error: Call to undefined function: mime_content_type()
最后查看了最新的php手册发现php mime_content_type()函数已经被废弃，当然官方不推荐使用，而且需要经过适当的php配置后才能使用。因此要获取图片或其他的文件的 MIME类型，Fatal error: Call to undefined function: mime_content_type()错误就有了以下几种解决方案。
mime_content_type()函数判断获取mime类型
如果对已被php 5.3.0废弃的mime_content_type()函数仍然情有独钟，那么可以对php进行配置启用magic_mime扩展。比如Centos下使用phpinfo()查看php apache配置，查找到mime-magic，如果显示“–without-mime-magic”，则要编译php切换到”with-mime-magic“选 项。mime_content_type()函数还依赖于Apache httpd 的magic文件(mime_magic.magicfile)，为了检测文件的MIME类型，必须配置告知magic文件的地址，如’–with- mime-magic=/usr/share/file/magic.mime’。Windows环境下还需要在php.ini中添加：
mime_magic.magicfile = “$PHP_INSTALL_DIRmagic.mime”
其中$PHP_INSTALL_DIR是你的php安装目录。在有些LAMP环境下，这个mime_magic文件不一定存在或可读，还要另外下载。另外有些虚拟主机为了安全考虑，即使是有with-mime-magic也不一定会返回正确的mime类型，有时候会返回空字符串。因此，就凭mime_content_type()函数已经被废弃这一项，就不推荐使用该方法获取文件MIME类型了。
php Fileinfo 获取文件MIME类型(finfo_open)
PHP官方推荐mime_content_type()的替代函数是Fileinfo函数。PHP 5.3.0+已经默认支持Fileinfo函数(fileinfo support-enabled)，不必进行任何配置即可使用finfo_open()判断获取文件MIME类型。Centos 默认安装的LAMP环境php版本还是PHP5.2.6，低于5.3.0版本则可能出现类似错误提示：PHP Fatal error: Call to undefined function finfo_open() in…。因为之前的php版本，需要加载magic_open类，fileinfo函数属于PECL扩展，启用fileinfo PECL扩展才能检测MIME类型。所以有两种途径使用fileinfo获取文件的MIME类型。
    将php版本升级到5.3.0以上。php官方也已经不再维护和更新这个fileinfo pecl扩展包，所以升级是最好的办法。
    安装fileinfo pecl扩展，Centos linux 如何安装fileinfo：在Centos下面安装fileinfo命令(rpm)：yum install php-pecl-Fileinfo。或使用源码安装编译：

    cd /usr/src/down &&  wget http://pecl.php.net/get/Fileinfo-1.0.4.tgz
    tar zxvf  Fileinfo-1.0.4.tgz
    cd /usr/src/down/Fileinfo-1.0.4 && phpize && ./configure && make && make install
    还可以使用网上流传较多的一种方法，Linux通过phpize使用pecl指令来安装fileinfo：
        若没有phpize指令，需要先安装。#phpize检测若提示”No command ‘phpize’ found”，则需先安装phpize；
        下载安装php-devel(php5-dev)的rpm，安装phpize；
        service httpd restart 或 reboot；
        命令 pecl install fileinfo 安装fileinfo扩展。
        安装完毕，/usr/lib/php/module目录下多了fileinfo.so文件，/usr/share/file目录下多了magic.mime和magic两个文档
        修改php.ini配置：加入 extension=”fileinfo.so”
        service httpd restart
        Windows服务器下安装fileinfo相似，php.ini：extension=php_fileinfo.dll

image_type_to_mime_type()获取图片MIME类型
如果我们需要判断MIME类型的文件只有图像文件，那么首先可以使用exif_imagetype()函数获取图像类型常量，再用 image_type_to_mime_type()函数将图像类型常量转换成图片文件的MIME类型。同样php.ini中要配置打开 php_mbstring.dll(Windows需要)和extension=php_exif.dll。phpinfo()“–enable-exif”。首先exif_imagetype返回的是图像类型常量(Imagetype Constants)，如IMAGETYPE_GIF、IMAGETYPE_JPEG、IMAGETYPE_PNG等。
<?php
$image = exif_imagetype(“f:\test.jpg”);   //本地路径或远程图片地址均可  IMAGETYPE_GIF//
$image = exif_imagetype(“http://www.phpec.org/logo.gif”);
$mime = image_type_to_mime_type($image);
echo $mime;  // 输出image/jpeg
?>

php上传文件获取MIME类型
如果使用php上传文件，检测上传文件的MIME类型，则可以使用全局变量$_FILES[‘uploadfile’][‘type’]，由客户端的浏览器检测获取文件MIME类型。

Centos 系统或其他环境下若都不方便获取文件MIME类型的话，还有最后一种绝对可行的方法，就是读取文件名后缀，根据后缀名一一对应文件的MIME类型，具体可以参考php手册上的这条评论。当然这种方法检测到的MIME文件类型不一定是非常准确的。

 


如果又很不幸的出现 call an undefined function exif_imagetype()
打开扩展 extension=php_exif.dll
并将extension=php_mbstring.dll ,放到extension=php_exif.dll前边

 

使用tinyproxy stunnel搭建 https proxy 服务器

在各种上网的方法当中，https proxy 可能是最简单、方便、快速的，它免去了 vpn 各种拨号连接的麻烦，也免去了安装各种客户端的麻烦，同时搭建所用的软件也是历史悠久的非常稳定。

吐槽：如果问为什么这么好的方式却很少人用，答案可能是因为它需要较多的￥money，而且可能需要一张双币/多币种信用卡来购买这些东西：一个虚拟服务器 vps，一个域名，一个 SSL 证书。vps 我比较推荐 linode，并不是因为你戳一下这个链接并成功购买后能返回一点零钱给我，而是 linode 相当厚道，它会跟随主流免费为你升级 CPU、内存、硬盘、带宽等等。域名和 SSL 证书大家可以参考我的前一篇《如何购买廉价 SSL 证书》。全部扔上购物车一年大概 $150 以上，捉襟见肘的可以考虑多人合购。

好了说回正题，用于实现 https proxy 的服务端软件很多，可以用老掉牙但很稳定的 squid，也可以随便用一个轻量级的 http proxy 程序搭配老掉牙的 stunnel，或者试试新秀 node-spdyproxy 也可以。

下面介绍一下比较简单的方案：轻量级 http proxy 程序 tinyproxy + stunnel 。

1、安装 c和 stunnel

首先使用各个 Linux 发行版的包管理器安装 tinyproxy 和 stunnel，比如： 

$ sudo yum install tinyproxy stunnel // 对于 centos linux

$ sudo pacman -S tinyproxy stunnel // 对于 arch linux

 

安装完成后顺便设置它们随开机启动（可选）。

2、设置 stunnel

把你证书私钥和购买的证书扔到 /etc/stunnel 里，然后编辑文件 stunnel.conf，先指定私钥和证书文件名：

cert = /etc/stunnel/mycert.pem

key = /etc/stunnel/mykey.pem

需要注意的是从证书服务商购买回来的证书通常是几个小文件，大概有是：一个你的域名证书，一个证书链证书，一个root证书。把它们用文本编辑器打开，然后按照上述的顺序复制粘贴成一个文件，这个文件就是上面 ”cert=“ 这行所需的文件。

然后指定端口转换，比如将端口 443 （https 的默认端口）绑定并转换到 tinyproxy 的默认端口 8888：

[https]

accept = 443

connect = 127.0.0.1:8888

其中 https 这个一项绑定的名称，可以随便起，accept 表示本机监听的端口，connect 表示转换到哪里。完整的意思就是为 127.0.0.1:8888 添加 SSL 加密层，然后通过 443 端口对外服务。

 

3、客户端设置

目前默认支持 https/spdy 代理的只有 google chrome 浏览器（其他浏览器需要在客户端运行 stunnel 把 https 翻译为 http 才能使用）。而且很诡异的是 chrome 没有自己独立设置 proxy 的地方，使用系统全局的那个 https 设置是不行的（因为系统那个 https 代理指的是当你访问 https 的网站时所走的 http 代理通道，跟我们这篇说的 https proxy 是两码事），所以你还得在 chrome 浏览器里安装插件  TunnelSwitch，然后在这个插件里设置 https 代理为：“你的网站域名:443”，这样所有工作都完成可以直接上网了。

4、一个给爱折腾的人的省钱方案

如果想节省购买 SSL 证书的花费，那么自己生成一个“自签名”的证书也是可以的，不过如果你的 proxy 想共享给其他人使用的话，要慎重考虑这种方式，因为它会让不爱折腾的人觉得很折腾。

用下面命令即可生成一个自签名证书： 

openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -subj "/CN=localhost" -out req.pem
openssl x509 -req -days 365 -in req.pem -signkey key.pem -out cert.pem

注意要将上面的 localhost 更改为你的域名，最终有用的分别是私钥文件 key.pem 和证书文件 cert.pem，把这两个文件替换上面第二步所提到的位置即可。

然后在客户端需要导入这个 cert.pem 才能顺利使用你所搭建的 https proxy 服务。各个操作系统的导入证书方法都不太相同。

  • 在 linux 里比较麻烦，需要用 libnss3 工具 certutil 来完成，命令如下： 
$ certutil -d "sql:$HOME/.pki/nssdb" -A -n dummy -i cert.pem -t C
  • 在 mac osx 里使用 keychain 工具，把证书拖进”证书“一栏里。
  • 在 windows 里双击证书文件，在选择“导入到位置”那一步选择”根信任“。

然后重启你的 chrome 浏览器就可以了。

Nginx Google 扩展,让google反向代理的配置和使用wen.lu一样简单.

en.lu 一路走到现在, 离不开大家的支持!

很多朋友通过各种方式问过我: “你丫怎么不开源啊…”

先向那些朋友道歉啊, 其实不是我不想开源, 只是之前的版本配置实在太复杂. nginx 三方扩展用了一大堆, 外加 lua, 以及突破千行的配置工程, 这么拙劣的技艺, 实在不好意思拿出来分享

遂决定写一个扩展, 让google反代的配置和使用wen.lu一样简单. 

location / { google on;
}

你没有看错, “一行配置, google 我有！”

现在 g2.wen.lu 就是由该扩展驱动

Demo Site

依赖库

  1. pcre 正则
  2. ngx_http_proxy_module 反向代理
  3. ngx_http_substitutions_filter_module 多重替换

安装

以 ubuntu 14.04 为例 i386, x86_64 均适用

最简安装
# # 安装 gcc & git # apt-get install build-essential git gcc g++ make # # 下载最新版源码 # nginx 官网:  # http://nginx.org/en/download.html # wget "http://nginx.org/download/nginx-1.7.8.tar.gz" # # 下载最新版 pcre # pcre 官网: # http://www.pcre.org/ # wget "ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.gz" # # 下载最新版 openssl # opessl 官网: # https://www.openssl.org/ # wget "https://www.openssl.org/source/openssl-1.0.1j.tar.gz" # # 下载最新版 zlib # zlib 官网: # http://www.zlib.net/ # wget "http://zlib.net/zlib-1.2.8.tar.gz" # # 下载本扩展 # git clone https://github.com/cuber/ngx_http_google_filter_module # # 下载 substitutions 扩展 # git clone https://github.com/yaoweibin/ngx_http_substitutions_filter_module # # 解压缩 # tar xzvf nginx-1.7.8.tar.gz
tar xzvf pcre-8.38.tar.gz
tar xzvf openssl-1.0.1j.tar.gz
tar xzvf zlib-1.2.8.tar.gz # # 进入 nginx 源码目录 # cd nginx-1.7.8 # # 设置编译选项 # ./configure \
  --prefix=/opt/nginx-1.7.8 \
  --with-pcre=../pcre-8.38 \
  --with-openssl=../openssl-1.0.1j \
  --with-zlib=../zlib-1.2.8 \
  --with-http_ssl_module \
  --add-module=../ngx_http_google_filter_module \
  --add-module=../ngx_http_substitutions_filter_module # # 编译, 安装 # 如果扩展有报错, 请发 issue 到 # https://github.com/cuber/ngx_http_google_filter_module/issues # make
sudo make install # # 启动, 安装过程到此结束 # sudo /opt/nginx-1.7.8/sbin/nginx # # 配置修改后, 需要 reload nginx 来让配置生效,  # sudo /opt/nginx-1.7.8/sbin/nginx -s reload
从发行版迁移
# # 安装 gcc & git # apt-get install build-essential git gcc g++ make # # 安装发行版 # (已安装的请忽略) # apt-get install nginx # # 查看发行版编译选项及版本 # nginx -V # nginx version: nginx/1.4.7 # built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) # TLS SNI support enabled # configure arguments:  #  --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' \ #  --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' \ #  --prefix=/usr/share/nginx \ #  --conf-path=/etc/nginx/nginx.conf \ #  --http-log-path=/var/log/nginx/access.log \ #  --error-log-path=/var/log/nginx/error.log \ #  --lock-path=/var/lock/nginx.lock \ #  --pid-path=/run/nginx.pid \ #  --http-client-body-temp-path=/var/lib/nginx/body \ #  --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \ #  --http-proxy-temp-path=/var/lib/nginx/proxy \ #  --http-scgi-temp-path=/var/lib/nginx/scgi \ #  --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \ #  --with-debug \ #  --with-pcre-jit \ #  --with-ipv6 \ #  --with-http_ssl_module \ #  --with-http_stub_status_module \ #  --with-http_realip_module \ #  --with-http_addition_module \ #  --with-http_dav_module \ #  --with-http_geoip_module \ #  --with-http_gzip_static_module \ #  --with-http_image_filter_module \ #  --with-http_spdy_module \ #  --with-http_sub_module \ #  --with-http_xslt_module \ #  --with-mail \ #  --with-mail_ssl_module # # 下载对应 nginx 大版本 # nginx 官网:  # http://nginx.org/en/download.html # wget "http://nginx.org/download/nginx-1.4.7.tar.gz" # # 下载本扩展 # git clone https://github.com/cuber/ngx_http_google_filter_module # # 下载 substitutions 扩展 # git clone https://github.com/yaoweibin/ngx_http_substitutions_filter_module # # 安装依赖库的 dev 包 # apt-get install libpcre3-dev libssl-dev zlib1g-dev libxslt1-dev libgd-dev libgeoip-dev # # 请对照自己发行版的 configure 参数进行 configure, 勿直接 copy 以下配置 # ./configure \
  --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' \
  --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' \
  --prefix=/usr/share/nginx \
  --conf-path=/etc/nginx/nginx.conf \
  --http-log-path=/var/log/nginx/access.log \
  --error-log-path=/var/log/nginx/error.log \
  --lock-path=/var/lock/nginx.lock \
  --pid-path=/run/nginx.pid \
  --http-client-body-temp-path=/var/lib/nginx/body \
  --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
  --http-proxy-temp-path=/var/lib/nginx/proxy \
  --http-scgi-temp-path=/var/lib/nginx/scgi \
  --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \
  --with-debug \
  --with-pcre-jit \
  --with-ipv6 \
  --with-http_ssl_module \
  --with-http_stub_status_module \
  --with-http_realip_module \
  --with-http_addition_module \
  --with-http_dav_module \
  --with-http_geoip_module \
  --with-http_gzip_static_module \
  --with-http_image_filter_module \
  --with-http_spdy_module \
  --with-http_sub_module \
  --with-http_xslt_module \
  --with-mail \
  --with-mail_ssl_module \
  --add-module=../ngx_http_google_filter_module \
  --add-module=../ngx_http_substitutions_filter_module # # 覆盖二进制文件 # cp -rf objs/nginx /usr/sbin/nginx # # 重启 nginx 至此, 迁移工作结束 #  service nginx stop
service nginx start # # 配置修改后, 需要 restart nginx 来让配置生效 # service nginx restart

基本配置方法

http配置方式 

server { server_name <你的域名>; listen 80; resolver 8.8.8.8; location / { google on;
  }
}

https配置方式 

server { server_name <你的域名>; listen 443; ssl on; ssl_certificate <你的证书>; ssl_certificate_key <你的私钥>; resolver 8.8.8.8; location / { google on;
  }
}

进阶配置方法

基本搜索

需要配置 resolver 用于域名解析 

server { # ... 仅列举部分配置 resolver 8.8.8.8; location / { google on;
  } # ... }
谷歌学术

google_scholar 依赖于 google, 所以 google_scholar 无法独立使用.

由于谷歌学术近日升级, 强制使用 https 协议, 并且 ncr 已经支持, 所以不再需要指定谷歌学术的 tld

配置 nginx 

location / { google on; google_scholar on;
}
默认语言偏好

默认的语言偏好可用 google_language 来设置, 如果没有设置, 默认使用 zh-CN (中文) 

location / { google on; google_scholar on; # 设置成德文 google_language "de"; 
}

支持的语言如下. 

ar    -> 阿拉伯
bg    -> 保加利亚
ca    -> 加泰罗尼亚
zh-CN -> 中国 (简体)
zh-TW -> 中国 (繁体)
hr    -> 克罗地亚
cs    -> 捷克
da    -> 丹麦
nl    -> 荷兰
en    -> 英语
tl    -> 菲律宾
fi    -> 芬兰
fr    -> 法国
de    -> 德国
el    -> 希腊
iw    -> 希伯来
hi    -> 印地文
hu    -> 匈牙利
id    -> 印度尼西亚
it    -> 意大利
ja    -> 日本
ko    -> 朝鲜
lv    -> 拉脱维亚
lt    -> 立陶宛
no    -> 挪威
fa    -> 波斯
pl    -> 波兰
pt-BR -> 葡萄牙 (巴西)
pt-PT -> 葡萄牙 (葡萄牙)
ro    -> 罗马尼亚
ru    -> 俄罗斯
sr    -> 塞尔维亚
sk    -> 斯洛伐克
sl    -> 斯洛文尼亚
es    -> 西班牙
sv    -> 瑞典
th    -> 泰国
tr    -> 土耳其
uk    -> 乌克兰
vi    -> 越南
搜索引擎爬虫许可

任何搜索引擎爬虫都不被允许爬取 google 镜像

如下的默认 robots.txt 已经内置. 

User-agent: *
Disallow: /

如果想要使用 google 自己的 robots.txt 请将 google_robots_allow 设为 on 

  #... location / { google on; google_robots_allow on;
  } #...
Upstreaming

upstream 减少一次域名解析的开销, 并且通过配置多个网段的 google ip 能够一定程度上减少被 google 机器人识别程序侦测到的几率 (弹验证码). 

# 可以通过如下方法获取 google ip ➜ ~ dig www.google.com @8.8.8.8 +short
173.194.38.209
173.194.38.211
173.194.38.212
173.194.38.210
173.194.38.208

然后将获取到的 ip 配置如下即可 

upstream www.google.com { server 173.194.38.209:443; server 173.194.38.211:443; server 173.194.38.212:443; server 173.194.38.210:443; server 173.194.38.208:443;
}
Proxy Protocal

默认采用 https 与后端服务器通信.

你可以使用 google_ssl_off 来强制将一些域降到 http 协议.

这个设置可以让一些需要二次转发的域通过 http 协议进行转发, 从而不再依赖 ssl 证书. 



https://github.com/cuber/ngx_http_google_filter_module/blob/master/README.zh-CN.md


https://github.com/cuber/ngx_http_google_filter_module/blob/master/README.md


					

		
		
	


	

				

			
						

				nginx配置SSL证书https可以正常访问http访问400错误
			

								


				

			
    

  1. 

    

    
				给nginx配置SSL证书之后，https可以正常访问，http访问显示400错误，nginx的配置如下：
			
    

    
				server {
			
    

    
				            listen 80 default backlog=2048;
			
    

    
				            listen 443;
			
    

    
				            server_name wosign.com;
			
    

    
				            root /var/www/html;
			
    

    
				            ssl on;
			
    

    
				            ssl_certificate /usr/local/Tengine/sslcrt/ wosign.com.crt;
			
    

    
				            ssl_certificate_key /usr/local/Tengine/sslcrt/ wosign.com .key;
			
    

    
				        }
			
    

    
				http访问的时候，报错如下：
			
    

    
				400 Bad Request
			
    

    
				The plain HTTP requset was sent to HTTPS port. Sorry for the inconvenience.
			
    

    
				Please report this message and include the following information to us.
			
    

    
				Thank you very much!
			
    

    
				 
			
    

    
				说是http的请求被发送到https的端口上去了，所以才会出现这样的问题。
			
    

    

    2. 

  2. 

    
			2
		
    

    

    
				server {
			
    

    
				            listen 80 default backlog=2048;
			
    

    
				            listen 443 ssl;
			
    

    
				            server_name wosign.com;
			
    

    
				            root /var/www/html;
			
    

    
				 
			
    

    
				            ssl_certificate /usr/local/Tengine/sslcrt/ wosign.com.crt;
			
    

    
				            ssl_certificate_key /usr/local/Tengine/sslcrt/ wosign.com .Key;
			
    

    
				        }
			
    

    
				把ssl on；这行去掉，ssl写在443端口后面。这样http和https的链接都可以用，完美解决。
			
    

    

    3. 


					

		
		
	


	

				

			
						

				隐藏Nginx和PHP版本号
			

								


				

			

	配置完一台服务器后，并不是就可以高枕无忧了，前不久刚刚爆发的PHP 5.3.9版本的漏洞也搞得人心惶惶，所以说经常关注安全公告并及时升级服务器也是必要的。一般来说，黑客攻击服务器的首要步骤就是收集信息，比如说你的软件版本，这些将成为下一步有针对性攻击的依据。所以说一定程度的隐藏这些信息就显得非常有必要了，本文将简单介绍如何在网络上隐藏Nginx版本号以及PHP的版本号。




	1.隐藏Nginx版本号，Nginx的版本号主要在两个地方会有，一个是HTTP header，有个Server:nginx/1.x.x类似会暴露Web服务器所用软件名称以及版本号，这个也是大多数Web服务器最容易暴露版本号的地方，第二个地方是Nginx出错页面，比如404页面没有找到等，这是如果用户没有指定页面的话，那么Nginx自己的页面会有版本戳记。




	不过幸运的是对于这两个地方的版本号隐藏，Nginx都提供了简单的办法一步到位，参考server_tokens。通过在配置文件的http节配置server_tokens off来达到我们目的。




	











  http { # ...省略一些配置 server_tokens off; }











	最后别忘了使用命令nginx -s reload刷新当前配置。完成后你可以查看所有页面的响应头或者错误页，看看是不是只看到nginx字样而看不到版本号？什么？你想连nginx也改掉？呵呵，这个恐怕就麻烦了，需要改动Nginx源代码然后重新编译，感兴趣的童鞋可以参考《Linux/VPS环境下Nginx安全配置小记(1)》。




	2.隐藏PHP的版本号，PHP容易暴露的版本号在什么地方呢？其实也是在HTTP头，以类似X-Powered-By: PHP/5.2.11这种形式存在，大家可能会想到会不会是Nginx问题，而去到Nginx里面找相关配置，呵呵，其实这个是在PHP的配置文件php.ini里改动，打开php.ini，找到下面叙述：











;;;;;;;;;;;;;;;;; ; Miscellaneous ; ;;;;;;;;;;;;;;;;;   ; Decides whether PHP may expose the fact that it is installed on the server ; (e.g. by adding its signature to the Web server header).  It is no security ; threat in any way, but it makes it possible to determine whether you use PHP ; on your server or not. ; http://php.net/expose-php expose_php = On











	将expose_php = On改为expose_php = Off就搞定了，当然，对于Apache服务器还有另外一个方法可以直接尝试在.htaccess文件中Header unset X-Powered-By，删除X-Powered-By节，不过我还是建议改动php.ini的expose_php。

					

		
		
	


	

				

			
						

				利用Nginx的ngx_http_image_filter_module做实时的图片压缩缩略图
			

								


				

			

	你还在用 ImageMagick 生成网站的上传图片缩略图吗？其实有更好的方法一部到位，简单有效。




	现而今有非常多的云存储服务支持图片空间，并根据设定的规则来生成空间里面的图片缩略图了，例如 UpYun、Aliyun OSS 都支持。




	但有时候我们会因为一些其他的考虑（例如：价格因素），选择本地文件存储上传文件，这个时候，我们如何实现图片缩略图呢？




	其实 Nginx 内置了 ngx_http_image_filter_module 可以帮助你处理图片：



    

  • 
		缩放
	
    • 

  • 
		裁剪
	
    • 

  • 
		调整图片品质
	
    • 

  • 
		旋转
	
    • 

  • 
		锐化
	
    • 




	我们常用的可能就是缩放和裁剪了，根据业务和设计需要，在合适的位置不同尺寸的缩略图。




	安装





	可能一些标准的 Nginx 安装包没有带这个 module 的，你需要使用 Nginx 官方的源安装，并额外安装 nginx-module-image-filter 这个包:



curl -O http://nginx.org/keys/nginx_signing.key
sudo apt-key add nginx_signing.key
sudo bash -c 'echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -cs) nginx
deb-src http://nginx.org/packages/ubuntu/ $(lsb_release -cs) nginx" > /etc/apt/sources.list.d/nginx-stable.list' sudo apt-get update
sudo apt-get install -y nginx nginx-module-image-filter 



	也可以直接用做好的 安装脚本



curl -sSL https://git.io/vVHhf | bash 



	场景





	以 Ruby China 的场景为例，我设计了下面几种不同的缩略图版本:








				版本名称
			

				限定尺寸 (px)
			

				缩略方式
			





				large
			

				1920
			

				限定宽度，高度自适应
			





				lg
			

				192×192
			

				固定宽度和高度
			





				md
			

				96×96
			

				固定宽度和高度
			





				sm
			

				48×48
			

				固定宽度和高度
			





				xs
			

				32×32
			

				固定宽度和高度
			







	配置 Nginx





	假定我们的上传文件存放在 /var/www/homeland/public/uploads 里面。




	下面是 Ruby China 这个缩略图规则的完整 Nginx 配置：




	/etc/nginx/nginx.conf



user nobody;
worker_processes auto;
pid /var/www/pids/nginx.pid;
daemon on;

# 载入 ngx_http_image_filter_module
load_module modules/ngx_http_image_filter_module.so;

http {
   # ... 省略
} 



	/etc/nginx/conf.d/ruby-china.conf



proxy_cache_path /var/www/cache/uploads-thumb levels=1:2 keys_zone=uploads_thumb:10m max_size=50G; server { listen 80 default_server; listen 443 ssl http2; root /var/www/homeland/public; location /uploads { expires 7d; gzip_static on; add_header Cache-Control public; add_header X-Pownered "nginx_image_filter"; # HTTP Response Header 增加 proxy_cache 的命中状态，以便于以后调试，检查问题  add_header X-Cache-Status $upstream_cache_status; proxy_pass http://127.0.0.1/_img/uploads; # 将缩略图缓存在服务，避免每次请求都重新生成  proxy_cache uploads_thumb; # 当收到 HTTP Header Pragma: no-cache 的时候，忽略 proxy_cache  # 此配置能让浏览器强制刷新的时候，忽略 proxy_cache 重新生成缩略图  proxy_cache_bypass $http_pragma; # 由于 Upload 文件一般都没参数的，所以至今用 host + document_uri 作为  proxy_cache_key "$host$document_uri"; # 有效的文件，在服务器缓存 7 天  proxy_cache_valid 200 7d; proxy_cache_use_stale error timeout invalid_header updating; proxy_cache_revalidate on; # 处理 proxy 的 error  proxy_intercept_errors on; error_page 415 = /assets/415.png; error_page 404 = /assets/404.png;
  } # 原始图片  location /_img/uploads { alias /var/www/homeland/public/uploads/$filename; expires 7d;
  } # 缩略图  location ~* /_img/uploads/(.+)!(large|lg|md|sm|xs)$ { set $filename /uploads/$1; if (-f $filename) { break;
    } # 根据 URL 地址 ! 后面的图片版本来准备好需要的参数（宽度、高度、裁剪或缩放）  set $img_version $2; set $img_type resize; set $img_w -; set $img_h -; if ($img_version = 'large') { set $img_type resize; set $img_w 1920;
    } if ($img_version = 'lg') { set $img_type crop; set $img_w 192; set $img_h 192;
    } if ($img_version = 'md') { set $img_type crop; set $img_w 96; set $img_h 96;
    } if ($img_version = 'sm') { set $img_type crop; set $img_w 48; set $img_h 48;
    } if ($img_version = 'xs') { set $img_type crop; set $img_w 32; set $img_h 32;
    } rewrite ^ /_$img_type;
  } # 缩放图片的处理  location /_resize { alias /var/www/homeland/public$filename; image_filter resize $img_w $img_h; image_filter_jpeg_quality 95; image_filter_buffer 20M; image_filter_interlace on;
  } # 裁剪图片的处理  location /_crop { alias /var/www/homeland/public$filename; image_filter crop $img_w $img_h; image_filter_jpeg_quality 95; image_filter_buffer 20M; image_filter_interlace on;
  }
} 



	你可能会觉得上面为何写得这么绕啊！




	没办法，Nginx 不支持在 if {} 这个 block 里面用 image_filter 函数，image_filter 的第一个参数 resize/crop 也不能用变量的方式传输，所以…




	然后，重启 Nginx，就可以尝试了。




	注意点




    

  • 
		由于开启了 proxy_cache 缩略图将会在服务器上以文件的形式存在，你需要确保每次上传新文件名尽可能的是唯一的（例如用时间，或文件内容 MD5 作为文件名，参考 CarrieWave 文件名设计）
	
    • 

  • 
		浏览器强制刷新，会发起 Pragma: no-cache 的 Request Header，Nginx 会忽略 proxy_cache 重新生成图片。
	
    • 




	效果演示





	




	



	








	扩展阅读




					

		
		
	


	

				

			
						

				访问Google的神器：Chrome的QUIC协议
			

								


				

			

	在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。




	QUIC协议的原理介绍：




	TCP、UDP都是计算机网络通信层的主要协议。TCP是面向连接的，更强调的是传输的可靠性，UDP是面向无连接的，也即在通信双方进行数据交换之前，无需建立连接,只要知道对方地址即可发送数据，由于UDP协议是无连接方式的协议，所以它的效率高，速度快，占资源少。




	为了集合两者的优点，谷歌公司研制了一种UDP通信的改进版——Quick UDP Internet Connections（QUIC），快速UDP互联网连接。




	




	QUIC的主要特点包括，具有SPDY（SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础）所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。




	总之，QUIC系统能够降低网络通信的延迟，提供更好的用户互动体验，尽管随着互联网的发展，网络带宽会持续增加，QUIC等新型通信协议具有越来越重要的意义。




	




	QUIC是Quick UDP Internet Connections的缩写，读作quick。由Google开发，概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit，还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。




	概要设计文档从TCP/UDP特性、网络安全等考虑出发，做了非常多设计思路方面的论述，开头就阐述了SPDY的4个缺点：



    

  1. 
		单个包（packet）丢失会阻塞整个流（stream）。
	
    2. 

  2. 
		TCP避免拥堵的机制做的不好，导致带宽降低和序列化的等待时间开销。
	
    3. 

  3. 
		TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
	
    4. 

  4. 
		TLS解密的开销。先到的包必须等后面的包到来才能解密。
	
    5. 




	可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。




	QUIC的文档还算未完成的状态，且Chromium的实现代码也在完善中，这还是个试验性的半成品，没有性能比较的数据。只浅浅研究即止，不深入了。




	




	

					

		
		
	


	

				

			
						

				全民大直播，流媒体选择Nginx是福还是祸？
			

								


				

			








CDN，视频云，已经“僧多粥少”









	




	视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵，揭竿而起的新生起义军们也正马不停蹄的赶往这方战场，各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏，让人眼花缭乱，“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下，视频云和CDN们，技术上到底是在竞争什么？作为视频平台和即将要进入视频领域的运营者，在技术平台的选型和搭建上又如何才能避免掉入大坑？






	











一个播放器的背后









	谁都知道视频直播最重要的是流畅和高清，但这光鲜亮丽的背后是技术和成本的双高门槛，是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播，主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节，还要求在数秒内完成，除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。




	




	




	再如下图，仅一个屌丝观众从播放器看这个主播，就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样？使用的系统环境又怎么样？一个观众尚且如此，要保障百万千万级别流畅的观看，难度可想而知。




	




	











高清流畅到底靠的是什么









	也许对于部分视频运营商和新进入者来说，直播推流端和播放器端依然觉得头大，但整体来说，除移动端外，PC端推流和播放技术已经比较成熟。难，主要难在传输和分发！正常情况下，只要推流端网络状况良好，传输和分发决定着直播是否能够流畅。







	传输和分发，涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂。也因为如此，视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层，如下图：




	




	




	L2资源层：对视频云和CDN来说，资源的确存在差别，但在其可承受范围内，可以视为差别不大；




	L4传输层：传输层可针对不同业务场景，比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障，不同应用场景的支持后续文章将专门介绍；




	L3网络层：视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要，随着CDN技术的日益成熟，虽然各家可能存在架构区别，但基本都能保障网络路由正常运转；




	L7应用层：抛开细枝末节，视频流的主线还是输入、传输与输出，承担这些工作的就是视频平台最核心组件流媒体服务器，这就是视频直播分发最本质的特点，需要专门的流媒体服务器来分发，所有视频云和CDN，都需要在中心层和边缘层部署流媒体Server。




	 




	通过以上逐层分析可知，当资源和网络层面相差不大的情况下，流媒体Server的性能决定了视频流分发的效果和质量，故流媒体Server才是视频云和CDN技术竞争的至高点。




	







	











市面主要的流媒体服务器对比









	目前市面上主流的流媒体服务器，有以Adobe FMS、Real Helix、Wowza为代表的第一代产品，它们的特点是单进程多线程。基于Linux2.7 epoll技术，出现了以多进程单线程为特点的第二代流媒体服务器，NginxRTMP、Crtmpd为其优秀的代表，另外还有基于JAVA的流媒体祖先Red5等。




	观止云开源流媒体服务器SRS（Simple RTMP Server），凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务，高升CDN基于SRS搭建其流媒体基础平台，其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server，在中国流媒体业界实属难能可贵。




	




	观止云源站集群BMS（Bravo Media Server）是SRS的商业版，BMS在SRS基础上增强了11项大功能，新增了9个大功能：




	




	增项的11项大功能：




	







	新增的9项大功能：




	







	







	流媒体Server的话说来也不短，上述列举的目前市面上主流流媒体服务器中，有名副其实的先烈RED5，有生不逢时的CRTMPD，都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp，以下是nginx-rtmp几个盛行于世的重要因素：



    

  • 

    
			2012年CDN业务开始极增长，随之直播需求也多了起来，彼时业界都还没有一套公认的特别满意的流媒体服务器；
		
    

    • 

  • 

    
			Nginx是HTTP领域绝对的霸主，大家（尤其是CDN运维）对Nginx熟悉程度很高，便于上手维护；
		
    

    • 

  • 

    
			基于Nginx，直播点播使用一套服务器，这也极具诱惑力，一套管理起来总比多套要简单；
		
    

    • 

  • 

    
			CDN是靠运维的行当，运维的信心都是长年运出来的，Nginx在图文上那么优秀，Nginx RTMP也差不了。
		
    

    • 




	







	nginx-rtmp确实生来就自带光环外，性能也的确是高，比Crtmpd还要高。然而，时过境迁，随着互动直播、移动直播的强势兴起的大直播时代，选择nginx-rtmp到底是福还是祸？




	下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比，供视频从业者根据自身业务场景特性择优选用。




	












1






网络协议对比







	




	BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。




	












2






体系架构对比







	




	架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。




	观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。




	












3






核心功能对比







	




	核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。




	












4






配置运维对比







	以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。




	（1）vhost配置




	FMS




	




	拷贝默认vhost目录：sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com




	







	nginx-rtmp




	不支持




	







	SRS/BMS




	




	动态获取配置文件：vhost bravo.sina.com { }




	结论：BMS动态获取配置最简单




	（2）app配置




	 FMS




	拷贝默认app目录：cp applications/live applications/mylive -r




	







	nginx-rtmp







	修改配置文件，增加如下内容：application live {  live on; }




	







	SRS/BMS









		无需配置
	







	结论：BMS无需配置，最简单 




	（3）http配置




	在输出为hls、http-flv等基于http协议的直播流时，需要配置http服务




	FMS






		配置FMS内置的Apache服务器文件：Apache2.2/conf/httpd.conf
	



		再修改如下字段：
	





			<Location /hds-live>
		







			    HttpStreamingEnabled true
		







			    HttpStreamingLiveEventPath “../applications” 
		







			    HttpStreamingContentPath “../applications” 
		







			    HttpStreamingF4MMaxAge 2
		







			    HttpStreamingBootstrapMaxAge 2
		







			    HttpStreamingFragMaxAge -1
		







			    Options -Indexes FollowSymLinks
		







			</Location
		







	







	nginx-rtmp









		nginx本身就是一个http服务器，
	





			修改其配置文件：
		







			conf/nginx.conf
		









			设置端口和根目录：
		







			http {
		







			    include       mime.types;
		







			    default_type  application/octet-stream;
		







			    sendfile        on;
		







			    keepalive_timeout  65;
		









			    server {
		







			        listen       80;
		







			        server_name  localhost;
		







			        location /dash {
		







			            root /tmp;
		







			            add_header Cache-Control no-cache;
		







			        }
		







			    }
		







			}
		







	







	SRS/BMS











			修改其配置文件：
		







			conf/http.hls.conf
		







			设置端口和根目录：
		







			http_stream {
		







			    enabled         on;
		







			    listen          8080;
		







			    dir             ./objs/nginx/html;
		







			}
		







	结论：nginx-rtmp需指定与app对应的ts文件存放目录，SRS/BMS会自动生成，更简单。




	（4）推流、播放URL配置




	RTMP直播时，各大服务器推流、播流URL均为：




	rtmp://server_ip_or_dns/app/stream




	







	用作HLS直播时，




	FMS 








			推流域名：
		







			rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent
		







			播流域名：
		







			http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m
		







	







	nginx-rtmp











			推流域名：
		







			rtmp://server_ip_or_dns/app/stream
		







			播流域名：
		







			http://server_ip_or_dns/app/stream.m3u8
		







	







	SRS/BMS











			同nginx-rtmp
		







	结论：nginx-rtmp、SRS/BMS均简单，FMS较复杂。




	












5






性能







	先说结论：




	SRS单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5




	 




	再例举SRS性能如此高的几个原因：




	1. st-load，这个是SRS能做到高性能的最重要的原因，一个st-load可以模拟2000+的客户端，如果没有st-load，如何知道系统的性能瓶颈在哪里？总不能打开3000个flash页面播放rtmp流吧？开启3000个ffmpeg来抓流？高性能不是想象和猜测出来的，而是反复测试、调试和改进出来的。




	2. gperf/gprof性能，编译SRS时，就可以打开gcp或者gprof的性能分析选项，非常方便的拿到数据。缩短了改进和优化开发周期。




	3. 引用计数的msgs避免内存拷贝。




	4. 使用writev发送chunked包，避免消息到chunked包的内存拷贝。




	5. mw(merged-write)技术，即一次发送多个消息。




	6. 减少timeout recv，每个连接都是一个st-thread在服务。




	7. fast buffer和cache。




	8. vector还是list？vector！vector比list高10%性能。




	












6






服务器日志







	日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，10分钟的排错，谁都会觉得长。然而，当前的视频云或CDN，谁又能做到10分钟呢？




	来看看日志吧。




	




	FMS的日志是这样的，恕我愚钝，你能看得出什么信息么？






		2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-
	



		702111234525315439     3130         3448         normal      livestream         –        –         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        –        flv     –        –        0       –        0       0         –        –    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         
	





	crtmpd的日志详细，但我又愚钝，若是上千人在线，你又能看出什么有用的东西么？




	






		
	



		/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER
	



		/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935
	



		/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpap