0、前情摘要

在一次飛行途中，我司客戶(hù)遭遇到了得物App在飛機(jī)上的WiFi網(wǎng)絡(luò)訪(fǎng)問(wèn)異常的問(wèn)題。這讓我們意識(shí)到在特定場(chǎng)景下，用戶(hù)可能面臨無(wú)法使用得物App的困擾。經(jīng)過(guò)SRE團(tuán)隊(duì)與無(wú)線(xiàn)團(tuán)隊(duì)、網(wǎng)絡(luò)團(tuán)隊(duì)聯(lián)合全力排查與優(yōu)化，最終成功解決了這一問(wèn)題，并同時(shí)挖掘出全網(wǎng)防火墻設(shè)備在各個(gè)C端用戶(hù)工作生活場(chǎng)景訪(fǎng)問(wèn)不到得物App的問(wèn)題。為得物er穩(wěn)定訪(fǎng)問(wèn)得物提供保障，同時(shí)也輸出類(lèi)似疑難問(wèn)題排查模板。

1、知識(shí)速遞

1.1  什么是空中WiFi技術(shù)？

目前機(jī)載 WiFi 服務(wù)主要有兩大解決方案：地空寬帶（ATG）無(wú)線(xiàn)通信系統(tǒng)和機(jī)載衛(wèi)星通信系統(tǒng)（SATCOM）。

• 地空寬帶（ATG）無(wú)線(xiàn)通信系統(tǒng)采用定制的無(wú)線(xiàn)收發(fā)設(shè)備，沿飛行航路或特定空域架設(shè)地面基站和對(duì)空天線(xiàn)，形成 地空通信鏈路。
• 機(jī)載衛(wèi)星通信系統(tǒng)由利用衛(wèi)星、飛機(jī)、衛(wèi)星地面站三者進(jìn)行數(shù)據(jù)通訊

兩者的技術(shù)優(yōu)劣勢(shì)對(duì)比如下：

馬斯克搞的星鏈服務(wù)用的是近軌衛(wèi)星群，距離地表在550公里范圍左右，時(shí)延基本在20ms以?xún)?nèi)，而我國(guó)目前用于客艙通信的衛(wèi)星基本是同步衛(wèi)星，離地距離36000公里，時(shí)延基本在500ms以上

1.2  電商業(yè)務(wù)為什么會(huì)普遍使用TCP協(xié)議

當(dāng)今互聯(lián)網(wǎng)主流通信協(xié)議使用的TCP/UDP協(xié)議,遵守TCP/IP的4層網(wǎng)絡(luò)模型,其中TCP協(xié)議相比UDP提供了可靠的、面向連接的通信：

• 三次握手

在TCP協(xié)議下，數(shù)據(jù)傳輸之前，通信雙方需要先建立連接，建立連接時(shí)會(huì)進(jìn)行一系列的握手過(guò)程，確保數(shù)據(jù)傳輸前通信雙方的狀態(tài)和能力都是正常的

• 包確認(rèn)機(jī)制（ACK)

在數(shù)據(jù)傳輸時(shí)，TCP協(xié)議會(huì)將數(shù)據(jù)分成多個(gè)包進(jìn)行傳輸，并且會(huì)對(duì)每個(gè)包進(jìn)行校驗(yàn)和確認(rèn)，確保數(shù)據(jù)能夠正確無(wú)誤地傳輸。

• 擁塞及流量控制

TCP協(xié)議提供了擁塞控制和流量控制等機(jī)制，能夠自適應(yīng)地調(diào)整傳輸速率，防止網(wǎng)絡(luò)擁塞和數(shù)據(jù)丟失

基于以上TCP協(xié)議保證數(shù)據(jù)的可靠性和完整性，因此在電商應(yīng)用中廣泛使用TCP協(xié)議。

2、天地協(xié)同排查

2.1  方案制定

