三次握手
第一次握手(syn=1)
客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序列号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
第二次握手(syn,ack=1)
服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态
第三次握手(ack=1)
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态
从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。
一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了
为什么是三次握手？不是两次、四次？
因为三次握手才能保证双方具有接收和发送的能力
为了防止旧的重复连接初始化造成混乱
两次握手连接，就无法阻止历史连接
两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。
在两次握手的情况下，服务端在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据，但是客户端此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，客户端判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而服务端在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接。
如果采用两次握手建立 TCP 连接的场景下，服务端在向客户端发送数据前，并没有阻止掉历史连接，导致服务端建立了一个历史连接，又白白发送了数据，妥妥地浪费了服务端的资源。
三次握手才可以同步双方的初始序列号
TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素
所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，
那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
三次握手才可以避免资源浪费
如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
即两次握手会造成消息滞留情况下，服务端重复接受无用的连接请求 SYN 报文，而造成重复分配资源。
为什么每次建立 TCP 连接时，初始化的序列号都要求不一样呢
为了防止历史报文被下一个相同四元组的连接接收（主要方面）；
（如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同四元组的连接接收的问题。）假设每次建立连接，客户端和服务端的初始化序列号都是从 0 开始：
为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收；
第一次握手丢失了，会发生什么？
如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的
通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。（达到最大重传次数还是失败过后就断开连接
第二次握手丢失了，会发生什么？
第二次握手的 SYN-ACK 报文其实有两个目的 ：
第二次握手里的 ACK， 是对第一次握手的确认报文；
第二次握手里的 SYN，是服务端发起建立 TCP 连接的报文；
第三次握手丢失了，会发生什么（重传 SYN-ACK 报文）
客户端收到服务端的 SYN-ACK 报文后，就会给服务端回一个 ACK 报文，也就是第三次握手
因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文 ，直到收到第三次握手，或者达到最大重传次数
（注意，ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。
相当于ACK丢了，就没有确认报文，相当于不能判定SYN-ACK收到了，就重传SYN-ACK)
TCP 四次挥手过程是怎样的？
为什么挥手需要四次？
客户端向服务端发送FIN，（不能发送了但还能接收数据
服务端回一个ACK，但服务端可能还没干完，干完之后（不再发送数据后），发一个FIN给客户端表示同意关闭连接
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。
特定情况下可以三次挥手
当被动关闭方（上图的服务端）在 TCP 挥手过程中，「没有数据要发送」并且「开启了 TCP 延迟确认机制」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。
什么是 TCP 延迟确认机制？
第一次挥手（第一次的FIN报文）丢失了，会发生什么？
如果第一次挥手丢失了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。
一直等不到就断开连接
第二次挥手（确认的ACK丢失了），会发生什么
当服务端收到客户端的第一次挥手后，就会先回一个 ACK 确认报文
ACK 报文是不会重传的，所以如果服务端的第二次挥手丢失了，客户端就会触发超时重传机制，重传 FIN 报文，直到收到服务端的第二次挥手，或者达到最大的重传次数。
第三次挥手（服务端发给客户端的FIN丢失了），会发生什么
服务端就会重发 FIN 报文，重发次数仍然由 tcp_orphan_retries 参数控制，这与客户端重发 FIN 报文的重传次数控制方式是一样的。
当客户端收到第二次挥手，也就是收到服务端发送的 ACK 报文后，客户端就会处于 FIN_WAIT2 状态
相当于要区分主动关闭方是用close还是shutdown函数
close方案 收到第二次挥手ack 进入wait2 默认等60秒 等fin，没有就关闭连接
而shutdown方案会死等
第四次挥手（客户端发给服务端的ACK丢失了），会发生什么
当客户端收到服务端的第三次挥手的 FIN 报文后，就会回 ACK 报文，也就是第四次挥手，此时客户端连接进入 TIME_WAIT 状态。
第四次挥手的 ACK 报文没有到达服务端，服务端就会重发 FIN 报文 ，重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。
什么是MSL（为什么要2MSL
MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃
TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。