为什么现在好多公司都搞云服务器，阿里 腾讯 百度 都挤进去，

云服务器的优势有哪些

为什么越来越多的企业和开发者使用云服务器来部署网站或应用总的来说，因为云服务器可提高效率，有助于节省企业和开发者的成本并获得更高收益。

1、敏捷性

云服务器，基于云端海量的虚拟资源池，支持资源的弹性伸缩，包括横向增加虚拟机的数量和纵向扩展资源的规模，可适应不断增长或波动的计算和带宽需求。当应用资源需求增加，你可以轻松扩展云端容量，同理，你也可以根据需求变化收缩资源规模。这种可根据运营策略的调整随需应变的敏捷性和高扩展性，是传统服务器无法比拟的，可使企业比竞争对手更具优势。

2、灾难恢复

使用云服务器，可为网站或应用数据提供更高的可靠性支持。无论业务规模大小，企业都应投资于灾难恢复工作，避免出现硬件故障导致的数据丢失、网站无法访问、服务器无法使用等突发情况。但要实现完善的容灾，通常需要高额的费用和专业技术知识，这对于小型企业来说无疑是很高的门槛。而云服务器，则可以有效地规避这些问题。我们以知了云OpenStack香港云服务器为例，知了云OpenStack云平台支持多重副本实时容灾、快照备份和回滚、热迁移等强大功能，如果某服务器集群出现硬件故障，系统将立即停止数据写入，而由其他备用服务器集群接管，并实现数据热迁移，在客户无感知的情况下快速恢复使用，且这些行为都是完全免费的。

3便捷性

云服务器优势还体现在业务的快速部署方面。传统服务器的使用，需要用户自己安装操作系统、配置防火墙、安装系列软件以搭建完善的应用部署环境。如今，这些工作都由云服务器供应商负责，供应商在云平台集成海量镜像，用户可一键获取并配置好相关应用程序的所需环境，即使技术实力较弱的小型企业也能轻松创建和管理线上IT服务。

4、成本控制

云计算削减了硬件的高成本。您花费高额费用无需购置硬件设备以及与之相关的监控、管理和维护成本。使用云服务器，您只需为需要的资源和服务付费，随时享受基于自选资源的模式，精准控制你的成本支出。并且，可以大幅节省运维管理费用。

5竞争力

您需要一个简单的方式来提高竞争力吗将业务迁移到云端，可以为每个开发者提供企业级技术支持。云服务器，可以使小型企业的业务部署和管理效率超出那些大型的成熟的竞争对手。例如知了云OpenStack香港云服务器，即开即用，秒级调度资源为您所用，业务可以最快上线，同时还能保持精简的资源组合以及管理上的敏捷性，这一切使您可以与更成熟的并肩前进，缩短与更强竞争对手之间的差距。

因此，云服务器优势有哪些总的来说，企业和开发者使用云服务器，在资源上可以做到随需随取，按需付费，在保持敏捷性的同时节省成本;在功能上支持多重数据备份和热迁移，使数据可靠性远超传统IT托管模式;在管理上可简化运维，使应用程序的部署和管理更有效率。使用云服务器，或者私有云，已经成为目前众多企业IT架构转型的重要方式。相信随着时间的推移将为越来越多的企业和开发者创造更高价值。

阿里的，阿里十年前开始搞阿里云，建立数据中台（就是数据中心，打通各个模块的数据，比如说在淘宝领券后可以在闲鱼上用）

而腾讯去年底才开始做这件事！

还有，阿里云是分布式服务器。一台负责分发，分发给其他众多服务器分别一起处理！

促使马云下决心做阿里云的是当时的紧迫情况：淘宝访问量暴涨，服务器扛不住。买美国人的设施又太贵。（其实当时可以买，只是马云下决心自己做）

时至今日，阿里云已经是世界第一。以此为基础的城市大脑武装杭州市，使之成为全世界互联网最发达的城市。

阿里聚安全的Android应用漏洞扫描器有一个检测项是本地拒绝服务漏洞的检测，采用的是静态分析加动态模糊测试的方法来检测，检测结果准确全面。本文将讲一下应用漏洞扫描器在针对本地拒绝服务的检测方法。

一、本地拒绝服务产生原因和影响

Android应用使用Intent机制在组件之间传递数据，如果应用在使用getIntent()，getAction()，IntentgetXXXExtra()获取到空数据、异常或者畸形数据时没有进行异常捕获，应用就会发生Crash，应用不可使用(本地拒绝服务)。恶意应用可通过向受害者应用发送此类空数据、异常或者畸形数据从而使应用产生本地拒绝服务。

