终于知道chrome老是不发起连接的原因了

最近发现chrome经常出现一种古怪的情况，就是打开一个URL的时候一直等待，但实际上连connect都没干。而且此时打开其它任何URL都是这样。而同时如果使用隐身模式打开URL就正常。今天终于（貌似）找到了答案：

http://code.google.com/p/chromium/issues/detail?id=12066

“Previously, we had a limit of 6 connections per proxy server, which was horrifically low.
Connections to all endpoint hosts remains at 6.
Basically, we have a map of socket pools, keyed by the proxy server.
Each of these proxy socket pools has a socket limit of 15 and a connection limit per host of 6.
The main TCP socket pool (non-proxied) has the standard 256 socket limit, and connection limit per host of 6.
There are two maps currently, one for HTTP proxies and one for SOCKS proxies.
Note that SSL tunnels over HTTP CONNECTs are still located within the standard http proxy socket pools.
We depend on the fact that our code never returns a non-SSL connected socket to the pool for a |connection_group|
that is to a HTTPS endpoint.  A newly connected socket from the pool will only have the TCP connection done.  An
idle socket will have both the TCP and the HTTP CONNECT and the SSL handshake done for it.”

也就是说，chrome最多同时只有256个socket连接（不是半开socket，是已经建立的socket），同时（一个tab中？）连接同一个主机的socket不能超过6个。但假如使用代理（http或者sock都一样）的话，同时存在的socket就只有15个——到了现在的15.0版是32个，看about:net-internals就知道了。

哦顺便隐身模式和正常模式是使用独立的网络层实例的相互不会影响。所以通常窗口SB了的时候还是可以用隐身模式的窗口发起连接……

能像FF那样调整吗？google又一次充分表现了老大哥作风：不能！爱用用不用滚！

所以我真的只能滚到FF那边了么！中国的网络……全部socket都跑代理也一点不奇怪啊！！（摔

于是从今天起当一个坚定的狗黑！（摔max

———————————-12.1追加————————————

其实自作孽又不好好做功课不能怪别人：privoxy一早就有报告这个问题，并且因此把本地的keep-alive时间设置成5秒，强调只有确认浏览器能支持多连接的时候才设置到较大的值。而我是自己手贱把它设置成了120的（死

素晴らしき日々~不連続存在 全通

一句话感想：莫装逼，装逼被雷劈。

……不好意思，以上なし，重新来。

一句话感想：莫装逼，装逼被雷劈。

…………………………

 

总之我始终对炒概念的剧本不太感冒。虽然剧本本身还算是挺圆满的，但除了老掉牙的存在主义思辨和认识论，严格来说反复地从不同视点描写同一个过程也算是一种炒概念吧。如果能把情节的张力一直维持到结束那也不错，可惜悬念揭开得又有点太早了。所以过了第三章之后感觉上吸引力就陡然下降（还好有由歧姐在撑场面）。

另外这剧本炒概念还有一点炒得让我很不满的地方，就是虽然到处地捏维特根斯坦，却没能在“语言”这个维特根斯坦的关键命题上去下点功夫。光是那点老掉牙的认识论命题，你扯出维特根斯坦来干嘛啊。

当然不管怎么说，剧本写得的确是很不错的。特别是前三章对狂气的内心活动的细致描写；对黑暗毫不修饰的大胆叙述，对不同视角的相互照应。如果能把后面几章砍掉，必要的内容融合到前三章的话，作为一个典型的现代风格小说去混个把奖回来也不是不可能。

于是感想就这样了……哦还有是第一二章的气氛营造很不错，一个人三更半夜地推的时候把我瘆得够呛……

哦对了剧透和情节讨论什么的欢迎访问黄油界的学术泰斗——卡乃教授的文章：http://bangumi.tv/blog/766，评论中还有多个好用的链接。

好久没做过饭了

我现在已经是工作日100%外食而休日外食也快到50%了——人只要一堕落那就是没救的。

就算是做饭，也难得正经的吃米饭。区区5公斤的米我已经吃了4个月，现在看来再吃4个月也没问题。但愿不要长虫了（跪

总之这是上星期做的饭：海鲜意大利面和清蒸茄子。都是超简单的菜式。

清蒸茄子：茄子切成段直接蒸熟，加上适量酱油，然后烧热油，里面放碎蒜炸到略变色的时候淋到茄子上即可。

