1.互联网的传输层协议

1.1 分类

互联网（一般是TCP/IP网络）为上层提供两个不同的传输层协议。

1. 用户数据报协议（User Datagram Protocol UDP协议）

2. 传输控制协议(Transmission Control Protocol TCP协议)

1.2 区别

使用UDP和TCP协议的各种网络应用如下所示

注： HTTP1.0和HTTP2.0使用TCP协议 HTTP3.0使用UDP协议

2.复用分用

2.１复用

复用指同一个发送端主机中的多个应用层使用同一个运输层协议传输数据。

2.２分用

分用指在同一个接收端主机传输层剥去报文的首部之后将数据正确的交付给目的应用程序

3. TCP报文段的可靠传输

1. 数据编号和确认 ​ TCP是面向字节的，会将应用层传递下来的报文传递下来的报文切分为报文段，然后看成是一个字节一个字节的字节流，将其用递增的序号编号，在连接开始时，就会确定这个序号的初始值。发送时，TCP报文段首部的ack字段就是期望接收到的字节的序号，也就是在这个序号之前的全部已经确认接收完毕。
2. 字节为单位的滑动窗口 TCP 作为一个传输层协议，最核心的能力是传输。传输需要保证可靠性，还需要控制流速，这两个核心能力均由滑动窗口提供。 滑动窗口的单位为字节。

发送缓存中分为已经发送并收到确认的报文段，滑动窗口部分，不允许发送的报文段。 滑动窗口内的为允许发送的报文段。 当收到报文的确认之后，滑动窗口向右滑动，直到滑动窗口的左侧正好包含确认序号的字节。 然后发送缓存就会将已经发送并确认的字节从缓存中移除，让接下来的数据使用。 在滑动窗口中，系统维护一个发送指针，每发送一个报文段，指针就向前移动一位。当移动到滑动窗口的最右部分，就无法继续发送，必须等待收到之前报文段的确认，滑动窗口向右滑动。 滑动窗口和发送缓存的关系

• 发送窗口只是发送缓存的一部分。已发送但未被确认数据大小<=发送窗口的大小。
• 发送缓存都应该是环形队列，并且是循环使用的。
• 当收到确认之后，滑动窗口左侧会按照确认号滑动到该字节，同时发送缓存也会将发送并成功收到确认的字节从缓存中删除。右侧会按照返回的确认首部中的窗口大小调整到对应的位置。
• 发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存会没有存放数据的空间

滑动窗口和接收缓存的关系

• 滑动窗口只是接收缓存的一部分。
• 接收缓存都应该是环形队列，并且是循环使用的。
• 当收到按序到达的报文段时，滑动窗口左侧向右移动。右侧应该和接收缓存重合
• 当收到未按序到达时，会放入接收窗口中，等待接收正确序号，然后滑动窗口向右移动。
• 当收到的报文段根据首部的检验和计算出发送差错时，会丢弃。
• 当应用程序从接收缓存中读取到已经按序到达的数据之后，接收缓存会将这些数据删除，因为是一个环形队列，所以接收缓存和滑动窗口的右侧都会向右移动读取的字节数。
• 如果接收应用程序来不及读取收到的数据，接收缓存最终会被填满，使接收窗口减少到0
• 如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口可以增大，但最大不能超过接收缓存的大小。

超时重传 ​ 当TCP每发送一个报文段，就会在重传队列中缓存这个报文段的副本，并且设置一个计时器，当收到确认号后会将其从重传队列中移除。当计时器时间到了还没有收到确认，就会重新发送这个报文段。 超时重传的时间选择

• 时间过长：大量的丢失的报文段不会即使的重传，降低传输效率。
• 时间过短： 很多报文还没来的及传输，就会被认为丢失，引起不必要的重传，加大网络负荷。
• 时间计算： ​ 超时重传的时间应该取决于当前报文段的往返时间(Round-trip Time RTT) 稍微长一些。 RTT的计算采用指数加权平均移动算法来计算，得出报文段的平均往返时间RTT(s) ​ 新的RTT(s) = (1-α)*旧的RTT(s) + α * 上一个RTT(s) （典型的α取1/8） ​ 超时重传时间(Retransmission Time-Out RTO )应当略大于上边的RTT(s)即可。

1. 快速重传 ​ 快速重传是对超时重传的一种补充 ​ 当超时重传的时间设置过长的时候，发送方并不会马上知道需要重新发送，因此，接收方在接收到后续的报文段而没有收到之前的某个报文段的时候，会将之前没收到的报文段的开始需要放入后续报文段的确认号中，当发送方一连接收到3个同样的确认号时，认为这个报文段已经丢失，立即重新发送。
2. 选择确认 如上快速重传中所示，后续的报文段接收方已经收到了，但是发送方并不知道，他们的确认中填写的是之前没有收到的报文段的序号，所以，这些已经收到的报文段会等超时之后再次发送，选择确认可以解决这个问题。通过报文段中的选项字段添加SACK字段，存放已经收到的报文段的字节开始序号和结束序号。

4.流量控制

​ 接收窗口的大小可以用来控制 TCP 协议的流速。这样，就可以避免发送方发送太快而接收方的接收缓存溢出的问题。

具体实现：

​ 发送端的发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。发送方收到的确认中的窗口大小是接收方的滑动窗口大小。发送方的滑动窗口必须小于等于这个值。接收方根据自己的接收能力控制发送方的发送速率。因此，流量控制是一个速度匹配服务，可以保证发送方的发送速率和接收方的程序的读取速率保持一致。

这种由接收方来控制发送方的做法，在计算机网路中经常使用。

窗口探测

当应用程序读取速度过慢，导致接收缓存中全部均为按序到达需要读取时，接收窗口大小被挤压为0，此时，返回给发送方的确认首部窗口大小为0，则发送方的滑动窗口的右侧会和左侧重叠，发送方的滑动窗口也变为0。发送方会一直等下去。为避免发生这种死锁状态，发送方会周期性（默认为60s）的发送一个字节数据的窗口探测报文段，以便强制接收方返回即时的窗口大小。当此时发送方的接收窗口依然为0，则接收方会丢弃这个字节并重复以前的数据进行确认。如果此时窗口大小不为0，则收到这个窗口探测的一个字节的数据并返回发送方确认消息。

综上所述，TCP的流量控制协议实现了发送应用程序的发送速率和接收应用程序的接受速率的匹配。