网络中的数据通信

网络中的数据通信

现在的互联网中使用的TCP/IP协议是基于OSI（开放系统互联）的七层参考模型的，（虽然不是完全符合）从上到下分别为：应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。其中数据链路层又可是分为两个子层，分别为逻辑链路控制层（Logic Link Control，LLC ）和介质访问控制层（(Media Access Control，MAC )，也就是平常说的MAC层。LLC对两个节点中的链路进行初始化，防止连接中断，保持可靠的通信。MAC层用来检验包含在每个桢中的地址信息。

首先分析一下在同一个网段的情况。假设有两台电脑分别命名为A和B，如果A需要向B发送数据，A主机首先把目标设备B的IP地址与自己的子网掩码进行“与”操作，以判断目标设备与自己是否位于同一网段内。如果目标设备在同一网段内，并且A没有获得与目标设备B的IP地址相对应的MAC地址信息，则源设备（A）以第二层广播的形式（目标MAC地址为全1）发送ARP请求报文，在ARP请求报文中包含了源设备（A）与目标设备（B）的IP地址。同一网段中的所有其他设备都可以收到并分析这个ARP请求报文，如果某设备发现报文中的目标IP地址与自己的IP地址相同，则它向源设备发回ARP响应报文，通过该报文使源设备获得目标设备的MAC地址信息。为了减少广播量，网络设备通过ARP表在缓存中保存IP与MAC地址的映射信息。在一次 ARP的请求与响应过程中，通信双方都把对方的MAC地址与IP地址的对应关系保存在各自的ARP表中，以在后续的通信中使用。ARP表使用老化机制，删除在一段时间内没有使用过的IP与MAC地址的映射关系。

两台计算机通过TCP/IP协议通讯的过程如下：

下面讨论两台不在同一个网段中的主机，假设网络中要从主机PC-A发送数据包PAC到PC-C主机中 。 PC-A并不需要获取远程主机（PC-C）的MAC地址，而是把IP分组发向缺省网关，由网关IP分组完成转发过程。如果源主机（PC-A）没有缺省网 关MAC地址的缓存记录，则它会通过ARP协议获取网关的MAC地址，因此在A的ARP表中只观察到网关的MAC地址记录，而观察不到远程主机的 MAC地址。在以太网(Ethernet)中，一个网络设备要和另一个网络设备进行直接通信，除了知道目标设备的网络层逻辑地址（如IP地址）外，还要知道目标设备的第二层物理地址(MAC地址)。ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。

上图对应两台计算机在同一网段中的情况，如果两台计算机在不同的网段中，那么数据从一台计算机到另一台计算机传输过程中要经过一个或多个路由器，如下所示：

链路层有以太网、令牌环网等标准，链路层负责网卡设备的驱动、帧同步（即从网线上检测到什么信号算作新帧的开始）、冲突检测（如果检测到冲突就自动重发）、数据差错校验等工作。交换机是工作在链路层的网络设备，可以在不同的链路层网络之间转发数据帧（比如十兆以太网和百兆以太网之间、以太网和令牌环网之间），由于不同链路层的帧格式不同，交换机要将进来的数据包拆掉链路层首部重新封装之后再转发。

网络层的IP协议是构成Internet的基础。Internet上的主机通过IP地址来标识，Internet上有大量路由器负责根据IP地址选择合适的路径转发数据包，数据包从Internet上的源主机到目的主机往往要经过十多个路由器。路由器是工作在第三层的网络设备，同时兼有交换机的功能，可以在不同的链路层接口之间转发数据包，因此路由器需要将进来的数据包拆掉网络层和链路层两层首部并重新封装。IP协议不保证传输的可靠性，数据包在传输过程中可能丢失，可靠性可以在上层协议或应用程序中提供支持。

网络层负责点到点（point-to-point）的传输（这里的“点”指主机或路由器），而传输层负责端到端（end-to-end）的传输（这里的“端”指源主机和目的主机）。传输层可选择TCP或UDP协议。

TCP是一种面向连接的、可靠的协议，有点像打电话，双方拿起电话互通身份之后就建立了连接，然后说话就行了，这边说的话那边保证听得到，并且是按说话的顺序听到的，说完话挂机断开连接。也就是说TCP传输的双方需要首先建立连接，之后由TCP协议保证数据收发的可靠性，丢失的数据包自动重发，上层应用程序收到的总是可靠的数据流，通讯之后关闭连接。

