TCP三次握手和四次挥手

        TCP是一种面向链接的、可靠的、基于字节流的传输层通讯协议，在发送数据前，通讯双方必须在彼此间创建一条链接。所谓的“链接”，实际上是客户端和服务端保存的一份关于对方的信息，如ip地址、端口号等。

        一个TCP链接一般分为三个阶段：链接、数据传输、退出（关闭）。经过三次握手创建一个连接，经过四次挥手来关闭一个链接。

1.TCP报文的头部结构

在了解TCP链接以前先来了解一下TCP报文的头部结构。

1.1 端口号（16位）

        源端口号标示这段报文来自哪里；目的端口号标示这段报文要发往哪里。进行tcp通讯时，通常客户端是经过系统自动选择的临时端口号，而服务器通常是使用指定的端口号。

1.2 序列号seq（32位）

        由于TCP使用IP来传输报文段，而IP不能过滤掉重复的报文，也不能保证报文的顺序。好比客户端给服务端发送一条5kb的数据，若是tcp一次只能发1kb，那就要将数据分红5段分5次来发，将这5段数据分别编号为一、二、三、四、5，发送的时候按照这个顺序进行发送，服务端收到的顺序可能就是13254，也就是说服务端收到的顺序和发送的顺序多是不一致的，甚至由于某些因素(好比客户端没收到服务端回复的ACK数据包就会重发数据)致使服务端收到多个编号相同的数据。

        那这样的话服务端收到所有数据后要如何将它们拼接成正确的数据呢？这里就用到了序列号。首先序列号被系统初始化为一个随机值ISN，一个报文的序列号就是ISN+这个报文携带的数据的第一个字节的偏移量。好比上面所说的例子要发5个报文，第一个报文的第一个字节的偏移量为0，序列号就是ISA+0；因为第一个报文携带的数据大小是1kb(1024)，因此第二个报文的第一个字节的偏移量就是1024，序列号就是ISA+1024，以此类推。（注意实际上三次握手时是会占据一个序列号的，因此实际上正式发送数据时第一个报文的序列号是ISA+1+0，这里为了方便理解就不考虑三次握手时占据的那个序列号）。

1.3 确认号ack（32位）

        仍是用前面的例子，服务端收到客户端发过来的报文后须要给客户端回复一个ack数据包，回复报文的确认号的值等于服务端收到的报文的序列号的值+1，好比服务端当前收到的报文的序列号是ISN+2048(也就是第3段数据)，那么它回复客户端的报文的确认号的值就是ISN+2048+1，其做用就是告诉客户端ISN+2048+1以前的全部数据都已经收到了。

        关于ack回复有几点须要说明(下面客户端为发送端，服务端为接收端)：

a.客户端发送一个报文后并不须要等服务端的ack回复就能够接着发下一条报文。

b.服务端回复ack时，必需要确保确认号以前的数据所有已经收到了，好比上面的例子，若是序列号是ISN+2048的报文收到了，可是ISN+1024的报文还没收到，那就不能回复ISN+2048+1的ack。

c.服务端在收到数据后不是当即给客户端发送ack的，通常会有200ms的延迟(系统有个定时器每隔200ms来检查是否须要发送ack包)。这么作是由于TCP数据包到达的顺序是不保证的，就好比上面必需要等ISN+1024的数据收到了才能回复ISN+2048+1的ack，这个时候就只用回复ISN+2048+1这一个ack就能够了，不须要回复ISN+1024+1的ack了，由于回复ISN+2048+1的ack就已经告诉客户端ISN+2048+1以前的数据已经所有收到了，这样作还能够减小网络流量。固然若是ISN+1024的数据丢包致使服务端一直没收到，那客户端也就一直收不到ack回复，客户端就会从上次收到的ack回复开始重发数据，包括服务端已经收到的ISN+2048数据也会重发。另外若是服务端恰好也有数据要发给客户端，那么就会在发送数据的TCP数据包里带上ack信息。

1.4 头部长度（4位）

头部长度是以32bit(4字节)为一个单位，头部长度的值表示TCP头部总共多少个32bit，4位的最大是二进制1111(十进制15)，TCP头部最大为15*32/8个字节，也就是60字节。TCP头部前面20个字节是固定的，TCP头部最小也就是20个字节。

1.5 六个标志位（每一个标志占1位，每一个标志只有0和1两种状态）

URG：为1时表示紧急指针有效。

ACK：为1时表示确认号是有效的，携带ACK标志的报文段也称确认报文段。

PSH：为1时是提示接收端应用程序应该当即从TCP接受缓冲区中读走数据，为后续接收的数据让出空间。

RST：为1时表示通知对方关闭链接或从新创建链接。带RST标志的TCP报文段也叫复位报文段。不少异常状况都会致使没法创建TCP链接或者TCP链接异常终止，好比客户端请求中使用了一个不存在的端口，那服务端就能够发送RST报文段拒绝这个请求；再好比TCP链接好久没有传输数据了，能够发送RST报文段来终止这个链接；还好比TCP链接出现了一次，而后服务端但愿终止这条异常的连接，能够发送RST报文段来终止这个链接。注意一旦发送了复位报文段，发送端全部排队等待发送的数据都将被丢弃，并且发送完RST报文后TCP链接就关闭了，因此接收端收到RST报文后也就没有必要发送ACK包来确认了。

SYN：为1表示创建一个链接，携带SYN标志的报文段为同步报文段。SYN标志位只有在TCP创建链接时(也就是三次握手的时候)才会被置为1，客户端请求创建链接时(第一次握手)的报文就携带SYN标志和初始化的序列号(也就是起始序列号)，SYN标志是提醒服务端记住客户端的起始序列号。而后服务端也会初始化本身的起始序列号并回复客户端一条报文(第二次握手)，这条报文包含服务端的起始序列号、SYN标志位和ACK标志位，其中SYN标志位用来提醒客户端记住服务端的起始序列号。

