|
Question : TCP packet format
|
|
Hi,
I am setting up an FTP server with my ISP. They are going to charge me for all data RECEIVED but all SENT data is free.
I am trying to work out the PROPORTION of SENT data to RECEIVED data when an FTP download takes place...
E.g. Does the FTP server send 512 bytes of data and then receive back 64 bytes from the client? What are the actual figures?
Any info on this would be very much appreciated.
|
Answer : TCP packet format
|
|
each packet received an ACK packet back, unless you're using selective acknowlegement on both sides..
I don't have the packet sizes in front of me now, but the general rule is send a packet of data, then get an ACK back, and then send the next packet.. etc. etc.
in a well "oiled" network, the ACKs are assumed, and the sender often will ramp itself up by sending several packets (up to 4 I think) together.. and then wait for the ACKs to come back.. this ramp up will continue to the available bandwidth, then fall back and come out of "slow start" if the file is big enough.. (eg. 100mb or more).. otherwise, it might never leave "slow start" especially if your not using large windows..
I digress.. large windows (RFC 1023 I think) would allow for better throughput over long slow networks, but not necessarily less packets.. and it would not do you any good if both sides in the transfer didn't use them..
without large windows, your transfer is liable to be choppy.. ie. you'll never achieve true maximum bandwidth..
as for packet size, I think that ultimately varies depending on content with the maximum size being 1518 bytes.. but don't quote me on numbers, I'm doing this from memory..
your best bet to actually figure out what your traffic looks like is to trap some of it and analyze it using tcpdump, tcptrace, and xplot.. if you need copies, I can provide urls.. I don't have them handy now.. but tcpdump should be on your unix system.. the other two can be grabbed through the web.. search for their name..
good luck
|
|
|
|