计算机网络---TCP的可靠传输机制和面向字节流传输

在了解了TCP的面向连接传输之后我们讲解TCP的可靠传输相关的机制和面向字节流传输
一，TCP的可靠传输

• 可靠应答机制
• 超时重传机制
• 报文中的序号和确认序号
  可靠应答机制
  就是在每次发送数据或者请求之后对方都要回复一个应答信号，告知信息已经完整的接收到了
  超时重传机制
  在一段发送数据给另一端之后，可能因为网络拥堵的原因或者其他原因数据无法到达另一端，在一定的时间没有收到对方的确认应答，就会进行重新发送
  报文中的序号和确认序号
  报文中的序号和确认序号是保证数据的正确性和有序性，在发送的数据中可能不是按照书序到达的，在序号和确认序号来及逆行排序就能进行重新按照正确的顺序进行排序。
  因为TCP为了实现可靠传输牺牲了部分常熟性能，并且有可能确认应答丢失就要重新传输数据，因此又提出几种机制来避免大量的丢包以及ACK丢失重传保证性能

滑动窗口机制
TCP通过双方协商窗口大小进行流量控制，避免因为缓冲区不够而导致丢包重传。通过协商，一次可以对多传输多条数据，之后然后等待确认应答，不需要一一停留。

• 窗口大小指的是无需等待确认应答可以继续发送数据的最大值，上图中就是4000个字节（分为四次发送）
• 发送前四个段的时候不需要等待任何的ACK，直接发送
• 收到第一个ACK之后华东窗口向后移动，继续发送的五段的数据，一次类推
• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来纪录当前还有那些数据没有应发，只有确认应答过的数据，才能从缓冲区中删除
  
• 窗口越大，则网络的吞吐率就越高
  16位的窗口大小，最多2^16字节。
  滑动窗口的快速重传机制
  （前提是每条数据的确认回复都必须按序回复），若前面的没有收到回复后面的不回发送ACK应答
• 发送方：若收到一条回复，表示ACK确认回复的数据全部安全到达，不会因为前面数据的ACK丢失而重传数据
  
  比如此时ACK丢失之后我们发送了ACK请求2001，表示2001以前的数据都已经接收到了。此时是不会重新传送的。
• 接收方：若前面数据丢失，则接收方后发的数据以及发送重传请求，并且连发三次，若发送方连续收到三次重传请求，则认为数据丢失，进行重传。
• 
  加入1001-2000的数据丢失之后一段会连续发送上一次收到数据之后的ACK就是1001，连续发送三次，若还是没有收到数据就重新发送。

滑动窗口中的拥塞控制
虽然已经有了滑动窗口机制，但是如果在开始的时候就发送大量的数据，仍然可能造成问题，比如网络状态比较拥堵的时候，发送大量的数据仍然会导致大量数据的重传。
TCP引入了慢启动，快增长，
慢启动快增长就是先发少量的数据，探探路，摸清当前网络拥堵状态，再决定按照多大的速度传输数据，在增长中速度是指数级别的，但是包含了一个阈值，当月色窗口超过这个阈值的时候就不再按照指数方式增长，而是按照线性方式增长。

黑色的就是发送的数据，红色就是应答

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候定义拥塞窗口大小为1
• 每次收到一个ACK应答，窗口加1
• 每次发送数据包的时候讲拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口
  

流量控制
接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送就会造成谍报，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接受端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制

• 接收端将自己饿可以接受的缓冲区大小放入TCP首部中的窗口大小中，通过ACK端通知发送端，
• 窗口大小字段越大，说明网络的吞吐量越大
• 接收端一旦发现字节的缓冲区块满了，就会将窗口大小设置成一个更小的值通知给发送端
• 发送端接收到这个窗口之后，就会减慢自己的发送速度
• 如果接收端缓冲区满了，就会将窗口置为0，这时候发送端不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

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

捎带应答机制
接收方对每一个数据的确认回复都需要发送一个TCP数据包，当时空包头的传输会降低性能，因此会考虑在即将发送的数据包中发送一个ACK确认信息，这样就可以减少一个空包头的发送。

二，面向字节流传输
发送方每次调用send都会将数据发送到缓冲区中，然后内核选择合适时机发送数据
接收方：网卡接收到数据都会讲数据放到缓冲区，用户用recv从缓冲区中读取数据。

此时有三条数据共3000字节，可能我们每次发送1500字节，在接收缓冲区不recv的话也是3000字节，但是此时问题出来了，怎样去区分我们的数据的开始和末尾了，这时候就导致了粘包的问题。
粘包的问题主要出现在发送缓冲区和接收缓冲区的数据的堆积，主要是因为数据之间没有明显的边界，TCP只管传输数据的字节流，导致发送端接收端因为数据的堆积在实际发送或者recv的时候一次获取到半条或者多条数据。
解决办法：TCP没有数据边界，可以在应用层进行边界处理
常见的办法：在边界中设置特殊的字符间隔（比如HTTP协议中的/r/n）。或者定长数据长度进行发送。