計(jì)算機(jī)網(wǎng)絡(luò)協(xié)議及通信

互聯(lián)網(wǎng)協(xié)議族(IPS Internet Protocol Suite):是一個網(wǎng)絡(luò)通訊模型模型,以及一整個網(wǎng)絡(luò)傳輸協(xié)議家族,為互聯(lián)網(wǎng)的基礎(chǔ)通訊架構(gòu).通常被稱為TCP/IP協(xié)議族,簡稱TCP/IP

1.前言

前面的章節(jié)已經(jīng)了解了java的基礎(chǔ)知識,這個章節(jié)來學(xué)習(xí)網(wǎng)絡(luò)協(xié)議,在實(shí)際工作中是一個較為重要的知識點(diǎn).現(xiàn)在是一個數(shù)據(jù)共享的時代,數(shù)據(jù)的傳輸基礎(chǔ)的就是這些網(wǎng)絡(luò)協(xié)議

2.目錄

目錄

3.計(jì)算機(jī)網(wǎng)絡(luò)協(xié)議及通信

3.1.OSI參考模型

簡易模型

OSI(open system interconnect):即開放式系統(tǒng)互聯(lián),一般都叫做OSI參考模型

  • 物理層:最底層,包括多種與物理介質(zhì)相關(guān)的協(xié)議,用于支撐TCP/IP通道,這一層主要傳送比特流
  • 數(shù)據(jù)鏈路層:包括物理層的協(xié)議,接受來自物理層的位流形式數(shù)據(jù),封裝成幀,傳送數(shù)據(jù)幀至上一層;同樣也接受上層的數(shù)據(jù)幀,拆裝為位流形式數(shù)據(jù)轉(zhuǎn)發(fā)到物理層
  • 網(wǎng)絡(luò)層:將數(shù)據(jù)幀組成數(shù)據(jù)包,負(fù)責(zé)IP地址的編碼和尋址,建立結(jié)點(diǎn)之間連接,是通信子網(wǎng)的最高層,數(shù)據(jù)鏈路層負(fù)責(zé)通信同一子網(wǎng)的,網(wǎng)絡(luò)層則負(fù)責(zé)通訊不同子網(wǎng)的,傳送數(shù)據(jù)包
  • 傳輸層:向用戶提供可靠的端到端的差錯和流量控制,保證報文的正確傳輸.提供會話層和網(wǎng)絡(luò)層之間的傳輸服務(wù),獲取到會話層數(shù)據(jù),必要時,對數(shù)據(jù)進(jìn)行分割,確保數(shù)據(jù)正確無誤地傳送到網(wǎng)絡(luò)層
  • 會話層:應(yīng)用程序和網(wǎng)絡(luò)之間的接口,提供包括訪問驗(yàn)證和會話管理在內(nèi)的建立和維護(hù)應(yīng)用之間通信機(jī)制
  • 表示層:解決語法表示問題,將數(shù)據(jù)語言編碼轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)語言,為了減少數(shù)據(jù)傳輸量,進(jìn)行數(shù)據(jù)的壓縮和解壓縮,為了安全提供加密和解密
  • 應(yīng)用層:計(jì)算機(jī)用戶及應(yīng)用程序和網(wǎng)絡(luò)之間的接口,面向用戶提供服務(wù),負(fù)責(zé)完成網(wǎng)絡(luò)中應(yīng)用程序與網(wǎng)絡(luò)操作系統(tǒng)之間的聯(lián)系,建立與結(jié)束使用者之間的聯(lián)系,并完成網(wǎng)絡(luò)用戶提出的各種網(wǎng)絡(luò)服務(wù)及應(yīng)用所需的監(jiān)督,管理和服務(wù)等各種協(xié)議.簡單來講就是將用戶提供的抽象語言進(jìn)行編碼的轉(zhuǎn)化,為表示層做準(zhǔn)備

3.2TCP/IP協(xié)議族

  • 鏈路層:對電信號進(jìn)行分組并形成具有特殊意義的數(shù)據(jù)幀,然后以廣播的形式通過物理介質(zhì)發(fā)送給接收方

