計(jì)算機(jī)網(wǎng)絡(luò)

OSI 7層模型

  • 物理層
  • 數(shù)據(jù)鏈路層
  • 網(wǎng)絡(luò)層
  • 傳輸層
  • 會話層
  • 表示層
  • 應(yīng)用層

TCP/IP協(xié)議 4層模型

  • 應(yīng)用層
  • 傳輸層
  • 網(wǎng)絡(luò)層
  • 網(wǎng)絡(luò)接口層
TCP/IP協(xié)議

UDP（用戶數(shù)據(jù)報(bào)協(xié)議）詳解

  • UDP是面向報(bào)文的，沒有可靠性控制，沒有擁塞控制，無連接，所以其開銷小，但網(wǎng)絡(luò)環(huán)境差或者發(fā)送數(shù)據(jù)過大時導(dǎo)致ip分片過多，導(dǎo)致發(fā)送率降低，影響程序的使用。
  • UDP支持一對一、一對多、多對多、多對一通信

  • UDP首部開銷小，只有8字節(jié)(64bit）


    UDP

TCP（傳輸控制協(xié)議）詳解

  • TCP是面向連接的：通信前需要建立連接，結(jié)束要釋放連接
  • TCP是可靠的： TCP發(fā)送的數(shù)據(jù)無重復(fù)，無丟失，無錯誤，與發(fā)送端一致
  • TCP是面向字節(jié)流的：TCP以字節(jié)為單位，傳輸過程中會被劃分為一個個數(shù)據(jù)報(bào)， 但接收端最終接受的數(shù)據(jù)與發(fā)送端一樣
  • TCP提供全雙工通信：TCP的兩端既可以作為發(fā)送端，也可以作為接收端
  • TCP只支持一對一通信
TCP
  • TCP頭部有20字節(jié)（20*8bit）
    • 源端口 和 目的端口 :傳輸層和網(wǎng)絡(luò)層一大重要區(qū)別就是傳輸層指定了數(shù)據(jù)報(bào)發(fā)往的應(yīng)用進(jìn)程，因此需要端口號標(biāo)識
    • 序號：當(dāng)前TCP數(shù)據(jù)報(bào)數(shù)據(jù)部分的第一個字節(jié)的序號，當(dāng)前字節(jié)在總字節(jié)的偏移量，可以給[0,2^{32}-1]個字節(jié)進(jìn)行編號（大約4G），而且序號循環(huán)使用，當(dāng)發(fā)送完2^{32}-1個字節(jié)后，序號又從0開始。
    • 確認(rèn)號：表示當(dāng)前主機(jī)作為接收端時，期望接收的下一個字節(jié)的編號是多少,也表示，當(dāng)前主機(jī)已經(jīng)正確接收的最后一個字節(jié)序號+1
    • 4位首部長度：表明了數(shù)據(jù)報(bào)頭部的長度
    • 保留字段（6位）
    • 標(biāo)識符 （6位）
      • URG:當(dāng)URG字段被置1，表示本數(shù)據(jù)報(bào)的數(shù)據(jù)部分包含緊急信息，此時緊急指針有效。緊急數(shù)據(jù)一定位于當(dāng)前數(shù)據(jù)包數(shù)據(jù)部分的最前面，緊急指針標(biāo)明了緊急數(shù)據(jù)的尾部。
        如control+c：這個命令要求操作系統(tǒng)立即停止當(dāng)前進(jìn)程。此時，這條命令就會存放在數(shù)據(jù)包數(shù)據(jù)部分的開頭，并由緊急指針標(biāo)識命令的位置，并URG字段被置1
      • ACK:ACK被置1后確認(rèn)號字段才有效,TCP規(guī)定，在連接建立后傳送的所有報(bào)文段都必須把ACK置1
      • PSH:當(dāng)接收方收到PSH=1的報(bào)文后，會立即將數(shù)據(jù)交付給應(yīng)用程序，而不會等到緩沖區(qū)滿后再提交
      • RST:當(dāng)該值為1時，表示當(dāng)前TCP連接出現(xiàn)嚴(yán)重問題，必須要釋放重連
      • SYN:當(dāng)SYN=1，ACK=0時，表示當(dāng)前報(bào)文段是一個連接請求報(bào)文;當(dāng)SYN=1，ACK=1時，表示當(dāng)前報(bào)文段是一個同意建立連接的應(yīng)答報(bào)文
      • FIN:FIN=1表示此報(bào)文段是一個釋放連接的請求報(bào)文
    • 窗口大小(16bit)：用于實(shí)現(xiàn)TCP的流量控制； 當(dāng)前 接收方的接收窗口的剩余容量，發(fā)送方收到該值后會將發(fā)送窗口調(diào)整成該值的大小。發(fā)送窗口的大小又決定了發(fā)送速率，所以接收方通過設(shè)置該值就可以控制發(fā)送放的發(fā)送速率 。 發(fā)送方每收到一個數(shù)據(jù)報(bào)都要調(diào)整當(dāng)前的發(fā)送窗口。
    • 校驗(yàn)和（16bit）:用于接收端檢驗(yàn)整個數(shù)據(jù)包在傳輸過程中是否出錯
    • 緊急指針（16bit）:用于標(biāo)識緊急數(shù)據(jù)的尾部
    • 選項(xiàng)字段 :上述字段都是每個TCP頭部必須要有的，而選項(xiàng)字段是可選的，且長度可變，最長40字節(jié)。最常用的選項(xiàng)字段為MMS：最大報(bào)文長度

TCP三次握手

三次握手

第一次握手

客戶端向服務(wù)端發(fā)送連接請求報(bào)文段。該報(bào)文段的頭部中SYN=1，ACK=0，seq=x。請求發(fā)送后，客戶端便進(jìn)入SYN-SENT狀態(tài)。

  • SYN=1，ACK=0表示該報(bào)文段為連接請求報(bào)文。
  • x為本次TCP通信的字節(jié)流的初始序號
    TCP規(guī)定：SYN=1的報(bào)文段不能有數(shù)據(jù)部分，但要消耗掉一個序號

第二次握手

服務(wù)端收到連接請求報(bào)文段后，如果同意連接，則會發(fā)送一個應(yīng)答：SYN=1，ACK=1，seq=y，ack=x+1。
該應(yīng)答發(fā)送完成后便進(jìn)入SYN-RCVD狀態(tài)

  • SYN=1，ACK=1表示該報(bào)文段為連接同意的應(yīng)答報(bào)文
  • seq=y表示服務(wù)端作為發(fā)送者時，發(fā)送字節(jié)流的初始序號
  • ack=x+1表示服務(wù)端希望下一個數(shù)據(jù)報(bào)發(fā)送序號從x+1開始的字節(jié)

第三次握手

當(dāng)客戶端收到連接同意的應(yīng)答后，還要向服務(wù)端發(fā)送一個確認(rèn)報(bào)文段，表示：服務(wù)端發(fā)來的連接同意應(yīng)答已經(jīng)成功收到。
該報(bào)文段的頭部為：ACK=1，seq=x+1，ack=y+1。
客戶端發(fā)完這個報(bào)文段后便進(jìn)入ESTABLISHED狀態(tài)，服務(wù)端收到這個應(yīng)答后也進(jìn)入ESTABLISHED狀態(tài)，此時連接的建立完成！

為什么連接建立需要三次握手，而不是兩次握手？

防止失效的連接請求報(bào)文段被服務(wù)端接收，從而產(chǎn)生錯誤

若建立連接只需兩次握手，客戶端并沒有太大的變化，仍然需要獲得服務(wù)端的應(yīng)答后才進(jìn)入ESTABLISHED狀態(tài)，而服務(wù)端在收到連接請求后就進(jìn)入ESTABLISHED狀態(tài)。此時如果網(wǎng)絡(luò)擁塞，客戶端發(fā)送的連接請求遲遲到不了服務(wù)端，客戶端便超時重發(fā)請求，如果服務(wù)端正確接收并確認(rèn)應(yīng)答，雙方便開始通信，通信結(jié)束后釋放連接。此時，如果那個失效的連接請求抵達(dá)了服務(wù)端，由于只有兩次握手，服務(wù)端收到請求就會進(jìn)入ESTABLISHED狀態(tài)，等待發(fā)送數(shù)據(jù)或主動發(fā)送數(shù)據(jù)。但此時的客戶端早已進(jìn)入CLOSED狀態(tài)，服務(wù)端將會一直等待下去，這樣浪費(fèi)服務(wù)端連接資源

TCP四次揮手

四次揮手

TCP連接是雙向的，因此在四次揮手中，前兩次揮手用于斷開一個方向的連接，后兩次揮手用于斷開另一方向的連接。

第一次揮手

若A認(rèn)為數(shù)據(jù)發(fā)送完成，則它需要向B發(fā)送連接釋放請求。該請求只有報(bào)文頭，頭中攜帶的主要參數(shù)為：
FIN=1，seq=u。此時，A將進(jìn)入FIN-WAIT-1狀態(tài)

  • FIN=1表示該報(bào)文段是一個連接釋放請求
  • seq=u，u-1是A向B發(fā)送的最后一個字節(jié)的序號

第二次揮手

B收到連接釋放請求后，會通知相應(yīng)的應(yīng)用程序，告訴它A向B這個方向的連接已經(jīng)釋放。此時B進(jìn)入CLOSE-WAIT狀態(tài)，并向A發(fā)送連接釋放的應(yīng)答，其報(bào)文頭包含：
ACK=1，seq=v，ack=u+1。

  • ACK=1除TCP連接請求報(bào)文段以外，TCP通信過程中所有數(shù)據(jù)報(bào)的ACK都為1，表示應(yīng)答。
  • seq=v：v-1是B向A發(fā)送的最后一個字節(jié)的序號
  • ack=u+1表示希望收到從第u+1個字節(jié)開始的報(bào)文段，并且已經(jīng)成功接收了前u個字節(jié)

A收到該應(yīng)答，進(jìn)入FIN-WAIT-2狀態(tài)，等待B發(fā)送連接釋放請求
第二次揮手完成后，A到B方向的連接已經(jīng)釋放，B不會再接收數(shù)據(jù)，A也不會再發(fā)送數(shù)據(jù)。但B到A方向的連接仍然存在，B可以繼續(xù)向A發(fā)送數(shù)據(jù)。

第三次揮手

當(dāng)B向A發(fā)完所有數(shù)據(jù)后，向A發(fā)送連接釋放請求，請求頭：FIN=1，ACK=1，seq=w，ack=u+1。B便進(jìn)入LAST-ACK狀態(tài)

第四次揮手

A收到釋放請求后，向B發(fā)送確認(rèn)應(yīng)答，此時A進(jìn)入TIME-WAIT狀態(tài)。該狀態(tài)會持續(xù)2MSL時間，若該時間段內(nèi)沒有B的重發(fā)請求的話，就進(jìn)入CLOSED狀態(tài)，撤銷TCB。當(dāng)B收到確認(rèn)應(yīng)答后，也便進(jìn)入CLOSED狀態(tài)，撤銷TCB。

為什么A要先進(jìn)入TIME-WAIT狀態(tài)，等待2MSL時間后才進(jìn)入CLOSED狀態(tài)？

為了保證B能收到A的確認(rèn)應(yīng)答。
若A發(fā)完確認(rèn)應(yīng)答后直接進(jìn)入CLOSED狀態(tài)，那么如果該應(yīng)答丟失，B等待超時后就會重新發(fā)送連接釋放請求，但此時A已經(jīng)關(guān)閉了，不會作出任何響應(yīng)，因此B永遠(yuǎn)無法正常關(guān)閉。

TCP可靠傳輸實(shí)現(xiàn)

  • 流量控制、擁塞控制、連續(xù)ARQ等技術(shù)來保證它的可靠性

停止等待協(xié)議（ARQ協(xié)議）

ARQ(Automatic Repeat reQuest)自動重傳請求。
顧名思義，當(dāng)請求失敗時它會自動重傳，直到請求被正確接收為止。這種機(jī)制保證了每個分組都能被正確接收。停止等待協(xié)議是一種ARQ協(xié)議。

停止等待協(xié)議的原理
  • 無差錯的情況
    A向B每發(fā)送一個分組，都要停止發(fā)送，等待B的確認(rèn)應(yīng)答；A只有收到了B的確認(rèn)應(yīng)答后才能發(fā)送下一個分組。
  • 分組丟失和出現(xiàn)差錯的情況
    發(fā)送者擁有超時計(jì)時器。每發(fā)送一個分組便會啟動超時計(jì)時器，等待B的應(yīng)答。若超時仍未收到應(yīng)答，則A會重發(fā)剛才的分組。
    • 分組出現(xiàn)差錯：若B收到分組，但通過檢查和字段發(fā)現(xiàn)分組在運(yùn)輸途中出現(xiàn)差錯，它會直接丟棄該分組，并且不會有任何其他動作。A超時后便會重新發(fā)送該分組，直到B正確接收為止。
    • 分組丟失：若分組在途中丟失，B并沒有收到分組，因此也不會有任何響應(yīng)。當(dāng)A超時后也會重傳分組，直到正確接收該分組的應(yīng)答為止。
      綜上所述：當(dāng)分組丟失 或 出現(xiàn)差錯 的情況下，A都會超時重傳分組。
  • 應(yīng)答丟失 和 應(yīng)答遲到 的情況
    TCP會給每個字節(jié)都打上序號，用于判斷該分組是否已經(jīng)接收。
    • 應(yīng)答丟失：若B正確收到分組，并已經(jīng)返回應(yīng)答，但應(yīng)答在返回途中丟失了。此時A也收不到應(yīng)答，從而超時重傳。緊接著B又收到了該分組。接收者根據(jù)序號來判斷當(dāng)前收到的分組是否已經(jīng)接收，若已接收則直接丟棄，并補(bǔ)上一個確認(rèn)應(yīng)答。
    • 應(yīng)答遲到：若由于網(wǎng)絡(luò)擁塞，A遲遲收不到B發(fā)送的應(yīng)答，因此會超時重傳。B收到該分組后，發(fā)現(xiàn)已經(jīng)接收，便丟棄該分組，并向A補(bǔ)上確認(rèn)應(yīng)答。A收到應(yīng)答后便繼續(xù)發(fā)送下一個分組。但經(jīng)過了很長時間后，那個失效的應(yīng)答最終抵達(dá)了A，此時A可根據(jù)序號判斷該分組已經(jīng)接收，此時只需簡單丟棄即可。

滑動窗口協(xié)議（連續(xù)ARQ協(xié)議）

連續(xù)ARQ協(xié)議

在ARQ協(xié)議發(fā)送者每次只能發(fā)送一個分組，在應(yīng)答到來前必須等待。而連續(xù)ARQ協(xié)議的發(fā)送者擁有一個發(fā)送窗口，發(fā)送者可以在沒有得到應(yīng)答的情況下連續(xù)發(fā)送窗口中的分組。這樣降低了等待時間，提高了傳輸效率

累計(jì)確認(rèn)

在連續(xù)ARQ協(xié)議中，接收者也有個接收窗口，接收者并不需要每收到一個分組就返回一個應(yīng)答，可以連續(xù)收到分組之后統(tǒng)一返回一個應(yīng)答。這樣能節(jié)省流量。
TCP頭部的ack字段就是用來累計(jì)確認(rèn)，它表示已經(jīng)確認(rèn)的字節(jié)序號+1，也表示期望發(fā)送者發(fā)送的下一個分組的起始字節(jié)號。

發(fā)送窗口

發(fā)送窗口的大小由接收窗口的剩余大小決定。接收者會把當(dāng)前接收窗口的剩余大小寫入應(yīng)答TCP報(bào)文段的頭部，發(fā)送者收到應(yīng)答后根據(jù)該值和當(dāng)前網(wǎng)絡(luò)擁塞情況設(shè)置發(fā)送窗口的大小。發(fā)送窗口的大小是不斷變化的。
發(fā)送窗口由三個指針構(gòu)成：

  • p1指向發(fā)送窗口的后沿，它后面的字節(jié)表示已經(jīng)發(fā)送且已收到應(yīng)答
  • p2指向尚未發(fā)送的第一個字節(jié)。
    p1-p2間的字節(jié)表示已經(jīng)發(fā)送，但還沒收到確認(rèn)應(yīng)答。這部分的字節(jié)仍需保留，因?yàn)榭赡苓€要超時重發(fā)。

  • p3指向發(fā)送窗口的前沿，它前面的字節(jié)尚未發(fā)送，且不允許發(fā)送
    p2-p3間的字節(jié)表示可以發(fā)送，但還沒有發(fā)送的字節(jié)


    發(fā)送窗口
