0、前情摘要

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

1、知識速遞

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

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

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

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

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

1.2  電商業(yè)務(wù)為什么會普遍使用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ù)據(jù)傳輸前通信雙方的狀態(tài)和能力都是正常的

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

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

• 擁塞及流量控制

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

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

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

2.1  方案制定

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

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

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

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

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

我們排障一般按從下往上逐層排除可疑點這個思路來時，日常工作會少走一些彎路

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

客戶端測試同學(xué)在飛機巡航狀況下，連上飛機WiFi后，打開得物App，的確存在訪問不了得物App的情況。于是，客戶端同步地下值班人員開啟測試。

（1）打開得物App，瀏覽不同頁面并截圖，確保影響范圍

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

（3）在瀏覽器單獨訪問典型接口，如主接口、社區(qū)接口、圖片鏈接等

（4）測試其它電商平臺，觀察其訪問情況。

以上所有訪問保留截圖、日志、抓包數(shù)據(jù)等

值班SRE同等時間抓取相同時間的接口的入口請求包，保存下來，后做對比分析。

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

2.4.1  鏈路診斷

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

這里簡單介紹一下ping/traceroute工具工作原理

（1）ping工具

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

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

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

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

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

• ping的例外

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

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

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

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ù)包從源到終點所需要的網(wǎng)絡(luò)路徑，并識別這些路徑上的瓶頸和故障

• 工作原理

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

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

• 工具發(fā)展歷程

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

• 配置初始值

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


#define MAX_HOPS    255 //最大跳數(shù)，限制 traceroute 能夠追蹤到的最遠節(jié)點的數(shù)量
#define MAX_PROBES  10 //每個路由節(jié)點的最大探測次數(shù)
#define DEF_HOPS    30 //默認(rèn)的最大跳數(shù)
#define DEF_NUM_PROBES  3 //默認(rèn)的每個節(jié)點的探測次數(shù)
#define DEF_WAIT_SECS   5.0 //默認(rèn)的等待每個節(jié)點響應(yīng)的時間
#define DEF_DATA_LEN    40  //IP包上的負載默認(rèn)大小
#define MAX_PACKET_LEN  65000 //最大的包長度，默認(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進行探測
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探測時啟始探測端口   */

• 包格式分析

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

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

2.4.2  應(yīng)用層測試

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

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

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

ios端：

高防端：

tcpdump是一個超級好用的開源的抓包工具，一直是我們SRE最重要的工具之一，這里給大家分享一下：

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

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

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

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



• 
  
• 工作原理

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

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

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

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

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

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

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

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

同時也從client端及防火墻出口同時進行了抓包：

電腦client側(cè)：

防火墻出口側(cè)：

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

2.7  廠商溝通

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

2.8  進展同步

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

4/19，我司ac設(shè)備自動進行了策略更新

4/21，請朋友幫忙在同一航班驗證得物App使用流暢，驗證通過

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

3.1  traceroute

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

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

3.2  ip包頭

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

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

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

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

功能實現(xiàn)：

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

URL過濾，運用HTTP識別技術(shù)就是獲取到HTTP請求時帶有的host字段來獲知用戶想要訪問的網(wǎng)站，以此來達到過濾網(wǎng)站目的（本次出問題就是此功能上）

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

2. HTTPS：三次握手后會建立SSL加密通道，在SSL第一次握手時客戶端發(fā)出client hello報文時，會有個server name字段（SNI），從這里獲知后進行相應(yīng)的過濾

參考資料：

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

2）東航官網(wǎng)

3）通信世界

4）中興通訊5G地空通信白皮書2020