了解了空中WiFi實(shí)現(xiàn)技術(shù)后，如何定位排查問(wèn)題便是我們SRE專(zhuān)家思考的問(wèn)題。對(duì)于任務(wù)疑難雜癥，永遠(yuǎn)的三板斧：模擬復(fù)現(xiàn)問(wèn)題，抓包，分析完整請(qǐng)求鏈路。本次麻煩的是場(chǎng)景特殊，需要在空中WiFi環(huán)境上才能復(fù)現(xiàn)，同時(shí)抓包又是一個(gè)技術(shù)活，只能我們技術(shù)團(tuán)隊(duì)親自出馬了。這里要特別表?yè)P(yáng)無(wú)線(xiàn)平臺(tái)的客戶(hù)端同學(xué)，為了完全復(fù)現(xiàn)場(chǎng)景，特地早上7點(diǎn)乘指定班機(jī)來(lái)回測(cè)試，收集重要抓包數(shù)據(jù)。

2.2  測(cè)試方案&工具確認(rèn)

因復(fù)現(xiàn)場(chǎng)景苛刻（必須萬(wàn)米高空WiFi才會(huì)開(kāi)啟），必須制定好完整的測(cè)試方案完成盡可能多的數(shù)據(jù)收集。無(wú)線(xiàn)平臺(tái)團(tuán)隊(duì)和SRE團(tuán)隊(duì)協(xié)同準(zhǔn)備好了測(cè)試工具包，可進(jìn)行網(wǎng)路層面測(cè)試包含ping和traceroute，APP層面的請(qǐng)求測(cè)試，單域名訪(fǎng)問(wèn)測(cè)試等。并準(zhǔn)備好抓包工具，在測(cè)試時(shí)留存所有抓包數(shù)據(jù)。SRE在公司同步值班抓取服務(wù)端請(qǐng)求包，做雙向?qū)Ρ取?/span>

下面是我們的SRE老司機(jī)梳理的各協(xié)議段排查工具，大家可收藏：

盡管TCP協(xié)議具有面向連接、可靠性高等優(yōu)點(diǎn)，但是在實(shí)際的網(wǎng)絡(luò)環(huán)境中，由于網(wǎng)絡(luò)的復(fù)雜性、拓?fù)浣Y(jié)構(gòu)、應(yīng)用缺陷等因素，會(huì)導(dǎo)致各種網(wǎng)絡(luò)問(wèn)題, 以下我們將排障工具和4層模型做了一個(gè)歸類(lèi)：

我們排障一般按從下往上逐層排除可疑點(diǎn)這個(gè)思路來(lái)時(shí)，日常工作會(huì)少走一些彎路

2.3  問(wèn)題復(fù)現(xiàn)&測(cè)試抓包

客戶(hù)端測(cè)試同學(xué)在飛機(jī)巡航狀況下，連上飛機(jī)WiFi后，打開(kāi)得物App，的確存在訪(fǎng)問(wèn)不了得物App的情況。于是，客戶(hù)端同步地下值班人員開(kāi)啟測(cè)試。

（1）打開(kāi)得物App，瀏覽不同頁(yè)面并截圖，確保影響范圍

（2）進(jìn)行網(wǎng)絡(luò)測(cè)試包含（ping、traceroute等）

（3）在瀏覽器單獨(dú)訪(fǎng)問(wèn)典型接口，如主接口、社區(qū)接口、圖片鏈接等

（4）測(cè)試其它電商平臺(tái)，觀(guān)察其訪(fǎng)問(wèn)情況。

以上所有訪(fǎng)問(wèn)保留截圖、日志、抓包數(shù)據(jù)等

值班SRE同等時(shí)間抓取相同時(shí)間的接口的入口請(qǐng)求包，保存下來(lái)，后做對(duì)比分析。

2.4  數(shù)據(jù)整理

2.4.1  鏈路診斷

網(wǎng)絡(luò)鏈路層測(cè)試：用ping/traceroute等工具對(duì)app.dewu.com/m.dewu.com相關(guān)域名進(jìn)行了拔測(cè)，均顯示網(wǎng)絡(luò)層正常

這里簡(jiǎn)單介紹一下ping/traceroute工具工作原理

（1）ping工具

ping是一種基于icmp協(xié)議開(kāi)發(fā)的網(wǎng)絡(luò)診斷工具，工作于第3層，其工作原理是向目標(biāo)主機(jī)發(fā)出一個(gè)icmp的echo request數(shù)據(jù)包，并等待接收echo response數(shù)據(jù)包，然后程序自動(dòng)估算丟包率和數(shù)據(jù)包的rtt，因此主要用于網(wǎng)絡(luò)連通性和網(wǎng)絡(luò)時(shí)延的診斷

