100.64.0.0/10 运营商级NAT(Carrier-grade NAT)共享地址空间

运营商级NAT(Carrier-grade NAT)是一种缓解IPv4地址枯竭的技术手段,通过使用特定的私有地址空间(如100.64.0.0/10)实现共享公网IP地址的目的。本文详细介绍了其工作原理、必要性和潜在问题。

运营商级NAT(Carrier-grade NAT)

  运营商级(Carrier-grade)NAT,是用于缓解是IPV4地址枯竭的一种方法,通过这种方法,原来被分配公网ip的端点、家庭网络等可以被分配一个私有的ip地址,共享一个地址池。
  以家庭网络为例,最初IPV4地址充足的时候,运营商可以分配给每个家庭一个公网ip,每个家庭使用NAT共享此ip(也可以不使用);而随着接入的家庭增多,为了防止运营商手中的地址消耗过快,不再分给每个家庭一个公网ip,因此就采用在家庭网络之上再架设一层NAT,让这些家庭共享一个地址池的方法来缓解压力。而这个运营商级别的NAT使用的预留地址空间,显然不能跟用户使用的预留地址空间冲突,所以只能再选取另一段地址作为运营商级NAT的地址空间,也就是[RFC6598]中记录分配的地址空间,这段地址叫Shared Address Space。ARIN根据此分配的需要将空间返还给IANA。分配的地址块为100.64.0.0/10
  这是近些年的改动,因此很多教科书中的预留地址中并没有介绍这个地址,事实上预留的地址还有很多,可以自己查阅文档:|

为什么要用新的地址空间:

  最初[RFC1918]分配了三个地址空间作为预留ip地址,供私有网络作为内网ip使用,其分布如下:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

  因为ISP用户的私有网络(例如家庭网络)常用的地址空间就是RFC1918分配的地址空间,因此ISP如果想在用户的NAT之上再架设NAT,就只能用另一块地址空间来作为私有地址,不能与用户使用的地址空间冲突。
  如果一个ISP部署一个大范围的NAT,并且使用[RFC1918]分配的地址空间(即我们最为熟知的那三个预留地址空间),会发生什么?试想一下一个路由器/NAT内外侧存在相同的ip地址 :P

CGN的害处

  其害处与一般NAT都是类似的,比如损害端到端原则,无法架设服务器等等,见一般教科书即可。另外,这样一个NAT显然会使得追踪ip地址变得困难,因为个人的私有ip地址对应公用地址池中的一个地址的一个端口,显然,如果不记录地址翻译,将很难追踪一个ip地址的行为。
  显然这种方法也只是缓解IPV4地址不够用的情况,并不能从根本上解决地址枯竭的问题。

参考资料:
https://en.wikipedia.org/wiki/Carrier-grade_NAT
https://tools.ietf.org/html/rfc1918
https://tools.ietf.org/html/rfc6598

