TCP擁塞控制詳解 | 7. 超越TCP

網(wǎng)絡(luò)傳輸問題本質(zhì)上是對網(wǎng)絡(luò)資源的共享和復(fù)用問題，因此擁塞控制是網(wǎng)絡(luò)工程領(lǐng)域的核心問題之一眷茁，并且隨著互聯(lián)網(wǎng)和數(shù)據(jù)中心流量的爆炸式增長炕泳，相關(guān)算法和機(jī)制出現(xiàn)了很多創(chuàng)新，本系列是免費電子書《TCP Congestion Control: A Systems Approach》的中文版上祈，完整介紹了擁塞控制的概念培遵、原理、算法和實現(xiàn)方式登刺。原文: TCP Congestion Control: A Systems Approach

第7章 超越TCP

隨著對擁塞控制的探索不斷深入荤懂，出現(xiàn)了許多新的算法和協(xié)議，與我們前幾章中所介紹方法的主要不同之處在于塘砸，它們大多數(shù)都針對特定用例優(yōu)化节仿，而不是TCP所支持的任意復(fù)雜度的異構(gòu)網(wǎng)絡(luò)環(huán)境。QUIC可能是個例外掉蔬，其最初目標(biāo)是提升HTTP的性能廊宪，但現(xiàn)在已經(jīng)發(fā)展成為一種通用的TCP替代方案。

本章將介紹其中某些具體用例女轿，但并沒有詳盡包含所有可能選項箭启。這些用例包括數(shù)據(jù)中心TCP性能調(diào)優(yōu)；在較長時間段內(nèi)僅用剩余容量傳輸背景流量蛉迹；非TCP兼容的基于HTTP的web流量優(yōu)化傅寡；以TCP友好的方式支持實時流；支持多路徑傳輸協(xié)議北救；以及具有獨特?zé)o線電誘導(dǎo)行為的移動蜂窩網(wǎng)絡(luò)荐操。

7.1 數(shù)據(jù)中心(DCTCP, On-Ramp)

有一些針對云數(shù)據(jù)中心的TCP優(yōu)化工作，其中之一是數(shù)據(jù)中心TCP(Data Center TCP) 珍策，數(shù)據(jù)中心環(huán)境的幾個特點使我們可以采用不同于傳統(tǒng)TCP的方法托启，這些特點包括:

  • 數(shù)據(jù)中心內(nèi)流量的往返時間較小攘宙；
  • 數(shù)據(jù)中心交換機(jī)中的緩沖區(qū)通常也很型退省拐迁；
  • 所有的交換機(jī)都在統(tǒng)一的管理控制之下，因此可以要求滿足一定的標(biāo)準(zhǔn)疗绣；
  • 大量流量具有較低的時延要求线召；
  • 這些流量與高帶寬流競爭；

應(yīng)該注意的是多矮，DCTCP不僅僅是TCP的一個版本灶搜，而是一種改變交換機(jī)行為和終端主機(jī)對從交換機(jī)接收到的擁塞信息的響應(yīng)的系統(tǒng)設(shè)計。

DCTCP的核心觀點是工窍，在數(shù)據(jù)中心環(huán)境中使用丟包作為擁塞的主要信號是不夠的。當(dāng)隊列已經(jīng)積累到足以溢出時前酿，低延遲流量已經(jīng)無法滿足其最低需求患雏，因此會對性能產(chǎn)生負(fù)面影響。DCTCP使用ECN的一個版本來提供擁塞的早期信號罢维。但是淹仑，ECN的原始設(shè)計將ECN標(biāo)記處理得很像一個丟包，并將擁塞窗口縮短一半肺孵，而DCTCP采用了一種更精細(xì)的方法匀借。DCTCP試圖估算遇到擁塞的字節(jié)比例，而不是簡單判斷擁塞是否發(fā)生平窘。然后吓肋，根據(jù)這個估算縮放擁塞窗口。同時標(biāo)準(zhǔn)TCP算法仍然在數(shù)據(jù)包實際丟失的情況下發(fā)揮作用瑰艘。該方法的設(shè)計目的是通過提前對擁塞做出反應(yīng)來保持隊列較短是鬼，同時不對空隊列做出過度反應(yīng)，避免犧牲吞吐量紫新。

該方法的關(guān)鍵挑戰(zhàn)是估算遇到擁塞的字節(jié)比例均蜜。對于每個交換機(jī)來說計算都很簡單，如果一個包到達(dá)芒率，并且交換機(jī)看到隊列長度(K)超過某個閾值囤耳，例如,

\mathsf{K} > \mathsf{(RTT} \times \mathsf{C)\ /\ 7}

其中C是每秒數(shù)據(jù)包的鏈路速率，然后交換機(jī)設(shè)置IP報頭中的CE位偶芍。該算法避免了RED的復(fù)雜性充择。

然后，接收器為每個流維護(hù)一個布爾變量匪蟀，我們將其表示為DCTCP.CE聪铺，并將其初始值設(shè)置為false。當(dāng)發(fā)送ACK報文時萄窜，如果DCTCP.CE為true铃剔，接收端會在TCP報頭中設(shè)置ECE (Echo Congestion Experienced)標(biāo)志撒桨，并且實現(xiàn)了以下狀態(tài)機(jī)來響應(yīng)每一個收到的數(shù)據(jù)包:

  • 如果設(shè)置了CE位，并且DCTCP.CE=False, 設(shè)置DCTCP.CE為True键兜，并立即發(fā)送ACK凤类。
  • 如果沒有設(shè)置CE位，并且DCTCP.CE=True, 設(shè)置DCTCP.CE為False普气，并立即發(fā)送ACK谜疤。
  • 其他清空清空忽略CE位。

"其他"情況的非明顯后果是现诀，只要收到CE值固定的數(shù)據(jù)包流夷磕，接收端就會每n個數(shù)據(jù)包發(fā)送一次延遲ACK，延遲ACK已被證明對保持高性能非常重要仔沿。

在每個觀察窗口(通常選擇近似于RTT的周期)結(jié)束時奋刽，發(fā)送端計算在該窗口期間遇到擁塞的字節(jié)的比例省容，即標(biāo)記為CE的字節(jié)與總傳輸字節(jié)的比率琳状。DCTCP以與標(biāo)準(zhǔn)算法完全相同的方式增加擁塞窗口锐极，但減小窗口的方式與上次觀察窗口期間遇到擁塞的字節(jié)數(shù)成正比。

具體來說成福，引入一個名為DCTCP.Alpha的新變量并初始化為1碾局，在觀察窗口的最后更新如下:

\mathsf{DCTCP.Alpha} = \mathsf{DCTCP.Alpha} \times \mathsf{(1 - g) + g} \times \mathsf{M}

