前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >计网 & OS

计网 & OS

作者头像
小简
发布2022-12-29 10:18:37
8210
发布2022-12-29 10:18:37
举报
文章被收录于专栏:简言之

计网

①网络分层

②TCP

❶三次握手

  1. 第一次握手:客户端向服务端发起建立连接请求,客户端会随机生成一个起始序列号x,客户端向服务端发送数据包(包含标志位SYN=1,序列号seq=x)。
    • 第一次握手前客户端的状态为CLOSE,第一次握手后客户端的状态为SYN-SEND。此时服务端的状态为LISTEN
  2. 第二次握手:服务端在收到客户端发来的报文后,会随机生成一个服务端的起始序列号y,然后给客户端回复一段报文(包括标志位SYN=1ACK=1,序列号seq=y,确认号ack=x+1)。(其中SYN=1表示要和客户端建立一个连接,ACK=1表示确认序号有效)
    • 第二次握手前服务端的状态为LISTEN,第二次握手后服务端的状态为SYN-RCVD,此时客户端的状态为SYN-SENT
  3. 第三次握手:客户端收到服务端发来的报文后,会再向服务端发送报文(包含标志位ACK=1,序列号seq=x+1,确认号ack=y+1)。
    • 第三次握手前客户端的状态为SYN-SENT,第三次握手后客户端和服务端的状态都为ESTABLISHED此时连接建立完成,客户端和服务端就可以传输数据啦。

参考:程序员大彬 (topjavaer.cn)

❷为什么要三次握手?

两次握手可以吗?

三次握手的目的是建立可靠的通信信道,即双方确认自己与对方的发送与接收是否正常。

Client

Server

第一次握手

什么都不能确认

对方发送正常,自己接收正常

第二次握手

自己发送、接收正常;对方发送、接收正常

对方发送正常,自己接收正常

第三次握手

自己发送、接收正常;对方发送、接收正常

自己发送、接收正常,对方发送、接收正常

两次握手的话服务端无法确认自己发送和对方接收是否正常,三次握手就能确认双发收发功能都正常,缺一不可。

即第三次握手防止了已失效的连接请求报文段突然又传输到了服务端。

❸四次挥手

  1. 第一次挥手:客户端向服务端连接释放报文段(FIN=1,seq=u),进入FIN-WAIT-1(终止等待1)状态。
  2. 第二次挥手:服务端收到连接释放报文段后发出确认报文段(ACK=1,ack=u+1,seq=v),服务端进入CLOSE-WAIT(关闭等待)状态,客户端进入FIN-WAIT-2(终止等待2)状态,此时的TCP处于半关闭状态,客户端到服务端的连接释放。
  3. 第三次挥手:服务端发送完数据,就会发出连接释放报文段(FIN=1,ACK=1,seq=w,ack=u+1),服务端进入LAST-ACK(最后确认)状态,等待客户端的确认。
  4. 第四次挥手:客户端收到服务端的连接释放报文段后,发出确认报文段(ACK=1,seq=u+1,ack=w+1),客户端进入TIME-WAIT(时间等待)状态。服务端收到客户端发出的确认报文段后关闭连接,进入CLOSED状态。如果客户端等待 2MSL(最大报文段生存时间) 后依然没有收到回复,就证明服务端已正常关闭,客户端才进入CLOSED状态。

❹TCP 与 UDP 的区别

  • 是否面向连接
    • UDP是无连接的,在传送数据之前不需要先建立连接。
    • TCP 面向连接,在传送数据之前必须先建立连接,数据传送结束后要释放连接。
  • 是否是可靠传输
    • 主机收到 UDP 报文后,不需要给出任何确认,并且不保证数据不丢失,不保证是否顺序到达。
    • TCP 提供可靠的传输服务,TCP 在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据,无差错、不丢失、不重复、并且按序到达。
  • 传输效率 :由于 TCP 进行传输的时候多了连接、确认、重传等机制,所以 TCP 的传输效率要比 UDP 低很多。
  • 传输形式 : TCP 是面向字节流的,UDP 是面向报文的。
  • 首部开销 :TCP 首部开销(20 ~ 60 字节)比 UDP 首部开销(8 字节)要大。
  • 是否提供广播或多播服务 :TCP 只支持点对点通信,UDP 支持一对一、一对多、多对一、多对多;