以太網(wǎng)協(xié)議:標(biāo)識好每一組電信號的信息特征,分組順序發(fā)送,一組電信號就是一個數(shù)據(jù)包,一個數(shù)據(jù)包被稱為一幀
數(shù)據(jù)通信:接入網(wǎng)絡(luò)的設(shè)備都需安裝網(wǎng)絡(luò)適配器(網(wǎng)卡),網(wǎng)卡的地址(MAC地址(只與廠商有關(guān),與所處網(wǎng)絡(luò)無關(guān)))就是數(shù)據(jù)包的發(fā)送地址和接收地址,以太網(wǎng)采用廣播的形式,把數(shù)據(jù)包發(fā)送給子網(wǎng)內(nèi)所有主機(jī),每臺主機(jī)會對比目標(biāo)MAC地址來進(jìn)行處理

  • 網(wǎng)絡(luò)層:定義網(wǎng)絡(luò)地址,區(qū)分網(wǎng)段,子網(wǎng)內(nèi)MAC尋址,對于不同子網(wǎng)的數(shù)據(jù)包進(jìn)行路由
  • IP協(xié)議:無法通過mac區(qū)分兩臺主機(jī)區(qū)分兩臺主機(jī)是否同屬一個網(wǎng)絡(luò),引入IP協(xié)議,制訂一套新地址,區(qū)分兩臺主機(jī)是否同屬一個網(wǎng)絡(luò),這套地址就是網(wǎng)絡(luò)地址,即IP地址;IP地址包含IPV4和IPV6,IPV4是一個32位的地址,采用4位的十進(jìn)制數(shù)字表示,IP協(xié)議將這個32位的地址分為兩部分,以192.168.24.1,其中前24位就是網(wǎng)絡(luò)地址,后8位就是主機(jī)地址,若兩個IP地址在同一子網(wǎng)內(nèi),則網(wǎng)絡(luò)地址一定相同,IP協(xié)議還引入子網(wǎng)掩碼,IP地址和子網(wǎng)掩碼按位與運(yùn)算后可得網(wǎng)絡(luò)地址
  • ARP協(xié)議(地址解析協(xié)議):根據(jù)IP地址獲取MAC地址,數(shù)據(jù)包包含目標(biāo)主機(jī)的IP地址,主機(jī)接收到會對比IP地址,如果相同就返回自己的MAC地址,不同則丟棄;ARP會將返回MAC地址與對應(yīng)IP地址存入本機(jī)ARP緩存中并保留一定時間,下次直接查詢ARP緩存節(jié)約資源
  • 路由協(xié)議:首先通過IP協(xié)議來判斷兩臺主機(jī)是否在同一個子網(wǎng)中,若在,就通過ARP協(xié)議查詢對應(yīng)的MAC地址,若不在,以太網(wǎng)會將數(shù)據(jù)包轉(zhuǎn)發(fā)給本子網(wǎng)的網(wǎng)關(guān)進(jìn)行路由,網(wǎng)關(guān)是互聯(lián)網(wǎng)子網(wǎng)與子網(wǎng)之間的橋梁,會進(jìn)行多次轉(zhuǎn)發(fā),最終將數(shù)據(jù)包轉(zhuǎn)發(fā)到目標(biāo)IP的子網(wǎng)中,然后再通過ARP獲取目標(biāo)MAC,最終也是通過廣播形式將數(shù)據(jù)包發(fā)送給接收方
  • 傳輸層:定義端口,標(biāo)識應(yīng)用程序身份,實(shí)現(xiàn)端口到端口的通信,TCP協(xié)議可以保證數(shù)據(jù)傳輸?shù)目煽啃?/li>
  • 數(shù)據(jù)通信:由于數(shù)據(jù)包到達(dá)主機(jī)后,無法確定那個應(yīng)用程序要接受這個包,因此傳輸層引入UDP協(xié)議,定義端口號,給每個應(yīng)用程序標(biāo)識身份,每個主機(jī)上的應(yīng)用程序需指定唯一端口號;
  • UDP/TCP協(xié)議:UDP協(xié)議(用戶數(shù)據(jù)報協(xié)議)比較簡單,沒有確認(rèn)機(jī)制,無法知道對方是否接受,可靠性較差.為了提高網(wǎng)絡(luò)可靠性,TCP協(xié)議就誕生了,TCP協(xié)議即傳輸控制協(xié)議,是一種面向連接的,可靠的,基于字節(jié)流的通信協(xié)議.TCP協(xié)議在UDP基礎(chǔ)上建立了三次握手四次揮手的確認(rèn)機(jī)制,是一個可靠的連接,消耗連接資源多,傳輸速度慢,而UDP是面向非連接的協(xié)議,容易丟包,效率較高
  • 應(yīng)用層:定義數(shù)據(jù)格式并按照對應(yīng)的格式解讀數(shù)據(jù)
    DNS協(xié)議過程
  • DNS協(xié)議:域名解析協(xié)議,將域名(www.baidu.com)解析成對應(yīng)的IP地址,首先本機(jī)計(jì)算機(jī)會將域名發(fā)送到解析域名的服務(wù)器上,服務(wù)器上有很多能解析各種域名的服務(wù)器,找到其中的一臺,沒有找到就會去查找根域名服務(wù)器,根服務(wù)器讓其其去對應(yīng)的子服務(wù)器查找,子服務(wù)器找到返回給計(jì)算機(jī),并將緩存到第一次查找的服務(wù)器,之后訪問該域名通過緩存查找
  • http協(xié)議:超文本傳輸協(xié)議,是客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn),客戶端叫做用戶代理(user agent),存儲著資源的應(yīng)答服務(wù)器為源服務(wù)器(origin server),在用戶代理和源服務(wù)器中間可能存在多個中間層.如,代理,網(wǎng)關(guān).事實(shí)上http并沒有規(guī)定使用(或者基于)TCP/IP協(xié)議,可以使用任何其它互聯(lián)網(wǎng)協(xié)議.通過URI(統(tǒng)一資源標(biāo)識符)來標(biāo)識請求資源 (無連接,無狀態(tài),靈活:傳輸任意類型數(shù)據(jù))
