面試官劝术,不要再問我三次握手和四次揮手

三次握手和四次揮手是各個公司常見的考點,也具有一定的水平區(qū)分度呆奕,也被一些面試官作為熱身題养晋。很多小伙伴說這個問題剛開始回答的挺好,但是后面越回答越冒冷汗梁钾,最后就歇菜了绳泉。

見過比較典型的面試場景是這樣的:

面試官:請介紹下三次握手
求職者:第一次握手就是客戶端給服務(wù)器端發(fā)送一個報文,第二次就是服務(wù)器收到報文之后姆泻,會應(yīng)答一個報文給客戶端零酪,第三次握手就是客戶端收到報文后再給服務(wù)器發(fā)送一個報文缕贡,三次握手就成功了翘悉。
面試官:然后呢艰赞?
求職者:這就是三次握手的過程井氢,很簡單的。
面試官:同廉。。。峻呛。罗售。。
番外篇:一首涼涼送給你

記住猿人谷一句話:面試時越簡單的問題钩述,一般就是隱藏著比較大的坑寨躁,一般都是需要將問題擴(kuò)展的。上面求職者的回答不對嗎牙勘?當(dāng)然對职恳,但距離面試官的期望可能還有點距離。

希望大家能帶著如下問題進(jìn)行閱讀方面,收獲會更大放钦。

  1. 請畫出三次握手和四次揮手的示意圖
  2. 為什么連接的時候是三次握手?
  3. 什么是半連接隊列恭金?
  4. ISN(Initial Sequence Number)是固定的嗎操禀?
  5. 三次握手過程中可以攜帶數(shù)據(jù)嗎?
  6. 如果第三次握手丟失了横腿,客戶端服務(wù)端會如何處理颓屑?
  7. SYN攻擊是什么?
  8. 揮手為什么需要四次耿焊?
  9. 四次揮手釋放連接時揪惦,等待2MSL的意義?
三次握手和四次揮手.png

1. 三次握手

三次握手(Three-way Handshake)其實就是指建立一個TCP連接時,需要客戶端和服務(wù)器總共發(fā)送3個包罗侯。進(jìn)行三次握手的主要作用就是為了確認(rèn)雙方的接收能力和發(fā)送能力是否正常器腋、指定自己的初始化序列號為后面的可靠性傳送做準(zhǔn)備。實質(zhì)上其實就是連接服務(wù)器指定端口歇父,建立TCP連接蒂培,并同步連接雙方的序列號和確認(rèn)號,交換TCP窗口大小信息榜苫。

剛開始客戶端處于 Closed 的狀態(tài)护戳,服務(wù)端處于 Listen 狀態(tài)。
進(jìn)行三次握手:

  • 第一次握手:客戶端給服務(wù)端發(fā)一個 SYN 報文垂睬,并指明客戶端的初始化序列號 ISN(c)媳荒。此時客戶端處于 SYN_SEND 狀態(tài)。

    首部的同步位SYN=1驹饺,初始序號seq=x钳枕,SYN=1的報文段不能攜帶數(shù)據(jù),但要消耗掉一個序號赏壹。

  • 第二次握手:服務(wù)器收到客戶端的 SYN 報文之后鱼炒,會以自己的 SYN 報文作為應(yīng)答,并且也是指定了自己的初始化序列號 ISN(s)蝌借。同時會把客戶端的 ISN + 1 作為ACK 的值昔瞧,表示自己已經(jīng)收到了客戶端的 SYN指蚁,此時服務(wù)器處于 SYN_REVD 的狀態(tài)。

    在確認(rèn)報文段中SYN=1自晰,ACK=1凝化,確認(rèn)號ack=x+1,初始序號seq=y酬荞。

  • 第三次握手:客戶端收到 SYN 報文之后搓劫,會發(fā)送一個 ACK 報文,當(dāng)然混巧,也是一樣把服務(wù)器的 ISN + 1 作為 ACK 的值枪向,表示已經(jīng)收到了服務(wù)端的 SYN 報文,此時客戶端處于 ESTABLISHED 狀態(tài)牲剃。服務(wù)器收到 ACK 報文之后遣疯,也處于 ESTABLISHED 狀態(tài),此時凿傅,雙方已建立起了連接缠犀。

    確認(rèn)報文段ACK=1,確認(rèn)號ack=y+1聪舒,序號seq=x+1(初始為seq=x辨液,第二個報文段所以要+1),ACK報文段可以攜帶數(shù)據(jù)箱残,不攜帶數(shù)據(jù)則不消耗序號滔迈。

