实习面经-百度运维部

1.TCP 三次握手 四次挥手

这个问题以及问题2，6可以参见我之前的一篇博客，点击跳转

2.TCP 与 UDP区别

3.TCP 流量控制和拥塞控制

流量控制

利用滑动窗口实现流量控制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方就重新设置持续计时器。
流量控制：指点对点通信量的控制，是端到端之间的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

TCP的拥塞控制

拥塞：即对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随着负荷的增大而下降。
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
拥塞控制有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
拥塞控制代价：需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。拥塞控制还需要将一些资源分配给各个用户单独使用，使得网络资源不能更好地实现共享。

几种拥塞控制方法

慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。

慢开始和拥塞避免

发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始算法：当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
另，慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：
当 cwnd < ssthresh 时，使用上述的慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。
拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。

1. 当TCP连接进行初始化时，把拥塞窗口cwnd置为1。前面已说过，为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。慢开始门限的初始值设置为16个报文段，即cwnd = 16 。
2. 在执行慢开始算法时，拥塞窗口 cwnd的初始值为1。以后发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值加1，然后开始下一轮的传输（图中横坐标为传输轮次）。因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时（即当cwnd=16时），就改为执行拥塞控制算法，拥塞窗口按线性规律增长。
3. 假定拥塞窗口的数值增长到24时，网络出现超时（这很可能就是网络发生拥塞了）。更新后的ssthresh值变为12（即变为出现超时时的拥塞窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时间增加一个MSS的大小。
   强调：“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

快重传和快恢复

如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口 cwnd 减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。

接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

1. 当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意：接下去不执行慢开始算法。
2. 由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
   下图给出了快重传和快恢复的示意图，并标明了“TCP Reno版本”。
   区别：新的 TCP Reno 版本在快重传之后采用快恢复算法而不是采用慢开始算法。
   
   也有的快重传实现是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3 X MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络 的资源而是停留在接收方的缓存中。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大了些。
   在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。
   采用这样的拥塞控制方法使得TCP的性能有明显的改进。
   接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口rwnd 。
   发送方窗口的上限值 = Min [ rwnd, cwnd ]
   当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
   当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。
   此部分参考了博友

4.QQ通信原理

QQ登录到QQ服务器时，会建立一个TCP连接来保持在线状态，TCP连接的远程端口一般是80，采用UDP方式登陆时是8000，但服务器不会一直保持与客户端的tcp通信，之后使用udp每隔一段时间发送心跳数据包来确定qq客户端是否还在网络中存活。由于qq客户端的ip地址不定，但账号是唯一的，因此当客户端a发送连接请求，服务器接收后，知道a上线了，会把qq端的a的账号和ip记录下来，保存在一个表中或其他位置，同时服务器会告诉qq客户端在线好友的ip地址，当a需要与好友通信时，直接使用ip就ok了。qq客户端之间的通信有两种方式，一种是通过服务中转，另一种是客户端之间直接通信。

5.ARP与ARP攻击

ARP协议

ARP（Address Resolution Protocol，地址解析协议）是一个位于TCP/IP协议栈中的网络层协议，负责将某个IP地址解析成对应的MAC地址。
ARP协议的基本功能就是通过目标设备的IP地址，来查询目标设备的mac地址。在局域网的任意一台主机中，都有一个ARP缓存表，里面保存本机已知的此局域网中各主机和路由器的IP地址和MAC地址的对照关系。ARP缓存表的生命周期是有时限的（一般不超过20分钟）。

ARP协议的缺陷

ARP协议是建立在信任局域网内所有节点的基础上的，他的效率很高。但是不安全。它是无状态的协议。他不会检查自己是否发过请求包，也不知道自己是否发过请求包。他也不管是否合法的应答，只要收到目标mac地址是自己的ARP reply或者ARP广播包（包括ARP reply和ARP request），会接受并缓存。

ARP攻击的局限性

ARP攻击仅能在以太网（局域网如：机房、内网、公司网络等）进行。
无法对外网（互联网、非本区域内的局域网）进行攻击。

ARP攻击原理

例如：
主机 IP地址 MAC地址 网关
A 192.168.0.2 Mac-a 192.168.0.1
B 192.168.0.3 Mac-b 192.168.0.1
C 192.168.0.4 Mac-c 192.168.0.1
D 192.168.0.5 Mac-d 192.168.0.1
ARP欺骗攻击建立在局域网主机间相互信任的基础上的

