從輸入URL到瀏覽器顯示頁面發(fā)生了什么

一切盡在圖中

1、輸入網址

當你開始輸入網址啊犬,比如:www.163.com時珊蟀,瀏覽器可以在書簽或者歷史記錄里面去搜索相關的網址推薦給你

2、瀏覽器查找域名的ip地址

(1)請求發(fā)起后抄淑,瀏覽器首先會解析這個域名,首先它會查看本地硬盤的 hosts 文件驰后,看看其中有沒有和這個域名對應的規(guī)則肆资,如果有的話就直接使用 hosts 文件里面的 ip 地址。

(2)?如果在本地的 hosts 文件沒有能夠找到對應的 ip 地址灶芝,瀏覽器會發(fā)出一個 DNS請求到本地DNS(域名分布系統(tǒng))服務器 郑原。本地DNS服務器一般都是你的網絡接入服務器商提供唉韭,比如中國電信,中國移動犯犁。

(3)查詢你輸入的網址的DNS請求到達本地DNS服務器之后属愤,本地DNS服務器會首先查詢它的緩存記錄,如果緩存中有此條記錄酸役,就可以直接返回結果住诸,此過程是遞歸的方式進行查詢。如果沒有簇捍,本地DNS服務器還要向DNS根服務器進行查詢

(4)根DNS服務器沒有記錄具體的域名和IP地址的對應關系只壳,而是告訴本地DNS服務器俏拱,你可以到域服務器上去繼續(xù)查詢暑塑,并給出域服務器的地址。這種過程是迭代的過程

(5)本地DNS服務器繼續(xù)向域服務器發(fā)出請求锅必,在這個例子中事格,請求的對象是.com域服務器。.com域服務器收到請求之后搞隐,也不會直接返回域名和IP地址的對應關系驹愚,而是告訴本地DNS服務器,你的域名的解析服務器的地址

(6)最后劣纲,本地DNS服務器向域名的解析服務器發(fā)出請求逢捺,這時就能收到一個域名和IP地址對應關系,本地DNS服務器不僅要把IP地址返回給用戶電腦癞季,還要把這個對應關系保存在緩存中劫瞳,以備下次別的用戶查詢時,可以直接返回結果绷柒,加快網絡訪問

3志于、建立tcp鏈接

? ? ? ? ?在拿到域名對應的IP地址后,會以隨機端口(1024~~65535)向WEB服務器程序80端口發(fā)起TCP的連接請求废睦,這個連接請求進入到內核的TCP/IP協議棧(用于識別該連接請求伺绽,解封包,一層一層的剝開)嗜湃,還有可能要經過Netfilter防火墻(屬于內核的模塊)的過濾奈应,最終到達WEB程序,最終建立了TCP/IP的連接购披,對于客戶端與服務器的TCP鏈接杖挣,必然要說的就是『三次握手』。
? ? ? ?所謂三次握手(Three-Way Handshake)即建立TCP連接今瀑,就是指建立一個TCP連接時程梦,需要客戶端和服務端總共發(fā)送3個包以確認連接的建立点把。在socket編程中,這一過程由客戶端執(zhí)行connect來觸發(fā)屿附,整個流程如下圖所示:

(1)第一次握手:Client將標志位SYN置為1郎逃,隨機產生一個值seq=J,并將該數據包發(fā)送給Server挺份,Client進入SYN_SENT狀態(tài)褒翰,等待Server確認。

? (2)第二次握手:Server收到數據包后由標志位SYN=1知道Client請求建立連接匀泊,Server將標志位SYN和ACK都置為1优训,ack=J+1,隨機產生一個值seq=K各聘,并將該數據包發(fā)送給Client以確認連接請求揣非,Server進入SYN_RCVD狀態(tài)。

? (3)第三次握手:Client收到確認后躲因,檢查ack是否為J+1早敬,ACK是否為1,如果正確則將標志位ACK置為1大脉,ack=K+1搞监,并將該數據包發(fā)送給Server,Server檢查ack是否為K+1镰矿,ACK是否為1琐驴,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態(tài)秤标,完成三次握手绝淡,隨后Client與Server之間可以開始傳輸數據了。