TCP

UDP

是否面向连接

是否可靠

是否有状态

传输效率

较慢

较快

传输形式

字节流

数据报文段

首部开销

20 ~ 60 bytes

8 bytes

广播或多播

❺使用 TCP 的协议有哪些?

基于TCP的应用层协议有:HTTP、 FTP、 SMTP、POP3/IMAP、 TELNET、SSH

协议

名称

默认端口

功能

HTTP

超文本传输协议

80

Web 浏览器与 Web 服务器通信

FTP

文件传输协议

20、21

提供文件传输服务

SMTP

简单邮件传输协议

25

用来发送电子邮件

POP3/IMAP

邮件接收协议

110/143

负责邮件接收的协议

TELNET

远程登陆协议

23

远程登录会话,被SSH取代

SSH

安全外壳协议

22

专为远程登录会话和其他网络服务提供安全性的协议

❻使用 UDP 的协议有哪些?

基于UDP的应用层协议:DHCP、DNS

  • DHCP:动态主机配置协议,用来动态配置 IP 地址,默认端口68
  • DNS:域名解析协议,将域名转换为 IP 地址,默认端口53

❼TCP 如何保证传输的可靠性?

  • 首先,TCP的连接是基于三次握手,而断开则是基于四次挥手。确保连接和断开的可靠性。
  • 其次,还体现在有状态;TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
  • 再次,还体现在可控制。它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制

流量控制 : 当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议(TCP 利用滑动窗口实现流量控制)。

拥塞控制 : 当网络拥塞时,减少数据的发送。

拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。

流量控制往往是点对点通信量的控制,是个端到端的问题。抑制发送端发送数据的速率,以便接收端来得及接收。

❽TCP 如何实现流量控制?

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

❾TCP 的拥塞控制是怎么实现的?

拥塞:在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。

为了进行拥塞控制,TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法,即 慢开始拥塞避免快重传快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。

  • 慢开始: 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1,每经过一个传播轮次,cwnd 加倍。
  • 拥塞避免: 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大,即每经过一个往返时间 RTT 就把发送放的 cwnd 加 1.
  • 快重传:有时个别报文段会在网络中丢失,但实际上网络并未发生拥塞。如果发送方迟迟收不到确认,就会产生超时,就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始,把拥塞窗口cwnd又设置为1,因而 降低了传输效率。快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认,使发送方及早知道有报文段没有到达对方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%。
  • 快恢复: 当发送方连续收到三个重复确认,就会把慢开始门限ssthresh减半,接着把cwnd值设置为慢开始门限 ssthresh减半后的数值,然后开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大。在采用快恢复算法时,慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。

③HTTP

❶从输入URL 到页面展示的过程

  1. DNS 解析

因为浏览器不能直接通过域名找到对应的服务器 IP 地址,所以需进行 DNS 解析,查找到对应的 IP 地址进行访问。

  1. TCP 连接

当浏览器获取到服务器的 IP 地址后,浏览器会用一个随机的端口(1024 < 端口 < 65535)向服务器 80 端口发起 TCP 连接请求(注:HTTP 默认约定 80 端口,HTTPS 为 443 端口)。这个连接请求到达服务端后,通过 TCP 三次握手,建立 TCP 的连接。

  1. 发送 HTTP / HTTPS 请求(建立 TLS 连接)

