java重要知識(shí)點(diǎn)集合（計(jì)算機(jī)網(wǎng)絡(luò)）

• OSI與TCP/IP各層的結(jié)構(gòu)與功能,都有哪些協(xié)議?

  • 應(yīng)用層
    • 應(yīng)用層(application-layer）的任務(wù)是通過應(yīng)用進(jìn)程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用。應(yīng)用層協(xié)議定義的是應(yīng)用進(jìn)程（進(jìn)程：主機(jī)中正在運(yùn)行的程序）間的通信和交互的規(guī)則。對(duì)于不同的網(wǎng)絡(luò)應(yīng)用需要不同的應(yīng)用層協(xié)議充易。在互聯(lián)網(wǎng)中應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS瘪吏，支持萬維網(wǎng)應(yīng)用的 HTTP協(xié)議铃彰，支持電子郵件的 SMTP協(xié)議等等盏檐。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報(bào)文呀打。
    • 域名系統(tǒng)(Domain Name System縮寫 DNS，Domain Name被譯為域名)是因特網(wǎng)的一項(xiàng)核心服務(wù)糯笙，它作為可以將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫贬丛，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的IP數(shù)串给涕。
    • HTTP協(xié)議：超文本傳輸協(xié)議（HTTP豺憔，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議额获。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個(gè)標(biāo)準(zhǔn)。
  • 運(yùn)輸層
    • 運(yùn)輸層(transport layer)的主要任務(wù)就是負(fù)責(zé)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)恭应。應(yīng)用進(jìn)程利用該服務(wù)傳送應(yīng)用層報(bào)文抄邀。“通用的”是指并不針對(duì)某一個(gè)特定的網(wǎng)絡(luò)應(yīng)用昼榛，而是多種應(yīng)用可以使用同一個(gè)運(yùn)輸層服務(wù)境肾。由于一臺(tái)主機(jī)可同時(shí)運(yùn)行多個(gè)線程，因此運(yùn)輸層有復(fù)用和分用的功能胆屿。所謂復(fù)用就是指多個(gè)應(yīng)用層進(jìn)程可同時(shí)使用下面運(yùn)輸層的服務(wù)奥喻，分用和復(fù)用相反，是運(yùn)輸層把收到的信息分別交付上面應(yīng)用層中的相應(yīng)進(jìn)程非迹。
    • 運(yùn)輸層主要使用以下兩種協(xié)議:
      • 傳輸控制協(xié)議 TCP（Transmission Control Protocol）--提供面向連接的环鲤，可靠的數(shù)據(jù)傳輸服務(wù)。
      • 用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）--提供無連接的憎兽，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/li>
    • 請(qǐng)簡(jiǎn)述TCP\UDP的區(qū)別
      • TCP和UDP是OSI模型中的運(yùn)輸層中的協(xié)議冷离。TCP提供可靠的通信傳輸，而UDP則常被用于讓廣播和細(xì)節(jié)控制交給應(yīng)用的通信傳輸纯命。
      • TCP面向連接西剥，UDP面向非連接即發(fā)送數(shù)據(jù)前不需要建立鏈接
      • TCP提供可靠的服務(wù)（數(shù)據(jù)傳輸），UDP無法保證
      • TCP面向字節(jié)流亿汞，UDP面向報(bào)文
      • TCP數(shù)據(jù)傳輸慢瞭空，UDP數(shù)據(jù)傳輸快
  • 網(wǎng)絡(luò)層
    • 在 計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)計(jì)算機(jī)之間可能會(huì)經(jīng)過很多個(gè)數(shù)據(jù)鏈路，也可能還要經(jīng)過很多通信子網(wǎng)留夜。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點(diǎn)， 確保數(shù)據(jù)及時(shí)傳送图甜。 在發(fā)送數(shù)據(jù)時(shí)碍粥，網(wǎng)絡(luò)層把運(yùn)輸層產(chǎn)生的報(bào)文段或用戶數(shù)據(jù)報(bào)封裝成分組和包進(jìn)行傳送。在 TCP/IP 體系結(jié)構(gòu)中黑毅，由于網(wǎng)絡(luò)層使用 IP 協(xié)議嚼摩，因此分組也叫 IP 數(shù)據(jù)報(bào) ，簡(jiǎn)稱 數(shù)據(jù)報(bào)矿瘦。
    • 這里要注意：不要把運(yùn)輸層的“用戶數(shù)據(jù)報(bào) UDP ”和網(wǎng)絡(luò)層的“ IP 數(shù)據(jù)報(bào)”弄混枕面。另外，無論是哪一層的數(shù)據(jù)單元缚去，都可籠統(tǒng)地用“分組”來表示潮秘。
    • 這里強(qiáng)調(diào)指出，網(wǎng)絡(luò)層中的“網(wǎng)絡(luò)”二字已經(jīng)不是我們通常談到的具體網(wǎng)絡(luò)易结，而是指計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)模型中第三層的名稱.
    • 互聯(lián)網(wǎng)是由大量的異構(gòu)（heterogeneous）網(wǎng)絡(luò)通過路由器（router）相互連接起來的枕荞」窈颍互聯(lián)網(wǎng)使用的網(wǎng)絡(luò)層協(xié)議是無連接的網(wǎng)際協(xié)議（Intert Protocol）和許多路由選擇協(xié)議，因此互聯(lián)網(wǎng)的網(wǎng)絡(luò)層也叫做網(wǎng)際層或IP層躏精。
  • 數(shù)據(jù)鏈路層
    • 數(shù)據(jù)鏈路層(data link layer)通常簡(jiǎn)稱為鏈路層渣刷。兩臺(tái)主機(jī)之間的數(shù)據(jù)傳輸，總是在一段一段的鏈路上傳送的矗烛，這就需要使用專門的鏈路層的協(xié)議辅柴。 在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí)，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報(bào)組裝程幀瞭吃，在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀碌嘀。每一幀包括數(shù)據(jù)和必要的控制信息（如同步信息，地址信息虱而，差錯(cuò)控制等）筏餐。
    • 在接收數(shù)據(jù)時(shí)，控制信息使接收端能夠知道一個(gè)幀從哪個(gè)比特開始和到哪個(gè)比特結(jié)束牡拇。這樣魁瞪，數(shù)據(jù)鏈路層在收到一個(gè)幀后，就可從中提出數(shù)據(jù)部分惠呼，上交給網(wǎng)絡(luò)層导俘。 控制信息還使接收端能夠檢測(cè)到所收到的幀中有誤差錯(cuò)。如果發(fā)現(xiàn)差錯(cuò)剔蹋，數(shù)據(jù)鏈路層就簡(jiǎn)單地丟棄這個(gè)出了差錯(cuò)的幀旅薄，以避免繼續(xù)在網(wǎng)絡(luò)中傳送下去白白浪費(fèi)網(wǎng)絡(luò)資源。如果需要改正數(shù)據(jù)在鏈路層傳輸時(shí)出現(xiàn)差錯(cuò)（這就是說泣崩，數(shù)據(jù)鏈路層不僅要檢錯(cuò)少梁，而且還要糾錯(cuò)），那么就要采用可靠性傳輸協(xié)議來糾正出現(xiàn)的差錯(cuò)矫付。這種方法會(huì)使鏈路層的協(xié)議復(fù)雜些凯沪。
  • 物理層
    • 在物理層上所傳送的數(shù)據(jù)單位是比特。 物理層(physical layer)的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送买优，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異妨马。 使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么∩庇“透明傳送比特流”表示經(jīng)實(shí)際電路傳送后的比特流沒有發(fā)生變化烘跺，對(duì)傳送的比特流來說，這個(gè)電路好像是看不見的脂崔。
    • 在互聯(lián)網(wǎng)使用的各種協(xié)中最重要和最著名的就是 TCP/IP 兩個(gè)協(xié)議÷舜荆現(xiàn)在人們經(jīng)常提到的TCP/IP并不一定單指TCP和IP這兩個(gè)具體的協(xié)議，而往往表示互聯(lián)網(wǎng)所使用的整個(gè)TCP/IP協(xié)議族砌左。

