TCP 传输控制协议

目录

可靠机制（5可靠）

1.确认应答机制

2.超时重传机制

3.连接管理机制

建立连接-》三次握手

断开连接-》四次挥手

第2，3个数据报为啥没有合并?

第2，3个数据报是否可以合并?(了解)

服务端出现大量的close_wait，原因?

为什么要四次挥手

4.流量控制机制

5.拥塞控制

效率机制

1.滑动窗口

2.延迟应答

3.捎带应答机制

---

tcp协议是一个可靠与效率均衡都协议

可靠机制（5可靠）

1.确认应答机制

发送的数据，接收端需要返回确认接收到数据报的应答TCP将每个字节的数据都进行了编号。即为序列号。

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

TCP 发送端发送数据包的时候会选择一个 seq 序列号，接收端收到数

据包后会检测数据包的完整性，如果检测通过会响应一个 ack 确认号表示收到了数据包

2.超时重传机制

发送端超过一定的时限，没有接收到ack应答包，就会进行重传

可能丢包:(1)发送数据丢包(2) ack应答包丢包

时限是动态变化的:跟网络环境（网速)有关

了解:成指数级增长，重传到达一定的次数，就表示对方出现异常，关闭连接

TCP 发送端发送了数据包后会启动一个定时器，如果一定时间没有收到接受端的确认后，将会重新发送该数据包。

3.连接管理机制

建立连接-》三次握手

建立连接:本质是双方保存了一个连接状态（连接状态，是有方向的）

(1）客户端发送syn =>申请建立客户端到服务端的连接seq

(2）服务端返回syn+ack =>申请建立服务端到客户端的连接并对第一个数据报的应答seq

syn和ack可以合并一起发送，也可以分开发

(—个数据报，两个标志位置为1)

(3)客户端返回ack =>对第二个数据报syn的应答

可以两次握手吗-》不可以

从三次握手的过程可以看出如果只有两次握手，那么客户端的起始序列号可以确认，服务端的起始序列号将得不到确认。

断开连接-》四次挥手

流程:

(1）客户端发送fin到服务端:申请关闭客户端到服务端的连接

(2)服务端返回ack=>服务端状态置为close_wait

(3）服务端发送fin到客户端:申请关闭服务端到客户端的连接=>客户端接收到，状态置为time_wait

(4）客户端返回ack=>服务端状态置为closed(已关闭)

=>客户端等待一定时间，状态置为closed(已关闭)

注意：第4个数据报，可能出现丢包(服务端无法断开连接)服务端就会根据超时重传机制，重发第3个数据报此时客户端如果是closed，就没法接收了！

第2，3个数据报为啥没有合并?

第2个数据报，是系统内核返回的(不用程序写代码来发送)

第3个数据报，是程序调用close方法发送的服务端在关闭连接前，可能需要做一些其他工作

第2，3个数据报是否可以合并?(了解)

先放在缓冲区(可能是立即发，也可能不是)=>对应的，第三个数据报也是发送到缓冲区

此时，如果第二个数据报还在缓冲区，就可能合并发送

服务端出现大量的close_wait，原因?

服务端没有执行close方法(因为执行close才会发送第3个数据报)

客户端接收第3个数据报，状态是time_wait，需要等待多久? => 2msl(了解)MSL是TCP报文的最大生存时间。就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失。

1个msl是，单个报文传输的最大时间，需要等待的，就是第4次返回，及可能的重传数据（第3次)

为什么要closewait=》如果直接close，那么服务端无法向客户端申请关闭连接

为什么要四次挥手

当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B发出的数据；B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向A 发送数据

4.流量控制机制

背景:发送端发送速度如果快于接收端，程度读取速度，就可能导致接收缓冲区被打满，进而引起一系统丢包，重传再次丢包的问题

tcp协议首部:

16位窗口大小—流量窗口大小

接收端接收能力有限，主动的告诉发送端，自己的接收能力

接收端:接收缓冲区，剩余空间大小=>返回的ack应答包，还会使用“窗口大小”字段来设置这个值

为了防止发送端发送数据的速度太快导致接收端缓冲区溢出，发送端只能发送接收端可以接纳的数据，为了达到这种控制效果，TCP 用了流量控制协议（可变大小的滑动窗口协议）来实现

5.拥塞控制

背景:网络状态不明的情况下，贸然发送大量的数据报，就可能产生网络拥塞。发送方收不到回复的ack，会重新传输这个数据包

拥塞控制的方法

1、 慢启动 + 拥塞避免

慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;

拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这

样拥塞窗口按线性规律缓慢增长。

指数增长阶段称之为慢启动，线性增长阶段称之为拥塞避免

2、快重传 + 快恢复：

快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对

方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大

小，然后执行拥塞避免算法。

效率机制

1.滑动窗口

作用:以并行的方式发送数据报，减少等待时间，提高效率

窗口大小:无需等待确认应答，而可以继续发送的数据报最大值

如何确定?

滑动窗口大小= min(流量窗口大小，拥塞窗口大小)→决定吞吐率（一定时间，网络数据传输的数量越大，吞吐率就越高)

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

发生丢包的情况:

(1) ack丢包:没影响，后续的ack也能表示序号前的全部接收

(2）发送的数据报丢包:

接收的ack下一个序号，是接收端，接收到的连续序号最大值+1妳(如果中间有部分没接收到，就相当于不连续)快重传:连续3次接收到下一个是x，就表示从x开始的数据报丢包，需要重传

2.延迟应答

背景:接收端返回的流量窗口大小代表接收缓冲区的可用空间大小，如果立即返回，就不划算﹐（(立即返回的流量窗口大小就会比较小)接收端可能接收速度还是比较快，读走以后就可以设置的更大）

接收端返回的流量窗口，不是立即返回，而是等待一定时间（延迟应答的由来），这样返回的流量窗口大小就可能更大

流量窗口大小，是滑动窗口大小的决定因素之一而滑动窗口大小又是网络吞吐量的决定因素之一

所以是效率机制——延迟一定时间应答，效率就更高

了解:延迟的条件由数量和时间来限制

不能超过最大的延迟时间——超过时间，发送端就认为丢包，会进行超时重传

3.捎带应答机制

背景:不管是客户端还是服务端，每一端，即可以是发送端，也可以是接收端

不管客户端还是服务端，接收到数据后，返回的ack应答包（作为接收端)，可以和发送的数据报（作为发送端）合并再一起(捎带的方式)发送给对方