<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:media="http://search.yahoo.com/mrss/"><channel><title><![CDATA[华斧网络科技]]></title><description><![CDATA[专注企业全球化，为互联网再加速]]></description><link>http://blog.axesdn.com/</link><image><url>http://blog.axesdn.com/favicon.png</url><title>华斧网络科技</title><link>http://blog.axesdn.com/</link></image><generator>Ghost 2.6</generator><lastBuildDate>Fri, 27 Sep 2024 23:30:26 GMT</lastBuildDate><atom:link href="http://blog.axesdn.com/rss/" rel="self" type="application/rss+xml"/><ttl>60</ttl><item><title><![CDATA[TCP Fast Open - Cutting edge tool for global deployment of TCP applications]]></title><description><![CDATA[<p>TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte stream-based transport layer communication protocol that is used in client-to-server transport protocols for various enterprise applications popularly. As we all know, the TCP protocol establishes a connection through a "three-way handshake." This method of establishing a connection prevents the wrong connection</p>]]></description><link>http://blog.axesdn.com/tcp-fast-open-a-tool-for-global-deployment-of-tcp-applications/</link><guid isPermaLink="false">5d92dececaa2020001fb6ebe</guid><dc:creator><![CDATA[Xiaoliang Liu]]></dc:creator><pubDate>Tue, 01 Oct 2019 06:18:26 GMT</pubDate><media:content url="http://blog.axesdn.com/content/images/2019/10/cutting-edge.png" medium="image"/><content:encoded><![CDATA[<img src="http://blog.axesdn.com/content/images/2019/10/cutting-edge.png" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"><p>TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte stream-based transport layer communication protocol that is used in client-to-server transport protocols for various enterprise applications popularly. As we all know, the TCP protocol establishes a connection through a "three-way handshake." This method of establishing a connection prevents the wrong connection from being generated.</p><p><strong>The process of TCP three-way diagram</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><p>1) The client sends a SYN (SEQ=M) message to the server and enters the SYN_SEND state.</p><p>2) The server receives the SYN message, responds to a SYN (SEQ=N) ACK (ACK=M+1) message, and enters the SYN_RECV state.</p><p>3) The client receives the SYN packet from the server, responds with an ACK (ACK=N+1) message, and enters the Established state.</p><p>After the three-way handshake is completed, the TCP client and the server successfully establish a connection and start transmitting data.</p><p>As it shows in above diagram, a time of 2 RTTs is needed from client request to starting data transmission. For example, the server is in New York, USA, and the client is in Beijing. Assume that the client-to-server is connected by a dedicated line (MPLS), and the end-to-end latency is 230 ms. In this environment, the client needs 230 ms*2=460 ms from initiating the request to receiving data. The client-to-server data interaction (especially the web application) of most enterprise applications is a TCP short connection. In this scenario, the time used for TCP connection establishment is huge, and the application experience of the client is greatly affected.</p><p>To solve this problem, the TFO (TCP Fast Open) protocol was proposed in 2011, and an IETF draft was formed in February 2012, which was finally released as RFC 7413 in December 2014. Reference: <a href="https://en.wikipedia.org/wiki/TCP_Fast_Open">https://en.wikipedia.org/wiki/TCP_Fast_Open</a></p><p><strong>TCP Fast Open diagram</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image-1.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><p>As it shows in above figure, TFO can accelerate the TCP handshake process and reduce the delay of application response from 2 RTT to 1 RTT. However, TFO requires to be deployed on both server and client to take effictive, this increase the complexity of  enterprise application deployment, so most enterprise applications have not been developed based on this protocol.</p><p>AXESDN's TCP optimization suite deploys TFO as an optimization feature on the core network cloud. Enterprise users do not have to consider deploying TFO in their own applications, and they can have the application acceleration experience brought by TFO with AXESDN SD-WAN. Now, AXESDN's NaaS (Global Smart Networking) and ADAS (Global Application Acceleration) support TFO, and no software changes are required for clients and servers.</p><p><strong>TFP deployment on AXESDN Cloud</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image-2.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><p><strong>NaaS (Global Smart Networking) </strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image-3.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><p><strong>ADAS (Global Application Acceleration)</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image-4.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><p><strong>Test comparison (Akamai vs. AXESDN)</strong></p><p>Test Application server: The source server (169.46.141.xx) is deployed in Dallas, USA, and the application protocol is http.<br>Test tool: Cloudwise (监控宝)<br>Test client: Liaoning Dalian Unicom, Henan Kaifeng Unicom, Jiangsu Changzhou Telecom, Shandong Jinan Unicom, Shaanxi Xi'an Telecom</p><p>Test results (take the average test result of all test client)</p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/10/image-5.png" class="kg-image" alt="TCP Fast Open - Cutting edge tool for global deployment of TCP applications"></figure><ol><li>Akamai (green) vs. AXESDN TFO off (purple), from overall statistic, the application response time is equivalent, but AXESDN is more stable than Akamai</li><li>Akamai (green) vs. AXESDN TFO on (blue), obviously, the application response time is accelerated by AXESDN significantly, which is much more lower and stable than Akamai</li></ol><p>After AXESDN turned on the TFO function, the application performance was significantly improved for user in China mainland to access the application deployed on the Dallas server.</p><ol><li>AXESDN TFO ON vs. OFF, application performance can be acclerated about 30%</li><li>AXESDN TFO ON vs. akamain application performance can be acclerated 30% to 100%.</li></ol><p>Please contact sales@axesdn. for a POC</p>]]></content:encoded></item><item><title><![CDATA[SD-WAN VS MPLS -- Battle of the last mile]]></title><description><![CDATA[<p>While telecom operators are increasing their infrastructure investment and Internet performance has improved in many regions, most companies are still reluctant to completely replace their MPLS infrastructure with a more cost-effective Internet IPVPN. For saving more budget for MPLS deployment for business-critical applications, Internet IPVPN is usually used to carry</p>]]></description><link>http://blog.axesdn.com/sd-wan-vs-mpls-battle-of-the-last-mile/</link><guid isPermaLink="false">5d4f00b7caa2020001fb6e45</guid><dc:creator><![CDATA[Xiaoliang Liu]]></dc:creator><pubDate>Sun, 11 Aug 2019 06:28:24 GMT</pubDate><media:content url="http://blog.axesdn.com/content/images/2019/08/PIC2.jpg" medium="image"/><content:encoded><![CDATA[<img src="http://blog.axesdn.com/content/images/2019/08/PIC2.jpg" alt="SD-WAN VS MPLS -- Battle of the last mile"><p>While telecom operators are increasing their infrastructure investment and Internet performance has improved in many regions, most companies are still reluctant to completely replace their MPLS infrastructure with a more cost-effective Internet IPVPN. For saving more budget for MPLS deployment for business-critical applications, Internet IPVPN is usually used to carry non-critical applications, to improve the cost efficiency of enterprise WAN. The reason behind is the IT managers have relied on MPLS for last 20 years and they are very concerned about the network stability and network performance which MPLS is good at. </p><p>As you may know, for stable network performance, some SD-WAN service providers can provide a private core network similar to MPLS, but for flexibility, SD-WAN chooses internet for last mile (from customer site to SD-WAN core) connectivity, this is different with MPLS which use private network for last mile connectivity. Therefore, the deployment method of SD-WAN has been criticized by many people, saying that it is “not as stable as MPLS” because SD-WAN use internet as the last mile connectivity. And "stability" is the most critical consideration for IT managers to make network solution selection decisions.</p><p>It can be seen that internet give SD-WAN the advantage (flexibility) and also the disadvantage (Instability). How the SD-WAN service provider solve disadvantage of last mile internet connectivity has become a key capability of a SD-WAN service provider. Regarding the solution, on the one hand, from resource perspective, it selects high-quality BGP Internet as the ISP of SD-WAN POP, and on the other hand, it is the network optimization technology which different with each other.</p><p>In this article, we will focus on the network optimization technology of the AXESDN, which is the secret that AXESDN can provide super better application performance than MPLS based on internet connectivity of the last mile. It is also one of the main reasons why customers choose to use AXESDN SD-WAN as the enterprise WAN connection solution.</p><p><strong>Last mile connectivity solution of AXESDN</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/08/--.jpg" class="kg-image" alt="SD-WAN VS MPLS -- Battle of the last mile"></figure><p>AXESDN leverages the following key technologies to reduce network packet loss caused by last-mile Internet access, and the impact of latency jitter on application performance:</p><p><strong>Redundancy</strong>: AER redundancy and link redundancy</p><p><strong>Link selection</strong>: The system actively monitors the packet loss rate and latency of each link and selects the link with the best performance for application traffic.</p><p><strong>Link aggregation</strong>: Sends traffic simultaneously through the primary link and the secondary link. If one of the links has packet loss, another link carries the same packet to the peer. This solution can significantly improve application performance when link packet loss.</p><p><strong>TCP optimization</strong>: Using technologies of “TCP retransmission optimization”, “TCP ACK mechanism optimization”, “TCP congestion control optimization”, and “Real transparent TCP proxy” to make sure the best TCP transmission performance for applications.</p><p>We did a test to demonstrate the effects of the above technology deployment.</p><p><strong>Test environment topology (network latency is 180ms)</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/08/image.png" class="kg-image" alt="SD-WAN VS MPLS -- Battle of the last mile"></figure><p><strong>Test case 1</strong>: [Without optimization] Bandwidth cap is 10Mbps, network packet loss rate 6%, Windows to Ubuntu file transfer (303MB)</p><p><strong>Test result</strong>: Although the bandwidth cap is 10 Mbps, the bandwidth utilization of the application is extremely low due to packet loss. The maximum bandwidth of the file transfer is 547 Kbps, and the average bandwidth usage is 136 kbps. (Note: Speed in below gif is MB/s, and the speed in screenshot is Mbps.)</p><div style="width:100%;height:0;padding-bottom:55%;position:relative;"><iframe src="https://giphy.com/embed/WP3lo1ALy38Tv1XgKF" width="100%" height="100%" style="position:absolute" frameborder="0" class="giphy-embed" allowfullscreen></iframe></div><p><a href="https://giphy.com/gifs/WP3lo1ALy38Tv1XgKF">via GIPHY</a></p><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP------_final-2.png" width="1663" height="928" alt="SD-WAN VS MPLS -- Battle of the last mile"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP-------2.png" width="1024" height="379" alt="SD-WAN VS MPLS -- Battle of the last mile"></div></div></div></figure><p><strong>Test case 2</strong>: [Without optimization] Bandwidth cap is 10Mbps, no packet loss on the network, Windows to Ubuntu file transfer (303MB)</p><p><strong>Test result</strong>: Although the bandwidth cap is 10Mbps, the limitation of the TCP window by the old TCP protocol stack causes the bandwidth utilization of the application to be related to the network delay. The higher the network latency, the lower the transmission speed, so in this environment, the maximum bandwidth occupied by the file transmission is 3Mbbps (less than 1/3 of the upper bandwidth limit), and the average bandwidth usage is 1.3Mbps. (Note: Speed in below gif is MB/s, and the speed in screenshot is Mbps.)</p><div style="width:100%;height:0;padding-bottom:68%;position:relative;"><iframe src="https://giphy.com/embed/VDZ7J92btN8cd591Dx" width="100%" height="100%" style="position:absolute" frameborder="0" class="giphy-embed" allowfullscreen></iframe></div><p><a href="https://giphy.com/gifs/VDZ7J92btN8cd591Dx">via GIPHY</a></p><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP-------_final.png" width="1457" height="924" alt="SD-WAN VS MPLS -- Battle of the last mile"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP-------.png" width="897" height="374" alt="SD-WAN VS MPLS -- Battle of the last mile"></div></div></div></figure><p><strong>Test case3</strong>: [with optimization] bandwidth cap is 10Mbps, network packet loss rate of 6%, Windows to Ubuntu file transfer (303MB)</p><p><strong>Test result</strong>: The maximum bandwidth for file transfer is 10Mbps, and the average bandwidth usage is 2.3Mbps. (Note: Speed in below gif is MB/s, and the speed in screenshot is Mbps.)</p><div style="width:100%;height:0;padding-bottom:68%;position:relative;"><iframe src="https://giphy.com/embed/cNeom94aFxFVeiddpr" width="100%" height="100%" style="position:absolute" frameborder="0" class="giphy-embed" allowfullscreen></iframe></div><p><a href="https://giphy.com/gifs/cNeom94aFxFVeiddpr">via GIPHY</a></p><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP------_final-3.png" width="1482" height="949" alt="SD-WAN VS MPLS -- Battle of the last mile"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/08/--_TCP-------3.png" width="895" height="383" alt="SD-WAN VS MPLS -- Battle of the last mile"></div></div></div></figure><p><strong>Summary of test results:</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/08/image-5.png" class="kg-image" alt="SD-WAN VS MPLS -- Battle of the last mile"></figure><p>According to the above test results, it can be seen that the bandwidth utilization of case 3 (with optimization &amp; link packet loss rate 6%) is higher than that of case 2 (without optimized &amp; 0 package loss). This is the proof that AXESDN optimization technology can provide better application performance than MPLS.</p><p>For free PoC test, please send email to sales@axesdn.com</p>]]></content:encoded></item><item><title><![CDATA[How Powerchina use SD-WAN to expanse their business globally]]></title><description><![CDATA[<figure class="kg-card kg-image-card kg-width-full"><img src="http://blog.axesdn.com/content/images/2019/07/image-4.png" class="kg-image"></figure><p>With the implementation of China's B&amp;R (The Belt and Road Initiative) strategy and the establishment of the AIIB. Making the best opportunity for many of the Chinese infrastructure construction giants to expand their business oversea. As a leading company in China's water conservancy and electric power infrastructure construction</p>]]></description><link>http://blog.axesdn.com/how-powerchina-use-sd-wan-to-expanse-their-business-globally/</link><guid isPermaLink="false">5d1f0a9acac38c0001964e5f</guid><dc:creator><![CDATA[Xiaoliang Liu]]></dc:creator><pubDate>Fri, 05 Jul 2019 09:47:16 GMT</pubDate><content:encoded><![CDATA[<figure class="kg-card kg-image-card kg-width-full"><img src="http://blog.axesdn.com/content/images/2019/07/image-4.png" class="kg-image"></figure><p>With the implementation of China's B&amp;R (The Belt and Road Initiative) strategy and the establishment of the AIIB. Making the best opportunity for many of the Chinese infrastructure construction giants to expand their business oversea. As a leading company in China's water conservancy and electric power infrastructure construction industry, POWERCHINA has many branches, hydropower stations and factories in Asia Pacific and the Middle East. With the digital transformation of enterprise management and production, POWERCHINA has built its own digital platform, using IT systems and tools to improve the efficiency of operations and production. However, due to the internet performance issue (jitter and packet loss), the network connectivity between global sites and the data center have become bottlenecks of the global digital platform. The low performance of the network connectivity slow down the data transmission between clients and servers, and even caused the IT service unavailable incident frequently for remote site which area without proper telecom infrastructure. </p><p>Based on the facts, POWERCHINA reevaluated the network solution, and try to find out a perfect way to solve the connectivity issues. Leasing Line (MPLS) was an option, but also has some limitations: </p><p>1.       Overseas sites are mostly located in geographically remote areas. Local telecom operators don’t have sufficient resources, and leasing line implementation is very difficult, costly and time consuming. Many sites will be relocated or rebuilt with the progress of the construction project, and the contract period of the dedicated line is more than 12 months. Both of the cost and the flexibility are not matched with the business needs.</p><p>2.       There are no full-time IT staff at overseas sites, and local staff do not have the competence to maintain professional network equipment (switches/routers).</p><p>3.       The leasing line (MPLS) can only provide a consistent network performance (very small jitter and low packet loss rate), but the traditional transmission network does not have the TCP optimization function. Under high latency conditions, the transmission efficiency of TCP could be limited. For example, the latency of MPLS between Shandong and Dubai is about 200ms, and the maximum default value of the TCP window of the customer's server is 64KB, then the maximum transmission bandwidth of the single TCP session is 64KB/200ms*8 = 2.56Mbps. In POWERCHINA’s OA system user case, OA user needs to upload large files from client to the OA server every day, the MPLS has a limited performance improvement on this OA user case because of lacking TCP optimization function.</p><p><em>For the TCP window and its scaling principle, please refer to: http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/</em></p><p>According to the customer's pain points, we propose a solution which use AXESDN NaaS as the networking solution to quickly deploy the connectivity between global sites and the data center, then activate the AXESDN TCP optimization, network monitoring and management features on AXESDN Cloud for all the other network functions that customer need.</p><p><strong>Network topology</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/07/Network-topology.JPG" class="kg-image"></figure><p><strong>Deployment lead time: hours</strong></p><p>1.       Before the AER is delivered to the customer site, AXESDN will work with the customer to finalize an installation solution and pre-configure it in both the cloud and AER.</p><p>2.       When the local customer receives the AER, they will receive an email and also a hard copy about the “AER Installation Guide”. Local customer does not need to have an IT maintenance background. Just following the instructions to complete the connection for power cable and the network cable.</p><p>3.       After AER is powered on and the network cable is connected, the installation and configuration work has been completed theoretically. For further configuration and maintenance activity, AXESDN can do remotely. </p><p><strong>Site relocation: hours</strong></p><p>AXESDN supports on-demand billing for both bandwidth and duration. During the relocation process, the network services of the new site and the old site can work in parallel. Customer can decide when to disconnect the old site depend on their relocation progress, and don’t need to set a deadline to relocation process from network service contract perspective, because the old site can be billed per day. </p><p><strong> TCP optimization</strong></p><p>Since the customer needs to maximize the bandwidth utilization of a single TCP session, we turned on TCP segmentation optimization on AXESDN Cloud. For “Segmentation optimization”, please refer to the following picture: </p><p>Unoptimized TCP Session</p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/07/unoptimized-TCP-session.jpg" class="kg-image"></figure><p>Optimized TCP Session</p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/07/Optimized-TCP-session.jpg" class="kg-image"></figure><p>AXESDN TCP Performance Optimization technical method: </p><p>o   TCP retransmission optimization</p><p>o   TCP ACK mechanism optimization</p><p>o   TCP congestion control optimization</p><p>o   TCP real transparent proxy</p><p><strong>Implementation result：</strong></p><p>Comparison of Network performance indicator (Latency/Packet loss)</p><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-DubaiOffice-1.jpg" width="478" height="292"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-DubaiOffice-1.jpg" width="478" height="293"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-India-2.jpg" width="475" height="293"></div></div><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-India-2.jpg" width="478" height="292"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-Indonesia-1.jpg" width="478" height="292"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-Indonesia-1.jpg" width="478" height="293"></div></div></div></figure><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-Bahrain-2.jpg" width="478" height="292"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-Bahrain-2.jpg" width="477" height="293"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-DubaiFactory-2.jpg" width="478" height="292"></div></div><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-DubaiFactory-2.jpg" width="477" height="293"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/Latency-SaudiArabia-1.jpg" width="475" height="293"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/PkgLoss-SaudiArabia-1.jpg" width="478" height="292"></div></div></div></figure><p>User console: Monitor and management </p><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/----3.jpg" width="858" height="134"></div></div></div></figure><figure class="kg-card kg-gallery-card kg-width-wide"><div class="kg-gallery-container"><div class="kg-gallery-row"><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/----1-1.jpg" width="834" height="395"></div><div class="kg-gallery-image"><img src="http://blog.axesdn.com/content/images/2019/07/----2-1.jpg" width="835" height="435"></div></div></div></figure><figure class="kg-card kg-image-card kg-width-wide"><img src="http://blog.axesdn.com/content/images/2019/07/----4-1.jpg" class="kg-image"></figure><p> Comparison of transmission efficiency</p><p>The following transmission efficiency comparison is based on the actual data transmission between the customer’s Qingdao site and the Bahrain site with following conditions: (The internet is unstable, so the transmission efficiency of long-term testing on internet will be much lower than the following results)</p><p>·         Qingdao-Bahrain Internet delay 300ms, no packet loss</p><p>·         Qingdao-Bahrain AXESDN delay 200ms, no packet loss</p><p>·         Qingdao site Internet bandwidth is 100Mbps</p><p>·         Bahrain site internet bandwidth is 10Mbps</p><p>·         AXESDN allocates 4Mbps for Bahrain site access</p><p>·         Transferred file size is 50MB</p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/07/image-1.png" class="kg-image"></figure><p>As the figure, under the condition that the network end-to-end latency is 200ms, With AXESDN TCP optimization service, the file transmission can reach the cap of the bandwidth subscription (4Mbps)</p><p><strong>Customer feedback</strong></p><figure class="kg-card kg-image-card"><img src="http://blog.axesdn.com/content/images/2019/07/image-2.png" class="kg-image"></figure>]]></content:encoded></item><item><title><![CDATA[MPLS网络的优势和缺点]]></title><description><![CDATA[<h1 id="it">IT全球业务场景网络解决方案的现实考量</h1>
<p><img src="http://blog.axesdn.com/content/images/2018/11/Pros-And-Cons-blog.jpg" alt="Pros-And-Cons-blog"></p>
<p>近来，越来越多的跨国企业都面临着是否放弃MPLS而转向其他替代方案的决定。 不幸的是，目前并没有一个解决方案能适合所有的场景。而答案在很大程度上取决于该企业的IT架构现状以及将来的目标。</p>
<p>在MPLS在90年代进入市场时，CIO以及IT专业人士都把它视为在蓬勃发展的数字时代驱动业务增长的途径。时过境迁，当年MPLS网络所支持的系统及应用通过近20多年的迅猛发展，其对网络的的需求已经大大超出了MPLS的能力范围，为了适应信息技术本身的高速发展，以及信息技术在企业生产环节中所扮演的越来越重要的地位，一种用以替代MPLS网络的更先进的网络技术的出现已经刻不容缓。</p>
<p>那些二十多年前的MPLS的支持者现在也开始考虑是否替换掉MPLS, 部署一种新的能够适应业务的全球快速扩展及调整，以及能更好的支持云应用和移动办公团队的网络解决方案。</p>
<p><img src="http://blog.axesdn.com/content/images/2018/11/MPLS-NETWORK-PROS-AND-CONS_1.png" alt="MPLS-NETWORK-PROS-AND-CONS_1"></p>
<p>用户场景的多样性使得IT基础设施能够满足上层应用多样性的需求。企业业务的快速发展也需要IT基础设施能提供相应的灵活的支持。MPLS在全球网络覆盖已经传输稳定性方面，仍然具有一些优势。但是面临越来越多样化的用户场景以及越来越迅速的业务发展变化，MPLS已经开始成为影响企业业务发展的IT基础设施瓶颈。所以IT管理者们不得不开始把眼光看向新的网络技术，例如SD-WAN。</p>
<p>IT管理者们该如何决策呢？与其他任何重要的商业决策一样，只有权衡各个技术方案的优缺点，并结合业务需求以及可承受成本等因素综合考虑后，才能选择是否坚持使用MPLS或是迁移到新技术平台。在权衡方案优缺点方面，希望以下信息能够帮助IT管理者们理清思路：</p>
<p><strong>MPLS优势</strong></p>
<p>以下是企业仍然采用或保留MPLS网络解决方案的一些原因：</p>
<p>•	MPLS是一项成熟可靠的技术，20多年来一直为企业提供私有网络组网服务。<br>
•	MPLS是一种高质量的网络连接方案，性能一致，正常情况下几乎无丢包，固定网络延迟和低抖动。<br>
•	对于对成本不敏感且不需要更高级别功能的企业来说，这是安全的选择。</p>
<p><strong>MPLS 缺点</strong></p>
<p>另一方面，这里有一些MPLS的缺点可供参考：</p>
<p>•	MPLS提供的是点到点私网连接，无法连接到发布在互联网（IP或域名）上的应用及服务。</p>]]></description><link>http://blog.axesdn.com/mplswang-luo-de-you-shi-he-que-dian-itquan-qiu-ye-wu-chang-jing-wang-luo-jie-jue-fang-an-de-xian-shi-kao-liang/</link><guid isPermaLink="false">5bffcb85d831910001f5b1d5</guid><dc:creator><![CDATA[Xiaoliang Liu]]></dc:creator><pubDate>Sun, 19 Aug 2018 17:23:27 GMT</pubDate><content:encoded><![CDATA[<h1 id="it">IT全球业务场景网络解决方案的现实考量</h1>
<p><img src="http://blog.axesdn.com/content/images/2018/11/Pros-And-Cons-blog.jpg" alt="Pros-And-Cons-blog"></p>
<p>近来，越来越多的跨国企业都面临着是否放弃MPLS而转向其他替代方案的决定。 不幸的是，目前并没有一个解决方案能适合所有的场景。而答案在很大程度上取决于该企业的IT架构现状以及将来的目标。</p>
<p>在MPLS在90年代进入市场时，CIO以及IT专业人士都把它视为在蓬勃发展的数字时代驱动业务增长的途径。时过境迁，当年MPLS网络所支持的系统及应用通过近20多年的迅猛发展，其对网络的的需求已经大大超出了MPLS的能力范围，为了适应信息技术本身的高速发展，以及信息技术在企业生产环节中所扮演的越来越重要的地位，一种用以替代MPLS网络的更先进的网络技术的出现已经刻不容缓。</p>
<p>那些二十多年前的MPLS的支持者现在也开始考虑是否替换掉MPLS, 部署一种新的能够适应业务的全球快速扩展及调整，以及能更好的支持云应用和移动办公团队的网络解决方案。</p>
<p><img src="http://blog.axesdn.com/content/images/2018/11/MPLS-NETWORK-PROS-AND-CONS_1.png" alt="MPLS-NETWORK-PROS-AND-CONS_1"></p>
<p>用户场景的多样性使得IT基础设施能够满足上层应用多样性的需求。企业业务的快速发展也需要IT基础设施能提供相应的灵活的支持。MPLS在全球网络覆盖已经传输稳定性方面，仍然具有一些优势。但是面临越来越多样化的用户场景以及越来越迅速的业务发展变化，MPLS已经开始成为影响企业业务发展的IT基础设施瓶颈。所以IT管理者们不得不开始把眼光看向新的网络技术，例如SD-WAN。</p>
<p>IT管理者们该如何决策呢？与其他任何重要的商业决策一样，只有权衡各个技术方案的优缺点，并结合业务需求以及可承受成本等因素综合考虑后，才能选择是否坚持使用MPLS或是迁移到新技术平台。在权衡方案优缺点方面，希望以下信息能够帮助IT管理者们理清思路：</p>
<p><strong>MPLS优势</strong></p>
<p>以下是企业仍然采用或保留MPLS网络解决方案的一些原因：</p>
<p>•	MPLS是一项成熟可靠的技术，20多年来一直为企业提供私有网络组网服务。<br>
•	MPLS是一种高质量的网络连接方案，性能一致，正常情况下几乎无丢包，固定网络延迟和低抖动。<br>
•	对于对成本不敏感且不需要更高级别功能的企业来说，这是安全的选择。</p>
<p><strong>MPLS 缺点</strong></p>
<p>另一方面，这里有一些MPLS的缺点可供参考：</p>
<p>•	MPLS提供的是点到点私网连接，无法连接到发布在互联网（IP或域名）上的应用及服务。<br>
•	AWS, Azure, GCP以及阿里云等公有云在全球各个区域都有不同的直连合作伙伴，所以目前还没有任何一家 MPLS运营商有能力可以连接到所有公有云的所有区域（需要在不同区域寻找合作伙伴资源）。<br>
•	MPLS的部署及带宽大小的变更需要很长时间，尤其是办公地点分布在不同的州或国家时。 每个新站点的部署可能需要3-6个月的时间。<br>
•	MPLS只是网络连接服务，它所提供的是稳定的网络连接，所以如果业务需要网络优化（3-7层），则需要安装网络优化的硬件，这在本来已经很昂贵的MPLS方案的基础上，又增加了额外的成本。<br>
•	MPLS运营商都需要很大的前期资本投入用于网络基础设施建设，且在单个项目实施上，也需要进行第一及最后一公里的网络铺设，所以MPLS服务的合同最短为12个月，且费用昂贵。</p>
<p>权衡方案的优缺点是IT管理者选择正确网络解决方案的第一步，但它不是该过程中的唯一步骤。企业网络作为IT基础设施的一个重要组成部分，是一项重大的投资，所以应该结合企业未来3-5年的业务发展来确定网络建设的目标，由此慎重的做出决定。</p>
<p><img src="http://blog.axesdn.com/content/images/2018/11/MPLS-NETWORK-PROS-AND-CONS_4.jpg" alt="MPLS-NETWORK-PROS-AND-CONS_4"></p>
<p>请阅读AXESDN的SD-WAN<a href="http://www.axesdncom">白皮书</a>，了解组织在决定最佳网络解决方案以满足其当前和未来需求时应考虑的所有因素。</p>
]]></content:encoded></item><item><title><![CDATA[Lightning speed with your SaaS deployment and connectivity – especially the Office 365]]></title><description><![CDATA[<p><img src="http://blog.axesdn.com/content/images/2019/07/O365-2.jpg" alt="O365-2"></p>
<p>As we all known, SaaS application has made it easier for IT to distribute, manage, and update software for the global enterprise – but the simplicity of the technology does not come without caveats. With applications moving outside of data center and into the cloud, IT now must figure out ways</p>]]></description><link>http://blog.axesdn.com/lightning-speed-with-your-saas-deployment-and-connectivity-especially-the-office365/</link><guid isPermaLink="false">5bffcb85d831910001f5b1d3</guid><dc:creator><![CDATA[Xiaoliang Liu]]></dc:creator><pubDate>Wed, 18 Apr 2018 12:34:01 GMT</pubDate><content:encoded><![CDATA[<p><img src="http://blog.axesdn.com/content/images/2019/07/O365-2.jpg" alt="O365-2"></p>
<p>As we all known, SaaS application has made it easier for IT to distribute, manage, and update software for the global enterprise – but the simplicity of the technology does not come without caveats. With applications moving outside of data center and into the cloud, IT now must figure out ways to optimize connectivity and performance over the enterprise WAN.</p>
<p>Office 365, which is delivered as-a-service, has replaced Microsoft Office. It is one of the most popular SaaS applications for enterprises worldwide and still growing each day. End users, however, can connect <strong>only via Internet</strong>, which cannot guarantee performance. Though this is such a business-critical application (especially the “Skype for business” feature), companies often vastly underprepared their network to optimize application performance. So what’s an enterprise IT team to do?</p>
<h3 id="connectingyourclienttosaasdirectlybympls">Connecting Your Client to SaaS directly by MPLS ?</h3>
<p>There is only a few SaaS providers allow customer to connect their HQ/Office to SaaS DC to accelerate the application performance. Companies like Microsoft make their SaaS applications available through its public cloud platforms – in this case, Azure – and allow customer connect from site to Azure DC with Direct Connection (ExpressRoute). But it can’t solve the connectivity issues as bellowing scenarios:</p>
<ul>
<li>Mobile users outside the location which direct connect to Azure.</li>
<li>Customer has global brunch sites</li>
</ul>
<p>In addition, SaaS applications -- especially Office 365 -- Require a WAN with WAN Optimization and adequate bandwidth. Office 365 users expect to be able to collaborate on Document/Files hosted in SharePoint in real time or host online video meeting in Skype for Business, All these applications require a stable network connection to remain productive. MPLS, however, isn’t not inherently WAN Optimized, which means IT departments have to implement WAN Optimization Hardware over MPLS and expend the resources to maintain them. They must also cut into the budget for additional bandwidth, which is both expensive and time-consuming to deploy.</p>
<p>When the connection is bad, due to latency, packet loss or jitter, the application performance will be affected for sure, which will reduce working efficiency a lot.</p>
<p>A good SaaS deployment starts with first recognizing that MPLS and/or the public internet will not lead to optimal outcomes for your global workforce, and then deploying smart, next-generation solutions that were built with this particular cloud environment in mind. (Such as AXESDN SD-WAN)</p>
<h3 id="choosingaproperconnectivitysolutionforyoursaasdeployment">Choosing a proper connectivity Solution for your Saas Deployment</h3>
<p>When you’re considering a SaaS deployment, here are the questions you must ask yourself and your strategic business partners in the feasibility study stage:</p>
<ol>
<li>Where the SaaS end client locate, or will locate? Are we going to test the connectivity to SaaS from each of the location? How to record and measure the connectivity and SaaS application performance?</li>
<li>Do we have to spend time and money to build up a global MPLS private network with reserved redundant bandwidth to optimize the SaaS application performance and also deal with the burst traffic?</li>
<li>Is WAN optimization hardware is necessary, and, if it is, do we have to postpone the SaaS deployment until we finish the WAN optimization hardware deployment?</li>
</ol>
<p>If the upon questions give you pause, then you might want to try answering them with AXESDN’s global SD-WAN instead.</p>
<p>AXESDN’s global SD-WAN is the only SD-WAN which build by telco-carrier class SDN/NFV technology, global private network with 32 POPs (by the end of Mar. 2019).</p>
<p>NaaS (Network as a service) is a product we build on the global SD-WAN platform, you can connect all your global sites (Public Cloud VPC, SaaS, IDC, Headquarter, Branch Office or Mobile Client) together via encrypted tunnel over internet for last mile. NaaS solution can ensure your SaaS application performance anywhere in the world by its global private network and embedded TCP and application optimization features.</p>
<p><img src="http://blog.axesdn.com/content/images/2018/11/image2-19.png" alt="image2-19"></p>
<p>AXESDN’s NaaS for SaaS acceleration has bellowing unique advantages:</p>
<ol>
<li>Box-less (no need to implement hardware in the workspace)</li>
<li>Pay-as-you-go (no need to do accurate bandwidth estimation)</li>
<li>Can be deployed in days</li>
<li>Embedded WAN optimization and QoS</li>
<li>Embedded security</li>
<li>Support dynamic routing protocol (OSPF, BGP etc…)</li>
<li>Visibility (real-time bandwidth statistic)</li>
<li>Custom alarm/notification</li>
</ol>
<p>If you do need to scale (upgrade/downgrade) your bandwidth, it only takes a few hours to do so. We scale to meet your needs in different geographies. We’ve also already peered with major SaaS (Office365, Salesforce, Dropbox…etc) access points. That means users on the AXESDN network already have a pre-existing route into these SaaS access points, AXESDN will maintain the route table while SaaS operator do changes.</p>
<p>When it comes to deploying a SaaS application, you do have to think differently – not about how you might optimize your legacy WAN for a new technology, but about how you can employ next-generation WAN technology to improve your end users’ experience, productivity, and, ultimately, results.</p>
<p>AXESDN’s Global SD-WAN really provide the IT management an alternative/better solution for global WAN connectivity in the Cloud stage.</p>
<p>Contact us: <a href="mailto:sales@axesdn.com">sales@axesdn.com</a> to get more info.</p>
]]></content:encoded></item></channel></rss>