2015年08月_芦笛

12月 11月 10月 09月 08月 04月 03月 02月 01月

原创 http Cache-Control: If-None-Match ETag/If-Modifed-Since Last-Modified

这里最终决定采用chunked是为了和长连接[3]配合使用, 省去slow-start ack/congestion window增加到正常大小的时间，还有3次握手时间（究竟是多少毫秒？）对原先代码的改造，逻辑上从上到下分层为file: >0 -- ok, 0 -- eof, -1 -- err, -11 -- eagain.prepare: 0 -- ok, 0 -- sta

2015-08-26 20:01:10 746

原创 http: 支持 Content-Encoding: gzip

curl -v --compressed http://localhost:8080/upload/a.out -o a.out请求:Accept-Encoding: gzip, deflate响应：Content-Encoding: gzipgzip -9c xx.txt > xx.gz开头是标记0x1f,0x8b，然后0x08表示使用deflate，前10个字节

2015-08-24 19:42:21 2959

原创 http:关于长连接和分块传输

动态生成的内容比如压缩流，动态网页+js hide，事先并不知道Content-Length, 为了提高响应速度，希望一边生成一边传输，通常以关闭连接表明内容传完完毕。但是希望连接keep-alive呢？解决办法是chunked transfer encoding，RFC规范要求如果是http/1.1，服务端和客户端都必须支持。例子：HTTP/1.1 200 OK\r\nT

2015-08-23 19:17:54 3185

原创 https实现的几个问题

官方推荐是TLS_server_method，我当前的系统ubuntu14.04，最新的只有SSLv23，但是抓包发现是TLSv1.2，文档只说了TLSv1，难道被ubuntu私下改了，只是头文件和文档没有更新？有人说accept之后,要在set non block之前调SSL_accept，否则会影响握手消息收发？任何一个SSL网络操作不管读写都可能产生 SSL_ERROR_WA

2015-08-22 20:15:26 2535

原创 http 206 Range -- 端点续传(resumed download) -- POST/PUT/DELETE

端点续传(resumed download):请求:Range: bytes=16-响应:HTTP/1.1 206 Partial ContentAccept-Ranges: bytesContent-Range: bytes 16-14385736/14385737Content-Length: 14385721Request -- Response* no

2015-08-16 09:50:20 2449

原创精确覆盖问题的dancing links 技术

精确覆盖一类的问题，难点在于01矩阵的构造。一旦构造好，就可以用下面的dancing links 技术快速有效地求解。构造思路：每个物体所有可能的摆放方式 --行不重复地覆盖所有格子 -- 目标列约束条件，或者单个选择的唯一表示 -- 列把可能的选择，包括已知的选择 --行比如对于数独问题[2]:(1)81个格子中每个格子只能放一个数字C1-81(2)每一行的数字不

2015-08-09 09:30:09 879

原创跳表(SkipList) -- 基于概率的平衡二叉树

从搜索的资料来看，重复的关键字让人感觉有一点不安，逻辑上的和空间消耗上的，于是找一些其他相关是否有改进的。deterministic skip list, 2-3-4tree的翻版，top-down方式维护平衡，感觉还是走的老路，且连续三者取中来提升，局部性不好，对concurrent不友好。又重新仔细读了一遍Pugh原文，"A level i node has i

2015-08-07 21:17:18 1059