OSI 七層模型
- OSI/RM，Open System Interconnection Reference Model ，開放式系統(tǒng)互聯(lián)通信參考模型，簡稱 OSI
- 一種概念模型，由國際標準化組織（ISO）提出
- 一個試圖使各種計算機在世界范圍內(nèi)互連為網(wǎng)絡的標準框架
OSI 將計算機網(wǎng)絡體系結構劃分為七層
- 主機層
- 第七層：應用層（Application Layer）
- 應用層直接和應用程序接口并提供常見的網(wǎng)路應用服務
- 應用層也向第六層表示層發(fā)出請求
- 第六層：表示層（Presentation Layer）
- 把數(shù)據(jù)轉換為能與接收者的系統(tǒng)格式兼容并適合傳輸?shù)母袷?/li>
- 第五層：會話層（Session Layer）
- 負責在數(shù)據(jù)傳輸中設定和維護電腦網(wǎng)絡中兩臺電腦之間的通訊連接
- 第四層：傳輸層（Transport Layer）
- 把傳輸表頭（TH）加至數(shù)據(jù)以形成數(shù)據(jù)包
- 傳輸表頭包含了所使用的協(xié)定等傳送資訊
- 第七層：應用層（Application Layer）
- 媒介層
- 第三層：網(wǎng)絡層（Network Layer）
- 提供路由和尋址功能，并具有一定的擁塞控制和流量控制的能力
- 第二層：數(shù)據(jù)鏈路層（Data Link Layer）
- 在兩個網(wǎng)絡實體之間提供數(shù)據(jù)鏈路連接的建立、維持和釋放管理
- 第一層：物理層（Physical Layer）
- 物理層確保原始的數(shù)據(jù)可在各種物理媒體上傳輸。
- 第三層：網(wǎng)絡層（Network Layer）
常見的
- HTTP 協(xié)議在應用層
- TCP 協(xié)議在傳輸層
- IP 協(xié)議在網(wǎng)絡層
HTTP 的工作原理
- HTTP ，HyperText Transfer Protocol，超文本傳輸協(xié)議
- 當我們在客戶端向服務器發(fā)送一個請求，服務器接收請求，并向客戶端發(fā)送一個響應，客戶端接收并展示，HTTP 協(xié)議在這個過程中規(guī)定了請求和響應的格式以及行為。
- 請求：請求行；請求頭；空行（回車）；消息體；
- 響應：響應行；響應頭；空行（回車）；消息體；
寫個簡單例子：
//請求
GET / HTTP/1.1 //方法 + 路徑 + 協(xié)議/版本號
Host: www.xxx.com //這里是域名，告訴服務器要請求的域名
Accept: text/html //請求的東西，比如這里向服務器要一個html文檔
... //這里都是key: value 格式，告訴服務器需求
//響應
HTTP/1.1 200 OK //對應請求，返回結果
Content-Type: text/html;charset=utf-8 //告訴瀏覽器返回了 html 文檔
<!doctype html><html><h1>響應</h1></html> //返回的 html 文檔內(nèi)容
URI和URL
- URI，Uniform Resourse Identifier，統(tǒng)一資源標識符
- URL，Uniform Resourse Locator，統(tǒng)一資源定位符
- URN，Uniform Resourse Name，統(tǒng)一資源名稱
其中 URL 和 URN 是 URI 的子集，URI 的通常表現(xiàn)形式就是 URL
幾種常見的URL
http(s)://www.xxx.com/xxx/index.htmlftp://ftp.xxx/xx.txtmailto:xxx@email.comtelnet://192.168.1.1:80
HTTP 與服務器交互的方法
最常見的有 GET，POST，從服務器獲取資源，除此之外還有
- HEAD：與GET類似，但不獲取資源，僅獲取資源的信息，是否存在，是否被修改
- PUT：向服務器寫入資源
- TRACE：客戶端向服務器發(fā)送請求的時候，中間可能會經(jīng)過防火墻、代理、網(wǎng)關等一些應用程序，每個中間節(jié)點都可能修改HTTP請求，TRACE方法允許客戶端在最終請求到達服務器的時候，查看這個請求最終變成怎樣了
- DELETE：要求服務器刪除請求的URL
- OPTIONS：請求服務器告知其支持的所有功能
狀態(tài)碼（Status Code）
- 用于表示請求的結果
- 100~199 用于指定客戶端相應的某些動作
- 200~299 用于表示請求成功
- 200 表示請求和響應成功
- 300~399 用于已經(jīng)移動的文件并且常被包含在定位信息中指定新的地址信息
- 301 請求的文檔被移到別處，瀏覽器自動訪問新的URL
- 304 客戶端緩存了文檔，再次請求這個文檔時，如果滿足條件，則使用緩存，并返回 304
- 400~499 用于指出客戶端的錯誤
- 403 資源不可用，服務器理解請求，但拒絕處理
- 404 無法找到指定位置的資源
- 500~599 用于支持服務器的錯誤
- 500 服務器出現(xiàn)問題，不能完成客戶的請求
- 503 服務器由于維護或負載過重未能響應
- 505 服務器不支持請求中指明的 HTTP 版本
瀏覽器緩存控制
瀏覽器在請求已經(jīng)訪問過的URL的時候，會判斷是否使用緩存。
判斷是否使用緩存主要通過判斷緩存是否在有效期，通過兩個字段來判斷
- Expires: GMT時間
- 響應會包含這個信息，過期時間，緩存的時候會將文件和這個信息保存，當瀏覽器再次訪問這個文件的時候，瀏覽器會將當前時間和這個信息時間作比較，如果在過期時間內(nèi)，則直接使用本地緩存的文件，狀態(tài)碼為200 form xxx cache ，如果超過了過期時間，則重新發(fā)送請求
- Cache-Control: max-age=數(shù)值
- 直接設置的過期時間，單位為秒，原理同Expires，由于使用的秒數(shù)，會比Expires準確，所以優(yōu)先級比Expires高，瀏覽器會先判斷Cache-Control
當瀏覽器判斷緩存過期之后，接著進行判斷緩存的文件是否有更新
判斷緩存是否有更新
- Last-Modified 和 If-Modified-Since
- 第一次請求時，服務器響應一個 Last-Modified，表示文件最后修改時間，緩存過期后，瀏覽器發(fā)送請求的時候會將該時間放在 If-Modified-Since 中一起發(fā)給服務器，服務器收到請求后，會將該時間與服務器中該文件的最后修改時間作比較，如果最后修改時間較新，則重新響應整個文件，如果最后修改時間較舊，則響應 HTTP 304，告知瀏覽器使用緩存
- Etag 和If-None-Match:
- 第一次請求時，服務器響應一個 Etag 字段，表示文件的唯一的字符串，當文件被修改時，該字符串回改變，緩存過期后，瀏覽器發(fā)送請求的時候會將該字符串放在 If-None-Match 中一起發(fā)給服務器，服務器收到請求后，會將 If-None-Match 中的字符串與服務器中的文件的 Etag 作比較，如果相同，則響應 HTTP 304，告知瀏覽器使用緩存，如果不同，則重新響應整個文件，并包含新的 Etag 字段。
- Etag 的優(yōu)先級比 Last-Modified 高，因為 Last-Modified 判斷只能精確到秒，而Etag是直接判斷文件是否被修改