阿里聚安全的博客以前有一篇文章《Android应用本地拒绝服务漏洞浅析》，里面详细讲了产生本地拒绝服务的四种情况：

1、NullPointerException空数据异常：应用程序没有对getAction()等获取到的数据进行空指针判断，从而导致空指针异常而导致应用崩溃。

2、ClassCastException类型转换异常：程序没有对getSerializableExtra()等获取到的数据进行类型判断而进行强制类型转换，从而导致类型转换异常而导致应用崩溃。

3、IndexOutOfBoundsException数组越界异常：程序没有对getIntegerArrayListExtra()等获取到的数据数组元素大小的判断，从而导致数组访问越界而导致应用崩溃。

4、ClassNotFoundException异常：程序没有无法找到从getSerializableExtra ()获取到的序列化类对象的类定义，因此发生类未定义的异常而导致应用崩溃。

当应用被恶意应用攻击时，本地拒绝服务一般会导致正在运行的应用崩溃，首先影响用户体验，其次影响到后台的Crash统计数据，另外比较严重的后果是应用如果是系统级的软件，可能导致手机重启。Nexus 5曾经出现过这样的情况，它预装了一个用来测试网络连通性的系统应用，这个应用是隐藏状态，无法在桌面上打开，包名为comlgeSprintHiddenMenu。在Android 443之前的版本里，这个应用里有大量导出的activity，这些 activity不需要任何权限就可以被外部调用。其中一个为comlgeSprintHiddenMenusprintspecSCRTN的组件是导出的，并且没有任何权限限制，给它发送一个空Intent，可导致Nexus 5手机重启。

二、阿里聚安全扫描器的进化提升

一个简单的本地拒绝服务类漏洞，要想进行大规模的自动化扫描，扫描器也要做不少的工作，并且随着对本地拒绝服务漏洞的认识，阿里聚安全的漏洞扫描器也在不断进行优化提高。

21 空Intent阶段

这个阶段的扫描器是初级阶段，一般只是通过AndroidManifestxml文件获取应用导出的组件，然后使用adb命令发送空intent给导出组件，捕获应用日志输出，查看是否有崩溃产生。

针对空Intent导致的本地拒绝服务情况可发送如下命令测试：

adb shell am start -n comjaqdosappsample/DosActivity

adb shell am startservice -n comjaqdosappsample/DosService

adb shell am broadcast -n comjaqdosappsample/DosReceiver

何为导出的组件

在AndroidManifestxml文件中如果应用的组件android:exported属性显式指定为“true”，或者并没有显式指定为“true”也没有显式指定为“false”，什么也没有写，但是有intent-filter并指定了相应的Action，则此组件为导出的组件。

22 解析Key值阶段

空Intent导致的拒绝服务毕竟只是一部分，还有类型转换异常、数组越界异常等导致的本地拒绝服务。在解析Key值阶段扫描器需要分析组件代码中是否使用了一些关键函数。

在Activity组件中的onCreate()方法中，Service组件中的onBind()和onStartCommand()方法中，BroadcastReceiver组件的onReceive()方法中，如果组件没有做好权限控制，都可接受任意外部应用传过来的Intent，通过查找getIntent()、getAction()和getXXExtra()这些关键函数，检测其是否有try catch异常保护，如果没有则会有本地拒绝服务风险。

在这一阶段扫描器遇到的挑战是找到这些关键函数中的Key值，Action值，不仅要找到，还要找到key对应的类型，来组装adb命令，发送命令给安装好的应用进行测试。

23 通用型拒绝服务阶段

2015年年初的时候，业界又爆出了通用型拒绝服务，由于应用中使用了getSerializableExtra() 的API，应用开发者没有对传入的数据做异常判断，恶意应用可以通过传入序列化数据，导致应用本地拒绝服务。此种方法传入的key值不管是否与漏洞应用相同，都会抛出类未定义的异常，相比解析Key值阶段通用性大大得到了提高。

针对这个常用的手工检测POC代码如下：

此阶段扫描器遇到的难题是无法直接通过adb命令进行测试，因为无法用adb命令传递序列化对象给应用。业界大部分漏洞扫描器也因为无法发送序列化对象给应用都止步解析Key值组装adb命令阶段，而阿里聚安全的漏洞扫描器能够发送序列化对象数据给指定的应用，再结合静态分析查找导出的组件和关键函数，动态运行应用，精确识别出会发生本地拒绝服务的应用组件，同时实现了大规模自动化测试。

