1. HTTP狀態(tài)碼

• 1XX：信息狀態(tài)碼：接收的請(qǐng)求正在處理

  • 100 Continue 繼續(xù)，一般在發(fā)送post請(qǐng)求時(shí)监右，已發(fā)送了http header之后服務(wù)端返回此信息表示確認(rèn)抖僵，之后發(fā)送具體參數(shù)信息

• 2XX：成功狀態(tài)碼：請(qǐng)求正常處理完畢

  • 200 OK 正常返回信息
  • 201 Created 請(qǐng)求成功并且服務(wù)器創(chuàng)建了新的資源
  • 202 Accepted 服務(wù)器已接受請(qǐng)求，但尚未處理
  • 204 No Content 服務(wù)器接收的請(qǐng)求已成功處理，但返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分
  • 206 Partical Content 客戶端進(jìn)行了范圍請(qǐng)求狗唉，服務(wù)器成功執(zhí)行了這部分GET請(qǐng)求，響應(yīng)報(bào)文中包含由Content-Range指定范圍的實(shí)體內(nèi)容

• 3XX：重定向狀態(tài)碼：需要進(jìn)行附加操作以完成請(qǐng)求

  • 301 Moved Permanently 請(qǐng)求的網(wǎng)頁(yè)已永久移動(dòng)到新位置涡真，以后應(yīng)使用資源現(xiàn)在所指的URI
  • 302 Found 臨時(shí)性重定向分俯，希望本次能使用新的URI訪問(wèn)
  • 303 See Other 臨時(shí)性重定向，且總是使用 GET 請(qǐng)求新的 URI
  • 304 Not Modified 自從上次請(qǐng)求后哆料，請(qǐng)求的網(wǎng)頁(yè)未修改過(guò)
  • 307 Temporary Redirect 與302有相同含義缸剪，但不會(huì)從POST變成GET

• 4XX：客戶端錯(cuò)誤狀態(tài)碼：服務(wù)器無(wú)法處理請(qǐng)求

  • 400 Bad Request 服務(wù)器無(wú)法理解請(qǐng)求的格式，客戶端不應(yīng)當(dāng)嘗試再次使用相同的內(nèi)容發(fā)起請(qǐng)求
  • 401 Unauthorized 第一次返回表示需要認(rèn)證东亦，第二次返回表示認(rèn)證失敗
  • 403 Forbidden 禁止訪問(wèn)
  • 404 Not Found 找不到如何與 URI 相匹配的資源

• 5XX: 服務(wù)器錯(cuò)誤狀態(tài)碼：服務(wù)器處理請(qǐng)求出錯(cuò)

  • 500 Internal Server Error 服務(wù)器執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤
  • 503 Service Unavailable 服務(wù)器端暫時(shí)無(wú)法處理請(qǐng)求（可能是過(guò)載或維護(hù)）

2. HTTP請(qǐng)求方法

• GET請(qǐng)求訪問(wèn)服務(wù)器上的某一資源
• POST向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求杏节，數(shù)據(jù)被包含在請(qǐng)求體中
• PUT向服務(wù)器提交數(shù)據(jù)并保存到請(qǐng)求URI指定的位置，傳輸文件
• HEAD只請(qǐng)求頁(yè)面的首部典阵，不返回報(bào)文主體部分
• DELETE刪除指定的資源
• OPTIONS查詢針對(duì)請(qǐng)求URI指定資源所支持的方法
• TRACE讓web服務(wù)器端將之前的 請(qǐng)求通信環(huán)回給客戶端的方法
• CONNECT要求通信時(shí)建立隧道奋渔，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行TCP通信

3. HTTP請(qǐng)求報(bào)文結(jié)構(gòu)

