通过ipv6绕开网页认证

在一个需要Web认证的WiFi网络下,无意中nettop发现有一条tcp6的链接是Established状态,搜一下发现大部分Web认证,都仅仅拦截ipv4的流量。

6.47.46

正常情况,如果没用通过Web认证,打开任意网页,都会被302重定向去登录页。

QQ20160504-0@2x

对比已经很明显了,基本上这个网络已经可以随意使用了。

新版SS同时监听ipv4和ipv6的配置改了,变成如下格式

愉快的和Gist玩耍

github.com树大招风,国内时不时就不能访问,连里面的Gist也有问题。

WordPress有一个Gist的embed插件,但是这个插件是直接引入Gist的script,这个script是通过document.write()阻塞方式,在当前DOM位置插入Gist定制的内容。

所以,国内访问我博客,如果谋篇文章引用了Gist上面的内容,访问就会被拦掉了。

研究了下Nginx反向代理,用了一个子域名来承载各种代理资源,用一级目录来区分反向代理站点,世界一下子安静了。

整个优化改造过程没WordPress什么事,用Nginx的ngx_http_proxy_module模块做目标站点反向代理,用Nginx的ngx_http_sub_module模块来替换页面中gist.github.com关键字。

折腾一番,Nginx能力又提升了,哈哈。

现在打开还是有点慢,因为代理每次都要重新请求,由于Gist的资源是会更新的,不能直接暴力缓存,还得想想怎么去缓存这种动态数据。

诡异的iOS keep-alive bug

https://bugs.webkit.org/show_bug.cgi?id=155632

去年12月发现,偶发性,各种Charles抓包、rvictl流量复制等方式来定位分析,还恶补了TCP协议,都没找到原因,只是看上去觉得iOS这边处理HTTP请求的方式怪怪的。

终于尘埃落定,服务端根据UA识别出iOS,关掉HTTP的Keep-Alive功能来规避。

keep-alive是HTTP协议里面的

keepalive是TCP协议里面的

HTTP协议通过头部的 connection: keep-alive 来通知两端TCP建立一个keepalive链接,在keepalive有效期内,不需要重复3次握手动作,不需要重新慢启动

 

用PhantomJS来给AJAX站点做SEO优化

腾讯问卷所有动态内容,全部由Ajax接口提供。

众所周知,大部分的搜索引擎爬虫都不会执行JS,也就是说,如果页面内容由Ajax返回的话,搜索引擎是爬取不到部分内容的,也就无从做SEO了。

先来看看效果

QQ20160321-1

去年一整年,搜索引擎收录都少得可怜。

更致命的是,被收录的页面,其搜索引擎里面显示的标题是最原始的html标题,权重如此高的地方,却被收录了一个没什么用的标题。

在去年年底完成实施了预渲染服务后,收录量蹭蹭蹭的起来了,并且收录的标题也都全部正常了。

而这所有的一切,除了Nginx接入层的配置是需要改动业务代码外,其他全部都是旁路机制。也就是说,自己做一套,可以给所有同类型业务共用,同时不会影响现有业务的任何代码任何流程。

继续阅读“用PhantomJS来给AJAX站点做SEO优化”

mac命令代理

内网装个东西就是麻烦,临时给某个命令走代理可以通过如下配置实现

 

iOS抓包新姿势 – rvictl

最近遇到一个诡异的问题,出现在特殊网络情况下,一旦劫持抓包就无法重现,怎么破?

Google告诉我们,iOS有一个rvictl的神器。

rvictl总共就3个参数

  • -l 显示当前活跃设备
  • -s 开始监听
  • -x 结束监听

其原理是将iOS设备的流量,像打日志一样复制一份到Mac上,在Mac上再通过Wireshark就能进行分析。这种做法,不像代理,不会干扰iOS设备正常的网络访问。

步骤

1.将iPhone通过数据线,连上Mac,并打开iTunes,复制设备UDID。

2.打开Terminal,输入  rvictl -s 设备UDID

3.打开Wireshark,在捕获选项里面选择rvi0这个设备,这个时候,iPhone所有TCP和UDP流量,都会打印到Mac上。

4.在Wireshark里面输入合适的过滤器,便于追踪目标流量。

也来说说webpack

入门

webpack,官方定位是一个模块打包工具,基础命令极其简单

在CLI模式中,第一个参数是入口文件,第二个参数是输出文件,并读取当前cwd目录下面的webpack.config.js配置,根据配置生成对应的bundle.js文件。

其用法与RequireJS里面的r.js命令极其相似。

快速上手

如果一个新业务,想做一下JS的模块化管理,那么可以立即选择webpack了。

如果一个老业务,曾经用了RequireJS或者SeaJS,那么也可以选择切换webpack了。

如果想做一个库\框架去为生态提供服务,也可以立即选择webpack,他能自动配置最终生成的library.js文件支持AMD\CommonJS等模块化方案。

用好配置里面的resolve,改造一下原有的Grunt\Gulp流程,即可使用webpack,业务代码基本无需改造。

多种模块化打包加载方案对比:http://webpack.github.io/docs/comparison.html

其实对于老业务而已,仅仅将JS的模块化从RequireJS替换到webpack,其收益并不明显,仅仅是最后生成的JS文件要小一些而已。