? SYN攻擊:
? ? ? ? ?
在三次握手過程中抛杨,Server發(fā)送SYN-ACK之后够委,收到Client的ACK之前的TCP連接稱為半連接(half-open connect),此時Server處于SYN_RCVD狀態(tài)怖现,當收到ACK后茁帽,Server轉入ESTABLISHED狀態(tài)。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址屈嗤,并向Server不斷地發(fā)送SYN包潘拨,Server回復確認包,并等待Client的確認饶号,由于源地址是不存在的铁追,因此,Server需要不斷重發(fā)直至超時茫船,這些偽造的SYN包將產時間占用未連接隊列琅束,導致正常的SYN請求因為隊列滿而被丟棄扭屁,從而引起網絡堵塞甚至系統(tǒng)癱瘓。SYN攻擊時一種典型的DDOS攻擊涩禀,檢測SYN攻擊的方式非常簡單料滥,即當Server上有大量半連接狀態(tài)且源IP地址是隨機的,則可以斷定遭到SYN攻擊了艾船,使用如下命令可以讓之現行: #netstat -nap | grep SYN_RECV

4葵腹、瀏覽器向web服務器發(fā)起http請求

? HTTP簡介
? ? ? ? HTTP(超文本傳輸協議)是一個基于請求與響應模式的、無狀態(tài)的屿岂、應用層的協議践宴,常基于TCP的連接方式爷怀,HTTP1.1版本中給出一種持續(xù)連接的機制阻肩,絕大多數的Web開發(fā),都是構建在HTTP協議之上的Web應用霉撵。

1磺浙、常用的HTTP方法有哪些?
? ? ?GET: 用于請求訪問已經被URI(統(tǒng)一資源標識符)識別的資源徒坡,可以通過URL傳參給服務器。
? ? ?POST:用于傳輸信息給服務器瘤缩,主要功能與GET方法類似喇完,但一般推薦使用POST方式。
? ? ?PUT: 傳輸文件剥啤,報文主體中包含文件內容锦溪,保存到對應URI位置。
? ? ?HEAD: 獲得報文首部府怯,與GET方法類似刻诊,只是不返回報文主體,一般用于驗證URI是否有效牺丙。
? ? ?DELETE:刪除文件则涯,與PUT方法相反,刪除對應URI位置的文件冲簿。
? ? ?OPTIONS:查詢相應URI支持的HTTP方法粟判。

2、GET方法與POST方法的區(qū)別
? ?(1)提交數據方式(位置):
? ? ? get重點在從服務器上獲取資源峦剔,post重點在向服務器發(fā)送數據档礁;get傳輸數據是通過URL請求,以field(字段)= value的形式吝沫,置于URL后呻澜,并用"?"連接递礼,多個請求數據間用"&"連接,如http://127.0.0.1/Test/login.action?name=admin&password=admin羹幸,這個過程用戶是可見的宰衙;
? ? ?post傳輸數據通過Http的post機制,將字段與對應值封存在請求實體中發(fā)送給服務器睹欲,這個過程對用戶是不可見的供炼;
? ? 因此,GET提交的數據會在地址欄中顯示出來窘疮,而POST提交袋哼,地址欄不會改變。

(2)傳輸數據的大小
? ? ? Get傳輸的數據量小闸衫,因為受URL長度限制涛贯,但效率較高;
? ? ? Post可以傳輸大量數據蔚出,所以上傳文件時只能用Post方式弟翘;

(3)安全性
? ? ?get是不安全的,因為URL是可見的骄酗,可能會泄露私密信息稀余,如密碼等;
? ? ?post較get安全性較高趋翻;
? ? ?這里安全的含義是真正的Security的含義睛琳,比如:通過GET提交數據,用戶名和密碼將明文出現在URL上踏烙,別人就可以拿到你的賬號和密碼了师骗。

(4)傳的中文字符可能會亂碼
? ? ?get方式只能支持ASCII字符,向服務器傳的中文字符可能會亂碼讨惩。
? ? ?post支持標準字符集辟癌,可以正確傳遞中文字符。

(1) Web瀏覽器分別發(fā)送請求行荐捻、請求頭信息 黍少、一個空行、請求體
? ? ? ? ? ?瀏覽器發(fā)送其請求命令之后靴患,還要以頭信息的形式向Web服務器發(fā)送一些別的信息仍侥,之后瀏覽器發(fā)送了一空白行來通知服務器,它已經結束了該頭信息的發(fā)送鸳君。?