• TCP 三次握手和四次揮手相關(guān)問題(重點(diǎn))

  • 三次握手相關(guān)問題

    • 圖解：

    • 流程講解：

      
      

    • 為什么要傳回 SYN

      • 接收端傳回發(fā)送端所發(fā)送的 SYN 是為了告訴發(fā)送端娇钱，我接收到的信息確實(shí)就是你所發(fā)送的信號(hào)了伤柄。

    • 傳了 SYN,為啥還要傳 ACK

      • 雙方通信無誤必須是兩者互相發(fā)送信息都無誤。傳了 SYN文搂，證明發(fā)送方到接收方的通道沒有問題适刀，但是接收方到發(fā)送方的通道還需要 ACK 信號(hào)來進(jìn)行驗(yàn)證。
  • 四次揮手相關(guān)問題
    • 第一步煤蹭，當(dāng)主機(jī)A的應(yīng)用程序通知TCP數(shù)據(jù)已經(jīng)發(fā)送完畢時(shí)笔喉，TCP向主機(jī)B發(fā)送一個(gè)帶有FIN附加標(biāo)記的報(bào)文段（FIN表示英文finish）。
    • 第二步硝皂，主機(jī)B收到這個(gè)FIN報(bào)文段之后常挚，并不立即用FIN報(bào)文段回復(fù)主機(jī)A，而是先向主機(jī)A發(fā)送一個(gè)確認(rèn)序號(hào)ACK稽物，同時(shí)通知自己相應(yīng)的應(yīng)用程序：對(duì)方要求關(guān)閉連接（先發(fā)送ACK的目的是為了防止在這段時(shí)間內(nèi)奄毡，對(duì)方重傳FIN報(bào)文段）。
    • 第三步贝或，主機(jī)B的應(yīng)用程序告訴TCP：我要徹底的關(guān)閉連接吼过，TCP向主機(jī)A送一個(gè)FIN報(bào)文段。
    • 第四步咪奖，主機(jī)A收到這個(gè)FIN報(bào)文段后盗忱，向主機(jī)B發(fā)送一個(gè)ACK表示連接徹底釋放。
  • 為什么是三次握手?
    • 保證可靠的核心就是雙方都需要確認(rèn)自己發(fā)送和接受信息的功能正常,但因?yàn)榫W(wǎng)絡(luò)環(huán)境的不穩(wěn)定性,這一秒能收發(fā)下一秒可能網(wǎng)絡(luò)核心就發(fā)生嚴(yán)重?fù)砣?所以世界上不存在完全可靠的通信協(xié)議.
  • 兩次握手會(huì)怎樣?
    • 若建立連接只需兩次握手羊赵，客戶端并沒有太大的變化趟佃，在獲得服務(wù)端的應(yīng)答后進(jìn)入ESTABLISHED狀態(tài)，即確認(rèn)自己的發(fā)送和接受信息的功能正常昧捷。但如果服務(wù)端在收到連接請(qǐng)求后就進(jìn)入ESTABLISHED狀態(tài),不能保證客戶端能收到自己的信息,此時(shí)如果網(wǎng)絡(luò)擁塞闲昭，客戶端發(fā)送的連接請(qǐng)求遲遲到不了服務(wù)端，客戶端便超時(shí)重發(fā)請(qǐng)求靡挥，如果服務(wù)端正確接收并確認(rèn)應(yīng)答序矩，雙方便開始通信，通信結(jié)束后釋放連接芹血。此時(shí)贮泞，如果那個(gè)失效的連接請(qǐng)求抵達(dá)了服務(wù)端楞慈，由于只有兩次握手幔烛，服務(wù)端收到請(qǐng)求就會(huì)進(jìn)入ESTABLISHED狀態(tài)，等待發(fā)送數(shù)據(jù)或主動(dòng)發(fā)送數(shù)據(jù)囊蓝。但此時(shí)的客戶端早已進(jìn)入CLOSED狀態(tài)饿悬，服務(wù)端將會(huì)一直等待下去，這樣浪費(fèi)服務(wù)端連接資源.
  • 為什么連接的時(shí)候是三次握手聚霜，關(guān)閉的時(shí)候卻是四次握手狡恬？
    • 因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后珠叔，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來應(yīng)答的弟劲，SYN報(bào)文是用來同步的祷安。但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)兔乞，很可能并不會(huì)立即關(guān)閉SOCKET汇鞭，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端庸追，"你發(fā)的FIN報(bào)文我收到了"霍骄。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文淡溯，因此不能一起發(fā)送读整。故需要四步握手。
  • 為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報(bào)文段生存時(shí)間)才能返回到CLOSE狀態(tài)咱娶？
    • 雖然按道理米间，四個(gè)報(bào)文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了豺总，但是我們必須假象網(wǎng)絡(luò)是不可靠的车伞，有可以最后一個(gè)ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報(bào)文喻喳。在Client發(fā)送出最后的ACK回復(fù)另玖，但該ACK可能丟失。Server如果沒有收到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í)器，等待2MSL的時(shí)間纲熏。如果在該時(shí)間內(nèi)再次收到FIN妆丘，那么Client會(huì)重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)局劲。MSL指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間勺拣，2MSL就是一個(gè)發(fā)送和一個(gè)回復(fù)所需的最大時(shí)間。如果直到2MSL鱼填，Client都沒有再次收到FIN药有，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接