此工具原始作者是Mike Muuss,于1983年開(kāi)發(fā),后面macos/win/linux相繼實(shí)現(xiàn)各自版本，以下沒(méi)有特殊說(shuō)明的情況下，所有相關(guān)參數(shù)或敘述主要是針對(duì)linux版本展開(kāi)的

• ping工具集成在iputils包中，開(kāi)源項(xiàng)目https://github.com/iputils/iputils
• 一個(gè)基于icmp協(xié)議的ping包格式

上圖中紅色標(biāo)注的屬于ip和icmp協(xié)議頭中較關(guān)鍵的字段：

• ping的部分參數(shù)默認(rèn)值

• ping的例外

從開(kāi)頭描述的ping的原理可以看出，目標(biāo)設(shè)備必須回復(fù)echo response才能判斷網(wǎng)絡(luò)連通性和時(shí)延，因此如果目標(biāo)設(shè)備設(shè)置了類(lèi)似“net.ipv4.icmp_echo_ignore_all=0”禁止或者防火墻設(shè)置了丟棄icmp包策略，此測(cè)試結(jié)果基本失效,此時(shí)需要其它工具如telnet/nc/curl等工具配合測(cè)試了

特別有意思的一點(diǎn)：在s20190709版本和此前版本，Identifier取值使用是當(dāng)前ping進(jìn)程的pid,如下圖所示：

ping當(dāng)前進(jìn)程pid是2570,16進(jìn)制值是0xa0a,因此在包中第25和26字節(jié)中展示出來(lái)是0xa0a，之后的版本考慮不安全，因此全部改為隨機(jī)值了

ping_common.c




//s20190709版本和此前的版本
    if (sock->socktype == SOCK_RAW)
        ident = htons(getpid() & 0xFFFF);


//之后的版本
    if (sock->socktype == SOCK_RAW && rts->ident == -1)
        rts->ident = rand() & IDENTIFIER_MAX;

（2）traceroute

• 功能與作用

用于查找數(shù)據(jù)包從源到終點(diǎn)所需要的網(wǎng)絡(luò)路徑，并識(shí)別這些路徑上的瓶頸和故障

• 工作原理

它發(fā)送一份TTL字段為1的IP數(shù)據(jù)包給目的主機(jī)，處理這份數(shù)據(jù)包的第一個(gè)路由器將TTL值減1，丟棄該數(shù)據(jù)包，并發(fā)送一份超時(shí)ICMP報(bào)文。這樣就得到了該路徑中的第一個(gè)路由器的地址。然后traceroute 在發(fā)送一份TTL=2的數(shù)據(jù)包，這樣我們就能得到第二個(gè)路由器的地址， 繼續(xù)這個(gè)過(guò)程直至該數(shù)據(jù)包到達(dá)目的地主機(jī)

這個(gè)數(shù)據(jù)包承載的上層協(xié)議可以是ICMP/UDP/TCP

• 工具發(fā)展歷程

最初是在1987年，由Van Jacobson主導(dǎo)實(shí)現(xiàn)，后面macos/win/linux/bsd等也都實(shí)現(xiàn)了各自版本，主流linux發(fā)行版基本使用的是這個(gè)項(xiàng)目https://traceroute.sourceforge.net/提供的

• 配置初始值

//代碼配置節(jié)選


#define MAX_HOPS    255 //最大跳數(shù)，限制 traceroute 能夠追蹤到的最遠(yuǎn)節(jié)點(diǎn)的數(shù)量
#define MAX_PROBES  10 //每個(gè)路由節(jié)點(diǎn)的最大探測(cè)次數(shù)
#define DEF_HOPS    30 //默認(rèn)的最大跳數(shù)
#define DEF_NUM_PROBES  3 //默認(rèn)的每個(gè)節(jié)點(diǎn)的探測(cè)次數(shù)
#define DEF_WAIT_SECS   5.0 //默認(rèn)的等待每個(gè)節(jié)點(diǎn)響應(yīng)的時(shí)間
#define DEF_DATA_LEN    40  //IP包上的負(fù)載默認(rèn)大小
#define MAX_PACKET_LEN  65000 //最大的包長(zhǎng)度，默認(rèn)為 65000 字節(jié)
#ifndef DEF_AF
#define DEF_AF      AF_INET  // 默認(rèn)的地址族，一般設(shè)置為 AF_INET，表示 IPv4


