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 状态
三次握手的过程：
- 一开始，客户端和服务端都处于 CLOSED 状态。客户端主动打开连接，服务端被动打卡连接，结束CLOSED z状态，开始监听，进入 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状态，服务端和客户端就可以快乐地通信了。
为什么需要三次握⼿？
总结：
- 三次握⼿才可以阻⽌重复历史连接的初始化(主因)
- 三次握⼿才可以同步双⽅的初始序列号
- 三次握⼿才可以避免资源浪费
解释：
1、阻⽌重复历史连接的初始化（主因）
- 当旧的SYN报⽂先到达服务端，服务端回⼀个ACK+SYN报⽂
- 客户端收到后可以根据⾃⾝的上下⽂，判断这是⼀个历史连接（序列号过期或超
时），那么客户端就会发送 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、避免资源浪费。
- 两次握⼿会造成消息滞留情况下，服务器重复接受⽆⽤的连接请求 SYN 报⽂，⽽造成重复分配资源。
- 只有两次握⼿时，如果客户端的SYN请求连接在⽹络中阻塞，客户端没有收到服务端的ACK报⽂，会重新发送SYN。
- 由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的
ACK 确认信号，所以每收到⼀个 SYN 就只能先主动建⽴⼀个连接
过程
- 客户端发送第⼀个报⽂，携带客户端初始序列号的SYN报⽂。
- 服务器发送第⼆个报⽂，携带服务器初始序列号的ACK + SYN的应答报⽂，
表⽰收到客户端的SYN报⽂。 - 客户端发送第三个报⽂，携带服务器的ACK应答报⽂。
TCP 四次挥手过程
断开过程
- 假设客户端打算关闭连接，发送⼀个TCP⾸部FIN被置1的FIN报⽂给服务端。
- 服务端收到以后，向客户端发送ACK应答报⽂。
- 等待服务端处理完数据后，向客户端发送FIN报⽂。
- 客户端接收到FIN报⽂后回⼀个ACK应答报⽂。
- 服务器收到ACK报⽂后，进⼊close状态，服务器完成连接关闭。
- 客户端在经过 2MSL ⼀段时间后，⾃动进⼊close状态，客户端也完成连接的关闭。
为什么挥⼿需要四次？
关闭连接时，客户端发送FIN报⽂，表⽰其不再发送数据，但还可以接收数据。
客户端收到FIN报⽂，先回⼀个ACK应答报⽂，服务端可能还要数据需要处理和发送，
等到其不再发送数据时，才发送FIN报⽂给客户端表⽰同意关闭连接。
从上⾯过程可知：
-
服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。
-
第⼀次ACK应答报⽂可以省略，因为下⼀个报⽂段携带了ACK信息，ACK是否出现取决于延迟确认特性。
-
延迟确认：即接收⽅收到包后，如果暂时没有内容回复给发送⽅，则延迟⼀段时间再确认，假如在这个时间范围内刚好有数据需要传输，则和确认包⼀起回复。这种也被称为数据捎带。延迟确认只是减轻⽹络负担，未必可以提升⽹络性能，有些情况下反⽽会影响性能。
为什么 TIME_WAIT 等待的时间是 2MSL？
-
MSL是 Maximum Segment Lifetime，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最长时间，超过这个时间报⽂将被丢弃。
-
等待MSL两倍：⽹络中可能存在发送⽅的数据包，当这些发送⽅的数据包被接收⽅处理后又会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。
-
2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。
如果在 TIME-WAIT时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的FIN 报⽂，那么 2MSL 时间将重新计时。
