This article is from netease Cloud community

Author: Liu Chao


As we mentioned in the last section, after a complicated process, the mobile App finally got the IP address of the SLB of the e-commerce website. Is it time to place an order?

Don’t hurry. As the saying goes, shop around. Most customers look at a lot of pictures of products before shopping, compare and contrast, and finally finally make up their minds and click the order button. Once the single button is pressed, the connection begins. The process of establishing a connection is also quite complicated, and finally needs to go through layers of encapsulation to build a complete network package. Today we’re going to look at that process.


4. Look at pictures, static resources CDN before shopping

When customers want to buy something on a shopping website, they usually go to the details page first to see if they want to buy the picture.





When deploying e-commerce applications, we usually store static resources in two places. One is in the Varnish cache behind the access layer nginx, which is usually a static page. Large, infrequently updated static images are stored in the object store. Static resources in both places are configured with CDN to deliver resources to edge nodes.

After the CDN is configured, the authoritative DNS server sets a CNAME alias for static resources, pointing to another domain name cdn.com, and returns the alias to the local DNS server.

When the local DNS server obtains the new domain name, it needs to resolve the new domain name. In this case, the DNS server is not the original authoritative DNS server, but cdn.com authoritative DNS server. This is the CDN’s own authoritative DNS server.

On this server, there is still a CNAME that points to another domain name, the global load balancer for the CDN network.

The local DNS server requests the global load balancer of the CDN to resolve the domain name. The global load balancer selects an appropriate cache server to provide services for the user and returns the IP address to the client. The client accesses the edge node and downloads resources. The cache server responds to the user request and sends the content required by the user to the user terminal.

If the cache server does not have the content the user wants, the cache server requests the content from its upper-level cache server all the way back to the site’s source server to pull the content locally.

For CDN, see CDN: Have you ever gone to the grocery Store to pick up a delivery?


5. Place an order if you like and both parties start to build connections

When you look at a lot of pictures and you really like something, you decide to order it.

E-commerce websites provide RESTful interfaces for placing orders. However, for placing orders that require confidentiality, HTTPS protocol is required to make requests.

Before all of this, the first thing to do is establish a connection.







HTTPS is based on TCP. Therefore, a TCP connection must be established first. In this example, the TCP connection is between the App on the phone and the SLB load balancer.

Although there are many routers and switches in between, TCP connections are end-to-end. TCP layer and HTTPS layer cannot see the process of intermediate packets. Although all packets are forwarded between these routers and switches at the time the connection is established, the details of forwarding will be explained in detail in the process of sending the order request, looking only at the end-to-end behavior.

For TCP connections, a three-way handshake is required to establish the connection. To maintain this connection, both parties need to maintain a state machine for the connection at the TCP layer.

Initially, both the client and the server are CLOSED. The server listens to a port and enters the LISTEN state. Then the client initiates a SYN connection and is in the SYN-sent state. The server receives a SYN from the initiated connection and ACK the client with a SYN. Then it is in syn-RCVD state.

After receiving the SYN and ACK packets from the server, the client sends the ACK packet and then enters the ESTABLISHED state. That’s because it worked. After receiving the ACK, the server is in the ESTABLISHED state because the ACK is successfully received.

After the TCP layer establishes a connection, the HTTPS layer establishes a connection. During the HTTPS exchange, the TCP layer is always ESTABLISHED.

For HTTPS, the Client sends a Client Hello message to the server to transmit TLS version information, encryption suite candidate list, and compression algorithm candidate list in plain text. In addition, there is a random number, which is used when negotiating symmetric keys.

The Server then returns a Server Hello message telling the client which protocol version, encryption suite, compression algorithm, and so on the Server has chosen to use. There is also a random number for subsequent key negotiation.

Then, the Server will give you a server-side certificate and say, “Server Hello Done, that’s all I have here.”

Of course, the client doesn’t trust the certificate, so you take the public key from the CA’s certificate from your trusted repository to decrypt the certificate of the e-commerce website. If successful, it shows that the e-commerce site is credible. This process, you may continue to back up the CA, the CA CA, CA CA CA, anyway, until a credit CA, is ok.

After the certificate is verified and the server is trusted, the Client computes a random pre-master number, sends it to the Client Key Exchange, encrypts it with the public Key in the certificate, and then sends it to the server. The server can decrypt it using the private Key.

Next, both the client and the server have three random numbers: their own, the peer, and the newly generated pre-master random number. With these three random numbers, the same symmetric key can be generated on both the client and the server.

With a symmetric key, the client can say, “Change Cipher Spec, we all use the negotiated communication key and encryption algorithm for encrypted communication.”

Then the client sends an Encrypted Handshake Message, encrypts the agreed parameters with the negotiated key, and sends it to the server for data and Handshake verification.

Similarly, the server can send “Change Cipher Spec” to say “no problem, we will use the negotiated communication key and encryption algorithm for Encrypted communication” and send the Encrypted Handshake Message as well.

When the handshake is complete, the symmetric key can be used for encrypted transmission.

The actual process of sending an order wrapped in a network packet, let’s leave that for a moment and continue the network packet story.

About TCP protocol, reference “TCP protocol (on) : because of the evil and complex, evil after good anti-easy” and “TCP protocol (below) : the west must be more evil, perseverance and wisdom difficult to kill”

For the HTTP protocol, see HTTP: How Difficult it is to Read the News. For the HTTPS protocol, see HTTPS: How Complicated it is to order food.

For RESTful apis, see jSON-based RESTful Interface Protocol: I don’t care about the process, please give me the result.


6. To send the single request network packet, go west and exit the gateway


Once the connection is established between the client and the server, the next step is to send the network packet with the order request.

The user layer sends an HTTP network packet, and because the server provides a RESTful API, the HTTP layer sends a request.