Summary of TCP/IP Network Protocols

1. TCP/IP Model
2. TCP and UDP
3. Why TCP Requires Three-Way Handshake
4. Why TCP Requires Four-Way Teardown
5. The Process of a Web Page Requesting a URL
6. How DNS Works
7. Principle of HTTPS Encryption

1. TCP/IP Model

Application Layer: Specifies the data format for application programs and handles specific application details.

Transport Layer: Specifies ports for specific applications to handle, establishing communication from port to port.

Network Layer: Mainly responsible for addressing and routing, transmitting data to the target address and establishing host-to-host communication.

Link Layer: The data link layer is divided into the Logical Link Control (LLC) sublayer and the Media Access Control (MAC) sublayer:

• MAC (Media Access Control) layer mainly defines how packets are transmitted over physical media, including data frame encapsulation/decapsulation, frame addressing and identification, frame reception and transmission, link management, and frame error control. The existence of the MAC layer masks the differences of different physical links.
• LLC (Logical Link Control) layer is responsible for identifying network layer protocols and providing services to the upper layer, including ensuring and controlling transmission reliability and the ordered transmission of packets.

When sending data, the MAC layer can determine if data can be sent in advance. If so, it adds some control information to the data and finally sends it in the specified format to the physical layer. When receiving data, the MAC layer first checks for transmission errors. If there are no errors, it removes the control information and sends it to the LLC layer.

Physical Layer: Connects computers through fiber optics, cables, etc., to achieve the transmission of binary data.

2. TCP and UDP

• TCP Header Structure: Source Port, Destination Port, Sequence Number, Acknowledgment Number, SYN/ACK status bits, Window Size, Checksum, Urgent Pointer.
• Characteristics: Connection-oriented, byte stream-oriented, reliable, ordered, slow speed, relatively heavyweight, flow control, congestion control.
• Applicable Scenarios: File transfer, browsers, etc.
• Applications: HTTP, HTTPS, RTMP, FTP, SMTP, POP3.

• UDP Header Structure: Source Port, Destination Port, Length Field, Checksum.
• Characteristics: Connectionless, message-oriented, unreliable, unordered, fast speed, lightweight, high real-time performance (no head-of-line blocking).
• Applicable Scenarios: Suitable for one-to-many, instant messaging, video calls, etc.
• Applications: DHCP, DNS, QUIC, VXLAN, GTP-U, TFTP, SNMP.

3. Why TCP Requires Three-Way Handshake

The reliable connection establishment of TCP is achieved through packet initial sequence numbers. The main purpose of the three-way handshake is to reach a consensus on the initial sequence numbers of packets between the client and server:

• First Handshake: The client sends SYN and client’s initial sequence number to the server.
• Second Handshake: The server sends SYN and server’s initial sequence number to the client, and also sends ACK and client’s initial sequence number + 1, indicating consensus on client’s initial sequence number.
• Third Handshake: The client sends ACK and server’s initial sequence number + 1 to the server, indicating consensus on server’s initial sequence number.

Two handshakes cannot reach consensus, while four would be redundant in terms of packet count.

The packet sequence number can be considered unique because it is generated by incrementing time and only repeats every four hours, which is much greater than the maximum packet generation time (MSL).

4. Why TCP Requires Four-Way Teardown

TCP is full-duplex, and disconnection requires ensuring that no data is to be sent in both directions:

• First Teardown: The client sends FIN and client’s sequence number to the server, indicating that the client has no data to send.
• Second Teardown: The server sends ACK and client’s sequence number + 1 to the client, indicating consensus on the client’s no data sending.
• Third Teardown: The server sends FIN and server’s sequence number to the client, indicating that the server has no data to send.
• Fourth Teardown: The client sends ACK and server’s sequence number + 1 to the server, indicating consensus on the server’s no data sending.

After the client sends ACK to the server in the fourth teardown, it enters the TIME_WAIT state and must wait for 2MSL before truly closing for two reasons:

