應用層：解決通過應用程序的互動來實作特定網絡應用的問題。
我們在浏覽器的位址中輸入某個網站的域名後，就可以通路該網站的内容，這個就是網際網路WWW應用，其相關的應用層協定為超文本傳送協定HTTP
HTTP基本概念
HTTP 是超文本傳輸協定，也就是HyperText Transfer Protocol。
HTTP的名字「超文本協定傳輸」，它可以拆成三個部分：
- 超文本
- 傳輸
- 協定
1. 「協定」
在生活中，我們也能随處可見「協定」，例如：
- 剛畢業時會簽一個「三方協定」；
- 找房子時會簽一個「租房協定」；
生活中的協定，本質上與計算機中的協定是相同的，協定的特點:
- 「協」字，代表的意思是必須有兩個以上的參與者。例如三方協定裡的參與者有三個：你、公司、學校三個；租房協定裡的參與者有兩個：你和房東。
- 「儀」字，代表的意思是對參與者的一種行為約定和規範。例如三方協定裡規定試用期期限、毀約金等；租房協定裡規定租期期限、每月租金金額、違約如何處理等。
針對 HTTP 協定，我們可以這麼了解。
HTTP 是一個用在計算機世界裡的協定。它使用計算機能夠了解的語言确立了一種計算機之間交流通信的規範（兩個以上的參與者），以及相關的各種控制和錯誤處理方式（行為約定和規範）。
2. 「傳輸」
所謂的「傳輸」，很好了解，就是把一堆東西從 A 點搬到 B 點，或者從 B 點 搬到 A 點。
别輕視了這個簡單的動作，它至少包含兩項重要的資訊。
HTTP 協定是一個雙向協定。
我們在上網沖浪時，浏覽器是請求方 A ，百度網站就是應答方 B。雙方約定用 HTTP 協定來通信，于是浏覽器把請求資料發送給網站，網站再把一些資料傳回給浏覽器，最後由浏覽器渲染在螢幕，就可以看到圖檔、視訊了。
資料雖然是在 A 和 B 之間傳輸，但允許中間有中轉或接力。
就好像第一排的同學想穿遞紙條給最後一排的同學，那麼傳遞的過程中就需要經過好多個同學（中間人），這樣的傳輸方式就從「A < --- > B」，變成了「A <-> N <-> M <-> B」。
而在 HTTP 裡，需要中間人遵從 HTTP 協定，隻要不打擾基本的資料傳輸，就可以添加任意額外的東西。
針對傳輸，我們可以進一步了解了 HTTP。
HTTP 是一個在計算機世界裡專門用來在兩點之間傳輸資料的約定和規範。
3. 「超文本」
HTTP 傳輸的内容是「超文本」。
我們先來了解「文本」，在網際網路早期的時候隻是簡單的字元文字，但現在「文本」。的涵義已經可以擴充為圖檔、視訊、壓縮包等，在 HTTP 眼裡這些都算做「文本」。
再來了解「超文本」，它就是超越了普通文本的文本，它是文字、圖檔、視訊等的混合體最關鍵有超連結，能從一個超文本跳轉到另外一個超文本。
HTML 就是最常見的超文本了，它本身隻是純文字檔案，但内部用很多标簽定義了圖檔、視訊等的連結，在經過浏覽器的解釋，呈現給我們的就是一個文字、有畫面的網頁了。
OK，經過了對 HTTP 裡這三個名詞的詳細解釋，就可以給出比「超文本傳輸協定」這七個字更準确更有技術含量的答案：
HTTP 是一個在計算機世界裡專門在「兩點」之間「傳輸」文字、圖檔、音頻、視訊等「超文本」資料的「約定和規範」。
HTTP 請求響應過程
讓我們通過⼀個例⼦來探讨⼀下 HTTP 的請求響應過程，我們假設通路的 URL 位址為
http://www.someSchool.edu/someDepartment/home.index ，當我們輸⼊⽹址并點選回⻋時，浏覽器内部會
進⾏如下操作
- DNS伺服器會⾸先進⾏域名的映射，找到通路 www.someSchool.edu 所在的位址，然後HTTP 用戶端程序在80 端⼝發起⼀個到伺服器 www.someSchool.edu 的 TCP 連接配接（80 端⼝是 HTTP 的預設端⼝）。在客戶和伺服器程序中都會有⼀個 套接字 與其相連。
- HTTP 用戶端通過它的套接字向伺服器發送⼀個 HTTP 請求報⽂。該報⽂中包含了路徑someDepartment/home.index 的資源，我們後⾯會詳細讨論 HTTP 請求報⽂。
- HTTP 伺服器通過它的套接字接收該報⽂，進⾏請求的解析⼯作，并從其 存儲器(RAM 或磁盤) 中檢索出對象www.someSchool.edu/someDepartment/home.index，然後把檢索出來的對象進⾏封裝，封裝到 HTTP響應報⽂中，并通過套接字向客戶進⾏發送。
- HTTP 伺服器随即通知 TCP 斷開 TCP 連接配接，實際上是需要等到客戶接受完響應報⽂後才會斷開 TCP 連接配接。
- HTTP 用戶端接受完響應報⽂後，TCP 連接配接會關閉。用戶端會從報⽂中提取響應⽂件，并檢查該 HTML ⽂件，然後循環檢查報⽂中其他内部對象。
- 檢查完成後，HTTP 用戶端會把對應的資源通過顯示器呈現給⽤戶。
⾄此，鍵⼊⽹址再按下回⻋的全過程就結束了。上述過程描述的是⼀種簡單的 請求-響應 全過程，真實的請求-響應情況可能要⽐上⾯描述的過程複雜很多。
HTTP 請求特征
HTTP 最凸出的優點是「簡單、靈活和易于擴充、應⽤⼴泛和跨平台」。
1. 簡單
HTTP 基本的報⽂格式就是 header + body ，頭部資訊也是 key-value 簡單⽂本的形式，易于了解，降低了學習和使⽤的⻔檻。
2. 靈活和易于擴充
HTTP協定⾥的各類請求⽅法、URI/URL、狀态碼、頭字段等每個組成要求都沒有被固定死，都允許開發⼈員⾃定義和擴充。
同時 HTTP 由于是⼯作在應⽤層（ OSI 第七層），則它下層可以随意變化。
HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚⾄把 TCP 層換成了基于 UDP 的QUIC。
3. 應⽤⼴泛和跨平台
互聯⽹發展⾄今，HTTP 的應⽤範圍⾮常的⼴泛，從桌上型電腦的浏覽器到⼿機上的各種 APP，從看新聞、刷貼吧到購物、理财、吃雞，HTTP 的應⽤⽚地開花，同時天然具有跨平台的優越性。
持久性連接配接和⾮持久性連接配接
我們上⾯描述的 HTTP 請求響應過程就是⼀種 ⾮持久連接配接 ，因為每次 TCP 在傳遞完報⽂後，都會關閉 TCP 連接配接，每個 TCP 連接配接隻傳輸⼀個請求報⽂和響應報⽂。
⾮持久性連接配接有⼀些 缺點 。
第⼀，必須為每個請求的對象建⽴和維護⼀個全新的連接配接。
第⼆，對于每個這樣的連接配接來說，在用戶端和伺服器中都要配置設定 TCP 的緩沖區和保持 TCP 變量，這給 Web伺服器帶來了嚴重的負擔。因為⼀台 Web 伺服器可能要同時服務于數百甚⾄上千個客戶請求。
早期 HTTP/1.0 性能上的⼀個很⼤的問題，那就是每發起⼀個請求，都要建立⼀次 TCP 連接配接（三次握⼿），⽽且是串⾏請求，做了⽆謂的 TCP 連接配接建⽴和斷開，增加了通信開銷。
為了解決上述 TCP 連接配接問題，HTTP/1.1 提出了⻓連接配接的通信⽅式，也叫持久連接配接。這種⽅式的好處在于減少了TCP 連接配接的重複建⽴和斷開所造成的額外開銷，減輕了伺服器端的負載。
持久連接配接的特點是，隻要任意⼀端沒有明确提出斷開連接配接，則保持 TCP 連接配接狀态。
HTTP 報⽂格式
我們上⾯描述了⼀下 HTTP 的請求響應過程，相信你對 HTTP 有了更深的認識，下⾯我們就來⼀起認識⼀下 HTTP的報⽂格式是怎樣的。
HTTP 協定主要由三⼤部分組成：
起始⾏（start line） ：描述請求或響應的基本資訊；
頭部字段（header） ：使⽤ key-value 形式更詳細地說明報⽂；
消息正⽂（entity） ：實際傳輸的資料，它不⼀定是純⽂本，可以是圖⽚、視訊等⼆進制資料。
其中起始⾏和頭部字段并成為 請求頭 或者 響應頭 ，統稱為 Header ；消息正⽂也叫做實體，稱為 body 。
HTTP 協定規定每次發送的報⽂必須要有 Header，但是可以沒有 body，也就是說頭資訊是必須的，實體資訊可以沒有。⽽且在 header 和 body 之間必須要有⼀個空⾏（CRLF）。
這幅圖需要注意⼀下，如果使⽤ GET ⽅法，是沒有實體體的，如果你使⽤的是 POST ⽅法，才會有實體體。當⽤戶送出表單時，HTTP 用戶端通常使⽤ POST ⽅法；與此相反，HTML 表單的擷取通常使⽤ GET ⽅法。HEAD⽅法類似于 GET ⽅法，隻不過 HEAD ⽅法不會傳回對象。
下⾯我們來看⼀下 HTTP 響應報⽂
可以看到，請求報⽂和響應報⽂隻有請求頭是不同的，其他資訊均⼀緻。
GET /some/page.html HTTP/1.1 HTTP/1.1 200 OK