• TCP 協(xié)議如何保證可靠傳輸

  • 應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。
  • TCP 給發(fā)送的每一個(gè)包進(jìn)行編號(hào)愤惰，接收方對(duì)數(shù)據(jù)包進(jìn)行排序苇经，把有序數(shù)據(jù)傳送給應(yīng)用層。
  • 校驗(yàn)和： TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和宦言。這是一個(gè)端到端的檢驗(yàn)和扇单，目的是檢測(cè)數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)奠旺，TCP 將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段令花。
  • TCP 的接收端會(huì)丟棄重復(fù)的數(shù)據(jù)。
  • 流量控制： TCP 連接的每一方都有固定大小的緩沖空間凉倚，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)兼都。當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率稽寒，防止包丟失扮碧。TCP 使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。 （TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制）
  • 擁塞控制： 當(dāng)網(wǎng)絡(luò)擁塞時(shí)杏糙，減少數(shù)據(jù)的發(fā)送慎王。
  • ARQ協(xié)議： 也是為了實(shí)現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送宏侍，等待對(duì)方確認(rèn)赖淤。在收到確認(rèn)后再發(fā)下一個(gè)分組。
  • 超時(shí)重傳： 當(dāng) TCP 發(fā)出一個(gè)段后谅河，它啟動(dòng)一個(gè)定時(shí)器咱旱，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)绷耍，將重發(fā)這個(gè)報(bào)文段吐限。

