內(nèi)核態(tài)？還是用戶態(tài)？哪一個(gè)更適合TCP/IP協(xié)議棧呢？

“TCP/IP協(xié)議棧到底是內(nèi)核態(tài)的好還是用戶態(tài)的好？”

問題的根源在于，干嘛非要這么刻意地去區(qū)分什么內(nèi)核態(tài)和用戶態(tài)。

引子

為了不讓本文成為干巴巴的說教，在文章開頭，我以一個(gè)實(shí)例分析開始。

最近一段時(shí)間，我?guī)缀趺刻焐钜苟荚谧鲆患拢瑢?duì)比mtcp，Linux內(nèi)核協(xié)議棧的收包處理和TCP新建連接的性能，同時(shí)還了解了一下騰訊的F-Stack。這里指明，我的mtcp使用的是netmap作為底層支撐，而不是DPDK。

測(cè)試過程中，我確認(rèn)了Linux內(nèi)核協(xié)議棧的scalable問題，并且確認(rèn)了用戶態(tài)協(xié)議棧是如何解決這個(gè)問題的。然而這并沒有讓我得出用戶態(tài)協(xié)議棧就一定比內(nèi)核態(tài)協(xié)議棧好這么一個(gè)明確的結(jié)論。

具體怎么講呢？先來看一張圖，這張圖大致描述了我的測(cè)試結(jié)論：

可以看出，Linux內(nèi)核協(xié)議棧存在嚴(yán)重的scalable問題(可伸縮性)，雖然我們看到用戶態(tài)協(xié)議棧性能也并非完美地隨著CPU核數(shù)的增加而線性擴(kuò)展，但已經(jīng)好太多了。 看到這個(gè)結(jié)論，我們不禁要問，Why？兩個(gè)問題：

為什么內(nèi)核協(xié)議棧PPS曲線呈現(xiàn)嚴(yán)重上凸？

為什么內(nèi)核協(xié)議棧的CPS(TCP每秒新建連接數(shù))隨著CPU核數(shù)的增加幾乎沒有什么變化？

第一個(gè)問題好回答，就像《人月神話》里說的一樣，任何事情都不能完美線性擴(kuò)展，因?yàn)?strong>溝通需要成本。好吧，當(dāng)我巧妙繞開第一個(gè)問題后，我不得不深度解析第二個(gè)問題。

我們知道，Linux內(nèi)核協(xié)議棧會(huì)將所有的Listener socket和已經(jīng)建立連接的establish socket分別鏈接到兩個(gè)全局的hash表中，這意味著每一個(gè)CPU核都有可能操作這兩張hash表，作為搶占式SMP內(nèi)核，Linux處理TCP新建連接時(shí)加鎖是必須的。

好在如今的新內(nèi)核的鎖粒度已經(jīng)細(xì)化到了hash slot，這大大提升了性能，然而面對(duì)hash到同一個(gè)slot的TCP syn請(qǐng)求來講，還是歇菜！

特別嚴(yán)重的是，如果用戶態(tài)服務(wù)器僅僅偵聽一個(gè)Nginx 80端口，那么這個(gè)機(jī)制就相當(dāng)于一個(gè)全局的內(nèi)核大鎖！對(duì)于Listener的slot鎖，那是為多個(gè)Listener而優(yōu)化的(最多INET_LHTABLE_SIZE個(gè)bucket，即32個(gè))，對(duì)于僅有一個(gè)Listener的新建連接而言，不會(huì)起到任何作用。但是這個(gè)只是在頻繁啟停服務(wù)+reuseport的時(shí)候才會(huì)發(fā)生，無關(guān)我們描述的場(chǎng)景。

對(duì)于TCP新建連接測(cè)試，很顯然要頻繁操作那張 establish hash 表，握手完成后加鎖插入 hash 表，連接銷毀時(shí)加鎖從 hash 表刪除！

問題已經(jīng)描述清楚了，要揭示答案了。

