網(wǎng)絡(luò)相關(guān)

一拉鹃、HTTP 協(xié)議

HTTP 協(xié)議:超文本傳輸協(xié)議
是一種詳細(xì)規(guī)定了瀏覽器和萬(wàn)維網(wǎng)(WWW = World Wide Web)服務(wù)器之間互相通信的規(guī)則,通過(guò)因特網(wǎng)傳送萬(wàn)維網(wǎng)文檔的數(shù)據(jù)傳送協(xié)議袋哼。
HTTP 是基于 TCP 的應(yīng)用層協(xié)議
(OSI 網(wǎng)絡(luò)七層協(xié)議從上到下分別是 應(yīng)用層、表示層闸衫、會(huì)話層 涛贯、傳輸層、網(wǎng)絡(luò)層 蔚出、數(shù)據(jù)鏈路層弟翘、物理層)
請(qǐng)求報(bào)文和響應(yīng)報(bào)文
1、請(qǐng)求報(bào)文

POST /somedir/page.html HTTP/1.1
//以上是請(qǐng)求行:方法字段URL字段和HTTP版本字段
Host: www.user.com
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
user-agent: Mozilla/5.0. 
Accept-lauguage: fr
//以上是首部行
(此處必須有一空行) // 空行分割header 和清求內(nèi)容
name=world 請(qǐng)求體
--------------------------------------- 作用
Host 指明了該對(duì)象所在的主機(jī)
Connection Keep-Alive 首部行用來(lái)表明該瀏覽器告訴服務(wù)器使用持續(xù)連接
Content-Type x-www-form-urlencoded 首部行用來(lái)表明 HTTP 會(huì)將請(qǐng)求參數(shù)用 key1=val1&key2=val2 的方式進(jìn)行組織骄酗,并放到請(qǐng)求實(shí)體里面
User-agent 首部行用來(lái)指明用戶代理稀余,即向服務(wù)器發(fā)送請(qǐng)求的瀏覽器類型
Accept-lauguage 首部行表示用戶想得到該對(duì)象的法語(yǔ)版本(如果服務(wù)器中有這樣的對(duì)象的話),否則趋翻,服務(wù)器應(yīng)發(fā)送它的默認(rèn)版本

2睛琳、響應(yīng)報(bào)文

HTTP/1.1 200 OK
//以上是狀態(tài)行:幼議版本字段。猶態(tài)碼相應(yīng)狀態(tài)信息
Connection: close
Server: Apache/2.2.3(CentOS)
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html
Content-Length: 122
//以上是首部寧
(此處必須有一空行) //空行分割header和實(shí)體主體
(data data data data)//響應(yīng)實(shí)體主體

狀態(tài)碼及其相應(yīng)的短語(yǔ)指示了請(qǐng)求的結(jié)果踏烙。

狀態(tài)碼----- 對(duì)應(yīng)的短語(yǔ)
200 OK 請(qǐng)求成功师骗,信息在返回的響應(yīng)報(bào)文中
301 MovedPermanently 請(qǐng)求的對(duì)象已經(jīng)被永久轉(zhuǎn)移了,新的 URL 定義在響應(yīng)報(bào)文中的 Location:首部行中讨惩”侔客戶軟件將自動(dòng)獲取新的 URL
400 BadRequest 一個(gè)通用差錯(cuò)代碼,指示該請(qǐng)求不能被服務(wù)器理解
404 NotFound 被請(qǐng)求的文件不在服務(wù)器上
505 HTTPVersionNotSupported 服務(wù)器不支持請(qǐng)求報(bào)文使用的 HTTP 協(xié)議版本 <4 開(kāi)頭的狀態(tài)碼通常是客戶端的問(wèn)題荐捻,5 開(kāi)頭的則通常是服務(wù)端的問(wèn)題>
-------------------------------- 作用
Connection close 首部行告訴客戶黍少,發(fā)送完報(bào)文后將關(guān)閉 TCP 連接。
Date 指的不是對(duì)象創(chuàng)建或最后修改的時(shí)間靴患,而是服務(wù)器從文件系統(tǒng)中檢索到該對(duì)象仍侥,插入到響應(yīng)報(bào)文, 并發(fā)送該響應(yīng)報(bào)文的時(shí)間鸳君。
Server 首部行指示該報(bào)文是由一臺(tái)ApacheWeb服務(wù)器產(chǎn)生的农渊, 類似于HTTP請(qǐng)求報(bào)文里的User-agent
Content-Length 首部行指示了被發(fā)送對(duì)象中的字節(jié)數(shù)
Content-Type 首部行指示了實(shí)體體中的對(duì)象是 HTML 文本
二、HTTP 的請(qǐng)求方式

GET、POST砸紊、PUT传于、DELETE、HEAD醉顽、OPTIONS

1沼溜、GET 和 POST 方式的區(qū)別
從語(yǔ)法角度來(lái)看,最直觀的區(qū)別就是

  • GET 的請(qǐng)求參數(shù)一般以?分割拼接到 URL 后面游添,POST 請(qǐng)求參數(shù)在 Body 里面
  • GET 參數(shù)長(zhǎng)度限制為 2048 個(gè)字符系草,POST 一般是沒(méi)限制的
  • GET 請(qǐng)求由于參數(shù)裸露在 URL 中, 是不安全的唆涝,POST 請(qǐng)求則是相對(duì)安全找都。
    之所以說(shuō)是相對(duì)安全,是因?yàn)槔群ǎ绻?POST 雖然參數(shù)非明文能耻,但如果被抓包,GET 和 POST 一樣都是不 安全的亡驰。(HTTPS 該用還是得用)

而從語(yǔ)義的角度來(lái)看:
GET:獲取資源是 安全的晓猛,冪等的(只讀的,純粹的)凡辱, 可緩存的
POST:獲取資源是 非安全的戒职,非冪等的,不可緩存的

  • 這里的安全是指不應(yīng)引起 Server 端的任何狀態(tài)變化
    GET 的語(yǔ)義就是獲取數(shù)據(jù)透乾,是不會(huì)引起服務(wù)器的狀態(tài)變化的帕涌,即是安全的(HEAD,OPTIONS 也是安全的)
    而 POST 語(yǔ)義則是提交數(shù)據(jù)续徽,是可能會(huì)引起服務(wù)器狀態(tài)變化的蚓曼,即是不安全的
  • 冪等:同一個(gè)請(qǐng)求方法執(zhí)行多次和執(zhí)行一次的效果完全相同
    顯然 GET 請(qǐng)求是冪等而 POST 請(qǐng)求是非冪等的。
    這里用冪等形容 GET 還不夠钦扭,因?yàn)?GET 不止是執(zhí)行多次和執(zhí)行一次的效果完全相同纫版,而且是執(zhí)行一次和執(zhí)行零次的效果也是完全相同的。
  • 可緩存的
    請(qǐng)求是否可以被緩存客情。
    GET 請(qǐng)求會(huì)主動(dòng)進(jìn)行 Cache

以上特性其弊,并非并列,正是因?yàn)?GET 是冪等的只讀的膀斋,即 GET 請(qǐng)求除了返回?cái)?shù)據(jù)不會(huì)有其他副作用梭伐,所以 GET 才是安全的,從而可以直接由 CDN 緩存仰担,大大減輕服務(wù)器的負(fù)擔(dān)糊识,也就是可緩存的。 而 POST 是非冪等的,即除了返回?cái)?shù)據(jù)還會(huì)有其他副作用赂苗,所以 POST 是不安全的愉耙,必須交由 web 服務(wù)器處 理,即是 不可緩存的
GET 和 POST 本質(zhì)上就是 TCP 鏈接拌滋,并無(wú)差別朴沿。但是由于 HTTP 的規(guī)定和瀏覽器/服務(wù)器的限制,導(dǎo)致他們 在應(yīng)用過(guò)程中體現(xiàn)出一些不同败砂。
在響應(yīng)時(shí)赌渣,GET 產(chǎn)生一個(gè) TCP 數(shù)據(jù)包;POST 產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包: 對(duì)于 GET 方式的請(qǐng)求昌犹,瀏覽器會(huì)把 Header 和實(shí)體主體一并發(fā)送出去锡垄,服務(wù)器響應(yīng) 200(返回?cái)?shù)據(jù)); 而對(duì)于 POST祭隔,瀏覽器先發(fā)送 Header,服務(wù)器響應(yīng) 100Continue路操,瀏覽器再發(fā)送實(shí)體主體疾渴,服務(wù)器響應(yīng) 200OK (返回?cái)?shù)據(jù))。

2屯仗、GET 相對(duì) POST 的優(yōu)勢(shì)是什么搞坝?

  • 最大的優(yōu)勢(shì)就是方便。GET 的 URL 可以直接手輸魁袜,從而 GET 請(qǐng)求中的 URL 可以被存在書簽里桩撮,或者歷史記錄里
  • 可以被緩存,大大減輕服務(wù)器的負(fù)擔(dān)
    所以大多數(shù)情況下峰弹,還是用 GET 比較好店量。
三、HTTP 的特點(diǎn)

無(wú)連接鞠呈、 無(wú)狀態(tài)
HTTP 的持久連接融师、Cookie/Session
1、HTTP 的無(wú)狀態(tài)
即協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力蚁吝。
每次的請(qǐng)求都是獨(dú)立的旱爆,它的執(zhí)行情況和結(jié)果與前面的請(qǐng)求和之后的請(qǐng)求時(shí)無(wú)直接關(guān)系的,它不會(huì)受前面的請(qǐng)求應(yīng)答情況直接影響窘茁,也不會(huì)直接影響后面的請(qǐng)求應(yīng)答情況
也就是說(shuō)服務(wù)器中沒(méi)有保存客戶端的狀態(tài)怀伦,客戶端必須每次帶上自己的狀態(tài)去請(qǐng)求服務(wù)器
標(biāo)準(zhǔn)的 HTTP 協(xié)議指的是不包括 cookies,session山林,application 的 HTTP 協(xié)議

2房待、HTTP 的持久連接

HTTP的持久連接

連接 處理能力
非持久連接 每個(gè)連接處理一個(gè)請(qǐng)求-響應(yīng)事務(wù)。
持久連接 每個(gè)連接可以處理多個(gè)請(qǐng)求-響應(yīng)事務(wù)。

持久連接情況下吴攒,服務(wù)器發(fā)出響應(yīng)后讓 TCP 連接繼續(xù)打開(kāi)著张抄。同一對(duì)客戶/服務(wù)器之間的后續(xù)請(qǐng)求和響應(yīng)可 以通過(guò)這個(gè)連接發(fā)送。
HTTP/1.0使用非持久連接洼怔。HTTP/1.1 默認(rèn)使用持久連接<keep-alive>署惯。

非持久連接的每個(gè)連接,TCP 得在客戶端和服務(wù)端分配 TCP 緩沖區(qū)镣隶,并維持 TCP 變量极谊,會(huì)嚴(yán)重增加服務(wù)器 負(fù)擔(dān)。而且每個(gè)對(duì)象都有 2 個(gè)RTT(RoundTripTime安岂,也就是一個(gè)數(shù)據(jù)包從發(fā)出去到回來(lái)的時(shí)間)的延遲轻猖,由 于 TCP 的擁塞控制方案,每個(gè)對(duì)象都遭受 TCP 緩啟動(dòng),因?yàn)槊總€(gè) TCP 連接都起始于緩啟動(dòng)階段

3域那、HTTP 持久連接怎么判斷一個(gè)請(qǐng)求是否結(jié)束的咙边?

  • Content-length:根據(jù)所接收字節(jié)數(shù)是否達(dá)到 Content-length
  • chunked(分塊傳輸):Transfer-Encoding。當(dāng)選擇分塊傳輸時(shí)次员,響應(yīng)頭中可以不包含 Content-Length败许,服務(wù)器會(huì)先回復(fù)一個(gè)不帶數(shù)據(jù)的報(bào)文(只有響應(yīng)行和響應(yīng)頭和\r\n),然后開(kāi)始 傳輸若干個(gè)數(shù)據(jù)塊淑蔚。當(dāng)傳輸完若干個(gè)數(shù)據(jù)塊后市殷,需要再傳輸一個(gè)空的數(shù)據(jù)塊,當(dāng)客戶端收到空的數(shù)據(jù)塊時(shí)刹衫,則客戶端知道數(shù)據(jù)接收完畢醋寝。
四、HTTPS带迟、對(duì)稱加密音羞、非對(duì)稱加密

1、HTTPS 和 HTTP 的區(qū)別
HTTPS 協(xié)議 = HTTP 協(xié)議 + SSL/TLS 協(xié)議
SSL 的全稱是 Secure Sockets Layer仓犬,即安全套接層協(xié)議黄选,是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS 的全稱是 Transport Layer Security婶肩,即安全傳輸層協(xié)議办陷。
即 HTTPS 是安全的 HTTP。

2律歼、HTTPS 的連接建立流程
HTTPS 為了兼顧安全與效率民镜,同時(shí)使用了對(duì)稱加密和非對(duì)稱加密。在傳輸?shù)倪^(guò)程中會(huì)涉及到三個(gè)密鑰:

  • 服務(wù)器端的公鑰和私鑰险毁,用來(lái)進(jìn)行非對(duì)稱加密
  • 客戶端生成的隨機(jī)密鑰制圈,用來(lái)進(jìn)行對(duì)稱加密


    HTTPS 連接過(guò)程

    如上圖们童,HTTPS 連接過(guò)程大致可分為八步:
    1、客戶端訪問(wèn) HTTPS 連接鲸鹦。
    客戶端會(huì)把安全協(xié)議版本號(hào)慧库、客戶端支持的加密算法列表、隨機(jī)數(shù)C發(fā)給服務(wù)端馋嗜。
    2齐板、服務(wù)端發(fā)送證書給客戶端
    服務(wù)端接收密鑰算法配件后,會(huì)和自己支持的加密算法列表進(jìn)行比對(duì)葛菇,如果不符合甘磨,則斷開(kāi)連接。否則眯停, 服務(wù)端會(huì)在該算法列表中济舆,選擇一種對(duì)稱算法(如 AES)、一種公鑰算法(如具有特定秘鑰長(zhǎng)度的 RSA)和 一種 MAC 算法發(fā)給客戶端莺债。 服務(wù)器端有一個(gè)密鑰對(duì)滋觉,即公鑰和私鑰,是用來(lái)進(jìn)行非對(duì)稱加密使用的齐邦,服務(wù)器端保存著私鑰椎侠,不能將其
    泄露,公鑰可以發(fā)送給任何人侄旬。 在發(fā)送加密算法的同時(shí)還會(huì)把數(shù)字證書和隨機(jī)數(shù)S發(fā)送給客戶端
    3、客戶端驗(yàn)證 server 證書
    會(huì)對(duì) server 公鑰進(jìn)行檢查煌妈,驗(yàn)證其合法性儡羔,如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問(wèn)題,那么 HTTPS 傳輸就無(wú)法繼續(xù)璧诵。
    4汰蜘、客戶端組裝會(huì)話秘鑰
    如果公鑰合格,那么客戶端會(huì)用服務(wù)器公鑰來(lái)生成一個(gè)前主秘鑰(Pre-MasterSecret之宿,PMS)族操,并通過(guò)該前主 秘鑰和隨機(jī)數(shù) C、S 來(lái)組裝成會(huì)話秘鑰
    5比被、客戶端將前主秘鑰加密發(fā)送給服務(wù)端
    是通過(guò)服務(wù)端的公鑰來(lái)對(duì)前主秘鑰進(jìn)行非對(duì)稱加密色难,發(fā)送給服務(wù)端
    6、服務(wù)端通過(guò)私鑰解密得到前主秘鑰
    服務(wù)端接收到加密信息后等缀,用私鑰解密得到主秘鑰枷莉。
    7涤久、服務(wù)端組裝會(huì)話秘鑰
    服務(wù)端通過(guò)前主秘鑰和隨機(jī)數(shù) C卷谈、S 來(lái)組裝會(huì)話秘鑰。 至此淹父,服務(wù)端和客戶端都已經(jīng)知道了用于此次會(huì)話的主秘鑰。
    8蹲盘、數(shù)據(jù)傳輸
    客戶端收到服務(wù)器發(fā)送來(lái)的密文股毫,用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密,得到服務(wù)器發(fā)送的數(shù)據(jù)召衔。
    同理铃诬,服務(wù)端收到客戶端發(fā)送來(lái)的密文,用服務(wù)端密鑰對(duì)其進(jìn)行對(duì)稱解密薄嫡,得到客戶端發(fā)送的數(shù)據(jù)氧急。
    總結(jié):
    會(huì)話秘鑰 =randomS + randomC + 前主秘鑰

  • HTTPS 連接建立過(guò)程使用非對(duì)稱加密,而非對(duì)稱加密是很耗時(shí)的一種加密方式
  • 后續(xù)通信過(guò)程使用對(duì)稱加密毫深,減少耗時(shí)所帶來(lái)的性能損耗
  • 其中吩坝,對(duì)稱加密加密的是實(shí)際的數(shù)據(jù),非對(duì)稱加密加密的是對(duì)稱加密所需要的客戶端的密鑰哑蔫。
