網(wǎng)絡面試知識點

HTTP

HTTP：超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol）是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議戳表。設(shè)計 HTTP 最初的目的是為了提供一種發(fā)布和接收 HTML 頁面的方法厘擂。它可以使瀏覽器更加高效。HTTP 協(xié)議是以明文方式發(fā)送信息，如果黑客截取了 Web 瀏覽器和服務器之間的傳輸報文顾复，就可以直接獲得其中的信息奏瞬。

隊頭阻塞/多路復用

HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題（Head of line blocking）枫绅，那什么是隊頭阻塞呢？

TCP 是個面向連接的協(xié)議硼端，即發(fā)送請求后需要收到 ACK 消息并淋，以確認對方已接收到數(shù)據(jù)。如果每次請求都要在收到上次請求的 ACK 消息后再請求珍昨，那么效率無疑很低县耽。后來 HTTP/1.1 提出了 Pipelining 技術(shù)，允許一個 TCP 連接同時發(fā)送多個請求镣典，這樣就大大提升了傳輸效率兔毙。

在這個背景下，下面就來談 HTTP/1.1 的隊頭阻塞兄春。下圖中澎剥，一個 TCP 連接同時傳輸 10 個請求，其中第 1赶舆、2哑姚、3 個請求已被客戶端接收，但第 4 個請求丟失芜茵，那么后面第 5 - 10 個請求都被阻塞叙量，需要等第 4 個請求處理完畢才能被處理，這樣就浪費了帶寬資源九串。

因此绞佩，HTTP 一般又允許每個主機建立 6 個 TCP 連接，這樣可以更加充分地利用帶寬資源，但每個連接中隊頭阻塞的問題還是存在征炼。

HTTP/2 的多路復用解決了上述的隊頭阻塞問題析既。不像 HTTP/1.1 中只有上一個請求的所有數(shù)據(jù)包被傳輸完畢下一個請求的數(shù)據(jù)包才可以被傳輸，HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連接同時被傳輸谆奥，這樣即使一個請求被阻塞眼坏，也不會影響其他的請求。如下圖所示酸些，不同顏色代表不同的請求宰译，相同顏色的色塊代表請求被切分的 Frame。

HTTP/2 雖然可以解決“請求”這個粒度的阻塞魄懂，但 HTTP/2 的基礎(chǔ) TCP 協(xié)議本身卻也存在著隊頭阻塞的問題沿侈。HTTP/2 的每個請求都會被拆分成多個 Frame，不同請求的 Frame 組合成 Stream市栗，Stream 是 TCP 上的邏輯傳輸單元缀拭，這樣 HTTP/2 就達到了一條連接同時發(fā)送多條請求的目標，這就是多路復用的原理填帽。我們看一個例子蛛淋，在一條 TCP 連接上同時發(fā)送 4 個 Stream，其中 Stream1 已正確送達篡腌，Stream2 中的第 3 個 Frame 丟失褐荷，TCP 處理數(shù)據(jù)時有嚴格的前后順序，先發(fā)送的 Frame 要先被處理嘹悼，這樣就會要求發(fā)送方重新發(fā)送第 3 個 Frame叛甫，Stream3 和 Stream4 雖然已到達但卻不能被處理，那么這時整條連接都被阻塞杨伙。

參考文章
HTTP/3 來了 其监！未來可期

HTTPS

HTTPS是在HTTP上建立SSL加密層，并對傳輸數(shù)據(jù)進行加密限匣，是HTTP協(xié)議的安全版抖苦。

HTTPS協(xié)議的主要作用：
1）一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?br> 2）另一種就是確認網(wǎng)站的真實性膛腐。

HTTPS并非是應用層的一種新協(xié)議睛约。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已鼎俘。

通常哲身，HTTP直接和TCP通信。當使用SSL時贸伐，則演變成先和SSL通信勘天，再由SSL和TCP通信了。簡言之，所謂HTTPS脯丝，其實就是身披SSL協(xié)議這層外殼的HTTP商膊。