計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分層

3.3.TCP的三次握手和四次揮手

TCP三次握手

三次握手過程:

  • 第一次握手:建立連接,客戶端發(fā)送連接請求報文段,把標(biāo)有SYN的數(shù)據(jù)包發(fā)給服務(wù)器端
  • 第二次握手:服務(wù)器端接收到客戶端的SYN的報文段,同時發(fā)送標(biāo)有SYN/ACK的數(shù)據(jù)包
  • 第三次握手:客戶端收到服務(wù)端的SYN/ACK的數(shù)據(jù)包,向服務(wù)器發(fā)送標(biāo)有ACK的數(shù)據(jù)包

三次握手的原因:
主要驗(yàn)證的是客戶端和服務(wù)端的接受和發(fā)送能力都是沒有問題的

  • 第一次握手:服務(wù)端知道客戶端的發(fā)送能力和服務(wù)端的接受能力沒有問題
  • 第二次握手:客戶端知道客戶端和服務(wù)端的發(fā)送和接受沒問題,但服務(wù)端不知道服務(wù)端的發(fā)送能力有沒有問題
  • 第三次握手:客戶端和服務(wù)端都知道發(fā)送和接受能力都沒問題
TCP四次揮手

四次揮手過程:

  • 第一次揮手:客戶端設(shè)置seq和ACK,向服務(wù)器發(fā)送一個FIN=1報文段,客戶端進(jìn)入FIN_WAIT狀態(tài),標(biāo)識客戶端沒有數(shù)據(jù)要發(fā)送給服務(wù)端
  • 第二次揮手:服務(wù)端收到了客戶端發(fā)送的FIN報文段,向客戶端回了一個ACK報文段
  • 第三次揮手:服務(wù)端向客戶端發(fā)送的FIN報文段,請求關(guān)閉連接,同時服務(wù)端進(jìn)入LAST_ACK狀態(tài)
  • 第四次揮手:客戶端收到服務(wù)端發(fā)送的FIN報文段后,向服務(wù)端發(fā)送ACK報文段,然后客戶端進(jìn)入TIME_WAIT狀態(tài).服務(wù)端收到客戶端的ACK報文段以后,就關(guān)閉連接.此時,客戶端等待2MSL(一個片段在網(wǎng)絡(luò)中最大的存活時間)后依然沒有收到回復(fù),則說明服務(wù)端已經(jīng)正常關(guān)閉,這樣客戶端就可以關(guān)閉連接了

四次揮手的原因:

  • 第一次揮手:客戶端發(fā)送第一次揮手后,就不能再向服務(wù)端發(fā)送數(shù)據(jù)了
  • 第二次揮手:服務(wù)端第一次響應(yīng)后,還可以繼續(xù)向客戶端發(fā)送數(shù)據(jù),這是是告訴客戶端,我收到了關(guān)閉請求
  • 第三次揮手:當(dāng)服務(wù)端數(shù)據(jù)響應(yīng)完成后,再通知客戶端,我這邊也可以關(guān)閉請求了,這時服務(wù)端就不能再向客戶端發(fā)送數(shù)據(jù)了
    第四次揮手:客戶端接收到確認(rèn)關(guān)閉報文,等待2MSL后沒有回復(fù),服務(wù)端已接收到,且正常關(guān)閉,客戶端也可以關(guān)閉連接了

MSL(MAXimum Segment Lifetime):任何報文在網(wǎng)絡(luò)上上存在的最長時間,超過這個時間報文將被丟棄

