http你不得不知道的那些事（八）--TCP三次握手

前两天连续有两个朋友问我关于tcp三次握手详情了，起初我就让他们在网上搜，因为网上这种东西都太多了，重复造轮子的事我可不太想做。不过他们给我的答复是已经在上网搜了，不过都说得不清不楚，最重要的是细节不清楚。我不太相信，就去看了下百度百科，果然细节讲得含糊其辞。我给他们回复了两遍，觉得不能再重复造轮子了，所以写了这篇文章，详细的分析下tcp的三次握手。

通过阅读上图，我想这个过程已经很清晰了。那这几个缩写是什么意思呢？

SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。

ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

seq： (sequence number) 顺序号码

ack: (acknowledge number) 确认号码

首先由Client发出请求连接即 SYN=1 ACK=0 (请看头字段的介绍), TCP规定SYN=1时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=x
然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y, ack=x+1,
再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1, seq=x+1, ack=y+1.然后连接建立。

有人会困惑为什么要进行三次握手呢（两次确认）？这主要是为了防止已失效的请求连接报文忽然又传送到了，从而产生错误。如何产生这种情况的呢？假定A向B发送一个连接请求，由于一些原因，导致A发出的连接请求在一个网络节点逗留了比较多的时间。此时A会将此连接请求作为无效处理又重新向B发起了一次新的连接请求，B正常收到此连接请求后建立了连接，数据传输完成后释放了连接。如果此时A发出的第一次请求又到达了B，B会以为A又发起了一次连接请求，如果是两次握手此时连接就建立了，B会一直等待A发送数据，从而白白浪费B的资源。三次握手的话，由于A没有发起连接请求，也就不会理会B的连接响应，B没有收到A的确认连接，就会关闭掉本次连接。

可能还有人困惑大写ACK和小写ack是有什么区别，为什么两个值还不一样。大写ACK是一种TCP协议规定的标识，小写ack是 acknowledge number 为确认号码，值是seq + 1。

以上就是三次握手详情。thx~