• 滑動(dòng)窗口和流量控制

  • TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率褂始，保證接收方來得及接收诸典。 接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率崎苗。將窗口字段設(shè)置為 0狐粱，則發(fā)送方不能發(fā)送數(shù)據(jù)。

• 擁塞控制

  • 在某段時(shí)間胆数，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分肌蜻，網(wǎng)絡(luò)的性能就要變壞。這種情況就叫擁塞幅慌。擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中宋欺，這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載轰豆。擁塞控制所要做的都有一個(gè)前提胰伍，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷齿诞。擁塞控制是一個(gè)全局性的過程，涉及到所有的主機(jī)骂租，所有的路由器祷杈，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。相反渗饮，流量控制往往是點(diǎn)對(duì)點(diǎn)通信量的控制但汞，是個(gè)端到端的問題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率互站，以便使接收端來得及接收私蕾。
  • 為了進(jìn)行擁塞控制，TCP 發(fā)送方要維持一個(gè) 擁塞窗口(cwnd) 的狀態(tài)變量胡桃。擁塞控制窗口的大小取決于網(wǎng)絡(luò)的擁塞程度踩叭，并且動(dòng)態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個(gè)翠胰。
  • TCP的擁塞控制采用了四種算法容贝，即 慢開始 、 擁塞避免 之景、快重傳 和 快恢復(fù)斤富。在網(wǎng)絡(luò)層也可以使路由器采用適當(dāng)?shù)姆纸M丟棄策略（如主動(dòng)隊(duì)列管理 AQM），以減少網(wǎng)絡(luò)擁塞的發(fā)生锻狗。
  • 慢開始： 慢開始算法的思路是當(dāng)主機(jī)開始發(fā)送數(shù)據(jù)時(shí)满力，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，那么可能會(huì)引起網(wǎng)絡(luò)阻塞轻纪，因?yàn)楝F(xiàn)在還不知道網(wǎng)絡(luò)的符合情況脚囊。經(jīng)驗(yàn)表明，較好的方法是先探測(cè)一下桐磁，即由小到大逐漸增大發(fā)送窗口悔耘，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd初始值為1我擂，每經(jīng)過一個(gè)傳播輪次衬以，cwnd加倍。
  • 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大校摩，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送放的cwnd加1.
  • 快重傳與快恢復(fù)： 在 TCP/IP 中看峻，快速重傳和恢復(fù)（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法衙吩，它能快速恢復(fù)丟失的數(shù)據(jù)包互妓。沒有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會(huì)使用定時(shí)器來要求傳輸暫停冯勉。在暫停的這段時(shí)間內(nèi)澈蚌，沒有新的或復(fù)制的數(shù)據(jù)包被發(fā)送。有了 FRR灼狰，如果接收機(jī)接收到一個(gè)不按順序的數(shù)據(jù)段宛瞄，它會(huì)立即給發(fā)送機(jī)發(fā)送一個(gè)重復(fù)確認(rèn)。如果發(fā)送機(jī)接收到三個(gè)重復(fù)確認(rèn)交胚，它會(huì)假定確認(rèn)件指出的數(shù)據(jù)段丟失了份汗，并立即重傳這些丟失的數(shù)據(jù)段。有了 FRR蝴簇，就不會(huì)因?yàn)橹貍鲿r(shí)要求的暫停被耽誤杯活。 　當(dāng)有單獨(dú)的數(shù)據(jù)包丟失時(shí)，快速重傳和恢復(fù)（FRR）能最有效地工作熬词。當(dāng)有多個(gè)數(shù)據(jù)信息包在某一段很短的時(shí)間內(nèi)丟失時(shí)轩猩，它則不能很有效地工作。