建立连接后就可以通过 HTTP 进行数据传输。如果使用 HTTPS,会在 TCP 与 HTTP 之间多添加一层协议做加密及认证的服务。HTTPS 使用 SSL(Secure Socket Layer) 和 TLS(Transport Layer Security) 协议,保障了信息的安全。

  1. 服务器处理请求并返回 HTTP 报文

服务器收到请求后,将发回一个 HTTP 响应报文,内容包括相关响应头和 HTML 正文。

  1. 浏览器解析渲染页面

浏览器在收到HTML,CSS,JS文件后,渲染页面呈现到屏幕上

  1. HTTP 请求结束,断开 TCP 连接

现在的页面为了优化请求的耗时,默认都会开启持久连接(keep-alive),那么一个 TCP 连接确切关闭的时机,是这个 tab 标签页关闭的时候。这个关闭的过程就是四次挥手

参考:浏览器从输入网址到页面展示的过程

❷SSL/TLS

SSL/TLS是一种密码通信框架,他是世界上使用最广泛的密码通信方法。SSL/TLS综合运用了密码学中的对称密码,消息认证码,公钥密码,数字签名,伪随机数生成器等。

SSL(Secure Socket Layer)安全套接层,是1994年由Netscape公司设计的一套协议,并与1995年发布了3.0版本。

TLS(Transport Layer Security)传输层安全是IETF在SSL3.0基础上设计的协议,相当于SSL的后续版本。

TLS主要分为两层,

  • 底层是TLS记录协议,负责消息的压缩,加密及认证
  • 上层是TLS握手协议,主要分为握手协议,密码规格变更协议和应用数据协议4个部分。
    • 1.握手协议:负责在客户端和服务器端商定密码算法和共享密钥,包括证书认证
    • 2.密码规格变更协议:负责向通信对象传达变更密码方式的信号
    • 3.警告协议:负责在发生错误的时候将错误传达给对方
    • 4.应用数据协议:负责将TLS承载的应用数据传达给通信对象的协议。

❸HTTP 和 HTTPS 有什么区别

  • 端口号 :HTTP 默认是 80,HTTPS 默认是 443。
  • URL 前缀 :HTTP 的 URL 前缀是 http://,HTTPS 的 URL 前缀是 https://
  • 安全性和资源消耗 :HTTP 安全性没有 HTTPS 高,但 HTTPS 比 HTTP 耗费更多服务器资源且响应速度更慢。
    • HTTP 协议运行在 TCP 之上,所有传输的内容都是明文。客户端和服务器端都无法验证对方的身份。
    • HTTP 协议运行在 SSL 之上,SSL/TLS 运行在 TCP 之上,HTTPS = (SSL/TLS + HTTP),SSL/TLS依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。加密采用对称加密,但对称加密的密钥用服务器方的证书进行非对称加密。
    • HTTP 使用 TCP 三次握手建立连接,客户端和服务器需要交换 3 个包。
    • HTTPS除了 TCP 的三个包,还要加上 SSL 握手需要的 9 个包,所以一共是 12 个包。

➍HTTP 1.0 、1.1、 2.0、3.0区别

⓵HTTP 1.0——1996

1.0的HTTP版本,是一种无状态,无连接的应用层协议。

特点:

  • 短连接:HTTP1.0规定浏览器和服务器保持短暂的链接
  • 无连接:浏览器每次请求都需要与服务器建立一个TCP连接,服务器处理完成以后立即断开TCP连接
  • 无状态:服务器不跟踪每个客户,也不记录过去的请求,借助cookie/session机制来做身份认证和状态记录。
  • 无法复用连接:每次发送请求,都需要进行一次TCP连接,而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
  • 队头阻塞:HTTP1.0规定下一个请求必须在前一个请求响应到达之后才能发送,假设前一个请求响应一直不到达,那么下一个请求就不发送,后面的请求就阻塞了。
  • 不支持断点续传:也就是说,每次都会传送全部的页面和数据。
⓶HTTP 1.1——1999