對(duì)于TCP CPS測(cè)試而言，會(huì)有頻繁的連接創(chuàng)建和鏈接銷毀的過程在執(zhí)行，映射到代碼，那就是inet_hash和inet_unhash兩個(gè)函數(shù)會(huì)頻繁執(zhí)行，我們看一下unhash：

void inet_unhash(struct sock *sk)
{
struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;
    spinlock_t *lock;
int done;


if (sk_unhashed(sk))
return;


if (sk->sk_state == TCP_LISTEN) 
  lock = &hashinfo->listening_hash[inet_sk_listen_hashfn(sk)].lock;
else // 多核SMP且高壓力下，難免會(huì)有多個(gè)socket被hash到同一個(gè)slot
  lock=inet_ehash_lockp(hashinfo,sk->sk_hash);


spin_lock_bh(lock);//這里是問題的根源
done=__sk_nulls_del_node_init_rcu(sk);
if(done)
sock_prot_inuse_add(sock_net(sk),sk->sk_prot,-1);
    spin_unlock_bh(lock);
}

關(guān)于hash的過程就不贅述了，同樣會(huì)有一個(gè)spinlock的串行化過程。

這似乎解釋了為什么內(nèi)核協(xié)議棧的CPS如此之低，但依然沒有解釋為什么內(nèi)核協(xié)議棧的CPS如此不scalable，換句話說，為何其曲線上凸。

從曲線上看，虛線的斜率隨著CPU核數(shù)的增加而減小。而曲線的斜率和溝通成本是負(fù)相關(guān)的。這里的溝通成本就是沖突后的自旋！

不求完全定量化分析，我們只需要證明另外一件事即可，那就是隨著CPU核數(shù)的增加，slot沖突將會(huì)加劇，從而導(dǎo)致spinlock更加頻繁，即CPU核心和spinlock頻度是正相關(guān)的??！

這是顯然的，且這很容易理解。如果我們的hash函數(shù)是完美的，那么每一次hash都是不偏不倚的，最終的hash bucket分布將是概率均勻的。CPU核數(shù)的增加并不會(huì)改變這個(gè)結(jié)論：

結(jié)論是，CPU核數(shù)的增加，只會(huì)加劇沖突，因此CPU核數(shù)越多，spinlock頻度就越高，明顯地二者正相關(guān)！spinlock隨著CPU核數(shù)的增加而增加，CPU核數(shù)增加的收益被同樣增加的spinlock成本完美抵消，所以說，隨著CPU核數(shù)的增加，CPS幾乎不會(huì)變化。

好了，這就是內(nèi)核協(xié)議棧的缺陷，它能不能改進(jìn)取決于你的決心，以上的描述沒有任何細(xì)節(jié)證明在內(nèi)核態(tài)實(shí)現(xiàn)協(xié)議棧是不好的，相反，它只是證明了Linux內(nèi)核如此這般的實(shí)現(xiàn)方法存在問題，僅此而已。

現(xiàn)在回到Linux內(nèi)核協(xié)議棧CPS問題的spinlock，其也是一個(gè)NAK協(xié)議，沖突了就等，直到等到，這是一種完全消極的被動(dòng)應(yīng)對(duì)方式。注定會(huì)失去scalable！！

Linux內(nèi)核里充斥著大量的這種被動(dòng)邏輯，但卻沒有辦法去優(yōu)化它們，因?yàn)橐婚_始它們就這么存在著。典型的場(chǎng)景就是，TCP短鏈接加上nf_conntrack。二者全部都需要操作全局的spinlock，嗚呼，悲哀！

說一下HTTP。搞底層協(xié)議的一般不會(huì)太關(guān)注HTTP，但是HTTP請(qǐng)求頭里的Connection字段會(huì)對(duì)性能產(chǎn)生巨大的影響，如果你設(shè)置為close，那就意味著服務(wù)器在完成任務(wù)后就斷開TCP連接，如果你設(shè)置為Keep-Alive，就意味著你可以在同一個(gè)TCP連接中請(qǐng)求多個(gè)HTTP。

