xx公司面试总结(查漏补缺)

缘起

今天下午面了一家特别想去的公司,结果聊很多,但是……折了,不要问我为什么知道的,面试完本来说别的同事(一般会是 HR)再聊一下但结果是前台来直接送走这不是凉了是什么?

主要原因我想是:

  • 人家本来要求就高
  • 我有几个技术点答的不好

我想,折了就折了吧,我只能看能不能变废为宝,从中学到点什么,吸取什么教训什么的,于是就有了本篇面试总结。

心得

关于形而上

形而上,或者是高大上、高逼格的东西,面试中如果能适当的、不生硬的引出来,肯定是有加分的,尤其是对那些高大上的岗位(管理岗、架构师啥的),所以,这个要靠平时自己多准备。貌似我对这个没有天赋

知识点

面试期间,大概有三个技术点我是没答对或者没描述明白的。具体情况如下:

Page fault

以下来自维基百科

页缺失(英语:Page fault,又名硬错误、硬中断、分页错误、寻页缺失、缺页中断、页故障等)指的是当软件试图访问已映射在虚拟地址空间中,但是当前并未被加载在物理内存中的一个分页时,由中央处理器的内存管理单元所发出的中断。

通常情况下,用于处理此中断的程序是操作系统的一部分。如果操作系统判断此次访问是有效的,那么操作系统会尝试将相关的分页从硬盘上的虚拟内存文件中调入内存。而如果访问是不被允许的,那么操作系统通常会结束相关的进程。

虽然其名为“页缺失”错误,但实际上这并不一定是一种错误。而且这一机制对于利用虚拟内存来增加程序可用内存空间的操作系统(比如Microsoft Windows和各种类Unix系统)中都是常见且有必要的。

我理解其实 Page fault 就是当进程访问虚拟内存中的某个不在物理内存里的内存页的时候,CPU 的 MMU 发出的一个中断。

如果访问时合法的,所需的内存页会被交换进物理内存。

Page fault 的分类

软性

以下内容来自于维基百科

软性页缺失指页缺失发生时,相关的页已经被加载进内存,但是没有向MMU注册的情况。操作系统只需要在MMU中注册相关页对应的物理地址即可。

发生这种情况的可能性之一,是一块物理内存被两个或多个程序共享,操作系统已经为其中的一个装载并注册了相应的页,但是没有为另一个程序注册。

可能性之二,是该页已被从CPU的工作集中移除,但是尚未被交换到磁盘上。比如OpenVMS这样的使用次级页缓存的系统,就有可能会在工作集过大的情况下,将某页从工作集中去除,但是不写入硬盘也不擦除(比如说这一页被读出硬盘后没被修改过),只是放入空闲页表。除非有其他程序需要,导致这一页被分配出去了,不然这一页的内容不会被修改。当原程序再次需要该页内的数据时,如果这一页确实没有被分配出去,那么系统只需要重新为该页在MMU内注册映射即可。

硬性

以下内容来自于维基百科

与软性页缺失相反,硬性页缺失是指相关的页在页缺失发生时未被加载进内存的情况。这时操作系统需要:

  • 寻找到一个空闲的页。或者把另外一个使用中的页写到磁盘上(如果其在最后一次写入后发生了变化的话),并注销在 MMU 内的记录
  • 将数据读入被选定的页
  • 向 MMU 注册该页

硬性页缺失导致的性能损失是很大的。以一块 7200rpm 的主流机械硬盘为例,其平均寻道时间为 8.5 毫秒,读入内存需要 0.05 毫秒。相对的,DDR3 内存的访问延迟通常在数十到 100 纳秒之间,性能差距可能会达到 8 万到 22 万倍。

另外,有些操作系统会将程序的一部分延迟到需要使用的时候再加载入内存执行,以此来提升性能。这一特性也是通过捕获硬性页缺失达到的。

当硬性页缺失过于频繁的发生时,称发生系统颠簸(Thrashing)。