M是標(biāo)記的字節(jié)組，g是估算增益奴艾，為常數(shù)(由實現(xiàn)設(shè)置)净当，決定了DCTCP.Alpha隨數(shù)據(jù)包的標(biāo)記而變化的速度。當(dāng)出現(xiàn)持續(xù)擁塞時蕴潦，DCTCP.Alpha接近1蚯瞧，如果持續(xù)通暢(沒有阻塞)，DCTCP.Alpha衰減到0品擎。這樣對新?lián)矶路磻?yīng)較小埋合，對持續(xù)擁堵反應(yīng)較大，擁堵窗口的計算如下:

\mathsf{CongestionWindow} = \mathsf{CongestionWindow} \times \mathsf{(1 - DCTCP.Alpha\ /\ 2)}

綜上所述萄传，CE標(biāo)記表明早期且頻繁發(fā)生的擁塞甚颂，但對這種標(biāo)記的反應(yīng)比標(biāo)準(zhǔn)TCP更慎重，以避免過度反應(yīng)導(dǎo)致隊列空秀菱。

闡述了DCTCP的論文振诬，包括推動其設(shè)計的數(shù)據(jù)中心流量特性的研究，獲得了SIGCOMM的"test of time"獎衍菱。

延伸閱讀:
M. Alizadeh, et al. Data Center TCP (DCTCP). ACM SIGCOMM, August 2010.

自DCTCP以來赶么，已經(jīng)有相當(dāng)多關(guān)于數(shù)據(jù)中心TCP優(yōu)化的研究，一般方法是從網(wǎng)絡(luò)中引入更復(fù)雜的信號脊串，發(fā)送方可以使用這些信號來管理擁塞辫呻。我們通過詳細(xì)介紹最近的一項成果On-Ramp來結(jié)束對這一用例的討論清钥，它側(cè)重于所有擁塞控制算法面臨的根本問題: 平衡長期流量與瞬態(tài)突發(fā)流量。On-Ramp采用模塊化設(shè)計放闺，直接解決了這一沖突祟昭，而且不需要依賴來自網(wǎng)絡(luò)的額外反饋。

其主要的觀點是怖侦，當(dāng)處于平衡狀態(tài)的擁塞控制算法遇到嚴(yán)重?fù)砣⒋蠓鶞p少窗口(或速率)時篡悟，必須決定是否記住之前的均衡狀態(tài)。這是一個困難的選擇匾寝，因為這取決于擁堵的持續(xù)時間搬葬，而擁堵的持續(xù)時間很難預(yù)測。如果擁塞是暫時的艳悔，算法應(yīng)該記住之前的狀態(tài)急凰，這樣一旦突發(fā)流量結(jié)束，就可以迅速恢復(fù)到原來的均衡狀態(tài)很钓，避免浪費網(wǎng)絡(luò)資源。如果由于一個或多個新流的到來造成了持續(xù)的擁塞董栽，算法應(yīng)該忽略之前的狀態(tài)码倦，以便迅速找到新的均衡。

圖41. On-Ramp對數(shù)據(jù)包傳輸進(jìn)行配速锭碳，以避免由于突發(fā)流量導(dǎo)致的網(wǎng)絡(luò)排隊袁稽，補充了傳統(tǒng)擁塞控制算法保持長期穩(wěn)定性和公平性的努力。

其思想是將擁塞控制機(jī)制分成兩部分擒抛，每一部分只關(guān)注長期/瞬時流量平衡的一個方面推汽。具體來說，On-Ramp被實現(xiàn)為位于傳統(tǒng)TCP擁塞控制算法之下的"墊片(shim)"歧沪，如圖41所示歹撒。On-Ramp處理突發(fā)流量(臨時填充網(wǎng)絡(luò)隊列)，當(dāng)測量到單向延遲(OWD, One-Way Delay) 增長過大(在OWD大于某個閾值)時在發(fā)送端臨時緩存數(shù)據(jù)包(而不是占用網(wǎng)絡(luò)內(nèi)緩沖區(qū))來試圖快速減少排隊時延诊胞。然后On-Ramp與現(xiàn)有擁塞控制算法合作暖夭，努力達(dá)成長期流量的平衡。On-Ramp已經(jīng)被證明可以與包括DCTCP在內(nèi)的幾種擁塞控制算法一起工作撵孤。

On-Ramp的關(guān)鍵設(shè)計是使兩個控制決策在各自的時間尺度上獨立運行迈着。但為了正常工作，On-Ramp需要精確測量OWD邪码，而OWD又依賴發(fā)送方和接收方之間的同步時鐘裕菠。由于數(shù)據(jù)中心延遲可以小于幾十微秒，發(fā)送方和接收方的時鐘必須同步到幾微秒內(nèi)闭专。這種高精度的時鐘同步傳統(tǒng)上需要硬件密集型協(xié)議奴潘，但On-Ramp利用了一種新的方法旧烧，利用協(xié)作節(jié)點網(wǎng)格中的網(wǎng)絡(luò)效應(yīng)來實現(xiàn)納秒級的時鐘同步，而不需要特殊硬件萤彩，這使得On-Ramp很容易部署粪滤。

延伸閱讀:
S. Liu, et al. Breaking the Transience-Equilibrium Nexus: A New Approach to Datacenter Packet Transport. Usenix NSDI ‘21. April 2021.
Y. Geng, et al. Exploiting a Natural Network Effect for Scalable, Fine-grained Clock Synchronization. Usenix NSDI ‘18, April 2018.

7.2 背景傳輸(LEDBAT)

與低延遲數(shù)據(jù)中心環(huán)境形成鮮明對比的是，許多應(yīng)用程序需要在很長一段時間內(nèi)傳輸大量數(shù)據(jù)雀扶，BitTorrent和軟件更新等文件共享協(xié)議就是類似例子杖小。LEDBAT(Low Extra Delay Background Transport)就是為了解決這一用例的問題的。

改進(jìn)TCP擁塞控制算法的各種努力的共同主題之一是與標(biāo)準(zhǔn)TCP共存愚墓。眾所周知予权，算法可以通過更積極的響應(yīng)擁塞而"超越"TCP。因此浪册，隱含的假設(shè)是新的擁塞控制算法應(yīng)該與標(biāo)準(zhǔn)TCP一起評估扫腺，以確保不只是從不那么激進(jìn)的TCP實現(xiàn)中竊取帶寬。

LEDBAT采用了相反的思路村象，它創(chuàng)建了一個故意不像TCP那么咄咄逼人的擁塞控制協(xié)議笆环。其思想是利用鏈路不擁塞時可用的帶寬，但在其他標(biāo)準(zhǔn)流到達(dá)時厚者，迅速收回流量并將帶寬留給其他流躁劣。此外，顧名思義库菲，與TCP填充瓶頸鏈路時的典型行為不同账忘，LEDBAT盡量不觸發(fā)明顯的排隊延遲。

