qyb的博客

一台老服务器上的 send(, , ,MSG_MORE) bug

上次研究完 HAProxy,觉得这东西搭配 Postfix 挺好,就安排给运维了,结果运维同学反馈,加持了 HAProxy 以后,返回 220 欢迎信息时间显著变长,于是昨天就抽时间和运维一起分析这个事儿

我的第一反应是 Postfix 处理 Proxy Protocol 有延时,比如反向DNS查询什么的,于是首先在 Postfix 服务器上执行 tcpdump

观察到,当客户端连接 HAProxy 之后,立即 HAProxy 就和 Postfix 完成了3WHS,然后足足等了 3 秒,才从 HAProxy 发来了 "PROXY X.X.X.X XXXX"

现在可确认延时发生在 HAProxy 上,接着去 HAProxy 机器上 strace -tt HAProxy进程

观察到,当完成和后台 Postfix 的 3WHS 之后,的确就立即把 "PROXY X.X.X.X ... "发送了,但是等了3秒,才recvfrom后面的 220

问题出在哪里呢??仔细看传送"PROXY X.X.X.X ..."的系统调用,原来是用的 send() syscall,而且,它使用了 MSG_MORE 这个参数... (不明白什么是 TCP_CORK 的同学可自行搜索,HAProxy 在这里使用 MSG_MORE 是很有道理的)

但为什么这个延时长达3秒实在理解不能,在我自己的机器上试了一下,是200ms,查看 sysctl 里面的 tcp 设置也没有头绪,对于这种古老的RHEL4服务器只能出大招了:因为这个HAProxy是为SMTP代理专用的,直接修改HAProxy源码,把MSG_MORE注释变成0就一切正常了

Topic: 技术

从搜狐的技术评级所想到的

下午和KCN领导聊天的时候随口提到这个事情,不完全是吐槽

总之,目前搜狐的技术委员会评出的3.1,比某度的某些T5还要靠谱一些。这个给业务在某些程度上造成了困扰,希望这个制度能越来越好,并且技术委员会能在2014年发挥除了考核之外,更大的作用

以当下的苛刻要求而言,在业务部门而不是研发部门的,年过30的同学,想在这条道路上精进到4.x,是一件很困难的事情——除非你做出一个牛逼的平台产品出来

目前搜狐技术委员会的标准,是:针对一个互联网服务需要的各项技术要求,你能带来什么价值

我严肃的思索了一下,当初我从eyou跳槽来搜狐的话,3.1或许能符合要求,3.2是绝对达不到标准的(应聘运维可能还能有4.x的机会)

所以,就只能和BAT竞争毕业生了,同时要给很好的机会,很好的导师,很好的环境,来帮助其成长

附:我自己觉得自己在技术上做得比较得意的事情

  1. 拿到了天大路由器的登录和enable口令
  2. eyou.com 的日历,把"事件"用一个链表数据结构很好的表示并存在硬盘上
  3. eyou MTA 第一版
  4. 写了一个 bridge,以及 SMP 下的各种坑
  5. 2004年,就建了一对很棒的前端CSS + JS组合
  6. eyou的编译脚本和安装脚本
  7. DV工具
  8. 搜狐通行证,Nginx Module + JS 我一个人全包
  9. web.py 的大工程
还有就是最近两个偶尔在具体事情上动动头脑动动手,还是能做一点点事情

最遗憾的事情,是进搜狐后,对运维的认识不够,很久很久以后,才形成认识和方法;否则很多事情能做得更好

Topic: 技术

Contatta, 一个"Collaborative Email"产品

企业电子邮件的未来到底是被一个新工具替代?还是邮件的自我进化?Contatta 是后面这条道路的一种尝试

注意到这个公司首先是看到了它制作的一个专题,觉得设计挺用心。于是好奇去网站上看了一眼,Demo 还算吸引人;最有意思的还是三个创始人完全没有计算机工程背景——2名销售+1名设计师,这种完全不符合一般认知的团队,很期待能给市场带来新的活力。

它制作的专题见下:
Contatta takes a look at the real cost of email for business
Courtesy of: Contatta

团队介绍文案

