Binder VS socket

 

【原创】【android】【Binder】2 Binder Vs Socket

标签： androidbinder

2014-10-05 11:39  569人阅读  评论(0)  收藏  举报

  分类：

android（5） 

版权声明：本文为博主原创文章，未经博主允许不得转载。

传输性能:

　　socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。

     消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区， 至少有两次拷贝过程。

     共享内存虽然无需拷贝，但控制复杂，难以使用。

表 1 各种IPC方式数据拷贝次数

IPC	数据拷贝次数
共享内存	0
Binder	1
Socket/管道/消息队列	2

 

安全性考虑:

　　 Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。 终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层设备导致电池很快耗尽等等。

     传统IPC没有任何 安全措施，完全依赖上层协议来确保。

     首先传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。 Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID， 但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。

     其次传统IPC访问接入点是开放的，无法建立私有通道。 比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法 阻止恶意程序通过猜测接收方地址获得连接。

　　基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。

     Binder基于 Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

传输数据量：

     socket TCP的传输方式 假如发送的数据过大，linux kernel 下面的TCP/IP stack 会重新分成小包发送的,对于应用程序来说，不需要关心数据大小。

     在UDP的方式下面，会由于 发送的数据大小超过了内核缓冲区的最大限制,这个限制好象是65535（默认情况下是64K），导致 UDP通信收不到包，阻塞在recvfrom()。

     1.UDP方式传输一段完整数据的大小时受内核缓冲区限制的，比如在默认情况下缓冲区大小是64K，所以对于该情况下的socket接收或者发送方，最大可以一次性发送一个64K的数据。而对于socket底层的具体实现是将64K的数据拆分成N个小数据包，内部提供机制保证数据的可靠性，例如每个包的大小为1K，则分成64个包，从服务器端发送到客户端，客户端在本地缓冲区重新组成完整的数据提交给用户。底层的实现方式应该各不相同，但是对于上层结果都是一样的。如果超过了缓冲区大小则无法完成组包出现丢包等等现象。同理，对于200K则可以发送接收200K大小的数据。

     binder的数据是有大小限制的，在传输的时候，会先把数据从binder client拷贝到内核，然后从内核拷贝到binder server,数据的大小貌似是：4M

参考文档：

【1】http://blog.csdn.net/gykimo/article/details/8901192   Android - Binder机制

【2】http://www.cnblogs.com/bastard/archive/2012/10/17/2728155.html Android为什么选择binder

【3】http://blog.csdn.net/l_serein/article/details/6589199 有关socket通信包大小的问题总结(UDP传输模式)