?

日常的開發中，大家關注的重點基本都在前端的展現、交互和性能上，而這些都算是瀏覽器上層的一些表現。而對于底層的一些協議關注的相對較少，這里就主要介紹一下這些基礎協議。?

基礎協議有很多，這里主要介紹一下最常見的http、https、tcp/udp協議。

---

基本概念

協議是多方之間相互商定的一種溝通或統一行動時的一種規則。互聯網協議也是一樣，規定了不同終端之間通信時數據傳輸的方式、格式等內容。在七層網絡模型中存在著各種不同的協議，其中?
http (Hypertext Transfer Protocol)超文本傳輸協議，是一種處于應用層的，服務器與瀏覽器之間進行文本傳輸的無狀態協議。?
https (Hypertext Transfer Protocol over Secure Socket Layer)基于SSL的HTTP協議，可以理解為加密型的http協議，同時https一般都不在使用http的默認80端口，改用433端口。?
TCP (Transmission Control Protocol)傳輸控制協議，一種面向連接的、可靠的、基于字節流的傳輸層通信協議。?
UDP (User Datagram Protocol)用戶數據協議，與TCP類似，也是一種傳輸層協議，不同的是，它是一種面向無連接的、不可靠的協議。

一次HTTP請求的過程中都發生了什么？

這是一道經典的前端面試題，剛畢業找工作的過程中被問了N遍。簡而言之，從你輸入網址到你看到頁面，大致經歷了以下過程?
1、域名解析—–有求于人，總要先找到人家吧。?
2、建立連接—–找到地址了，快快聯絡，相互認識總是要的。?
3、發送請求—–提出請求，等待回復。?
4、接收響應—–得到回復，準備開工。?
5、渲染頁面—–開工蓋房，蓋完收工。?
下面先從網址說起

網址？URL？

我們現在所說的網址，也稱之為URL，全稱Uniform Resource Locator。用于表明某一資源在網絡上的地址。基本格式如下?
schema://host[:port#]/path/…/[?search][#hash]?
scheme 指定低層使用的協議(例如：http, https, ftp)?
host HTTP服務器的IP地址或者域名?
port# HTTP服務器的默認端口是80，這種情況下端口號可以省略。?
path 訪問資源的路徑?
search 發送給http服務器的數據?
hash 哈希?
其中hash是不會傳給服務器的，并且hash后面的部分在url解析的時候也會被當作hash，因此hash必須放在最后，避免其他信息被影響。

域名解析，找到真正的門牌號

通常情況下我們在瀏覽器窗口輸入的網址都不是目標的原始地址，而是一種為了方便記憶的語義化之后的地址。而在網絡中一個終端的實際地址其實是IP地址。為了實現與服務器的通信，首要的就是找到服務器的IP地址，而由網址到IP地址的解析過程即為域名解析。?
域名解析大致分為幾個步驟?
1、瀏覽器緩存解析，在chrome中可以使用chrome://net-internals/#dns命令查詢瀏覽器緩存。?
2、本機緩存解析 ，windows下可以在dos窗口使用ipconfig /displaydns命令查詢本機緩存。?
3、本機host，BIOS緩存解析?
4、向DNS服務器發送請求解析，這種解析請求是面向無連接的，客戶端只是發送請求，沒收到回復就繼續請求。本身不存在一個確認雙方連接狀態的過程，屬于一種不安全、穩定的通信，而這就是UDP協議的一個表現。?
每一步中如果解析出結果就停止向下解析，返回IP地址。這也就是我們在平時的工作中會去配置host文件，以達到對不同環境映射的原理。

三次握手？在么？在？有個請求

在完成了域名解析之后，瀏覽器確定了服務器地址。那么就要開始通信了。為了確保準確的連接到服務器，確保通信成功，這個時候通過傳輸層tcp協議開始三次握手。?

1）瀏覽器手心發送一個連接請求，同時進入請求已發送狀態，等待服務器的回復?2）服務器接收到請求后，則向瀏覽器返回一個確認信息，并進入請求已接收狀態，等待瀏覽器再次確認。?

3）瀏覽器端再次發送一個連接確認信號，并進入連接準備狀態，服務端確認后也進入準備狀態，雙方即可開始通信。

與http不同的是，https會在三次握手的過程中將加密協議等信息一并傳輸，最終在建立連接之后瀏覽器與服務器之間的通信數據，就可以通過加密來保證通信的安全性。

請求響應數據？給我這個，好 拿去

建立連接后，雙方開始http協議通信。而在這個通信過程中，雙方都對數據添加了一些額外的信息來表明雙方需要的什么樣的格式、那種緩存策略、安全機制等等，這些信息就是頭部信息/首部信息。?
首部信息大致可以分成三個部分，?
1）通用部分?
2）請求頭部分?
3）響應頭部分

通用部分?
請求與響應都遵守的通用部分主要包括一些基本的連接信息和緩存信息等等，如

首部描述

