作者簡(jiǎn)介：競(jìng)哲，攜程資深后端開(kāi)發(fā)工程師，關(guān)注網(wǎng)絡(luò)協(xié)議、RPC、消息隊(duì)列以及云原生等領(lǐng)域。

一、背景

QUIC 全稱 quick udp internet connection，即“快速 UDP 互聯(lián)網(wǎng)連接”(和英文 quick 諧音，簡(jiǎn)稱“快”)，是由 google 提出的使用 udp 進(jìn)行多路并發(fā)傳輸?shù)膮f(xié)議，是HTTP3的標(biāo)準(zhǔn)傳輸層協(xié)議。近幾年隨著QUIC協(xié)議在IETF的標(biāo)準(zhǔn)化發(fā)展，越來(lái)越多的國(guó)內(nèi)外大廠開(kāi)始在生產(chǎn)環(huán)境對(duì)QUIC進(jìn)行落地，以此提升某些業(yè)務(wù)場(chǎng)景下的服務(wù)性能。

Trip.com App作為一個(gè)面向國(guó)際化的App，承載了大量海外用戶的請(qǐng)求，這些請(qǐng)求需要從海外回源到上海，具有鏈路長(zhǎng)、網(wǎng)絡(luò)不穩(wěn)定等特點(diǎn)。在這樣的背景下，我們嘗試使用QUIC對(duì)App的傳輸鏈路進(jìn)行了優(yōu)化，并與目前的TCP傳輸鏈路進(jìn)行對(duì)比實(shí)驗(yàn)。結(jié)果表明，QUIC協(xié)議的落地降低了Trip.com App大約20%的鏈路耗時(shí)，大大提升了用戶的體驗(yàn)。

二、QUIC簡(jiǎn)介

簡(jiǎn)單來(lái)說(shuō)，QUIC是基于UDP封裝的安全的可靠傳輸協(xié)議，通過(guò)TLS1.3來(lái)保證傳輸?shù)陌踩裕⑼ㄟ^(guò)協(xié)議標(biāo)準(zhǔn)來(lái)保證基于UDP傳輸?shù)目煽啃?。目前QUIC協(xié)議已經(jīng)成為新一代HTTP協(xié)議HTTP3的標(biāo)準(zhǔn)底層協(xié)議。QUIC在整個(gè)網(wǎng)絡(luò)協(xié)議棧中的位置如下所示：

相較于TCP協(xié)議，QUIC主要具備以下優(yōu)勢(shì)：

三、QUIC服務(wù)端落地實(shí)踐

QUIC的落地需要客戶端與服務(wù)端的共同支持，客戶端我們使用了Google的開(kāi)源Cronet網(wǎng)絡(luò)庫(kù)，服務(wù)端基于Nginx的官方quic分支。為了滿足我們的業(yè)務(wù)與部署場(chǎng)景，客戶端與服務(wù)端都對(duì)原生的代碼進(jìn)行了一些改造。本文主要介紹服務(wù)端的改造內(nèi)容以及整體架構(gòu)。

3.1 服務(wù)端整體架構(gòu)

服務(wù)端的整體分層如圖所示：

其中：

• AX是公網(wǎng)的負(fù)載均衡器，通過(guò)配置可以做到將相同客戶端ip+port的數(shù)據(jù)包轉(zhuǎn)發(fā)到下游的同一臺(tái)實(shí)例上。
• Nginx Stream層是基于Nginx實(shí)現(xiàn)的數(shù)據(jù)包轉(zhuǎn)發(fā)層，主要用來(lái)支持連接遷移的功能。
• Nginx QUIC即QUIC服務(wù)端，基于Nginx的官方quic分支開(kāi)發(fā)改造，用來(lái)接收QUIC數(shù)據(jù)包，并解析出Http請(qǐng)求轉(zhuǎn)發(fā)到公司的API Gateway上。

