JavaWeb~传输控制协议（TCP，Transmission Control Protocol）(完整篇)

最新推荐文章于 2024-05-14 21:13:05 发布

2401_84103327

最新推荐文章于 2024-05-14 21:13:05 发布

阅读量631

点赞数 10

分类专栏：程序员文章标签： tcp/ip 网络协议网络

本文链接：https://blog.csdn.net/2401_84103327/article/details/138226842

版权

程序员专栏收录该内容

235 篇文章 0 订阅

订阅专栏

丢包有俩种可能性

客户端发的请求丢了

服务器回复的应答丢了

所以无论是哪方丢了都会触发重新传输报文
也就是说当发送了一条数据之后 TCP内部会自动启动一个定时器达到一定时间还没有收到ACK(应答) 定时器就会触发重传消息的动作
但是俩种丢包的方式实际上还有差距

如果是请求丢了那对双方没什么影响重发就行

但是如果是应答(ACK)丢了那么服务器就会遇到收到很多重复数据的情况那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果

那么如果超时的时间如何确定?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.

但是这个时间的长短, 随着网络环境的不同, 是有差异的.

如果超时时间设的太长, 会影响整体的重传效率;

如果超时时间设的太短, 有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间

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

如果重发一次之后, 仍然得不到应答, 等待 2_500ms 后再进行重传.

如果仍然得不到应答, 等待 4_500ms 进行重传. 依次类推, 以指数形式递增.

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

连接管理机制(三次握手)

===========================================================================

在正常情况下, TCP要经过三次握手建立连接

在这里插入图片描述

举个打电话的简单列子

在这里插入图片描述

TCP中的真实连接过程

在这里插入图片描述

第一次握手：

客户端将TCP报文标志位SYN置为1，随机产生一个序号值seq=J，保存在TCP首部的序列号(Sequence Number)字段里，指明客户端打算连接的服务器的端口，并将该数据包发送给服务器端，发送完毕后，客户端进入SYN_SENT状态，等待服务器端确认。

第二次握手：

服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将TCP报文标志位SYN和ACK都置为1，ack=J+1，随机产生一个序号值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。

第三次握手：

客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

注意:我们上面写的ack和ACK，不是同一个概念：

小写的ack代表的是头部的确认号Acknowledge number，缩写ack，是对上一个包的序号进行确认的号，ack=seq+1。

大写的ACK，则是我们上面说的TCP首部的标志位，用于标志的TCP包是否对上一个包进行了确认操作，如果确认了，则把ACK标志位设置成1。

建立连接的过程相当于通信双方各自给对方发送SYN 再各自给对方发送ACK应答只不过中间的ACK和SYN合二为一了于是就形成了三次握手

如果只有俩次握手可以吗?

答案是不可以
就那我刚刚举的那个打电话的例子你说该取消那一次"握手" 如果必须要让双方都知道彼此正常的话至少三次握手

如果是四次握手可以吗?

可以但是完全没必要
如果是将中间第二步的SYN和ACK拆开是可以的但是这样做效率比较低传输一个包的效率肯定比传输俩个包的效率高
如果是比如刚刚那个打电话的例子你打电话反复问听的到吗? 这既复杂又没有意义呀是吧嘿嘿

连接中的重要状态

CLOSED

处于关闭状态

LISTEN

服务器准备就绪随时可以有客户端来建立连接

STN_SENT / STN_RCVD

建立连接的中间过程如果连接正常这俩个状态都是一瞬间消失的

ESTABLISHED

连接建立完毕

断连接管理机制(四次挥手)

============================================================================

在这里插入图片描述

挥手请求可以是Client端，也可以是Server端发起的，我们假设是Client端发起：

第一次挥手： Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq，此时，Client端进入FIN_WAIT_1状态，这表示Client端没有数据要发送给Server端了。

第二次分手：Server端收到了Client端发送的FIN报文段，向Client端返回一个标志位是ACK的报文段，ack设为seq加1，Client端进入FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求。

