字节跳动抖音研发---测试开发三面---面经（附答案）【接口/自动化/web】测试面试题

目录

一：前言

【文章的末尾给大家留下了大量的福利哦。】

一、为什么连接的时候是三次握手，关闭的时候却是四次握手？

二、TCP 连接为 什么 C lient 会在发送出 ACK 之后进入到 TIME_WAIT

三、为什么不能用两次握手进行连接？

四、如果已经建立了连接，但是客户端突然出现故障了怎么办，

五、HTTPS 和 HTTP 的区别：

六、HTTPS 的优点

七、HTTPS 的缺点

八、http 切换到 HTTPS 如何实现

九、网站从 http 过度到 https 需要注意的几个小问题

十、POST 和 GET 的区别

十一、HTTP 常见状态码介绍

十二、什么是泛型？

十三、IO 密集型与 CPU 密集型操作

十四、什么是多态？为什么使用多态？

十五、动态内存回收对程序员有什么好处

十六、浏览器、安卓、ios 系统之间的区别

十七、什么是幂等性？

十八、在 TCP/IP 协议有四层。

十九、http 协议中的信息头 header 包含什么

二十、TCP 的优点

---

一：前言

嗨咯铁汁们，很久不见，我还是你们的老朋友凡叔，因为看到最近很多的看凡叔文章的小伙伴都在面试，这里给大家出了一篇关于字节的面试题总结，当然也结合了常见的测试面试题，因为篇幅的原因这篇文章只有【1.2w字】但是！注意但是

【文章的末尾给大家留下了大量的福利哦。】

当然大量的大厂面试全套福利肯定少不了。废话少说咱们直接上干货。

一、为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当 Server 端收到 Client 端的 SYN( 同步序列编号 ) 连接请求报文后，可以直接发送

SYN+ACK 报文。其中 ACK 报文是用来应答的， SYN 报文是用来同步的。但是关闭连接时，当

Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET ，所以只能先回复一个 ACK 报文，

告诉 Client 端， " 你发的 FIN 报文我收到了 " 。只有等到我 Server 端所有的报文都发送完了，

我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。

1.1传输层 TCP 传输报文

位于传输层的 TCP 协议为传输报文提供可靠的字节流服务。它为了方便传输，将大块的数

据分割成以报文段为单位的数据包进行管理，并为它们编号，方便服务器接收时能准确地还

原报文信息。 TCP 协议通过 “ 三次握手 ” 等方法保证传输的安全可靠。

客户端发送一个带有 SYN 标志的数据包给服务端，在一定的延迟时间内等待接收的回复。

服务端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息，最后客户端再回

传一个带 ACK 标志的数据包，代表握手结束，连接成功。

SYN （

Synchronize Sequence Numbers ）同步序列编号

ACK (Acknowledgement ）确认字符

FIN （ Finish ）结束标志

发送端发送一个 SYN=1 ， ACK=0 标志的数据包给接收端，请求进行连接，这是第一次握手；

接收端收到请求并且允许连接的话，就会发送一个 SYN=1 ， ACK=1 标志的数据包给发送端，

告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；最后，发送端

发送一个 SYN=0 ， ACK=1 的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之

后，一个 TCP 连接建立，开始通讯。

下图也可以这么理解：

客户端： “ 你好，在家不，有你快递。 ”---SYN

服务端： “ 在的，送来就行。 ”-----SYN/ACK

客户端： “ 好嘞。 ”-----ACK 关闭 TCP 连接

为了避免服务器与客户端双方的资源占用和损耗，当双方没有请求或响应传递时，任意一方都可以发起关

闭请求。与创建 TCP 连接的 3 次握手类似，关闭 TCP 连接，需要 4 次握手。

SYN （

Synchronize Sequence Numbers ）同步序列编号

ACK (Acknowledgement ）确认字符

FIN （ Finish ）结束标志

4 次握手

上图可以这么理解：

客户端： “ 兄弟，我这边没数据要传了，咱关闭连接吧。 ”----FIN

服务端： “ 收到，我看看我这边有木有数据了。 ”----ACK

服务端： “ 兄弟，我这边也没数据要传你了，咱可以关闭连接了。 ”----FIN

客户端： “ 好嘞。 ”----ACK

二、TCP 连接为 什么 C lient 会在发送出 ACK 之后进入到 TIME_WAIT

状态需要经过 2MSL(最大报文段生存时间)才能返回到 CLOSE 状态？ 答：虽然按道理，四个报文都发送完毕，我们可以直接进入 CLOSE 状态了，但是我们必须假

象网络是不可靠的，有可能最后一个 ACK 丢失。所以 TIME_WAIT 状态就是用来重发可能丢

失的 ACK 报文。在 Client 发送出最后的 ACK 回复，但该 ACK 可能丢失。 Server 如果没有收

到 ACK ，将不断重复发送 FIN 片段。所以 Client 不能立即关闭，它必须确认 Server 接收到了

该 ACK 。 Client 会在发送出 ACK 之后进入到 TIME_WAIT 状态。 Client 会设置一个计时器，等

待 2MSL 的时间。如果在该时间内再次收到 FIN ，那么 Client 会重发 ACK 并再次等待 2MSL 。

所谓的 2MSL 是两倍的 MSL(Maximum Segment Lifetime) 。 MSL 指一个片段在网络中最大的存

活时间， 2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL ， Client 都没有再

次收到 FIN ，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。

三、为什么不能用两次握手进行连接？

答： 3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作 ( 双方都知道彼此已

准备好 ) ，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机 S 和

C 之间的通信，假定 C 给 S 发送一个连接请求分组， S 收到了这个分组，并发 送了确认应答

分组。按照两次握手的协定， S 认为连接已经成功地建立了，可以开始发送数据分组。可是，

C 在 S 的应答分组在传输中被丢失的情况下，将不知道 S 是否已准备好，不知道 S 建立什么

样的序列号， C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下， C 认为连接还未

建立成功，将忽略 S 发来的任何数据分组，只等待连接确认应答分组。而 S 在发出的分组超

时后，重复发送同样的分组。这样就形成了死锁。

四、如果已经建立了连接，但是客户端突然出现故障了怎么办，

Server

端怎么处理？

TCP 心跳包的发送，通常有两种技术：

1. 应用层自己实现的心跳包

由应用程序自己发送心跳包来检测连接是否正常，服务器每隔一定时间向客户端发送一个短

小的数据包，然后启动一个线程，在线程中不断检测客户端的回应， 如果在一定时间内没

有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没有收到服

务器的心跳包，则认为连接不可用。

2. 使用 SO_KEEPALIVE 套接字选项

在 TCP 的机制里面，本身是存在有心跳包的机制的，也就是 TCP 的选项 . 不论是服务端还是

客户端，一方开启 KeepAlive 功能后，就会自动在规定时间内向对方发送心跳包， 而另一方

在收到心跳包后就会自动回复，以告诉对方我仍然在线。因为开启 KeepAlive 功能需要消耗

额外的宽带和流量，所以 TCP 协议层默认并不开启默认的 KeepAlive 超时需要 7,200 ， 000 MilliSeconds ， 即 2 小时，探测次数为 5 次。对于很多服务端应用程序来说， 2 小时的空闲

时间太长。因此，我们需要手工开启 KeepAlive