Connection	允許客戶端和服務器指定與請求/響應連接有關的選項，http1.1版本默認keep-alive
Date	提供日期和時間標志，說明報文是什么時間創建的
MIME-Version	給出了發送端使用的MIME版本
Via	顯示了報文經過的中間節點(代理、網關)
Cache-Control	用于隨報文傳送緩存指示，no-cache不緩存
Pragma	另一種隨報文傳送指示的方式，但并不專用于緩存，no-cache不緩存

請求頭信息?
請求頭信息主要用于向服務器說明是從哪里發出的請求、請求什么格式的數據、請求數據時有什么偏好、中間經過的一些代理以及瀏覽器自身的一些屬性等等。

首部描述

基礎信息	基礎信息
Host	給出了接收請求的服務器的主機名和端口號
Referer	提供了包含當前請求URI的文檔的URL
User-Agent	將發起請求的應用程序名稱告知服務器(User-Agent)用戶代理
Accept	告訴服務器能夠發送哪些媒體類型，此外還有Accept-Charset、Accept-Encoding、Accept-Language
條件信息	條件信息
Expect	允許客戶端列出某請求所要求的服務器行為
If-Match	如果實體標記與文檔當前的實體標記相匹配，就或者這份文檔
If-Modified-Since	除非在某個指定的日期之后資源被修改過，否則就限制這個請求
If-Range	允許對文檔的某個范圍進行條件請求
If-Unmodified-Since	除非在某個指定的日期之后資源沒有被修改過，否則就限制這個請求
Range	如果服務器支持范圍請求，就請求資源的指定范圍
安全認證信息	安全認證信息
Authorization	包含了客戶端提供給服務器，以便對其自身進行認證的數據
Cookie	客戶端用它想服務器傳送一個令牌-他并不是真正的安全首部，但卻是隱含了安全功能
代理信息	代理信息
Proxy-Authorization	與Authorization首部相同，但這個首部是在與代理進行認證時使用的
Proxy-Connection	與Connection首部相同，但這個首部是在于代理建立連接時使用的

響應頭信息?
響應頭則主要是向瀏覽器說明服務器是從哪里響應、響應的內容有多大、遵循什么規范以及一些代理、安全認證信息等等，以便于瀏覽器更好地更快更安全的處理數據。

首部描述

基礎信息	基礎信息
Age	(從最初創建開始)響應持續時間
Public	服務器為其資源支持的請求方法列表
Server	服務器應用程序軟件的名稱和版本
Accept-Ranges	對此資源來說，服務器可接受的范圍類型
Vary	服務器查看的其他首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最合適的資源版本發送給客戶端。
安全認證信息	安全認證信息
Proxy-Authenticate	來自代理的對客戶端的質詢列表
Set-Cookie	不是真正的安全首部，但隱含有安全功能；可以在客戶端設置一個令牌，以便服務器對客戶端進行標識。此外還有Set-Cookie2
緩存信息	緩存信息
ETag	與此實體有關的實體標記
Expires	實體不在有效，要從原始的源端再次獲取此實體的日期和時間
Last-Modified	這個實體最后一次被修改的日期和時間
響應實體信息	響應實體信息
Content-Type	這個主體的對象模型
Content-MD5	主體的MD5校驗，此外還有Content-Base,Content-Encoding,Content-Language,Content-Length,Content-Location,Content-Range

除此之外http協議中還定義了一些額外的頭部信息輔助通信，比如用于處理跨域請求的

首部描述

跨域信息	跨域信息
Access-Control-Allow-Origin	允許的訪問域，一般設為*
Access-Control-Allow-Methods	允許的請求方式列表，如POST, GET, OPTIONS,DELETE,PUT

數據加載、渲染

這個在這部分不做細講。

說到這里，一次http請求的大致過程就說完了，其中也包括了http、tcp/udp協議的一些信息，并不詳細，主要供給大家做一個簡略的介紹。下面在簡要介紹一些我們工作中經常用到的東西。

代理

代理在我們的工作用應用很多，比如翻墻用的VPN代理，映射文件的nginx，CDN服務器、代理軟件Charles、fidder等等，嚴格的說host本身也算得上是一種代理。而代理又分為正向代理和反向代理。

正向代理介于客戶端與服務器之間，此時客戶端一般不能直接訪問服務器，而代理服務器可以。這種情況下，中間代理就成為了一個請求與響應的中轉站，轉發我們的請求，并把服務器的響應轉回給我們。也就是我們平常使用vpn翻墻時的狀態。

而反向代理呢，一般作用在服務端，把用戶的請求映射到不同的實際資源地址上去。就像我們在平時使用nginx一樣，把一系列的請求映射到本地。這一點和Charles這些代理軟件，原理上都是一樣的。

再比如CDN，內容分發網絡，本身也是一種反向代理。CDN首先會在DNS解析階段拿到優先解析的特權，并把DNS解析的請求發送給CDN服務器。服務器會根據用戶的IP，就近的選擇一臺緩存服務器，并告知用戶去和這個服務器通信。這樣，用戶在訪問時就可以把請求定向到距離用戶最近的網絡節點上，降低請求節點距離，提高請求效率。這也就是CDN要相對比較快的原因啦。

轉載于:https://www.cnblogs.com/heioray/p/7169775.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。