接收窗口

接收者收到的字節(jié)會存入接收窗口，接收者會對已經(jīng)正確接收的有序字節(jié)進(jìn)行累計(jì)確認(rèn)，發(fā)送完確認(rèn)應(yīng)答后，接收窗口就可以向前移動指定字節(jié)。
如果某些字節(jié)并未按序收到，接收者只會確認(rèn)最后一個有序的字節(jié)，從而亂序的字節(jié)就會被重新發(fā)送。


接收窗口

流量控制

如果發(fā)送者發(fā)送過快，接收者來不及接收，那么就會有分組丟失。為了避免分組丟失，控制發(fā)送者的發(fā)送速度，使得接收者來得及接收，這就是流量控制

  • 流量控制根本目的是防止分組丟失，它是構(gòu)成TCP可靠性的一方面
  • 滑動窗口協(xié)議既保證了分組無差錯、有序接收，也實(shí)現(xiàn)了流量控制
流量控制引發(fā)的死鎖

當(dāng)發(fā)送者收到了一個窗口為0的應(yīng)答，發(fā)送者便停止發(fā)送，等待接收者的下一個應(yīng)答。但是如果這個窗口不為0的應(yīng)答在傳輸過程丟失，發(fā)送者一直等待下去，而接收者以為發(fā)送者已經(jīng)收到該應(yīng)答，等待接收新數(shù)據(jù)，這樣雙方就相互等待，從而產(chǎn)生死鎖。