五钉寝、對(duì)稱加密和非對(duì)稱加密

1、對(duì)稱加密
用同一套密鑰來(lái)進(jìn)行加密解密闸迷。 對(duì)稱加密通常有 DES,IDEA,3DES 加密算法嵌纲。
2、非對(duì)稱加密
用公鑰和私鑰來(lái)加解密的算法腥沽。 公鑰(PublicKey)與私鑰(PrivateKey)是通過(guò)一種算法得到的一個(gè)密鑰對(duì)(即一個(gè)公鑰和一個(gè)私鑰)逮走, 公鑰是密鑰對(duì)中公開(kāi)的部分,私鑰則是非公開(kāi)的部分,私鑰通常是保存在本地今阳。

  • 用公鑰進(jìn)行加密师溅,就要用私鑰進(jìn)行解密;反之盾舌,用私鑰加密墓臭,就要用公鑰進(jìn)行解密(數(shù)字簽名)。
  • 由于私鑰是保存在本地的妖谴,所以非對(duì)稱加密相對(duì)與對(duì)稱加密是安全的窿锉。 但非對(duì)稱加密比對(duì)稱加密耗時(shí)(100 倍以上),所以通常要結(jié)合對(duì)稱加密來(lái)使用。

常見(jiàn)的非對(duì)稱加密算法有:RSA膝舅、ECC(移動(dòng)設(shè)備用)嗡载、Diffie-Hellman、ElGamal仍稀、DSA(數(shù)字簽名用)
而為了確北谴客戶端能夠確認(rèn)公鑰就是想要訪問(wèn)的網(wǎng)站的公鑰,引入了數(shù)字證書的概念琳轿,由于證書存在一級(jí) 一級(jí)的簽發(fā)過(guò)程判沟,所以就出現(xiàn)了證書鏈耿芹,在證書鏈中的頂端的就是根 CA。

六挪哄、TCP 的特點(diǎn)和報(bào)文結(jié)構(gòu)

1吧秕、面向連接、可靠傳輸迹炼、面向字節(jié)流砸彬、全雙工服務(wù)
2、TCP 的報(bào)文結(jié)構(gòu)
TCP 報(bào)文段由首部字段和一個(gè)數(shù)據(jù)字段組成斯入。 數(shù)據(jù)字段包含一塊應(yīng)用數(shù)據(jù)砂碉。最大報(bào)文長(zhǎng)度MSS(MaximumSegmentSize)限制了報(bào)文段數(shù)據(jù)字段的最大 長(zhǎng)度。MSS選項(xiàng)用于在 TCP 連接建立時(shí)刻两,收發(fā)雙方協(xié)商通信時(shí)每一個(gè)報(bào)文段所能承載的最大數(shù)據(jù)長(zhǎng)度增蹭。 所以當(dāng) TCP 發(fā)送一個(gè)大文件(比如一張高清圖片)時(shí),通常是將該文件劃分為MSS長(zhǎng)度的若干塊(最后一 塊除外磅摹,通常會(huì)小于MSS)滋迈。而實(shí)際交互式應(yīng)用通常傳送長(zhǎng)度小于MSS的數(shù)據(jù)塊。

TCP 的報(bào)文結(jié)構(gòu)

如圖户誓,與 UDP 一樣饼灿,首部包括源端口號(hào)和目的端口號(hào),用于多路復(fù)用/分解來(lái)自 上層或送到上層應(yīng)用的數(shù)據(jù)帝美。TCP 首部也同樣包括檢驗(yàn)和字段

TCP 首部還包含下列字段:

  • 32比特的序號(hào)字段Seq(sequencenumberfield) 和32比特的確認(rèn)號(hào)字段Ack(acknowledgenumberfield)
  • 16 比特的接收窗口字段 RW(receivewindowfield),該字段用于流量控制碍彭,用于指示接收方愿意接收的字 節(jié)數(shù)量。
  • 4 比特的首部長(zhǎng)度字段(headerlengthfield)悼潭,該字段指示了以 32 比特的字為單位的 TCP 首部長(zhǎng)度庇忌。 由于 TCP 選項(xiàng)字段的原因,TCP 首部長(zhǎng)度是可變的女责。(通常漆枚,選項(xiàng)字段為空创译,所以 TCP 首部的典型長(zhǎng) 度就是 20 字節(jié))
  • 可選和變長(zhǎng)的選項(xiàng)字段(optionfield)抵知,該字段用于發(fā)送方和接收方協(xié)商最大報(bào)文段長(zhǎng)度(MSS)時(shí), 或用作窗口調(diào)節(jié)因子時(shí)使用软族。
  • 6 比特的標(biāo)志字段(flagfield)刷喜。ACK 比特用于指示確認(rèn)字段中的值是有效的,即該報(bào)文段包括一個(gè)對(duì) 已被接收?qǐng)?bào)文段的確認(rèn)立砸。RST掖疮、SYN、FIN 比特用于連接建立和拆除颗祝。 PSH 比特指示接收方應(yīng)立即將數(shù)據(jù)交給上層浊闪。URG 比特用于指示報(bào)文段里存在著被發(fā)送端的上層實(shí)體 置為“緊急”的數(shù)據(jù)恼布。緊急數(shù)據(jù)的最后一個(gè)字節(jié)由 16 比特的緊急數(shù)據(jù)指針字段指出。當(dāng)緊急數(shù)據(jù)存在 并給出指向緊急數(shù)據(jù)尾的指針的時(shí)候搁宾,TCP 必須通知接收端的上層實(shí)體折汞。在實(shí)踐中,PSH盖腿、URG 和緊 急數(shù)據(jù)指針并沒(méi)有使用

3爽待、序號(hào)字段 Seq 和確認(rèn)號(hào)字段 Ack

  • 在 TCP 通訊中,無(wú)論是建立連接翩腐,數(shù)據(jù)傳輸鸟款,友好斷開(kāi),強(qiáng)制斷開(kāi)茂卦,都離不開(kāi) Seq 值和 Ack 值何什,它們 是 TCP 傳輸?shù)目煽勘WC。
  • 序號(hào) Seq: TCP 把數(shù)據(jù)看成一個(gè)無(wú)結(jié)構(gòu)的疙筹、有序的字節(jié)流富俄。一個(gè)報(bào)文段的序號(hào)因此是該報(bào)文段的首字節(jié)的字節(jié)流編號(hào)。 比如數(shù)據(jù)流由一個(gè)包含100000字節(jié)的文件組成而咆,其MSS是1000字節(jié)霍比,數(shù)據(jù)流的首字節(jié)編號(hào)是 0。該 TCP 將為該數(shù)據(jù)流構(gòu)建100個(gè)報(bào)文段暴备。給第一個(gè)報(bào)文段分配序號(hào) 0悠瞬,第二個(gè)則是1000,第三個(gè)是2000涯捻,以此 類推浅妆。每一個(gè)序號(hào)被填入到相應(yīng) TCP 報(bào)文段首部的序號(hào)字段中。
  • 確認(rèn)號(hào) Ack: TCP 是全雙工服務(wù)的障癌,因此主機(jī) A 在向主機(jī) B 發(fā)送數(shù)據(jù)的同時(shí)凌外,也許也在接收主機(jī) B 的數(shù)據(jù)。 主機(jī) A 填充進(jìn)報(bào)文段的確認(rèn)號(hào)是主機(jī) A 期望從主機(jī) B 收到的下一個(gè)字節(jié)的序號(hào)涛浙。
    在上個(gè)例子中康辑,假如服務(wù)端已經(jīng)接收包含字節(jié)0-999的報(bào)文段和包含字節(jié)2000-2999的報(bào)文段,但由于 某種原因轿亮,還未收到包含字節(jié)1000-1999的報(bào)文段疮薇,那么將仍會(huì)等待字節(jié)1000(及其后的字節(jié))。因此 服務(wù)端發(fā)給客戶端的下一個(gè)報(bào)文段將在確認(rèn)號(hào) Ack 字段中包含 1000我注。 因?yàn)?TCP 只確認(rèn)該流中至第一個(gè)丟失字節(jié)為止的字節(jié)按咒,所以 TCP 被稱為累積確認(rèn)。
七但骨、三次握手

數(shù)據(jù)開(kāi)始傳輸前励七,需要通過(guò) 三次握手來(lái)建立連接
事實(shí)上我認(rèn)為智袭,這里稱呼三步握手(three-way handshake)才更貼切些

TCP 三次握手?jǐn)?shù)據(jù)交互

第一步:

  • 客戶端的 TCP 首先向服務(wù)端的 TCP 發(fā)送一條特殊的 TCP 報(bào)文段。該報(bào)文段不包含應(yīng)用層數(shù)據(jù)掠抬,該報(bào)文 段首部中的一個(gè)標(biāo)志位(SYN比特)被置為 1补履,所以該報(bào)文段被稱為 SYN 報(bào)文段。另外剿另,客戶會(huì)隨機(jī) 選擇一個(gè)初始序號(hào)client_isn箫锤,并將該序號(hào)放置于該起始的 TCPSYN報(bào)文段的序號(hào)字段中。
  • 客戶端和服務(wù)端最開(kāi)始都處于CLOSED狀態(tài)雨女,發(fā)送過(guò)該 SYN報(bào)文段后谚攒,客戶端 TCP 進(jìn)入SYN_SENT 狀態(tài),等待服務(wù)端確認(rèn)并將 SYN 比特置為 1 的報(bào)文段氛堕。

第二步:

  • 收到 SYN 報(bào)文段后馏臭,服務(wù)端會(huì)為該 TCP 連接分配 TCP 緩存和變量,服務(wù)端 TCP 會(huì)進(jìn)入SYN_RCVD狀 態(tài)讼稚,等待客戶端 TCP 發(fā)送確認(rèn)報(bào)文段括儒。
  • 并向該客戶端 TCP 發(fā)送允許連接的報(bào)文段,該報(bào)文段同樣不包含應(yīng)用層數(shù)據(jù)锐想。該報(bào)文段首部的 SYN 比特被置為 1帮寻,確認(rèn)號(hào)字段被置為client_isn+1。服務(wù)端還會(huì)選擇自己的初始序號(hào)server_isn赠摇, 放到報(bào)文段首部的序號(hào)段中固逗。該連接被稱為 SYNACK 報(bào)文段。

第三步:

  • 收到 SYNACK 報(bào)文段后藕帜,客戶端也要為該 TCP 連接分配緩存和變量烫罩,客戶端 TCP 進(jìn)入ESTABLISHED 狀態(tài),在此狀態(tài)洽故,客戶端就能發(fā)送和接收包含有效載荷數(shù)據(jù)的報(bào)文段了贝攒。
  • 并向服務(wù)端 TCP 發(fā)送一個(gè)報(bào)文段:這最后一個(gè)報(bào)文段對(duì)服務(wù)端的允許連接的報(bào)文表示了確認(rèn)(將 server_isn+1 放到報(bào)文段首部的確認(rèn)字段中)。因?yàn)檫B接已經(jīng)建立了时甚,所以該SYN比特被置為 0隘弊。 這個(gè)階段吻贿,可以在報(bào)文段負(fù)載中攜帶應(yīng)用層數(shù)據(jù)榨惠。
  • 收到客戶端該報(bào)文段后姓建,服務(wù)端 TCP 也會(huì)進(jìn)入ESTABLISHED狀態(tài),可以發(fā)送和接收包含有效載荷數(shù)據(jù)的報(bào)文段唧瘾。
八、四次揮手

參與 TCP 連接的兩個(gè)進(jìn)程中的任何一個(gè)都能終止該連接获诈,當(dāng)連接結(jié)束后镣屹,主機(jī)中的資源(緩存和變量)會(huì)被釋放。
上邊說(shuō)到,SYN 和 FIN 標(biāo)志位分別對(duì)應(yīng)著 TCP 連接的建立和拆除。


第一步:

  • 客戶應(yīng)用進(jìn)程發(fā)出一個(gè)關(guān)閉連接的指令溢豆。會(huì)引起客戶端 TCP 向服務(wù)端發(fā)送一個(gè)特殊的 TCP 報(bào)文段。該 報(bào)文段即是將首部的一個(gè)標(biāo)志位FIN比特置為 1。
  • 同時(shí)迹栓,客戶端進(jìn)入FIN_WAIT_1狀態(tài),等待服務(wù)端的帶有確認(rèn)的 TCP 報(bào)文段扔役。

第二步:

  • 收到該報(bào)文段后會(huì)向客戶端發(fā)送一個(gè)確認(rèn)報(bào)文段亿胸。
  • 服務(wù)端 TCP 進(jìn)入CLOSE_WAIT狀態(tài)宾添,對(duì)應(yīng)客戶端的TIME_WAIT沪袭,表示被動(dòng)關(guān)閉侠鳄。
  • 客戶端收到該報(bào)文段后,進(jìn)入FIN_WAIT_2狀態(tài)死宣,等待服務(wù)端的 FIN 比特置為 1 的報(bào)文段伟恶。

第三步:

  • 服務(wù)端發(fā)送自己的終止報(bào)文段,同樣是把報(bào)文段首部的標(biāo)志位FIN比特置為 1毅该。 ? 服務(wù)端 TCP 進(jìn)入LAST_ACK狀態(tài)博秫,等待服務(wù)端最后的確認(rèn)報(bào)文段。

