计网，操作系统

一、操作系统

1、死锁产生的必要条件：

互斥，不可剥夺，请求和保持，循环等待

采用资源复用或共享的方式打破互斥

当进程获取了部分资源但是无法获取全部资源，就自动释放已经占用的资源打破不可剥夺条件

给进程分配资源时一次性分配其资源，要么不分配打破请求和保持

给资源分配一个编号，进程按编号递增的方式请求资源，打破循环等待

2、进程间通信方式：

管道，信号，信号量，套接字，共享内存，消息队列

3、进程线程协程的区别

进程是资源分配的最小单位，是一个运行软件的实例，进程又可以包含很多个线程，进程上下文切换的开销很大

线程是资源调度的最小单位，多个线程可以共享进程中的资源，线程上下文切换开销很小

协程是用户轻量级的线程，协程的调度由用户来控制，线程可以包含多个协程

4、进程调度算法

1、先来先服务

2、最短进程优先

3、时间片轮转

4、优先调度算法

5、单道和多道的区别

1、单道程序设计技术是指在内存一次只能允许一个程序进行运行，在这次程序运行结束前，其它程序不允许使用内存。 这是早期的操作系统所使用的技术。

2、多道程序设计技术是现代操作系统普遍使用的，它可以允许多个程序驻存在内存中，系统通过某种调度策略交替执行程序。

6、互斥和同步的基本概念

互斥：是指散布在不同进程之间的若干程序片段，当某个进程执行其中的一个程序片段时，其他进程就不能运行它们之中的任一程序片段，只能等到该进程运行完之后才可以继续运行。

同步：是指散布在不同进程之间的若干程序片段，它们的运行必须严格按照一定的先后次序来运行，这种次序依赖于要完成的任务。比如数据的收发，必须发送方发送了接收方才能收。

    同步是一种更为复杂的互斥吗，而互斥是一种特殊的同步。互斥是两个进程或线程之间不可以同时运行，它们会互相排斥，必须等待其中的一个运行完，另一个才可以运行。而同步也是不可以同时运行，并且还需要按照某种顺序来运行。

总结：

互斥是指某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法控制对资源的访问顺序 同步是指在互斥的基础上实现对资源的有序访问

二、计算机网络

1、计算机网络分层：

1.1 应用层协议

FTP协议（文件传输协议）

POP3协议（收邮件）

SMTP协议（发邮件）

DNS协议（地址解析）

SNMP协议（简单网络管理）

Telnet协议（远程登陆）

2、TCP协议

2.1、TCP三次握手

1、客户端给服务端发送一个SYN报文，包含一个seq序列号（是由发送端随机生成的）表示建立TCP连接请求

2、服务端给客户端回复连接请求的报文，包含一个服务端的seq序列号，并将客户端的序列号加一作为ACK进行回复

3、客户端收到报文之后，将自己的序列号加一，然后将服务端的序列号加一回复ACK

 

2.1.1、是否可以使用“两报文握手”建立连接？

        考虑这样一种情况，TCP客户进程发出一个TCP连接请求报文段，但该报文段在某些网络节点长时间滞留了，这必然会造成该报文段的超时重传。

        假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。

        由于我们改为两报文握手，因此TCP服务器进程发送完TCP连接请求确认报文段后，进入的是连接已建立状态，而不像三次握手那样进入同步已接收状态，TCP服务器进程并等待TCP客户进程发来针对TCP连接请求确认报文段的普通确认报文段。TCP客户进程收到TCP连接请求确认报文段后进入TCP连接已建立状态，但不会给TCP服务器进程发送针对该报文段的普通确认报文段。

现在，TCP双方都处于连接已建立状态，他们可以相互传输数据，之后可以通过四报文挥手来释放连接，TCP双方都进入了关闭状态。

一段时间后，之前滞留在网络中的那个失效的TCP连接请求报文段到达了TCP服务器进程，TCP 服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求，于是给TCP客户进程发送TCP连接请求确认报文段并进入连接已建立状态。

该报文段到达TCP客户进程，由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段。

但TCP服务器进程已进入了连接已建立状态，他认为新的TCP连接已建立好了，并一直等待TCP客户进程发来数据。这将白白浪费TCP服务器进程所在主机的很多资源。

综上所述，采用三报文握手，而不是两报文握手来建立TCP连接，是为了防止已失效的连接请求报文段突然又传送到了TCP服务器进程因而导致错误。

2.2、TCP四次挥手

2.2.1、四次挥手过程

第一次挥手：

客户端向服务器发送一个 FIN 数据包（FIN = 1，seq = u）主动断开连接，报文中会指定一个序列号。 告诉服务器：我要跟你断开连接了，不会再给你发数据了； 客户端此时还是可以接收数据的，如果一直没有收到被动连接方的确认包，则可以重新发送这个包。 此时客户端处于 FIN_WAIT1 状态。 第二次挥手：