(2)Web服務器應答? 相應行农渊、相應頭、空行、相應體
? ? ? ? ? 客戶端向服務器發(fā)出請求后砸紊,服務器會客戶機回送應答传于,?HTTP/1.1 200 OK ,應答的第一部分是協議的版本號和應答狀態(tài)碼醉顽。

(3)?Web服務器關閉TCP連接
? ? ? ? ? 一般情況下沼溜,一旦Web服務器向瀏覽器發(fā)送了請求數據,它就要關閉TCP連接游添,然后如果瀏覽器或者服務器在其頭信息加入了這行代碼:

Connection:keep-alive
? ? ? ? TCP連接在發(fā)送后將仍然保持打開狀態(tài)系草,于是,瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求唆涝。保持連接節(jié)省了為每個請求建立新連接所需的時間找都,還節(jié)約了網絡帶寬。

請求報文包含三部分:

a、請求行
? ? ?包含請求方法、URI火脉、HTTP版本信息

b、請求首部字段
? ? ?請求頭部由關鍵字/值對組成泼疑,每行一對,關鍵字和值用英文冒號“:”分隔。請求頭部通知服務器有關于客戶端請求的信息,典型的請求頭有:
?User-Agent:產生請求的瀏覽器類型戒职。
?Accept:客戶端可識別的內容類型列表
?Host:請求的主機名,允許多個域名同處一個IP地址煞茫,即虛擬主機帕涌。

c、空行
? ? ? 最后一個請求頭之后是一個空行续徽,發(fā)送回車符和換行符,通知服務器以下不再有請求頭亲澡。

d钦扭、請求內容實體
? ? ? 請求數據不在GET方法中使用,而是在POST方法中使用床绪。POST方法適用于需要客戶填寫表單的場合客情。與請求數據相關的最常使用的請求頭是Content-Type和Content-Length。

響應報文包含三部分:
? ??
a癞己、狀態(tài)行:包含HTTP版本膀斋、狀態(tài)碼、狀態(tài)碼的原因短語
? ? b痹雅、響應首部字段
? ? c仰担、空行
? ? d、響應內容實體

常見的HTTP相應狀態(tài)碼
1xx:指示信息--表示請求已接收绩社,繼續(xù)處
2xx:成功--表示請求已被成功接收摔蓝、理解赂苗、接受
3xx:重定向--要完成請求必須進行更進一步的操作。? 301 永久重定向 302暫時性重定向
4xx:客戶端錯誤--請求有語法錯誤或請求無法實現
5xx:服務器端錯誤--服務器未能實現合法的請求

常見狀態(tài)代碼贮尉、狀態(tài)描述的說明如下:
200:請求被正常處理
204:請求被受理但沒有資源可以返回
206:客戶端只是請求資源的一部分拌滋,服務器只對請求的部分資源執(zhí)行GET方法,相應報文中通過Content-Range指定范圍的資源猜谚。
301:永久性重定向
302:臨時重定向
303:與302狀態(tài)碼有相似功能败砂,只是它希望客戶端在請求一個URI的時候,能通過GET方法重定向到另一個URI上
304:請求內容沒有修改魏铅,客戶端使用緩存副本
307:臨時重定向昌犹,與302類似,只是強制要求使用POST方法
400:客戶端請求有語法錯誤沦零,服務器無法識別
401:請求需要認證
403:請求的對應資源禁止被訪問
404:服務器無法找到對應資源
500:服務器內部錯誤
503:服務器正忙祭隔,當前不能處理客戶端的請求,一段時間后可能恢復正常

常見HTTP首部字段
a路操、通用首部字段(請求報文與響應報文都會使用的首部字段)
? ? ?Date:創(chuàng)建報文時間
? ? ?Connection:連接的管理
? ? ?Cache-Control:緩存的控制
? ? ?Transfer-Encoding:報文主體的傳輸編碼方式

b疾渴、請求首部字段(請求報文會使用的首部字段)
? ? ? Host:請求資源所在服務器
? ? ?Accept:可處理的媒體類
? ? ?Accept-Charset:可接收的字符集
? ? ?Accept-Encoding:可接受的內容編碼
? ? ?Accept-Language:可接受的自然語言

c、響應首部字段(響應報文會使用的首部字段)
? ? ?Accept-Ranges:可接受的字節(jié)范圍
? ? ?Location:令客戶端重新定向到的URI
? ? ?Server:HTTP服務器的安裝信息

