前言

📕各位读者好, 我是小陈, 这是我的个人主页
📗小陈还在持续努力学习编程, 努力通过博客输出所学知识
📘如果本篇对你有帮助, 烦请点赞关注支持一波, 感激不尽
📙 希望我的专栏能够帮助到你:
JavaSE基础: 从数据类型 到 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
Java数据结构: 顺序表, 链表, 二叉树, 堆, 哈希表等 (正在持续更新)
JavaEE初阶: 多线程, 网络编程, html, css, js, severlet, http协议, linux等(正在持续更新)

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

在使用 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 大概率不是同一时机发送的, 如果赶巧了在同一, 说不定可能会合并, 但是通常情况下是四次交互

2, 一端调用了 close 方法, 发送了 fin , 怎么还能进行后续的三次交互呢 ?
调用 close 方法只是关闭了 socket 文件, 操作系统内核仍然会维护服务器和客户端的连接, 等到四次挥手之后才彻底断开连接

3, 如果不调用 close 方法, 怎么发送 fin ?
如果某一端不调用 close 方法, 就会在其进程结束时会由操作系统内核自动关闭 socket 文件, 还是会向对端发送 fin