设计与艺术的区别

蛇头GG发来的一篇文章，值得一读：The Difference Between Art and Design。摘录一下标题：

• 艺术源于灵感，而设计源于动机。
• 艺术为人诠释，而设计为人理解。
• 艺术是一种品味，而设计则是一种主张。
• 艺术来自天赋，而设计来自技艺。
• 艺术为不同的人带来不同的信息，而设计为不同的人带来相同的信息。

一部分应用层协议放进kernel？

先把想法记下来。

• 提供一种描述语言，将应用层协议描述成DFA；
• 一个generator将DFA转换为代码；
• 用户态程序通过某种接口来向kernel请求已经协商好的该种协议的socket并由kernel直接填写一部分数据结构；
• 应用程序对socket的第一个回应有时间限制—-如果一段时间之内不回应，则系统将该socket交给下一个监听进程。

解决的问题：

另外一种DSR结构

dawnh在之前的人肉traceback中提到了 另一种DSR结构。即：

• 服务器端将虚拟IP绑在lo0上（子网掩码为/32）；—-确保服务器收包、不广播ARP；
• 负载平衡设备接Internet的网口接路由器进来的VLAN；（“VLAN-Internet”）—-从Internet进入的包发到负载均衡设备上；
• 负载平衡设备的内网网口能够到达服务器；（“VLAN-Incoming”）—-负载均衡设备将请求根据负载均衡的条件路由到VLAN-Incoming上的服务器；
• 路由器提供一个绑定某一内网网址，且能联通服务器的接口；（“VLAN-Outgoing”）—-服务器回应包发到VLAN-Outgoing上的Internet路由器；
• 服务器默认网关设为路由器的内网地址。

（此VLAN划分是出于性能方面的考虑，不划分VLAN并不会导致整个系统不能用）。

改一行代码带来的性能改进

FreeBSD先前的vesa framebuffer驱动有个问题，就是滚屏的时候会比较慢。jkim大长辈于是改了一行代码。

好吧，我承认我之前一直以为是console驱动想要锁&Giant的问题。其实真正的原因是默认的pmap_mapdev并不做写合并，所以应该呼叫更低阶的pmap_mapdev_attr并传入PAT_WRITE_COMBINING参数。

解释一下DSR结构中服务器IP地址的配置

因为有人在我前一篇blog《使用DSR模式实现单IP服务冗余》里提了个问题，这里解释一下。

DSR比较常见的两种配置，一种是我之前文章中提到的禁止外网网卡ARP的方法，另一种是把虚拟IP绑定到lo0上。这两种方法各自有一些优缺点。一般来说，我喜欢用前一种方法。

概率趣题

今天在 Matrix67 的 blog 上看到这么一道题：

一个人有两个小孩儿，其中有一个生于星期二的男孩儿。问另一个是男孩儿的概率是多少？

答案当然不是1/2或者1/4，因为我们已经知道了有一个是生于星期二的男孩，因此这是一个条件概率问题。

ZFS实现快速部署（作弊条）

FreeBSD从8.0开始支持从ZFS引导系统，因此，可以使用ZFS的快照功能来实现快速部署。

新机器使用LiveFS启动，Fix it，CDROM。

SYNCookie反制

最近看到一个很有意思的攻击。记一笔。

针对 SYN Flood 攻击（特点是攻击者发出大量 SYN 请求，但并不完成 TCP 握手），目前操作系统会采用 SYNcookie 予以反制。FreeBSD上的实现是在系统资源充足的时候采用标准的握手机制，而当发现存在可能的攻击（即可用的 TCP 状态资源不足时）应用 SYNcookie；SYNcookie是将TCP状态建立推迟到三次握手 之后，具体做法是将服务器本地的一个秘密数据与来源/目的IP、端口编码来形成序号来发出SYN+ACK，并在收到对方回应ACK时验证这个序号的真实性。

使用DSR模式实现单IP服务冗余

FreeBSD支持以DSR（Direct Server Return，即服务器直接将流量通过路由器返回，而不经过负载平衡设备；俗称"单臂模式"）模式提供服务。为了改善服务的可用性，可以使用这种方法来配置服务器。这种方法非常适合于大并发、大流量的环境。

DNS和MX的冗余

一般来说DNS和MX都需要做冗余。前者的冗余和容灾要求要高于后者。

DNS的冗余通常需要做到跨ISP，甚至跨大洲。由于安全和性能方面的理由，提供权威DNS解析的服务器都不应同时作为缓存DNS服务器；此外，实践上权威DNS服务器应该是受保护的管理服务器的slave，而不应直接在权威DNS服务器上操作（读、写分开），这样可以有效减少由于修改操作所导致的downtime。

• ← 上一页
• 下一页 →