计算机基础知识

参考链接：https://blog.csdn.net/ChineseSoftware/article/details/123176978
https://www.cnblogs.com/8023-CHD/p/11067141.html
https://blog.csdn.net/qq_42033567/article/details/108088514

http与https的区别

HTTP 的URL以http:// 开头，而HTTPS 的URL 以https:// 开头
HTTP的默认端口是80，而HTTPS的默认端口是443
在OSI网络模型中，HTTP工作于应用层，而HTTPS的安全传输机制工作在传输层
HTTP是明文传输，HTTPS 在 HTTP 的基础上加入了 SSL 协议，SSL 依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
HTTP的连接很简单，是无状态的。HTTPS是由SSL+HTTP构建的可进行加密传输、身份认证的网络协议，比HTTP安全。

Linux常用命令


cd 命令切换目录
ls 命令查看当前目录下的文件
	-l:列出长数据串，包含文件的属性与权限数据等 
	-a:列出全部的文件，连同隐藏文件（开头为.的文件）一起列出来（常用）
pwd 当前目录的绝对路径 
touch 创建文件
mkdir 创建文件夹
mv 移动文件、目录
rm 用于删除文件或目录
vim 用于文件编辑
cat 用于查看文本文件内容
tar 对文件进行压缩与解压缩 压缩：tar -zcf 解压缩：tar -zxf
kill 终止进程
chmod 改变文件权限 r：读权限 w：写权限 x：可执行权限 u：用户 g：同组用户 o:其他用户 a：所有用户
chmod xxx 文件名称
每一位分别表示不同类的权限，每一位的范围为0-7，表示读写执行的权限。

tcp和udp的区别

连接方面，TCP是面向连接的，UDP是无连接的。
TCP是面向字节流的，发送数据时会将数据分解为多个小的数据报文进行发送；UDP是基于数据报的，发送数据时会直接打上UDP头将整个报文发送出去。
TCP只支持一对一通讯；而UDP支持一对一、一对多、多对一、多对多通讯。
TCP要求实时性低、准确度高；UDP要求实时性高、准确度低。
TCP头部20-60字节，UDP头部8个字节。
TCP提供可靠的传输服务，通过TCP连接传输的数据，无差错、不重复、按序到达；UDP尽最大努力进行交付，不保证可靠交付。
基于TCP的应用层协议有：SMTP（简单邮件传输协议）、TELNET（远程登录服务协议）、HTTP（超文本传输协议）、FTP（文件传输协议）。
基于UDP的应用层协议：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（简单文件传输协议）。

cookie和session区别

cookie通过在客户端记录信息确定用户身份，session通过在服务器端记录信息确定用户身份。
cookie不是很安全，考虑安全应当使用session。
因为session会在一定时间保存在服务器上，当访问增多，会比较占用服务器性能，考虑到减轻服务器性能方面，应当使用cookie。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
可以考虑将登陆信息等重要信息存放为 session，其他信息如果需要保留，可以放在 cookie 中。

进程和线程的区别

1.根本区别：进程是操作系统进行资源分配的最小单位，线程是操作系统进行任务调度的最小单位。
2.从属关系不同：进程中包含了线程，线程属于进程。
3.开销不同：进程的创建、销毁和切换的开销都远大于线程。
4.拥有资源不同：每个进程都有自己的内存空间，一个进程中的线程会共享这些内存空间。
5.CPU利用率不同：进程的CPU利用率较低，因为上下文切换开销较大，而线程的CPU利用率高，上下文的切换速度快。
6.操纵者不同：进程的操纵者一般是操作系统，线程的操纵者一般是编程人员。

线程有哪几种状态

线程通常都有5种状态，创建、就绪、运行、阻塞和死亡。
创建： 在生成线程对象，并没有调用该对象的start方法，这时线程处于创建状态。
就绪： 当调用了线程对象的start方法后，该线程就进入了就绪状态，当调用了线程对象的start方法后，该线程就进入了就绪状态。此时线程调度程序还没有把该线程设置为当前线程。当线程从等待或者睡眠中回来后也会处于就绪状态。
运行： 线程调度程序将处于就绪状态的线程设置为当前线程，此时线程就进入了运行状态，开始执行run函数中的代码。
阻塞： 线程正在运行时，因为等待某个资源被暂停进入阻塞状态。sleep、suspend等方法都能导致线程阻塞。
死亡： 如果一个线程的run方法执行结束，该线程就会死亡。

http的三次握手和四次挥手

三次握手

在这里插入图片描述

