不愿意分享的原因并不一定是因为有经验的人不愿意分享，可能很多时候是分享受众的问题。
以前在公司经常给后台工程师普及 Web Server 和 数据库索引 之类的基础知识。几次之后从分享的过程来看，他们都说知道。但实际上他们根本就没明白，还是继续犯很弱的错误，也从来不会问，可能因为会显得自己很无知。
自己在面试和被面试的过程中也得出一个结论，国内企业里，99％的工程师根本就不合格。原因不在于智商，而在于心态。
大部分 Web 工程师不知道 HTTP 状态码为何物，甚至有些工程师不知道有 HTTP 头。
有过同事不知道文件可以算 md5 。
甚至连不会用 if else 的都大有人在。
很难跟这些人分享 nonblocking 服务器的设计和架构。

觉得读磁盘更快的同学，你们有没有考虑过一个问题，为什么大多数 Key/Value 数据库不是简单的把 Key 作为文件名 ，Value 作为内容按单个文件存储？

简单回答: MySQL
这个和文件系统，文件尺寸，IO 性能，服务器内存大小都有很大关系。

如果本身不是强算法类的路线，比如PhD啊，高频交易，人工智能之类的。
工程实践对你更重要。举个例子，以前和一个朋友交流垃圾邮件过滤，我们都聊到了朴素贝叶斯，
他说他们在实跌的项目上确实有用过，也用过其他一些学习算法，最后这些在大规模场合全部淘汰掉了，
最后胜出的极其简单有效，把文本中所有的英文和标点全过滤掉，再把剩下的做一次 MD5 。
人工标记垃圾信息的 MD5 值，如果 MD5 相同，就是垃圾信息。
当然能够有较强的工程思想也不容易，要看很多论文，RFC，写成吨的代码。

hashcash 必然是有效的，要不然 bitcoin 早就被攻击死了。
LS们讨论的大量IP+0000随机数的不太现实。。。
sha1 大部分语言 100K/s hash 轻轻松松的。但你不太可能有那么多 IP 地址。或者说，如果真有这么大的资源，也无所谓攻击这个地址了，静态页面都能打死了，光流量服务器都撑不住。完全不在一个讨论层次上。
小规模的单服务器网站，直接在存 session 在页面渲染出挑战值就可以。
大规模的多服务器网站，可以用 hmac(ip + timestamp) 做挑战值，验证写到 nginx 里，性能损失可以忽略。

页面上放个 Flash ?

在源代码里 UTF8/GBK 或者 BOM 或者 Line Break 出问题的，都不能算是合格程序员。
在缩进和对齐上，tab用来缩进，空格用来对齐是国际惯例，包括 Python 。这样在所有的编辑器，不管是 4 空格缩进，还是 8 空格缩进，看起来都是正常的。

对于各种射交应用，多复杂的关系不用外键都无所谓，反正错那么几百万几千万条记录也没人 care。
对于金融，电商等不用外键有点儿捉死了。
理解各种数据库的并发锁，事务的隔离级别也很重要。
一般情况下为了避免 debug 的时候太纠结，我全部使用最严格模式。
至于，触发器和存储过程，持保留意见，我写的全部应用都没有用到过。
出于两点，
一是SQL的语法有点儿诡异且不可移植。
二是不喜欢同时使用Python和SQL维护数据逻辑。

为了使 RDBMS 健壮好用我有个规则，最少功能，最大约束。

离你电脑最近的键盘，是最好的键盘。
或者
离你手最近的那把键盘，是最好的键盘。
我的HHKB放桌上吃灰，G80 买来第一天就送人了，微软进水坏了。
所以我的最好用的键盘是 MacBook Air 自带的键盘，成吨的代码都是靠它写出来的。

http://libjpeg.sourceforge.net/
http://libpng.sourceforge.net/

这两个项目应该是最知名，用得最多的图片压缩项目了。

用 PBKDF2 吧，对于非密码专业人士，最好不要自己相当然的 roll 一套机制。
多重认证也不一定安全，尤其是在密码已经泄露的时候。
GSM 短信是明文可以监听的。
二阶段认证很多人的使用是不合理的，在上一家公司做顾问的时候，review 他们的代码，他们就犯了典型的错误，在取消二次认证的时候，需要认证，但是在设置的时候不需要，如果我拿到密码，直接用 curl 提交一个新的key到他们的设置二次认证的接口上就可以了。告诉他们工程师是完全不理你的。
另外，任何加密手段，暴力破解都是有效的，除了一次一密密码本。

可以提几点来简单增加安全性，
在传输密码的接口上用 HTTPS ，最好带绿条的。
在登录接口加 rate limit ，不要只限制 IP ，要限制 ID 。
Session ID 不要用自增 int 。
服务器时间尽量准确。
生成密码摘要的 salt 要每个都不一样，如果自己 roll 的话。

进阶的可以，
敏感数据分库分权限存储，密码，信用卡号码等。
买套代理服务器IP库，限制代理访问。
上 WAF 。

@Livid 听说过一个把用无线网卡开监听模式的流量做随机数生成器。

一，如果实在想解决这个问题，中间加一层 API ，负责处理 Web Server 和 DB 的连接。
二，连接池确实能解决一定问题。
三，这跟是否自带调度器无关，而是因为 Python 有 GIL 。我现在在 C 部分的代码，即使多线程也是每个线程使用一个 event loop 。跟进程模型几乎一样的，只是节省了共享内存的部分。
四，如果你写过类似的，就会知道，像这样的产品，从开始到可用，最少需要一年的时间。
五，同上。
六，优秀的工程师必备条件之一就是不要高估自己的能力。

请楼主注意 Linux内核，GNU/Linux操作系统和Linux 发行版之间的区别。

这个问题不用太担心，
一，一般 WebServer 和 DB 都是局域网直连，网络性能损失很小，在要求不是极高的情况下，能够满足需求。
二，因为 RDBMS 的特殊性，目前一个连接并不能同时执行多个请求。所以如果使用非阻塞IO，不仅会导致前端非常复杂，并且依然会卡在一个执行时间超长的 SQL 上，除非针对每次请求创建一个 DB 连接，这样一定程度上增加了 latency 和 DB 的负荷。
三，如果用多核 CPU （现在几乎全部都是）的服务器，可以同时创建多个 Web Server 的进程，能够缓解DB阻塞的问题。
四，不建议自己实现 DB Driver ，除非你知道你在做什么。
五，自己实现协议和DB的，都是走火入魔的标志。

楼主应该是把 TCP 和 HTTP 协议搞混了。如果想只发不收，只要 server 不 send 数据就可以。
如果强制不收，可以用 shutdown 关掉连接的接收一端。详见 man 2 shutdown 。

Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SID 的不可预测性，暂且认为是安全的。这是一种认证手段。

而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让 某App 有权利访问 某用户 的信息。这里的 Token 是唯一的。不可以转移到其它 App 上，也不可以转到其它 用户 上。

转过来说 Session 。Session 只提供一种简单的认证，即有此 SID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。

所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。
如果永远只是自己的网站，自己的 App ，用什么就无所谓了。

@p8p8
https://github.com/zhicheng/storage
把里边的参数改成你的帐户的。
只写了又拍云的，其它的也是类似，对客户端透明。你说的那种需要在请求URL加验证参数，S3 可以实现，其它的就不清楚了。

@maga 这你得看阿里云OSS的文档啊。。。一般情况下都支持得吧。