极简设计

https 2016-01-01

Read More


使用httpclient必须知道的参数设置及代码写法、存在的风险 2016-01-01

Read More


http 2016-01-01

HTTP(HyperText Transfer Protocol)翻译之争

制定者提出transfer不是传输的意思,是针对资源的动作,而不是传输数据的含义 图灵社区翻译大讨论多数人认为应该翻译成“转移”,URL这个资源标识符在浏览器,Cache,Proxy,Server等实体中的转移和操作(manipulation)

不少WWW应用中违背RESTful设计的地方

1.Cookie之中携带状态信息违背了REST 2.返回客户的页面中内嵌Java Applet应用,使得客户端也有智能了,也违反了REST等等

HTTP/2

新事物诞生多源于旧事物的痛点

HTTP1.X作为www的基础,支撑Web多年。在线高清视频,网页游戏用户体验都很好 HTTP1.X设计上的痛点,目前通过折中方式绕过 HTTP/2的引入可以归功于谷歌对完美的极致的追求

- 严格的B/S模式

Server端不能主动发起通知。开发者要引入一些复杂折中机制(AJAX, long poll,web socket等)

  • 不支持真正的基于一个连接的并行多会话 这会影响处理速度,对于google这样的巨型应用服务商,网页加载速度慢一点都会带来巨额广告损失

  • 数据中心,如果协议更轻便,单台物理服务器支撑更多并发连接,数据中心在耗电量不变的前提下可以提供更大规模应用支持,直接提高营收

  • 协议头部的数据冗余

Google有高水平开发人才,创新基因和占垄断地位的Web应用和Chrome,等待又意味着金钱的流失 于是挽袖子干,升级Chrome,大规模在Google应用部署了SPDY(类似HTTP/2的协议),Twister等厂商也跟进。挟天子以令诸侯,赶IETF上架。如果没有google的努力,HTTP1.X的时代会延续更久

HTTP/2标准的发展 HTTP Server Push

www的RESTful风格严格基于C/S模型。未想到过支持Server发起请求

  • Client Poll

两种poll方式

  1. Client定时向Server询问是否有事件
  2. Piggyback

Server端将事件累积起来,下一次应答Client请求的时候捎带送回去 像Linux异常的实现,在下一次系统调用的时候捎带把signal送回去 这两种都是方式都是模拟,缺点显而易见

  • Server Push

目的是即时将消息发送到Client。基于现有HTTP 1X有两种hack机制:long poll和HTTP streaming

一、Long polling

机制:

1.Client发起一个请求,目的是创建一个控制通道

2.server端保持这个请求,不应答,直到有事件产生,server发送response通知client

3.一次事件通知后,连接关闭。client发起一个新的请求,重建控制通道,等待下次事件

简言之,Client每个poll至少收到一个event响应(server也可以积攒多个事件,一次发送)

二、Streaming

利用了协议设计中的奇淫巧计,算是HTTP1X下hack方式Server Push实现的精华了 可以在同一连接,分多个部分发送HTTP response,能立刻想到是chunked编码

Server一直不发送last chunk,有事件就插入到chunk data通知Client,可以一直插入新的chunk data。这样一个HTTP连接可以用于多次事件通知,这也是streaming和long poll这两个名词的区别所在

MIME Multipart是streaming的一种实现 本质上和chunk类似,只是在MIME中。不是HTTP机制 一个MIME内可以带若干个Message,Message之间使用叫做boundary的字符串分开 MIME结束的地方,会有一个结尾boundary的特殊字符串,类比HTTP chunk编码的last chunk

Mixed-Replace这种MIME type,底层传输也是基于HTTP chunked 编码。它的引入就是为了server push 这类multipart之中的所有单独的message都是针对同一个对象的信息 新message替换旧的。可以想象,把电影胶片有序排列,每幅胶片通过一个message传输,更新HTML的某个图像框,multipart MIME一气发送下来,展现出来的就是一部影片了