UDP是无连接的传输协议，不保证可靠性，有点像寄信，信写好放到邮筒里，既不能保证信件在邮递过程中不会丢失，也不能保证信件寄送顺序。使用UDP协议的应用程序需要自己完成丢包重发、消息排序等工作。

目的主机收到数据包后，如何经过各层协议栈最后到达应用程序呢？其过程如下图所示：

以太网驱动程序首先根据以太网首部中的“上层协议”字段确定该数据帧的有效载荷（payload，指除去协议首部之外实际传输的数据）是IP、ARP还是RARP协议的数据报，然后交给相应的协议处理。假如是IP数据报，IP协议再根据IP首部中的“上层协议”字段确定该数据报的有效载荷是TCP、UDP、ICMP还是IGMP，然后交给相应的协议处理。假如是TCP段或UDP段，TCP或UDP协议再根据TCP首部或UDP首部的“端口号”字段确定应该将应用层数据交给哪个用户进程。IP地址是标识网络中不同主机的地址，而端口号就是同一台主机上标识不同进程的地址，IP地址和端口号合起来标识网络中唯一的进程。

虽然IP、ARP和RARP数据报都需要以太网驱动程序来封装成帧，但是从功能上划分，ARP和RARP属于链路层，IP属于网络层。虽然ICMP、IGMP、TCP、UDP的数据都需要IP协议来封装成数据报，但是从功能上划分，ICMP、IGMP与IP同属于网络层，TCP和UDP属于传输层。

【知识补充】

（1）网关的含义

网关是说这样一种设备：如果主机要发包，就往这个设备发送。也就是说此设备要有路由功能或有去往外部网络的路径。在实际网络里，网关一般由路由器或Server充当。

（2）ARP(Address Resolution Protocol)是地址解析协议，ARP是一种将IP地址转化成物理地址的协议。从IP地址到物理地址的映射有两种方式：表格方式和非表格方式。ARP 具体说来就是将网络层（IP层，也就是相当于OSI的第三层）地址解析为数据链接层（MAC层，也就是相当于OSI的第二层）的MAC地址。ARP协议是通过IP地址来获得MAC地址的。

（3）网络中需要唯一的MAC地址的理由：

（a）IP地址的分配是根据网络的拓朴结构，而不是根据谁制造了网络设置。若将高效的路由选择方案建立在设备制造商的基础上而不是网络所处的拓朴位置基础上，这种方案是不可行的。

（b）当存在一个附加层的地址寻址时，设备更易于移动和维修。例如，如果一个以太网卡坏了，可以被更换，而无须取得一个新的IP地址。如果一个IP主机从一个网络移到另一个网络，可以给它一个新的IP地址，而无须换一个新的网卡。

（c）无论是局域网，还是广域网中的计算机之间的通信，最终都表现为将数据包从某种形式的链路上的初始节点出发，从一个节点传递到另一个节点，最终传送到目的节点。数据包在这些节点之间的移动都是由ARP，负责将IP地址映射到MAC地址上来完成的。

（4）标识网络中的一台计算机，一般至少有三种方法，最常用的是域名地址、IP地址和MAC地址，分别对应应用层、网络层、物理层。网络管理一般就是在网络层针对IP地址进行管理，但由于一台计算机的IP地址可以由用户自行设定，管理起来相对困难，MAC地址一般不可更改，所以把IP地址同MAC地址组合到一起管理就成为常见的管理方式。

（5）交换机和路由器的主要区别

工作层次不同

最初的的交换机是工作在 OSI／RM开放体系结构的数据链路层，也就是第二层，而路由器一开始就设计工作在OSI模型的网络层。由于交换机工作在 OSI的第二层（数据链路层），所以它的工作原理比较简单，而路由器工作在OSI的第三层（网络层），可以得到更多的协议信息，路由器可以做出更加智能的转发决策。

数据转发所依据的对象不同

交换机是利用物理地址或者说MAC地址来确定转发数据的目的地址。而路由器则是利用不同网络的ID号（即IP地址）来确定数据转发的地址。IP地址是在软件中实现的，描述的是设备所在的网络，有时第三层的地址也称为协议地址或者网络地址。MAC地址通常是硬件自带的，由网卡生产商来分配的，而且已经固化到了网卡中去，一般来说是不可更改的。而IP地址则通常由网络管理员或系统自动分配。