等待2MSL原因:

  • 1.保證客戶端發(fā)送的最后一個ACK報文段能夠到達(dá)服務(wù)端,因?yàn)?這個ACK報文段有可能丟失,會使服務(wù)端重傳FIN+ACK報文段,導(dǎo)致服務(wù)端無法正常關(guān)閉
  • 2.使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失,是下一個新的連接不會出現(xiàn)這種就得連接請求報文段

3.4.瀏覽器打開網(wǎng)址頁面過程

  • 1.URL地址:統(tǒng)一資源定位符,互聯(lián)網(wǎng)上的每個文件都有唯一的URL
    protocol:// hostname[:port]/path/[;parameters][?query]#fragment →
    協(xié)議://主機(jī)名:端口號/路徑/參數(shù)/查詢#信息片段
  • 2.DNS解析:將域名轉(zhuǎn)化為IP地址
    查找順序:瀏覽器緩存 → 操作系統(tǒng)緩存 → 本地host文件 → 路由器緩存 → ISP DNS緩存 → 根DNS服務(wù)器
  • 3.建立TCP連接:根據(jù)解析到的IP,依據(jù)各層的協(xié)議建立TCP連接
  • 4.發(fā)送HTTP請求:瀏覽器發(fā)送GET/POST請求
  • 5.解析接受到的http數(shù)據(jù):獲取服務(wù)器的響應(yīng)數(shù)據(jù),解析HTML,CSS,JS文件構(gòu)建dom樹,顯示網(wǎng)頁
  • 連接關(guān)閉:頁面為了優(yōu)化請求的耗時,默認(rèn)開啟持久連接(keep-alive),tab標(biāo)簽關(guān)閉時,tcp連接經(jīng)過四次揮手關(guān)閉關(guān)閉

3.5.HTTPS

HTTPS:超文本傳輸安全協(xié)議,HTTPS經(jīng)由HTTP進(jìn)行通信,但利用SSL/TLS來加密數(shù)據(jù)包.是提供對網(wǎng)站服務(wù)器的身份認(rèn)證,保護(hù)交換數(shù)據(jù)的隱私和完整性

HTTP和HTTPS的區(qū)別

HTTPS較HTTP最大的不同就是多了一層SSL(Secure Sockets Layer安全套接層)/TLS(Transport Layer Security安全傳輸協(xié)議).其提供通信雙方識別和認(rèn)證通道,保證數(shù)據(jù)的機(jī)密性和數(shù)據(jù)的完整性
過程:

  • 商定雙方通信使用的版本
  • 確定雙方使用的密碼組合
  • 瀏覽器通過服務(wù)端的加密數(shù)據(jù)驗(yàn)證服務(wù)端身份
  • 生成會話密鑰,此后通信使用對稱加密

傳統(tǒng)的http方式在傳輸數(shù)據(jù)時都是文明,很容易出現(xiàn)數(shù)據(jù)被監(jiān)聽和竊取的情況,也可能被監(jiān)聽者篡改,導(dǎo)致訪問的內(nèi)容與服務(wù)器不一致,http是一種不安全的傳輸協(xié)議

傳輸數(shù)據(jù)被竊聽

明文形式的數(shù)據(jù)在網(wǎng)絡(luò)上傳輸是不安全的,必須要對數(shù)據(jù)進(jìn)行加密才能安全傳輸

  • 對稱加密:加密和解密使用的都是同一個密鑰,常見的有DES和AES,效率較高
  • 非對稱加密:公鑰數(shù)據(jù)加密,私鑰才能解密,私鑰進(jìn)行加密,公鑰才能解密,常見的是RSA算法,私鑰不需要通過網(wǎng)絡(luò)傳輸,加密解密速度慢

由于網(wǎng)絡(luò)數(shù)據(jù)的傳輸十分頻繁,因此傳輸時應(yīng)使用效率較高的對稱加密加密數(shù)據(jù).但由于瀏覽器無法得知密鑰,需網(wǎng)絡(luò)傳輸密鑰,但是未得到密鑰之前的通訊都是明文的,容易被監(jiān)聽,竊取.不安全

此時,我們要結(jié)合非對稱加密,來建立安全的傳輸機(jī)制

  • 1.服務(wù)器端生成公鑰和私鑰,將公鑰傳輸給瀏覽器(客戶端)
  • 2.瀏覽器隨機(jī)生成一串密鑰后傳輸給服務(wù)端,服務(wù)端用私鑰解密,得到對稱加密密鑰

問題:

  • 因?yàn)楣€加密的數(shù)據(jù),只能被私鑰解密,公鑰屬于公開的,不怕被監(jiān)聽.
  • 但是攻擊者篡改公鑰,使用自己生成的密鑰串,那么服務(wù)器的都有數(shù)據(jù)仍將被竊取

