港服奈飞服务器1毗连不上_奈飞换不了区「奈飞服务器」

（点击上方公众号，可快速关注）

　　泉源：hrchen（@dr_hrchen）

　　链接：https://www.jianshu.com/p/3c1941acbd79

　　App网络服务的高可靠和低耽误对于无线业务稳固发展至关紧张，已往两年来我们不停在连续优化App网络服务的性能，到本年Q2竣事时根本完成了App网络服务通道管理和性能优化的阶段性目标，特此撰文总结此中的履历教导，为以后的工作打下底子。

　　携程App无线网络服务架构

　　2014年携程为无线服务开辟了MobileGateway，有两种范例：TCPGateway和HTTPGateway。TCPGateway计划用于App中Native业务网络服务，基于TCP协议之上计划了应用层协议，雷同于RPC机制。TCPGateway兼具了接入层和服务动态路由的功能，接入层的功能基于Netty实现，管理客户端的TCP长毗连大概短毗连；动态路由的功能基于Netfix开源的Zuul实现（Zuulisagatewayservicethatprovidesdynamicrouting,monitoring,resiliency,security,andmore.），可以在TCPGateway上实现服务路由、监控、反爬和用户鉴权等功能。

TCPGateway

　　每个TCP服务哀求到达TCPGateway之后，会根据报文头中的服务号，转发到后端对应的业务服务集群上，从而实现后端服务的解耦。TCPGateway到后端业务服务集群之间的转发利用HTTP协议的接口情势实现，一个TCP服务哀求的完备报文会作为HTTP哀求的Payload转发到后端业务服务集群，吸取到HTTP相应后，会将其Payload完备的返回到对应的TCP毗连中。

　　HTTPGateway用于App中Hybrid和H5Web站点的网络服务，采取HTTPRestful接口情势提供服务，其逻辑相对简单，核心是HTTP服务动态转发的功能。

HTTPGateway

　　MobileGateway的更多计划实现细节可以参考王兴朝同砚在2015上海QCon的演讲《携程无线Gateway》。

　　基于TCP协议实现App网络服务

　　带宽和耽误是影响网络服务性能的两个因素，带宽受网络通道上最小带宽的网段限定，耽误是网络包在客户端和服务端之间的来回传输时长，差别网络范例上的带宽和耽误差别非常大（见下图）。

带宽和耽误

　　我们要实现更好性能的网络服务，对于网络自身的带宽和耽误这两点而言，能做只是尽大概选择最符合的网络通道，其他只能在怎样利用网络通道上举行优化。

　　传统的非IM即时消息类App通常都是利用HTTP协议来实现网络服务的（RestfulAPI情势），携程利用TCP协议来实现，确实会增长很多开辟本钱，比方必要计划应用层协议、管理网络毗连、处理惩罚非常等，但下面几点缘故起因还是让我们终极选择基于TCP协议来实现App网络服务：

携程用户偶然会在网络环境非常差的景区利用，必要针对弱网举行特别的优化，单纯HTTP应用层协议很难实现。

HTTP哀求初次必要举行DNS域名分析，我们发现国底细况下针对携程域名的失败率在2-3%（包罗域名挟制息争析失败的环境），严峻影响用户体验。

HTTP固然是基于TCP协议实现的应用层协议，上风是封装性好，客户端和服务端办理方案成熟。劣势是可控性小，无法针对网络毗连、发送哀求和吸取相应做定制性的优化，纵然是HTTP的特性如保持长毗连KeepAlive大概管道Pipeline等都会受制于网络环境中的Proxy大概服务端实现，很难充实发挥作用。

　　基于TCP协议实现可以让我们可以或许完备控制整个网络服务生命周期的各个阶段，包罗如下几个阶段：

　　1.获取服务端IP地点

　　2.创建毗连

　　3.序列化网络哀求报文

　　4.发送网络哀求

　　5.担当网络相应

　　6.反序列化网络相应报文

　　我们的网络服务通道管理和优化工作就是从这几个方面睁开的。

　　TCP网络服务通道管理和性能优化

　　1.告别DNS，直接利用IP地点