服务器收到 FIN 数据包之后，向客户端发送确认包（ACK = 1,ack = u + 1），把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了 这是服务器在告诉客户端：我知道你要断开了，但是我还有数据没有发送完，等发送完了所有的数据就进行第三次挥手 此时服务端处于 CLOSE_WAIT 状态，客户端处于 FIN_WAIT2 状态 第三次挥手：

服务器向客户端发送FIN 数据包（FIN=1，seq = w），且指定一个序列号，以及确认包（ACK = 1， ack = u + 1），用来停止向客户端发送数据 这个动作是告诉客户端：我的数据也发送完了，不再给你发数据了 此时服务端处于LAST_ACK状态，客户端处于TIME_WAIT状态 第四次挥手：

客户端收到 FIN数据包 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值 此时客户端处于 TIME_WAIT 状态。 需要过一了一定时间（2MSL）之后，客户端发送确认包（ACK = 1， ack = w + 1），此时客户端才会进入 CLOSED 状态，以确保发送方的ACK可以到达接收方，防止已失效连接请求报文段出现在此连接中。 至此，完成四次挥手。

2.2.2、挥手报文丢失会发生什么？

第一次挥手丢失

当客户端调用close函数后，就会向服务端发送FIN报文，试图与服务端断开联系，此时客户端进入FIN_WAIT_1状态。

如果客户端一直收不到ack应答报文的话，就会触发超时重传机制，最大重传次数由tcp_orphan_retries参数决定。当超过指定次数时，就不再发送报文，直接进入close状态

第二次挥手丢失 当接受到客户端的FIN报文，就会先回应一个ack报文，此时服务端进入close_wait状态。

当ack报文丢失时，ack是不会重传的。服务端的ack报文丢失了，客户端就会触发超时重传，直到收到ack报文或则到达超时重传次数

第三次挥手丢失 当服务端接收到客户端的fin报文时，内核会自动回复ack应答报文，然后处于CLOSE_WAIT状态，他必须等待应用进程调用close函数关闭连接。

调用close函数后，内核就会发出FIN报文，进入LAST_ACK状态，等待客户端返回ack来确认关闭连接。

如果服务端没有收到ack，则会跟客户端重传FIN报文一样

第四次挥手丢失 当客户端接收到服务端发来的FIN报文后，就会回应ack应答报文，进入TIME_WAIT状态。

服务端没有收到ack报文之前，还是处于LAST_ACK状态

如果服务端没有收到ack报文的话，服务端就会重发FIN报文，重发次数仍然由tcp_orphan_retries参数控制

2.2.3 为什么要等待2MSL时间？

MSL最长报文段寿命Maximum Segment Lifetime

两个理由：1）保证A发送的最后一个ACK报文段能够到达B。2）防止“已失效的连接请求报文段”出现在本连接中。

1）这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。 2）A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

2.3、TCP和UDP的区别

1、TCP面向连接，通过三次握手建立连接，四次挥手接除连接;UDP是无连接的，即发送数据之前不需要建立连接，这种方式为UDP带来了高效的传输效率，但也导致无法确保数据的发送成功。 ​ 2、TCP是可靠的通信方式。通过TCP连接传送的数据，TCP通过超时重传、 数据校验等方式来确保数据无差错，不丢失，不重复，且按序到达；而UDP由于无需连接的原因，将会以最大速度进行传输，但不保证可靠交付，也就是会出现丢失、重复等等问题。

​ 3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流，由于连接的问题，当网络出现波动时，连接可能出现响应问题；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。 ​

4、每一条TCP连接只能是点到点的；而UDP不建立连接，所以可以支持一对一，一对多，多对一和多对多的交互通信，也就是可以同时接受多个人的包。 ​ 5、TCP需要建立连接，首部开销20字节相比8个字节的UDP显得比较大。 ​ 6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。

3、HTTP和HTTPS协议

3.1、对称加密和非对称加密

1、加密和解密使用同一个秘钥，所以叫做对称加密，对称加密：DES、AES

2、非对称加密之所以不对称，指的就是加密用一个密钥，而解密的时候用的是另外一个密钥。公钥和私钥是一对，如果用公钥对数据加密，那么只能用对应的私钥解密。如果用私钥对数据加密，只能用对应的公钥进行解密。因为加密和解密用的是不同的密钥，所以称为非对称加密。非对称加密：RSA、DSA。

3.2、HTTP和HTTPS区别

HTTP（超文本传输协议）和HTTPS（安全超文本传输协议）是两种用于在客户端和服务器之间传输数据的协议。它们之间的主要区别在于安全性。

1. 安全性：HTTP是不安全的协议，所有传输的数据都是明文的，容易被黑客截取和篡改。而HTTPS通过使用SSL（安全套接层）或TLS（传输层安全）协议，对数据进行加密和身份验证，提供了更高的安全级别。