發(fā)送第一個SYN的一端將執(zhí)行主動打開(active open),接收這個SYN并發(fā)回下一個SYN的另一端執(zhí)行被動打開(passive open)被辑。

在socket編程中燎悍,客戶端執(zhí)行connect()時,將觸發(fā)三次握手盼理。

三次握手.png

1.1 為什么需要三次握手谈山,兩次不行嗎?

弄清這個問題宏怔,我們需要先弄明白三次握手的目的是什么奏路,能不能只用兩次握手來達(dá)到同樣的目的。

  • 第一次握手:客戶端發(fā)送網(wǎng)絡(luò)包臊诊,服務(wù)端收到了鸽粉。
    這樣服務(wù)端就能得出結(jié)論:客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的抓艳。
  • 第二次握手:服務(wù)端發(fā)包触机,客戶端收到了。
    這樣客戶端就能得出結(jié)論:服務(wù)端的接收、發(fā)送能力威兜,客戶端的接收销斟、發(fā)送能力是正常的。不過此時服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常椒舵。
  • 第三次握手:客戶端發(fā)包,服務(wù)端收到了约谈。
    這樣服務(wù)端就能得出結(jié)論:客戶端的接收笔宿、發(fā)送能力正常,服務(wù)器自己的發(fā)送棱诱、接收能力也正常泼橘。

因此,需要三次握手才能確認(rèn)雙方的接收與發(fā)送能力是否正常迈勋。

試想如果是用兩次握手炬灭,則會出現(xiàn)下面這種情況:

如客戶端發(fā)出連接請求,但因連接請求報文丟失而未收到確認(rèn)靡菇,于是客戶端再重傳一次連接請求重归。后來收到了確認(rèn),建立了連接厦凤。數(shù)據(jù)傳輸完畢后鼻吮,就釋放了連接,客戶端共發(fā)出了兩個連接請求報文段较鼓,其中第一個丟失椎木,第二個到達(dá)了服務(wù)端,但是第一個丟失的報文段只是在某些網(wǎng)絡(luò)結(jié)點長時間滯留了博烂,延誤到連接釋放以后的某個時間才到達(dá)服務(wù)端香椎,此時服務(wù)端誤認(rèn)為客戶端又發(fā)出一次新的連接請求,于是就向客戶端發(fā)出確認(rèn)報文段禽篱,同意建立連接畜伐,不采用三次握手,只要服務(wù)端發(fā)出確認(rèn)谆级,就建立新的連接了烤礁,此時客戶端忽略服務(wù)端發(fā)來的確認(rèn),也不發(fā)送數(shù)據(jù)肥照,則服務(wù)端一致等待客戶端發(fā)送數(shù)據(jù)脚仔,浪費資源。

1.2 什么是半連接隊列舆绎?

服務(wù)器第一次收到客戶端的 SYN 之后鲤脏,就會處于 SYN_RCVD 狀態(tài),此時雙方還沒有完全建立其連接,服務(wù)器會把此種狀態(tài)下請求連接放在一個隊列里猎醇,我們把這種隊列稱之為半連接隊列窥突。

當(dāng)然還有一個全連接隊列,就是已經(jīng)完成三次握手硫嘶,建立起連接的就會放在全連接隊列中阻问。如果隊列滿了就有可能會出現(xiàn)丟包現(xiàn)象。

這里在補(bǔ)充一點關(guān)于SYN-ACK 重傳次數(shù)的問題:
服務(wù)器發(fā)送完SYN-ACK包沦疾,如果未收到客戶確認(rèn)包称近,服務(wù)器進(jìn)行首次重傳,等待一段時間仍未收到客戶確認(rèn)包哮塞,進(jìn)行第二次重傳刨秆。如果重傳次數(shù)超過系統(tǒng)規(guī)定的最大重傳次數(shù),系統(tǒng)將該連接信息從半連接隊列中刪除忆畅。
注意衡未,每次重傳等待的時間不一定相同,一般會是指數(shù)增長家凯,例如間隔時間為 1s缓醋,2s,4s肆饶,8s......

