RFC8312 中文翻譯——用于快速長距離網(wǎng)絡(luò)的 cubic 算法

RFC8312

摘要

CUBIC是當前TCP標準的擴展硕并。它與現(xiàn)有的TCP標準僅在發(fā)送方的擁塞控制算法上有所不同秧荆。特別地乙濒,它采用了三次函數(shù)代替了現(xiàn)有TCP標準中的線性窗口增加函數(shù)颁股,提高了在高速長距離網(wǎng)絡(luò)環(huán)境下的可擴展性和穩(wěn)定性。CUBIC及其前身的算法已經(jīng)被Linux作為默認算法使用了很多年诉儒。本文檔提供了CUBIC的規(guī)范忱反,以支持第三方實現(xiàn)温算,并通過對CUBIC性能的實驗來征求社區(qū)反饋注竿。

此 Memo 的狀態(tài)

本文件不是互聯(lián)網(wǎng)標準跟蹤規(guī)范魂贬;它是為了提供信息而出版的随橘。

本文檔是Internet工程任務(wù)組(IETF)的產(chǎn)品机蔗。它代表了IETF社區(qū)的共識甘萧。它已經(jīng)收到了公眾的審查扬卷,并已批準出版的互聯(lián)網(wǎng)工程指導(dǎo)小組(IESG)怪得。并非所有IESG批準的文件都適用于任何級別的互聯(lián)網(wǎng)標準徒恋;見RFC 7841第2節(jié)入挣。

有關(guān)本文件的當前狀態(tài)硝拧、任何勘誤表以及如何提供反饋的信息障陶,請訪問https://www.rfc-editor.org/info/rfc8312.

1. 介紹

TCP在快速長距離網(wǎng)絡(luò)中的低利用率問題在[K03]和[RFC3649]中有很好的描述抱究。這個問題產(chǎn)生于在具有大帶寬延遲積(BDP)的網(wǎng)絡(luò)中媳维,擁塞事件之后擁塞窗口的緩慢增加遏暴,在 [HKLRX06] 指出朋凉,即使在數(shù)百個數(shù)據(jù)包的擁塞窗口大小范圍內(nèi)杂彭,也經(jīng)常觀察到這個問題亲怠。這個問題同樣適用于所有 Reno 風格的TCP標準及其變體,包括TCP-Reno[RFC5681]主胧、TCP-NewReno[RFC6582][RFC6675]踪栋、SCTP[RFC4960]和TFRC[RFC5348]夷都,它們使用相同的線性增加函數(shù)進行窗口增長囤官,我們在下文中將它們統(tǒng)稱為“標準TCP”(Standard TCP)治拿。

CUBIC最初是在 [HRX08] 中提出的,它是對標準TCP擁塞控制算法的一種改進见坑。本文檔描述了CUBIC的最新規(guī)范荞驴。具體來說熊楼,CUBIC使用了一個CUBIC函數(shù)來代替標準TCP的線性窗口增加函數(shù)鲫骗,以提高在快速和長距離網(wǎng)絡(luò)下的可擴展性和穩(wěn)定性执泰。

Binary-Increase擁塞控制(BIC-TCP)[XHR04] 是CUBIC的前身渡蜻,在2005年被Linux選為默認的TCP擁塞控制算法茸苇,已經(jīng)被整個互聯(lián)網(wǎng)社區(qū)使用了好幾年学密。CUBIC使用了與BIC-TCP類似的窗口增加功能腻暮,在保持BIC-TCP的優(yōu)勢(如穩(wěn)定性、窗口可伸縮性和RTT公平性)的同時叫惊,它在帶寬使用方面比BIC-TCP更具攻擊性和公平性霍狰。CUBIC已經(jīng)取代BIC-TCP成為Linux中默認的TCP擁塞控制算法饰及,并被Linux全局部署燎含。通過在各種互聯(lián)網(wǎng)場景中的廣泛測試屏箍,我們相信CUBIC在全球互聯(lián)網(wǎng)上的測試和部署是安全的赴魁。

在接下來的章節(jié)中颖御,我們首先簡要說明了CUBIC的設(shè)計原則潘拱,然后提供了CUBIC的確切規(guī)格,最后根據(jù)[RFC5033]中規(guī)定的指南討論了CUBIC的安全特性瘪弓。

