前言

作為一名程序員，不可能不與網(wǎng)絡(luò)打交道。現(xiàn)在我們的手機，電腦，不夸張地說，離開了網(wǎng)絡(luò)就是一塊“廢鐵”，它們的作用將大打折扣。本文的作用呢，主要是針對不是非網(wǎng)絡(luò)專業(yè)開發(fā)的人員準(zhǔn)備的， 以’最短的時間，了解計網(wǎng)最多的知識’為前提起筆。

概述

先來了解下各種我們知道, 但是不太了解的專業(yè)名詞的意思

因特網(wǎng)

[[210887]]

因特網(wǎng)

因特網(wǎng)是當(dāng)今世界上最大的網(wǎng)絡(luò)，是”網(wǎng)絡(luò)的網(wǎng)絡(luò)”。 即因特網(wǎng)是所有網(wǎng)絡(luò)互連起來的一個巨型網(wǎng)絡(luò)。

因特網(wǎng)的組成：

• 邊緣部分 : 主機
• 核心部分 : 大量網(wǎng)絡(luò)和連接這些網(wǎng)絡(luò)的路由器(此路由器不是我們家用的路由器)

以太網(wǎng)

以太網(wǎng)是現(xiàn)在最常用的局域網(wǎng)通信協(xié)議， 以太網(wǎng)上傳輸?shù)氖荕AC幀。由于以太網(wǎng)同一時間只允許一臺計算機發(fā)送數(shù)據(jù)， 所以必須有一套檢測機制, 那就是CSMA/CD協(xié)議：

• 多點接入 : 多臺計算機以多點接入的方式連接在一根總線上
• 載波監(jiān)聽 : 不管是否正在發(fā)送, 每個站都必須不停地檢測信道
• 碰撞檢測 : 邊發(fā)送邊監(jiān)聽

OSI

開放系統(tǒng)互連基本參考模型，只要遵守這個OSI標(biāo)準(zhǔn)， 任何兩個系統(tǒng)都能進行通信。 OSI是七層協(xié)議體系結(jié)構(gòu)，而TCP/IP是一個四層協(xié)議體系結(jié)構(gòu)， 于是我們采取折中的方法， 學(xué)習(xí)計算機網(wǎng)絡(luò)原理的時候往往用的是五層協(xié)議的體系結(jié)構(gòu) ：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層和應(yīng)用層。

協(xié)議體系結(jié)構(gòu)

物理層

計算機的世界里只有0和1，正如你現(xiàn)在所看這篇文章的文字，存儲在計算機中也是一大串0和1的組合。 但是這些數(shù)字不能在真實的物理介質(zhì)中傳輸?shù)模?而需要把它轉(zhuǎn)換為光信號或者電信號，所以這一層負責(zé)將這些比特流(0101)與光電信號進行轉(zhuǎn)換。

如果沒有物理層， 那么也就不存在互聯(lián)網(wǎng)，不存在數(shù)據(jù)的共享，因為數(shù)據(jù)無法在網(wǎng)絡(luò)中流動。

數(shù)據(jù)鏈路層

數(shù)據(jù)在這一層不再是以比特流的形式傳輸， 而是分割成一個一個的幀再進行傳輸。

MAC地址

又稱計算機的硬件地址， 被固化在適配器(網(wǎng)卡)ROM上的占48位的地址。MAC地址可以用來唯一區(qū)別一臺計算機，因為它在全球是獨一無二的。

分組交換

由于數(shù)據(jù)在這次曾要被分割成一個一個的幀，由于不同的鏈路規(guī)定了不同的最大幀長，即MTU(最大傳輸單元)， 凡是超出這個MTU的幀都必須被分塊。 例如一臺貨車一次能運輸5噸的貨物, 而有條公路限載重2噸，那么你只好分3次運輸。

網(wǎng)橋

網(wǎng)橋工作在數(shù)據(jù)鏈路層，根據(jù)MAC幀的目的地址對收到的幀進行轉(zhuǎn)發(fā)和過濾。

以太網(wǎng)交換機

實際上就是一個多接口的網(wǎng)橋, 以太網(wǎng)交換機的每個接口都直接與一個單個主機或另一個集線器相連, 可以很容易實現(xiàn)VLAN(虛擬局域網(wǎng))