　　假如是初次发送基于HTTP协议的网路服务，第一件事就是举行DNS域名分析，我们统计过DNS分析乐成率只有98%，剩下2%是分析失败大概运营商DNS挟制（LocalDNS返回了非源站IP地点），同时DNS分析在3G下耗时200毫秒左右，4G也有100毫秒左右，耽误显着。我们基于TCP毗连，直接跳过了DNS分析阶段，利用内置IP列表的方式举行网络毗连。

　　携程App内置了一组ServerIP列表，同时每个IP具备权重。每次创建新毗连，会选择权重最高的IP地点举行毗连。App启动时，IP列表的全部权重是雷同的，此时会启动一组Ping的操纵，根据Ping值的耽误时间来盘算IP的权重，这么做的原理是Ping值越小的IP地点，毗连后的网络传输耽误也应该相对更小。业界也有利用HTTPDNS方式来办理DNS挟制题目，同时返回最符合用户网络的ServerIP。然而HTTPDNS的开辟和摆设必要不小的开辟本钱，我们如今没有利用。

　　内置ServerIP列表也会被更新，每次App启动后会有个MobileConfig服务（支持TCP和HTTP两种网络范例服务）更新ServerIP列表，同时支持差别产物线的ServerIP列表更新。因此，传统DNS分析可以或许办理多IDC导流的功能也可以通过此方法办理。

　　2.Socket毗连优化，镌汰毗连时间

　　和HTTP协议中的Keepalive特性一样，最直接镌汰网络服务时间的优化本领就是保持长毗连。每次TCP三次握手毗连必要淹灭客户端和服务端各一个RTT（Roundtriptime）时间才华完成，就意味着100-300毫秒的耽误；TCP协议自身应对网络拥塞的SlowStart机制也会影响新毗连的传输性能。

　　携程App利用了长毗连池的方式来利用长毗连，长毗连池中维护了多个保持和服务端的TCP毗连，每次网络服务发起后会从长毗连池中获取一个空闲长毗连，完成网络服务后再将该TCP毗连放回长毗连池。我们没有在单个TCP毗连上实现Pipeline和Multiplexing机制，而是采取最简单的FIFO机制，缘故起因有二：1.简化MobileGateway的服务处理惩罚逻辑，镌汰开辟本钱；2.在服务端同时返回多个相应时，假如某个相应报文非常大，利用多个长毗连方式可以加快吸取服务相应报文速率。

　　假如发起网络服务时长毗连池中的TCP毗连都正在被占用，大概TCP长毗连的网络服务失败，则会发起一个TCP短毗连实现网络服务。这里长毗连和短毗连的区别仅仅是服务完成后是否直接关闭这个TCP毗连。

　　附：Pipeline和Multiplexing是有区别的，如HTTP/1.1支持Pipeline，客户端可否同时发送多个哀求，但是服务端返反响应时也要按照哀求的发送序次来返反响应；SPDY和HTTP/2协议支持Multiplexing，即支持相应报文的乱序返回，发送哀求和吸取相应互不干扰，因此克制了HTTP/1.1Pipeline也没能完全办理的Headoflineblocking题目。参考资料：1,2。参考资历2中提到HTTP/1.1的Pipeline特性只是部分办理了Headoflineblocking题目，由于alargeorslowresponsecanstillblockothersbehindit。

　　3.弱网和网络抖动优化

　　携程App引入了网络质量参数，通过网络范例和端到端Ping值举行盘算，根据差别的网络质量改变网络服务战略：

　　调解长毗连池个数：比方在2G/2.5GEgde网络下，会镌汰长毗连池个数为1（运营商会限定单个目标IP的TCP毗连个数）；WIFI网络下可以增长长毗连池个数等机制。

　　动态调解TCPconnection、write、read的超时时间。

　　网络范例切换时，比方WIFI和移动网络、4G/3G切换至2G时，客户端IP地点会发生变革，已经毗连上的TCPSocket注定已经失效（每个Socket对应一个四元组：源IP、源Port、目标IP、目标Port），此时会主动关闭全部空闲长毗连，现有网络服务也会根据状态主动重试。

　　4.数据格式优化，镌汰数据传输量和序列化时间

