TCP三次握手 A和B一起玩运输和吃苹果的游戏

TCP三次握手
A和B都参加了运输苹果和吃掉苹果的比赛。但是现在双方都不知道队友是谁
A的角色是发苹果  B的角色是收苹果和吃苹果


1.B先收集了一些信息，比如苹果放在哪里，苹果发到哪里，苹果丢了怎么重新发
当前的号码牌是几号（即当前的发送和接收序号）
术语叫：创建传输控制块


2.B把信息收集好了，就把家门打开，等着其他人来找他一起合作玩游戏

3.A也和B一样，先收集一些基本信息比如苹果放在哪里，苹果发到哪里
苹果丢了怎么重新发。当前的发送和接收序号等
术语叫，创建传输控制块

4.A主动找到B，和B说，你想和我一起合作完成游戏吗（SYN=1）？A处于同步请求已发送状态
SYN=1,seq=x(随机值)，作为TCP客户进程所选择的初始序号
（PS:TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号）
这是A给B发的第x-x条消息，从0开始算

5.B接收到同步请求，就和A说，我愿意和你一起合作玩游戏,那你愿意和我一起合作玩游戏吗？然后进入同步请求已接收状态
SYN=1,ACK=1,ack=x+1,seq=y(随机值),作为TCP服务进程所选择的初始序号
ack=x+1是对TCP客户端请求seq=x的确认。这个报文也不能携带数据，因为SYN=1

我同意（ACK=1）,你也愿意吗（SYN=1）,这是我给你发的第y-y条消息，也是从0开始算。我想收到你的第x+1条数据（ack=x+1）

6.A收到B发的消息，信息若狂，这是同意和我组队，并且还问我意见呢，我得赶紧回。说我愿意我愿意和你一起合作玩游戏。
进入连接已建立状态
ACK=1,seq=x+1,ack=y+1
ps:这里SYN没有值，所以可以发送数据，但是如果不发送数据的话，就不消耗序号，所以说还是seq=x+1

我也同意（ACK=1,）这是我给你发的第x+1条数据（seq=x+1）  我想收到你的第y+1条数据（ack=y+1）


7.B收到A的报文，知道了A也愿意和自己合作，于是B也进入连接已建立状态

　　

两次握手可以吗？会出现什么问题


如果只有两次握手
1.A发了一个TCP连接请求，但是由于网络原因，没能按时传送到B

2.A重新发一个TCP连接请求，进入连接已发送状态
3.B收到A的请求，进入连接已建立状态，然后给A发连接请求

4.A收到B的连接请求，进入连接已建立状态
5.正常传输数据，然后四次挥手关闭连接

6.若此时1中的请求到达B，则B再次进入连接已建立状态，等待A发消息
但是由于A已经关闭了，所以B是永远收不到来自A的信息的，会造成B很大的资源浪费


简单理解就是，两次握手太草率了。A给B发，B给A回就建立连接，万一A发完就跑了呢，那B永远也等不到A之后的承诺了

　　

A给B发邮件，过了5分钟B没回信
A重新发一封问B，要不要组队合作同步玩游戏
B收到了，给A回邮件说，可以，然后自己进入连接已建立状态
A收到B的邮件，知道了B同意，所以也进入连接已建立状态
A和B一起玩游戏，然后说拜拜，A下线了
然后B又收到了A最开始发的那封邮件，
B想，A还想和我一起玩游戏呢，那就再来一局。进入了连接已建立状态，并且给A回邮件说，我同意一起玩游戏，等A回复
但是A已经下线了，他是不能回复B的邮件的，B就会一直等待，浪费B的资源

所以一定要三次握手，保证A在线