為了充分利用CPU的性能，提升整個(gè)系統(tǒng)的高可用性，Nginx Stream和Nginx QUIC都是集群多進(jìn)程部署。這就為請(qǐng)求轉(zhuǎn)發(fā)、實(shí)現(xiàn)連接遷移和0-RTT帶來(lái)了一系列問(wèn)題。下面針對(duì)遇到的問(wèn)題以及我們的解決方案進(jìn)行簡(jiǎn)單的介紹。

3.2 集群多進(jìn)程部署

由于我們?cè)诙噙M(jìn)程部署Nginx QUIC服務(wù)端時(shí)采用reuseport的形式監(jiān)聽(tīng)端口，所以在介紹多進(jìn)程部署之前，先簡(jiǎn)單介紹Linux系統(tǒng)的reuseport機(jī)制和Nginx的進(jìn)程模型。

所謂reuseport，簡(jiǎn)單理解就是允許多個(gè)套接字對(duì)同一ip+port進(jìn)行監(jiān)聽(tīng)。Linux在接收到數(shù)據(jù)時(shí)，會(huì)根據(jù)四元組轉(zhuǎn)發(fā)數(shù)據(jù)到相應(yīng)的套接字，即來(lái)源于同一個(gè)客戶端的數(shù)據(jù)總會(huì)被分發(fā)給相同的套接字。Nginx基于這個(gè)特性，在啟動(dòng)時(shí)，對(duì)于配置reuseport的端口，會(huì)在創(chuàng)建與進(jìn)程數(shù)量一致的套接字，監(jiān)聽(tīng)同一端口，并為每個(gè)進(jìn)程分配其中的一個(gè)套接字。這樣便實(shí)現(xiàn)了多進(jìn)程監(jiān)聽(tīng)同一端口的功能，并且來(lái)源于同一源ip+port的數(shù)據(jù)總是會(huì)被分發(fā)給同一進(jìn)程。

有了以上理論基礎(chǔ)，我們來(lái)看集群多進(jìn)程部署時(shí)，我們的系統(tǒng)會(huì)出現(xiàn)什么問(wèn)題。由于Nginx Stream層主要用來(lái)支持連接遷移，所以此處暫時(shí)先忽略NginxStream的存在，即服務(wù)的架構(gòu)為AX直連Nginx QUIC集群。

由于AX為四層負(fù)載均衡器，所以在對(duì)UDP數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)時(shí)，可能將隸屬于同一QUIC請(qǐng)求的多個(gè)UDP包轉(zhuǎn)發(fā)到不同的下游實(shí)例中，這就會(huì)導(dǎo)致請(qǐng)求無(wú)法被處理。其次，即使所有的數(shù)據(jù)包都被AX轉(zhuǎn)發(fā)到同一臺(tái)Nginx QUIC實(shí)例上，由于Nginx QUIC實(shí)例為多進(jìn)程部署，如果多個(gè)數(shù)據(jù)包的源ip+port不同，也會(huì)被分發(fā)到不同的Nginx進(jìn)程中。以上兩種情況都會(huì)導(dǎo)致正常的請(qǐng)求無(wú)法被處理，整個(gè)系統(tǒng)完全無(wú)法正常工作。

幸運(yùn)的是，經(jīng)過(guò)調(diào)研我們發(fā)現(xiàn)AX可以通過(guò)配置將來(lái)源于同一源ip+port的數(shù)據(jù)包通過(guò)同一出口ip+port轉(zhuǎn)發(fā)到同一臺(tái)服務(wù)器實(shí)例上，服務(wù)端實(shí)例通過(guò)reuseport機(jī)制就可以做到將數(shù)據(jù)分發(fā)給同一進(jìn)程。這樣如果客戶端的ip+port不發(fā)生變化，其請(qǐng)求就會(huì)被一直轉(zhuǎn)發(fā)到同一臺(tái)服務(wù)端實(shí)例的同一進(jìn)程中。