• ARQ協(xié)議

  • 自動(dòng)重傳請(qǐng)求（Automatic Repeat-reQuest荡澎，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一均践。它通過使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸摩幔。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒有收到確認(rèn)幀彤委，它通常會(huì)重新發(fā)送。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議或衡。
  • 停止等待ARQ協(xié)議
    • 停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)慕褂埃幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)（回復(fù)ACK）封断。如果過了一段時(shí)間（超時(shí)時(shí)間后）斯辰，還是沒有收到 ACK 確認(rèn)，說明沒有發(fā)送成功坡疼，需要重新發(fā)送彬呻，直到收到確認(rèn)后再發(fā)下一個(gè)分組；
    • 在停止等待協(xié)議中柄瑰，若接收方收到重復(fù)分組闸氮，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)教沾；
    • 優(yōu)點(diǎn)： 簡(jiǎn)單
    • 缺點(diǎn)： 信道利用率低蒲跨，等待時(shí)間長
    • 1. 無差錯(cuò)情況:
      • 發(fā)送方發(fā)送分組,接收方在規(guī)定時(shí)間內(nèi)收到,并且回復(fù)確認(rèn).發(fā)送方再次發(fā)送。
    • 2. 出現(xiàn)差錯(cuò)情況（超時(shí)重傳）: 停止等待協(xié)議中超時(shí)重傳是指只要超過一段時(shí)間仍然沒有收到確認(rèn)授翻，就重傳前面發(fā)送過的分組（認(rèn)為剛才發(fā)送過的分組丟失了）或悲。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器孙咪，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長一些。這種自動(dòng)重傳方式常稱為 自動(dòng)重傳請(qǐng)求 ARQ 巡语。另外在停止等待協(xié)議中若收到重復(fù)分組翎蹈，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)捌臊。連續(xù) ARQ 協(xié)議 可提高信道利用率。發(fā)送維持一個(gè)發(fā)送窗口兜材，凡位于發(fā)送窗口內(nèi)的分組可連續(xù)發(fā)送出去理澎，而不需要等待對(duì)方確認(rèn)。接收方一般采用累積確認(rèn)曙寡，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)糠爬，表明到這個(gè)分組位置的所有分組都已經(jīng)正確收到了。
    • 3. 確認(rèn)丟失和確認(rèn)遲到
      • 確認(rèn)丟失：確認(rèn)消息在傳輸過程丟失 當(dāng)A發(fā)送M1消息举庶，B收到后执隧，B向A發(fā)送了一個(gè)M1確認(rèn)消息，但卻在傳輸過程中丟失户侥。而A并不知道镀琉，在超時(shí)計(jì)時(shí)過后，A重傳M1消息蕊唐，B再次收到該消息后采取以下兩點(diǎn)措施：
        • 丟棄這個(gè)重復(fù)的M1消息屋摔，不向上層交付。
        • 向A發(fā)送確認(rèn)消息替梨。（不會(huì)認(rèn)為已經(jīng)發(fā)送過了钓试，就不再發(fā)送。A能重傳副瀑，就證明B的確認(rèn)消息丟失）弓熏。
      • 確認(rèn)遲到 ：確認(rèn)消息在傳輸過程中遲到 A發(fā)送M1消息，B收到并發(fā)送確認(rèn)糠睡。在超時(shí)時(shí)間內(nèi)沒有收到確認(rèn)消息挽鞠，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認(rèn)消息（B收到了2份M1）狈孔。此時(shí)A收到了B第二次發(fā)送的確認(rèn)消息滞谢。接著發(fā)送其他數(shù)據(jù)。過了一會(huì)除抛，A收到了B第一次發(fā)送的對(duì)M1的確認(rèn)消息（A也收到了2份確認(rèn)消息）狮杨。處理如下：
        • A收到重復(fù)的確認(rèn)后，直接丟棄到忽。
        • B收到重復(fù)的M1后橄教，也直接丟棄重復(fù)的M1清寇。
  • 連續(xù)ARQ協(xié)議
    • 連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口护蝶，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去华烟，而不需要等待對(duì)方確認(rèn)。接收方一般采用累計(jì)確認(rèn)持灰，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)盔夜，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。
    • 優(yōu)點(diǎn)： 信道利用率高堤魁，容易實(shí)現(xiàn)喂链，即使確認(rèn)丟失，也不必重傳妥泉。
    • 缺點(diǎn)： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息椭微。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號(hào)）盲链，這時(shí)接收方只能對(duì)前兩個(gè)發(fā)送確認(rèn)蝇率。發(fā)送方無法知道后三個(gè)分組的下落，而只好把后三個(gè)全部重傳一次刽沾。這也叫 Go-Back-N（回退 N）本慕，表示需要退回來重傳已經(jīng)發(fā)送過的 N 個(gè)消息。

