網(wǎng)絡(luò)協(xié)議
-
OSI七層結(jié)構(gòu)
- 應(yīng)用層
- 表示層
- 會話層：半雙工、單工和全雙工的方式建立會話。
- 傳輸層：該層的主要任務(wù)是：向用戶提供可靠的端到端的差錯和流量控制，保證報文的正確傳輸。該層常見的協(xié)議：TCP協(xié)議、UDP協(xié)議。
- 網(wǎng)絡(luò)層：尋址
- 數(shù)據(jù)鏈路層：流量控制，將物理層的數(shù)據(jù)
- 物理層：計算機(jī)之間基礎(chǔ)的比特流
OSI七層模型分別對應(yīng)著五層模型的哪一部分；
OSI模型 TCP/IP分層
應(yīng)用層（HTTP）
表示層（HTML）
會話層 ----------> 應(yīng)用層
傳輸層 ----------> 傳輸層（TCP、UDP）
網(wǎng)絡(luò)層 ----------> 互聯(lián)網(wǎng)絡(luò)層（IP）
數(shù)據(jù)鏈路層（ARP）-> 網(wǎng)卡層
物理層 ----------> 硬件層-
網(wǎng)絡(luò)模型的分層、IP和Mac地址在那個層、TCP和HTTP分別在那個層；
- ip和mac地址在網(wǎng)絡(luò)層
- tcp在數(shù)據(jù)傳輸層
- http在應(yīng)用層
HTTP/HTTPS
-
Https和Http有什么區(qū)別；
一、HTTPS協(xié)議需要到證書頒發(fā)機(jī)構(gòu)CA申請證書，HTTP不用申請證書；二、HTTP是超文本傳輸協(xié)議，屬于應(yīng)用層信息傳輸，HTTPS 則是具有SSL加密傳安全性傳輸協(xié)議，對數(shù)據(jù)的傳輸進(jìn)行加密，相當(dāng)于HTTP的升級版；
三、HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
四、HTTP的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。
https的加密怎么實現(xiàn)的
CA證書+SSL加密-
Http為什么是無狀態(tài)的；
- 原先http協(xié)議只是用來訪問靜態(tài)頁面，無需狀態(tài)。
- 后來http協(xié)議得到廣泛使用，某些場景需要記錄狀態(tài)，針對這種場景可以用session或者cookies來記錄狀態(tài)，無需對http自身進(jìn)行改造。
-
http1.0、http 1.1和http2.0的區(qū)別；
http演化歷史http/1.0：如需要發(fā)送多個請求必須創(chuàng)建多個 TCP 連接，并且瀏覽器對于單域名請求有數(shù)量限制（一般6個），其連接無法被復(fù)用
http/1.1：引入流水線（Pipelining）技術(shù)，但先天 FIFO（先進(jìn)先出）機(jī)制導(dǎo)致當(dāng)前請求的執(zhí)行依賴于上一個請求執(zhí)行的完成，容易引起報頭阻塞，并沒有從根本上解決問題
http/2：重新定義底層 http 語義映射，允許同一個連接上使用請求和響應(yīng)雙向數(shù)據(jù)流。同一域名只需占用一個 TCP 連接，通過數(shù)據(jù)流（Stream）以幀為基本協(xié)議單位，從根本上解決了問題，避免了因頻繁創(chuàng)建連接產(chǎn)生的延遲，減少了內(nèi)存消耗，提升了使用性能
RPC(在dubbo篇重點看)
什么是RPC、如何實現(xiàn)RPC、RPC 的實現(xiàn)原理
網(wǎng)絡(luò)IO
2. 使用事件驅(qū)動模型實現(xiàn)高效穩(wěn)定的網(wǎng)絡(luò)服務(wù)器程序
參考多路復(fù)用，在netty篇重點看
連接
-
什么是長連接和短連接
所謂長連接，指在一個TCP連接上可以連續(xù)發(fā)送多個數(shù)據(jù)包，在TCP連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測包以維持此連接，一般需要自己做在線維持。
短連接是指通信雙方有數(shù)據(jù)交互時，就建立一個TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開此TCP連接，一般銀行都使用短連接。
比如http的，只是連接、請求、關(guān)閉，過程時間較短,服務(wù)器若是一段時間內(nèi)沒有收到請求即可關(guān)閉連接。
其實長連接是相對于通常的短連接而說的，也就是長時間保持客戶端與服務(wù)端的連接狀態(tài)。 -
長連接與短連接的操作過程
通常的短連接操作步驟是：
連接→數(shù)據(jù)傳輸→關(guān)閉連接；而長連接通常就是：
連接→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→保持連接(心跳)→……→關(guān)閉連接；
這就要求長連接在沒有數(shù)據(jù)通信時，定時發(fā)送數(shù)據(jù)包(心跳)，以維持連接狀態(tài)，短連接在沒有數(shù)據(jù)傳輸時直接關(guān)閉就行了 -
什么時候用長連接，短連接？
長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，下次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費(fèi)。
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因為長連接對于服務(wù)端來說會耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。
總之，長連接和短連接的選擇要視情況而定。
TCP、IP/UDP協(xié)議（傳輸層）
tcp可以參照這兩個文檔，講的比較清楚
深入理解TCP協(xié)議（上）：理論基礎(chǔ)
深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理
tcp重點關(guān)注的知識點
- 三次握手、四次揮手和狀態(tài)流轉(zhuǎn)
- 建立socket依靠多路復(fù)用
- 失敗重傳
- 重復(fù)數(shù)據(jù)處理
- 可靠傳輸、包亂序問題
- 流量控制（滑動窗口）
- 擁堵處理（粘包、拆包）
知識點列表
-
全雙工、半雙工、單工
- 全雙工（Full Duplex）是指在發(fā)送數(shù)據(jù)的同時也能夠接收數(shù)據(jù)，兩者同步進(jìn)行，這好像我們平時打電話一樣，說話的同時也能夠聽到對方的聲音。目前的網(wǎng)卡一般都支持全雙工。
- 半雙工（Half Duplex），所謂半雙工就是指一個時間段內(nèi)只有一個動作發(fā)生，舉個簡單例子，一條窄窄的馬路，同時只能有一輛車通過，當(dāng)目前有兩量車對開，這種情況下就只能一輛先過，等到頭兒后另一輛再開，這個例子就形象的說明了半雙工的原理。早期的對講機(jī)、以及早期集線器等設(shè)備都是基于半雙工的產(chǎn)品。隨著技術(shù)的不斷進(jìn)步，半雙工會逐漸退出歷史舞臺.
- 單工通信是指通信線路上的數(shù)據(jù)按單一方向傳送.
三次握手
建立連接前的校驗動作，確保雙方都是可以接收數(shù)據(jù)的。為什么握手不是兩次或者四次，是三次？
TCP 需要 seq 序列號來做可靠重傳或接收，而避免連接復(fù)用時無法分辨出 seq 是延遲或者是舊鏈接的 seq，因此需要三次握手來約定確定雙方的 ISN（初始 seq 序列號）。TCP三次握手?jǐn)?shù)據(jù)丟失了怎么辦？那如果后面又找到了呢？
數(shù)據(jù)丟失，快速重發(fā)（SACK）
重復(fù)數(shù)據(jù)過濾，Duplicate SACK，當(dāng)ack大于后面的SACK時，發(fā)送方就知道這個數(shù)據(jù)已經(jīng)發(fā)送過，丟失的應(yīng)該是ACK。-
TCP的失敗重傳
- 超時重傳
- 快速重傳
- SACK方法
- Duplicate SACK方法
-
四次揮手是什么，為什么不能減少為三次，或者變得更多？
-
SYN攻擊
使用隨機(jī)的ip，偽造SYN請求，將機(jī)器的syn連接的隊列耗盡。- tcp_synack_retries 可以用他來減少重試次數(shù)；
- tcp_max_syn_backlog，可以增大SYN連接數(shù)
- tcp_abort_on_overflow 處理不過來干脆就直接拒絕連接了。
-
tcp的狀態(tài)流轉(zhuǎn)
tcp狀態(tài)流轉(zhuǎn) -
tcp在time_wait狀態(tài)到closed狀態(tài)為什么要等待兩個MSL
- TIME_WAIT確保有足夠的時間讓對端收到了ACK，如果被動關(guān)閉的那方?jīng)]有收到Ack，就會觸發(fā)被動端重發(fā)Fin，一來一去正好2個MSL
- 有足夠的時間讓這個連接不會跟后面的連接混在一起（你要知道，有些自做主張的路由器會緩存IP數(shù)據(jù)包，如果連接被重用了，那么這些延遲收到的包就有可能會跟新連接混在一起）
-
RTT算法
記錄消息從發(fā)送到接收回來消耗的時長，存在以下問題？
重傳的時間要不要計算進(jìn)去？- 經(jīng)典算法，計算了重傳時間
- 改良算法，沒有計算重傳時間，當(dāng)網(wǎng)絡(luò)抖動需要重傳很多時，會有大問題，所以這里取巧，如果發(fā)生重傳，超時時間*2
- 繼續(xù)改良，將重傳時間加權(quán)，用加權(quán)因子，整出一個公式，調(diào)的一手好參數(shù)。
-
tcp的流控，sliding windows 滑動窗口
發(fā)送方窗口示例 TCP的擁塞控制、流量控制詳細(xì)說明？
什么是TCP 粘包/拆包，TCP粘包/拆包的解決辦法
TCP 粘包/拆包的原因及解決方法UDP協(xié)議和TCP協(xié)議的比較、TCP為什么可靠；
TCP/IP協(xié)議-為什么說TCP是可靠連接
快速理解為什么說UDP有時比TCP更有優(yōu)勢
網(wǎng)絡(luò)層
兩個不同ip地址的計算機(jī)之間如何通信；
計算機(jī)之間是如何互相通信的-
地址解析協(xié)議ARP；
【是什么】
透過目標(biāo)設(shè)備的ip地址，查詢目標(biāo)設(shè)備的mac地址，以保證通信的順利進(jìn)行。【怎么做】（緩存->廣播->匹配->更新緩存）
- 每個運(yùn)行tcp/ip協(xié)議的主機(jī)上都會有arp高速緩存表，緩存了目標(biāo)ip地址與mac地址的映射關(guān)系。
- 先從緩存中找，找不到會在本局域網(wǎng)上發(fā)送廣播。
- 局域網(wǎng)內(nèi)所有接收到的arp進(jìn)程，會取報文跟自身比較ip地址，如果匹配，向發(fā)送方發(fā)送消息。
- 發(fā)送方接收到之后，更新本地緩存表。
-
從瀏覽器中輸入URL到頁面加載的發(fā)生了什么？
數(shù)據(jù)鏈路層
-
數(shù)據(jù)鏈路層是做什么的?
- 主要的作用：將不穩(wěn)定的物理層傳輸，轉(zhuǎn)化為穩(wěn)定的數(shù)據(jù)鏈路傳輸，將比特流聚合轉(zhuǎn)為幀
- 因為兩端數(shù)據(jù)處理能力的不同，數(shù)據(jù)鏈路層，需要具備流量控制的能力
-
數(shù)據(jù)鏈路層的流量控制方法？
相關(guān)聯(lián)問題
-
C10k問題
-
長短URL相互轉(zhuǎn)換方案（同筆試題，問我方案可以有多少不同URL，高并發(fā)怎么辦，怎樣建立索引以及怎樣分布式）
在分布式系列中重點分析
-
多路復(fù)用
在netty篇重點看