以上方案只是針對(duì)客戶端ip+port不發(fā)生變化的場(chǎng)景，但在移動(dòng)網(wǎng)絡(luò)的環(huán)境下，客戶端網(wǎng)絡(luò)變化是十分正常的事情。當(dāng)客戶端網(wǎng)絡(luò)發(fā)生變化時(shí)，客戶端就需要與服務(wù)端進(jìn)行重新握手建立連接，這樣就會(huì)帶來(lái)額外的時(shí)延，影響用戶體驗(yàn)。

雖然QUIC有對(duì)連接遷移的支持，Nginx也對(duì)連接遷移的功能進(jìn)行了實(shí)現(xiàn)，但都是針對(duì)端對(duì)端的場(chǎng)景，在我們集群多進(jìn)程部署的場(chǎng)景下無(wú)法正常工作。為此，我們對(duì)代碼以及部署架構(gòu)進(jìn)行了一些定制化改造以支持集群多進(jìn)程部署場(chǎng)景下的連接遷移。

3.3 連接遷移

連接遷移是QUIC的一個(gè)重大特性。指的是當(dāng)客戶端或服務(wù)端的ip+port發(fā)生變化時(shí)，兩端可以保證連接不中斷繼續(xù)通信。大多數(shù)情況下都是客戶端ip+port變化導(dǎo)致的連接遷移，服務(wù)端的ip+port基本不會(huì)改變。本文中討論的也是客戶端ip+port發(fā)生變化的場(chǎng)景。

在以TCP作為傳輸層協(xié)議的網(wǎng)絡(luò)鏈路中，當(dāng)用戶的網(wǎng)絡(luò)發(fā)生變化，如移動(dòng)網(wǎng)與wifi的切換，客戶端需要重新與服務(wù)端建立連接才可以繼續(xù)通信。由于TCP建立連接需要三次握手，這就需要消耗額外的RTT(Round-Trip Time，往返時(shí)延)。尤其在弱網(wǎng)或者跨地區(qū)調(diào)用的場(chǎng)景下，建立連接需要消耗更多的時(shí)間，這對(duì)用戶來(lái)說(shuō)體驗(yàn)非常差。

而由于QUIC基于UDP協(xié)議，UDP并沒(méi)有連接的概念，因此便可以在QUIC協(xié)議中通過(guò)connectionId來(lái)標(biāo)識(shí)一個(gè)唯一的連接。當(dāng)四元組發(fā)生改變時(shí)，只要connectionId “不變”，便可以維持連接不斷，從而實(shí)現(xiàn)連接遷移的功能。

3.3.1 Nginx-QUIC連接遷移功能的實(shí)現(xiàn)

為了利于大家對(duì)Nginx連接遷移功能實(shí)現(xiàn)的理解，先簡(jiǎn)單介紹一下QUIC的握手過(guò)程中涉及到的數(shù)據(jù)包類型?？蛻舳嗽谑状闻c服務(wù)端建立連接時(shí)，首先會(huì)發(fā)送一個(gè)Initial包。服務(wù)端收到Initial包后返回Handshake包，客戶端收到Handshake包后，便可以正常發(fā)送應(yīng)用請(qǐng)求數(shù)據(jù)。此處我們省略了握手過(guò)程中的ACK、加解密過(guò)程，精簡(jiǎn)后的握手流程如圖所示：

對(duì)QUIC握手流程有了大致的了解之后，我們來(lái)看Nginx是如何實(shí)現(xiàn)連接遷移功能的。

客戶端發(fā)起與服務(wù)器建立連接的請(qǐng)求時(shí)，會(huì)在Initial包中攜帶一個(gè)由客戶端隨機(jī)生成的dcid。Nginx服務(wù)端收到Initial包后，會(huì)隨機(jī)生成一個(gè)cid在Handshake包中返回，后續(xù)客戶端發(fā)送的數(shù)據(jù)包都會(huì)以這個(gè)服務(wù)端返回的cid作為dcid。握手完成后，Nginx會(huì)生成多個(gè)cid保存在內(nèi)存中，并在握手完成后將這些cid發(fā)送給客戶端作為備用，cid的個(gè)數(shù)取決于客戶端與服務(wù)端 active_connection_id_limit 參數(shù)的限制。