• 首行是Request-Line包括：請(qǐng)求方法，請(qǐng)求URI壮啊，協(xié)議版本嫉鲸，CRLF
• 首行之后是若干行請(qǐng)求頭，包括通用頭部歹啼，請(qǐng)求頭部玄渗，實(shí)體頭部座菠，每個(gè)一行以CRLF結(jié)束
• 請(qǐng)求頭和消息實(shí)體之間有一個(gè)CRLF分隔
• 根據(jù)實(shí)際請(qǐng)求需要可能包含一個(gè)消息實(shí)體 一個(gè)請(qǐng)求報(bào)文例子如下
  
  HTTP請(qǐng)求報(bào)文結(jié)構(gòu).png

4. HTTP響應(yīng)報(bào)文結(jié)構(gòu)

• 首行是狀態(tài)行包括：HTTP版本，狀態(tài)碼藤树，狀態(tài)描述浴滴，后面跟一個(gè)CRLF
• 首行之后是若干行響應(yīng)頭，包括：通用頭部也榄，響應(yīng)頭部巡莹，實(shí)體頭部
• 響應(yīng)頭部和響應(yīng)實(shí)體之間用一個(gè)CRLF分隔
• 最后是一個(gè)可能的消息實(shí)體 響應(yīng)報(bào)文例子如下：
  
  HTTP響應(yīng)報(bào)文結(jié)構(gòu).png

5. HTTP1.0 與 HTTP1.1區(qū)別

• 長(zhǎng)連接

  • HTTP/1.0默認(rèn)使用短連接，每次請(qǐng)求都要重新建立連接甜紫。開(kāi)銷會(huì)比較大降宅。HTTP 1.1起，默認(rèn)使用長(zhǎng)連接 ,默認(rèn)開(kāi)啟Connection：keep-alive囚霸。 可以用長(zhǎng)連接來(lái)發(fā)多個(gè)請(qǐng)求腰根。
  • 有非流水線和流水線方式。流水線方式是客戶在收到HTTP的響應(yīng)報(bào)文之前就能接著發(fā)送新的請(qǐng)求報(bào)文拓型。與之相對(duì)應(yīng)的非流水線方式是客戶在收到前一個(gè)響應(yīng)后才能發(fā)送下一個(gè)請(qǐng)求

• 錯(cuò)誤狀態(tài)響應(yīng)碼

  • 在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼额嘿，如410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

• 緩存處理

  • HTTP1.0主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)
  • HTTP1.1則引入了更多的緩存控制策略例如Entity tag劣挫，If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略册养。

• 帶寬優(yōu)化

  • HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象压固，例如客戶端只是需要某個(gè)對(duì)象的一部分球拦，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能
  • HTTP1.1允許只請(qǐng)求資源的某個(gè)部分帐我，返回碼是206（Partial Content）坎炼，這樣就方便了開(kāi)發(fā)者自由的選擇以便于充分利用帶寬和連接

6. Http2.0

• 多路復(fù)用

  • 在 HTTP/1 中，為了性能考慮拦键，我們會(huì)引入雪碧圖谣光、使用多個(gè)域名等等的方式。這一切都是因?yàn)闉g覽器限制了同一個(gè)域名下的請(qǐng)求數(shù)量芬为，當(dāng)頁(yè)面中需要請(qǐng)求很多資源的時(shí)候萄金，隊(duì)頭阻塞會(huì)導(dǎo)致在達(dá)到最大請(qǐng)求數(shù)量時(shí)，剩余的資源需要等待其他資源請(qǐng)求完成后才能發(fā)起請(qǐng)求
  • 在 HTTP/2 中引入了多路復(fù)用技術(shù)媚朦，可以只通過(guò)一個(gè) TCP 連接就可以傳輸所有的請(qǐng)求數(shù)據(jù)捡絮。解決了瀏覽器限制同一個(gè)域名下的請(qǐng)求數(shù)量的問(wèn)題，也更容易實(shí)現(xiàn)全速傳輸莲镣，新開(kāi)一個(gè) TCP 連接需要慢慢提升傳輸速度
  • 在 HTTP/2 中，有兩個(gè)非常重要的概念涎拉，分別是幀（frame）和流（stream）
  • 幀代表著最小的數(shù)據(jù)單位瑞侮，每個(gè)幀會(huì)標(biāo)識(shí)出該幀屬于哪個(gè)流的圆，流也就是多個(gè)幀組成的數(shù)據(jù)流
  • 多路復(fù)用，就是在一個(gè) TCP 連接中可以存在多條流半火。也就是可以發(fā)送多個(gè)請(qǐng)求越妈，對(duì)端可以通過(guò)幀中的標(biāo)識(shí)知道屬于哪個(gè)請(qǐng)求。通過(guò)這個(gè)技術(shù)钮糖，可以避免 HTTP 舊版本中的隊(duì)頭阻塞問(wèn)題梅掠，極大的提高傳輸性能