2. 約定

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文件中的關(guān)鍵詞“必須”月褥、“不得”、“必須”舀透、“應(yīng)”愕够、“不應(yīng)”惑芭、“應(yīng)”遂跟、“不應(yīng)”幻锁、“建議”哄尔、“不建議”岭接、“可”和“可選”在所有大寫字母出現(xiàn)時(且僅在所有大寫字母出現(xiàn)時)應(yīng)按照BCP 14[RFC2119][RFC8174]的規(guī)定進行解釋亿傅,如下所示葵擎。

3. CUBIC 設(shè)計原理

CUBIC遵循以下設(shè)計原則:

  • 原則1:為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性酬滤,CUBIC使用了一個三次函數(shù)的凹凸曲線來增加擁塞窗口的大小盯串,而不是僅僅使用一個凸函數(shù)。

  • 原則2:為了對TCP友好,CUBIC被設(shè)計成在RTT短河泳、帶寬小拆挥、標準TCP性能好的網(wǎng)絡(luò)中表現(xiàn)得像標準TCP某抓。

  • 原則3:對于RTT公平性,CUBIC被設(shè)計成在具有不同RTT的流之間實現(xiàn)線性帶寬共享崎坊。

  • 原則4:CUBIC適當設(shè)置乘性窗口遞減因子流强,以平衡可伸縮性和收斂速度。

3.1 原則1

為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性蚕捉,CUBIC使用了一個三次函數(shù)的凹凸曲線來增加擁塞窗口的大小迫淹,而不是僅僅使用一個凸函數(shù)敛熬。

為了更好的網(wǎng)絡(luò)利用率和穩(wěn)定性应民,CUBIC [HRX08] 使用了一個三次函數(shù)來增加窗口繁仁,該函數(shù)根據(jù)距離上一次擁塞事件所經(jīng)過的時間來計算窗口增加的大小归园。大多數(shù)替代標準TCP的擁塞控制算法都使用凸函數(shù)來增加擁塞窗口庸诱,而CUBIC算法同時使用凸函數(shù)和凹函數(shù)來增加窗口朱灿。在通過冗余ACK或顯式擁塞通知(ECN Echo ACKs)[RFC3168] 檢測到擁塞事件母剥,使得窗口減小之后环疼,CUBIC將檢測到擁塞時的窗口大小記錄為 W_{max} 炫隶,并對擁塞窗口進行乘性減少伪阶。在進入擁塞避免階段后栅贴,利用三次函數(shù)的凹形曲線(左邊)增加擁塞窗口檐薯。三次函數(shù)的穩(wěn)定點設(shè)置為 W_{max} 坛缕,窗口大小在到達 W_{max} 之前會遵循三次函數(shù)曲線持續(xù)增長赚楚。在窗口大小達到 W_{max} 之后宠页,三次函數(shù)進入到凸形曲線區(qū)域(右邊)勇皇,窗口大小開始沿著凸形區(qū)域增大敛摘。這種窗口調(diào)整方式(先凹后凸)提高了算法的穩(wěn)定性兄淫,同時保持了較高的網(wǎng)絡(luò)利用率[CEHRX07]捕虽。這是因為窗口大小幾乎保持不變泄私,圍繞著 W_{max} 形成一個穩(wěn)態(tài)區(qū)域捅暴,此時網(wǎng)絡(luò)利用率被認為是最高的蓬痒。在穩(wěn)態(tài)下梧奢,CUBIC的大多數(shù)窗口大小樣本都接近于 W_{max} 亲轨,從而提高了網(wǎng)絡(luò)的利用率和穩(wěn)定性瓶埋。需要注意的是养筒,那些僅使用凸函數(shù)來增加擁塞窗口大小的擁塞控制算法的在接近 W_{max} 時窗口會劇烈增加晕粪,從而在網(wǎng)絡(luò)飽和點附近引入大量的包突發(fā)巫湘,可能導(dǎo)致頻繁的全局丟失同步( global loss synchronizations )。

  • W_{max} => 記錄了早期檢測到擁塞時的窗口大小阅嘶,表征客戶端窗口如果超過這個值太多可能會導(dǎo)致大量丟包讯柔,應(yīng)該盡量的接近并穩(wěn)定在這個值(在穩(wěn)態(tài)階段)魂迄;
  • 全局同步:每個發(fā)送方與其他發(fā)送方同時降低和增加傳輸速率的這種模式被稱為“全局同步”捣炬。=> TCP global synchronization
