XX Net 1.0.3 开发笔记

1. OpenSSL

   测试Google ip时，发现OpenSSL库的连接性能比ssl库要稳定很多。
   连接成功能力高40%
   因此全部采用OpenSSL，不再用ssl

2. 连接池

   测试发现，建立跟GWS(Google Web Server)的tcp连接，如果没有传输内容，约15秒就失效了。
   如果已经ssl握手成功，这个链接可以在240秒后才失效。
   而使用过的ssl连接，如果是正常结束，还可以下次接着用，而不必再重新建连接。
   一个ssl 连接，如果要复用Reuse，所连接的host必须相同。

   一次tcp连接时间约300ms，而ssl握手需要两次TCP连接，约600ms，一次小型请求的耗时约300ms。
   所以一次正常的请求耗时需要约1.2秒。

   如果建立连接池，在需要的时候，已经有握手好的连接可以用，那么就只需要300ms，差别4倍。

   因此建立了ssl的连接池，同时更改了appid的机制：一段时间内，只使用同一个appid，直到这个appid失效。

3. 建立appid的管理

   appid有时会超出限额，限额有一天范围内的，也有短时间内的。超出限额的，先暂时剔除，等全部剔除完后，
   再重新加回来，重新开始。

4. tcp连接

   不传数据，只能存活15秒
   15秒内用户还没有点下一个网页，这些连接就失效了。
   干脆就不要连接池，只

5. ip选优策略

   每次连接tcp和ssl握手， 会向ip管理器报告耗时。如果连接失败，也会报告异常。
   tcp连接耗时大约是握手的一半，因此都折算为握手时间。

   每10秒会根据耗时重新排序。
   系统会保持最多100个可用ip，每次使用会在前5个最好的ip里随机挑选。
   保持ip多样性，避免某个ip突然失效，影响正常使用。

   如果连接失败，连接时间会增加300ms。
   这样做的原因是避免某一次连接失败，直接删除一个优质的ip。毕竟网络丢包是经常发生的事情。
   增加300ms，能够让该ip 马上排到后面去，但属于可用ip。

   下次启动时会重新检查所有ip，好的ip会重新排到前面，而差的ip就会被删除，从而去寻找更好的ip。

   为了避免在网络不好时，把辛辛苦苦找到的ip给删了，ip删除只在一个线程里，在删除前检查
   baidu.com是否能够访问，如果不能访问，说明网络不行。
   等网络恢复了，再检查一遍，如果还能连接，就会加回ip池，否则才真正删除。

6. 代码清理

   连接只有2种：直连GWS的Google服务，不需要经过GoogleAppEngine代理的。
   另一种就是基本非Google的，需要经过GoogleAppEngine进行代理中转。

   不需要经过代理中转的，就只建立一个tcp连接，后面就直接交给浏览器去握手加密和复用了。
   需要经过代理中转的，就是ssl握手，然后把请求封装好，发给appEngine

   文件名、类名、函数名都进行了重构，更容易通过名字知道其功能。

   无用的代码、无用的参数都删除了，让代码更容易理解。

7. 对于CPU性能

   暂时感觉还不是太严重，而gevent不熟悉，就没有引入。
   哪天需要了再加进来吧

8. 服务端部署

    前面说了，tcp连接没有握手，只能存活15秒。
    部署服务端的库，执行很慢，它来请求连接，到真正去握手，还需要几秒时间。如果不够
   “新鲜”的连接，就会失效，导致上传失败。
    因此，tcp 连接要给足够新鲜的，这样可以保证上传成功的概率

9. 服务端兼容

   3.2的服务端跟之前的版本不兼容。
   为了方便一些用户在新老版本之间切换，我把新、老版本的服务端都放进去了。
   这样同一个appid，就能够给新、老两个版本用了。

10. 证书问题

    某些网站，GoogleChrome对证书要求比较严格，比如".twitter.com"的证书，about.twitter.com无法使用。
    而FireFox 是正常的。
    包括Youtube也有这样的现象出现。
    而专门给about.twitter.com制作一个https证书，就OK了。

    解决方案，就是在检测到浏览器对证书拒绝时，生成一个全版的证书，再通过自动重试机制，
    让这个过程感觉不出来。