操作系统知识点

1.GET和POST的不同

• get参数通过url传递，post放在request body中。
• get请求在url中传递的参数是有长度限制的，而post没有。
• get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
• get请求只能进行url编码，而post支持多种编码方式
• get请求会浏览器主动cache，而post支持多种编码方式。
• get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。
• 本质都是tcp连接，但是GET一个数据包，POST两个数据包，会先发header再发data。

2.一次完整的web页面请求

• 打开网页
• 建立tcp连接（http是应用层协议，需要先建立tcp连接）
• 浏览器向服务器发送请求。
• 浏览器发送header信息。
• web服务器应答。
• web服务器发送应答头信息。
• web服务器发送数据。
• 发送完毕后web服务器关闭tcp连接，如果header里有keep-alive则保持连接。

3.DNS域名解析

• 客户端向dns服务器发送解析请求，dns服务器再自身缓存里查找，找不到就往上一层找。
• localdns：本地运营商的dns。
• httpdns：使用http协议向dns服务器53端口请求，代替dns协议。

4.TCP和UDP

• 确认和重传机制
• 建立连接时三次握手同步双方的“序列号 + 确认号 + 窗口大小信息”，是确认重传、流控的基础
• 传输过程中，如果Checksum校验失败、丢包或延时，发送端重传
• 数据排序：TCP有专门的序列号SN字段，可提供数据re-order
• 流量控制：窗口和计时器的使用。TCP窗口中会指明双方能够发送接收的最大数据量
• 拥塞控制

TCP的拥塞控制由4个核心算法组成。

• “慢启动”（Slow Start）
• “拥塞避免”（Congestion avoidance）
• “快速重传 ”（Fast Retransmit）
• “快速恢复”（Fast Recovery）

https：把数据进行非对称加密，然后客户端从第三方服务器获取证书（加密后的公钥）

http完整请求：建立tcp连接，发送http命令请求头，web服务器应答，关闭tcp连接

tcp：

三次握手：

• 客户端syn包
• 服务器syn+ack
• 客户端ack

缺陷：洪泛攻击

• 伪造客户端发送大量连接请求，服务器确认，真正的客户端不回复，造成浪费服务器资源。

解决办法：

• 监控无效链接
• 延缓tcb分配
• 防火墙
• 调短超时时间

四次挥手：

• 一方发起断开请求，并停止数据传输。
• 对方确认。
• 对方传输完剩余数据，并再次确认。
• 一方确认，断开连接。

5.短链接和长链接的特点以及应用在什么场合

长连接：

• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。
• 每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次挥手。
• 如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作后，下次操作时直接发送数据就可以了，不用再建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。

短连接：

• web网站的http服务一般都用短连接。因为长连接对于服务器来说要耗费一定的资源。像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但是每个用户又不需频繁操作的情况下需要短连接。总之：长连接和短连接的选择要根据需求而定。

6.进程和线程

进程：

• 一个程序至少有一个进程，一个进程至少有一个线程。
• 系统进行资源分配和调度的一个独立单位，有独立的内存单元。地址空间，全局变量，文件描述符，各种硬件等等资源
• 进程有独立的地址空间，所以崩溃后不会对其他进程造成影响。
• 进程切换需要保存上下文并切换，所以效率较低。使用中断完成。

线程：

• 线程是进程的一个实体,是CPU调度和分派的基本单位。
• 相同进程内的线程资源共享，独立的只有程序计数器、栈和一组寄存器。
• 一个线程可以创建和撤销另一个线程，同一个进程中的多个线程之间可以并发执行。
• 线程崩溃会导致进程崩溃，崩溃一般伴随栈溢出、读取或者访问了非法地址。
• 线程切换需要保存程序计数器和寄存器状态，切换效率比进程高。

并发和并行：

• 并行：多个线程或者进程同时运行。
• 并发：多个线程按时间来分配处理器资源，宏观上看是同时运行。

进程通信：

• 互斥量，同一时间只能由一个拥有互斥对象的线程访问资源。
• 信号量，实现进程互斥，可以设置最大同时访问的数量。互斥量就等于信号量设置为1。
• 管道，ipc机制，表现为一个只存在于内存中的文件，半双工通信。匿名管道，只能相关进程间通信，如父子兄弟进程。命名管道，无关进程间通信。
• 共享内存，进程资源独立，但是可以共享内存。
• 消息队列，rpc

线程同步：

• 临界区，串行访问公共资源，由于是公共资源，所以只能同步同一进程内的线程。
• 互斥量，同一时间只能由一个拥有互斥对象的线程访问资源。
• 信号量，实现进程互斥，可以设置最大同时访问的数量。互斥量就等于信号量设置为1。
• 事件，通过event来通知线程。