持續(xù)計(jì)時器

為了避免流量控制引發(fā)的死鎖，TCP使用了持續(xù)計(jì)時器。每當(dāng)發(fā)送者收到一個零窗口的應(yīng)答后就啟動該計(jì)時器。時間一到便主動發(fā)送報(bào)文詢問接收者的窗口大小。若接收者仍然返回零窗口，則重置該計(jì)時器繼續(xù)等待；若窗口不為0，則表示應(yīng)答報(bào)文丟失了，此時重置發(fā)送窗口后開始發(fā)送，這樣就避免了死鎖的產(chǎn)生。

擁塞控制

擁塞控制是作用于網(wǎng)絡(luò)的，它是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過大的情況

  • 緩解網(wǎng)絡(luò)壓力
  • 保證分組按時到達(dá)
慢開始算法 和 擁塞避免算法
  • 發(fā)送方維護(hù)一個發(fā)送窗口，發(fā)送窗口的大小取決于網(wǎng)絡(luò)的擁塞情況和接收窗口的大小，發(fā)送窗口是動態(tài)變化的。
  • 發(fā)送方還維護(hù)一個慢開始門限
    • 發(fā)送窗口 < 慢開始門限：使用慢開始算法
    • 發(fā)送窗口 > 慢開始門限：使用擁塞避免算法
    • 發(fā)送窗口 = 慢開始門限：使用慢開始算法或擁塞避免算法

