网络基础协议随笔
?
日常的開發(fā)中,大家關(guān)注的重點基本都在前端的展現(xiàn)、交互和性能上,而這些都算是瀏覽器上層的一些表現(xiàn)。而對于底層的一些協(xié)議關(guān)注的相對較少,這里就主要介紹一下這些基礎(chǔ)協(xié)議。?
基礎(chǔ)協(xié)議有很多,這里主要介紹一下最常見的http、https、tcp/udp協(xié)議。
基本概念
協(xié)議是多方之間相互商定的一種溝通或統(tǒng)一行動時的一種規(guī)則。互聯(lián)網(wǎng)協(xié)議也是一樣,規(guī)定了不同終端之間通信時數(shù)據(jù)傳輸?shù)姆绞健⒏袷降葍?nèi)容。在七層網(wǎng)絡(luò)模型中存在著各種不同的協(xié)議,其中?
http (Hypertext Transfer Protocol)超文本傳輸協(xié)議,是一種處于應(yīng)用層的,服務(wù)器與瀏覽器之間進(jìn)行文本傳輸?shù)臒o狀態(tài)協(xié)議。?
https (Hypertext Transfer Protocol over Secure Socket Layer)基于SSL的HTTP協(xié)議,可以理解為加密型的http協(xié)議,同時https一般都不在使用http的默認(rèn)80端口,改用433端口。?
TCP (Transmission Control Protocol)傳輸控制協(xié)議,一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。?
UDP (User Datagram Protocol)用戶數(shù)據(jù)協(xié)議,與TCP類似,也是一種傳輸層協(xié)議,不同的是,它是一種面向無連接的、不可靠的協(xié)議。
一次HTTP請求的過程中都發(fā)生了什么?
這是一道經(jīng)典的前端面試題,剛畢業(yè)找工作的過程中被問了N遍。簡而言之,從你輸入網(wǎng)址到你看到頁面,大致經(jīng)歷了以下過程?
1、域名解析—–有求于人,總要先找到人家吧。?
2、建立連接—–找到地址了,快快聯(lián)絡(luò),相互認(rèn)識總是要的。?
3、發(fā)送請求—–提出請求,等待回復(fù)。?
4、接收響應(yīng)—–得到回復(fù),準(zhǔn)備開工。?
5、渲染頁面—–開工蓋房,蓋完收工。?
下面先從網(wǎng)址說起
網(wǎng)址?URL?
我們現(xiàn)在所說的網(wǎng)址,也稱之為URL,全稱Uniform Resource Locator。用于表明某一資源在網(wǎng)絡(luò)上的地址。基本格式如下?
schema://host[:port#]/path/…/[?search][#hash]?
scheme 指定低層使用的協(xié)議(例如:http, https, ftp)?
host HTTP服務(wù)器的IP地址或者域名?
port# HTTP服務(wù)器的默認(rèn)端口是80,這種情況下端口號可以省略。?
path 訪問資源的路徑?
search 發(fā)送給http服務(wù)器的數(shù)據(jù)?
hash 哈希?
其中hash是不會傳給服務(wù)器的,并且hash后面的部分在url解析的時候也會被當(dāng)作hash,因此hash必須放在最后,避免其他信息被影響。
域名解析,找到真正的門牌號
通常情況下我們在瀏覽器窗口輸入的網(wǎng)址都不是目標(biāo)的原始地址,而是一種為了方便記憶的語義化之后的地址。而在網(wǎng)絡(luò)中一個終端的實際地址其實是IP地址。為了實現(xiàn)與服務(wù)器的通信,首要的就是找到服務(wù)器的IP地址,而由網(wǎng)址到IP地址的解析過程即為域名解析。?
域名解析大致分為幾個步驟?
1、瀏覽器緩存解析,在chrome中可以使用chrome://net-internals/#dns命令查詢?yōu)g覽器緩存。?
2、本機緩存解析 ,windows下可以在dos窗口使用ipconfig /displaydns命令查詢本機緩存。?
3、本機host,BIOS緩存解析?
4、向DNS服務(wù)器發(fā)送請求解析,這種解析請求是面向無連接的,客戶端只是發(fā)送請求,沒收到回復(fù)就繼續(xù)請求。本身不存在一個確認(rèn)雙方連接狀態(tài)的過程,屬于一種不安全、穩(wěn)定的通信,而這就是UDP協(xié)議的一個表現(xiàn)。?
每一步中如果解析出結(jié)果就停止向下解析,返回IP地址。這也就是我們在平時的工作中會去配置host文件,以達(dá)到對不同環(huán)境映射的原理。
三次握手?在么?在?有個請求
在完成了域名解析之后,瀏覽器確定了服務(wù)器地址。那么就要開始通信了。為了確保準(zhǔn)確的連接到服務(wù)器,確保通信成功,這個時候通過傳輸層tcp協(xié)議開始三次握手。?
1)瀏覽器手心發(fā)送一個連接請求,同時進(jìn)入請求已發(fā)送狀態(tài),等待服務(wù)器的回復(fù)?2)服務(wù)器接收到請求后,則向瀏覽器返回一個確認(rèn)信息,并進(jìn)入請求已接收狀態(tài),等待瀏覽器再次確認(rèn)。?
3)瀏覽器端再次發(fā)送一個連接確認(rèn)信號,并進(jìn)入連接準(zhǔn)備狀態(tài),服務(wù)端確認(rèn)后也進(jìn)入準(zhǔn)備狀態(tài),雙方即可開始通信。
與http不同的是,https會在三次握手的過程中將加密協(xié)議等信息一并傳輸,最終在建立連接之后瀏覽器與服務(wù)器之間的通信數(shù)據(jù),就可以通過加密來保證通信的安全性。
請求響應(yīng)數(shù)據(jù)?給我這個,好 拿去
建立連接后,雙方開始http協(xié)議通信。而在這個通信過程中,雙方都對數(shù)據(jù)添加了一些額外的信息來表明雙方需要的什么樣的格式、那種緩存策略、安全機制等等,這些信息就是頭部信息/首部信息。?
首部信息大致可以分成三個部分,?
1)通用部分?
2)請求頭部分?
3)響應(yīng)頭部分
通用部分?
請求與響應(yīng)都遵守的通用部分主要包括一些基本的連接信息和緩存信息等等,如
| Connection | 允許客戶端和服務(wù)器指定與請求/響應(yīng)連接有關(guān)的選項,http1.1版本默認(rèn)keep-alive |
| Date | 提供日期和時間標(biāo)志,說明報文是什么時間創(chuàng)建的 |
| MIME-Version | 給出了發(fā)送端使用的MIME版本 |
| Via | 顯示了報文經(jīng)過的中間節(jié)點(代理、網(wǎng)關(guān)) |
| Cache-Control | 用于隨報文傳送緩存指示,no-cache不緩存 |
| Pragma | 另一種隨報文傳送指示的方式,但并不專用于緩存,no-cache不緩存 |
請求頭信息?
請求頭信息主要用于向服務(wù)器說明是從哪里發(fā)出的請求、請求什么格式的數(shù)據(jù)、請求數(shù)據(jù)時有什么偏好、中間經(jīng)過的一些代理以及瀏覽器自身的一些屬性等等。
| 基礎(chǔ)信息 | 基礎(chǔ)信息 |
| Host | 給出了接收請求的服務(wù)器的主機名和端口號 |
| Referer | 提供了包含當(dāng)前請求URI的文檔的URL |
| User-Agent | 將發(fā)起請求的應(yīng)用程序名稱告知服務(wù)器(User-Agent)用戶代理 |
| Accept | 告訴服務(wù)器能夠發(fā)送哪些媒體類型,此外還有Accept-Charset、Accept-Encoding、Accept-Language |
| 條件信息 | 條件信息 |
| Expect | 允許客戶端列出某請求所要求的服務(wù)器行為 |
| If-Match | 如果實體標(biāo)記與文檔當(dāng)前的實體標(biāo)記相匹配,就或者這份文檔 |
| If-Modified-Since | 除非在某個指定的日期之后資源被修改過,否則就限制這個請求 |
| If-Range | 允許對文檔的某個范圍進(jìn)行條件請求 |
| If-Unmodified-Since | 除非在某個指定的日期之后資源沒有被修改過,否則就限制這個請求 |
| Range | 如果服務(wù)器支持范圍請求,就請求資源的指定范圍 |
| 安全認(rèn)證信息 | 安全認(rèn)證信息 |
| Authorization | 包含了客戶端提供給服務(wù)器,以便對其自身進(jìn)行認(rèn)證的數(shù)據(jù) |
| Cookie | 客戶端用它想服務(wù)器傳送一個令牌-他并不是真正的安全首部,但卻是隱含了安全功能 |
| 代理信息 | 代理信息 |
| Proxy-Authorization | 與Authorization首部相同,但這個首部是在與代理進(jìn)行認(rèn)證時使用的 |
| Proxy-Connection | 與Connection首部相同,但這個首部是在于代理建立連接時使用的 |
響應(yīng)頭信息?
響應(yīng)頭則主要是向瀏覽器說明服務(wù)器是從哪里響應(yīng)、響應(yīng)的內(nèi)容有多大、遵循什么規(guī)范以及一些代理、安全認(rèn)證信息等等,以便于瀏覽器更好地更快更安全的處理數(shù)據(jù)。
| 基礎(chǔ)信息 | 基礎(chǔ)信息 |
| Age | (從最初創(chuàng)建開始)響應(yīng)持續(xù)時間 |
| Public | 服務(wù)器為其資源支持的請求方法列表 |
| Server | 服務(wù)器應(yīng)用程序軟件的名稱和版本 |
| Accept-Ranges | 對此資源來說,服務(wù)器可接受的范圍類型 |
| Vary | 服務(wù)器查看的其他首部的列表,可能會使響應(yīng)發(fā)生變化;也就是說,這是一個首部列表,服務(wù)器會根據(jù)這些首部的內(nèi)容挑選出最合適的資源版本發(fā)送給客戶端。 |
| 安全認(rèn)證信息 | 安全認(rèn)證信息 |
| Proxy-Authenticate | 來自代理的對客戶端的質(zhì)詢列表 |
| Set-Cookie | 不是真正的安全首部,但隱含有安全功能;可以在客戶端設(shè)置一個令牌,以便服務(wù)器對客戶端進(jìn)行標(biāo)識。此外還有Set-Cookie2 |
| 緩存信息 | 緩存信息 |
| ETag | 與此實體有關(guān)的實體標(biāo)記 |
| Expires | 實體不在有效,要從原始的源端再次獲取此實體的日期和時間 |
| Last-Modified | 這個實體最后一次被修改的日期和時間 |
| 響應(yīng)實體信息 | 響應(yīng)實體信息 |
| Content-Type | 這個主體的對象模型 |
| Content-MD5 | 主體的MD5校驗,此外還有Content-Base,Content-Encoding,Content-Language,Content-Length,Content-Location,Content-Range |
除此之外http協(xié)議中還定義了一些額外的頭部信息輔助通信,比如用于處理跨域請求的
| 跨域信息 | 跨域信息 |
| Access-Control-Allow-Origin | 允許的訪問域,一般設(shè)為* |
| Access-Control-Allow-Methods | 允許的請求方式列表,如POST, GET, OPTIONS,DELETE,PUT |
數(shù)據(jù)加載、渲染
這個在這部分不做細(xì)講。
說到這里,一次http請求的大致過程就說完了,其中也包括了http、tcp/udp協(xié)議的一些信息,并不詳細(xì),主要供給大家做一個簡略的介紹。下面在簡要介紹一些我們工作中經(jīng)常用到的東西。
代理
代理在我們的工作用應(yīng)用很多,比如翻墻用的VPN代理,映射文件的nginx,CDN服務(wù)器、代理軟件Charles、fidder等等,嚴(yán)格的說host本身也算得上是一種代理。而代理又分為正向代理和反向代理。
正向代理介于客戶端與服務(wù)器之間,此時客戶端一般不能直接訪問服務(wù)器,而代理服務(wù)器可以。這種情況下,中間代理就成為了一個請求與響應(yīng)的中轉(zhuǎn)站,轉(zhuǎn)發(fā)我們的請求,并把服務(wù)器的響應(yīng)轉(zhuǎn)回給我們。也就是我們平常使用vpn翻墻時的狀態(tài)。
而反向代理呢,一般作用在服務(wù)端,把用戶的請求映射到不同的實際資源地址上去。就像我們在平時使用nginx一樣,把一系列的請求映射到本地。這一點和Charles這些代理軟件,原理上都是一樣的。
再比如CDN,內(nèi)容分發(fā)網(wǎng)絡(luò),本身也是一種反向代理。CDN首先會在DNS解析階段拿到優(yōu)先解析的特權(quán),并把DNS解析的請求發(fā)送給CDN服務(wù)器。服務(wù)器會根據(jù)用戶的IP,就近的選擇一臺緩存服務(wù)器,并告知用戶去和這個服務(wù)器通信。這樣,用戶在訪問時就可以把請求定向到距離用戶最近的網(wǎng)絡(luò)節(jié)點上,降低請求節(jié)點距離,提高請求效率。這也就是CDN要相對比較快的原因啦。
轉(zhuǎn)載于:https://www.cnblogs.com/heioray/p/7169775.html
總結(jié)
- 上一篇: Entry
- 下一篇: Drools的HelloWord例子