第三次分手： Server端向Client端发送标志位是FIN的报文段，请求关闭连接，同时Client端进入LAST_ACK状态。

第四次分手： Client端收到Server端发送的FIN报文段，向Server端发送标志位是ACK的报文段，然后Client端进入TIME_WAIT状态。Server端收到Client端的ACK报文段以后，就关闭连接。此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。

其实四次挥手断开连接本质也是双方发起断开连接请求再各自给对方回应只不过中间的FIN和ACK是不能合并在一起的
为什么不能合并在一起呢? (这也是一个常见问题断开连接可以是三次吗?)

因为发送的时机不一样服务器发送ACK后服务器在这俩个之间应用程序需要处理积压的数据就是虽然客户端要断开连接但是服务器仍然可能会有一些待处理的数据此时需要服务器把积压的数据处理完了之后才会发送FIN 调用socket的close方法的时候发挥发送FIN

当然建立连接的时候 ACK和SYN多事内核决定的时间上是同一时间发送的所以就可以合并在一起

断开连接的重要状态

FIN_WAIT1 / FIN_WAIIT2

实现TCP连接和断开都需要一定的流程为了方便记录不同的流程所以就引进来很多不同的状态而这俩个就是为了记录状态(根据状态识别现在到哪个步骤了)

其实FIN_WAIT1的存在是很短暂的当客户端发送FIN进入该状态一旦收到ACK就会进入FIN_WAIT2的状态如果服务器一直不发送FIN 那么客户端就会一直处于FIN_WAIT2的状态而服务器就会处于CLOSE_WAIT状态

CLOSE_WAIT

此时4次挥手挥了一半 (当然有可能挥了一半剩下的一般就不挥了也就是服务器没有调用close方法从而导致没有正确的关闭连接 ) (比如服务器代码中出现一些异常导致没有执行close方法)

如果服务器上出现大量的CLOES_WAIT状态说明服务器代码中有BUG 这就是文件资源泄漏问题

LAST_ACK

只要服务器接收到了FIN发送了ACK 然后又成功执行了close方法向客户端发送了FIN就会进入LAST_ACK状态

TIME_WAIT

这个算是较为重要的一个状态

谁先主动断开连接谁就会进入TIME_WAIT状态其实此时对于主动断开一方已经完成了4次挥手但是他任然不能立即释放连接而且要以这个状态保持一段时间再彻底释放连接

那么等待时间为什么是2MSL呢?

就要了解为什么TIME_WAIT要等待一段时间其实就是为了确保双方都真正的进入CLOSED状态

如一旦最后一个ACK丢失服务器无法区分是自己FIN丢失了还是对方ACK丢失了所以服务器都会重新传输FIN数据包如果客户端不保持一段时间服务器重传的FIN就无法有应答ACK了

所以一旦存在大量的TIME_WAIT状态的这种情况不是BUG 过段时间就好了

所以服务器需要重传FIN的话就会有俩部分一是发送FIN的时间二是A接收CK的时间所以需要2MSL的时间

滑动窗口

===================================================================

刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段. 这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候
滑动窗口的本质就是批量传输数据

总的传输时间: N份数据传输的时间叠加成了一份的时间 N份的应答时间叠加成了!份的时间

在这里插入图片描述

体会窗口

就是不等待ACK的情况下批量发送的最大数据就叫"窗口的大小" 比如上面窗口大小就是4000

发送前四个段的时候, 不需要等待任何ACK, 直接发送

体会滑动

一个很形象的比喻就是窗口的范围就表示当前哪些数据在等待ACK 随着ACK的到达就立刻发送下一个范围内的数据包就这样在一个一个的滑动

收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;

操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

窗口越大, 则网络的吞吐率就越高;

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论

数据包已经抵达, ACK被丢了

