一般分为四个阶段:
通电—>开机自检(BIOS)—>MBR引导—>GRUB菜单—>加载内核kernel—>运行init进程(系统里其他所以进程的父进程)—>读取/etc/inittab配置文件—>执行/etc/rc.d/rc.sysinit脚本(系统初始化脚本,设置主机名和IP地址等)—>执行/etc/rc.d/rc脚本(根据系统的运行级别,在开机时启动不同软件、0到6级)—>启动mingetty进程。
Linux系统启动流程图及其相关文件
系统执行流程图
Web服务器(当前主流的有Apache, Nginx, IIS) 约等于 HTTP服务器 + 其他服务
我们假设以浏览器作为客户端
(1) 用户做出了一个操作,可以是填写网址敲回车,可以是点击链接,可以是点击按键等,接着浏览器获取了该事件。
(2) 浏览器与对端服务程序建立TCP连接。
(3) 浏览器将用户的事件按照HTTP协议格式**打包成一个数据包,其实质就是在待发送缓冲区中的一段有着HTTP协议格式的字节流。
(4) 浏览器确认对端可写,并将该数据包推入Internet,该包经过网络最终递交到对端服务程序。
(5) 服务端程序拿到该数据包后,同样以HTTP协议格式解包,然后解析客户端的意图。
(6) 得知客户端意图后,进行分类处理,或是提供某种文件、或是处理数据。
(7) 将结果装入缓冲区,或是HTML文件、或是一张图片等。
(8) 按照HTTP协议格式将(7)中的数据打包
(9) 服务器确认对端可写,并将该数据包推入Internet,该包经过网络最终递交到客户端。
(10) 浏览器拿到包后,以HTTP协议格式解包,然后解析数据,假设是HTML文件。
(11) 浏览器将HTML文件展示在页面
以上为Web服务器工作基本原理。其实不难发现,这仅仅只是一个简单的网络通信。我们应该深信,作为一个服务器,其根本的工作无非有三个:
1.接收数据 2. 发送数据 3. 数据处理
而Web服务器的本质就是 接收数据 ⇒ HTTP解析 ⇒ 逻辑处理 ⇒ HTTP封包 ⇒ 发送数据
高级的服务器无非就是将这三个部分更加细致的设计了。
在DHCP过程中有两个对象DHCP客户端和DHCP服务端,而且DHCP在三层是通过可靠地TCP协议实现,DHCP服务运行在67和68端口。
DHCP实现的简单过程,如图1所示
1.发现阶段
在DHCP服务配置完成后,DHCP Client启动时,由于没有IP地址,会自动发送以discover的广播报文,源地址为0.0.0.0目的地址为255.255.255.255。网络上的所有支持TCP/IP的主机都会收到该DHCP Discovery报文,但是只有DHCP Server会响应该报文。
2.DHCP Server offer响应阶段
DHCP Server收到discover报文后,通过解析报文,查询dhcpd.conf配置文件,如果在地址池中能找到合适的IP地址,DHCP Server会给DHCP Client发送offer报文,告诉DHCP Client,该DHCP Server拥有资源,可以提供DHCP服务。
3.DHCP Client请求使用阶段
当DHCP Client收到offer报文时,知道在本网段中有可用的DHCP Server可以提供DHCP服务,因此,它会发送一个request请求报文,向该DHCP Server请求IP地址、掩码、网关、DNS等信息,以便登陆网络。
4.DHCP Server确认使用阶段(获得IP地址)
当DHCP Server收到DHCP Client发送的DHCP Request后,确认要为该DHCP Client提供的IP地址后,便向该DHCP Client响应一个包含该IP地址以及其他Option的报文,来告诉DHCP Client可以使用该IP地址了。然后DHCP Client即可以将该IP地址与网卡绑定。另外其他DHCP Server都将收回自己之前为DHCP Client提供的IP地址。
5. DHCP Client重新登录网络阶段
当DHCP Client重新登录后,发送一个以前的DHCP Server分配的IP地址信息的DHCP Request报文,当DHCP Server收到该请求后,会尝试让DHCP客户端继续使用该IP地址。并回答一个ACK报文。
如果该IP地址无法再次分配给该DHCP Client后,DHCP回复一个NAK报文,当DHCP Client收到该NAK报文后,会重新发送DHCP Discovery报文来重新获取IP地址。
6. DHCP Client续约阶段
DHCP获取到的IP地址都有一个租约,租约过期后,DHCP Server将回收该IP地址,所以如果DHCP Client如果想继续使用该IP地址,则必须更新器租约。更新的方式就是,当当前租约期限过了一半后,DHCP Client都会发送DHCP Renew报文来续约租期。
# 用户访问网站流程框架
第一步:客户端用户从浏览器输入www.baidu.com网站网址后回车,系统会查询本地hosts文件及DNS缓存信息,查找是否存在网址对应的IP解析记录。如果有就直接获取到IP地址,然后访问网站,一般第一次请求时,DNS缓存是没有解析记录的;
第二步:如果客户端没有DNS缓存或hosts没有对应www.baidu.com网站网址的域名解析记录,那么,系统会把浏览器的解析请求,交给客户端本地设置的DNS服务器地址解析(此DNS为LDNS,即Local DNS),如果LDNS服务器的本地缓存有对应的解析记录,就会直接返回IP地址;如果没有,LDNS会负责继续请求其它的DNS服务器;
第三步:LDNS会从DNS系统的“.”根开始请求www.baidu.com域名的解析,经过一系列的查找各个层次DNS服务器,最终会查找到www.baidu.com域名对应的授权DNS服务器,而这个授权DNS服务器,正是该企业购买域名时用于管理域名解析的服务器。这个服务器有www.baidu.com对应的IP解析记录,如果此时都没有,就表示企业的运维人员么有给www.baidu.com域名做解析;
第四步:baidu.com域名对应的授权DNS服务器会把www.baidu.com对应的最终IP解析记录发给LDNS;
第五步:LDNS把收到来自授权DNS服务器关于www.baidu.com对应的IP解析记录发给客户端浏览器,并且在LDNS本地把域名和IP的对应解析缓存起来,以便下一次更快的返回相同的解析请求的记录;
第六步:客户端浏览器获取到了www.baidu.com的对应IP地址,接下来浏览器会请求获得的IP地址对应的Web服务器,Web服务器接收到客户的请求并响应处理,将客户请求的内容返回给客户端浏览器;
至此,一次访问浏览网页的完整过程就完成了。
DNS解析原理
dns解析的流程:计算机之间只能通过ip相互通信,因为ip不好记,于是才使用dns服务器把域名解析为相应的ip,这里以解析www.baidu.com为例,当我们输入这个网址回车的时候,浏览器会首先查询浏览器的缓存,这个缓存存活时间可能只有1分钟,如果没找到,则去查询本地的dns缓存和hosts文件,如果有www.baidu.com这个域名对应的ip,则直接通过这个ip访问网站服务器。如果本地的dns缓存和hosts文件没找到,这时候就会把请求发送给,网卡配置信息里的dns服务器,默认有两个,只有当dns1不能访问时,才会使用dns2。我们也称网卡配置信息里的dns为local dns,这时候local dns会先查询它的缓存,有没有www.baidu.com相应的记录,如果有,则返回给用户,如果没有,就会访问根域名服务器,世界一共有13台根域名服务器,根域名服务器一看,是找.com的,于是会把.com的顶级域名服务器的ip发送给local dns,这时local dns再次访问.com的顶级域名服务器,.com的顶级域名服务器一看,是找一级域名baidu.com的,于是再将baidu.com的ip发送给local dns,然后继续往下找,直到找到www.baidu.com的权威dns的A记录或者cname,这时候local dns会把找到的www.baidu.com的ip发送给客户端,并记录在缓存中,这样的话,下次如果有其他的用户访问www.baidu.com这个域名时,local dns的缓存中就有记录了。客户端收到local dns发送过来的ip就会通过ip去访问服务器,并将这个ip记录在dns缓存中。
它的主要功能是通过网络让不同的机器系统之间可以彼此共享文件和目录。NFS服务器可以允许NFS客户端将远端NFS服务器端的共享目录挂载到本地的NFS客户端中。在本地的NFS客户端的机器看来,NFS服务器端共享的目录就好像自己的磁盘分区和目录一样。一般客户端挂载到本地目录的名字可以随便,但为方便管理,我们要和服务器端一样比较好。
NFS就是网络共享目录或共享文件。服务端共享,客户端挂载使用。挂载流程原理:
1)首先服务器端启动RPC服务,并开启111端口
2)启动NFS服务,并向RPC注册端口信息
3)客户端启动RPC(portmap服务),向服务端的RPC(portmap)服务请求服务端的NFS端口
4)服务端的RPC(portmap)服务反馈NFS端口信息给客户端。
5)客户端通过获取的NFS端口来建立和服务端的NFS连接并进行数据的传输。
主动模式下,FTP客户端从任意的非特殊的端口(N > 1023)连入到FTP服务器的命令端口--21
端口。然后客户端在N+1(N+1 >= 1024)端口监听,并且通过N+1(N+1 >= 1024)端口发送命令给FTP服务器。服务器会反过来连接用户本地指定的数据端口,比如20端口。
以服务器端防火墙为立足点,要支持主动模式FTP需要打开如下交互中使用到的端口:
FTP服务器命令(21)端口接受客户端任意端口(客户端初始连接)
FTP服务器命令(21)端口到客户端端口(>1023)(服务器响应客户端命令)
FTP服务器数据(20)端口到客户端端口(>1023)(服务器初始化数据连接到客户端数据端口)
FTP服务器数据(20)端口接受客户端端口(>1023)(客户端发送ACK包到服务器的数据端口)
用图表示如下:
优缺点:
主动模式对ftp对服务器管理有利,是由FTP服务器主动与客户端的高位随机端口建立连接,而这个端口很有可能被客户端的防火墙阻塞。而被动模式对客户端管理有效,它是企图与服务端的随机端口建立连接但是这个端口很可能又会被服务端的防火墙所拒绝。
被动模式FTP
为了解决服务器发起到客户的连接的问题,人们开发了一种不同的FTP连接方式。这就是所谓的被
动方式,或者叫做PASV,当客户端通知服务器它处于被动模式时才启用。在被动方式FTP中,命令连接和数据连接都由客户端,这样就可以解决从服务器到客户端的数据端口的入方向连接被防火墙过滤掉的问题。当开启一个FTP连接时,客户端打开两个任意的非特权本地端口(N >; 1024和N+1)。第一个端口连接服务器的21端口,但与主动方式的FTP不同,客户端不会提交PORT命令并允许服务器来回连它的数据端口,而是提交PASV命令。这样做的结果是服务器会开启一个任意的非特权端口(P >; 1024),并发送PORT P命令给客户端。然后客户端发起从本地端口N+1到服务器的端口P的连接用来传送数据。
对于服务器端的防火墙来说,必须允许下面的通讯才能支持被动方式的FTP:
FTP服务器命令(21)端口接受客户端任意端口(客户端初始连接)
FTP服务器命令(21)端口到客户端端口(>1023)(服务器响应客户端命令)
FTP服务器数据端口(>1023)接受客户端端口(>1023)(客户端初始化数据连接到服务器指定的任意端口)
FTP服务器数据端口(>1023)到客户端端口(>1023)(服务器发送ACK响应和数据到客户端的数据端口)
用图表示如下:
Kickstart是一种无人值守的安装方式。它的工作原理是在安装过程中记录典型的需要人工干预填写的各种参数,并生成一个名为ks.cfg的文件。如果在安装过程中(不只局限于生成Kickstart安装文件的机器)出现要填写参数的情况,安装程序首先会去查找Kickstart生成的文件,如果找到合适的参数,就采用所找到的参数;如果没有找到合适的参数,便需要安装者手工干预了。所以,如果Kickstart文件涵盖了安装过程中可能出现的所有需要填写的参数,那么安装者完全可以只告诉安装程序从何处取ks.cfg文件,然后就去忙自己的事情。等安装完毕,安装程序会根据ks.cfg中的设置重启系统,并结束安装。
PXE+Kickstart 无人值守安装操作系统完整过程如下: