摘要:前端主要關注于應用層的協議,傳輸層的協議斷舍離一下,就主要總結這兩種協議了。是序號,是確認序號。根據服務端發來的返回一個包給服務端。服務端接收后進入狀態。并在兩端維護了索引表,用于記錄出現過的,避免重復傳輸。
前端主要關注于應用層的 HTTP 協議,傳輸層的 TCP 協議,斷舍離一下,就主要總結這兩種協議了。OSI 參考模型 與 TCP/IP 五層模型
我們主要關注于 TCP/IP 五層模型 的 應用層 和 傳輸層 就足夠了。
應用層:
作用:為應用程序提供服務。
常見協議:HTTP、HTTPS、FTP、POP3、SMTP等。
傳輸層:
作用:實現應用程序之間的數據傳輸。
協議:UDP、TCP
UDP 與 TCP UDPUDP 是面向無連接的協議,它只會把數據傳遞給接收端,但不會關注接收端是否已經正確接收了數據,所以有時候 UDP 會被認為是不可靠的數據報協議。但這種特性反而適合多播,實時的視頻和音頻傳輸。
優點:
無需建立連接(減少了延遲)
實現簡單(效率高)
頭部開銷小( 8 字節)
沒有擁塞控制(更好的控制發送時間和速率)
缺點:
沒有建立連接(數據想發就發,不可靠)
沒有擁塞控制(網絡條件不好時會導致丟包)
TCPTCP 是面向有連接的協議,在使用 TCP 協議 傳輸數據之前一定需要在發送方和接收方之間建立連接。建立連接三次握手,斷開連接四次揮手~TCP 建立連接三次握手
第一次握手:
客戶端向服務端發送一個 SYN(Seq=X) 包,客戶端進入 SYN-SENT 狀態,等待服務端的 ACK(Ack=X+1)回復。
ps: Seq 是序號,Ack 是確認序號。
第二次握手:
服務端根據接收到客戶端發來的 SYN(Seq=X) 包后返回一個 ACK(Ack=X+1) 以及 SYN(Seq=Y) 包給客戶端,服務端進入 SYN-RECIVED 狀態,等待客戶端的 ACK(Ack=Y+1) 回復。
第三次握手:
客戶端接收到 ACK(X+1) 后,進入 ESTABLISHED 狀態。根據服務端發來的 SYN(Y) 返回一個 ACK(Y+1) 包給服務端。
服務端 接收 ACK(Y+1)后進入 ESTABLISHED 狀態。此時連接建立成功。
TCP 關閉連接四次揮手這個過程可以用以下三句形象表示:
(客戶端):我想建立連接了,服務端你準備好沒有呀?
(服務端):我準備好了,你準備好沒有?
(客戶端):我也準備好了,開始吧~
UDP 與 TCP 的區別這個過程可以用以下四句句形象表示:
(客戶端):我想關閉連接了。
(服務端):我知道了。
(服務端):我現在準備關閉連接了,ok 嗎?
(客戶端):ok,你關閉吧。
UDP 協議是面向無連接的,它不能保證數據有序且不丟失的傳到對端,但是 UDP 比 TCP 更高效。
TCP 協議是面向有連接的,建立和斷開連接都需要握手,在傳輸數據的過程中,通過滑動窗口(流量控制)、擁塞處理(慢開始,擁塞避免,快速重傳,快速恢復),能夠正確處理丟包問題,保證接收方能夠收到數據,與此同時還能夠有效利用網絡帶寬。
HTTPHTTP (HyperText Transfer Protocol) 超文本傳輸協議 是一個基于 TCP (傳輸層) 的應用層協議,是客戶端與服務端之間請求和響應的標準。主要特點
簡單快速
客戶端向服務器請求服務時,只需請求方法和請求路徑。
無狀態
客戶端再次向服務器請求服務時,服務器并不知道客戶端之前是否請求過。
無連接
每次請求都會建立一個 TCP 連接,請求處理完成后連接斷開。HTTP 報文
請求行:
GET https://www.baidu.com/ HTTP/1.1 由請求方法、URL、協議版本組成
響應行:
HTTP/1.1 200 OKHTTP 請求方法
協議版本、狀態碼、狀態信息組成
請求方法分為很多種,最常用的也就是 GET 和 POST 了。雖然請求方法很多,但更多的是為了傳達語義。更多的方法的語義描述可以閱讀 文檔 。
GET 和 POST 的區別GET
能緩存、請求長度限制、 有歷史記錄GET 多用于 無副作用(不修改資源)、冪等(請求次數與資源無關)的場景。
POST
POST 相對 GET 安全一點點,因為 GET 請求發送的數據包含在 URL 里。
兩者詳細對比:
![GET與POST](https://inknight.cn/pic/note/...
)
狀態碼表示了響應的狀態,可以讓我們知道這一次的請求是成功還是失敗,如果失敗,是什么原因導致的。
2XX 成功
200 OK ,請求成功并返回數據
204 No Content ,成功但無內容
206 Partial Content ,范圍請求
3XX 重定向
301 永久重定向,表示資源已被分配了新的 URL
302 臨時重定向,資源臨時被分配新的 URL
304 資源未修改,可使用緩存
4XX 客戶端錯誤
400 請求語法錯誤
401 要求身份認證
403 請求被服務器拒絕
404 資源不存在
5XX 服務器錯誤
500 服務器錯誤
503 服務器超負載或停機維護
HTTPS更安全的網絡傳輸協議
需要安裝證書(公鑰)
經過 SSL/TLS 協議 加密,傳輸的內容是經過加密的
使用 443 端口
HTTP/2多路復用
在同一個 TCP 連接上傳輸所有的請求數據,避免 隊頭阻塞(瀏覽器限制同一個域名下的連接數)問題
Header 壓縮
使用了 HPACK 壓縮格式對傳輸的 header 進行編碼,減少了 header 的大小。并在兩端維護了索引表,用于記錄出現過的 header ,避免 header 重復傳輸。
二進制傳輸
在之前的 HTTP 版本中,我們是通過文本的方式傳輸數據。在 HTTP/2 中引入了新的編碼機制,所有傳輸的數據都會被分割,并采用二進制格式編碼。
服務端推送
服務端可以在客戶端的某個請求后,主動推送其他客戶端在之后會用到的資源。省去了客戶端重復請求的步驟,降低了延遲。
參考資料:
https://juejin.im/post/5c64d15d6fb9a049d37f9c20#heading-49
https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?
http://www.alloyteam.com/2016/07/httphttp2-0spdyhttps-reading-this-is-enough/
https://juejin.im/book/5bdc715fe51d454e755f75ef/section/5bdc72b151882516f039fce3
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/109096.html
摘要:需要說明是的,這里說的專家不再關心細節,不代表成為專家后學不會細節,也不代表專家不了解細節。本文將從三個點去解釋,為什么專家看上去越來越原理技術細節。試想一個不能理解業務要做什么的人,即便懂得再多技術細節,對業務也是沒有價值的。1. 引言 本周的精讀是有感而發。 筆者接觸前端已有八年,觀察了不少前端大牛的發展路徑,發現成功的人都具有相似的經歷: 初期技術熱情極大 -> 大量標志性技術項目 -...
摘要:不過幸運的是所有面試的公司都給了,在這里總結下經驗吧。這里推薦下我當時看的一篇的面經,木易楊老師寫的大廠高級前端面試題匯總。 前言 本人畢業一年,最近陸續面試了頭條、瓜子、360、猿輔導、中信銀行、老虎等公司,由于最近比較寒冬而且招1-3年的并不多,再加上自己對公司規模和位置有一定要求,所以最后合適的也就這幾家了。不過幸運的是所有面試的公司都給了offer,在這里總結下經驗吧。掘金:h...
摘要:互聯網的產品人員,可能整個職業生涯都要與技術人員打交道。還有開房信息泄露那次,是由于被黑客攻擊。關于黑客攻擊的問題,作為產品人員甚至普通的開發人員,都是沒有辦法的事情,要有極其專業的安全團隊才可能應付。 我們常說,作為技術人員要有產品思維,從產品和運營的角度去思考技術方案。是的,我們也這樣做了。然而,從我多年的需求溝通及項目協調的經驗來看,產品人員其實也可以有一點技術思維。 所謂技術思...
摘要:第二十二期掘金團隊請來了進階解密作者劉望舒做了為期三天的活動活動已結束。我們在此精選了一些來自用戶的提問及劉望舒的回答。提醒本期分布式微服務主題的正在進行,歡迎前去提問,傳送門關于劉望舒進階之光進階解密的作者,安卓巴士等技術大會特邀講師。第二十二期 AMA 掘金團隊請來了《Android進階解密》作者-- 劉望舒做了為期三天的 Ask Me Anything (AMA) 活動(活動已結束)。...
摘要:也就正式開始了我的前端之路。在這期間,我還購買并配置了自己的云服務器,自己的博客系統,自己的還學會了的基本操作。不必說的是高級程序設計豆瓣鏈接這本書,也就是大家常說的高程,基本上每個合格的前端程序員都要熟讀很多很多次,每次讀都會有新發現。 原創 西安前端交流會: 卡農 ovenzeze@qq.com 本文章同步發表在wdShare西安前端交流會網站、我的個人博客以及segmentF...
閱讀 1193·2021-11-15 18:00
閱讀 1789·2021-10-08 10:15
閱讀 752·2021-09-04 16:48
閱讀 2373·2021-09-04 16:48
閱讀 1313·2019-08-29 18:40
閱讀 965·2019-08-29 13:08
閱讀 2987·2019-08-26 14:06
閱讀 1110·2019-08-26 13:35