Compression TCP/IP

Apr 05, 2005 8 Replies

Where in the TCP/IP protocol stack does compression occur?


Regards,



Ben



[bare with me... there is a link to security]


formatting link
Excerpt:-

OSI Protocol Stack

  1. Application -- End user services such as email. 6. Presentation -- Data problems and data compression 5. Session -- Authenication and authorization 4. Transport -- Gaurentee end-to-end delivery of packets 3. Network -- Packet routing 2. Data Link -- Transmit and receive packets 1. Physical -- The cable or physical connection itself.

TCP/IP Protocol Stack.

  1. Application -- Authenication, compression, and end user services. 4. Transport -- Handles the flow of data between systems and provides access to the network for applications via the (BSD socket library) 3. Network -- Packet routing 2. Link -- Kernel OS/device driver interface to the network interface on the computer.

Quite happy to bear with you but you do not want to see me with my clothes off ;-)

That would assume the end-user applications were aware of data compression. What if this wasn't the case? Would compression not occur?

On aside, I believe there is an error..... `Network,' should read `internet,' not to be confused with Internet.

;-) Will watch my typing in future.....

When you talk about TCP/IP stack you normally are not talking about the Application level. Just the Transport level. That's why I say there's no compression in the TCP/IP stack, because the Application level don't use to be considered part of the TCP/IP stack.

Regards.

With a dial-up connection (and certain others), the link layer is PPP: (ftp://ftp.rfc-editor.org/in-notes/std/std51.txt). PPP includes a limited form of compression.

Why is this of interest, anyhow?

I'm currently examining IPsec.

If encryption is used, then compression is not possible.

I'm also interested in any potential performance gains (smaller packets ->

faster [IPsec] encryption... but at what overhead? Smaller packers should also improve performance elsewhere)

Regards,

Ben

You compress the data before you encrypt it.

compress decompress encrypt decrypt send() -----> recv()

Sorry, I thought I had already implied that in my last post.

Yes, it is possible. BUT, can performance gains be achieved by doing it?

(Security is also increased by compressing then encrypting)

If you consider that part of the TCP/IP stack is right.

Regards.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required