static const char *module = "default";  //默認(rèn)使用udp進(jìn)行探測(cè)
static tr_module default_ops = {
    .name = "default",
    .init = udp_default_init,
    .send_probe = udp_send_probe,
    .recv_probe = udp_recv_probe,
    .expire_probe = udp_expire_probe,
    .header_len = sizeof (struct udphdr),
};
#define DEF_START_PORT  33434   /*  udp探測(cè)時(shí)啟始探測(cè)端口   */

• 包格式分析

從抓包可以驗(yàn)證代碼實(shí)現(xiàn)邏輯，以及整個(gè)探測(cè)過(guò)程(tcpdump host 1.1.1.1 -Nn -w 保存文件名.pcap)

從兩個(gè)工具的介紹和測(cè)試數(shù)據(jù)來(lái)看，說(shuō)明網(wǎng)路層面是正常的。

2.4.2  應(yīng)用層測(cè)試

空中側(cè)從ios/android終端，https/http等維度對(duì)我司后臺(tái)服務(wù)接口進(jìn)行了測(cè)試驗(yàn)證，同時(shí)也對(duì)友商的app進(jìn)行了購(gòu)物體驗(yàn)，只有得物App的接口返回異常（https/http),且使用瀏覽器測(cè)試時(shí)返回帶有攔截提示的頁(yè)面；

2.4.3  網(wǎng)絡(luò)抓包

空中側(cè)對(duì)ios端進(jìn)行了抓包，地面?zhèn)仍诟叻廊肟谶M(jìn)行了抓包，從client/server側(cè)角度看，雙方都認(rèn)為對(duì)方發(fā)起了強(qiáng)制斷開(kāi)（reset）信令：從手機(jī)端看認(rèn)為是高防（服務(wù)端）先斷開(kāi)的，從高防側(cè)看認(rèn)為是手機(jī)（客戶(hù)端）先斷開(kāi)的

ios端：

高防端：

tcpdump是一個(gè)超級(jí)好用的開(kāi)源的抓包工具，一直是我們SRE最重要的工具之一，這里給大家分享一下：

tcpdump是一個(gè)功能強(qiáng)大的命令行網(wǎng)絡(luò)數(shù)據(jù)包截獲工具。

通過(guò)使用 tcpdump，可以捕獲和分析網(wǎng)絡(luò)中的數(shù)據(jù)包流量，從而能夠診斷網(wǎng)絡(luò)問(wèn)題、監(jiān)視網(wǎng)絡(luò)行為、進(jìn)行網(wǎng)絡(luò)安全審計(jì)等操作。

tcpdump也是作為學(xué)習(xí)網(wǎng)絡(luò)協(xié)議和數(shù)據(jù)包結(jié)構(gòu)的非常好的工具，用于對(duì)網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行分析和解碼。

• tcpdump工作在數(shù)據(jù)鏈路層



• 
  
• 工作原理

1. 網(wǎng)絡(luò)數(shù)據(jù)包截獲：通過(guò)調(diào)用 libpcap 庫(kù)捕獲從指定網(wǎng)絡(luò)接口傳輸?shù)臄?shù)據(jù)包。具體來(lái)說(shuō)，libpcap 庫(kù)利用操作系統(tǒng)提供的原始套接字(Socket)接口來(lái)截獲網(wǎng)絡(luò)數(shù)據(jù)包，然后通過(guò)回調(diào)機(jī)制將數(shù)據(jù)包傳遞給tcpdump進(jìn)程。
2. 數(shù)據(jù)包過(guò)濾：tcpdump可以根據(jù)用戶(hù)設(shè)置的過(guò)濾規(guī)則對(duì)捕獲到的數(shù)據(jù)包進(jìn)行過(guò)濾。過(guò)濾規(guī)則利用 BPF (Berkeley Packet Filter) 過(guò)濾器來(lái)實(shí)現(xiàn)，這是一個(gè)基于指令集的過(guò)濾器，它能夠?qū)?shù)據(jù)包的各個(gè)字段進(jìn)行匹配和過(guò)濾，過(guò)濾出符合條件的數(shù)據(jù)包。
3. 數(shù)據(jù)包解析：一旦通過(guò)過(guò)濾器選定了要截獲的數(shù)據(jù)包，tcpdump就會(huì)對(duì)這些數(shù)據(jù)包進(jìn)行解析和格式化，展示其中的各個(gè)字段和屬性。數(shù)據(jù)包解析過(guò)程的關(guān)鍵是數(shù)據(jù)包格式的識(shí)別和解碼，tcpdump和 libpcap 庫(kù)可以識(shí)別和處理多種數(shù)據(jù)包格式，包括以太網(wǎng)、IPv4/IPv6、TCP/UDP、DNS、HTTP 等等。
4. 數(shù)據(jù)包展示：最后，tcpdump將解析后的數(shù)據(jù)包內(nèi)容輸出到標(biāo)準(zhǔn)輸出或者用戶(hù)指定的文件中，供用戶(hù)進(jìn)行查看和處理。用戶(hù)可以對(duì)輸出內(nèi)容進(jìn)行進(jìn)一步處理，比如進(jìn)行過(guò)濾、排序、統(tǒng)計(jì)等操作，以更好地理解網(wǎng)絡(luò)數(shù)據(jù)流量，分析網(wǎng)絡(luò)協(xié)議和應(yīng)用行為，發(fā)現(xiàn)問(wèn)題和優(yōu)化性能等。