與TCP Vegas一樣熙宇，LEDBAT的目標(biāo)是在擁塞嚴(yán)重到足以造成丟包之前檢測到它的發(fā)生鳖擒。然而，LEDBAT采用了一種不同的方法來進(jìn)行烫止，即通過單向延遲測量作為主要輸入?yún)?shù)蒋荚。這是一個相對新穎的方法，在一個具有合理精度但不完全同步的時鐘被認(rèn)為是常態(tài)的時代是有意義的馆蠕。

為了計算單向延遲圆裕，發(fā)送方在每個傳輸包中放入時間戳，接收方將其與本地系統(tǒng)時間進(jìn)行比較荆几，以測量包所經(jīng)歷的延遲吓妆，然后將這個計算值發(fā)送回發(fā)送方。即使時鐘不是精確同步的吨铸，這種延遲的變化也可以用來推斷隊列的堆積行拢。假設(shè)時鐘沒有較大的相對"偏差"，即它們的相對偏移量不會變化太快诞吱，這在實踐中是一個合理的假設(shè)舟奠。

發(fā)送端監(jiān)測測量到的延遲竭缝，并估算固定組件(可能是由于光速和其他固定延遲)是在某一(可配置的)時間間隔內(nèi)看到的最低值。排除時間最久的估算沼瘫，從而允許改變路由路徑并改變固定延遲抬纸。任何超過這個最小值的延遲都被認(rèn)為是由于排隊引起的延遲。

建立"基礎(chǔ)"延遲后耿戚，發(fā)送方從測量延遲中減去該延遲以獲得排隊延遲湿故，并可以選擇性的使用濾波算法來減少估算中的短期噪聲。然后將這個估計的排隊延遲與目標(biāo)延遲進(jìn)行比較膜蛔，當(dāng)延遲低于目標(biāo)時坛猪，允許增大擁塞窗口，當(dāng)延遲高于目標(biāo)時皂股，減小擁塞窗口墅茉，其增大和減小的速度與距離目標(biāo)的距離成正比，增大速度被限制為不超過標(biāo)準(zhǔn)TCP窗口在增長階段的增長速度呜呐。

LEDBAT在收到ACK時設(shè)置CongestionWindow的算法總結(jié)如下:

\mathsf{CongestionWindow}\ = \mathsf{CongestionWindow + (GAIN \times off\_target \times bytes\_newly\_acked \times MSS / CongestionWindow)}

其中就斤，GAIN取值為0到1的配置參數(shù)，off_target是測量的排隊延遲和目標(biāo)之間的差距蘑辑，表示為目標(biāo)的一個分?jǐn)?shù)洋机，bytes_newly_acked是當(dāng)前ACK中確認(rèn)的數(shù)據(jù)包字節(jié)數(shù)。因此以躯，測量延遲相對目標(biāo)越低槐秧，擁塞窗口增長越快啄踊，但絕不會超過每個RTT一個MSS忧设。減小速度與隊列長度超過目標(biāo)的距離成正比。CongestionWindow在響應(yīng)丟包颠通、超時和長空閑期時也會有所減少址晕，這與TCP非常相似。

因此顿锰，LEDBAT可以很好的利用空閑的可用帶寬谨垃，同時避免創(chuàng)建長隊列，其目標(biāo)是將時延保持在目標(biāo)附近(這是一個可配置的數(shù)字硼控，建議在100毫秒量級)刘陶。如果其他流量開始與LEDBAT流競爭，LEDBAT將會后退牢撼，從而防止隊列變長匙隔。

LEDBAT被IETF定義為實驗協(xié)議，允許相當(dāng)大程度的實現(xiàn)靈活性熏版，例如根據(jù)延遲估算和一系列配置參數(shù)纷责，可以在RFC中找到更多細(xì)節(jié)捍掺。

延伸閱讀:
S. Shalunov, et al. Low Extra Delay Background Transport (LEDBAT). RFC 6817, December 2012.

7.3 HTTP性能(QUIC)

HTTP自20世紀(jì)90年代萬維網(wǎng)發(fā)明以來就一直存在，一開始就運行在TCP上再膳。最初版本HTTP/1.0由于使用TCP的方式存在大量性能問題挺勿，例如，每個對象的請求都需要建立新的TCP連接喂柒，然后在返回應(yīng)答后關(guān)閉不瓶。早期提出的HTTP/1.1的目的是更好的利用TCP。TCP繼續(xù)被HTTP使用了20多年胳喷。

事實上湃番，TCP作為一種支持Web的協(xié)議仍然存在問題，特別是因為可靠吭露、有序的字節(jié)流并不完全是Web流量的正確模型吠撮。特別是，由于大多數(shù)網(wǎng)頁包含許多對象讲竿，因此能夠并行請求許多對象是有意義的泥兰，但TCP只提供單一字節(jié)流。如果一個包丟失题禀，TCP會等待重傳這個數(shù)據(jù)包鞋诗，然后再繼續(xù)，然而HTTP可以很高興的接收其他不受單個丟包影響的對象迈嘹。多TCP連接似乎是一個解決方案削彬，但也有其自身缺陷，包括缺乏連接之間擁塞的共享信息秀仲。

高延遲無線網(wǎng)絡(luò)的興起等其他因素使得單一設(shè)備有可能使用多個網(wǎng)絡(luò)(例如融痛，Wi-Fi和蜂窩網(wǎng)絡(luò))。同時神僵，加密雁刷、身份驗證等越來越多被使用，也促使人們認(rèn)識到HTTP的傳輸層將從新方法中受益保礼。為滿足這一需求而出現(xiàn)的協(xié)議是QUIC沛励。

QUIC由谷歌在2012年提出，隨后被提議為IETF標(biāo)準(zhǔn)炮障。它已經(jīng)得到了大量的部署目派，出現(xiàn)在大多數(shù)Web瀏覽器和流行網(wǎng)站中，甚至開始用于非HTTP應(yīng)用程序胁赢∑蟛洌可部署性是協(xié)議設(shè)計者考慮的關(guān)鍵因素。在QUIC中有很多可選部分，其規(guī)范跨越了三個RFC练对，長達(dá)幾百頁遍蟋，但在這里主要關(guān)注其擁塞控制方法，其中包含了我們在本書中看到的許多觀點螟凭。

和TCP一樣虚青，QUIC在傳輸中建立擁塞控制，但它認(rèn)識到?jīng)]有完美的擁塞控制算法螺男。相反棒厘，它假設(shè)不同的發(fā)送者可能使用不同的算法。QUIC規(guī)范中的基準(zhǔn)算法類似于TCP NewReno下隧，但發(fā)送方可以單方面選擇不同的算法奢人，如CUBIC。QUIC提供了所有的機(jī)制來檢測丟包淆院，以支持各種擁塞控制算法何乎。