2. 数据传输方式：HTTP使用的是明文传输，数据在传输过程中不进行加密处理。而HTTPS使用SSL/TLS协议对数据进行加密，确保数据在传输过程中的安全性。

3. 端口：HTTP使用的是默认端口80进行通信，而HTTPS使用的是默认端口443。

4. 证书：在使用HTTPS时，服务器需要获得SSL证书，证书由可信任的第三方机构颁发，用于验证服务器的身份。这样客户端在与服务器建立连接时可以确认其身份，并确保数据不会被中间人攻击篡改。

总结来说，HTTP和HTTPS的区别主要在于数据传输的安全性和加密方式。HTTPS更加安全可靠，适用于需要保护敏感信息的网站和应用，如银行、电子商务等。而HTTP由于不加密数据，更适用于无需保护敏感信息的一般网站和应用。

3.3、HTTPS的工作流程

1.Client发起一个HTTPS的请求，根据RFC2818的规定，Client知道需要连接Server的443端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（-key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”

3.4、HTTP状态码

• 1xx：指示信息--表示请求已接收，继续处理

• 2xx：成功--表示请求已被成功接收、理解、接受

• 3xx：重定向--要完成请求必须进行更进一步的操作

• 4xx：客户端错误--请求有语法错误或请求无法实现

• 5xx：服务器端错误--服务器未能实现合法的请求

  注：常见状态代码、状态描述、说明：

  200 OK //客户端请求成功。

  201 created //成功创建。

  302 Found //重定向，新的URL会在response中的Location中返回，浏览器将会使用新的URL发出新的Request。

  304 Not Modified //代表上次的文档已经被缓存了， 还可以继续使用。

  400 Bad Request //客户端请求有语法错误，不能被服务器所理解。

  401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。

  403 Forbidden //服务器收到请求，但是拒绝提供服务。

  404 Not Found //请求资源不存在，如：输入了错误的URL。

  405 method not allowed //该http方法不被允许。

  410 gone //这个url对应的资源现在不可用。

  415 unsupported media type //请求类型错误。

  422 unprocessable entity //校验错误时用。

  429 too many request //请求过多。

  500 Internal Server Error //服务器发生不可预期的错误。

  503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

  响应正文就是服务器返回的资源的内容。

4、DNS协议

4.1、DNS解析过程

1、浏览器先会检查缓存和本地host文件，有没有该域名对应的IP地址，有就直接使用

2、如果没有就会想本地DNS服务器发送请求，本地DNS服务器如果有缓存记录就返回

3、如果没有就向根域名服务器发送请求询问顶级域名服务器的地址，给本地DNS服务器返回顶级域名服务器的地址

4、本地DNS服务器会向顶级域名服务器发送请求询问权威域名服务器地址，给本地DNS服务器返回权威域名服务器的地址

5、本地DNS服务器就会向权威域名服务器发送请求询问对应的IP地址是多少，给本地DNS服务器返回最终的IP地址

6、本地DNS服务器将最终的ip返回给我们的主机

5、ARP协议（地址解析协议）

将目标IP地址转换为目标的MAC地址

5.1、工作原理

ARP协议主要依赖ARP高速缓存(ARP cache)。ARP高速缓存就是一个映射表，它记录了IP地址和物理地址的映射关系。每一台主机和路由器都设有ARP高速缓存，在实际传输中，通常已知下一跳的目的IP地址(这是通过查询路由表完成的，不是本篇的知识)，通过查询ARP高速缓存即可知道对应的物理地址。

5.2、请求流程

1、源主机或者路由器会给该网络的所有主机发送ARP请求分组(也就是给这个网络广播该分组)，所有主机会检查分组的目的IP地址是否与自身的IP地址相同。如果不相同，就丢弃该分组；如果相同，就说明自己就是被寻找的目的主机或者路由器。

2、目的主机(或目的路由器)在收到ARP请求分组后，会做两件事： ​ 1.将源主机的IP地址和对应的物理地址添加进自身的ARP高速缓存映射表。 ​ 这是因为既然源主机会和自己通信，那么自己之后也可能会主动和源主机通信，提前建立源主机的映射表项是有必要的，之后自己 要主动和源主机通信就不用广播ARP请求分组了。 ​ 2.给源主机发送ARP响应报文(注意，该报文是单播的) ​ 目的主机需要给源主机发送ARP响应报文，告知源主机自己的物理地址。源主机在收到所需的ARP响应报文，就可以发送帧给目的主 机了。 为什么是单播而不是广播呢？那是因为目的主机已经有源主机的物理地址了，可以直接给源主机发送对应的帧，不需要广播。

当源主机接收到ARP响应报文后，也会将目的主机的IP地址和对应的物理地址添加到自己的ARP高速缓存映射表中，这样下次再和该主机通信，就不用广播ARP分组了。之后就可以通过物理地址，给目的主机发送帧了。