传统的交换机只能分割冲突域，不能分割广播域；而路由器可以分割广播域

由交换机连接的网段仍属于同一个广播域，广播数据包会在交换机连接的所有网段上传播，在某些情况下会导致通信拥挤和安全漏洞。连接到路由器上的网段会被分配成不同的广播域，广播数据不会穿过路由器。虽然第三层以上交换机具有VLAN功能，也可以分割广播域，但是各子广播域之间是不能通信交流的，它们之间的交流仍然需要路由器。

路由器提供了防火墙的服务，而交换机则没有

路由器仅仅转发特定地址的数据包，不传送不支持路由协议的数据包传送和未知目标网络数据包的传送，从而可以防止广播风暴。

各种远程通信协议分析与比较

基本原理

要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层层面去看，网络通信需要做的就是将数据流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，其中传输协议比较出名的有HTTP、TCP、UDP等，HTTP、TCP、UDP都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有BIO、NIO、AIO三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议。 

应用级协议

远程服务通讯，需要达到的目标是在一台计算机发起请求，另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端，这其中又会有诸如one way request、同步请求、异步请求等等请求方式，按照网络通信原理，需要实现这个需要做的就是将请求转换成流，通过传输协议传输至远端，远端计算机在接收到请求的流后进行处理，处理完毕后将结果转化为流，并通过传输协议返回给调用端。

但为了应用方便，业界推出了很多基于此原理之上的应用级协议，使得可以不用去直接操作这么底层的东西，通常应用级的远程通信协议会提供： 
1、为了避免直接做流操作，提供一种更加易用或贴合语言的标准传输格式； 
2、网络通信机制的实现，就是替你完成了将传输格式转化为流，通过某种传输协议传输至远端计算机，远端计算机在接收到流后转化为传输格式，并进行存储或以某种方式通知远端计算机。 

应用级的远程通信协议，在java领域中知名的有：RMI、XML-RPC、Binary- RPC、SOAP、CORBA、JMS，下面具体看看这些协议：

RMI

RMI 是个典型的为java定制的远程通信协议，我们都知道，在single vm中，我们可以通过直接调用java object instance来实现通信，那么在远程通信时，如果也能按照这种方式当然是最好了，这种远程通信的机制成为RPC（Remote Procedure Call），RMI正是朝着这个目标而诞生的。

来看下基于RMI的一次完整的远程通信过程的原理：

1、客户端发起请求，请求转交至RMI 客户端的stub类； 
2、stub类将请求的接口、方法、参数等信息进行序列化； 
3、基于socket将序列化后的流传输至服务器端； 
4、服务器端接收到流后转发至相应的 skelton类； 
5、skelton类将请求的信息反序列化后调用实际的处理类； 
6、处理类处理完毕后将结果返回给skelton类； 
7、Skelton类将结果序列化，通过socket将流传送给客户端的stub； 
8、stub在接收到流后反序列化，将反序列化后的Java Object返回给调用者。

来看jboss-remoting对于此过程的一个更好的图示：  

根据原理来回答下之前学习应用级协议带着的几个问题：

1、传输的标准格式是什么？ 
是Java ObjectStream。 
2、怎么样将请求转化为传输的流？ 
基于Java串行化机制将请求的java object信息转化为流。 
3、怎么接收和处理流？ 
根据采用的协议启动相应的监听端口，当有流进入后基于Java串行化机制将流进行反序列化，并根据RMI协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java串行化机制进行返回。 
4、传输协议是？ 
Socket。 

 XML-RPC

XML- RPC也是一种和RMI类似的远程调用的协议，它和RMI的不同之处在于它以标准的xml格式来定义请求的信息(请求的对象、方法、参数等)，这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。 
来看下XML-RPC协议的一次远程通信过程： 
1、客户端发起请求，按照XML-RPC协议将请求信息进行填充； 
2、填充完毕后将xml转化为流，通过传输协议进行传输； 
3、接收到在接收到流后转换为xml，按照XML- RPC协议获取请求的信息并进行处理； 
4、处理完毕后将结果按照XML-RPC协议写入xml中并返回。

图示以上过程： 

同样来回答问题：

