TCP可靠传输

1.确认应答机制

2.超时重传机制

3.滑动窗口机制

4.拥塞控制机制

    慢启动 拥塞避免 快重传 快恢复

5.捎带应答机制

6.延时应答机制

 

确认应答机制

    1.当发送方发送一个报文数据的时候，需要带上序号，当接收方接收到这个报文数据时，需要对该报文进行确认

    2.确认做法，给发送发发送一个确认报文，而确认报文当中的确认序号是告诉发送方，期待下一个序号是多少

超时重传机制

    当消息发送方。发送一条消息后，就会开启一个重传计时器，用来计算消息发出去的时间，当消息发送出去的时间大于RTO的时候，还没有收到确认报文，则重传报文。

    不论是数据丢失，还是接收方发送的确认报文丢失，对于消息发送方而言，都没有收到确认报文，所以会在RTO时间之后进行重传

    RTO = 超时重传时间，动态计算

    RTO = 2* RTT

    RTT：报文往返时间，从发送开始计算，知道收到确认应答，所经历的时间被称为报文往返时间

    预测下次发送RTT = RTT（cur）*i + RTT (prev)*(1-i)  TCP默认情况下i=0.9

 

滑动窗口机制

    1.窗口：已经被发送到网络上，但是还没有完成确认的分组的集合

     不必让发送方等待一个报文确认到达后再发送下一个报文，而是，允许发送方发送多个分组的报文到网络上，会提高发送的效率

    2.分组

     TCP在发送数据时候，都有一个起始序号得，，分组就是TCP发送数据流序号的集合

    1.窗口：已经被发送到网络上，但是还没有完成确认的分组的集合

    2.对于TCP通信双放都维护了一对窗口，即发送窗口+接收窗口

    3.滑动窗口传输层TCP协议进行流量控制得一种手段，对于接收双方而言，通告发送自己的可以接收得缓冲区大小，以此来控制发送方发送数据的大小，从而达到流量控制的目的

    4.滑动窗口当中的数据暂时不要确认，直接发送到网络上，窗口向前滑动的时候，意味着接收到了序号较小的分组的确认数据包，窗口向右滑动，发送新的内容

    5.滑动窗口发送方丢丢包必须重传

    6.滑动窗口接收端丢失ACK，针对发送，如果接收端回复的ACK丢失，但是我们在发送端接收到丢失序号更大的确认信号之后，则接收端不需要重传

 

拥塞重传机制

    慢启动，拥塞避免，快重传、快恢复

慢启动

    1.当双方建立连接之后，一开始不要发送大量的数据，而是先发送少量的数据，探测网络拥塞程度，当网络情况较好的情况下，逐渐增大发送数据量

    2.拥塞窗口：cwnd

    3.慢开始门限

    慢开始算法：随着传输轮次增加，拥塞窗口的大小指数增长  

    当cwnd < ssthresh,执行满开始算法

    当swnd == ssthresh,既可以使用慢开始算法，也可以使用阻塞避免算法

    当cwnd > ssthresh,执行阻塞避免算法

    4.阻塞避免算法：拥有窗口大小随着传输轮次增加，呈线性增长。

    注意：a.窗口大小决定可以往网络上发送多少字节，并不决定每次发送多少字节

               b.MSS：最大报文段长度，决定传输层TCP协议每次给网络提交多少数据

               c.MTU：数据链路层对数据帧限制大小

               d.MTU = 网络层ip头部 + 传输层TCP头部 + MSS

    快重传

    

    1.当接收方发现丢失了一个报文（接收方收到了比丢失报文序号更大的报文了），每收到一个大于丢失报文序号的报文段的时候，就会发出重复确认，发出重复确认的本质是为了告诉发送方，接收方丢失了一个报文。

    2.在发送方接收到3个重复确认报文后，就会重传丢失的报文段，而不需要等待RTO的时间

    快恢复

    

    1.如果网络阻塞导致发送方发送给接收方的报文的时候，丢失某个TCP报文，就会发出三个重复确认包，而发送方随机重传报文之后进入快恢复阶段

    2.设置新的慢开始门限，新的慢开始门限 = 拥塞窗口/2；

    3.将拥塞窗口大小设置为新的慢开始门限

    4.执行拥塞避免算法

 

 

捎带应答机制

    

    1.对于TCP通信双方而言，每一方都要发送给对方发送数据，为了减少网络当中的ACK确认数量包，双方在发送数据的时候，捎带对刚刚发送的数据进行确认

    2.PSH+ACK--》TCP报头当中 序号+确认序号+PSH标志位+ACK标志位

 

 

延时应答机制

    

    1.同样也是为了减少网络当中数据包的数据量，防止网络拥塞

    2.接收方收到数据之后，等待一段时间（200ms），再给发送方回复确认包；为了是在等待这段时间内，应用层将数据读走，从而在回复确认包时告诉发送方，接收方有更大的接收能力。

 

保活计时器

    1.保证TCP连接是正常的

    2.产生背景：当前这个连接已经两个小时没有产生数据了，则发送保活探测包。

    3.每隔75s发送一个保活探测包，连续发送十次，如果十次都没有收到确认，则认为连接异常，需要断开连接

    4.保活计时器只要收到数据，就会重置，从零开开始计时。

 

面向字节流

    字节流：数据和数据之间没有明显边界

    针对应用层程序：可以接收任意大小的数据

    带来粘包问题