2014年 —- 变

职业上处于转型做游戏服务端的时期 感觉下来，Web服务端和游戏服务端最大的不同就是状态的维持和在线用户之间数据的共享和广播。

虽然学习了很多游戏服务端相关的知识，转型期还是有代价的，钱就不说了，web端学习到的很多知识基本就荒废了，特别是javascript相关的。
接触下来，我发现用什么语言并不是很重要了，毕竟后面的思路，算法，基本上是一样的。
书，基本没有看，但是我认为这不代表不学习，因为大部分时间都花在了学习读博客／文章／问答，写代码上了。

语言方面，没有进一步发掘Python的性能了，因为再深入，就是C了。学习了Golang，现在算是个初学者了吧。

还上线了一个"一次性邮箱" https://34nm.com 为啥叫这个奇怪的名字？
是因为@符号正好在34之前，nm正好在".“之前，就是这么简单的原因。 目前发送了451封邮件，阻止了893封，用户数166
作为一个小工具，我觉得达到了我当初100个用户的期望

同时，通过这个网站，学习到了很多TLS，加密相关的知识，SMTP指令相关的知识。
Github上记录的commit有149个，不过大部分都是给其他程序修修补补。

工具方面，换成了Mac，效率提升了不是一个档次。

今年你所完成的最重要的事情是什么？ 完了……我觉得没有 今年你所学到的最有用的是什么？ 花了3个星期学个Golang，太值当了

满分10分，你在这一年对自己的满意度有几分？

今年不及格，4分，应该花更多的时间来学习和整理知识，不能老是说各种借口的 你明年想要实现什么，要不要来个前所未有最棒的一年？
做一个手机App游戏，自娱自乐一下：）

#年终总结

要讲memoryview，就要讲它的主要应用场合—-缓冲区（buffer）
要讲buffer前就要讲讲Python的字符处理：Python中的字符是不能修改的 例如
当你需要收集从socket.recv上来的代码时，大部分的人都选择了拼接字符串

while not self.sock.closed:
data = ''
while len(data) < 1024:
d = self.sock.recv(12)
if not d: return;
data += d

殊不知，由于Python字符串的特点，这实际上是将data复制一份，然后于d进行拼接，然后再赋值给data。
当字符大小有1M左右的时候，这种复制的效率会下降10%左右（其他大小没有测试过，但是应该是字符越大，复制的效率就越低，毕竟要重新分配内存区域并填满是很费事的）
而且网络传输有个特点，就是客户端想传多大都可以，所以就会出现只传输部分数据的情况，这时，socket.recv循环次数增多，导致字符缓冲区复制的操作次数增多。
所以，对于已知缓冲区大小下，可以先分配大小的缓冲区，然后依次写入相应数据即可（不需要复制了）。 改装上面的栗子，我们假定已知缓冲区应该有1KB

buf = bytearray(1024)
mv = memoryview(buf)
i = 0
while i < 1024:
i = self.sock.recv_into(mv)
if not i: return; # remote closed
if i < 1024:
mv = mv[i:1024]
i += i

即可

使用的是Python的SSL／TLS库（反正也是用OpenSSL的）

• Ubuntu 14.10 Python 2.7.8／Gevent 1.0.1
• OpenSSl 1.0.1j
• CPU: 双核I5
• 内存：4G
• 网络：1000Mbps网卡
• 没有使用特殊的加速硬件

• 交换算法：ECDSA虐哭了RSA
• 加密算法：
  • RC4-MD5完胜其他（但是不安全），
  • DES系的性能集体阵亡
  • AES还是有不错的性能

详情就看图吧（数值越低越好）

加密传输次数增加 对于 总完成时间影响

加密数据总量增加 对于 总完成时间影响

并发数 对于 总完成时间影响

[具体数据表格在这里](https://docs.google.com/spreadsheets/d/1kvt8NOHFZR0yNhl9pUxm-
Lgn5EnHVmRBTvYQGCHTcso/edit?usp=sharing)

准备知识

• 私钥／公钥签名算法 之后要说的RSA、ECC（椭圆曲线加密算法）都是其中的一种。
• 迪菲－赫尔曼密钥交换 简写就是DH
• ECDH 椭圆曲线DH 使用椭圆曲线签名算法用来进行密钥交换
• SHA 1-N 、MD5 都是摘要算法，运算出的值进行校验
• AES DES 3DES RC4 都是加密算法，用来加密传输用的数据

所以ECDH-ECDSA-AES256-GCM-SHA384 意思是： 使用ECDH协议交换以ECDSA为加密算法的公钥，
AES256-GCM加密算法加密传输数据 SHA算法384位强度进行校验

证书制作流程

一般流程是：