第一次握手：客户端发送一个SYN报文，并指明客户端的初始化序列号，此时客户端处于SYN-SENT状态。
第二次握手：服务器收到客户端的SYN报文后，会以自己的SYN报文作为应答，也指定自己的初始化序列号，将客户端的seq+1作为ack的值，表示自己收到了客户端的seq，并请求下一个seq，此时服务器处于SYN-RCVD状态。
第三次握手：客户端收到SYN报文后，会发送一个ACK报文，将ack设为服务器的seq+1，表示已经收到服务器的SYN报文，并发送下一个seq，此时客户端初一ESTABLISHED状态，服务器收到ACK报文后，也处于ESTABLISHED状态，此时，双方已建立起了连接。
为什么要三次握手？
通过三次握手可以保证双方的发送和接收能力正常，确保与列好同步，以及防止旧的失效连接请求产生误解，从而建立可靠的链接。
确认双方的发送和接收能力：第一次握手客户端发送SYN报文段到服务器，服务器接收到SYN报文段后，确认客户端的发送能力和自己的接收能力正常。
确保客户端和服务器的序列号同步：在第二次握手时，服务器发送了带有SYN/ACK标志的报文段，其中ACK确认号字段的值为客户端的初始序列号加1，同时，服务器也选择了自己的初始序列号。这样，客户端和服务器都知道对方的初始序列号，并可以同步它们的序列号。
防止已失效的连接请求报文段产生连接：考虑这样一种情况，客户端发送了一个连接请求报文段，但因网络延迟等原因导致该报文段长时间滞留，过了一段时间后，客户端重新发送了一个新的连接请求报文段并成功建立连接。此时，滞留的旧报文段可能会到达服务器，如果只进行两次握手，服务器会认为这是一个新的连接请求并建立连接，而实际上客户端可能已经关闭了该连接。通过三次握手，可以让服务器确认客户端对连接的真实意图。

http的四次握手

在这里插入图片描述

第一次挥手：客户端会发送一个FIN报文，报文会指定一个序列号，此时客户端处于FIN-WAIT1状态。
第二次挥手：服务端收到FIN报文后，会发送ACK报文，并且把ack等于客户端序列值+1表示已经收到客户端的FIN报文了，此时服务端处于CLOSE-WAIT状态。客户端收到服务端的ACK报文后，进入FIN-WAIT2。
第三次挥手：服务端传输完剩余数据后，服务端想断开连接，会发送FIN报文，且指定一个序列号，此时服务端处于LAST-ACK状态。
第四次挥手：客户端收到FIN后，发送ACK报文进行应答，seq=服务器的ack，ack=服务器的seq+1，此时客户端处于TIME-WAIT状态，需要过一阵子以确保服务器收到自己的ACK报文进入CLOSE状态，服务器收到ACK报文后，也进入CLOSE状态。

为什么要四次挥手？

为了保证在最后断开的时候，客户端能够发送最后一个ACK报文段能够被服务器接收到。如果客户端在收到服务器给它的断开连接的请求之后，回应完服务器就直接断开连接的话，若服务器没有收到回应就无法进入CLOSE状态，所以客户端要等待两个最长报文段寿命的时间，以便于服务器没有收到请求之后重新发送请求。
防止“已失效的连接请求报文”出现在连接中，在释放连接的过程中会有一些无效的滞留报文，这些报文在经过2MSL的时间内就可以发送到目的地，不会滞留在网络中。这样就可以避免在下一个连接中出现上一个连接的滞留报文了。

为什么需要接收方最后等待2MSL
1MSL表示一个1个最长报文段的寿命。
接收方等待最后一次ack+重发的第三次释放连接请求到达发送方的时间<=2MSL，因此需要等待2MSL。
本质原因是网络是不可靠的，所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果发送方的最后一次ack没有被接收方收到的话，那么接收方会进行重传第三次的释放连接请求，TIME_WAIT就是为了在这种情况下重发丢失了的ack报文。

TCP为什么是可靠的
可靠传输就是通过TCP连接传送的数据是没有差错、不会丢失、不重复并且按序到达的。TCP通过序列号、检验和、确认应答信号、重发机制、连接管理、窗口控制、流量控制、拥塞控制一起保证TCP传输的可靠性。

确认应答 （1）发送端每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收端对分配的这个序列号进行确认，如果发送端在一个特定时间内没有收到接收端的确认，则发送端会重传此数据包。（2）接收端利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等，接收端一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。
超时重传 TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息；接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。发送方没有接收到响应的ACK报文原因可能有两点：（1）数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。（2）接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
拥塞控制 慢启动、拥塞避免、快重传、快恢复
流量控制 如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。