Filesystem 1K-blocks Used Available Use% Mounted on /dev/block/dm-17 755432 755432 0 100% / tmpfs 3873464 2512 3870952 1% /dev tmpfs 3873464 28 3873436 1% /mnt /dev/block/dm-24 2060120 2060120 0 100% /mnt/vendor/my_product /dev/block/dm-25 16 16 0 100% /mnt/vendor/my_engineering /dev/block/dm-26 4 4 0 100% /mnt/vendor/my_company /dev/block/dm-27 4 4 0 100% /mnt/vendor/my_carrier /dev/block/dm-28 83296 83296 0 100% /mnt/vendor/my_region /dev/block/dm-29 4 4 0 100% /mnt/vendor/my_heytap /dev/block/dm-30 2283532 2283532 0 100% /mnt/vendor/my_stock /dev/block/dm-31 1578456 1578456 0 100% /mnt/vendor/my_preload /dev/block/dm-32 4 4 0 100% /mnt/vendor/my_bigball /dev/block/dm-33 380 380 0 100% /mnt/vendor/my_manifest /dev/block/mmcblk0p96 229344 10036 219308 5% /mnt/vendor/oplusreserve /dev/block/mmcblk0p51 59376 204 59172 1% /metadata /dev/block/dm-18 1227872 1227872 0 100% /system_ext /dev/block/dm-19 7920 7920 0 100% /product overlay-overlay 83296 83296 0 100% /product/app overlay-overlay 83296 83296 0 100% /product/priv-app overlay-overlay 83296 83296 0 100% /product/lib64 overlay-overlay 83296 83296 0 100% /product/lib overlay-overlay 2060120 2060120 0 100% /product/overlay overlay 2060120 2060120 0 100% /product/etc/permissions overlay 2060120 2060120 0 100% /product/framework /dev/block/dm-20 353816 353816 0 100% /vendor /dev/block/dm-21 80884 80640 244 100% /vendor_dlkm /dev/block/dm-22 308 304 4 99% /system_dlkm /dev/block/dm-23 1026360 1026360 0 100% /odm tmpfs 3873464 32 3873432 1% /apex tmpfs 3873464 4 3873460 1% /bootstrap-apex tmpfs 3873464 944 3872520 1% /linkerconfig /dev/block/loop3 45936 45908 28 100% /bootstrap-apex/com.android.vndk.v33@1 /dev/block/loop1 788 756 32 96% /bootstrap-apex/com.android.tzdata@351400020 /dev/block/loop2 11712 11668 44 100% /bootstrap-apex/com.android.runtime@1 /dev/block/loop0 38592 38564 28 100% /bootstrap-apex/com.android.i18n@1 tmpfs 3873464 0 3873464 0% /tmp /dev/block/mmcblk0p50 27632 2300 25332 9% /mnt/vendor/persist /dev/block/mmcblk0p31 184240 129808 54432 71% /vendor/firmware_mnt /dev/block/mmcblk0p33 28116 16716 11400 60% /vendor/dsp /dev/block/mmcblk0p41 65488 944 64544 2% /vendor/bt_firmware /dev/block/dm-71 228570232 5218344 223351888 3% /data /dev/block/loop4 4404 4372 32 100% /mnt/opex/com.oplus.CustCore@15000029 overlay 4404 4372 32 100% /system_ext/framework/oplusex/com.oplus.CustCore /dev/block/loop5 30144 30116 28 100% /mnt/opex/com.oplus.NetworkAssistSys@15002030 overlay 30144 30116 28 100% /system_ext/framework/oplusex/com.oplus.NetworkAssistSys /dev/block/loop6 320 288 32 90% /mnt/opex/com.oplus.fancyIconLoader@1000000 overlay 320 288 32 90% /system_ext/framework/oplusex/com.oplus.fancyIconLoader /dev/block/loop7 912 884 28 97% /mnt/opex/com.oplus.moduleservices@15000014 overlay 912 884 28 97% /system_ext/framework/oplusex/com.oplus.moduleservices overlay 912 884 28 97% /system_ext/lib64/oplusex/com.oplus.moduleservices /dev/block/loop8 9252 9220 32 100% /mnt/opex/com.oplus.odmf@15002008 overlay 9252 9220 32 100% /system_ext/framework/oplusex/com.oplus.odmf overlay 9252 9220 32 100% /system_ext/lib64/oplusex/com.oplus.odmf tmpfs 3873464 0 3873464 0% /data_mirror /dev/block/loop9 45936 45908 28 100% /apex/com.android.vndk.v33@1 /dev/block/loop10 3320 3288 32 100% /apex/com.android.compos@2 /dev/block/loop18 348 316 32 91% /apex/vendor.oplus.hardware.stability.aidl@1 /dev/block/loop13 38592 38564 28 100% /apex/com.android.i18n@1 /dev/block/loop12 788 756 32 96% /apex/com.android.tzdata@351400020 /dev/block/loop19 280 248 32 89% /apex/vendor.oplus.hardware.engineer.aidl@1 /dev/block/loop21 2164 2132 32 99% /apex/com.google.mainline.primary.libs@351165000 /dev/block/loop14 11712 11668 44 100% /apex/com.android.runtime@1 /dev/block/loop17 232 112 120 49% /apex/com.android.apex.cts.shim@1 /dev/block/dm-67 1368 1336 32 98% /apex/com.android.rkpd@351310000 /dev/block/loop20 308 276 32 90% /apex/com.android.nfcservices@352090000 /dev/block/loop15 6016 5988 28 100% /apex/com.android.devicelock@1 /dev/block/loop16 648 620 28 96% /apex/com.android.profiling@352090000 /dev/block/dm-69 6808 6776 32 100% /apex/com.android.media@351504000 /dev/block/dm-68 3048 3016 32 99% /apex/com.android.os.statsd@351610000 /dev/block/loop24 4684 4656 28 100% /apex/com.android.uwb@352090000 /dev/block/dm-59 21932 21900 32 100% /apex/com.android.adservices@351537040 /dev/block/dm-65 31132 31104 28 100% /apex/com.android.mediaprovider@351613160 /dev/block/dm-63 6812 6784 28 100% /apex/com.android.conscrypt@351412000 /dev/block/dm-56 7812 7784 28 100% /apex/com.android.neuralnetworks@351010040 /dev/block/dm-55 4816 4788 28 100% /apex/com.android.appsearch@351412140 /dev/block/loop30 83056 83016 40 100% /apex/com.android.virt@2 /dev/block/dm-57 18808 18776 32 100% /apex/com.android.cellbroadcast@351511000 /dev/block/dm-51 6348 6316 32 100% /apex/com.android.extservices@351538083 /dev/block/dm-49 628 600 28 96% /apex/com.android.configinfrastructure@351010000 /dev/block/dm-48 15376 15348 28 100% /apex/com.android.healthfitness@351511060 /dev/block/dm-47 836 808 28 97% /apex/com.android.ipsec@351410000 /dev/block/dm-45 8712 8684 28 100% /apex/com.android.adbd@351010000 /dev/block/dm-46 28624 28588 36 100% /apex/com.android.media.swcodec@351504000 /dev/block/dm-52 41788 41748 40 100% /apex/com.android.art@351610080 /dev/block/dm-40 232 104 128 45% /apex/com.android.scheduling@351010000 /dev/block/dm-43 25528 25500 28 100% /apex/com.android.permission@351610020 /dev/block/dm-44 13988 13960 28 100% /apex/com.android.ondevicepersonalization@351541000 /dev/block/dm-38 23132 23100 32 100% /apex/com.android.tethering@351510080 /dev/block/dm-41 4248 4216 32 100% /apex/com.android.resolv@351510000 /dev/block/dm-39 736 708 28 97% /apex/com.android.sdkext@351415000 /dev/block/dm-37 10348 10316 32 100% /apex/com.android.wifi@351610000 /dev/fuse 228570232 5218344 223351888 3% /mnt/installer/0/emulated 结合df-k内容分析为什么du -a出来的数据总和要比lpdump出来的数据总和大好多
最新发布
08-14
<think>首先,用户提供了 `df -k` 命令的输出,并询问为什么 `du -a` 出来的数据总和比 `lpdump` 出来的数据总和大好多。但用户没有提供具体的 `lpdump` 输出,只提到了之前的比较。在之前的对话中,用户有 `du -a` 和 `lpdump` 的数据,但这里没有重复。所以,我需要基于给定的 `df -k` 输出和问题来分析。 回顾用户的问题:"结合df-k内容分析为什么du -a出来的数据总和要比lpdump出来的数据总和大好多"。这里的 "df-k" 可能指的是 `df -k` 的输出,用户已经粘贴了。 关键点: - `du -a` 报告的是文件大小的总和。 - `lpdump` 报告的是分区大小(扇区数)。 - 用户说 `du -a` 的总和比 `lpdump` 大好多,这与之前的例子相反(在之前的例子中,`du` 小于 `lpdump`)。 在之前的例子中: - `du -a system` 是 758772 块(1024字节块),约 777 MB。 - `lpdump` 的 `system_a` 是 1527712 扇区(512字节扇区),约 782 MB,所以 `du` < `lpdump`。 但用户现在说 "du -a出来的数据总和要比lpdump出来的数据总和大好多",意思是总和上 `du` > `lpdump`。这矛盾,所以我需要检查 `df -k` 输出。 `df -k` 显示文件系统的使用情况,以 1K 块为单位。输出中,许多挂载点显示 100% 使用,Used 等于 1K-blocks,Available 为 0。 例如: - `/dev/block/dm-17`: 755432K used, total 755432K - `/dev/block/dm-24`: 2060120K used, total 2060120K - 等等。 现在,`du -a` 是递归计算目录下所有文件的大小总和。`df` 报告文件系统别的使用情况,包括元数据和保留空间。 为什么 `du -a` 总和可能大于 `lpdump` 分区总和? 1. **`du` vs `df` 差异**: - `du` 计算文件大小的总和。 - `df` 报告文件系统已用块,包括文件数据和文件系统开销(如 inode 表、日志、保留块)。 - 通常,`df` 的已用空间大于 `du` 的文件总和,因为包括开销。但有时 `du` 可能更大,如果文件有稀疏块或存在硬链接等,但一般 `df` >= `du`。 用户说 `du -a` 总和 > `lpdump` 分区总和。`lpdump` 报告分区大小,类似于 `df` 的总块数。 在 `df -k` 输出中,每个文件系统的 "1K-blocks" 是总大小,"Used" 是已用大小。 如果用户运行 `du -a` 在根目录或整个系统,它会递归计算所有文件的大小。 但 `lpdump` 输出分区大小。分区大小应该对应于 `df` 的 "1K-blocks"。 在之前的例子,`lpdump` 的 `system_a` 有 1527712 扇区 * 512B = 782188544B ≈ 764248K (除以1024),但 `df` 输出中,`/` 是 dm-17 有 755432K,不一致。可能不同分区。 在 `df` 输出中,根 `/` 是 dm-17 755432K,其他如 `/system` 没有直接显示,但有 `/system_ext`、`/product` 等。 用户可能运行 `du -a` 在多个目录,然后总和,而 `lpdump` 是分区大小总和。 在 Android 系统中,分区可能被挂载到不同路径。 为什么 `du` 总和 > `lpdump` 总和? 可能原因: - **重复计算**:`du -a` 可能递归遍历目录,如果有多层挂载点(如 overlay),文件可能被多次计算。 - 在 `df` 输出中,有许多 overlay 挂载点,例如: ``` overlay-overlay 83296 83296 0 100% /product/app overlay-overlay 83296 83296 0 100% /product/priv-app ... ``` 这些 overlay 可能指向相同的底层存储,但 `du -a` 如果遍历 `/product`,可能会计算底层和 overlay 的文件,导致重复。 - **稀疏文件**:如果文件有空洞,`du` 报告实际分配块,而 `lpdump` 报告分区大小。 - **符号链接**:`du` 默认不跟随符号链接,但如果使用 `-L`,可能重复计算。 - **文件系统开销**:但通常使 `df` > `du`,而不是相反。 - **单位混淆**:用户可能没有正确转换单位。 在 `df` 输出中,所有值以 1K 块为单位。`lpdump` 以扇区为单位,通常 512B 或 4K。 用户说 "du -a出来的数据总和",可能用户运行了类似 `du -a / | awk '{sum+=$1} END {print sum}'` 得到总和。 在 `df` 输出,总块数总和:计算所有 "1K-blocks" 列。 但许多是覆盖或虚拟文件系统,如 tmpfs、overlay,所以物理分区可能不重复。 列出物理分区: - dm-17: 755432K ( / ) - dm-24: 2060120K ( /mnt/vendor/my_product ) - dm-25: 16K ( /mnt/vendor/my_engineering ) - 等等 但有些是 loop 设备,如 /dev/block/loop*,用于 APEX。 物理存储可能来自 mmcblk0 或 dm 设备。 用户可能比较了 `du -a` 在所有挂载点的总和 vs `lpdump` 分区大小总和。 在 `df` 输出,有多个 100% 使用的分区,Used 等于总大小。 如果 `du -a` 在根目录运行,它可能包括所有子目录,但有些子目录是挂载点,`du` 会进入挂载点并计算文件。 在文件系统,当挂载点存在时,`du` 会显示挂载文件系统的使用,而不是底层目录。 例如,如果 `/system` 是一个挂载点,`du -a /` 对于 `/system` 会显示挂载文件系统的使用大小,而不是计算文件。 在 `df` 输出,根 `/` 是 dm-17,然后其他如 `/system_ext` 是 dm-18,等等。 所以 `du -a /` 应该报告每个挂载点的使用,类似于 `df`,但 `du` 是递归文件大小,`df` 是块使用。 通常,对于单个文件系统,`du -s` 和 `df` 应该接近,但可能有差异。 但用户说总和 `du -a` > `lpdump` 总和。 另一个可能性:**硬链接**。如果文件有多个硬链接,`du` 可能多次计算,但 `du` 默认不计算硬链接多次;它基于 inode 或文件,只计算一次。 `du` 基于文件分配块,所以硬链接不重复计算。 在 overlay 文件系统,如 Android 的,overlay 挂载点可能使文件出现多次,但底层存储相同。 例如,在 `df` 输出: ``` overlay-overlay 83296 83296 0 100% /product/app overlay-overlay 83296 83296 0 100% /product/priv-app ... ``` 这些 overlay 可能共享相同的 lowerdir 或 upperdir,所以文件只存储一次,但挂载到多个位置。 如果用户运行 `du -a /product`,它会遍历 `/product/app`、`/product/priv-app` 等,每个都是独立的挂载点,`du` 会报告每个挂载点的使用,但由于是 overlay,可能指向相同数据,所以重复计算。 例如,所有 `/product/app`、`/product/priv-app` 等显示 83296K used,但可能共享存储。 所以,如果用户总和所有 `du -a` 输出,它会多次计算相同的文件。 而 `lpdump` 报告物理分区大小,不重复。 在 `df` 输出,也有类似问题,但 `df` 显示每个挂载点的使用,可能也重复。 例如,`/product/app` 和 `/product/priv-app` 都显示 83296K,但底层可能相同。 所以总和 `df` 的 "Used" 会大于实际物理使用。 同样,`du -a` 如果遍历所有目录,会多次计算文件。 此外,有 tmpfs 和虚拟文件系统,它们没有持久存储,`lpdump` 可能不包括。 所以,可能原因:**挂载点重叠和 overlay 导致重复计算**。 在 Android 系统,动态分区和 overlay 文件系统常见。 另一个点:`/data` 分区在 `df` 中显示为 dm-71,228570232K used 5218344K? 等等: ``` /dev/block/dm-71 228570232 5218344 223351888 3% /data ``` 这里 Used 是 5218344K, 总大小 228570232K, 所以使用率 3%,不是 100%。 但其他系统分区是 100%。 对于系统分区,`du` 和 `df` 应该接近,但 overlay 可能导致 `du` 总和更大。 用户说 "du -a出来的数据总和要比lpdump出来的数据总和大好多",所以基于此。 在回答中,我需要: 1. 解释基于 `df -k` 输出。 2. 分析为什么 `du -a` 总和可能大于 `lpdump` 分区总和。 3. 提出 3-5 个相关问题。 回答结构: - 先分析 `df -k` 输出。 - 解释 `du` 和 `lpdump` 差异。 - 给出原因:主要是挂载点重叠和文件系统特性导致重复计算。 - 然后输出 "§§相关问题§§" 并列出问题。 确保用中文。 最后,提出相关问题。</think>### 分析 `df -k` 输出与 `du -a` vs `lpdump` 差异原因 根据您提供的 `df -k` 输出(以 1K 块为单位显示文件系统使用情况),结合 `du -a`(递归计算文件大小总和)和 `lpdump`(报告分区物理扇区大小)的行为,`du -a` 总和大于 `lpdump` 总和的原因主要在于 **文件系统挂载结构、overlay 机制导致的重复计算,以及虚拟文件系统的干扰**。以下是详细分析: #### 1. **关键差异来源**: - **`du -a` 的工作方式**: - `du -a` 递归遍历指定目录(如根目录 `/`),对所有文件的大小进行求和(以 1024 字节块为单位)。 - 在您的 `df -k` 输出中,存在大量 **overlay 挂载点**(如 `/product/app`、`/product/priv-app` 等),这些挂载点共享相同的底层数据(例如,多个 overlay 指向同一个源分区 `/dev/block/dm-19`)。当 `du -a` 遍历父目录(如 `/product`)时,它会为每个挂载点子目录独立计算大小,导致相同数据被多次重复求和。 - 示例:`/product/app`、`/product/priv-app` 等均报告 83296K,但底层数据来自同一个分区(`/dev/block/dm-19`)。如果用户对 `/product` 运行 `du -a`,总和会远大于实际物理数据大小。 - **`lpdump` 的工作方式**: - `lpdump` 转储物理分区信息(如扇区数和分区边界),以扇区(通常 512 字节)为单位报告分区总容量。它不涉及文件系统内容,仅反映分区布局。 - 分区大小是固定的,不包括文件系统元数据或挂载点冗余。例如,`lpdump` 可能只为 `/dev/block/dm-19` 报告一个分区大小,而不会为每个 overlay 子目录单独计数。 - **`df -k` 的印证**: - 您的输出显示多个挂载点(如 overlay、tmpfs)使用率 100%,但部分为虚拟文件系统(如 `tmpfs`)或覆盖层(如 `overlay-overlay`),它们不占用额外物理存储。 - 总和计算:如果简单累加 `df -k` 中所有 "Used" 列(如 `755432 + 2060120 + ...`),会包含重复数据(overlay)和临时文件系统(tmpfs),导致总和虚高。而 `lpdump` 仅累加物理分区大小,无此问题。 #### 2. **为什么 `du -a` 总和 > `lpdump` 总和**: - **Overlay 文件系统的重复计算**: - Android 系统广泛使用 overlay 机制(如 `/product/*` 路径下的多个挂载点)。`du -a` 在递归遍历时,会将同一底层文件在不同挂载点的“视图”视为独立文件,导致大小被多次添加。而 `lpdump` 只计算底层分区一次。 - 示例:在 `df -k` 中,`/product/app`、`/product/priv-app` 等均显示 83296K,但物理存储仅来自 `/dev/block/dm-19`(7920K)。`du -a` 总和可能增加数倍。 - **虚拟文件系统(tmpfs、loop 设备)的干扰**: - `tmpfs`(如 `/dev`、`/apex`)基于内存,无持久存储;`loop` 设备(如 `/dev/block/loop*`)用于 APEX 模块,是文件映射而非独立分区。 - `du -a` 会包含这些临时文件的大小,但 `lpdump` 忽略它们(因不对应物理分区)。在您的输出中,tmpfs 和 loop 设备占用了显著空间(如 `tmpfs` 总计约 11,620,392K),但物理上不存在。 - **挂载点嵌套与遍历范围**: - 如果 `du -a` 从根目录 `/` 开始,它会进入所有子挂载点(如 `/system_ext`、`/vendor`),并累加其内容。而 `lpdump` 仅列出分区元数据。例如,`/data` 分区(`/dev/block/dm-71`)在 `df -k` 中仅报告 5218344K,但若包含其子目录,`du -a` 可能更大。 - **单位与统计误差**: - `du -a` 以 1024 字节块为单位,`lpdump` 以扇区(通常 512 字节)为单位。单位转换不一致可能导致数值偏差(但非主因)。 - 文件系统特性:如稀疏文件或硬链接,`du -a` 可能高估(但影响较小)。 #### 3. **根本原因总结**: - `du -a` 总和偏大是由于 **系统挂载结构(尤其是 overlay)引发的重复计算**,并非实际数据增长。物理存储大小应由 `lpdump` 或 `df -k` 中物理分区(如 `dm-*`、`mmcblk0*`)的 "1K-blocks" 列更准确反映。 - **推荐验证方法**: - 避免对根目录运行 `du -a`,改为针对单个物理分区挂载点(如 `du -s /system`)。 - 比较 `df -k` 中物理分区的 "Used" 与 `lpdump` 的转换值(扇区数 × 512 / 1024),二者应接近(差异来自文件系统开销)。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值