1.五層網絡模型介紹
由於這是針對Android開發者的網絡基礎文章，而計算機網絡知識體系十分複雜繁多，所以筆者這裏只作淺層的介紹，對Android開發無幫助的網絡知識，筆者這裏就不廢話連篇了，讀者如果想深入研究，筆者倒是可以推薦一些書籍，在文章末尾位置。對於上圖的五層網絡模型，我們只需要對應用層和傳輸層研究的細緻些，而下面三層，瞭解即可。下面來對這五層作一一介紹：
- 物理層：主要作用是定義物理設備之間如何傳輸數據。
- 數據鏈路層：在通信的實體之間建立數據鏈路連接。
- 網絡層爲數據在結點之間傳輸創建邏輯鏈路。
- 傳輸層：向用戶提供端到端(End-to-End)的服務,傳輸層向高層屏蔽了下層數據通信的細節，作爲Android開發者,需要對這一層的TCP/IP,UDP協議非常瞭解。
- 應用層：爲應用軟件提供了很多服務，構建於TCP協議之上，屏蔽網絡的傳輸相關細節。這一層需要了解Http,Ftp等協議。
2.Http協議
2.1 三次握手與四次揮手
2.1.1 Tcp三次握手
什麼是三次握手？它主要作用是幹什麼，爲什麼是三次握手呢？我們先來看看Tcp三次握手的過程：
- 第一次握手：客戶端發送syn包(seq=x)到服務器，並進入SYN_SEND狀態，等待服務器確認;
- 第二次握手：服務器收到syn包，必須確認客戶的SYN(ack=x+1)，同時自己也發送一個SYN包(seq=y)，即SYN+ACK包，此時服務器進入SYN_RECV狀態;
- 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
Tcp三次握手的主要目的：
首先，tcp是可靠傳輸協議，需要三次握手建立連接服務。
三次握手的目的是“爲了防止已經失效的連接請求報文段突然又傳到服務端，因而產生錯誤”，這種情況是：client端發出了一個連接請求報文，而是因爲某些未知的原因在某個網絡節點上發生延遲、滯留，導致延遲到連接釋放以後的某個時間纔到達server端。本來這是一個早已失效的報文段，但是server收到此失效的報文之後，會誤認爲是client再次發出的一個新的連接請求，於是server端就向client又發出確認報文，表示同意建立連接。如果不採用“三次握手”，那麼只要server端發出確認報文就會認爲新的連接已經建立了，但是client端此時並沒有發出建立連接的請求，因此不會去向server端發送數據，server端沒有收到數據就會一直等待，產生死鎖現象，這樣server端就會白白浪費掉很多資源。如果採用“三次握手”的話就不會出現這種情況，client端首先發出連接請求並進入等待狀態，server接收連接請求後同意建立連接，並向client返回報文段表示已經建立連接server進入SYN_RECV狀態，client接收到server發出的確認信息後自己再發出確認信息，然後就可以建立直接通信。所以說只有三次握手在邏輯上纔是最合適的，可以保障可靠性。
三次握手的最主要目的是保證連接是雙工的，可靠更多的是通過重傳機制來保證的。
2.1.2 Tcp四次揮手
當客戶端沒有數據再需要發送給服務端時，就需要釋放客戶端的連接，這整個過程爲：
- 1.客戶端發送一個報文給服務端（沒有數據），其中FIN設置爲1，Sequence Number置爲u，客戶端進入FIN_WAIT_1狀態
- 2.服務端收到來自客戶端的請求，發送一個ACK給客戶端，Acknowledge置爲u+1，同時發送Sequence Number爲v，服務端年進入CLOSE_WAIT狀態
- 3.服務端發送一個FIN給客戶端，ACK置爲1，Sequence置爲w，Acknowledge置爲u+1，用來關閉服務端到客戶端的數據傳送，服務端進入LAST_ACK狀態
- 4.客戶端收到FIN後，進入TIME_WAIT狀態，接着發送一個ACK給服務端，Acknowledge置爲w+1，Sequence Number置爲u+1，最後客戶端和服務端都進入CLOSED狀態
也許你會問我：爲什麼TCP連接的建立只需要三次握手而TCP連接的釋放需要四次握手呢：
因爲服務端在LISTEN狀態下，收到建立請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而連接關閉時，當收到對方的FIN報文時，僅僅表示對方沒有需要發送的數據了，但是還能接收數據，己方未必數據已經全部發送給對方了，所以己方可以立即關閉，也可以將應該發送的數據全部發送完畢後再發送FIN報文給客戶端來表示同意現在關閉連接。
從這個角度而言，服務端的ACK和FIN一般都會分開發送。
2.2 請求頭和響應頭
2.2.1 請求頭
什麼是請求頭？http請求頭，HTTP客戶程序（例如瀏覽器），向服務器發送請求的時候必須指明請求類型（一般是GET或者POST）。如有必要，客戶程序還可以選擇發送其他的請求頭。
注意：面試官會問你請求類型僅僅有Get和Post嗎？顯示Http請求不止這兩種：
HTTP協議中共定義了八種方法或者叫“動作”來表明對Request-URI指定的資源的不同操作方式
- OPTIONS：返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送’*'的請求來測試服務器的功能性。
- HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
- GET：向特定的資源發出請求。
- POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的創建和/或已有資源的修改。
- PUT：向指定資源位置上傳其最新內容。
- DELETE：請求服務器刪除Request-URI所標識的資源。
- TRACE：回顯服務器收到的請求，主要用於測試或診斷。
- CONNECT：HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
雖然HTTP的請求方式有8種，但是我們在實際應用中常用的也就是get和post，其他請求方式也都可以通過這兩種方式間接的來實現。面試官接着會問你Get和Post有什麼區別？
Get和Post的區別如下：
a.提交數據方面的區別：
get提交的數據一般放在url之後，用"?"來分隔開來，post是通過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
因爲get設計成傳輸小數據，而且最好是不修改服務器的數據，所以瀏覽器一般都在地址欄裏面可以看到，但post一般都用來傳遞大數據，或比較隱私的數據，所以在地址欄看不到，能不能看到不是協議規定，是瀏覽器規定的。
b.提交的數據大小是否有限制：
get是有大小限制的，而post是沒有大小限制。get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認爲不受限制。但理論上，IIS4中最大量爲80KB，IIS5中爲100KB。
post基本沒有限制，我想大家都上傳過文件，都是用post方式的。只不過要修改form裏面的那個type參數
c.取得變量的值：
對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。
d.安全性：
get安全性非常低，post安全性較高。
如果沒有加密，他們安全級別都是一樣的，隨便一個監聽器都可以把所有的數據監聽到。
以上扯完了Http請求的類型以及Get和Post的區別，接下來，我們來看看請求頭中比較重要的頭字段信息：
2.2.2 響應頭
什麼是響應頭？既然有請求，那麼肯定有響應對不對，在http請求成功時，響應頭中是存在一個叫響應碼的東，它也叫狀態碼，它是用來標記請求的結果狀態，比如：200代表請求成功，做過網絡開發的你對這個狀態碼很熟悉吧！由於狀態碼比較多，所以筆者也就不在這裏一一例舉了,面試的時候把常見的一些說出來就行了，200，404等等。點擊查閱所有狀態碼
接下來我們來看看響應頭中字段信息:
非常注意：
1.如何保存Token呢？比如二次登陸，又或者其它接口需要這個Token才能去訪問，那麼我們可能需要使用set-cookie字段,以下是set-cookie中參數的含義。在之後講解Cookie和Session的時候具體會講解二者和Token之間的聯繫。
2.3 Cookie和Session
2.3.1 什麼是Cookie?
Cookie意爲“甜餅”，是由W3C組織提出，最早由Netscape社區發展的一種機制。目前Cookie已經成爲標準，所有的主流瀏覽器如IE、Netscape、Firefox、Opera等都支持Cookie。
由於HTTP是一種無狀態的協議，服務器單從網絡連接上無從知道客戶身份。怎麼辦呢？就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務器就能從通行證上確認客戶身份了。這就是Cookie的工作原理。
Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
2.3.2 什麼是Session?
Session是另一種記錄客戶狀態的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種方式記錄在服務器上。
如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那麼Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份。Session相當於程序在服務器上建立的一份客戶檔案，客戶來訪的時候只需要查詢客戶檔案表就可以了。它的工作流程如下：
（1）第一步當然是創建Session啦
（2）在創建Session的同時，服務器會爲Session生成一個唯一的Session Id。
（3）在Session創建完成後，就可以調用Session的相關方法往Session中增加內容。
（4）當客戶端再次發送請求的時候，會將這個Session Id帶上，服務器接收到這個請求之後就會依據Session Id找到對應的Session來確認客戶端的身份。
2.3.3 Cookie和Session的區別
a.存放的位置不同：
Cookie保存在客戶端，而Session保存在服務端。簡單的說，當你登錄一個網站的時候，如果web服務器端使用的是session,那麼所有的數據都保存在服務器上面，客戶端每次請求服務器的時候會發送 當前會話的session_id，服務器根據當前session_id判斷相應的用戶數據標誌，以確定用戶是否登錄，或具有某種權限。由於數據是存儲在服務器 上面，所以你不能僞造，但是如果你能夠獲取某個登錄用戶的session_id，用特殊的瀏覽器僞造該用戶的請求也是能夠成功的。session_id是服務 器和客戶端鏈接時候隨機分配的，一般來說是不會有重複，但如果有大量的併發請求，也不是沒有重複的可能性，我曾經就遇到過一次。登錄某個網站，開始顯示的 是自己的信息，等一段時間超時了，一刷新，居然顯示了別人的信息。
b.存取的方式不同：
Cookie中只能保存ASCII字符串，Session中可以保存任意類型的數據，甚至Java Bean乃至任何Java類、對象等。
c.安全性的不同：
Cookie存儲在客戶端，對客戶端是可見的，可被客戶端窺探、複製、修改。而Session存儲在服務器上，不存在敏感信息泄露的風險
d.有效期上的不同：
Cookie的過期時間可以被設置很長。Session依賴於名爲JSESSIONI的Cookie，其過期時間默認爲-1，只要關閉了瀏覽器窗口，該Session就會過期，因此Session不能完成信息永久有效。如果Session的超時時間過長，服務器累計的Session就會越多，越容易導致內存溢出。
e.對服務器造成的壓力不同：
每個用戶都會產生一個session，如果併發訪問的用戶過多，就會產生非常多的session，耗費大量的內存。因此，諸如Google、Baidu這樣的網站，不太可能運用Session來追蹤客戶會話。
f.瀏覽器支持不同:
Cookie運行在瀏覽器端，若瀏覽器不支持Cookie，需要運用Session和URL地址重寫。
g.跨域支持不同:
Cookie支持跨域訪問（設置domain屬性實現跨子域），Session不支持跨域訪問
2.3.4 Token和 Cookie & Session的聯繫
2.4 長連接和短連接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
2.5 心跳包
2.6 Http發展歷史
https://www.cnblogs.com/zhangyfr/p/8662673.html
3.Https
什麼是Https?Https並不是一個單獨的協議，而是對工作在一加密連接（SSL/TLS）上的常規Http協議，通過TCP和Http之間加入TLS(Transport Layer Security)來加密保證數據的安全。
3.1 Https和Http區別
HTTP+ 加密 + 認證 + 完整性保護 = HTTPS
3.2 SSL/TLS協議
4.DNS
4.1 什麼是DNS?
它所提供的服務是用來將主機名和域名轉換爲IP地址的工作。
當然現在已經是IPV6了。圖比較老了，理解它的原理，此圖就湊合湊合吧！
4.2 DNS查詢過程
遞歸：DNS服務器可使用其自身的資源記錄信息緩存來應答查詢，也可代表請求客戶機來查詢或聯繫其他DNS服務器，以完全解析該名稱，並隨後將應答返回至客戶機。
迭代：客戶機自己也可嘗試聯繫其他的DNS服務器來解析名稱。如果客戶機這麼做，它會使用基於服務器應答的獨立和附加的查詢。
步驟如下：
a.在瀏覽器中輸入域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關係。
b.如果hosts裏沒有這個域名的映射，則查詢本地DNS解析器緩存。
c.如果hosts與本地DNS服務器緩存都沒有相應的網址映射關係，首先會找TCP/IP參數中設置的首選DNS服務器。
d.如果要查詢的域名，不是由本地DNS服務器區域解析，但是該DNS服務器已經緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析。
e.本地DNS就把請求發送到13臺根DNS,根DNS服務器收到請求後會判斷這個域名（.com）是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到這個IP信息後，將會練習負責.com域的這臺服務器。
f.如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析。
5.瀏覽器訪問一個url所經歷的過程
