三次握手协议: 三次握手协议的主要过程是交互彼此之间的初始序列号, 如果没有确认的 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 就是没有数据要发呢? 你B一遍遍给我发初始的序列号信息,1个,2个,3个,, 此时A可以告诉你说序列号包我收到啦, 别发了再 (这不就是第三次握手的内容么) 所以, 如果是两次握手的话,B的回复包没丢还好, 如果丢了, 那么至少还要发送两个数据包来确认问题! 这是至少! 因此还是要通过三次握手才行呢; 三次握手,A和B都能达到一个终态, 这个终态可以有效防止丢包的雪崩效应如果B一直没有收到A的ack帧, 那么就重发syncB,acka; 如果A一直没有收到B的syncB,ackA, 那么就重新发ackA; 三次握手的一个最大的好处就是告诉B:A知道你的初始序列号是多少了, 可能暂时不会有数据过来了, 所以疑惑扫了一大堆到这里其实建立的是A和B的全双工的链路
那四次挥手又是解决啥问题呢?
A调用close是为了说啥呢? 是说我这里不在对你B发送数据, 还是告诉B我不再接受数据呢? 是前者, 告诉B我不再向你发送数据了 (但是我这边仍然有段时间会接受到你的数据) 或者说是申请关闭链接, 你看着办吧
ACK报文在TCP协议中超级重要, 它可以很大程度防止丢包引起的重传握手阶段的ACK上面已经分析过了; 在真正的数据传输阶段呢, 当A发送了1,2,3,4,5包, 然后又发送了6, 我怎么确定包是否是收到了呢? 要不然我一个劲儿地发也没用呀,ACK帧的主要作用就是让A和B的信息透明
ACK在整个TCP协议中的作用是信息透明, 防止重传;
在结束的时候也是这样, 如果 A 发送了FIN, 如果好久没有相应, 那么A怎么知道到底是因为数据包在A->B 的路上丢了, 还是B已经收到了, 所以必须要让A心知肚明, 此时B先发送一个ACK帧过来, 通知A: 我B收到了你的断开请求还是没有找到问题的根源三次握手的第三个 ACK 包是为了降低 B 的疑惑, 即当 A 迟迟没有发数据, 不是因为 A 没有收到 B 的序列号, 而是 Abenlai
来源: http://www.bubuko.com/infodetail-2545889.html