无效

以下内容来自于维基百科

当程序访问的虚拟地址是不存在于虚拟地址空间内的时候,则发生无效页缺失。一般来说这是个软件问题,但是也不排除硬件可能,比如因为内存故障而损坏了一个正确的指针。

具体动作与所使用的操作系统有关,比如 Windows 会使用异常机制向程序报告,而类 Unix 系统则会使用信号机制。如果程序未处理相关问题,那么操作系统会执行默认处理方式,通常是转储内存、终止相关的程序,然后向用户报告。

貌似这才是真正的“错误”。

TCP Fast Open

以下内容来自于维基百科

TCP 快速打开(英语:TCP Fast Open,简称 TFO )是对计算机网络中传输控制协议(TCP)连接的一种简化握手手续的拓展,用于提高两端点间连接的打开速度。

它通过握手开始时的 SYN 包中的 TFO cookie(一个 TCP 选项)来验证一个之前连接过的客户端。如果验证成功,它可以在三次握手最终的 ACK 包收到之前就开始发送数据,这样便跳过了一个绕路的行为,更在传输开始时就降低了延迟。这个加密的 Cookie 被存储在客户端,在一开始的连接时被设定好。然后每当客户端连接时,这个 Cookie 被重复返回。

此 Cookie 通常采用一种分组密码,私钥由服务器根据客户端的IP地址保存,生成一个第三方难以仿冒的消息认证码标签,即便第三方可以伪造源IP地址或从其他IP地址制造到同一个服务器的连接。尽管使用了加密技术来生成cookie,但 TFO 并不着眼于提供比它所替换的三次握手有更多的安全性,并且不对所产生的 TCP 连接提供任何形式的加密保护或端点身份认证。它的目的不是为了抵挡中间人攻击。

这个协议最早提出于 2011 年并在 2012 年 2 月时已为一个 IETF 互联网草案,这项规范最终在 2014 年 12 月作为RFC 7413 发布。

TFO 的具体过程

以下内容来自于维基百科

  1. 客户端发送 SYN 数据包,该数据包包含 Fast Open 选项,且该选项的 Cookie 为空,这表明客户端请求 Fast Open Cookie;
  2. 支持 TCP Fast Open 的服务器生成 Cookie,并将其置于 SYN-ACK 数据包中的 Fast Open 选项以发回客户端;
  3. 客户端收到 SYN-ACK 后,缓存 Fast Open 选项中的 Cookie。
实施TCP Fast Open

以下描述假定客户端在此前的 TCP 连接中已完成请求 Fast Open Cookie 的过程并存有有效的 Fast Open Cookie。

客户端发送 SYN 数据包,该数据包包含数据(对于非 TFO 的普通 TCP 握手过程,SYN 数据包中不包含数据)以及此前记录的 Cookie;
支持 TCP Fast Open 的服务器会对收到 Cookie 进行校验:如果 Cookie 有效,服务器将在 SYN-ACK 数据包中对 SYN和数据进行确认(Acknowledgement),服务器随后将数据递送至相应的应用程序;否则,服务器将丢弃 SYN 数据包中包含的数据,且其随后发出的 SYN-ACK 数据包将仅确认(Acknowledgement)SYN 的对应序列号;
如果服务器接受了 SYN 数据包中的数据,服务器可在握手完成之前发送数据;
客户端将发送 ACK 确认服务器发回的 SYN 以及数据,但如果客户端在初始的 SYN 数据包中发送的数据未被确认,则客户端将重新发送数据;
此后的 TCP 连接和非 TFO 的正常情况一致。
注:客户端在请求并存储了 Fast Open Cookie 之后,可以不断重复 TCP Fast Open 直至服务器认为 Cookie 无效(通常为过期)。

Docker 的网络模型

这里聊到的其实是指我在前公司用过的一个简单的 Docker 应用的网络模型,非常简单,就是桥接。