第四步:

  • 客戶端收到服務(wù)端的終止報(bào)文段后眶掌,向服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文段挡育。同時(shí),客戶端進(jìn)入TIME_WAIT 狀態(tài)朴爬。
  • 假如 ACK 丟失即寒,TIME_WAIT 狀態(tài)使 TCP 客戶重傳最后的確認(rèn)報(bào)文,TIME_WAIT 通常會(huì)等待 2MSL (MaximumSegmentLifetime 最長(zhǎng)報(bào)文段壽命)召噩。經(jīng)過(guò)等待后母赵,連接就正式關(guān)閉,重新進(jìn)入CLOSED 狀態(tài)具滴,客戶端所有資源將被釋放市咽。
  • 服務(wù)端收到該報(bào)文段后,同樣也會(huì)關(guān)閉抵蚊,重新進(jìn)入CLOSED狀態(tài)施绎,釋放所有服務(wù)端 TCP 資源

一些問(wèn)題
1溯革、問(wèn):為什么建立連接只用三次握手,而斷開(kāi)連接卻要四次揮手谷醉?

  • 首先致稀,當(dāng)客戶端數(shù)據(jù)已發(fā)送完畢,且知道服務(wù)端也全部接收到了時(shí)俱尼,就會(huì)去斷開(kāi)連接即向服務(wù)端發(fā)送 FIN
  • 服務(wù)端接收到客戶端的 FIN抖单,為了表示接收到了,就會(huì)向客戶端發(fā)送 ACK ? 但此時(shí)遇八,服務(wù)端可能還在發(fā)送數(shù)據(jù)矛绘,并沒(méi)有關(guān)閉 TCP 窗口的意思,所以服務(wù)端的 FIN 和 ACK 并不是同 步發(fā)的刃永,只有當(dāng)數(shù)據(jù)發(fā)送完了货矮,才會(huì)發(fā)送 FIN
  • 答:服務(wù)端的 FIN 和 ACK 需要分開(kāi)發(fā),并不是像三次握手中那樣斯够,SYN 可以和 ACK 同步發(fā)囚玫,所以就需 要四次揮手

2、在四次揮手中读规,客戶端為什么在 TIME_WAIT 后必須等待 2MSL 時(shí)間呢抓督?
這個(gè)ACK報(bào)文段有可能丟失,因而使處在LAST_ACK端的服務(wù)端收不到對(duì)已發(fā)送的FIN報(bào)文段的ACK報(bào) 文段束亏,從而服務(wù)端會(huì)去不斷重傳FIN報(bào)文段铃在。 而客戶端就能在 2MSL時(shí)間內(nèi)收到重傳的FIN報(bào)文段。接著客戶端重傳一次確認(rèn)碍遍,重新啟動(dòng) 2MSL計(jì)時(shí)器定铜。 直至服務(wù)端收到后,客戶端和服務(wù)端就都會(huì)進(jìn)入CLOSED狀態(tài)雀久,關(guān)閉 TCP 連接宿稀。 而如果客戶端不等待 2MSL時(shí)間,而是在發(fā)送完ACK確認(rèn)后立即釋放資源赖捌,關(guān)閉連接祝沸,那么就無(wú)法收到服 務(wù)端重傳的FIN報(bào)文段,因而也不會(huì)再發(fā)送一次ACK確認(rèn)報(bào)文段越庇,這樣罩锐,服務(wù)端就無(wú)法正常進(jìn)入CLOSED 狀態(tài),資源就一直無(wú)法釋放了卤唉。

  • 答:為了保證客戶端發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá)服務(wù)端涩惑。

3、TCP 在創(chuàng)建連接時(shí)桑驱,為什么需要三次握手而不是兩次或四次竭恬?
一個(gè)簡(jiǎn)單的例子:

  • 三次握手:
    “喂跛蛋,你聽(tīng)得到嗎?”
    “我聽(tīng)得到呀痊硕,你聽(tīng)得到我嗎赊级?”
    “我能聽(tīng)到你,今天 balabala……”
  • 兩次握手:
    “喂岔绸,你聽(tīng)得到嗎理逊?”
    “我聽(tīng)得到呀,你聽(tīng)得到我嗎盒揉?”
    “喂晋被,你聽(tīng)得到嗎?” “……誰(shuí)在說(shuō)話刚盈?”
    “喂羡洛,你聽(tīng)得到嗎?” “……”
  • 四次握手:
    “喂扁掸,你聽(tīng)得到嗎翘县?”
    “我聽(tīng)得到呀”“你能聽(tīng)到我嗎最域?”
    “……不想跟傻逼說(shuō)話”

之所以不用四次握手的原因很容易理解谴分,就是浪費(fèi)資源,服務(wù)端的SYN和ACK可以一起發(fā)镀脂,完全沒(méi)必要分開(kāi)兩次牺蹄。
而如果是兩次握手:
客戶端發(fā)出的第一個(gè)連接請(qǐng)求SYN報(bào)文段并沒(méi)有丟失,而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了薄翅,以致延誤到 連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端沙兰。本來(lái)這是一個(gè)早已失效的報(bào)文段。但服務(wù)端收到此失效的連接請(qǐng) 求SYN報(bào)文段后翘魄,就誤認(rèn)為是客戶端再次發(fā)出的一個(gè)新的連接請(qǐng)求SYN報(bào)文段鼎天。于是就向客戶端發(fā)出ACK 確認(rèn)報(bào)文段,同意建立連接暑竟。假設(shè)不采用三次握手斋射,那么只要服務(wù)端發(fā)出確認(rèn),新的連接就建立了但荤。 由于現(xiàn)在客戶端并沒(méi)有發(fā)出建立連接的SYN請(qǐng)求罗岖,因此不會(huì)理睬服務(wù)端的確認(rèn),也不會(huì)向服務(wù)端發(fā)送數(shù)據(jù)腹躁。 但服務(wù)端卻以為新的運(yùn)輸連接已經(jīng)建立桑包,并一直等待客戶端發(fā)來(lái)數(shù)據(jù)。這樣纺非,服務(wù)端的很多資源就白白浪
費(fèi)掉了。
事實(shí)上:TCP 對(duì)有數(shù)據(jù)的 TCP 報(bào)文段必須確認(rèn)的原則,所以洁仗,客戶端對(duì)服務(wù)端的SYN報(bào)文段必須回復(fù)一個(gè) ACK報(bào)文段表示確認(rèn)弯洗。并且,TCP 不會(huì)為沒(méi)有數(shù)據(jù)的ACK超時(shí)重傳单刁,那么當(dāng)服務(wù)端沒(méi)收到客戶端的ACK確 認(rèn)報(bào)文段時(shí),會(huì)超時(shí)重傳自己的SYN報(bào)文段,一直到收到客戶端的ACK為止泳梆。

  • 答:兩次握手會(huì)可能導(dǎo)致已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端產(chǎn)生錯(cuò)誤,四次握手又太浪費(fèi)資源

代碼實(shí)現(xiàn)
參考 UDP 的代碼榜掌,其實(shí) TCP 在代碼實(shí)現(xiàn)上也很相似优妙,首先·socket·初始化時(shí)不再用·SOCK_DGRAM·,而是用·SOCK_STREAM·

fd.socket(A_INET, SOCK_STREAM, IPPROTO_TCP):

TCP 服務(wù)端要多了一道監(jiān)聽(tīng)憎账、接受連接的過(guò)程:

int listen_ret = listen(fd,5);
int listen_socket = accept( _fd, (sockaddr *)&addr套硼,&addr_len);

UDP 則是多了一道連接的過(guò)程:

int ret = connect(_fd, (struct sockaddr *) &addr, sizeof (addr));

然后就是在接收和發(fā)送數(shù)據(jù)時(shí),不用再傳主機(jī)和端口了胞皱。即由 recvfrom邪意、sendto 改為 recv 和 send。

send(_fd, [buffer bytes], [buffer length], 0);
recv(_fd, receiveBuffer, sizeof(receiveBuffer), 0);

python 的客戶端代碼如下:

from socket import *
serverName = '127.0.0.1'
serverPort = 12888
clientSocket = socket(AF_ INET,SOCK_STREAM)
clientSocket.connect( (serverName, serverPort))
sentence = raw_ input( 'Input lowercase:\n')
clientsocket.send(sentence)
modifiedSentence = clientSocket.recv(1029)
print 'From server: \n',modifiedSentence
clientSocket.close( )

服務(wù)端代碼:

from socket import *
serverPort = 12800
serverSocket = socket(AF_ INET,SOCK_STREAM)
serverSocket.bind('',serverPort))
serverSocket.listen(1)
print 'server is ready to receive'
connectionsocket,addr = serversocket.accept()
sentence = connectionSocket.recv(1029)
capitalizesentence = sentence.upper()
print capitalizeSentence
connectionSocket.send(capitalizeSentence)
connectionsocket.close()
九反砌、可靠數(shù)據(jù)傳輸

網(wǎng)絡(luò)層服務(wù)(IP 服務(wù))是不可靠的雾鬼。IP 不保證數(shù)據(jù)報(bào)的交付,不保證數(shù)據(jù)報(bào)的按序交付宴树,也不保證數(shù)據(jù)報(bào)中數(shù)據(jù)的完整性策菜。
TCP 則是在 IP 服務(wù)上創(chuàng)建了一種可靠數(shù)據(jù)傳輸服務(wù) TCP 的可靠數(shù)據(jù)傳輸服務(wù)確保一個(gè)進(jìn)程從其接收緩存中讀出的數(shù)據(jù)流是無(wú)損壞、無(wú)間隔酒贬、無(wú)冗余又憨、按序的 數(shù)據(jù)流。即該字節(jié)流與連接的另一端發(fā)出的字節(jié)流是完全相同的锭吨。
作為 TCP 接收方蠢莺,有三個(gè)與發(fā)送和重傳有關(guān)的主要事件
1、從上層應(yīng)用數(shù)據(jù)接收數(shù)據(jù)
將數(shù)據(jù)封裝到一個(gè)報(bào)文段中零如,并把報(bào)文段交付給 IP躏将。每個(gè)報(bào)文段都包含一個(gè)序號(hào) Seq,即該報(bào)文段第一個(gè) 數(shù)據(jù)字節(jié)的字節(jié)流編號(hào)埠况。如果定時(shí)器還沒(méi)有為其他報(bào)文段而運(yùn)行耸携,則啟動(dòng)定時(shí)器(即不是每條報(bào)文段都會(huì)啟 動(dòng)一個(gè)定時(shí)器,而是一共只啟動(dòng)一個(gè)定時(shí)器)辕翰,定時(shí)器的過(guò)期間隔是TimeoutInterval 是由 EstimatedRTT 和 DevRTT 計(jì)算得來(lái)的:TCP 的往返時(shí)間的估計(jì)與超時(shí)
2夺衍、超時(shí)
TCP 通過(guò)重傳引起超時(shí)的報(bào)文段來(lái)響應(yīng)超時(shí)事件,然后重啟定時(shí)器喜命。
而發(fā)送端超時(shí)有兩種情況:發(fā)送數(shù)據(jù)超時(shí)沟沙,接收端發(fā)送 ACK 超時(shí)河劝。這兩種情況都會(huì)導(dǎo)致發(fā)送端在 TimeoutInterval內(nèi)接收不到 ACK 確認(rèn)報(bào)文段。

  • 1矛紫、如果是發(fā)送數(shù)據(jù)超時(shí)赎瞎,直接重傳即可。
  • 2颊咬、而如果是接收端發(fā)送 ACK 超時(shí)务甥,這種情況接收端實(shí)際上已經(jīng)接收到發(fā)送端的數(shù)據(jù)了。那么當(dāng)發(fā)送 端超時(shí)重傳時(shí)喳篇,接收端會(huì)丟棄重傳的數(shù)據(jù)敞临,同時(shí)再次發(fā)送 ACK。

而如果在TimeoutInterval后接收到了 ACK麸澜,會(huì)收下 ACK挺尿,但不做任何處理

  • TCP 不會(huì)為沒(méi)有數(shù)據(jù)的 ACK 超時(shí)重傳

以下兩種情況:

  • 1、如果在發(fā)送兩條或多條數(shù)據(jù)報(bào)文段都超時(shí)炊邦,那么只會(huì)重傳序號(hào)最小的那個(gè)编矾,并重啟定時(shí)器。只要 其余報(bào)文段的 ACK 在新重啟的定時(shí)器超時(shí)前到達(dá)馁害,就不會(huì)重傳窄俏。
  • 2、如果發(fā)送序號(hào)為100和120的兩條數(shù)據(jù)報(bào)文段蜗细,序號(hào)100的 ACK 丟失裆操,但收到了序號(hào)120的 ACK怒详, 由于累積確認(rèn)機(jī)制炉媒,可以得出接收方已經(jīng)接收到了序號(hào)100的報(bào)文段,這種情況也不會(huì)去重傳昆烁。

3吊骤、接收到 ACK
用 TCP 狀態(tài)變量SendBase指最早未被確認(rèn)的字節(jié)的序號(hào)。則SendBase - 1 指接收方已正確按序接收 到的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)静尼。
當(dāng)收到 ACK 確認(rèn)報(bào)文段后白粉,會(huì)將 ACK 的值 Y 與SendBase比較。TCP 采用累計(jì)確認(rèn)的方法鼠渺,所以Y確認(rèn)來(lái) 字節(jié)編號(hào)在 Y 之前的所有字節(jié)都已經(jīng)收到鸭巴。如果Y比SendBase小,不用理會(huì)拦盹;而如果Y比SendBase
大鹃祖,則該 ACK 是在確認(rèn)一個(gè)或多個(gè)先前未被確認(rèn)的報(bào)文段,因此要更新SendBase變量普舆,如果當(dāng)前還有未 被確認(rèn)的報(bào)文段恬口,TCP 還要重啟定時(shí)器校读。
通過(guò)超時(shí)重傳,能保證接收到的數(shù)據(jù)是無(wú)損壞祖能、無(wú)冗余的數(shù)據(jù)流歉秫,但并不能保證按序。
而通過(guò) TCP 滑動(dòng)窗口养铸,能夠有效保證接收數(shù)據(jù)有序

十雁芙、流量控制

TCP 連接的雙方主機(jī)都會(huì)為該 TCP 連接分配緩存和變量。當(dāng)該 TCP 連接收到正確钞螟、按序的字節(jié)后却特,就將數(shù) 據(jù)放入接收緩存。上層的應(yīng)用進(jìn)程會(huì)從該緩存中讀取數(shù)據(jù)筛圆,但不必是數(shù)據(jù)一到達(dá)就立即讀取裂明,因?yàn)榇藭r(shí)應(yīng)用程序可能在做其他事務(wù)。而如果應(yīng)用層讀取數(shù)據(jù)相對(duì)緩慢太援,而發(fā)送方發(fā)送得太多闽晦、太快,發(fā)送的數(shù)據(jù)就會(huì)很容易地使該連接的接收緩存溢出提岔。
所以仙蛉,TCP 為應(yīng)用程序提供了流量控制服務(wù)(flow-controlservice),以消除發(fā)送方使接收方緩存溢出的可 能性碱蒙。
流量控制是一個(gè)速度匹配服務(wù)荠瘪,即發(fā)送方的發(fā)送速率與接收方應(yīng)用程序的讀取速率相匹配。 作為全雙工協(xié)議赛惩,TCP 會(huì)話的雙方都各自維護(hù)一個(gè)發(fā)送窗口和一個(gè)接收窗口(receivewindow)的變量來(lái)提 供流量控制哀墓。而發(fā)送窗口的大小是由對(duì)方接收窗口來(lái)決定的,接收窗口用于給發(fā)送方一個(gè)指示--該接收方還有多少可用的緩存空間喷兼。

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

