10.28 头条客户端一面凉经555
第一次面试,面试官很温柔也很帅~,人也特别好,虽然应该是凉了,但还是很感谢这位面试官
-
自我介绍
-
项目:关于优惠券,为什么不将优惠券领取表和优惠券使用表合成一个表?
-
三次握手、四次挥手
-
TCP的所有知识点(流量控制、拥塞控制…)
-
- 停止等待ARQ
- 发送窗口 = 1,接收窗口 = 1
- 发送端收到ACK之后才发送下一个报文段
- 信道利用率差
- 回退N帧ARQ(GBN)
- 发送窗口 > 1,接收窗口 = 1
- 如果某个报文没有被正确接收,则该报文之后的所有报文都要重传
- 累积确认(如果接收方确认了某一报文,说明在该报文之前的所有报文都被正确接收了)
- 在GBN机制下,接收方一次只交付一个分组给上层,并且保证按序
- 接收方不会对失序到达的分组进行缓存,而是丢弃
- 选择重传ARQ(SR)
- 发送窗口 > 1,接收窗口 > 1
- 为每个报文段设置单独的计时器,若计时器超时,只重发这一个计时器
- 不会累积确认
- TCP所采用的机制
- 累积确认(GBN)
- 接收端有缓存(SR),存放正确接收但失序的分组 (SACK:选择性确认机制,接收端会返回最近收到的报文段的序列号范围,这样发送端就知道哪些数据包已到达,与ACK相结合就知道要重发哪些)
- 停止等待ARQ
-
滑动窗口
- 图中分为四个部分:窗口左侧(已发送已确认)、窗口(已发送未确认、即将要发送未确认)、窗口右侧(未发送未确认)
- 滑动窗口的大小为 拥塞控制窗口 和 流量控制窗口 的最小值
- 作用:保证次序、提高吞吐量
-
- 如果发送方发送速率太快,可能会导致接收方来不及处理和接受数据,需要使用滑动窗口协议来控制发送方的传输速率
-
拥塞控制
- cwnd:拥塞窗口,ssthresh:慢开始门限值
- 首先进行慢开始(cwnd指数增加),当cwnd达到ssthresh时,开始执行拥塞避免(cwnd每次增加1)
- 当发送方的重传计时器超时时,说明网络可能出现了拥塞,①将ssthresh的值改为发生拥塞时cwnd的一半;②将cwnd的值减为1,重新开始慢开始
- 当发送方连续收到三个重复确认时,说明某个报文丢失,
- ① 执行快重传,即发送方立刻重传接收方未收到的报文段,不必等到重传计时器超时;
- ② 当接收方收到失序的报文段后立即发出确认,不要等到自己发送数据时捎带确认;
- ③ 执行快恢复,即将ssthresh减为发生拥塞时cwnd的一半;
- ④ 继续执行拥塞避免,而不是执行慢开始
-
-
七层协议
-
还知道哪些协议(我回的ARP协议)
-
DNS协议是哪一层的,DNS的知识点
- DNS是应用层!!(OMG当时我回的网络层,面试官还重复了一遍我的答案)
-
UDP的所有知识点
-
进程、线程,编程过程中有没有使用过进程线程
-
Python的特点
-
有一个1000行的代码,分别用Python、Java、C++运行有什么区别
-
面向对象的三个特点(封装、继承、多态)
- 重载:
- 一个类中多态性的表现
- 函数名相同
- 参数个数或参数类型不同
- 对返回值没有要求(不能通过返回值判断是不是重载)
- 重写:
- 父类与子类之间多态性的表现
- 函数名、参数列表、返回值必须相同
- 重写函数的访问修饰符一定要大于被重写函数的访问修饰符(public > protected > defult > private)
- 重写方法一定不能抛出新的检查异常或声明比被重写方法更加宽泛的检查型异常
- C++的STL库(SOS我讲的HashMap)vector、queue、stack、map(应该是想问底层的)
- 算法题:求两个有序数组的中位数 (还要说出时间复杂度和空间复杂度)