但這看起來也不是很有用。作為一個(gè)瀏覽器客戶端，誰管你服務(wù)器能撐得住多少CPS?。【退阄覀€(gè)人將Connection設(shè)置為Keep-Alive，別人不從，又能把他們?cè)鯓樱?/p>

ACK和NAK

一般認(rèn)為NAK協(xié)議可以最大限度的節(jié)約空間，但是卻浪費(fèi)了時(shí)間，然而在帶寬資源非常緊缺的TCP協(xié)議誕生伊始，多發(fā)一個(gè)字節(jié)都嫌多，為什么卻選擇了ACK而不是NAK？

答案正是空間換取scalable。后來的事實(shí)證明，TCP選擇了ACK，這是一個(gè)正確的選擇。

NAK表明你必須被動(dòng)地等待壞消息，沒有消息就是好消息，但是要等多久呢？不得而知。而ACK的主動(dòng)報(bào)送則可以讓你規(guī)劃下一步的動(dòng)作。

有沒有深夜喝完酒和朋友分開的經(jīng)歷。我酒量還可以，所以一般都是擔(dān)心朋友路上出點(diǎn)什么事情，一般我都會(huì)讓朋友到家后發(fā)個(gè)微信表明自己到家了，這樣我收到他的信息后就能安然入睡了。

如果這個(gè)時(shí)候用NAK協(xié)議會(huì)怎樣？對(duì)于一個(gè)本來就不可信的信道而言，就算他給我打了求救電話也有可能接不通，我要等到什么時(shí)候才能確保朋友已經(jīng)安全到家？

TCP的ACK機(jī)制作為時(shí)鐘驅(qū)動(dòng)其發(fā)送引擎源源不斷地發(fā)送數(shù)據(jù)，最終可以適應(yīng)各種網(wǎng)絡(luò)環(huán)境，也正為如此，30多年前的TCP到現(xiàn)在還依然安好(PS：這里并不能讓我釋懷，因?yàn)槲矣憛扵CP。我在這里說TCP的好話，僅僅是因?yàn)樗x擇了ACK而不是NAK這件事是正確的，僅此而已)。

鄙視鏈

把內(nèi)核態(tài)和用戶態(tài)做了一個(gè)界限分明的區(qū)分，于是一條鄙視鏈就形成了，或者說反過來就是是一條膜拜鏈。在內(nèi)核態(tài)寫代碼的鄙視寫應(yīng)用程序的，寫用戶態(tài)代碼的膜拜搞內(nèi)核的(然后把Java和C都扯進(jìn)來，搞C的鄙視搞Java的？)。

先不談鄙視鏈，也不談膜拜鏈。只要區(qū)分了內(nèi)核態(tài)和用戶態(tài)，那么想要實(shí)現(xiàn)一個(gè)功能的時(shí)候，就必然面臨一個(gè)選擇，即在什么態(tài)實(shí)現(xiàn)它。緊接著而來的就是一場(chǎng)論戰(zhàn)，隨便舉幾個(gè)例子。

Linux 2.4內(nèi)核中有個(gè)小型的WEB服務(wù)器，結(jié)果被鄙視了

現(xiàn)如今Facebook搞了個(gè)KTLS，旨在把SSL過程放在內(nèi)核里以支持高性能HTTPS

我自己把OpenVPN數(shù)據(jù)通道移植進(jìn)內(nèi)核，見人就拿這事跟人家炫耀

騰訊F-Stack把BSD協(xié)議棧嫁接在用戶態(tài)，美其名曰高效，靈活

mtcp貌似也做了同樣的事

Telira的銷售不厭其煩告訴我用戶態(tài)的DPI是多么高效

微軟的很多網(wǎng)絡(luò)服務(wù)都實(shí)現(xiàn)在內(nèi)核態(tài)

無論怎么搞，套路基本就是原來在內(nèi)核態(tài)實(shí)現(xiàn)的，現(xiàn)在移到用戶態(tài)，原來在用戶態(tài)實(shí)現(xiàn)的，現(xiàn)在移到內(nèi)核態(tài)，就這么搞來搞去，其中有的很成功，有的就很失敗。

所謂的成功是因?yàn)檫@個(gè)移植解決了特定場(chǎng)景下的特定問題，比如用戶態(tài)協(xié)議棧的mmap+Polling 模式就解決了協(xié)議棧收包PPS吞吐率低的問題，然而很多移植都失敗了，這些失敗的案例很多都是為了移植而移植，故意搗騰的。

請(qǐng)注意，不要被什么用戶態(tài)協(xié)議棧所誤導(dǎo)，世界上沒有萬金油！

正文

很多人混淆了原因和結(jié)果，正如混淆目標(biāo)和手段一樣常見。

我們都知道，Linux內(nèi)核協(xié)議棧收包吞吐低，然而當(dāng)你問起Linux內(nèi)核協(xié)議棧為什么這樣時(shí)，回答大多是“切換開銷大”，“內(nèi)存拷貝太多”，“cache miss太高”，“中斷太頻繁”…

但是注意，作為使用協(xié)議棧的業(yè)務(wù)方?jīng)]人會(huì)關(guān)注這些，實(shí)際上這些都是原因而不是結(jié)果，業(yè)務(wù)關(guān)注的就是收包吞吐低這個(gè)事實(shí)，為什么吞吐低這正是內(nèi)核工程人員要查明并搞定的，上面那些關(guān)于切換，拷貝，cache miss，中斷之類的描述，其實(shí)都是造成收包吞吐低的原因而不是問題本身。

同時(shí)，優(yōu)化掉這些問題并不是目的，目的只有一個(gè)，就是提高收包吞吐，優(yōu)化掉這些問題全部是達(dá)到目的的手段。

手段和目的混淆非常常見，這也是為什么很難有手機(jī)賣過蘋果手機(jī)的原因?？纯刺O果的廣告宣傳的是什么，是產(chǎn)品本身，而很多安卓機(jī)的廣告都是在拼數(shù)據(jù)，大肆宣傳什么CPU，內(nèi)存等硬件采用了什么先進(jìn)的技術(shù)，但是那些買手機(jī)拍視頻的網(wǎng)紅懂這些嗎？關(guān)注這些嗎？

回到協(xié)議棧話題?，F(xiàn)在，我們優(yōu)化的目標(biāo)只有一個(gè)，那就是提高收包吞吐，我們的優(yōu)化目標(biāo)并不是什么避免切換，降低cache miss，避免頻繁中斷這些，這些只是達(dá)到目標(biāo)的手段，如果有更好地手段，我們大可不關(guān)注這些。

同樣的，把協(xié)議棧移來移去的，并不是目標(biāo)，沒有什么公司會(huì)把“將協(xié)議棧移植到用戶態(tài)”，“在內(nèi)核態(tài)實(shí)現(xiàn)HTTP協(xié)議”這種作為KPI，這些都是手段而已，把協(xié)議棧在內(nèi)核態(tài)用戶態(tài)移來移去除了能展示自己高超的水平之外，對(duì)整體目標(biāo)是沒有幫助的。

那么很顯然，如果不用移植，能就地解決問題，那豈不更好？如果我有點(diǎn)石成金的本事，我干嘛還要通過辛勤地工作來讓我的老婆和女兒崇拜我？

接下來就要評(píng)估到底是用移植的手段，還是就地解決的手段來解決協(xié)議棧收包吞吐低的問題。在評(píng)估之前，首先我們要明確問題的原因到底出在哪里。嗯，上面已經(jīng)列舉了一些了，切換開銷大，內(nèi)存拷貝昂貴，cache miss高，中斷太頻繁…