1篮绰、發(fā)送窗口
發(fā)送方的發(fā)送緩存內(nèi)的數(shù)據(jù)都可以被分為 4 類:

  • 已發(fā)送,已收到 ACK
  • 已發(fā)送季惯,未收到 ACK
  • 未發(fā)送吠各,但允許發(fā)送
  • 未發(fā)送,但不允許發(fā)送

則 2 和 3 屬于發(fā)送窗口

  • 發(fā)送窗口只有收到發(fā)送窗口內(nèi)字節(jié)的 ACK 確認(rèn)勉抓,才會(huì)移動(dòng)發(fā)送窗口的左邊界

2贾漏、接收窗口
接收方的緩存數(shù)據(jù)分為 3 類:

  • 1.已接收
  • 2.未接收但準(zhǔn)備接收
  • 3.未接收而且不準(zhǔn)備接收

則 2 屬于接收窗口(這里的接收指接收數(shù)據(jù)并確認(rèn))

  • 接收窗口只有在前面所有的報(bào)文段都確認(rèn)的情況下才會(huì)移動(dòng)左邊界。當(dāng)在前面還有字節(jié)未接收但收到后面字節(jié)的情況下藕筋,會(huì)先接收下來(lái)纵散,接收窗口不會(huì)移動(dòng),并不對(duì)后續(xù)字節(jié)發(fā)送 ACK 確認(rèn)報(bào)文,以此確保發(fā)送端會(huì)對(duì)這些數(shù)據(jù)重傳困食。

我們定義以下變量:

  • LastByteRead:接收方應(yīng)用程序讀取的數(shù)據(jù)流的最后一個(gè)字節(jié)編號(hào)边翁。可以得知硕盹,這是接收緩存的起點(diǎn)
  • LastByteRcvd:從網(wǎng)絡(luò)中到達(dá)的并且已放入接收緩存中的數(shù)據(jù)流的最后一個(gè)自己的的編號(hào)符匾。

可以得知:LastByteRcvd-LastByteRead<=RcvBuffer(接收緩存大小) 那么接收窗口rwnd=RcvBuffer- (LastByteRcvd-LastByteRead) rwnd是隨時(shí)間動(dòng)態(tài)變化的,如果rwnd為 0瘩例,則意味著接收緩存已經(jīng)滿了啊胶。 接收端在回復(fù)給發(fā)送端的 ACK 中會(huì)包含該 rwnd,發(fā)送端則會(huì)根據(jù) ACK 中的接收窗口的值來(lái)控制發(fā)送窗口垛贤。

有一個(gè)問(wèn)題焰坪,如果當(dāng)發(fā)送rwnd為 0 的ACK后,發(fā)送端停止發(fā)送數(shù)據(jù)聘惦。等待一段時(shí)間后某饰,接收方應(yīng)用程序 讀取了一部分?jǐn)?shù)據(jù),接收端可以繼續(xù)接收數(shù)據(jù)善绎,于是給發(fā)送端發(fā)送報(bào)文告訴發(fā)送端其接收窗口大小黔漂,但這 個(gè)報(bào)文不幸丟失了,我們知道禀酱,不含數(shù)據(jù)的 ACK 是不會(huì)超時(shí)重傳的炬守,于是就出現(xiàn)發(fā)送端等待接收端的ACK 通知||接收端等待發(fā)送端發(fā)送數(shù)據(jù)的死鎖狀態(tài)。

為了處理這種問(wèn)題剂跟,TCP 引入了持續(xù)計(jì)時(shí)器(Persistencetimer)减途,當(dāng)發(fā)送端收到對(duì)方的rwnd=0的ACK通 知時(shí),就啟用該計(jì)時(shí)器曹洽,時(shí)間到則發(fā)送一個(gè) 1 字節(jié)的探測(cè)報(bào)文鳍置,對(duì)方會(huì)在此時(shí)回應(yīng)自身的接收窗口大小, 如果結(jié)果仍未 0衣洁,則重設(shè)持續(xù)計(jì)時(shí)器墓捻,繼續(xù)等待。

十一坊夫、擁塞控制

TCP 除了可靠傳輸服務(wù)外,另一個(gè)關(guān)鍵部分就是擁塞控制撤卢。 TCP 讓每一個(gè)發(fā)送方根據(jù)所感知到的網(wǎng)絡(luò)擁塞程度來(lái)限制其能向連接發(fā)送流量的速率环凿。

可能有三個(gè)疑問(wèn):
1、TCP 發(fā)送方如何感知網(wǎng)絡(luò)擁塞放吩?
2智听、TCP 發(fā)送方如何限制其向連接發(fā)送流量的速率?
3、發(fā)送方感知到網(wǎng)絡(luò)擁塞時(shí)到推,采用何種算法來(lái)改變其發(fā)送速率考赛?

這就是 TCP 的擁塞控制機(jī)制。 前邊說(shuō)到莉测,TCP 連接的每一端都是由一個(gè)接收緩存颜骤、一個(gè)發(fā)送緩存和幾個(gè)變量(LastByteRead、 LastByteRcvd捣卤、rwnd等)組成忍抽。而運(yùn)行在發(fā)送方的 TCP 擁塞控制機(jī)制會(huì)跟蹤一個(gè)額外的變量,即擁塞 窗口 cwnd(congestionwindow)董朝。它對(duì)一個(gè) TCP 發(fā)送方能向網(wǎng)絡(luò)中發(fā)送流量的速率進(jìn)行了限制鸠项。 發(fā)送方中未被確認(rèn)的數(shù)據(jù)量不會(huì)超過(guò)cwnd和rwnd的最小值:min(rwnd,cwnd)

1、TCP 發(fā)送方如何感知網(wǎng)絡(luò)擁塞子姜?
冗余 ACK(duplicateACK):就是再次確認(rèn)某個(gè)報(bào)文段的 ACK祟绊,而發(fā)送方先前已經(jīng)收到對(duì)該報(bào)文段的確認(rèn)。
冗余 ACK 的產(chǎn)生原因:

  • 1.當(dāng)接收端接收到失序報(bào)文段時(shí)哥捕,即該報(bào)文段序號(hào)大于下一個(gè)期望的久免、按序的報(bào)文段,檢測(cè)到數(shù)據(jù)流 中的間隔扭弧,即由報(bào)文段丟失阎姥,并不會(huì)對(duì)該報(bào)文段確認(rèn)。TCP 不使用否定確認(rèn)鸽捻,所以不能向發(fā)送方發(fā)送 顯式的否定確認(rèn)呼巴,為了使接收方得知這一現(xiàn)象,會(huì)對(duì)上一個(gè)按序字節(jié)數(shù)據(jù)進(jìn)行重復(fù)確認(rèn)御蒲,這也就產(chǎn)生 了一個(gè)冗余ACK衣赶。
  • 2.因?yàn)榘l(fā)送方經(jīng)常發(fā)送大量的報(bào)文段,如果其中一個(gè)報(bào)文段丟失厚满,可能在定時(shí)器過(guò)期前府瞄,就會(huì)收到大 量的冗余ACK。一旦收到 3 個(gè)冗余ACK(3 個(gè)以下很可能是鏈路層的亂序引起的碘箍,無(wú)需處理)遵馆,說(shuō)明 在這個(gè)已被確認(rèn) 3 次的報(bào)文段之后的報(bào)文段已經(jīng)丟失,TCP 就會(huì)執(zhí)行快速重傳丰榴,即在該報(bào)文段的定時(shí) 器過(guò)期之前重傳丟失的報(bào)文段货邓。

將 TCP 發(fā)送方的丟包事件定義為:要么出現(xiàn)超時(shí),要么收到來(lái)自接收方的 3 個(gè)冗余ACK四濒。

當(dāng)出現(xiàn)過(guò)度的擁塞時(shí)换况,路由器的緩存會(huì)溢出职辨,導(dǎo)致一個(gè)數(shù)據(jù)報(bào)被丟棄。丟棄的數(shù)據(jù)報(bào)接著會(huì)引起發(fā)送方的
丟包事件戈二。那么此時(shí)舒裤,發(fā)送方就認(rèn)為在發(fā)送方到接收方的路徑上出現(xiàn)了網(wǎng)絡(luò)擁塞。

2觉吭、TCP 發(fā)送方如何限制其向連接發(fā)送流量的速率腾供?

  • 當(dāng)出現(xiàn)丟包事件時(shí):應(yīng)當(dāng)降低 TCP 發(fā)送方的速率。
  • 當(dāng)對(duì)先前未確認(rèn)報(bào)文段的確認(rèn)到達(dá)時(shí)亏栈,即接收到非冗余 ACK 時(shí)台腥,應(yīng)當(dāng)增加發(fā)送方的速率。

3绒北、發(fā)送方感知到網(wǎng)絡(luò)擁塞時(shí)黎侈,采用何種算法來(lái)改變其發(fā)送速率?
即 TCP 擁塞控制算法(TCPcongestioncontrolalgorithm) 包括三個(gè)主要部分:慢啟動(dòng)闷游、擁塞避免峻汉、快速恢復(fù),其中快速恢復(fù)并非是發(fā)送方必須的脐往,慢啟動(dòng)和擁塞避 免則是 TCP 強(qiáng)制要求的

  • 1休吠、慢啟動(dòng)
    當(dāng)一條 TCP 連接開(kāi)始時(shí),擁塞窗口cwnd的值通常置為一個(gè)MSS的較小值业簿,這就使初始發(fā)送速率大約 為 MSS/RTT(RTT:往返時(shí)延瘤礁,報(bào)文段從發(fā)出到對(duì)該報(bào)文段的確認(rèn)被接收之間的時(shí)間量)。 而對(duì) TCP 發(fā)送方來(lái)說(shuō)梅尤,可用帶寬可能比MSS/RTT大得多,TCP 發(fā)送方希望迅速找到可用帶寬的數(shù)量柜思。 因此,在慢啟動(dòng)狀態(tài)巷燥,cwnd以一個(gè)MSS的值開(kāi)始并且每當(dāng)收到一個(gè)非冗余ACK就增加一個(gè)MSS赡盘。

    最初cwnd值為1MSS,發(fā)送一個(gè)報(bào)文段M1缰揪。收到M1的確認(rèn)后陨享,cwnd增加為2MSS,這時(shí)可以發(fā)送兩個(gè) 報(bào)文段M2钝腺,M3抛姑。收到這兩個(gè)報(bào)文段的確認(rèn)后,cwnd則增加為4MSS拍屑,可以發(fā)送四個(gè)報(bào)文段途戒,以此類推...

因此,TCP 雖然發(fā)送速率起始慢僵驰,但在慢啟動(dòng)階段以指數(shù)增長(zhǎng)。

這種指數(shù)增長(zhǎng)很顯然不是無(wú)限制的,那么何時(shí)結(jié)束呢蒜茴? 如果出現(xiàn)丟包事件星爪,TCP 發(fā)送方將 ssthresh(慢啟動(dòng)閾值)設(shè)置為cwnd/2

  • 發(fā)生由超時(shí)引起的丟包事件,并將cwnd重置為1MSS粉私,重啟慢啟動(dòng)
  • 當(dāng) TCP 發(fā)送方的cwnd值達(dá)到或超過(guò)ssthresh顽腾,再繼續(xù)翻倍顯然不合適。這時(shí)將結(jié)束慢啟動(dòng)轉(zhuǎn)移到 擁塞避免模式诺核。
  • TCP 發(fā)送方檢測(cè)到 3 個(gè)冗余 ACK抄肖,會(huì)結(jié)束慢啟動(dòng),并快速重傳窖杀,即在該報(bào)文段的定時(shí)器過(guò)期之前重傳 丟失的報(bào)文段漓摩。且進(jìn)入快速恢復(fù)狀態(tài)。
十二入客、擁塞避免

一旦進(jìn)入擁塞避免狀態(tài)管毙,cwnd 的值大約是上次遇到擁塞時(shí)的值的一半,即距離擁塞并不遙遠(yuǎn)桌硫。因此夭咬,TCP 無(wú)法每過(guò)一個(gè) RTT 就將 cwnd 翻倍。而是每個(gè) RTT 只增加 1MSS铆隘,即每收到一個(gè)非冗余 ACK卓舵,就將 cwnd 增加 1/cwnd。即假如此時(shí) cwnd 為 10MSS膀钠,則每收到一個(gè)非冗余 ACK掏湾,cwnd 就增加 1/10MSS,在 10 個(gè)報(bào)文段都收到確認(rèn)后托修,擁塞窗口的值就增加了 1MSS忘巧。



那么何時(shí)結(jié)束擁塞避免的線性增長(zhǎng)(每 RTT1MSS)呢? 和慢啟動(dòng)一樣睦刃,如果出現(xiàn)丟包事件砚嘴,TCP 發(fā)送方將ssthresh(慢啟動(dòng)閾值)設(shè)置為cwnd/2(加法增大, 乘法減猩尽)

  • 發(fā)生由超時(shí)引起的丟包事件际长,擁塞避免和慢啟動(dòng)處理的方式相同。即 TCP 發(fā)送方將ssthresh(慢啟 動(dòng)閾值)設(shè)置為cwnd/2兴泥,并將 cwnd 重置為1MSS工育,重啟慢啟動(dòng)
  • TCP 發(fā)送方檢測(cè)到 3 個(gè)冗余 ACK,cwnd為原來(lái)的一半加上3MSS搓彻,進(jìn)入快速恢復(fù)狀態(tài)如绸。


十三嘱朽、快速恢復(fù)

快速恢復(fù)是由 3 個(gè)冗余 ACK 引起的。
在快速恢復(fù)中怔接,對(duì)引起 TCP 進(jìn)入快速恢復(fù)狀態(tài)的缺失報(bào)文段搪泳,對(duì)收到的每個(gè)冗余 ACK, cwnd增加 1 個(gè) MSS扼脐。 最終岸军,當(dāng)對(duì)丟失報(bào)文段的一個(gè) ACK 到達(dá)時(shí),TCP 在降低 cwnd 后進(jìn)入擁塞避免狀態(tài)瓦侮。 如果出現(xiàn)超時(shí)艰赞,和之前一樣,即 TCP 發(fā)送方將ssthresh(慢啟動(dòng)閾值)設(shè)置為cwnd/2肚吏,并將cwnd重 置為1MSS方妖,重啟慢啟動(dòng)

快速恢復(fù)并非是必須的。

TCP 的擁塞控制是:每個(gè) RTT 內(nèi)cwnd線性(加性增)增加1MSS须喂,然后出現(xiàn) 3 個(gè)冗余 ACK 事件時(shí)cwnd減 半(乘性減)吁断,因此 TCP 擁塞控制常被稱為加性增,乘性減擁塞控制方式坞生。

十四仔役、DNS

因特網(wǎng)上的主機(jī),可以使用多種方式標(biāo)識(shí)是己,比如主機(jī)名或 IP 地址煌茴。

  • 一 種標(biāo) 識(shí)方 法 就是 用它 的主 機(jī) 名 (hostname)巴粪, 比如·www.baidu.com法精、www.google.com刚照、 gaia.cs.umass.edu 等。這方式方便人們記憶和接受摔认,但是這種長(zhǎng)度不一逆皮、沒(méi)有規(guī)律的字符串路由器并 不方便處理。
  • 還有一種方式参袱,就是直接使用定長(zhǎng)的电谣、有著清晰層次結(jié)構(gòu)的 IP 地址,路由器比較熱衷于這種方式抹蚀。
    為了折衷這兩種方式剿牺,我們需要一種能進(jìn)行主機(jī)名到 IP 地址轉(zhuǎn)換的目錄服務(wù)。這就是*域名系統(tǒng)(Domain NameSystem环壤,DNS)的主要任務(wù)晒来。