image-20200702115622954

3.2 原則2

為了對TCP友好婿屹,CUBIC被設(shè)計成在RTT短、帶寬小美莫、標準TCP性能好的網(wǎng)絡(luò)中表現(xiàn)得像標準TCP。

CUBIC 通過建立 “TCP友好區(qū)域” 襟铭,使其在較小的 BDP 場景下寒砖,將每個流的公平性提升到標準TCP的水平。注意漠嵌,標準TCP在短RTT和小帶寬(或小BDP)網(wǎng)絡(luò)下表現(xiàn)良好儒鹿,但在具有長RTT和大帶寬(或大BDP)的網(wǎng)絡(luò)中约炎,存在可擴展性問題章钾。標準TCP的另一種擁塞控制算法設(shè)計為在每個流的基礎(chǔ)上對標準TCP友好贱傀,必須在小型BDP網(wǎng)絡(luò)中比在大型BDP網(wǎng)絡(luò)中更有效地增加擁塞窗口魁衙。CUBIC 的侵略性主要取決于窗口縮減前的最大窗口大小 W_{max}剖淀,小BDP網(wǎng)絡(luò)的 W_{max} 小于大BDP網(wǎng)絡(luò)纵隔。因此,CUBIC在小型BDP網(wǎng)絡(luò)中增加擁塞窗口的力度小于大型BDP網(wǎng)絡(luò)炮姨。因此捌刮,當 CUBIC 算法的三次函數(shù)增加擁塞窗口的力度小于標準TCP時,CUBIC 只遵循標準TCP的窗口大小舒岸,以確保 CUBIC 算法在小型BDP網(wǎng)絡(luò)中至少達到與標準TCP相同的吞吐量绅作。我們將 CUBIC 類似于標準TCP的區(qū)域稱為“TCP友好區(qū)域”。

3.3 原則3

對于RTT公平性蛾派,CUBIC被設(shè)計成在具有不同RTT的流之間實現(xiàn)線性帶寬共享。

具有不同RTT的兩個 CUBIC 流( CUBIC flow ) 的吞吐量比率( ratio )與其RTT比率的倒數(shù)成正比洪乍,其中對于每一個流的吞吐量近似于其擁塞窗口的大小除以其RTT眯杏。具體地說,CUBIC在TCP友好區(qū)之外保持獨立于RTT的窗口增長率壳澳,因此具有不同RTT的流在穩(wěn)定狀態(tài)下在TCP友好區(qū)之外操作時具有相似的擁塞窗口大小役拴。這種線性吞吐率的概念類似于高統(tǒng)計復(fù)用環(huán)境下的標準TCP,在這種環(huán)境下钾埂,數(shù)據(jù)包丟失與單個流量無關(guān)河闰。然而,在低統(tǒng)計復(fù)用環(huán)境下褥紫,具有不同RTT的標準TCP流的吞吐量比與其RTT比的倒數(shù)成二次比例[XHR04]姜性。CUBIC始終確保線性吞吐量比與統(tǒng)計復(fù)用的級別無關(guān)。這是對標準TCP的改進髓考。雖然對不同RTT流的特定吞吐量比率沒有共識部念,但我們認為在有線互聯(lián)網(wǎng)下,使用線性吞吐量比率似乎比使用相等吞吐量(即氨菇,不同RTT流的相同吞吐量)或更高階吞吐量比率(例如:低統(tǒng)計復(fù)用環(huán)境下標準TCP的二次吞吐率)更加合理儡炼。

3.4 原則4

CUBIC適當設(shè)置乘性窗口遞減因子,以平衡可伸縮性和收斂速度查蓉。

