TCP三次握手，四次挥手

序号：seq(sequence number) TCP包文太大在网络传输中要分段，接收时再按照序号重组
确认号：ack(acknowledge number) 服务器收到请求后的回复，存在于确认消息里，ack=上一个包的序号+1，用来表示服务器期望收到你下一个序号为ack的数据包。

状态控制码 打上标记可以理解为置位1，未打标记置位0
ACK：acknowledge：确认位=1，表示这个消息是一个确认消息
RST：RESET：重置=1，表示这个消息释放连接。TCP连接出现错位，通信要重新建立连接
SYN：synchronous：同步=1，要么是客户端发送1个连接的消息，要么是服务器端确认接受连接消息
FIN：FINAL：终止=1，表示发送报文结束，释放这个链接。接下来进行四次挥手。

TCP的三次握手过程
C-S：发送SYN=1，seq=x
C端关闭━主动打开，S端关闭━被动打开
S-C:发送ACK=1，SYN=1，ack=x+1,seq=y
S端处于监听状态，C端处于同步已发送状态
C-S:发送ACK=1，ack=y+1，seq=x+1
C端建立连接，S端建立连接

TCP的四次挥手
C-S：FIN=1，seq=x
C建立连接状态━终止等待1，S端建立连接到━关闭等待
S-C：ACK=1，ack=x+1，seq=v
S关闭等待持续，C终止等待1━终止等待2
S-C：ACK=1，FIN=1，seq=y，ack=x+1
C端终止等待━时间等待，S最后确认
C-S：ACK=1，ack=y+1,seq=x+1
C端时间等待持续一会后关闭，S端关闭

两种协议对比：

常见问题：
【1】创建连接，为什么TCP客户端最后还要发送一次确认呢？
保证数据保真有序（双向）
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果采用的是三次握手，就算是那一次失效的报文过了很久传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

【2】三次握手过程中可以携带数据吗？
第一次、第二次握手不可以携带数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

【3】SYN攻击是什么？
SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

【4】为什么客户端最后还要等待2MSL？
MSL（Maximum Segment Lifetime）可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。TCP允许不同的实现可以设置不同的MSL值。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

【5】为什么建立连接是三次握手，关闭连接确是四次挥手呢？
断开连接时，可能有没有传输完的数据，保证数据的完整性。

【6】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。