"heavy" Mobile network Performance Disclosure (next)--network protocol and Performance Improvement practice

Last Update:2016-01-09 Source: Internet

Author: User

Tags failover dns entry

Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞

Performance of network protocolsNow it's our turn to actually control things.The performance of network processing is not proportional to the addition of delay Time. This is because the intrinsic operation of most network protocols is bidirectional information exchange.The remainder of this chapter focuses on understanding why these exchanges of information are generated and how to reduce or even eliminate the frequency of their exchange.Figure 3: Network protocolTcpTransmission Control Protocol (TCP) is a connection-oriented, ip-based transport Protocol. The Error-free Duplex communication channel under the influence of TCP is indispensable for other protocols, such as HTTP or tls.TCP shows a lot of two-way communication that we need to avoid as much as Possible. Some of these can be replaced by the use of extended protocols such as the TCP Fast open protocol, while others can be minimized by adjusting system parameters, such as initializing congested forms. In this section, we will explore both methods to provide the background of some TCP internal components at the same time . TCP Fast OpenInitializing a TCP connection convention requires 3 times of information exchange, which is what we call the 3-time Handshake.TCP Fast Open (TFO) is an extension of TCP that eliminates round-trip delays during the usual handshake.TCP the three handshake negotiation operations on the client and the server make it possible for both parties to make robust two-way communication. The most initial SYN information (synchronous Information) represents the connection request of the client, and assuming that the server accepts the request, it returns a Syn-ack message (synchronizing and receiving the message); The client sends an ACK message to answer the Server. At this point, a logical connection is established and the client is able to send the Data. In this case you will notice that at least one RTT delay was introduced during the 3 handshake, which is very good. Figure 4:TCP3 Second handshakeFrom a traditional point of view. There is no other way to avoid the delay caused by a TCP3 handshake other than to recycle the Connection. however, such ideas occur as the introduction of the TCP Fast Open IETF specification Changes.TFO agree that the client sends data before the logical connection is Established. This actually negates the round-trip delay in the 3-time handshake. The cumulative effect of this optimization is Impressive. According to Google's survey, TFO can reduce the loading time of page 40%. Although this specification is only a draft, TFO has been supported by the mainstream browser (above Chrome22) and the platform (Linux3.6 above), and other vendors have pledged to fully support it in the near Future. TCP Fast Open is a correction to the 3 handshake protocol, which agrees to have a small amount of data payload (such as HTTP requests) within the synchronous message (SYN messages). This valid responsibility is passed to the application server, otherwise the connection handshake is complete .Earlier expansion scenarios like TFO finally failed because of security issues. TFO uses security tokens or cookies to solve the Problem. This means that the client is divided into security tokens (tooken) during the traditional TCP connection handshake, and the security token is expected to be included in the SYN message of the TFO optimization Request.For the use of tfo, here are some small warnings.The most notable of these is the lack of idempotent guarantees for data requested in the initialized SYN Message. Although TCP guarantees repeated packets (recurring occurrences), It is ignored by the Recipient. however, This guarantee does not apply to the handshake process of the Connection.The solution is now being standardized in the draft specification, but at the same time TFO can still be safely applied to idempotent processing. Initial congestion FormThe initial congestion form is a configurable item of TCP and has a huge potential to accelerate small network transactions.The recent IETF specification facilitates the setup of the usual initial congestion form to grow to 3 message segments (such as packets) to 10 segments. The proposal is based on a wide range of research conducted by google, which proves that the setting of this parameter has an average 10% improvement in Performance.But suppose the congestion form (cwnd) of TCP is not Described. The purpose and potential impact of such a setup will not be truly understood.When operating on an unreliable network, TCP guarantees client and server Reliability. This is equivalent to a promise that all data sent out will be received, or at least appear to Be. , packet loss is the biggest obstacle to meeting reliability Requirements. This requires detection, correction, and Prevention.TCP a positive response mechanism was adopted to detect the loss of Packets. That is, every packet sent out should be answered by its intended receiver, assuming that no answer means that the packet is lost during Transmission. In the process of waiting for confirmation, the data transmission packet is guaranteed to exist in a special buffer, that is, the congestion form. When this buffer is stuffed, an event called CWnd depletion occurs, and all transmissions stop until the receiver answers and frees up the space to send many other packets.These events are critical in TCP Performance.In addition to network bandwidth limitations, TCP throughput is essentially limited by the frequency of CWnd depletion Events. This may be related to the size of the congested form. When TCP performance peaks, a congestion flush is required to adjust the current network state: congested forms are too big to add the risk of network congestion--excessive congestion in the network condition adds a lot of packet loss, and too little precious network bandwidth will not be fully exploited.logically, the more you know about the network situation, the more you can choose the best congestion form Size.The reality is that key network attributes, such as capacity and latency, are very difficult to measure and constantly changing.also, it would be more complicated to assume that an internet-based TCP connection would need to traverse many networks.Because of the lack of means to accurately determine the size of the network capacity, instead of TCP through network congestion to determine the size of the congested form.When TCP discovers that a packet is missing, it expands the size of the congested form, suggesting that a network somewhere down the line cannot handle the current transfer Rate.By adopting such congestion avoidance mechanisms, TCP finally minimizes the CWnd depletion event to some extent it consumes the allocated capacity for all Connections. So now, finally, We have achieved the Goal. Explains the importance of initial congestion form Parameters.Network congestion can only be measured by dropping packets.A new or spare connection because there is not enough packet loss data to justify creating the optimal size of the congested form. TCP takes a sensible approach to starting with the size of a congested form with a possible minimum of network Congestion. This initially means that you need to set up 1 shards (about 1480 bytes), and sometimes this is Recommended. And later experiments will demonstrate that a setting of up to 4 is also valid. In practice you also usually find that the initial congestion form is set to 3 message segments (approximately 4kb).The initial congestion form is not conducive to small network transaction processing. This effect is very easy to explain. In the table, under the 3 message segment Settings. CWnd runs out of time after sending 3 packets or 4k of Data. If the packet is sent continuously, the response will not arrive before any agreed round trip time (rtt), and if the RTT is 100ms, then the effective transfer rate is only a poor 400 bytes/second. Although TCP adjusts its own congestion form to take full advantage of the effective capacity, it will be very slow at the Start. In fact, such a way is called slow start.To reduce the performance impact of slow start on smaller downloads, it needs to evaluate the risk return of the initial congestion form Again. That's exactly what Google did, and it found that setting the initial congestion form to 10 segments (about 14kb) would achieve maximum throughput in the smallest network congestion scenario. The real world also proves that this setting can reduce the loading time of page 10% in total, and the round-trip delay of the connection will be improved greatly.It is also not easy to change the default value of the initial congestion form. Under most server operating systems, a system-level configuration can only be set by a privileged user, and this is a very small number of applications that cannot even be configured with a client without Permission. It is important to note that a larger initial congestion form can speed up the download on the server side, while the client can speed up the Upload. Assuming the inability to change this setting on the client means that special effort should be made to reduce the size of the request Payload.Hypertext Transfer ProtocolThis section discusses techniques for reducing high round-trip latency in Hypertext Transfer Protocol (HTTP) PERFORMANCE.KeepAliveKeepAlive is an HTTP convention that agrees to synchronize successive HTTP requests to use the same TCP Connection. At least one 3-time handshake required by a single-group round-trip request can be avoided, saving dozens of or hundreds of milliseconds per Request. deeper, KeepAlive Another additional but not mentioned advantage is that it retains the current TCP congestion form size between requests, which results in fewer CWnd depletion events Occurring.Figure 5:http PipeliningIn fact, a pipeline distributes network latency across HTTP transactions in a network round-trip.For example, 5 pipeline HTTP requests that are connected by a 100-millisecond RTT will produce an average round trip delay of 20 milliseconds, under the same conditions. This average delay of 10 pipeline requests is reduced to 10 milliseconds.however, http pipeling has obvious drawbacks that prevent it from being widely used, which is the impact of historically misaligned HTTP proxy support and Denial-of-service attacks. Secure Transport Layer ProtocolTransport Layer Security (Transport layer Security,tls) is a session-oriented network protocol that agrees to securely exchange sensitive information on public networks . Although TLS is effective in terms of secure communications. however, its performance will degrade under high latency networks.TLS the use of a complex handshake protocol consists of two exchange Client-service-side Information. This is why a tls-secured HTTP transmission is noticeably slower. Usually. Discovering a TLS slow is actually complaining about the delay of multiple round trips in its handshake protocol. Figure 6:dns Querytypically, The main platform provides a cache implementation to avoid frequent DNS Queries. The semantics of the DNS cache are easy: each DNS response includes a time-to-live (time-to-live,ttl) attribute to declare how long the result will be Cached. The TTL range is usually between a few seconds and a few days, but usually a few minutes.A low TTL value. typically, under one minute, it is used to affect load distribution or to reduce the time of server replacement or ISP Failover.Refresh failedHighly available systems often rely on redundant infrastructure hosts in their IP rooms.A DNS entry with a low TTL value can reduce the time the client points to the failed host, but at the same time it can cause a large number of additional DNS Queries. So the value of TTL should be a tradeoff between reducing downtime and maximizing client Performance.There is usually no point in reducing client performance. however, this is an exception when the server Fails. There is an easy way to solve the problem, that is, not to strictly observe the ttl, but to flush the DNS cache only if higher-level protocols such as TCP or HTTP are detected to unrecoverable Errors.Such techniques simulate TTL in most scenarios to maintain consistent DNS cache Behavior. however, This almost eliminates the performance penalty in the DNS high-availability Solution.however, It is important to note that this technical solution is incompatible with other dns-based distributed load Scenarios.Asynchronous flushAsynchronous refresh is a DNS caching method that adheres to the TTL rules that have been set but largely eliminates the delay in querying DNS frequently. In this technique, an asynchronous Dnsclient library such as C-ares is Required.This method is very easy. An expired request still returns an old result, but there is a non-clogging DNS query in the background to periodically flush the DNS Cache. This scenario assumes that a plug-in (such as Synchronous) callback is used to query each old DNS data, so this approach is almost unaffected by DNS query latency, but is still compatible with a very many dns-based failover scenarios and distributed load SCENARIOS.SummarizeTo reduce the impact of high latency on mobile networks, you need to reduce the number of network round trips that dramatically add to the latency of the mobile network . Using software optimization to focus on minimizing or eliminating round-trip protocol messages is key to overcoming this daunting performance Issue. (mobile Network Performance chapter, complete the full text.) ） 1. This paper is translated by the program Ape architecture2. This document is translated from the performance of Open Source software | Secrets of Mobile Network performance3. Reprint Please be sure to indicate this article from : program Ape Architecture (no.:archleaner )4. Many other articles please scan the code: "heavy" Mobile network Performance Disclosure (next)--network protocol and Performance Improvement practice

This article is an English version of an article which is originally in the Chinese language on aliyun.com and is provided for information purposes only. This website makes no representation or warranty of any kind, either expressed or implied, as to the accuracy, completeness ownership or reliability of the article or any translations thereof. If you have any concerns or complaints relating to the article, please send an email, providing a detailed description of the concern or complaint, to info-contact@alibabacloud.com. A staff member will contact you within 5 working days. Once verified, infringing content will be removed immediately.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

Get Started for Free

Sales Support

1 on 1 presale consultation

Chat Contact Sales
After-Sales Support

24/7 Technical Support 6 Free Tickets per Quarter Faster Response

Open a Ticket
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.

Learn More