HTTP1.1继承了HTTP1.0,克服了HTTP1.0性能上的问题。

  • 长连接:HTTP1.1增加Connection字段,通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接,可以在请求头中携带Connection:false来告知服务器关闭请求。
  • 支持断点续传:通过使用请求头中的 Range 来实现。它允许只请求资源的某个部分,即返回码是 206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  • 增加Host字段 : HTTP/1.1在请求头中加入了Host字段。没有Host头域会报告一个错误(400 Bad Request)
  • 缓存处理 : 在 HTTP1.0 中主要使用 Header 里的 If-Modified-Since,Expires 来做为缓存判断的标准,HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
  • 可以使用管道传输:多个请求可以同时发送,但是服务器还是按照顺序,先回应 A 请求,完成后再回应 B 请求。要是 前面的回应特别慢,后面就会有许多请求排队等着。这称为「队头堵塞」。
  • 状态响应码 : HTTP/1.1中新加入了大量的状态码,光是错误响应状态码就新增了24种。例如:
    • 100 (Continue)——在请求大资源前的预热请求,
    • 206 (Partial Content)——范围请求的标识码,
    • 409 (Conflict)——请求与当前资源的规定冲突,
    • 410 (Gone)——资源已被永久转移,而且没有任何已知的转发地址。
⓷HTTP 2.0——2015

http2.0是一种安全高效的下一代http传输协议。安全是因为http2.0建立在https协议的基础上,高效是因为它是通过二进制分帧来进行数据传输。正因为这些特性,http2.0协议也在被越来越多的网站支持。

  • 二进制分帧:HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧,突破了HTTP1.1的性能限制,改进传输性能。
  • 多路复用:使用多个stream,每个stream又分帧传输,使得一个tcp连接能够处理多个http请求
  • 头部压缩:通讯双方各自维护一个header的索引表,使得不需要直接发送值,通过发送key缩减头部大小
  • 服务器推送:服务器除了最初请求的响应外,服务器还可额外向客户端推送资源,而无需客户端明确的需求

参考:深入理解http2.0协议,看这篇就够了!

⓸HTTP 3.0——2022

基于Google的QUIC,HTTP3 背后的主要思想是放弃 TCP,转而使用基于 UDP 的 QUIC 协议。 为什么要有HTTP3.0? 为了解决HTTP/2.0中TCP造成的队头阻塞问题,HTTP/3.0直接放弃使用TCP,将传输层协议改成UDP;但是因为UDP是不可靠传输,所以这就需要QUIC实现可靠机制

  • 使用基于UDP的QUIC 协议:减少了tcp三次握手时间,以及tls握手时间;
  • 解决多路复用丢包的队头阻塞问题:解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题;
  • 优化了重传策略,重传包和原包的编号不同,降低后续重传计算的消耗;
  • 连接迁移,不再用tcp四元组确定一个连接,而是用一个64位随机数来确定这个连接;
  • 更合适的流量控制:通过流量控制可以限制客户端传输资料量的大小,有了流量控制后,接收端就可以只保留相对应大小的接收 buffer ,优化记忆体被占用的空间。

参考:HTTP/3 ,它来了

➎HTTP 常见状态码总结

HTTP 状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型。响应分为五类:

分类

分类描述

1**

信息响应,服务器收到请求,需要请求者继续执行操作

2**

成功响应,操作被成功接收并处理

3**

重定向,需要进一步的操作以完成请求

4**

客户端错误,请求包含语法错误或无法完成请求

5**

服务器错误,服务器在处理请求的过程中发生了错误

  • 程序员最想看到的:200-OK。
  • 程序员不想看到的:500-Internal-Server-Error。
  • 用户不想看到的:401-Unauthorized、403-Forbidden、408-Request-Time-out。

参考:HTTP 状态码 | 菜鸟教程 (runoob.com)