為了在可擴展性和收斂速度之間取得平衡乌询,CUBIC將乘性窗口遞減因子設(shè)置為0.7,而標準TCP使用0.5豌研。雖然這提高了CUBIC的可伸縮性妹田,但這種決策的一個副作用是收斂較慢唬党,特別是在低統(tǒng)計復(fù)用環(huán)境下。這種設(shè)計選擇遵循了《高速TCP》(HSTCP)[RFC3649]一書的作者和其他研究人員(例如[GV02])所做的觀察:當前的互聯(lián)網(wǎng)變得更加異步鬼佣,丟失同步頻率更低驶拱,統(tǒng)計復(fù)用率更高。在這種環(huán)境下晶衷,即使嚴格的乘增乘減(MIMD)也可以收斂蓝纲。具有相同RTT的 CUBIC流 總是獨立于統(tǒng)計復(fù)用收斂到相同的吞吐量,從而實現(xiàn)算法內(nèi)公平性晌纫。我們還發(fā)現(xiàn)税迷,在統(tǒng)計復(fù)用充分的環(huán)境下,CUBIC流 的收斂速度是合理的缸匪。

4. CUBIC 擁塞控制

本文檔中所有窗口大小的單位為最大段大形毯(MSS, Maximum Segment Size )的段类溢,所有時間的單位為秒凌蔬。cwnd 表示流的擁塞窗口大小, ssthresh 表示慢啟動閾值闯冷。

4.1 窗口增加函數(shù)

CUBIC通過僅在接收到ACK時增加擁塞窗口來維持標準TCP的確認(ACK)時鐘砂心。它不會對TCP的快速恢復(fù)和重傳進行任何更改,例如TCP NewReno [RFC6582] [RFC6675]蛇耀。在擁塞避免期間辩诞,如果重復(fù)ack檢測到數(shù)據(jù)包丟失或ack使用ECN Echo flags[RFC3168]檢測到網(wǎng)絡(luò)擁塞,CUBIC將更改標準TCP的窗口增加功能纺涤。假設(shè)在上一次擁塞事件中窗口縮小之前的窗口大小為 W_{max} 译暂。

CUBIC使用以下函數(shù)進行窗口的增加:

Eq. 1 W_{cubic}(t) = C * (t - K)^3 + W_{max}

其中 C 是一個常數(shù),用于確定高BDP網(wǎng)絡(luò)中窗口增加的侵略性撩炊,t 是從當前擁塞避免開始所經(jīng)過的時間外永, K 是上述函數(shù)將當前窗口大小增加到 W_{max} 所需的時間,如果沒有進一步的擁塞事件拧咳,則使用以下公式計算:

Eq. 2 K = \sqrt[3]{\frac{W_{max} * (1 - \beta)}{C}}

其中 \beta_{cubic} 是CUBIC的乘性遞減因子伯顶,即,當檢測到擁塞事件時骆膝,CUBIC將其 cwnd 減少到 W_{cubic}(0)=W_{max} * \beta 祭衩。我們將在第4.5節(jié)討論如何設(shè)置 \beta_{cubic} ,在第5節(jié)討論如何設(shè)置 C 阅签。

當在擁塞避免期間接收到ACK時掐暮,CUBIC使用 Eq. 1 計算下一RTT期間的窗口增加率 W_{cubic}(t+RTT) 作為擁塞窗口的候選目標值,其中RTT是由標準TCP計算的加權(quán)平均RTT政钟。

根據(jù)當前擁塞窗口大小 cwnd 的值劫乱,CUBIC以三種不同的模式運行:

  1. TCP友好區(qū)域 织中,確保CUBIC至少達到與標準TCP相同的吞吐量;
  2. 凹區(qū)域 衷戈,如果 CUBIC 不在TCP友好區(qū)域狭吼,且 cwnd 小于 W_{max}
  3. 凸區(qū)域 殖妇,如果 CUBIC 不在TCP友好區(qū)域刁笙,且 cwnd 大于 W_{max}

下面谦趣,我們將描述CUBIC在每個區(qū)域采取的確切行動疲吸。

4.2 TCP友好區(qū)域

標準TCP在某些類型的網(wǎng)絡(luò)中表現(xiàn)良好,例如前鹅,在短RTT和小帶寬(或小BDP)網(wǎng)絡(luò)下摘悴。在這些網(wǎng)絡(luò)中,我們使用TCP友好區(qū)域來確保CUBIC至少達到與標準TCP相同的吞吐量舰绘。