1.3 ISN(Initial Sequence Number)是固定的嗎改衩?

當(dāng)一端為建立連接而發(fā)送它的SYN時,它為連接選擇一個初始序號驯镊。ISN隨時間而變化葫督,因此每個連接都將具有不同的ISN。ISN可以看作是一個32比特的計數(shù)器板惑,每4ms加1 橄镜。這樣選擇序號的目的在于防止在網(wǎng)絡(luò)中被延遲的分組在以后又被傳送,而導(dǎo)致某個連接的一方對它做錯誤的解釋冯乘。

三次握手的其中一個重要功能是客戶端和服務(wù)端交換 ISN(Initial Sequence Number)洽胶,以便讓對方知道接下來接收數(shù)據(jù)的時候如何按序列號組裝數(shù)據(jù)。如果 ISN 是固定的裆馒,攻擊者很容易猜出后續(xù)的確認(rèn)號姊氓,因此 ISN 是動態(tài)生成的。

1.4 三次握手過程中可以攜帶數(shù)據(jù)嗎喷好?

其實第三次握手的時候翔横,是可以攜帶數(shù)據(jù)的。但是梗搅,第一次禾唁、第二次握手不可以攜帶數(shù)據(jù)

為什么這樣呢?大家可以想一個問題效览,假如第一次握手可以攜帶數(shù)據(jù)的話,如果有人要惡意攻擊服務(wù)器荡短,那他每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù)丐枉。因為攻擊者根本就不理服務(wù)器的接收、發(fā)送能力是否正常掘托,然后瘋狂著重復(fù)發(fā) SYN 報文的話瘦锹,這會讓服務(wù)器花費很多時間、內(nèi)存空間來接收這些報文闪盔。

也就是說沼本,第一次握手不可以放數(shù)據(jù),其中一個簡單的原因就是會讓服務(wù)器更加容易受到攻擊了锭沟。而對于第三次的話,此時客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)识补。對于客戶端來說族淮,他已經(jīng)建立起連接了,并且也已經(jīng)知道服務(wù)器的接收凭涂、發(fā)送能力是正常的了祝辣,所以能攜帶數(shù)據(jù)也沒啥毛病。

1.5 SYN攻擊是什么切油?

服務(wù)器端的資源分配是在二次握手時分配的蝙斜,而客戶端的資源是在完成三次握手時分配的,所以服務(wù)器容易受到SYN洪泛攻擊澎胡。SYN攻擊就是Client在短時間內(nèi)偽造大量不存在的IP地址孕荠,并向Server不斷地發(fā)送SYN包,Server則回復(fù)確認(rèn)包攻谁,并等待Client確認(rèn)稚伍,由于源地址不存在,因此Server需要不斷重發(fā)直至超時戚宦,這些偽造的SYN包將長時間占用未連接隊列个曙,導(dǎo)致正常的SYN請求因為隊列滿而被丟棄,從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓受楼。SYN 攻擊是一種典型的 DoS/DDoS 攻擊垦搬。

檢測 SYN 攻擊非常的方便,當(dāng)你在服務(wù)器上看到大量的半連接狀態(tài)時艳汽,特別是源IP地址是隨機(jī)的猴贰,基本上可以斷定這是一次SYN攻擊。在 Linux/Unix 上可以使用系統(tǒng)自帶的 netstats 命令來檢測 SYN 攻擊骚灸。

netstat -n -p TCP | grep SYN_RECV

常見的防御 SYN 攻擊的方法有如下幾種:

  • 縮短超時(SYN Timeout)時間
  • 增加最大半連接數(shù)
  • 過濾網(wǎng)關(guān)防護(hù)
  • SYN cookies技術(shù)

2. 四次揮手

建立一個連接需要三次握手糟趾,而終止一個連接要經(jīng)過四次揮手(也有將四次揮手叫做四次握手的)。這由TCP的半關(guān)閉(half-close)造成的。所謂的半關(guān)閉义郑,其實就是TCP提供了連接的一端在結(jié)束它的發(fā)送后還能接收來自另一端數(shù)據(jù)的能力蝶柿。