DNS 是:
1、一個(gè)由分層的 DNS 服務(wù)器實(shí)現(xiàn)的分布式數(shù)據(jù)庫(kù)
2郑现、一個(gè)使得主機(jī)能夠查詢分布式數(shù)據(jù)庫(kù)的應(yīng)用層協(xié)議

而 DNS 服務(wù)器通常是運(yùn)行 BIND 軟件的 UNIX 機(jī)器湃崩,DNS 協(xié)議運(yùn)行在 UDP 上荧降,使用 53 號(hào)端口 DNS 通常是由其他應(yīng)用層協(xié)議所使用的,包括HTTP竹习、SMTP等誊抛。其作用則是:將用戶提供的主機(jī)名解析為 IP 地址

DNS 的一種簡(jiǎn)單設(shè)計(jì)就是在因特網(wǎng)上只使用一個(gè) DNS 服務(wù)器列牺,該服務(wù)器包含所有的映射整陌。很明顯這種設(shè)計(jì) 是有很大的問(wèn)題的:

  • 單點(diǎn)故障:如果該 DNS 服務(wù)器崩潰,全世界的網(wǎng)絡(luò)隨之癱瘓
  • 通信容量:?jiǎn)蝹€(gè) DNS 服務(wù)器必須處理所有 DNS 查詢
  • 遠(yuǎn)距離的集中式數(shù)據(jù)庫(kù):?jiǎn)蝹€(gè) DNS 服務(wù)器必須面對(duì)所有用戶瞎领,距離過(guò)遠(yuǎn)會(huì)有嚴(yán)重的時(shí)延泌辫。
  • 維護(hù):該數(shù)據(jù)庫(kù)過(guò)于龐大,還需要對(duì)新添加的主機(jī)頻繁更新九默。

所以震放,DNS 被設(shè)計(jì)成了一個(gè)分布式、層次數(shù)據(jù)庫(kù)

十五驼修、DNS 服務(wù)器

為了處理擴(kuò)展性問(wèn)題殿遂,DNS 使用了大量的 DNS 服務(wù)器,它們以層次方式組織乙各,并且分布在全世界范圍內(nèi)墨礁。

域名服務(wù)器是提供域名解析的服務(wù)器,在有基本的知識(shí)下耳峦,任何人都可以搭建域名服務(wù)器恩静,甚至是根域名 服務(wù)器,有名的軟件有:BIND

目前的 DNS 服務(wù)器大致分為 3 種類型的 DNS 服務(wù)器:根 DNS 服務(wù)器蹲坷、頂級(jí)域 DNS 服務(wù)器驶乾、權(quán)威 DNS 服務(wù)器

1、 根 DNS 服務(wù)器


因特網(wǎng)上有 13 個(gè)根 DNS 服務(wù)器(標(biāo)號(hào) A 到 M)循签,1 個(gè)為主根服務(wù)器在美國(guó)级乐。其余 12 個(gè)均為輔根服務(wù)器,其中 9 個(gè)在美國(guó)县匠,歐洲 2 個(gè)风科,位于英國(guó)和瑞典,亞洲 1 個(gè)位于日本聚唐。這里的個(gè)并不是指物理意義上的單個(gè)服務(wù)器丐重,它是一個(gè)邏輯概念,根 DNS 服務(wù)器可以由分布在全球的多個(gè)服務(wù)器組成杆查,形成一個(gè)集群扮惦,對(duì)外統(tǒng)一為 1 臺(tái)邏輯的根 DNS 服務(wù)器(即每個(gè)標(biāo)號(hào)下的根 DNS 服務(wù)器的 IP 地址是一樣的)。而實(shí)際物理意義上的根DNS 服務(wù)器亲桦,已超過(guò)千臺(tái) https://root-servers.org/ 這里可以查到所有根 DNS 服務(wù)器的分布


截止目前崖蜜,中國(guó)有19臺(tái)根 DNS 服務(wù)器浊仆,分別位于:

  • 北京:F,I豫领,J抡柿,L
  • 杭州:J
  • 澳門:F
  • 香港:A、D等恐、E洲劣、F、F课蔬、I囱稽、J
  • 臺(tái)北:E、F二跋、F战惊、I、K扎即、L

2吞获、頂級(jí)域(TLD)DNS 服務(wù)器
這些服務(wù)器負(fù)責(zé)頂級(jí)域名如 com、org谚鄙、net各拷、edu 和 gov,以及所有國(guó)家的頂級(jí)域名如 uk襟锐、fr撤逢、ca 和 cn

3、權(quán)威 DNS 服務(wù)器
在因特網(wǎng)上具有公共可訪問(wèn)主機(jī)的每個(gè)組織機(jī)構(gòu)必須提供公共可訪問(wèn)的 DNS 記錄粮坞,這些記錄將這些主機(jī)的 名字映射為 IP 地址蚊荣。一個(gè)組織機(jī)構(gòu)的權(quán)威 DNS 服務(wù)器收藏了這些 DNS 記錄。
除此之外莫杈,還有一種很重要的 DNS互例,成為本地 DNS 服務(wù)器,其嚴(yán)格來(lái)說(shuō)不屬于該服務(wù)器的層次結(jié)構(gòu)筝闹,但它 對(duì) DNS 層次結(jié)構(gòu)是重要的媳叨。每個(gè) ISP(互聯(lián)網(wǎng)服務(wù)提供商),比如一個(gè)大學(xué)关顷,一個(gè)公司或一個(gè)居民區(qū)的ISP糊秆, 都有一臺(tái)本地DNS服務(wù)器。

十六议双、DNS 解析過(guò)程

1痘番、迭代查詢和遞歸查詢


很清晰地顯示出了一條 DNS 查詢鏈:本地 DNS 服務(wù)器-->根 DNS 服務(wù)器-->頂級(jí)域 DNS 服務(wù)器-->權(quán)威 DNS 服務(wù)器 ,所有查詢都是遞歸的。
這是遞歸查詢汞舱。
遞歸查詢

這種利用了迭代查詢和遞歸查詢伍纫,從 Client 與本地 DNS 之間是遞歸查詢,其余則是迭代查詢昂芜。 所謂 遞歸查詢過(guò)程 就是 “查詢的遞交者” 更替, 而 迭代查詢過(guò)程 則是 “查詢的遞交者”不變莹规。 從理論上講,任何 DNS 查詢既可以是迭代的也能是遞歸的泌神。 而在實(shí)際過(guò)程中良漱,更常用的是圖上 從請(qǐng)求主機(jī)到本地 DNS 服務(wù)器的查詢是遞歸,其余查詢是迭代的這種方式腻扇。

2债热、DNS 緩存
DNS 緩存(DNSCaching):為了改善時(shí)延性能并減少在因特網(wǎng)上到處傳輸?shù)?DNS 報(bào)文數(shù)量,DNS 廣泛使用 了緩存技術(shù)幼苛。 在一個(gè)請(qǐng)求鏈中,當(dāng)某 DNS 服務(wù)器接收一個(gè) DNS 回答時(shí)焕刮,它能將該回答中的信息緩存在本地存儲(chǔ)器中舶沿。那 么另一個(gè)對(duì)相同主機(jī)名的查詢到達(dá)該 DNS 服務(wù)器時(shí),該 DNS 服務(wù)器就可以提供所要求的 IP 地址配并,即使它 不是該主機(jī)名的權(quán)威服務(wù)器括荡。 由于 IP 和主機(jī)名的映射并不是永久的,DNS 服務(wù)器在一段時(shí)間后就會(huì)丟棄緩存的信息溉旋。 本地 DNS 服務(wù)器也能夠緩存 TLD 服務(wù)器的 IP 地址畸冲,從而允許本地 DNS 繞過(guò)查詢鏈中的根 DNS 服務(wù)器。
而事實(shí)上观腊,有 DNS 的地方邑闲,就有緩存。瀏覽器梧油、操作系統(tǒng)苫耸、本地 DNS 服務(wù)器、根 DNS 服務(wù)器儡陨,它們都會(huì) 對(duì) DNS 結(jié)果做一定程度的緩存褪子。

3、DNS 解析過(guò)程


大致分為 8 步:

  • 1骗村、發(fā)起基于域名的請(qǐng)求后嫌褪,首先檢查本地緩存(瀏覽器緩存-->操作系統(tǒng)的 hosts 文件) ? - - - 2、如果本地緩存中有胚股,直接返回目標(biāo) IP 地址笼痛,否則將域名解析請(qǐng)求發(fā)送給本地 DNS 服務(wù)器 - 3、如果本地 DNS 服務(wù)器中有信轿,直接返回目標(biāo) IP 地址晃痴,到這一步基本能解析 80%的域名残吩。如 果沒(méi)有,本地 DNS 服務(wù)器將解析請(qǐng)求發(fā)送給根 DNS 服務(wù)器
  • 4倘核、根 DNS 服務(wù)器會(huì)返回給本地 DNS 服務(wù)器一個(gè)所查詢的 TLD 服務(wù)器地址列表
  • 5泣侮、本地 DNS 服務(wù)器再向上一步返回的 TLD 服務(wù)器發(fā)送請(qǐng)求,TLD 服務(wù)器查詢并返回域名對(duì)應(yīng) 的權(quán)威域名服務(wù)器的地址
  • 6紧唱、本地 DNS 服務(wù)器再向上一步返回的權(quán)威域名服務(wù)器發(fā)送請(qǐng)求活尊,權(quán)威域名服務(wù)器會(huì)查詢存 儲(chǔ)的域名和 IP 的映射關(guān)系表,將 IP 連同一個(gè) TTL(過(guò)期時(shí)間)值返回給本地 DNS 服務(wù)器
  • 7漏益、本地 DNS 服務(wù)器會(huì)將 IP 和主機(jī)名的映射保存起來(lái)蛹锰,保存時(shí)間由 TTL 來(lái)控制
  • 8、本地 DNS 服務(wù)器把解析的結(jié)果返回給用戶绰疤,用戶根據(jù) TTL 值緩存在本地系統(tǒng)緩存中铜犬,域 名解析過(guò)程結(jié)束
十七、DNS 記錄和報(bào)文

1轻庆、資源記錄
所有 DNS 服務(wù)器都存儲(chǔ)了資源記錄(ResourceRecord癣猾,RR),其提供了主機(jī)名到 IP 的映射余爆。 資源記錄是一個(gè)包含以下字段的四元組: (Name纷宇,Value,Type蛾方,TTL)
TTL 是該記錄的生存時(shí)間像捶,決定了資源記錄應(yīng)當(dāng)從緩存中刪除的時(shí)間。
Name 和 Value 的值取決于
Type(以下涉及的 foo,bar 均為偽變量):

  • Type=A桩砰,則 Name 是主機(jī)名拓春,Value 使其對(duì)應(yīng)的 IP 地址。這也是一個(gè)標(biāo)準(zhǔn)的主機(jī)名到 IP 地址的映射五芝。 如(replay1.bar.foo.com,145.37.93.126,A)
  • Type=NS痘儡,則 Name 是個(gè)域(如foo.com),而 Value 是個(gè)知道如何獲取該域中主機(jī) IP 地址的權(quán)威 DNS 服務(wù)器的主機(jī)名枢步,如(foo.com,dns.foo.com,NS)
  • Type=CNAME,則 Name 是別名為 Name 的主機(jī)對(duì)應(yīng)的規(guī)范主機(jī)名沉删。該記錄能夠向查詢的主機(jī)提供一個(gè) 主機(jī)名對(duì)應(yīng)的規(guī)范主機(jī)名,如(foo.com,replay1.bar.foo.com,CNAME)
  • Type=MX醉途,則 Value 是個(gè)別名為 Name 的郵件服務(wù)器的規(guī)范主機(jī)名矾瑰。如(foo.com,main.bar.foo.com,MX)

2、 DNS 報(bào)文

DNS 只有查詢和回答兩種報(bào)文隘擎,這兩種報(bào)文格式是一樣的殴穴。

  • 前 12 個(gè)字節(jié)是首部區(qū)域。 標(biāo)識(shí)符用于標(biāo)識(shí)該查詢,這個(gè)標(biāo)識(shí)符會(huì)被復(fù)制到對(duì)查詢的回答報(bào)文中采幌,以便讓客戶用它來(lái)匹配發(fā)送的請(qǐng)求和接收到的回答劲够。
    標(biāo)志字段中含有若干標(biāo)志。1 比特的“查詢/回答”標(biāo)志位指出報(bào)文是查詢報(bào)文(0)還是回答報(bào)文(1)休傍。 當(dāng)某 DNS 服務(wù)器是所請(qǐng)求名字的權(quán)威 DNS 服務(wù)器時(shí)征绎,1 比特的“權(quán)威的”標(biāo)志位被置在回答報(bào)文中。此 外磨取,還有“希望遞歸”人柿、“遞歸可用”等標(biāo)志位。
    在首部中忙厌,還有 4 個(gè)數(shù)量相關(guān)的字段凫岖,指出來(lái)在首部后的 4 類數(shù)據(jù)區(qū)域出現(xiàn)的數(shù)量,其中 RR 是資源 記錄的意思逢净。
  • 問(wèn)題區(qū)域包含著正在進(jìn)行的查詢信息哥放。該區(qū)域包括: 名字字段,指出正在被查詢的主機(jī)名字汹胃; 類型字 段婶芭,指出有關(guān)該名字的正被查詢的問(wèn)題類型,即上邊說(shuō)的四元組中的 Type
  • 回答區(qū)域包含了對(duì)最初請(qǐng)求的名字的資源記錄着饥。在回答區(qū)域中可以包含多條 RR,因此一個(gè)主機(jī)名理 論上能夠有多個(gè) IP 地址(不同用戶在不同地點(diǎn)訪問(wèn)同一個(gè)域名惰赋,可能會(huì)訪問(wèn)到不同的 IP 地址)
  • 權(quán)威區(qū)域中包含了其他權(quán)威服務(wù)器的記錄
  • 附加區(qū)域包含了其他有幫助的記錄

得知 DNS 的報(bào)文格式后宰掉,我們也就可以手動(dòng)發(fā)送 DNS 查詢包了。

十八赁濒、DNS 解析安全問(wèn)題

1轨奄、DNS 劫持


一種可能的域名劫持方式即黑客侵入了寬帶路由器并對(duì)終端用戶的本地 DNS 服務(wù)器進(jìn)行篡改,指向黑客自 己偽造的本地 DNS 服務(wù)器拒炎,進(jìn)而通過(guò)控制本地 DNS 服務(wù)器的邏輯返回錯(cuò)誤的 IP 信息進(jìn)行域名劫持挪拟。
另一方面,由于 DNS 解析主要是基于 UDP 協(xié)議击你,除了上述攻擊行為外玉组,攻擊者還可以監(jiān)聽(tīng)終端用戶的域名 解析請(qǐng)求,并在本地 DNS 服務(wù)器返回正確結(jié)果之前將偽造的 DNS 解析響應(yīng)傳遞給終端用戶丁侄,進(jìn)而控制終端 用戶的域名訪問(wèn)行為惯雳。