1、传输的标准格式是？ 
标准格式的XML。 
2、怎么样将请求转化为传输的流？ 
将XML转化为流。 
3、怎么接收和处理流？ 
通过监听的端口获取到请求的流，转化为XML，并根据协议获取请求的信息，进行处理并将结果写入XML中返回。
4、传输协议是？ 
Http。

Binary-RPC

Binary- RPC看名字就知道和XML-RPC是差不多的了，不同之处仅在于传输的标准格式由XML转为了二进制的格式。 
同样来回答问题： 
1、传输 的标准格式是？ 
标准格式的二进制文件。 
2、怎么样将请求转化为传输的流？ 
将二进制格式文件转化为流。 
3、 怎么接收和处理流？ 
通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行处理并将结果写入二进制文件中返回。 
4、 传输协议是？ 
Http。  

 SOAP 
SOAP 原意为Simple Object Access Protocol，是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议，可以认为SOAP是XML RPC的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML规范不同，SOAP也是Webservice采用的服务调用协议标准，因此在此就不多加阐述了。 

CORBA 
Common Object Request Broker Architecture（公用对象请求代理[调度]程序体系结构），是一组用来定义“分布式对象系统”的标准，由OMG(Object Menagement Group)作为发起和标准制定单位。CORBA的目的是定义一套协议，符合这个协议的对象可以互相交互，不论它们是用什么样的语言写的，不论它们运行于什么样的机器和操作系统。 
CORBA在我看来是个类似于SOA的体系架构，涵盖可选的远程通信协议，但其本身不能列入通信协议这里来讲，而且 CORBA基本淘汰，在此就不进行阐述了。

JMS

JMS是实现java领域远程通信的一种手段和方法，基于JMS实现远程通信时和RPC是不同的，虽然可以做到RPC的效果，但因为不是从协议级别定义的，因此不认为JMS是个RPC协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS的东西，可以统一的将这类机制称为消息机制，而消息机制通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错。

来看JMS中的一次远程通信的过 程： 
1、客户端将请求转化为符合JMS规定的Message； 
2、通过JMS API将Message放入JMS Queue或Topic中； 
3、如为JMS Queue，则发送中相应的目标Queue中，如为Topic，则发送给订阅了此Topic的JMS Queue。 
4、处理端则通过轮训JMS Queue，来获取消息，接收到消息后根据JMS协议来解析Message并处理。

回答问题： 
1、传输的标准格式是？ 
JMS规定的Message。 
2、怎么样将请求转化为传输的流？ 
将参数信息放入Message中即可。 
3、怎么接收和处理流？ 
轮训JMS Queue来接收Message，接收到后进行处理，处理完毕后仍然是以Message的方式放入Queue中发送或Multicast。 
4、传 输协议是？ 
不限。 
基于JMS也是常用的实现远程异步调用的方法之一。 

JBoss-Remoting

Jboss- remoting是由jboss编写的一个java领域的远程通讯框架，基于此框架，可以很简单的实现基于多种传输协议的java对象的RPC。

回答问题： 
1、是基于什么协议实现的？ 
JBoss-Remoting是个通讯框架，因此它支持多种协议方式的通信，例如纯粹的socket+io方式、rmi方式、http+io方式等。 
2、 怎么发起请求？ 
在JBoss-Remoting中，只需将需要发起的请求参数对象传入jboss-remoting的InvocationRequest对象即可，也可根据协议基于InvocationRequest封装符合需求的InvocationRequest对象。 
3、怎么将请求转化为符合协议的格式 的？ 
JBoss-Remoting基于Java串行化机制或JBoss自己的串行化实现来将请求转化为对象字节流。 
4、使用 什么传输协议传输？ 
支持多种传输协议，例如Socket、HTTP等。 
5、响应端基于什么机制来接收请求？ 
响应端只需将自己的处理对象注册到JBoss-Remoting提供的Server端的Connector对象中即可。 
6、怎么将流还原为传输格式的？ 
JBoss-Remoting基于java串行化机制或jboss自己的串行化实现来将请求信息还原为java对象。 
7、处理完毕后怎么回应？ 
处理完毕后将结果对象直接返回即可，jboss-remoting会将此对象按照协议进行序列化，返回至调用端。

另外，jboss- remoting支持多种通信方式，例如同步/异步/单向通信等。 

Spring-Remoting