• 在瀏覽器中輸入url地址 ->> 顯示主頁的過程(重點(diǎn))

  • 總體來說分的幾個(gè)過程
    • DNS解析
    • TCP連接
    • 發(fā)送HTTP請(qǐng)求
    • 服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文
    • 瀏覽器解析渲染頁面
    • 連接結(jié)束
  • 等待整體：https://segmentfault.com/a/1190000006879700

• 狀態(tài)碼

  • 圖解：

• 各種協(xié)議與HTTP協(xié)議之間的關(guān)系

  • 圖解

• HTTP長連接,短連接

  • 在HTTP/1.0中默認(rèn)使用短連接侧漓。也就是說间狂，客戶端和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接火架，任務(wù)結(jié)束就中斷連接鉴象。當(dāng)客戶端瀏覽器訪問的某個(gè)HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件何鸡、CSS文件等）纺弊，每遇到這樣一個(gè)Web資源，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話骡男。而從HTTP/1.1起淆游，默認(rèn)使用長連接，用以保持連接特性隔盛。使用長連接的HTTP協(xié)議犹菱，會(huì)在響應(yīng)頭加入這行代碼：Connection:keep-alive 在使用長連接的情況下，當(dāng)一個(gè)網(wǎng)頁打開完成后吮炕，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉腊脱，客戶端再次訪問這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接龙亲。Keep-Alive不會(huì)永久保持連接陕凹，它有一個(gè)保持時(shí)間悍抑，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接杜耙。HTTP協(xié)議的長連接和短連接搜骡，實(shí)質(zhì)上是TCP協(xié)議的長連接和短連接。

