|
> I don't know if this applies to all operating systems, or if it's a
> standard or what, but I noticed that when resending TCP packets with the
> SYN bit set, the sequence number does not change. Now, with what I know
> of TCP, this is exactly the desired behaviour -- can anyone enlighten us
> if it's standardized or not? -- and we could use this to our advantage.
There is a standardized three-way handshake and Positive Acknowledgement
with Re-transmission (PAR) which is an integral part of TCP.
Basically each byte of data from the initial sequence number is numbered
sequentially. The host receiving data during a transaction sends an
acknowldegement back to the sending host which includes the sequence number
of the last byte of data which was successfully received. The sending host
then resends data as necessary depending on what acknowledgement number was
received.
So the sequence numbers on retransmitted bytes may return to values they
have been times before if the receiving host asks the sending host to resend
data. This is just how TCP works. The sequence numbers are the only way that
either host keeps all of its chickens in order, so when data is resent in
order for both sides to know what's going on, the sequence numbers have to
be rewound and played back.
> It occured to me that if we were to keep track of not only SYNs, but their
> sequence numbers, we could possibly very easily detect when a TCP based
> real server is having problems by noticing that we've seen that sequence
> number in a SYN from that host not too long ago, and either remove that
> server from the pool, or (more likely) notify userspace for appropriate
> handling.
I really don't think there's a lot that can be done with this. PAR has been
built into TCP to make it a reliable protocol. It helps gaurantee that all
data actually gets from point A to point B. If retransmissions need to
occur, it may have nothing to do with either end -- it may have to do with
something way out on the Internet which cannot be changed. If there was
anything we could do with this information, TCP would already be doing it;
we'd just be reinventing the wheel.
And what would keep someone from sending a bunch of ACKs back to our real
servers... forcing them to retransmit... and then having us take them down.
<?>
Also, I think you're suggesting that we make observations at the network
layer by using this information... however... if things make it all the way
up the ladder to the protocol layer, the network is probably fine.
It just seems like we'd be meddling in foreign waters. Let TCP do what we
pay it to do and otherwise leave it alone.
> Any thoughts?
But those are just my opinions.
All the best --
Ted
|