以太網(wǎng)的MAC幀

MAC幀的格式為 ：

MAC幀格式

• 目的地址 : 接收方48位的MAC地址
• 源地址 : 發(fā)送方48位的MAC地址
• 類型字段 : 標(biāo)志上一層使用的是什么協(xié)議, 0×0800為IP數(shù)據(jù)報

網(wǎng)絡(luò)層

如果只有數(shù)據(jù)鏈路層沒有網(wǎng)絡(luò)層,，數(shù)據(jù)就只能在同一條鏈路上傳輸，不能跨鏈路傳輸。有了網(wǎng)絡(luò)層，數(shù)據(jù)便能跨域不同的數(shù)據(jù)鏈路傳輸。

IP地址

IP地址又稱為軟件地址，存儲在計算機的存儲器上， IPv4地址為32位，IPv6地址為128位。

IP地址和MAC地址

• 網(wǎng)絡(luò)層以上使用IP地址, 數(shù)據(jù)鏈路層以下使用MAC地址
• IP地址是邏輯地址, MAC地址是物理地址
• IP分組中首部的源地址和目的地址在傳輸中不會改變, MAC幀中首部的源地址和目的地址每到一個路由器會改變一次

IP地址分類

IP地址 = {<網(wǎng)絡(luò)號>, <主機號>}

A類地址 : 0.0.0.0 ~ 127.0.0.0

B類地址 : 128.0.0.0 ~ 191.255.0.0

C類地址 : 192.0.0.0 ~ 223.255.255.0

劃分子網(wǎng)之后的IP地址

IP地址 = {<網(wǎng)絡(luò)號>, <子網(wǎng)號>, <主機號>}

例如某單位擁有一個B類IP地址， 145.13.0.0，但凡目的地址為145.13.x.x的數(shù)據(jù)報都會被送到這個網(wǎng)絡(luò)上的路由器R。內(nèi)部劃分子網(wǎng)后變成 : 145.13.3.0, 145.13.7.0，145.13.21.0. 但是對外仍表現(xiàn)為一個網(wǎng)絡(luò)，即145.13.0.0. 這樣路由器R收到報文后，再根據(jù)目的地址發(fā)到對應(yīng)的子網(wǎng)上。

子網(wǎng)掩碼

一般由一串1和一串0組成，不管網(wǎng)絡(luò)有沒有劃分子網(wǎng)，將子網(wǎng)掩碼和IP地址做按位與運算即可得出網(wǎng)絡(luò)地址。

所有的網(wǎng)絡(luò)都必須使用子網(wǎng)掩碼，同時在路由表中必須有子網(wǎng)掩碼這一欄。 如果一個網(wǎng)絡(luò)不劃分子網(wǎng)，那么該網(wǎng)絡(luò)的子網(wǎng)掩碼就是默認的子網(wǎng)掩碼。

A類地址的默認子網(wǎng)掩碼為255.0.0.0

B類地址的默認子網(wǎng)掩碼為255.255.0.0

C類地址的默認子網(wǎng)掩碼為255.255.255.0

盡管劃分子網(wǎng)增加了靈活性，但是卻減少了能夠連接在網(wǎng)絡(luò)上的主機總數(shù)。

構(gòu)成超網(wǎng)的IP地址

IP地址 = {<網(wǎng)絡(luò)前綴>, <主機號>}

使用網(wǎng)絡(luò)前綴， 無分類域間路由選擇CIDR。

例如，128.14.35.7/20, 意思是前20位為網(wǎng)絡(luò)前綴，后12位為主機號。 另外，CIDR把網(wǎng)絡(luò)前綴相同的連續(xù)的IP地址組成一個”CIDR地址塊”。

地址掩碼 : CIDR使用32位的地址掩碼, 類似于子網(wǎng)掩碼。

IP數(shù)據(jù)報

在網(wǎng)絡(luò)層, 數(shù)據(jù)是以IP數(shù)據(jù)報(IP分組)的形式傳輸?shù)?/p>

IP數(shù)據(jù)報的格式

首部前20字節(jié)為固定長度, 是所有IP數(shù)據(jù)報必備的. 后4字節(jié)是可選字段, 其長度可變。