與TCP相比，QUIC的許多設(shè)計特性使丟包和擁塞檢測更加健壯土辩。例如支救，無論是第一次發(fā)送還是重傳，TCP對一個數(shù)據(jù)包使用相同的序列號拷淘，而QUIC序列號(稱為包號)是嚴(yán)格遞增的各墨。序列號越大表示報文發(fā)送的時間越晚，越低表示報文發(fā)送的時間越早启涯，這意味著始終有可能區(qū)分第一次傳輸?shù)臄?shù)據(jù)包和由于丟包或超時重傳的數(shù)據(jù)包贬堵。

還要注意，TCP序列號指的是傳輸字節(jié)流中的字節(jié)结洼，而QUIC序列號指的是整個包黎做。由于QUIC序列號空間足夠大(高達(dá)2^62 - 1)，可以避免循環(huán)問題补君。

QUIC協(xié)議支持選擇性確認(rèn)引几，在TCP SACK選項中可以支持確認(rèn)三個以上數(shù)據(jù)包范圍昧互，從而提高了高丟包環(huán)境性能挽铁，只要成功接收了部分包，就可以向前推進(jìn)敞掘。

與TCP快速恢復(fù)所依賴的重復(fù)ACK相比叽掘，QUIC采用了一種更可靠的方法來判斷丟包。該方法是獨立于QUIC開發(fā)的玖雁，名為RACK-TLP: 最近確認(rèn)和尾丟包探針(Recent Acknowledgments and Tail Loss Probes)更扁。其關(guān)鍵觀點為，當(dāng)發(fā)送方在丟包之后沒有發(fā)送足夠的數(shù)據(jù)來觸發(fā)重復(fù)ACK時，或者當(dāng)重傳的數(shù)據(jù)包本身丟失時浓镜，重復(fù)ACK無法觸發(fā)丟包恢復(fù)溃列。相反，如果實際上沒有丟包膛薛，包的重排序也可能觸發(fā)快速恢復(fù)听隐。QUIC采用了RACK-TLP的思想，通過兩個機(jī)制來解決這個問題:

  • 收到包的時候哄啄，如果一個序列號更高的包已經(jīng)被確認(rèn)雅任，并且這個包在"過去足夠長的時間"被發(fā)送，或者在確認(rèn)包之前有K個包(K是一個參數(shù))咨跌，那么這個包被認(rèn)為是丟失的沪么。
  • 在等待ACK到達(dá)的"探測超時時間間隔"之后發(fā)送探測包，以觸發(fā)ACK锌半，從而提供關(guān)于丟失包的信息禽车。

第一個機(jī)制是確保少量包被重新排序不會被解釋為丟包事件。K建議初始設(shè)置為3刊殉，但如果有更嚴(yán)重的無序情況哭当，可以更新K。"過去足夠長的時間"的定義比測量的RTT稍微長一點冗澈。

第二個機(jī)制是確保即使數(shù)據(jù)包沒有生成重復(fù)ACK钦勘，也會發(fā)送探測數(shù)據(jù)包來引出進(jìn)一步的ACK，從而暴露接收到的數(shù)據(jù)包流中的缺口亚亲。通過使用估算RTT及其方差彻采，將"探測超時間隔"計算為足以解釋ACK可能遇到的所有延遲。

QUIC是傳輸協(xié)議領(lǐng)域最有趣的發(fā)展捌归。TCP的許多限制幾十年來一直為人所知肛响，但QUIC代表了迄今為止最成功的努力之一，它在設(shè)計空間中指明了一個不同的點惜索，基于幾十年來的寶貴經(jīng)驗特笋，將TCP擁塞控制提煉為基準(zhǔn)規(guī)范。因為QUIC的靈感來自于HTTP和Web的經(jīng)驗(在TCP出現(xiàn)很久之后才出現(xiàn))巾兆，提供了關(guān)于分層設(shè)計和互聯(lián)網(wǎng)演變中不可預(yù)見后果的有趣案例研究猎物。還有更多內(nèi)容可以介紹，關(guān)于QUIC的權(quán)威參考是RFC 9000角塑，但是擁塞控制在單獨的RFC 9002中涉及蔫磨。

延伸閱讀:
J. Iyengar and I. Swett, Eds. QUIC Loss Detection and Congestion Control. RFC 9002, May 2021.

7.4 TCP友好協(xié)議(TCP-Friendly Protocols, TFRC)

正如本書提到的，因為TCP在檢測到擁塞時以各種形式退出圃伶，因此很容易構(gòu)建出性能優(yōu)于TCP的傳輸協(xié)議堤如。任何不通過降低發(fā)送速率來響應(yīng)擁塞的協(xié)議蒲列，最終都會比它競爭的任何TCP或TCP類流量獲得更大的瓶頸鏈路份額。在有限資源下搀罢，這可能會導(dǎo)致?lián)砣罎⒒柔赥CP擁塞控制剛被開發(fā)出來時，擁塞崩潰開始變得很普遍榔至。因此剪侮，業(yè)界有強烈的興趣確保互聯(lián)網(wǎng)上的絕大多數(shù)流量在某種意義上是"TCP友好的"洛退。

當(dāng)我們使用"TCP友好"這個術(shù)語時瓣俯，是在說我們期望得到與TCP類似的擁塞響應(yīng)。LEDBAT可以被認(rèn)為"比TCP友好"兵怯，因為在第一個延遲提示時就減少窗口大小彩匕，它比TCP更積極的在擁塞時退后。但是有一類應(yīng)用對于TCP友好需要更多的思考媒区，因為它們不使用基于窗口的擁塞方案驼仪，這就是包括流媒體在內(nèi)的典型"實時"應(yīng)用。

如視頻流和電話等多媒體應(yīng)用可以通過改變編碼參數(shù)來調(diào)整發(fā)送速率袜漩，在帶寬和質(zhì)量之間進(jìn)行權(quán)衡绪爸。但是，不可能突然大幅降低發(fā)送速率而不影響質(zhì)量宙攻，而且它們通常需要在有限的質(zhì)量級別中進(jìn)行選擇奠货。如3.1節(jié)所討論的，這些考慮導(dǎo)致其采用基于速率的方法座掘，而不是基于窗口的方法递惋。

對于這些應(yīng)用來說，TCP友好的方法是嘗試選擇一個與TCP在類似條件下實現(xiàn)的發(fā)送速率相似的發(fā)送速率溢陪，但要以一種防止速率波動太大的方式進(jìn)行萍虽。支持這一想法的是多年來對TCP吞吐量建模的研究。在定義TFRC標(biāo)準(zhǔn)的RFC 5348中給出了TCP吞吐量方程的簡化版本形真，其中一些變量設(shè)置為推薦值杉编，目標(biāo)傳輸速率X(比特/秒)的方程為:

\mathsf{X} = \frac{s}{R\times\sqrt{2p/3} + 12\sqrt{3p/8}\times p \times (1 + 32 p^2)}