HTTPS優(yōu)缺點

優(yōu)點：

  • 使用HTTPS協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器宠进；
  • HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸晕拆、身份認證的網(wǎng)絡協(xié)議，要比http協(xié)議安全材蹬，可防止數(shù)據(jù)在傳輸過程中不被竊取实幕、改變，確保數(shù)據(jù)的完整性堤器。
  • HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案昆庇，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本闸溃。

缺點：

  • HTTPS協(xié)議握手階段比較費時整吆，會使頁面的加載時間延長近50%，增加10%到20%的耗電辉川；
  • HTTPS連接緩存不如HTTP高效表蝙，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響员串；
  • SSL證書需要錢勇哗，功能越強大的證書費用越高，個人網(wǎng)站寸齐、小網(wǎng)站沒有必要一般不會用欲诺。
  • SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名渺鹦，IPv4資源不可能支撐這個消耗扰法。
  • HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊毅厚、拒絕服務攻擊塞颁、服務器劫持等方面幾乎起不到什么作用。最關(guān)鍵的吸耿，SSL證書的信用鏈體系并不安全祠锣，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行咽安。

HTTP和HTTPS區(qū)別

  • HTTP 的連接很簡單伴网，是無狀態(tài)的。HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸妆棒、身份認證的網(wǎng)絡協(xié)議澡腾，比 HTTP 協(xié)議安全沸伏。
  • HTTPS比HTTP更加安全，對搜索引擎更友好动分，利于SEO,谷歌毅糟、百度優(yōu)先索引HTTPS網(wǎng)頁;
  • HTTPS需要用到ca的SSL證書，而HTTP不用;
  • HTTPS標準端口443澜公，HTTP標準端口80;
  • HTTPS基于傳輸層姆另，HTTP基于應用層;
  • HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

http狀態(tài)碼

客戶端的每一次請求坟乾，服務器都必須給出回應蜕青。回應包括 HTTP 狀態(tài)碼和數(shù)據(jù)兩部分糊渊。

HTTP 狀態(tài)碼就是一個三位數(shù)右核，分成五個類別。

  • 1xx：相關(guān)信息
  • 2xx：操作成功
  • 3xx：重定向
  • 4xx：客戶端錯誤
  • 5xx：服務器錯誤

這五大類總共包含100多種狀態(tài)碼渺绒，覆蓋了絕大部分可能遇到的情況贺喝。每一種狀態(tài)碼都有標準的（或者約定的）解釋，客戶端只需查看狀態(tài)碼宗兼，就可以判斷出發(fā)生了什么情況躏鱼，所以服務器應該返回盡可能精確的狀態(tài)碼。

API 不需要1xx狀態(tài)碼殷绍，下面介紹其他四類狀態(tài)碼的精確含義染苛。

2XX狀態(tài)碼

200狀態(tài)碼表示操作成功，但是不同的方法可以返回更精確的狀態(tài)碼主到。

  • GET: 200 OK
  • POST: 201 Created
  • PUT: 200 OK
  • PATCH: 200 OK
  • DELETE: 204 No Content

POST返回201狀態(tài)碼茶行，表示生成了新的資源；DELETE返回204狀態(tài)碼登钥，表示資源已經(jīng)不存在畔师。

此外，202 Accepted狀態(tài)碼表示服務器已經(jīng)收到請求牧牢，但還未進行處理作箍，會在未來再處理录平，通常用于異步操作茸炒。下面是一個例子拜隧。

HTTP/1.1 202 Accepted

{
  "task": {
    "href": "/api/company/job-management/jobs/2130040",
    "id": "2130040"
  }
}

3xx 狀態(tài)碼

API 用不到301狀態(tài)碼（永久重定向）和302狀態(tài)碼（暫時重定向，307也是這個含義）轮纫，因為它們可以由應用級別返回腔寡，瀏覽器會直接跳轉(zhuǎn)，API 級別可以不考慮這兩種情況蜡感。

