三次握手协议：三次握手协议的主要过程是交互彼此之间的初始序列号，如果没有确认的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的序列号，而是Abenlai】