算法的具體過程：

  • 通信開始時，發(fā)送方的發(fā)送窗口設(shè)為1，并發(fā)送第一個分組M1；
  • 接收方收到M1后，返回確認(rèn)應(yīng)答，此時發(fā)送方發(fā)送窗口擴(kuò)大兩倍，并發(fā)送M2、M3；（即，發(fā)送方每次收到確認(rèn)應(yīng)答后，都將發(fā)送窗口設(shè)為當(dāng)前值的兩倍）
  • 若發(fā)送窗口>慢開始門限，則使用擁塞避免算法，每次收到確認(rèn)應(yīng)答后都將發(fā)送窗口+1；
  • 若發(fā)送方出現(xiàn)了超時重傳，則表明網(wǎng)絡(luò)出現(xiàn)擁塞，此時：
    a）慢開始門限設(shè)為當(dāng)前發(fā)送窗口的一半；
    b）發(fā)送窗口設(shè)為1；
    c）啟用擁塞避免算法；
    注意：發(fā)送超時重傳時，發(fā)送窗口有可能已經(jīng)超過了慢開始門限，也有可能還沒超過；此時不管何種情況，都一律啟用擁塞避免算法，并執(zhí)行上述三步操作！

快速重傳 和 快速恢復(fù)算法

當(dāng)接收端收到了3個相同的ACK應(yīng)答，會啟動快速恢復(fù)算法

  • 把慢開始門限設(shè)為當(dāng)前發(fā)送窗口的一半
  • 把當(dāng)前發(fā)送窗口設(shè)為慢開始門限+3，重傳丟失的分組
  • 再次收到相同的ACK時，發(fā)送窗口大小+1
  • 當(dāng)收到新的ACK時，把當(dāng)前的發(fā)送窗口設(shè)為慢開始門限，啟用擁塞避免算法