其中:

  • s是分片大小(不包括IP和傳輸層頭域)；
  • R為RTT咆霜，單位為秒邓馒；
  • P是"丟包事件"的數(shù)量，體現(xiàn)為占傳輸數(shù)據(jù)包的比例裕便。

雖然這個公式的推導(dǎo)本身就很有趣(參見下面的第二個參考)绒净，但這里的關(guān)鍵思想是见咒，如果我們知道RTT和路徑的丟包率偿衰，就能很好的知道TCP連接能夠提供多少帶寬。因此，TFRC試圖引導(dǎo)無法實現(xiàn)基于窗口的擁塞控制算法的應(yīng)用程序在相同的條件下達(dá)到與TCP相同的吞吐量下翎。

唯一需要解決的問題是p和R的度量缤言，然后決定應(yīng)用程序應(yīng)該如何響應(yīng)X的變化。與其他協(xié)議一樣视事，TFRC使用時間戳來比TCP最初更準(zhǔn)確的度量RTT胆萧。包序列號用于確定接收端丟包，連續(xù)丟包被分組為單個丟包事件俐东。從這些信息中可以計算出損包事件概率p跌穗，然后由接收端反饋給發(fā)送端。

對速率變化的確切響應(yīng)方式當(dāng)然取決于應(yīng)用程序本身虏辫，其基本思想是蚌吸，應(yīng)用程序可以在一組編碼速率中選擇能夠適應(yīng)TFRC規(guī)定的速率的最高質(zhì)量。

雖然TFRC的概念可靠砌庄，但由于若干原因羹唠，其部署很有限。一個原因是以DASH(Dynamic Adaptive Streaming over HTTP) 出現(xiàn)了針對某些類型的流通信的更簡單的解決方案娄昆。DASH只適用于非實時媒體(例如看電影)佩微，但事實證明，這在整個互聯(lián)網(wǎng)上的媒體流量中占很大比例萌焰，事實上在所有互聯(lián)網(wǎng)流量中占比也很大哺眯。

DASH讓TCP(或者QUIC)負(fù)責(zé)擁塞控制，應(yīng)用程序測量TCP正在交付的吞吐量扒俯，然后相應(yīng)調(diào)整視頻流的質(zhì)量族购，以避免接收端饑餓。這種方法已經(jīng)被證明適合于視頻娛樂陵珍，但是由于依賴于接收端有適度的大量緩沖來平滑TCP吞吐量的波動寝杖，并不真正適合于交互式音視頻領(lǐng)域。DASH的關(guān)鍵實現(xiàn)之一是可以對不同帶寬要求的視頻進(jìn)行多質(zhì)量級編碼互纯，并提前存儲在流媒體服務(wù)器上瑟幕。然后，一旦觀察到的網(wǎng)絡(luò)吞吐量下降留潦，服務(wù)器就會下降到較低質(zhì)量的流只盹，然后在條件允許的情況下再上升到較高質(zhì)量的流⊥迷海客戶端可以向服務(wù)器發(fā)送信息殖卑，比如它還有多少緩沖視頻等待播放，以幫助服務(wù)器選擇合適的質(zhì)量和帶寬流坊萝。這種方法的成本是服務(wù)器上額外的媒體存儲孵稽，但在現(xiàn)代流媒體視頻時代许起，這種成本已經(jīng)變得相當(dāng)廉價。請注意菩鲜，這里的"服務(wù)器"可能是CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))中的一個節(jié)點园细。因此，視頻流可以利用客戶端和服務(wù)它的CDN節(jié)點之間可用帶寬的任何改進(jìn)接校，從而傳輸更高質(zhì)量級別的媒體猛频。

TFRC的另一個限制是，它使用丟包作為主要擁塞信號蛛勉，但不響應(yīng)丟包之前的延遲鹿寻。雖然在TFRC的研究中這是最先進(jìn)的技術(shù)，但TCP擁塞控制領(lǐng)域現(xiàn)在已經(jīng)把延遲考慮在內(nèi)了诽凌，比如TCP Vegas和BBR(參見第5章)烈和。當(dāng)我們考慮到真正需要一些別的支持(不是DASH)的多媒體應(yīng)用程序正是那些對延遲敏感的應(yīng)用程序時，這就特別有問題了皿淋。由于這個原因招刹，在撰寫本文時，仍在繼續(xù)為實時流量定義TCP友好的擁塞控制標(biāo)準(zhǔn)窝趣。IETF RMCAT (RTP Media Congestion Avoidance Techniques)工作組是這項工作的中心疯暑。因此，下面的TFRC規(guī)范并不是最后的工作哑舒，但為如何實現(xiàn)TCP友好協(xié)議提供了有用的參考妇拯。

延伸閱讀:
S. Floyd, M. Handley, J. Padhye, and J. Widmer. TCP Friendly Rate Control (TFRC): Protocol Specification. RFC 5348, September 2008.
J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM, September 1998

7.5 多路徑傳輸

雖然連接到互聯(lián)網(wǎng)的早期主機(jī)只有一個網(wǎng)絡(luò)接口，但現(xiàn)在在一個設(shè)備上有至少兩個不同網(wǎng)絡(luò)的接口很常見洗鸵，最常見的例子是具有蜂窩和WiFi接口的移動電話越锈。另一個例子是數(shù)據(jù)中心，服務(wù)器經(jīng)常會分配多個網(wǎng)絡(luò)接口膘滨，以提高容錯能力甘凭。許多應(yīng)用程序一次只使用一個可用的網(wǎng)絡(luò)，但同時使用多個接口可以提高性能火邓。這種多路徑通信的思想已經(jīng)存在了幾十年丹弱，并導(dǎo)致了IETF對TCP擴(kuò)展的標(biāo)準(zhǔn)化，以支持利用成對主機(jī)之間的多路徑的端到端連接铲咨，這被稱為MPTCP(Multipath TCP) 躲胳。

一對主機(jī)同時通過兩條或多條路徑發(fā)送流量對擁塞控制來說有重要意義。例如纤勒，如果兩條路徑共享一個瓶頸鏈接坯苹，那么每個路徑一個TCP連接的簡單實現(xiàn)將獲得兩倍于標(biāo)準(zhǔn)TCP連接的瓶頸帶寬份額，MPTCP的設(shè)計者在保持多路徑好處的同時正著手解決這種潛在的不公平摇天。MPTCP提出的擁塞控制方法同樣適用于其他傳輸協(xié)議粹湃，如QUIC恐仑。多路徑傳輸擁塞控制的高級目標(biāo)是:

  1. 在最佳可用路徑上執(zhí)行效果至少與單一路徑流一樣好。
  2. 不要從任何路徑中獲取比單一路徑流更多的資源再芋。
  3. 從最擁堵的路徑上移除更多流量菊霜，與前兩個目標(biāo)一致坚冀。

值得注意的是济赎，對其他TCP流公平的想法有一些微妙之處，我們在第3.2節(jié)中討論過记某。