❻HTTP 中 GET 和 POST 区别

  • 1.GET请求参数通过URL传递;POST请求参数通过请求体传递。
  • 2.GET请求产生1个TCP数据包;POST请求产生2个TCP数据包。
    • 对于GET请求,浏览器会把请求头和请求体一并发送出去
    • 对于POST请求,浏览器先发送请求头,服务器响应100 continue,浏览器再发送请求体
  • 3.GET请求会被浏览器主动缓存;POST请求不会,需手动设置。
  • 4.GET请求参数会被保留在浏览器历史记录中;POST请求参数不会被保留。

❼URI 和 URL 的区别

  • URI(Uniform Resource Identifier)统一资源标识符,唯一标识一个资源
    • URI 像是身份证,唯一标识一个人
  • URL(Uniform Resource Locator)统一资源定位符,提供该资源多路径,是一种具体的URI。
    • URL像是住址,可以通过URL找到这个人

❽cookie和session的区别?

Cookie & Session | 简言之 (jwt1399.top)

  • Cookie 是一种服务端产生存储在客户端用于记录客户端状态的机制。
  • Session 是一种存储在服务器端用于记录客户端状态的机制。
  • Cookie 机制是通过检查客户身上的“通行证”来确认客户身份
  • Session 机制是通过检查服务器上的“客户明细表”来确认客户身份

区别

Cookie

Session

存储位置

客户端

服务端

存储大小

有限制(4k)

无限制

跨域支持

支持

不支持

存储信息

不加密

加密

生命周期

可自定义

不可自定义

❾HTTP 如何保存用户状态?

HTTP 是一种无状态(stateless)协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。

Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁这个 Session)。在服务端保存 Session 的方法很多,最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。

既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?大部分情况下,我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

**Cookie 被禁用怎么办?**最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

❿HTTP和RPC

HTTP(HyperText Transfer Protocol,超文本传输协议)

RPC(Remote Procedure Call,远程过程调用)

基于HTTP协议

基于TCP协议,也可以基于HTTP协议

HTTP接口使用基于HTTP协议的URL传参调用

实现调用本地接口一样调用远程服务的接口

HTTP更臃肿,但跨平台、跨语言更灵活

RPC效率更好,但是实现更难

需要配置Nginx,HAProxy实现负载均衡

自带了负载均衡策略

HTTP主要用于对外的异构环境,浏览器调用,APP接口调用,第三方接口调用等等。

RPC主要用于公司内部服务调用,性能消耗低,传输效率高,服务治理方便。

流行的RPC框架
  1. gRPC:gRPC是Google公布的开源项目,基于HTTP2.0协议,并支持常见的众多编程语言。HTTP 2.0协议是基于二进制的HTTP协议的升级版本,gRPC底层使用了Netty框架。
  2. Thrift:Thrift是Facebook的一个开源项目,主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL文件自动生成服务代码框架。Thrift对于底层的RPC通讯都是透明的,用户只需要对其进行二次开发即可,省去了一系列重复的前置基础开发工作。
  3. Dubbo:Dubbo是阿里集团开源的一个极为出名的RPC框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。

④Other

❶DNS 的解析过程

  1. 浏览器搜索自己的DNS缓存
  2. 若没有,则搜索操作系统中的DNS缓存hosts文件
  3. 若没有,则操作系统将域名发送至本地域名服务器,查找成功则返回结果,否则依次向根域名服务器顶级域名服务器权限域名服务器发起查询请求,最终返回IP地址给本地域名服务器
  4. 本地域名服务器将得到的IP地址缓存起来并返回给操作系统
  5. 操作系统将 IP 地址缓存起来返回给浏览器
  6. 浏览器得到域名对应的IP地址

❷ARP 协议

地址解析协议(Address Resolution Protocol),它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中,总是需要知道下一跳(物理上的下一个目的地)该去往何处,但 IP 地址属于逻辑地址,而 MAC 地址才是物理地址,ARP 协议解决了 IP 地址转 MAC 地址的一些问题。

OS

①进程和线程