TCP 的連接的拆除需要發(fā)送四個包,因此稱為四次揮手(Four-way handshake)非驮,客戶端或服務(wù)器均可主動發(fā)起揮手動作交汤。

剛開始雙方都處于 ESTABLISHED 狀態(tài),假如是客戶端先發(fā)起關(guān)閉請求劫笙。四次揮手的過程如下:

  • 第一次揮手:客戶端發(fā)送一個 FIN 報文芙扎,報文中會指定一個序列號。此時客戶端處于 FIN_WAIT1 狀態(tài)填大。
    即發(fā)出連接釋放報文段(FIN=1戒洼,序號seq=u),并停止再發(fā)送數(shù)據(jù)允华,主動關(guān)閉TCP連接圈浇,進(jìn)入FIN_WAIT1(終止等待1)狀態(tài),等待服務(wù)端的確認(rèn)靴寂。
  • 第二次揮手:服務(wù)端收到 FIN 之后磷蜀,會發(fā)送 ACK 報文,且把客戶端的序列號值 +1 作為 ACK 報文的序列號值百炬,表明已經(jīng)收到客戶端的報文了褐隆,此時服務(wù)端處于 CLOSE_WAIT 狀態(tài)。
    即服務(wù)端收到連接釋放報文段后即發(fā)出確認(rèn)報文段(ACK=1剖踊,確認(rèn)號ack=u+1庶弃,序號seq=v),服務(wù)端進(jìn)入CLOSE_WAIT(關(guān)閉等待)狀態(tài)蜜宪,此時的TCP處于半關(guān)閉狀態(tài)虫埂,客戶端到服務(wù)端的連接釋放∑匝椋客戶端收到服務(wù)端的確認(rèn)后掉伏,進(jìn)入FIN_WAIT2(終止等待2)狀態(tài),等待服務(wù)端發(fā)出的連接釋放報文段澳窑。
  • 第三次揮手:如果服務(wù)端也想斷開連接了斧散,和客戶端的第一次揮手一樣,發(fā)給 FIN 報文摊聋,且指定一個序列號鸡捐。此時服務(wù)端處于 LAST_ACK 的狀態(tài)。
    即服務(wù)端沒有要向客戶端發(fā)出的數(shù)據(jù)麻裁,服務(wù)端發(fā)出連接釋放報文段(FIN=1箍镜,ACK=1源祈,序號seq=w,確認(rèn)號ack=u+1)色迂,服務(wù)端進(jìn)入LAST_ACK(最后確認(rèn))狀態(tài)香缺,等待客戶端的確認(rèn)。
  • 第四次揮手:客戶端收到 FIN 之后歇僧,一樣發(fā)送一個 ACK 報文作為應(yīng)答图张,且把服務(wù)端的序列號值 +1 作為自己 ACK 報文的序列號值,此時客戶端處于 TIME_WAIT 狀態(tài)诈悍。需要過一陣子以確保服務(wù)端收到自己的 ACK 報文之后才會進(jìn)入 CLOSED 狀態(tài)祸轮,服務(wù)端收到 ACK 報文之后,就處于關(guān)閉連接了侥钳,處于 CLOSED 狀態(tài)适袜。
    即客戶端收到服務(wù)端的連接釋放報文段后,對此發(fā)出確認(rèn)報文段(ACK=1舷夺,seq=u+1痪蝇,ack=w+1),客戶端進(jìn)入TIME_WAIT(時間等待)狀態(tài)冕房。此時TCP未釋放掉,需要經(jīng)過時間等待計時器設(shè)置的時間2MSL后趁矾,客戶端才進(jìn)入CLOSED狀態(tài)耙册。

收到一個FIN只意味著在這一方向上沒有數(shù)據(jù)流動。客戶端執(zhí)行主動關(guān)閉并進(jìn)入TIME_WAIT是正常的毫捣,服務(wù)端通常執(zhí)行被動關(guān)閉详拙,不會進(jìn)入TIME_WAIT狀態(tài)。

在socket編程中蔓同,任何一方執(zhí)行close()操作即可產(chǎn)生揮手操作饶辙。


