三次握手协议：三次握手协议的主要过程是交互彼此之间的初始序列号，如果没有确认的ACK帧可以么？肯定是可以的
client A -------> server B
client A 发送了自己的初始序列号；然后B看见了之后B发送了一个初始序列号，这样两次“握手”都可以啊。但是两次握手的问题是：此时A开始发送信息，B肯定是收到了A的序列号了；B告诉A说我的序列号；二次握手基于的假设是：我发送结束后默认你已经知道了我的初始序列号是多少，但是现在的问题是B肯定是知道A的序列号了，所以B可以很自如地向A发送数据包，但是如果A一直没有发送数据包，那么是因为B的sync序列号的包没有达到，A不知道B的初始序列号所以没发呢？还是说A就是没有发送数据包，还是说A的数据包丢失了呢？B端充满了疑惑。好像是可以工作的，B端此时会超时重传，不断地去发送SYNC包告诉A说自己的初始序列号；那么这里就是整个问题的核心了：此时我如果A就是没有数据要发呢? 你Ｂ一遍遍给我发初始的序列号信息，１个，２个，３个，。。。。，此时Ａ可以告诉你说序列号包我收到啦，别发了再（这不就是第三次握手的内容么）。。。所以，如果是两次握手的话，Ｂ的回复包没丢还好，如果丢了，那么至少还要发送两个数据包来确认问题！这是至少！因此还是要通过三次握手才行呢；三次握手，Ａ和Ｂ都能达到一个终态，这个终态可以有效防止丢包的雪崩效应。如果Ｂ一直没有收到Ａ的ａｃｋ帧，那么就重发ｓｙｎｃＢ，ａｃｋａ；如果Ａ一直没有收到Ｂ的ｓｙｎｃＢ，ａｃｋＡ，那么就重新发ａｃｋＡ；三次握手的一个最大的好处就是告诉Ｂ：Ａ知道你的初始序列号是多少了，可能暂时不会有数据过来了，所以疑惑扫了一大堆。到这里其实建立的是Ａ和Ｂ的全双工的链路。
那四次挥手又是解决啥问题呢？
Ａ调用ｃｌｏｓｅ是为了说啥呢？是说我这里不在对你Ｂ发送数据，还是告诉Ｂ我不再接受数据呢？是前者，告诉Ｂ我不再向你发送数据了（但是我这边仍然有段时间会接受到你的数据）或者说是申请关闭链接，你看着办吧。
ＡＣＫ报文在ＴＣＰ协议中超级重要，它可以很大程度防止丢包引起的重传。握手阶段的ＡＣＫ上面已经分析过了；在真正的数据传输阶段呢，当Ａ发送了１，２，３，４，５包，然后又发送了６，我怎么确定包是否是收到了呢？要不然我一个劲儿地发也没用呀，ＡＣＫ帧的主要作用就是让Ａ和Ｂ的信息透明。
ＡＣＫ在整个ＴＣＰ协议中的作用是信息透明，防止重传；
在结束的时候也是这样，如果A发送了ＦＩＮ，如果好久没有相应，那么Ａ怎么知道到底是因为数据包在Ａ－>B的路上丢了，还是Ｂ已经收到了，所以必须要让Ａ心知肚明，此时Ｂ先发送一个ＡＣＫ帧过来，通知Ａ：我Ｂ收到了你的断开请求。【还是没有找到问题的根源。三次握手的第三个ACK包是为了降低B的疑惑，即当A迟迟没有发数据，不是因为A没有收到B的序列号，而是因为A本来就没有发过来数据，至于发过来的数据半路丢了，那就是A的事情了】那四次挥手呢？
四次挥手也是也是同样的道理，需要发送ACK帧表明对方确实已经收到了我的帧，以此表明我可以进入下一个状态，等待我期望的数据包，完成状态机的转换。WAIT状态确实可以防止新建立的客户端接收到老的tcp链接的数据包，因为服务器端在发送FIN(3)的数据包的时候已经保证之前的数据包都发送完毕了，这个FIN的目前的年龄肯定是小于之前发送给client的数据包的年龄的，所以clinet进入WAIT状态时等待的2mst就能够保证该端口不被占用。很巧妙。但是如果client端接受到服务器端的FIN(3)后发送给服务器的ack包对了咋办呢？知乎上的讨论
https://www.zhihu.com/question/27564314
先如知乎上说的这样记着吧，如果长时间得不到链接，服务器端的LAST_ACK就自动转化成close状态了。
整个网络模型就是自动机。