• Header 壓縮

  • 在 HTTP/1 中，我們使用文本的形式傳輸 header店归，在 header 攜帶 cookie 的情況下阎抒，可能每次都需要重復(fù)傳輸幾百到幾千的字節(jié)。
  • 在 HTTP/2 中消痛，傳輸?shù)?header 進(jìn)行編碼且叁，減少了 header 的大小。并在兩端維護(hù)了索引表秩伞，用于記錄出現(xiàn)過(guò)的 header 逞带，后面在傳輸過(guò)程中就可以傳輸已經(jīng)記錄過(guò)的 header 的鍵名，對(duì)端收到數(shù)據(jù)后就可以通過(guò)鍵名找到對(duì)應(yīng)的值纱新。

• 服務(wù)端 Push

  • 在 HTTP/2 中展氓，服務(wù)端可以在客戶端某個(gè)請(qǐng)求后，主動(dòng)推送其他資源脸爱∮龉可以想象以下情況，某些資源客戶端是一定會(huì)請(qǐng)求的阅羹，這時(shí)就可以采取服務(wù)端 push 的技術(shù)勺疼，提前給客戶端推送必要的資源，這樣就可以相對(duì)減少一點(diǎn)延遲時(shí)間

7. HTTP/3

• HTTP/2存在的問(wèn)題

  • HTTP/2使用多路復(fù)用捏鱼，同一域名下只需要使用一個(gè)TCP連接执庐。當(dāng)連接中出現(xiàn)了丟包的情況，整個(gè)TCP都要開(kāi)始等待重傳导梆，也就導(dǎo)致了后面的所有數(shù)據(jù)都被阻塞轨淌，表現(xiàn)情況反倒不如HTTP/1。對(duì)于HTTP/1來(lái)說(shuō)看尼，開(kāi)啟多個(gè)TCP連接递鹉，出現(xiàn)這種情況只會(huì)影響其中一個(gè)連接，剩余的還可以正常傳輸數(shù)據(jù)藏斩。
  • 這個(gè)問(wèn)題是底層支撐的TCP協(xié)議的問(wèn)題躏结。那么就會(huì)有人考慮到去修改TCP協(xié)議，但這已經(jīng)是一件不可能完成的任務(wù)了狰域。因?yàn)?code>TCP存在的時(shí)間太長(zhǎng)媳拴，已經(jīng)充斥在各種設(shè)備中黄橘，并且這個(gè)協(xié)議是由操作系統(tǒng)實(shí)現(xiàn)的，更新起來(lái)不大現(xiàn)實(shí)屈溉。
  • 基于這個(gè)原因塞关，Google 就更起爐灶搞了一個(gè)基于UDP協(xié)議的QUIC協(xié)議，并且使用在了HTTP/3上子巾，HTTP/3最大的改造就是使用了QUIC帆赢。

• QUIC：

  • QUIC基于UDP，但是在原本的基礎(chǔ)上新增了多路復(fù)用线梗、0-RTT椰于、使用 TLS1.3 加密、流量控制缠导、有序交付廉羔、重傳等等功能。

