参考了这篇文章 ，其中netns是docker在用的方法，配置比较复杂，比较简单的方法是创建专门的group，在iptable增加针对group的限制。 # 新增一个组 groupadd no-lan # 验证下组 sg no-lan id # 阻止no-lan这个组对10.0.0.0/8的访问 iptables -I OUTPUT 1 -m owner --gid-owner no-lan -d 10.0.0.0/8 -j DROP sg no-lan 'ping 10.0.0.1' sg no-lan 'ping 114.114.114.114' sg no-lan 'python your-script.py'
这个文章时2016年组内分享时写的，在此做个备份 常见web应用的部署 Title: uwsgi应用(django) nginx->uwsgi: uwsgi_pass（uwsgi-protol） uwsgi->django: call django->uwsgi: resp Title: 代理方式(tornado) nginx->app: proxy_pass(http) app->nginx: resp(http) 应用内生成缓存指令 api要有缓存，要根据api的具体情况定制缓存策略，下面给一种简单的缓存架构 ...
这个文档时2015年左右调研capnproto时的记录，在这里做个备份 capnproto是google protobuf的开发人员离开google后创建的一个新的数据序列化项目，优点就是编码解码速度非常块，cloudflare使用它用来做日志消息的打包，因此我们对它进行了测试。使用没有问题，只是由于capnproto打包的消息要比采用纯文本的方式大2~3倍，而我们的格式比较固定，最终还是采用了纯文本消息的形式，没有用capnproto。 ...
这个文档是2013年时写的一个api设计的考虑，内容可能已经不适合现在了，仅在这里做个备份 如何设计一个API服务 认证 api key url中附加一个key /api/posts/?key=aasd2323423asdfasdf 应用场景： google map api 简单的s -> s认证 缺点： key容易泄漏 不可靠，不适合做强认证 api签名 用双方都知道的密钥对api参数进行签名，可以防止参数伪造,如 http://shot.test.com/api/thumb/?blur=0&client=test&sign=0881307c9f1e440f05e4cc58075c9485&size=L&url=http%3A%2F%2Fwww.douban.com ...
2014年左右，在组内做分享时写的一个文档，最近翻出来了，在这里记录下 variable num = 42 str = ‘hello’ is_ok = false t = {key1 = 'value1', key2 = false} u = {['@!#'] = 'qbert', [{}] = 1729, [6.28] = 'tau'} print(u[6.28]) -- prints "tau" for key, val in pairs(u) do print(key, val) end v = {'value1', 'value2', 1.21, 'gigawatts'} for i = 1, #v do print(v[i]) end function fib(n) if n < 2 then return 1 end return fib(n - 2) + fib(n - 1) end flow control if ...
2023年，重新注册了域名，把之前的博客文章迁移到了hugo，重新整理了下，也没有多少内容。 然后把电脑上的一些历史的markdown文件，觉得还有保存价值的，也加了进来。 整理了下目录结构，把历史的文件按年存放，今年写的都会放到posts/2023目录下。这样也方便查找。 ...
今天读了篇论文Cookies Lack Integrity: Real-World Implications，里面有涉及到CDN相关的，提到了我们的服务，我就分析了下。 CDN服务商一般给客户提供一个专用域名，每个客户一个独立的子域名，子域名供不同的客户使用，假设某cdn服务商使用cname.cdn-site.com的不同子域名给不同客户提供服务： ...
我不会擅长玩游戏，从小就是。 同龄人童年时玩红白机，马里奥、双截龙之类的，我没有玩过。 大学时，同学们中见流行魔兽、红警、CS，我也没玩过，我晕3D，CS画面看着就会头晕。 工作之后很多年，手游开始流行，有一段时间同事们都在玩海岛奇兵，也玩了几个月，后来就放弃了，觉得玩法单一，也就是消磨下碎片时间。 ...
2019年了，上一篇blog是4年前。 发现每到一年开始的时候，就会想要不要重新把博客写起来，但是一直没能坚持下来。 现在的博客是用markdown写的，用pelican生成静态文件，所以操作会稍微有点麻烦，但是很方便归档管理，后果就是一直不写，但是写的东西一直都没丢，8年前到现在的blog都一直还在，今天还把历史的文章的格式整理下。 ...
都已经8012年了啊！！！