根據(jù)[FHP00]中的分析蹂喻,設(shè)計了TCP友好區(qū)。分析研究了加法因子為 \alpha_{aimd} (每RTT增加一個窗口)捂寿、乘法因子為 \beta_{aimd}(表示為)的加法增乘減(AIMD)算法的性能. 具體地說口四,AIMD(\alpha_{aimd}, \beta_{aimd}) 的平均擁塞窗口大小可以使用 Eq .3 (其中 \alpha_{aimd} = \frac{3 * (1 - \beta_{aimd})}{1 + \beta_{aimd}} )來計算窗口大小,以此來實現(xiàn)與使用AIMD(1秦陋,0.5)的標準TCP相同的平均窗口大小蔓彩。

Eq .3 AVG_{W_{aimd}} = \sqrt{\frac{\alpha_{aimd} * (1 + \beta_{aimd})}{2 * (1 - \beta_{aimd}) * p}}

基于上述分析,CUBIC使用Eq. 4來估計窗口大小 W_{est}AIMD(\alpha_{aimd}, \beta_{aimd})驳概, 其中 \alpha_{aimd} = \frac{3 * (1 - \beta_{cubic})}{1 + \beta_{cubic}}赤嚼, \beta_{aimd} = \beta_{cubic})的 與 以及 ,它實現(xiàn)了與標準TCP相同的平均窗口大小顺又。當在擁塞避免階段收到 ACK 時更卒,( cwnd 可以大于或小于 W_{max} ),CUBIC 檢查 W_{cubic}(t) 是否小于W_{est}(t) 待榔。 如果小于逞壁,則 CUBIC 當前位于TCP友好區(qū)域,在每次收到ACK時锐锣, cwnd 應(yīng)該設(shè)置為 W_{est}(t) 腌闯。

Eq .4 W_{est}(t) = W_{max} * \beta_{cubic} + \frac{3 * (1 - \beta_{cubic})}{1 + \beta_{cubic}} * \frac{t}{RTT}

4.3 凹區(qū)域

當在擁塞避免階段接收到ACK時,如果CUBIC不在TCP友好區(qū)域并且 cwnd 小于 W_{max} 雕憔,那么 CUBIC 處于凹區(qū)域姿骏。CUBIC算法處于次區(qū)域時,每收到一個ACK斤彼,cwnd 必須增加 \frac{W_{cubic}(t + RTT) - cwnd}{cwnd} 分瘦,其中 W_{cubic}(t+RTT) 使用 Eq. 1 計算蘸泻。

4.4 凸區(qū)域

當在擁塞避免階段接收到ACK時,如果CUBIC不在TCP友好區(qū)域并且 cwnd 大于或等于 W_{max} 嘲玫, 那么 CUBIC 處于凸區(qū)域悦施。凸區(qū)域表示自上一次擁塞事件以來,網(wǎng)絡(luò)條件可能受到了干擾去团,這可能意味著在一些流離開之后抡诞,可用帶寬會增加。由于因特網(wǎng)是高度異步的土陪,所以在不引起可用帶寬的重大變化的情況下昼汗,一定量的擾動總是可能的。在這個區(qū)域鬼雀,CUBIC非常小心顷窒,非常緩慢地增加它的窗口大小。凸函數(shù)曲線確保窗口在開始時增長非常緩慢源哩,并逐漸增加其增長率鞋吉。我們也把這個區(qū)域稱為“最大探測階段”,因為CUBIC正在尋找一個新的 W_{max} 璧疗。CUBIC算法處于次區(qū)域時坯辩,每收到一個ACK馁龟,cwnd 必須增加 \frac{W_{cubic}(t + RTT) - cwnd}{cwnd} 崩侠,其中 W_{cubic}(t+RTT) 使用 Eq. 1 計算。

4. 5 乘性減少

當收到三次冗余ACK坷檩、檢測到丟包或收到顯示擁塞控制包時却音,檢測到網(wǎng)絡(luò)擁塞,CUBIC 通過如下步驟更新其 W_{max} 矢炼、 cwndssthresh

其中 \beta_{cubic} 應(yīng)設(shè)置為0.7