进阶

如果单单从CLI模式中的提供的参数来看,webpack的能力也就到此为止了。但webpack的作者并非只想做一个AMD\CommonJS\ES6 Modules的协议实现。

webpack提供了一个Loader和Plugin的机制,让社区通过提交自己的Loader和Plugin,大大拓展了webpack的应用场景。

别忘了,webpack的REPL可是完整的nodejs,也就是说Grunt、Gulp能做的事情,webpack也能做(只是能做,不代表webpack擅长做)。

同时,通过各种Loader和Plugin,webpack还能打包样式、图片等资源文件,并按需将这些资源文件inline到html中。

与babel的勾搭

建议es-2015就先别折腾了,webpack本身编译速度,在我的MBP上面是50ms上下,但加入babel并使用es-2015语法转换后,编译耗时直接涨到700~800ms,这还仅仅是只有两个js文件的demo。

在webpack的roadmap里面,看到有对ES6 Modules进行支持的计划,我们还是静等吧。

欠成熟的Loader和Plugin列表

其最富有想象力、最能拓展的Loader和Plugin,她们的列表是竟然是人工维护的一份Github Pages。相对于其他社区来说,这块差了点。同时由于是手动维护的列表,其Loader和Plugin的质量,只能通过Github和npm中进行判断。

读书笔记《React-引领未来的用户界面开发框架》

React这么火,我们也来深入研究下吧。

买了本React相关的书籍,刚看了前十章,随手记一下读后感吧。

废话篇

这部分内容,人云亦云

垂直切分的组件

React对于配置多名前端开发的团队,在协作上有一定的优势。

其组件化思路,是一种垂直划分,每个组件高度自治。与我们习惯上的Html、JS、CSS三分离的水平划分思路不一样。

垂直划分,让每个组件自己决定自己的结构、行为、表现,调用方只需要拿来即可使用。使用JSX来定义组件结构,通过Sytle对象来inline样式属性。

这里有两个不爽的地方。

  • JSX语法太丑陋
  • style对象权重太高,外链样式难以做正常的样式覆盖

JSX语法问题,还好IDE能高亮,看上去稍微舒服点。内联style权重问题比较难解决,最近WebRebuild上萝卜分享过一个css_module的解决方案,挺暴力,但又十分有效。

枚举一切可变字段(state)

其实在Backbone的年代,已经有这样的东西,只是没有强调而已,且没有那么智能的去更新界面(Backbone需要手动监听字段变化,然后去执行对应的方法,一切都要手动)

在React的世界里面,一切的讨论都围绕着这些可枚举的state。为了能高效的实现刷新界面,大家都乐意去细化界面上每个可变元素,将其与组件的state映射起来(其实就是在JSX里面包个{this.state.something})

setState() => componentDidUpdate

由于所有可变因素(state)都被枚举出来了,且界面发生变化的原因有且仅有一个,这让React组件变得可预知性可测试性

大肚能容

ref、getDOMNode()、componentDidMount()、componentWillUnmount()让React有了兼容其他非React生态的JS库\组件的能力,这个还是挺赞的,对于已有业务,改造起来也稍微方便点。

高能篇

这部分脑洞比较大

论setter、getter的重要性

一个好框架\库,需要有一个统一的输入输出接口

在React里面,有一个很重要的概念,是一切改变,都必须通过setState()方法来传达。只有这样,所有的变化才是可控的、可预测的。

setter、getter这两个方法,其实在各种各样的库里面都有,但没有像React世界里面这么强调。

例如在某个中间环节,为了图快,时不时就出现直接修改原始对象属性的情况。这种变动,框架层面是没法侦测到的。

又例如读取某个带嵌套关系的对象,没用getter,一个不小心就把原始对象的引用给暴露的出来,然后极容易出现在某些边边角角发生引用被改动从而触发一些很隐晦的BUG。

论钩子的重要性

一个好框架\库,需要有丰富的外部钩子,便于拓展

WordPress占有率高吧,为啥?因为他易于定制、拓展,他有非常丰富完善的钩子机制来给各种主题、插件提供定制拓展能力。

React也有很多钩子,他强调的生命周期,其实就是一系列的钩子,给业务能非常容易的在想定制拓展的地方进行定制拓展。

Backbone有钩子吗?有,但少得可怜,没记错的话,Backbone.View默认只有initialize和render两个钩子,React组件单单存在期的钩子都比他多。

Marionette则弥补了Backbone.View在钩子上面的缺失,可惜太小众。

钩子要怎么做?简单来说就是在框架、库的生命周中埋下大量空函数供拓展的时候覆盖就好了。

未完待续

用madge来绘制项目的依赖图

https://www.npmjs.com/package/madge

今天早上刚发现,很犀利的一个模块依赖检查工具,并可以可视化的绘制出来,支持AMD\CommonJS\ES6等模块依赖。

安装

使用说明

绘制依赖图

用处

业务做优化、重构的时候,可以先跑一次依赖图,看看都有哪些边边角角藏着废弃代码。

业务做局部模块优化的时候,也可以跑一遍依赖图,看看修改的模块会导致哪些地方出现变动。