赞
踩
目录
TCP 状态和“线程状态”是类似的概念,用于描述 TCP 连接过程中正在执行什么操作。
TCP 服务器和客户端都有一定的数据结构来保存连接信息,而这个数据结构中有一个属性叫“状态”,操作系统内核根据状态的不同,决定当前应该执行什么操作。
- LISTEN 状态表示服务器创建好了 serverSocket,并且绑定客户端完成,等待客户端 new Socket 进行三次握手连接。
- ESTABLISHED 状态表示连接已经建立完毕,三次握手完成。图中的两个 ESTABLISHED 状态可以认为是几乎同时进入。
- CLOSE_WAIT 表示收到对方发送过来的 fin,接下来的代码中需要调用 close 来主动返回 fin,由于关闭速度 socket 非常快,该状态不太容易被察觉到。【谁被动断开连接,谁进入 CLOSE_WAIT】
- TIME_WAIT 表示本端给对方发起 fin 之后,对方也给返回了 fin,该状态存在的意义是给最后一个 ack 重传留有一定时间,防止最后一个 ack 丢包,只要该状态还存在,就依然会保存对端的信息,才能为连接提供各种操作(包括返回 ack )。【谁主动断开连接,谁进入 TIME_WAIT】
需要注意的是:TIME_WAIT 也不会无休止的等待,最多等待 2 MSL(MSL 是系统内核的配置项,表示客户端到服务器之间,允许消耗的最长时间),一旦超过这个时间,就再也不会发送 ack 了。
滑动窗口时是 TCP 中非常有特点的机制。
正常的确认应答机制下,每次发送放收到一个 ack 后才会发送下一个数据,导致大量的时间都消耗在等 ack 上。
而滑动窗口就可以在保证可靠性传输的基础上,提高效率(减少损失的速度,而不是增加速度),通过批量传输,把多次请求的等待时间,使用同一份时间来等,减少了总的等待时间。
例如:此时批量4个数据,对应4个 ack,这4个 ack 到达的时间各异,此时不需要等所有 ack 都到达,只要有一个 ack到达,就发送下一个数据,不需要管 ack 的顺序。
当采用滑动窗口的策略时,如果出现丢包,如何进行重传?这里分两种情况讨论:
1、ack 丢了
这种情况下, 部分 ack 丢了并不要紧,对可靠性没有影响,不需要进行重传,因为可以通过后续的 ack 进行确认。2、数据丢了
数据丢了必然需要重传。 上述重传的过程中,整体的效率是非常高的,因为这里的重传做到了“针对性”重传,不会有重复发送,整体的效率没有额外的损失,这种重传称为“快速重传”。
TCP 有接收缓冲区(生产者消费者模型),发送的数据先放到缓冲区里排队,当发现缓冲区中的数据不连续时证明数据丢失,就会重传对应的数据,待数据补齐后再继续接收后面的数据。
滑动窗口的窗口大小不能无限大,如果窗口过大导致发送速度大于接收方的处理速度(导致接收缓冲区满了),就会出现丢包问题,进而影响了 TCP 的可靠传输。【任何提升效率的行为都不应该影响到可靠性】
为了让发送速度与处理速度保持步调一致,就需要根据接收方的处理能力反过来影响发送方的发送速率,称为“流量控制”。通过这个字段来给发送方反馈发送速度。该字段在普通报文中无意义,在 ack 报文中才有意义。接收方会按照自身接收缓冲区的剩余空间大小(又称为“接收窗口”)作为 ack 中窗口大小的数值,发送方就能根据该数值调整窗口大小。
当接收窗口逐渐较少,直至到 0 后,此时接收方的接收缓存区已满,发送方将停止发送。然后发送方会周期性发送窗口探测包(不携带载荷),用于查询窗口大小,当查询到窗口大小不为 0 时继续发送。
JVM 的垃圾回收机制以及垃圾回收算法的详解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136530845?spm=1001.2014.3001.5501对 JVM 的类加载机制以及寻找字节码文件的“双亲委派模型”的理解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136529700?spm=1001.2014.3001.5501【网络编程】理解客户端和服务器并使用Java提供的api实现回显服务器-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136322678?spm=1001.2014.3001.5501
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。