• To ensure the ACK sent by the client reaches the server, letting the server know the client received the third teardown, allowing the server to disconnect.
• To ensure that all packets in this connection have died in the network, preventing a new connection on the same port from receiving old packets.

5. The Process of a Web Page Requesting a URL

1. Preparation for HTTP Request

• Initiate a DNS request to resolve the domain name to the corresponding IP address.
• Establish a TCP connection; if Keep-Alive is enabled, the TCP connection can also be reused for multiple requests.

2. Construction of HTTP Request

Construct the message according to the HTTP message format, including:

• Request Line: Includes request method, URL, HTTP version information; request methods include POST, GET, PUT, DELETE, etc.
• Headers: Includes Accept-Charset (character sets the client can accept), Content-Type (format of the body content), Cache-control (cache control), etc.
• Body Entity: When using POST, PUT, etc., the client usually needs to send data to the server, which is stored in the request body.

3. Sending the HTTP Request

After adding HTTP headers, the message will pass through the transport layer, network layer, and link layer, adding TCP header, IP header, and MAC header respectively.

Then determine if the target address and the local machine are in the same local area network. If so, use the ARP protocol to obtain the target MAC address and place it in the MAC header; if not, place the gateway MAC address in the MAC header.

After the gateway receives the packet, it extracts the target IP address, finds the next-hop router based on the routing protocol, obtains the next-hop router’s MAC address, and sends the packet forward. This continues until reaching the target local area network.

The last-hop router finds the target address is in its local area network, uses the ARP protocol to obtain the target address’s MAC address, and then sends the packet to the target machine.

When the target machine receives the packet, it ascends layer by layer, parsing the MAC header, IP header, TCP header, and finally sending it to the HTTP server process corresponding to the port number in the TCP header, which then returns the web page to the client.

4. Construction of HTTP Response

The HTTP response message includes:

• Status Line: Includes version, status code, phrase information; status codes include 200 (OK), 404 (Not Found), 503 (Service Unavailable), etc.
• Headers: Includes Retry-After (can retry after a certain time), Content-Type (format of the body content), etc.
• Body Entity: The format of the returned data, including HTML, JSON, etc.

6. How DNS Works

DNS servers include three types: root domain, top-level domain, and authoritative domain:

• Root Domain DNS Server: Returns the IP address of the top-level domain DNS server.
• Top-Level Domain DNS Server: Returns the IP address of the authoritative DNS server.
• Authoritative Domain DNS Server: Returns the corresponding host’s IP address.

The client first checks its local cache for the domain name’s corresponding IP address. If found, it returns directly; if not, it sends a request to the local DNS server.

The local DNS server checks for cached data; if not found, it sequentially requests the root domain server, top-level domain server, and authoritative domain server, ultimately obtaining the domain name’s corresponding IP address.

7. Principle of HTTPS Encryption

HTTPS generates keys through asymmetric encryption, then uses this key for symmetric encryption of transmitted data. This combination of symmetric and asymmetric encryption ensures both transmission security and efficiency.

The private key of asymmetric encryption is not transmitted over the Internet, ensuring its confidentiality. However, the public key is public and may be impersonated, so it needs to be verified through certificates and authoritative agencies.

The server must apply for a digital certificate from a CA (Certificate Authority). The CA uses its private key to generate a digital signature of the server’s personal information and public key, then forms a digital certificate together with the server’s personal information and public key.

When the client initiates a request, the server sends the digital certificate to the client. The client uses the CA’s public key to decrypt the digital signature to generate a digest of the server’s information, which it then compares with the digest in the certificate to verify if the digital certificate is a legitimate certificate issued by the CA.

However, the CA’s public key may also be impersonated. To verify the legitimacy of the CA’s public key, the CA must also have its own digital certificate, signed by a more trusted and authoritative CA, thus forming a multi-level certification authority. Client devices come pre-installed with a portion of the root certificates from authoritative agencies.