The first day of HCIP (static routing experiment)

1. Introduction to the three-way handshake of TCP connection

The TCP three-way handshake is the minimum value that can complete the connection under the premise of ensuring its reliability.

In the first handshake, the client sends SYN (synchronous connection request) and its own seq;

In the second handshake, the server will reply ACK=client SYN+1 after receiving the SYN sent by the client, and send its own SYN;

In the third handshake, the client sends an ack to confirm receipt of the SYN from the server to complete the connection.

There is no need for a handshake because TCP is a connection-oriented transmission mechanism, which is two-way. The most basic connection cannot be completed by only one handshake, so one handshake is definitely not possible;

Assuming that two handshake is required, when A sends a SYN to B, if B does not receive the information due to network delay or other reasons, then A has not received the ACK reply sent by B for a long time, and will continue to send to B SYN connection request. At this time, if B can normally receive the SYN and reply ACK to A, the two will establish a connection. At some point later, when B receives the first SYN, it will think that it is just a link request and will reply to A. , And A knows that he has completed the link and does not need the ACK, it will be discarded, and B will continue to send ACK, resulting in the occupation and waste of network resources;

The root cause of the above phenomenon is that the server does not know that this is an invalid connection, and the three-way handshake can solve this problem. The second time B replies ACK+SYN to A, the server knows that A must also reply to a confirmation. If the confirmation is not received , Which proves that this is an invalid connection, the connection will be released and re-established, so the three-way handshake mechanism is adopted.

The so-called "three-way handshake" is to negotiate how to track the amount of data sent each time to synchronize the sending and receiving of the data segment, the number of data confirmations determined according to the amount of data received, and when the data is sent and received. Cancel the connection and establish a virtual connection.

2. Introduction to the four waves of TCP disconnection

(1) The TCP client sends a FIN to close the data transmission from the client to the server.

(2) When the server receives this FIN, it sends back an ACK, confirming that the sequence number is the received sequence number plus 1. Like SYN, a FIN will occupy a serial number.

(3) The server closes the client's connection and sends a FIN to the client.

(4) The client sends back an ACK message to confirm, and sets the confirmation sequence number to the received sequence number plus 1.

TCP is full double public. To achieve reliable connection closure, A sends an end message FIN. After receiving B's confirmation, A knows that he has no data to send, and B knows that A no longer sends data, and he will not receive it. The data is available, but at this time, A can still receive data, and B can also send data; when B sends a FIN message, the two sides will be truly disconnected and read and write separately. In order to prevent the invalid connection request segment from being suddenly transmitted to host B, an error occurs.

3. Static routing experiment

1. IP address division (easy to summarize-reduce the number of routing entries for easy management)

192.168.1.0/24

3 digits for 6 network segments

192.168.1.0/27-->backbone road (borrow 3 digits from six network segments) 192.168.1.0/30 192.168.1.4/30 192.168.1.8/30 192.168.1.12/30 192.168.1.16/30

192.168.1.20/30 192.168.1.24/30 192.168.1.28/30

Loopback

R1 192.168.1.32/27-->192.168.1.32/28 192.168.1.48/28

R2 192.168.1.64/27-->192.168.1.64/28 192.168.1.80/28

R3 192.168.1.96/27

R4 192.168.1.128/27-->192.168.1.128/28 192.168.1.144/28

R5 192.168.1.160/27

192.168.1.192/27

192.168.1.224/27