阿垃垃圾后宫记的全时间线

到囮物语为止，阿垃垃圾的高中时代的幸福（？）后宫生活的全貌终于完整了，所以蛋疼一下记下来。

PS：狂气的黑化的抚子好萌！

————宇宙大爆炸的起始线————

20万年前：现代人类出现（啥！！？）

500年前：kissshot出生（啥……）

若干年前：八九寺真宵被车撞死变成永远的1x岁（我不是萝莉控所以不记得到底是多大）<———-（你tmd快给我正经一点！）

————阿垃垃圾升上高三的春假的分隔线————

3月25日下午：阿垃垃圾看到了羽川裙底（白色）并且被搭讪
3月26日凌晨到4月7日：阿垃垃圾变成了吸血鬼然后又变成了半吸血鬼

成就：

• 羽川的整套下着；
• 忍野忍加入了后宫！

————以上是《伤物语》的内容————

黄金周：阿垃垃圾被班长玩得死去活来！

成就：羽川翼加入了后宫！

————以上是《猫物语·黑》的内容————

5月8日到5月9日：阿垃垃圾接住了体重只有5公斤的战场原大人

成就：战场原大人加入了后宫！

————以上是《化物语·一》的内容————

母亲节（5月14日）：阿垃垃圾遇到了迷路的蜗牛

成就：

• 阿垃垃圾证实他是犯罪等级的萝莉控
• 战场原大人升级为正宫！！！
• 八九寺真宵加入了后宫！

————以上是《化物语·二》的内容————

五月底：阿垃垃圾被恶魔追杀

成就：

• 阿垃垃圾看到了战场原大人的裙底
• 阿垃垃圾损失了一辆山地车
• 神原骏河加入了后宫！

————以上是《化物语·三》的内容————

6月11日：阿垃垃圾受忍野咩咩之托前往北白蛇神社。
（此时诈欺师贝木泥舟从四月开始已经在镇上活动了相当长的时间）

成就：

• 千石抚子加入了后宫！

————以上是《化物语·四》的内容————

6月13日：阿垃垃圾和战场原大人最初的约会
6月14日：阿垃垃圾又一次被班长玩得死去活来！！

成就：

• 战场原大人升级为超·正宫！！！
• 忍野忍升级为正宫。现在可以和她做这样的事和那样的事（？？！！）了！
• 给羽川翼发了一张好人卡！

————以上是《化物语·五》的内容————

————以上是《化物语》的内容————

7月29日：阿垃垃圾去了抚子家中。在离开后，去了神原家中，并在门口见到了贝木泥舟。
7月29日下午：阿垃垃圾被战场原大人监禁了！同时阿良良木火怜和贝木泥舟对决。
7月30日：阿垃垃圾阻止了火怜向贝木再度挑战的尝试。
7月30日傍晚：战场原大人和贝木对决，将贝木赶出了镇子。

成就：

• 从羽川翼处得到了“可以尽情摸胸部”券（但被扔掉了）
• 和羽川翼缔结了“如果升学考一次及格就可以舔眼球”的约定（从“舔眼球”和“舔眼球之外身体任何柔软的部分”中选择的）
• 阿垃垃圾证实他是死刑犯罪等级的妹控
• 阿良良木火怜加入了后宫！

————以上是《伪物语·上》的内容————

8月14日：阿良良木月火被影缝余弦袭击
8月14日晚：阿垃垃圾和影缝余弦对决

成就：

• 和火怜发生了禁断的行为
• 夺取了月火的初吻
• 阿良良木月火加入了后宫！

————以上是《伪物语·下》的内容————

8月20日（暑假最后一天）：阿垃垃圾和忍在北白蛇神社进行了时间跳跃

————以上是《倾物语》的内容————

8月21日：羽川家被烧

8月22日：学习塾的废墟被烧

8月23日深夜：阿垃垃圾从未知的大冒险中归来

————以上是《猫物语·白》的内容————

————以上时间很可能也是《鬼物语》的内容————

10月31日：抚子在上学时看到了蛇的幻影

————以上是《囮物语》的内容————

翌年毕业典礼：阿垃垃圾和扶子对决

————以上很可能是《恋物语》的内容————

翌年新学期：神原遇到了沼地蜡花

————以上是《花物语》的内容————

