【筆記】謝希仁—計網(wǎng)五版:chapter eight 因特網(wǎng)上的音頻/視頻服務(wù)

本章對因特網(wǎng)提供音頻/視頻服務(wù)進(jìn)行概述,然后介紹流式音頻/視頻中的媒體服務(wù)器和實時流式協(xié)議RTSP,并以IP電話為例介紹交互式音頻/視頻所使用的一些協(xié)議,如實時傳送協(xié)議RTP、實時傳送控制協(xié)議RTCP锚赤、H.323以及會話發(fā)起協(xié)議SIP。接著討論改進(jìn)“盡最大努力交付”的服務(wù)的一些措施褐鸥,包括怎樣使因特網(wǎng)能夠提供服務(wù)質(zhì)量线脚,并介紹綜合服務(wù)IntServ、資源預(yù)留協(xié)議RSVP和區(qū)分服務(wù)DiffServ的要點晶疼。(無線局域網(wǎng)和下一代因特網(wǎng)不介紹)

一酒贬、概述

多媒體信息和傳統(tǒng)數(shù)據(jù)信息不同又憨。它是指內(nèi)容上相互關(guān)聯(lián)的文本翠霍、圖形、圖像蠢莺、聲音寒匙、動畫和活動圖像等所形成的復(fù)合數(shù)據(jù)信息。

多媒體的兩個特點:信息量往往很大液兽;在傳輸多媒體數(shù)據(jù)時锦募,對時延和時延抖動均有較高的要求欧穴。

模擬的多媒體信號只有經(jīng)過數(shù)字化后才能在因特網(wǎng)上傳送胖翰。就是對模擬信號要經(jīng)過采樣和模數(shù)轉(zhuǎn)換變?yōu)閿?shù)字信號乌妒,然后將一定數(shù)量的比特組裝成分組進(jìn)行發(fā)送箱残。這些分組在發(fā)送時的時間間隔都是恒定的志笼,通常稱這樣的分組是等時的韭脊。等時分組進(jìn)入因特網(wǎng)的速率也是恒定的掸鹅,但傳統(tǒng)的因特網(wǎng)本身是非等時的塞帐。這是因為

在使用IP協(xié)議的因特網(wǎng)中,每一個分組是獨立地傳送巍沙,因而這些分組在到達(dá)接收端時就會變成非等時的葵姥。如果我們在接收端對這些以非恒定速率到達(dá)的分組邊接收邊還原,那么就一定會產(chǎn)生很大的失真句携±菩遥看下圖。

要解決這個問題矮嫉,可在接收端設(shè)置適當(dāng)大小的緩存削咆,當(dāng)緩存中的分組數(shù)達(dá)到一定的數(shù)量后再以恒定速率按順序?qū)⑦@些分組讀出進(jìn)行還原播放〈浪瘢看下圖态辛。T叫做播放時延。這清除了時延的抖動挺尿。

有些問題未討論——

①播放時延T設(shè)置多大奏黑?大了,可消除更大的時延抖動编矾,但所有分組經(jīng)受的平均時延也增大了熟史,這對于實時應(yīng)用如視頻會議是很不利的。小了窄俏,消除時延抖動效果差蹂匹,因此折中考慮。

②在因特網(wǎng)上傳輸實時數(shù)據(jù)的分組時有可能會出現(xiàn)差錯或甚至丟失凹蜈。如果用TCP協(xié)議對這些差錯或丟失的分組進(jìn)行重傳限寞,那么時延就會大大增加。因此實時數(shù)據(jù)的傳輸在運(yùn)輸層就應(yīng)采用用戶數(shù)據(jù)報協(xié)議UDP而不使用TCP協(xié)議仰坦。這就是說履植,對于傳送實時數(shù)據(jù),我們寧可丟失少量分組悄晃,也不要太晚到達(dá)的分組玫霎。在連續(xù)音頻或視頻中,丟失少量的影響并不大。

由于分組的到達(dá)不按序庶近,但將分組還原和播放時又應(yīng)當(dāng)是按序的翁脆。因此在發(fā)送多媒體分組時還應(yīng)當(dāng)給每一個分組加上序號。這表明還應(yīng)當(dāng)有相應(yīng)的協(xié)議支持才行鼻种。

還有一種情況反番,就是要使接收端能夠?qū)⒐?jié)目中本來就存在的正常的短時間停頓(如音樂中停頓幾拍)和因某些分組的較大遲延造成的“停頓”區(qū)分開來。這就需要增加一個時間戳叉钥,以便告訴接收端應(yīng)當(dāng)在什么時間播放哪個分組恬口。