在这里插入图片描述

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认; 比如上图的主机A,没有收到ACK1001 但是收到了ACK2001 此时主机A就可以判断出是1001的ACK丢失了无所谓数据已经传过去了 (因为如果数据没有传过去的话返回的ACK始终会是1001 不会出现2001这个ACK)

数据包就直接丢了.

在这里插入图片描述

如上图所示

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"一样;

如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送; 这个时候接收端收到了1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了,

被放到了接收端操作系统内核的接收缓冲区中这种机制被称为 “高速重发控制”(也叫 “快重传”)

而且大部分触发重传的时候窗口已经是满的了所以需要等待ACK到了之后才可以继续往后滑动

流量控制

===================================================================

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;

窗口大小字段越大, 说明网络的吞吐量越高;

接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;

发送端接受到这个窗口之后, 就会减慢自己的发送速度;

如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

由上图更能体现窗口的大小是动态变换的~~

好好体会上图可以发现流量控制的本质上就是接收方通过TCP报头中的窗口大小将自己的处理能力和缓冲区剩余空间大小发送给对方来制约发送方发送数据的速率

拥塞控制

===================================================================

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据

在这里插入图片描述

此处引入一个概念程为拥塞窗口最终发送的实际窗口大小 = min(拥塞窗口, 流量控制的窗口)

由上图可知最开的的时候慢开始所以定义拥塞窗口为1 前去探探路

如果正常接收到ACK后就为了能够在短时间内快速接近拥堵情况就让其指数规律快速增长

但是后序又得考虑流量控制所以不能增长的太快就需要引入一个叫做慢启动的阈值

当拥塞窗口的值超过这个阈值的时候就不再按指数增长开始线性增长

一旦出现拥堵(丢包) 拥塞窗口就会一下子回到最初值重复刚才的指数 + 线性增长但是要注意此时指数增长的阈值要比之前小了 (阈值一般就是拥堵情况的窗口大小 / 2)

总而言之因为网络的拥堵情况是瞬息万变的所以窗口的实际大小是动态变化的

延迟应答

===================================================================

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小比如我们举个简单的例子有人前一天晚上问你你明天中午能吃几块的麻辣烫因为你现在不饿你就说了个就几块吧但是呢等到明天中午的时候你就饿了所以你会吃几十块的所以如果你第二天早上回答的话会更准确一点这就是一个延迟应答
在TCP中也会有延时应答

假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;

但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;

在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;

如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M

所以延迟应答的目的就是为了提高效率在流量控制的基础上尽量返回一个合理的而且是又比较大的窗口
一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率那么所有的包都可以延迟应答么? 肯定也不是

数量限制: 每隔N个包就应答一次;

时间限制: 超过最大延迟时间就应答一次

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms

这个时间200ms也很有说法不能影响可靠性的前提下而且这个是必须小于超时重发的时间的

捎带应答

===================================================================

这个是在延时应答的基础上为了进一步提高程序的运行效率而引入的机制如下图

在这里插入图片描述

我们一开始将内核收到数据会立刻返回ACK 但是现在我们引入了延迟应答后我们返回ACK的时间就会往后拖大约200ms 此时这个时间足够让应用程序完成响应的计算所以后序程序在返回RESP的时候就会发现刚才要返回的ACK还没有发呢就会在这个RESP数据报的基础上顺便带上一个ACK的信息
也就是说捎带应答就是因为有延时应答的机制存在将连续发送俩个包的时间在延时的时间范围内的话就会合并成一个包发送去节省快带提高效率
所以说在断开连接的时候有可能合并成三次也正是应为延迟应答和捎带应答
但是注意在连接过程中中间SYN和ACK的合并不是因为这个那是因为接受SYN和发送ACK都是在内核中实现没有涉及到不同的发送时机

面向字节流的粘包问题

=========================================================================

此处注意我的标题是面向字节流的粘包问题所以这个问题不是针对TCP 而是只要涉及到字节流都会有可能发生这个问题