三、支持Server Push的新协议

  • Server-Sent Events(SSE)

W3C的标准,与其说是全双工协议,不如说是long polling的标准化。看了协议描述,SSE同前文提到的multipart/x-mixed-replace是本质一样的

a)定义了标准的MIME type “text/event-stream ”

b)定义了消息格式,如下面

data: This is the first message. data: This is the second message, it data: has two lines. data: This is the third message. data: This is the first message. data: This is the second message, it data: has two lines.

data: This is the third message. c)标准化了前文例子中的keep alive

使用':’开头的数据,表示comments,每隔一段时间发送一次,作为keep-alive

d)建议disable chunked编码,可以独立于chunked编码工作

SSE并非新协议,附属于HTTP1.X,没有被IETF标准化

  • WebSockets

独立实现了完全的Server Push。HTML5中提出,并最终独立发展的全双工协议,恰如其名,web上面的socket和streaming类似,websocket是client发起的长连接。但C/S双方可以随时互发信息,独立于HTTP,不受拘束

HTML5这种信息表示层的规范会涉及通信协议的定义,可能和Google的SPDY一样,为了解决问题,赶IETF上架


HOL 及其它协议缺陷 HOL(head-of-line blocking) HTTP是一种顺次处理的ping-pang协议(ping即HTTP request,pang即HTTP response)。HOL指同一连接上,请求有序处理,即便请求之间没有关联性

HOL是下面HTTP1.X的已有技术的传承:

1.1.HTTP1.0

每个连接一对request和response,然后关闭连接

1.2.HTTP 1.1 Persistent connection

应用可以复用一个HTTP连接,多次ping-pang,时序是:

C2S: req1 req2 req3 S2C: resp1 resp2 resp3

进行完一对ping-pang,client才能发起新的请求。

在第一次听说persistent connection的时候我有如下疑问:

A)Client和Server之间如何协商Persistent Connection?

对于HTTP1.1,persistent connection是缺省行为。如果client不支持,需要在request中显示添加 connection : close字段

B)谁来关闭Persistent Connection?

Client和Server都有权关闭persistent connection。

任何包括“connection:close”字段的HTTP消息(无论请求应答),都表示当前的ping-pang是最后一对了

1.3 HTTP 1.1 Pipe line

client可以一次发送一批request,可能的时序如下:

C2S: req1 req2 req3 req4 req5 req6 S2C: resp1 resp2 resp3 resp4 resp5 resp6

这是HTTP 1.1协议下看起来最并行的情景了。即便这样,如果req1没有处理完,server也不会处理req2。即,pipeline的情况下也有HOL问题

1.4 解决办法

Head-of-line blocking在HTTP1.1中是协议缺陷,不修改协议的情况下只能并发多个HTTP连接

如果可以对协议进行修改,最好可以实现类似下面这样的完全无序并发:

C2S: req1 req2 req3 req4 req5 req6 S2C: resp3 resp1 resp4 resp6 resp5 resp2

2.不是缺陷的缺陷

【1】还提到了一些其它HTTP1.X的问题,但我觉得都不是事儿,设计者的出发点也不是协议功能

其一是HTTP报文头部冗余。协议建议进行首部压缩,这句话对于任何协议都适用。首部都压缩后,我们网络工程师调试困难多多,还怎么构造文本直接通过telnet测试。安全网关处理这些信息,不得不分配内存解压缩,劳神费力易出错。

其二是引入了流控以及请求优先级的概念,都是协议增强,和缺陷无关


SPDY事实标准 http://www.unclekevin.org/?p=289


(SM,NF,WAKA) http://www.unclekevin.org/?p=320

HTTP/2标准现状 http://www.unclekevin.org/?p=352

HTTP/2安全考量 http://www.unclekevin.org/?p=394

HTTP 头部压缩 http://www.unclekevin.org/?p=402

实现分析 http://www.unclekevin.org/?p=418

Read More


html5 离线缓存 2016-01-01