d屯仗、實體首部字段(請求報文與響應報文的的實體部分使用的首部字段)
? ? ? Allow:資源可支持的HTTP方法
? ? ?Content-Type:實體主類的類型
? ? ?Content-Encoding:實體主體適用的編碼方式
? ? ?Content-Language:實體主體的自然語言
? ? ?Content-Length:實體主體的的字節(jié)
? ? ?Content-Range:實體主體的位置范圍搞坝,一般用于發(fā)出部分請求時使用

下面給出一個HTTP響應報文例子

HTTPS、HTTP
http缺點:
a魁袜、通信使用明文不加密桩撮,內容可能被竊聽
b、不驗證通信方身份峰弹,可能遭到偽裝
c店量、無法驗證報文完整性,可能被篡改鞠呈, HTTPS就是HTTP加上加密處理(一般是SSL安全通信線路)+認證+完整性保護

HTTP優(yōu)化
利用負載均衡優(yōu)化和加速HTTP應用
利用HTTP Cache來優(yōu)化網站

HTTP2.0版本新特性
多路復用融师,頭部壓縮,服務器推送蚁吝,二進制分幀層

5旱爆、服務器端處理

服務器端收到請求后的由web服務器(準確說應該是http服務器)處理請求,諸如Apache窘茁、Ngnix怀伦、IIS等。web服務器解析用戶請求山林,知道了需要調度哪些資源文件房待,再通過相應的這些資源文件處理用戶請求和參數,并調用數據庫信息,最后將結果通過web服務器返回給瀏覽器客戶端

6吴攒、關閉TCP鏈接
? ? ? ??
為了避免服務器與客戶端雙方的資源占用和損耗张抄,當雙方沒有請求或響應傳遞時,任意一方都可以發(fā)起關閉請求洼怔。與創(chuàng)建TCP連接的3次握手類似署惯,關閉TCP連接,需要4次握手镣隶。
? ? ? ?所謂四次揮手(Four-Way Wavehand)即終止TCP連接极谊,就是指斷開一個TCP連接時,需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開安岂。在socket編程中轻猖,這一過程由客戶端或服務端任一方執(zhí)行close來觸發(fā),整個流程如下圖所示:

? ? ? ? 由于TCP連接是全雙工的域那,因此咙边,每個方向都必須要單獨進行關閉,這一原則是當一方完成數據發(fā)送任務后次员,發(fā)送一個FIN來終止這一方向的連接败许,收到一個FIN只是意味著這一方向上沒有數據流動了,即不會再收到數據了淑蔚,但是在這個TCP連接上仍然能夠發(fā)送數據市殷,直到這一方向也發(fā)送了FIN。首先進行關閉的一方將執(zhí)行主動關閉刹衫,而另一方則執(zhí)行被動關閉醋寝,上圖描述的即是如此。

(1)第一次揮手:Client發(fā)送一個FIN带迟,用來關閉Client到Server的數據傳送音羞,Client進入FIN_WAIT_1狀態(tài)。
(2)第二次揮手:Server收到FIN后仓犬,發(fā)送一個ACK給Client黄选,確認序號為收到序號+1(與SYN相同,一個FIN占用一個序號)婶肩,Server進入CLOSE_WAIT狀態(tài)。
(3)第三次揮手:Server發(fā)送一個FIN貌夕,用來關閉Server到Client的數據傳送律歼,Server進入LAST_ACK狀態(tài)。
(4)第四次揮手:Client收到FIN后啡专,Client進入TIME_WAIT狀態(tài)险毁,接著發(fā)送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態(tài)畔况,完成四次揮手鲸鹦。

? 上面是一方主動關閉,另一方被動關閉的情況跷跪,實際中還會出現同時發(fā)起主動關閉的情況馋嗜,具體流程如下圖:

?流程和狀態(tài)在上圖中已經很明了了,在此不再贅述吵瞻,可以參考前面的四次揮手解析步驟葛菇。

