原生 JDK 网络编程 BIO（五）

女爷i 2022-10-29 07:37 168阅读 0赞

今天我们分析，原生 JDK 网络编程 BIO

**一、一些常见术语**

**Socket**  是应用层与  TCP/IP  协议族通信的中间软件抽象层，它是一组接口。在设计模式 中，Socket  其实就是一个门面模式，它把复杂的  TCP/IP  协议族隐藏在  Socket  接口后面，对 用户来说，一组简单的接口就是全部，让 Socket  去组织数据，以符合指定的协议。 主机 A  的应用程序要能和主机  B  的应用程序通信，必须通过  Socket  建立连接，而建 立 Socket  连接必须需要底层  TCP/IP  协议来建立  TCP  连接。建立  TCP  连接需要底层  IP  协议来 寻址网络中的主机。我们知道网络层使用的 IP  协议可以帮助我们根据  IP  地址来找到目标主 机，但是一台主机上可能运行着多个应用程序，如何才能与指定的应用程序通信就要通过  TCP  或  UPD  的地址也就是端口号来指定。这样就可以通过一个  Socket  实例唯一代表一个主机上的一个应用程序的通信链路了。

**1、短连接：**

连接 \-> 传输数据 \-> 关闭连接

传统  HTTP  是无状态的，浏览器和服务器每进行一次  HTTP  操作，就建立一次连接，但任 务结束就中断连接。 也可以这样说：短连接是指 SOCKET  连接后发送后接收完数据后马上断开连接。

**2、长连接：**

连接 \-> 传输数据 \-> 保持连接  \->  传输数据 \->  。。。  \-> 关闭连接。 长连接指建立 SOCKET  连接后不管是否使用都保持连接。

**3、什么时候用长连接，短连接？**

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个  TCP  连 接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降

低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就  OK  了，不用建立  TCP 连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成 socket  错误，而且 频繁的 socket  创建也是对资源的浪费。 而像 WEB  网站的  http  服务一般都用短链接，因为长连接对于服务端来说会耗费一定的 资源，而像 WEB  网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。 总之，长连接和短连接的选择要视情况而定。

**二、网络编程里通用常识**

既然是通信，那么是肯定是有两个对端的，（就和   去大保健一样的，一个人 怎么大保健呢？必须要有   和技师两个人才能进行，  总不能在大保健里 自娱自乐，那还去大保健干嘛？那么在大保健里提供服务的场所叫会所或者某某中心，具体 提供服务的那个人叫技师，享受服务的那个人叫 ）。 在通信编程里提供服务的叫服务端，连接服务端使用服务的叫客户端。在开发过程中， 如果类的名字有 Server  或者  ServerSocket  的，表示这个类是给服务端容纳网络服务用的，如果类的名字只有 Socket  的，那么表示这是负责具体的网络读写的。那么对于服务端来说 ServerSocket 就只是个场所，具体和客户端沟通的还是一个一个的  socket ，所以在通信编程 里，ServerSocket  并不负责具体的网络读写， ServerSocket  就只是负责接收客户端连接后， 新启一个 socket  来和客户端进行沟通。这一点对所有模式的通信编程都是适用的。 在通信编程里，我们关注的其实也就是三个事情：连接（客户端连接服务器，服务器等 待和接收连接）、读网络数据、写网络数据，所有模式的通信编程都是围绕着这三件事情进 行的。服务端提供 IP  和监听端口，客户端通过连接操作想服务端监听的地址发起连接请求，通过三次握手连接，如果连接成功建立，双方就可以通过套接字进行通信。

***1、InetAddress***  ***类***

java.net.InetAddress  类是  Java  对  IP  地址（包括  IPv4  和  IPv6) 的高层表示。大多数其他网 络类都要用到这个类，包括 Socket 、 ServerSocket 、 URL 、 DatagramSocket ， DatagramPacket 等。一般地讲，它包括一个主机名和一个 IP  地址。 我们在网络编程里常用的  InetSocketAddress  里就包含了  InetAddress 。

常用方法

InetAddress  类没有公共构造函数。实际上， InetAddress  有一些静态工厂方法，可以连 接到 DNS  服务器来解析主机名。最常用的是  InetAddress.getByName() 。例如，可以如下

InetAddress address = InetAddress.getByName("www.baidu.com");
            System.out.println(address);

