?

日常的開發(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é)

以上是生活随笔為你收集整理的网络基础协议随笔的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。