當(dāng)客戶端主動(dòng)發(fā)起連接遷移時(shí)，會(huì)從備用的cid集合中取出一個(gè)作為后續(xù)數(shù)據(jù)包的dcid。Nginx收到攜帶新dcid的非探測(cè)包后，感知到客戶端發(fā)生了遷移，會(huì)對(duì)新的客戶端地址進(jìn)行驗(yàn)證，當(dāng)驗(yàn)證通過(guò)后，后續(xù)數(shù)據(jù)包都會(huì)發(fā)送給新的客戶端地址，也就完成了整個(gè)連接遷移的流程。

以上對(duì)連接遷移的實(shí)現(xiàn)，僅僅在端對(duì)端且服務(wù)器單進(jìn)程部署的場(chǎng)景下可以很好地工作。但是，在實(shí)際的生產(chǎn)環(huán)境中，由于引入了AX等負(fù)載均衡設(shè)備，而且服務(wù)端為多機(jī)多進(jìn)程部署，因此當(dāng)客戶端網(wǎng)絡(luò)環(huán)境發(fā)生變化時(shí)，新的請(qǐng)求數(shù)據(jù)包可能會(huì)被轉(zhuǎn)發(fā)到新的服務(wù)器進(jìn)程中。由于新的服務(wù)器進(jìn)程并不包含此客戶端連接遷移所需的上下文，就會(huì)導(dǎo)致客戶端遷移失敗。

解決上述問(wèn)題的思路就是引入一個(gè)中間的LB層，這層的主要作用是解析出udp包中的dcid，然后根據(jù)dcid轉(zhuǎn)發(fā)，把連接遷移前后的數(shù)據(jù)包轉(zhuǎn)發(fā)到同一服務(wù)器的同一進(jìn)程上。

此處我們基于Nginx搭建了Nginx Stream層，作為QUIC的LB層來(lái)實(shí)現(xiàn)數(shù)據(jù)包轉(zhuǎn)發(fā)。由于連接遷移后，客戶端會(huì)使用全新的dcid來(lái)發(fā)送數(shù)據(jù)包，為了使得Nginx Stream層通過(guò)新dcid的也可以路由到遷移前的機(jī)器上，我們還對(duì)服務(wù)端生成客戶端dcid的邏輯進(jìn)行了改造，在dcid中包含了服務(wù)端的ip+port信息。這樣，當(dāng)Stream層的機(jī)器收到遷移后的數(shù)據(jù)包時(shí)，便可以根據(jù)dcid中的ip+port信息將其轉(zhuǎn)發(fā)到客戶端遷移之前的服務(wù)端機(jī)器上。

加入Nginx Stream層之后的服務(wù)端整體架構(gòu)如圖所示：

以上方案只是實(shí)現(xiàn)了將客戶端連接遷移前后的請(qǐng)求轉(zhuǎn)發(fā)到同一臺(tái)服務(wù)器上，但無(wú)法保證請(qǐng)求被轉(zhuǎn)發(fā)到服務(wù)器的同一進(jìn)程中。試想，當(dāng)客戶端發(fā)生連接遷移時(shí)，AX可能會(huì)將客戶端遷移后的數(shù)據(jù)包發(fā)送到跟之前不同的Nginx Stream實(shí)例上，雖然Nginx Stream可以通過(guò)dcid中的ip+port信息將數(shù)據(jù)包轉(zhuǎn)發(fā)到同一臺(tái)Nginx QUIC實(shí)例上，但對(duì)于Nginx QUIC來(lái)說(shuō)，源ip+port為Nginx Stream的ip+port，源ip+port發(fā)生了改變。由于Nginx多進(jìn)程分發(fā)請(qǐng)求依賴了操作系統(tǒng)的reuseport機(jī)制，而Linux的reuseport是根據(jù)四元組進(jìn)行請(qǐng)求分發(fā)的，因此源ip+port的改變就可能會(huì)導(dǎo)致請(qǐng)求在服務(wù)端被分發(fā)到與遷移前不同的Nginx進(jìn)程中，從而導(dǎo)致連接遷移失敗。