• HTTP 1.0和HTTP 1.1的主要區(qū)別是什么?

  • HTTP1.0最早在網(wǎng)頁中使用是在1996年佑女，那個(gè)時(shí)候只是使用一些較為簡(jiǎn)單的網(wǎng)頁上和網(wǎng)絡(luò)請(qǐng)求上记靡，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)絡(luò)請(qǐng)求中，同時(shí)HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議团驱。 主要區(qū)別主要體現(xiàn)在：
  • 長連接 : 在HTTP/1.0中摸吠，默認(rèn)使用的是短連接，也就是說每次請(qǐng)求都要重新建立一次連接店茶。HTTP 是基于TCP/IP協(xié)議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷蜕便，如果每次請(qǐng)求都要這樣的話劫恒，開銷會(huì)比較大贩幻。因此最好能維持一個(gè)長連接，可以用個(gè)長連接來發(fā)多個(gè)請(qǐng)求两嘴。HTTP 1.1起丛楚，默認(rèn)使用長連接 ,默認(rèn)開啟Connection： keep-alive。 HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式 憔辫。流水線方式是客戶在收到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)碼贰您，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突坏平；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
  • 緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)锦亦，HTTP1.1則引入了更多的緩存控制策略例如Entity tag舶替，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
  • 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用 :HTTP1.0中杠园，存在一些浪費(fèi)帶寬的現(xiàn)象顾瞪，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過來了抛蚁，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能陈醒，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分瞧甩，即返回碼是206（Partial Content）钉跷，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

• URI和URL的區(qū)別是什么?

  • URI(Uniform Resource Identifier) 是同一資源標(biāo)志符肚逸，可以唯一標(biāo)識(shí)一個(gè)資源尘应。
  • URL(Uniform Resource Location) 是同一資源定位符惶凝，可以提供該資源的路徑。它是一種具體的 URI犬钢，即 URL 可以用來標(biāo)識(shí)一個(gè)資源苍鲜，而且還指明了如何 locate 這個(gè)資源。
  • URI的作用像身份證號(hào)一樣玷犹，URL的作用更像家庭住址一樣混滔。URL是一種具體的URI，它不僅唯一標(biāo)識(shí)資源歹颓，而且還提供了定位該資源的信息坯屿。

• HTTP 和 HTTPS 的區(qū)別？

  • 端口 ：HTTP的URL由“http://”起始且默認(rèn)使用端口80巍扛，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443领跛。
  • 安全性和資源消耗： HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文撤奸，客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份吠昭。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運(yùn)行在TCP之上胧瓜。所有傳輸?shù)膬?nèi)容都經(jīng)過加密矢棚，加密采用對(duì)稱加密，但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密府喳。所以說蒲肋，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費(fèi)更多服務(wù)器資源钝满。
    • 對(duì)稱加密：密鑰只有一個(gè)兜粘，加密解密為同一個(gè)密碼，且加解密速度快弯蚜，典型的對(duì)稱加密算法有DES孔轴、AES等；
    • 非對(duì)稱加密：密鑰成對(duì)出現(xiàn)（且根據(jù)公鑰無法推知私鑰熟吏，根據(jù)私鑰也無法推知公鑰）距糖，加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密）牵寺，相對(duì)對(duì)稱加密速度較慢悍引，典型的非對(duì)稱加密算法有RSA、DSA等帽氓。

• 請(qǐng)簡(jiǎn)單說一下你了解的端口及對(duì)應(yīng)的服務(wù)趣斤？

  • 圖解：

    image.png

• 簡(jiǎn)述HTTP中GET和POST的區(qū)別

  • 從原理性看：
    • 根據(jù)HTTP規(guī)范，GET用于信息獲取黎休，而且應(yīng)該是安全和冪等的
    • 根據(jù)HTTP規(guī)范浓领，POST請(qǐng)求表示可能修改服務(wù)器上資源的請(qǐng)求
  • 從表面上看：
    • GET請(qǐng)求的數(shù)據(jù)會(huì)附在URL后面玉凯，POST的數(shù)據(jù)放在HTTP包體
    • POST安全性比GET安全性高