离线本地存储和传统的浏览器缓存区别
浏览器与服务器的交互 ...

Read More


hash 2016-01-01

常用数据结构复杂度 http://bigocheatsheet.com/

map使用时性能注意 事先规划好容量 使用concurrentHashMap或特定场景选择如TreeMap的结构

JDK8中HashMap的新特性 如果某个桶中的链表记录过大的话(当前是TREEIFY_THRESHOLD = 8),就会把这个链动态变成红黑二叉树,使查询最差复杂度由O(N)变成了O(logN)。

SparseArray代替HashMap Android官方推荐使用SparseArray(稀疏数组)或者LongSparseArray代替HashMap 使用基本类型(Primitive)中的int作为Key,不需要Pair<K,V>或者Entry<K,V>这样的包装类,节约了内存 SpareAraay维护的是一个排序好的数组,使用二分查找数据,即O(log(N)),每次插入数据都要进行排序,同样耗时O(N);而HashMap使用hashCode来加入/查找/删除数据,即O(N/buckets_size) 总的来说,就是SparseArray针对Android嵌入式设备进行了优化,牺牲了微小的时间性能,换取了更大的内存优化;同时它还有别的优化,比如对删除操作做了优化; 如果你的数据非常少(实际上也是如此),那么使用SpareArray也是不错的

Read More


guava 2016-01-01

guava

Read More


golang 2016-01-01

互联网时代的C

  • 充分利用多核
  • 软件品质和团队协作
  • 编程哲学重塑

并发与分布式

执行体 多数语言语法层不支持协程,通过库支持也不完整,仅创建/销毁/切换,协程中调用同步IO会阻塞其他协程 执行体间通信需要有互斥/同步,消息传递,多数语言提供了库支持,也看不到协程

软件工程

  • 代码风格
  • 错误处理
  • 接口
  • 单元测试

免public/private/protected关键字,以大小写统一作用域 花括号统一 错误处理引入deffer,免嵌套try catch

编程哲学

变革派,非改良派

语言特性

  • gc
  • 丰富内置类型
  • 多返回值
  • 错误处理
  • 匿名函数与闭包
  • 类型和接口
  • gorouting
  • 反射
  • 语言交互

闪光点 - 函数多返回值 - 花括号统一 - 非侵入性接口 OOP仅接口和封装是精髓,继承就花拳绣腿?鸟会飞,麻雀是鸟,所以会飞之类的看上去头头是道的学院派例子。 - defer -- 并发相关 go chan select,语言层直接支持并发 go 简化并行运行某函数需要的各种库和继承代码 chan 类比为线程安全的blockingqueue select 即select/poll/epoll 同类产品 三个关键字大大简化并发编程心智负担

NB哄哄的作者

Ken Thompson:与Dennis Ritchie两人开发的Unix Rob Pike:Bell Labs Unix团队,Plan 9 ,UTF-8设计者 Robert Griesemer:Java的HotSpot编译器,Chrome的JS引擎V8 Russ Cox:Plan 9 Ian Taylor:GCC Brad Fitzpatrick: memcached

类型和接口

关键字沿用c struct,不沿袭超级复杂的类型系统,不支持继承和重载,只支持最基本的类型组合 不光是对OOP做减法,引入无比强大的非侵入式接口

以前实现接口前要先定义接口,类型与接口紧密绑定

type Bird struct{ } func (b *Bird) Fly(){ } 可之后定义IFly接口 type IFly interface { Fly() }

func main(){ var fly IFly=new(Bird) fly.Fly() }

工程管理

消除工程文件(makefile,pom.xml) 云风-Go 语言初步 http://blog.codingnow.com/2010/11/go_prime.html

  • mix-in 的接口风格(知乎 Mixin 是什么概念?)

以平坦的方式编写函数,没有层次。而后用 interface 把需要的功能聚合在一起。没有继承层次,只有组合功能

  • 强类型系统