為了解決這個(gè)問(wèn)題，就要求NginxStream可以將數(shù)據(jù)包準(zhǔn)確地轉(zhuǎn)發(fā)到指定機(jī)器的指定進(jìn)程中。我們進(jìn)行了調(diào)研，總結(jié)下來(lái)大致分為兩種解決方案：

• 一是修改操作系統(tǒng)reuseport的分發(fā)機(jī)制，使其根據(jù)dcid將數(shù)據(jù)分發(fā)到指定進(jìn)程。
• 二是使不同的進(jìn)程監(jiān)聽(tīng)不同的端口，這樣就可以通過(guò)將數(shù)據(jù)包轉(zhuǎn)發(fā)到不同端口，從而轉(zhuǎn)發(fā)到具體的進(jìn)程。

第一種方案需要修改Linux內(nèi)核代碼，成本較高，并且dcid在整個(gè)系統(tǒng)中屬于QUIC的應(yīng)用層數(shù)據(jù)，我們認(rèn)為不應(yīng)該在操作系統(tǒng)代碼中嵌入應(yīng)用層的數(shù)據(jù)邏輯，因此最終選擇了多端口的解決方案。

3.3.2 基于監(jiān)聽(tīng)多端口的連接遷移方案

為了降低NginxStream配置文件復(fù)雜度和系統(tǒng)的整體維護(hù)成本，以及未來(lái)支持服務(wù)端的平滑無(wú)損升級(jí)，我們讓每個(gè)進(jìn)程監(jiān)聽(tīng)了兩種不同的端口：

• 第1種是監(jiān)聽(tīng)端口listening port，主要接收客戶端的initial或0-RTT包，用來(lái)建立連接，每個(gè)進(jìn)程的listening port相同;
• 第2種是worker port，用來(lái)接收客戶端第一個(gè)包之后的所有數(shù)據(jù)包，每個(gè)進(jìn)程的workerport不同。

基于此方案，由于不同進(jìn)程監(jiān)聽(tīng)了相同的listening port，因此在建立連接時(shí)，由Linux根據(jù)四元組進(jìn)行請(qǐng)求分發(fā)，從而實(shí)現(xiàn)進(jìn)程間的負(fù)載均衡。一旦客戶端與服務(wù)端建立了連接，后續(xù)此客戶端所有請(qǐng)求報(bào)文中的dcid都包含了此服務(wù)器的ip+worker port信息，因此后續(xù)請(qǐng)求(包括連接遷移后的請(qǐng)求)都會(huì)被Nginx Stream層轉(zhuǎn)發(fā)到同一服務(wù)器的同一進(jìn)程進(jìn)行處理，從而實(shí)現(xiàn)了多進(jìn)程場(chǎng)景下對(duì)連接遷移功能的支持。

完整的連接遷移過(guò)程如下圖：

可以看到，整個(gè)連接遷移過(guò)程對(duì)Nginx Stream來(lái)說(shuō)是透明的，它只負(fù)責(zé)解析dcid中的ip+port信息，并進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)。Stream層并不需要感知服務(wù)端worker port的存在，僅僅在收到initial或0-RTT包時(shí)，需要根據(jù)dcid的hash值將其轉(zhuǎn)發(fā)到Nginx QUIC機(jī)器的listening port上，因此在Stream機(jī)器的配置文件中，只需要配置Nginx QUIC的listening port。這樣，如果Nginx QUIC需要修改單機(jī)的進(jìn)程數(shù)，Nginx Stream層無(wú)需做任何改動(dòng)。

而在Nginx QUIC端，只需在Nginx現(xiàn)有進(jìn)程模型的基礎(chǔ)上，為每個(gè)進(jìn)程額外分配一個(gè)worker port，并在為客戶端生成的dcid中包含ip+worker port的信息即可。

