网络编程
三次握手、四次挥手
- 目的
- 是为了确认客户端和服务端建立可靠的通信通道。一方面,为了保证客户端和服务端能够正常接收和发送消息,另一方面,为了确认双方都支持tcp协议,使用tcp传输
- 三次握手
- 客户端请求连接
- 服务端同意连接,请求连接客户端
- 客户端同意连接
- 四次挥手
- 客户端请求断开连接
- 服务端同意断开连接
- 服务端请求断开连接
- 客户端同意断开
-
GIL锁
- 在一个进程中存在多个线程时,每个线程在执行任务时,GIL锁每次会锁一个线程,当被锁的线程遇见IO操作时,这个锁就会解开,自动锁住另外一个线程,依次执行。
-
TCP、UDP
- 区别
- a.tcp协议安全可靠、面向连接、字节流形式传输,udp协议不安全可靠、不面向连接、但是传输效率高
- b.tcp协议不允许同时和多个客户端连接,udp允许同时连接多个客户端
- 流程
- tcp
- 俩端创建套接字,绑定服务(ip+port),监听,等待连接(三次连接),通信,关闭客户端套接字,关闭服务器套接字
- udp
- 俩端创建套接字,绑定服务,通信,关闭套接字
- tcp
- 区别
-
ARP协议
- Address Reslution Protocol,地址解析协议,通过ip地址解析得到mac地址。
-
粘包
- 粘包原因
- 一方面,客户端和服务端的收发数据大小不一致造成粘包
- 客户端发送了少量数据,时间间隔短,所以nagle算法帮我们整合了,此时服务端不知道要接收多少,造成粘包;客户端发送了大量数据,服务端不知道要接受多少,造成数据混乱
- 另一方面,是合包机制、nagle算法没有提供合理的拆包机制,造成粘包
- 一方面,客户端和服务端的收发数据大小不一致造成粘包
- 解决方法
- 最简单的方式就是短连接,收发一个数据包之后就断开连接,想要继续发送继续连接,再断开这样,但是,这样效率太低
- 解决粘包本质是获取发送数据的大小。可以先获取文件大小,然后把文件大小放到字典里,把字典发过去。这样服务端就知道包的的大小,不会造成混乱。
- 如果连续发送两个100字节的数据,肯定造成粘包,可以在俩send加recv,收到一个success即可!
- 粘包原因
-
OSI7层协议
-
操作系统作用
- 隐藏丑陋的硬件接口,提供良好的抽象接口
- 管理、调度进程
-
栈、消息队列
-
并发、并行
- 并发:宏观上多个任务一起执行
- 并行:微观上几个任务时时刻刻都在同时工作
-
socket的理解
-
多线程、多进程、协程
- 多进程
- 进程是计算机资源分配的最小单元
- 多线程
- 线程时cpu调度的最小单元
- 协程
- 多进程
-
进程的小概念
- 进程同步部分---锁、信号量、事件
- 锁
- 为了避免一端代码被多个进程同时执行。虽然加锁效率低了,但为了安全,必须加锁
- 信号量
- 锁
- 进程之间数据共享---队列、管道、manager
- 进程池
- 进程同步部分---锁、信号量、事件
-
IO多路复用
- 原理:指单个进程可以同时监听多个IO操作。例如同时监听多个文件句柄,socket对象一旦发送或者接受对象,文件句柄出现变化就会立刻感知到。
- 实现:使用select,poll,epoll实现
-
异步非阻塞
-
生产者消费者模型
- 原理
- 这个模型主要通过一个容器来解决问题,叫阻塞队列。生产者生产出来东西不用给消费者,而是放到阻塞队列中,消费者不用去生产者那里去拿,而是直接到阻塞队列中去拿。解决了大多数并发问题。
- 为什么要用这个模型
- 在线程世界中,生产者就是生产数据的线程,消费者就是消费数据的线程。如果生产线程生产速度大于或者小于消费线程的消费速度,会降低效率,由此引入了个这!
- 如何实现
- 管道加锁、共享数据
- 原理