寫在開頭
第一次覺得android需要學的東西太多了。網絡知識必不可少也。一點一點總結學習。
HTTP/HTTPS學習總結鏈接： android開發之網絡學習-http/https ，歡迎大家的補充，共同學習與進步。
Socket學習總結總結鏈接： android開發之網絡學習-Socket學習 ，歡迎大家的補充，共同學習與進步。
TCP/IP模型
TCP/IP協議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構成互聯網基礎的網絡協議，是Internet的核心協議。
基於TCP/IP的參考模型將協議分成四個層次，它們分別是數據鏈路層、網絡層、傳輸層和應用層。
基於OSI的參考模型將協議分成七個層次，它們分別是物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。（瞭解就好）
TCP/IP協議族按層次由上到下，層層將數據進行包裝。
第一層是應用層，這裏面有http，https，ftp等等我們熟悉的協議。
第二層是傳輸層，著名的TCP（準確性）和UDP（實效性）協議就在這個層次。
第三層是網絡層，IP協議就在這裏，它負責對數據加上IP地址和其他的數據來確定傳輸的目標。
第四層是數據鏈路層，這個層次爲待傳送的數據加入一個以太網協議頭，並進行CRC編碼（循環冗餘碼校驗英文名稱爲Cyclical Redundancy Check，主要用於錯誤偵測（Error Detecting）URL：http://blog.sina.com.cn/s/blog_7880d3350101gbxj.html，可稍微瞭解下），爲最後的數據傳輸做準備。
圖片詳解了TCP/IP協議中每個層的作用，而TCP/IP協議通信的過程其實就對應着數據入棧與出棧的過程。入棧的過程，數據發送方每層不斷地封裝首部與尾部，添加一些傳輸的信息，確保能傳輸到目的地。出棧的過程，數據接收方每層不斷地拆除首部與尾部，得到最終傳輸的數據。
應用層
我們大部分開發者的工作在應用層開發，對於其http，https等協議會在下一個文章中進行總結。
傳輸層（也就是TCP/IP）
TCP/UDP都是傳輸層協議，但是兩者具有不同的特性，同時也具有不同的應用場景。
TCP應用：
當對網絡通訊質量有要求的時候，比如：整個數據要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。
UDP應用：
當對網絡通訊質量要求不高的時候，要求網絡通訊速度能儘量的快，這時就可以使用UDP。比如直播類，DNS域名轉換（DNS（Domain Name System，域名系統），因特網上作爲域名和IP地址相互映射的一個分佈式數據庫，能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。DNS協議運行在UDP協議之上，使用端口號53。）等。
TCP連接的建立與終止
三次握手（連接）
TCP是面向連接的，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一條連接。在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號並交換 TCP窗口大小信息。
第一次握手：建立連接。客戶端發送連接請求報文段，將SYN位置爲1，Sequence Number爲x；然後，客戶端進入SYN_SEND狀態，等待服務器的確認；
第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，自己自己還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK報文段。然後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢以後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。
三次握手的必要性
爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
具體例子：“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。”
四次揮手（斷開）
當客戶端和服務器通過三次握手建立了TCP連接以後，當數據傳送完畢，肯定是要斷開TCP連接的啊。那對於TCP的斷開連接，這裏就有了神祕的“四次分手”。
第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
第三次分手：主機2向主機1發送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態；
第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連接；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。
四次分手的重要性
TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。
爲什麼要等待2MSL
MSL：報文段最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間。
原因有二：
保證TCP協議的全雙工連接能夠可靠關閉
保證這次連接的重複數據段從網絡中消失
第一點：如果主機1直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網絡原因，導致主機2沒有收到主機1最後回覆的ACK。那麼主機2就會在超時之後繼續發送FIN，此時由於主機1已經CLOSED了，就找不到與重發的FIN對應的連接。所以，主機1不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正確的關閉連接。
第二點：如果主機1直接CLOSED，然後又再向主機2發起一個新連接，我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連接和已經關閉的老連接端口號是一樣的，如果前一次連接的某些數據仍然滯留在網絡中，這些延遲數據在建立新連接之後纔到達主機2，由於新連接和老連接的端口號是一樣的，TCP協議就認爲那個延遲的數據是屬於新連接的，這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連接的所有數據都從網絡中消失。
TCP流量控制
如果發送方把數據發送得過快，接收方可能會來不及接收，這就會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。
設A向B發送數據。在連接建立時，B告訴了A：“我的接收窗口是 rwnd = 400 ”(這裏的 rwnd 表示 receiver window) 。因此，發送方的發送窗口不能超過接收方給出的接收窗口的數值。請注意，TCP的窗口單位是字節，不是報文段。假設每一個報文段爲100字節長，而數據報文段序號的初始值設爲1。大寫ACK表示首部中的確認位ACK，小寫ack表示確認字段的值ack。
從圖中可以看出，B進行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值爲止。B向A發送的三個報文段都設置了 ACK = 1 ，只有在ACK=1時確認號字段纔有意義。
TCP擁塞控制
簡單介紹：發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞窗口。
發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡中的分組數。
慢開始和擁塞避免
慢開始算法
當主機開始發送數據時，如果立即所大量數據字節注入到網絡，那麼就有可能引起網絡擁塞，因爲現在並不清楚網絡的負荷情況。
因此，較好的方法是 先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。
通常在剛剛開始發送報文段時，先把擁塞窗口 cwnd 設置爲一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞窗口增加至多一倍MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口 cwnd ，可以使分組注入到網絡的速率更加合理。（如圖）
一個傳輸輪次所經歷的時間其實就是往返時間RTT。
不過“傳輸輪次”更加強調：把擁塞窗口cwnd所允許發送的報文段都連續發送出去，並收到了對已發送的最後一個字節的確認。
另，慢開始的“慢”並不是指cwnd的增長速率慢，而是指在TCP開始發送報文段時先設置cwnd=1，使得發送方在開始時只發送一個報文段（目的是試探一下網絡的擁塞情況），然後再逐漸增大cwnd。
爲了防止擁塞窗口cwnd增長過大引起網絡擁塞，還需要設置一個慢開始門限ssthresh狀態變量。慢開始門限ssthresh的用法如下：
當 cwnd < ssthresh 時，使用上述的慢開始算法。
當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。
當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞控制避免算法。
擁塞避免算法
讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。
無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置爲出現擁塞時的發送 方窗口值的一半（但不能小於2）。然後把擁塞窗口cwnd重新設置爲1，執行慢開始算法。
這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生 擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
如下圖，用具體數值說明了上述擁塞控制的過程。現在發送窗口的大小和擁塞窗口一樣大。
快重傳和快恢復
快重傳
快重傳算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時才進行捎帶確認。
接收方收到了M1和M2後都分別發出了確認。現在假定接收方沒有收到M3但接着收到了M4。
顯然，接收方不能確認M4，因爲M4是收到的失序報文段。根據 可靠傳輸原理，接收方可以什麼都不做，也可以在適當時機發送一次對M2的確認。
但按照快重傳算法的規定，接收方應及時發送對M2的重複確認，這樣做可以讓 發送方及早知道報文段M3沒有到達接收方。發送方接着發送了M5和M6。接收方收到這兩個報文後，也還要再次發出對M2的重複確認。這樣，發送方共收到了 接收方的四個對M2的確認，其中後三個都是重複確認。
快重傳算法還規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段M3，而不必 繼續等待M3設置的重傳計時器到期。
由於發送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網絡吞吐量（網絡中的數據是由一個個數據包組成，防火牆對每個數據包的處理要耗費資源。吞吐量是指在沒有幀丟失的情況下，設備能夠接受的最大速率。）提高約20%。
快恢復
與快重傳配合使用的還有快恢復算法，其過程有以下兩個要點：
當發送方連續收到三個重複確認，就執行“乘法減小”算法，把慢開始門限ssthresh減半。
與慢開始不同之處是現在不執行慢開始算法（即擁塞窗口cwnd現在不設置爲1），而是把cwnd值設置爲 慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。
網絡層（此層傳輸的是數據報文）
IP協議（是這一層最重要的一個協議，也是我們的要重視的）
IP協議是TCP/IP協議的核心，所有的TCP，UDP，IMCP，IGCP的數據都以IP數據格式傳輸。但是IP不是可靠的協議，IP協議並沒有提供一種數據未傳達以後的處理機制，所以他的可靠性是被認爲是TCP或UDP（也就是傳輸層）要做的事情。
IP地址
在數據鏈路層中我們一般通過MAC地址來識別不同的節點，而在IP層我們也要有一個類似的地址標識，這就是IP地址。
32位IP地址（IPV4）分爲網絡位和地址位，這樣做可以減少路由器中路由表記錄的數目，有了網絡地址，就可以限定擁有相同網絡地址的終端都在同一個範圍內，那麼路由表只需要維護一條這個網絡地址的方向，就可以找到相應的這些終端了。(目前IPV6越來越普及，128IP地址)
A類IP地址: 1.0.0.0~127.0.0.0
B類IP地址:128.0.0.0~191.255.255.255
C類IP地址:192.0.0.0~223.255.255.255
ARP及RARP協議（要了解，地址解析協議）
ARP 是根據IP地址獲取MAC地址的一種協議。
ARP（地址解析）協議是一種解析協議，本來主機是完全不知道這個IP對應的是哪個主機的哪個接口，當主機要發送一個IP包的時候，會首先查一下自己的ARP高速緩存（就是一個IP-MAC地址對應表緩存）。
如果查詢的IP－MAC值對不存在，那麼主機就向網絡發送一個ARP協議廣播包，這個廣播包裏面就有待查詢的IP地址，而直接收到這份廣播的包的所有主機都會查詢自己的IP地址，如果收到廣播包的某一個主機發現自己符合條件，那麼就準備好一個包含自己的MAC地址的ARP包傳送給發送ARP廣播的主機。
而廣播主機拿到ARP包後會更新自己的ARP緩存（就是存放IP-MAC對應表的地方）。發送廣播的主機就會用新的ARP緩存數據準備好數據鏈路層的的數據包發送工作。
RARP協議的工作與此相反，不做贅述。
ICMP協議（保證可靠性協議）
IP協議並不是一個可靠的協議，它不保證數據被送達，那麼，自然的，保證數據送達的工作應該由其他的模塊來完成。其中一個重要的模塊就是ICMP(網絡控制報文)協議。ICMP不是高層協議，而是IP層的協議。
當傳送IP數據包發生錯誤。比如主機不可達，路由不可達等等，ICMP協議將會把錯誤信息封包，然後傳送回給主機。給主機一個處理錯誤的機會，這 也就是爲什麼說建立在IP層以上的協議是可能做到安全的原因。
PING（確定網絡是否連接）
ping可以說是ICMP的最著名的應用，是TCP/IP協議的一部分。利用“ping”命令可以檢查網絡是否連通，可以很好地幫助我們分析和判定網絡故障。
Traceroute（網絡在哪一環斷開）
Traceroute是用來偵測主機到目的主機之間所經路由情況的重要工具，也是最便利的工具。
Traceroute的原理：它收到到目的主機的IP後，首先給目的主機發送一個TTL=1的UDP數據包，而經過的第一個路由器收到這個數據包以後，就自動把TTL減1，而TTL變爲0以後，路由器就把這個包給拋棄了，並同時產生 一個主機不可達的ICMP數據報給主機。主機收到這個數據報以後再發一個TTL=2的UDP數據報給目的主機，然後刺激第二個路由器給主機發ICMP數據 報。如此往復直到到達目的主機。這樣，traceroute就拿到了所有的路由器IP。
數據鏈路層（此層傳輸的是幀數據）
物理層負責0、1比特流與物理設備電壓高低、光的閃滅之間的互換。 數據鏈路層負責將0、1序列劃分爲數據幀從一個節點傳輸到臨近的另一個節點,這些節點是通過MAC來唯一標識的(MAC,物理地址，一個主機會有一個MAC地址)。
封裝成幀: 把網絡層數據報加頭和尾，封裝成幀,幀頭中包括源MAC地址和目的MAC地址。
透明傳輸:零比特填充、轉義字符。
可靠傳輸: 在出錯率很低的鏈路上很少用，但是無線鏈路WLAN會保證可靠傳輸。
差錯檢測(CRC):接收者檢測錯誤,如果發現差錯，丟棄該幀。
寫在後面
大部分都是其他大神的總結，供自己和他人學習。謝謝各位前輩了！