三次握手和四次挥手

序列号seq：首次建立连接时，随机取。

确认号ack：上一个seq + 1

ACK：置1时，为有效报文。

SYN：置1，代表请求建立连接的报文

FIN：置1，代表请求断开连接的报文

 

一、三次握手

 

 

①client端发送请求，请求建立连接。此时SYN置1，并产成一个随机的seq=100

②server收到一个SYN为1的请求，知道是有人请求建立连接。然后将自己的SYN，ACK置1。序列号ack=seq+1=101，并产生随机的seq=200

　　此时，client端已经发出一个SYN=1的请求，并且收到一个SYN=1的请求。那么对于client而言，已经建立链接了。但是对于server端，并不知道是否已经建立连接，因此需要第三次握手。

③client发送②server请求的应答。这时不需要SYN置1（因为对于client，链接已经建立），ACK置1，ack=seq+1=201（代表确认号为200的请求的应答），seq=②的ack=101。server收到seq为101的报文，他就知道和client的连接已经建立

　

只采用两次握手的话，如果已失效的连接请求报文段又传到了服务器端。client 发出的第一个连接请求报文段在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。server发送SYN=1的请求会一直等待应答，直到超时自动释放连接

 

二、四次挥手

①client向server发送FIN=1的断开链接请求。seq随机取=200。

②server收到client的FIN=1的断开请求，ack=seq+1=2001，seq随机取=3000。此时，client不再向server发送数据，但是仍然可以接收到server发来的数据

③server再次向client发送FIN=1的断开请求，ack=上一个ack=2001，seq随机取=5000

　　②和③不能合并到一起变成三次挥手，再server收到client的断开请求时，server可能还在接收数据。因此，要先发送一个应答，告诉client你可以不用发了。等到收完数据后可以发送FIN=1的断开请求

④client收到断开请求后，做出应答。ack=seq+1=5001，seq=ack。server收到后立即释放连接。client在发送应答后的2个最大生存时间后释放

　　client发出的应答可能会丢失，因此要等待2MSL。如果丢失，server会重发③。如果client在2MSL内没收到重发的请求，则认为可以释放连接