為了防止公鑰被篡改,引入了CA權(quán)威機(jī)構(gòu):

  • 1.網(wǎng)站向CA機(jī)構(gòu)申請,將公鑰提交給CA機(jī)構(gòu),CA機(jī)構(gòu)根據(jù)公鑰及其他驗(yàn)證信息(網(wǎng)站域名,有效時長等)來制作證書

  • CA機(jī)構(gòu)使用私鑰加密數(shù)據(jù),將加密配置在服務(wù)器上,瀏覽器訪問網(wǎng)站時,網(wǎng)站首先將加密數(shù)據(jù)返回瀏覽器,瀏覽器使用CA機(jī)構(gòu)公鑰解密數(shù)據(jù),解密成功,則可以獲取數(shù)字證書信息,包括公鑰


    數(shù)字證書解密成功

解密失敗,說明網(wǎng)站返回的加密數(shù)據(jù)有可能被篡改了,或者非CA機(jī)構(gòu)的私鑰加密而來


數(shù)字證書解密失敗

注意:為了防止其他網(wǎng)站管理員申請相同域名的數(shù)字證書,致使加密數(shù)據(jù)被成功解析,而數(shù)字證書卻是其它網(wǎng)站的信息,包括公鑰,則其它網(wǎng)站可竊取網(wǎng)站信息.CA機(jī)構(gòu)會對其它信息包括域名等信息進(jìn)行輔助校驗(yàn)

https通信

4.總結(jié)

這一章節(jié)講解了各層的協(xié)議,簡單了解通信時的過程.這里主要是一些原理性質(zhì)知識點(diǎn)講解,與開發(fā)時http API的使用關(guān)聯(lián)不大,但掌握這些底層協(xié)議和通信過程是十分重要的,對于網(wǎng)絡(luò)數(shù)據(jù)的通信有一個更加清晰的認(rèn)識

參考:
http://www.reibang.com/p/c056f9373a10 https://blog.csdn.net/guolin_blog/article/details/104546558
http://www.reibang.com/p/d1c813dc4225

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末搭盾，一起剝皮案震驚了整個濱河市谱仪，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖愚隧，帶你破解...
    沈念sama閱讀 206,968評論 6贊 482
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件们妥，死亡現(xiàn)場離奇詭異拥刻，居然都是意外死亡潭辈，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門盏档，熙熙樓的掌柜王于貴愁眉苦臉地迎上來凶掰，“玉大人，你說我怎么就攤上這事蜈亩∨尘剑” “怎么了？”我有些...
    開封第一講書人閱讀 153,220評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵稚配，是天一觀的道長畅涂。 經(jīng)常有香客問我，道長道川，這世上最難降的妖魔是什么午衰？ 我笑而不...
    開封第一講書人閱讀 55,416評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任苹丸，我火速辦了婚禮，結(jié)果婚禮上苇经，老公的妹妹穿的比我還像新娘。我一直安慰自己宦言，他們只是感情好扇单，可當(dāng)我...
    茶點(diǎn)故事閱讀 64,425評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著奠旺，像睡著了一般蜘澜。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上响疚，一...
    開封第一講書人閱讀 49,144評論 1贊 285
  • 城市分裂傳說
    那天鄙信，我揣著相機(jī)與錄音，去河邊找鬼忿晕。 笑死装诡，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的践盼。 我是一名探鬼主播鸦采，決...
    沈念sama閱讀 38,432評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼咕幻！你這毒婦竟也來了渔伯？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 37,088評論 0贊 261
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤肄程，失蹤者是張志新（化名）和其女友劉穎锣吼，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體蓝厌，經(jīng)...
    沈念sama閱讀 43,586評論 1贊 300
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡玄叠，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,028評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了褂始。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片诸典。...
    茶點(diǎn)故事閱讀 38,137評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖崎苗，靈堂內(nèi)的尸體忽然破棺而出狐粱，到底是詐尸還是另有隱情，我是刑警寧澤胆数，帶...
    沈念sama閱讀 33,783評論 4贊 324
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布肌蜻，位于F島的核電站，受9級特大地震影響必尼，放射性物質(zhì)發(fā)生泄漏蒋搜。R本人自食惡果不足惜篡撵，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,343評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望豆挽。 院中可真熱鬧育谬，春花似錦、人聲如沸帮哈。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽娘侍。三九已至咖刃，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間憾筏，已是汗流浹背嚎杨。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留氧腰，地道東北人枫浙。 一個月前我還...
    沈念sama閱讀 45,595評論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像古拴，于是被迫代替她去往敵國和親自脯。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,901評論 2贊 345