4G通讯模块为何要设Apn

Posted 2023-05-15

参考技术A APN为自动获取的默认APN的PDP承载，如果没有设置APN则无法通信。 APN是4G模块用来告知网关要访问哪种外部数据网络（外部分组数据网，包括企业内部网、Internet、WAP网站、行业内部网等）；还是以刚才的开通电话为例，开通时要求“仅支持省内电话呼入呼出”、“仅支持国内电话呼入呼出”、“可全球呼入呼出”这个就相当于是电话单的APN。
APN为自动获取的默认APN的PDP承载，如果没有设置APN则无法通信。
激活PDP请求时，4G模块会指定一个APN（如果是通用的sim卡，在AT命令中，可以不再主动传入这个APN参数，因为4G模块固件会自动从网络端获取到正确的APN），PDP承载就根据APN来决定是“直接使用之前已经激活的同名APN的PDP承载”还是“新激活一个PDP承载”。

即时通讯开发为何要选择Netty

Netty 是一个基于 JAVA NIO 类库的异步通信框架，它的架构特点是：异步非阻塞、基于事件驱动、高性能、高可靠性和高可定制性。

 

使用 Netty 能够做什么？

    开发异步、非阻塞的 TCP 网络应用程序；
    开发异步、非阻塞的 UDP 网络应用程序；
    开发异步文件传输应用程序；
    开发异步 HTTP 服务端和客户端应用程序；
    提供对多种编解码框架的集成，包括谷歌的 Protobuf、Jbossmarshalling、Java 序列化、压缩编解码、XML 解码、字符串编解码等，这些编解码框架可以被用户直接使用；
    提供形式多样的编解码基础类库，可以非常方便的实现私有协议栈编解码框架的二次定制和开发；
    基于职责链模式的 Pipeline-Handler 机制，用户可以非常方便的对网络事件进行拦截和定制；
    所有的 IO 操作都是异步的，用户可以通过 Future-Listener 机制主动 Get 结果或者由 IO 线程操作完成之后主动 Notify 结果，用户的业务线程不需要同步等待；
    IP 黑白名单控制；
    打印消息码流；
    流量控制和整形；
    性能统计；
    基于链路空闲事件检测的心跳检测

随着网站规模的不断扩大，系统并发访问量也越来越高，传统基于 Tomcat 等 Web 容器的垂直架构已经无法满足需求，需要拆分应用进行服务化，以提高开发和维护效率。从组网情况看，垂直的架构拆分之后，系统采用分布式部署，各个节点之间需要远程服务调用，高性能的 RPC 框架必不可少，Netty 作为异步高性能的通信框架，往往作为基础通信组件被这些 RPC 框架使用。

典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信，Dubbo 协议默认使用 Netty 作为基础通信组件，用于实现各进程节点之间的内部通信。

其中，服务提供者和服务消费者之间，服务提供者、服务消费者和性能统计节点之间使用 Netty 进行异步/同步通信。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

除了 Dubbo 之外，淘宝的消息中间件 RocketMQ 的消息生产者和消息消费者之间，也采用 Netty 进行高性能、异步通信。除了阿里系和淘宝系之外，很多其它的大型互联网公司或者电商内部也已经大量使用 Netty 构建高性能、分布式的网络服务器。

无论是手游服务端、还是大型的网络游戏，Java 语言得到了越来越广泛的应用。Netty 作为高性能的基础通信组件，它本身提供了 TCP/UDP 和 HTTP 协议栈，非常方便定制和开发私有协议栈。

经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架，默认采用 Netty 进行跨节点通信，它的 Netty Service 基于 Netty 框架二次封装实现。

大数据计算往往采用多个计算节点和一个/N个汇总节点进行分布式部署，各节点之间存在海量的数据交换。由于 Netty 的综合性能是目前各个成熟 NIO 框架中最高的，因此，往往会被选中用作大数据各节点间的通信。

企业和 IT 集成需要 ESB，Netty 对多协议支持、私有协议定制的简洁性和高性能是 ESB RPC 框架的首选通信组件。事实上，很多企业总线厂商会选择 Netty 作为基础通信组件，用于企业的 IT 集成。

Netty 的异步高性能、高可靠性和高成熟度的优点，使它在通信行业得到了大量的应用。

