Sending Data With Least Overhead?

[MrFish]

I'm trying to compress data as much as possible before sending data in Javascript. I'd like to send a CSV list of numbers and possibly a character or two thrown in there and get as many in as possible before reaching the 1,500 byte limit (1 HTTP packet-- so the internet says). I'm really not sure where to look or if it's possible. I don't need someone to do it for me but I'm looking for at least a point in the right direction. Thanks in advance!

[JamesB]

HTTP isn't limited to 1500 bytes, you can send hundreds of megabytes over HTTP, I don't think there is even a length limit on the protocol.Other protocols of lower-level will have length limits per packet, but this won't effect HTTP because fragmentation occurs on the data, multiple lower-level packets are sent, and the receiving end rebuilds the data from all the lower-level packets received before the data is parsed to the application (eg. PHP).

[MrFish]

Oh sorry I should clarify. When I said "limit" that was a packet limit. You could also say a limit I'm putting on my script (personally). I don't want to send multiple packets for one set of information. I want to fill every packet to it's max size (or really close) before I send it to reduce the time it takes overall (since http has that lengthy handshake process).

[Ingolme]

To reduce size you can remove and unnecessary spaces, line breaks and indentation of the data. If your server supports it, use gzip compression. http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

[justsomeguy]

The server and client do not renegotiate for every packet. They negotiate once, send and acknowledge all packets, and the recipient puts the packets in the correct order and there's the message. The only thing extra that gets sent is an acknowledgement that the packet was received so that it doesn't need to be sent again.

[Synook]

Also, just because the maximum size of the data section of one packet is 1500 B doesn't mean that your web server will always actually put 1500 B in every packet — it may, if it was performing badly, put only 100 B in a packet (for various reasons). Of course it must be remembered that HTTP is an application-layer protocol, and it has to go all the way down the protocols OSI model (and back up again) — for example, the data section of an Ethernet frame also has a maximum length of 1500 B, and so you will be able to fit much less than 1500 B in each frame, due to the cumulative metadata. The point is, it is utterly useless to even consider how many frames/packets/whatever you are sending. Not only does it not actually matter, as JSG pointed out (since the packet overhead is linear with respect to the number of packets you send, and the "handshake" you speak of actually has no relation to packets), but trying to fiddle with your data won't do anything, anyway.