这个方法并不只是设置  InetAddress  类中的一个私有  String  字段。实际上它会建立与本 地 DNS  服务器的一个连接，来查找名字和数字地址（如果你之前查找过这个主机，这个信 息可能会在本地缓存，如果是这样，就不需要再建立网络连接）。如果 DNS  服务器找不到 这个地址，这个方法会抛出一个 UnknownHostException  异常，这是  IOException  的一个子类。 还可以按 IP  地址反向查找。例如，如果希望得到地址  208.201.239.100  的主机名，可以 向 InetAddress.getByName(() 传入一个点分四段地址 :

InetAddress address2 =  InetAddress.getByName("124.232.170.22");
            System.out.println(address2.getHostName());

如果你查找的地址没有相应的主机名，getHostName()就会返回你提供的点分四段地址。 很多的网站实际上有多个地址。如果出于某种原因你需要得到一个主机的所有地址，可以调用 getAllByName()，它会返回一个数组:

InetAddress[] allByName = InetAddress.getAllByName("www.baidu.com");
            for(InetAddress addr:allByName ){
                System.out.println(addr);
            }

如果你知道一个数字地址，可以由这个地址创建一个 InetAddress  对象，而不必使用 InetAddress.getByAddress()与  DNS  交互。这个方法可以为不存在或者无法解析的主机创建地 址：

测试可达性   InetAddress 类有两个  isReachable() 方法，可以测试一个特定节点对当前主机是否可达 ( 也 就是说，能否建立一个网络连接) 。连接可能由于很多原因而阻塞，包括防火墙、代理服务 器、行为失常的路由器和断开的线缆等，或者只是因为试图连接时远程主机没有开机。

InetAddress address = InetAddress.getByName("www.baidu.com");
            System.out.println(address);
            boolean reachable = address.isReachable(500);
            System.out.println("是否连接上：:"+reachable);

***2、Networklnterface*** ***类***

由于  NetworkInterface  对象表示物理硬件和虚拟地址网络接口，所以不能任意构造。与 InetAddress 类一样，有一些静态工厂方法可以返回与某个网络接口关联的  NetworkInterface 对象。可以通过 IP  地址、名字或枚举来请求一个  NetworkInterface 。

例如：

InetAddress address = InetAddress.getByName("127.0.0.1");
            NetworkInterface byInetAddress = NetworkInterface.getByInetAddress(address);
            System.out.println(byInetAddress);

或

Enumeration<NetworkInterface> networkInterfaces
                    = NetworkInterface.getNetworkInterfaces();
            while(networkInterfaces.hasMoreElements()){
                NetworkInterface networkInterface = networkInterfaces.nextElement();
                System.out.println(networkInterface+"===============");
                Enumeration<InetAddress> inetAddresses = networkInterface.getInetAddresses();
                while(inetAddresses.hasMoreElements()){
                    System.out.println(networkInterface.getDisplayName()
                            +"-"+inetAddresses.nextElement());
                }
            }

名字的格式与平台有关。在典型的 UNIX 系统上，以太网接口名的形式为 eth0、eth1 等。 本地回送地址的名字可能类似于“lo”。在 Windows 上，名字是类似“CE31”和“ELX100” 的字符串，取自这个特定网络接口的厂商名和硬件模型名。

**三、原生**  **JDK**  **网络编程**  **BIO**

传统的同步阻塞模型开发中， ServerSocket  负责绑定  IP  地址，启动监听端口； Socket  负责发起连接操作。连接成功后，双方通过输入和输出流进行同步阻塞式通信。

传统  BIO  通信模型：采用  BIO  通信模型的服务端，通常由一个独立的  Acceptor  线程负 责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链 路处理，处理完成后，通过输出流返回应答给客户端，线程销毁。即典型的一请求一应答模 型，同时数据的读取写入也必须阻塞在一个线程内等待其完成。 该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程 个数和客户端并发访问数呈 1:1 的正比关系， Java  中的线程也是比较宝贵的系统资源，线程 数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统最终就**死** **-** **掉** **-** **了** 。 为了改进这种一连接一线程的模型，我们可以使用线程池来管理这些线程，实现 1  个或 多个线程处理 N  个客户端的模型（但是底层还是使用的同步阻塞  I/O ），通常被称为 “ 伪异 步 I/O  模型 “ 。 我们知道，如果使用 CachedThreadPool  线程池（不限制线程数量，如果不清楚请参考 文首提供的文章），其实除了能自动帮我们管理线程（复用），看起来也就像是 1:1  的客户 端：线程数模型，而使用FixedThreadPool  我们就有效的控制了线程的最大数量，保证了系 统有限的资源的控制，实现了 N:M  的伪异步  I/O  模型。 但是，正因为限制了线程数量，如果发生读取数据较慢时（比如数据量大、网络传 输慢等），大量并发的情况下，其他接入的消息，只能一直等待，这就是最大的弊端。 如何使用，参见如下示例：

1、服务端代码：

public class Server {
    
        public static void main(String[] args) throws IOException {
            //服务端启动必备
            ServerSocket serverSocket = new ServerSocket();
            //表示服务端在哪个端口上监听
            serverSocket.bind(new InetSocketAddress(10001));
            System.out.println("Start Server ....");
            try{
                while(true){
                    new Thread(new ServerTask(serverSocket.accept())).start();
                }
            }finally {
                serverSocket.close();
            }
        }
    
        //每个和客户端的通信都会打包成一个任务，交个一个线程来执行
        private static class ServerTask implements Runnable{
    
            private Socket socket = null;
            public ServerTask(Socket socket){
                this.socket = socket;
            }
    
            @Override
            public void run() {
                //实例化与客户端通信的输入输出流
                try(ObjectInputStream inputStream =
                        new ObjectInputStream(socket.getInputStream());
                    ObjectOutputStream outputStream =
                        new ObjectOutputStream(socket.getOutputStream())){
    
                    //接收客户端的输出，也就是服务器的输入
                    String userName = inputStream.readUTF();
                    System.out.println("Accept client message:"+userName);
    
                    //服务器的输出，也就是客户端的输入
                    outputStream.writeUTF("Hello,"+userName);
                    outputStream.flush();
                }catch(Exception e){
                    e.printStackTrace();
                }finally {
                    try {
                        socket.close();
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
            }
        }
    }

2、客户端代码：

public class Client {
    
        public static void main(String[] args) throws IOException {
            //客户端启动必备
            Socket socket = null;
            //实例化与服务端通信的输入输出流
            ObjectOutputStream output = null;
            ObjectInputStream input = null;
            //服务器的通信地址
            InetSocketAddress addr
                    = new InetSocketAddress("127.0.0.1",10001);
    
            try{
                socket = new Socket();
                socket.connect(addr);//连接服务器
    
                output = new ObjectOutputStream(socket.getOutputStream());
                input = new ObjectInputStream(socket.getInputStream());
    
                /*向服务器输出请求*/
                output.writeUTF("Nandao");
                output.flush();
    
                //接收服务器的输出
                System.out.println(input.readUTF());
            }finally{
                if (socket!=null) socket.close();
                if (output!=null) output.close();
                if (input!=null) input.close();
            }
        }
    }

3、执行结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

**1、BIO** **应用****-RPC** **框架**

***为什么要有***  ***RPC*** ***？***

我们最开始开发的时候，一个应用一台机器，将所有功能都写在一起，比如说比较常见 的电商场景。 随着我们业务的发展，我们需要提示性能了，我们会怎么做？将不同的业务功能放到线 程里来实现异步和提升性能。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

但是业务越来越复杂，业务量越来越大，单个应用或者一台机器的资源是肯定背负不起 的，这个时候，我们会怎么做？将核心业务抽取出来，作为独立的服务，放到其他服务器上 或者形成集群。这个时候就会请出 RPC ，系统变为分布式的架构。 为什么说千万级流量分布式、微服务架构必备的 RPC  框架？和  LocalCall  的代码进行比较，因为引入 rpc  框架对我们现有的代码影响最小，同时又可以帮我们实现架构上的扩展。 现在的开源 rpc  框架，有什么？ dubbo ， grpc  等等 当服务越来越多，各种 rpc  之间的调用会越来越复杂，这个时候我们会引入中间件，比 如说 MQ 、缓存，同时架构上整体往微服务去迁移，引入了各种比如容器技术  docker ， DevOps 等等。最终会变为如图所示来应付千万级流量，但是不管怎样，rpc  总是会占有一席之地。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

***2、什么是***  ***RPC*** ***？***

RPC （ Remote Procedure Call  ——远程过程调用），它是一种通过网络从远程计算机程 序上请求服务，而不需要了解底层网络的技术。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

一次完整的  RPC  同步调用流程：

1 ）服务消费方（ client ）以本地调用方式调用客户端存根；

2 ）什么叫客户端存根？就是远程方法在本地的模拟对象，一样的也有方法名，也有方 法参数，client stub  接收到调用后负责将方法名、方法的参数等包装，并将包装后的信息通 过网络发送到服务端；

3 ）服务端收到消息后，交给代理存根在服务器的部分后进行解码为实际的方法名和参数；

4 ）  server stub  根据解码结果调用服务器上本地的实际服务；

5 ）本地服务执行并将结果返回给  server stub ；

6 ） server stub  将返回结果打包成消息并发送至消费方；

7 ） client stub  接收到消息，并进行解码；

8 ）服务消费方得到最终结果。

RPC  框架的目标就是要中间步骤都封装起来，让我们进行远程方法调用的时候感觉到就 像在本地调用一样。

***3、RPC***  ***和***  ***HTTP***

rpc  字面意思就是远程过程调用，只是对不同应用间相互调用的一种描述，一种思想。 具体怎么调用？实现方式可以是最直接的 tcp  通信，也可以是  http  方式，在很多的消息中间 件的技术书籍里，甚至还有使用消息中间件来实现 RPC  调用的，我们知道的  dubbo  是基于 tcp 通信的， gRPC  是  Google  公布的开源软件，基于最新的  HTTP2.0  协议，底层使用到了  Netty 框架的支持。所以总结来说，rpc  和  http  是完全两个不同层级的东西，他们之间并没有什么 可比性。

***4、实现***  ***RPC***  ***框架***

实现  RPC  框架需要解决的那些问题

*代理问题*

代理本质上是要解决什么问题？要解决的是被调用的服务本质上是远程的服务，但是调 用者不知道也不关心，调用者只要结果，具体的事情由代理的那个对象来负责这件事。既然 是远程代理，当然是要用代理模式了。 代理(Proxy) 是一种设计模式 , 即通过代理对象访问目标对象 . 这样做的好处是 : 可以在目 标对象实现的基础上, 增强额外的功能操作 , 即扩展目标对象的功能。那我们这里额外的功能 操作是干什么，通过网络访问远程服务。 jdk 的代理有两种实现方式：静态代理和动态代理。

*序列化问题*

序列化问题在计算机里具体是什么？我们的方法调用，有方法名，方法参数，这些可能 是字符串，可能是我们自己定义的 java  的类，但是在网络上传输或者保存在硬盘的时候， 网络或者硬盘并不认得什么字符串或者 javabean ，它只认得二进制的  01  串，怎么办？要进 行序列化，网络传输后要进行实际调用，就要把二进制的 01  串变回我们实际的  java  的类， 这个叫反序列化。java  里已经为我们提供了相关的机制  Serializable 。

*通信问题*

我们在用序列化把东西变成了可以在网络上传输的二进制的  01  串，但具体如何通过网 络传输？使用 JDK  为我们提供的  BIO 。

*登记的服务实例化*

登记的服务有可能在我们的系统中就是一个名字，怎么变成实际执行的对象实例，当然 是使用反射机制。

反射机制是什么？

反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对 于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用

对象的方法的功能称为  java  语言的反射机制。

反射机制能做什么

反射机制主要提供了以下功能：

•在运行时判断任意一个对象所属的类；

•在运行时构造任意一个类的对象；

•在运行时判断任意一个类所具有的成员变量和方法；

•在运行时调用任意一个对象的方法；

•生成动态代理。

最后成型的代码参见工程  ketang-v3-rpc

***四、实现后的思考***

Dubbo

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

在  Dubbo  里：

服务容器负责启动，加载，运行服务提供者。

服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者在启动时，向注册中心订阅自己所需的服务。

注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送 变更数据给消费者。

服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如 果调用失败，再选另一台调用。

服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数 据到监控中心。

我们的实现和  Dubbo  的比较可以看到

1、性能欠缺，表现在网络通信机制，序列化机制等等

2、负载均衡、容灾和集群功能很弱

3、服务的注册和发现机制也很差劲

Dubbo  和  SpringCloud  哪个更好

协议上比较： http  相对更规范，更标准，更通用，无论哪种语言都支持  http  协议。如果你是对外开放 API ，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的 支持，相应的，如果采用 http ，无疑在你实现  SDK  之前，支持了所有语言，所以，现在开 源中间件，基本最先支持的几个协议都包含 RESTful 。 RPC 协议性能要高的多，例如  Protobuf 、 Thrift 、 Kyro  等，（如果算上序列化）吞吐量大 概能达到 http  的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服 务做的比较好的，例如，netflix 、阿里，曾经都传出过为了提升性能而合并服务。

服务全面上比较：当然是  springloud  更胜一筹，但也就意味着在使用  springloud  上其实 更重量级一点，dubbo  目前版本专注于服务治理，使用上更轻量一点。 就国内的热度来说，如果我们看百度指数的查询结果，springloud  和  dubbo  几乎是半斤 八两，dubbo  相比起来还略胜一筹 总的来说对外开放的服务推荐采用 RESTful ，内部调用推荐采用  RPC  方式。当然不能一 概而论，还要看具体的业务场景。

到此，原生 JDK 网络编程 BIO分析完成，下篇我们分析NIO，敬请期待！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221024/5495a52c3002413ba93e56b50456ed83.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221024/27e5789181e0413b8c9441ad9b98757d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221024/43069195826e4fcf883cafb175f639fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221024/6cf6fbd0c0704efcb57588e3a4dc972d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221024/03e7aa9daac04520aadc87dc691226b8.png