我正在尝试通过剥离一些字节来修改TCP有效负载。
只要将这些字节替换为相同长度的其他字节而不是剥离它们，修改包就可以了。
如果删除了字节，Wireshark在转储中显示[未捕获TCP先前段]消息。
我同时删除了校验和和修改后的程序包的程序包长度，以便Scapy在发送程序包时重新计算所有校验和：
# Delete the old checksums
del packet_mod[IP].chksum
del packet_mod[TCP].chksum
# Delete the old packet length
del packet_mod[IP].len
如果我在修改后的数据包的末尾也切断len（stripped_bytes），则修改有效，因为接收方将重新发送的TCP段添加到修改后的包中。
例如：我剥离了20个字节的TCP有效负载。然后，如果我还在有效负载的末尾另外切断了20个字节，则修改仅适用。
我想念什么？
我不明白这部分是什么意思：
例如：我剥离了20个字节的TCP有效负载。然后进行修改仅适用于如果我还在末尾额外切断20个字节的情况有效载荷。
无论如何，您所缺少的是每个TCP段都带有TCP标头字段-“序列号”字段-表示该段的数据内容在字节流中的位置正在通过TCP传输。
TCP接收器使用段序列号和段长度（段长度是根据IP数据报的长度计算得出的传送了该段）以从中构建连续的字节流收到的流量。例如，如果接收方以前收集了所有数据，直到序列位置200和下一个传入段看起来像这样：
(segment 1) sequence=200 length=80 data='data data data ...'
(segment 2) sequence=280 length=60 data='more data ...'
(segment 3) sequence=340 length=70 data='even more data ...'
然后，接收者知道它已经收集了所有数据直到（但不包括）位置410。由于没有间隙，这些数据已准备好传递给应用程序。
注意，段号（1），（2），（3）在not中出现TCP标头。这些数字只是在那里，因此该描述可以参考它们。
很明显，如果段（2）已经丢失，并且接收方仅收集段（1）和（3），则接收方将知道接收到的数据存在差距。它会确切地知道差距所在的位置：从位置280开始缺少60个字节。TCP承诺提供完整的有序数据流，因此直到填补了这一空白，不允许接收方交付任何之后的字节（例如它在段中在位置340处的70个字节）3）到应用程序。如果丢失的字节不会很快到达然后接收者将告诉发送者有关间隙的信息，并且发送者将重新传输丢失的数据。
这就是为什么从TCP段中删除字节会导致问题。如果您的程序从段（2）中删除了20个字节，然后从接收器中删除了会看到这个：
(segment 1) sequence=200 length=80 data='data data data ...'
(segment 2) sequence=280 length=40 data='more data ...'
(segment 3) sequence=340 length=70 data='even more data ...'
接收者将得出结论，发现了320字节的20个字节。
如果Wireshark正在观察此流量，则它将得出相同的结论。TCP接收器和Wireshark都不知道导致此问题的原因。丢失的字节是段（2）已被编辑。 Wireshark的最合理的猜测是丢失的字节在一个段中莫名其妙地没有提供检查，这就是为什么显示“未捕获上一个段”消息。它说“上一个”因为它直到检查才发现有差距段（3），然后在间隔后一个。
接收者将以与处理任何间隙。它将告诉发件人有关差距并等待丢失要重传的数据。如果接收方收到丢失的数据然后它将填补空白，然后照常继续。如果你继续拦截重传并删除丢失的字节然后接收方将继续报告存在差距，并且发送者最终将厌倦了重新传输丢失的数据它将放弃TCP连接。
这意味着您不能简单地从运行中的TCP段中删除数据并期望TCP不会注意到数据丢失。原则上你可以通过删除一些数据然后操纵序列来完成来自所有发件人和的所有后续分段中的编号接收方发送的确认，但这是一个更大的任务。
参考：描述了基本的TCP序列号机制在RFC 793和长期以来使用序列号提高安全性的最佳实践是RFC 1948和在RFC 6528中正式确定为标准。