TCP 三次握手

1、第⼀个SYN报⽂：
客户端随机初始化序列号client_isn，放进TCP⾸部序列号段，
然后把SYN置1。把SYN报⽂发送给服务端，表⽰发起连接，
之后客户端处于SYN-SENT状态。

2、第⼆个报⽂SYN+ACK报⽂：
服务端收到客户端的SYN报⽂，把⾃⼰的序号server_isn放进TCP⾸部序列号段，
确认应答号填⼊client_ins + 1，把SYN+ACK置1。
把SYN+ACK报⽂发送给客户端，然后进⼊SYNRCVD状态。

3、第三个报⽂ACK：
客户端收到服务端报⽂后，还要向服务端回应最后⼀个应答报⽂。

• ⾸先应答报⽂ TCP ⾸部 ACK 标志位置为 1 ，
• 其次「确认应答号」字段填⼊ server_isn + 1 ，
• 最后把报⽂发送给服务端，
  这次报⽂可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
  服务器收到客户端的应答报⽂后，也进⼊ ESTABLISHED 状态

---

---

为什么需要三次握⼿？

总结：

1. 三次握⼿才可以阻⽌重复历史连接的初始化(主因)
2. 三次握⼿才可以同步双⽅的初始序列号
3. 三次握⼿才可以避免资源浪费

解释：
1、阻⽌重复历史连接的初始化（主因）

1. 当旧的SYN报⽂先到达服务端，服务端回⼀个ACK+SYN报⽂
2. 客户端收到后可以根据⾃⾝的上下⽂，判断这是⼀个历史连接（序列号过期或超
   时），那么客户端就会发送 RST 报⽂给服务端，表⽰中⽌这⼀次连接。

两次握⼿在收到服务端的响应后开始发⽣数据，不能判断当前连接是否是历史连接。

三次握⼿可以在客户端准备发送第三次报⽂时，客户端因有⾜够的上下⽂来判断当前连接是否是历史连接。

客户端连续发送多次 SYN（都是同一个四元组）建立连接的报文，在网络拥堵情况下：

• 一个「旧 SYN 报文」比「最新的 SYN」 报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文中的确认号是 91（90+1）。
• 客户端收到后，发现自己期望收到的确认号应该是 100 + 1，而不是 90 + 1，于是就会回 RST 报文。
• 服务端收到 RST 报文后，就会释放连接。
• 后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。

上述中的「旧 SYN 报文」称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。

---

如果是两次握手连接，就无法阻止历史连接，那为什么 TCP 两次握手为什么无法阻止历史连接呢？

我先直接说结论，主要是因为在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。

你想想，在两次握手的情况下，服务端在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据，但是客户端此时还没有进入 ESTABLISHED 状态，

• 假设这次是历史连接，客户端判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，
• 而服务端在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接。

可以看到，如果采用两次握手建立 TCP 连接的场景下，服务端在向客户端发送数据前，并没有阻止掉历史连接，导致服务端建立了一个历史连接，又白白发送了数据，妥妥地浪费了服务端的资源。

因此，要解决这种现象，最好就是在服务端发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

所以，TCP 使用三次握手建立连接的最主要原因是防止「历史连接」初始化了连接。

2、同步双⽅的初始序列号
TCP 协议的通信双⽅， 都必须维护⼀个「序列号」， 序列号是可靠传输的⼀个关键因素。

• 接收端可以去除重复数据。
• 接收端可以按照序列号顺序接收。
• 标识发送的数据包，哪些已经被收到。

这样⼀来⼀回，才能确保双⽅的初始序列号能被可靠的同步

3、避免资源浪费。

1. 两次握⼿会造成消息滞留情况下，服务器重复接受⽆⽤的连接请求 SYN 报⽂，⽽造成重复分配资源。
2. 只有两次握⼿时，如果客户端的SYN请求连接在⽹络中阻塞，客户端没有收到服务端的ACK报⽂，会重新发送SYN。
3. 由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的
   ACK 确认信号，所以每收到⼀个 SYN 就只能先主动建⽴⼀个连接

---

过程

1. 客户端发送第⼀个报⽂，携带客户端初始序列号的SYN报⽂。
2. 服务器发送第⼆个报⽂，携带服务器初始序列号的ACK + SYN的应答报⽂，
   表⽰收到客户端的SYN报⽂。
3. 客户端发送第三个报⽂，携带服务器的ACK应答报⽂。

---

TCP 四次挥手过程

断开过程

1. 假设客户端打算关闭连接，发送⼀个TCP⾸部FIN被置1的FIN报⽂给服务端。
2. 服务端收到以后，向客户端发送ACK应答报⽂。
3. 等待服务端处理完数据后，向客户端发送FIN报⽂。
4. 客户端接收到FIN报⽂后回⼀个ACK应答报⽂。
5. 服务器收到ACK报⽂后，进⼊close状态，服务器完成连接关闭。
6. 客户端在经过 2MSL ⼀段时间后，⾃动进⼊close状态，客户端也完成连接的关闭。

为什么挥⼿需要四次？

关闭连接时，客户端发送FIN报⽂，表⽰其不再发送数据，但还可以接收数据。

客户端收到FIN报⽂，先回⼀个ACK应答报⽂，服务端可能还要数据需要处理和发送，

等到其不再发送数据时，才发送FIN报⽂给客户端表⽰同意关闭连接。

从上⾯过程可知：

1. 服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。

2. 第⼀次ACK应答报⽂可以省略，因为下⼀个报⽂段携带了ACK信息，ACK是否出现取决于延迟确认特性。

3. 延迟确认：即接收⽅收到包后，如果暂时没有内容回复给发送⽅，则延迟⼀段时间再确认，假如在这个时间范围内刚好有数据需要传输，则和确认包⼀起回复。这种也被称为数据捎带。延迟确认只是减轻⽹络负担，未必可以提升⽹络性能，有些情况下反⽽会影响性能。

为什么 TIME_WAIT 等待的时间是 2MSL？

1. MSL是 Maximum Segment Lifetime，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最长时间，超过这个时间报⽂将被丢弃。

2. 等待MSL两倍：⽹络中可能存在发送⽅的数据包，当这些发送⽅的数据包被接收⽅处理后又会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。

3. 2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。
   如果在 TIME-WAIT时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的FIN 报⽂，那么 2MSL 时间将重新计时。