Java TCP协议(2)

TCP可靠传输

五. 流量控制

用来控制发送方的窗口大小,通过接收方返回来的ACK进行反制。

接收方把自己能够处理的数据量主动告诉发送方,从而让发送方动态调整窗口大小。

如果窗口大小为0表示没有空间去接收数据了,主机A就不发数据了,导致主机B就没有后续的ACK了,也就意味着双发停止通讯了。

过了重发超时以后若还没有收到窗口更新的通知,发送端会发送一个窗口探测的包,窗口探测不携带具体的数据,只是问一下接收方,现在是否可以处理数据,能处理多少。

六. 拥塞控制

通过网络的畅通程度来控制窗口大小。

发送数据时,由于会经过很多网络设置,而网络情况是不固定的。

所以,在数据传输的过程中可能会造成阻塞和超时。

1.程序启动的时候把拥塞窗口的值调到很少,比如1,

2.如果接收到ACK表示当前窗口大小没有问题,然后就调大窗口大小

3.到达阈值之前以指数形式增大,到达阈值之后,以1为步长进行增大

4.当增大到一定程序发生丢包的情况,就证明网络阻塞了,这时就把窗口大小重新调用1,同时重置新的阈值=当前窗口大小的二分之一

拥塞窗口大小与ACK应答中的窗口大小共同决定发送的滑动窗口大小,哪个小用哪个。

七. 延迟应答

TCP在应答时,并不是每收到一个请求应答一次,而是每隔几个应答一次 。

及时应答的时候,窗口大小是缓冲区剩余的空间。

延迟应答时,应用程序还要从缓冲区中取走一部分数据,这时缓冲区的剩余部分就变大了,ACK时窗口大小就可以设置更大的值,最终发送方就会按这个值去增大发送窗口。

八. 捎带应答

由于TCP是全双工,接收方也可以给发送方做一个响应操作。

当主机A发送响应数据时,如果有ACK需要返回,那么这两个报文就有可能被合并成一个,减少了通讯次数,提升了效率。

相关推荐
鶴哥只手遮天6 小时前
Spring AI 2.0.1 深度解析-第 14 章 MCP 服务端(上):注解式实现与工具来源
java·人工智能·开源
鶴哥只手遮天6 小时前
Spring AI 2.0.1 深度解析-第 15 章 MCP 服务端(下):三种协议形态、Streamable 传输与状态管理
java·人工智能·开源
鶴哥只手遮天6 小时前
Spring AI 2.0.1 深度解析-第 16 章 向量存储(上):`VectorStore` 接口体系、`BatchingStrategy`
java·人工智能·开源
鶴哥只手遮天6 小时前
Spring AI 2.0.1 深度解析-第 12 章 工具循环的流式形态、Usage 累加与扩展体系
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 23 章 模型供应商实现:从 `OpenAiSetup` 到 Bedrock
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 06 章 内置 Advisor 全景:13 个实现逐个剖到源码级
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 03 章 消息体系与 Prompt:不可变模型、`ChatOptions` 与模板渲染
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 24 章 生产实践与 2.x 迁移:陷阱清单、AOT 与调优
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 10 章 工具调用(中):执行链路、结果转换与工具限制
java·人工智能·开源
鶴哥只手遮天7 小时前
Spring AI 2.0.1 深度解析-第 13 章 MCP 客户端:传输、工具聚合与命名冲突
java·人工智能·开源