3.4 0-RTT實(shí)現(xiàn)

QUIC的另一個(gè)重要特性是支持0-RTT建立連接，它通過(guò)UDP+TLS1.3構(gòu)建安全的互聯(lián)服務(wù)。對(duì)于TLS1.3來(lái)說(shuō)，如果是首次建立連接需要1-RTT，非首次可以實(shí)現(xiàn)0-RTT。

當(dāng)客戶端與服務(wù)端第一次建立連接時(shí)，服務(wù)端會(huì)依賴加密層的TLS會(huì)生成加密的New Session Ticket返回給客戶端，并將解密的ticket_key保存在本地?？蛻舳嗽诎l(fā)起0-RTT請(qǐng)求時(shí)，會(huì)在報(bào)文的PSK中帶上NewSession Ticket。服務(wù)端收到報(bào)文時(shí)，通過(guò)ticket_key對(duì)PSK中的信息進(jìn)行解密。如果解密成功，則可以恢復(fù)之前的session，后續(xù)直接進(jìn)行安全通信。如果失敗，則需要重新握手建立TLS連接。

0-RTT實(shí)現(xiàn)示意圖如下：

可以看到，服務(wù)端支持0-RTT的關(guān)鍵就是需要包含恢復(fù)session所需的ticket_key。但是，nginx中生成的ticket_key是保存在進(jìn)程的上下文中的，由于nginx中各個(gè)進(jìn)程的上下文是相互獨(dú)立的，因此不同進(jìn)程間的ticket_key無(wú)法共享。

并且0-RTT握手時(shí)數(shù)據(jù)包中的dcid由客戶端隨機(jī)生成，不包含路由信息，所以Nginx Stream層也無(wú)法通過(guò)dcid將0-RTT請(qǐng)求轉(zhuǎn)發(fā)到之前已經(jīng)與客戶端建連的進(jìn)程中。這就導(dǎo)致如果服務(wù)端進(jìn)程無(wú)法解密收到的0-RTT數(shù)據(jù)包，就會(huì)導(dǎo)致0-RTT握手失敗，客戶端需要重新發(fā)起1-RTT握手請(qǐng)求。

為了解決這個(gè)問(wèn)題，我們引入了Redis，使得服務(wù)端集群中的各機(jī)器各進(jìn)程共享ticket_key。一個(gè)進(jìn)程在生成ticket_key之前，先去查找redis是否已經(jīng)存在ticket_key，如果已經(jīng)存在直接查詢出來(lái)作為當(dāng)前進(jìn)程ticket_key，如果不存在直接生成并且存入Redis。這樣可以保證在各個(gè)進(jìn)程中的ticket_key相同，最終的效果是如果A進(jìn)程加密的session，0-RTT時(shí)被轉(zhuǎn)發(fā)到了B進(jìn)程，因?yàn)锳、B進(jìn)程的ticket_key相同，B進(jìn)程也可以解密session，完成連接的建立。

改造后的0-RTT流程如下所示：

四、總結(jié)

QUIC協(xié)議由于其強(qiáng)大的拓展性與靈活性，以及弱網(wǎng)環(huán)境下呈現(xiàn)出來(lái)的優(yōu)勢(shì)，近幾年逐漸被各大廠商應(yīng)用在生產(chǎn)環(huán)境中。我們針對(duì)IBU業(yè)務(wù)海外流量大的特點(diǎn)，基于Nginx官方的quic分支進(jìn)行改造，在生產(chǎn)環(huán)境實(shí)現(xiàn)了多機(jī)多進(jìn)程環(huán)境下0-RTT、連接遷移等功能，并取得了Trip.com App請(qǐng)求總體平均耗時(shí)減少20%的良好效果。后續(xù)我們也會(huì)緊跟社區(qū)步伐，將更多QUIC的優(yōu)秀特性更新集成到我們的服務(wù)中，推動(dòng)QUIC協(xié)議在攜程更好地落地。