關于三次握手與四次揮手通常都會有典型的面試題,在此提出供有需求的XDJM們參考:
? ? (1)三次握手是什么或者流程橡羞?四次揮手呢眯停?答案前面分析就是。
? ? (2)為什么建立連接是三次握手卿泽,而關閉連接卻是四次揮手呢莺债?
? ? ? ?這是因為服務端在LISTEN狀態(tài)下,收到建立連接請求的SYN報文后签夭,把ACK和SYN放在一個報文里發(fā)送給客戶端齐邦。而關閉連接時,當收到對方的FIN報文時覆致,僅僅表示對方不再發(fā)送數據了但是還能接收數據侄旬,己方若全部數據都發(fā)送給對方了,所以己方可以立即close煌妈,也可以發(fā)送一些數據給對方后關閉儡羔,再發(fā)送FIN報文給對方來表示同意現在關閉連接,因此璧诵,己方ACK和FIN一般都會分開發(fā)送汰蜘。

匯總Web瀏覽器與Web服務器之間一次完整的HTTP通信過程
1. 建立TCP連接
? ? ? ?在HTTP工作開始之前,Web瀏覽器首先要通過網絡與Web服務器建立連接之宿,該連接是通過TCP來完成的族操,該協議與IP協議共同構建 Internet,即著名的TCP/IP協議族比被,因此Internet又被稱作是TCP/IP網絡色难。HTTP是比TCP更高層次的應用層協議,根據規(guī)則等缀, 只有低層協議建立之后才能進行更高層協議的連接枷莉,因此,首先要建立TCP連接尺迂,一般TCP連接的端口號是80或者443笤妙。

2. Web瀏覽器向Web服務器發(fā)送請求命令
? ? ?
一旦建立了TCP連接冒掌,Web瀏覽器就會向Web服務器發(fā)送請求命令。例如:GET/sample/hello.jsp HTTP/1.1蹲盘。

3. Web瀏覽器發(fā)送請求頭信息
? ? ?
瀏覽器發(fā)送其請求命令之后股毫,還要以頭信息的形式向Web服務器發(fā)送一些別的信息,之后瀏覽器發(fā)送了一空白行來通知服務器召衔,它已經結束了該頭信息的發(fā)送铃诬。

4.?Web服務器應答
? ??
客戶端向服務器發(fā)出請求后,服務器會客戶機回送應答薄嫡,?HTTP/1.1 200 OK 氧急,應答的第一部分是協議的版本號和應答狀態(tài)碼。

5.?Web服務器發(fā)送應答頭信息
? ??
服務器也會隨同應答向用戶發(fā)送關于它自己的數據及被請求的文檔毫深。

6.?Web服務器向瀏覽器發(fā)送數據
? ? ?
Web服務器向瀏覽器發(fā)送頭信息后吩坝,它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結束,接著哑蔫,它就以Content-Type應答頭信息所描述的格式發(fā)送用戶所請求的實際數據钉寝。

7.?Web服務器關閉TCP連接
? ??
一般情況下,一旦Web服務器向瀏覽器發(fā)送了請求數據闸迷,它就要關閉TCP連接嵌纲,然后如果瀏覽器或者服務器在其頭信息加入了這行代碼:

Connection:keep-alive
? ? ?TCP連接在發(fā)送后將仍然保持打開狀態(tài),于是腥沽,瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求逮走。保持連接節(jié)省了為每個請求建立新連接所需的時間,還節(jié)約了網絡帶寬今阳。

7师溅、瀏覽器解析資源
? ? ?
對于獲取到的HTML、CSS盾舌、JS墓臭、圖片等等資源。
? ? ?瀏覽器通過解析HTML妖谴,生成DOM樹窿锉,解析CSS,生成CSS規(guī)則樹膝舅,然后通過DOM樹和CSS規(guī)則樹生成渲染樹嗡载。渲染樹與DOM樹不同,渲染樹中并沒有head仍稀、display為none等不必顯示的節(jié)點鼻疮。
? ? ? 在解析CSS的同時,可以繼續(xù)加載解析HTML琳轿,但在解析執(zhí)行JS腳本時判沟,會停止解析后續(xù)HTML,這就會出現阻塞問題崭篡。

8挪哄、瀏覽器布局渲染
? ? ?
根據渲染樹布局,計算CSS樣式琉闪,即每個節(jié)點在頁面中的大小和位置等幾何信息迹炼。HTML默認是流式布局的,CSS和js會打破這種布局颠毙,改變DOM的外觀樣式以及大小和位置斯入。這時就要提到兩個重要概念:repaint和reflow。
? ? ? repaint:屏幕的一部分重畫蛀蜜,不影響整體布局刻两,比如某個CSS的背景色變了,但元素的幾何尺寸和位置不變滴某。
? ? ?reflow: 意味著元件的幾何尺寸變了磅摹,我們需要重新驗證并計算渲染樹。是渲染樹的一部分或全部發(fā)生了變化霎奢。這就是Reflow户誓,或是Layout。