原因知道了，自然就能對(duì)癥下藥了，現(xiàn)在的問題是，需要評(píng)估用戶態(tài)和內(nèi)核態(tài)搞定這些問題的可行性，成本以及難度，來決定到底在什么態(tài)來解決問題，最終其實(shí)會(huì)發(fā)現(xiàn)用戶態(tài)實(shí)現(xiàn)一套協(xié)議棧是更容易的。

換句話說，如果能在內(nèi)核態(tài)協(xié)議棧通過patch的方式解決這些問題，誰也不會(huì)去搞用戶態(tài)協(xié)議棧了。

不是內(nèi)核態(tài)實(shí)現(xiàn)協(xié)議棧不好，而是內(nèi)核態(tài)解決多核下的收包擴(kuò)展性問題很難，因?yàn)長inux內(nèi)核設(shè)計(jì)之初并沒有考慮多核擴(kuò)展性。一旦面對(duì)多核，以下的問題是積重難返的：

任務(wù)切換

內(nèi)存拷貝

CPU跳躍

鎖和中斷

內(nèi)核，至少是Linux內(nèi)核沒有提供任何基礎(chǔ)設(shè)施來完美解決上述問題，隨著CPU核數(shù)越來越多，為了應(yīng)對(duì)上述很多問題將會(huì)導(dǎo)致越來越多的trick加入內(nèi)核，內(nèi)核將會(huì)變得越來越重。

簡而言之，如果能在內(nèi)核態(tài)實(shí)現(xiàn)一個(gè)穩(wěn)定的內(nèi)核線程高效收包，那也并不是不可以，而不是說必須要搞在用戶態(tài)。然而，在內(nèi)核態(tài)實(shí)現(xiàn)這個(gè)確實(shí)不易，正是因?yàn)橛脩魬B(tài)完成同樣的工作更加簡單，才會(huì)出現(xiàn)大量的用戶態(tài)協(xié)議棧。

中斷和輪詢

現(xiàn)在來看一下中斷和輪詢背后的哲學(xué)。

中斷本質(zhì)上是一種節(jié)約的思維影響下的產(chǎn)物，典型的“好萊塢法則”之實(shí)例。這是讓系統(tǒng)被動(dòng)接收通知的方式，雖然在主觀上，這種方式可以讓系統(tǒng)“在沒有收到通知時(shí)干點(diǎn)別的”，但是在客觀現(xiàn)實(shí)看來，這段時(shí)間任何系統(tǒng)都沒法一心一意地去做所謂的“別的”。

都面試過吧，如果你不是什么太牛的人，那么一般很難拿到招聘方人員的聯(lián)系方式，面試完后一句“回去等通知吧”，會(huì)讓多少人能平常心態(tài)等通知的同時(shí)還能繼續(xù)自己的當(dāng)前工作？(我之前不能，但現(xiàn)在確實(shí)可以了，我除外)這個(gè)時(shí)候，很多人都會(huì)想，如果能問一下就好了，然而并不能。

此外，有沒有這樣的經(jīng)歷，當(dāng)你專注地想做一件事時(shí)，最煩人的就是手機(jī)響。此時(shí)很多人都會(huì)手機(jī)靜音且扔遠(yuǎn)一點(diǎn)，等事情做完了再去看一下。

對(duì)，這就是中斷和輪詢的特征。中斷是外界強(qiáng)加給你的信號(hào)，你必須被動(dòng)應(yīng)對(duì)，而輪詢則是你主動(dòng)地在處理事情。對(duì)于中斷而言，其最大的影響就是打斷你當(dāng)前工作的連續(xù)性，而輪詢則不會(huì)，完全在你自己的掌控之中。

對(duì)于我自己而言，我的手機(jī)基本上是常靜音的，微信則是全部“消息免打擾”，我會(huì)選擇在自己idle的時(shí)候主動(dòng)去看手機(jī)消息，以此輪詢的方式治療嚴(yán)重的電話恐懼癥。

