TCP三次握手和Time-Wait状态

第一次握手：建立连接时。client发送

syn

包和一个随机序列号

seq=x

到server，并进入

SYN_SEND

状态，等待server进行确认。

（

syn

，同 步序列编号）。

第二次握手，server收到

syn

包，必须确认客户的

SYN

。然后server发送一个

ACK=1, SYN=1, seq=y

的随机数和

ack=x+1

的确认数的包发送回去。

第三次握手是client收到server端的

SYN+ACK

包，然后向server端发送确认包

ack=y+1, seq=x+1, ACK=1

,client和server端进入

ESTABLISHED

状态，完毕三次握手。详细图演示样例如以下(

ACK

表示首部中的

ACK

位置1。

ack

表示首部中确认序号字段的值)：





这里多说一点，既然提到了连接时的三次握手，就顺便把断开连接时的四次挥手也复习一下。

首先client主动发送

Fin=1，seq=u

。它等于前面已传 送过去的最后一个字节的序号加1.这时

A

进入

FIN-WAIT-1

状态。等待

B

的确认。

B

收到连接后马上发出确认。确认号是

ack=u+1

，而这个报文段 自己的序号是

v

。等于

B

前面已传送过的数据的最后一个字节的序号加1.然后

B

即进入

CLOSE-WAIT

状态。因而

A

到

B

的这个链接如今已经断开了，这时 的

TCP

连接处于半关闭状态。即

A

已经没有数据须要发送了。

但

B

若发送数据，

A

还是要接受的。

A

收到来自

B

的确认之后就进入了

FIN-WAIT-2

状态等 待

B

发出连接释放报文段。

若

B

已经没有要向

A

发送数据。其应用进程就通知

TCP

释放连接。这时

B

发出的连接释放报文段必须使用

FIN=1

.如今假定

B

的序 号为

w

，

B

还必须反复上次已发送过的确认号

ack=u+1

.这时

B

就进入了

LAST-ACK

状态。等待

A

确认。

A

在收到

B

的连接释放之后必须对此发出确 认。在确认号中把

ACK

置1。确认号

ack=w+1

,而自己的序号是

seq=u+1

。接着

A

进入

TIME-WAIT

状态。为了保证

B

能够收到确认释放报文段。

例如以下图：



是不是全部运行主动关闭的

socket

都会进入

TIME_WAIT

状态呢？

有没有什么情况使主动关闭的

socket

直接进入

CLOSED

状态呢？

主动关闭的一方在发送最后一个

ack

后

就会进入

TIME_WAIT

状态 停留

2MSL

（

max segment lifetime

）时间

这个是

TCP/IP

不可缺少的，也就是“解决”不了的。也就是

TCP/IP

设计者本来是这么设计的

主要有两个原因:

防止上一次连接中的包，迷路后又一次出现，影响新连接

（经过

2MSL

，上一次连接中全部的反复包都会消失）

可靠的关闭

TCP

连接

在主动关闭方发送的最后一个

ack(fin)

，有可能丢失。这时被动方会又一次发

fin

, 假设这时主动方处于

CLOSED

状态 ，就会响应

rst

而不是

ack

。所以

主动方要处于

TIME_WAIT

状态，而不能是

CLOSED

。