HTTP和HTTPS

HTTP

HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議。它不涉及數(shù)據(jù)包（packet）傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口。

HTTP是一個無狀態(tài)的協(xié)議,無狀態(tài)是指客戶機(jī)Web瀏覽器和服務(wù)器之間不需要建立持久的連接，這意味著當(dāng)一個客戶端向服務(wù)器端發(fā)出請求，然后服務(wù)器返回響應(yīng)(response)，連接就被關(guān)閉了，在服務(wù)器端不保留連接的有關(guān)信息

客戶機(jī)發(fā)起一次請求的時候：

  • 客戶機(jī)會將請求封裝成http數(shù)據(jù)包-->封裝成Tcp數(shù)據(jù)包-->封裝成Ip數(shù)據(jù)包--->封裝成數(shù)據(jù)幀--->硬件將幀數(shù)據(jù)轉(zhuǎn)換成bit流（二進(jìn)制數(shù)據(jù)）-->最后通過物理硬件（網(wǎng)卡芯片）發(fā)送到指定地點(diǎn)。
  • 服務(wù)器硬件首先收到bit流....... 然后轉(zhuǎn)換成ip數(shù)據(jù)包。于是通過ip協(xié)議解析Ip數(shù)據(jù)包，然后又發(fā)現(xiàn)里面是tcp數(shù)據(jù)包，就通過tcp協(xié)議解析Tcp數(shù)據(jù)包，接著發(fā)現(xiàn)是http數(shù)據(jù)包通過http協(xié)議再解析http數(shù)據(jù)包得到數(shù)據(jù)