FIN：为1时用来告知对方本端要关闭链接了。

1.6 窗口大小（16位）

窗口大小能够理解为本身接收数据的缓存区大小，用来告诉对方本身最大还能接收多少数据，若是对方发送的数据超过了窗口大小，那这个数据会被丢弃。当窗口大小为0时对方会暂停发送数据，直到窗口大小大于0时才会恢复发送数据。

1.7 校验和（16位）

发送端对TCP报文(包括TCP头部和数据部分)执行CRC算法获得校验和，接收端收到报文后对报文执行一样的算法，将结果与校验和进行比对，二者一致说明TCP报文段在传输过程当中没有损坏，若是不一致那么这段TCP报文段会被直接丢弃。

1.8 紧急指针（16位）

只有当URG标志位为1时紧急指针才是有意义的，紧急指针指向紧急数据最后一个字节的下一位。准确来讲紧急指针的值实际上是一个相对于序列号的偏移量，好比说紧急指针的值是5，若是这个报文段的序列号seq=10，那就表示紧急指针指向的是15这个位置的字节，这就意味着10到14这段数据是紧急数据。紧急数据是不进入缓存区的。（注：关于紧急指针的指向和紧急数据的长度网上有不一样的说法，我这里也不能肯定哪一种是正确的）。

1.9 TCP头部选项

TCP头部选项时长度可变的可选信息，最多包含40个字节。典型的TCP头部选项包含kind、length和info三个部分，kind表示选项的类型，length表示选项的长度，info表示选项的具体内容。

2. 三次握手

• 第一次握手：客户端要向服务端发起链接请求，首先客户端随机生成一个起始序列号ISN(好比是100)，那客户端向服务端发送的报文段包含SYN标志位(也就是SYN=1)，序列号seq=100。

• 第二次握手：服务端收到客户端发过来的报文后，发现SYN=1，知道这是一个链接请求，因而将客户端的起始序列号100存起来，而且随机生成一个服务端的起始序列号(好比是300)。而后给客户端回复一段报文，回复报文包含SYN和ACK标志(也就是SYN=1,ACK=1)、序列号seq=300、确认号ack=101(客户端发过来的序列号+1)。

• 第三次握手：客户端收到服务端的回复后发现ACK=1而且ack=101,因而知道服务端已经收到了序列号为100的那段报文；同时发现SYN=1，知道了服务端赞成了此次链接，因而就将服务端的序列号300给存下来。而后客户端再回复一段报文给服务端，报文包含ACK标志位(ACK=1)、ack=301(服务端序列号+1)、seq=101(第一次握手时发送报文是占据一个序列号的，因此此次seq就从101开始，须要注意的是不携带数据的ACK报文是不占据序列号的，因此后面第一次正式发送数据时seq仍是101)。当服务端收到报文后发现ACK=1而且ack=301，就知道客户端收到序列号为300的报文了，就这样客户端和服务端经过TCP创建了链接。

3. 四次挥手

好比客户端初始化的序列号ISA=100，服务端初始化的序列号ISA=300。TCP链接成功后客户端总共发送了1000个字节的数据，服务端在客户端发FIN报文前总共回复了2000个字节的数据。

• 第一次挥手：当客户端的数据都传输完成后，客户端向服务端发出链接释放报文(固然数据没发完时也能够发送链接释放报文并中止发送数据)，释放链接报文包含FIN标志位(FIN=1)、序列号seq=1101(100+1+1000，其中的1是创建链接时占的一个序列号)。须要注意的是客户端发出FIN报文段后只是不能发数据了，可是还能够正常收数据；另外FIN报文段即便不携带数据也要占据一个序列号。
• 第二次挥手：服务端收到客户端发的FIN报文后给客户端回复确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=1102(客户端FIN报文序列号1101+1)、序列号seq=2300(300+2000)。此时服务端处于关闭等待状态，而不是立马给客户端发FIN报文，这个状态还要持续一段时间，由于服务端可能还有数据没发完。
• 第三次挥手：服务端将最后数据(好比50个字节)发送完毕后就向客户端发出链接释放报文，报文包含FIN和ACK标志位(FIN=1,ACK=1)、确认号和第二次挥手同样ack=110二、序列号seq=2350(2300+50)。
• 第四次挥手：客户端收到服务端发的FIN报文后，向服务端发出确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=235一、序列号seq=1102。注意客户端发出确认报文后不是立马释放TCP链接，而是要通过2MSL(最长报文段寿命的2倍时长)后才释放TCP链接。而服务端一旦收到客户端发出的确认报文就会立马释放TCP链接，因此服务端结束TCP链接的时间要比客户端早一些。

4. 常见面试题

4.1 为何TCP链接的时候是3次？2次不能够吗？

由于须要考虑链接时丢包的问题，若是只握手2次，第二次握手时若是服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(能够理解服务端已经链接成功)据，而客户端一直没收到服务端的确认报文，因此客户端就不知道服务端是否已经准备好了(能够理解为客户端未链接成功)，这种状况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。

若是是三次握手，即使发生丢包也不会有问题，好比若是第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会从新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

4.2 为何TCP链接的时候是3次，关闭的时候倒是4次？

由于只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(因此不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

4.3 为何客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP链接？

这里一样是要考虑丢包的问题，若是第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，因此须要等这么长时间来确认服务端确实已经收到了。

4.4 若是已经创建了链接，可是客户端忽然出现故障了怎么办？

TCP设有一个保活计时器，客户端若是出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会从新复位这个计时器，时间一般是设置为2小时，若两小时尚未收到客户端的任何数据，服务器就会发送一个探测报文段，之后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭链接。