计算机网络 TCP的数据传输
01.先看TCP特点
- ②TCP协议:
- 必须建立连接,形成传输数据的通道
- 在连接中可进行大数据量传输
- 通过三次握手完成连接,是可靠协议
- 必须建立连接,效率会稍低
- 那么你知道为tcp如何保证传输是可靠的,为何效率会低一些?
02.如何保证可靠传输
- TCP 协议如何保证可靠传输
- 1.应用数据被分割成 TCP 认为最适合发送的数据块。
- 2.TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
- 3.校验和: TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
- 4.TCP 的接收端会丢弃重复的数据。
- 5.流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 (TCP 利用滑动窗口实现流量控制)
- 6.拥塞控制: 当网络拥塞时,减少数据的发送。
- 7.停止等待协议 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
03.TCP流量控制
- 流量控制指点对点通信量的控制,是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。这里是通过滑动窗口机制来实现的。发送方的发送窗口不能超过接收方的接收窗口。TCP的窗口单位是字节,不是报文段。
- 这上图中B一共进行了三次流量控制:第一次将窗口减小到
300
,第二次减小到100
,最后减小到0
,这时发送方暂停发送知道B发送一个新的窗口值为止。 - 如果B发送了一个新的窗口值到A,但是A并没有收到,就会造成死锁。为解决这个问题,TCP为每个链接设置有一个持续计时器。只要TCP收到一个0窗口,就启动计时器。若计时器设置的时间到了,就发送一个探测报文,而接收方在确认的时候会给出一个现在的窗口值。
- 这上图中B一共进行了三次流量控制:第一次将窗口减小到
04.TCP拥塞控制
- 防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提:网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机、路由器,以及与降低网络传输性能有关的所有因素。
4.1 慢开始和拥塞避免
- 发送方维持一个拥塞窗口
cwnd
的状态变量。发送方让自己的发送窗口小于等于拥塞窗口。 慢开始
:由小到大的逐渐增大拥塞窗口。首先将cwnd设置为一个最大报文段MMS,在收到一个对新的报文段的确认后,把拥塞窗口增加一个MMS。——指数增长拥塞避免
:当慢开始到门限值(ssthresh)后,使用拥塞避免算法(cwnd每次加1)。当发现网络拥塞后,将cwnd置为1,ssthresh减半,再次执行慢开始。
4.2 快重传和快恢复
快重传
:当接收方收到一个失序报文段后就立即发送重复确认而不要等到自己发送数据时捎带确认。当发送方连续收到三个重复确认时,应立即重传接收方尚未收到的报文段。快恢复
:与快重传结合使用。- 在连续收到三个重复确认时,将慢开始的ssthresh减半,这是为了防止网络拥塞( ** 接下来并不执行慢开始 ** )。
- 由于发送方现在认为 网络很可能没有拥塞,于是接下来不执行慢开始,而是将cwnd值设置为ssthresh减半后的值,然后执行拥塞避免。
05.停止等待协议
5.1 无差错情况
- 发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
5.2 出现差错情况
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。
5.3 确认丢失和确认迟到
确认丢失:确认消息在传输过程丢失
- 当A发送M1消息,B收到后,B向A发送了一个M1确认消息,但却在传输过程中丢失。而A并不知道,在超时计时过后,A重传M1消息,B再次收到该消息后采取以下两点措施:
- 1.丢弃这个重复的M1消息,不向上层交付。
- 2.向A发送确认消息。(不会认为已经发送过了,就不再发送。A能重传,就证明B的确认消息丢失)。
确认迟到 :确认消息在传输过程中迟到
- A发送M1消息,B收到并发送确认。在超时时间内没有收到确认消息,A重传M1消息,B仍然收到并继续发送确认消息(B收到了2份M1)。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会,A收到了B第一次发送的对M1的确认消息(A也收到了2份确认消息)。处理如下:
- 1.A收到重复的确认后,直接丢弃。
- 2.B收到重复的M1后,也直接丢弃重复的M1。
06.传输伪代码
6.1 客户端发送数据
1 | /** |
6.2 服务端接收数据
1 | /** |