前言

各位读者好, 我是小陈, 这是我的个人主页, 希望我的专栏能够帮助到你:
📕 JavaSE基础: 基础语法, 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
📗 Java数据结构: 顺序表, 链表, 堆, 二叉树, 二叉搜索树, 哈希表等
📘 JavaEE初阶: 多线程, 网络编程, TCP/IP协议, HTTP协议, Tomcat, Servlet, Linux, JVM等(正在持续更新)

之前的文章介绍了基于 TCP 协议的 SocketAPI 使用, 写了一个简单的回显程序, 对服务器客户端的网络通信和 TCP 协议有了一个基本认识

TCP 协议是一种有链接的可靠传输协议, 并且 TCP 设计的宗旨是保证可靠性的同时, 尽可能地提高传输效率, 因此 TCP 具有八大机制

1️⃣连接管理(三次握手 + 四次挥手)
2️⃣确认应答
3️⃣超时重传
4️⃣滑动窗口
5️⃣流量控制
6️⃣拥塞控制
7️⃣延迟应答
8️⃣捎带应答

在这里插入图片描述

看不懂吧, 没关系, 我会出手, 先记住2~3 用来保证可靠性, 4~8 用来提高效率

在使用 TCP 协议进行网络通信时, 首先需要客户端和服务器建立连接, 通信结束服务器和客户端要断开连接, 这个过程的背后就是 TCP 的连接管理机制, 也是非常重要的知识点, 本片就重点介绍这个连接管理机制的原理

提示：是正在努力进步的小菜鸟一只，如有大佬发现文章欠佳之处欢迎批评指点~ 废话不多说，直接上干货！

一、三次握手

📌服务器和客户端在通信之前, 要建立连接, 这个过程称作“三次握手”, 在程序中对应的就是 ServerSocket 类里面的 accept 方法

👉一次握手就是一次交互, 服务器和客户端经历了三次交互之后, 双方才能建立连接, 如图 :
在这里插入图片描述

📌注意 : 第一个发送 syn (同步报文段)的是客户端

图上明明是四次交互, 为什么说是三次握手呢 ?
由于三次握手中的发送 syn 和 ack 都是操作系统内核完成的, 我们程序员干预不了也感知不到, 服务器给客户端发的两条( syn 和 ack )是同一时机的, 所以实际上是合并成一条发送了
(后面会写文章介绍TCP首部的格式, 到时候就会知道如何实现了)

所以正确的三次握手过程如下图所示 :
在这里插入图片描述

syn 是表示请求建立的报文段, 发送这个可以理解, 为什么还要有一个 ack 报文段呢 ?
这是 TCP 的确认应答机制, 用来保证可靠传输, 后续的文章中还会介绍

三次握手的作用

相当于是正式通信前的检查, 这个过程中发送方和接收方都进行了收发数据报, 如果顺利, 就能确认双方发送数据和接收数据的能力都是正常的

二、四次挥手

📌服务器和客户端在通信之后, 要断开连接, 这个过程称作“四次挥手”, 在程序中对应的就是 Socket 类里面的 close 方法

👉一次挥手就是一次交互, 服务器和客户端经历了四次交互之后, 双方才能断开连接, 如图 :
在这里插入图片描述

📌 和三次握手不同, 第一次发送 fin(结束报文段)的可以是客户端也可以是服务器

下面是一些关于四次挥手的解释说明

1, 四次挥手过程中, 被发送 fin 的一端(图中是服务器)的 ack 和 fin 能否合并成一条发送呢 ?
通常情况下不能, 因为三次握手中的 syn 和 ack 都是由内核完成的, 而四次挥手中的 fin 是由于调用了 close 方法才发送的, 不能保证一端 close 之后, 另一端的 close 方法什么时候调用, 所以 ack 和 fin 大概率不是同一时机发送的, 但是也有小概率因为 TCP 的捎带应答机制进行合并, 大部分情况下是四次交互, 所以称作四次挥手
2, 一端调用了 close 方法, 发送了 fin , 怎么还能进行后续的三次交互呢 ?
调用 close 方法只是关闭了 socket 文件, 操作系统内核仍然会维护服务器和客户端的连接, 等到四次挥手之后才彻底断开连接
3, 如果不调用 close 方法, 怎么发送 fin ?
如果某一端不调用 close 方法, 就会在其进程结束时会由操作系统内核自动关闭 socket 文件, 还是会向对端发送 fin