　　传输数据量越小，在雷同TCP毗连上的传输时间越短。携程App曾经利用自行计划的一套数据格式，厥后和GoogleProtocolBuffer对比后发现，特定命据范例下数据包巨细会低落20-30%，序列化和反序列化时间可以低落10-20%，因此如今核心服务都在渐渐迁徙到到ProtocolBuffer格式。别的Facebook曾分享过他们利用FlatBuffer数据格式进步性能的实践，我们分析后不太得当携程的业务场景因而没有利用。

　　5.引入重试机制，提拔网络服务乐成率

　　受TCP协议重传机制来包管可靠传输的机制开导，我们在应用层面也引入了重试机制来进步网络服务乐成率。我们发现90%以上的的网络服务失败都是由于网络毗连失败，此时再次重试是有机遇毗连乐成并完成服务的；同时我们发现前面提到的网络服务生命周期处于1创建毗连、序列化网络哀求报文、发送网络哀求这三个阶段失败时，都是可以主动重试的，由于我们可以确信哀求还没有到达服务端举行处理惩罚，不会产生幂等性题目（假如存在幂等性题目，会出现重复订单等环境）。当网络服务必要重试时，会利用短毗连举行补偿，而不再利用长毗连。

　　实现了上述机制后，携程App网络服务乐成率由原先的95.3%+提拔为如今的99.5%+（这里的服务乐成率是指端到端服务乐成率，即客户端收罗的服务乐成数除以哀求总量盘算的，而且不区分当前网络状态），结果明显。

　　6.其他网络服务机制Tricks

　　携程App也实现了其他一些网络服务机制方便业务开辟，如网络服务优先级机制，高优先级服务优先利用长毗连，低优先级服务默认利用短毗连；网络服务依靠机制，根据依靠关系主动发起或取消网络服务，比方主服务失败时，子服务主动取消。

　　开辟过程中我们也发现一些移动平台上的TCPSocket开辟tricks：

　　1.iOS平台上的原生Socket接口创建毗连并不会激活移动网络，这里原生Socket接口是指POSIXSocket接口，必须利用CFSocket大概再上层的网络接口实行网络毗连时才会激活网络。因此携程App启动时会优先激活注册一些第三方SDK以及发送HTTP哀求来激活移动网络。

　　2.公道设置Socket的几个参数：SO_KEEPALIVE参数确保TCP毗连保持（注：此KeepAlive是TCP中的属性，和HTTP的KeepAlive是两个场景概念），SO_NOSIGPIPE参数关闭SIGPIPE变乱，TCP_NODELAY参数关闭TCPNagle算法的影响。

　　3.由于iOS要求支持IPv6-Only网络，因此利用原生Socket必须支持IPv6。

　　4.假如利用select来处理惩罚nonblockingIO操纵，确保精确处理惩罚差别的返回值和超时参数。

　　5.保持TCP长毗连可用性的心跳机制：对于非IM类应用而言，心跳机制的作用不大，由于用户会不绝触发哀求去利用TCP毗连，尤其在携程业务场景下，通过数据统计发现利用心跳与否对服务耗时和乐成率影响极小，因此如今已经关闭心跳机制。原先的心跳机制是TCP长毗连池中的空闲TCP毗连每60秒发送一个心跳包到Gateway，Gateway返回一个心跳相应包，从而让两边确认TCP毗连有效。

　　Hybrid网络服务优化

　　携程App中有相称比例的业务是利用Hybrid技能实现的，运行在WebView环境中，此中的全部网络服务（HTTP哀求）都是由体系控制的，我们无法掌控，也就无法举行优化，其端到端服务乐成率也仅有97%左右（注：这里指页面中业务逻辑发送的网络服务哀求，而非静态资源哀求）。

　　我们采取了名为『TCPTunnelforHybrid』的技能方案来优化Hybrid网络服务，和传统HTTP加快产物的方法差别，我们没有采取拦截HTTP哀求再转发的方式，而是在携程Hybrid框架中的网络服务层举行主动切换。

TCPTunnelforHybrid

　　如图所示，该技能方案的流程如下：

　　1.假如App支持TCPTunnelforHybrid，Hybrid业务在发网络服务时，会通过Hybrid接口转发至AppNative层的TCP网络通讯层，该模块会封装这个HTTP哀求，作为TCP网络服务的Payload转发到TCPGateway；