24 动态注册BroadcastReceiver阶段

BroadcastReceiver组件一般分为两种，一种是静态注册，提前在AndroidManifestxml声明组件;另外一种是动态注册，在代码中使用registerReceiver()方法注册BroadcastReceiver，只有当registerReceiver()的代码执行到了才进行注册。

动态注册BroadcastReceiver的常见使用方法如下：

很多开发者没有意识到，如上使用registerReceiver()方法注册的是全局BroadcastReceiver，和静态注册BroadcastReceiver android:exported属性为true性质一样，如果没有指定权限访问控制(permission参数)，可以被任意外部应用访问，向其传递Intent，根据具体情况产生的危害可能不同，一种比较普遍的情况是容易产生本地拒绝服务漏洞。

动态注册BroadcastReceiver导致导出的Receiver这种情况非常少被大家注意，现有的一些安全检测工具、扫描器都不能发现动态注册的BroadcastReceiver。在此阶段，动态注册BroadcastReceiver隐藏在所有代码中，在应用的任何地方都可能出现，需要扫描器全局分析应用的代码找出关键函数registerReceiver，还要找出其IntentFilter所设置的Action和Receiver的权限设置，现在一般一个普通的正常Android应用都有几十M的大小，反编译成smali代码会更多，扫描器遇到的挑战主要是查找的时间和空间挑战，还有多个参数查找的准确性。目前业界只有阿里聚安全的扫描器有准确扫描动态注册BroadcastReceiver导致的本地拒绝服务的能力。

通过阿里聚安全的漏洞扫描器对一些样本进行了检测，也发现了不少动态注册BroadcastReceiver导致的本地拒绝服务攻击。

三、本地拒绝服务漏洞现状

为了了解本地拒绝服务漏洞的现状，阿里聚安全的应用漏洞扫描器针对国内外的各行业主要APP进行了扫描，共扫描了三百多款APP。

国内行业主要是通过采集国内某应用市场的APP，我们采集了各个行业的TOP APP总共有151个，发现拒绝服务漏洞的总个数为970个，平均个数为64个，其中影音播放类的APP本地拒绝服务个数最多，健康类安全类和运营商类比较少、游戏类的最少。

国内行业APP本地拒绝服务漏洞情况：

柱状图是国内各个行业APP按本地拒绝服务漏洞平均个数排序：

下图是各个组件引起的本地拒绝服务的数量、占比情况：

国内行业动态注册BroadcastReceiver导致的本地拒绝服务漏洞有247个，约占拒绝服务漏洞总数的25%，比静态注册BroadcastReceiver的要多不少：

国外行业主要是通过采集Google Play上的APP，我们也采集了各个行业的TOP APP总共有177个，发现拒绝服务漏洞的总个数是649个，平均漏洞个数为37个，平均漏洞个数最多的是办公类应用，最少的和国内行业一样是游戏。

国外行业APP本地拒绝服务漏洞情况：

国外各个行业的应用本地拒绝服务漏洞平均个数排序：

各个组件引起的本地拒绝服务的数量、占比情况：

国外行业动态注册BroadcastReceiver导致的本地拒绝服务漏洞有147个，约占拒绝服务漏洞总数的23%，比国内的情况略少，可见动态注册BroadcastReceiver导致的本地拒绝服务都没有引起大家的重视。

总体上来看，本地拒绝服务风险因为具有Android版本无关性，漏洞本身对APP影响也不大，只与应用开发者是否注意、重视有关，所以现在还经常在应用中出现。在各大厂商的安全应急响应中心评级为低危漏洞，也有厂商不收此类漏洞，但是这些攻击面依然存在，如果深入分析这些组件，有的不仅仅是引发本地拒绝服务风险，必须遵循最小权限原则，没有必要导出的组件不要导出。

四、阿里聚安全对开发者建议

(1)阿里聚安全的漏洞扫描器已经具备覆盖动态注册Receiver产生的拒绝服务漏洞(目前，还没发现友商的漏洞扫描器有这样的能力)，使用阿里聚安全的漏洞扫描器进行扫描，可及时发现这些漏洞。

(2)不必要导出的组件将其exported属性显式的设为“false”，这样可以减少应用的攻击面。