雖然多路徑算法的細(xì)節(jié)涉及到復(fù)雜的計算司训，但所采取的總體方法比較簡單。擁塞控制算法在每個子流的基礎(chǔ)上大致模擬TCP液南，同時試圖確保上述三個目標(biāo)都得到滿足壳猜。該算法的核心是使用以下公式在子流上接收到ACK時增加每個子流的擁塞窗口大小。

\mathsf{MIN} (\frac{\alpha \times \mathsf{BytesAcked} \times \mathsf{MSS_{i}}}{\mathsf{CongestionWindowTotal}}, \frac{\mathsf{BytesAcked} \times \mathsf{MSS_{i}}}{\mathsf{CongestionWindow_{i}}} )

CongestionWindowTotal是所有子流擁塞窗口的總和滑凉，\mathsf{CongestionWindow_{i}}是子流i的擁塞窗口统扳。MIN的第二個參數(shù)模擬了標(biāo)準(zhǔn)TCP將獲得的增量，從而確保子流不會比TCP更激進(jìn)(目標(biāo)2)儿子。第一個參數(shù)使用變量α來確碧棠唬總體上多路徑流獲得與使用其最佳可用路徑(目標(biāo)1)相同的吞吐量糙臼。RFC 6356介紹了計算α的細(xì)節(jié)。需要注意的是朱嘴，因為沒有丟包，因此非擁塞路徑能夠比擁塞路徑增加更多的擁塞窗口粗合，隨著時間的推移萍嬉，更多流量會移動到非擁塞路徑上(目標(biāo)3)。

雖然回頭看這很簡單隙疚，但正如Wischik和他的同事在NSDI的一篇論文中介紹的那樣壤追，正是基于許多有趣的分析才幫助他們找到了正確的方法。

延伸閱讀:
D. Wischik, C. Raiciu, A. Greenhalgh and M. Handley. Design, Implementation and Evaluation of Congestion Control for Multipath TCP. NSDI, April 2011.
C. Raiciu, M. Handley and D. Wischik. Coupled Congestion Control for Multipath Transport Protocols. RFC 6356, October 2011.

7.6 移動蜂窩網(wǎng)絡(luò)

我們以一個一直受到研究團(tuán)體關(guān)注的用例作為總結(jié): 擁塞控制和移動蜂窩網(wǎng)絡(luò)之間的相互作用供屉。從歷史上看大诸，TCP/IP互聯(lián)網(wǎng)和移動蜂窩網(wǎng)絡(luò)是獨立發(fā)展的，自3G寬帶服務(wù)引入以來贯卦，后者充當(dāng)了端到端TCP連接的"最后一英里"资柔。隨著5G的推出，我們可以預(yù)期移動網(wǎng)絡(luò)將在提供互聯(lián)網(wǎng)連接方面發(fā)揮越來越重要的作用撵割，其如何影響擁塞控制將會受到越來越多的關(guān)注贿堰。

雖然移動無線連接可以被視為與通過互聯(lián)網(wǎng)的端到端路徑上的任何其他跳沒有什么不同，但由于歷史原因啡彬，它被視為一種特殊情況羹与，端到端路徑在邏輯上被劃分為圖42所示的兩個段: 通過互聯(lián)網(wǎng)的有線段和通過無線接入網(wǎng)(RAN)的無線最后一跳故硅。這種"特殊情況"的觀點是有理由的，因為(1)由于無線電頻譜的稀缺纵搁，無線鏈路通常是瓶頸吃衅；(2)由于設(shè)備移動性和無線電干擾的綜合效果，RAN中可用帶寬可能是高度可變的腾誉；并且(3)當(dāng)設(shè)備從一個蜂窩移動到另一個蜂窩時徘层，由給定基站提供服務(wù)的設(shè)備數(shù)量會波動。

圖42. 包括最后一跳無線鏈路的端到端路徑利职，其中基站緩沖數(shù)據(jù)包等待通過無線接入網(wǎng)(RAN)傳輸趣效。

雖然RAN內(nèi)部很大程度上是封閉和專有的，但研究人員通過實驗觀察到猪贪，在邊緣有明顯的緩沖跷敬，這可能是為了吸收預(yù)期的無線電鏈路爭用，同時在容量打開時保持足夠的工作負(fù)載热押。正如Haiqing Jiang和他的同事在2012年CellNet研討會論文中指出的那樣西傀，這種大緩沖區(qū)對于TCP擁塞控制是有問題的，會導(dǎo)致發(fā)送端超出無線電鏈路上的實際可用帶寬桶癣，并且在這個過程中拥褂，會引入顯著的延遲和抖動。這是第6.3節(jié)中確定的緩沖膨脹問題的另一個示例鬼廓。

延伸閱讀:
H. Jiang, Z. Liu, Y. Wang, K. Lee and I. Rhee. Understanding Bufferbloat in Cellular Networks ACM SIGCOMM Workshop on Cellular Networks, August 2012.

Jiang的論文提出了可能的解決方案肿仑，并普遍觀察到，像Vegas這樣基于延遲的方法比Reno或CUBIC這樣基于丟包的方法表現(xiàn)更好碎税，但近十年來尤慰，這個問題在很大程度上一直沒有得到解決。隨著基于開源軟件的RAN實現(xiàn)的承諾正在逐步興起雷蹂，可能很快就可以采取跨層方法伟端，由RAN提供接口，使基站內(nèi)部發(fā)生的事情對更高層次的協(xié)議棧(例如匪煌，在第6章中描述的AQM機(jī)制)可見责蝠。 Xie Yi和Jamieson最近的研究表明，這種方法可能是有效的萎庭，盡管他們的實現(xiàn)使用終端設(shè)備反饋霜医，而不是讓RAN直接參與。無論如何實現(xiàn)驳规，其想法是讓接收方明確告訴發(fā)送方在最后一跳上有多少帶寬可用肴敛，然后發(fā)送方必須判斷實際瓶頸是在最后一跳還是互聯(lián)網(wǎng)路徑上的其他點上。

延伸閱讀:
Y. Xie, F. Yi, and K. Jamieson. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurements. SIGCOMM 2020.
L. Peterson and O. Sunay. 5G Mobile Networks: A Systems Approach. January 2020.
L. Peterson, C. Cascone, B. O’Connor, T. Vachuska, and B. Davie. Software-Defined Networks: A Systems Approach. November 2021.

蜂窩網(wǎng)絡(luò)成為TCP擁塞控制新挑戰(zhàn)的另一個方面是，鏈路帶寬不是恒定的医男，而是隨每個接收端所經(jīng)歷的信噪比的函數(shù)而變化砸狞。正如BBR作者所指出的，這個無線鏈路的調(diào)度器(目前是不透明的)可以使用給定客戶端的隊列數(shù)據(jù)包數(shù)量作為其調(diào)度算法的輸入镀梭，因此構(gòu)建隊列的"好處"可以增加調(diào)度器提供的帶寬刀森。BBR試圖在其設(shè)計中解決這一問題，確保具有足夠的侵略性报账，至少在無線鏈路緩沖區(qū)中緩存一些包研底。