W_{max} = cwnd; // save window size before reduction
ssthresh = cwnd * \beta_{cubic}; // new slow-start threshold
ssthresh = max(ssthresh, 2); // threshold is at least 2 MSS
cwnd = cwnd * \beta_{cubic}; // window reduction

W_max = cwnd;                 // save window size before reduction
ssthresh = cwnd * beta_cubic; // new slow-start threshold
ssthresh = max(ssthresh, 2);  // threshold is at least 2 MSS
cwnd = cwnd * beta_cubic;     // window reduction

\beta_{cubic} 設(shè)置為一個大于 0.5 的值的副作用為收斂速度較慢系瓢。我們認為,雖然設(shè)置自適應(yīng)的 \beta_{cubic} 可以使得算法更快的收斂句灌,但這將使得 CUBIC 的分析更加困難夷陋。這種自適應(yīng)調(diào)整 \beta_{cubic} 是將會在 CUBIC 的下一個版本納入考慮。

4.6 Fast Convergence

為了提高 CUBIC 算法的收斂速度胰锌,我們在 CUBIC 算法中加入了一個啟發(fā)式算法骗绕。當一個新的流加入網(wǎng)絡(luò)時,如果現(xiàn)有的流已經(jīng)使用了網(wǎng)絡(luò)的所有帶寬资昧,那么網(wǎng)絡(luò)中的現(xiàn)有流需要放棄一些帶寬來允許新的流有一些增長的空間酬土。為了加速現(xiàn)有流的帶寬釋放,應(yīng)該實現(xiàn)以下稱為“快速收斂”的機制格带。

通過快速收斂撤缴,當發(fā)生擁塞事件時刹枉,在擁塞窗口的窗口縮小之前,每個流會記住自己在更新 W_{max} 之前最后一個 W_{max} 的值屈呕,我們將其標記為 W_{lastmax} 微宝。

