十月最新,小红书面试经历,问答超详细!

⼗⽉最新,⼩红书⾯试经历,问答超详细!
⼀⾯
⼀⾯⾯试官看着⼆⼗七⼋岁,⽂质彬彬,这哪⾥是写代码的,头发都飘起来了好么。上来就⼲项⽬,由于⼤家的项⽬都不太⼀样,所以对于项⽬部分我就说说我⾯试的时候经常遇到的问题
描述下项⽬
⼀⼝是吃不了胖⼦的,描述之前先憋着⽓掂量掂量⾃⼰所说的东西能不能唬住⾃⼰,然后唬住⾯试官。
项⽬中担任的⾓⾊
双立柱卧式带锯床对于⼤多数的我们⽽⾔,就是开发的⾓⾊,同样的道理,⾓⾊对应相应的职务,阐述⾃⼰做的内容能引⾯试官上钩,拉钩上吊⼀百年不许变。
在项⽬遇到什么困难铝制工艺品
这三个问题,是不是可以拎着脚趾拇都可以想出来,除⾮不是你做的,哈哈哈哈哈。不慌,不是我们做的也不怕,我们必须知道有个⽹站叫做Github,⼤⽜这么多,⾃⼰不是⼤⽜,难道不会学学⼈家麦。Clo
ne下来,搭建环境跑起来,开始调试修改,通过将模块拆分,进⼀步修改,这不就是你的项⽬吗,当然我不怎么建议⼤家这么操作啦。
项⽬被问的差不多了,开始怼基础知识,基础知识⽼四套,计算机⽹络,数据库,操作系统,数据结构(来吧,时刻准备着,真没吹⽜逼)
我看你简历中写着⽹络流量的还原,你应该对计算机⽹络⽐较熟悉?(注意哈,简历上写上去的东西,⾃⼰⼼⾥⼀定要有点B数),那我们说说计算机⽹络
说说计算机⽹络中TCP的三次握⼿吧
⾸先 Client 给 Server 发送⼀个SYN包,Server 接收到 SYN 回复SYN+ACK,然后客户端回复 ACK 表⽰收到。
你这样回答肯定是不会让⾯试官满意的,那就加点配料,不放佐料的菜怎么⾹?那就详细的安排⼀下
⾸先客户端的协议栈向服务端发送SYN包,同时告诉服务端当前发送的序列号是X,此时客户端进⼊ SYNC_SENT状态
服务端的协议栈收到这个包以后,使⽤ ACK 应答,此时应答的值为 X+1,表⽰对SYN 包 J 的确认,
同时服务端也发送⼀个SYN包,告诉客户端当前我的发送序列号是Y,此时服务端进⼊SYNC_RCVD状态
客户端协议栈收到 ACK 以后,应⽤程序通过connect调⽤表⽰服务端的单向连接成功,此时状态为ESTABLISHED,同时客户端协议栈对服务器端的 SYN 进⾏应答,此时数据为Y+1
服务端收到客户端的应答包,通过accept阻塞调⽤返回,此时服务端到客户单的单向连接也建⽴成功,服务器将进⼊ESTABLISHED状态这样是不是稍微有B格⼀点呢,⽽且还⽐较形象,当然为了加深⼤家对这个过程的印象,我再举个例⼦
**第⼀次握⼿:**⼩蓝给某⼥娃告⽩,说我喜欢你,然后我傻乎乎的等着回应
第⼆次握⼿:⼥⽣看我这颜值,秒回,⾃然就答应我啊,并回复我也喜欢你拉
第三次握⼿:我收到⼥⽣的回应说:“那晚上去吃⽕锅,看电影,理疗”
就这样在⼀起啦,那么后续是啥样呢?是不是得往下看看什么是四次挥⼿了(渣男⽯锤),⾮也,还在热恋期呢,专⼀的好吗。⾯试官会继续问你三次握⼿
⾯试官说:“那我问你,如果客户端发送的SYN丢失了或者其他原因导致Server⽆法处理,是什么原因?
这个场景⾮常常见,没有万⽆⼀失。在TCP的可靠传输中,如果SYN包在传输的过程中丢失,此时Client段会触发重传机制,但是也不是⽆脑的⼀直重传过去,重传的次数是受限制的,可以通过 tcp_syn_retries 这个配置项来决定。如果此时 tcp_syn_retries 的配置为3,那么其过程如下
TCP重传
当 Client 发送 SYN 后,如果过了1s还没有收到 Server 的回应,那么进⾏第⼀次的重传。如果经过了2s没有收到Sever的响应进⾏第⼆次的重传,⼀直重传tcp_syn_retries次。这⾥的重传三次,意味着当第⼀次发送SYN后,需要等待(1 +2 +4 +8)秒,如果还是没有响应,connect就会通过ETIMEOUT的错误返回。
说说四次挥⼿吧,哎,卑微的蓝蓝
金属钝化剂第⼀次挥⼿:⼥⽣觉得和这个男⽣不太合适,但是是个好⼈,决定提出分⼿,等待男⽣回应
第⼆次挥⼿:这男⽣吧,也是会玩⼉,直接说:”分就分“
第三次挥⼿:过了⼀段时间,男⽣觉得好没得⾯⼦:“我⼀个⼤⽼爷们,应该是我提出分⼿啊”,于是给⼥⽣说:我们分⼿吧
第四次挥⼿:⼥⽣看到这个消息,你是「」还是「神经病」?
TIMEWAIT了解哈,过多的TIMEWAIT怎么办,什么原因造成的?
回答问题的⽅法⽆外乎即是什么,为什么会出现以及可以解决的⽅案全自动打胶机
在TCP的四次挥⼿过程中,发起连接断开的⼀⽅会进⼊TIME_WAIT的状态。通常⼀个TCP连接通过对外开发端⼝的⽅式提供服务,在⾼并发的情况下,每个连接占⽤⼀个端⼝,但是端⼝是有限的以致于可能导致端⼝耗尽,所以就会出现’“服务时⽽好时⽽坏的情况”。
如下图所⽰的TCP四次挥⼿,TCP连接准备终⽌的时候会发送FIN报⽂,主机2进⼊CLOSE_WAIT状态并发送ACK应答。主机1会在TIMEWAIT停留2MSL的时间。
为什么不直接进⼊CLOSE转态,⽽是需要先等待2MSL,这段时间在⼲啥?
第⼀个原因是为了确保最后的ACK能够正常接收,从⽽有效的正常关闭。怎么理解,科学家们在设计TCP的时候,假设TCP报⽂会出错从⽽开始重传,如果主机1的报⽂没有传输成功,那么主机2就会重发FIN报⽂,此时主机1没有维护TIME_WAIT状态,就会失去上下⽂从⽽恢复RST,导致服被动关闭⼀⽅出现错误。
四次挥⼿
第⼆个原因是让旧链接的重复分节在⽹络中⾃然消失。
⼀次⽹络通信可能经过⽆数个路由器,交换机,不知道到底会是哪个环节出问题。我们为了标识⼀个连接,通过四元组的⽅式[源IP,源端⼝,⽬的IP,⽬的端⼝]。假设此时两个连接A,B。A连接在中途中断了,此时重新创建B连接,这个B连接的四元组和A连接⼀样,如果A 连接经过⼀段时间到达了⽬的地,那么B连接很有可能被认为是A连接的⼀部分,这样就会造成混乱。所以TCP设置了这样⼀个机制,让两个⽅向的分组都被丢弃。
那么TIME_WAIT有哪些危害?
过多的连接势必造成内存资源的浪费
对端⼝的占⽤。可开启的端⼝也就32768~61000
有没有对TCP进⾏优化过
哺乳睡衣
开玩笑,这东西复习过,尽管问,锤⼦不怕。优化的点很多,随便提⼀点,让后⽐较深的描述下这个过程就⾏⽐如调整哪些参数在某些特定的条件下会最优
我们应该都知道半连接,即收到SYN以后没有回复SYN+ACK的连接,那么Server每收到新的SYN包,
都会创建⼀个半连接,然后将这个半连接加⼊到半连接的队列(syn queue)中,syn queue的长度⼜是有限的,可以通过tcp_max_syn_backlog进⾏配置,当队列中积压的半连接数超过了配置的值,新的SYN包就会被抛弃。对于服务器⽽⾔,可能瞬间多了很多新的连接,所以通过调⼤该值,以防⽌SYN包被丢弃⽽导致Client收不到SYN+ACK。
就这样是不是就可以让⾯试官感觉,这⼩伙⼦有点东西。那怎么配置呢
电子签章技术配置syn queue
你以为⾯试官是傻⼦?当然不是,万⼀⾯试官问你:半连接积压较多,还有其他的原因?
哈哈哈,这说明⾯试官上钩了哇,来,我们看看还有啥原因
还有可能是因为恶意的Client在进⾏SYN Flood攻击。
SYN Flood攻击是个啥过程?
⾸先Client以较⾼频率发送SYN包,且这个SYN包的源IP不停的更换,对于Server来说,这是新的链接,就会给它分配⼀个半连接
Server的SYN+ACK会根据之前的SYN包IP,发现不是原来的IP,所以⽆法收到Client的ACK包,从⽽导致⽆法正确的建⽴连接,⾃然就让Server的半连接队列耗尽,⽆法响应正常的SYN包
那有没有什么⽅案解决这个问题?
那必须,毕竟⾯试嘛,需要让⾯试官问我们知道的内容。在Linux内核中引⼊了SYN Cookies机制,那看看这个机制是啥意思
⾸先Server收到SYN包,不分配资源保存Client的信息,⽽是根据SYN计算出Cookie值,然后将Cookie记录到SYN ACK并发送出去
如果是正常的情况,这个Cookies值会伴随着Client的ACK报⽂带回来
Server会根据这个Cookies检查ACK包的合法性,合法则创建连接
那么开启SYN Cookies的⽅法?
SYN Cookies
⽹络问到这就差不多了,挺好的,完全按照我的套路出牌。开始怼作系统
说下什么是⼤页内存
,我差点没反应过来,“⼤爷内存”,不过确实⽜逼,⼤页内存,记住了,是⼤页内存。
我们知道操作系统堆内存的管理采⽤多级页表和分页进⾏管理,操作系统给每个页的默认⼤⼩是4KB。假设当前进程使⽤的内存⽐较⼤为1GB,那么此时在页表中会占⽤1GB/4KB=26211个页表项,但是系统的TLB可容乃的页表项远远⼩于这个数量。所以当多个内存密集型应⽤访问内存的时候,就会导致过多的TLB没有命中,因此在特定的情况下会需要减少未命中次数,⼀个可⾏的办法即是增⼤每个页的尺⼨。
操作系统默认⽀持的⼤页为2MB,当使⽤1GB内存的时候,页表将占⽤512页表项,⼤⼤的提⾼TLB命中率从⽽提⾼性能。另外需要注意的是,⼤页内存分配的是物理内存,所以不会有换出磁盘的操作,所以没有缺页中断,也就不会引⼊访问磁盘的时延。
⾏,差不多时间了,写个简单代码吧,实现⼀个⽆重复字符的最长⼦串
思路:使⽤滑动窗⼝保证每个窗⼝的字母都是唯⼀的
使⽤ vectorm 来记录⼀个字母如果后⾯出现重复时,i 应该调整到的新位置
所以每次更新的时候都会保存 j + 1 ,即字母后⾯的位置
j 表⽰⼦串的最后⼀个字母,计算⼦串长度为 j - i + 1

本文发布于:2024-09-21 00:33:13,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/1/109777.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:连接   内存   试官   服务端   发送   导致   不会   需要
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议