目前因特網(wǎng)提供的音頻/視頻服務(wù)有三種:

①流式存儲音頻/視頻

將已壓縮的錄制好的音頻/視頻文件存儲在服務(wù)器上。用戶可邊下載邊播放沼侣,這里下載沒有把內(nèi)容存儲在硬盤上祖能,這對保護(hù)版權(quán)有利。

②流式實況音頻/視頻

音頻/視頻節(jié)目不是事先錄制好和存儲在服務(wù)器中蛾洛,而是在發(fā)送方邊錄制邊發(fā)送(不是錄制完畢后發(fā)送)养铸。在接收時也是要求能夠連續(xù)播放。接收方收到節(jié)目的時間和節(jié)目中的事件的發(fā)生時間可以認(rèn)為是同時的轧膘。

③交互式音頻/視頻

是用戶使用因特網(wǎng)和其他人進(jìn)行實時交互式通信钞螟。

二、流式存儲音頻/視頻

為什么不在瀏覽器中直接播放音頻/視頻谎碍?——播放器沒有集成在萬維網(wǎng)瀏覽器中鳞滨,因此必須使用一個單獨的應(yīng)用程序來播放這種音頻/視頻節(jié)目,這個應(yīng)用程序通常稱為媒體播放器蟆淀。媒體播放器具有的主要功能:管理用戶界面拯啦、解壓縮、消除時延抖動和處理傳輸帶來的差錯熔任。

1.具有元文件的萬維網(wǎng)服務(wù)器

元文件:非常小褒链。描述或指明其他文件的一些重要信息。如音頻/視頻文件的信息疑苔。

①瀏覽器用戶點擊所要看的音頻/視頻文件的超鏈甫匹,使用HTTP的GET報文接入到萬維網(wǎng)服務(wù)器。實際上惦费,這個超鏈沒有直接指向所請求的音頻/視頻文件兵迅,而是指向一個元文件。這個元文件有實際的音頻/視頻文件的統(tǒng)一資源定位符URL薪贫。

②萬維網(wǎng)服務(wù)器把元文件裝入HTTP響應(yīng)報文的主體恍箭,發(fā)回瀏覽器。在響應(yīng)報文中還有指明該音頻/視頻文件類型的首部后雷。

③客戶機(jī)瀏覽器收到萬維網(wǎng)服務(wù)器的響應(yīng)季惯,分析其內(nèi)容類型首部,調(diào)用相關(guān)的媒體播放器臀突,把提取出的元文件傳送給媒體播放器勉抓。

④媒體播放器使用元文件中的URL直接和萬維網(wǎng)服務(wù)器建立TCP連接,并向萬維網(wǎng)服務(wù)器發(fā)送HTTP請求報文候学,要求下載瀏覽器想要的音頻/視頻文件藕筋。

⑤萬維網(wǎng)服務(wù)器發(fā)送HTTP響應(yīng)報文,把該音頻/視頻文件發(fā)送給媒體播放器梳码。媒體播放器在存儲了若干秒的音頻/視頻文件后(這是為了消除抖動)隐圾,就以音頻/視頻流的形式邊下載邊解壓縮邊播放。

2.媒體服務(wù)器

也稱為流式服務(wù)器掰茶。媒體服務(wù)器和萬維網(wǎng)服務(wù)器可以運(yùn)行在一個端系統(tǒng)內(nèi)暇藏,也可以運(yùn)行在兩個不同的端系統(tǒng)中。媒體服務(wù)器與普通萬維網(wǎng)服務(wù)器的最大區(qū)別就是濒蒋,媒體服務(wù)器支持流式音頻和視頻的傳送盐碱。看下圖步驟沪伙。

①~③同上瓮顽。

④媒體播放器使用元文件中的URL接入到媒體播放器,請求下載瀏覽器所請求的音頻/視頻文件围橡,下載可以借助于使用UDP的任何協(xié)議暖混,例如使用實時運(yùn)輸協(xié)議RTP(見8.3.3節(jié))

⑤媒體服務(wù)器給出響應(yīng),把該音頻/視頻文件發(fā)送給媒體播放器翁授。媒體播放器在延遲了若干秒后拣播,以流的形式邊下載邊解壓縮邊播放。

注意——