再来一些笔记

        最近折腾出一个私有协议来给某些可能被特别关照的协议做额外的包装，因此顺便地也关注了一下店长之前提到的基于流量特征来检测特定协议的技术。然后留点阅读笔记和感想在这里好了。当然我不是CS出身所以各种胡说八道请大力地拍。

        如果流量检测技术能发展完善并被大规模使用的话，对抗上的难度将比现在又要大得多。对私有协议而言，我们可以很容易地抹掉其所承载的协议上已知的指纹。然而如果仅止于此的话，私有协议很可能仍然保有所承载的协议的流量特征而被检出。了解可能的技术并有针对性地采取措施应该是有益的。在上述这篇文献中，对流量监测使用的是机器学习的方案，在训练中使用的数据集来自于对流量的一系列统计信息，数据主要来自于对数据包的大小和数据包间隔时间的统计项，包括最大/最小值，平均值和标准偏差，其中双向的数据包是分别统计的。

        因此如果要考虑对抗流量监测的策略，我们也可以从这些被用于训练的数据集着手。从理论上说，最简单的方案就是在私有协议的流量中增加冗余的数据包，并限制最大传输速率，从而把流量抹成直线。不过在实际应用中这必然不太现实，至少不是非常经济的方案。我的想法是，冗余数据包可以被加入，但相对于实际流量应该有一个限度，通过有限的额外带宽（或性能牺牲）就能达到改变流量特征而躲避检测的效果。不过，我实际上对机器学习一无所知，或者即使知道，也并不能预测我们的流量将遭到什么样的算法来检查，因而也不能知道怎么改变流量特征才是有效的。另一个要考虑的因素是，参考文献中研究的是对特定协议（SSH）的识别，而当我们的协议实际上是作为数据隧道用于承载其它流量时，它的流量特征相对来说很可能是复杂的，并且应当接近于数据隧道上所承载的流量的特征。例如，它很可能是混合了HTTP和其它一些协议的流量特征的混合。（不过，恰恰是这种“混合”，很可能反而会构成一类新的特征而被检出。）总之我能做的，也就是对于参考文献中提及的用于学习的数据集中的各项，泛泛地讨论一下可能采取的做法而已了。

        对隧道协议来说，数据包大小的特征很可能比数据包间间隔时间的特征更为重要。因为隧道协议可以承载任何流量，因此上层应用的改变就可以随便地改变数据包包间间隔。（例如持续地发送icmp包。）而在数据包的大小上，包大小的最小值应当比最大值更可能成为特征。因为不管是TCP还是UDP，包的最大值都是有上限的（MTU）而且很容易就能达到。当然，如果一个协议所发送的数据包极少超过MTU，则也可能成为一个显著的特征。而从这一点很自然地可以构想一个逆向的策略，也就是人为地限制的数据包的大小，从而造成一个虚假的特征。如果这一方案有效地话，则甚至不需要付出额外的带宽代价而仅仅是损失性能；考虑到当前多数数据隧道的实际状况，这样的性能损失并不会造成很严重的后果。不过在实现上，因为涉及了对数据包的直接控制，稍微有点复杂。

        可见要对抗基于数据包特征的流量检测，对小数据包的处理很可能成为关键。如果我们的目的是用私有协议来承载其它协议，为了不直接介入所承载的协议，我们是不能采用将小数据包合并成大包再发送这样的方式来阻止小数据包的出现的。能采取的办法只能是将小数据包加上多余的字节扩大。这也是我写协议时采用的策略。当采取这种策略时，基于数据包大小的其他统计值自然也相应地变化：平均值增大，标准偏差减少。但如果只是按一定比例来增大每个数据包的话，通过检查平均值/标准差和最小值的相关性，说不定仍然能被识别（除非将每个数据包都塞到和MTU一样大）。所以我在实现中还随机地挑选一部分“小”（当前的判据是小于平均值的一半）的数据包，在已经增加的长度上再增加一定的字节来消除这种相关。

        上述的策略当然只是些粗糙的个人想法罢了。而且因为没有测试的可能也不知道到底有没有实际效果。我最后提及的一点是，连接开始的用于握手和加密协商等部分的流量可能是特征最强的，甚至不用统计的方法都能被检测到。所以对这部分流量应该要重点处理（我现在做的是通过socket接收到的最初的100次数据统统增加到相同的大小再发送）。

         要说的基本上就这么多。当然，没有任何证据表明敌人已经，或者在未来打算采用这样的封锁策略。他们做的事情很可能更简单，更无懈可击。比如这样，或者这样，或者干脆这样。对百分一的可能尽百分一百的力量，我只不过是再次为这句悲壮的老话多写了一个注脚而已。