撇開過去的研究不談，一個很有趣的問題是笙什，無線連接未來是否仍將保持其獨特性飘哨。如果從移動網(wǎng)絡(luò)運營商的角度看琐凭，那么目標(biāo)始終是在大范圍變化的條件下最大限度利用稀缺的無線電頻譜统屈，使用深度隊列將工作負(fù)載保持在盡可能高的水平是一種經(jīng)過驗證的方法。當(dāng)寬帶連接是新的服務(wù)愁憔，語音和文本是主要用例時孽拷，這當(dāng)然是有意義的，但今天的5G需要提供良好的TCP性能膜宋，重點應(yīng)該放在端到端goodput和最大化吞吐量/延遲比(即在第3.2節(jié)討論的功率曲線)。但是有改進(jìn)的機(jī)會嗎炼幔？

我們相信這個問題的答案是肯定的秋茫。除了提供對前面提到的RAN調(diào)度器和隊列的更多可見性之外，還有三個其他因素可能會改變這個領(lǐng)域乃秀。首先肛著，5G部署可能會支持網(wǎng)絡(luò)切片，這是一種隔離不同類別流量的機(jī)制跺讯，意味著每個切片都有自己的隊列枢贿，可以按照特定于流量的方式進(jìn)行調(diào)整和調(diào)度。其次刀脏，小型基站的普及可能會減少在給定基站上爭奪帶寬的流量數(shù)量局荚，這將如何影響調(diào)度器最大化頻譜利用率還有待觀察。第三火本，通過附近的邊緣云而不是互聯(lián)網(wǎng)為5G連接設(shè)備提供服務(wù)將變得越來越普遍危队，這意味著端到端TCP連接將有更短的往返時間聪建，將使擁塞控制算法對RAN中可用容量的變化更敏感。當(dāng)然茫陆，沒人能保證未來如何發(fā)展金麸，但所有這些因素都應(yīng)該為未來調(diào)整擁塞控制算法提供充足的機(jī)會。

附錄

關(guān)于擁塞控制的研究論文非常廣泛簿盅，本書只引用了一小部分挥下。這里收集了更全面的參考書目，(目前)根據(jù)書中涉及的主要主題組織桨醋。

我們邀請社區(qū)幫助保持書目的完整和更新棚瘟。如果提供額外的引用或修復(fù)錯誤偎蘸，請?zhí)峤?a target="_blank">Pull Request到GitHub迷雪。如果對如何改進(jìn)書目的組織方式提出建議章咧，請向GitHub發(fā)布Issue赁严。

基礎(chǔ)

隊列分析
理論基礎(chǔ)
評估標(biāo)準(zhǔn)
架構(gòu)

通用算法

主動隊列管理

特定領(lǐng)域算法

數(shù)據(jù)中心
背景傳輸
HTTP
無線
實時
多路徑

實現(xiàn)與工具

關(guān)于本書

TCP Congestion Control: A Systems Approach在GitHub上根據(jù)創(chuàng)作共用協(xié)議(CC BY-NC-ND 4.0)許可條款提供。邀請社區(qū)在相同的條件下提供更正倡缠、改進(jìn)昙沦、更新和新材料盾饮。雖然本授權(quán)并不自動授予制作衍生作品的權(quán)利普办，但我們非常希望與感興趣的各方討論衍生作品(如翻譯)衔蹲。請聯(lián)系discuss@systemsapproach.org舆驶。

如果使用該作品沙廉，其包括以下版權(quán)信息:

Title: TCP Congestion Control: A Systems Approach
Authors: Larry Peterson, Lawrence Brakmo, and Bruce Davie
Source: https://github.com/SystemsApproach/tcpcc
License: CC BY-NC-ND 4.0

閱讀本書

本書是系統(tǒng)方法系列的一部分撬陵，其在線版本發(fā)布在https://tcpcc.systemsapproach.org亮隙。

要跟蹤進(jìn)度并接收新版本通知，可以在Facebook和Twitter上關(guān)注本項目维费。要閱讀關(guān)于互聯(lián)網(wǎng)發(fā)展的實時評論，請訂閱Systems Approach Newsletter阅畴。

編譯本書

要建立可供網(wǎng)頁瀏覽的版本贱枣，首先需要下載源碼:

$ mkdir ~/systemsapproach
$ cd ~/systemsapproach
$ git clone https://github.com/SystemsApproach/tcpcc.git
$ cd tcpcc

構(gòu)建過程實現(xiàn)在Makefile中纽哥，并且需要安裝Python春塌。Makefile將創(chuàng)建一個虛擬環(huán)境(venv-docs)俏拱，用于安裝文檔生成工具集彰触，可能還需要使用系統(tǒng)的包管理器安裝enchant C庫况毅，以便拼寫檢查器正常工作。

請運行make html味廊，在_build/html中生成HTML余佛。

請運行make lint檢查格式辉巡。

執(zhí)行make spelling檢查拼寫郊楣。如果有拼寫正確但字典中沒有的單詞、名稱或首字母縮寫詞输硝，請?zhí)砑拥?code>dict.txt文件中点把。

請運行make查看其他可用的輸出格式砾医。

向本書投稿

如果你使用這些材料如蚜，希望也愿意給出回饋错邦。如果你是開放源碼的新手伦吠，可以查看How to Contribute to Open Source指南毛仪，你將學(xué)到如何發(fā)布Issue，如何發(fā)出Pull Request合并改進(jìn)衡怀，以及其他一些主題抛杨。

如果你想投稿，并且正在尋找一些需要關(guān)注的內(nèi)容真竖，請查看wiki上的當(dāng)前待辦事項列表。

關(guān)于作者

Larry Peterson是普林斯頓大學(xué)計算機(jī)科學(xué)系Robert E. Kahn名譽教授璧亚，并從2003年到2009年擔(dān)任主席癣蟋。Peterson教授的研究主要集中在互聯(lián)網(wǎng)大規(guī)模分布式系統(tǒng)的設(shè)計、實現(xiàn)和操作幔欧，包括廣泛使用的PlanetLab和MeasurementLab平臺礁蔗。他目前正在為開放網(wǎng)絡(luò)基金會(ONF)的Aether接入邊緣云項目做出貢獻(xiàn)晒骇，并擔(dān)任首席科學(xué)家洪囤。Peterson是美國國家工程院院士，ACM和IEEE院士款咖，2010年IEEE Kobayashi計算機(jī)與通信獎得主，2013年ACM SIGCOMM獎得主富腊。Peterson擁有普渡大學(xué)博士學(xué)位赘被。