• 多路復(fù)用

  • 雖然 HTTP/2 支持了多路復(fù)用僻造，但是TCP協(xié)議終究是沒(méi)有這個(gè)功能的憋他。QUIC原生就實(shí)現(xiàn)了這個(gè)功能，并且傳輸?shù)膯蝹€(gè)數(shù)據(jù)流可以保證有序交付且不會(huì)影響其他的數(shù)據(jù)流髓削。
  • QUIC 在移動(dòng)端的表現(xiàn)也會(huì)比TCP好竹挡。因?yàn)?code>TCP是基于IP和端口去識(shí)別連接的，這種方式在多變的移動(dòng)端網(wǎng)絡(luò)環(huán)境下是很脆弱的立膛。但是QUIC通過(guò)ID的方式去識(shí)別一個(gè)連接揪罕，不管網(wǎng)絡(luò)環(huán)境如何變化，只要 ID 不變宝泵，就能迅速重連好啰。

• 0-RTT

  • 對(duì)于TCP連接需要1RTT，對(duì)于HTTPS這種應(yīng)用而言儿奶，由于還需要額外的TLS握手框往，需要3RTT。而QUIC可以做到0RTT闯捎，即通信雙方發(fā)起通信連接時(shí)椰弊，第一個(gè)數(shù)據(jù)包便可以攜帶有效的業(yè)務(wù)數(shù)據(jù)
  • 如果一對(duì)使用QUIC進(jìn)行加密通信的雙方此前從來(lái)沒(méi)有通信過(guò)，那么0RTT是不可能的瓤鼻，如果客戶機(jī)與服務(wù)器彼此之間曾經(jīng)建立TLS連接秉版，則可以使用從該會(huì)話緩存的信息來(lái)建立新的TLS連接，而不必從頭協(xié)商茬祷，即第一次連接斷開(kāi)后清焕，緩存當(dāng)前會(huì)話的上下文，在下次恢復(fù)會(huì)話的時(shí)候，只需要將之前的緩存?zhèn)鬟f給服務(wù)端驗(yàn)證通過(guò)就可以進(jìn)行傳輸了秸妥。

• 糾錯(cuò)機(jī)制

  • 假如說(shuō)這次我要發(fā)送三個(gè)包借卧，那么協(xié)議會(huì)算出這三個(gè)包的異或值并單獨(dú)發(fā)出一個(gè)校驗(yàn)包，也就是總共發(fā)出四個(gè)包筛峭。當(dāng)出現(xiàn)其中的非校驗(yàn)包丟包的情況時(shí)，可以通過(guò)另外三個(gè)包計(jì)算出丟失的數(shù)據(jù)包的內(nèi)容陪每。當(dāng)然這種技術(shù)只能使用在丟失一個(gè)包的情況下影晓，如果出現(xiàn)丟失多個(gè)包就不能使用糾錯(cuò)機(jī)制了，只能使用重傳的方式檩禾。

8. HTTPS

• HTTP的不足

  • 通信使用明文（不加密）挂签，內(nèi)容可能會(huì)被竊聽(tīng)；
  • 不驗(yàn)證通信方的身份盼产，有可能遭遇偽裝饵婆；
  • 無(wú)法證明報(bào)文的完整性，有可能已遭篡改戏售；

• HTTP +加密+認(rèn)證+完整性保護(hù)=HTTPS

  • HTTPS是安全版的HTTP侨核，不是一個(gè)新的協(xié)議，而是HTTP加上加密處理灌灾、認(rèn)證以及完整性保護(hù)搓译。通信接口部分先和SSL通信，再由SSL和TCP通信锋喜。所謂HTTPS些己，其實(shí)就是身披SSL協(xié)議這層外殼的 HTTP。