一些笔记（续）

关于模式B：这两天在家里连续观察到由于模式B而导致到VPS的IP被封锁的状况，因此模式B的存在也基本可以确定了。

关于模式B的一些特征：

1. 在启动VPN时，不管TCP还是UDP模式都会出现。
2. 激发的间隔时间较长，都在数小时的量级。每次封锁，从30秒到10分钟不等，有逐步拉长的趋势。今晚观察到的封锁时间基本都在10分钟左右。
3. 每次激发后仅封锁一次，解开之后，再触发的时间从不到半小时到数小时不等。今晚观察到的封锁开始时间分别是：
21:51; 22:25;23:28-23:38
（VPN是从14点左右启动的，在前两次封锁中，未能记录到每次封锁准确的结束时间，但从印象上判断，都在10分钟的量级。）
4. 在封锁时，同C段的IP都被封锁，但同B段（不同C段）的不受影响。
5. 封锁是针对源-目标IP对进行的，也就是说在封锁进行时，从其他源IP出发仍然能访问到目标IP。
6. （有待验证）被封锁时，同C段但不是目标IP最先被取消封锁，目标IP在同C段IP被取消封锁后仍然持续一段时间。

tr到目标IP所在C段的部分路由如下：

目标IP：

6    83 ms    88 ms    71 ms  119.253.0.6
7    17 ms    23 ms    10 ms  218.12.255.193
8    25 ms    31 ms    34 ms  202.99.160.209
9    15 ms    14 ms    17 ms  219.158.8.141
10    57 ms    57 ms    50 ms  219.158.4.150 （封锁时在此开始丢包）
11   239 ms   239 ms   237 ms  144.228.44.181

目标IP-1：

6    16 ms    30 ms    11 ms  119.253.0.6
7    11 ms     8 ms    19 ms  218.12.255.193
8    22 ms    17 ms    16 ms  202.99.160.57
9    30 ms    24 ms    22 ms  219.158.96.105
10    65 ms    61 ms    78 ms  219.158.4.174
11   231 ms   233 ms   224 ms  144.228.110.97

目标IP+1：

6    16 ms    30 ms    11 ms  119.253.0.6
7    11 ms     8 ms    19 ms  218.12.255.193
8    22 ms    17 ms    16 ms  202.99.160.57
9    30 ms    24 ms    22 ms  219.158.96.105
10    65 ms    61 ms    78 ms  219.158.4.174   （封锁时在此开始丢包）
11   231 ms   233 ms   224 ms  144.228.110.97

下一步的目标是继续观察这一封锁到底是由vpn或者长连接激发的还是随机进行的。

想法

中国是一个每时每刻都验证着“逆水行舟不进则退”这句话的地方。基于SSH和VPN的单点方案用了好几年，如果再不发展就快要被赶上了。

下一代的方案，我想，至少应该是这样：

1 多个分布式的远程接入点。客户端可以轮流使用或随地地访问这些接入点。

2 按需连接，避免基于连接，流量记录等手段的检测。必要时，也许可以加入能发送多余流量进行混淆的模块。

3 可加载自定义的混淆器模块，并能方便地在两端部署，实现大量的私有协议，避免深度包过滤。

基本上，就是把已有的一些软件的实现方法和私人配置的VPS结合在一起。完成了这样一个框架的话，大概又能撑上几年的时间吧。

洪水越来越高，方舟上能坐的人也越来越少。一个小软件拯救众生的时代已经过去；个人单打独斗解救自己的模式也渐渐受到威胁。下一步大概是数人合作的地下小集团变成主流了。从现在开始，直到所有的数据包都被路由器丢掉的那一刻，你，准备好了吗？

花物语

以下是无节操地剧透的咆哮体读后感。

为什么突然就跑到一年之后了啊！主角跑的跑毕业的毕业都没人了啊！！整本书都是神原一个在话痨啊！！！

而且还没有工口发言啊！ドキドキ的百合场面总共也只有不到三页啊！！谁你妹的要看你各种阴暗内省啊！！！