1. 生成自己的私钥
2. 用私钥生成csr（Certificate Signing Request 验证签名申请）
3. 将csr提交CA（Certificate authority 验证管理局）
4. CA发回一个crt（Certificate 验证文件）
5. 将CA发回的crt和CA公开的crt进行叠加（先后顺序不能颠倒）
6. 在应用程序中设置keyfile为自己的私钥
7. 在应用程序中设置certfile为叠加后的crt文件

+-----+ +-----+
| You | | CA |
+-----+ +-----+
-------------------------------\ | |
| Generate private key and CSR |-| |
|------------------------------| | |
| |
| give CSR |
|------------>|
| | ------------\
| |-| check CSR |
| | |-----------|
| |
| give CRT |
|< ------------|
-------------------------------\ | |
| Set your CRT and private key |-| |
|------------------------------| | |
| |

自签名流程：

1. 生成自己的私钥
2. 用自己的私钥生成CA crt
3. 如果需要自签署其他csr，需要执行命令

命令cheatsheat

生成RSA私钥：

openssl genrsa -out myrsa.key 2048

解释： genrsa （generate rsa）， 2048是位数 生成ECC私钥：

openssl ecparam -name secp256k1 -genkey -noout -out myecdsa.private.key

解释： secp256k1是曲线的名称 可以用openssl ecparam -list_curves找想要的曲线 生成csr文件：

openssl req -new -sha256 -key [私钥地址] -out [想要csr的地址]

解释： sha256是之前说的摘要算法，默认的sha1已经不再安全了 生成自签名crt文件：

openssl req -new -nodes -x509 -key [私钥地址] -out [想要的crt的地址] -days [想要的天数]

自签名csr文件：

openssl x509 -req -in [CSR地址] -signkey [签署用的私钥] -out [想要的CRT地址] -days [想要的天数]

验证签名文件信息：

openssl x509 -in [CRT文件] -text -noout

对很多管理员来说,添加邮件服务无非就是安装个exim4.就能用了.殊不知,其实现代的邮件为了防止垃圾邮件,已经走得太远太远了.
搜索中文圈,压根没有相关资料,这里我就当抛砖了.

SPF

全名Sender Policy Framework，用来鉴别发送邮件的服务器或者IP，是否为该域允许的范围。
这需要在发送邮件的域名下添加一条TXT记录，举个例子： example.net. TXT "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all" v=spf1做开头为必须，spf1说明这是第一版spf协议 SPF规定有6种机制：

• ALL 匹配所有的结果，一般放在最后
• A 匹配所有该域的A记录
• MX 匹配所有该域的MX记录
• IP4 所有之后的IPv4地址，可以用mask匹配多项，比如：192.168.0.0/24
• IP6 所有之后的IPv6地址，同IPv4
• INCLUDE 去之后对应地址查找，比如INCLUDE:spf.34nm.com，就是去spf.34nm.com继续查找TXT/SPF记录

还有四种修饰符分别意义是：

• “+"：允许，默认记录都是允许
• “-"：不允许
• “~"：中立，也就是没有相关策略
• “?"：同样是中立，但是为debug

这样例子中 example.net. TXT "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all" 的意思是

DKIM

由于SPF天生只验证是否可以发信, 不保证这个发信人是验证的,因此,SPF验证通过的仍然可能是伪造的邮件. 这就需要DKIM来进一步保证这封邮件不是伪造的.
在特殊的子域名”_domainkey”(例如:_domainkey.example.com)的TXT记录中插入一对RSA密钥中的公钥,
而RSA的私钥用来加密邮件的部分字段. 收到邮件的服务器发现有DKIM-SIGNATURE字段时,会自动校验DKIM的公钥, 按照匹配程度进行处理.
这样就完成了验证.

+---------------+ +-----------------+
| SenderServer | | ReceiverServer |
+---------------+ +-----------------+
| -----------------\ |
|-| Calculate DKIM | |
| |----------------| |
| |
| Send singed mail |
|--------------------------->|
| |
| Check DKIM record |
|< ---------------------------|
| | ---------------------------\
| |-| OK, found key and verify |
| | |--------------------------|
| |

还可以在特殊子域名之上,再建立一堆域名,例如authmail._domainkey.example.com,这样在校验邮件时还可以选择不同的密钥.
协议的内容相对来说就简单很多了,只有三种值:

• v=DKIM1; 使用DKIM第一版协议
• k=rsa; 使用RSA加密
• p=长长的一段公钥

DMARC

该验证的都验证了,还有个DMARC是干吗的呢? 这是为了给域名邮件的拥有者报告垃圾邮件的状况而设定的规则.
和之前的方法一样,在_dmarc.example.com下面设定自己的DMARC规则, 具体就参考Google 提供的文档 吧.

https://support.google.com/a/answer/2466580?hl=zh-Hans&ref_topic=2759254