传输层（二）

本文主要总结了关于TCP协议的可靠传输以及面向字节流的特性以及注意事项；重点在于关于TCP保证数据可靠传输所制定的一些机制，以及粘包问题；
一.TCP可靠传输：
TCP可靠传输：-------------------保证数据的可靠到达；
在应用层进行数据传输时，TCP协议负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地；
如何才能进行可靠传输？？？？---------TCP协议中推出了一些机制来进行管理；
1.关于序列号：
（1）序列号：TCP会对每个字节的数据进行编号，数据的编号就是数据的序列号，每个字节都有自己的序列号；
（2）作用：在网络中标识一个通信；接收端为了区别重复的报文段，接收端有时会收到很多重复的数据；TCP协议就需要能够识别出那些是重复的包，并且把重复的丢掉，此时就需要使用序列号，来实现去重；
2.确认应答机制：（ACK机制）
（1）概念：当接收方收到一条报文后，向发送端发送一条确认ACK，此ACK的作用就是告诉发送端：接收端已经成功的收到了消息，并且希望收到下一条报文的序列号是什么；
（2）为什么需要确认应答机制？？？
原理图如下：


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

在TCP建立连接后，发送的每条数据都有可能丢失，确认应答机制的作用就是保证发送的数据是什么，是否接收到；以此来保证数据的完整性；
（3）确认应答机制的作用：来确认接收端收到数据了可以知道收到的是哪一条数据；

3.超时重传机制：
（1）什么是超时重传机制： TCP每发送一个报文段，就会对这个报文段设置一次计时器，只要计时器设置的重传时间到，但发送端还没有收到接收端发来的确认，此时就会重传此报文段；超时重传机制是内核实现的，因为超时重传机制是TCP的一部分，而TCP又属于内核，所以超时重传机制也就是内核实现的；
（2）引发超时重传的原因有以下两种情况：
主机1发送数据给主机2后，因为网络拥堵等原因，没有在规定时间内数据到达主机2；因此由于主机1没有收到主机2的确认应答信息，就会进行重发；（如下图所示）

主机1没有收到主机2的确认应答信息，也可能是因为ACK的丢失：（如下图所示）

因此主机2会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉；这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果；

（3）超时重传机制的作用：保证传输数据的安全达到；
（4）超时的时间该如何确定？？？
最理想的情况下，找到一个最小的时间，保证“确认应答一定能在这个时间内返回”；但是这个时间的长短，会随着网络环境的不同，会有差异；如果超时时间设置的太长，会影响整体的重传效率，但是如果时间设置的太短，有可能会频繁的发送重复的包；

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个大超时时间；

Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制；每次判定超时重发的超时时间都是500ms的整数倍；如果重发一次之后，仍然得不到应答，等待 2500ms 后再进行重传；如果仍然得不到应答，等待 4500ms 进行重传；依次类推, 以指数形式递增。累计到一定的重传次数, TCP认为网络或者对端主机出现异常，强制关闭连接；

因为TCP为了实现可靠传输，因此牺牲了部分可靠传输性能；但是因为ACK的丢失而导致重传，性能降低就不划算了，因此又推出了多种机制避免进一步的性能降低：

4.滑动窗口机制：
在之前我们刚才讨论了确认应答策略，对于每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段；这样做有一个比较大的缺点，就是性能较差；尤其是数据往返的时间较长的时候；

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)；-------滑动窗口机制；
（1）滑动窗口机制的概念： 滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的数据帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的数据帧的序号，称为接收窗口；通过协议字段的大小双方进行协商，一次可以最多传输多少条数据，之后然后等待确认应答，不需要进行停等；通过两个指针来维护窗口的前言和后言；

原理图如下所示：

TCP通过双方协商窗口大小进行流量控制，避免因缓冲区数据塞满而大量丢包；窗口大小指的是无需等待确认应答而可以继续发送数据的最大值；上图的窗口大小就是个字节(四个段)；发送前四个段的时候, 不需要等待任何ACK, 直接发送; 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;

操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉; 窗口越大, 则网络的吞吐率就越高;

**发送端：**发送的起始位置—后沿，发送的结束位置—前沿；若窗口中后沿数据没有接收到ACK的确认，并且后沿不能向前移动，数据就不能从缓冲区移除；当接收到ACK的确认后窗口前后沿向后移动向后；

**接收端：**接收数据的起始位置—后沿，接收的结束位置—前沿；当接收数据时，当没有接收到第一条数据，则后沿不能移动，只有接收到第一条数据后，后沿才能进行移动；