API 用到的3xx狀態(tài)碼蹬蚁，主要是303 See Other，表示參考另一個 URL郑兴。它與302和307的含義一樣犀斋，也是"暫時重定向"，區(qū)別在于302和307用于GET請求情连，而303用于POST叽粹、PUT和DELETE請求。收到303以后却舀，瀏覽器不會自動跳轉(zhuǎn)虫几，而會讓用戶自己決定下一步怎么辦。

下面是一個例子挽拔。

HTTP/1.1 303 See Other
Location: /api/orders/12345

4xx 狀態(tài)碼

4xx狀態(tài)碼表示客戶端錯誤辆脸，主要有下面幾種。

  • 400 Bad Request： 服務器不理解客戶端的請求螃诅，未做任何處理啡氢。
  • 401 Unauthorized： 用戶未提供身份驗證憑據(jù)，或者沒有通過身份驗證术裸。
  • 403 Forbidden： 用戶通過了身份驗證倘是，但是不具有訪問資源所需的權(quán)限。
  • 404 Not Found： 所請求的資源不存在袭艺，或不可用搀崭。
  • 405 Method Not Allowed： 用戶已經(jīng)通過身份驗證，但是所用的 HTTP 方法不在他的權(quán)限之內(nèi)猾编。
  • 410 Gone： 所請求的資源已從這個地址轉(zhuǎn)移瘤睹，不再可用。
  • 415 Unsupported Media Type： 客戶端要求的返回格式不支持答倡。比如默蚌，API 只能返回 JSON 格式，但是客戶端要求返回 XML 格式苇羡。
  • 422 Unprocessable Entity ： 客戶端上傳的附件無法處理绸吸，導致請求失敗。
  • 429 Too Many Requests： 客戶端的請求次數(shù)超過限額设江。

5xx 狀態(tài)碼

5xx狀態(tài)碼表示服務端錯誤锦茁。一般來說，API 不會向用戶透露服務器的詳細信息叉存，所以只要兩個狀態(tài)碼就夠了码俩。

  • 500 Internal Server Error： 客戶端請求有效，服務器處理時發(fā)生了意外歼捏。
  • 503 Service Unavailable： 服務器無法處理請求稿存，一般用于網(wǎng)站維護狀態(tài)笨篷。

TCP可靠性保證機制

  • 檢驗和
  • 序列號
  • 確認應答機制（ACK）
  • 超時重傳機制
  • 連接管理機制（三次握手四次揮手）
  • 流量控制
  • 擁塞控制

相關(guān)文章
TCP可靠性的保證機制總結(jié)

瀏覽從輸入網(wǎng)址到回車發(fā)生了什么

當用戶訪問頁面時，瀏覽器需要獲取用戶請求內(nèi)容瓣履，這個過程主要涉及瀏覽器網(wǎng)絡模塊：

  • 首先會進行 url 解析率翅，根據(jù) dns 服務器根據(jù)輸入的域名查找對應IP，然后向該IP地址發(fā)起請求袖迎；
  • 瀏覽器獲得并解析服務器的返回內(nèi)容(HTTP response)冕臭；
  • 瀏覽器加載HTML文件及文件內(nèi)包含的外部引用文件及圖片，多媒體等資源燕锥。

通過網(wǎng)絡模塊加載到HTML文件后渲染引擎渲染流程如下辜贵，這也通常被稱作關(guān)鍵渲染路徑（Critical Rendering Path）：

  • 構(gòu)建DOM樹(DOM tree)：解析HTML生成DOM樹
  • 構(gòu)建CSSOM(CSS Object Model)樹：解析樣式生成CSSOM規(guī)則樹
  • 執(zhí)行JavaScript：加載并執(zhí)行JavaScript代碼（包括內(nèi)聯(lián)代碼或外聯(lián)JavaScript文件）
  • 構(gòu)建渲染樹(render tree)：將DOM樹和CSSO規(guī)則樹合并生成渲染樹（渲染樹：按順序展示在屏幕上的一系列矩形，這些矩形帶有字體归形，顏色和尺寸等視覺屬性）
  • 布局（layout）：遍歷渲染樹開始布局托慨，計算每個節(jié)點的位置大小等信息
  • 繪制（painting）：將渲染樹每個節(jié)點繪制到屏幕

