【JAVA基础--计算机网络】--TCP三次握手+四次挥手

本文详细阐述了TCP协议中的三次握手用于建立连接确保双方能力正常,以及四次挥手用于可靠断开连接避免状态不一致。涉及面试常见问题及潜在问题的讨论。
摘要由CSDN通过智能技术生成

写在前面

三次握手建立连接;四次挥手断开连接;

TCP协议里的标识:
SYNSynchronization(同步)
ACKAcknowledgment(确认)
FINFinish(结束)

1. 三次握手

1.1 作用: 为了在不可靠的信道上建立起可靠的连接;
1.2 建立过程

当客户端向服务端发起连接请求时候:

  1. 先发一包连接请求数据(SYN包)来询问能否与服务端建立连接,这包数据我们叫做SYN包:(想和你同步);
  2. 如果对端同意连接就会回复一包SYN+ACK包(确认同步);
  3. 客户端收到之后回复一包ACK包(确认)。

注:自己的序号用对方的确认号; 自己的确认号 用对方的序号+1
在这里插入图片描述

在这里插入图片描述

1.3 面试提问

问题1:为什么是三次握手而不是两次握手or四次握手
答:
目的:握手是为了确认双方的接收与发送能力是否正常

  • 第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的;

  • 第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常;

  • 第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常;

  • 如果是两次握手,服务端并不能确认客户端的接收能力是否正常;而且为了防止已经失效的请求报文,突然又传到服务器引起错误
  • 三次握手是两端建立连接的所需要的最小收发包的次数,所以四次握手就没有必要了

问题2:两次握手可能产生的问题?
答:假设采取两次握手,客户端向服务端发起一个报文SYN1,因为某些未知错误,并未到达服务器,在中间某个网络节点产生了滞留;而为了建立连接客户端会重新发送一个SYN包,我们称之为SYN2,这次正常送达服务端,并且回复SYN+ACK后建立连接;这时阻塞的网络节点突然恢复,把SYN1重新发给了服务端,服务端就会误认为是客户端发起了新的连接;

服务端认为是两个连接,客户端认为是一个连接,造成了状态不一致的问题;


2. 四次挥手

握手之后就建立连接­——连接建立好以后,客户端就可以发送http请求——然后服务端响应内容;

因为TCP协议是全双工的,所以两端都可以发送关闭请求;

2.1 作用:为了在不可靠的网络信道中进行可靠的连接断开确认
2.2 断开过程
  • 第一次挥手:客户端发送FIN+ACK(确认结束)
  • 第二次挥手:服务端回复ACK(确认)因为服务端可能还存在未发送完毕的数据所以还需要等待数据全部发送完以后回复确认结束,也就是第三次挥手;
  • 第三次挥手:服务端回复FIN+ACK(确认结束);
  • 第四次挥手:客户端回复ACK(确认);进入超时等待状态
    在这里插入图片描述
2.3 面试提问

问题1:为什么客户端在回复ACK包之后还需要等待超时时间?
答:
目的:为了在不可靠的网络信道中进行可靠的连接断开确认;

原因:因为如果客户端在发送完最后一包ACK包就释放了连接的话,一旦ACK包在网络中丢失,服务端就会一直停留在最后确认状态;若发送完最后一包ACK包,再等待一段时间,此时如果服务端没有收到ACK包,就会重发FIN包;客户端会响应这个FIN包,且重发ACK包,并刷新超时时间

  • 43
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大龄烤红薯

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值