TCP 三次握手与四次挥手面试题
1. TCP基本认识
TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
-
TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是
20个字节，如果使用了「选项」字段则会变长的。 -
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
TCP 和 UDP 应用场景：
由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：
FTP文件传输；- HTTP / HTTPS；
由于 UDP 面向无连接，它可以随时发送数据，再加上 UDP 本身的处理既简单又高效，因此经常用于：
- 包总量较少的通信，如
DNS、SNMP等； - 视频、音频等多媒体通信；
- 广播通信；
TCP 和 UDP 可以使用同一个端口
2. TCP连接建立
TCP 三次握手过程
- 一开始，客户端和服务端都处于
CLOSE状态。先是服务端主动监听某个端口，处于LISTEN状态 - 客户端会随机初始化序号（
client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把SYN标志位置为1，表示SYN报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN-SENT状态。 - 服务端收到客户端的
SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入client_isn + 1, 接着把SYN和ACK标志位置为1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于SYN-RCVD状态。 - 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部
ACK标志位置为1，其次「确认应答号」字段填入server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于ESTABLISHED状态。 - 服务端收到客户端的应答报文后，也进入
ESTABLISHED状态。
从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。
一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。
为什么是三次握手？不是两次、四次？
TCP 连接：
- 用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括 Socket、序列号和窗口大小称为连接。
所以，重要的是为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。
接下来，以三个方面分析三次握手的原因：
- 三次握手才可以阻止重复历史连接的初始化（主要原因）（在网络拥堵情况下）
- 三次握手才可以同步双方的初始序列号
- 三次握手才可以避免资源浪费
小结
TCP 建立连接时，通过三次握手能防止历史连接的建立，能帮助双方同步初始化序列号，能减少双方不必要的资源开销。序列号能够保证数据包不重复、不丢弃和按序传输。
不使用「两次握手」和「四次握手」的原因：
- 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
- 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。
什么是 SYN 攻击？如何避免 SYN 攻击？
假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务端不能为正常用户服务。
什么是 TCP 半连接和全连接队列。
在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：
- 半连接队列，也称 SYN 队列；
- 全连接队列，也称 Accept 队列；
不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，默认情况都会丢弃报文。
SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。
避免 SYN 攻击方式，可以有以下四种方法：
- 调大 netdev_max_backlog；当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数，默认值是 1000，我们要适当调大该参数的值，比如设置为 10000。
- 增大 TCP 半连接队列；
- 开启 tcp_syncookies；开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接，相当于绕过了 SYN 半连接来建立连接。
- 减少 SYN+ACK 重传次数；以加快处于 SYN_REVC 状态的 TCP 连接断开。
3. TCP连接断开
TCP 四次挥手过程
双方都可以主动断开连接，断开连接后主机中的「资源」将被释放。
你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。
为什么挥手需要四次？
再来回顾下四次挥手双方发 FIN 包的过程
- 关闭连接时，客户端向服务端发送
FIN时，仅仅表示客户端不再发送数据了但是还能接收数据。 - 服务端收到客户端的
FIN报文时，先回一个ACK应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN报文给客户端来表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。
但是在特定情况下，四次挥手是可以变成三次挥手的。
为什么 TIME_WAIT 等待的时间是 2MSL？
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。
TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
比如，如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。
可以看到 2MSL时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。
为什么需要 TIME_WAIT 状态？
主动发起关闭连接的一方，才会有 TIME-WAIT 状态。
需要 TIME-WAIT 状态，主要是两个原因：
- 防止历史连接中的数据，被后面相同四元组的连接错误的接收；状态会持续
2MSL时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。 - 保证「被动关闭连接」的一方，能被正确的关闭；等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。
服务器出现大量 TIME_WAIT 状态的原因有哪些？
首先要知道 TIME_WAIT 状态是主动关闭连接方才会出现的状态，所以如果服务器出现大量的 TIME_WAIT 状态的 TCP 连接，就是说明服务器主动断开了很多 TCP 连接。
问题来了，什么场景下服务端会主动断开连接呢？
- 第一个场景：HTTP 没有使用长连接。
- 第二个场景：HTTP 长连接超时。
- 第三个场景：HTTP 长连接的请求数量达到上限。对于一些 QPS 比较高的场景，比如超过 10000 QPS，甚至达到 30000 , 50000 甚至更高，如果 keepalive_requests 参数值是 100，这时候就 nginx 就会很频繁地关闭连接，那么此时服务端上就会出大量的 TIME_WAIT 状态。
服务器出现大量 CLOSE_WAIT 状态的原因有哪些？
CLOSE_WAIT 状态是「被动关闭方」才会有的状态，而且如果「被动关闭方」没有调用 close 函数关闭连接，那么就无法发出 FIN 报文，从而无法使得 CLOSE_WAIT 状态的连接转变为 LAST_ACK 状态。
所以，当服务端出现大量 CLOSE_WAIT 状态的连接的时候，说明服务端的程序没有调用 close 函数关闭连接。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
故障指的是客户端的主机发生了宕机，或者断电的场景。发生这种情况的时候，如果服务端一直不会发送数据给客户端，那么服务端是永远无法感知到客户端宕机这个事件的，也就是服务端的 TCP 连接将一直处于 ESTABLISH 状态，占用着系统资源。
为了避免这种情况，TCP 搞了个保活机制。这个机制的原理是这样的：
定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
4. Socket 编程
针对 TCP 应该如何 Socket 编程？
accept 发生在三次握手的哪一步？
客户端 connect 成功返回是在第二次握手，服务端 accept 成功返回是在三次握手成功之后。
为什么抓包抓到的 TCP 挥手是三次，而不是书上说的四次？
当被动关闭方（如服务端）在 TCP 挥手过程中，「没有数据要发送」并且「开启了 TCP 延迟确认机制」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。
而通常情况下，服务器端收到客户端的FIN后，很可能还没发送完数据，所以就会先回复客户端一个ACK包，稍等一会儿，完成所有数据包的发送后，才会发送FIN包，这也就是四次挥手了。
内容整理自小林coding复习笔记