媒體服務(wù)器也可以在TCP連接上向媒體播放器傳送音頻/視頻文件收擦。由于TCP有重傳丟失報文段的功能诫尽,因此音頻/視頻文件還原后的質(zhì)量應(yīng)當(dāng)會更好些(只要重傳時不造成緩存的清空)。但如果網(wǎng)絡(luò)發(fā)生分組丟失而重傳時應(yīng)用程序的緩存已被抽空炬守,那么媒體服務(wù)器在播放音頻/視頻文件時就會出現(xiàn)暫停牧嫉。

3.實時流式協(xié)議RTSP

real-time streaming protocol。本身不傳達(dá)數(shù)據(jù)减途, 而僅僅是使媒體播放器能夠控制多媒體流的傳送(有點像文件傳送協(xié)議FTP有一個控制信道)酣藻,因此RTSP又稱為帶外協(xié)議(out-of-band protocol)。它能使用戶在播放從因特網(wǎng)下載的實時數(shù)據(jù)時能夠進(jìn)行控制鳍置,如暫停辽剧、播放、快進(jìn)税产、快退等怕轿。

RTSP的語法和操作與HTTP協(xié)議的相似(所有的請求和響應(yīng)報文都是ASCII文本)偷崩。但與HTTP不同的地方是RTSP是有狀態(tài)的協(xié)議(HTTP是無狀態(tài)的)。RTSP記錄客戶機(jī)所處于的狀態(tài)(初始化狀態(tài)撞羽、播放狀態(tài)或暫停狀態(tài))阐斜。RTSP控制分組即可在TCP上傳送,也可在UDP上傳送诀紊。RTSP沒有定義音頻/視頻的壓縮方案谒出,也沒有規(guī)定音頻/視頻在網(wǎng)絡(luò)中傳送時應(yīng)如何封裝在分組中。RTSP不規(guī)定音頻/視頻流在媒體播放器中應(yīng)如何緩存邻奠。

三笤喳、交互式音頻/視頻

1.IP電話概述

Ⅰ、狹義的和廣義的IP電話

狹義的IP電話就是指在IP網(wǎng)絡(luò)上打電話碌宴。IP網(wǎng)絡(luò)就是“使用IP協(xié)議的分組交換網(wǎng)”的簡稱杀狡。

廣義的IP電話則不僅僅是電話通信,而且還可以是在IP網(wǎng)絡(luò)上進(jìn)行交互式多媒體實時通信(包括語音贰镣、視像等)捣卤,甚至還包括即時傳信IM。即時傳信是在上網(wǎng)時就能從屏幕上得知有哪些朋友也正在上網(wǎng)八孝。

Ⅱ董朝、IP電話網(wǎng)關(guān)

是公用電話網(wǎng)與IP網(wǎng)絡(luò)的接口設(shè)備。作用是:①在電話呼叫階段和呼叫釋放階段進(jìn)行電話信令的轉(zhuǎn)換干跛;②在通話期間進(jìn)行話音編碼的轉(zhuǎn)換子姜。

Ⅲ、IP電話的通信質(zhì)量

IP電話的通話質(zhì)量與電路交換電話網(wǎng)的通信質(zhì)量有很大的差別楼入。在電路交換電話網(wǎng)中任何兩端之間的通信質(zhì)量都是有保證的哥捕。但I(xiàn)P電話則不然。IP電話的通信質(zhì)量主要由兩個因素決定嘉熊。一是通話雙方端到端的時延和時延抖動遥赚,二是話音分組的丟失率。但這兩個因素都是不確定的阐肤,而是取決于當(dāng)時網(wǎng)絡(luò)上的通信量凫佛。通信量大時,端到端時延和時延抖動以及分組丟失率都會很高孕惜。因此愧薛,一個用戶使用IP電話的通信質(zhì)量取決于當(dāng)時其他的許多用戶的行為。但是電路交換電話網(wǎng)的情況完全不是這樣衫画,當(dāng)電路交換網(wǎng)的通信質(zhì)量太大時毫炉,往往使我們無法接通電話(聽到的是忙音),即電話網(wǎng)拒絕對正在撥號的用戶提供接通服務(wù)削罩。但是只要我們撥通了電話瞄勾,那么電信公司就能保證讓用戶滿意的通話質(zhì)量费奸。

IP電話端到端時延是由以下幾個因素造成的:

(1)話音信號進(jìn)行模數(shù)交換要經(jīng)受時延。

(2)已經(jīng)數(shù)字化的話音比特流要積累到一定的數(shù)量才能夠裝配成一個話音分組进陡,這也產(chǎn)生時延愿阐。

