Solo  当前访客:0 开始使用

Carson

记录精彩的程序人生

01操作系统与计算机网络 有更新!

2019-04-23 08:46:14 dulinanaaa
0  评论    166  浏览

进程和线程(非常重要)

区别和联系:

进程是资源分配的最小单位
线程是程序执行的最小单位

进程使用独立的数据空间
线程共享线程的数据空间

线程调度

简单了解几种线程调度算法就可以了

参考:进程调度算法总结

先来先服务调度(既可以作业调度,也可用于进程调度)

从就绪队列中选择一个最先进入该队列的进程,为之分配处理机,使之投入运行。该进程一直运行到完成或发生某事件而阻塞后才放弃处理机

最短作业优先调度

预计执行时间短的进程优先分派处理机。通常后来的短进程不抢先正在执行的进程

最高影响比优先调度

介于先来先服务调度和最短作业优先调度之间,不会因为先来先服务而影响了短作业的效率,也不会因为最短优先而影响长作业没有执行的机会

时间片轮转调度

011.jpg

优先级调度(用于作业调度)

  • 分为非抢占式优先权调度算法和抢占式优先权调度算法
    • 非抢占式优先权调度算法:系统一旦把处理机分配给优先权最高的进程后,便一直执行下去,至完成。
    • 抢占式优先权调度算法:只要系统中出现一个新的就绪进程,就进行优先权比较 。若出现优先权更高的进程,则立即停止当前执行,并将处理机分配给新到的优先权最高的进程。

多级反馈队列调度(进程调度)

多级中优先级不同,同级的多个作业中按照时间片轮转调度

线程切换步骤

线程的上下文切换,明白线程切换的代价

进程间通信(IPC)(面试中间件研发会经常被考查)

六种方式的原理和使用场景:(???)
Pipe
MessageQueue
共享内存
UnixSocket
Signal
Semaphore

进程间数据共享的场景,可以使用:共享内存
进程间数据交换的场景,可以使用:MessageQueue、UnixSocket

协程

漫画-协程

网上找的:有点类似CPU的中断、没有线程切换的开销(执行效率高)、没有多线程的锁机制(只是一个线程,共享次源不加锁,只需看状态就可以了)
协程更轻量化,是在用户态进行调度,切换的代价比线程上下文切换低很多
Java第三方协程框架:Kilim

Linux常用命令

考查线上问题的排查经验(???)
重点使用
awk
top
netstat
grep
less
tail

计算机网络

HTTP

了解Http的规范(知道协议的Method/Header/Cookies)
需要了解常用的状态码404 503 302
Https的交互流程
QUIC协议已经被标准化为Http3协议,是基于UDP协议的,但实现了类似TCPr 可靠性保障和流量控制

TCP

高频考点
三次握手建连
四次挥手断连
Nagel算法和ACK延迟
Keepalive:
长时间没有数据发送的场景下,TCP保持连接可用的机制
开启和设置方式
通过滑动窗口机制来实现流量控制的

传输是基于字节流而非报文,将数据按照字节大小进行编号,接收端通过ACK来确认收到的数据编号,通过这种机制来保证接收数据的有序性和完整性,因此TCP能够提供可靠性传输。
TCP还能提供流量控制能力,通过滑动窗口来控制数据的发送速率,滑动窗口的本质是动态缓冲区。接收区根据自己的处理能力在TCP的Header中动态调整窗口大小,通过ACK应答包通知给发送端,发送端通过窗口的大小来调整发送的速度

三次握手建连过程:

021.jpg

  1. 首先在建立连接前需要让Server端先监听端口。因此,Server端建立连接前的初始状态是listen状态
  2. 这时Client端准备建立连接,先发送一个SYN同步包,发送完同步包后,Client端的连接状态为syn_sent状态
  3. Server端收到SYN后,同意建立连接,会向Client端回复一个ACK,由于TCP是双工传输,Server端也会向Client端同时发送一个同步请求SYN,申请Server端向Client端建立连接。发送完ACK和SYN后,Server端的状态就变成了syn_rcvd(syn_received)
  4. Clinet收到Server的ACK后,Client的连接状态就变成了established的状态。同时,Client端向Server端发送ACK响应,回复Server端的SYN请求。
  5. Server端收到Client端的ACK后Server端的连接状态就变成了established的状态。
    此时,建连完成,双方随时进行数据传输。
  • 三次握手是为了建立双向连接
  • 需要记住Client端和Server端的连接状态变化
  • 回答SYN洪水冲击发生的原因:Server端在收到Client端的SYN请求后,发送了ACK和SYN,但是Client端不进行回复,导致Server端大量的连接处在syn_rcvd状态,进而影响其它正常请求的建连
  • 上面解决:可以设置Linux的TCP参数,syc_ack_retries=0来加快半连接的回收速度.或者调大max_syn_backlog来应对少量的SYN洪水攻击。
四次挥手断连过程:

022.jpg

首先通信的双方(Server和Client)起初都是established的状态
然后Client端先发起了关闭链接请求。Client端向Server端发起了一个FIN包,表示Clinet端已经没有数据要发送了,然后Client端就进入了fin_wait_1状态。
Server端收到FIN后,返回ACK。然后进入close_wait状态,此时,Server处于半关闭状态。因为此时Client向Server方向已经不会发起数据了,但是Server向Client可能还有数据要发送。当Server端数据发送完毕后,Server端会向Client端发送FIN,表示Server端也没有数据要发送了,这时,Server进入last_ack阶段,就等待Clinet端的应答就可以关闭连接了。
Client端收到Server端的FIN后,回复ACK,然后进入time_wait状态。time_wait状态下,需要等待两倍的MSL,就是最大报文段生存时间,来保证连接的可靠关闭,之后才会进入到closed状态
而Server端在收到ACK后就直接可以进入到closed状态。

  • 为什么要等待两倍的MSL之后才能关闭连接?
    原因有2个:
    1.要保证TCP协议的全双工连接能够可靠关闭
    2.要保证这次连接中重复的数据段能够从网络中消失,防止端口被重用的时候,可能会产生数据混淆
  • 大量Socket处于time_wait或者close_wait状态的问题?
    一般开启Linux的TCP参数tw-re-use和tw-re-cycle能够加快time_wait的回收
    而出现在量的close_wait状态,一般是被动关闭的一方,可能存在代码的bug,没有正确关闭连接所导致的

,
TOP