1. 緊急數(shù)據(jù)到底解決了什么問題1.1 從一個(gè)問題場(chǎng)景說起做網(wǎng)絡(luò)編程久了你早晚會(huì)遇到一個(gè)尷尬的局面你的程序正在從網(wǎng)絡(luò)上讀取一大塊數(shù)據(jù)比如一個(gè)正在下載的文件、一段不斷刷新的日志流這時(shí)候用戶突然按下了CtrlC或者點(diǎn)擊了界面上的“取消”按鈕。你的本意是讓對(duì)端立刻停止當(dāng)前的數(shù)據(jù)傳輸去處理這個(gè)中斷請(qǐng)求但TCP是面向字節(jié)流的協(xié)議數(shù)據(jù)是按順序到達(dá)的后發(fā)出來的控制指令排在那幾MB數(shù)據(jù)后面對(duì)端要等這批數(shù)據(jù)全部處理完才能看到你的取消指令。這就好比你在一條單車道公路上開車前面堵了一長(zhǎng)串貨車你有一輛救護(hù)車要過去但公路沒有應(yīng)急車道。你只能等貨車一輛一輛挪走救護(hù)車才能通過。對(duì)于很多實(shí)時(shí)性要求高的場(chǎng)景這個(gè)等待是不可接受的。TCP的緊急數(shù)據(jù)機(jī)制就是為了給這條“數(shù)據(jù)公路”留出一條應(yīng)急通道而設(shè)計(jì)的。它屬于TCP協(xié)議棧中一個(gè)相對(duì)冷門、但關(guān)鍵時(shí)刻能救命的特性。很多人學(xué)TCP的時(shí)候注意力全放在三次握手、四次揮手、滑動(dòng)窗口、擁塞控制這些大塊頭上緊急數(shù)據(jù)這個(gè)知識(shí)點(diǎn)往往被一筆帶過。但真到了需要它的時(shí)候如果不懂它內(nèi)部的指針計(jì)算規(guī)則和邊界語義寫出來的代碼大概率會(huì)在某些邊界條件下翻車。這篇文章會(huì)把TCP緊急數(shù)據(jù)的機(jī)制從頭到尾拆開講清楚包括URG標(biāo)志和緊急指針的配合方式、緊急數(shù)據(jù)與帶外數(shù)據(jù)的區(qū)別、在Linux套接字編程里怎么收發(fā)緊急數(shù)據(jù)、以及實(shí)際落地時(shí)那些文檔里不會(huì)明說的坑。1.2 緊急數(shù)據(jù)、帶外數(shù)據(jù)、URG標(biāo)志先分清概念先說清楚術(shù)語。TCP頭部里有兩個(gè)字段和緊急數(shù)據(jù)直接相關(guān)URG標(biāo)志位1個(gè)bit表示當(dāng)前報(bào)文段中攜帶了緊急數(shù)據(jù)。緊急指針Urgent Pointer16位用于標(biāo)記緊急數(shù)據(jù)在報(bào)文段中的位置。教科書上常把TCP緊急數(shù)據(jù)等同于“帶外數(shù)據(jù)Out-of-Band Data簡(jiǎn)稱OOB”這個(gè)說法有歷史原因但嚴(yán)格來說它倆并不完全對(duì)等。帶外數(shù)據(jù)是一個(gè)通用的概念指的是與普通數(shù)據(jù)流分開傳輸、擁有獨(dú)立處理通道的數(shù)據(jù)。而在TCP里并沒有真正獨(dú)立的物理通道所謂“帶外”是靠緊急指針在同一個(gè)字節(jié)流里臨時(shí)劃出一塊區(qū)域來實(shí)現(xiàn)的本質(zhì)上還是走同一條TCP連接、同一個(gè)字節(jié)流。這個(gè)設(shè)計(jì)的精妙之處在于TCP不額外建立連接、不額外占用端口只是通過頭部的標(biāo)志和指針在既有數(shù)據(jù)流里標(biāo)記出一段“需要接收方特殊對(duì)待”的數(shù)據(jù)。它犧牲了一點(diǎn)點(diǎn)帶寬效率換來了傳輸通道的復(fù)用和實(shí)現(xiàn)的簡(jiǎn)潔。TCP緊急數(shù)據(jù)機(jī)制最初的目標(biāo)場(chǎng)景是交互式應(yīng)用。比如古老的telnet協(xié)議用戶在終端里按下了中斷鍵這個(gè)中斷信號(hào)需要立刻到達(dá)遠(yuǎn)端執(zhí)行中斷邏輯而不是排隊(duì)等當(dāng)前輸出流走完。TCP緊急數(shù)據(jù)正好滿足了這種“發(fā)送一個(gè)短小控制信號(hào)要求對(duì)端立刻處理”的需求。到了今天這個(gè)機(jī)制仍然以各種形式存在于傳輸層只是很多上層的應(yīng)用協(xié)議已經(jīng)不再依賴它了。至于為什么后來大家不愛用后面我在應(yīng)用場(chǎng)景這一節(jié)里會(huì)詳細(xì)分析。2. 緊急指針的計(jì)算規(guī)則最容易翻車的地方2.1 緊急指針到底指向哪里TCP緊急指針的語義是理解整個(gè)機(jī)制最關(guān)鍵、也最容易出錯(cuò)的地方。先看協(xié)議規(guī)范的定義緊急指針是一個(gè)正的偏移量它和當(dāng)前報(bào)文段的序號(hào)相加得到的是緊急數(shù)據(jù)最后一個(gè)字節(jié)的下一個(gè)位置。注意這個(gè)表述緊急指針指向的不是緊急數(shù)據(jù)的起始位置也不是緊急數(shù)據(jù)的最后一個(gè)字節(jié)而是最后一個(gè)字節(jié)之后的位置。這個(gè)“偏移一個(gè)字節(jié)”的規(guī)則坑過不知道多少初學(xué)者也讓不同操作系統(tǒng)在實(shí)現(xiàn)時(shí)產(chǎn)生過微妙的差異。舉個(gè)例子。假設(shè)當(dāng)前TCP報(bào)文段的序列號(hào)是1000緊急指針的值是5那么緊急數(shù)據(jù)最后一個(gè)字節(jié)的序列號(hào)是1004緊急數(shù)據(jù)區(qū)間涵蓋了序列號(hào)1000到1004。接收方拿到這段數(shù)據(jù)后會(huì)認(rèn)為前面的這5個(gè)字節(jié)是緊急數(shù)據(jù)文件名緊急數(shù)據(jù)之外的內(nèi)容都是普通數(shù)據(jù)。實(shí)際計(jì)算時(shí)用到的公式是指針指向的序號(hào) 報(bào)文段序號(hào) 緊急指針值所以當(dāng)緊急指針值為1時(shí)指向的序號(hào)就是報(bào)文段本身序號(hào)的下一個(gè)位置。這在特殊場(chǎng)景下意味著什么如果緊急指針為0實(shí)際上沒有緊急數(shù)據(jù)如果緊急指針為1那么緊急數(shù)據(jù)可能只有0個(gè)有效字節(jié)僅起到“進(jìn)入緊急模式”的作用。這種邊界情況相當(dāng)微妙后面我會(huì)結(jié)合代碼再講。2.2 緊急指針偏移量的經(jīng)典誤解很多人在第一次看RFC 793的時(shí)候都會(huì)對(duì)緊急指針產(chǎn)生這樣一個(gè)誤解以為緊急指針就是緊急數(shù)據(jù)的字節(jié)數(shù)。這個(gè)理解在大多數(shù)情況下恰好碰巧能工作因?yàn)榫o急數(shù)據(jù)通常就在報(bào)文段的開頭指針值確實(shí)等于緊急數(shù)據(jù)的長(zhǎng)度。但一旦緊急數(shù)據(jù)不是從報(bào)文段開頭開始的這個(gè)理解就不成立了。舉個(gè)典型的場(chǎng)景發(fā)送方調(diào)用了多次send函數(shù)先發(fā)送了一段普通數(shù)據(jù)緊接著發(fā)送了緊急數(shù)據(jù)。在TCP的實(shí)現(xiàn)中這兩個(gè)write操作可能被合并到同一個(gè)報(bào)文段里發(fā)出。此時(shí)這個(gè)報(bào)文段的起始序列號(hào)對(duì)應(yīng)的是普通數(shù)據(jù)的開頭緊急指針的值等于“普通數(shù)據(jù)長(zhǎng)度 緊急數(shù)據(jù)長(zhǎng)度”。如果你按“指針值 緊急數(shù)據(jù)長(zhǎng)度”來理解解析出的數(shù)據(jù)邊界就錯(cuò)了多讀了普通數(shù)據(jù)進(jìn)去。還有一種情況更隱蔽緊急指針指向的序號(hào)可能超出當(dāng)前報(bào)文段的數(shù)據(jù)范圍。比如發(fā)送方先發(fā)了一個(gè)只包含普通數(shù)據(jù)的報(bào)文段此時(shí)套接字已經(jīng)被標(biāo)記為進(jìn)入緊急模式但緊急數(shù)據(jù)本身還留在發(fā)送緩沖區(qū)里沒有隨這個(gè)報(bào)文段發(fā)出。接收方收到這個(gè)報(bào)文段時(shí)會(huì)從緊急指針計(jì)算出“緊急數(shù)據(jù)的結(jié)束位置”從而知道字節(jié)流中哪些區(qū)域?qū)儆诰o急模式范圍?？墒沁@個(gè)范圍在當(dāng)前報(bào)文段里只覆蓋了一部分接收方需要等后續(xù)的報(bào)文段到達(dá)才能真正拿到緊急數(shù)據(jù)的內(nèi)容。這個(gè)“緊急模式”是個(gè)很關(guān)鍵的狀態(tài)概念。TCP不是簡(jiǎn)單地把緊急數(shù)據(jù)當(dāng)作報(bào)文里的一個(gè)特殊載荷而是讓接收方進(jìn)入一種“緊急模式”在該模式下所有落在緊急指針之前、但還未被消費(fèi)的數(shù)據(jù)都會(huì)被視作緊急數(shù)據(jù)的一部分。這意味著緊急數(shù)據(jù)并不一定只存在于那個(gè)帶有URG標(biāo)志的報(bào)文段里它可能跨越多個(gè)報(bào)文段。2.3 緊急指針與序列號(hào)回繞的配合TCP的序列號(hào)是32位無符號(hào)整數(shù)最大值是2^32 - 1。當(dāng)序列號(hào)增長(zhǎng)到最大值后會(huì)回繞到0重新開始。緊急指針作為一個(gè)偏移量與序列號(hào)相加時(shí)也應(yīng)遵循同樣的無符號(hào)回繞規(guī)則。這個(gè)細(xì)節(jié)在正常情況下不會(huì)引發(fā)問題但在高帶寬長(zhǎng)連接場(chǎng)景下如果連接持續(xù)收發(fā)數(shù)據(jù)足夠久序列號(hào)回繞是必然發(fā)生的。此時(shí)如果緊急指針的計(jì)算不按回繞規(guī)則處理就會(huì)算出錯(cuò)誤的緊急數(shù)據(jù)邊界。好在Linux內(nèi)核的TCP實(shí)現(xiàn)中所有序列號(hào)比較都是通過內(nèi)核提供的相關(guān)宏來做無符號(hào)回繞判斷的應(yīng)用層不需要自己處理但了解這一點(diǎn)能幫你理解為什么有些資料里反復(fù)強(qiáng)調(diào)序列號(hào)比較不能直接用普通小于大于號(hào)。3. 緊急模式與緊急數(shù)據(jù)讀取接收方的視角3.1 接收方如何判斷“進(jìn)入緊急模式”TCP接收方收到帶有URG標(biāo)志的報(bào)文段后會(huì)做兩件事第一記錄緊急指針指向的序列號(hào)第二比較這個(gè)緊急序列號(hào)與當(dāng)前已接收數(shù)據(jù)的序列號(hào)如果緊急序列號(hào)大于當(dāng)前已確認(rèn)的序列號(hào)就認(rèn)為進(jìn)入了緊急模式。為什么“大于”這個(gè)條件很重要因?yàn)門CP的緊急指針是一個(gè)位置標(biāo)記它并不保證緊急數(shù)據(jù)此刻已經(jīng)到達(dá)接收方。它只是告訴你從這個(gè)位置往前、但你還沒收到的那些數(shù)據(jù)都屬于緊急數(shù)據(jù)。如果你已經(jīng)收到了緊急指針之后的數(shù)據(jù)說明緊急數(shù)據(jù)區(qū)已經(jīng)完整到達(dá)緊急狀態(tài)隨之解除。這就引出一個(gè)很容易忽略的點(diǎn)緊急模式是一個(gè)隨數(shù)據(jù)流動(dòng)而動(dòng)態(tài)變化的狀態(tài)。它不是一次性事件而是跟著字節(jié)流走的一段標(biāo)記區(qū)間。應(yīng)用程序使用select或poll監(jiān)聽異常事件時(shí)只有當(dāng)緊急指針推進(jìn)到有新數(shù)據(jù)進(jìn)入緊急范圍時(shí)才會(huì)觸發(fā)可讀異常事件。如果緊急數(shù)據(jù)已經(jīng)全部被消費(fèi)完緊急模式解除異常事件不會(huì)再觸發(fā)。3.2 一次只能讀一個(gè)字節(jié)MSG_OOB的限制在Linux的伯克利套接字API里接收緊急數(shù)據(jù)是通過recv函數(shù)的MSG_OOB標(biāo)志完成的。有一個(gè)很多新手會(huì)踩的坑通過MSG_OOB讀取緊急數(shù)據(jù)時(shí)一次recv只能讀取一個(gè)字節(jié)。是的你沒看錯(cuò)一次只能讀一個(gè)字節(jié)。無論你傳入的緩沖區(qū)多大MSG_OOB讀取都會(huì)嚴(yán)格限制為1字節(jié)。這不是Linux的bug而是POSIX規(guī)范明確規(guī)定的行為。原因是TCP緊急數(shù)據(jù)在字節(jié)流里的語義就是“緊急數(shù)據(jù)最后一個(gè)字節(jié)及其之前未被消費(fèi)的部分”而緊急數(shù)據(jù)區(qū)通常沒有明確的起始邊界唯一能確定的是它結(jié)束的位置。既然邊界不明確規(guī)范干脆規(guī)定每次只允許讀取最后那個(gè)字節(jié)保證語義清晰。如果需要讀取完整的緊急數(shù)據(jù)就必須反復(fù)調(diào)用recv(MSG_OOB)直到讀到緊急指針之前的數(shù)據(jù)全部消費(fèi)完最后一次讀取會(huì)返回錯(cuò)誤表示緊急數(shù)據(jù)已經(jīng)讀完。這個(gè)限制直接導(dǎo)致了一個(gè)常見問題如果緊急數(shù)據(jù)的長(zhǎng)度超過1字節(jié)應(yīng)用層就需要循環(huán)讀取。而循環(huán)讀取的過程中緊急模式已經(jīng)解除后續(xù)的數(shù)據(jù)可能已經(jīng)混入普通數(shù)據(jù)流處理起來要額外小心。3.3 select異常事件與SIGURG信號(hào)接收方接收緊急數(shù)據(jù)有兩種常見的通知機(jī)制第一種是使用select或poll監(jiān)聽套接字的異常事件。在select中對(duì)應(yīng)的是exceptfds集合在poll中對(duì)應(yīng)的是POLLPRI事件。當(dāng)收到新的緊急數(shù)據(jù)時(shí)該事件會(huì)觸發(fā)應(yīng)用可以得知“有緊急數(shù)據(jù)可讀”再調(diào)用recv(MSG_OOB)去消費(fèi)。第二種是使用信號(hào)。在Linux中可以設(shè)置SIGURG信號(hào)的處理函數(shù)當(dāng)緊急數(shù)據(jù)到達(dá)時(shí)內(nèi)核向進(jìn)程發(fā)送SIGURG信號(hào)。這個(gè)方式的實(shí)時(shí)性更好適合交互型應(yīng)用。配合fcntl的F_SETOWN操作把套接字的所有權(quán)指定給某個(gè)進(jìn)程或進(jìn)程組SIGURG才會(huì)準(zhǔn)確投遞給目標(biāo)進(jìn)程。需要留意的是SIGURG和select的異常事件各有利弊。信號(hào)方式實(shí)時(shí)性好但信號(hào)處理函數(shù)里有諸多限制不適合做復(fù)雜邏輯select方式更簡(jiǎn)單直觀但Linux對(duì)緊急數(shù)據(jù)的通知粒度較粗不是每個(gè)緊急字節(jié)都會(huì)觸發(fā)一次事件而是僅在緊急指針推進(jìn)時(shí)觸發(fā)。4. 緊急數(shù)據(jù)的高層語義從應(yīng)用到內(nèi)核的調(diào)用鏈4.1 發(fā)送端如何發(fā)送緊急數(shù)據(jù)發(fā)送緊急數(shù)據(jù)在Linux下使用send函數(shù)并傳入MSG_OOB標(biāo)志。來看一個(gè)最簡(jiǎn)單的發(fā)送示例#include sys/socket.h #include netinet/in.h #include stdio.h #include string.h #include unistd.h int main() { int sock socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_LOOPBACK); addr.sin_port htons(9999); if (connect(sock, (struct sockaddr*)addr, sizeof(addr)) 0) { perror(connect); return 1; } // 先發(fā)送普通數(shù)據(jù) const char *normal_msg hello normal data, this is a long message; send(sock, normal_msg, strlen(normal_msg), 0); // 再發(fā)送緊急數(shù)據(jù) const char *urgent_msg X; int ret send(sock, urgent_msg, strlen(urgent_msg), MSG_OOB); if (ret 0) { perror(send MSG_OOB); } close(sock); return 0; }發(fā)送端調(diào)用send(MSG_OOB)時(shí)內(nèi)核會(huì)做以下幾件事將待發(fā)送的數(shù)據(jù)放入發(fā)送隊(duì)列并計(jì)算出緊急指針。在下一個(gè)發(fā)出的TCP報(bào)文段中設(shè)置URG標(biāo)志。更新TCP控制塊中的緊急指針字段。值得注意的細(xì)節(jié)是MSG_OOB的發(fā)送不要求緊急數(shù)據(jù)只有一個(gè)字節(jié)你可以一次發(fā)送多個(gè)字節(jié)的緊急數(shù)據(jù)。發(fā)送方并沒有“一次只能發(fā)一個(gè)字節(jié)”的限制這個(gè)限制只存在于接收方的recv調(diào)用。但從規(guī)范化設(shè)計(jì)的角度我強(qiáng)烈建議每次只發(fā)送1字節(jié)。這不是因?yàn)閰f(xié)議限制而是因?yàn)槎嘧止?jié)緊急數(shù)據(jù)在接收端的讀取實(shí)在太別扭了。你發(fā)3個(gè)字節(jié)緊急數(shù)據(jù)接收端要循環(huán)調(diào)用3次recv(MSG_OOB)才能全部取出來中間還得處理狀態(tài)切換麻煩不說還容易出錯(cuò)。所以在設(shè)計(jì)應(yīng)用協(xié)議時(shí)緊急數(shù)據(jù)最好承載“命令字”或“單字節(jié)信號(hào)”這種小顆粒信息。4.2 內(nèi)核對(duì)緊急指針的更新策略再看內(nèi)核的視角。發(fā)送方調(diào)用send(MSG_OOB)之后TCP的發(fā)送路徑會(huì)更新發(fā)送隊(duì)列的緊急指針。具體來說緊急指針指向當(dāng)前發(fā)送隊(duì)列中最后一個(gè)已寫入字節(jié)的下一個(gè)位置。后續(xù)發(fā)送普通數(shù)據(jù)時(shí)緊急指針不再改變。這個(gè)更新策略決定了緊急數(shù)據(jù)的邊界從進(jìn)入緊急模式的那一刻起到發(fā)送緊急數(shù)據(jù)的那個(gè)字節(jié)為止中間所有數(shù)據(jù)都會(huì)被接收方視為緊急數(shù)據(jù)。舉一個(gè)實(shí)際例子發(fā)送方先發(fā)送10個(gè)字節(jié)的普通數(shù)據(jù)然后發(fā)送5個(gè)字節(jié)的緊急數(shù)據(jù)中間沒有別的操作。那么從接收方的視角看這15個(gè)字節(jié)全部處于緊急模式范圍內(nèi)。接收方如果聰明的話會(huì)認(rèn)為前面10個(gè)字節(jié)是緊急數(shù)據(jù)的一部分或者至少會(huì)知道緊急模式一直持續(xù)到第15個(gè)字節(jié)結(jié)束。這個(gè)語義對(duì)于純收發(fā)場(chǎng)景影響不大但如果你的程序需要精確區(qū)分緊急數(shù)據(jù)和普通數(shù)據(jù)一定要意識(shí)到TCP緊急數(shù)據(jù)沒有“起始邊界”。它只知道從哪里結(jié)束不知道從哪里開始。在協(xié)議設(shè)計(jì)上如果需要明確區(qū)分上層協(xié)議必須額外攜帶邊界信息。4.3 TCP緊急模式與普通數(shù)據(jù)流的混合有人會(huì)問緊急數(shù)據(jù)會(huì)不會(huì)打斷普通數(shù)據(jù)流優(yōu)先發(fā)送答案是不會(huì)完全打斷但會(huì)有限地插隊(duì)。TCP的緊急數(shù)據(jù)并沒有獨(dú)立的優(yōu)先級(jí)隊(duì)列。它還是和普通數(shù)據(jù)一樣進(jìn)入同一個(gè)發(fā)送緩沖區(qū)。區(qū)別在于帶有URG標(biāo)志的報(bào)文段在接收端的處理路徑上會(huì)被更快地識(shí)別應(yīng)用層也能通過通知機(jī)制更快地感知。但在網(wǎng)絡(luò)上傳輸時(shí)它并不會(huì)搶在普通數(shù)據(jù)前面飛也不會(huì)獲得路由器或交換機(jī)的特殊優(yōu)先級(jí)。那“緊急”體現(xiàn)在哪里主要體現(xiàn)在接收路徑的處理效率。接收端的TCP協(xié)議棧一旦發(fā)現(xiàn)URG標(biāo)志會(huì)立刻更新緊急指針狀態(tài)并通過信號(hào)或I/O事件通知應(yīng)用層。應(yīng)用層收到通知后可以決定優(yōu)先讀取這批數(shù)據(jù)。所以緊急數(shù)據(jù)更準(zhǔn)確的定位是給應(yīng)用層的一個(gè)快速提醒信號(hào)而不是傳輸層的搶道機(jī)制。這個(gè)認(rèn)知偏差是很多工程師誤解緊急數(shù)據(jù)性能特性的根源。如果追求絕對(duì)的端到端低時(shí)延應(yīng)該考慮獨(dú)立的控制連接而不是依賴緊急數(shù)據(jù)。5. 實(shí)際應(yīng)用場(chǎng)景哪些協(xié)議還在用緊急數(shù)據(jù)5.1 經(jīng)典場(chǎng)景telnet與交互式控制TCP緊急數(shù)據(jù)機(jī)制從誕生之日起就跟telnet這類交互式協(xié)議深度綁定。telnet協(xié)議中定義了一套IP選項(xiàng)和命令其中就包括“中斷進(jìn)程”等控制類命令。當(dāng)用戶按下CtrlCtelnet客戶端會(huì)發(fā)送緊急數(shù)據(jù)服務(wù)器收到后立刻中斷當(dāng)前正在執(zhí)行的命令而不是等輸出流走完。這種場(chǎng)景之所以適合緊急數(shù)據(jù)是因?yàn)榻换ナ浇K端里用戶的操作意圖非常迫切等不起普通數(shù)據(jù)的排隊(duì)。今天的telnet已經(jīng)很少直接使用了但很多telnet的替代品和遠(yuǎn)程終端工具在設(shè)計(jì)時(shí)仍然借鑒了這套思路。如果你去翻SSH的實(shí)現(xiàn)會(huì)發(fā)現(xiàn)SSH協(xié)議本身沒有采用TCP的緊急數(shù)據(jù)機(jī)制而是通過獨(dú)立的通道和消息類型來區(qū)分控制消息和普通數(shù)據(jù)。這在架構(gòu)上更清晰也更容易在復(fù)雜的網(wǎng)絡(luò)環(huán)境下保持穩(wěn)定。5.2 rlogin時(shí)代的OOB用法比telnet更有名的是rlogin。BSD的rlogin協(xié)議把TCP緊急數(shù)據(jù)當(dāng)作真正的“帶外帶內(nèi)結(jié)合體”來用控制消息都通過緊急數(shù)據(jù)發(fā)送普通終端輸出走正常數(shù)據(jù)流。這套設(shè)計(jì)在當(dāng)時(shí)很成功rlogin的交互體驗(yàn)比telnet更流暢尤其是控制字符的響應(yīng)速度。rlogin的具體做法是這樣的客戶端發(fā)送一個(gè)字節(jié)的緊急數(shù)據(jù)這個(gè)字節(jié)被用作控制消息的類型標(biāo)記隨后緊跟的普通數(shù)據(jù)作為參數(shù)。所有數(shù)據(jù)都走同一條TCP連接但控制消息通過緊急指針快速到達(dá)對(duì)端。接收方的rlogin服務(wù)器通過SIGURG信號(hào)感知緊急數(shù)據(jù)到達(dá)然后立刻處理。這個(gè)用法直到今天還被一些老牌網(wǎng)絡(luò)設(shè)備的配置工具沿用。比如某些網(wǎng)絡(luò)設(shè)備的命令行配置接口在進(jìn)行大文件傳輸?shù)耐瑫r(shí)仍需要響應(yīng)CtrlC這樣中斷操作就會(huì)使用類似機(jī)制。5.3 為什么現(xiàn)代應(yīng)用紛紛放棄緊急數(shù)據(jù)既然緊急數(shù)據(jù)設(shè)計(jì)得這么精巧為什么現(xiàn)代應(yīng)用反而不愛用了我總結(jié)了幾個(gè)主要原因第一跨平臺(tái)語義不統(tǒng)一。雖然TCP協(xié)議規(guī)定了緊急指針的計(jì)算方式但各操作系統(tǒng)在應(yīng)用層暴露的接口語義并不完全一致。同樣是recv(MSG_OOB)在不同平臺(tái)上能讀到的字節(jié)數(shù)、緊急指針的推進(jìn)時(shí)機(jī)都有細(xì)微差別。這給跨平臺(tái)開發(fā)帶來了額外負(fù)擔(dān)。第二中間設(shè)備的干擾。眾多NAT網(wǎng)關(guān)、代理服務(wù)器、負(fù)載均衡器在處理TCP緊急數(shù)據(jù)時(shí)行為不一。有些實(shí)現(xiàn)會(huì)直接忽略URG標(biāo)志有些會(huì)試圖重寫緊急指針結(jié)果改錯(cuò)導(dǎo)致數(shù)據(jù)錯(cuò)亂。在一個(gè)復(fù)雜網(wǎng)絡(luò)路徑上緊急數(shù)據(jù)能不能可靠抵達(dá)對(duì)端很多時(shí)候是個(gè)玄學(xué)問題。第三應(yīng)用層協(xié)議的設(shè)計(jì)范式變了?，F(xiàn)代應(yīng)用層協(xié)議更傾向于使用獨(dú)立的控制通道或顯式的消息類型來區(qū)分命令和數(shù)據(jù)。比如HTTP/2的多路復(fù)用、WebSocket的幀類型、gRPC的獨(dú)立調(diào)用上下文都提供了比緊急數(shù)據(jù)更清晰、更可控的機(jī)制。傳輸層的緊急數(shù)據(jù)反而顯得太底層、太簡(jiǎn)陋。第四安全考量。緊急數(shù)據(jù)的處理路徑在歷史上出過不少安全漏洞包括緩沖區(qū)處理不當(dāng)導(dǎo)致的堆溢出、緊急指針異常導(dǎo)致的拒絕服務(wù)攻擊?，F(xiàn)代安全實(shí)踐中很多運(yùn)維人員會(huì)建議關(guān)閉或嚴(yán)格限制緊急數(shù)據(jù)的處理減少攻擊面。5.4 緊急數(shù)據(jù)在物聯(lián)網(wǎng)和工業(yè)控制中的現(xiàn)狀物聯(lián)網(wǎng)和工業(yè)控制領(lǐng)域是目前仍在使用TCP緊急數(shù)據(jù)為數(shù)不多的活躍場(chǎng)景之一。原因很簡(jiǎn)單輕量級(jí)設(shè)備上資源有限不想為偶爾一兩次的控制指令單獨(dú)建立連接。而TCP緊急數(shù)據(jù)的實(shí)現(xiàn)成本低、占用帶寬小契合這類設(shè)備的訴求。比如某些傳感器網(wǎng)關(guān)通過TCP上傳大批量采樣數(shù)據(jù)同時(shí)需要及時(shí)響應(yīng)主站下發(fā)的校準(zhǔn)指令。這種情況下校準(zhǔn)指令通過緊急數(shù)據(jù)發(fā)送采樣數(shù)據(jù)走普通字節(jié)流既不用額外維護(hù)一條連接又能滿足控制指令的時(shí)延要求。但請(qǐng)注意即便在這些場(chǎng)景里緊急數(shù)據(jù)也只是作為一種“改造方案”在使用業(yè)界很多新設(shè)計(jì)已經(jīng)開始轉(zhuǎn)向在普通數(shù)據(jù)流中內(nèi)嵌控制消息幀或者使用TCP_NOTSENT_LOWAT等機(jī)制來優(yōu)化發(fā)送緩沖區(qū)的調(diào)度。6. 常見問題與排查技巧實(shí)錄6.1 緊急數(shù)據(jù)讀取不完整的根因我見過不少同事在實(shí)際開發(fā)中遇到這樣的問題發(fā)送方明明發(fā)送了3字節(jié)的緊急數(shù)據(jù)接收方調(diào)用recv(MSG_OOB)卻只能收到1個(gè)字節(jié)后續(xù)數(shù)據(jù)怎么都讀不到了。排查很久才發(fā)現(xiàn)接收方只觸發(fā)了一次異常事件而一次讀取只能消費(fèi)1字節(jié)。這個(gè)問題的根源在于接收方對(duì)緊急模式的理解有偏差。緊急模式是一個(gè)動(dòng)態(tài)推進(jìn)的狀態(tài)它需要通過多次處理來逐步消化。正確的做法是char buf[16]; int ret; while (1) { ret recv(sock, buf, sizeof(buf), MSG_OOB); if (ret 0) { // 當(dāng)緊急數(shù)據(jù)全部讀取完畢時(shí)recv會(huì)返回EINVAL錯(cuò)誤 if (errno EINVAL) break; // 其他錯(cuò)誤處理 break; } // 處理讀取到的緊急數(shù)據(jù)字節(jié) process_urgent_byte(buf[0]); }循環(huán)讀取到返回EINVAL錯(cuò)誤說明緊急數(shù)據(jù)已經(jīng)全部消費(fèi)完。但這里還有個(gè)細(xì)節(jié)EINVAL是在緊急數(shù)據(jù)全部讀完、且沒有其他未讀數(shù)據(jù)時(shí)返回的。如果讀到一半套接字變得不可讀也可能返回EAGAIN。所以循環(huán)讀取務(wù)必區(qū)分EINVAL和EAGAIN不要混為一談。6.2 緊急模式與已緩存數(shù)據(jù)的關(guān)系一個(gè)更隱蔽的坑是TCP接收緩沖區(qū)里已經(jīng)堆積了大量普通數(shù)據(jù)此時(shí)緊急數(shù)據(jù)到達(dá)。由于緊急指針指向的是序列號(hào)空間中的一個(gè)位置接收方內(nèi)核會(huì)標(biāo)記從當(dāng)前已讀位置到緊急指針之間的所有數(shù)據(jù)都屬于緊急模式范圍。這意味著那堆積在緩沖區(qū)里的普通數(shù)據(jù)有一部分會(huì)被當(dāng)作緊急數(shù)據(jù)的一部分。這會(huì)導(dǎo)致什么后果如果應(yīng)用層只依賴select的異常事件而不去讀取普通數(shù)據(jù)那么緊急數(shù)據(jù)會(huì)被阻塞在緩沖區(qū)里因?yàn)閮?nèi)核必須在所有緊急模式范圍內(nèi)的數(shù)據(jù)都消費(fèi)完后才會(huì)解除緊急狀態(tài)。舉個(gè)具體例子接收緩沖區(qū)里已經(jīng)有100字節(jié)普通數(shù)據(jù)此時(shí)收到緊急指針指向位置120的緊急數(shù)據(jù)。緊急模式覆蓋了從當(dāng)前讀取位置比如0到120的全部范圍。應(yīng)用層如果只通過MSG_OOB讀取一次只能讀到位置120那個(gè)字節(jié)還有中間119個(gè)字節(jié)只能通過普通recv讀取。如果不讀這119字節(jié)緊急模式就一直不解除select異常事件會(huì)反復(fù)觸發(fā)造成事件風(fēng)暴。這種問題的排查思路是查看套接字接收緩沖區(qū)的未讀字節(jié)數(shù)并對(duì)比緊急指針的位置判斷緊急范圍內(nèi)是否堆積了過多普通數(shù)據(jù)。如果積壓嚴(yán)重說明應(yīng)用層消費(fèi)普通數(shù)據(jù)的速度跟不上需要優(yōu)化普通數(shù)據(jù)的讀取邏輯。6.3 用tcpdump抓包觀察緊急數(shù)據(jù)排查緊急數(shù)據(jù)問題最有效的手段是抓包。tcpdump可以通過特定過濾條件查看TCP頭部的URG標(biāo)志和緊急指針tcpdump -i eth0 tcp[13] 0x20 ! 0這個(gè)過濾條件的意思是TCP頭部第13個(gè)字節(jié)的二進(jìn)制位中URG標(biāo)志位0x20非零即帶有緊急數(shù)據(jù)的報(bào)文段。抓包時(shí)重點(diǎn)關(guān)注幾個(gè)信息URG標(biāo)志是否按預(yù)期置位。緊急指針的值是否符合預(yù)期。緊急指針指向的序列號(hào)與報(bào)文段數(shù)據(jù)范圍的關(guān)系。當(dāng)一個(gè)帶有URG標(biāo)志的報(bào)文段到達(dá)接收端你可以在tcpdump輸出里看到類似這樣的行12:34:56.789012 IP 10.0.0.1.54321 10.0.0.2.80: Flags [P.], seq 1000:1010, ack 2000, win 4096, urg 5, length 10urg后面的數(shù)值就是緊急指針值。結(jié)合seq的值可以算出緊急數(shù)據(jù)結(jié)束的序列號(hào)是1010 5 1015。如果這個(gè)值超過了報(bào)文段本身的結(jié)束序列號(hào)1010說明緊急數(shù)據(jù)范圍沒有在當(dāng)前報(bào)文段內(nèi)結(jié)束接收方需要等后續(xù)報(bào)文段。這個(gè)判斷對(duì)于確認(rèn)緊急模式的結(jié)束位置非常關(guān)鍵。6.4 與其他傳輸特性的沖突案例最后分享一個(gè)真實(shí)的沖突案例。某項(xiàng)目里客戶端通過TCP上傳大文件同時(shí)需要在收到服務(wù)端的取消指令后立即停止上傳。工程師使用了緊急數(shù)據(jù)來傳遞取消指令開發(fā)環(huán)境下一切正常但上了生產(chǎn)環(huán)境后取消操作經(jīng)常要延遲好幾秒才生效。排查發(fā)現(xiàn)這個(gè)項(xiàng)目的TCP窗口設(shè)置非常大且客戶端一直在滿速發(fā)送數(shù)據(jù)。當(dāng)服務(wù)端發(fā)送緊急數(shù)據(jù)時(shí)客戶端的數(shù)據(jù)還在瘋狂地填充網(wǎng)絡(luò)緩沖區(qū)和接收緩沖區(qū)緊急數(shù)據(jù)雖然被標(biāo)記了URG但在接收路徑上仍然排在大量已收到的普通數(shù)據(jù)后面。服務(wù)端的應(yīng)用層雖然立即知道了緊急數(shù)據(jù)到達(dá)但客戶端這邊的發(fā)送緩沖區(qū)堆積了大量數(shù)據(jù)應(yīng)用層要等這些數(shù)據(jù)全部確認(rèn)或超時(shí)重傳才能真正停下來。這個(gè)案例說明了一個(gè)常被忽視的事實(shí)緊急數(shù)據(jù)只能保證接收端快速感知不能保證接收端立刻中斷當(dāng)前的數(shù)據(jù)流。如果你想實(shí)現(xiàn)“立即停止”這種強(qiáng)實(shí)時(shí)控制最佳實(shí)踐還是使用獨(dú)立的控制連接或者結(jié)合SO_RCVLOWAT等套接字選項(xiàng)來調(diào)整接收路徑的調(diào)度。6.5 緊急數(shù)據(jù)使用建議速查如果看完前面這些分析你仍然決定在自己的協(xié)議中使用TCP緊急數(shù)據(jù)這幾點(diǎn)建議可以幫你少踩坑緊急數(shù)據(jù)盡量只發(fā)送1個(gè)字節(jié)避免多字節(jié)讀取帶來的邊界問題。接收方用循環(huán)recv(MSG_OOB)消費(fèi)緊急數(shù)據(jù)區(qū)分處理EINVAL和EAGAIN。緊急數(shù)據(jù)只用來傳遞“提醒”或“命令字”不要承載完整業(yè)務(wù)數(shù)據(jù)。結(jié)合select異常事件或SIGURG信號(hào)使用注意事件通知和實(shí)際讀取之間的競(jìng)態(tài)。在協(xié)議設(shè)計(jì)上預(yù)留緊急指針越界后的對(duì)端行為驗(yàn)證確保中間設(shè)備不會(huì)篡改URG標(biāo)志。生產(chǎn)環(huán)境務(wù)必用tcpdump或協(xié)議分析工具驗(yàn)證緊急指針的計(jì)算結(jié)果不要只憑代碼邏輯推測(cè)。7. 緊急數(shù)據(jù)的替代方案與選型思考7.1 獨(dú)立控制連接如果你的應(yīng)用對(duì)控制指令的實(shí)時(shí)性要求極高且網(wǎng)絡(luò)路徑復(fù)雜最穩(wěn)妥的方案是建立獨(dú)立的TCP控制連接?？刂七B接和主數(shù)據(jù)連接分開控制指令獨(dú)占一條連接天然不會(huì)被數(shù)據(jù)流量阻塞。這個(gè)方案的代價(jià)是額外的連接開銷和端口管理復(fù)雜度但從可靠性和可維護(hù)性角度遠(yuǎn)勝于緊急數(shù)據(jù)。HTTP/2的多路復(fù)用本質(zhì)上也是這個(gè)思路的進(jìn)化版在一條TCP連接上邏輯分流出多個(gè)流控制流的優(yōu)先級(jí)更高數(shù)據(jù)流之間互不干擾。7.2 應(yīng)用層消息幀另一個(gè)方案是在普通數(shù)據(jù)流中內(nèi)嵌控制消息幀。發(fā)送方在數(shù)據(jù)流里用一種特殊的起始標(biāo)記來標(biāo)識(shí)控制消息接收方解析時(shí)遇到標(biāo)記立即處理。這個(gè)方案實(shí)現(xiàn)簡(jiǎn)單兼容性好但在大數(shù)據(jù)量場(chǎng)景下控制消息仍然會(huì)被普通數(shù)據(jù)阻塞在接收緩沖區(qū)后面。7.3 選型對(duì)比表特性TCP緊急數(shù)據(jù)獨(dú)立控制連接應(yīng)用層消息幀實(shí)現(xiàn)復(fù)雜度低中低跨平臺(tái)一致性差好好實(shí)時(shí)性中高中網(wǎng)絡(luò)兼容性差好好帶寬開銷低中低維護(hù)成本中高低適合場(chǎng)景輕量設(shè)備交互強(qiáng)實(shí)時(shí)控制一般協(xié)議設(shè)計(jì)從這張表可以看出來TCP緊急數(shù)據(jù)最突出的優(yōu)勢(shì)是低成本最明顯的短板是跨平臺(tái)一致性和網(wǎng)絡(luò)兼容性。選不選它取決于你的應(yīng)用場(chǎng)景里哪個(gè)維度更重要。在我個(gè)人看來TCP緊急數(shù)據(jù)是一個(gè)值得了解透、但需要謹(jǐn)慎選用的機(jī)制。學(xué)習(xí)它的價(jià)值不僅在于會(huì)用更在于理解TCP協(xié)議的邊界和設(shè)計(jì)取舍。知道它為什么存在、為什么被冷落、在什么場(chǎng)景下還能發(fā)揮獨(dú)特價(jià)值這些認(rèn)知比單純記住那幾行API調(diào)用更有意義。我在實(shí)際排查緊急數(shù)據(jù)問題時(shí)最大的體會(huì)是很多看似古怪的線上故障追根溯源都在于對(duì)TCP頭部標(biāo)志和指針語義的理解不到位。像緊急指針偏移一個(gè)字節(jié)這種細(xì)節(jié)平時(shí)用不到的時(shí)候毫無存在感一旦用到就可能是壓垮排查效率的關(guān)鍵一錘。把基礎(chǔ)概念摳扎實(shí)比刷更多的高級(jí)框架都管用。