(3)話音分組的發(fā)送需要時間,此時間等于話音分組長度與通信線路的數(shù)據(jù)率之比四濒。

(4)話音分組在Internet中經(jīng)過許多路由器的存儲轉(zhuǎn)發(fā)時延换况。

(5)話音分組到達(dá)接收端在緩沖區(qū)暫存所引起的時延职辨。

(6)最后將話音分組還原成模擬話音信號的數(shù)模轉(zhuǎn)換也要經(jīng)受一定的時延盗蟆。

(7)話音信號在通信線路上的傳播時延。

(8)由終端設(shè)備的硬件和操作系統(tǒng)產(chǎn)生的接入時延舒裤。

3和7:當(dāng)采用高速光纖主干網(wǎng)時喳资,3不大。話音信號在通信線路上的傳播時延一般很刑诠(衛(wèi)星通信除外)仆邓,7不考慮。

1伴鳖、2和6:取決于話音編碼的方法节值。有兩種標(biāo)準(zhǔn):G.729和G.723.1。

幀大小是壓縮到每一個分組中的話音信號時間長度榜聂。處理時間是對一個幀運(yùn)行編碼算法所需的時間搞疗。幀長是一個已編碼的幀的字節(jié)數(shù)(不包括首部)。數(shù)字信號處理MIPS(每秒百萬指令)是用數(shù)字信號處理芯片實現(xiàn)編碼所需的最小處理機(jī)速率须肆。

4和5:困難匿乃。當(dāng)網(wǎng)絡(luò)發(fā)生擁堵而產(chǎn)生話音分組丟失時,還必須采用一定的策略(稱為“丟失掩蔽算法”)對丟失的話音分組進(jìn)行處理豌汇。例如幢炸, 可使用前一個話音分組來填補(bǔ)丟失的話音分組的間隙。

接收端緩存空間和播放時延的大小對話音分組丟失率和端到端時延也有很大的影響拒贱⊥鸹玻看下圖。

最佳值是N逻澳,但不存在

舉例——Skype

2.IP電話所需要的幾種應(yīng)用協(xié)議

IP電話通信中岩调,至少需要兩種應(yīng)用協(xié)議。一種是信令協(xié)議赡盘,它使我們能夠在因特網(wǎng)上找到被叫用戶号枕。另一種是話音分組的傳送協(xié)議,它使我們用來進(jìn)行電話通信的話音數(shù)據(jù)能夠以時延敏感屬性在因特網(wǎng)中傳送陨享。這樣葱淳,為了在因特網(wǎng)中提供實時交互式的音頻/視頻服務(wù)钝腺,我們需要新的多媒體體系結(jié)構(gòu)。

?實時傳輸協(xié)議 [RTP] 和 實時控制協(xié)議 [RTCP]

四赞厕、改進(jìn)“盡最大努力交付”的服務(wù)

1.使因特網(wǎng)提供服務(wù)質(zhì)量

可設(shè)法增加一些機(jī)制艳狐,即:分組的分類、管制皿桑、調(diào)度以及呼叫接納

2.調(diào)度和管理機(jī)制

Ⅰ毫目、調(diào)度機(jī)制

調(diào)度是指排隊的規(guī)則,默認(rèn)先進(jìn)先出FIFO诲侮。但最大缺點是不能區(qū)分敏感分組和一般敏感分組镀虐。也可加上按優(yōu)先級排隊。

分組到達(dá)路由器后就由分類器(又稱為分類程序)對其進(jìn)行優(yōu)先級分類沟绪,然后按照類別進(jìn)入相應(yīng)的隊列刮便。優(yōu)先級排隊缺點是:在高優(yōu)先級隊列中總是有分組時,低優(yōu)先級隊列中的分組就長期得不到服務(wù)绽慈。

公平排隊FQ是對每種類別的分組流設(shè)置一個隊列恨旱,然后輪流使每一個隊列一次只能發(fā)送一個分組。對于空的隊列就跳過去坝疼。缺點是:長分組得到的服務(wù)時間長搜贤,而短分組就比較吃虧,并且公平排隊并沒有區(qū)分分組的優(yōu)先級钝凶。

可增加隊列“權(quán)重”的概念仪芒,這就是加權(quán)公平排隊WFQ


Ⅱ腿椎、管制機(jī)制

平均速率——指在一定的時間間隔內(nèi)通過的分組數(shù)桌硫。

