三次握手、四次挥手
- 目的
- 是为了确认客户端和服务端建立可靠的通信通道。一方面，为了保证客户端和服务端能够正常接收和发送消息，另一方面，为了确认双方都支持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实现
-
异步非阻塞
-
生产者消费者模型
- 原理
- 这个模型主要通过一个容器来解决问题，叫阻塞队列。生产者生产出来东西不用给消费者，而是放到阻塞队列中，消费者不用去生产者那里去拿，而是直接到阻塞队列中去拿。解决了大多数并发问题。
- 为什么要用这个模型
- 在线程世界中，生产者就是生产数据的线程，消费者就是消费数据的线程。如果生产线程生产速度大于或者小于消费线程的消费速度，会降低效率，由此引入了个这！
- 如何实现
- 管道加锁、共享数据
- 原理