1、TCP三次握手状态及消息类型
三次握手：服务端先从close到listen。
①第一个SYN报文：客户端到服务端。
客户端随机初始化序列号client_isn，放进TCP首部序列号段，然后把SYN置1。把SYN报文发送给服务端，表示发起连接，之后客户端处于SYN-SENT状态。
②第二个报文SYN+ACK报文：服务端到客户端。
服务端收到客户端的SYN报文，把自己的序号server_isn放进TCP首部序列号段，确认应答号填入client_ins + 1，把SYN+ACK置1。把SYN+ACK报文发送给客户端，然后进入SYN-RCVD状态。
③第三个报文ACK：
客户端收到服务端报文后，还要向服务端回应最后一个应答报文。首先该应答报文 TCP 首部 ACK 标志位置为 1，其次确认应答号字段填入server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
2、为什么需要三次握手？
-
三次握手才可以阻止重复历史连接的初始化(主因)；
-
三次握手才可以同步双方的初始序列号
-
三次握手才可以避免资源浪费
①阻止重复历史连接的初始化。（主因）
- 当旧的SYN报文先到达服务端，服务端回一个ACK+SYN报文，
- 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST报文给服务端，表示中止这一次连接。
两次握手在收到服务端的响应后开始发生数据，不能判断当前连接是否是历史连接。
三次握手可以在客户端准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接。
②同步双方的初始序列号。
TCP 协议的通信双方， 都必须维护一个序列号， 序列号是可靠传输的一个关键因素。
- 接收端可以去除重复数据。
- 接收端可以按照序列号顺序接收。
- 标识发送的数据包，哪些已经被收到。
- 客户端发送第一个报文，携带客户端初始序列号的SYN报文，
- 服务器发送第二个报文，携带服务器初始序列号的ACK + SYN的应答报文，表示收到客户端的SYN报文。
- 客户端发送第三个报文，携带服务器的ACK应答报文。
这样一来一回，才能确保双方的初始序列号能被可靠的同步。
两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
③避免资源浪费。
两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求SYN报文，而造成重复分配资源。
只有两次握手时，如果客户端的SYN请求连接在网络中阻塞，客户端没有收到服务端的ACK报文，会重新发送SYN。由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接
另外：TCP是没有“请求”一说的，TCP是一种通信的方式，“请求”一词是事务上的概念，HTTP协议是一种事务协议，如果说发送一个HTTP请求，这种说法就没有问题。应该是发送SYN报文，接收ACK+SYN报文。
3、TCP 三次握手的第三个ACK丢了会怎样
如果此时 ACK 在网络中丢失，那么 Server 端该TCP连接的状态为 SYN_RECV，并且依次等待 3 秒、6 秒、12 秒后重新发送 SYN+ACK包，以便 Client重新发送 ACK包，如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。
客户端认为连接建立，服务端处于SYN_RCVD或CLOSE状态。
服务端处于CLOSE：
- 服务器认为连接超时，后续服务器收到这个 client 的包，认为连接已经关闭，返回RST。客户端收到后关闭连接。
- 客户端会超时重传这个ACK 吗？不会！TCP 不会为没有数据的ACK超时重传。
服务端处于 SYN_RCVD：
- 双方都没数据发送，服务端进行重传，收到客户端 ACK 确认， 连接进入 Established 状态。
- 客户端发送数据，服务端收到DATA+ACK，切换到 Established， 接收数据。
- 服务端想发送数据，发送不了，会进行重传，收到 ACK 确认才可以发。