支持工程师面试题(某大型集团公司)题库详解.docxVIP

支持工程师面试题(某大型集团公司)题库详解

面试问答题（共20题）

第一题

请详细说明一下TCP协议三次握手过程的每个步骤，并解释为什么TCP连接建立需要经过三次握手而非两次或四次？

答案：

TCP三次握手过程详解：

TCP(TransmissionControlProtocol)连接建立需要经过三个步骤，确保通信双方都确认准备就绪，并且同步初始序列号。

第一次握手(SYN_SENT状态)：

过程：客户端（或主动方）向服务器（或被动方）发送一个SYN(SynchronizeSequenceNumbers)报文段。该报文段的SYN标志位被设置为1，同时包含一个客户端的初始序列号client_isn(ClientInitialSequenceNumber)。这个初始序列号是一个随机值，用于保证数据传输的序列号唯一性。

目的：请求建立连接。告诉服务器：“我准备发送数据了，请确认。”

第二次握手(SYN_RCVD状态)：

过程：服务器接收到客户端的SYN报文段后，如果同意建立连接，会向客户端发送一个确认报文段。这个报文段包含两个标志位：SYN和ACK(Acknowledgment)都被设置为1。SYN标志位表示服务器也请求建立连接，ACK标志位表示服务器确认收到了客户端的SYN。这个报文段的确认号ack_num等于客户端的初始序列号client_isn加1(ack_num=client_isn+1)。同时，服务器自身也会选择一个初始序列号server_isn(ServerInitialSequenceNumber)放在该报文段的序列号字段seq_num中。

目的：确认客户端的连接请求，并通知客户端：“我同意建立连接，也准备好了接收你的数据。”

第三次握手(ESTABLISHED状态)：

过程：客户端收到服务器的确认报文段后，会向服务器发送最后一个报文段来确认连接。这个报文段的ACK标志位被设置为1，SYN标志位被设置为0。这个报文段的确认号ack_num等于服务器的初始序列号server_isn加1(ack_num=server_isn+1)，序列号seq_num则等于客户端自己的初始序列号client_isn加1(seq_num=client_isn+1)。

目的：确认服务器已经收到了双方的连接请求和初始序列号，连接建立成功，双方都进入ESTABLISHED状态，可以开始进行双向数据传输。

为什么需要三次握手，而非两次或四次？

为什么不是两次握手？

无法保证双方都同步序列号：如果采用两次握手（客户端发SYN，服务器回复SYN-ACK），当服务器的SYN-ACK报文段在网络中延迟，并最终被客户端收到时，客户端虽然知道服务器同意了连接，但服务器并不知道自己之前发的SYN是否已经到达客户端并被处理。如果服务器没有收到客户端的初始ACK，它会认为连接已建立并开始发送数据，而客户端可能在“以为”连接成功建立的情况下执行了其他操作或发送了数据，这会导致连接混乱或数据丢失。

“已死连接”问题（ChurnProblem）：设想一个场景：客户端发送了SYN(步骤1)，但由于网络问题，这个SYN丢失了。客户端超时后会重发SYN(变成新的SYN1)，成功完成三次握手。与此同时，之前那个丢失的SYN突然到达了服务器。服务器收到这个旧的SYN后，会回复SYN-ACK(步骤2)，这个SYN-ACK也可能因为网络延迟而延迟很久才到达。服务器收到后，认为建立了连接，发送一个ACK给客户端，这个ACK也会因为网络延迟而延迟很久才到达。此时，客户端已经在“旧的连接”上收到服务器的SYN-ACK和ACK，进入ESTABLISHED状态（这是不可能的，因为旧的SYN早已超时）。如果服务器再次收到客户端为“新的连接”而发的第三个报文段(ACK2)，服务器会误认为这是对SYN1的确认，导致建立了一个从未被客户端实际建立连接的“幽灵连接”。三次握手可以有效防止这种“已死连接”问题，因为服务器只有在收到客户端的ACK(第三步)后，才会确认连接真正建立。

为什么不是四次握手？

三次握手已经足够完成确认双方意向、同步初始序列号、确保双方都准备好接收数据等核心任务。

增加到四次握手（例如，再让服务器在收到客户端的ACK后也发一个ACK回客户端）并不会带来额外的可靠性，只会增加一个多余的往返时间(RTT)，降低连接建立效率。

总结:TCP三次握手是一种设计精巧的机制，它保证了连接建立的可靠性（双方都确认了对方的接收能