求大神帮忙修改:php查询上中下级

$b = strrpos($a[0], '.'); //strrpos(被搜索字符串,要查找字符串,[查找开始的位置]) 查找字符串最后一次出现的位置: 找到则返回最后一次出现的位置;未找到则返回false

其实今天笔试的时候做这道题忘了怎么返回json格式的数据了,就直接用了Thinkphp的ajaxReturn,后来回来的时候查了一下才知道原来直接echo,这么简单,框架还是为辅吧,要多写原生。今天笔试的是一家手游公司,对数据库操作和原生要求比较多。

1.数据库的基本增删查改

基本的增删改查语句,关联语句,函数等过一遍

2.谈谈数据库优化的方法

(1)创建表的时候避免使用NULL默认值,因为NULL对于大多数数据库都需要进行特殊处理和索引逻辑等等。所以大多数时候不用NOT NULL,可以用特殊值0或1代替
(2)尽可能使用更小的字段类型,因为mysql从磁盘读取数据之后是存到内存当中,这意味着更小的数据类型使得从磁盘读取或者打包到内存效率会更好
(3)字符集的转换:客户端或者应用程序使用的字符集可能和数据库使用的字符集不一致,需要在mysql运行过程中隐含转化
(4)创建索引,如果一张表很大然后符合条件的值很多,那么创建索引就能带来性能的提升。但是如果像性别,只有两个值,就没必要建索引,而是用enum。一张表的索引最好不超过6个,太多的话会影响Insert和Update的效率,因此要考虑删除使用不频繁的索引
(5)先考虑在where和order by这两列上建立索引。尽量少在where子句中进行表达式操作、函数操作等等
FULLTEXT解析器用“ ”(空格)、“,”(逗号)“.”(点号)作为默认的单词分隔符,因此对于不使用这些分隔符的语言如汉语来说,FULLTEXT解析器不能正确的识别单词,对于这种情况需做额外处理。

(8)尽量满足范式(有的情况下要用反范式)下面是三大范式的区别,也要去看一下
第一范式:数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。如果实体中的某个属性有多个值时,必须拆分为不同的属性

第二范式:满足第一范式前提,当存在多个主键的时候,才会发生不符合第二范式的情况。比如有两个主键,不能存在这样的属性,它只依赖于其中一个主键,这就是不符合第二范式

第三范式:满足第二范式前提,如果某一属性依赖于其他非主键属性,而其他非主键属性又依赖于主键,那么这个属性就是间接依赖于主键,这被称作传递依赖于主属性。

(1)MyISAM强调性能,其执行速度比InnoDB类型更快,但不支持事务,而InnoDB提供事务支持以及外部键、行级锁等高级数据库功能
(2)如果增删改操作比较多,或者需要事务支持,则使用Innodb,如果是读的操作比较多,则使用Myisam

一、关于读写性能(QPS)
memcache更加快速,在性能上比redis快,缺点是仅支持字符串。
Redis支持丰富的数据结构类型,字符串,散列(哈希),集合,有序集合还支持订阅发布,地理位置等。
实际运用中可以结合二者,memcache可作为session存储的方式,session都是kv键值对。

Redis提供了多种不同级别的持久化方式:
RDB持久化可以在指定的时间间隔内生成数据集的时间点快照;
AOF持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。
AOF文件中的命令全部以Redis协议的格式来保存,新命令会被追加到文件的尾部,Redis还可以在后台对AOF文件进行重写(rewrite),使得AOF文件的体积不会超出保存数据集状态所需的实际大小。
Redis还可以同时使用AOF持久化和rob持久化,在这种情况下,当Redis重启时,它会优先使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比rob保存的数据更完整。

memcache是把所有的数据保存在内存中,采用hash表的方式,每条数据由key,value组成,每个key都是独一无二的,当要访问某个值得时候,先按照键找到值然后返回结果。memcache采用LPU(least recently used)算法来逐渐把过期数据清理掉。

1.写一个函数判断数组的深度

1.说一下常见的HTTP状态码

(1)消息(临时响应):1字头。
这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送 1xx 响应。
100: 服务器仅接收到部分请求
101: 服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。
代表请求已经被服务器所接收、理解、并接受
200: 请求成功(其后是对GET和POST请求的应答文档。)
201: 请求被创建完成,同时新的资源被创建。
(3)重定向:3字头。
表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。
300: 多重选择。链接列表。用户可以选择某链接到达目的地。
301: 页面永久重定向
302: 页面临时重定向
304: 资源未被修改,服务器告诉客户,原来缓冲的文档还可以继续使用
(4)请求错误:4字头。
这些状态代码表示请求可能出错,妨碍了服务器的处理
400: 服务器未能理解请求
401: 被请求的页面需要用户名和密码。
403: 对请求页面的访问被禁止。(通常为没有读权限)
404: 服务器无法找到被请求的页面。
408: 超出服务器等待时间
413: 由于所请求的实体的太大,服务器不会接受请求。
414: 由于url太长,服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时,就会发生这种情况。
(5)服务器错误:5字头。
这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误,而不是请求出错
500: 请求未完成。服务器遇到不可预知的情况。
502: 作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
503: 服务器临时过载或当机。

