三次握手协议

我们常见的三次握手协议大概是TCP通过三次握手建立连接的，但是在BLE的LL层连接管理的启动加密过程也是存在三次握手的过程，以前大概学习过TCP的三次连接，但是理解似乎只在于其实现，而没有思考其中的原理，今天看到一篇文章用军事上的电报的例子很好的说明了其原理和利弊，拾人牙慧。

三次握手保证了什么？

我们来看两个人通过传唤机进行通信的过程：

** 第一次握手：**
“ 二号二号，我是一号，收到请回答。”

二号收到之后，二号可以确定的是自己的接收器和一号的发射器是好的。但是一号什么都不能确认，他不知道自己是否发射成功，也不知道对方是否能够收到。

** 第二次握手：**
“ 一号一号，我是二号，收到。”

一号收到后，一号可以确定自己的接收器和二号的发射器是好的。但是2号什么也不能确定，既不知道自己的信号是否能发出去，也不知道对方的接收装置是否是好的。
** 第三次握手：**
“ 二号二号，收到你的回答，请准备收报。”

第三次握手，到二号收到之后，才能确认自己的发射器和一号的接收器是好的。

经过三次握手之后，彼此双方确认自己和对方的接收装置和通信环境是完好的。

三次握手不能保证什么？

三次握手协议只能保证握手的时候装置和通信环境是没有问题的，但是并不能保证之后的状态也是完好的。

因为无线环境的复杂性和特殊性，我们只能通过各种协议的校验来保证无线过程的完整。

TCP/IP

对于TCP/IP协议建立连接的过程没有什么不同，就是经过完成三次确认确保双方的通信链路是通的。

简单过程如下：

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

参考
http://blog.sina.com.cn/s/blog_624f70600100he7u.html