峰值速率——限制了數(shù)據(jù)流在非常短的時間間隔內(nèi)的流量。

突發(fā)長度——網(wǎng)絡(luò)也現(xiàn)在在非常短的時間間隔內(nèi)連續(xù)注入到網(wǎng)絡(luò)中的分組數(shù)啃炸。

對上面三個指標(biāo)進(jìn)行管制铆隘,可用非常著名的漏洞管制器。工作原理如圖南用。

Ⅲ膀钠、漏桶機(jī)制與加權(quán)公平排隊相結(jié)合

3.綜合服務(wù)IntServ與資源預(yù)留協(xié)議RSVP

IntServ特點:

(1)資源預(yù)留。一個路由器需要知道不斷出現(xiàn)的會話已經(jīng)預(yù)留了多少資源(即鏈路帶寬和緩存空間)

(2)呼叫建立裹虫。在一個會話開始之前必須先有一個呼叫建立(又稱為呼叫接納)過程肿嘲,它需要在其分組傳輸路徑上的每一個路由器都參加。每一個路由器都要確定該會話所需的本地資源是否夠用筑公,同時還不要影響到已經(jīng)建立的會話的服務(wù)質(zhì)量雳窟。

IntServ定義了兩類服務(wù):

(1)有保證的服務(wù)

可保證每一個分組在通過路由器時的排隊時延有一個嚴(yán)格的上限。

(2)受控負(fù)載的服務(wù)

可以使應(yīng)用程序得到比通常的“盡最大努力”更加可靠的服務(wù)匣屡。

IntServ共有四個組成部分:

(1)資源預(yù)留協(xié)議RSVP封救,它是IntServ的信令協(xié)議

(2)接納控制拇涤,用來決定是否同意對某一資源的請求

(3)分類器,用來把進(jìn)入路由器的分組進(jìn)行分類誉结,并根據(jù)分類的結(jié)果把不同類別的分組放入特定的隊列鹅士。

(4)調(diào)度器,根據(jù)服務(wù)質(zhì)量要求決定分組發(fā)送的前后順序惩坑。

資源預(yù)留協(xié)議RSVP在進(jìn)行資源預(yù)留時采用了多播樹的方式掉盅,發(fā)送端發(fā)送PATH報文(即存儲路徑狀態(tài)報文)給所有的接收端指明通信量的特性。每個路由器都要轉(zhuǎn)發(fā)PATH報文以舒,而接收端用RESV報文(即資源預(yù)留請求報文)進(jìn)行響應(yīng)趾痘。路徑上的每個路由器對RESV報文的請求都可以拒絕或者接受。拒絕時稀轨,路由器就發(fā)送一個差錯報文給接收端扼脐,從而終止了這一信令過程岸军。接受時奋刽,鏈路帶寬和緩存空間就被分配到這個分組流,而相關(guān)的流狀態(tài)信息就保留在路由器中艰赞∮缎常“流”是在多媒體通信中的一個常用的名詞,定義為具有同樣的源IP地址方妖、源端口號狭魂、目的IP地址、目的端口號党觅、協(xié)議標(biāo)識符及服務(wù)質(zhì)量需求的一連串分組雌澄。

綜合服務(wù)IntServ體系結(jié)構(gòu)的問題:

(1)狀態(tài)信息的數(shù)量與流的數(shù)目成正比

(2)IntServ體系結(jié)構(gòu)復(fù)雜

(3)綜合服務(wù)IntServ所定義的服務(wù)質(zhì)量等級數(shù)量太少,不夠靈活

4.區(qū)分服務(wù)DiffServ

Ⅰ杯瞻、區(qū)分服務(wù)的基本概念

要點:

(1)力圖不改變網(wǎng)絡(luò)的基礎(chǔ)結(jié)構(gòu)镐牺,但在路由器中增加區(qū)分服務(wù)的功能。因此DiffSev將IP協(xié)議中原有8位的IPv4的服務(wù)器類型字段和IPv6的通信量類字段重新定義為區(qū)分服務(wù)DS魁莉。路由器根據(jù)DS字段的值來處理分組的轉(zhuǎn)發(fā)睬涧。因此利用DS字段的不同數(shù)值就可提供不同等級的服務(wù)質(zhì)量。前6位是區(qū)分服務(wù)碼點DSCP旗唁,后2位不使用CU(currently unused)畦浓。

