标签：java 重传 22 TCP 发送 分组 课后 窗口 字节
五、TCP协议
1、基本特点
-
TCP 是面向连接的传输层协议，UDP面向无连接
-
每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一）
-
TCP 提供可靠交付的服务（持续交付）
-
TCP 提供全双工通信（信道双向传输）
-
面向字节流(传送最小单位为字节，即八位)
上图可以看出TCP传输是如何面向字节流的，具体细节后面继续解析
2、TCP连接基于Socket
-
TCP 把连接作为最基本的抽象，每一条 TCP 连接有两个端点
-
TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是传输层的协议端口。TCP 连接的端点叫做套接字(socket)
-
IP地址+服务端口构成了套接字
3、TCP协议确保可靠传输
TCP使用自动重传请求ARQ (Automatic Repeat reQuest)确保可靠传输
停止等待机制:
报文过不了检验的，被B丢弃，A发送发出去的报文无回应、重新发送
请注意：
-
在发送完一个分组后，必须暂时保留已发送的分组的副本，方便重传
-
分组和确认分组都必须进行编号
-
超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些
4、确认丢失和确认迟到机制
确认丢失机制将超时的包覆盖为超时重传的包
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
ARQ 表明重传的请求是自动进行的
5、TCP流水线传输
停止等待协议的优点是简单，但缺点是信道利用率太低
改进:
发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认，由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率
6、连续 ARQ 协议(自动重传协议)
连续ARQ（Automatic Repeat reQuest）协议指发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有分组都可连续发送出去，而中途不需要等待对方的确认。这样信道的利用率就提高了。而发送方每收到一个确认就把发送窗口向前滑动一个分组的位置
接收方一般都是采用积累确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了
积累确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息
例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只是对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。
7、TCP 报文段的首部格式
-
源端口和目的端口字段各占 2 字节(16位)，源端口指发送端相关服务端口，目的端口是目标主机相关服务，端口是传输层与应用层的服务接口，传输层的复用和分用功能都要通过端口才能实现。
-
序号：当前数据组的第一个字节在整个文件中的序号
-
确认号ack：接收端发送，提示发送端下一次该发的数据在整个文件中的序号（收发连续的话就是序号+1），接收端收到后，会把这个序号之前的数据从缓存中删掉
-
数据偏移：指明当前TCP报文段第多少个字节后是TCP的数据部分了，数据偏移最多表示1111，即15，他最多可以表示15乘以4，即60个字节的偏移量，所以选项+填充最多只能是40个字节
-
保留：就是保留，没有用的
-
URG：urgent，意思是优先级高，发送端优先发送，而不是在缓存中排队
-
ACK：acknowledge，1意味着确认正式建立了会话
-
PSH：1意味着接收端优先读取，而不是在缓存中排队
-
RST：reset，1意味着TCP会话出现严重错误，必须释放和重新连接，比如你打开网页又立马将之关掉了，那么接收方也不用再给你传输网页信息了
-
SYN：同步，1意味着要发起会话
-
FIN：finish，1意味着释放连接
-
窗口：同步接收端和发送端窗口大小的，接收端先发，发送端根据接收端的窗口尺寸确定发送端窗口尺寸
-
检验和：略，上已讲
-
紧急指针：只有URG为1才有用
8、滑动窗口
（1）TCP 可靠通信的具体实现：
-
TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口
-
TCP 的可靠传输机制用字节的序号进行控制
-
TCP 两端的四个窗口经常处于动态变化之中
-
TCP连接的往返时间 RTT 也不是固定不变的，需要使用特定的算法估算较为合理的重传时间
（2）窗口动态变化-以字节为单位的滑动窗口：
-
A的发送窗口是由B的接受窗口长度决定的
-
在没有收到B确认收到之前，A不能删掉滑动窗口内的内容
-
A可以持续给B发送，直到A的滑动窗口内数据都发送成功
-
B收到后给A发确认收到的反馈ack（下一个应该发送的字节的序号），A收到后，就可以滑动窗口到对应的位置。例如B反馈ack是7，那么A的滑窗可以移动到7位置，1-6删除，21-26可以继续发送
相关名词：
P3 – P1 = A 的发送窗口（又称为通知窗口）
P2 – P1 = 已发送但尚未收到确认的字节数
P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口）
9、 TCP流量控制
流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制，收方返回的 rwnd中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送，发送方在rwnd窗口之后的数据不允许发送
流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面
死锁解决：
接收方返回窗口大小为0，可能是缓冲区已满，需要处理缓存中的字节，发送端收到滑动窗口为0，不再发送，但是数据还没发送完，这就造成了死锁
如果在某个时候，接收方缓冲区有空间了，于是发送了一个非 0 窗口的通告给接收方，不幸的是这个通告丢失了，而发送方却还在死等接收方的非 0 窗口通告，接下来就成了死锁
TCP 为每一个连接设有一个持续计时器
若持续计时器设置的时间到期，就周期性的向接收方发送 1 字节的 0 窗口探测报文
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器，等待重传
若窗口不是零，则死锁的僵局就可以打破了
六、三次握手齐白首
传输连接有三个阶段，即：连接建立（三次握手）、数据传送和连接释放（四次挥手）
头两次握手除了确定双方都能联通外，还通知了双方的一些端口信息
A：我们谈恋爱吧
标签：java,重传,22,TCP,发送,分组,课后,窗口,字节 来源： https://blog.csdn.net/m0_65483413/article/details/122218636
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。