2、緩存污染(DNS 污染)
我們知道在接收到域名解析請(qǐng)求時(shí)鸿摇,本地 DNS 服務(wù)器首先會(huì)查找緩存石景,如果緩存命中就會(huì)直接返回緩存結(jié) 果,不再進(jìn)行遞歸 DNS 查詢。這時(shí)候如果本地 DNS 服務(wù)器針對(duì)部分域名的緩存進(jìn)行更改潮孽,比如將緩存結(jié)果 指向第三方的廣告頁(yè)揪荣,就會(huì)導(dǎo)致用戶的訪問(wèn)請(qǐng)求被引導(dǎo)到這些廣告頁(yè)地址上。

3往史、如何解決 DNS 劫持仗颈?
DNS 解析發(fā)生在 HTTP 協(xié)議之前,DNS 解析和 DNS 劫持和 HTTP 沒(méi)有關(guān)系,DNS 協(xié)議使用的是 UDP 協(xié)議向服 務(wù)器的 53 端口進(jìn)行請(qǐng)求。 要想解決 DNS 劫持:

  • 可以使用 HttpDNS 的方案:使用 HTTP 協(xié)議向 DNS 服務(wù)器的 80 端口進(jìn)行請(qǐng)求,來(lái)規(guī)避 DNS 劫持 比如:http://119.29.29.29/d?dn=domain&ip=clientIp
  • 在終端上,可以更換 DNS 服務(wù)器,不管手機(jī)還是電腦,都能手動(dòng)配置 DNS



十九抒和、Cookie

這里有說(shuō)到庙洼,HTTP 協(xié)議是無(wú)狀態(tài)的,服務(wù)器中沒(méi)有保存客戶端的狀態(tài)叠聋,客戶端必須每次帶上自己的狀態(tài)去
請(qǐng)求服務(wù)器
基于 HTTP 這種特點(diǎn)虏束,就產(chǎn)生了 cookie/session

1袜啃、用戶與服務(wù)器的交互:Cookie
cookie主要是用來(lái)記錄用戶狀態(tài)熟妓,區(qū)分用戶,狀態(tài)保存在客戶端

  • 1.首次訪問(wèn)amazon時(shí)阐污,客戶端發(fā)送一個(gè) HTTP 請(qǐng)求到服務(wù)器端 。服務(wù)器端發(fā)送一個(gè) HTTP 響應(yīng)到客 戶端笛辟,其中包含Set-Cookie頭部
  • 2.客戶端發(fā)送一個(gè) HTTP 請(qǐng)求到服務(wù)器端,其中包含Cookie頭部隘膘。服務(wù)器端發(fā)送一個(gè) HTTP 響應(yīng)到客 戶端
  • 3.隔段時(shí)間再去訪問(wèn)時(shí)杠览,客戶端會(huì)直接發(fā)包含Cookie頭部的 HTTP 請(qǐng)求。服務(wù)器端發(fā)送一個(gè) HTTP 響 應(yīng)到客戶端

cookie 技術(shù)有 4 個(gè)組件:

  • 1.在 HTTP 響應(yīng)報(bào)文中的一個(gè)cookie首部行
  • 2.在 HTTP 請(qǐng)求報(bào)文中的一個(gè)cookie首部行
  • 3.在用戶端系統(tǒng)中保留一個(gè)cookie文件踱阿,并由用戶的瀏覽器進(jìn)行管理
  • 4.位于 Web 站點(diǎn)的一個(gè)后端數(shù)據(jù)庫(kù)

也就是說(shuō)醇滥,cookie功能需要瀏覽器的支持阅虫。如果瀏覽器不支持cookie(如大部分手機(jī)中的瀏覽器)或 者把cookie禁用了,cookie功能就會(huì)失效不跟。

2颓帝、cookie 的修改和刪除
在修改cookie的時(shí)候,只需要新cookie覆蓋舊cookie即可窝革,在覆蓋的時(shí)候购城,由于Cookie具有不可 跨域名性,注意name虐译、path瘪板、domain需與原cookie一致 刪除cookie也一樣,設(shè)置cookie的過(guò)期時(shí)間expires為過(guò)去的一個(gè)時(shí)間點(diǎn)菱蔬,或者maxAge=0(Cookie 的有效期,單位為秒)即可

3篷帅、cookie 的安全
事實(shí)上,cookie的使用存在爭(zhēng)議拴泌,因?yàn)樗徽J(rèn)為是對(duì)用戶隱私的一種侵害魏身,而且cookie并不安全 HTTP 協(xié)議不僅是無(wú)狀態(tài)的,而且是不安全的蚪腐。使用 HTTP 協(xié)議的數(shù)據(jù)不經(jīng)過(guò)任何加密就直接在網(wǎng)絡(luò)上傳播箭昵, 有被截獲的可能。使用 HTTP 協(xié)議傳輸很機(jī)密的內(nèi)容是一種隱患回季。

  • 如果不希望Cookie在 HTTP 等非安全協(xié)議中傳輸家制,可以設(shè)置 Cookie 的secure屬性為true。瀏覽 器只會(huì)在 HTTPS 和 SSL 等安全協(xié)議中傳輸此類 Cookie泡一。
  • 此外颤殴,secure屬性并不能對(duì) Cookie 內(nèi)容加密,因而不能保證絕對(duì)的安全性鼻忠。如果需要高安全性涵但,需 要在程序中對(duì) Cookie 內(nèi)容加密、解密帖蔓,以防泄密矮瘟。
  • 也可以設(shè)置cookie為 HttpOnly,如果在 cookie 中設(shè)置了 HttpOnly 屬性塑娇,那么通過(guò) js 腳本將無(wú)法讀 取到cookie信息澈侠,這樣能有效的防止 XSS(跨站腳本攻擊)攻擊
二十、Session

除了使用Cookie埋酬,Web 應(yīng)用程序中還經(jīng)常使用 Session 來(lái)記錄客戶端狀態(tài)哨啃。Session是服務(wù)器端使用的 一種記錄客戶端狀態(tài)的機(jī)制烧栋,使用上比Cookie簡(jiǎn)單一些,相應(yīng)的也增加了服務(wù)器的存儲(chǔ)壓力棘催。
Session 是另一種記錄客戶狀態(tài)的機(jī)制劲弦,不同的是 Cookie 保存在客戶端瀏覽器中,而 Session 保存在服務(wù)器上醇坝。
客戶端瀏覽器訪問(wèn)服務(wù)器的時(shí)候邑跪,服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上。這就是Session呼猪』客 戶端瀏覽器再次訪問(wèn)時(shí)只需要從該Session中查找該客戶的狀態(tài)就可以了。

  • 當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session時(shí)宋距,服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已 包含了一個(gè)session標(biāo)識(shí)(稱為SessionId)
  • 如果已包含則說(shuō)明以前已經(jīng)為此客戶端創(chuàng)建過(guò) session轴踱,服務(wù)器就按照 SessionId 把這個(gè)session檢索 出來(lái),使用(檢索不到谚赎,會(huì)新建一個(gè))
  • 如果客戶端請(qǐng)求不包含SessionId淫僻,則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session 相關(guān)聯(lián)的SessionId,SessionId的值應(yīng)該是一個(gè)既不會(huì)重復(fù)壶唤,又不容易被找到規(guī)律以仿造的字符 串雳灵,這個(gè)SessionId將被在本次響應(yīng)中返回給客戶端保存。
  • 保存這個(gè)SessionId的方式可以采用cookie闸盔,這樣在交互過(guò)程中瀏覽器可以自動(dòng)的按照規(guī)則把這 個(gè)標(biāo)識(shí)發(fā)送給服務(wù)器悯辙。但cookie可以被人為的禁止,則必須有其他機(jī)制以便在cookie被禁止時(shí)仍 然能夠把SessionId傳遞回服務(wù)器迎吵。
二十一躲撰、Cookie 和 Session 的區(qū)別

1、cookie 數(shù)據(jù)存放在客戶的瀏覽器上击费,session 數(shù)據(jù)放在服務(wù)器上拢蛋。
2、cookie 相比 session 不是很安全蔫巩,別人可以分析存放在本地的 cookie 并進(jìn)行 cookie 欺騙,考慮到安全應(yīng)當(dāng)使用 session瓤狐。
3、session 會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上批幌。當(dāng)訪問(wèn)增多,會(huì)比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面嗓节,應(yīng)當(dāng)使用 cookie荧缘。
4、單個(gè) cookie 保存的數(shù)據(jù)不能超過(guò) 4K拦宣,很多瀏覽器都限制一個(gè)站點(diǎn)最多保存 20 個(gè) cookie截粗。而 session存儲(chǔ)在服務(wù)端信姓,可以無(wú)限量存儲(chǔ)
5、所以:將登錄信息等重要信息存放為 session;其他信息如果需要保留绸罗,可以放在 cookie 中

二十二意推、IP 協(xié)議

IP 協(xié)議是 TCP/IP 核心協(xié)議。

1珊蟀、IP 協(xié)議的數(shù)據(jù)報(bào)格式(IPv4)

  • 版本號(hào)
    規(guī)定了數(shù)據(jù)報(bào)的 IP 協(xié)議版本(IPv4 還是 IPv6)菊值。不同的 IP 版本使用不同的數(shù)據(jù)報(bào)格式 祝闻,
    上圖是 IPv4 的數(shù)據(jù)報(bào)格式
  • 首部長(zhǎng)度
    大多數(shù) IP 數(shù)據(jù)報(bào)不包含選項(xiàng)可很,所以一般 IP 數(shù)據(jù)報(bào)具有 20 字節(jié)的首部串前。
  • 服務(wù)類型
    使不同類型的 IP 數(shù)據(jù)報(bào)能相互區(qū)別開(kāi)來(lái)芋绸。
  • 數(shù)據(jù)報(bào)長(zhǎng)度
    整個(gè) IP 數(shù)據(jù)報(bào)的長(zhǎng)度捂蕴,利用首部長(zhǎng)度和總長(zhǎng)度就可以是算出 IP 數(shù)據(jù)報(bào)中數(shù)據(jù)內(nèi)容的起始地
    址垫竞。
    該字段長(zhǎng)度為 16 比特郑原,所以 IP 數(shù)據(jù)報(bào)最長(zhǎng)可達(dá) 2^16=65535 字節(jié)漓藕,而事實(shí)上砸喻,數(shù)據(jù)報(bào)
    很少有超過(guò) 1500 字節(jié)的
  • 標(biāo)識(shí)柔逼、標(biāo)志、片偏移字段
    這三個(gè)字段與 IP 分片有關(guān)割岛。此外愉适,IPv6 不允許在路由器上對(duì)分組分片
  • 生存時(shí)間 TTL
    用來(lái)確保數(shù)據(jù)報(bào)不會(huì)永遠(yuǎn)在網(wǎng)絡(luò)中循環(huán)。設(shè)置該數(shù)據(jù)報(bào)可以經(jīng)過(guò)的最多的路由器數(shù)蜂桶。指定了
    數(shù)據(jù)報(bào)的生存時(shí)間儡毕,經(jīng)過(guò)一個(gè)路由器,它的值就減 1扑媚,當(dāng)該字段為 0 時(shí)腰湾,數(shù)據(jù)報(bào)就被丟棄
  • 協(xié)議
    該字段只有在一個(gè) IP 數(shù)據(jù)報(bào)到達(dá)其目的地才有用。該字段值指示了 IP 數(shù)據(jù)報(bào)的數(shù)據(jù)部分應(yīng)
    交給哪個(gè)特定的傳輸層協(xié)議疆股,比如费坊,值為 6 表明要交給 TCP,而值為 17 則表明要交給 UDP
  • 首部檢驗(yàn)和
    與 UDP/TCP 的檢驗(yàn)和不同旬痹,這個(gè)字段只檢驗(yàn)數(shù)據(jù)報(bào)的首部附井,不包括數(shù)據(jù)部分。
  • 選項(xiàng)字段
    是一個(gè)可變長(zhǎng)字段两残,選項(xiàng)字段一直以 4 字節(jié)作為界限永毅。這樣就可以保證首部始終是 4 字節(jié)的
    整數(shù)倍人弓。很少被用到
  • 源 IP 和目的 IP
    記錄源 IP 地址沼死,目的 IP 地址。
二十三崔赌、IP 數(shù)據(jù)報(bào)分片

一個(gè)鏈路層幀能承載的最大數(shù)據(jù)量叫做最大傳送單元(MaximunTransmissionUnit,MTU),即鏈路層的 MTU 限制著 IP 數(shù)據(jù)報(bào)的長(zhǎng)度意蛀。
問(wèn)題是在不同的鏈路上耸别,可能使用不同的鏈路層協(xié)議,且每種協(xié)議可能具有不同的 MTU县钥。 假定在某條鏈路上收到一個(gè) IP 數(shù)據(jù)報(bào)秀姐,通過(guò)檢查轉(zhuǎn)發(fā)表確定出鏈路,且出鏈路的 MTU 比該 IP 數(shù)據(jù)報(bào)的長(zhǎng) 度要小若贮,如何將這個(gè)過(guò)大的 IP 數(shù)據(jù)報(bào)壓縮進(jìn)鏈路層幀的有效載荷字段呢省有?

解決方案就是分片:將 IP 數(shù)據(jù)報(bào)中的數(shù)據(jù)分片為兩個(gè)或更多個(gè)較小的 IP 數(shù)據(jù)報(bào),用單獨(dú)的鏈路層幀封裝這 些較小的 IP 數(shù)據(jù)報(bào)兜看,然后向出鏈路上發(fā)送這些幀锥咸,每個(gè)這些較小的數(shù)據(jù)都稱為片(fragment)。

片在到達(dá)目的地傳輸層前需要重新組裝细移。

實(shí)際上搏予,TCP 和 UDP 都希望從網(wǎng)絡(luò)層上收到完整的未分片的報(bào)文。IPv4 的數(shù)據(jù)報(bào)重組工作是在端系統(tǒng)中弧轧, 而不是在網(wǎng)絡(luò)路由器中雪侥。
當(dāng)一臺(tái)目的主機(jī)從相同源收到一系列數(shù)據(jù)時(shí),需要確定這些數(shù)據(jù)報(bào)中的某些是否是一些原來(lái)較大的數(shù)據(jù)報(bào)中的片精绎。而如果是片的話速缨,需要進(jìn)一步確定何時(shí)收到最后一片,并且如何將這些片拼接到一起以形成初始 的數(shù)據(jù)報(bào)代乃。從而就用到了前邊說(shuō)到的 IPv4 數(shù)據(jù)報(bào)首部中的 標(biāo) 識(shí) 旬牲、 標(biāo) 志 、 片 偏 移 字段搁吓。

  • 1原茅、當(dāng)生成一個(gè)數(shù)據(jù)報(bào)時(shí),發(fā)送主機(jī)在為該數(shù)據(jù)報(bào)設(shè)置源和目的地址的同時(shí)在貼上標(biāo)識(shí)號(hào),發(fā) 送主機(jī)通常將為它發(fā)送的每個(gè)數(shù)據(jù)報(bào)標(biāo)識(shí)號(hào)加 1
  • 2堕仔、當(dāng)某路由器需要對(duì)一個(gè)數(shù)據(jù)報(bào)分片時(shí)擂橘,形成的每個(gè)數(shù)據(jù)報(bào)(即片)具有初始數(shù)據(jù)報(bào)的源 地址、目的地址和標(biāo)識(shí)號(hào)
  • 3摩骨、當(dāng)目的地從同一發(fā)送主機(jī)收到一系列數(shù)據(jù)報(bào)時(shí)通贞,它能夠檢查數(shù)據(jù)報(bào)的標(biāo)識(shí)號(hào)以確定哪些 數(shù)據(jù)報(bào)實(shí)際上是同一較大數(shù)據(jù)報(bào)的片
  • 4、由于 IP 協(xié)議是不可靠服務(wù)恼五,一個(gè)或者多個(gè)片可能永遠(yuǎn)到達(dá)不了目的地昌罩。為了讓目的主機(jī) 絕對(duì)相信它已收到初始數(shù)據(jù)報(bào)的最后一個(gè)片,最后一個(gè)片的標(biāo)志比特被設(shè)為 0灾馒,其余被設(shè)為 1
  • 5峡迷、為了讓目的主機(jī)確定是否丟失了一個(gè)片,并且能按照正確的順序重新組裝片,使用偏移 字段指定該片應(yīng)放在初始 IP 數(shù)據(jù)報(bào)的哪個(gè)位置>
    此外绘搞,如果有一個(gè)片或者多個(gè)片未能到達(dá),則該不完整的數(shù)據(jù)報(bào)將會(huì)被丟棄且不會(huì)交給傳輸
    層傅物。但如果傳輸層正使用著 TCP夯辖,則 TCP 將通過(guò)讓源以初始數(shù)據(jù)來(lái)重傳數(shù)據(jù)。因?yàn)?IP 層沒(méi)有
    超時(shí)重傳機(jī)制董饰,所以會(huì)重傳整個(gè)數(shù)據(jù)報(bào)蒿褂,而不是某個(gè)片