2.5  數(shù)據(jù)包分析

• 從網(wǎng)絡(luò)鏈路層測(cè)試數(shù)據(jù)結(jié)果看，網(wǎng)絡(luò)層上端口是正常通行的，包括tcp三次握手。那說(shuō)明整個(gè)網(wǎng)絡(luò)鏈路是通暢的。不存在網(wǎng)絡(luò)不通的情況。（從友商可正常訪(fǎng)問(wèn)來(lái)看也能印證這個(gè)問(wèn)題）
• 從網(wǎng)絡(luò)抓包數(shù)據(jù)來(lái)看，從client/server側(cè)角度看，雙方都認(rèn)為對(duì)方發(fā)起了強(qiáng)制斷開(kāi)（reset）信令：從手機(jī)端看認(rèn)為是高防（服務(wù)端）先斷開(kāi)的，從高防側(cè)看認(rèn)為是手機(jī)（客戶(hù)端）先斷開(kāi)的
• 從應(yīng)用層上截圖來(lái)看，貌似受到類(lèi)似acl的攔截

綜合結(jié)論：最有可能是受到類(lèi)似防火墻之類(lèi)的中間層設(shè)備攔截

2.6  模擬復(fù)現(xiàn)

從如下截圖來(lái)看，可能和我司的防火墻同一廠(chǎng)商，于是迅速和網(wǎng)絡(luò)同學(xué)組織了一次模擬驗(yàn)證：

將某一終端IP在防火墻上開(kāi)啟“禁用訪(fǎng)問(wèn)網(wǎng)站/軟件下載”策略，

然后在瀏覽器上請(qǐng)求https://app.dewu.com,發(fā)現(xiàn)命中此策略

同時(shí)也從client端及防火墻出口同時(shí)進(jìn)行了抓包：

電腦client側(cè)：

防火墻出口側(cè)：

基于上面的證據(jù)鏈，基本可以確認(rèn)防火墻的策略誤判了公司得物App的域名為下載類(lèi)網(wǎng)站

2.7  廠(chǎng)商溝通

將我司復(fù)現(xiàn)的問(wèn)題反饋給廠(chǎng)家后，廠(chǎng)商的策略工程師確認(rèn)此“訪(fǎng)問(wèn)網(wǎng)站/軟件下載”策略存在bug，并在溝通中的過(guò)程也確認(rèn)了此航司與我司都是使用同一廠(chǎng)商的防火墻。

2.8  進(jìn)展同步

4/18，廠(chǎng)商進(jìn)行了全網(wǎng)策略發(fā)布

4/19，我司ac設(shè)備自動(dòng)進(jìn)行了策略更新

4/21，請(qǐng)朋友幫忙在同一航班驗(yàn)證得物App使用流暢，驗(yàn)證通過(guò)

3、網(wǎng)絡(luò)技術(shù)點(diǎn)回顧

3.1  traceroute

從本次的traceroute數(shù)據(jù)中我們可以確定一點(diǎn)：

• 空中WiFi到國(guó)內(nèi)電商主要域名的時(shí)延基本都在600ms以上，此數(shù)據(jù)也進(jìn)一步確認(rèn)空中WiFi使用的SATCOM方式（高延遲）