image.png

2.1 揮手為什么需要四次?

因為當(dāng)服務(wù)端收到客戶端的SYN連接請求報文后斑粱,可以直接發(fā)送SYN+ACK報文弃揽。其中ACK報文是用來應(yīng)答的,SYN報文是用來同步的则北。但是關(guān)閉連接時矿微,當(dāng)服務(wù)端收到FIN報文時,很可能并不會立即關(guān)閉SOCKET尚揣,所以只能先回復(fù)一個ACK報文涌矢,告訴客戶端,"你發(fā)的FIN報文我收到了"快骗。只有等到我服務(wù)端所有的報文都發(fā)送完了娜庇,我才能發(fā)送FIN報文塔次,因此不能一起發(fā)送。故需要四次揮手名秀。

2.2 2MSL等待狀態(tài)

TIME_WAIT狀態(tài)也成為2MSL等待狀態(tài)励负。每個具體TCP實現(xiàn)必須選擇一個報文段最大生存時間MSL(Maximum Segment Lifetime),它是任何報文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長時間泰偿。這個時間是有限的熄守,因為TCP報文段以IP數(shù)據(jù)報在網(wǎng)絡(luò)內(nèi)傳輸,而IP數(shù)據(jù)報則有限制其生存時間的TTL字段耗跛。

對一個具體實現(xiàn)所給定的MSL值裕照,處理的原則是:當(dāng)TCP執(zhí)行一個主動關(guān)閉,并發(fā)回最后一個ACK调塌,該連接必須在TIME_WAIT狀態(tài)停留的時間為2倍的MSL晋南。這樣可讓TCP再次發(fā)送最后的ACK以防這個ACK丟失(另一端超時并重發(fā)最后的FIN)。

這種2MSL等待的另一個結(jié)果是這個TCP連接在2MSL等待期間羔砾,定義這個連接的插口(客戶的IP地址和端口號负间,服務(wù)器的IP地址和端口號)不能再被使用。這個連接只能在2MSL結(jié)束后才能再被使用姜凄。

2.3 四次揮手釋放連接時政溃,等待2MSL的意義?

MSL是Maximum Segment Lifetime的英文縮寫,可譯為“最長報文段壽命”态秧,它是任何報文在網(wǎng)絡(luò)上存在的最長時間董虱,超過這個時間報文將被丟棄。

為了保證客戶端發(fā)送的最后一個ACK報文段能夠到達(dá)服務(wù)器申鱼。因為這個ACK有可能丟失愤诱,從而導(dǎo)致處在LAST-ACK狀態(tài)的服務(wù)器收不到對FIN-ACK的確認(rèn)報文。服務(wù)器會超時重傳這個FIN-ACK捐友,接著客戶端再重傳一次確認(rèn)淫半,重新啟動時間等待計時器。最后客戶端和服務(wù)器都能正常的關(guān)閉匣砖。假設(shè)客戶端不等待2MSL科吭,而是在發(fā)送完ACK之后直接釋放關(guān)閉,一但這個ACK丟失的話猴鲫,服務(wù)器就無法正常的進(jìn)入關(guān)閉連接狀態(tài)砌溺。

兩個理由:

  1. 保證客戶端發(fā)送的最后一個ACK報文段能夠到達(dá)服務(wù)端。
    這個ACK報文段有可能丟失变隔,使得處于LAST-ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報文段的確認(rèn)规伐,服務(wù)端超時重傳FIN+ACK報文段,而客戶端能在2MSL時間內(nèi)收到這個重傳的FIN+ACK報文段匣缘,接著客戶端重傳一次確認(rèn)猖闪,重新啟動2MSL計時器鲜棠,最后客戶端和服務(wù)端都進(jìn)入到CLOSED狀態(tài),若客戶端在TIME-WAIT狀態(tài)不等待一段時間培慌,而是發(fā)送完ACK報文段后立即釋放連接豁陆,則無法收到服務(wù)端重傳的FIN+ACK報文段,所以不會再發(fā)送一次確認(rèn)報文段吵护,則服務(wù)端無法正常進(jìn)入到CLOSED狀態(tài)盒音。
  2. 防止“已失效的連接請求報文段”出現(xiàn)在本連接中。
    客戶端在發(fā)送完最后一個ACK報文段后馅而,再經(jīng)過2MSL祥诽,就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失,使下一個新的連接中不會出現(xiàn)這種舊的連接請求報文段瓮恭。

