update time 2019年09月19日14:02:34
CSDN地址 （尷尬 簡書暫時還沒有學會整目錄 -，-）
前言
在總結完 前兩章的Android 基礎知識後，我發現自己的Java 基礎方面相當的薄弱（當然這個是我一直都有的軟肋，這次暴漏的更加明顯）所以臨時總結 添加一篇基礎知識，包含的內容：常問的基礎面試題+重點知識點。寫完這一篇文章後，後續會主要總結和閱讀 我經常使用的第三方工具 的源碼解析 例如：Okhttp ，rxjava 等的簡單源碼理解和剖析。本人三年小白，還在不斷摸索中成長，文章有不對的地方勞煩指出，本人將改正學習，加油
重點順序 參考博客 釐米大佬 nb
網絡基礎
網絡協議的體系結構
物理層
數據鏈路層：邏輯鏈路控制LLC、媒體接入控制MAC
網絡層：IP協議、地址解析協議ARP、逆地址解析協議RARP、因特網控制報文協議ICMP
傳輸層：傳輸控制協議TCP、用戶數據報協議UDP
應用層：文件傳輸協議FTP、遠程登錄協議TELNET、超文本傳輸協議HTTP、域名系統DNS、簡單郵件協議SMTP、簡單網絡管理協議SNMP
TCP和UDP
-
TCP傳輸控制協議：面向連接；使用全雙工的可靠信道；提供可靠的服務，即無差錯、不丟失、不重複且按序到達；擁塞控制、流量控制、超時重發、丟棄重複數據等等可靠性檢測手段；面向字節流；每條TCP連接只能是點到點的；用於傳輸可靠性要求高的數據，協議上來說沒有長度限制（但是使用中還是不建議過長數據傳輸）
-
UDP用戶數據報協議：UDP 本身不提供確認，序列號，超時重傳等機制，有長度限制，無連接；使用不可靠信道；盡最大努力交付，即不保證可靠交付；無擁塞控制等；面向報文；支持一對一、一對多、多對一和多對多的交互通信；用於傳輸可靠性要求不高的數據（舉例場景：包總量較少的通信（DNS、SNMP），即時通信，廣播、多播）
TCP特性
- TCP 提供一種面向連接的、可靠的字節流服務
- 僅有兩方進行彼此通信。不能廣播和多播
- TCP 使用校驗和，確認和重傳機制來保證可靠傳輸
- TCP 給數據分節進行排序，並使用累積確認保證數據的順序不變和非重複
- TCP 使用滑動窗口機制來實現流量控制，通過動態改變窗口的大小進行擁塞控制
注意：TCP 並不能保證數據一定會被對方接收到。TCP 能夠做到的是，如果有可能，就把數據遞送到接收方，否則就（通過放棄重傳並且中斷連接這一手段）通知用戶。因此它所能提供的是數據的可靠遞送或故障的可靠通知。
擁塞控制和流量控制
-
擁塞控制：對網絡中的路由和鏈路傳輸進行速度限制，避免網絡過載；包含四個過程：慢啓動、擁塞避免、快重傳和快恢復
-
流量控制 ：對點和點/發送方和接收方之間進行速度匹配，由於接收方的應用程序讀取速度不一定很迅速，加上緩存有限，因此需要避免發送速度過快；相關技術：TCP滑動窗口、回退N針協議
TCP 握手
參考GitBook
建立一個 TCP 連接時，需要客戶端和服務器總共發送3個包。三次握手的目的是連接服務器指定端口，建立 TCP 連接，並同步連接雙方的序列號和確認號，交換 TCP 窗口大小信息。
第一次握手(SYN=1, seq=x):
客戶端發送一個 TCP 的 SYN 標誌位置1的包，指明客戶端打算連接的服務器的端口，以及初始序號 X,保存在包頭的序列號(Sequence Number)字段裏。
發送完畢後，客戶端進入 SYN_SEND 狀態。
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服務器發回確認包(ACK)應答。即 SYN 標誌位和 ACK 標誌位均爲1。服務器端選擇自己 ISN 序列號，放到 Seq 域裏，同時將確認序號(Acknowledgement Number)設置爲客戶的 ISN 加1，即X+1。 發送完畢後，服務器端進入 SYN_RCVD 狀態。
第三次握手(ACK=1，ACKnum=y+1)
客戶端再次發送確認包(ACK)，SYN 標誌位爲0，ACK 標誌位爲1，並且把服務器發來 ACK 的序號字段+1，放在確定字段中發送給對方，並且在數據段放寫ISN的+1
發送完畢後，客戶端進入 ESTABLISHED 狀態，當服務器端接收到這個包時，也進入 ESTABLISHED 狀態，TCP 握手結束。
TCP 揮手
第一次揮手(FIN=1，seq=x)
假設客戶端想要關閉連接，客戶端發送一個 FIN 標誌位置爲1的包，表示自己已經沒有數據可以發送了，但是仍然可以接受數據。
發送完畢後，客戶端進入 FIN_WAIT_1 狀態。
第二次揮手(ACK=1，ACKnum=x+1)
服務器端確認客戶端的 FIN 包，發送一個確認包，表明自己接受到了客戶端關閉連接的請求，但還沒有準備好關閉連接。
發送完畢後，服務器端進入 CLOSE_WAIT 狀態，客戶端接收到這個確認包之後，進入 FIN_WAIT_2 狀態，等待服務器端關閉連接。
第三次揮手(FIN=1，seq=y)
服務器端準備好關閉連接時，向客戶端發送結束連接請求，FIN 置爲1。
發送完畢後，服務器端進入 LAST_ACK 狀態，等待來自客戶端的最後一個ACK。
第四次揮手(ACK=1，ACKnum=y+1)
客戶端接收到來自服務器端的關閉請求，發送一個確認包，並進入 TIME_WAIT狀態，等待可能出現的要求重傳的 ACK 包。
服務器端接收到這個確認包之後，關閉連接，進入 CLOSED 狀態。
客戶端等待了某個固定時間（兩個最大段生命週期，2MSL，2 Maximum Segment Lifetime）之後，沒有收到服務器端的 ACK ，認爲服務器端已經正常關閉連接，於是自己也關閉連接，進入 CLOSED 狀態。
HTTP
HTTP 協議構建於 TCP/IP 協議之上，是一個應用層協議，默認端口號是 80，HTTP 是無連接無狀態的。
HTTP 定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，對應着對這個資源的查，增，改，刪4個操作。
重點說下 GET/POST :
-
GET：當客戶端要從服務器中讀取某個資源時使用GET；一般用於獲取/查詢資源信息；GET參數通過URL傳遞，傳遞的參數是有長度限制，不能用來傳遞敏感信息
-
POST：當客戶端給服務器提供信息較多時可以使用POST；POST會附帶用戶數據，一般用於更新資源信息；POST將請求參數封裝在HTTP 請求數據中，可以傳輸大量數據，傳參方式比GET更安全
狀態碼：
HTTP 響應與 HTTP 請求相似，HTTP響應也由3個部分構成，分別是：
-
狀態行
響應頭(Response Header)
響應正文
狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。 -
常見的狀態碼有如下幾種：
1xx：表示服務器已接收了客戶端請求，客戶端可繼續發送請求
2xx：表示服務器已成功接收到請求並進行處理
3xx：表示服務器要求客戶端重定向
4xx：表示客戶端的請求有非法內容
400 Bad Request：表示客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthonzed：表示請求未經授權，該狀態代碼必須與 WWW-Authenticate 報頭域一起使用
403 Forbidden：表示服務器收到請求，但是拒絕提供服務，通常會在響應正文中給出不提供服務的原因
404 Not Found：請求的資源不存在，例如，輸入了錯誤的URL
5xx：表示服務器未能正常處理客戶端的請求而出現意外錯誤
500 Internal Server Error：表示服務器發生不可預期的錯誤，導致無法完成客戶端的請求
503 Service Unavailable：表示服務器當前不能夠處理客戶端的請求，在一段時間之後，服務器可能會恢復正常
HTTP 發展之路
- HTTP1.0默認使用短連接，HTTP1.1開始默認使用長連接
HTTP1.1增加更多的請求頭和響應頭來改進和擴充HTTP1.0的功能，比如身份認證、狀態管理和Cache緩存等 - HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯，不同於HTTP1.x的解析是基於文本，HTTP2.0 可以主動服務端推送：
HTTP 和 HTTPS區別
-
HTTP（超文本傳輸協議）：運行在TCP之上；傳輸的內容是明文；端口是80
-
HTTPS（安全爲目標的HTTP）：運行在SSL/TLS之上，SSL/TLS運行在TCP之上；傳輸的內容經過加密；端口是443
訪問URL 過程
在瀏覽器地址欄鍵入URL後：
- 瀏覽器向DNS服務器請求解析該URL中的域名所對應的IP地址
- 解析出IP地址後，根據該IP地址和默認端口80，和服務器建立TCP連接
- 瀏覽器發出讀取文件的HTTP請求，該請求報文作爲TCP三次握手的第三個報文的數據發送給服務器
- 服務器對瀏覽器請求作出響應，並把對應的html文本發送給瀏覽器
- 釋放TCP連接，若connection模式爲close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接；若connection模式爲keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求
- 客戶端將服務器響應的html文本解析並顯示