http超文本傳輸協(xié)議（p是協(xié)議protocol）（學(xué)習(xí)http的核心原因：1.前后端交互流程 2.保障數(shù)據(jù)傳輸安全 3.優(yōu)化頁(yè)面加載速度）（雙方之間，客戶(hù)端和服務(wù)器之間）
http傳輸?shù)氖俏淖郑瑘D片，音頻，視頻等超文本數(shù)據(jù)。

1. 3次握手（保證可靠性，減少資源浪費(fèi)）-4次斷開(kāi)（優(yōu)雅）
   1.1 3次握手過(guò)程（此處客戶(hù)端和服務(wù)端將分別使用‘客’和‘服’代替）：由客服到服客再到客服。即（SYN）服確認(rèn)客發(fā)送的請(qǐng)求正常和自己的接收正常--（SYN+ACK）客確認(rèn)自己和服的接收和發(fā)送都正常--（ACK）服確認(rèn)客和自己的接受和發(fā)送請(qǐng)求都正常。最后客和服都確認(rèn)自己的接收和發(fā)送都正常就可以建立連接。
   1.2 4次揮手此處客戶(hù)端和服務(wù)端將分別使用‘客’和‘服’代替）：由客到服再由服到客然后繼續(xù)由服到客最后由客到服。即(FIN結(jié)束+ACK確認(rèn)）客請(qǐng)求斷開(kāi)連接，服接收--（ACK）服發(fā)送收到--（FIN+ACK）但是服仍有數(shù)據(jù)沒(méi)發(fā)送給客，服發(fā)送完數(shù)據(jù)后才會(huì)向客戶(hù)端發(fā)送斷開(kāi)鏈接的請(qǐng)求，表示已斷開(kāi)--（ACK）客發(fā)送給服表示知道服關(guān)閉了連接。

2. 應(yīng)用場(chǎng)景：
   2.1 API的設(shè)計(jì)和應(yīng)用
   2.2 基本的請(qǐng)求和響應(yīng)機(jī)制
   2.3 復(fù)雜的數(shù)據(jù)交換格式（json、xml等）
   2.4 websocket
   2.5http/2和http/3等新技術(shù)

3. 完整傳輸過(guò)程:
   3.1域名解析。
   3.2發(fā)起TCP的3次握手。
   3.3建立TCP連接后發(fā)起http請(qǐng)求。
   3.4服務(wù)器端響應(yīng)http請(qǐng)求，瀏覽器得到html代碼。
   3.5瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源。
   3.6瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶(hù)。

4. 發(fā)展動(dòng)力：主要是客戶(hù)需求的推動(dòng)

5.傳輸數(shù)據(jù)在不同層的含義（統(tǒng)稱(chēng)數(shù)據(jù)包）：
5.1 MAC層的傳輸單位是幀frame
5.2 IP層的傳輸單位是包packet
5.3 TCP層的傳輸單位是段segment
5.4 HTTP層的傳輸單位是消息或報(bào)文message

*6.請(qǐng)求響應(yīng)結(jié)構(gòu)（核心內(nèi)容）：
*6.1請(qǐng)求格式：。請(qǐng)求行（包含方法、url、http版本）
。請(qǐng)求頭（包含請(qǐng)求的附加信息，如Host、User-Agent等）
   。空行（請(qǐng)求行和請(qǐng)求體之間的分隔）
。請(qǐng)求體（可選，包含發(fā)送給服務(wù)器的數(shù)據(jù)）
* 6.2響應(yīng)格式：
。狀態(tài)行（包含http版本、狀態(tài)碼、狀態(tài)消息）
。響應(yīng)頭（包含響應(yīng)的附加信息，如Content-Type、Content-Length等）
。空行(響應(yīng)頭和響應(yīng)體之間的分隔)
。響應(yīng)體（服務(wù)器返回的數(shù)據(jù)內(nèi)容）

7. 五大類(lèi)http狀態(tài)碼（狀態(tài)碼的含義）：
   7.1【1xx提示信息】表示臨時(shí)響應(yīng)，告知客戶(hù)端請(qǐng)求已被接受。
   7.2【2xx成功】請(qǐng)求已被成功處理。
   7.3【3xx重定向】需要客戶(hù)端采取進(jìn)一步行動(dòng)來(lái)完成請(qǐng)求。
   7.4【4xx 客戶(hù)端錯(cuò)誤】請(qǐng)求包含錯(cuò)誤，服務(wù)器無(wú)法處理。
   7.5【5xx服務(wù)器錯(cuò)誤】服務(wù)器在處理請(qǐng)求時(shí)發(fā)生了錯(cuò)誤。
   7.6（常見(jiàn)狀態(tài)碼）：
   。200 OK:客戶(hù)端請(qǐng)求成功(成功)。
   。206 Partial Content:客戶(hù)發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。
   。301 Moved Permanently:所請(qǐng)求的頁(yè)面都已經(jīng)轉(zhuǎn)移至新的url。
   。302 Found:所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url。
   。304 Not Modified:客戶(hù)端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求，服務(wù)器告訴客戶(hù)，原來(lái)緩沖的文檔還可以繼續(xù)使用。
   。400 Bad Request:客戶(hù)端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解。
   。401 Unauthorized:請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用

8.鍵入網(wǎng)址再按下回車(chē)，后面究竟發(fā)生了什么 ？
8.1 使用ip地址訪問(wèn)web服務(wù)器（輸入ip和端口號(hào)，用tcp3次握手建立聯(lián)系）
8.2 使用域名訪問(wèn)web服務(wù)器（解析域名，瀏覽器查找緩存--沒(méi)有就向操作系統(tǒng)緩存要，還沒(méi)有就檢查本機(jī)域名解析文件hosts，找到映射得到ip，建立tcp發(fā)送http請(qǐng)求）瀏覽器多了一個(gè)訪問(wèn)hosts文件的動(dòng)作，也就是本機(jī)的DNS解析

9. OSI7層模型（物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，會(huì)話(huà)層，表示層，應(yīng)用層）/TCP/IP 5層模型（物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，應(yīng)用層）
   9.1 TCP/IP 5層模型（物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，應(yīng)用層），其中前三層主要方向是運(yùn)維工程師，后兩層的只要方向是前端工程師。應(yīng)用層構(gòu)建與協(xié)議之上、傳輸層定義數(shù)據(jù) 的傳輸，數(shù)據(jù)過(guò)大需分包、網(wǎng)絡(luò)層為數(shù)據(jù)在節(jié)點(diǎn)之間傳輸創(chuàng)建邏輯鏈路、數(shù)據(jù)鏈路層為通訊實(shí)體間建立數(shù)據(jù)鏈路鏈接。
   9.2 OSI7層模型（物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，會(huì)話(huà)層，表示層，應(yīng)用層）
   9.3 tcp/ip4層模型（網(wǎng)絡(luò)接口層，網(wǎng)絡(luò)層，傳輸層，應(yīng)用層）

10.TCP和UDP的區(qū)別：
10.1 TCP（Transmission Control Protocol，傳輸控制協(xié)議）是基于連接的協(xié)議，也就是說(shuō)，在正式首發(fā)數(shù)據(jù)前，必須和對(duì)方建立起可靠的連接。一個(gè)TCP連接必須要經(jīng)過(guò)‘3次對(duì)話(huà)’才能建立起來(lái)。
10.2 UDP (User Date Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議)是與TCP相對(duì)應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對(duì)方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過(guò)去。UDP只適用于一次只傳送少量數(shù)據(jù)、對(duì)可靠性要求不高的應(yīng)用環(huán)境。

11.第一周總結(jié)：重點(diǎn)是6和1.