上面的步驟并不是一次性執(zhí)行完成，例如DOM或者CSSOM被修改時暇榴，就會有某個過程需要被重復執(zhí)行榴芳，重新計算并重新渲染。實際上跺撼，由于JS跟css的操作會多次修改DOM跟CSSOM窟感。

前端安全（CSRF、XSS）

XSS

XSS歉井，即 Cross Site Script柿祈，中譯是跨站腳本攻擊；其原本縮寫是 CSS哩至，但為了和層疊樣式表(Cascading Style Sheet)有所區(qū)分躏嚎，因而在安全領(lǐng)域叫做 XSS。

XSS 攻擊是指攻擊者在網(wǎng)站上注入惡意的客戶端代碼菩貌，通過惡意腳本對客戶端網(wǎng)頁進行篡改卢佣，從而在用戶瀏覽網(wǎng)頁時，對用戶瀏覽器進行控制或者獲取用戶隱私數(shù)據(jù)的一種攻擊方式箭阶。

攻擊者對客戶端網(wǎng)頁注入的惡意腳本一般包括 JavaScript虚茶，有時也會包含 HTML 和 Flash。有很多種方式進行 XSS 攻擊仇参，但它們的共同點為：將一些隱私數(shù)據(jù)像 cookie嘹叫、session 發(fā)送給攻擊者，將受害者重定向到一個由攻擊者控制的網(wǎng)站诈乒，在受害者的機器上進行一些惡意操作罩扇。

XSS攻擊可以分為3類：反射型（非持久型）、存儲型（持久型）怕磨、基于DOM喂饥。

反射型

反射型 XSS 只是簡單地把用戶輸入的數(shù)據(jù) “反射” 給瀏覽器消约，這種攻擊方式往往需要攻擊者誘使用戶點擊一個惡意鏈接，或者提交一個表單员帮，或者進入一個惡意網(wǎng)站時或粮，注入腳本進入被攻擊者的網(wǎng)站。

存儲型

存儲型 XSS 會把用戶輸入的數(shù)據(jù) “存儲” 在服務器端集侯，當瀏覽器請求數(shù)據(jù)時，腳本從服務器上傳回并執(zhí)行帜消。這種 XSS 攻擊具有很強的穩(wěn)定性棠枉。

比較常見的一個場景是攻擊者在社區(qū)或論壇上寫下一篇包含惡意 JavaScript 代碼的文章或評論，文章或評論發(fā)表后泡挺，所有訪問該文章或評論的用戶辈讶，都會在他們的瀏覽器中執(zhí)行這段惡意的 JavaScript 代碼。

基于DOM

基于 DOM 的 XSS 攻擊是指通過惡意腳本修改頁面的 DOM 結(jié)構(gòu)娄猫，是純粹發(fā)生在客戶端的攻擊

CSRF

CSRF贱除，即 Cross Site Request Forgery，中譯是跨站請求偽造媳溺，是一種劫持受信任用戶向服務器發(fā)送非預期請求的攻擊方式月幌。

通常情況下，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務器的信任悬蔽，可以在受害者毫不知情的情況下以受害者名義偽造請求發(fā)送給受攻擊服務器扯躺，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護之下的操作。

防范

  • 防御 XSS 攻擊
    • HttpOnly 防止劫取 Cookie
    • 用戶的輸入檢查
    • 服務端的輸出檢查
  • 防御 CSRF 攻擊
    • 驗證碼
    • Referer Check
    • Token 驗證

相關(guān)文章
淺說 XSS 和 CSRF

前端跨域

