We know that the PDU of the application layer is a message, and finally becomes the bit stream of the physical layer to propagate, so what is the relationship between the message format of a protocol and the body of this message? What is the role of understanding the message format of a protocol? CCNA 200-301 sample questions.
In short, the sender of the data does the encapsulation (Encapsulation) and encoding of the original data at each layer (the sinking process from the upper layer to the bottom layer), and the receiver of the data does the data at each layer (the floating process from the bottom layer to the upper layer) Decapsulation, Decode, and finally restore the original data, and understand the true meaning of the original data!
In order to make the above text easier to understand, let's take a short story as an example.
Alice visits the passhot website (https://www.passhot.com)
Suppose Alice's first message has been encapsulated layer by layer and reaches the sending buffer of the network card. The network card does not need to understand what this message is and what it means. In the eyes of the network card, it is just a series of 0 and 1 binary bit streams.
The network card needs to encapsulate the binary stream, add an Ethernet header, and add an Ethernet tail (FCS).
o The source MAC in the Ethernet header represents its own MAC address, 6 bytes.
o The destination MAC in the Ethernet header represents the MAC address of the receiver, 6 bytes.
o Ethetype in the Ethernet header represents what protocol is encapsulated, here 0x0800, representing the IP protocol, 2 bytes.
o The FCS at the end of the Ethernet represents the frame check code, generally a CRC check algorithm, 4 bytes.
The network card also needs to encode these 0, 1 binary streams. What kind of current waveform represents 0 and what represents 1, and then the 0, 1 binary stream becomes the current waveform transmitted in the network cable.
In order to make the receiver ready to receive in advance, it is also necessary to send 8 bytes (64 binary bits) of synchronization signal before sending these waveforms. Inter-Frame Gap is also required between frames, so that the receiver can identify each frame.
Okay, switch the viewing angle to the receiver, the receiver detects the complete 64-bit synchronization signal, and is ready to receive. Ignore the 64 sync bit, start receiving the signal starting at the 65th bit, and decode it into 0 or 1 according to the decoding specification, and put it into the receive buffer.
In this process, once the complete destination MAC address is received, it is compared with its own MAC address. If it is different, the receiving process is abandoned. If they are the same, continue to receive. The receiving process continues until an empty time gap (Inter-Frame Gap) is detected, and this frame is received.
The network card first extracts the last 32 bits (4 bytes). According to the protocol specification, this is the FCS check code. Calculate the FCS check code for the received frame (except FCS) to see if it matches the extracted FCS The check code is the same.
o If they are the same, the frame is intact and you can continue processing.
o If it is different, it means the frame is wrong and discarded.
Then, according to Ethetype = 0x0800, the network card retrieves which software module (callback function) is responsible for handling this IP protocol. The IP module takes the buffered data and releases the buffer.
IP module
The IP module can use the format in this picture to perform a message format validity check (Sanity Check) on the received data. As long as there are illegal fields, discard them. For example, if TTL = 0 is detected and discarded, an ICMP error message needs to be sent to the host corresponding to the source IP.
If everything is normal, the IP module extracts the "Source IP" field and searches the routing table, performs routing, finds the corresponding outgoing interface, and continues to sink the IP packet to the physical outgoing interface (Outgoing Interface). The physical interface follows the interface data The link layer encapsulation type (Ethernet / HDLC, etc.), complete encapsulation and coding, the steps are similar.
After the relay of N multi-relay routers, the message finally reaches the IP layer of the knowing server. The IP layer searches for routes and finds that it is the real receiver. The IP layer extracts the "Protocol" protocol field, assuming "Protocol" = 0x06. The IP layer retrieved as "Protocol" = 0x06 The service module is the TCP module.
The IP layer completely strips the IP header and submits the data stripped of the IP header to the TCP module for processing.
TCP module
The TCP module also needs to check the validity of messages (Sanity Check) and Checksum. If everything is normal, TCP looks up the TCP Session ID based on the extracted five-tuple {<protocol>, <src addr>, <src port>, <destaddr>, <dest port>}.
o If found, forward the message to the secondary Session ID for processing
o If not found, and SYN = 1, as a new connection, create a new connection
o If it is not found, and SYN = 0, it is regarded as an illegal link and sent to Reset for processing.
Assuming that the Session ID is found, the Session ID is responsible for reading and processing the packet header, updating the sliding window, and sending a confirmation message. At the same time, according to "Destination Port" to search for who continue to process the message. Here "Destination Port" = 443, which is handled by the TLS protocol. TCP strips the TCP header and submits the rest to TLS for processing.
TLS module As shown in the figure below, TLS is one of "Hand Shake", "Change_Spec", "Alert", and "Application" according to the "Type" field, and you can know whether it is a handshake message or an application data message.
Assuming that "Type" = "Application" here, it means that this is encrypted upper layer data, as shown in the gray part.
TLS retrieves the decrypted key (Session Key) and HMAC Key based on the TLS Session ID, encrypts the encrypted data, and then completes the integrity check of the data.
If everything is normal, the plaintext data is decrypted. In the header of the plaintext data, there is a field named "Application Protocol", there are HTTP 1.1, HTTP 1.2, SPDY, etc., TLS retrieval is the module responsible for this type. Assume here is HTTP 1.2.
HTTP module
As shown in the figure below, http also has its own protocol format that regulates the meaning of each field offset. This is usually done using TLV (Type Length Value).
The HTTP module only needs to extract the information of each field, understand it according to the meaning of the protocol specification, and make a response action.
The PASSHOT server saw that this was originally a request to pull the user's homepage. Since the request page had embedded the user's "Access Token", the user's identity authentication work was completed. Knowing that the server organized the user's homepage according to the HTTP 1.2 protocol format, And return to Alice.
The data needs to sink from the upper layer to the bottom layer again. This process and the floating process are reversed. If you understand the floating process, then the sinking process is very easy to understand!
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.
Comments