1/3的篇幅都是第二主角的自述啊！而且干巴巴完全没有味道啊！！别说工口了连工都没有啊！！！和这货有关的篇幅笑点基本为零啊！！！！

连阿拉垃圾都都只出场了不到20页啊！虽然更变态了但说话没超过30句啊！！战场原大人才说了两句话啊！！！还你妹的是垃圾转述啊！！！！

阿拉垃圾开你妹的黄色甲壳虫啊！羽川去你大爷的战争地带NGO啊！！这整本书都去你妈的什么后日谈啊！！！！！！！！

总之西尾这回完全就是把一个名为“后记”的东西硬撑到270页丢出来骗钱。

一些笔记

家里的小区宽带连续两天出现了国外网全面中断现象。中国在路由器级别部署了某种新的装置已经是不争的事实。现在的问题只是这种装置在何种情况下会起作用，以及使用何种方式工作。

我常用的网络环境有两个，也就是家中和工作时候的网络，分别属于不同的ISP，但都是小区宽带。目前已经在这两个网络中均观察到出国连接被crackdown的现象，并呈现出两种完全不同的工作方式。

模式A：在家中的网络连续两天被观察到。每次持续2小时左右，第一次是在5月16日下午4点到6点左右，第二次是在5月17日22：45开始，到18日0:57止。在第二次crackdown的过程中，更多网络状况信息被进一步探测到，并将在下面详述。

模式A的特点：

• crackdown进行时，可以推测所有到国外IP的连接均遭到阻断。（访问的IP样本有三个，包括gnu.org和两个IP地址从来没有公开过的VPS）
• 阻断发生在骨干路由器上。表现为任何数据包均被丢弃。
• 无法判断和我本人的网络行为是否存在关联性。（crackdown开始前和结束后，我都正常地使用并且只使用OpenVPN，及其它到国外网站的http访问，没有受到任何其它干扰。在5月17日22:45前，我的openvpn[TCP模式]已经正常连接了4小时以上）而且，小区宽带的出口IP是多人共用的。
• 在crackdown进行中，到国内IP的访问一切正常。

以下是在5月17日22:45到18日0:57之间观察到的一些详细数据：

• 国外IP被阻断的时间分布：在22：45到0:30之间，我没有使用计算机，机器除了openvpn和其它后台的网络访问（包括至少一个对twitter的访问）外没有任何用户网络行为。从openvpn的访问日志中可以看到，openvpn在22:45第一次提示连接超时，之后自动重试重新连接，到0：30时，有多次重新连接成功之后又提示连接超时的经历，如下表：

<提示连接超时的时间  -   提示连接成功的时间>

22:45 – 22:55
23:01 – 23:14
23:17 – 23:25
23:27 – 23:27
23:30 – 23:32
23:52 – 23:52

从上述数据可见，crackdown是逐步加强的，这和周日时观察到的情况（已经没有具体数据，仅凭印象）相符合。第一次出国IP阻断持续了10分钟，之后网络有6分钟左右恢复正常，然后再次被阻断13分钟，恢复3分钟；如此到23:52后，已经无法建立有效的openvpn连接。不过，我在0:30左右之后可以观察到（ping结果），出国IP仍然会有偶发的可以访问到的情况，但持续非常短，一般不超过20秒（接收到少于20个ping数据包）

• 在crackdown时的路由情况和正常时对比，以及从VPS反向tr

目标1：到gnu.org

2     5 ms     1 ms     3 ms  119.255.18.185
3     5 ms     5 ms     4 ms  10.1.35.1
4     4 ms     3 ms     4 ms  10.1.55.1
5     1 ms     2 ms     2 ms  203.86.64.117
6     3 ms     2 ms     2 ms  119.253.0.22
7    33 ms    32 ms    31 ms  219.142.5.181
8    55 ms    56 ms    57 ms  219.141.147.1
9    61 ms    61 ms    60 ms  118.84.3.13
10     *        *        *     请求超时。

目标2：阻断时

1     1 ms     1 ms     2 ms  182.18.29.9
2     3 ms     2 ms     3 ms  182.18.29.9
3     2 ms     2 ms     2 ms  123.124.18.209
4     2 ms     1 ms     2 ms  124.65.56.73
5     2 ms     3 ms     3 ms  124.65.58.73
6     3 ms     3 ms     2 ms  61.148.152.37
7     3 ms     3 ms     5 ms  202.96.12.177 (ChinaUnicom)
8     *        *        *     请求超时。

