計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)大全
計(jì)算機(jī)的世界里只有0和1, 正如你現(xiàn)在所看這篇文章的文字, 存儲(chǔ)在計(jì)算機(jī)中也是一大串0和1的組合. 但是這些數(shù)字不能在真實(shí)的物理介質(zhì)中傳輸?shù)? 而需要把它轉(zhuǎn)換為光信號(hào)或者電信號(hào), 所以這一層負(fù)責(zé)將這些比特流(0101)與光電信號(hào)進(jìn)行轉(zhuǎn)換.下面是小編為大家?guī)?lái)的計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)的知識(shí)，歡迎閱讀。
因特網(wǎng)
因特網(wǎng)是當(dāng)今世界上最大的網(wǎng)絡(luò), 是”網(wǎng)絡(luò)的網(wǎng)絡(luò)”. 即因特網(wǎng)是所有網(wǎng)絡(luò)互連起來(lái)的一個(gè)巨型網(wǎng)絡(luò).
因特網(wǎng)的組成 :
邊緣部分 : 主機(jī)
核心部分 : 大量網(wǎng)絡(luò)和連接這些網(wǎng)絡(luò)的路由器(此路由器不是我們家用的路由器)
以太網(wǎng)
以太網(wǎng)是現(xiàn)在最常用的局域網(wǎng)通信協(xié)議, 以太網(wǎng)上傳輸?shù)氖荕AC幀. 由于以太網(wǎng)同一時(shí)間只允許一臺(tái)計(jì)算機(jī)發(fā)送數(shù)據(jù), 所以必須有一套檢測(cè)機(jī)制, 那就是CSMA/CD協(xié)議 :
多點(diǎn)接入 : 多臺(tái)計(jì)算機(jī)以多點(diǎn)接入的方式連接在一根總線(xiàn)上
載波監(jiān)聽(tīng) : 不管是否正在發(fā)送, 每個(gè)站都必須不停地檢測(cè)信道
碰撞檢測(cè) : 邊發(fā)送邊監(jiān)聽(tīng)
OSI
開(kāi)放系統(tǒng)互連基本參考模型, 只要遵守這個(gè)OSI標(biāo)準(zhǔn), 任何兩個(gè)系統(tǒng)都能進(jìn)行通信. OSI是七層協(xié)議體系結(jié)構(gòu), 而TCP/IP是一個(gè)四層協(xié)議體系結(jié)構(gòu), 于是我們采取折中的方法, 學(xué)習(xí)計(jì)算機(jī)網(wǎng)絡(luò)原理的時(shí)候往往用的是五層協(xié)議的體系結(jié)構(gòu) : 物理層, 數(shù)據(jù)鏈路層, 網(wǎng)絡(luò)層, 傳輸層和應(yīng)用層
協(xié)議體系結(jié)構(gòu)
物理層
計(jì)算機(jī)的世界里只有0和1, 正如你現(xiàn)在所看這篇文章的文字, 存儲(chǔ)在計(jì)算機(jī)中也是一大串0和1的組合. 但是這些數(shù)字不能在真實(shí)的物理介質(zhì)中傳輸?shù)? 而需要把它轉(zhuǎn)換為光信號(hào)或者電信號(hào), 所以這一層負(fù)責(zé)將這些比特流(0101)與光電信號(hào)進(jìn)行轉(zhuǎn)換.
如果沒(méi)有物理層, 那么也就不存在互聯(lián)網(wǎng), 不存在數(shù)據(jù)的共享, 因?yàn)閿?shù)據(jù)無(wú)法在網(wǎng)絡(luò)中流動(dòng).
數(shù)據(jù)鏈路層
數(shù)據(jù)在這一層不再是以比特流的形式傳輸, 而是分割成一個(gè)一個(gè)的幀再進(jìn)行傳輸.
MAC地址
又稱(chēng)計(jì)算機(jī)的硬件地址, 被固化在適配器(網(wǎng)卡)ROM上的占48位的地址. MAC地址可以用來(lái)唯一區(qū)別一臺(tái)計(jì)算機(jī), 因?yàn)樗谌蚴仟?dú)一無(wú)二的
分組交換
由于數(shù)據(jù)在這次曾要被分割成一個(gè)一個(gè)的幀, 由于不同的鏈路規(guī)定了不同的最大幀長(zhǎng), 即MTU(最大傳輸單元), 凡是超出這個(gè)MTU的幀都必須被分塊. 例如一臺(tái)貨車(chē)一次能運(yùn)輸5噸的貨物, 而有條公路限載重2噸, 那么你只好分3次運(yùn)輸.
網(wǎng)橋
網(wǎng)橋工作在數(shù)據(jù)鏈路層, 根據(jù)MAC幀的目的地址對(duì)收到的幀進(jìn)行轉(zhuǎn)發(fā)和過(guò)濾.
以太網(wǎng)交換機(jī)
實(shí)際上就是一個(gè)多接口的網(wǎng)橋, 以太網(wǎng)交換機(jī)的每個(gè)接口都直接與一個(gè)單個(gè)主機(jī)或另一個(gè)集線(xiàn)器相連, 可以很容易實(shí)現(xiàn)VLAN(虛擬局域網(wǎng))
以太網(wǎng)的MAC幀
MAC幀的格式為 :
MAC幀格式
目的地址 : 接收方48位的MAC地址
源地址 : 發(fā)送方48位的MAC地址
類(lèi)型字段 : 標(biāo)志上一層使用的是什么協(xié)議, 0×0800為IP數(shù)據(jù)報(bào)
網(wǎng)絡(luò)層
如果只有數(shù)據(jù)鏈路層沒(méi)有網(wǎng)絡(luò)層, 數(shù)據(jù)就只能在同一條鏈路上傳輸, 不能跨鏈路傳輸. 有了網(wǎng)絡(luò)層, 數(shù)據(jù)便能跨域不同的數(shù)據(jù)鏈路傳輸.
IP地址
IP地址又稱(chēng)為軟件地址, 存儲(chǔ)在計(jì)算機(jī)的存儲(chǔ)器上, IPv4地址為32位, IPv6地址為128位
IP地址和MAC地址
網(wǎng)絡(luò)層以上使用IP地址, 數(shù)據(jù)鏈路層以下使用MAC地址
IP地址是邏輯地址, MAC地址是物理地址
IP分組中首部的源地址和目的地址在傳輸中不會(huì)改變, MAC幀中首部的源地址和目的地址每到一個(gè)路由器會(huì)改變一次
IP地址分類(lèi)
IP地址 = {<網(wǎng)絡(luò)號(hào)>, <主機(jī)號(hào)>}
A類(lèi)地址 : 0.0.0.0 ~ 127.0.0.0
B類(lèi)地址 : 128.0.0.0 ~ 191.255.0.0
C類(lèi)地址 : 192.0.0.0 ~ 223.255.255.0
劃分子網(wǎng)之后的IP地址
IP地址 = {<網(wǎng)絡(luò)號(hào)>, <子網(wǎng)號(hào)>, <主機(jī)號(hào)>}
例如某單位擁有一個(gè)B類(lèi)IP地址, 145.13.0.0, 但凡目的地址為145.13.x.x的數(shù)據(jù)報(bào)都會(huì)被送到這個(gè)網(wǎng)絡(luò)上的路由器R. 內(nèi)部劃分子網(wǎng)后變成 : 145.13.3.0, 145.13.7.0, 145.13.21.0. 但是對(duì)外仍表現(xiàn)為一個(gè)網(wǎng)絡(luò), 即145.13.0.0. 這樣路由器R收到報(bào)文后, 再根據(jù)目的地址發(fā)到對(duì)應(yīng)的子網(wǎng)上.
子網(wǎng)掩碼
一般由一串1和一串0組成, 不管網(wǎng)絡(luò)有沒(méi)有劃分子網(wǎng), 將子網(wǎng)掩碼和IP地址做按位與運(yùn)算即可得出網(wǎng)絡(luò)地址.
所有的網(wǎng)絡(luò)都必須使用子網(wǎng)掩碼, 同時(shí)在路由表中必須有子網(wǎng)掩碼這一欄. 如果一個(gè)網(wǎng)絡(luò)不劃分子網(wǎng), 那么該網(wǎng)絡(luò)的子網(wǎng)掩碼就是默認(rèn)的子網(wǎng)掩碼.
A類(lèi)地址的默認(rèn)子網(wǎng)掩碼為255.0.0.0
B類(lèi)地址的默認(rèn)子網(wǎng)掩碼為255.255.0.0
C類(lèi)地址的默認(rèn)子網(wǎng)掩碼為255.255.255.0
盡管劃分子網(wǎng)增加了靈活性, 但是卻減少了能夠連接在網(wǎng)絡(luò)上的主機(jī)總數(shù).
構(gòu)成超網(wǎng)的IP地址
IP地址 = {<網(wǎng)絡(luò)前綴>, <主機(jī)號(hào)>}
使用網(wǎng)絡(luò)前綴, 無(wú)分類(lèi)域間路由選擇CIDR
例如, 128.14.35.7/20, 意思是前20位為網(wǎng)絡(luò)前綴, 后12位為主機(jī)號(hào). 另外, CIDR把網(wǎng)絡(luò)前綴相同的連續(xù)的IP地址組成一個(gè)”CIDR地址塊”
地址掩碼 : CIDR使用32位的地址掩碼, 類(lèi)似于子網(wǎng)掩碼.
IP數(shù)據(jù)報(bào)
在網(wǎng)絡(luò)層, 數(shù)據(jù)是以IP數(shù)據(jù)報(bào)(IP分組)的形式傳輸?shù)?/p>
IP數(shù)據(jù)報(bào)的格式
首部前20字節(jié)為固定長(zhǎng)度, 是所有IP數(shù)據(jù)報(bào)必備的. 后4字節(jié)是可選字段, 其長(zhǎng)度可變.
IP數(shù)據(jù)報(bào)首部固定的字段分析 :
版本號(hào) : IP協(xié)議的版本, IPv4或IPv6
首部長(zhǎng)度 : 記錄了首部的長(zhǎng)度, 最大為1111, 即15個(gè)32位字長(zhǎng), 即60字節(jié). 當(dāng)首部長(zhǎng)度不是4字節(jié)的整數(shù)倍時(shí), 需要使用最后的填充字段加以填充.
服務(wù)類(lèi)型 : 一般無(wú)用
總長(zhǎng)度 : 指首部和數(shù)據(jù)之和的長(zhǎng)度. 最大為216-1 = 65535字節(jié). 但是由于數(shù)據(jù)鏈路層規(guī)定每一幀的數(shù)據(jù)長(zhǎng)度都有最大長(zhǎng)度MTU, 以太網(wǎng)規(guī)定MTU為1500字節(jié), 所以超出范圍的數(shù)據(jù)報(bào)就必須進(jìn)行分片處理
標(biāo)識(shí) : 每產(chǎn)生一個(gè)IP數(shù)據(jù)報(bào), 計(jì)數(shù)器就+1, 并將此值賦值給標(biāo)識(shí)字段. 再以后需要分片的數(shù)據(jù)報(bào)中, 標(biāo)識(shí)相同說(shuō)明是同一個(gè)數(shù)據(jù)報(bào)
標(biāo)志 : 占3位, 最低位記為MF(More Fragment). MF = 1說(shuō)明還有分片; MF = 0說(shuō)明這已經(jīng)是最后一個(gè)分片. 中間一位記為DF(Don’t Fragment), 意思是不能分片. 只有當(dāng)DF = 0時(shí)才允許分片.
段位移 : 又稱(chēng)片位移, 相對(duì)于用戶(hù)數(shù)據(jù)字段的起點(diǎn), 該片從何處開(kāi)始. 片位移以8個(gè)字節(jié)為偏移單位. 所以, 每個(gè)分片的長(zhǎng)度一定是8字節(jié)的整數(shù)倍.
生存時(shí)間 : TTL(Time To Live). 數(shù)據(jù)報(bào)能在因特網(wǎng)中經(jīng)過(guò)路由器的最大次數(shù)為255次, 每經(jīng)過(guò)一個(gè)路由器則TTL – 1, 為0時(shí)丟棄該報(bào)文.
協(xié)議 : 記錄該報(bào)文所攜帶的數(shù)據(jù)是使用何種協(xié)議.
首部檢驗(yàn)和 : 只檢驗(yàn)數(shù)據(jù)報(bào)的首部, 不檢驗(yàn)數(shù)據(jù)部分. 不為0則丟棄報(bào)文.
源地址和目的地址 : 不解釋
IP層轉(zhuǎn)發(fā)分組的流程
每個(gè)路由器內(nèi)部都維護(hù)一個(gè)路由表, 路由表包含以下內(nèi)容(目的網(wǎng)絡(luò)地址, 下一跳地址).
使用子網(wǎng)時(shí)分組轉(zhuǎn)發(fā)時(shí), 路由表必須包含以下三項(xiàng)內(nèi)容: 目的網(wǎng)絡(luò)地址, 子網(wǎng)掩碼和下一跳地址.
特定主機(jī)路由 : 對(duì)特定的目的地址指明一個(gè)路由
默認(rèn)路由 : 不知道分組該發(fā)給哪個(gè)路由器時(shí)就發(fā)給默認(rèn)路由. 當(dāng)一個(gè)網(wǎng)絡(luò)只有很少的對(duì)外連接時(shí)使用默認(rèn)路由非常合適.
路由器的分組轉(zhuǎn)發(fā)算法
從數(shù)據(jù)報(bào)中拿到目的IP地址D, 得出目的網(wǎng)絡(luò)地址N
若N就是與此路由器直接相連的某個(gè)網(wǎng)絡(luò)地址, 則直接交付(不需要再交給其他路由器轉(zhuǎn)發(fā), 直接找到該目的主機(jī)交付), 否則 -> (3)
若路由表中有目的地址為D的特定主機(jī)路由, 則把數(shù)據(jù)報(bào)傳給該路由器, 否則 -> (4)
若路由表中有到達(dá)網(wǎng)絡(luò)N的路由, 則把數(shù)據(jù)報(bào)傳給該路由器, 否則 -> (5)
若路由表中有默認(rèn)路由, 則交給該路由器, 否則 -> (6)
報(bào)告轉(zhuǎn)發(fā)分組出錯(cuò)
虛擬專(zhuān)用網(wǎng)VPN
因特網(wǎng)中的所有路由器對(duì)該目的地址是專(zhuān)用地址的數(shù)據(jù)報(bào)一律不轉(zhuǎn)發(fā), 下面有3種專(zhuān)用地址(虛擬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有一個(gè)部門(mén)在廣州和另一個(gè)在上海, 而他們?cè)诋?dāng)?shù)囟加凶约旱膶?zhuān)用網(wǎng). 那么怎么將這兩個(gè)專(zhuān)用網(wǎng)連接起來(lái)呢?
租用電信的通信線(xiàn)路為本機(jī)構(gòu)專(zhuān)用, 但是太貴了
利用公用的因特網(wǎng)當(dāng)做通信載體, 這就是虛擬專(zhuān)用網(wǎng)VPN
網(wǎng)絡(luò)地址轉(zhuǎn)換NAT
多個(gè)專(zhuān)用網(wǎng)內(nèi)部的主機(jī)公用一個(gè)NAT路由器的IP地址, 在主機(jī)發(fā)送和接收IP數(shù)據(jù)報(bào)時(shí)必須先通過(guò)NAT路由器進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換.
NAT路由器的工作原理
不僅如此, NAT還能使用端口號(hào), 搖身一變成為網(wǎng)絡(luò)地址和端口轉(zhuǎn)換NAPT
ARP協(xié)議
ARP是解決同一個(gè)局域網(wǎng)上的主機(jī)或路由器的IP地址和MAC地址的映射問(wèn)題, 即 IP地址 -> ARP -> MAC地址
每一個(gè)主機(jī)都有一個(gè)ARP高速緩存, 里面有本局域網(wǎng)上的各主機(jī)和路由器的IP地址到MAC地址的映射表. 以下是ARP的工作原理 :
那如果是跨網(wǎng)絡(luò)使用ARP呢?
在本網(wǎng)絡(luò)上廣播
未找到該主機(jī), 則到路由器
路由器幫忙轉(zhuǎn)發(fā)(在另一網(wǎng)絡(luò)上廣播)
找到了則完成ARP請(qǐng)求, 未找到則返回(2)
傳輸層
這一層是重中之重, 因?yàn)閿?shù)據(jù)鏈路層, 網(wǎng)絡(luò)層這兩層的數(shù)據(jù)傳輸都是不可靠的, 盡最大能力交付的. 什么意思的.? 就是它們不負(fù)責(zé)提交給你的就是正確的數(shù)據(jù). 然而這一層的TCP協(xié)議將要提供可靠傳輸
這一層主要重點(diǎn)是兩個(gè)協(xié)議 : UDP 和 TCP
用戶(hù)數(shù)據(jù)報(bào)協(xié)議UDP
UDP主要特點(diǎn) :
無(wú)連接
盡最大努力交付
面向報(bào)文 : 應(yīng)用層交下來(lái)的報(bào)文直接加上UDP頭部就往IP層扔, 不合并也不拆分
沒(méi)有擁塞控制
支持一對(duì)一, 一對(duì)多, 多對(duì)一和多對(duì)多的交互通信
首部開(kāi)銷(xiāo)小, 只有8個(gè)字節(jié)
UDP首部
UDP首部格式
源端口 : 源端口號(hào). 在需要對(duì)方回信時(shí)選用, 不需要?jiǎng)t全0
目的端口 : 目的端口號(hào). 這在終點(diǎn)交付報(bào)文時(shí)必須要使用到
長(zhǎng)度 : UDP數(shù)據(jù)報(bào)的長(zhǎng)度, 最小值為8(僅有首部)
檢驗(yàn)和 : 與IP數(shù)據(jù)報(bào)只檢驗(yàn)首部不同的是, UDP需要把首部和數(shù)據(jù)部分一起檢驗(yàn)
傳輸控制協(xié)議TCP
TCP主要特點(diǎn) :
面向連接的運(yùn)輸層協(xié)議
每一條TCP連接只能有2個(gè)端點(diǎn), TCP是點(diǎn)對(duì)點(diǎn)的
提供可靠交付
全雙工通信
面向字節(jié)流
TCP的工作流程
TCP字節(jié)流
TCP的連接
TCP連接的端點(diǎn)叫套接字(socket)
socket = (IP地址 : 端口號(hào))
每一條TCP連接唯一地被通信兩端的兩個(gè)端點(diǎn)(socket)所確定. 即 :
TCP連接 ::= {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}
TCP報(bào)文段的首部
1862021-96ebb99a0ddcdbcb
TCP報(bào)文段的首部
源端口和目的端口 : 同UDP端口作用
序號(hào) : 本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)
確認(rèn)號(hào) : 期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)
若確認(rèn)號(hào) = N, 則表明 : 到序號(hào)N-1為止的所有數(shù)據(jù)都已正常收到
數(shù)據(jù)偏移 : TCP報(bào)文段的首部長(zhǎng)度
保留 : 以后用, 目前為0
緊急URG : 若URG = 1時(shí), 說(shuō)明緊急指針字段有效, 告訴系統(tǒng)這是緊急數(shù)據(jù), 應(yīng)盡快傳送. 例如突然要中斷傳送
確認(rèn)ACK : ACK = 1時(shí)確認(rèn)號(hào)才有效, ACK = 0時(shí)確認(rèn)號(hào)無(wú)效. TCP規(guī)定, 連接建立后所有傳送的報(bào)文段都必須把ACK置1
推送PSH : 若PSH = 1, 則接收方收到報(bào)文段之后不再等到整個(gè)緩存滿(mǎn)而是直接向上交付
復(fù)位RST : 當(dāng)RST = 1, 說(shuō)明TCP連接有嚴(yán)重錯(cuò)誤, 必須釋放連接再重連
同步SYN : 在連接建立時(shí)用來(lái)同步序號(hào). 當(dāng)SYN = 1, ACK = 0時(shí)表明這是一個(gè)連接請(qǐng)求報(bào)文段, 對(duì)方若同意建立連接, 則在響應(yīng)的報(bào)文段中置SYN = 1, ACK = 1
終止FIN : 當(dāng)FIN = 1, 表明此報(bào)文段的發(fā)送方數(shù)據(jù)已發(fā)送完畢, 并要求釋放連接
窗口 : 告訴對(duì)方 : 從本報(bào)文段首部中的確認(rèn)號(hào)算起, 接收方目前允許對(duì)方發(fā)送的數(shù)據(jù)量. 這是作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)
檢驗(yàn)和 : 同UDP, 檢驗(yàn)首部和數(shù)據(jù)部分
緊急指針 : 當(dāng)URG = 1時(shí)有效, 指出緊急數(shù)據(jù)的末尾在報(bào)文段的位置
選項(xiàng) : 最大可40字節(jié), 沒(méi)有則為0
最大報(bào)文段長(zhǎng)度MSS(Maximum Segment Size) : 每一個(gè)TCP報(bào)文段中數(shù)據(jù)字段的最大長(zhǎng)度, 若不填寫(xiě)則為默認(rèn)的536字節(jié).
窗口
TCP中很重要的一個(gè)概念, 那就是窗口(發(fā)送窗口和接收窗口)
由于停止等待協(xié)議非常低效, 于是衍生出窗口這一概念. 上圖為發(fā)送方維持的發(fā)送窗口, 位于發(fā)送窗口的5個(gè)分組都可以連續(xù)發(fā)送出去而不需要等待對(duì)方的確認(rèn). 每收到一個(gè)確認(rèn), 就把發(fā)送窗口前移一個(gè)分組的位置. 這大大提高了信道利用率!
接收方不必發(fā)送每個(gè)分組的確認(rèn)報(bào)文, 而是采用累積確認(rèn)的方式. 也就是說(shuō), 對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)報(bào)文.
超時(shí)重傳
如果發(fā)送方等待一段時(shí)間后, 還是沒(méi)收到 ACK 確認(rèn)報(bào)文, 就會(huì)啟動(dòng)超時(shí)重傳. 這個(gè)等待的時(shí)間為重傳超時(shí)時(shí)間(RTO, Retransmission TimeOut).
然而, RTO 的值不是固定的, 這個(gè)時(shí)間總是略大于連接往返時(shí)間(RTT，Round Trip Time). 假設(shè)報(bào)文發(fā)送過(guò)去需要5秒, 對(duì)方收到后發(fā)送確認(rèn)報(bào)文回來(lái)也需要5秒, 那么RTT就為10秒, 那這RTO就要比10秒要略大一些. 那么超過(guò)RTO之后還沒(méi)有收到確認(rèn)報(bào)文就認(rèn)為報(bào)文丟失了, 就要重傳.
流量控制
利用滑動(dòng)窗口和報(bào)文段的發(fā)送時(shí)機(jī)來(lái)進(jìn)行流量控制.
擁塞控制
發(fā)送方維持一個(gè)擁塞窗口cwnd, 發(fā)送窗口 = 擁塞窗口.
慢開(kāi)始 : cwnd = 1, 然后每經(jīng)過(guò)一個(gè)傳輸輪次就翻倍
擁塞避免 : 讓cwnd緩慢增大, 每經(jīng)過(guò)一個(gè)傳輸輪次就+1
慢開(kāi)始門(mén)限ssthresh :
當(dāng)cwnd < ssthresh, 使用慢開(kāi)始算法
當(dāng)cwnd > ssthresh, 使用擁塞避免算法
當(dāng)cwnd = ssthresh, 隨意
只要判斷網(wǎng)絡(luò)出現(xiàn)擁塞, 把ssthresh設(shè)為當(dāng)前發(fā)送擁塞窗口的一半(不能小于2), 并把cwnd設(shè)為1, 重新執(zhí)行慢開(kāi)始算法.
除了慢開(kāi)始和擁塞避免算法外, 還有一組快重傳和快恢復(fù)算法 :
快重傳 : 接收方及時(shí)發(fā)送確認(rèn), 而發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn), 馬上重傳
快恢復(fù) : 當(dāng)發(fā)送方一連收到三個(gè)重復(fù)確認(rèn)時(shí), ssthresh減半, cwnd設(shè)為ssthresh.
TCP三次握手
TCP三次握手建立連接和四次揮手?jǐn)嚅_(kāi)連接是面試愛(ài)問(wèn)的知識(shí)點(diǎn).
Q : 為什么要三次握手, 兩次不可以嗎?
A : 試想一下, A第一次發(fā)送請(qǐng)求連接, 但是在網(wǎng)絡(luò)某節(jié)點(diǎn)滯留了, A超時(shí)重傳, 然后這一次一切正常, A跟B就愉快地進(jìn)行數(shù)據(jù)傳輸了. 等到連接釋放了以后, 那個(gè)迷失了的連接請(qǐng)求突然到了B那, 如果是兩次握手的話(huà), B發(fā)送確認(rèn), 它們就算是建立起了連接了. 事實(shí)上A并不會(huì)理會(huì)這個(gè)確認(rèn), 因?yàn)槲覊焊鶝](méi)有要傳數(shù)據(jù)啊. 但是B卻傻傻地以為有數(shù)據(jù)要來(lái), 苦苦等待. 結(jié)果就是造成資源的浪費(fèi).
更加接地氣的解釋就是 : A打電話(huà)給B
第一次握手 : 你好, 我是A, 你能聽(tīng)到我說(shuō)話(huà)嗎
第二次握手 : 聽(tīng)到了, 我是B, 你能聽(tīng)到我說(shuō)話(huà)嗎
第三次握手 : 聽(tīng)到了, 我們可以開(kāi)始聊天了
三次握手其實(shí)就是為了檢測(cè)雙方的發(fā)送和接收能力是否正常, 你說(shuō)呢?
TCP四次揮手
Q : 為什么要四次揮手, 而不是兩次, 三次?
A :
首先, 由于TCP的全雙工通信, 雙方都能作為數(shù)據(jù)發(fā)送方. A想要關(guān)閉連接, 必須要等數(shù)據(jù)都發(fā)送完畢, 才發(fā)送FIN給B. (此時(shí)A處于半關(guān)閉狀態(tài))
然后, B發(fā)送確認(rèn)ACK, 并且B此時(shí)如果要發(fā)送數(shù)據(jù), 就發(fā)送(例如做一些釋放前的處理)
再者, B發(fā)送完數(shù)據(jù)之后, 發(fā)送FIN給A. (此時(shí)B處于半關(guān)閉狀態(tài))
然后, A發(fā)送ACK, 進(jìn)入TIME-WAIT狀態(tài)
最后, 經(jīng)過(guò)2MSL時(shí)間后沒(méi)有收到B傳來(lái)的報(bào)文, 則確定B收到了ACK了. (此時(shí)A, B才算是處于完全關(guān)閉狀態(tài))
PS : 仔細(xì)分析以上步驟就知道為什么不能少于四次揮手了.
Q : 為什么要等待2MSL(Maximum Segment Lifetime)時(shí)間, 才從TIME_WAIT到CLOSED?
A : 在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒(méi)有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認(rèn)Server接收到了該ACK。Client會(huì)在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會(huì)設(shè)置一個(gè)計(jì)時(shí)器，等待2MSL的時(shí)間。如果在該時(shí)間內(nèi)再次收到FIN，那么Client會(huì)重發(fā)ACK并再次等待2MSL。MSL指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間，2MSL就是一個(gè)發(fā)送和一個(gè)回復(fù)所需的最大時(shí)間。如果直到2MSL，Client都沒(méi)有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。
更加接地氣的解釋 :
第一次揮手 : A告訴B, 我沒(méi)數(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了, 還有一個(gè)重要的DNS
域名系統(tǒng)(DNS, Domain Name System)
DNS 能將域名(例如, )解析成IP地址.
域名服務(wù)器分類(lèi)
根域名服務(wù)器 : 最高層次的域名服務(wù)器
頂級(jí)域名服務(wù)器 : 如其名
權(quán)限域名服務(wù)器 : 負(fù)責(zé)一個(gè)區(qū)的應(yīng)服務(wù)器
本地域名服務(wù)器 : 主機(jī)發(fā)送DNS查詢(xún)請(qǐng)求就是發(fā)給它
DNS查詢(xún)
主機(jī)向本地域名服務(wù)器的查詢(xún)一般都是采用遞歸查詢(xún)
本地域名服務(wù)器向根域名服務(wù)器的查詢(xún)通常是采用迭代查詢(xún)
遞歸查詢(xún) : B問(wèn)A廣州怎么去, A不知道, A就問(wèn)C, C不知道就問(wèn)D...直到知道了再一層一層轉(zhuǎn)告直到A告訴B.
迭代查詢(xún) : B問(wèn)A廣州怎么去, A不知道, A就告訴你可以去問(wèn)C, 然后B就去問(wèn)C, C不知道, C就告訴你可以去問(wèn)D, 然后B就去問(wèn)D...直到B知道為止
DNS查詢(xún)例子 : 域名為x.tom.com的主機(jī)想知道y.jerry.com的IP地址
主機(jī)x.tom.com先向本地域名服務(wù)器dns.tom.com進(jìn)行遞歸查詢(xún)
本地域名服務(wù)器采用迭代查詢(xún). 它先問(wèn)一個(gè)根域名服務(wù)器
根域名服務(wù)器告訴它, 你去問(wèn)頂級(jí)域名服務(wù)器dns.com
本地域名服務(wù)器問(wèn)頂級(jí)域名服務(wù)器dns.com
頂級(jí)域名服務(wù)器告訴它, 你去問(wèn)權(quán)限域名服務(wù)器dns.jerry.com
本地域名服務(wù)器問(wèn)權(quán)限域名服務(wù)器dns.jerry.com
權(quán)限域名服務(wù)器dns.jerry.com告訴它所查詢(xún)的主機(jī)的IP地址
本地域名服務(wù)器把查詢(xún)結(jié)果告訴主機(jī)x.tom.com
PS : 該查詢(xún)使用UDP, 并且為了提高DNS查詢(xún)效率, 每個(gè)域名服務(wù)器都使用高速緩存.
URL
URL的格式 : <協(xié)議>://<主機(jī)>:<端口>/<路徑>, 端口和路徑有時(shí)可省略.
使用HTTP協(xié)議的URL : http://<主機(jī)>:<端口>/<路徑>, HTTP默認(rèn)端口號(hào)是80
HTTP協(xié)議
HTTP是面向事務(wù)的, 即它傳輸?shù)臄?shù)據(jù)是一個(gè)整體, 要么全部收到, 要么全部收不到.
萬(wàn)維網(wǎng)的工作過(guò)程
每一次HTTP請(qǐng)求就需要建立一次TCP連接和釋放TCP連接.
HTTP是無(wú)連接, 無(wú)狀態(tài)的. 每一次請(qǐng)求都是作為一次新請(qǐng)求.
HTTP/1.0 缺點(diǎn) : 無(wú)連接, 每一次請(qǐng)求都要重新建立TCP連接, 所以每一次HTTP請(qǐng)求都要花費(fèi)2倍RTT時(shí)間(一次TCP請(qǐng)求, 一次HTTP請(qǐng)求)
HTTP/1.1 : 使用持續(xù)連接, 即保持TCP連接一段時(shí)間.
HTTP/1.1持續(xù)工作的兩種工作方式 : 非流水線(xiàn)方式和流水線(xiàn)方式
非流水線(xiàn)方式 : 收到一個(gè)請(qǐng)求的響應(yīng)再發(fā)下一個(gè)請(qǐng)求, 效率低, 浪費(fèi)資源
流水線(xiàn)方式 : 能夠同時(shí)發(fā)送多個(gè)請(qǐng)求, 效率高
HTTP的GET和POST
GET 請(qǐng)求通常用于查詢(xún)、獲取數(shù)據(jù)，而 POST 請(qǐng)求則用于發(fā)送數(shù)據(jù)
GET 請(qǐng)求的參數(shù)在URL中, 因此絕不能用GET請(qǐng)求傳輸敏感數(shù)據(jù), 而POST 請(qǐng)求的參數(shù)在請(qǐng)求頭中, 安全性略高于GET請(qǐng)求
ps : POST請(qǐng)求的數(shù)據(jù)也是以明文的形式存放在請(qǐng)求頭中, 因此也不安全
Cookie
萬(wàn)維網(wǎng)使用Cookie來(lái)跟蹤用戶(hù), 表示HTTP服務(wù)器和用戶(hù)之間傳遞的狀態(tài)信息.
Cookie工作原理 :
1. 用戶(hù)瀏覽某網(wǎng)站, 該網(wǎng)站的服務(wù)器為用戶(hù)產(chǎn)生一個(gè)唯一的識(shí)別碼, 并以此為索引在服務(wù)器后端數(shù)據(jù)庫(kù)中產(chǎn)生一個(gè)項(xiàng)目2. 返回給用戶(hù)的HTTP響應(yīng)報(bào)文中添加一條 "Set-cookie", 值為該識(shí)別碼, 如1233. 用戶(hù)的瀏覽器將該cookie保存起來(lái), 在用于繼續(xù)瀏覽該網(wǎng)站時(shí)發(fā)送的每一個(gè)HTTP請(qǐng)求都會(huì)有一行 Cookie: 123
于是, 這個(gè)網(wǎng)站就知道Cookie為123的這個(gè)用戶(hù)做了什么, 為這個(gè)用戶(hù)維護(hù)一個(gè)獨(dú)立的列表(如購(gòu)物車(chē))
當(dāng)然, Cookie是把雙刃劍, 方便的同時(shí)也帶有危險(xiǎn)性, 例如隱私泄露等, 用戶(hù)可以自行決定是否使用Cookie
Session
Cookie是保存在客戶(hù)端上的, 而Session是保存在服務(wù)器中. 當(dāng)服務(wù)器收到用戶(hù)發(fā)出的Cookie時(shí), 會(huì)根據(jù)Cookie中的SessionID來(lái)查找對(duì)應(yīng)的Session, 如沒(méi)有則會(huì)生成一個(gè)新的SessionID返回給用戶(hù)
總而言之, Cookie和Session就是同一樣?xùn)|西存放地方不同而已.
HTTPS
HTTPS協(xié)議在HTTP協(xié)議的基礎(chǔ)上, 在HTTP和TCP中間加入了一層SSL/TLS加密層, 解決了HTTP不安全的問(wèn)題: 冒充, 篡改, 竊聽(tīng)三大風(fēng)險(xiǎn)。
【計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)】相關(guān)文章：
計(jì)算機(jī)網(wǎng)絡(luò)的分類(lèi)知識(shí)01-22
計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)知識(shí)01-20
計(jì)算機(jī)網(wǎng)絡(luò)入門(mén)知識(shí)大全01-26
計(jì)算機(jī)網(wǎng)絡(luò)重點(diǎn)知識(shí)介紹01-20
計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)知識(shí)總結(jié)01-13
計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)知識(shí)介紹01-25
計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)點(diǎn)分析03-10