2.4 為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL才能返回到CLOSE狀態(tài)雄坪?

理論上,四個報文都發(fā)送完畢屯蹦,就可以直接進(jìn)入CLOSE狀態(tài)了维哈,但是可能網(wǎng)絡(luò)是不可靠的,有可能最后一個ACK丟失登澜。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文阔挠。

3. 總結(jié)

《TCP/IP詳解 卷1:協(xié)議》有一張TCP狀態(tài)變遷圖,很具有代表性脑蠕,有助于大家理解三次握手和四次揮手的狀態(tài)變化谒亦。如下圖所示,粗的實線箭頭表示正常的客戶端狀態(tài)變遷空郊,粗的虛線箭頭表示正常的服務(wù)器狀態(tài)變遷。

TCP狀態(tài)變遷圖.jpg

以后面試官再問你三次握手和四次揮手切揭,直接把這一篇文章丟給他就可以了狞甚,他想問的都在這里。

參考:《TCP/IP詳解 卷1:協(xié)議》

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末廓旬,一起剝皮案震驚了整個濱河市哼审,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌孕豹,老刑警劉巖涩盾,帶你破解...
    沈念sama閱讀 212,080評論 6 493
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異励背,居然都是意外死亡春霍,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,422評論 3 385
  • 文/潘曉璐 我一進(jìn)店門叶眉,熙熙樓的掌柜王于貴愁眉苦臉地迎上來址儒,“玉大人芹枷,你說我怎么就攤上這事×ぃ” “怎么了鸳慈?”我有些...
    開封第一講書人閱讀 157,630評論 0 348
  • 文/不壞的土叔 我叫張陵,是天一觀的道長喧伞。 經(jīng)常有香客問我走芋,道長,這世上最難降的妖魔是什么潘鲫? 我笑而不...
    開封第一講書人閱讀 56,554評論 1 284
  • 正文 為了忘掉前任翁逞,我火速辦了婚禮,結(jié)果婚禮上次舌,老公的妹妹穿的比我還像新娘熄攘。我一直安慰自己,他們只是感情好彼念,可當(dāng)我...
    茶點故事閱讀 65,662評論 6 386
  • 文/花漫 我一把揭開白布挪圾。 她就那樣靜靜地躺著,像睡著了一般逐沙。 火紅的嫁衣襯著肌膚如雪哲思。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,856評論 1 290
  • 那天吩案,我揣著相機(jī)與錄音棚赔,去河邊找鬼。 笑死徘郭,一個胖子當(dāng)著我的面吹牛靠益,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播残揉,決...
    沈念sama閱讀 39,014評論 3 408
  • 文/蒼蘭香墨 我猛地睜開眼胧后,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了抱环?” 一聲冷哼從身側(cè)響起壳快,我...
    開封第一講書人閱讀 37,752評論 0 268
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎镇草,沒想到半個月后眶痰,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,212評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡梯啤,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,541評論 2 327
  • 正文 我和宋清朗相戀三年竖伯,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,687評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡黔夭,死狀恐怖宏胯,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情本姥,我是刑警寧澤肩袍,帶...
    沈念sama閱讀 34,347評論 4 331
  • 正文 年R本政府宣布,位于F島的核電站婚惫,受9級特大地震影響氛赐,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜先舷,卻給世界環(huán)境...
    茶點故事閱讀 39,973評論 3 315
  • 文/蒙蒙 一艰管、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧蒋川,春花似錦牲芋、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,777評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至氮兵,卻和暖如春裂逐,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背泣栈。 一陣腳步聲響...
    開封第一講書人閱讀 32,006評論 1 266
  • 我被黑心中介騙來泰國打工卜高, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人南片。 一個月前我還...
    沈念sama閱讀 46,406評論 2 360
  • 正文 我出身青樓掺涛,卻偏偏與公主長得像,于是被迫代替她去往敵國和親疼进。 傳聞我的和親對象是個殘疾皇子薪缆,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,576評論 2 349

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