3.2  ip包頭

• ip包頭中的ttl正常情況下每經(jīng)過(guò)一個(gè)路由器，TTL的值就會(huì)減1，直到服務(wù)器接收時(shí)不再變化，也就是正常情況下client和server的包中的值不應(yīng)該有變化，如果有較大變化都基本是中間設(shè)備篡改
• ip包頭中另外一個(gè)字段identifcation用于標(biāo)識(shí)IP數(shù)據(jù)報(bào)的唯一性，如果一個(gè)ip包需要分片（MTU超過(guò)1460），則每個(gè)分片的ip包中的identifcation數(shù)值一樣;  同時(shí)RFC791規(guī)范并沒(méi)有規(guī)定Identification字段的取值方式，但實(shí)際情況下我們看到的依次增長(zhǎng)（MTU超過(guò)1500字節(jié)加1），如果有跳變很大，基本也是中間設(shè)備篡改

3.3  AC設(shè)備網(wǎng)絡(luò)管理

AC（Access Controller）是一種中央控制的網(wǎng)絡(luò)設(shè)備，用于管理多個(gè)AP（Access Point）的上網(wǎng)行為。AC 設(shè)備上網(wǎng)行為管理功能可以幫助管理員對(duì)用戶(hù)的上網(wǎng)行為進(jìn)行監(jiān)控和管理，包括以下方面：

• 認(rèn)證和授權(quán)管理：AC 設(shè)備可以實(shí)現(xiàn)多種認(rèn)證方式，如無(wú)線(xiàn)局域網(wǎng)安全性協(xié)議（WPA、WPA2）、802.1X 認(rèn)證等，確保用戶(hù)的合法身份，并授權(quán)其訪(fǎng)問(wèn)網(wǎng)絡(luò)。
• 流量控制：AC 設(shè)備可以對(duì)接入的用戶(hù)進(jìn)行流量控制，限制其上行和下行的帶寬、流量總量等參數(shù)，以避免網(wǎng)絡(luò)擁堵和單個(gè)用戶(hù)占用過(guò)多帶寬資源。
• 上網(wǎng)行為過(guò)濾：AC 設(shè)備可以對(duì)用戶(hù)的網(wǎng)絡(luò)訪(fǎng)問(wèn)進(jìn)行過(guò)濾，禁止用戶(hù)訪(fǎng)問(wèn)某些不適宜的網(wǎng)站或應(yīng)用，確保網(wǎng)絡(luò)的安全和穩(wěn)定。
• 用戶(hù)管理和監(jiān)控：AC 設(shè)備可以對(duì)所有接入用戶(hù)進(jìn)行統(tǒng)一管理和監(jiān)控，包括用戶(hù)的身份、設(shè)備類(lèi)型、MAC 地址、IP 地址、上網(wǎng)時(shí)長(zhǎng)等，幫助管理員了解用戶(hù)的上網(wǎng)習(xí)慣和行為特征，發(fā)現(xiàn)和處理異常行為。

功能實(shí)現(xiàn)：

用戶(hù)認(rèn)證，可以基于用戶(hù)和用戶(hù)組來(lái)管理用戶(hù)的登陸，可以配置本地認(rèn)證也可以AAA認(rèn)證等等

URL過(guò)濾，運(yùn)用HTTP識(shí)別技術(shù)就是獲取到HTTP請(qǐng)求時(shí)帶有的host字段來(lái)獲知用戶(hù)想要訪(fǎng)問(wèn)的網(wǎng)站，以此來(lái)達(dá)到過(guò)濾網(wǎng)站目的（本次出問(wèn)題就是此功能上）

1. HTTP：三次握手后，HTTP發(fā)出請(qǐng)求，帶有host字段，從這里得知訪(fǎng)問(wèn)網(wǎng)站

2. HTTPS：三次握手后會(huì)建立SSL加密通道，在SSL第一次握手時(shí)客戶(hù)端發(fā)出client hello報(bào)文時(shí)，會(huì)有個(gè)server name字段（SNI），從這里獲知后進(jìn)行相應(yīng)的過(guò)濾

參考資料：

1）中國(guó)民航網(wǎng)

2）東航官網(wǎng)

3）通信世界

4）中興通訊5G地空通信白皮書(shū)2020