Spring- remoting是Spring提供java领域的远程通讯框架，基于此框架，同样也可以很简单的将普通的spring bean以某种远程协议的方式来发布，同样也可以配置spring bean为远程调用的bean。

1、是基于什么协议实现的？ 
和JBoss-Remoting一样，作为一个远程通讯的框架，Spring通过集成多种远程通讯的Library，从而实现了对多种协议的支持，例如 rmi、http+io、xml-rpc、binary-rpc等。 
2、怎么发起请求？ 
在Spring中，由于其对于远程调用的bean采用的是proxy实现，发起请求完全是通过服务接口调用的方式。 
3、怎么将请求转化为符合协议的格式的？ 
Spring按照协议方式将请求的对象信息转化为流，例如Spring Http Invoker是基于Spring自己定义的一个协议来实现的，传输协议上采用的为http，请求信息是基于java串行化机制转化为流进行传输。 
4、使用什么传输协议传输？ 
支持多种传输协议，例如RMI、HTTP等。 
5、响应端基于什么机制来接收请求？ 
响应端遵循协议方式来接收请求，对于使用者而言，则只需通过Spring的配置方式将普通的Spring Bean配置为响应端或者说提供服务端。 
6、 怎么将流还原为传输格式的？ 
按照协议方式来进行还原。 
7、处理完毕后怎么回应？ 
处理完毕后直接返回即可，spring-remoting将根据协议方式来做相应的序列化。 

Hessian

Hessian 是由caucho提供的一个基于binary-RPC实现的远程通讯Library。 
1、是基于什么协议实现的？ 
基于Binary-RPC协议实现。 
2、怎么发起请求？ 
需通过Hessian本身提供的API来发起请求。 
3、怎么将请求转化为符合协议的格式的？ 
Hessian通过其自定义的串行化机制将请求信息进行序列化，产生二进制流。 
4、使用什么传输协议传输？ 
Hessian基于HTTP协议进行传输。 
5、响应端基于什么机制来接收请求？ 
响应端根据Hessian提供的API来接收请求。 
6、怎么将流还原为传输格式的？ 
Hessian根据其私有的串行化机制来将请求信息进行反序列化，传递给使用者时已是相应的请求信息对象了。 
7、处理完毕后怎么回应？ 
处理完毕后直接返回，Hessian将结果对象进行序列化，传输至调用端。 

Burlap

Burlap 也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC协议的。 
1、是基于什么协议实现的？ 
基于XML-RPC协议实现。 
2、怎么发起请求？ 
根据Burlap提供的API。 
3、怎么将请求转化为符合协议的格 式的？ 
将请求信息转化为符合协议的XML格式，转化为流进行传输。 
4、使用什么传输协议传输？ 
Http协议。 
5、响应端基于什么机制来接收请求？ 
监听Http请求。 
6、怎么将流还原为传输格式的？ 
根据XML-RPC协议进行还原。 
7、处理完毕后怎么回应？ 
返回结果写入XML中，由Burlap返回至调用端。 

XFire、 Axis

XFire、Axis是Webservice的实现框架，WebService可算是一个完整的SOA架构实现标准了，因此采用 XFire、Axis这些也就意味着是采用webservice方式了。 
1、是基于什么协议实现的？ 
基于SOAP协议。 
2、 怎么发起请求？ 
获取到远端service的proxy后直接调用。 
3、怎么将请求转化为符合协议的格式的？ 
将请求信息转化为遵循SOAP协议的XML格式，由框架转化为流进行传输。 
4、使用什么传输协议传输？ 
HTTP协议。 
5、 响应端基于什么机制来接收请求？ 
监听HTTP请求。 
6、怎么将流还原为传输格式的？ 
根据SOAP协议进行还原。 
7、处理完毕后怎么回应？ 
返回结果写入XML中，由框架返回至调用端。 

ActiveMQ

ActiveMQ 是JMS的实现，基于JMS这类消息机制实现远程通讯是一种不错的选择，毕竟消息机制本身的功能使得基于它可以很容易的去实现同步/异步/单向调用等，而且消息机制从容错角度上来说也是个不错的选择，这是Erlang能够做到容错的重要基础。 
1、是基于什么协议实现的？ 
基于JMS协议。 
2、怎么发起请求？ 
遵循JMS API发起请求。 
3、怎么将请求转化为符合协议的格式的？ 
应该是二进制流（不确定）。 
4、使用什么传输协议传输？ 
支持多种传输协议，例如socket、http等等。 
5、 响应端基于什么机制来接收请求？ 
监听符合协议的端口。 
6、怎么将流还原为传输格式的？ 
同问题3。 
7、 处理完毕后怎么回应？ 
遵循JMS API生成消息，并写入JMS Queue中。 、