IP數(shù)據(jù)報首部固定的字段分析：

• 版本號 : IP協(xié)議的版本， IPv4或IPv6。
• 首部長度 : 記錄了首部的長度，最大為1111， 即15個32位字長，即60字節(jié)。當(dāng)首部長度不是4字節(jié)的整數(shù)倍時， 需要使用最后的填充字段加以填充。
• 服務(wù)類型 : 一般無用。
• 總長度 : 指首部和數(shù)據(jù)之和的長度， 最大為216-1 = 65535字節(jié)。但是由于數(shù)據(jù)鏈路層規(guī)定每一幀的數(shù)據(jù)長度都有最大長度MTU， 以太網(wǎng)規(guī)定MTU為1500字節(jié)，所以超出范圍的數(shù)據(jù)報就必須進行分片處理。
• 標(biāo)識 : 每產(chǎn)生一個IP數(shù)據(jù)報，計數(shù)器就+1， 并將此值賦值給標(biāo)識字段。 再以后需要分片的數(shù)據(jù)報中， 標(biāo)識相同說明是同一個數(shù)據(jù)報。
• 標(biāo)志 : 占3位, 最低位記為MF(More Fragment)。 MF = 1說明還有分片；MF = 0說明這已經(jīng)是最后一個分片。 中間一位記為DF(Don’t Fragment)，意思是不能分片。 只有當(dāng)DF = 0時才允許分片。
• 段位移 : 又稱片位移， 相對于用戶數(shù)據(jù)字段的起點，該片從何處開始。 片位移以8個字節(jié)為偏移單位。 所以，每個分片的長度一定是8字節(jié)的整數(shù)倍。
• 生存時間 : TTL(Time To Live)。 數(shù)據(jù)報能在因特網(wǎng)中經(jīng)過路由器的最大次數(shù)為255次， 每經(jīng)過一個路由器則TTL – 1，為0時丟棄該報文。
• 協(xié)議 : 記錄該報文所攜帶的數(shù)據(jù)是使用何種協(xié)議。
• 首部檢驗和 : 只檢驗數(shù)據(jù)報的首部，不檢驗數(shù)據(jù)部分。 不為0則丟棄報文。
• 源地址和目的地址 : 不解釋。

IP層轉(zhuǎn)發(fā)分組的流程

每個路由器內(nèi)部都維護一個路由表， 路由表包含以下內(nèi)容(目的網(wǎng)絡(luò)地址， 下一跳地址)。

使用子網(wǎng)時分組轉(zhuǎn)發(fā)時，路由表必須包含以下三項內(nèi)容：目的網(wǎng)絡(luò)地址， 子網(wǎng)掩碼和下一跳地址。

特定主機路由 ： 對特定的目的地址指明一個路由

默認路由 ： 不知道分組該發(fā)給哪個路由器時就發(fā)給默認路由。當(dāng)一個網(wǎng)絡(luò)只有很少的對外連接時使用默認路由非常合適。

路由器的分組轉(zhuǎn)發(fā)算法

• 從數(shù)據(jù)報中拿到目的IP地址D, 得出目的網(wǎng)絡(luò)地址N
• 若N就是與此路由器直接相連的某個網(wǎng)絡(luò)地址, 則直接交付(不需要再交給其他路由器轉(zhuǎn)發(fā), 直接找到該目的主機交付), 否則 -> (3)
• 若路由表中有目的地址為D的特定主機路由, 則把數(shù)據(jù)報傳給該路由器, 否則 -> (4)
• 若路由表中有到達網(wǎng)絡(luò)N的路由, 則把數(shù)據(jù)報傳給該路由器, 否則 -> (5)
• 若路由表中有默認路由, 則交給該路由器, 否則 -> (6)
• 報告轉(zhuǎn)發(fā)分組出錯

虛擬專用網(wǎng)VPN

因特網(wǎng)中的所有路由器對該目的地址是專用地址的數(shù)據(jù)報一律不轉(zhuǎn)發(fā), 下面有3種專用地址(虛擬IP地址)

10.0.0.0 ~ 10.255.255.255

172.16.0.0 ~ 172.31.255.255

192.168.0.0 ~ 192.168.255.255