• HTTPS采用混合加密機(jī)制

  • 共享密鑰加密：加密和解密同用一個(gè)密鑰的方式稱為共享密鑰加密嘿般，也叫做對(duì)稱密鑰加密段标，以共享密鑰加密時(shí)必須將密鑰也發(fā)送給對(duì)方，但如何安全轉(zhuǎn)交密鑰則稱為一大困難炉奴。
  • 公開(kāi)密鑰加密：公開(kāi)密鑰加密方式很好地解決了共享密鑰加密的困難逼庞。公開(kāi)密鑰加密使用一對(duì)非對(duì)稱的密鑰，一把私有密鑰盆佣，一把公開(kāi)密鑰往堡。其中公開(kāi)密鑰任何人都可以獲得。發(fā)送密文方使用公開(kāi)密鑰進(jìn)行加密處理共耍，接收方使用私鑰進(jìn)行解密虑灰，而根據(jù)公開(kāi)密鑰和密文進(jìn)行解密是異常困難的。
  • HTTPS采用混合加密機(jī)制：在交換密鑰階段使用公開(kāi)密鑰加密方式痹兜，建立通信交換報(bào)文階段使用共享密鑰加密方式穆咐，既保證共享密鑰不被竊取，同時(shí)也不會(huì)因?yàn)楣_(kāi)密鑰過(guò)于復(fù)雜的加密方式導(dǎo)致效率過(guò)低。

• 證明公開(kāi)密鑰正確性的證書

  • 非對(duì)稱密鑰加密方式的問(wèn)題在于对湃，無(wú)法證明公開(kāi)密鑰是否被攻擊者調(diào)包崖叫。為了解決這個(gè)問(wèn)題，可以使用由數(shù)字證書認(rèn)證機(jī)構(gòu)和其相關(guān)機(jī)關(guān)頒發(fā)的公開(kāi)密鑰證書
  • 數(shù)字證書認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后拍柒，會(huì)對(duì)已申請(qǐng)的公開(kāi)密鑰做數(shù)字簽名心傀，將該公開(kāi)密鑰放入公鑰證書后綁定在一起。服務(wù)器會(huì)將這份由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端拆讯，接到證書的客戶端可使用數(shù)字證書認(rèn)證機(jī)構(gòu)的公開(kāi)密鑰脂男，對(duì)那張證書上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過(guò)种呐，客戶端便可明確：一宰翅，認(rèn)證服務(wù)器的公開(kāi)密鑰的是真實(shí)有效的數(shù)字證書認(rèn)證機(jī)構(gòu)。二爽室，服務(wù)器的公開(kāi)密鑰是值得信賴的汁讼。

• 完整性保護(hù)

  • 應(yīng)用層發(fā)送數(shù)據(jù)時(shí)附加MAC報(bào)文摘要，可以查知報(bào)文是否被篡改從而保護(hù)報(bào)文完整性

• HTTPS通信步驟

  • 簡(jiǎn)單來(lái)說(shuō)阔墩，客戶端向一個(gè)需要HTTPS訪問(wèn)的網(wǎng)站發(fā)起請(qǐng)求嘿架，服務(wù)器將證書（包含公鑰）發(fā)給客戶端進(jìn)行校驗(yàn)，客戶端校驗(yàn)成功后戈擒，會(huì)給服務(wù)器發(fā)送一個(gè)使用公鑰加密后的隨機(jī)串眶明，服務(wù)器使用私鑰解密這個(gè)串，從此服務(wù)器與客戶端使用這個(gè)隨機(jī)串進(jìn)行對(duì)稱加密通信筐高。

9. TCP

• 建立連接斷開(kāi)連接都需要先需要進(jìn)行握手搜囱。在傳輸數(shù)據(jù)的過(guò)程中，通過(guò)各種算法保證數(shù)據(jù)的可靠性柑土，當(dāng)然帶來(lái)的問(wèn)題就是相比 UDP 來(lái)說(shuō)不那么的高效
• 三次握手與四次揮手

