简单轻巧、优雅随心
  • Chrome 处理长连接时遇到的一些问题

    星空泪 发表于 2016年01月28日 | 归类于 学习笔记 | 2010 次阅读

    最近在原有的 Webit 基础上开发了一个基于 HTTP 协议和 RESTful API 的消息推送程序。程序采用 Comet 模式实现 Server Push。

    既然是 HTTP 协议,我便写了一个简单的 Web 客户端用于测试。这里记录一下其间遇到的一些问题。

    1. 多个标签页之间的长连接相互阻塞,通过开发者工具可以看到连接在 Stalled 这一阶段等待了 20 秒。
    2. 长连接在多个标签页之间跳跃,导致消息推送混乱。

    研究一番后,明白了如下事实:

    1. 无论是否声明使用缓存,Chrome 在发起请求之前都会固执地访问缓存。我尝试添加了多个 HTTP 头声明禁止使用缓存均已失败告终。
    2. Chrome 访问缓存时会对缓存加读写锁,所以在对同一个资源发起多个请求时,后续请求会被阻塞直至锁释放或者达到 20 秒的锁超时时间。
    3. Chrome 会在多个标签页之间共享长连接,这是因为 HTTP 请求是无状态的,而共享连接可以减轻服务器负荷。

    对于第一、二个原因,可以通过在请求地址后添加随机查询参数(一般来说是时间戳)来解决。

    对于第三个问题,我写的程序虽然基于 HTTP 协议,却并是非无状态的。如果我的程序需要通过浏览器正常访 ...

    标签:HTTP , Chrome , 长连接
    没有评论
  • Linux无法产生core dump的原因

    星空泪 发表于 2016年01月07日 | 归类于 学习笔记 , 网海拾贝 | 1844 次阅读

      一、要保证存放Coredump的目录存在且进程对该目录有写权限。存放Coredump 的目录即进程的当前目录,一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动,则脚本可能会修改当前目录,这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。

      二、若程序调用了seteuid()/setegid()改变了进程的有效用户或组,则在默认情况下系统不会为这些进程生成Coredump。很多服务程序都会调用seteuid(),如MySQL,不论你用什么用户运行 mysqld_safe启动MySQL,mysqld进行的有效用户始终是msyql用户。如果你当初是以用户A运行了某个程序,但在ps里看到的这个程序的用户却是B的话,那么这些进程就是调用了seteuid了。为了能够让这些进程生成core dump,需要将/proc/sys/fs/suid_dumpable 文件的内容改为1(一般默认是0)。

      三、这个一般都知道,就是要设置足够大的C ...

    标签:linux
    没有评论
  • automake, autoconf 使用详解

    星空泪 发表于 2016年01月04日 | 归类于 网海拾贝 | 1612 次阅读

    文章转自: http://www.laruence.com/2009/11/18/1154.html

    作为Linux下的程序开发人员,大家一定都遇到过Makefile,用make命令来编译自己写的程序确实是很方便.一般情况下,大家都是手工写一个简单Makefile,如果要想写出一个符合自由软件惯例的Makefile就不那么容易了.

    在本文中,将给大家介绍如何使用autoconf和automake两个工具来帮助我们自动地生成符合自由软件惯例的 Makefile,这样就可以象常见的 GNU程序一样,只要使用”./configure”,”make”,”make instal”就可以把程序安装到Linux系统中去了.

    这将特别适合想做开放源代码软件的程序开发人员,又或如果你只是自己写些小的Toy程序,那么这个文章对你也会有很大的帮助.
     

    一.Makefile介绍

      Makefile是用于自动编译和链接的 ,一个工程有很多文件组成,每一个文件的改变都会导致工程的重新链接,但是不是 所有的文件都需要重新编译,Makefile中纪录有文件的信息,在 make时会决定在链接的时候需要重新编 ...

    标签:linux
    没有评论
  • Keep Alive 对 HTTPS 性能的巨大影响

    星空泪 发表于 2015年12月20日 | 归类于 学习笔记 | 1424 次阅读

    最近为 Webit 添加了 HTTPS 支持。为了了解 HTTPS 下的性能,我重新对 Webit 进行了测试。

    结果基本在预料之中。不过,也发现了一些其他的以往未能了解的东西。

    下面是测试结果:

    #ab -n 10000 -c 100 https://127.0.0.1:1039/

    Requests per second:    891.10 [#/sec] (mean)

    #ab -n 10000 -c 100 -k https://127.0.0.1:1039/

    Requests per second:    20710.75 [#/sec] (mean)

    性能差距居然超过了 20 倍。看来 HTTPS 在建立连接的过程中消耗的资源非常可观。如果在项目中需要使用 HTTPS,请务必使用 Keep Alive 连接。使用 HTTPS 短连接性能非常之差。

    为了确定这是真相而不是我写的程序有 bug,顺便对 nginx 做了一次测试(nginx测试在阿里云服务器上,两次测试结果不可横向比较):

    #ab -n 10000 -c 100 https://127.0.0 ...

    标签:HTTP , HTTPS , Webit
    没有评论
  • 知乎的显著缺陷:模式与目标的背离

    星空泪 发表于 2015年02月21日 | 归类于 学习笔记 | 3198 次阅读

    知乎的模式是什么?这个问题难以一言蔽之,但是其最核心的部分就是投票。无论是问题或者回答,由用户给出肯定(赞同)或者否定(没有帮助)的评价,并根据投票结果进行排序。

    知乎的目标是什么?一个最好的中文问答社区。换言之,试图让知乎回答一切问题。

    问答社区的这种运作模式在某些垂直社区运作得非常不错,例如 StackOverflow。其原因有两个:

    1. 问题往往是有标准答案的。
    2. 用户的观点相对而言是统一的。

    然而,当知乎试图使用这种模式去运作一个覆盖面更加宽广的社区时,一切都变得不同了:

    1. 问题往往是有争议的。
    2. 不同用户所持的观点往往是对立的。

    知乎试图建立非垂直社区的原因是显而易见的:更大的市场意味着看上去更大的发展潜力。人嘛,总是有一些雄心壮志的。

    但是,当投票机制作用于这样一个社区时,就不可避免地演变成了多数人的暴政

    举一个简单的例子,有人提了一个“如何评价xxx(某个人或者某种事物)”的问题。认同人数较多的正面(或者负面)评价往往会被排在最前面,而持相反观点的回答会被直接折叠隐藏。这无疑会让持相反观点的少数人感到被冒犯。

    也就是说,知乎的投票模式剥夺了少数人表达自己观点的权利。并且非常不幸的是:

    1. 大量的问题是存在争 ...
    标签:知乎
    3 条评论
  • TCP选项:TCP_NODELAY和TCP_CORK

    星空泪 发表于 2015年01月23日 | 归类于 学习笔记 , 网海拾贝 | 3520 次阅读

    Nagle算法

    根据创建者John Nagle命名。该算法用于对缓冲区内的一定数量的消息进行自动连接。该处理过程(称为Nagling),通过减少必须发送的封包的数量,提高了网络应用 程序系统的效率。Nagle算法,由Ford Aerospace And Communications Corporation Congestion Control in IP/TCPinternetworks(IETF RFC 896)(1984)定义,最初是用于缓冲Ford的私有TCP/IP网络拥塞情况,不过被广泛传播开来。

    Nagle的文档定义了一种他称之为小封包问题的解决方法。当某个应用程序每次只产生一字节的数据,就会导致网络由于这样的小封包而过载(该情况通 常被称为“发送端SB窗口并发症”),从而产生该问题。一个源自键盘的单一字符-1字节的数据-可能导致一个41字节的封包被传送,该封包包含了1字节的 有用数据和40字节的头部数据。这种4000%过载的情况,在像APRANET这样只有很轻负载的网络中是可以接受的,但在像Ford这样的负载很重的网 络中,可能强制重传,导致封包丢失,并且通过过度拥挤交换节点和 ...

    标签:TCP , Nagle
    没有评论
  • HTTP 协议缓存机制详解

    星空泪 发表于 2015年01月21日 | 归类于 学习笔记 , 网海拾贝 | 2849 次阅读

    浏览器第一次请求流程图:

    浏览器再次请求时:

    Expires策略:Expires是Web服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。不过Expires 是HTTP 1.0的东西,现在默认浏览器均默认使用HTTP 1.1,所以它的作用基本忽略。Expires 的一个缺点就是,返回的到期时间是服务器端的时间,这样存在一个问题,如果客户端的时间与服务器的时间相差很大(比如时钟不同步,或者跨时区),那么误差就很大,所以在HTTP 1.1版开始,使用Cache-Control: max-age=秒替代。

    Cache-control策略(重点关注):Cache-Control与Expires的作用一致,都是指明当前资源的有效期,控制浏览器是否直接从浏览器缓存取数据还是重新发请求到服务器取数据。只不过Cache-Control的选择更多,设置更细致,如果同时设置的话,其优先级高于Expires。Cache-Control的值可以是public、private、no-cache、no- store、no-transform、must-re ...

    标签:缓存 , HTTP
    没有评论
  • 关于使用chroot导致程序不能获取时区的问题

    星空泪 发表于 2014年11月26日 | 归类于 学习笔记 | 2770 次阅读

    之前遇到一个很奇怪的问题,就是程序更新之后所记录的日志中时间突然不对了。仔细的检查了日志文件后发现程序启动时所记录的时间是正确的 +8 时区时间,但是进入事件处理循环之后所记录的时间变成了 UTC 时间。

    经过一个无比痛苦和纠结的反复检查过程之后,终于发现问题是由于程序中新增的 chroot 调用导致的。

    chroot是在unix系统的一个操作,针对正在运作的软件进程和它的子进程,改变它外显的根目录。一个运行在这个环境下,经由chroot设置根目录的程序,它不能够对这个指定根目录之外的文件进行访问动作,不能读取,也不能更改它的内容。

    通过 chroot 并降低程序的运行时权限,能够增强程序的安全性,以降低可能出现的漏洞所造成的危害。

    chroot 之后,程序无法再访问 /etc/timezone 文件。而程序中调用的时间函数需要访问这个文件来获取时区信息。因此在调用了 chroot 之后,程序所记录的所有时间信息都变成了 UTC 时间。

    解决方法也比较简单,就是在程序中手动设置 TZ 环境变量,这样时间函数可以从环境变量当中来获取到时区信息。

    此外,在使用 chroot 的测试过程中还发 ...

    标签:linux , C
    没有评论