Java网络编程之TCP协议核心机制(一)

目录

题外话

正题

TCP协议核心机制

1.确认应答机制

2.超时重传

3.连接管理

 三次握手(建立数据连接)和四次挥手(断开连接)

三次握手

三次握手的意义

为什么不能是四次挥手和两次挥手呢???

四次挥手(断开连接)

四次挥手的意义

四次挥手能变为三次挥手吗?

小结

---

 

题外话

最近进入了迷茫期了,可能是我学习能力和心态不足,在宿舍总是静不下心学习,调整调整,正好把最近学的内容再整理复习一遍

正题

本篇博客要讲的TCP协议核心机制属于网络通信中的内容,大多都是概念性内容,也是面试时肯定会考的问题

TCP协议核心机制

关于TCP协议核心机制这里,我也看了好多好多视频什么的,但是感觉讲的不太细致

TCP协议核心机制是保证TCP功能特点创造出来的

TCP协议和UDP协议是传输层(TCP/IP参考模型中的一种)的两种协议,这里直接展示下两种协议的功能特点

1.确认应答机制

此机制实际就是为了保证传输的可靠性 

我们从客户端发送到服务器的数据是通过数据的一串连续的序列号表示的

服务器会向客户端发送数据序列号最后一位加1也就是ACK应答报文来确认数据包是否丢失

如果发生丢包服务器不会返回应答报文,这样就可以保证传输可靠性

如下图(演示的是没有丢包的情况)

2.超时重传

因为网络问题等一系列原因导致客户端发送数据后服务器没有接收到数据

从而在一定时间间隔内,导致客户端没有收到服务器的确认应答数据,就会开始进行超时重传

如下图

我们要说明两个问题

1.超时重传的设置时间

我们要制定超时重传的时间,如果时间过短(比如数据还没传输完成就开始重传),这样就会导致客户端多次发送重复数据

如果时间过长,如果发生网络等问题引起数据一直发送不过去,又因为设置超时时间过长导致数据不重传一直等待,很影响传输效率

针对这个问题,我们需要通过发送数据大小动态调整超时时间,要让在超时时间内可以完成数据传输,又不会因为网络等问题一直等待数据传输影响效率

2.超时重传的频率问题,如果网络一直有问题(比如网速很慢)

我们在正常网速情况下超时时间内可以完成数据传输,但是在网速很慢的情况下超时时间内就无法完成

所以每当进行一次超时重传的时候,会将超时时间按倍数加长,重传频率会变低

Linux中(BSD Unix和Windows也是如此),超时以500ms为⼀个单位进行控制,每次判定超时重发的 超时时间都是500ms的整数倍

累计到⼀定的重传次数,TCP认为网络或者对端主机出现异常,TCP会强制关闭连接

3.超时重传导致传输多个重复数据问题

TCP接收方在操作系统内核中会存在一个数据结构"接收缓冲区",当数据到达接收缓冲区可能是乱序,因为数据发送前序号是从小到大连续的,所以在缓冲区中会将数据从小到大排序,

TCP这边会针对收到的数据按照序号进行去重

3.连接管理

这里我们需要讲解一下三次握手和四次挥手

我们想传输数据进行通信,一定是要先建立客户端和服务器的连接,建立之后才能传输数据

 三次握手(建立数据连接)和四次挥手(断开连接)

三次握手

简单来说就是客户端和服务器需要互相知道对方能接收自己的数据信息

一般都是客户端主动发送请求

比如甲要给乙用语音打电话

1.甲先给乙打过去电话,甲问乙能不能听到

2.乙说能听到,你那边也可以听到吗

3.甲说我这边也可以听到

这样甲和乙就建立了连接,双方都可以收到对方发送的信息

下面咱们庖丁解牛将三次握手逐层分析一下

客户端需要发送数据开始建立连接

1.首先客户端发送SYN(同步)数据包到服务器

当服务器收到SYN数据包知道客户端要开始建立连接

然后服务器发送SYN数据包和ACK数据包,告诉客户端我已经准备好建立连接

2.服务器同时发送SYN(同步)数据包和ACK(确认同步)数据包到客户端

客户端收到服务器可以建立连接的信息后,要告诉服务器,自己也可以建立连接

3.客户端发送ACK(确认同步)数据包到服务器

经过以上三次挥手,服务器和客户端双方都确认对方可以建立连接,从而真正建立连接开始通信

三次挥手状态转换详情图

说一下重要的两个状态

LISTEN状态:服务器出现的状态,当服务器绑定一个端口成功之后会进入LISTEN状态,随时可以有客户端连接

ESABLISHED状态:代表建立连接完成,可以随时进行后续通信

三次握手的意义

三次握手可以确保数据在两个设备之间可靠地传输。它可以防止以下情况的发生:

不会丢失:如果没有三次握手，客户端和服务器可能会同时发送数据，导致数据丢失。

不会重复:如果没有三次握手，客户端和服务器可能会重复发送数据，导致数据重复。

不会乱序:如果没有三次握手，客户端和服务器可能会乱序发送数据，导致数据乱序。

为什么不能是四次挥手和两次挥手呢???

1.我们要建立连接一定是客户端和服务器都知道对方要建立连接并且准备好

2.我们要考虑建立连接的安全性和效率问题(一个SYN数据包会经历层层分装和分用)

3.两次挥手是一定不安全的,而四次挥手完全没有必要

4.三次挥手是在安全和效率都得到保证的情况下的方案

四次挥手(断开连接)

客户端和服务器都可以提出断开连接请求

简单来说客户端和服务器有一方提出断开连接,双方都要关闭资源还要整理一些正在传输的数据,这些都执行完,互相通知对方可以关闭连接

这里还是庖丁解牛一步一步讲解一下

1.客户端发送断开连接请求FIN

2.服务器发送ACK应答,代表自己收到断开连接请求

3.服务器要关闭删除一些数据,之后发送FIN表示可以终端连接

4.客户端发送ACK应答,同意关闭连接

四次挥手的意义

四次挥手可以确保数据在两个设备之间可靠地传输。它可以防止以下情况的发生:

如果没有四次挥手，客户端和服务器可能会同时关闭连接，导致数据丢失。

如果没有四次挥手，客户端和服务器可能会重复发送数据，导致数据重复。

如果没有四次挥手，客户端和服务器可能会乱序发送数据，导致数据乱序。

四次挥手能变为三次挥手吗?

常规情况下不能合并,因为服务器收到FIN会立即发送ACK(由内核控制的)

之后还要整理资源,将正在传输的数据整理完成等操作,这也需要时间,然后调用close的时候服务器才会传输FIN到客户端

这两个操作不是同一时机,难以进行合并

在特殊情况下可以合并上述两个操作,TCP中还有一个机制,"延时应答"(这篇博客先不讲了,内容太多了)

在正常情况下,断开连接肯定要经历四次挥手,所以要考虑最常见的情况,称为四次挥手

小结

总结一下博客内容吧

首先,所有的TCP机制都是在保证TCP的功能特点

TCP要先依靠连接管理机制,进行三次挥手(建立连接),然后才能进行数据通信

数据通信过程中,我们要通过确认应答机制保证不会丢失数据包

在数据传输过程中,我们为了保证数据安全性和传输效率还要依靠超时重传机制

这中间还有一些机制下篇博客再讲

当我们关闭数据通信,也要依靠连接管理机制进行四次挥手(断开连接),才能保证数据正确关闭

如果觉得本人写的不错麻烦家人们给个三连吧(点赞关注收藏!!!)