• ARQ協(xié)議

  • 即超時(shí)重傳機(jī)制蜀肘，通過(guò)確認(rèn)和超時(shí)機(jī)制保證了數(shù)據(jù)的正確送達(dá)，ARQ 協(xié)議包含停止等待ARQ 和連續(xù)ARQ 兩種協(xié)議稽屏。
  • 停止等待ARQ：只要發(fā)送一段報(bào)文扮宠，都要停止發(fā)送并啟動(dòng)一個(gè)定時(shí)器，等待對(duì)端回應(yīng)狐榔，在定時(shí)器時(shí)間內(nèi)接收到對(duì)端應(yīng)答就取消定時(shí)器并發(fā)送下一段報(bào)文坛增。若出現(xiàn)丟包超時(shí)或輸過(guò)程中報(bào)文出錯(cuò)，就會(huì)再次發(fā)送數(shù)據(jù)直到對(duì)端響應(yīng)薄腻，所以需要每次都備份發(fā)送的數(shù)據(jù)收捣。
  • 連續(xù)ARQ：在連續(xù) ARQ 中，發(fā)送端擁有一個(gè)發(fā)送窗口庵楷，可以在沒(méi)有收到應(yīng)答的情況下持續(xù)發(fā)送窗口內(nèi)的數(shù)據(jù)罢艾，通過(guò)累計(jì)確認(rèn)楣颠，可以在收到多個(gè)報(bào)文以后統(tǒng)一回復(fù)一個(gè)應(yīng)答報(bào)文，告訴發(fā)送端這個(gè)序號(hào)之前的數(shù)據(jù)已經(jīng)全部接收到了咐蚯，相比停止等待 ARQ 協(xié)議來(lái)說(shuō)減少了等待時(shí)間童漩，提高了效率，弊端在于可能造成重復(fù)發(fā)送數(shù)據(jù)的情況（7號(hào)已經(jīng)正確接收而6號(hào)丟失）

• 流量控制

  • 在TCP中春锋，兩端其實(shí)都維護(hù)著窗口：分別為發(fā)送端窗口和接收端窗口矫膨。
  • 發(fā)送端窗口包含已發(fā)送但未收到應(yīng)答的數(shù)據(jù)和可以發(fā)送但是未發(fā)送的數(shù)據(jù)
  • 發(fā)送端窗口是由接收窗口剩余大小決定的。接收方會(huì)把當(dāng)前接收窗口的剩余大小寫入應(yīng)答報(bào)文期奔，發(fā)送端收到應(yīng)答后根據(jù)該值和當(dāng)前網(wǎng)絡(luò)擁塞情況設(shè)置發(fā)送窗口的大小豆拨，所以發(fā)送窗口的大小是不斷變化的。
  • 實(shí)現(xiàn)了流量控制的功能
  • 出現(xiàn)零窗口情況時(shí)能庆，發(fā)送端會(huì)停止發(fā)送數(shù)據(jù)，并定時(shí)發(fā)送請(qǐng)求給對(duì)端脚线，讓對(duì)端告知窗口大小搁胆。在重試次數(shù)超過(guò)一定次數(shù)后，可能會(huì)中斷TCP鏈接

