0

I want an http message to be sent and processed quickly by a remote server, via an already established persistent TCP connection How can I optimize the communication?

I have a few ideas, but I am not knowledgeable enough about networking to know if they make sense:

  • HTTP sits on top of TCP. But how does it work exactly? Specifically, if I send 1 http message, does it translate into only 1 tcp message? (I know the initial handshake takes 3 round trip time, but I do not care about this, as the connection is already established). I guess it depends on the Maximum Segment Size that the server can accept?
  • Can I ask the server for a bigger maximum segment size if needed? How can I do it (I use python, httplib and socket modules, it would be ideal in this language).
  • The remote server works with TCP, but could I try sending it UDP messages? I know UDP is faster, but could this idea work?
DevShark
  • 8,558
  • 9
  • 32
  • 56

1 Answers1

-1

I'll allow myself to comment/answer in-text:

I have a few ideas, but I am not knowledgeable enough about networking to know if they make sense:

Exactly! Read up on TCP and HTTP, on wikipedia, for a starter. It will make things much easier to discuss. Probably also faster than asking on stackoverflow ;)

HTTP sits on top of TCP. But how does it work exactly?

Well, exactly like protocols work over each other in a layered protocol stack. Read Wikipedia's TCP article, and about the OSI/ISO layer model.

Specifically, if I send 1 http message, does it translate into only 1 tcp message?

No. HTTP itself doesn't care (and it doesn't have to) into how many lower level packets communication gets split.

(I know the initial handshake takes 3 round trip time, but I do not care about this, as the connection is already established).

3 time? That's not something that makes sense. Read about the TCP handshake and how HTTP asks for a document.

I guess it depends on the Maximum Segment Size that the server can accept?

Among a lot of different other factors; really: HTTP doesn't care the least!

Can I ask the server for a bigger maximum segment size if needed?

No. Your network stack will most probably automatically use the biggest MTU that works.

How can I do it (I use python, httplib and socket modules, it would be ideal in this language).

The remote server works with TCP, but could I try sending it UDP messages?

There are some specialized HTTP-over-UDP protocols, but they are not HTTP. Generally, HTTP is spoken over TCP, but again, the internet works on a layered protocol stack, and higher level protocols usually don't care what transports their data -- you could perfectly well have an HTTP session over carrier pidgeons!

I know UDP is faster, but could this idea work?

It's not. That's a misconception. UDP doesn't have automatic re-requesting for packets that got lost along the way, which, for things like multimedia or games might make sense, but using TCP gives you an ordered session, which is necessary for HTTP.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • Hi Marcus, thanks for answering. Let me rephrase a few things: + TCP does send 3 messages to establish the handshake. That's what you can see with tools like Wireshark. Maybe not 3 round trip but at least three trips. + You say http does not care about how many tcp packets it is being sent over. That's not my question. My question is: if the http message is small enough, will it be sent over 1 packet? Can I do something to help this? + Finally, UDP is generally recognized as faster, but more lossy (see http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it) – DevShark Jun 24 '15 at 21:22
  • At application level, then, if the http message is one byte or smaller, then yes. IIRC, there are no http messages in that set. – Martin James Jun 24 '15 at 23:51
  • @DevShark I still do not agree. There's nothing faster about UDP. It's an IP protocol, just as TCP is. Hence, it takes exactly the same time to deliver data. Additional overhead might come from the fact that TCP needs to establish a connection first (you already have that) and that TCP blocks if too many packets haven't been acknowledged by the other end of the transmisdsion -- but that's never relevant nowadays because of transmit and receive windows, unless packets really get lost, in which case HTTP would break if it wasn't for TCP's automatic recovery. – Marcus Müller Jun 25 '15 at 06:19
  • @DevShark "more lossy" is absolut bs. Either a HTTP transactionhas zero loss, or it's broken. – Marcus Müller Jun 25 '15 at 06:47
  • UDP is not "loss tolerant", hence more lossy. Again, that's according to http://stackoverflow.com/questions/47903/udp-vs-tcp-how-much-faster-is-it . – DevShark Jun 25 '15 at 07:16
  • @DevShark: "Lossy" describes something where *some* information might be lost. HTTP is a protocol that relies on the underlying transport to not have that quality, hence HTTP over UDP wouldn't be lossy, since there's no "half complete, but still OK" HTTP transaction. – Marcus Müller Jun 25 '15 at 07:23
  • @DevShark: also, the accepted answer is not really true in the question you quote -- look at the answers that have 100+ more upvotes than that answer. – Marcus Müller Jun 25 '15 at 07:25