图片描述
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~

链接:https://www.imooc.com/article/details/id/20812
来源:慕课网