今天和小胡去参加了一个线下的活动，本来没抱着很大的兴趣，但是在听的过程中发现自己确实在技术的积累以及术语的积累上不够，虽然是移动端的东西，但是感觉原理上其实都相差不大，技术在不断发展，但是一些基础的东西其实更新的没有那么快，而且我觉得技术这东西，一旦入了门，用起来应该难度没有那么大，虽然它在日新月异的发展，但是万变不论其宗，现在关键是要逐步提高对各种基础知识的理解。只有基础打牢了，才能应对起来没有那么累。
其实自己对网络通信这块还比较好奇，想先从这一块入手，确实一个程序现在想起来无非就是这几块，基础语法，网络通信，数据库，多线程。再往深处拔高点就是高并发的优化问题了，比如今天所说的弱网优化，但是如果连基础的网络通信结构你都不是很清晰，又何谈优化呢？当然前面的都是一些偏后端的。
后面会从基础的开始，对自己对网络通信的理解写下来，今天搜了一下LPC和RPC的区别。想写一下这个。
本地函数调用，因为在同一个地址空间，或者说在同一块内存，所以通过方法栈和参数栈就可以实现。就是我们平常写的代码，一个计算器类，一个加法运算，直接声明调用就ok。
现在，基于高性能和高可靠等因素的考虑，你决定将系统改造为分布式应用，将很多可以共享的功能都单独拎出来，比如上面说到的计算器，你单独把它放到一个服务里头，让别的服务去调用它。这样就是基于服务的一种思想。
这下问题来了，服务A里头并没有CalculatorImpl这个类，那它要怎样调用服务B的CalculatorImpl的add方法呢？
有同学会说，可以模仿B/S架构的调用方式呀，在B服务暴露一个Restful接口，然后A服务通过调用这个Restful接口来间接调用CalculatorImpl的add方法。
很好，这已经很接近RPC了，不过如果是这样，那每次调用时，是不是都需要写一串发起http请求的代码呢？比如httpClient.sendRequest...之类的，能不能像本地调用一样，去发起远程调用，让使用者感知不到远程调用的过程呢，RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
RPC要解决两个问题：
解决分布式系统中，服务之间的调用问题。
远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
以上是RPC的一些基本概念。LPC则是本地过程调用，也是独立进程之间的通信。是微软整合了RPC的概念，Windows系统出于对自身性能的需要，调整了RPC的概念(或者让其狭义化了)，分化出了LPC的概念。LPC应该是现在我们所做的平台推出的一种新架构。比如说人员管理和设备管理，以及考勤和门禁等都是一个独立的进程（组件化）。先写这么多吧，晚安！
觉得最主要的还是说平台做大了，你不得不去改变，去适应客户的需求，技术为了市场服务，以实际需求为主，结合现有技术满足他们，这可能是一个软件工程师应该有的。
网友评论