二十四、IPv4 編址

1卒暂、IP 地址
一臺(tái)主機(jī)通常只有一條鏈路連接到網(wǎng)絡(luò)啄栓,當(dāng)主機(jī)上的 IP 想發(fā)送一條數(shù)據(jù)報(bào)時(shí),就在該鏈路上發(fā)送也祠。主機(jī)與 物理鏈路之間的邊界叫做接口(interface)昙楚。 而路由器的任務(wù)是從鏈路上接收數(shù)據(jù)報(bào)并從某些其他鏈路轉(zhuǎn)發(fā)出去,路由器必須有兩條或更多鏈路與其連
接诈嘿,路由器與它的任意一條鏈路之間的邊界也叫做接口堪旧。即一臺(tái)路由器會(huì)有多個(gè)接口,每個(gè)接口有其鏈路奖亚。
因?yàn)槊颗_(tái)主機(jī)與路由器都能發(fā)送和接收 IP 數(shù)據(jù)報(bào)淳梦, IP 要求每臺(tái)主機(jī)和路由器接口都有自己的 IP 地址。因此昔字, 一個(gè) IP 地址技術(shù)上是與一個(gè)接口相關(guān)聯(lián)的爆袍,而不是與包括該接口的主機(jī)或路由器相關(guān)聯(lián)的。

2作郭、子網(wǎng)
每個(gè) IP 地址(IPv4)長(zhǎng)度為 32 比特(4 字節(jié))陨囊,按點(diǎn)分十進(jìn)制記法書寫,即地址中的每個(gè)字節(jié)都用它的十 進(jìn)制形式書寫所坯,各字節(jié)間以點(diǎn).隔開(kāi)谆扎,比如193.32.122.30 在因特網(wǎng)上的每臺(tái)主機(jī)和路由器上的每個(gè)接口,必須有一個(gè)全球唯一的 IP 地址(NAT 后的接口除外)芹助。這 些地址不能自由選擇堂湖,一個(gè)接口的 IP 地址的一部分需要由其連接的子網(wǎng)來(lái)決定。


如圖状土,一臺(tái)路由器有三個(gè)接口无蜂,連接 7 臺(tái)主機(jī)。左側(cè)的三臺(tái)主機(jī)以及連接它們的路由器的接口蒙谓,都有一個(gè)形如 223.1.1.x 的 IP 地址斥季。即在它們的 IP 地址中,最左側(cè)的 24 比特是相同的。

互聯(lián)左側(cè)這三個(gè)主機(jī)接口與 1 個(gè)路由器接口的網(wǎng)絡(luò)形成 1 個(gè)子網(wǎng)(subnet)(也被稱為 IP 網(wǎng)絡(luò)或直接稱為網(wǎng)絡(luò))酣倾。IP 編址為這個(gè)子網(wǎng)分配一個(gè)地址:223.1.1.0/24舵揭,其中的/24 記法,有時(shí)稱為子網(wǎng)掩碼(network mask)躁锡,指示了 32 比特中的最左側(cè) 24 比特定義了子網(wǎng)地址午绳。任何連接到該子網(wǎng)的主機(jī)都要求其地址具有 223.1.1.x 的形式。同樣圖中下側(cè)和右側(cè)也是子網(wǎng)映之,分別為 223.1.3.0/24 和 223.1.2.0/24


上圖顯示了 3 臺(tái)通過(guò)點(diǎn)對(duì)點(diǎn)鏈路彼此互聯(lián)的路由器拦焚,這里出現(xiàn)了 6 個(gè)子網(wǎng)。
一個(gè)具有多個(gè)以太網(wǎng)段和點(diǎn)對(duì)點(diǎn)鏈路的組織將具有多個(gè)子網(wǎng)杠输,在給定子網(wǎng)上的所有設(shè)備都具有相同的子網(wǎng)地址赎败。
雖然在理論上來(lái)說(shuō),不同子網(wǎng)可以有完全不同的子網(wǎng)地址蠢甲。但上圖可以看出僵刮,這 6 個(gè)子網(wǎng)在前 16 個(gè)比特是 一致的,都是223.1

3峡钓、無(wú)類別域間路由選擇(CIDR)
因特網(wǎng)的地址分配策略被稱為無(wú)類別域間路由選擇(CIDR)(也被稱為無(wú)分類編址妓笙,以區(qū)分于分類編址)。對(duì) 于子網(wǎng)尋址能岩,32 比特的 IP 地址被分為兩部分寞宫,也是點(diǎn)分十進(jìn)制數(shù)形式a.b.c.d/x,其中 x 指示了地址的 第一部分中的比特?cái)?shù)拉鹃,又被稱為該地址的前綴(prefix)辈赋。
一個(gè)組織通常被分配一塊連續(xù)的地址,即具有相同前綴的地址膏燕。在該組織外的的路由器僅考慮前面的前綴 比特 x钥屈,這相當(dāng)大地減少了在這些路由器中轉(zhuǎn)發(fā)表的長(zhǎng)度,形式為a.b.c.d/x單一表項(xiàng)足以將數(shù)據(jù)報(bào)轉(zhuǎn)發(fā) 到該組織內(nèi)的任何目的地坝辫。


如圖篷就,200.23.16.0/20 下有 8 個(gè)組織,分別是 200.23.16.0/23 到 200.23.30.0/23近忙,每個(gè)組織有自己的子網(wǎng)竭业。而外界不需要知道這 8 個(gè)組織。這種使用單個(gè)網(wǎng)絡(luò)前綴通告多個(gè)網(wǎng)絡(luò)的能力通常稱為地址聚合及舍,也稱為路由聚合路由摘要

4未辆、分類編址
在 CIDR 被采用之前, IP 地址的網(wǎng)絡(luò)部分被限制長(zhǎng)度為 8锯玛、 16咐柜、 24 比特兼蜈,也就是分類編址(classfuladdressing)。 具有 8拙友、16为狸、24 比特子網(wǎng)地址的子網(wǎng)被稱為A、B和C類網(wǎng)絡(luò)遗契。
一個(gè)C類(/24)子網(wǎng)既能容納 2 的 8 次 方 -2=254 臺(tái)主機(jī)(其中兩個(gè)地址預(yù)留用于特殊用途)钥平,這對(duì)于 很多組織來(lái)說(shuō)都太小了。
而一個(gè)B類(/16)子網(wǎng)可支持多達(dá) 2 的 16 次 方 -2=65534 臺(tái)主機(jī)姊途,又太大了。
在分類編址方法下知态,一個(gè)有2000臺(tái)主機(jī)的組織通常被分給一個(gè) B 類(/16)地址捷兰,那么剩下的 6 萬(wàn)多個(gè)地 址就浪費(fèi)掉了。這就會(huì)導(dǎo)致 B 類地址空間的迅速損耗以及所分配的地址空間的利用率低负敏。

此外贡茅,255.255.255.255是 IP 廣播地址,當(dāng)一臺(tái)主機(jī)發(fā)出一個(gè)目的地址為該地址的數(shù)據(jù)報(bào)時(shí)其做,該報(bào)文會(huì) 交付給同一個(gè)網(wǎng)絡(luò)中的所有主機(jī)顶考。

5、獲取主機(jī)地址
某組織一旦獲得了一塊地址妖泄,它就可為本組織內(nèi)的主機(jī)與路由器逐一分配 IP 地址驹沿。系統(tǒng)管理員通常手工配 置路由器中的 IP 地址。主機(jī)地址也能手動(dòng)配置蹈胡,但更多使用的是動(dòng)態(tài)主機(jī)配置協(xié)議(DHCP)渊季。DHCP 允許 主機(jī)自動(dòng)獲取 IP 地址。網(wǎng)絡(luò)管理員可以配置 DHCP罚渐,以使某給定主機(jī)每次與網(wǎng)絡(luò)連接時(shí)能得到一個(gè)相同的 IP 地址却汉,或者某主機(jī)將被分配一個(gè)臨時(shí)的 IP 地址,該地址在每次與網(wǎng)絡(luò)連接時(shí)也許是不同的荷并。

6合砂、網(wǎng)絡(luò)地址轉(zhuǎn)換
每個(gè) IP 地址(IPv4)長(zhǎng)度為 32 比特(4 字節(jié)),因此總共有 2[圖片上傳失敗...(image-524f6a-1565267828082)]個(gè)可能的 IP 地址源织,約為 40 億個(gè)翩伪。在互聯(lián)網(wǎng)越來(lái)越普及的當(dāng)下,個(gè)人計(jì)算機(jī)及智能手機(jī)等越來(lái)越多雀鹃,這些 IP 地址顯然無(wú)法滿足人們的需求幻工。
為了解決 IP 地址不足的問(wèn)題,于是就有了網(wǎng)絡(luò)地址轉(zhuǎn)換(NetworkAddressTranslation黎茎, NAT)囊颅,它的思想就 是給一個(gè)局域網(wǎng)絡(luò)分配一個(gè) IP 地址就夠了,對(duì)于這個(gè)網(wǎng)絡(luò)內(nèi)的主機(jī),則分配私有地址踢代,這些私有地址對(duì)外 是不可見(jiàn)的盲憎,他們對(duì)外的通信都要借助那個(gè)唯一分配的 IP 地址。

如果從廣域網(wǎng)到達(dá)NAT路由器的所有數(shù)據(jù)報(bào)都有相同的目的 IP 地址胳挎,那么該路由器如何知道是發(fā)送給哪個(gè) 內(nèi)部主機(jī)的呢饼疙?其原理就是使用在 NAT 路由器上的一張 NAT 轉(zhuǎn)換表,并在該表內(nèi)包含了端口號(hào)及其 IP 地 址慕爬。

  • 假設(shè)一臺(tái)主機(jī)向廣域網(wǎng)請(qǐng)求數(shù)據(jù)窑眯,NAT 路由器收到該數(shù)據(jù)報(bào),會(huì)為該數(shù)據(jù)報(bào)生成一個(gè)新的端 口號(hào)替換掉源端口號(hào)医窿,并將源 IP 替換為其廣域網(wǎng)一側(cè)接口的 IP 地址磅甩。當(dāng)生成一個(gè)新的源端
    口號(hào)時(shí),該端口號(hào)可以是任意一個(gè)當(dāng)前未在 NAT 轉(zhuǎn)換表中的源端口號(hào)(端口號(hào)字段是 16 比
    特姥卢,意味著 NAT 協(xié)議可以支持超過(guò) 60000 個(gè)并行使用路由器廣域網(wǎng)一側(cè) IP 地址的連接)卷要,
    路由器中的 NAT 也在其 NAT 轉(zhuǎn)換表中增加一表項(xiàng)。
  • 該 NAT 路由器收到廣域網(wǎng)返回的數(shù)據(jù)時(shí)独榴,路由器使用目的 IP 地址與目的端口號(hào)從 NAT 轉(zhuǎn)換 表中檢索出該主機(jī)使用的IP 地址和目的端口號(hào)僧叉,改寫該數(shù)據(jù)報(bào)的目的IP 地址和目的端口號(hào),
    并向該主機(jī)轉(zhuǎn)發(fā)該數(shù)據(jù)報(bào)

NAT 雖然在近幾年得到了很廣泛的應(yīng)用棺榔,但也被很多人反對(duì)瓶堕。
主要是:

  • 1、端口號(hào)是用來(lái)進(jìn)程編址的掷豺,而不是主機(jī)編址的(NAT 協(xié)議類似 NAT 路由器將該家庭網(wǎng)絡(luò) 的主機(jī)都當(dāng)做進(jìn)程處理捞烟,并通過(guò) NAT 轉(zhuǎn)換表為其分配端口號(hào))
  • 2、路由器通常僅應(yīng)當(dāng)處理高達(dá)第三層的分組
  • 3当船、違背端到端原則题画,即主機(jī)彼此之間應(yīng)當(dāng)相互直接對(duì)話,結(jié)點(diǎn)不應(yīng)當(dāng)介入修改 IP 地址與端 口號(hào)德频。
  • 4苍息、應(yīng)當(dāng)用 IPv6 來(lái)解決 IP 地址短缺問(wèn)題

但不管反對(duì)與否,NAT 終究已成為當(dāng)今因特網(wǎng)的一個(gè)重要組件

二十五壹置、IPv6 數(shù)據(jù)報(bào)格式

1竞思、IPv6 數(shù)據(jù)報(bào)格式

  • 版本(4 比特)
    該字段用于標(biāo)識(shí) IP 版本號(hào),IPv6 將該字段值設(shè)為 6钞护。而如果將該字段設(shè)為 4 并不能創(chuàng)建一個(gè)合法的 IPv4 數(shù)據(jù)報(bào)
  • 流量類型(8 比特)
    類似于 IPv4 數(shù)據(jù)報(bào)中的服務(wù)類型(TOS)
  • 流標(biāo)簽(20 比特)
    流標(biāo)簽字段是 IPv6 數(shù)據(jù)報(bào)中新增的一個(gè)字段盖喷,用來(lái)標(biāo)識(shí)一條數(shù)據(jù)報(bào)的流類型,以便在網(wǎng)絡(luò)層區(qū)分不同的報(bào)文难咕。
  • 有效載荷長(zhǎng)度(16 比特)
    IPv6 數(shù)據(jù)報(bào)中在 40 定長(zhǎng)字節(jié)數(shù)據(jù)報(bào)首部后的字節(jié)數(shù)量课梳,即除了 IPv6 的數(shù)據(jù)報(bào)首部以外的其他部分的總長(zhǎng)度
  • 下一個(gè)首部(8 比特)
    當(dāng) IPv6 沒(méi)有擴(kuò)展報(bào)頭時(shí)距辆,該字段的作用和 IPv4 的協(xié)議字段一樣。當(dāng)含有擴(kuò)展報(bào)頭時(shí)暮刃,該字段的值即為第一個(gè)擴(kuò)展報(bào)頭的類型
  • 跳限制(8 比特)
    與 IPv4 報(bào)文中的 TTL 字段類似跨算,轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)的每臺(tái)路由器將對(duì)該字段的內(nèi)容減 1.如果跳限制計(jì)數(shù)到達(dá) 0,則該數(shù)據(jù)報(bào)將被丟棄
  • 源地址和目的地址(各 128 比特) 記錄源 IP 地址椭懊,目的 IP 地址
  • 數(shù)據(jù)
  • 下一個(gè)首部(8 比特)
    當(dāng) IPv6 沒(méi)有擴(kuò)展報(bào)頭時(shí)诸蚕,該字段的作用和 IPv4 的協(xié)議字段一樣。當(dāng)含有擴(kuò)展報(bào)頭時(shí)氧猬,該字段的值即為第一個(gè)擴(kuò)展報(bào)頭的類型
  • 跳限制(8 比特)
    與 IPv4 報(bào)文中的 TTL 字段類似背犯,轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)的每臺(tái)路由器將對(duì)該字段的內(nèi)容減 1.如果跳限制計(jì)數(shù)到達(dá) 0,則該數(shù)據(jù)報(bào)將被丟棄
  • 源地址和目的地址(各 128 比特)
    記錄源 IP 地址盅抚,目的 IP 地址
  • 數(shù)據(jù)

