一:进程与线程的区别
1.进程时操作系统资源分配的最小单位,线程时程序执行的最小单位
2.进程有自己的独立地址空间,每启动一个进程,系统就会为它分配地址空间,建立数据表来维护代码段 堆栈段 和数据段。
线程共享进程中的数据,使用相同的地址空间,因此CPU切换一个线程的花费远比进程要小很多,同时创建一个线程的开销也比 进程要小很多。
3.线程之间的通信更方便,同一进程下线程共享静态变量 、全局变量等,而进程之间的通信需要以通信的方式(IPC)进行。不过处理好同步与互斥是编写多线程程序的难点。
4.多进程程序更健壮,多线程程序只要有一个线程死掉,整个进程也死掉了,而一个进程死掉并不会对另外一个进程造成影响,因为进程有自己独立的地址空间。
二:简单介绍下进程的切换过程
进程切换有两个重要的问题1.进行调度的时机 2.进程切换的过程
进程切换的过程
进程调度由操作系统内核进行,目的是合理分配系统资源,令每个进程都能获得执行时间。进程调度由schedule函数负责,该函数是操作系统的内核函数,并非系统调用,只能在内核态中由内核代码主动调用的。
三:你经常使用哪些Linux命令,主要用来解决什么问题
1.文件目录操作类的命令,如:cd ls cp rm find grep zip tar yum less
2.系统权限操作命令,如:chmod chown sudo
3.操作系统级命令,如:shutdown uname top du df lost netstat
四:为什么TCP建连需要三次握手而断连需要4次
开始之前,先简单介绍下TCP报文段首部格式的几个名词
1.序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生,给字节编上序号后,就给每一个报文段指派一个序号,序列号seq就是这个报文段中的第一个字节的数据编号。
2.确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号:序列号表示报文段携带数据的第一个字节的编号:而确认号指的是期望接受到下一个字节的编号:因此当前报文段最后一个字节的编号+1即为确认号。确认ACK:占1位,仅当ACK=1时,确认好字段才有效。ACK=0时,确认号无效。
3.同步SYN:连接建立时用于同步序列号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1 ,ACK=1.因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被设置为1,握手完成后SYN标志被设置为0.
4.终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接。
PS:ACK SYN FIN 大写表示标志为,其值为1或0,ack seq小写表示序号
三次握手:
A: 喂,你听得到吗? A-->SYN_SEND
B:我听到了,你听到我了吗?应答与请求同实发出 B-->SYN_RCVD | A-->ESTABLISHED
A:我能听到你 B-->ESTABLISHED
四次告别
A: 我不说了。 A-->FIN_WAIT1
B:我知道了,等下,上一句还没说完。B-->CLOSE_WAIT | A-->FIN_WAIT2
B:好了,说完了,我也不说了。 B-->LAST_ACK
A:我知道了 。A-->TIME_WAIT | B-->CLOSED
TCP建立三次握手得详细过程
(1)主机A向主机B发送TCP连接请求数据包,其中包含主机A的初始序列号seq(A)=x.
其中确认报文段中,同步标志为SYN=1,ACK=0,表示这是一个TCP连接请求数据报文:序号seq=x,表明传输数据时的第一个数据字节的序号时x.
(2)主机B收到请求后,会发回连接确认数据包
齐总确认报文段中,标志位SYN=1,ACK=1,表示这是一个TCP连接响应数据报文,并含主机B的初始序列号seq(B)=y,以及主机B对主机A初始序列号的确认ack(B)=seq(A)+1=x+1
(3)第三次,主机A收到主机B的确认报文后,还需要做出确认,即发送一个序列号 seq(A)=x+1;确认号为ack(A)=y+1的报文
为什么需要三次握手?
还要再发一次确认时为了,防止已失效的连接请求报文段突然又传到了B,因而产生错误。
已失效的报文段,正常情况下:A发出连接请求,但因为丢失了,故而不能收到B的确认。于是A重新发出请求,然受收到确认,建立连接,数据传输完毕后,释放连接,A发了2个,一个丢掉,一个到达,没有“已失效的报文段”。
但是某种情况下,A的第一个在某个节点滞留了,延误到达,本来这事一个早已失效的报文段,但是在A发送第二个,并且得到B的回应,建立了连接以后,这个报文竟然到达了,于是B就认为,A又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,A收到B的确认,但A知道自己并没有发送建立连接的请求,因为不会理睬B的这个确认,于是哪,A也不会发送任何数据,而B却以为新的连接建立起来,一直等待A发送数据给自己,此时B的资源就被白白浪费了。但是采用三次握手的话,A就不发送确认,那么B由于收不到确认,也就知道并没有要求建立连接。
简单讲;第三次握手,主机A发送了一次确认时为了防止:如果客户端迟迟没有服务器返回的确认报文,这时他会放弃连接,重新启动一条连接请求,但问题是:服务器不知客端没有收到,所有会收到两个连接请求,白白浪费了一条连接开销。
TCP释放四次握手
(1)四次握手的过程
假设主机A为客户端,主机B为服务器,其释放TCP连接的过程如下
1.关闭客户端到服务器的连接:首先客户端A发送一个FIN,用来关闭客户端到服务器的数据传送,然后等待服务器的确认。
其中终止标志为FIN=1,序列号seq=u
2.服务器收到这个FIN,它发回一个ACK,确认号ACK为收到的序号加1
3.关闭服务器到客户端的连接:也是发送一个FIN给客户端
4.客户端收到FIN后,并发回一个ACK报文确认,并将确认序号seq设置为收到序号加1
首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
主机A发送FIN后,进入终止等待状态。
服务器B收到主机A连接释放报文段后,就立即给主机A发送确认,然后服务器B就进入了close-wait状态,此时TCP服务器进程就通知高层应用进程,因而从A到B的连接就释放了。此时是“半关闭”的状态。即A不可以发送给B,但是B可以发送给A。
此时,若B没有数据要发送给A了,其应用进程就通知TCP释放连接,然后发送A连接释放报文段,并等待确认。A发送确认后,进入time-wait,注意,此时,TCP连接还没有释放掉,然后经过时间等待,计时器设置的2MSL后,A才进入close状态。
五:为什么TCP关闭连接时需要TIME_WAIT状态,为什么要等2MS
存在TIME_WAIT状态有两个理由:
1.被动关闭连接的一方,在一段时间内没有收到对方的ACK确认数据包,会重新发送FIN数据包,因而主动关闭连接的一方需要停留在等待状态以处理对方重新发送的FIN数据包。否则他会回应一个RST数据包,给被动关闭的一方,使得对方莫名奇妙。
2.在TIME_WAIT状态下,不允许应用程序在当前ip 和端口上和之前通信client建立一个新的连接。这样就能避免新的连接收到之前的ip和端口一致的连接残存在网络中的数据包。这也是TIME_WAIT状态的等待时间被设置为2MSL的原因,以确保网络上当前连接两个方向上尚未接收的TCP报文已经全部消失。
六:请简述下一次完整的HTTP请求的过程
1.浏览器中输入 www.baidu.com 这个网址进行DNS域名解析,得到对应的IP地址
2.根据这个IP,找到对应的服务器,发起TCP的三次握手
3.建立TCP连接后发起HTTP请求
4.服务器响应HTTP请求,浏览器得到HTML代码
5.浏览器解析html代码,并请求html代码中的资源(js css picture)
6.浏览器渲染页面,呈现给用户