TCP SACK（Selective Acknowledgment，选择性确认）
TCP SACK（Selective Acknowledgment，选择性确认）是一种TCP拓展选项，用于改进TCP在丢包时的性能表现。传统的TCP在发生数据包丢失时，会触发拥塞控制，降低发送速率，然后等待确认。而SACK选项允许接收端向发送端报告已经成功接收的数据，以及缺失的数据段，从而发送端可以更精确地重传丢失的数据段，而不必等待整个数据流程重新传输。
举例来说，假设有一个TCP连接需要传输10个数据段（每个数据段的编号从1到10）。当发送端传输数据段1到数据段5，并且接收端已经成功接收它们，但由于网络拥塞，数据段6丢失了。在传统的TCP中，接收端只能确认收到数据段5，而发送端会认为数据段1到5都已经成功传输。这就导致发送端要等待数据段6的确认，才能继续发送后续的数据段。
使用TCP SACK，接收端可以向发送端报告成功接收了数据段1到5，以及缺失了数据段6。发送端收到这个SACK报告后，它就知道只需要重传数据段6，而不必等待整个数据流程重新传输。这种方式可以显著提高网络的吞吐量和传输效率，特别是在高丢包率的情况下。
综上所述，TCP SACK的主要用途是改进TCP在丢包情况下的传输效率，避免不必要的重传和等待。
需要注意的是，SACK并不是TCP协议的默认选项，它需要在TCP连接的双方都支持并启用才能发挥作用。不同操作系统和TCP实现可能在SACK的支持和实现上存在差异。
通过上行包的TCP ACK，判断之前上行包是否是丢包还是重传可以涉及一些分析和观察。下面是一些可能的方法和指示：
TCP序列号： 每个TCP数据段都有一个唯一的序列号，ACK报文中的确认号表示已经成功接收的数据序列号。如果之前的数据段因为丢包而触发了重传，那么ACK报文中的确认号将是之前重传数据段的序列号，而不是最近发送的数据段的序列号。
重复ACK： 如果之前的数据段被接收端成功接收，但发送端以为该数据段丢失，发送端可能会收到重复的ACK报文。连续多次接收相同序列号的ACK报文可能是因为发送端重传了该数据段。这种情况下，发送端可以通过观察重复ACK报文的次数来判断是否发生了重传。
SACK选项： 如果使用了TCP SACK（选择性确认），接收端可以在ACK报文中指明成功接收的数据段范围，以及丢失的数据段。发送端可以通过解析SACK选项来判断是否存在数据段丢失，从而进行重传。
时间间隔： 观察ACK报文的时间间隔也可以提供一些指示。如果两个连续的ACK报文之间的时间间隔很短，那么可能是因为接收端快速确认了之前的重传数据段。
窗口大小变化： 观察发送端的窗口大小是否在变化。如果之前的数据包因为丢失而触发了重传，发送端可能会降低窗口大小以进行拥塞控制。这种情况下，你可以通过比较窗口大小的变化来推断是否发生了丢包和重传。
数据段的时间戳： 如果发送端在数据段中包含了时间戳选项，接收端的ACK报文中也可能包含时间戳。通过比较数据段和ACK报文中的时间戳，你可以判断是否存在重传。
比特位图： 在某些情况下，发送端可以通过在TCP头部的选项字段中包含比特位图，表示发送端认为哪些数据段丢失。接收端在ACK报文中也可以返回相应的比特位图，表示哪些数据段已成功接收，哪些数据段需要重传。
快速重传： 如果接收端在收到失序的数据段后立即发送了一个重复的ACK报文，这可能是触发发送端进行快速重传的迹象。在快速重传机制下，发送端会重传失序的数据段，而不是等待超时。
拥塞窗口变化： 观察发送端的拥塞窗口变化。如果发送端在ACK报文中指定了较小的拥塞窗口，这可能是因为发送端认为之前的数据段丢失了。而在重传后，发送端可能会逐渐增加拥塞窗口来测试网络的可用带宽。