• 擁塞處理

  • 慢啟動(dòng)：連接開(kāi)始時(shí)邮绿，最初cwnd（擁塞窗口）=1 MSS（最大報(bào)文長(zhǎng)度）渠旁，每過(guò)一個(gè)RTT，發(fā)送速率翻倍船逮，起始慢顾腊，慢啟動(dòng)階段指數(shù)增長(zhǎng)，直到：
    • 出現(xiàn)超時(shí)指示的丟包事件挖胃，將cwnd設(shè)為1并重新開(kāi)始慢啟動(dòng)杂靶，將ssthresh（慢啟動(dòng)閾值）設(shè)為ssthresh/2
    • cwnd等于ssthresh時(shí)結(jié)束慢啟動(dòng)轉(zhuǎn)移至擁塞避免模式
    • 檢測(cè)到三個(gè)冗余ACK進(jìn)行快速重傳并進(jìn)入快速恢復(fù)狀態(tài)
  • 擁塞避免：每個(gè)RTT只增加1個(gè)MSS
    • 出現(xiàn)超時(shí)，cwnd設(shè)為1個(gè)MSS酱鸭，ssthresh更新為cwnd/2
    • 出現(xiàn)三個(gè)冗余ACK時(shí)吗垮，cwnd減半，ssthresh更新為cwnd/2凹髓，進(jìn)入快速恢復(fù)狀態(tài)
  • 快速恢復(fù)
    • 對(duì)引起進(jìn)入快速恢復(fù)的缺失報(bào)文段烁登，對(duì)收到的每個(gè)冗余ACK，cwnd增加1個(gè)MSS蔚舀，最終當(dāng)對(duì)丟失報(bào)文段的一個(gè)ACK到達(dá)時(shí)饵沧，降低cwnd后進(jìn)入擁塞避免狀態(tài)
    • 如果出現(xiàn)超時(shí)，cwnd設(shè)為1并 ssthresh更新為cwnd的一半赌躺，遷移到慢啟動(dòng)狀態(tài)

10. UDP

• UDP 協(xié)議是面向無(wú)連接的狼牺，不需要在正式傳遞數(shù)據(jù)之前先建立連接，不對(duì)數(shù)據(jù)報(bào)文進(jìn)行拆分和拼接操作寿谴，不保證有序且不丟失的傳遞到對(duì)端锁右，沒(méi)有任何控制流量的算法，在網(wǎng)絡(luò)條件不好的情況下可能會(huì)導(dǎo)致丟包，頭部開(kāi)銷小咏瑟，提供了單播拂到，多播，廣播的功能码泞，適合實(shí)時(shí)性要求高的應(yīng)用場(chǎng)景（如直播兄旬，電話會(huì)議等）
• 總的來(lái)說(shuō) UDP 相較于 TCP 更加的輕便

11. 三次握手與四次揮手

標(biāo)志位介紹

• 三次握手

  • 第一次握手：建立連接時(shí)，客戶端發(fā)送syn包（syn=x）到服務(wù)器余寥，并進(jìn)入SYN_SENT狀態(tài)领铐，等待服務(wù)器確認(rèn)；
  • 第二次握手：服務(wù)器收到syn包宋舷，必須確認(rèn)客戶的SYN（ack=x+1）绪撵，同時(shí)自己也發(fā)送一個(gè)SYN包（syn=y），即SYN+ACK包祝蝠，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)音诈；
  • 第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1）绎狭，此包發(fā)送完畢细溅，客戶端和服務(wù)器進(jìn)入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手儡嘶。

三次握手

• 四次揮手

  • 客戶端進(jìn)程發(fā)出連接釋放報(bào)文喇聊，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部蹦狂，F(xiàn)IN=1誓篱，此時(shí)，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)凯楔。
  • 服務(wù)器收到連接釋放報(bào)文燕鸽，發(fā)出確認(rèn)報(bào)文，ACK=1啼辣，ack=u+1啊研，服務(wù)端進(jìn)入關(guān)閉等待狀態(tài)。這時(shí)客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了鸥拧，但是服務(wù)器若發(fā)送數(shù)據(jù)党远，客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間富弦，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間沟娱。
  • 客戶端收到服務(wù)器的確認(rèn)請(qǐng)求后，客戶端進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)腕柜，等待服務(wù)器發(fā)送連接釋放報(bào)文济似。
  • 服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后矫废，就向客戶端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1砰蠢，ack=u+1蓖扑，服務(wù)器進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)台舱。
  • 客戶端收到服務(wù)器的連接釋放報(bào)文后律杠，必須發(fā)出確認(rèn)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)竞惋。注意此時(shí)TCP連接還沒(méi)有釋放柜去，必須經(jīng)過(guò)2MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，才進(jìn)入CLOSED狀態(tài)拆宛。
  • 服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)嗓奢，立即進(jìn)入CLOSED狀態(tài)，結(jié)束了這次的TCP連接浑厚。服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早蔓罚。