使犯错误的机会大大降低。正确通过编译,几乎就没有什么bug 了。而编写程序又有点使用 lua 这种动态语言的感觉,总之,写起来很舒服

  • 内置的 string / slice 类型,以及 gc

现代编程必须的东西。手工管理未必有更高的效率,但一定有更多的出错机会

  • defer

用它来实现 RAII 比 C++ 利用栈上对象的析构函数的 trick 方案让人塌实多了 go 在语言设计上是很吝啬新的关键字的。但多出一个关键字 defer ,并用内建函数 panic / recover 来解决许多看似应该用 exception 解决的问题要漂亮的多

  • zero 初始化

C++ 的构造函数特别多余 go 把这点贯彻了,不会再有未定义的数据


发现花了四年时间锤炼自己用 C 语言构建系统的能力,试图找到一个规范,可以更好的编写软件。结果发现只是对 Go 的模仿。缺乏语言层面的支持,只能是一个拙劣的模仿

Go 有 C 的血脉,所以依然分值和对值的引用(指针类型)

和 slice 这种东西是引用类型,但却是一个值,而不是指针

以 C++ 做比,它更像是 smart_pointer 或 iterator 这种东西,语法上是值,但语义上是引用

new 用来生成 *T ,make 用来生成一个 T 对另一个 T 的引用。并绑定了新的数据,比如 slice 是对 array 的引用,并绑定了边界。不同到 slice 可以引用同一个 array ,却有不同的边界

系统级的编程语言,逃不开对实现的追究。所以我认为 new 和 make 分开是很自然的事情


为什么除了Go语言, 其他类C语言都是垃圾

Node.js单线程事件循环机制和非阻塞的编程模式让人不太满意。还有,所有的东西都要用Javascript的回调函数

说说Golang的使用心得 http://blog.jobbole.com/84554/

为什么我不喜欢Go语言式的接口(即Structural Typing) http://blog.zhaojie.me/2013/04/why-i-dont-like-go-style-interface-or-structural-typing.html

iota: Golang 中优雅的常量 https://segmentfault.com/a/1190000000656284

初入坑golang,感觉良好 http://tnt.wicast.tk/2015/05/04/golang-is-my-choice/

http://tonybai.com/

http://www.xiaozhou.net/

Read More


理解Git的工作流程 2016-01-01

Read More


TopGit 2016-01-01

Read More


一些git常用方法 2016-01-01

Read More


版本管理的发展史 2016-01-01

Read More


git权威指南 笔记 2016-01-01

git权威指南

Read More


git merge –squash介绍 2016-01-01

git merge branchName 操作方便并不意味着这样操作就是合理的 在某些情况下,应该优先选择使用--squash选项 git merge --squash branchName git commit -m "message here"

与不使用该选项的合并结果相同,但是不提交、不移动HEAD,需要一条额外的commit命令 效果相当于将branchName分支上的多个commit合并成一个,放在当前分支上,原来的commit历史则没有拿过来

判断是否使用--squash选项最根本的标准是,待合并分支上的历史是否有意义

如果在开发分支上提交非常随意,甚至写成微博体,那么一定要使用--squash选项 版本历史记录的应该是代码的发展,而不是开发者在编码时的活动

只有在开发分支上每个commit都有其独自存在的意义,并且能够编译通过的情况下(能够通过测试就更完美了),才应该选择缺省的合并方式来保留commit历史

from

Read More


使用Git的分支和合并功能来进行版本管理的开发模型 2016-01-01

git-workflows-and-tutorials

Read More


git 2016-01-01

git 文章整理

Read More


gc 2016-01-01

gc 是一种失败的内存管理模式?

Read More


flume 2016-01-01

Read More


eclipse 插件 2016-01-01

曾经用eclipse时代比较好用的一些插件,现在idea了

Read More


dubbo 2016-01-01

Read More


docker 2016-01-01

Read More


并发 2016-01-01

多进程和多线程的优缺点

协程

风格之争

Read More


chrome 2016-01-01