瀏覽器的同源策略安全機制導致了跨域蝎困，容易有CSRF攻擊录语。

跨域解決方案：

  • JSONP，script 標簽是不受同源策略的限制的禾乘，它可以載入任意地方的 JavaScript 文件澎埠，而并不要求同源。
  • document.domain始藕，這種方式只適合主域名相同蒲稳，但子域名不同的iframe跨域。比如主域名是http://crossdomain.com:9099伍派，子域名是http://child.crossdomain.com:9099弟塞，這種情況下給兩個頁面指定一下document.domain即document.domain = crossdomain.com就可以訪問各自的window對象了。
  • CORS是一個W3C標準拙已，全稱是"跨域資源共享"（Cross-origin resource sharing）跨域資源共享 CORS 詳解决记。
  • Nginx代理配置

cdn加速

簡單的來說就是原服務器上數(shù)據(jù)復制到其他服務器上，用戶訪問時倍踪，那臺服務器近訪問到的就是那臺服務器上的數(shù)據(jù)系宫。

CDN加速優(yōu)點是成本低索昂，速度快±┙瑁可以用CDN best的CDN進行加速椒惨，免費，可部署私有潮罪，公有CDN系統(tǒng)康谆。可以實現(xiàn)宕機檢測嫉到，自動切換ip沃暗，分線路，分組解析何恶。也就是CDN加速的主要作用就是保證網(wǎng)站的正常訪問孽锥，及加快網(wǎng)站訪問速度和響應速度，防止網(wǎng)站因黑客攻擊细层，DNS解析劫持故障等導致的網(wǎng)站服務器的宕機狀況的出現(xiàn)惜辑。

負載均衡

垂直擴展

隨著系統(tǒng)訪問量的增加，在不新增服務器的情況下疫赎，可以通過提升單機硬件配置來做負載均衡（可從cpu盛撑、內(nèi)存、硬盤捧搞，網(wǎng)卡等方面提升）撵彻，但是垂直擴展會帶來成本問題...

在早期時候，價格不變時实牡，每隔一到兩年技術(shù)會革新陌僵，性能會翻一倍，即摩爾定律：

當價格不變時创坞，集成電路上可容納的元器件數(shù)目碗短，約每隔18-24個月便會增加一倍，性能也將提升一倍题涨。
換言之偎谁，每一美元所能買到的電腦性能，將每隔18-24個月翻一倍以上纲堵。

當技術(shù)已經(jīng)達到瓶頸巡雨，提升電腦性能的消耗的成本將越來越高，所以摩爾定律已經(jīng)放緩席函。因此單機擴展性能提高是有限的铐望，而且成本會越來越高

水平擴展

目前在高并發(fā)高可用系統(tǒng)架構(gòu)中，最優(yōu)方案還是水平擴展。理論上正蛙，在系統(tǒng)能支持水平擴展的前提下督弓，增加服務器數(shù)量，部署更多機器集群乒验，能帶來無限的性能提升愚隧。

Nginx

Nginx 是一個高性能的WEB服務器和反向代理服務，最常用的軟件負載均衡器锻全，屬于第七層應用層協(xié)議狂塘。

核心概念：用戶請求先到Nginx，再由Ngix轉(zhuǎn)發(fā)請求到后面的應用服務器（如：node）

一般做到10W 并發(fā)鳄厌，因為http請求的處理包括解析和封裝Http 內(nèi)容荞胡，要處理更多請求，需要更多內(nèi)存部翘、CPU等資源硝训。

如果面臨幾十萬并發(fā)量响委，可以使用Ngix集群新思，則需要LVS負責轉(zhuǎn)發(fā)給 Ngix 集群機器

LVS

LVS（Linux Virtual Server），Linux 虛擬服務器赘风，中國人開發(fā)夹囚，目前絕大部分Linux 發(fā)行版，都集成在內(nèi)核了 邀窃。實現(xiàn)基于第四層（傳輸層）的軟件負載均衡方案荸哟。支持10W～50W 并發(fā)量。