目标2：阻断时反向tr

traceroute to 182.18.29.12 (182.18.29.12), 30 hops max, 40 byte packets
（前略）
5  69.22.142.125  13.694 ms  13.694 ms  13.690 ms
6  69.22.143.118  8.941 ms  8.777 ms  8.773 ms
7  69.22.153.146  254.783 ms  254.645 ms  254.641 ms
8  219.158.29.221  235.723 ms  233.921 ms  233.941 ms
9  * * *
10  * * *

目标2：正常时（18日0：57之后）

1     *        *        *     请求超时。
2     5 ms     1 ms     1 ms  119.255.18.185
3     4 ms     2 ms     3 ms  10.1.35.1
4     3 ms     2 ms     3 ms  10.1.55.37
5     3 ms     3 ms     3 ms  203.86.64.98
6     4 ms     3 ms     5 ms  119.253.0.6
7     6 ms     7 ms     7 ms  218.12.255.193
8    24 ms    23 ms    23 ms  202.99.160.209 (Unicom)
9    15 ms    11 ms    15 ms  219.158.7.13
10    11 ms    10 ms    15 ms  219.158.4.150
11   181 ms   180 ms   183 ms  144.228.44.181
12   178 ms   177 ms   175 ms  144.228.111.22
13   185 ms   184 ms   210 ms  89.149.184.149

（下略）

目标2：正常时反向tr

traceroute to 182.18.29.12 (182.18.29.12), 30 hops max, 40 byte packets
（前略）

5  69.22.142.125  8.625 ms  8.629 ms  8.624 ms
6  69.22.143.118  23.956 ms  23.629 ms  23.624 ms
7  69.22.153.146  219.328 ms  219.333 ms  219.325 ms
8  219.158.29.221  198.513 ms  198.694 ms  198.702 ms BB (Unicom)
9  219.158.5.133  199.619 ms  198.524 ms  198.519 ms  BB (Unicom)
10  219.158.4.77  193.028 ms  192.642 ms  192.598 ms
11  123.126.0.210  192.694 ms  193.280 ms  193.192 ms
12  202.106.228.14  194.329 ms  193.804 ms  194.255 ms
13  61.148.152.146  193.089 ms  193.182 ms  193.100 ms
14  202.106.200.2  193.100 ms  193.092 ms  192.999 ms
15  61.50.135.42  193.323 ms  193.459 ms  194.055 ms
16  182.18.29.12  194.683 ms  194.736 ms  194.550 ms

目标3：阻断时：

1     *        *        *     请求超时。
2     2 ms     2 ms     1 ms  119.255.18.185
3     4 ms     3 ms     6 ms  10.1.35.1
4     3 ms     1 ms     2 ms  10.1.55.37
5     3 ms     3 ms     4 ms  119.253.0.77
6    10 ms    32 ms     9 ms  219.142.5.181
7    55 ms    58 ms    52 ms  219.141.147.1
8    55 ms    52 ms    52 ms  118.84.3.13
9     *        *        *     请求超时。
10     *        *        *     请求超时。

目标3：阻断时反向tr

1  199.58.186.197  0.038 ms  0.015 ms  0.013 ms
2  206.220.172.109  0.607 ms  0.611 ms  0.645 ms
3  206.220.173.25  0.582 ms  0.626 ms  0.754 ms
4  173.241.130.53  0.484 ms  0.496 ms  0.486 ms
5  89.149.186.185  160.824 ms 89.149.182.69  64.332 ms  64.345 ms
6  77.67.79.150  120.834 ms  120.552 ms  120.503 ms
7  219.158.30.41  281.441 ms  280.558 ms  280.513 ms
8  219.158.4.249  309.694 ms  309.643 ms  309.653 ms
9  219.158.23.9  336.488 ms  336.451 ms  336.575 ms
10  202.96.12.30  311.670 ms  312.242 ms  311.527 ms
11  202.106.228.14  307.554 ms  307.524 ms  308.070 ms
12  61.148.152.146  313.934 ms  316.911 ms  316.545 ms
13  202.106.200.58  310.915 ms 202.106.200.2  311.125 ms 202.106.200.58  310.423 ms
14  61.50.135.42  308.939 ms  308.484 ms  308.203 ms
15  * * *
16  * * *

