$ traceroute6 www.amazon.com
traceroute6: `www-amazon-com.customer.fastly.net' has multiple addresses; using `2606:2cc0::374'
traceroute6 to www-amazon-com.customer.fastly.net (2606:2cc0::374) from 2600:1f18:400c:b800:bdf1:6584:1971:4efe, 64 hops max, 12 byte packets
1 2620:107:4000:2210:8000:0:f405:667 58.911 ms # 244.5.102.7
2620:107:4000:2210:8000:0:3ec:3e71 0.831 ms
2620:107:4000:2210:8000:0:3ec:3e73 0.808 ms
2 2620:107:4000:a792::f000:3841 0.419 ms # 240.0.56.65
2620:107:4000:a792::f000:3843 0.473 ms
2620:107:4000:a792::f000:3842 0.4 ms
3 2620:107:4000:cfff::f20c:2b01 17.258 ms # 242.12.43.1
2620:107:4000:cfff::f20c:2b81 12.562 ms
2620:107:4000:cfff::f200:e353 2.026 ms
4 2620:107:4000:c5c0::f3fd:1 1429.46 ms 1299.83 ms
2620:107:4000:c5c0::f3fd:3 1368.37 ms
5 2620:107:4000:cfff::f202:d4c3 2.15 ms
2620:107:4000:cfff::f202:d545 1.931 ms
2620:107:4000:cfff::f202:d445 1.358 ms
6 2620:107:4000:8001::24 2.469 ms
2620:107:4000:8001::44 10.271 ms
2620:107:4000:8001::24 1.16 ms
[...]
$
总之,我想你明白我要说的是什么了:我们被告知,IANA 将 IP 空间分配给地区注册管理机构,他们进一步管理分配的网络块。一些早期采用者从 Jon Postel(最初的 IANA)那里得到了一份特别的礼物:他们自己的 /8。
在区域注册表级别,可用的 IP 空间没有均匀分配。如果我们去掉保留的 IP 空间(总共 35 /8,包括 E 类、组播和选定的其他网络块),只查看分配给不同区域互联网注册机构 (RIR) 的实际可用 IP 地址,那么我们会发现 ARIN 管理着超过 50% 的 IPv4 IP 空间,而 AFRINIC 只管理着 2.7%。相比之下,IPv6 地址空间的分配要均匀得多:
当然,当我们用完 IP 地址时,网络块被重新分配和重新分配,在区域注册表之间转移,公司开始交易网络块,如果你有一个备用的 /9 左右,这被证明是一个非常好的快速赚钱方式。
但观察到的 AS 频率是一个因素。如果我们统计给定 CIDR 的 IP 地址并按 AS 映射这些地址,则会出现不同的视图:
换句话说,我们发现自己是触摸大象的盲人之一——我们从不同的侧面得到不同的观点,却没有真正得到完整的视角。尝试将 AS 编号和网络名称组合在一起并手动将它们与实体相关联,我得出了拥有最多 IP 地址的顶级组织的粗略分布,这些地址占所有 IP 空间的很大一部分,并且至少在一定程度上回答了我们最初的问题。前十名(无论如何,按这个计数计算)是:
美国国防部(352M 个 IP 地址,占所有 IPv4 地址的 8.19%)
亚马逊(181M,4.21%)
中国电信 (112M, 2.61%)
AT&T (111M, 2.59%)
Verizon (101M,2.35%)
康卡斯特 (71M, 1.64%)
Lumen Technologies (65M, 1.52%)
Microsoft(59M,1.37%)
软银 (48M, 1.1%)
韩国电信 (46M, 1.08%)
这里需要指出的一点(除了 DoD 是一个明显的异类)是只有两家公司不是电信提供商:Amazon 和 Microsoft。所有其他公司实际上是 ISP 和 Telco。
RFC3986,即“Uniform Resource Identifier (URI):Generic Syntax”,是一个 Internet Standard。 Request for Comments (RFC) 系列是著名的档案式文档系列,该系列构成了 Internet Engineering Task Force (IETF) 标准过程的主干。 在数以千计的 RFC 中,只有很少的部分,比如 TCP (RFC793) 以及 Internet Mail 格式 (RFC821) 和协议 (RFC822), 提高了整个 Internet Standard 的发展水平。 RFC3986 在 2005 年 1 月也提高了这个水平。
按照 URI 标准,上面的第一个例子 —— http://www.cisco.com/en/US/partners/index.html —— 实际上是一个 URI,并且它由以下几个组成部分:
方案名 (http)
域名 (www.cisco.com)
路径 (/en/US/partners/index.html)
IETF 达成共识,共同管理该方案。Official IANA Registry of URI Schemes(请参阅 参考资料)中包括一些大家所熟悉的方案,如 http、 https 和 mailto,还有其他许多您可能熟悉或不熟悉的方案。
URI 路径像一个典型的文件路径名。URI 按照 UNIX® 的惯例采用了正下划线 (a/b/c),因为在 20 世纪 80 年代后期设计 URI 的时候, 在 Internet 上, UNIX 文化比 PC 文化更流行。正是那个时候,出现了几个用于访问远程文件的流行表示法。其中一个是 Ange-ftp, 它是用来编辑远程文件的 emacs 的一个扩展。它用路径名将主机名和用户名结合起来,以获取像/jbrown@freddie.ucla.edu:~mblack/这样的结果。为了跨机器进行命名,为 Web 开发的 URI 语法(按照非标准的 Apollo Domain UNIX)使用了双下划线符号,但是它也引入了方案语法,这样,来自许多不同协议的命名约定得到了统一。其中的一些例子有:
因为它将不会按照您期望的那样工作,除非您真的 想 在 XSLT 样式表之后引用 exslt.org 目录中的一个文件。XSLT 的 href 属性采用了一个 URI 引用,它可能是绝对引用,也可能是相对引用。以一个方案和一个冒号开始的 URI 引用是绝对引用;否则,该引用就是相对引用。相对的 URI 引用更像一个文件路径。例如,../noarch/config.xsd 也是一个相对的 URI 引用。
国际化的资源标志符
HTML 中的 href 属性采用了 URI 引用,这样讲有些过于简单。URI 和 URI 引用都是从有限的 ASCII 字符集合中得出的,并且 HTML 比它们更加国际化。事实上,对遵循 RFC3986 的注释的请求是符合 RFC3987 标准,即 Internationalized Resource Identifiers (IRI) 标准(请参阅 参考资料)。此规范在 IETF 标准化过程中没有它的前辈走的远,但是技术本身已是相当成熟,并被广泛部署。除了能够使用所有 Unicode 字符,而不是仅仅能够使用 ASCII 字符之外,IRI 和 URI 是完全一样的。像 URI一样,每个 IRI 都有一个相应的编码,以防需要在只接受 URI 的协议(比如 HTTP)中使用 IRI。
用 xml:base 重写基本 URI
通常, URI 引用与在哪种文档中发现它有关。如果使用基本 URI http://exslt.org/math/min/math.min.template.xsl 查看一个文档,并看到了一个 URI 引用 ../../random/random.xml,那么引用将扩展为 http://exslt.org/random/random.xml。在 HTML 中,您可以把一个 base 元素放在文档顶端来重写基本 URI。XML Base 规范(请参阅 参考资料)在 XML 中也提供了同样的功能。
对于 Internet 主机,名称和位置都有单独的标准。主机名和域名有相同的语法(例如,zork1.example.edu)。这些主机名通过 Domain Name System (DNS) 协议和类似 192.168.300.21 的地址相连。当主机改变了在网络中的位置或重新编号之后,这种间接的做法允许主机保留其名称。
Web 中偶尔中断的链接使 Web 地址从外观上看更像是一个位置,而不是一个名称,并且在 IEIF 社区中也出现了不同的观点:
URI:RFC1630,发布于 1994 年 6 月,被称为“Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web”(请参阅 参考资料)。它是一个Informational RFC —— 也就是说,它没有获得社区的任何认可。
URL:RFC1738,发布于 1994 年 12 月, 被称为“Uniform Resource Locators”(请参阅 参考资料)。它是一个 Proposed Standard —— 也就是说,它是一个共识过程的结果,虽然它还没有经过测试,并成熟到足以成为一个完整的 Internet Standard。
The allocation of Internet Protocol version 4 (IPv4) address space to various registries is listed
here. Originally, all the IPv4 address spaces was managed directly by the IANA. Later parts of the
address space were allocated to various other registries to manage for particular purposes or
regional areas of the world. RFC 1466 [RFC1466] documents most of these allocations.
Indicates the status of address blocks as follows:
RESERVED: designated by the IETF for specific non-global-unicast purposes as noted.
LEGACY: allocated by the central Internet Registry (IR) prior to the Regional Internet Registries
(RIRs). This address space is now administered by individual RIRs as noted, including maintenance
of WHOIS Directory and reverse DNS records. Assignments from these blocks are distributed globally
on a regional basis.
ALLOCATED: delegated entirely to specific RIR as indicated.
UNALLOCATED: not yet allocated or reserved.
192.0.2.0/24 reserved for TEST-NET-1 [RFC5737].
Complete registration details for 192.0.2.0/24 are found in [IANA registry iana-ipv4-special-registry].
192.88.99.0/24 reserved for 6to4 Relay Anycast [RFC3068]
Complete registration details for 192.88.99.0/24 are found in [IANA registry iana-ipv4-special-registry].
192.88.99.2/32 reserved for 6a44 Relay Anycast [RFC6751] (possibly collocated with 6to4 Relay
at 192.88.99.1/32 - see [RFC3068] section 2.4)
192.168.0.0/16 reserved for Private-Use Networks [RFC1918].
Complete registration details for 192.168.0.0/16 are found in [IANA registry iana-ipv4-special-registry].
The IETF has reserved the address block of 192.0.0.0/24 for use for
special purposes relating to protocol assignments. This registry
contains the current assignments made by the IETF from this address
block.
Address prefixes listed in the Special Purpose Address Registry are
not guaranteed routability in any particular local or global context.
[1] Several protocols have been granted exceptions to this rule. For
examples, see [RFC4379] and [RFC5884].
[2] Not useable unless by virtue of a more specific reservation.