❶进程和线程的区别

  • 进程是指一个内存中运行的应用程序,每个进程都有自己独立的一块内存空间。
  • 线程是比进程更小的执行单位,一个进程可以启动多个线程,每条线程并行执行不同的任务。
  • 调度:进程是资源管理的基本单位,线程是程序执行的基本单位。
  • 切换:线程上下文切换比进程上下文切换要快得多。
  • 拥有资源:进程是拥有资源的一个独立单位,线程不拥有系统资源,但是可访问隶属于进程的资源。
  • 系统开销:创建或撤销进程时,系统都要为之分配或回收系统资源,创建或撤销进程的开销大于创建或撤销线程时的开销,进程切换的开销也远大于线程切换的开销。

❷进程间的通信方式

  1. 管道/匿名管道(Pipes) :用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。
  2. 有名管道(Named Pipes) : 匿名管道由于没有名字,只能用于亲缘关系的进程间通信。为了克服这个缺点,提出了有名管道。有名管道严格遵循**先进先出(first in first out)**。有名管道以磁盘文件的方式存在,可以实现本机任意两个进程通信。
  3. 信号(Signal) :信号是一种比较复杂的通信方式,用于通知接收进程某个事件已经发生;
  4. 消息队列(Message Queuing) :消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道(无名管道:只存在于内存中的文件;命名管道:存在于实际的磁盘介质或者文件系统)不同的是消息队列存放在内核中,只有在内核重启(即,操作系统重启)或者显式地删除一个消息队列时,该消息队列才会被真正的删除。消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取。比 FIFO 更有优势。消息队列克服了信号承载信息量少,管道只能承载无格式字节流以及缓冲区大小受限等缺点。
  5. 信号量(Semaphores) :信号量是一个计数器,用于多进程对共享数据的访问,信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。
  6. 共享内存(Shared memory) :使得多个进程可以访问同一块内存空间,不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作,如互斥锁和信号量等。可以说这是最有用的进程间通信方式。
  7. 套接字(Sockets) : 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元,可以看做是不同主机之间的进程进行双向通信的端点,简单的说就是通信的两方的一种约定,用套接字中的相关函数来完成通信过程。

❸进程有哪几种状态

  • 创建状态(new) :进程正在被创建,尚未到就绪状态。
  • 就绪状态(ready) :进程已处于准备运行状态,即进程获得了除了处理器之外的一切所需资源,一旦得到处理器资源(处理器分配的时间片)即可运行。
  • 运行状态(running) :进程正在处理器上运行(单核 CPU 下任意时刻只有一个进程处于运行状态)。
  • 阻塞状态(waiting) :又称为等待状态,进程正在等待某一事件而暂停运行如等待某资源为可用或等待 IO 操作完成。即使处理器空闲,该进程也不能运行。
  • 结束状态(terminated) :进程正在从系统中消失。可能是进程正常结束或其他原因中断退出运行。

❹进程的调度算法

  • 先来先服务(FCFS)
    • 从就绪队列中选择一个最先进入该队列的进程为之分配资源,使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
  • 短作业优先(SJF)
    • 从就绪队列中选出一个估计运行时间最短的进程为之分配资源,使它立即执行并一直执行到完成或发生某事件而被阻塞放弃占用 CPU 时再重新调度。
  • 优先级调度算法(PSA)
    • 为每个流程分配优先级,首先执行具有最高优先级的进程,依此类推。具有相同优先级的进程以 FCFS 方式执行。可以根据内存要求,时间要求或任何其他资源要求来确定优先级。
  • 高响应比优先调度算法(HRRN)
    • 根据“响应比 =(进程执行时间+进程等待时间)/ 进程执行时间”这个公式得到的响应比来进行调度。
    • 优点是兼顾长短作业,缺点是计算响应比开销大,适用于批处理系统。
    • FCFS方式只考虑每个作业的等待时间而未考虑执行时间的长短;
    • SJF方式只考虑执行时间而未考虑等待时间的长短
  • 时间片轮转调度算法 (RR)
    • 每个进程被分配一个时间段,称作它的时间片,即该进程允许运行的时间。

