一：TCP可靠传输

TCP可靠传输：TCP基于以字节为单位的滑动窗口来实现可靠传输

发送方收到了一个来自接收方的确认报文段
- 报文段首部中窗口字段取值为20，也就是接收方表明自己的接收窗口尺寸为20字节
- 确认号字段的值为31，表明接收方希望收到下一个数据的序号为31，而序号30之前的数据已经全部正确接收了
发送方根据这两个字段的值构造出自己的发送窗口。发送方在没有收到接收方确认的情况下，可以把发送窗口内的数据依次发送出去，凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。发送窗口有后沿和前沿部分
- 后沿：其后面部分是已发送并且已经收到确认的数据字节序号，这些数据字节显然不需要再保存在发送缓存中了，可以将其删除。其移动情况有两种可能
  - 不动：没有收到新的确认
  - 前移：收到了新的确认
- 前沿：其前面部分是当前不允许发送的数据字节序号。其移动情况有三种可能
  - 通常是不断向前移动
  - 不动
    - 没有收到新的确认，对方通知的窗口大小也不变
    - 收到新确认但对方通知的窗口缩小，使发送窗口前沿正好不动
  - 向后收缩
假定发送方将发送窗口内序号31-41的数据封装在几个不同的报文段中发送出去
此时，发送窗口的位置并没有改变，发送窗口内序号31-34的数据已经发送但没有收到确认，而序号42-50的数据是允许发送但还未被发送的
那么应该如何描述发送窗口的状态呢？如下图，可以使用三个指针P1、P2和P3分别指向相应的字节序号
- 小于P1：已发送并且已经收到确认的部分
- 大于等于P3：不允许发送
- P3-P1：是当前发送窗口的尺寸
- P2-P1：已发送但未收到确认的字节数量
- P3-P2：允许发送但当前尚未发送的字节数（又称为可用窗口或有效窗口）
接收窗口尺寸为20，在接收窗口外面到30号为止的数据是已经发送确认并且已交付给应用进程的数据，因此无需保留这些数据，可将它们从接收缓存中删除；接收窗口内31-50号数据是允许接收的数据接收窗口外51号及其后续数据目前不允许接收
假设发送方之前发送的封装有32和33号数据的报文段到达了接收方，由于数据序号落在了接收窗口内，所以接收方接受他们，并将它们存入接收缓存
但是它们是未按序到达的数据，因为31号数据还未到达，这有可能是丢了也有可能是滞留在了网络中的某处
接收方只能对按序到达的数据中的最高序号给出确认，因此接收方发出的确认报文段中的确认序号仍然为31，也就是希望收到31号数据
窗口字段的值仍为20，表明接收方没有改变自己接收窗口的大小
发送方收到该确认报文后，发现这是针对31号数据的重复确认，就知道接收方收到了未按序到达的数据
由于这是针对31号数据的第一个重复确认，因此并不会引起针对该数据的快重传
另外，接收方窗口的窗口尺寸仍然为20，因此发送方保持自己的发送窗口也为20
假设现在，封装有31号数据的报文段到达了接收方，接收方接受该报文段，将其封装的31号数据存入接收缓存
接收方现在可以将接收到的31-33号数据交付给应用进程，然后将接收窗口向前移动3个序号，并给发送方发送确认报文段
该确认报文段中窗口字段的值仍然为20，表明接收方没有改变自己接收窗口的大小，确认号字段为34，表明接收方已经收到了序号33为止的全部数据
现在，假设又有几个数据报文段到达了接收方，他们封装有37、38和40号数据，这些数据的序号虽然落在接收窗口内，但它们都是未按序到达的数据，只能先暂存在接收缓存中
假设接收方先前发送的确认报文段到达了发送方，发送方接收后，将发送窗口向前滑动3个序号，发送窗口的尺寸保持不变，这样就有新序号51-53落入了发送窗口内，同时序号31-33移出了发送窗口
现在可以将31-33号数据从发送缓存中删除了，因为已经收到了针对它们的确认
发送方继续将发送窗口内序号42-53的数据封装在几个不同的报文段中发送出去
现在，发送窗口内的序号已经用完了，发送方在未收到接收方确认的情况下，不能再发送新的数据
序号落在发送窗口内的已发送数据如果迟迟收不到接收方的确认，则会超时重传

二：补充说明

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大
- 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的
- 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸
对于不按序到达的数据应如何处理，TCP并无明确规定
- 如果接收方把不按序到达的数据一律丢弃, 那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据
- TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上
- 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源
- TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认RFC 1122
- 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据
TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口