基于JMS此类机制实现远程通讯的例子有 Spring-Intergration、Mule、Lingo等等。 

Mina

Mina 是Apache提供的通讯框架，在之前一直没有提到网络IO这块，之前提及的框架或Library基本都是基于BIO的，而Mina是采用NIO 的，NIO在并发量增长时对比BIO而言会有明显的性能提升，而java性能的提升，与其NIO这块与OS的紧密结合是有不小的关系的。

1、是基于什么协议实现的？ 
基于纯粹的Socket+NIO。 
2、怎么发起请求？ 
通过Mina提供的Client API。 
3、怎么将请求转化为符合协议的格式的？ 
Mina遵循java串行化机制对请求对象进行序列化。 
4、使用什么传输协议传输？ 
支持多种传输协议，例如Socket、HTTP等等。 
5、响应端基于什么机制来接收请求？ 
以NIO的方式监听协议端口。 
6、 怎么将流还原为传输格式的？ 
遵循Java串行化机制对请求对象进行反序列化。 
7、处理完毕后怎么回应？ 
遵循Mina API进行返回。 
MINA是NIO方式的，因此支持异步调用是毫无悬念的。 

EJB

EJB 最突出的在于其分布式，EJB采用的是ORMI协议，和RMI协议是差不多的，但EJB在分布式通讯的安全控制、transport pool、smart proxy等方面的突出使得其在分布式领域是不可忽视的力量。 
1、是基于什么协议实现的？ 
基于ORMI协议。 
2、怎么发起请求？ 
EJB调用。 
3、怎么将请求转化为符合协议的格式的？ 
遵循java串行化机制对请求对象进行序列化。 
4、使用什么传输协议传输？ 
Socket。 
5、响应端基于什么机制来接收请求？ 
监听协议端口。 
6、怎么将流还原为传输格式的？ 
遵循java串行化机制对请求对象进行反序列化。 
7、处理完毕后怎么回应？ 
直接返回处理对象即可。 

【JBOSS的JNDI的实现】

在将对象实例绑定到jboss jnp server后，当远程端采用context.lookup()方式获取远程对象实例并开始调用时，jboss jndi的实现方法是从jnp server上获取对象实例，将其序列化回本地，然后在本地进行反序列化，之后在本地进行类调用。

通过这个机制就可以知道，本地其实是必须有绑定到jboss上的对象实例的class的，否则反序列化的时候肯定就失败了，而远程通讯需要做到的是在远程执行某动作，并获取到相应的结果，可见纯粹基于JNDI是无法实现远程通讯的。

但JNDI也是实现分布式服务框架一个很关键的技术点，因为可以通过它来实现透明化的远端和本地调用，就像 EJB，另外它也是个很好的隐藏实际部署机制（就像datasource）等的方案。

总结

由上一系列的分析可知，在远程通讯领域中，涉及的知识点还是相当的多的，例如有：通信协议(Socket/tcp/http/udp /rmi/xml-rpc etc.)、消息机制、网络IO（BIO/NIO/AIO）、MultiThread、本地调用与远程调用的透明化方案（涉及java classloader、Dynamic Proxy、Unit Test etc.）、异步与同步调用、网络通信处理机制（自动重连、广播、异常、池处理等）、Java Serialization (各种协议的私有序列化机制等)、各种框架的实现原理（传输格式、如何将传输格式转化为流的、如何将请求信息转化为传输格式的、如何接收流的、如何将流还原为传输格式的等等），要精通其中的哪些东西，得根据实际需求来决定，只有在了解了原理的情况下才能很容易的做出选择，甚至可以根据需求做私有的远程通讯协议。

参考链接1：https://blog.csdn.net/zxy131072/article/details/90373442

参考链接2：https://www.cnblogs.com/cyruswang/p/4577295.html

参考链接3：https://www.cnblogs.com/zkwarrior/p/5939213.html