Common network protocols in browsers

Common network protocols in browsers

In fact, browsers need to deal with various network protocols to complete various WEB application functions. HTTP is only one of them. This article describes common network protocols in browsers and their relationships.

We often hear the term "TCP/IP protocol". Literally, some people think that it refers to both TCP and IP protocols. In fact, in most cases, the TCP/IP Protocol refers to the entire Internet Protocol Suite, which is collectively referred to as other protocols for communication using the IP Protocol. There are many TCP/IP protocols, and there is also a hierarchical model. Compared with the OSI model, the layer of TCP/IP is simpler, from bottom to top: physical layer, data link layer, network layer, transport layer and application layer.

An IP (Internet Protocol) is a network-layer Protocol used to select and address routes between networked hosts. 4 In IPv4 refers to the 4th versions of the TCP/IP protocol. The IP protocol is not removed until this version, so there is no separate Protocol 1-Protocol 3. Protocol 5 is a pilot protocol with little progress, so the next version of the IP protocol becomes IPv6.

TCP (Transmission Control Protocol) and UDP (User datasync Protocol) are the two most important transport layer protocols in the TCP/IP Protocol. TCP is a connection-oriented and reliable stream protocol; UDP is a non-reliable datagram protocol. Later we can see that upper-layer protocols with higher reliability requirements are generally based on TCP, while upper-layer protocols with higher requirements for high-speed transmission and real-time performance are generally based on UDP.

After introducing the lower-layer IP, TCP, and UDP protocols, let's take a look at several common application layer protocols in browsers.

HTTP and WebSocket

HTTP protocol is the most important network protocol used by browsers. It includes many versions, such as the most common HTTP/1.1, the newly released HTTP/2, there are also the transitional version SPDY implemented by Google. This article does not discuss the details of HTTP and the differences between different versions, but only intends to list the relationship between HTTP and other protocols/applications. For details, see:

+ ------------- + -------------- +

| XHR | SSE | WS |

+ ------------- + ------ ++

| HTTP |

+ ---------------------------------- + ------- +

| TLS * |

+ ------------------------------------------ +

| TCP |

+ ------------------------------------------ +

| IP |

+ ------------------------------------------ +

It can be seen that HTTP is implemented over TCP, so HTTP does not need to focus on the reliability of data transmission. A mechanism similar to sequential control and resend is already available at the transport layer. At the same time, HTTP also has some disadvantages of TCP, which brings challenges to WEB performance optimization.

Both XHR (XmlHTTPRequest) and SSE (Server-Sent Events) are data interaction functions provided by browsers, and their essence is HTTP. XHR is the core of Ajax technology and everyone is familiar with it. I will not discuss it here. The SSE concept is still new. I would like to say a few more words. We know that HTTP can only be initiated by the client and then responded by the server. The same is true for SSE, except that the server will keep the HTTP connection and send the response multiple times. It is not like sending the response once it is done. In fact, similar HTTP persistent connection technologies in WebIM have been prevalent for a long time. If you are interested, you can read this article eight years ago: Comet: HTTP persistent connection-based "server push" technology.

Since XHR and SSE are essentially HTTP connections, some common concepts in HTTP protocol, such as request methods (GET and POST ), the Request Response Header (Cookie, content encoding, Transmission Encoding, cache, etc.) still exists.

However, WS (WebSocket) is directly implemented based on TCP, and those concepts in HTTP no longer exist. It should be noted that, as shown in the preceding figure, it still depends on HTTP, because WebSocket handshake uses the HTTP Upgrade mechanism. Once the handshake is complete, subsequent data transmission is completed directly on TCP. Using HTTP as a guide, the new protocol in the browser is a common practice.

Transport Layer Security (TLS) is an option to ensure the integrity and confidentiality of data during transmission. After TLS is enabled, the URL prefix of the HTTP protocol needs to be changed from http: // to https: //; the URL prefix of the WebSocket Protocol needs to be changed from ws: // to wss ://.

DNS

DNS (Domain Name System) is a well-known Domain Name resolution service that provides conversion from Domain Name to IP address. Most Network Interactions in browsers use domain names, and the transport layer protocol requires IP addresses, so DNS is the foundation.