假設(shè)現(xiàn)在公司A有一個部門在廣州和另一個在上海, 而他們在當(dāng)?shù)囟加凶约旱膶Ｓ镁W(wǎng). 那么怎么將這兩個專用網(wǎng)連接起來呢?

• 租用電信的通信線路為本機構(gòu)專用, 但是太貴了
• 利用公用的因特網(wǎng)當(dāng)做通信載體, 這就是虛擬專用網(wǎng)VPN

網(wǎng)絡(luò)地址轉(zhuǎn)換NAT

多個專用網(wǎng)內(nèi)部的主機公用一個NAT路由器的IP地址, 在主機發(fā)送和接收IP數(shù)據(jù)報時必須先通過NAT路由器進行網(wǎng)絡(luò)地址轉(zhuǎn)換。

NAT路由器的工作原理

不僅如此, NAT還能使用端口號, 搖身一變成為網(wǎng)絡(luò)地址和端口轉(zhuǎn)換NAPT

ARP協(xié)議

ARP是解決同一個局域網(wǎng)上的主機或路由器的IP地址和MAC地址的映射問題, 即 IP地址 -> ARP -> MAC地址

每一個主機都有一個ARP高速緩存, 里面有本局域網(wǎng)上的各主機和路由器的IP地址到MAC地址的映射表. 以下是ARP的工作原理：

 

ARP的工作原理.jpg

那如果是跨網(wǎng)絡(luò)使用ARP呢?

• 在本網(wǎng)絡(luò)上廣播
• 未找到該主機, 則到路由器
• 路由器幫忙轉(zhuǎn)發(fā)(在另一網(wǎng)絡(luò)上廣播)
• 找到了則完成ARP請求, 未找到則返回(2)

傳輸層

這一層是重中之重, 因為數(shù)據(jù)鏈路層, 網(wǎng)絡(luò)層這兩層的數(shù)據(jù)傳輸都是不可靠的, 盡最大能力交付的. 什么意思的? 就是它們不負責(zé)提交給你的就是正確的數(shù)據(jù). 然而這一層的TCP協(xié)議將要提供可靠傳輸

這一層主要重點是兩個協(xié)議 : UDP 和 TCP

用戶數(shù)據(jù)報協(xié)議UDP

UDP主要特點 :

• 無連接
• 盡最大努力交付
• 面向報文 : 應(yīng)用層交下來的報文直接加上UDP頭部就往IP層扔, 不合并也不拆分
• 沒有擁塞控制
• 支持一對一, 一對多, 多對一和多對多的交互通信
• 首部開銷小, 只有8個字節(jié)

UDP首部

UDP首部格式

• 源端口 : 源端口號. 在需要對方回信時選用, 不需要則全0
• 目的端口 : 目的端口號. 這在終點交付報文時必須要使用到
• 長度 : UDP數(shù)據(jù)報的長度, 最小值為8(僅有首部)
• 檢驗和 : 與IP數(shù)據(jù)報只檢驗首部不同的是, UDP需要把首部和數(shù)據(jù)部分一起檢驗

傳輸控制協(xié)議TCP

TCP主要特點 :

• 面向連接的運輸層協(xié)議
• 每一條TCP連接只能有2個端點, TCP是點對點的
• 提供可靠交付
• 全雙工通信
• 面向字節(jié)流

TCP的工作流程

TCP字節(jié)流

 

TCP的連接

TCP連接的端點叫套接字(socket)

socket = (IP地址 : 端口號)

每一條TCP連接唯一地被通信兩端的兩個端點(socket)所確定. 即 :

TCP連接 ::= {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}

TCP報文段的首部

 TCP報文段的首部

• 源端口和目的端口 : 同UDP端口作用
• 序號 : 本報文段的數(shù)據(jù)的第一個字節(jié)的序號
• 確認號 : 期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號

若確認號 = N, 則表明 : 到序號N-1為止的所有數(shù)據(jù)都已正常收到