(3)导出的组件在getIntent()后，IntentgetXXXExtra()时用try…catch做好异常处理。

(4)在导出的组件设置好权限控制，不让任意第三方应用访问。

(5)对于动态注册的BroadcastReceiver，尽量少用registerReceiver()方法，如果只在本应用内通信，改用LocalBroadcastManager的registerReceiver()进行本地注册，如果必须导出给外部应用，在使用registerReceiver()时要指定好相应的访问权限。

1HSF框架的采用Netty+Hession数据序列化协议实现服务交互

HSF采用网络通信框架Netty+Hession数据序列化协议实现服务间的调用，主要考虑点在大并发量时，服务的交互性达到最佳。这类RPC协议采用多路复用的TCP长连接方式，即在服务调用者和服务提供者之间有多个服务请求同时调用时会共用一个长连接，一个长连接交替传输不同请求的字节块。它既避免了反复建立连接开销，也避免了连接的等待闲置从而减少了系统的连接总数，同时还避免了TCP顺序传输中的线头阻塞问题。

2HSF框架的容错机制

为了保证服务的高可用性，在生产环境中相同的服务往往会有很多个应用实例来提供服务，在进行服务调用时，服务调用者端已经保存了它需要调用的服务的服务器列表信。假如有三台服务器提供了相同的服务，当采用随机方式获取其中一台进行服务交互时，不论这台服务器已经发生故障无法回应请求，还是该服务器已经接收了请求，在服务请求处理过程中出现了服务器故障（宕机、网络问题）造成该服务器没有在规定的时间（一般服务调用会设置超时时间）内返回处理结果，则服务调用端会获取服务调用失败的反馈，会立即从剩下的两台机器中选择一台进行服务调用。从而保证了个别服务提供者出现问题，完全不影响该服务提供正常的服务。因为配置服务器是采用长连接的方式与服务器节点进行通信，一旦发现有服务实例出现故障，此时会将这台服务器提供者的信息从服务器的服务列表中删除，然后将更新后的服务列表以推送的方式同步给予该服务相关的所有服务调用者端，这样当下次进行服务调用时，就不会因为随机而对已经停止提供服务的服务器发送请求。

3HSF框架的线性扩展支持

HSF最为重要的一个特性就是服务能力的可扩展性，真正做到某个服务的业务处理能力随着服务器资源的增加得到线性的增长。基于HSF框架的运行机制，面对超级大的服务调用压力时，新增的服务提供实例（即增加一台服务器）可在几秒内（完成服务的注册发布、更新后的服务列表推送到服务调用端）开始进行服务请求处理，达到分担其他服务器实例压力的作用，实现服务能力整体水位恢复到正常的状态。据说双十一的时候阿里的多个服务中心所部署的服务实例节点数量超过2000个，即同一个服务由超过2000个服务实例同时提供负载均衡的服务。

根据我所知道的回答一下这个问题。

利用公有云（比如阿里云、腾讯云、华为云等）部署了应用之后，为了访问申请的云服务器，需要使用公网IP，公有云服务商不仅提供了固定的公网IP，更多采用的是弹性公网IP。

弹性公网IP的基础是：NAT

弹性公网IP

申请了弹性公网IP之后，可以将期绑定到云服务器实例，用于通过公网访问自己申请的云主机。

总结

腾讯云、阿里云、华为云均支持弹性公网IP。随着公有云业务的不断发展，云服务提供商的公网资源是远远不够的，目前通过运营商上网也采用了运营商级别的NAT。将来有可能所有的云主机均得采用弹性公网IP。

对于公有云服务商提供的云服务器的公网IP，大家有什么看法呢，欢迎在评论区，留言讨论。

如需更多帮助，请私信关注。谢谢

瞎回答的很多。实质上，并没有魔术。阿里云的ip就是买的，是一大段一大段ip范围买下的。

那些说类似专线独立ip的人，都是瞎掰，专线实质上是电信买下的ip范围里租一个给你用，电信那端通过调整路由表把对应的ip报文转发到你那根物理线路上。

阿里云的技术方式完全不一样。

首先阿里和电信一样，都是购买巨大的一段ip地址范围，它的地址范围不比电信小多少。ipv4的地址范围就是这些大佬买光的，国外aws，google，微软的ip范围更大。

