计算机网络

服务端

紧急指针

ACK = 1

首部长

总的来说三次握手1，客服端和服务端都可以知道对方已经做好了接受和发送数据的准备。2，TCP连接是面向连接的并且数据是有序的，三次握手可以同步序列号。3，防止服务端受到SYN洪范攻击。（很多机器发送半连接服务端为这些连接分配空间导致资源浪费）

客服端发起释放连接请求表示客服端没有数据要发送了，服务端收到请求后发送确认报文，此时客服端仍然可以接收来自服务端的数据，服务端发送完数据后，也发出释放连接请求，客服端收到后发送确认报文。

数据

FIN = 1

客服端与服务端建立连接时，会进行三次握手，客服端与服务端释放连接时会进行四次挥手。

丢失/拥塞

选项

TCP报文

当我们客服端发送的报文由于网络拥塞很久才到服务端，客服端迟迟没有收到确认报文，会再次发送连接报文，此时服务端会先后收到两个报文，此时服务端会抛弃掉一个报文（多个报文情况也是一样的），也会发送确认报文。

15

以上是正常情况下我们客服端无服务端建立连接的过程，但是我们知道网络是未知的可能发生报文的丢失或者遇到网络拥塞导致报文迟迟才到，我们来分析这些情况

我们客服端一旦接收到服务端发来的确认报文就会再次发送确认报文，并且准备号发送接受和发送数据，由于客服端发送的确认报文会因为延迟或者丢失迟迟未到服务端，在次过程中服务端会再次发送确认报文，而客服端收到重复的确认报文，也会重新发送确认报文，直到不在收到服务端的确认报文。最后服务端接收到客服端的确认报文就会准备与客服端通信。

客服端

丢失

窗口大小

当我们客服端发送的连接报文丢失时，我们客服端发现迟迟没有收到服务端的报文便会再次发送连接报文。

保留位

释放连接过程（四次挥手）

31

由于服务端发送的确认报文也可能发生丢失或者很久才到的情况。发生丢失或拥塞时我们客服端就会再次发送相同的连接请求，因为客服端会认为服务端没有接受到连接报文，而服务端会自动忽略掉多余的相同的连接报文，并且每隔一段时间发送报文，直到服务端再次收到客服端的确认报文。

建立连接过程（三次握手）

检验和

TIME_WAIT

确认号

计算机网络

由于网络的未知性，我们TCP建立连接的过程是复杂的，可能会重复发送或接受到多次相同的报文。那么我们为什么一定要进行3次握手呢？两次可以吗？假设我们只有两次握手，当我们的客服端发送了连接报文，并且服务端接受到该报文后就会发送确认报文，确认报文发送完以后服务端就准备好发送数据了，此时由于我们客服端可能并没有接受到确认报文，所以没有来得及准备好服务端发送过来的数据，从而引发错误。而我们再加上一个第三次连接，就可以保证客服端在接收到服务端确认报文后准备好可以接收服务端数据并再次发送确认报文，服务端收到确认报文后就知道客服端已经准备接受数据了，就可以发送数据了data。（我们连接报文和确认报文都不包含数据段的）

序列号

目的端口

首先我们客服端发出连接请求发送SYN报文，此时我们的ACK标记是0，我们随机算产生一个序列号seq = x，等待服务端的回应，服务端接受到SYN报文，发送确认报文，此时ACK=1，并将确认号ack设置为x+1，随机产生一个序列号y，客服端收到确认报文，也发送确认报文，最终连接建立

TCP 三次握手四次挥手

0

源端口

U A P R S FR C S S Y I G K H T NN 

1，为什么我们要四次挥手？      因为当我们一方已经没有数据需要发送时，另外一        方可能还有数据没有发完，只要双方都没有数据需        要发送时我们才能关闭连接。2，如上我们客服端接受到释放连接报文并发送确认报      文后为什么还要等待一个2MSL（如TIME_WAIT）?    。由于网络原因我们客服端最后发送的ACK报文能           丢失所以我们不能早早的就关闭连接，因为服务端         后面可能还会发送FIN报文          。防止服务端在没有接收到客服端ACK报文情况              下，本机相同端口再次与服务端建立连接，从而         引发错误