网络数据包拦截之：修改TCP包内容时注意的问题

首先描述一种现象，曾经家里的ADSL宽带，当用IE浏览器浏览网页时候，
不管你打开什么类型的网站，都会出现电信广告，或是嵌入到原来网页中或是弹出广告框，十分的讨厌。
曾经天真的以为是每个网站都跟电信合作，在他们的网站代码里潜入了电信广告，
其实不是这样，只要在任何一个网关路由设备里，拦截TCP数据包，这里的拦截是基于IP层数据包的拦截。
分析TCP包里HTTP协议并在里边添加数据，即可实现上边所说的讨厌的广告内容。
现在所说的，就是在修改TCP包内容时，需要注意的问题的细节，
否则的话即使改了内容也无法达到预期效果，同时很可能会中断TCP连接。

1），首先是最大包长度的问题。以太网卡最大传输单元是 1500字节，
就是一次能把1500字节传输到网络上去，称为MTU（最大传输单元）。
（这里假设修改后，包长度都不超过MTU, 而且修改都能在单个包里完成，否则情况更复杂）。
TCP协议又有一个叫MSS的最大分段大小的概念，意思是，每次最大传输的TCP包负载的最大值。
每次TCP握手连接时候，连接双方都会协商 MSS 值， 所以跟踪这个TCP连接，修改MSS值，一定程度上解决最大包长度问题。

2），其次是修改了TCP包内容之后，需要相应修改 IP头里的 length字段，重新计算IP头里的校验和以及TCP头里的校验和。

3），如果包内容改变后，包长度变化了，必定造成 TCPHeader->seq和TCPHeader->ack的不正确，需要重新计算。

问题 1），2）都是比较好解决的。3）是最麻烦的，他需要从头到尾跟踪这个TCP连接。
比如在一个TCP连接的里，有一个发送的数据包被修改之后，长度从OldLen1改变为NewLen1，长度变化了
Change1 = NewLen1 - OldLen1；
则在这个包的所有的后续发送的包的 TCPHeader->seq 都需要改成 TCPHeader->seq + Change1，
在所有后续的接收包的 TCPHeader->ack 都需要改成 TCPHeader->ack - Change1,
但是并不包括本次发送的数据包。
如果在后续发送的包里，又有一个数据包B 改变了长度Change2，则在B之后发送的数据包都需要改成
TCPHeader->seq+Change1+Change2， 在后续接收的包都改成 TCPHeader->ack-Change1-Change2.
依此类推。
Change1+change2 可以理解为offset，就是seq的修改偏移，也是之后收发的数据包的seq和ack需要修正的值。


如果遇到乱序，重复的数据包，情况就更麻烦些。
重复的包还好办，直接重新修改，重新计算就可以了，如果是乱序的包，情况就复杂了。
比如发送方连续发送 1，2，3，4，5 五个数据包，接收方接收到 1，2，4，5，其中 3丢失了，接收方要求发送方重新发送3，
4，5包在发送中，都被修改了长度，按照上面的思路，则要正确记录 数据包3之前的seq的修改后的 offset，
同时要记录 4，5两个点的seq的修改后的offset，直到接收方回复ack，才能把ack之前的修改包的seq的offset删除，
因为ack之前的都已经被成功接收了。
如果这样计算的话，会很复杂。所以把问题想简单点，就简单记录当前被修改数据包之前的offset和修改之后的offset，
这样做虽然遇到像上面那种情况，会出现混乱。 但是绝大部分都能正常工作。
这个思路也要得益于 linux内核中netfilter的NAT实现代码里关于seq和ack修正的处理办法，
详细信息，可以参照 linux内核中 netfilter实现的 nf_nat_helper.c 源文件。