目标3：正常时

1     *        *        *     请求超时。
2     3 ms     1 ms     1 ms  119.255.18.185
3     4 ms     2 ms     3 ms  10.1.35.1
4     1 ms     1 ms     1 ms  10.1.55.37
5     4 ms     3 ms     2 ms  119.253.0.77
6    11 ms    33 ms    33 ms  219.142.5.181
7    33 ms    32 ms    34 ms  219.141.147.1
8    40 ms    41 ms    43 ms  118.84.3.13    CHINANET BACKBONE NETWORK (Telecom)
9    32 ms    34 ms    33 ms  202.97.53.82   CIINANET BB (Telecom)
10    37 ms    37 ms    40 ms  202.97.53.242
11   220 ms   216 ms   217 ms  202.97.51.158
12   224 ms   221 ms   225 ms  202.97.49.118
13   237 ms   234 ms   229 ms  218.30.54.174
14   253 ms   253 ms   285 ms  64.125.31.194
15   274 ms   282 ms   298 ms  64.125.30.49
16   288 ms   285 ms   288 ms  64.125.31.49
17   437 ms   411 ms     *     64.124.202.214
18   360 ms   314 ms   460 ms  206.220.172.5
19   262 ms   259 ms   259 ms  206.220.172.2
20   262 ms   259 ms   259 ms  66.71.255.10
（下略）

目标3：正常时反向tr

traceroute to 182.18.29.12 (182.18.29.12), 30 hops max, 40 byte packets
1  199.58.186.197  0.042 ms  0.013 ms  0.012 ms
2  206.220.172.109  0.957 ms  0.949 ms  0.940 ms
3  206.220.173.25  0.930 ms  0.923 ms  1.318 ms
4  173.241.130.53  0.810 ms  0.818 ms  0.810 ms
5  89.149.182.69  64.306 ms  64.258 ms 89.149.184.150  90.759 ms
6  77.67.79.150  64.264 ms  64.195 ms  64.164 ms
7  219.158.30.41  257.707 ms  257.572 ms  257.547 ms   (China Unicom)
8  219.158.4.249  303.486 ms  303.491 ms  303.481 ms
9  219.158.23.9  330.597 ms  330.550 ms  330.551 ms
10  202.96.12.30  306.057 ms  307.519 ms  306.883 ms
11  202.106.228.14  302.398 ms  302.397 ms  312.051 ms
12  61.148.152.146  309.273 ms  311.116 ms  310.961 ms
13  202.106.200.2  305.947 ms 61.148.148.70  304.553 ms 61.148.148.6  334.239 ms
14  61.50.135.42  303.356 ms  302.953 ms  303.037 ms
15  * * *
16  * * *

从以上数据可以得到如下结论：

• 阻断的路由同时存在于联通和电信。
• 可以看到到目标2的路由（联通出口）在恢复到正常状态后发生了改变，但目标3（电信出口）则没有。
• 有趣的是，在联通骨干网上，阻断时到目标2的访问和反向数据包均被丢弃（目标2数据），而在电信骨干网上，阻断时仅丢弃了到目标3的数据包，反向数据仍然可以发送。

以上是模式A的情形。

模式B：5月17日在工作场所的网络被观察到，持续2小时左右。

模式B的特点：

• 仅仅到openvpn服务器的IP被阻断，其他出国IP正常，（测试样本同上，另外增加了一个和openvpn同B段的IP）。基本可以判断和本人的网络行为存在关联性。（使用了TCP模式的openvpn）
• 阻断发生在骨干路由器上。表现为任何数据包均被丢弃。
• 从5月17日15:00到18:00，观察到的阻断发生了2次，每次服务器IP被阻断1分钟左右，之后恢复正常。阻断分别发生于15:26和16：34。

由于阻断时间比较短，没有得到更多的网络数据，有待进一步观察。

第一次做油炸食物

用电磁炉来油炸食物的你伤不起啊！！！！！

然后结果如图左边的那样orz……

花掉了超过150毫升的油，炸完的油不知道该怎么办，除了拿一点来炒了黑椒牛柳和意大利面之外剩下的都装纸杯里丢掉了…………