if (W_max < W_last_max){ // should we make room for others
  W_last_max = W_max;             // remember the last W_max
  W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else {
  W_last_max = W_max              // remember the last W_max
}

在一個擁塞事件發(fā)生時,如果的當前 W_{max} 值小于 W_{lastmax}虎眨,則表示由于可用帶寬的變化芥吟,該流的飽和點正在減小。然后我們允許這個流通過進一步減少 W_{max} 來釋放更多的帶寬专甩。此操作有效地延長了此流增加其擁塞窗口的時間钟鸵,因為減少 W_{max} 會迫使流更早地達到飽和點。這使得新的流有更多的時間趕上它的擁塞窗口大小涤躲。

4.7 Timeout

在超時的情況下棺耍,CUBIC遵循標準TCP來減少 cwnd [RFC5681],與標準TCP[RFC5681]有一點不同的是种樱,CUBIC 使用 \beta_{cubic} 來設(shè)置 ssthresh 蒙袍。

在超時之后的第一次擁塞避免期間,CUBIC使用 Eq. 1 增加其擁塞窗口大小嫩挤,其中 t 是自當前擁塞避免開始以來經(jīng)過的時間害幅, K 被設(shè)置為0,并且 W_{max} 被設(shè)置為當前擁塞避免開始時的擁塞窗口大小岂昭。

4.8 Slow Start

cwnd 不大于 ssthresh 時以现,CUBIC必須采用慢啟動算法。在慢啟動算法中约啊,CUBIC可以在一般網(wǎng)絡(luò)中選擇標準TCP慢啟動算法RFC5681邑遏,也可以在快速和長距離網(wǎng)絡(luò)中選擇有限慢啟動算法RFC3742或混合慢啟動算法HR08。

在CUBIC運行混合慢啟動[HR08]的情況下恰矩,它可以退出第一個慢啟動而不引起任何分組丟失记盒,因此是未定義的。在這種特殊情況下外傅,CUBIC切換到擁塞避免并使用 Eq. 1 增大其擁塞窗口大小纪吮,其中 t 是自當前擁塞避免開始以來經(jīng)過的時間,K 被設(shè)置為0萎胰,并且 W_{max} 設(shè)置為當前擁塞避免開始時的擁塞窗口大小碾盟。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市奥洼,隨后出現(xiàn)的幾起案子巷疼,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,470評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件嚼沿,死亡現(xiàn)場離奇詭異估盘,居然都是意外死亡,警方通過查閱死者的電腦和手機骡尽,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,393評論 3 392
  • 文/潘曉璐 我一進店門遣妥,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人攀细,你說我怎么就攤上這事箫踩。” “怎么了谭贪?”我有些...
    開封第一講書人閱讀 162,577評論 0 353
  • 文/不壞的土叔 我叫張陵境钟,是天一觀的道長。 經(jīng)常有香客問我俭识,道長慨削,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,176評論 1 292
  • 正文 為了忘掉前任套媚,我火速辦了婚禮缚态,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘堤瘤。我一直安慰自己玫芦,他們只是感情好,可當我...
    茶點故事閱讀 67,189評論 6 388
  • 文/花漫 我一把揭開白布本辐。 她就那樣靜靜地躺著桥帆,像睡著了一般。 火紅的嫁衣襯著肌膚如雪师郑。 梳的紋絲不亂的頭發(fā)上环葵,一...
    開封第一講書人閱讀 51,155評論 1 299
  • 那天调窍,我揣著相機與錄音宝冕,去河邊找鬼。 笑死邓萨,一個胖子當著我的面吹牛地梨,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播缔恳,決...
    沈念sama閱讀 40,041評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼宝剖,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了歉甚?” 一聲冷哼從身側(cè)響起万细,我...
    開封第一講書人閱讀 38,903評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎纸泄,沒想到半個月后赖钞,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體腰素,經(jīng)...
    沈念sama閱讀 45,319評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,539評論 2 332
  • 正文 我和宋清朗相戀三年雪营,在試婚紗的時候發(fā)現(xiàn)自己被綠了弓千。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,703評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡献起,死狀恐怖洋访,靈堂內(nèi)的尸體忽然破棺而出砂沛,到底是詐尸還是另有隱情孤里,我是刑警寧澤,帶...
    沈念sama閱讀 35,417評論 5 343
  • 正文 年R本政府宣布宿刮,位于F島的核電站岂嗓,受9級特大地震影響扶歪,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜摄闸,卻給世界環(huán)境...
    茶點故事閱讀 41,013評論 3 325
  • 文/蒙蒙 一善镰、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧年枕,春花似錦炫欺、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,664評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至摩桶,卻和暖如春桥状,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背硝清。 一陣腳步聲響...
    開封第一講書人閱讀 32,818評論 1 269
  • 我被黑心中介騙來泰國打工辅斟, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人芦拿。 一個月前我還...
    沈念sama閱讀 47,711評論 2 368
  • 正文 我出身青樓士飒,卻偏偏與公主長得像,于是被迫代替她去往敵國和親蔗崎。 傳聞我的和親對象是個殘疾皇子酵幕,可洞房花燭夜當晚...
    茶點故事閱讀 44,601評論 2 353

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

  • Java IO知識圖譜 1 OSI七層網(wǎng)絡(luò)模型 上下層之間遵循的約定叫做"接口",同層之間遵循的約定叫做"協(xié)議"....
    allen鍋閱讀 924評論 0 1
  • TCP擁塞控制算法的目的可以簡單概括為:公平競爭缓苛、充分利用網(wǎng)絡(luò)帶寬芳撒、降低網(wǎng)絡(luò)延時、優(yōu)化用戶體驗,然而就目前而言要實...
    VictorHong閱讀 2,343評論 0 0
  • 這是本人梳理的網(wǎng)絡(luò)編程背景知識筆記笔刹,其中很多內(nèi)容也不是原創(chuàng)庐完,拿來之后根據(jù)自己的理解做的整合。分享出來徘熔,希望對大家有...
    架構(gòu)禪話閱讀 877評論 0 1
  • RFC6298[https://datatracker.ietf.org/doc/html/rfc6298] 摘要...
    SunnyQjm閱讀 1,435評論 0 1
  • 表情是什么门躯,我認為表情就是表現(xiàn)出來的情緒。表情可以傳達很多信息酷师。高興了當然就笑了讶凉,難過就哭了。兩者是相互影響密不可...
    Persistenc_6aea閱讀 124,926評論 2 7