其次，阿里云内部，不是简单的改路由器，而是当有bgp能力的核心路由把全网络里属于阿里云的ip报文导入数据中心后，通过服务器进行报文数据软交换，也就是常说的sdn（软件定义的网络）技术把ip分配给具体的虚拟机。这样确保虚拟机绑ip可轻松的自动绑定。当你在界面上点一下申请弹性ip的时候，阿里云就从它的ip池里空余的ip中，分一个给你，注意，这个ip池比阿里的机器数量，甚至虚拟机数量要大很多。当你分配了弹性ip后，如果要绑定弹性ip到具体某个虚拟机时候，背地里，阿里云就简单的把这个ip和虚拟机的路由关系告诉它的软交换服务器集群，然后所有进入阿里云中的报文里，属于这个ip的报文被投递给这台虚拟机。

下面有很多瞎回答的，NAT是可以减少公网IP地址的使用，但还是需要公网IP。

公网IP只可能是云服务商自己向电信或移动等运营商买的。

阿里云有很多服务器，但是并不是所有服务器都需要公网IP，比如数据库服务器，负载均衡服务器等，只需要内网IP就够了。实际需要使用公网IP的服务器就是直接面对用户的那几台而已。

借助内网IP和弹性公网IP，以及IP回收等，实际需要使用的公网IP数量是可控的。

那么，阿里云到底有多少公网IP呢？可以看下这里的不精确统计

http://aschacuonet/companyview/s_alibaba

大概是 860万个公网IP。

这里面包含了阿里在国内、美国、新加坡的IP地址统计，应该还不完整。

一句话回答：就是买的。

通过BGP自治号(AS)查询，阿里云大约有3千万个公网IP，AS名称为“CNNIC-ALIBABA-CN-NET-AP”，有兴趣的可以自己去查。

另外这么多IP当然不可能是运营商分配的，事实上运营商的公网IP还没阿里云多，这些IP是阿里云向CNNIC申请，APNIC审核并最终由ICANN分配的。

在逻辑上阿里实际就是一个运营商，它和移动联通电信的网络连接，和移动联通电信三网互通原理完全一样，都是基于边界网关协议BGP，搞一次地址广播的花费至少就要花好几百万

没啥特别的实现方法，就是大批量买IP地址，通过广域网路由协议发布。

原来IPV4地址还不值钱，阿里早就大段大段地买，囤积了非常多的IPV4地址资源。

国内的BAT，从IPV4资源来看，阿里比腾讯多一个数量级，腾讯比百度多一个数量级，百度比其他厂商多一个数量级。

查了下阿里的AS信息，大概有十来个B段地址。

现在的IPV4地址，基本上已经分配完了，现在要拿到新的IP网段，基本上只能找ISP买，或者收购其他有IPV4资源的公司。

全世界所有的公网IP地址都源自ICANN这个组织，这个组织掌握着全球“互联网地址簿”

互联网协议（IP）地址的空间分配、协议标识符的指派、通用顶级域名（gTLD）、国家和地区顶级域名（ccTLD）系统的管理、根服务器系统的管理等都是由ICANN负责管理。

ICANN先分配给亚太互联网信息中心（APNIC）、欧洲IP资源网络协调中心（PIPE NCC）、美洲互联网号码注册机构（ARIN）、拉丁美洲和加勒比地区互联网信息中心（LACNIC）、非洲互联网络信息中心（AfriNIC），再由这些地域性的组织分配给所在区域的ISP。

IPV4最多可以提供约429亿个IP地址，这么多年过去了，用着用着就发现不够用了。虽然全世界的各个分配机构都相继宣告了IPV4地址已经耗尽，但还是有大量的ISP私藏了大量的IPV4的IP地址。

绝大多数人对IPV4地址枯竭这件事都理解有偏差

宣告枯竭的对象是IPV4地址分配组织，它只是告诉大家我手里所有的IPV4地址已经全部发放完毕了，至于已经从分配组织获得的IP地址，分配组织才不管你用还是不用。假如还想从分配组织手里申请新的IPV4地址就必须要等别人不用归还，稀缺的资源往往需要排队走关系。

所以但凡稍微有点实力的ISP运营商都不会傻傻地将IPV4地址退回去，而是大批量的囤货，即使不用也会攥着手里。假如真有那些坚持不下去的ISP运营商，退了多少IPV4地址立马就会被瓜分掉。IPV6在不断的普及当中，当简短的IPV4地址注定会变成一种稀缺资源。

ISP手里囤积的IPV4地址是完全足够日常使用