Lawrence Brakmo目前在Facebook的Kernel小組工作民假。在加入Facebook之前，他是谷歌主機(jī)網(wǎng)絡(luò)組的成員野舶，在此之前，是DoCoMo美國實驗室操作系統(tǒng)組的研究員和項目經(jīng)理宰衙。Brakmo致力于TCP增強以提高網(wǎng)絡(luò)性能平道，包括TCP Vegas和TCP-NV擁塞控制算法的設(shè)計。他還開發(fā)了操作系統(tǒng)技術(shù)供炼，以提高系統(tǒng)的可靠性一屋、性能和能耗窘疮。Brakmo在亞利桑那大學(xué)獲得計算機(jī)科學(xué)博士學(xué)位。

Bruce Davie是計算機(jī)科學(xué)家考余，因其在網(wǎng)絡(luò)領(lǐng)域的貢獻(xiàn)而聞名身冬。他是VMware亞太區(qū)的前副總裁兼首席技術(shù)官嘿歌，在VMware收購SDN初創(chuàng)公司Nicira期間加入VMware步脓。在此之前，他是Cisco Systems研究員况脆，領(lǐng)導(dǎo)一個架構(gòu)師團(tuán)隊弹惦，負(fù)責(zé)多協(xié)議標(biāo)簽交換(MPLS)。Davie擁有超過30年的網(wǎng)絡(luò)行業(yè)經(jīng)驗，并合著了17個RFC。他于2009年成為ACM研究員蚓曼，并于2009年至2013年擔(dān)任ACM SIGCOMM主席捎琐。他還在麻省理工學(xué)院做了五年的訪問講師练慕。Davie是多本書的作者，擁有40多項美國專利。

你好，我是俞凡寻拂，在Motorola做過研發(fā)，現(xiàn)在在Mavenir做技術(shù)工作师幕，對通信、網(wǎng)絡(luò)砂蔽、后端架構(gòu)、云原生、DevOps样眠、CICD、區(qū)塊鏈、AI等技術(shù)始終保持著濃厚的興趣，平時喜歡閱讀、思考植旧，相信持續(xù)學(xué)習(xí)完沪、終身成長听皿，歡迎一起交流學(xué)習(xí)。
微信公眾號：DeepNoMind

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末段只，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子宋渔，更是在濱河造成了極大的恐慌州疾，老刑警劉巖，帶你破解...
    沈念sama閱讀 218,755評論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件皇拣，死亡現(xiàn)場離奇詭異严蓖，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,305評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門颗胡，熙熙樓的掌柜王于貴愁眉苦臉地迎上來毫深，“玉大人，你說我怎么就攤上這事杭措》咽玻” “怎么了？”我有些...
    開封第一講書人閱讀 165,138評論 0贊 355
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵手素，是天一觀的道長。 經(jīng)常有香客問我瘩蚪，道長泉懦，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 58,791評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任疹瘦，我火速辦了婚禮崩哩，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘言沐。我一直安慰自己邓嘹，他們只是感情好，可當(dāng)我...
    茶點故事閱讀 67,794評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布险胰。 她就那樣靜靜地躺著汹押，像睡著了一般。 火紅的嫁衣襯著肌膚如雪起便。 梳的紋絲不亂的頭發(fā)上棚贾，一...
    開封第一講書人閱讀 51,631評論 1贊 305
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音榆综，去河邊找鬼妙痹。 笑死，一個胖子當(dāng)著我的面吹牛鼻疮，可吹牛的內(nèi)容都是我干的怯伊。 我是一名探鬼主播，決...
    沈念sama閱讀 40,362評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼判沟，長吁一口氣：“原來是場噩夢啊……” “哼耿芹！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起水评，我...
    開封第一講書人閱讀 39,264評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤猩系，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后中燥，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體寇甸，經(jīng)...
    沈念sama閱讀 45,724評論 1贊 315
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了拿霉。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片吟秩。...
    茶點故事閱讀 40,040評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖绽淘，靈堂內(nèi)的尸體忽然破棺而出涵防，到底是詐尸還是另有隱情，我是刑警寧澤沪铭，帶...
    沈念sama閱讀 35,742評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布壮池，位于F島的核電站，受9級特大地震影響杀怠，放射性物質(zhì)發(fā)生泄漏椰憋。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 41,364評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一赔退、第九天 我趴在偏房一處隱蔽的房頂上張望橙依。 院中可真熱鬧，春花似錦硕旗、人聲如沸窗骑。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,944評論 0贊 22
  • 一樁弒父案漆枚，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽创译。三九已至，卻和暖如春浪读，著一層夾襖步出監(jiān)牢的瞬間昔榴，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,060評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工碘橘， 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留互订，地道東北人。 一個月前我還...
    沈念sama閱讀 48,247評論 3贊 371
  • 代替公主和親
    正文 我出身青樓痘拆，卻偏偏與公主長得像仰禽，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子纺蛆，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,979評論 2贊 355

推薦閱讀更多精彩內(nèi)容

  • 網(wǎng)絡(luò)傳輸問題本質(zhì)上是對網(wǎng)絡(luò)資源的共享和復(fù)用問題吐葵，因此擁塞控制是網(wǎng)絡(luò)工程領(lǐng)域的核心問題之一，并且隨著互聯(lián)網(wǎng)和數(shù)據(jù)中心...
    DeepNoMind閱讀 682評論 0贊 0
  • 網(wǎng)絡(luò)傳輸問題本質(zhì)上是對網(wǎng)絡(luò)資源的共享和復(fù)用問題桥氏，因此擁塞控制是網(wǎng)絡(luò)工程領(lǐng)域的核心問題之一温峭，并且隨著互聯(lián)網(wǎng)和數(shù)據(jù)中心...
    DeepNoMind閱讀 492評論 0贊 0
  • 網(wǎng)絡(luò)傳輸問題本質(zhì)上是對網(wǎng)絡(luò)資源的共享和復(fù)用問題，因此擁塞控制是網(wǎng)絡(luò)工程領(lǐng)域的核心問題之一字支，并且隨著互聯(lián)網(wǎng)和數(shù)據(jù)中心...
    DeepNoMind閱讀 745評論 0贊 0
  • 網(wǎng)絡(luò)傳輸問題本質(zhì)上是對網(wǎng)絡(luò)資源的共享和復(fù)用問題凤藏，因此擁塞控制是網(wǎng)絡(luò)工程領(lǐng)域的核心問題之一奸忽，并且隨著互聯(lián)網(wǎng)和數(shù)據(jù)中心...
    DeepNoMind閱讀 466評論 0贊 1
  • TCP通過維護(hù)一個擁塞窗口來進(jìn)行擁塞控制，擁塞控制的原則是揖庄，只要網(wǎng)絡(luò)中沒有出現(xiàn)擁塞栗菜，擁塞窗口的值就可以再增大一些，...
    風(fēng)亡小窩閱讀 1,875評論 0贊 1