传统的同步阻塞 IO 通信存在如下几个问题：

    线程模型存在致命缺陷：一连接一线程的模型导致服务端无法承受大量客户端的并发连接；
    性能差：频繁的线程上下文切换导致 CPU 利用效率不高；
    可靠性差：由于所有的 IO 操作都是同步的，所以业务线程只要进行 IO 操作，也会存在被同步阻塞的风险，这会导致系统的可靠性差，依赖外部组件的处理能力和网络的情况。
    采用非阻塞 IO（NIO）之后，同步阻塞 IO 的三个缺陷都将迎刃而解：
    Nio 采用 Reactor 模式，一个 Reactor 线程聚合一个多路复用器 Selector，它可以同时注册、监听和轮询成百上千个 Channel，一个 IO 线程可以同时并发处理N个客户端连接，线程模型优化为1：N（N < 进程可用的最大句柄数）或者 M : N (M通常为 CPU 核数 + 1， N < 进程可用的最大句柄数)；
    由于 IO 线程总数有限，不会存在频繁的 IO 线程之间上下文切换和竞争，CPU 利用率高；
    所有的 IO 操作都是异步的，即使业务线程直接进行 IO 操作，也不会被同步阻塞，系统不再依赖外部的网络环境和外部应用程序的处理性能。

由于切换到 NIO 编程之后可以为系统带来巨大的可靠性、性能提升，所以，目前采用 NIO 进行通信已经逐渐成为主流。

即便抛开代码和 NIO 类库复杂性不谈，一个高性能、高可靠性的 NIO 服务端开发和维护成本都是非常高的，开发者需要具有丰富的 NIO 编程经验和网络维护经验，很多时候甚至需要通过抓包来定位问题。也许开发出一套 NIO 程序需要 1 个月，但是它的稳定很可能需要 1 年甚至更长的时间，这也就是为什么我不建议直接使用 JDK NIO 类库进行通信开发的一个重要原因。

Netty 是业界最流行的 NIO 框架之一，它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的，它已经得到成百上千的商用项目验证，例如 Hadoop 的 RPC 框架 Avro 使用 Netty 作为通信框架。很多其它业界主流的 RPC 和分布式服务框架，也使用 Netty 来构建高性能的异步通信能力。

Netty 的优点总结如下：

    API 使用简单，开发门槛低；
    功能强大，预置了多种编解码功能，支持多种主流协议；
    定制能力强，可以通过 ChannelHandler 对通信框架进行灵活的扩展；
    性能高，通过与其它业界主流的 NIO 框架对比，Netty 的综合性能最优；
    社区活跃，版本迭代周期短，发现的 BUG 可以被及时修复，同时，更多的新功能会被加入；
    经历了大规模的商业应用考验，质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它完全满足不同行业的商用标准。

正是因为这些优点，Netty 逐渐成为 Java NIO 编程的首选框架。

事实上，Netty 各版本之间的 API 变更并没有一些人讲的那么可怕，最大的变更就是 3.X 系列到 4.X/5.X 的变更，Netty 不仅仅重构了包路径，对于之前一直想改但是考虑到前向兼容性没改的类库进行了优化和修改。这次变更的主要原因是 Netty 脱离了 Jboss 独立发展，这对于 Netty 的长远发展是件好事。

在我看来，Netty4.X 系列版本的架构和 API 设计更加合理，同时，它提供了更多新的特性。因此，我个人建议用户可以选择 4.X 系列版本，以免未来升级遇到困难和问题。

对于已经使用 3.X 系列版本的用户，如果现有功能已经满足需求，短期内暂时不需要升级。如果需要使用更多新特性和功能，建议在充分评估之后进行升级，这可能需要一些工作量。

由于 Netty5 最新版本仍处于测试阶段，从学习和研究角度可以试用一下，Netty5 相比于 Netty4 是前向兼容的，因此，未来用户升级到 Netty5 会更加容易。

根据我的经验，无论选择哪个，都是个正确的选择。两者各有千秋，Netty 在内存管理方面更胜一筹，综合性能也更优。但是，API 变更的管理和兼容性做的不是太好。相比于 Netty，Mina 的前向兼容性、内聚的可维护性功能更多，例如 JMX 的集成、性能统计、状态机等。

建议用户可以根据自己对两者的熟悉程度和实际项目需求，做出最佳选择。如果你锁定了两者，本身就意味着你做出了正确选择，不需要再纠结于选择哪个而和领导、同事吵得面红耳赤。

Netty 的基础开发和应用非常简单，开发一个 Echo 服务端只需要 28 行代码，开发对应的 Echo 客户端只需要 26 行代码！

但是，如果你要利用它进行私有协议栈开发、HTTP 服务端和客户端开发等，仍然需要深入的学习 Netty 的一些高级类库和功能，了解 Netty 的设计原理。只有这样，才能恰到好处的使用 Netty，为项目和公司带来更大的价值。