作為一名程序員, 不可能不與網(wǎng)絡(luò)打交道. 現(xiàn)在我們的手機, 電腦, 不夸張地說, 離開了網(wǎng)絡(luò)就是一塊’廢鐵’, 它們的作用將大打折扣.. 本文的作用呢, 主要是針對不是非網(wǎng)絡(luò)專業(yè)開發(fā)的人員準備的, 以’最短的時間, 了解計網(wǎng)最多的知識’為前提起筆.
先來了解下各種我們知道, 但是不太了解的專業(yè)名詞的意思
因特網(wǎng)
因特網(wǎng)
因特網(wǎ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標準, 任何兩個系統(tǒng)都能進行通信. OSI是七層協(xié)議體系結(jié)構(gòu), 而TCP/IP是一個四層協(xié)議體系結(jié)構(gòu), 于是我們采取折中的方法, 學習計算機網(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)換為光信號或者電信號, 所以這一層負責將這些比特流(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地址
類型字段 : 標志上一層使用的是什么協(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地址 = {, }
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地址 = {, , }
例如某單位擁有一個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ò)前綴, 無分類域間路由選擇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é). 當首部長度不是4字節(jié)的整數(shù)倍時, 需要使用最后的填充字段加以填充.
服務(wù)類型 : 一般無用
總長度 : 指首部和數(shù)據(jù)之和的長度. 最大為216-1 = 65535字節(jié). 但是由于數(shù)據(jù)鏈路層規(guī)定每一幀的數(shù)據(jù)長度都有最大長度MTU, 以太網(wǎng)規(guī)定MTU為1500字節(jié), 所以超出范圍的數(shù)據(jù)報就必須進行分片處理
標識 : 每產(chǎn)生一個IP數(shù)據(jù)報, 計數(shù)器就+1, 并將此值賦值給標識字段. 再以后需要分片的數(shù)據(jù)報中, 標識相同說明是同一個數(shù)據(jù)報
標志 : 占3位, 最低位記為MF(More Fragment). MF = 1說明還有分片; MF = 0說明這已經(jīng)是最后一個分片. 中間一位記為DF(Don’t Fragment), 意思是不能分片. 只有當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ā)給默認路由. 當一個網(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有一個部門在廣州和另一個在上海, 而他們在當?shù)囟加凶约旱膶Ｓ镁W(wǎng). 那么怎么將這兩個專用網(wǎng)連接起來呢?
租用電信的通信線路為本機構(gòu)專用, 但是太貴了
利用公用的因特網(wǎ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ù)傳輸都是不可靠的, 盡最大能力交付的. 什么意思的? 就是它們不負責提交給你的就是正確的數(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連接 ::= = {(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, 則接收方收到報文段之后不再等到整個緩存滿而是直接向上交付
復位RST : 當RST = 1, 說明TCP連接有嚴重錯誤, 必須釋放連接再重連
同步SYN : 在連接建立時用來同步序號. 當SYN = 1, ACK = 0時表明這是一個連接請求報文段, 對方若同意建立連接, 則在響應(yīng)的報文段中置SYN = 1, ACK = 1
終止FIN : 當FIN = 1, 表明此報文段的發(fā)送方數(shù)據(jù)已發(fā)送完畢, 并要求釋放連接
窗口 : 告訴對方 : 從本報文段首部中的確認號算起, 接收方目前允許對方發(fā)送的數(shù)據(jù)量. 這是作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)
檢驗和 : 同UDP, 檢驗首部和數(shù)據(jù)部分
緊急指針 : 當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
:
當cwnd
當cwnd > ssthresh, 使用擁塞避免算法
當cwnd = ssthresh, 隨意
擁塞控制
只要判斷網(wǎng)絡(luò)出現(xiàn)擁塞, 把ssthresh設(shè)為當前發(fā)送擁塞窗口的一半(不能小于2), 并把cwnd設(shè)為1, 重新執(zhí)行慢開始算法.
除了慢開始和擁塞避免算法外, 還有一組快重傳和快恢復算法 :
快重傳
: 接收方及時發(fā)送確認, 而發(fā)送方只要一連收到三個重復確認, 馬上重傳
快恢復
: 當發(fā)送方一連收到三個重復確認時, ssthresh減半, cwnd設(shè)為ssthresh.
TCP三次握手
TCP三次握手建立連接和四次揮手斷開連接是面試愛問的知識點.
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回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發(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ā)送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。
更加接地氣的解釋 :
第一次揮手 : A告訴B, 我沒數(shù)據(jù)發(fā)了, 準備關(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)
域名服務(wù)器分類
根域名服務(wù)器 : 最高層次的域名服務(wù)器
頂級域名服務(wù)器 : 如其名
權(quán)限域名服務(wù)器 : 負責一個區(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知道為止
本地域名服務(wù)器采用迭代查詢. 它先問一個根域名服務(wù)器
根域名服務(wù)器告訴它, 你去問頂級域名服務(wù)器dns.com
本地域名服務(wù)器問頂級域名服務(wù)器dns.com
PS : 該查詢使用UDP, 并且為了提高DNS查詢效率, 每個域名服務(wù)器都使用高速緩存.
URL
URL的格式 :
://:/
, 端口和路徑有時可省略.
使用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的這個用戶做了什么, 為這個用戶維護一個獨立的列表(如購物車)
當然, Cookie是把雙刃劍, 方便的同時也帶有危險性, 例如隱私泄露等, 用戶可以自行決定是否使用Cookie
Session
Cookie是保存在客戶端上的, 而Session是保存在服務(wù)器中. 當服務(wù)器收到用戶發(fā)出的Cookie時, 會根據(jù)Cookie中的SessionID來查找對應(yīng)的Session, 如沒有則會生成一個新的SessionID返回給用戶
總而言之, Cookie和Session就是同一樣東西存放地方不同而已.
HTTPS
HTTPS協(xié)議
HTTPS協(xié)議在HTTP協(xié)議的基礎(chǔ)上, 在HTTP和TCP中間加入了一層SSL/TLS加密層, 解決了HTTP不安全的問題: 冒充, 篡改, 竊聽三大風險.
聯(lián)系客服