在使用DS字段之前,因特網(wǎng)的ISP要和用戶商定一個服務(wù)等級協(xié)定SLA检疫。在SLA中指明了被支持的服務(wù)類別(可包括吞吐量讶请、分組丟失率、時延屎媳、時延抖動夺溢、網(wǎng)絡(luò)的可用性等)和每一類別所容許的通信量抹蚀。

(2)網(wǎng)絡(luò)被劃分為許多個DS域。DiffServ將所有的復(fù)雜性放在DS域的邊界結(jié)點企垦,而使DS內(nèi)部路由器工作得盡可能地簡單环壤。

(3)邊界路由器的功能多,可分為分類器和通信量調(diào)節(jié)器钞诡。

(4)DiffServ提供了聚合功能郑现。DiffServ是把若干個流根據(jù)其DS值聚合成少量的流。路由器對相同DS值的流都按相同的優(yōu)先級進(jìn)行轉(zhuǎn)發(fā)荧降。這就大大簡化了網(wǎng)絡(luò)內(nèi)部的路由器的轉(zhuǎn)發(fā)機(jī)制接箫。區(qū)分服務(wù)DiffServ不需要使用RSVP信令。


Ⅱ朵诫、每跳行為PHB

per-hop behavior辛友。行為是指轉(zhuǎn)發(fā)分組時路由器對分組是怎樣處理的。每條是強(qiáng)調(diào)行為只涉及到本路由器轉(zhuǎn)發(fā)的這一跳的行為剪返,而下一個路由器再怎么處理則與本路由器的處理無關(guān)废累。

分為迅速轉(zhuǎn)發(fā)PBH和確保轉(zhuǎn)發(fā)PBH。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末脱盲,一起剝皮案震驚了整個濱河市邑滨,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌钱反,老刑警劉巖掖看,帶你破解...
    沈念sama閱讀 206,126評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異面哥,居然都是意外死亡哎壳,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,254評論 2 382
  • 文/潘曉璐 我一進(jìn)店門尚卫,熙熙樓的掌柜王于貴愁眉苦臉地迎上來归榕,“玉大人,你說我怎么就攤上這事焕毫《卓溃” “怎么了?”我有些...
    開封第一講書人閱讀 152,445評論 0 341
  • 文/不壞的土叔 我叫張陵邑飒,是天一觀的道長循签。 經(jīng)常有香客問我,道長疙咸,這世上最難降的妖魔是什么县匠? 我笑而不...
    開封第一講書人閱讀 55,185評論 1 278
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上乞旦,老公的妹妹穿的比我還像新娘贼穆。我一直安慰自己,他們只是感情好兰粉,可當(dāng)我...
    茶點故事閱讀 64,178評論 5 371
  • 文/花漫 我一把揭開白布故痊。 她就那樣靜靜地躺著,像睡著了一般玖姑。 火紅的嫁衣襯著肌膚如雪愕秫。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 48,970評論 1 284
  • 那天焰络,我揣著相機(jī)與錄音戴甩,去河邊找鬼。 笑死闪彼,一個胖子當(dāng)著我的面吹牛甜孤,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播畏腕,決...
    沈念sama閱讀 38,276評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼缴川,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了郊尝?” 一聲冷哼從身側(cè)響起二跋,我...
    開封第一講書人閱讀 36,927評論 0 259
  • 序言:老撾萬榮一對情侶失蹤战惊,失蹤者是張志新(化名)和其女友劉穎流昏,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體吞获,經(jīng)...
    沈念sama閱讀 43,400評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡况凉,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,883評論 2 323
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了各拷。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片刁绒。...
    茶點故事閱讀 37,997評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖烤黍,靈堂內(nèi)的尸體忽然破棺而出知市,到底是詐尸還是另有隱情,我是刑警寧澤速蕊,帶...
    沈念sama閱讀 33,646評論 4 322
  • 正文 年R本政府宣布嫂丙,位于F島的核電站,受9級特大地震影響规哲,放射性物質(zhì)發(fā)生泄漏跟啤。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,213評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望隅肥。 院中可真熱鬧竿奏,春花似錦、人聲如沸腥放。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,204評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽秃症。三九已至平痰,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間伍纫,已是汗流浹背宗雇。 一陣腳步聲響...
    開封第一講書人閱讀 31,423評論 1 260
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留莹规,地道東北人赔蒲。 一個月前我還...
    沈念sama閱讀 45,423評論 2 352
  • 正文 我出身青樓,卻偏偏與公主長得像良漱,于是被迫代替她去往敵國和親舞虱。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,722評論 2 345

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