TCP transmission skills, read this article is enough!

ACK changes when uploading files in TCP?

In a tcp connection, if only the client side has been uploading files, and the other side's server will send a confirmation ack packet after receiving the packet, does the data content of this packet have a length? Or to put it another way, in this case, the ack field of the data packet sent by the client to the server does not change? (It's not normal ack and seq to increase sequentially), the server clearly has no data to send, then the client's ack field can be unchanged all the time.

Everyone should know the meaning of TCP's ACK, which is to send a confirmation message to the other party to show that all byte data of byte number <Acknowledge Number (Acknowledge Number) has safely reached the destination.

Alice sends data to Bob. Bob ’s TCP needs to confirm Alice ’s TCP, right? The question is coming. Does Alice need to confirm to Bob?

If Bob has no data to send to Alice, Alice's TCP will not have the opportunity to ACK the other party, so Alice's TCP will not send any ACK at all, and the ACK confirmation number will stay in place and stay still.

If Bob has data to send to Alice, Alice's TCP also needs to ACK the other party, and Alice's acknowledgment number also needs to grow as the received byte data of the other party grows slowly.

Next, when Alice transfers files to Bob, does Bob have any data to transfer to Alice?

Use http to transfer files, and the http protocol uses Request / Response interaction. When transferring files, Alice's file data is cut into N small segments, submitted to TCP for transmission, traversing the network, and the data reaches Bob's TCP, TCP confirmation. Later, the data arrives at Bob's http. At this time, Bob just caches the data and waits for the complete file data to arrive. Don't do anything else?

How does Alice see her file upload progress bar on the web page? Bob's http pushes the page update part of the current web page to Alice, so that Alice can know her file upload progress in real time. So, Bob ’s http submits the updated webpage to TCP for transmission, traverses the network, and reaches Alice ’s TCP. Do I need TCP to ACK? Of course you need it! Taking a step back, Bob does not push the updated page to Alice, but just caches the data and waits patiently to receive the complete file data. This is that Bob's TCP does not have any bytes of data to send. "TCP does not generate data, TCP is only the carrier of byte data at the application layer", the source of the data is at the application layer (here http), not TCP!

Okay, Alice is very depressed and can't see the progress bar of the file upload. After a while, all the files arrive at Bob, and it is Bob ’s http that knows this fact. The files are all transferred, and the page that successfully uploaded the file is always pushed to Alice through the http response. Obviously the data is generated in this way, Bob's data will soon reach Alice's TCP, TCP will immediately ACK, the ACK confirmation number and the other party's byte data show a synchronous increase.

If the subject says that this is not the answer I want, the file upload uses a private protocol. When the file upload is complete, the receiver does nothing. Once the file upload is completed, the party immediately closes the connection and Alice ’s ACK confirms Has the number been eternal? No! Suppose, when the two parties establish TCP, Bob's byte origin sequence number (ISN) = 2000, who occupies this number? Bob's SYN! In the communication process, Alice's ACK number has been 2001, because Bob has never transmitted data to Alice. When closing the connection, Bob's TCP will send FIN to close the connection, Sequence Number = 2001, who occupies this 2001 number? Of course it's Bob's FIN!

How does Alice ACK?

Alice sends confirmation number (Acknowledge Number) = 2002

Obviously, Alice's confirmation number has changed from 2001 to 2002, and it is not constant!

The above is the news sharing from the PASSHOT. I hope it can be inspired you. If you think today' s content is not too bad, you are welcome to share it with other friends. There are more latest Linux dumps, CCNA 200-301 dumps and CCNP Written dumps waiting for you.