+ ------------------------------- +

| DNS |

+ ------------------------------- +

| TCP | UDP |

+ --------------- +

| IP |

+ ------------------------------- +

By default, DNS uses UDP to obtain query results. Generally, TCP is used only when the results exceed 512 bytes or when the DNS server is synchronized. This is because DNS is frequently used and basic, and response speed needs to be prioritized. UDP can meet the speed requirements, but also introduces problems similar to DNS cache poisoning.

WebRTC

Before WebRTC (Web Real-Time Communication) emerged, DNS was almost the only UDP-based protocol used by browsers. Among the three functions provided by WebRTC, MediaStream has nothing to do with the network. RTCPeerConnection and RTCDataChannel are both based on UDP,

+ ----------------------- + ------------------------- +

| RTCPeerConnection | RTCDataChannel |

+ ----------------------- + ------------------------- +

| SRTP | SCTP |

++ --------- + --------------------------- +

| DTLS |

+ ------------- + ----------------------------------- +

| ICE, STUN, TURN |

+ ------------------------------------------------- +

| UDP |

+ ------------------------------------------------- +

| IP |

+ ------------------------------------------------- +

This figure is complex. We will introduce it from the bottom up:

The ICE (Interactive Connectivity Establishment) framework is used to establish an effective channel between the end and the end, giving priority to direct connections, followed by STUN negotiation, and can only use TURN forwarding:

The STUN (Session Traversal Utilities for NAT) protocol solves three problems: 1) obtain the Internet IP address and port; 2) create a route entry in NAT and bind the Internet port, so that the inbound group that reaches the Internet IP address and port can find the application without being discarded. 3) defines a simple keep-alive mechanism, make sure that the NAT route entries are not deleted due to timeout. The STUN server must be deployed on the public network. You can build it on your own or use public services provided by a third party, such as Google's "stun: stun.l.google.com: 19302 」.

The TURN (Traversal Using Relays around NAT) Protocol relies on the Internet Relay Device to transmit data between the two ends. Simply put, the two ends can access the TURN service to forward messages and indirectly connect the two ends.

DTLS (Data Transport Layer Security) is essentially TLS. It only makes some minor modifications to ensure its compatibility with UDP Datagram transmission, it can be understood as udp tls.

There are two new protocols:

SRTP (Secure Real-time Transport Protocol, Secure Real-time transmission Protocol ). Real-time data such as audio and video in WebRTC is transmitted through this protocol. It is a security version of the RTP protocol.

SRTCP (Secure Real-Time Control Transport Protocol, Secure Real-Time Control transmission Protocol ). It tracks the running status of SRTP to adjust the sending rate, encoding quality, and other parameters of each stream. It is a secure version of The RTCP protocol.

The target of the other route is RTCDataChannel, which is used to transmit any application data between ends and ends. SRTP is designed to transmit media data and is not suitable for transmitting application data, so here we need a new protocol:

SCTP (Stream Control Transmission Protocol, Stream Control Transmission Protocol ). SCTP itself is a transport layer protocol that runs directly on the IP protocol, similar to TCP and UDP. However, in WebRTC, SCTP runs on DTLS. A good thing about SCTP is that it provides delivery attribute options. You can specify whether messages are ordered or out of order, whether they are reliable or partially reliable. You can also specify timeout retransmission or count retransmission policies when some are reliable.

QUIC

Google is experimenting with a new transport layer protocol: QUIC (Quick UDP Internet Connections). Its essence is to implement HTTP based on UDP, which is equivalent to TCP + TLS. From the current data, QUIC can greatly reduce the connection Time, which is achieved by simplifying the handshake step to reduce the RTT (Round-Trip Time, similar to TFO (TCP Fast Open ). If you are interested, you can view the connection. It is said that 50% of Google's own service requests from Chrome have used the QUIC protocol.

Finally, I would like to express my admiration for Google. To optimize the WEB performance, Google uses the browser (Chrome), typographical engine (Blink), JS engine (V8), image format (WebP), and transport layer protocol (tcp tfo, QUIC) the application layer protocol (SPDY) and HTML5 (starting with Google Gears) have made a lot of efforts. This is a great example of a technology company!