（2）滑动窗口中的快速重传机制：
前提条件：每条数据的确认回复都必须按序回复；若前边的数据没有收到，则不会对后面的数据进行回复；因为此时处于乱序的状态；这就意味着若接受到一条回复，表示ACK确认序号之前的数据已经全部安全到达，不会因为前面数据的ACK丢失而重传；

ACK确认丢失情况：
滑动窗口机制规定在数据传输过程中，每条数据都要进行回复，并且应该按序进行逐条回复；如果没有收到第一条，但是收到第二条，第二条就不能进行回复，应该先回复第一条；带来的好处就是如果第一条ACK丢失后，如果发送端收到的是第二条回复，也会认为第一条接收成功，第一条就不需要重传------提高了丢包情况下的传输性能；

数据丢失情况：
当数据连续发送n条，但第一条数据丢失，接收端先接收到第二条数据，这时候接收端会认为第一条数据可能丢失；因此直接向发送端发送一条数据重传请求，连续发送三次（防止网络延时又接收到数据报）；当发送端连续发送三次数据传输请求，则会对数据进行重传；

（3）滑动窗口的拥塞控制机制： 慢启动，块增长；
滑动窗口机制通过窗口的大小来确定连续发送多条数据，一开始通信的时候不了解网络的状态；有可能造成发的越多，丢的越多；超时重传就越多，降低效率；因此采用滑动窗口的控制拥塞机制；

滑动窗口的控制拥塞机制是指发送端控制一个拥塞窗口的大小，在进行数据传输的时候，进行网络探测式的发送；若网络状态良好则发送的数据快速增长，达到阈值时，不在继续增长；若传输过程中出现丢包，则重新初始化拥塞窗口；

作用：拥塞控制为了避免因为网络状态不好导致通信初始大量的数据包丢失重传，降低性能；

5.延迟应答机制：
接收方收到数据后并不会立即进行确认回复，而是等待一段时间；因为这段延迟时间内，有可能用户已经recv将缓冲区的数据取走，窗口就可以将可能保证最大大小；保证传输的吞吐量；

应答机制原理：
如果接收数据的主机立刻返回ACK应答， 这时候返回的窗口可能比较小；
假设接收端缓冲区为1M，一次收到了500K的数据；如果立刻应答， 返回的窗口就是500K； 但实际上可能处理端处理的速度很快， 10ms之内就把500K数据从缓冲区消费掉了；
在这种情况下，接收端处理还远没有达到自己的极限， 即使窗口再放大一些， 也能处理过来； 如果接收端稍微等一会再应答， 比如等待200ms再应答， 那么这个时候返回的窗口大小就是1M；

窗口越大， 网络吞吐量就越大， 传输效率就越高； 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；

6.捎带应答机制：
虽然有延迟应答，但是客户端和服务器在应用层还是还是”一发一收”，此时就会导致数据传输效率低下，捎带应答就是接收端在给发送端发送数据的时候，捎带着向发送端发去确认应答，应答的内容是接收端已经收到发送端发送的数据；

使用捎带应答之前：
客户端：你好吗？
服务器：我收到你发的消息了（接收端的ACK应答）
服务器：我很好

使用捎带应答之后：
客户端：你好吗？
服务器：我很好（接收端给发送端发送的数据），我也收到你发的消息了（接收端的ACK应答）

二.面向字节流： 传输字节流；
1.传输字节流原理：发送方每次调用send都会将数据发送到数据缓冲区，然后内核选择合适时机发送数据；接收方网卡接收到数据后，都会将数据放到接收数据缓冲区；用户recv就是从接收缓冲区接收数据；
原理图如下所示：

2.粘包问题：
（1）粘包问题主要发生的位置：发送缓冲回区的数据堆积；接收缓冲区的数据堆积；
（2）粘包的本质：数据之间没有明显的边界，TCP只管传输数据的字节流导致发送端/接收端因为数据的堆积在实际发送或接受时一次获取半条数据或多条数据；
（3）如何解决TCP的粘包问题？？？
TCP在传输层没有边界，但是可以在用户层进行边界处理对于；
对于定长的包 保证每次都按固定大小读取即可；
对于变长的包：可以在包头的位置，约定一个包总长度的字段， 从而就知道了包的结束位置；此外还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔 符不和正文冲突即可)；

注意：UDP是一个一个把数据交给应用层，它有明确的数据边界，因此不会造成粘包问题；