HTTPS

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL。其所用的端口號是443


https通信過程

過程大致如下：
1） SSL客戶端通過TCP和服務(wù)器建立連接之后（443端口），并且在一般的tcp連接協(xié)商（握手）過程中請求證書。
即客戶端發(fā)出一個消息給服務(wù)器，這個消息里面包含了自己可實(shí)現(xiàn)的算法列表和其它一些需要的消息，SSL的服務(wù)器端會回應(yīng)一個數(shù)據(jù)包，這里面確定了這次通信所需要的算法，然后服務(wù)器向客戶端返回證書。（證書里面包含了服務(wù)器信息：域名。申請證書的公司，公共秘鑰）。
2）Client在收到服務(wù)器返回的證書后，判斷簽發(fā)這個證書的公共簽發(fā)機(jī)構(gòu)，并使用這個機(jī)構(gòu)的公共秘鑰確認(rèn)簽名是否有效，客戶端還會確保證書中列出的域名就是它正在連接的域名。
3） 如果確認(rèn)證書有效，那么生成對稱秘鑰并使用服務(wù)器的公共秘鑰進(jìn)行加密。然后發(fā)送給服務(wù)器，服務(wù)器使用它的私鑰對它進(jìn)行解密，這樣兩臺計(jì)算機(jī)可以開始進(jìn)行對稱加密進(jìn)行通信。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 230,182評論 6贊 543
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,489評論 3贊 429
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
    開封第一講書人閱讀 178,290評論 0贊 383
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長。 經(jīng)常有香客問我，道長，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 63,776評論 1贊 317
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 72,510評論 6贊 412
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 55,866評論 1贊 328
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音，去河邊找鬼。 笑死，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,860評論 3贊 447
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 43,036評論 0贊 290
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 49,585評論 1贊 336
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,331評論 3贊 358
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,536評論 1贊 374
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 39,058評論 5贊 363
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,754評論 3贊 349
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,154評論 0贊 28
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,469評論 1贊 295
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個月前我還...
    沈念sama閱讀 52,273評論 3贊 399
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,505評論 2贊 379