那么如何來治療Linux內(nèi)核收包的電話恐懼癥呢？答案是暫時(shí)沒有辦法。

因?yàn)槿绻胫袛嘧冚喸?，那就必然得有一個(gè)內(nèi)核線程去主動(dòng)poll網(wǎng)卡，而這種行為與當(dāng)前的Linux內(nèi)核協(xié)議棧是不相容的，這意味著你要重新在內(nèi)核實(shí)現(xiàn)一套全新的協(xié)議棧，面臨著沒完沒了的panic，oops風(fēng)險(xiǎn)。

雖然Linux已經(jīng)支持socket的busy polling模式，但這也只是緩解，而非根治！相反，完全在用戶態(tài)實(shí)現(xiàn)poll，則是一個(gè)非常干凈的方案。

關(guān)于內(nèi)存拷貝，任務(wù)切換以及cache miss，試著用上面的思路去分析，最終的結(jié)論依然是在用戶態(tài)重新實(shí)現(xiàn)一個(gè)自主的處理進(jìn)程，將會(huì)比修改內(nèi)核協(xié)議棧的方式來的更加干凈。

幾乎所有的評(píng)估結(jié)論表明，用戶態(tài)協(xié)議棧是一個(gè)干凈的方案，但卻并不是唯一正確的方案，更沒有證據(jù)說用戶態(tài)協(xié)議棧是最好的方案。選擇在用戶態(tài)實(shí)現(xiàn)協(xié)議棧解決收包吞吐低的問題，完全是因?yàn)樗仍趦?nèi)核態(tài)解決同樣的問題更加容易，僅此而已。

意義

這里聊一個(gè)哲學(xué)問題。

有人說內(nèi)核就應(yīng)該只負(fù)責(zé)控制平面，數(shù)據(jù)平面的操作全部應(yīng)該交給用戶態(tài)。

好吧，這里又一個(gè)柏拉圖式的分類，實(shí)際上依然毫無意義。當(dāng)然，引出類似概念的人肯定有十足的理由去說服別人相信他的分類是客觀的，有依據(jù)的，但那仍然不過是一種主觀的臆斷。

繼續(xù)說下去的話，也許最終的結(jié)論將是，只有微內(nèi)核體系的操作系統(tǒng)才是最完美的操作系統(tǒng)。但事實(shí)上，我們都在用的幾乎所有操作系統(tǒng)，沒有一個(gè)是完全的微內(nèi)核操作系統(tǒng)，微軟的 Windows 不是，而 Linux 更是一個(gè)宏內(nèi)核系統(tǒng)，沒有微內(nèi)核系統(tǒng)。

看來似乎只有一個(gè)說法能解釋這種矛盾，那就是完美的東西本來就是不存在的，我們看到的世界上所有的東西，都是柏拉圖眼中的影子，而完美則代表了抽象的本質(zhì)，那是上帝的范疇，我們甚至無力去仰望！從小的時(shí)候，我們就被老師告知，世界上不存在完美的球形。

因此，如果微內(nèi)核，宏內(nèi)核根本就不存在，那么憑什么內(nèi)核態(tài)就只能處理控制平面呢？如果內(nèi)核態(tài)處理網(wǎng)絡(luò)協(xié)議棧這種做法是錯(cuò)誤的，那為什么UNIX/Linux的內(nèi)核網(wǎng)絡(luò)協(xié)議棧卻存在了40多年呢？嗯，存在的即是合理的。

世界是進(jìn)化而來的，而不是設(shè)計(jì)而來的，即便是存在設(shè)計(jì)者，也是一個(gè)蹩腳的設(shè)計(jì)者，你看，我們?nèi)梭w本身不就存在很多bug嗎？因此，即便是上帝那里，存在的也是柏拉圖眼里的影子。

審核編輯：劉清