TCP协议详解_flsh can协议-CSDN博客

本文链接：https://blog.csdn.net/qq_45141428/article/details/105067503

在这里插入图片描述

注：

TCP采用了累积确认的方式，这类似于GBN，即如果TCP发送了对某个序号N的确认，则表明在N之前的所有字节流都已经被正确接收。但是另一方面，TCP又不会像GBN协议那样简单丢弃失序到达的报文段，而是会将它们缓存起来，但是这些被缓存的报文段不会逐个被确认。当发生超时时，TCP只会重传发生超时的那一个报文段。
TCP还允许接收方选择性的确认失序到达的分组，而不是累积的对最后一个确认最后一个正确到达的分组，将它与TCP所采取的选择重传结合起来看就很想选择重传协议的工作机制。因此说TCP的差错恢复结合了GBN和选择重传。

在这里插入图片描述

Three way handshake:（建立连接）

Step 1: client host sends TCP SYN segment to server
specifies initial seq #
no data
Step 2: server host receives SYN, replies with SYNACK segment
server allocates buffers
specifies server initial seq. #
Step 3: client receives SYNACK, replies with ACK segment, which may contain data

Closing a connection:

client closes socket: clientSocket.close();

TCP client lifecycle&TCP server lifecycle
在这里插入图片描述

在这里插入图片描述

当网络拥塞时数据报不能及时被转，在分组转发网络中，数据报就会被排队，甚至出现丢包因此说网络拥塞会带来网络销：

慢启动

原理：当连接开始时，指数性增长

加性增—乘性减: AIMD

原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生loss

Additive Increase: 每个RTT将CongWin增大一个MSS——拥塞避免
Multiplicative Decrease: 发生loss后将CongWin减半

注：MSS（Maximum Segment Size）（最大报文段长度）

Q:何时应该指数性增长切换为线性增长(拥塞避免)?
A:当CongWin达到Loss事件前值的1/2时

Threshold变量

Loss事件发生时, Threshold 被设为Loss事件前CongWin 值的1/2。
在这里插入图片描述
Loss事件的处理：

注：3个重复ACKs表示网络还能够传输一些 segments，timeout事件表明拥塞更为严重。

TCP拥塞控制总结

When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.