　　2.TCPGateway会根据服务号判定出是Hybrid转发服务，解包后将Payload直接转发至HTTPGateway，此HTTP哀求对HTTPGateway是透明的，HTTPGateway无需区分是App直接发来的还是TCPGateway转发来的HTTP哀求；

　　3.后端业务服务处理惩罚完成后，HTTP相应会经HTTPGateway返回给TCPGateway，TCPGateway将此HTTP相应作为Payload返回给App的TCP网络通讯层；

　　4.TCP网络通讯层会再将该Payload反序列化后返回给Hybrid框架，终极异步回调给Hybrid业务调用方。整个过程对于Hybrid业务调用方也是透明的，它并不知道TCPTunnel的存在。

　　采取该技能方案后，携程App中Hybrid业务的网络服务乐成率提拔至99%以上，均匀耗时降落了30%

TCPTunnelforHybridResult

　　外洋网络服务优化

　　携程如今没有摆设外洋IDC，外洋用户在利用App时必要访问位于国内的IDC，服务均匀耗时显着高于国内用户。我们采取了名为『TCPBypassforOversea』的技能方案来优化外洋网络服务性能，重要是利用了Akamai的外洋专属网络通道，同时在携程国内IDC摆设了局端装备，利用专用加快通道的方式来提拔外洋用户体验。

TCPBypassforOversea

　　外洋用户启动App后先通过Akamai定制域名获取ServerIP，全部网络服务优先走Akamai通道；假如Akamai通道的网络服务失败而且重试机制见效时，会改走传统Internet通道举行重试。相比只用传统Internet通道，在保持网络服务乐成率稳固的环境下，利用Akamai通道Bypass技能后均匀服务耗时降落了33%。

TCPBypassforOverseaResult

　　其他网络协议探究

　　已往两年我们的网络服务优化工作都是基于TCP协议实现的，根本到达了优化目标。不外这两年来新的应用层网络协议SPDY和HTTP/2渐渐迈入主流，基于UDP的QUIC协议看起来也非常风趣，值得跟进调研。

　　SPDYHTTP/2

　　SPDY是Google基于TCP开辟的网络应用层协议，如今已经克制开辟，转向支持基于SPDY结果计划的HTTP/2协议，HTTP/2协议的核心改进着实就是针对HTTP/1.x中影响耽误性能的痛点举行优化：

　　1.Header压缩：压缩冗余的HTTP哀求和相应Header。

　　2.支持Multiplexing：支持一个TCP毗连上同时实现多个哀求和相应。

　　3.保持长毗连（比HTTP/1.x更彻底）：镌汰网络毗连时间。

　　4.支持推送：可以由服务端主动推送数据到客户端。

　　官方性能测试结果表现利用SPDY大概HTTP/2的页面加载时间镌汰30%左右，不外这是针对网页的测试结果，对于App中的网络服务，具体优化结果我们还在举行内部测试，不外其优化本领看和如今我们利用TCP协议的优化本领雷同，因此性能优化结果大概不会很明显。

　　QUIC

　　QUIC是Google基于UDP开辟的应用层协议，UDP协议无需毗连，不存在重传机制，因此应用层必要包管服务的可靠性。如今国内腾讯有针对弱网络实行过QUIC协议，我们也在举行测试，终极是否会采取还必要看测试的结果。

　　综述

　　技能只是本领，终极还是要反映在业务结果上。我们已经实现除静态资源等必要访问CDN的网络哀求外，其他App网络服务利用同一的TCP通道，从而具备更好的性能调优和业务监控本领。携程如今基于TCP协议的各种App网络服务优化，也是各种技能方案的均衡，固然如今HTTP/2等新协议渐渐成熟，但是TCP协议自身的机动性支持有针对性的性能优化，还是具备其特别的上风，盼望我们的实践总结能对国内无线技能从业者有一些鉴戒代价。

【本日微信公号保举↓】

更多保举请看《值得关注的技能和计划公众号》

　　此中保举了包罗技能、计划、极客和IT相亲相干的热门公众号。技能涵盖：Python、Web前端、Java、安卓、iOS、PHP、C/C++、.NET、Linux、数据库、运维、大数据、算法、IT职场等。点击《值得关注的技能和计划公众号》，发现出色！