❺线程有多少种状态

  1. New(新建):尚未启动的线程处于此状态。
  2. Runnable(运行):在Java虛拟机中执行的线程处于此状态。
  3. Blocked(阻塞):被阻塞等待监视器锁定的线程处于此状态。
  4. Waiting(等待):正在等待另一个线程执行特定动作的线程处于此状态。
  5. Timed Waiting(计时等待):正在等待另一个线程执行动作达到指定等待时间的线程处于此状态。
  6. Terminated(终止):已退出的线程处于此状态。

❻并发&并行

并发:同一个时刻,多个任务交替执行。单核 cpu 实现的多任务就是并发。例如:Tom 边开车边接电话

并行:同一个时刻,多个任务同时执行。多核 cpu 可以实现并行。例如:Tom 开车 ,Jack 接电话

❼线程间的同步的方式

  1. **互斥量(Mutex)**:采用互斥对象机制,只有拥有互斥对象的线程才有访问公共资源的权限。比如 Java 中的 synchronized 关键词和各种 Lock 都是这种机制。
  2. 信号量(Semaphore) :它允许同一时刻多个线程访问同一资源,但是需要控制同一时刻访问此资源的最大线程数量。
  3. 事件(Event) :Wait/Notify:通过通知操作的方式来保持多线程同步,方便的实现多线程优先级的比较操作。

❽死锁

死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,它们都将无法推进下去。

死锁产生的四个必要条件

  • 互斥:一个资源每次只能被一个进程使用
  • 不可强占:任一进程不能从另一进程那里抢夺资源
  • 请求和保持:一个进程请求资源而阻塞时,不释放已占有的资源
  • 循环等待:进程之间循环等待着资源

解决死锁的方法

  • 预防死锁:采用策略限制并发进程对资源的请求,使得死锁的必要条件在系统执行的任何时间上都不满足。
  • 避免死锁:系统在分配资源时,根据资源的使用情况提前做出预测,从而避免死锁的发生
  • 检测死锁:设专门的机构,当死锁发生时,能够检测死锁的发生,并精确地确定与死锁有关的进程和资源。
  • 解除死锁:与检测死锁配套的一种措施,用于将进程从死锁状态下解脱出来

②内存管理

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-12-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 计网
    • ①网络分层
      • ②TCP
        • ❶三次握手
        • ❷为什么要三次握手?
        • ❸四次挥手
        • ❹TCP 与 UDP 的区别
        • ❺使用 TCP 的协议有哪些?
        • ❻使用 UDP 的协议有哪些?
        • ❼TCP 如何保证传输的可靠性?
        • ❽TCP 如何实现流量控制?
        • ❾TCP 的拥塞控制是怎么实现的?
      • ③HTTP
        • ❶从输入URL 到页面展示的过程
        • ❷SSL/TLS
        • ❸HTTP 和 HTTPS 有什么区别
        • ➍HTTP 1.0 、1.1、 2.0、3.0区别
        • ➎HTTP 常见状态码总结
        • ❻HTTP 中 GET 和 POST 区别
        • ❼URI 和 URL 的区别
        • ❽cookie和session的区别?
        • ❾HTTP 如何保存用户状态?
        • ❿HTTP和RPC
      • ④Other
        • ❶DNS 的解析过程
        • ❷ARP 协议
    • OS
      • ①进程和线程
        • ❶进程和线程的区别
        • ❷进程间的通信方式
        • ❸进程有哪几种状态
        • ❹进程的调度算法
        • ❺线程有多少种状态
        • ❻并发&并行
        • ❼线程间的同步的方式
        • ❽死锁
      • ②内存管理
      相关产品与服务
      云服务器
      云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档