T
Not sure I agree that TCP was optimized for file transfer -
certainly a transport that's optimized for file transfer doesn't
need to ensure strict ordering of all messages sent from one peer
to another as long as they get reassembled in correct order when
the file is written. Otherwise, I agree. Keith
The slow start parameters are.
Sure, you can use TCP for many things, but if you are making an HTTP GET request, slow start on send is doing the exact opposite of what you would want (and often with parameters chosen for 1980s line speeds).
TCP slow-start on send remains OK for HTTP. with current initial window sizes. The original IW is too small only because requests are full of a LOT of junk.
TCP infers EOF from server-initiated CLOSE, however - which causes TIMEWAIT accumulation at the server, if specs are followed. The current approach is largely to ignore those specs.
So we COULD make protocols for particular uses, but given how little those specs are actually honored, it seems like a waste of our time.
Joe
|