谷歌的开源项目Chromium,由开源社区维护 Chrome基于 Chromium,但是最重要的一点是它是闭源的!所以有这样的一种说法:谷歌把核心技术都保留在了之家的 Chrome 中 Chrome支持了一些商业的收费插件、闭源组件等,这些是不会出现在开源软件中的: H.264 、mp3 编码等

Chrome 浏览器包括 Stable 、Beta 、DEV 、Canary及Chromium 版 稳定性 Stable>Beta>DEV>Canary>Chromium 更新速度相反

Chromium

  • Google Chrome的基础,是一个开源项
  • 拥有诸多尖端优势
  • 拥有众多的版本包括Windows、Mac及Linux,几乎每天都在进行更新;
  • 该版本不稳定

Google Chrome dev

  • 以Chromium最新版本为基础
  • 每星期更新
  • 相对稳定,类似同类产品的“测试版”
  • 最新的功能和特性都有体现

Google Chrome beta

  • 基于稳定的开发版本
  • 每月更新
  • 最新的功能和特性基本定型
  • 可以正常使用,很少会出错

Google Chrome Stable

  • 基于最稳定的Google Chrome beta
  • 新功能基本固定,经过数月测试
  • 每隔几个月发布
  • 版本稳定

Read More


c++ 流派 2016-01-01

  • 经典C++流 类是核心,例程多用C Runtime的,很少用模版,一般是正统教育的结果
  • 古典C流 基本上当C用,偶尔用用对象,不使用异常,喜欢怀旧
  • MFC流 秉承MFC的风格,主要使用MFC/ATL对象和Win32 API,不喜欢STL,用很多的宏把IDE的语法提示模块折磨到崩溃
  • Portable流 以C Runtime和STL为主要工具,使用类和模版,不跨平台毋宁死
  • Functional流 以模版和STL为主要武器,大量使用函数式语言的设计方法,并号称这才是真正的C++
  • Win32流:多使用全局函数,偏爱Win32 API,但不排斥C Runtime,通常喜欢轻量级的程序,所以身材也比较苗条
  • Java流 全面使用Java的风格,不能容许任何全局成员,但允许使用STL的集合类,写很多叫Factory的类
  • COM流 喜欢AddRef()和Release(),大量使用接口,隐藏一切可以隐藏的东西,诵经的时候要把上帝替换成COM
  • 戒律流 追求完美的C++程序,计较每一个const和throw(),极力避免不安全的cast,随身一定要带一本ISO C++手册
  • 混沌流 其程序无常形,无恒道,变幻莫测,吾不知其名

  • C流 精通C,习惯了她的思想
  • C/C++流 精通C,对C++一般,但是为了项目或者其他需求,不得不实现混用。而且不爱写注释
  • MFC/C++流 使用类,几乎不用模版。大量派生!大量异常!
  • STL/C++流 大量使用范型,创建可移植!!能用crt的全部使用crt
  • DP/C++流 热爱设计模式,大量类,但都讲求自认为的精细,间或使用范型。大量注释,恨不得比代码还多,XP方法下的产物

Read More


c 2016-01-01

http://m.oschina.net/blog/368991 http://zhiwei.li/text/page/3/

http://emacslisp.com/?p=7 http://www.lofter.com/postentry?from=search&permalink=3b23a9_1358b95 http://chenyufei.info/blog/2011-03-06/wrap-c-function-using-libtcc/ http://jingpin.jikexueyuan.com/article/38895.html

Read More


books 2016-01-01

几本作者签名的书 maven实战 git权威指南 设计模式之禅 Spring 3.x 企业应用开发实战

Read More


分布式Java应用基础与实践 2016-01-01

强引用

A a=new A(); 对象主动释放引用后才被GC

软引用

JVM内存不足、或认为不经常活动时被回收,适用于缓存 -XX:SoftRefLRUPolicyMSPerMB=1000

HotSpot JVM garbage collection options cheat sheet http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html

Read More


token 2016-01-01

OpenID/OAuth

Read More