TCP三次握手学习心得

客户端A若要连接服务端B，首先A会向B发送一个连接请求，其中SYN=1，ACK=0，B为了告诉A成功收到了消息，则向A发送一个确认包，其中SYN=1,ACK=1,这时A收到之后又会向B发送一个确认收到确认包的确认包，SYN=0,ACK=1。最后B收到这个包之后，A和B的连接就成功建立。

首先解释SYN和ACK分别是什么，SYN是同步标志位，ACK是确认标志位，SYN的作用是告诉对方自己数据的起始***是多少，ACK是告诉对方自己已收到对方发来的数据包，希望对方传来的下一个数据包是第几个字节。也就是说三次握手的1，2次握手是向对方同步自己的***而2，3次握手是向对方确认自己已经收到了对方发来的数据包。

这时候就会有人有疑问，为什么不是两次握手或四次握手呢？
先来说两次握手，A向B发送请求连接信号，B向A发送一个收到信号，同意连接的信号，这样两次握手不就可以了吗。其实不然，假如A发送请求后，这时A进入等待状态，B收到了信号再向A发送确认信号，B就已经进入了连接状态，但是万一B发送的信号中途丢包了呢，这样A就会一直处于等待状态，但是B却认为连接已经建立。

换一种想法，其实三次握手的第一次握手是A告诉B自己有发的能力，第二次握手B告诉了A自己有收和发的能力，第三次握手A告诉B自己有收的能力。这样也说明了为什么不是四次握手，三次握手都已经把该说的都说了，该知道的都知道了，四次岂不是就很浪费了。

有人认为四次握手应该是：第一次A向B发送同步序列信号，第二次B向A发送确认信号，第三次B向A发送同步序列信号，第四次A向B发送确认信号。明显第二次和第三次的可以合成一次发送。
其实三次握手协议也不是一定可靠的，但是可以说是最合适最可靠的。

就拿两军交流为例，A军和B军中间隔了一座大山，A想告诉B军一个作战计划，这时A就会派一个传令兵赶到B军所在地告诉他们作战计划，B一听：诶，这个计划不错哟，我要告诉A我同意这个计划了，于是B也派这个传令兵回去A的兵营告诉A，A知道B同意这个计划后就想让B知道自己已经了解到他们同意了，于是又派这个传令兵千里迢迢赶到B的所在地，但是A不知道这个传令兵究竟有没有成功告知B，于是B就只能再派这个传令兵到A的兵营。。。。就这样陷入了死循环，传令兵累死了。。。

所以如果真要保证连接正确无误，就需要像这样无限次的握手。