• 【問(wèn)題1】為什么連接三次握手，關(guān)閉卻是四次握手瞻颂？

  • 因?yàn)榻r(shí)當(dāng)Server端收到Client端連接請(qǐng)求報(bào)文后，可以直接發(fā)送確認(rèn)報(bào)文郑象。但是關(guān)閉連接時(shí)Server端收到FIN報(bào)文時(shí)贡这，很可能并不會(huì)立即關(guān)閉，所以只能先回復(fù)一個(gè)ACK報(bào)文厂榛，告訴Client端盖矫，"你發(fā)的FIN報(bào)文我收到了"。等到Server端所有的報(bào)文都發(fā)送完了击奶，才能發(fā)送FIN報(bào)文辈双，因此不能一起發(fā)送。故需要四步握手柜砾。

• 【問(wèn)題2】為什么TIME_WAIT狀態(tài)需要經(jīng)過(guò)2MSL(最大報(bào)文段生存時(shí)間)才能返回到CLOSE狀態(tài)湃望？

  • 在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失痰驱。Server如果沒(méi)有收到ACK证芭，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉担映，它必須確認(rèn)Server接收到了該ACK废士。Client會(huì)在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會(huì)設(shè)置一個(gè)計(jì)時(shí)器蝇完，等待2個(gè)最大報(bào)文段生存時(shí)間官硝。如果在該時(shí)間內(nèi)再次收到FIN矗蕊，那么Client會(huì)重發(fā)并重新計(jì)時(shí)。如果直到2MSL氢架，Client都沒(méi)有再次收到FIN傻咖，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接达箍。

• 【問(wèn)題3】為什么不能用兩次握手進(jìn)行連接没龙？

  • 主要為了防止已失效的請(qǐng)求連接報(bào)文忽然又傳送到了，從而產(chǎn)生錯(cuò)誤缎玫。
  • 假定A向B發(fā)送一個(gè)連接請(qǐng)求硬纤，由于一些原因，導(dǎo)致A發(fā)出的連接請(qǐng)求在一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)逗留了較長(zhǎng)時(shí)間赃磨。此時(shí)A會(huì)將此連接請(qǐng)求作為無(wú)效處理筝家，重新向B發(fā)起了一次新的連接請(qǐng)求，B正常收到此連接請(qǐng)求后建立了連接邻辉，數(shù)據(jù)傳輸完成后釋放了連接溪王。如果此時(shí)A發(fā)出的第一次請(qǐng)求又到達(dá)了B，B會(huì)以為A又發(fā)起了一次連接請(qǐng)求值骇，如果是兩次握手：此時(shí)連接就建立了莹菱，B會(huì)一直等待A發(fā)送數(shù)據(jù)，從而白白浪費(fèi)B的資源吱瘩。 如果是三次握手：由于A沒(méi)有發(fā)起連接請(qǐng)求道伟，也就不會(huì)理會(huì)B的連接響應(yīng)，B沒(méi)有收到A的確認(rèn)連接使碾，就會(huì)關(guān)閉掉本次連接蜜徽。

• 【問(wèn)題4】如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦票摇？

  • TCP還設(shè)有一個(gè)本行活計(jì)時(shí)器，每收到一次客戶端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器矢门，時(shí)間通常是設(shè)置為2小時(shí)盆色，若2小時(shí)內(nèi)還沒(méi)有收到客戶端的任何數(shù)據(jù)，服務(wù)器會(huì)發(fā)送探測(cè)報(bào)文段祟剔，以后每隔75秒鐘發(fā)送一次傅事。若一連發(fā)送10個(gè)仍然沒(méi)反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障峡扩，接著就關(guān)閉連接蹭越。

12. OSI七層模型

OSI七層模型.png

OSI七層模型與TCP/IP五層模型.png