当A发广播询问：我想知道IP是192.168.0.3的硬件地址是多少？

此时B当然会回话：我是IP192.168.0.3我的硬件地址是mac-b，

可是此时IP地址是192.168.0.4的C也非法回了：我是IP192.168.0.3,我的硬件地址是mac-c。而且是大量的。

所以A就会误信192.168.0.3的硬件地址是mac-c，而且动态更新缓存表

这样主机C就劫持了主机A发送给主机B的数据，这就是ARP欺骗的过程。

假如C直接冒充网关，此时主机C会不停的发送ARP欺骗广播，大声说：我的ＩＰ是１９２.１６８.０.１，我的硬件地址是ｍａｃ－ｃ，
此时局域网内所有主机都被欺骗，更改自己的缓存表，此时Ｃ将会监听到整个局域网发送给互联网的数据报。

通常表现

• 打开网页速度非常慢，甚至打不开
• 提示IP地址冲突
• 甚至导致校园网瘫痪断网
• 一般会绑定木马病毒，窃取用户账号密码

ARP攻击检测

手动监测
网络管理员可以通过命令查看主机的ARP表或路由器的ARP表
也可以用Sniffer工具进行抓包，查看可疑的

ARP攻击的防御

ARP双向绑定 ：
在pc端上 IP+mac 绑定
在网络设备（交换路由）上 采用ip+mac+端口绑定
网关也进行IP和mac的静态绑定
采用支持ARP过滤的防火墙
建立DHCP服务器
ARP攻击一般先攻击网关，将DHCP服务器建立在网关上
划分安全区域
ARP广播包是不能跨子网或网段传播的，网段可以隔离广播包。VLAN就是一个逻辑广播域，通过VLAN技术可以在局域网中创建多个子网，就在局域网中隔离了广播。。缩小感染范围。 但是，安全域划分太细会使局域网的管理和资源共享不方便。

6.用浏览求访问百度的具体过程

7.ES原理以及倒排索引

详见另一篇博客

8.数据库优化(select，解决访问量过大的问题）

针对此问题，对数据库优化方面的问题进行了简单整理。
(1)对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
(2)应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库

备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用NULL。

不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了， 不管是否插入值（NULL也包含在内），都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num = 0

(3)应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
(4)应尽量避免在 where 子句中使用 or 来连接查询条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or Name = 'admin'

可以这样查询：

select id from t where num = 10
union all
select id from t where Name = 'admin'

(5)in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

很多时候用 exists 代替 in 是一个好的选择：

select num from a where num in(select num from b)

可以用下面的方式代替：

select num from a where exists(select 1 from b where num=a.num)

(6)下面的查询也将导致全表扫描：

select id from t where name like ‘%abc%’

若要提高效率，可以考虑全文检索。
(7).应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2 = 100

改为：

select id from t where num = 100*2

(8)应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描;
不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。如：

//name以abc开头的id
select id from t where substring(name,1,3) = ’abc’ 
// ‘2005-11-30’    --生成的id     
select id from t where datediff(day,createdate,’2005-11-30′) = 0

应改为:

select id from t where name like 'abc%'
select id from t where createdate >= '2005-11-30' and createdate < '2005-12-1'

(9)在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
(10)Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时产生大量日志。
(11)对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高。
(12)select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的。
(13)索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。
(13)应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
(14)尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连 接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
(15)尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
(16)避免频繁创建和删除临时表，以减少系统表资源的消耗。临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件， 最好使用导出表。
(17)在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
(18)如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
(19)在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
(20)尽量避免大事务操作，提高系统并发能力。

9.数据库的读写锁

10.聚合索引

11.进程与线程的区别

12.非递归实现树的遍历

13.若网络不通，如何检测是哪一跳出了问题？

14.死锁的产生，预防以及避免

15.Redis集群的存取、容错机制

16.linux 常用命令，管道

感受

就我在面试过程中所得到信息，对此部门的认识：此部门需要解决百度各服务运行过程中出现的紧急问题，保证各业务正常对用户提供服务，对百度的各业务进行运行与维护。出现各种bug时需要能快速确定bug出现的位置及原因，快速解决bug；并在各业务正常运行过程中，主动检测可能存在的问题，进行优化。
对计算机网络基础知识要求较高，对语言及框架要求不高。