網絡分層：
- 應用層
- 傳輸層
- 網絡層
- 數據鏈路層
- 物理層
物理層：
比特流在節點之間的傳輸，是計算機連接起來的物理手段。
數據鏈路層：
控制網絡層和物理層之間的通信，功能是在不可靠的物理線路上進行數據可靠傳輸。
網絡層：
兩台主機上應用程序端到端的通信。
兩個協議：
TCP 傳輸控制協議，可靠。
UDP 用戶數據報協議，不可靠，無連接的協議。
傳輸層：
Http、FTP、Telnet、SMTP、POP3
TCP的三次握手與四次揮手
三次握手流程：
-
第一次握手：建立連接。客戶端發送連接請求報文段，將 SYN 設置為 1、Sequence Number（seq）為 x；接下來客戶端進入SYN_SENT狀態，等待服務端的確認。
-
第二次握手：服務器收到客戶端的 SYN 報文段，對 SYN 報文段進行確認，設置Acknowledgment Number（ACK）為 x+1（seq+1）；同時自己還要發送 SYN 請求信息，將SYN設置為1、seq為y。服務端將 上述所有信息放到SYN+ACK報文段中，一並發送給客戶端，此時服務端進入SYN_RCVD狀態。
-
第三次握手：客戶端收到服務端的SYN+ACK報文段；然后將ACK設置為y+1，向服務端發送ACK報 文段，這個報文段發送完畢后，客戶端和服務端都進入ESTABLISHED （TCP連接成功）狀態，完成TCP的 三次握手。
四次揮手過程：
- 第一次揮手：客戶端設置seq和ACK，向服務端發送一個FIN報文段。此時，客戶端進入FIN_WAIT_1 狀態，表示客戶端沒有數據要發送給服務端了。
- 第二次揮手：服務端收到了客戶端發送的FIN報文段，向客戶端回了一個ACK報文段。
- 第三次揮手：服務端向客戶端發送 FIN 報文段，請求關閉連接，同時服務端進入LAST_ACK狀態。
- 第四次揮手：客戶端收到服務端發送的FIN報文段，向服務端發送ACK報文段，然后客戶端進入 TIME_WAIT狀態。服務端收到客戶端的ACK報文段以后，就關閉連接。此時，客戶端等待2MSL（最大報 文段生存時間）后依然沒有收到回復，則說明服務端已正常關閉，這樣客戶端也可以關閉連接了。
Http協議原理
Http協議特點：
- 支持CS模式
- 簡單快速
- 靈活
- 無狀態
格式：
http://host[＂:＂port][abs_path]
http://主機域名或者IP地址[＂:＂端口號][請求資源的URI]
Http請求報文：
請求行由請求方法、URL字段和HTTP協議的版本組成，格式如下：
Method Request-URI HTTP-Version CRLF
其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議 版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。
HTTP請求方法有8種，分別是GET、POST、HEAD、PUT、DELETE、TRACE、CONNECT、 OPTIONS。對於移動開發最常用的就是GET和POST了。
- GET：請求獲取Request-URI所標識的資源。
- POST：在Request-URI所標識的資源后附加新的數據。
- HEAD：請求獲取由Request-URI所標識的資源的響應消息報頭。
- PUT：請求服務器存儲一個資源，並用Request-URI作為其標識。
- DELETE：請求服務器刪除Request-URI所標識的資源。
- TRACE：請求服務器回送收到的請求信息，主要用於測試或診斷。
- CONNECT：HTTP 1.1協議中預留給能夠將連接改為管道方式的代理服務器。
- OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項和需求。
請求報頭
在請求行之后會有0個或者多個請求報頭，每個請求報頭都包含一個名字和一個值，它們之間用英文冒 號“：”分割。
請求數據
請求數據不在GET方法中使用，而在POST方法中使用。POST方法適用於需要客戶填寫表單的場合， 與請求數據相關的最常用的請求報頭是Content-Type和Content-Length。
Http響應報文：
HTTP 的響應報文由狀態行、響應報頭、空行、響應正文組成。
狀態行格式如下所示： HTTP-Version Status-Code Reason-Phrase CRLF 其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態碼；ReasonPhrase表示狀態碼的文本描述。
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發送附帶條件的請求時，條件不滿足時返回，與重定向無關
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器無法識別
401：請求需要認證
403：請求的對應資源禁止被訪問
404：服務器無法找到對應資源
500：服務器內部錯誤
503：服務器正忙
http消息報頭：
消息報頭分為通用報頭、請求報頭、響應報頭、實體報頭等。消息報頭由鍵值對組成，每行一對，關 鍵字和值用英文冒號“：”分隔。
消息報頭分為通用報頭、請求報頭、響應報頭、實體報頭等。消息報頭由鍵值對組成，每行一對，關
鍵字和值用英文冒號“：”分隔。
1.通用報頭
它既可以出現在請求報頭，也可以出現在響應報頭中，如下所示。
• Date：表示消息產生的日期和時間。
• Connection：允許發送指定連接的選項。例如指定連接是連續的；或者指定“close”選項，通知服務
器，在響應完成后，關閉連接。
• Cache-Control：用於指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出
現），且是獨立的（一個消息的緩存指令不會影響另一個消息處理的緩存機制）。
2.請求報頭
請求報頭通知服務器關於客戶端請求的信息。典型的請求報頭如下所示。
• Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。
• User-Agent：發送請求的瀏覽器類型、操作系統等信息。
• Accept：客戶端可識別的內容類型列表，用於指定客戶端接收哪些類型的信息。
• Accept-Encoding：客戶端可識別的數據編碼。
• Accept-Language：表示瀏覽器所支持的語言類型。
• Connection：允許客戶端和服務器指定與請求/響應連接有關的選項。例如，這時為Keep-Alive則表示
保持連接。
• Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式。
3.響應報頭
用於服務器傳遞自身信息的響應。常見的響應報頭如下所示。
• Location：用於重定向接收者到一個新的位置，常用在更換域名的時候。
• Server：包含服務器用來處理請求的系統信息，與User-Agent請求報頭是相對應的。
4.實體報頭
實體報頭用來定義被傳送資源的信息，其既可用於請求也可用於響應。請求和響應消息都可以傳送一
個實體。常見的實體報頭如下所示。
• Content-Type：發送給接收者的實體正文的媒體類型。
• Content-Lenght：實體正文的長度。
• Content-Language：描述資源所用的自然語言。
• Content-Encoding：實體報頭被用作媒體類型的修飾符。它的值指示了已經被應用到實體正文的附加
內容的編碼，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應的解碼機制。
• Last-Modified：實體報頭用於指示資源的最后修改日期和時間。
• Expires：實體報頭給出響應過期的日期和時間。