• 數(shù)據(jù)偏移 : TCP報文段的首部長度
• 保留 : 以后用, 目前為0
• 緊急URG : 若URG = 1時, 說明緊急指針字段有效, 告訴系統(tǒng)這是緊急數(shù)據(jù), 應(yīng)盡快傳送. 例如突然要中斷傳送
• 確認ACK : ACK = 1時確認號才有效, ACK = 0時確認號無效. TCP規(guī)定, 連接建立后所有傳送的報文段都必須把ACK置1
• 推送PSH : 若PSH = 1, 則接收方收到報文段之后不再等到整個緩存滿而是直接向上交付
• 復(fù)位RST : 當(dāng)RST = 1, 說明TCP連接有嚴(yán)重錯誤, 必須釋放連接再重連
• 同步SYN : 在連接建立時用來同步序號. 當(dāng)SYN = 1, ACK = 0時表明這是一個連接請求報文段, 對方若同意建立連接, 則在響應(yīng)的報文段中置SYN = 1, ACK = 1
• 終止FIN : 當(dāng)FIN = 1, 表明此報文段的發(fā)送方數(shù)據(jù)已發(fā)送完畢, 并要求釋放連接
• 窗口 : 告訴對方 : 從本報文段首部中的確認號算起, 接收方目前允許對方發(fā)送的數(shù)據(jù)量. 這是作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)
• 檢驗和 : 同UDP, 檢驗首部和數(shù)據(jù)部分
• 緊急指針 : 當(dāng)URG = 1時有效, 指出緊急數(shù)據(jù)的末尾在報文段的位置
• 選項 : 最大可40字節(jié), 沒有則為0

最大報文段長度MSS(Maximum Segment Size) : 每一個TCP報文段中數(shù)據(jù)字段的最大長度，若不填寫則為默認的536字節(jié)。

窗口

TCP中很重要的一個概念, 那就是窗口(發(fā)送窗口和接收窗口)

窗口

 

由于停止等待協(xié)議非常低效，于是衍生出窗口這一概念。上圖為發(fā)送方維持的發(fā)送窗口， 位于發(fā)送窗口的5個分組都可以連續(xù)發(fā)送出去而不需要等待對方的確認。每收到一個確認， 就把發(fā)送窗口前移一個分組的位置。這大大提高了信道利用率!

接收方不必發(fā)送每個分組的確認報文，而是采用累積確認的方式。也就是說， 對按序到達的最后一個分組發(fā)送確認報文。

超時重傳

如果發(fā)送方等待一段時間后， 還是沒收到 ACK 確認報文，就會啟動超時重傳。 這個等待的時間為重傳超時時間(RTO, Retransmission TimeOut)。

然而, RTO 的值不是固定的，這個時間總是略大于連接往返時間(RTT，Round Trip Time)。假設(shè)報文發(fā)送過去需要5秒，對方收到后發(fā)送確認報文回來也需要5秒，那么RTT就為10秒， 那這RTO就要比10秒要略大一些。那么超過RTO之后還沒有收到確認報文就認為報文丟失了，就要重傳。

流量控制

利用滑動窗口和報文段的發(fā)送時機來進行流量控制。

擁塞控制

發(fā)送方維持一個擁塞窗口cwnd, 發(fā)送窗口 = 擁塞窗口。

慢開始 : cwnd = 1, 然后每經(jīng)過一個傳輸輪次就翻倍

擁塞避免 : 讓cwnd緩慢增大, 每經(jīng)過一個傳輸輪次就+1

慢開始門限ssthresh :

當(dāng)cwnd < ssthresh, 使用慢開始算法當(dāng)cwnd > ssthresh, 使用擁塞避免算法當(dāng)cwnd = ssthresh, 隨意

擁塞控制

只要判斷網(wǎng)絡(luò)出現(xiàn)擁塞， 把ssthresh設(shè)為當(dāng)前發(fā)送擁塞窗口的一半(不能小于2)，并把cwnd設(shè)為1，重新執(zhí)行慢開始算法。

除了慢開始和擁塞避免算法外, 還有一組快重傳和快恢復(fù)算法 :

快重傳 : 接收方及時發(fā)送確認, 而發(fā)送方只要一連收到三個重復(fù)確認, 馬上重傳

快恢復(fù) : 當(dāng)發(fā)送方一連收到三個重復(fù)確認時, ssthresh減半, cwnd設(shè)為ssthresh.

TCP三次握手

TCP三次握手建立連接和四次揮手?jǐn)嚅_連接是面試愛問的知識點。

TCP三次握手

Q : 為什么要三次握手, 兩次不可以嗎?