线程锁：

读写锁，可以多个线程共同读，只有一个线程可以写。

自旋锁，获取不到锁就循环查看锁是否释放。互斥锁获取不到会睡眠。

乐观锁悲观锁。

死锁：

• 互斥
• 占有且等待
• 不可抢占
• 循环等待

预防死锁

破坏上述条件

抢占资源，停止死锁进程。

银行家算法，实时统计进程和资源，只有资源够才分配。

7.消息队列和rpc

消息队列：

• 消息从某一端发出，在某个队列里存储，之后再由容器发到另一端。
• 作用，异步处理，应用解耦，流量削峰，进程通信。
• 模式，点对点，接受完应答后再从消息队列中删除消息。发布订阅模式，消息发到topic，然后由topic发给订阅者。
• AMQP，应用层高级消息队列协议。发布者发到exchange，exchange再将消息发送到queue。topic
• rabbitmq队列持久化，启动两个进程，一个存内存里，另一个内存不足时存到磁盘上。队列持久化。
• 消息确认机制，未确定会发给其他消费者，确认后再删除消息。
• zeromq，性能最好，消息只保存在内存里，但是请求应答一对一，不在乎消息丢失。不像一个消息队列服务器，更像一个底层网络通讯库。不是单独的服务或者程序，仅仅是一套组件，其封装了网络通信、消息队列、线程调度等功能，向上层提供简洁的API，应用程序通过加载库文件，调用API函数来实现高性能网络通信。

rpc：

• 远程过程调用，一台机器上的程序可以调用另一台机器上的程序。跨越了传输层和应用层，用于分布式服务的通信。
• rpc基于tcp/ip协议
• 内部子系统较多，接口非常多的情况下。rpc框架的好处，长链接，不需要跟HTTP一样每次三次握手，减少网络开销。rpc框架有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。

rpc架构：

• 客户端（Client），服务的调用方。
• 服务端（Server），真正的服务提供者。
• 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
• 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

rpc过程：

• 通讯问题，建立TCP连接传输数据
• 寻址问题
• 根据网络协议序列化成二进制数据
• 接收到数据后反序列化成内存中的传递方式
• 返回值返回的时候也经过序列化反序列化。
• 序列化：应用层对象转为二进制串。 反序列化：二进制串转换为应用层对象。

8.分布式系统

分布式系统保证操作的时序性、原子性，操作互斥。

分布式锁实现对共享资源的抢占。借鉴了多线程和多进程的互斥锁。

分布式锁实现：

• redis根据判断redis中是否有某个锁id，判断是否上锁。
• 设置超时时间防止死锁。
• redis去拿锁，不存在就设置锁并获得锁，存在的话判断是否超时，超时了才能拿到。各种实现方式大同小异。

9.SOA和微服务

• 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；
• 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
• 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

微服务需求：

• 能支持当前业务需求，当然这只是最最基本的条件；
• 每个微服务都要去中心化，不存在单点故障；
• 每个微服务都要实现高可用、高负载，不会因为一个服务不可用而影响了整套业务流；
• 每个微服务都要高度通用化，即多种终端都可调用，不分语言和平台；
• 服务部署或升级简单，不会消耗大量人力并且部署过程不易出现人为错误；
• 微服务具有快速注册与自动发现功能（例如dubbo框架）

10.websocket

• 基于tcp的全双工协议，持久化协议，用于服务端主动向客户端推送消息。轮询，心跳检测等。
• 一次握手即可建立永久连接。
• http协议可以通过keep-alive将多个http请求合成一个。
• websocket基于http协议，将http协议升级。

11.中断和系统调用

• 中断是指在CPU正常运行期间，由于内外部事件或由程序预先安排的事件引起的CPU暂时停止正在运行的程序，转而为该内部或外部事件或预先安排的事件服务的程序中去，服务完毕后再返回去继续运行被暂时中断的程序。Linux中通常分为外部中断（又叫硬件中断）和内部中断（又叫异常）。
• 系统调用通过中断实现，中断号为0x80，应用程序通过系统调用访问系统资源。
• 在用户态和内核态切换，栈切换和寄存器保存与恢复，比较耗时。
• 中断号——中断向量表——查找中断处理函数——处理。

12.session和cookie

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

需要浏览器支持并打开。

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

session_id放在header里

1. cookie数据存放在客户的浏览器上，session数据放在服务器上；
2. cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session；
3. session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE；
4. 单个cookie在客户端的限制是4K，就是说一个站点在客户端存放的COOKIE不能超过4K；