I’m downloading a file using HTTP. A packet is lost. What happens?

TCP never drops data so no, there is no way to indicate a server should forget about some segment.

use mostly TCP, because you want to get your files complete and in order.

Coonection receive un RST -RESET and FIN the conenction

TCP is a bi-directional protocol

The way I understand this, there are 2 ways to close TCP connection:

  • send FIN flag
  • send RST flag

RST causes immediate connection termination, while in FIN you get a confirmation.

FIN says “i finished talking to you, but i’ll still listen to everything you have to say until you’re done”

RST says “there is no conversation. i won’t say anything and i won’t listen to anything you say” – this is useful if you have long lasting TCP connection with little traffic. if one of the computers is restarted, it forgets about the connection, and the other computer gets RST, as soon as it sends another packet

 

FIN is an orderly close of an existing connection in one direction, after all pending data is sent.

RST is is an error condition that says there is no such connection.

It is not possible to use both at the same time. The concept doesn’t even begin to make sense.

 

If you are downloading, let’s say video, UDP is preferred because even if the download is missing a few bits of information, you can still get the video and it will play.

 

a. if the download is using HTTP it will be TCP Port 80
b. if the download is using FTP it will be TCP Port 21 for control, TCP Port 20 for data (server-sided) and a random TCP Port at client side (your end).
b1. if it’s active FTP the random port will be initialized from the Server
b2. if it’s passive FTP the random port will be initialized from the Client
c. if the download is using FTPS (FTP over TLS/SSL) it will be either TCP/UDP Port 990 for control, TCP/UDP Port 989 for data
d. if the download is using SFTP (SSH File Transfer) it will be either TCP/UDP Port 22 or TCP/UDP Port 115

 

Unlike UDP, TCP is oriented “connection”. When a machine A sends data to a machine B, machine B is notified of the arrival of the data, and reflects the good reception of these data by an acknowledgement of receipt. Here comes the CRC for data control. It is based on a mathematical equation to verify the integrity of transmitted data. Thus, if the received data is corrupt, the TCP protocol allows recipients to ask the issuer to return the corrupt data.

UDP is a “non-connection”-oriented protocol. To do simple, when a machine to send packets destined for a machine B, this flow is unidirectional. Indeed, the transmission of data is done without notifying the recipient (the B machine), and the recipient receives the data without acknowledgement of receipt to the transmitter (A machine). This is due to the fact that encapsulation of data sent by the UDP protocol does not transmit the information concerning the issuer. Therefore, the recipient knows not the issuer of data except his IP. It is faster (no connection phase), but you don’t know if the recipient is connected or out when you send the datagram.