A : 試想一下, A第一次發(fā)送請求連接, 但是在網(wǎng)絡(luò)某節(jié)點滯留了, A超時重傳, 然后這一次一切正常, A跟B就愉快地進行數(shù)據(jù)傳輸了. 等到連接釋放了以后, 那個迷失了的連接請求突然到了B那, 如果是兩次握手的話, B發(fā)送確認, 它們就算是建立起了連接了. 事實上A并不會理會這個確認, 因為我壓根沒有要傳數(shù)據(jù)啊. 但是B卻傻傻地以為有數(shù)據(jù)要來, 苦苦等待. 結(jié)果就是造成資源的浪費.

更加接地氣的解釋就是 : A打電話給B

第一次握手 : 你好, 我是A, 你能聽到我說話嗎第二次握手 : 聽到了, 我是B, 你能聽到我說話嗎第三次握手 : 聽到了, 我們可以開始聊天了三次握手其實就是為了檢測雙方的發(fā)送和接收能力是否正常, 你說呢?

TCP四次揮手

TCP四次揮手

 

Q : 為什么要四次揮手, 而不是兩次, 三次?

A :

首先, 由于TCP的全雙工通信, 雙方都能作為數(shù)據(jù)發(fā)送方. A想要關(guān)閉連接, 必須要等數(shù)據(jù)都發(fā)送完畢, 才發(fā)送FIN給B. (此時A處于半關(guān)閉狀態(tài))

然后, B發(fā)送確認ACK, 并且B此時如果要發(fā)送數(shù)據(jù), 就發(fā)送(例如做一些釋放前的處理)

再者, B發(fā)送完數(shù)據(jù)之后, 發(fā)送FIN給A. (此時B處于半關(guān)閉狀態(tài))

然后, A發(fā)送ACK, 進入TIME-WAIT狀態(tài)

最后, 經(jīng)過2MSL時間后沒有收到B傳來的報文, 則確定B收到了ACK了. (此時A, B才算是處于完全關(guān)閉狀態(tài))

PS : 仔細分析以上步驟就知道為什么不能少于四次揮手了.

Q : 為什么要等待2MSL(Maximum Segment Lifetime)時間, 才從TIME_WAIT到CLOSED？

A : 在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復(fù)所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

更加接地氣的解釋 :

第一次揮手 : A告訴B, 我沒數(shù)據(jù)發(fā)了, 準(zhǔn)備關(guān)閉連接了, 你要發(fā)送數(shù)據(jù)嗎第二次揮手 : B發(fā)送最后的數(shù)據(jù)第三次揮手 : B告訴A, 我也要關(guān)閉連接了第四次揮手 : A告訴B你可以關(guān)閉了, 我這邊也關(guān)閉了

應(yīng)用層

應(yīng)用層協(xié)議最著名的就是HTTP, FTP了, 還有一個重要的DNS

域名系統(tǒng)(DNS, Domain Name System)

DNS 能將域名(例如, www.jianshu.com)解析成IP地址。

域名服務(wù)器分類

• 根域名服務(wù)器 : 最高層次的域名服務(wù)器
• 頂級域名服務(wù)器 : 如其名
• 權(quán)限域名服務(wù)器 : 負責(zé)一個區(qū)的應(yīng)服務(wù)器
• 本地域名服務(wù)器 : 主機發(fā)送DNS查詢請求就是發(fā)給它

DNS查詢

DNS查詢

• 主機向本地域名服務(wù)器的查詢一般都是采用遞歸查詢
• 本地域名服務(wù)器向根域名服務(wù)器的查詢通常是采用迭代查詢

遞歸查詢 : B問A廣州怎么去, A不知道, A就問C, C不知道就問D...直到知道了再一層一層轉(zhuǎn)告直到A告訴B.  迭代查詢 : B問A廣州怎么去, A不知道, A就告訴你可以去問C, 然后B就去問C, C不知道, C就告訴你可以去問D, 然后B就去問D...直到B知道為止

DNS查詢例子 : 域名為x.tom.com的主機想知道y.jerry.com的IP地址

