m0_71115526的博客

进程和线程的比较 1. 进程的开销比线程的开销大很多 2. 进程之间的数据是隔离的，但是，线程之间的数据不隔离 3. 多个进程之间的线程数据不共享----->还是让进程通信(IPC)------->进程下的线程也通信了---->队列 GIL全局解释器锁 Python在设计之初就考虑到要在主循环中，同时只有一个线程在执行。虽然 Python 解释器中可以“运行”多个线程，但在任意时刻只有一个线程在解释器中运行。 对Python解释器的访问由全局解释器锁(GI

加锁可以保证多个进程修改同一块数据时，同一时间只能有一个任务可以进行修改，即串行的修改，没错，速度是慢了，但牺牲了速度却保证了数据安全。虽然可以用文件共享数据实现进程间通信，但问题是：1.效率低（共享数据基于文件，而文件是硬盘上的数据）2.需要自己加锁处理因此我们最好找寻一种解决方案能够兼顾这两点的机制：这就是mutiprocessing模块为我们提供的基于消息的IPC通信机制：队列和管道。1 队列和管道都是将数据存放于内存中。

精简的说，操作系统就是一个协调、管理和控制计算机硬件资源和软件资源的控制程序。操作系统所处的位置如图操作系统位于计算机硬件与应用软件之间，本质也是一个软件。操作系统由操作系统的内核（运行于内核态，管理硬件资源）以及系统调用（运行于用户态，为应用程序员写的应用程序提供系统调用接口）两部分组成，所以，单纯的说操作系统是运行于内核态的，是不准确的。一：隐藏了丑陋的硬件调用接口，为应用程序员提供调用硬件资源的更好，更简单，更清晰的模型（系统调用接口）。

只有TCP有粘包现象，UDP永远不会粘包首先需要掌握一个socket收发消息的原理发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据，也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。

arp协议由来：计算机通信基本靠吼，即广播的方式，所有上层的包到最后都要封装上以太网头，然后通过以太网协议发送，在谈及以太网协议时候，我门了解到：通信是基于Mac的广播方式实现，计算机在发包时，获取自身的Mac是容易的，如何获取目标主机的Mac，就需要通过arp协议。网络层的由来：有了ethernet、Mac地址、广播的发送方式，世界上的计算机就可以彼此通信了，问题是世界范围的互联网是由 一个个彼此隔离的小的局域网组成的，那么如果所有的通信都采用以太网的广播方式，那么一台机器发送的包全世界都会收到。