Does TCP improve the ability of IP to send really really large files? [closed]

Question

How does TCP improve the ability of IP to send really large files? Show me the math. (Calculate the max packet that IP can send and multiply by the maximum fragments. Compare that to what TCP can do.)

Answer 1

IP is a layer-3 protocol, and TCP is a layer-4 protocol. Neither protocol understands files. An application will send data to layer-4 (TCP), and TCP will break the data into chunks and encapsulate it in TCP segments. TCP will pass the segments to layer-3 (IP), which in turn encapsulates the segments in packets. IP will pass the packets to layer-2 (ethernet), which encapsulates the packets in frames. Ethernet will then pass the frames to the hardware (driver) which serializes the frames to bits on the wire.

TCP is one of many layer-4 protocols. It is a connection-oriented protocol which creates a bi-directional conversation with TCP on the other end. TCP provides guarantees for delivery and reassembly of out-of-order segments, and this is why it is often used for files transfers, but an application could use something like UDP, which doesn't have any guarantees. With UDP, the application must take on the responsibilities to get all data and reassemble it into the correct order.

This Wikipedia article may help you understand the OSI Model.

Answer 2

TCP provides three features that IP alone does not have:

1. Guaranteed delivery. If a packet is lost, TCP will detect and resend it.
2. Packet ordering. If packets arrive out of order, TCP can reassemble them in the correct order.
3. Transmission rate control. TCP allows the receiver to tell the sender to slow down or speed up as necessary.

Answer 3

Actually TCP run atop of IP (ie. you can't run TCP exclusively without IP).

Long story short: multiple protocols are involved during a file transfer, and the assumption that TCP/IP is always better (than UDP/IP for instance) for large file transmission can be technically not exact.

This is because, as said above, we have many protocols involved (have a look at http://docs.oracle.com/cd/E23823_01/html/816-4554/ipov-6.html#ipov-7), and each one of them can implement features in an exclusive, complimentary or even duplicate way with respect to each others.

Practical example:

• FTP: run atop of TCP/IP, it's reliable in case of unreliable networks (when there is rumor, when devices or links over the Internet fail, etc.)
• TFTP: run atop of UDP/IP, it's easier by design, it's totally unable to manage unreliable networks (and situation in which packets are not delivered in the proper order) but it has less overhead

If you're transferring files in your local - reliable and deterministic - LAN you will probably require less time with TFTP than FTP, but if something goes wrong the result will be a corrupted file or a connection abort (requiring you to restart everything and lose more time).

Even if questionable from a real point prospective, no one will stop you from using UDP and than write an application protocol that implements the features of TCP, like retransmission, windowing, congestion avoidance, etc.

Nowadays, btw, I would say that the most promising protocol is WEBDAV (HTTP), that runs on TCP/IP.

But going back to your question my answer would be: TCP can be considered a better choice for developing an application protocol for large file transfers, because it has some built-in features that we can use out of the box, like:

• Congestion avoidance: if a link become congested the 2 peers can dynamically lower the speed
• Sequencing: if packets containing the payload of a file cross different paths and arrive at destination in a different order, TCP can rebuild the payload properly
• Error management: actually managed complimentary with other protocols, if part of the transmission is lost or corrupted, a retransmission of those data is automatically performed