• 主機x.tom.com先向本地域名服務(wù)器dns.tom.com進行遞歸查詢
• 本地域名服務(wù)器采用迭代查詢. 它先問一個根域名服務(wù)器
• 根域名服務(wù)器告訴它, 你去問頂級域名服務(wù)器dns.com
• 本地域名服務(wù)器問頂級域名服務(wù)器dns.com
• 頂級域名服務(wù)器告訴它, 你去問權(quán)限域名服務(wù)器dns.jerry.com
• 本地域名服務(wù)器問權(quán)限域名服務(wù)器dns.jerry.com
• 權(quán)限域名服務(wù)器dns.jerry.com告訴它所查詢的主機的IP地址
• 本地域名服務(wù)器把查詢結(jié)果告訴主機x.tom.com

PS : 該查詢使用UDP, 并且為了提高DNS查詢效率, 每個域名服務(wù)器都使用高速緩存.

URL

URL的格式 : <協(xié)議>://<主機>:<端口>/<路徑>, 端口和路徑有時可省略.

使用HTTP協(xié)議的URL : http://<主機>:<端口>/<路徑>, HTTP默認端口號是80

HTTP協(xié)議

HTTP是面向事務(wù)的, 即它傳輸?shù)臄?shù)據(jù)是一個整體, 要么全部收到, 要么全部收不到.

萬維網(wǎng)的工作過程

 

每一次HTTP請求就需要建立一次TCP連接和釋放TCP連接.

HTTP是無連接, 無狀態(tài)的. 每一次請求都是作為一次新請求.

HTTP/1.0 缺點 : 無連接, 每一次請求都要重新建立TCP連接, 所以每一次HTTP請求都要花費2倍RTT時間(一次TCP請求, 一次HTTP請求)

HTTP/1.1 : 使用持續(xù)連接, 即保持TCP連接一段時間.

HTTP/1.1持續(xù)工作的兩種工作方式 : 非流水線方式和流水線方式    非流水線方式 : 收到一個請求的響應(yīng)再發(fā)下一個請求, 效率低, 浪費資源    流水線方式 : 能夠同時發(fā)送多個請求, 效率高

HTTP的GET和POST

GET 請求通常用于查詢、獲取數(shù)據(jù)，而 POST 請求則用于發(fā)送數(shù)據(jù)

GET 請求的參數(shù)在URL中, 因此絕不能用GET請求傳輸敏感數(shù)據(jù), 而POST 請求的參數(shù)在請求頭中, 安全性略高于GET請求

ps : POST請求的數(shù)據(jù)也是以明文的形式存放在請求頭中, 因此也不安全

Cookie

萬維網(wǎng)使用Cookie來跟蹤用戶, 表示HTTP服務(wù)器和用戶之間傳遞的狀態(tài)信息.

Cookie工作原理 :

1. 用戶瀏覽某網(wǎng)站， 該網(wǎng)站的服務(wù)器為用戶產(chǎn)生一個唯一的識別碼，并以此為索引在服務(wù)器后端數(shù)據(jù)庫中產(chǎn)生一個項目

2. 返回給用戶的HTTP響應(yīng)報文中添加一條 "Set-cookie"，值為該識別碼，如1233。用戶的瀏覽器將該cookie保存起來，在用于繼續(xù)瀏覽該網(wǎng)站時發(fā)送的每一個HTTP請求都會有一行 Cookie： 123于是，這個網(wǎng)站就知道Cookie為123的這個用戶做了什么，為這個用戶維護一個獨立的列表(如購物車)。

當(dāng)然，Cookie是把雙刃劍，方便的同時也帶有危險性，例如隱私泄露等， 用戶可以自行決定是否使用Cookie。

Session

Cookie是保存在客戶端上的，而Session是保存在服務(wù)器中。當(dāng)服務(wù)器收到用戶發(fā)出的Cookie時， 會根據(jù)Cookie中的SessionID來查找對應(yīng)的Session，如沒有則會生成一個新的SessionID返回給用戶。

總而言之，Cookie和Session就是同一樣?xùn)|西存放地方不同而已。

HTTPS

HTTPS協(xié)議 

HTTPS協(xié)議在HTTP協(xié)議的基礎(chǔ)上，在HTTP和TCP中間加入了一層SSL/TLS加密層， 解決了HTTP不安全的問題： 冒充， 篡改， 竊聽三大風(fēng)險。