TCP的三次握手。
第一次握手：建立连接时，客户端 发送 syn 包（syn=j）到 服务器，并进入 SYN_SENT 状态，等待服务器确认；
syn：同步序列号（Synchronize Sequence Numbers）
第二次握手：服务器 收到 客户端 发送的 syn 包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（seq=k），即 SYN+ACK包，此时服务器进入 SYN_RECV 状态；
seq: (sequence)
ack: 确认
先说下为什么加1？
假设 a 邮了一个快递给 b，快递员是 c。
a 想知道 b 是否可以接收快递，然后 b 就把快递又邮回去了。
但是 b 没有做标记的话，a 无法知道 b 是否收到了包裹。
所以 b 加了一个1，表示自己签收到了。
然后为什么又发了一个序列号？(seq)
因为 b 也需要知道 a 是否可以接收包裹。
第三次握手：客户端 收到 服务器 的 SYN+ACK 包，向 服务器 发送确认包 ACK(ack=k+1），此包发送完毕，客户端和服务器进入 ESTABLISHED（TCP连接成功）状态，完成三次握手。
established: 建立成功了
*******************************************************************************************************************************
ok, 接下来说为啥需要三次，而不是两次！
那么我们必须明白一个事情，握手是为了解决什么问题？
握手要解决的问题其实是：希望服务器端只开一个连接给客户端使用。两次握手不是一定不成功
假设 a 要把自己的孩子送到 b 家里待几天。
a 要通过给 b 送快递的方式来确定 b 在不在家，c 是快递员。
a 的快递送给 b 的时候，c 把包送到了 b ，b 成功签收，并发包告诉 a 我在家！
假设 b 的快递送给 a 的时候，c 把包丢了。
那么问题就在这里，假设只有两次握手
a 的快递送给 b, b 收到后，要传给 a。
但是，b 的快递给 a 的时候呢， 快递员 c 把包弄丢了。
此时，a 没有收到包的情况下，会以为包没有发给 b。(因为是两次握手，此时的 b 只是假设了 a 收到了包)
但是 b 呢？ b 已经准备好 a 送孩子过来，就会打开一个门等 a 发送孩子过来。
此时的 a 会以为 b 没在家，重新发一个包查看 b 是否现在在家。（a如果收到包，那么两次握手也可以成功建立连接）
那么 b 收到之后是不是又会开一个门？是否就造成了这种资源浪费！！！
如果这次 a 还是没收到呢？ b 就会一直开很多门！
握手 3 次 就是为了解决以上问题的。
OK， 那么接下来说3次握手之后会有其他问题吗？
如果握手成功，接下来把孩子送过去就Ok了。
是不是有人还想问 孩子送到半路出了问题怎么办！
假设孩子半路又被 快递员 弄丢了..
那么，又有什么问题呢？a 知道 b 在家, 就算是失败了，a 至少不用发快递问 b 在不在家了。<== 握手主要是解决这个问题
所以它只需要再发一个孩子过去，直到孩子发过去为止。
总结：3次握手是为了减少因网络或其他原因造成不必要的资源浪费（a没有收到b的包的情况下）
好，还有一个问题， 大家问我 一次 握手不就不会有问题吗？
我擦， b 不存在呢？ 你一直发孩子，客户端是不是就资源浪费了？
自己捋一捋吧！