IPV4地址就像海绵里的水，你挤挤它就会出来。这也就是为什么很多服务器的运营商和网络运营商能够保证公网IP地址的供应。

IPV4地址到目前为止还能游刃有余，很大程度上归功于NAT技术，即网络地址转换。

NAT技术能够将当前地址空间中的IP地址映射到另一个地址空间，可以理解成一个转换表，其中存储着外部地址/端口到内部地址/端口的转换关系。通过NAT技术就无需每台设备都拥有一个独立唯一的IP地址，可以很多台设备共用一个公网IP地址，而局域网内使用私网不重复的IP地址即可。

NAT技术不仅可以缓解IP地址短缺的问题，还可以有效地保护私有网络。现在申请宽带已经很难再申请到公网IP地址了，甚至于运营商可以实现一个地区都使用内网IP地址。那么问题就来了，绝大多数人并不喜欢NAT转换技术，希望设备能够获得公网的IP，便于远程管理。所以很多“攻城狮们”会尝试通过各种NAT穿透技术来解决NAT转换技术所带来的问题，比如：SOCKS、UPNP、ALG等等。

实际上服务器对于公网IP地址的需求量也并没有那么大，比如：很多网站、域名可以存放在一台服务器上，共用一个公网IP地址。理论上服务器的配置足够、带宽足够可以同时存放N多个网站，应用类的APP服务器也是同样的道理。

公网IP地址的配置和局域网的IP地址配置并无二致

互联网内很多组织都共同维护着一本类似“114”的地址查询薄，IP地址由分配组织分配给ISP后，分配组织就会更新地址簿，其他组织就会同步更新。

这就好比快递，收快递的人也许并不知道送到具体哪个地方，他只需要将包裹收好贴上地址后统一放到快递站点，再由快递站点送到区域中转站，再由区域中转站送到市级以上的大型中转站，大型中转站就知道如何层层下发，最终有派件员送到收快递的人手中。

IP地址分配组织会标识每个IP地址具体是属于哪个ISP运营商，至于ISP运营商是想很多个网站或者应用用一个公网IP地址、还是一个服务器用多个公网IP地址、还是一个服务器使用弹性的公网IP地址，就不是IP地址分配组织会管的事情了。

阿里云服务器是如何实现每台服务器都是公网IP的呢？服务器那么多，不应该每台服务器都去运营商购买公网IP吧。难道是使用NAT转换的吗？

阿里云的ip就是买的，是一大段一大段ip范围买下的。

那些说类似专线独立ip的人，都是瞎掰，专线实质上是电信买下的ip范围里租一个给你用，电信那端通过调整路由表把对应的ip报文转发到你那根物理线路上。

阿里云的技术方式完全不一样。

首先阿里和电信一样，都是购买巨大的一段ip地址范围，它的地址范围不比电信小多少。ipv4的地址范围就是这些大佬买光的，国外aws，google，微软的ip范围更大。

其次，阿里云内部，不是简单的改路由器，而是当有bgp能力的核心路由把全网络里属于阿里云的ip报文导入数据中心后，通过服务器进行报文数据软交换，也就是常说的sdn（软件定义的网络）技术把ip分配给具体的虚拟机。这样确保虚拟机绑ip可轻松的自动绑定。当你在界面上点一下申请弹性ip的时候，阿里云就从它的ip池里空余的ip中，分一个给你，注意，这个ip池比阿里的机器数量，甚至虚拟机数量要大很多。当你分配了弹性ip后，如果要绑定弹性ip到具体某个虚拟机时候，背地里，阿里云就简单的把这个ip和虚拟机的路由关系告诉它的软交换服务器集群，然后所有进入阿里云中的报文里，属于这个ip的报文被投递给这台虚拟机。

阿里云有很多服务器，但是并不是所有服务器都需要公网IP，比如数据库服务器，负载均衡服务器等，只需要内网IP就够了。实际需要使用公网IP的服务器就是直接面对用户的那几台而已。

借助内网IP和弹性公网IP，以及IP回收等，实际需要使用的公网IP数量是可控的。

人家阿里有自己的as号好吧，bgp互联的，有自己ip段，nat个锤子

很正常，开过专线的就知道，给钱，一条线路，所有内网电脑全可以分配外网ip。

当然是向运营商买ip了，不可能是NAT，至于为什么不是，你需要了解NAT的工作原理，NAT其中一个必要条件是NAT转换必须有一方是公网地址