简单地说，GFW升级设置了。这次应该是覆盖了203.208.45/46/47.*中的所有IP（其中45段全部被设IP黑洞），并且针对443端口采
用了特殊的屏蔽手段。体现为IP或许可以ping通，但telnet
443端口大部分情况下超时（不是连接重置）。而80端口则畅通无阻，但可想而知所有的非加密HTTP数据包肯定都会接受GFW的关键词过滤等内容审查，
随之而来的就是小黑屋。
少数时候有HTTPS包可以漏过（低于5%），多次尝试telnet发现偶尔可以建立连接。在开启了SPDY的Chrome上体现为页面很难刷开，但一旦
刷开则该站点就此畅通。应该是因为SPDY的长连接会话机制保障了后续不会有握手包，从而避免了被干扰所致。这从某个侧面也反映了这次的封锁技术是以监视
并干扰SYN/ACK包为主，并不针对所有类型的数据包（估计忙不过来）。
猜测可能是之前Tor项目组检测到的GFW新研制的HTTPS探测技术（或 者是某种类似的技术）投入了使用。（估计）其原理在于发现HTTPS（443端口）的SYN包之后，GFW自身也发HTTPS连接请求去探测该端口可能会 返回什么内容。一旦审查到内容有害，就干扰TCP握手过程，丢弃匹配地址组的SYN/ACK包。并且从测试的表现看来似乎有小黑屋效应，也就是说之后一段 时间都会无法连通443端口，但休息一阵子后第一次连接的成功率很高。
目前看来这个手段的效果还不错，虽然还有漏网之鱼，但至少可以消磨掉绝大部分人的耐性，并让决意翻墙者苦不堪言。但HTTPS探测需要与服务器建立真实有 效的SSL连接，还要处理加解密相关事宜。对于以全体压制为原则的GFW设备而言，计算资源（主要是CPU）的耗用可能会相当大。这一方面可以说明为什么 会有漏网之鱼，另一方面也解释了为什么会有小黑屋机制作辅助。可以预言这种手段短期内还不会投入日常使用，更多可能出现在特殊时期临时高压维稳。
总之，这几个IP段在18大期间很可能会被咬住不放，不过分赃大会之后应该会松口。但一旦该手段被启用，目前通过hosts+HTTPS翻墙的人，应对措施应该只有换别的IP，要不就得耐心点，多刷刷页面了。
真心祈祷大家不要再公布可用的IP地址了，公布一些就少一些啊！
下午开会去了，回来（16时）发现这些IP段已恢复到之前的状况。目前估计有以下的可能：
1.HTTPS探测功能需要GFW去干一些很费CPU的事情，相关人员发现撑不住，最后还是放弃了。
2.为了关键那几天能顶上用场，在搞演习，测试效果.
猜测可能是之前Tor项目组检测到的GFW新研制的HTTPS探测技术（或 者是某种类似的技术）投入了使用。（估计）其原理在于发现HTTPS（443端口）的SYN包之后，GFW自身也发HTTPS连接请求去探测该端口可能会 返回什么内容。一旦审查到内容有害，就干扰TCP握手过程，丢弃匹配地址组的SYN/ACK包。并且从测试的表现看来似乎有小黑屋效应，也就是说之后一段 时间都会无法连通443端口，但休息一阵子后第一次连接的成功率很高。
目前看来这个手段的效果还不错，虽然还有漏网之鱼，但至少可以消磨掉绝大部分人的耐性，并让决意翻墙者苦不堪言。但HTTPS探测需要与服务器建立真实有 效的SSL连接，还要处理加解密相关事宜。对于以全体压制为原则的GFW设备而言，计算资源（主要是CPU）的耗用可能会相当大。这一方面可以说明为什么 会有漏网之鱼，另一方面也解释了为什么会有小黑屋机制作辅助。可以预言这种手段短期内还不会投入日常使用，更多可能出现在特殊时期临时高压维稳。
总之，这几个IP段在18大期间很可能会被咬住不放，不过分赃大会之后应该会松口。但一旦该手段被启用，目前通过hosts+HTTPS翻墙的人，应对措施应该只有换别的IP，要不就得耐心点，多刷刷页面了。
真心祈祷大家不要再公布可用的IP地址了，公布一些就少一些啊！
下午开会去了，回来（16时）发现这些IP段已恢复到之前的状况。目前估计有以下的可能：
1.HTTPS探测功能需要GFW去干一些很费CPU的事情，相关人员发现撑不住，最后还是放弃了。
2.为了关键那几天能顶上用场，在搞演习，测试效果.