為了方便理解瞬捕，初學者可認為安裝使用了LVS的Linux服務器鞍历，等于快遞中轉(zhuǎn)。

核心理念：原本是請求LVS服務器的數(shù)據(jù)包肪虎，被LVS軟件篡改了數(shù)據(jù)包的目的地劣砍，將流量轉(zhuǎn)移到了Ngix所在的機器IP，從而實現(xiàn)負載均衡扇救。

為什么說LVS比Nigx快刑枝？
網(wǎng)絡層第四層使用的協(xié)議（如TCP）內(nèi)容比Http簡單，解析和組裝所消耗的CPU迅腔、內(nèi)存等資源比Nigx要低装畅。

硬件設(shè)備F5

F5是實現(xiàn)第四層（傳輸層）交換的一款產(chǎn)品，屬于硬交換沧烈，價格貴性能好

服務端上限

  • Nginx 支撐1W～10W并發(fā)
  • LVS 支撐10W～50W并發(fā)
  • F5 支撐200W～1000W并發(fā)

DNS-無限水平擴展

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末掠兄，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌徽千，老刑警劉巖苫费，帶你破解...
    沈念sama閱讀 221,635評論 6贊 515
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異双抽，居然都是意外死亡百框，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,543評論 3贊 399
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門牍汹，熙熙樓的掌柜王于貴愁眉苦臉地迎上來铐维，“玉大人，你說我怎么就攤上這事慎菲〖奚撸” “怎么了？”我有些...
    開封第一講書人閱讀 168,083評論 0贊 360
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵露该，是天一觀的道長睬棚。 經(jīng)常有香客問我，道長解幼，這世上最難降的妖魔是什么抑党？ 我笑而不...
    開封第一講書人閱讀 59,640評論 1贊 296
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮撵摆，結(jié)果婚禮上底靠，老公的妹妹穿的比我還像新娘。我一直安慰自己特铝，他們只是感情好暑中，可當我...
    茶點故事閱讀 68,640評論 6贊 397
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著鲫剿，像睡著了一般鳄逾。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上灵莲，一...
    開封第一講書人閱讀 52,262評論 1贊 308
  • 城市分裂傳說
    那天雕凹，我揣著相機與錄音，去河邊找鬼笆呆。 笑死请琳，一個胖子當著我的面吹牛，可吹牛的內(nèi)容都是我干的赠幕。 我是一名探鬼主播俄精，決...
    沈念sama閱讀 40,833評論 3贊 421
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼榕堰！你這毒婦竟也來了竖慧？” 一聲冷哼從身側(cè)響起嫌套，我...
    開封第一講書人閱讀 39,736評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎圾旨，沒想到半個月后踱讨，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 46,280評論 1贊 319
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡砍的，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,369評論 3贊 340
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年痹筛，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片廓鞠。...
    茶點故事閱讀 40,503評論 1贊 352
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡帚稠，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出床佳，到底是詐尸還是另有隱情滋早，我是刑警寧澤，帶...
    沈念sama閱讀 36,185評論 5贊 350
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布砌们，位于F島的核電站杆麸，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏浪感。R本人自食惡果不足惜昔头，卻給世界環(huán)境...
    茶點故事閱讀 41,870評論 3贊 333
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望篮撑。 院中可真熱鬧减细，春花似錦匆瓜、人聲如沸赢笨。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,340評論 0贊 24
  • 一樁弒父案驮吱，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽茧妒。三九已至，卻和暖如春左冬，著一層夾襖步出監(jiān)牢的瞬間桐筏，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,460評論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來泰國打工拇砰， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留梅忌，地道東北人。 一個月前我還...
    沈念sama閱讀 48,909評論 3贊 376
  • 代替公主和親
    正文 我出身青樓除破，卻偏偏與公主長得像牧氮，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子瑰枫，可洞房花燭夜當晚...
    茶點故事閱讀 45,512評論 2贊 359

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