用ajax方法,把请求返回的参数(格式是json)填充到table中,以表格形式列出

data:(忘了发送的参数是什么了,随便写一下){

1.遇到问题时怎么解决(错误日志)

首先开启错误日志,配置php.ini
display_errors = Off ;本地测试开启,项目上线要关闭,防止服务器重要信息泄露 

配置完之后重启服务器即可,参考了php的异常和处理文章的一小段代码,自己另外做了测试

在上面提到的内容,其实有一些可以自己去拓展看一下的,比如提到innodb和myisam,前者是使用行锁,后者是使用表锁,那可以去拓展一下,什么是表锁什么事行锁,逐渐增大自己的知识面

IIS7批量FTP管理功能说明:
1、可批量导入,导出FTP信息
2、其他ftp工具有的功能,我们也有
3、特色功能:可以定时上传下载
4、数据信息列表化、一眼就能知道那个是那个
5、批量连接 标签页式切换 方便快捷
6、7大连接模式 更多好的兼容
7、内嵌编辑器 有效解决普通txt记事本乱码
8、锁屏功能 当程序有规定时间内没人操作,则自动锁程序。输入密码才可以正常操作

本产品适用于:懒得记录FTP信息和有批量定时备份,上传下载的运维或站长。


ISO位于二层和三册之间,可认定为是2.5层

VPN/虚拟私有网络的分类:

  • 站点之间的基于互联网的IPSec
  • 路由器逐跳转发,最长匹配查找
  • 传统IP流量工程切换,备份,转发的问题
  • LDP/Label Distribution Protocol/标签分发协议: MPLS 体系中的一种主要协议。在 MPLS 网络中,两个标签交换路由器(LSR)必须用在它们之间或通过它们转发流量的标签上达成一致。[用UDP去发现邻居,TCP去建立邻居,目的端口号都为646]

    • 一是接入服务,即帮助用户接入Internet
    • 二是导航服务,即帮助用户在Internet上找到所需要的信息
    • 三是信息服务,即建立数据服务系统,收集、加工、存储信息,定期维护更新,并通过网络向用户提供信息内容服务。
  • PE/Provider Edge:服务提供商骨干网的边缘路由器,它相当于标签边缘路由器(LER)。

  • CE/Customer Edge/用户边缘设备:是服务提供商所连接的用户端路由器。CE路由器通过连接一个或多个PE路由器,为用户提供服务接入。CE路由器通常是一台IP路由器,它与连接的PE路由器建立邻接关系。

  • 控制平面:负责产生和维护路由信息以及标签信息

  • 标签分发协议/LDP/Label Distribution Protocol:负责标签的分配、标签转发信息表的建立、标签交换路径的建立、拆除等工作
  • 转发平面:即数据平面(Data Plane),负责普通IP报文的转发以及带MPLS标签报文的转发

  • TTL: 8bit,防止环路和数据无限转发
    1. 信源模式的MPLS中不使用TTL
  • 必须有IGP或静态路由
  • mpls lsr-id x.x.x.x–配置标签交换路由器的ID,该地址必须在全局路由可达,否则无法发现、建立邻居或邻居不稳定

MPLS标签的转发/标签的行为

  • PUSH Label:存在于入口的PE;会根据FEC/转发等价类(一般意义上是一个前缀)压入一个标签
  • SWAP:存在于P;进行标签的交换
  • POP:移除/弹出一层标签
  • 有时候需要关闭MPLS的TTL复制功能,如不希望边缘用户/CE知道PE内的具体信息
  • 建议在配置MPLS的时候也配置关闭TTL

用UDP去发现邻居,TCP去建立邻居,目的端口号都为646

  • 基本发现机制:发现直接连接在同一链路上的LSR邻居,目的地址224.0.0.2(224网段的组播地址的TTL值都为1)
  • 扩展发现机制:发现非直连的LSR邻居,单播形式
  • 对一个前缀向所有的邻居发送相同的标签
  • 两个设备之间有多个运行LDP的链路,但是会话依旧只有一个
  • 下游自主方式/DU/Downstream Unsolicited:默认情况下的标签分发方式,对于一个特定的FEC,LSR无需从上游获得标签请求消息即进行标签分配与分发;华为设备默认情况下只针对32位的路由来分发标签(因此在配置接口IP时应该配置成32位的后缀)(思科设备是对所有的静态和igp路由分发标签);下游分配的标签供上游使用的
  • 下游按需方式/DoD/Downstream on Demand:需要上游请求,下游设备才会进行标签的分配与分发
  • 定义:在LSP的建立过程中,LSR分配标签时采用的处理方式。
  • Independent/独立标签分配控制方式:本地LSR可以自主地分配一个标签绑定到某个FEC,并通告上游LSR,而无需等待下游的标签
  • Ordered/有序标签分配控制方式:默认的标签分配方式,对于LSR上某个FEC的标签映射,只有当该LSR已经具有此FEC下一跳的标签映射消息、或者该LSR就是此FEC的出节点时,该LSR才可以向上游发送此FEC的标签映射
  • 定义:对LSR收到的、但目前暂时不需要的标签映射的处理方式
  • Conservative/保守:对于从邻居LSR收到的标签映射,只有当邻居LSR是自己的下一跳才保留
  • Liberal/自由标签保持方式:默认的方式;对于从邻居LSR收到的标签映射,无论邻居LSR是不是自己的下一跳都保留,可以更快速地切换
  • 原本在MPLS的最后一跳需要查找FIB和LFIB,而MPLS域内PE又多,会造成效率低,因此有了PHP

  • PHP:在倒数第二跳收到了来自末跳设备的特殊标签(3,即隐式空标签,默认行为;0,即显示空标签~用于QoS)

  • 严格意义上不是只有最后一跳才做,任何设备都会做

  • 产生背景:由于LDP的收敛速度依赖于IGP路由的收敛,即LDP的收敛速度比IGP的收敛速度慢,因此可能导致:
    • 当主链路发生故障时,IGP路由和LSP均切换到备份链路上。但当主链路从故障中恢复时,由于LDP的收敛速度低于IGP,IGP会先切换回主链路,因此会造成LSP流量损失
    • 当主链路IGP正常但主链路的LDP会话发生故障时,由于IGP仍在使用主链路而备份链路不存在IGP,导致LSP链路无法建立,造成LSP流量丢失
    • 当某节点发生主备倒置时,LDP会话的建立可能晚于IGP的GR/Graceful Restart结束,从而发布链路的最大开销值,造成路由震荡
  • 产生背景:LDP是动态方式通告标签,一般情况下都使用LDP建立LSP,但若LDP协议出现问题,可能导致MPLS流量的丢失,因此对于某些关键数据或重要业务,通过配置静态LSP来确定传输路径

  • 特点:静态LSP需要通过手工配置来实现,不需要交互控制报文,资源消耗比较小,但通过静态方式建立的LSP不能根据网络topo变化动态调整,需要管理员预干涉,所以适用于topo简单且稳定的网络

    • 上一节点的出标签等于下一节点的入标签
  • 需要在Ingress/入口PE、Transit/传输P设备和Egress/出口PE上配置(因为LSP是单向的而数据包有来有回,因此在每个需要配置的设备上都需要配置双向)

▲因为LSP是单向的,所以不要忘记建立双向的LSP

  • 其中外层标签/公网标签是LDP分发的
  • 内层标签/VPN的标签/私网标签是MP-BGP协议(VPNV4)来自动分发的(每个VPNV4分配一条标签,仅出口PE了解内层标签,中间设备不关心内层标签)。

VRF/Virtual Route Forwarding/虚拟路由器转发:相当于把一个路由器划分成多个子虚拟路由器,不同的虚拟子路由器之间相互隔离(VRP,FIB等都隔离)

  • RD/route-distinguisher/路由区分符:64位长,必须拥有,建议RD是惟一的;目的是解决在PE和PE之间更新VPNv4路由的时候解决潜在的路由重叠问题
  • 不同的VPN之间的路由表通过VRF实现
  • PE上存在多个路由转发表,包括一个公网/全局路由转发表,以及一个或多个VPN路由转发表
  • 一个VPN实例/Site可以拥有多个接口,但一个接口只能属于一个VPN实例
  • 多个PE之间需要全互联或者需要有RR
  • 采用不同的地址族来区分不同的网络层协议,以便正确处理VPN-IPv4路由
  • 在PE设备间更新什么内容:
  • 如果客户端是IDG协议则需要双向重分布
  • 如果客户端是静态路由,需要手工书写静态路由指向客户站点,然后重发布到BGP的vpn实例中
  • 如果客户也是BGP协议,需要在BGP的vpn实例中激活邻居
  • 1.配置SP内的IGP(OSPF,ISIS等),以确定路由可达
  • 2.配置LDP(具体命令见上),以为BGP配置更新源,确保外层的LSP是连续的
    • ip add 15.1.1.1 24 --配置IP地址,此时的IP地址不是全局范围的单播地址(若在绑定vpn实例之前配置了IP地址,可能会被删除)
  • 存在的问题:在MPLS VPN的场景下的OSPF,改变了框架,PE设备成为ABR。MPLS区域被认为是超级区域0,所以得到了区域间的路由/inter-area[会造成问题,如若两个CE之间存在直连的低速备份链路,那么路由就不会走MPLS域而是走直连的备份链路]
  • 问题:因为同一个CE/vpn实例若运行的是BGP协议,那么他们的AS号就会配置成相同,在CE1通过MPLS传递给CE2的时候,因为AS_Path的放环机制,会丢弃传递过来的路由

描述:类似于MPLS VPN(L3 VPN),该为L2 VPN,也存在两层标签(私网+公网),封装双层VLAN Tag

  • 解决日益紧缺的公网VLAN ID资源问题(原本只有4096个Vlan可供使用,该技术将可使用的Vlan扩展到个)
  • 用户可以规划自己的私网VLAN ID
  • 提供一种较为简单的二层VPN解决方法
  • 使用户网络具有较高的独立性
    • 在PE的与CE相连接的接口视图下配置

使用了UDP的67和68的端口号

  • 自动分配:DHCP给主机指定一个永久的IP地址
  • 手动分配:对某几台指定的mac的电脑给他固定的IP地址
  • 动态分配:DHCP给主机指定一个有时间限制的IP地址,到时间或主机表明放弃该地址时,这个IP地址可以给其他主机使用
  • DHCP DISCOVER:客户端发出广播来寻找可用的服务器
  • DHCP OFFER:服务器用于相应DHCP DISCOVER报文,并指定相应的配置参数(可以是广播报文也可以是单播报文,根据Discovery报文的Flag字段选择)(IP,网关,租期,DNS等)
  • DHCP REQUEST:客户端发送给服务器来请求配置参数或者请求配置确认或续租(有广播报文,因为DHCP服务器可能有多个,用以通知某个服务器同意,其他服务器拒绝)(也有单播报文,在DHCP续87.5%租期的时候发送的Request就是单播报文)
  • DHCP ACK:服务器到客户端,含有配置参数包括IP地址(单播报文)
  • DHCP DELINE:当客户端发现地址已被使用时,用来通知服务器
  • DHCP INFORM:客户端已有IP地址时用它来向服务器请求其他的配置参数
  • DHCP NAK:由服务器发送给客户端来表明客户端的地址请求不正确或租赁已过期
  • DHCP RELAEASE:客户端要释放地址时用来通知服务器
  • 最重要的是单播路由可达
  • 在DHCP服务器上需要配置全局的DHCP配置,并配置单播路由可达
  • 为了更好的网络设计和拓展性
    • 绑定表包括mac地址,IP地址,租期时间, VLAN ID,接口信息
    • 信任/非信任端口:一般通向DHCP服务器(运营商网络内部)的端口设置为信任,其他端口(连接运营商网络外部的端口)都设置为不信任
  • Option82选项:DHCP协议报文的选项部分的一项,用于记录报文如端口类型,端口号,VLAN信息及其桥mac信息,是生成绑定表的重要部分
    • 一般都在交换机上配置,因为DHCP服务器一般都是连接交换机的
  • 相当于复制数据包到另外一个端口,以便于镜像端口的设备进行监视等操作
  • 用来方便管理员维护查看网络流量
  • 轻量级系统,向导式安装;免客户端,通过浏览器随时地管理网络
  • 面向不同客户提供相应的解决方案
  • 多厂商统一管理,采用被广泛使用的标准网络协议SNMP
  • 版本:精简版、标准版–主流应用、专业版

eSight可管理的设备:

  • 预适配华为H3C、CISCO、中兴等厂商的网络设备,以及IBM、HP、SUN等厂商的IT设备
  • 对于支持标准MIB的第三方设备,通过自定义设置就能达到与预置的第三方设备相同的管理能力
  • 对于不支持标准MIB的第三方设备,可通过打网元补丁的方式进行适配
    • NMS/Network Management System/网络管理系统:是SNMP网络的管理者,能够提供友好的人机交互界面,方便网络管理员完成大多数的网络管理工作
    • Agent:是SNMP网络的被管理者,负责接收、处理来自NMS的SNMP报文。在某些情况下,如接口状态发生改变时,Agent也会主动向NMS发送告警信息
  • Base/管理信息库:是被管理对象的集合。NMS管理设备的时候,通常会关注设备的一些参数,比如接口状态、CPU利用率等,这些参数就是被管理对象,在MIB中称为节点。每个Agent都有自己的MIB。MIB定义了节点之间的层次关系以及对象的一系列属性,比如对象的名称、访问权限和数据类型等。被管理设备都有自己的MIB文件,在NMS上编译这些MIB文件,就能生成该设备的MIB。NMS根据访问权限对MIB节点进行读/写操作,从而实现对Agent的管理

    • SNMPv1采用团体名(Community Name)认证机制。团体名类似于密码,用来限制NMS和Agent之间的通信。如果NMS配置的团体名和被管理设备上配置的团体名不同,则NMS和Agent不能建立SNMP连接,从而导致NMS无法访问Agent,Agent发送的告警信息也会被NMS丢弃
    • SNMPv2c也采用团体名认证机制。SNMPv2c对SNMPv1的功能进行了扩展:提供了更多的操作类型;支持更多的数据类型;提供了更丰富的错误代码,能够更细致地区分错误 —多数使用
    • SNMPv3采用USM(User-Based Security Model,基于用户的安全模型)认证机制。网络管理员可以配置认证和加密功能。认证用于验证报文发送方的合法性,避免非法用户的访问;加密则是对NMS和Agent之间的传输报文进行加密,以免被窃听。采用认证和加密功能可以为NMS和Agent之间的通信提供更高的安全性
  • SNMP的四种基本操作:

    • Inform操作:Agent使用该操作向NMS发送Inform报文。Agent要求NMS发送回应报文,因此,Inform报文比Trap报文更可靠,但消耗的系统资源更多。如果Agent在一定时间内没有收到NMS的回应报文,则会启动重发机制。只有SNMPv2c和SNMPv3支持Inform操作
  • 单服务器模式:B/S模式,支持多个浏览器同时接入
  • 分级部署模式:在该模式下,上级网管可以把下级网管加入到系统中并提供打开下级网管的链接。当用户点击下级网管连接时,将会弹出一个新的浏览器窗口,在新的浏览器窗口将会打开下级网管的主页

eSight添加设备的方式:

  • 批量添加:通过导入提供的excle表格来实现批量添加

传统网络面临哪些挑战:

  • 移动化加剧,要求一致的业务体验

  • 人工维护效率低,要求策略能灵活调整

  • 接入方式丰富,传统单点防御失效

  • 服务器侧:业务管理器/SM(准入控制,用户管理,业务随行),业务控制器/SC(与网络接入设备进行联动来进行策略的下发等),管理中心/MC(管理SM和SC,安全接入管理,终端管理,补丁管理,license管理)
  • 网络接入设备:防火墙,AR,交换机,AP
  • 用户侧:客户端,Web Portal,系统自带的802.1X的客户端
  • 准入控制:通过认证控制用户的接入
  • 访客管理:对访客的账号的申请、权限的分发等
  • 业务随行:在移动化办公时为接入用户提供一致化的策略、体验
  • 业务编排:对数据流进行区分、管控
  • 安全协防:通过关联分析网络中的日志,识别潜在的安全问题,并将发现的网络安全问题直观的展现给网络管理员
  • 终端安全:要求用户终端符合企业的安全规则(软件版本、补丁等)
  • mac认证:主要用于IP电话、打印机等没有认证界面的哑终端设备
  • 802.1X认证:可与华为全系列交换机、路由器及WLAN设备以及第三方标准802.1X交换机联动
  • Protal认证/Web认证:用户可以通过Web认证界面来实行认证,可与华为全系列交换机、路由器以及WLAN设备联动
  • 安全组:用户安全组(定义能够访问网络资源的用户),资源安全组(定义哪些资源能够被访问,如vlan,ip网段等)
  • 策略矩阵:即用户安全组到资源安全组的映射
  • 用户优先级:区分普通用户,vip用户等
  • IP-Group查询:方便管理员查询
  • 编排设备:负责业务流量的识别和分流重定向
  • 业务设备:负责将引导过来的流量进行业务处理
    • 出方向故障即交换机\编排设备转发给业务设备时故障:
    • 交换机直接转发,不转发给业务设备进行处理
  • 进入交换机方向的GRE隧道故障:当发现从业务设备到编排设备的链路故障时,编排设备会自动断开与该业务设备的链路连接,并对原本要流经该业务设备的流量进行直接转发或丢弃处理
  • 终端安全管理的4大趋势:

  • domain default —配置默认的域并关联之前配置的server,认证和计费模板
  • 在不同的交换机组中添加设备
  • 配置隔离域(如防病毒服务器,补丁服务器等)(策略>准入控制>认证授权>授权结果中>增加)
  • 配置认证后域(如各个部分的服务器等)(策略>准入控制>认证授权>授权结果中>增加)
  • 配置认证规则:策略>准入控制>认证授权>认证规则>增加
  • 配置授权规则:如安全检查不通过后分配到隔离域;安全检查通过后分配到认证后域(策略>准入控制>认证授权>授权规则中>增加)
  • 配置mac地址旁路认证、授权、计费等:为哑终端进行认证配置(资源>终端>终端列表)
  • 基本配置完成,可使用客户端的登陆软件/AnyOffice来验证检查

传统的IP网络无区别地对待所有数据包,采用的策略是FIFO/先进先出,对报文的延迟、抖动、丢包率和可靠性需求不提供任何承诺和保障。

要提高通信质量,就是要提高带宽、减少时延和抖动、降低丢包率

    • 带宽也称为吞吐量,是指在固定的时间内,从网络一端传输到另一端的最大数据位数,也可以理解为网络的两个节点之间特定数据流的平均速率。带宽的单位是比特/秒(bit/s)。

    • 通常情况下,带宽越大,数据通行能力就越强,网络服务质量就越好。这就好比高速公路,车道越多,车辆通行能力就越强,发生堵车的概率就越低。对于网络用户而言,都希望带宽越大越好,但是相应的网络运营和维护成本也就越高。

    • 时延是指一个报文或分组从网络的发送端到接收端所需要的延迟时间,一般由传输延迟及处理延迟组成。

    • 单个网络设备的时延包括传输时延、串行化时延、处理时延、以及队列时延

    • 以语音传输为例,时延是指从说话者开始说话到对方听到所说内容的时间。一般人们察觉不到小于100毫秒的延迟。当延迟在100毫秒和300毫秒之间时,说话者可以察觉到对方回复的轻微停顿,这种停顿可能会使通话双方都感觉到不舒服。超过300毫秒,延迟就会很明显,用户开始互相等待对方的回复。当通话的一方不能及时接收到期望的回复时,说话者可能会重复所说的话,这样会与远端延迟的回复碰撞,导致重复。

    • 网络拥塞会导致通过同一连接传输的分组延迟各不相同。抖动用来描述延迟变化的程度,也就是最大延迟与最小延迟的时间差。

    • 抖动对于实时性的传输是一个重要参数。例如,语音和视像等实时业务极不容忍抖动,因为抖动会造成语音或视像的断续。

    • 抖动也会影响一些网络协议的处理。有些协议是按固定的时间间隔发送交互性报文,抖动过大会导致协议震荡。

    • 所有传输系统都有抖动,只要抖动在规定容差之内就不会影响服务质量。利用缓存可以克服过量的抖动,但这将增加时延。

    • 丢包率是指在网络传输过程中丢失报文的数量占传输报文总数的百分比。少量的丢包对业务的影响并不大,例如,在语音传输中,丢失一个比特或一个分组的信息,通话双方往往注意不到。在视频的传输中,丢失一个比特或一个分组可能造成在屏幕上瞬间的波形干扰,但能很快恢复正常。

    • 使用TCP传送数据可以处理少量的丢包,因为TCP允许丢失的信息重发,但大量的丢包会影响传输效率。在QoS中,我们关注的是丢包的统计数据,也就是丢包率。所以正常传输时,将网络丢包率控制在一定范围内即可。

    • Best-Effort是最简单的QoS服务模型,用户可以在任何时候,发出任意数量的报文,而且不需要通知网络。提供Best-Effort服务时,网络尽最大的可能来发送报文,但对时延、丢包率等性能不提供任何保证。
    • Best-Effort服务模型适用于对时延、丢包率等性能要求不高的业务,是现在Internet的缺省服务模型,它适用于绝大多数网络应用,如FTP、E-Mail等。
    • 只能通过提升外在的链路、设备性能来解决网络的问题
    • IntServ模型是指用户在发送报文前,需要通过信令(Signaling)向网络描述自己的流量参数,申请特定的QoS服务。网络根据流量参数,预留资源以承诺满足该请求。在收到确认信息,确定网络已经为这个应用程序的报文预留了资源后,应用程序才开始发送报文。应用程序发送的报文应该控制在流量参数描述的范围内。网络节点需要为每个流维护一个状态,并基于这个状态执行相应的QoS动作,来满足对应用程序的承诺。

    • IntServ模型使用了RSVP(Resource Reservation Protocol)协议作为信令,在一条已知路径的网络拓扑上预留带宽、优先级等资源,路径沿途的各网元必须为每个要求服务质量保证的数据流预留想要的资源,通过RSVP信息的预留,各网元可以判断是否有足够的资源可以使用。只有所有的网元都给RSVP提供了足够的资源,“路径”方可建立。

    • DiffServ模型的基本原理是将网络中的流量分成多个类,每个类享受不同的处理,尤其是网络出现拥塞时不同的类会享受不同级别的处理。同一类的业务在网络中会被聚合起来统一发送,保证相同的时延、抖动、丢包率等QoS指标。

    • 与Intserv模型相比,DiffServ模型不需要信令。在DiffServ模型中,应用程序发出报文前,不需要预先向网络提出资源申请,而是通过设置报文的QoS参数信息,来告知网络节点它的QoS需求。网络不需要为每个流维护状态,而是根据每个报文流指定的QoS参数信息来提供差分服务,即对报文的服务等级划分,有差别地进行流量控制和转发,提供端到端的QoS保证。DiffServ模型充分考虑了IP网络本身灵活性、可扩展性强的特点,将复杂的服务质量保证通过报文自身携带的信息转换为单跳行为,从而大大减少了信令的工作,是当前网络中的主流服务模型。

交换机、路由器、防火墙、WLAN等产品均支持配置基于DiffServ服务模型的QoS业务。基于DiffServ模型的QoS业务主要分为以下几大类:

  • 要实现差分服务,需要首先将数据包分为不同的类别或者设置为不同的优先级。报文分类即把数据包分为不同的类别,可以通过MQC配置中的流分类实现;报文标记即为数据包设置不同的优先级,可以通过优先级映射和重标记优先级实现。

  • 流量监管、流量整形和接口限速

    流量监管和流量整形可以将业务流量限制在特定的带宽内,当业务流量超过额定带宽时,超过的流量将被丢弃或缓存。其中,将超过的流量丢弃的技术称为流量监管,将超过的流量缓存的技术称为流量整形。接口限速分为基于接口的流量监管和基于接口的流量整形。

  • 拥塞管理在网络发生拥塞时,将报文放入队列中缓存,并采取某种调度算法安排报文的转发次序。而拥塞避免可以监督网络资源的使用情况,当发现拥塞有加剧的趋势时采取主动丢弃报文的策略,通过调整流量来解除网络的过载。

其中,报文分类和标记是实现差分服务的前提和基础;流量监管、流量整形、接口限速、拥塞管理和拥塞避免从不同方面对网络流量及其分配的资源实施控制,是提供差分服务的具体体现。

  • 在MPLS中根据数据包的EXP字段来标识QoS服务等级

    • DSCP的两种表达方式:

      • 数字表达方式:0`63
        • CS:对应路由器的协议

        • EF:对应承载语音的流量,因为其要求低延迟、低抖动、低丢包率

        • AF4:对应语音的信令流量,其优先级低于语音流量是因为相对于语音流量而言其允许一定的丢包和延迟

        • AF3:对应电视的直播流量

        • AF1:对应普通上网业务

简单流分类:使用上述的MPLS,Vlan Tag,IPv4,IPv6的优先级字段进行分类。但是针对某些特殊需求,简单流分类则无法实现

流量监管、流量整形和接口限速

流量监管:将超过的流量丢弃

  • 优点:可实现对不同报文的限速即重标记
  • 缺点:较高的丢包率;链路空闲时带宽得不到充分利用

流量整形:将超过的流量缓存

  • 优点:可实现对不同报文分别进行限速;缓冲机制可减少带宽浪费,减少流量重传
  • 缺点:可能增加延迟,需要较多的设备缓冲资源
  • 增加了报文传输的时延和抖动
  • 过高的延迟会引起报文重传
  • 使网络的有效吞吐量降低,造成网络资源的损害
  • 加剧耗费大量的网络资源(特别是存储资源),不合理的资源分配甚至可能导致系统陷入资源死锁而崩溃
  1. 有些数据包本身携带优先级,根据其携带的优先级分类不同的队列
  2. 选择队列的调度算法。队列的调度机制:FIFO、PQ、WRR、WFQ、CBQ等
    1. FIFO/先进先出:默认的方式
      1. 优点:实现机制简单且处理速度快
      2. 缺点:不能有差别地对待优先级不同的报文
      1. 优点:对高优先级的报文提供了优先转发
      2. 缺点:低优先级报文可能出现“饿死”情况
    2. WRR/Weighted Round Robin/加权循环调度:根据权重发送,一轮发送一个数据包,一轮权重减1,权重为0则不能发送数据包。当所有队列的权重都为0时重置初始的权重
      1. 优点:避免了PQ的“饿死”现象
      2. 缺点:基于报文个数来调度,容易出现包长尺寸不同的报文出现不平等调度;低延迟业务得不到及时调整
      1. 优点:可完全按照权重分配带框;自动分类,配置简单
      2. 缺点:低时延业务得不到及时调度;无法实现用户自定义分类规则
      1. WFQ对报文按流进行分类(相同源IP地址,目的IP地址,源端口号,目的端口号,协议号,Precedence的报文属于同一个流),每一个流被分配到一个队列,该过程称为散列。WFQ入队过程采用HASH算法来自动完成,尽量将不同的流分入不同的队列。在出队的时候,WFQ按流的优先级(precedence)来分配每个流应占有出口的带宽。优先级的数值越小,所得的带宽越少。优先级的数值越大,所得的带宽越多。这样就保证了相同优先级业务之间的公平,体现了不同优先级业务之间的权值。
      2. 优点:提供了自定义类的支持;可为不同的业务定义不同的调度策略
      3. 缺点:由于涉及到复杂的流分类,故启用CBQ会消耗一定的系统资源
  • 尾丢弃:传统的方式,丢弃后面的超出的内容
    • 缺点1:会引发TCP全局同步

    • 解决办法:RED/早期随机检测/Random Early Detection:在队列未装满时先随机丢弃一部分报文,通过预先降低一部分TCP连接的传输速率来尽可能延缓TCP全局同步的到来

    • 缺点2:引起TCP饿死现象

    • 缺点3:无差别丢包----不区分普通业务和关键业务

    • 解决办法:WRED/Weighed Random Early Detection/带权早期检测:能解决上述的尾丢弃的三个缺点,且大大提高了链路带宽利用率

路由器、三层交换机、防火墙等都可以配置该协议

若怀疑存在虚拟网关,可在cmd下使用tracert命令验证

  • 将局域网内的一组物理网关设备划分在一起,称为一个备份组
  • 将多个物理网关加入到备份组中,形成一个虚拟网关,承担物理网关功能
  • 只要备份组中有一个物理网关正常工作,虚拟网关就仍然正常工作
  • 由一个主(Master)和多个备份(Backup)组成,功能上相当于一个虚拟网关
  • 虚拟网关具有一个虚拟IP地址,作为终端的网关IP地址
  • Master:负责应答虚拟IP地址的ARP请求,转发发往虚拟网关的数据包
  • 优先级:0~255,默认是100,越大越优先
    • 个人能配置的优先级:0~254
    • 优先级255:保留给IP地址拥有者使用(当本地的ip地址与vrrp配置的虚拟ip地址一样时,忽略之前配置的优先级,直接从Initiate状态到Master状态,优先级被置为255,直接成为Master)
    • 优先级0:用于触发Backup立即成为Master(如Master主动退出时)
    • 如果优先级一样则IP地址越大越优先
  • 抢占机制默认开启(只针对优先级的抢占,若优先级相同但是IP地址不同且此时已经选举好了Master和Backup则不能抢占)
  • 虚拟mac地址规则:00-00-5e(代表权威机构IANA)+00-01(代表是VRRP)+备份组的组编号的16进制数
    • Master默认1s发送一次VRRP通告报文,通告自己工作正常
    • 如果Backup等待了3个时间间隔后。仍然没有收到通告报文(或受到了优先级为0的报文–master主动退出),则认为自己是Master,并对外发送VRRP通告报文,重新进行Master的选举
    • 为了避免地主备转换,让Backup有足够的时间收集必要的信息(如路由信息),Backup接收到优先级较低的VRRP报文后,不会立即抢占成为Master,而是等待一定时间后,才会对外发送VRRP通告报文取代原来的Master
  1. 备份组的所有路由器默认先置为Backup,一定时间后若没有接收到优先级等参数优于自己的报文则变为Master,否则仍然保持Backup状态

作用:当Master上行链路故障时,自动修改优先级,重新选举Master

▲注意STP协议的影响,因此VRRP的Master应该和STP/RSTP/MSTP的根桥应该保持一致,否则可能引起次优路径

▲注意对DHCP的影响,不能配置为接口模式因为可能造成得到的网关不是虚拟的ip地址,因配置成全局模式

▲DHCP还需要注意:因为设置了多个DHCP服务器,默认情况下多个服务器分配的IP地址范围是一样的,若一个交换机故障(如sw1之前已经分发出了如1.0.0.250地址),另一个交换机可能还会分发故障交换机分发出的ip地址(如sw2之前没有分配1.0.0.250地址,因此会分配给新的请求主机),会造成ip地址冲突。------------------->因此配置DHCP服务器时,最好确保各个服务器分配的ip地址范围不冲突

目的:为了减小设备故障对业务的影响、提高网路的可用性,设备要能够尽快检测到与相邻设备的通信故障,以便能够及时采取措施,从而保证业务继续进行

  • 硬件检测:例如通过SDH/Synchronous Digital Hierarchy/同步数字体系告警检测链路故障。硬件检测的优点是可以很快发现故障,但并不是所有介质都能提供硬件检测。
  • 慢Hello机制:通常采用路由协议中的Hello报文机制。这种机制检测到故障所需时间为秒级。对于高速数据传输,例如吉比特速率级,超过1秒的检测时间将导致大量数据丢失;对于时延敏感的业务,例如语音业务,超过1秒的延迟也是不能接受的。并且,这种机制依赖于路由协议。
  • 其他检测机制:不同的协议有时会提供专用的检测机制,但在系统间互联互通时,这样的专用检测机制通常难以部署。
  • 解决了上述检测机制的不足
  • 通用、标准化、介质无关、协议无关、为上层协议服务
  • 全网统一的检测机制,用于快速检测,监控网路中链路或路由的转发联通状况
  • 保证邻居间能够快速检测到通信故障,从而快速建立起备用的通道恢复通信
  1. 本身没有发现机制,靠上层协议通知
  2. 建立BFD会话,周期性地发送BFD控制报文进行检测
  3. 检测到故障后,再通知上层协议
  • Down:会话处于Down状态或刚刚建立
  • Init:已经能够与对端系统通信,本端希望使会话进入Up状态。收到对端的Down状态的报文时从Down到Init
  • Up:会话已经建立成功。收到对端的Init状态的报文时,从Init到Up
  1. 控制报文方式:链路两端会话通过控制报文交互检测链路状态
  2. Echo报文方式:链路某一端通过发送Echo报文由另一端转发回来,实现对链路的双向检测(适用于某一端不能配置BFD的场景)
    • 单跳检测(绑定的是接口,即直连的)用UDP的3784端口
    • 多跳检测(绑定的是IP,可以是非直连的)用UDP的4784端口
  • Echo报文:用UDP的3785端口(用于某段不能配置BFD的场景)
  • 主动模式:主动发送BFD报文,不管是否收到对端发来的BFD控制报文,默认为该模式
  • 被动模式:不主动发送BFD报文,只有接受到对端发来的BFD报文才会发送
  • 至少需要有一个主动模式的设备才能正常建立会话
  • 异步模式:周期性地发送BFD控制报文,如果在检测时间内没有收到BFD控制报文则将会话Down,默认的模式
  • 查询模式:一旦BFD回话建立,不再周期性地发送BFD报文,而是通过其他机制检测连通性,减少大量BFD会话带来的开销
  • 与静态路由联动:静态路由本身没有任何检测机制

我要回帖

更多关于 php怎么修改数据库内容 的文章

 

随机推荐