计算机网络三次握手，四次挥手流程
首部内容说明：重要的内容加粗
（1）序号：Seq 序号，占 32 位，用来标识从 TCP 源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：Ack 序号，占 32 位，只有 ACK 标志位为 1 时，确认序号字段才有效，Ack=Seq+1。
（3）标志位：共 6 个，即 URG、ACK、PSH、RST、SYN、FIN 等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。
注意：
（A）不要将确认序号 Ack（代表确认号序号下面那个内容，图一中的 201 和 501）与标志位中的 ACK 搞混了。
（B）确认方 Ack = 发起方 Req+1，两端配对。
假设A为客户端，B为服务器端。
(1) 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求，处于LISTEN状态
(2) A 向 B 发送连接请求报文，
- SYN=1(连接请求同步位，表示连接请求报文)
- ACK=0（确认位，ACK=1时确认号生效）
- sqe=x（A随机选择初始的序号 x） 然后客户端处于SYN-SENT状态
(3) B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，
- SYN=1
- ACK=1
- ack=x+1（确认号为 x+1（x+1以前的数据都接受到了））
- sqe=y同时随机选择初始的序号
然后服务端处于SYN-RCVD状态
(4) A 收到 B 的连接确认报文后，
- ACK=1
- ack= y+1，向 B 发出确认
- seq= x+1（序号）
- 然后客户端处于ESTABLISHED状态（没有SYN=1）
(5) B 收到 A 的确认后，连接建立
(6+) 三次握手的时候可能还会交换窗口大小和缓存大小
TCP 四次挥手过程
TCP 四次挥手流程图
A--->B（1）FIN = 1,sqe =u
B--->A（2）ACK = 1,sqe =v
B--->A（3）FIN = 1,ACK =1,sqe =w,ack =u+1
A--->B（4）ACK = 1,sqe =u+1,ack =w+1
流程解析：
1）假设 Client 端发起中断请求，也就是发送 FIN 报文。Server 端接到 FIN 报文后，意思是说 “我 client 端要发给你了”，但是如果你还没有数据要发送完成，则不必急着关闭 Socket，可以继续发送数据。所以所以你先发送 ACK，"告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候 Client 端就进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。
2）当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文，"告诉 Client 端，好了，我这边数据发完了，准备好关闭连接了"。
3）Client 端收到 FIN 报文后，" 就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。
4）Server 端收到 ACK 后，"就知道可以断开连接了"。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，我 Client 端也可以关闭连接了。Ok，TCP 连接就这样关闭了！
为什么要三次握手四次挥手？
首先网络通信必须需要两次握手
-
那么第三次握手的作用是什么呢？
- 防止：已经失效的连接请求报文传送到对方，引起错误
- 主要防止资源的浪费。
-
第三次挥手的作用是什么？
- 第三次挥手主要是服务器端向客户端发送确认关闭报文FIN=1，在这之前还可以保证数据继续传送，Client 端收到 FIN 报文后，" 就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。
-
第四次挥手的作用是什么？
- 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
DDOS攻击在哪一阶段
一般发生在请求连接的第一个握手包（SYN包）阶段：
- 什么是SYN洪范泛攻击？
-
- SYN Flood利用TCP协议缺陷，发送大量伪造的TCP连接请求，常用假冒的IP或IP号段发来海量的请求连接的第一个握手包（SYN包） ，被攻击服务器回应第二个握手包（SYN+ACK包），因为对方是假冒IP，对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN_RECV状态的“半连接” ，并且会重试默认5次回应第二个握手包，大量随机的恶意syn占满了未完成连接队列，导致正常合法的syn排不上队列，让正常的业务请求连接不进来。【服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击】
- 检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击【在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击】
- 怎么解决？
- 缩短超时（SYN Timeout）时间
- 增加最大半连接数
- 过滤网关防护 * SYN cookies技术：
- 当服务器接受到 SYN报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id，目的 Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并把 cookie 作为序列号响应给客户端。
- 如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id，目的 Id，端口号以及秘密函数计算出一个结果，如果结果的值 + 1 等于确认字段的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源
