进程间通讯的几种假设

作者：陶宁,华清远见嵌入式学院上海中心讲师。

在学习网络的时候我经常会想一些实际的问题，设定各种常用的假设来让同学们尽量的明白其中的奥秘，下面是自己的一些理解：

假如：如果我这边是一个服务器，类似做一个聊天的服务，大家做一个事情就是每个人把想说的话发给我，然后我再发给其他人，同时其他人再做这件事情的话， 那么这个房间里的数据交换量应该是人数的平方，人数要是达到几千人，那么数据量就会很壮观。那么在这种情况下很困难。也可以用共享缓冲区来实现，但也会有一些问题，如：大家共享一个缓冲区，我接到数据后放到缓冲区中了，这个数据可以被大家所共享。正常的话应该维护着缓冲区还剩多少，但是如果发数据的时候，我给一个人发的比较快，发了100个字节，但另一个人发的比较慢，只发了50个字节，那么怎么去维护这个缓冲区呢，没办法了，因为整个缓冲区有无数个指向位置的指针，它表示着还有多少数据没有发，这样整个系统就被最后的那个指针拖慢了，解决办法就是检查最后一个人的位置的指针，然后把缓冲清掉，这是读。下面我们来看写，假设同一时刻有多个人在加锁（也就是在发数据），那么系统会越来越慢的。发的时候加锁的，同时如果加锁的时候一个没有处理完，那么其他人有可能都在加着锁，那系统会越来越慢的。

也就是说发过来的是加锁的，又读不了数据，每个人又是阻塞通讯的，读不了数据也就发不了数据，这样就造成了系统运行越来越慢，数据会越来越多，造成很多矛盾。所以这样数据交换就没有什么意义了。

结论：这种多进程在数据交换上很显然是不合适的。

假如：服务器能处理100000个请求（TCP），但是这个100000个请求都一直通讯或者偶尔通讯，但是通讯量都不是很大，比如聊QQ，持续时间都非常长，但数据量却很小而且是随机的，但TCP的资源消耗成本是非常高的，用TCP的话又得打开又得连接的，而UDP打开大门（端口），不需要3次握手，随便来即可，所以在这里就不太适合用TCP协议了。总的来说任何设备的处理能力是有限的，如果每个人都和服务器去TCP连接，那么服务器是受不了的，如：服务器的后台共享是非常痛苦的。