当前位置: 首页 > news >正文

「网络原理」三次握手四次挥手

🎇个人主页:Ice_Sugar_7
🎇所属专栏:计网
🎇欢迎点赞收藏加关注哦!

三次握手&四次挥手

  • 🍉连接管理
    • 🍌三次握手
    • 🍌意义
    • 🍌四次挥手
    • 🍌TCP 状态转换
      • 🥝LISTENING 状态
      • 🥝ESTABLISHED 状态
      • 🥝CLOSE_WAIT & TIME_WAIT 状态

🍉连接管理

有连接是 TCP 的特点之一

socket = new Socket(serverIp,serverPort);

执行这行代码其实就是在建立连接,不过这只是在调用 socket api,真正建立连接是在操作系统内核完成的,见下图:

在这里插入图片描述

🍌三次握手

内核通过三次握手来完成建立连接的过程
在此之前得先介绍一种数据报—— syn

syn 是一个特殊的 TCP 数据报,它没有载荷,因此不会携带应用层数据;
同时标志位中的 SYN 值为 1
虽说无载荷,但是它也有 IP 报头、以太网数据帧帧头、TCP 报头等。其中 TCP 报头和 IP 报头分别包含客户端自己的端口和 IP

syn 其实是 synchronized 的缩写,它是多线程的常客,意为同步。多线程使用 synchronized 加锁实现的同步是协调多个线程间的执行顺序;而 TCP 这里的同步是指进入连接状态,客户端和服务器相互配合完成一系列工作。可以理解为 syn 就是客户端给服务器打个招呼,表示要与它建立连接,服务器收到后要发个 ack 回应一下,同时发个 syn 表示同意连接

在这里插入图片描述

🍌意义

  1. 三次握手可以初步确认通信链路是否畅通,这是确保可靠性的前提条件
  2. 三次握手可以验证通信双方发送能力和接收能力是否正常

在这里插入图片描述
由此衍生出一道面试题:能否握两次手?四次呢?
A:两次肯定不行,因为服务器这边还无法确认自己的发送能力和对端的接收能力是否正常,因此需要服务端再来一次握手,把信息同步给服务器;四次可以,但是没必要

  1. 三次握手的过程中也会协商一些必要的参数
    通信是客户端和服务器两端共同配合完成的,所以有些参数要进行协商,这些参数往往是在“选项”中体现的

在这里插入图片描述
我们前面说“选项”可有可无,最少占 0 个字节,最多占 40 字节(报头最大长度为 60,去掉固定的 20,就剩下 40 字节)。选项中的信息我们不用去深究,不过有一个信息是比较关键的 —— TCP 通信的序号起始值
TCP 在一次通信过程中,序号不是从 0 或 1 开始的,而是先选择一个比较大的数字,从它开始计算,而且即使是同一个客户端和服务器,每次连接的起始值都不同。这里的“不同”不是随机给一个值,而是经过一系列的分配策略得出的。这样做的好处在于避免处理到上次连接的数据报
数据报在传输过程中遇到阻塞,迟迟没有到达对端,可能在本次连接断开后还没到达,等到下次连接建立时才到达,但此时已经是别的客户端了,不适合处理上次连接的数据报,应该把它丢弃


🍌四次挥手

每个客户端/服务器都要保存对端的信息,这些信息需要使用一定的数据结构来存储,断开连接的本质就是把对端的信息从数据结构中删掉/释放掉
四次挥手中,服务器和客户端其中一方先调用 socket.close(),然后触发 FIN,即向对端发送 FIN 结束报文段
(除了调用 close(),结束进程也会触发 FIN。这两种方式本质都是关闭 socket 文件)
假设是客户端请求断开连接,那么四次挥手流程如下:

在这里插入图片描述
注意四次挥手中间的两步不像三次握手,不一定可以合并

在这里插入图片描述
在这里插入图片描述
下面总结一下这两者之间的相似之处和不同之处
相似点:
都是通信双方中某一方给对方发起一个 syn/fin,交互过程中中间两个数据报是由同一个机器发出的
不同点:

  1. 三次握手中间两次可以合并为一次;四次挥手不一定
  2. 三次握手一定是客户端主动发起连接请求;而四次挥手可以由客户端或服务器发起

🍌TCP 状态转换

前面说 TCP 服务器和客户端都有一定的数据结构保存连接的信息,在数据结构中有个属性叫作状态,操作系统内核根据不同的状态决定应该干什么

🥝LISTENING 状态

表示服务器创建好 serverSocket,并且绑定好端口号了
设定端口号为 5000,启动服务器后在控制台查询服务器状态,得到如下信息:

在这里插入图片描述

🥝ESTABLISHED 状态

表示客户端和服务器已经建立连接(三次握手结束了)
启动客户端后,再次查询状态:

在这里插入图片描述
接下来看一下三次握手中的状态变化

在这里插入图片描述


🥝CLOSE_WAIT & TIME_WAIT 状态

前者表示接下来代码中需要调用 close 来主动发起 FIN。收到对方的 FIN 后会进入这个状态
本端给对方发起 FIN 后,对端也给本端发 FIN 之后,本端就会进入 TIME_WAIT 状态
主动断开连接的一端会进入 TIME_WAIT 状态;被动断开的一端则是进入 CLOSE_WAIT 状态
接下来看一下四次挥手中的状态变化,假设是客户端主动断开 TCP 连接

在这里插入图片描述

http://www.lryc.cn/news/369235.html

相关文章:

  • 第二十四章 SOAP 错误处理 - 发生故障时添加 WS-Addressing 标头元素
  • CSS真题合集(一)
  • Golang | Leetcode Golang题解之第144题二叉树的前序遍历
  • 离奇问题:java通过poi读取excel单元格的小数时会出错
  • 前端框架是什么
  • Feign的动态代理如何配置
  • ReactRouter——路由配置、路由跳转、带参跳转、新route配置项
  • 异步处理耗时逻辑
  • Switch 之 配置SNMP
  • 微软如何打造数字零售力航母系列科普13 - Prime Focus Technologies在NAB 2024上推出CLEAR®对话人工智能联合试点
  • Nginx之正向代理配置示例和说明
  • Linux文件与目录管理
  • 08.组件间通信-插槽
  • 在AWS上运行的EKS Elastic Kubernetes Service 创建集群Cluster,Node group, Nodes
  • 10款堪称神器的宝藏软件,相见恨晚
  • 为什么会选择厚膜作为芯片电阻?
  • 基本药物采购使用
  • k8s小型实验模拟
  • leetcode168:Excel表列名称
  • 排课系统1
  • uni-popup
  • torchmetrics,一个无敌的 Python 库!
  • 如何快速上手Python,成为一名数据分析师
  • MC服务器怎么搭建
  • JavaScript正则表达式
  • Redis实战宝典:基础知识、实战技巧、应用场景及最佳实践全攻略
  • [FFmpeg学习]初级的SDL播放mp4测试
  • 情景题之小明的Linux实习之旅:linux实战练习1(下)【基础命令,权限修改,日志查询,进程管理...】
  • k8s 证书更新
  • Linux操作系统学习:day01