? ? ? ?有些情況下幕侠,比如修改了元素的樣式帝美,瀏覽器并不會立刻 reflow 或 repaint 一次,而是會把這樣的操作積攢一批晤硕,然后做一次 reflow悼潭,這又叫異步 reflow 或增量異步 reflow。
? ? ? 有些情況下窗骑,比如 resize 窗口女责,改變了頁面默認的字體等。對于這些操作创译,瀏覽器會馬上進行 reflow抵知。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市软族,隨后出現的幾起案子刷喜,更是在濱河造成了極大的恐慌,老刑警劉巖立砸,帶你破解...
    沈念sama閱讀 222,807評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件掖疮,死亡現場離奇詭異,居然都是意外死亡颗祝,警方通過查閱死者的電腦和手機浊闪,發(fā)現死者居然都...
    沈念sama閱讀 95,284評論 3 399
  • 文/潘曉璐 我一進店門恼布,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人搁宾,你說我怎么就攤上這事折汞。” “怎么了盖腿?”我有些...
    開封第一講書人閱讀 169,589評論 0 363
  • 文/不壞的土叔 我叫張陵爽待,是天一觀的道長。 經常有香客問我翩腐,道長鸟款,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,188評論 1 300
  • 正文 為了忘掉前任茂卦,我火速辦了婚禮何什,結果婚禮上,老公的妹妹穿的比我還像新娘疙筹。我一直安慰自己富俄,他們只是感情好,可當我...
    茶點故事閱讀 69,185評論 6 398
  • 文/花漫 我一把揭開白布而咆。 她就那樣靜靜地躺著霍比,像睡著了一般。 火紅的嫁衣襯著肌膚如雪暴备。 梳的紋絲不亂的頭發(fā)上悠瞬,一...
    開封第一講書人閱讀 52,785評論 1 314
  • 那天,我揣著相機與錄音涯捻,去河邊找鬼浅妆。 笑死,一個胖子當著我的面吹牛障癌,可吹牛的內容都是我干的凌外。 我是一名探鬼主播,決...
    沈念sama閱讀 41,220評論 3 423
  • 文/蒼蘭香墨 我猛地睜開眼涛浙,長吁一口氣:“原來是場噩夢啊……” “哼康辑!你這毒婦竟也來了?” 一聲冷哼從身側響起轿亮,我...
    開封第一講書人閱讀 40,167評論 0 277
  • 序言:老撾萬榮一對情侶失蹤疮薇,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后我注,有當地人在樹林里發(fā)現了一具尸體按咒,經...
    沈念sama閱讀 46,698評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,767評論 3 343
  • 正文 我和宋清朗相戀三年但骨,在試婚紗的時候發(fā)現自己被綠了励七。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片智袭。...
    茶點故事閱讀 40,912評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖呀伙,靈堂內的尸體忽然破棺而出补履,到底是詐尸還是另有隱情,我是刑警寧澤剿另,帶...
    沈念sama閱讀 36,572評論 5 351
  • 正文 年R本政府宣布,位于F島的核電站贬蛙,受9級特大地震影響雨女,放射性物質發(fā)生泄漏。R本人自食惡果不足惜阳准,卻給世界環(huán)境...
    茶點故事閱讀 42,254評論 3 336
  • 文/蒙蒙 一氛堕、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧野蝇,春花似錦讼稚、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,746評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至乍狐,卻和暖如春赠摇,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背浅蚪。 一陣腳步聲響...
    開封第一講書人閱讀 33,859評論 1 274
  • 我被黑心中介騙來泰國打工藕帜, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人惜傲。 一個月前我還...
    沈念sama閱讀 49,359評論 3 379
  • 正文 我出身青樓洽故,卻偏偏與公主長得像,于是被迫代替她去往敵國和親盗誊。 傳聞我的和親對象是個殘疾皇子时甚,可洞房花燭夜當晚...
    茶點故事閱讀 45,922評論 2 361

推薦閱讀更多精彩內容