我们是一个致力于用云计算技术改变现有企业IT模式的团队,希望您能认可这个技术趋势,让我们一起为改变世界而努力。当前我们专注于企业基础办公领域,提供SaaS模式的企业邮箱 产品,以及围绕邮箱的扩展增值服务。

我们在服务器端使用的主要的开发语言是 Python,技术工作包括:
  1. 提供可靠的邮件传输服务。保障跨多个网络运营商的邮件顺畅传输,在外发和接收两个方向上均进行严格的垃圾邮件发送识别,以避免资源被滥用。
  2. 提供POP、IMAP、SMTP等邮箱访问服务。尤其是基于浏览器的,以收件箱和联系人为核心,方便用户进行办公协同的 WebMail 系统;我们也在计划移动设备上的相应方案;这是我们整个"big story"的核心。
  3. 为我们日常运营支撑而提供的一系列管理和运维平台;以及同客户自身的业务集成等的系列开发工作。
  4. 技术的挑战是,应对复杂的IDC和网络环境,如何构建出,并运维好一套分布式高可用的系统。电子邮件是现代企业办公的最最最基础组件,用户无法容忍哪怕是非常短暂的服务不可用, 这给我们的技术工作带来了诸多要求和限制条件,亦是艰苦工作背后的乐趣和价值体现。

    Topic: 电子邮件

关于 Proxy Protocol

在生产环境中,Load Balancer 相当重要。常见硬件有 F5,软件有 LVS,或者更偏应用层的 HAProxy。

但实际运用中,怎么把 source ip/port 传递给后端的 real server 是一个大问题。因为realserver通常是需要这些信息用来记日志,或者安全防护策略应用之类。。。

如果是 F5,需要 real server 把自己的 default gateway 指向过去;如果是 LVS/HAProxy 也类似,需要LB服务器打开 TPROXY 内核选项,同时 realserver 有网段的限制。

上述的方案虽然透明,但是对网络结构有特殊要求,所以后来 HAProxy 的作者提出了 Proxy Protocol

现在至少 Postfix 2.10,甚至 Haraka 都能支持这个协议了。

HAProxy 很值得尝试

渠道还是直销?

上周日,经纬的熊飞凑了一群做SaaS toB业务的老板们喝茶。

神州鹰的叶总对自己产品很有信心,他们不用直销,号称3000家渠道,按照他的说法,直接找老板上门演示,都不用介绍产品功能,老板自己就能琢磨出这个工具能给日常管理带来哪些变化

北森的纪总则必须依赖直销。因为他们的产品比较复杂,必须了解客户的需求后,才能告诉客户哪些模块是他所需要的。最终还是要走到解决方案的路上,他最后这么说。销售必须理解客户的痛点,否则说服不了客户。

====

采取什么样的营销模式,和产品性质息息相关,也是商业模式中的重要组成部分。周教主所说的产品模式、用户模式、推广模式、收入模式是一环环紧密相连的。

Topic: 商业

一句话blog

回想最近3年,最大的心得是要首先做好团队定位和人员盘点,然后才是运营KPI的正确制定和执行

Topic: 商业

中国企业网盘(EFSS)市场有多大?

已知2012年,Box的收入是8500w美元。

从2013年底它还能拿到100M的融资看,2013年的财务表现应该也很亮眼,以至于投资人认为还有更广阔的市场需要资源投入。假定Box在2013年收入是2亿美元吧。

进一步假定全球公有EFSS服务在2013年的总收入是4亿美元。

假定中国是全球的1/100,那么理论上应该是400w美元,大约2400w人民币。。。

从理论上,够快在拿到红杉投资时宣布2013年要达到收入1000w人民币是有道理的.

实际上,我得说我对搜狐企业网盘2013年的表现很不满意。2014年继续努力!

Topic: 商业

气质问题

前不久有很精辟的一句话,如果产品免费那么实际上用户即产品。

诚然,捜狐就是一个这样销售"注意力"的公司。

对于工具而言,强调的是顺手好用,而不是让工具吸引注意力。所以不受重视乃在情理之中。

好在尚有几个销售"信任"的领域,还有赖于个人邮箱服务的经营。

Topic: 商业
订阅 RSS - qyb的博客