可以看出媳板,在 IPv4 數(shù)據(jù)報(bào)中出現(xiàn)的幾個(gè)字段在 IPv6 數(shù)據(jù)報(bào)中已不復(fù)存在:

  • 分片/重新組裝 IPv6
    不允許在中間路由器上進(jìn)行分片和重新組裝。這種操作只能在源與目的地上執(zhí)行泉哈。如果路由器收到的 IPv6 數(shù)據(jù)報(bào)因太大不能轉(zhuǎn)發(fā)出鏈路上的話,路由器會(huì)丟掉該數(shù)據(jù)報(bào)破讨,并回一個(gè)“分組太大”的 ICMP 差錯(cuò)報(bào)文
  • 首部檢驗(yàn)和
    因?yàn)檫\(yùn)輸層和數(shù)據(jù)鏈路層協(xié)議執(zhí)行了檢驗(yàn)操作丛晦,該項(xiàng)功能在網(wǎng)絡(luò)層就沒(méi)有必要了,從而更快速處理 IP 分組
  • 選項(xiàng)
    選項(xiàng)字段不再是標(biāo)準(zhǔn) IP 首部的一部分了提陶。但并沒(méi)有消失烫沙,而是可能出現(xiàn)在 IPv6 首部中由“下一個(gè)首部”指出的位置上。即就像 TCP 或 UDP 協(xié)議首部能夠是 IP 分組中的“下一個(gè)首部”隙笆,
    選項(xiàng)字段也能是“下一個(gè)首部”

IPv6 相對(duì) IPv4 最重要的變化如下:

  • 擴(kuò)大的地址容量
    IPv6 將 IP 地址長(zhǎng)度由 32 比特增加到 128 比特锌蓄,這使得理論可存在的 IP 地址增加到 2[圖片
    上傳失敗...(image-a67865-1565268140183)]個(gè),約 340 萬(wàn)億億億億個(gè)撑柔,這是一個(gè)非常大的數(shù)字瘸爽,確保全世界再也不會(huì)用盡 IP 地址,甚 至可以為地球上每一粒沙子都分配一個(gè)唯一的 IP 地址除了單播和多播地址外铅忿, IPv6 沒(méi)有廣播這一說(shuō)法剪决,而是引入了一種稱為任播地址的新型地址,這種地址可以使數(shù)據(jù)報(bào)交付給一組主機(jī)中的任意一個(gè)
  • 簡(jiǎn)化高效的 40 字節(jié)首部
    除去共 32 字節(jié)的源地址和目標(biāo)地址外檀训,首部其余字段只占了 8 字節(jié)
  • 流標(biāo)簽與優(yōu)先級(jí)
    給屬于特殊流的分組打上標(biāo)簽柑潦,這些特殊流是發(fā)送方要求進(jìn)行特殊處理的流,如一種非默認(rèn)服務(wù)質(zhì)量或需要實(shí)時(shí)服務(wù)的流

2峻凫、IPv6 書寫和表達(dá)方式
表述和書寫時(shí)渗鬼,把長(zhǎng)度為 128 比特的 IPv6 地址分成 8 個(gè) 16 位的二進(jìn)制段、每一個(gè) 16 位的二進(jìn)制段用 4 位 的 16 進(jìn)制數(shù)表示荧琼,段間用“:”(冒號(hào))隔開(kāi)(其書寫方法和 IPv4 的十進(jìn)制數(shù)加“.”不同)譬胎。

例如:1000:0000:0000:0000:000A:000B:000C:000D就是每一個(gè) 16 位的二進(jìn)制數(shù)的段用 4 位 16 進(jìn)制數(shù)的段來(lái)表示差牛、段間用“:”(冒號(hào))隔開(kāi)的一個(gè) IPv6 地址;其中:各個(gè) 4 位 16 進(jìn)制數(shù)的段中的高位 0 允許省略银择;因此多糠,上面的 IPv6 地址也可以縮寫成:1000:0:0:0:A:B:C:D。

為了更進(jìn)一步簡(jiǎn)化浩考,IPv6 的地址規(guī)范中還規(guī)定夹孔,可以在一個(gè) IPv6 地址中最多使用一次雙冒號(hào)(::)來(lái)取代 IPv6 地址中緊密相連的多個(gè)全 0 的 16 進(jìn)制數(shù)的段(因?yàn)槿绻试S在一個(gè) IPv6 地址中使用一次以上的雙冒 號(hào)時(shí)將無(wú)法判斷 IPv6 地址的長(zhǎng)度,所以 IPv6 的地址規(guī)范中才規(guī)定:在一個(gè) IPv6 地址中最多只能使用一次 雙冒號(hào))析孽,這樣上面的 IPv6 地址還可以縮寫成:1000::A:B:C:D搭伤。

雙冒號(hào)使用的地點(diǎn)可以在 IPv6 地址的前面、后面或者是中間袜瞬;例如:對(duì)于1000:0:0:0:A:B:0:0這樣的 一個(gè) IPv6 地址怜俐,可以寫成1000::A:B:0:0,也可以寫成1000:0:0:0:A:B::邓尤;但是不能寫成 1000::A:B::拍鲤。

帶有端口號(hào)的 IPV6 地址字符串形式,地址部分應(yīng)當(dāng)用“[]”括起來(lái)汞扎,在后面跟著‘:’帶上端口號(hào)季稳,如 [A01F::0]:8000

二十六、從 IPv4 到 IPv6 的遷移

基于 IPv4 的公共因特網(wǎng)如何遷移到 IPv6 呢澈魄?這是個(gè)非尘笆螅現(xiàn)實(shí)的問(wèn)題
雖然 IPv6 使能系統(tǒng)可做成向后兼容,即能接收痹扇、發(fā)送和路由 IPv4 數(shù)據(jù)報(bào)铛漓,但已部署的 IPv4 使能系統(tǒng)卻不 能處理 IPv6 數(shù)據(jù)報(bào)

1、雙協(xié)議棧
引入IPv6使能結(jié)點(diǎn)的最直接方式是雙棧方法鲫构, 即使用該方法的IPv6結(jié)點(diǎn)還有完整的IPv4實(shí)現(xiàn)浓恶,即IPv6/IPv4 結(jié)點(diǎn),具有接收和發(fā)送 IPv4 和 IPv6 兩種數(shù)據(jù)報(bào)的能力结笨。
當(dāng)與IPv4結(jié)點(diǎn)互操作時(shí)问顷,IPv6/IPv4結(jié)點(diǎn)可使用 IPv4 數(shù)據(jù)報(bào);當(dāng)與IPv6結(jié)點(diǎn)互操作時(shí)禀梳,IPv6/IPv4 結(jié)點(diǎn)又可使用 IPv6 數(shù)據(jù)報(bào)杜窄。

IPv6/IPv4結(jié)點(diǎn)必須有 IPv6 與 IPv4 兩種地址。此外算途,它們還必須能確定另一個(gè)結(jié)點(diǎn)是否是 IPv6 使能的或 僅 IPv4 使能的塞耕。

可以使用 DNS 來(lái)解決,若要解析的結(jié)點(diǎn)名字是 IPv6 使能的嘴瓤,則 DNS 會(huì)返回一個(gè) IPv6 地址扫外,否則返回一個(gè) IPv4 地址莉钙。如果發(fā)出 DNS 請(qǐng)求的結(jié)點(diǎn)是僅 IPv4 使能的,則只返回一個(gè) IPv4 地址筛谚。

兩個(gè) IPv6 使能的結(jié)點(diǎn)不應(yīng)相互發(fā)送 IPv4 數(shù)據(jù)報(bào)磁玉,而如果發(fā)送方或接收方任意一個(gè)僅為 IPv4 使能的,則必須 使用 IPv4 數(shù)據(jù)報(bào)。

這樣就會(huì)有下面這種情況:



如圖驾讲,假如結(jié)點(diǎn) A蚊伞、B、E吮铭、F 都是 IPv6 使能的結(jié)點(diǎn)时迫,而結(jié)點(diǎn) C 和 D 是僅 IPv4 使能的結(jié)點(diǎn),那么當(dāng)按 A->B->C->D->E->F 順序發(fā)送數(shù)據(jù)報(bào)時(shí),AB 之間會(huì)發(fā) IPv6 數(shù)據(jù)報(bào)谓晌,BC 會(huì)發(fā) IPV4 數(shù)據(jù)報(bào)掠拳, 由于 IPv6 數(shù)據(jù)報(bào)特定的字段在 IPv4 數(shù)據(jù)報(bào)中無(wú)對(duì)應(yīng)的部分,這些字段將會(huì)丟失纸肉。因此溺欧,即使 E 和 F 之間能發(fā) IPv6 數(shù)據(jù)報(bào),從 D 到達(dá) E 的 IPv4 數(shù)據(jù)報(bào)并未含有從 A 發(fā)出的初始 IPv6 數(shù)據(jù)報(bào)中的所有字段柏肪。

2胧奔、隧道
建隧道是另一種雙棧方法,該方法能解決上述問(wèn)題预吆。
假定兩個(gè) IPv6 結(jié)點(diǎn)要使用 IPv6 數(shù)據(jù)報(bào)進(jìn)行交互,但是它們是經(jīng)由中間 IPv4 路由器互聯(lián)的胳泉。將兩臺(tái) IPv6 路由器中間的 IPv4 路由器的集合成為一個(gè)隧道拐叉,如 B->C->D->E。


如圖扇商,借助于隧道凤瘦,在隧道發(fā)送端的 IPv6 結(jié)點(diǎn)可將整個(gè) IPv6 數(shù)據(jù)報(bào)放到一個(gè) IPv4 數(shù)據(jù)報(bào)的數(shù)據(jù)字段中。于是案铺,該 IPv4 數(shù)據(jù)報(bào)的地址設(shè)為指向隧道接收端的 IPv6 結(jié)點(diǎn)蔬芥,再發(fā)送給隧道中的第一個(gè)結(jié)點(diǎn)。而隧道中的 IPv4 路由器在它們之間為該數(shù)據(jù)報(bào)提供路由控汉,就像對(duì)待其他 IPv4 數(shù)據(jù)報(bào)一樣笔诵,完全不知道該數(shù)據(jù)報(bào)自身就含有一個(gè)完整的 IPv6 數(shù)據(jù)報(bào)。而隧道接收端的 IPv6 結(jié)點(diǎn)最終收到該 IPv4 數(shù)據(jù)報(bào)姑子,并確定該 IPv4 數(shù)據(jù)報(bào)中含有一個(gè) IPv6 數(shù)據(jù)報(bào)乎婿,于是提取出該 IPv6 數(shù)據(jù)報(bào),然后再為該 IPv6 數(shù)據(jù)報(bào)提供路由

3街佑、NAT-PT
除了雙棧和隧道方案外谢翎,還有一種 NAT-PT(Network Address Translator - Protocol Translator)附帶協(xié)議轉(zhuǎn)換器的網(wǎng)絡(luò)地址轉(zhuǎn)換器方案

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末捍靠,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子森逮,更是在濱河造成了極大的恐慌榨婆,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,402評(píng)論 6 499
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件褒侧,死亡現(xiàn)場(chǎng)離奇詭異良风,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)璃搜,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,377評(píng)論 3 392
  • 文/潘曉璐 我一進(jìn)店門拖吼,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人这吻,你說(shuō)我怎么就攤上這事吊档。” “怎么了唾糯?”我有些...
    開(kāi)封第一講書人閱讀 162,483評(píng)論 0 353
  • 文/不壞的土叔 我叫張陵怠硼,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我移怯,道長(zhǎng)香璃,這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書人閱讀 58,165評(píng)論 1 292
  • 正文 為了忘掉前任舟误,我火速辦了婚禮葡秒,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘嵌溢。我一直安慰自己眯牧,他們只是感情好忌警,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,176評(píng)論 6 388
  • 文/花漫 我一把揭開(kāi)白布牵署。 她就那樣靜靜地躺著,像睡著了一般鳞疲。 火紅的嫁衣襯著肌膚如雪秧骑。 梳的紋絲不亂的頭發(fā)上版确,一...
    開(kāi)封第一講書人閱讀 51,146評(píng)論 1 297
  • 那天,我揣著相機(jī)與錄音乎折,去河邊找鬼绒疗。 笑死,一個(gè)胖子當(dāng)著我的面吹牛骂澄,可吹牛的內(nèi)容都是我干的忌堂。 我是一名探鬼主播,決...
    沈念sama閱讀 40,032評(píng)論 3 417
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼酗洒,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼士修!你這毒婦竟也來(lái)了枷遂?” 一聲冷哼從身側(cè)響起,我...
    開(kāi)封第一講書人閱讀 38,896評(píng)論 0 274
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤棋嘲,失蹤者是張志新(化名)和其女友劉穎酒唉,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體沸移,經(jīng)...
    沈念sama閱讀 45,311評(píng)論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡痪伦,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,536評(píng)論 2 332
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了雹锣。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片网沾。...
    茶點(diǎn)故事閱讀 39,696評(píng)論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖蕊爵,靈堂內(nèi)的尸體忽然破棺而出辉哥,到底是詐尸還是另有隱情,我是刑警寧澤攒射,帶...
    沈念sama閱讀 35,413評(píng)論 5 343
  • 正文 年R本政府宣布醋旦,位于F島的核電站,受9級(jí)特大地震影響会放,放射性物質(zhì)發(fā)生泄漏饲齐。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,008評(píng)論 3 325
  • 文/蒙蒙 一咧最、第九天 我趴在偏房一處隱蔽的房頂上張望捂人。 院中可真熱鬧,春花似錦矢沿、人聲如沸滥搭。這莊子的主人今日做“春日...
    開(kāi)封第一講書人閱讀 31,659評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至福青,卻和暖如春摄狱,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背无午。 一陣腳步聲響...
    開(kāi)封第一講書人閱讀 32,815評(píng)論 1 269
  • 我被黑心中介騙來(lái)泰國(guó)打工媒役, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人宪迟。 一個(gè)月前我還...
    沈念sama閱讀 47,698評(píng)論 2 368
  • 正文 我出身青樓酣衷,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親次泽。 傳聞我的和親對(duì)象是個(gè)殘疾皇子穿仪,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,592評(píng)論 2 353