OSI七層
1.物理層：物理層的作用就是通過物理手段把電腦連接起來，它主要規定了網絡的一些電氣特性，作用是負責傳送0和1的電信號。
2.數據鏈路層：物理層就是傳輸電路的0和1信號的，但是單純的0和1沒有意義，必須規定解讀方式：多少個0和1算一組？每個信號有什麼意義？
——這就是鏈路層的意義，它在物理層的上方，確定了0和1的分組方式。
以太網協議：“以太網”規定，一組電信號構成一個數據包，叫做“幀（Frame）”；每一幀分成兩個個部分：標頭（Head）和數據（Data）。
MAC地址：以太網規定，連入網絡的所有設備，都必須具有“網卡”接口。數據包必須是從一塊網卡，傳送到另一塊網卡，網卡的地址，就是數據包的發送地址和接受地址，也叫MAC地址。
注意：內網也就是局域網，只需經過物理層和數據鏈路層就可以完成網絡通信，無需經過網絡層等已上層。
3.網絡層：網絡層的出現，他的作用是引入一套新的地址，使我們能夠區分哪些計算機屬於同一個子網，這個套機制就叫做“網絡地址”，也就是“IP地址”。
4.傳輸層:“傳輸層”的功能，就是建立“端口到端口”之間的通信。相比之下，“網絡層”的功能是建立“主機到主機"的通信。
5.會話層:會話層建立、管理、終止會話。（在五層模型裏面已經合併到了應用層）對應主機進程，指本地主機與遠程主機正在進行的會話
6.表示層:數據的表示、安全、壓縮。（在五層模型裏面已經合併到了應用層）格式有，JPEG、ASCll、DECOIC、加密格式等
7.應用層:網絡服務與最終用戶的一個接口。協議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
@see 計算機網絡漫談：OSI七層模型與TCP/IP四層（參考）模型 https://www.jianshu.com/p/c793a279f698
TCP/IP四層
TCP/IP四層：TCP/IP參考模型分爲四個層次：應用層、傳輸層、網絡互連層和主機到網絡層。
1、主機到網絡層
實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。由於這一層次未被定義，所以其具體的實現方法將隨着網絡類型的不同而不同。
2、網絡互連層
網絡互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，爲了儘快地發送分組，可能需要沿不同的路徑同時進行分組傳遞。
因此，分組到達的順序和發送的順序可能不同，這就需要上層必須對分組進行排序。
3、傳輸層
在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。
即：傳輸控制協議TCP（transmission control protocol）和用戶數據報協議UDP（user datagram protocol）。
4、應用層
TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。"應用層"的作用，就是規定應用程序的數據格式。
@see TCP/IP四層模型 http://www.cnblogs.com/BlueTzar/articles/811160.html
網路協議的意義
因特網無疑是人類有史以來最偉大的設計，它互聯了全球數億臺計算機、通訊設備，即便位於地球兩端的用戶也可在頃刻間完成通訊。
可以說『協議』是支撐這麼一個龐大而複雜的系統有條不紊運作的核心，而所謂『協議』就是通訊雙方所必須遵守的規則，在這種規則下，不同的數據報可能被解析爲不同的響應動作。
簡而言之，『協議』就是指如果發送和接收方按照這個規則進行數據報文的發送，即可在基本的數據傳輸之上得到某些特殊的功能或服務，否則你的數據別人是不認識的。例如：遵循 TCP 協議的兩端，可以在不可靠的網絡傳輸中得到可靠的數據傳輸能力。
網路通信的過程
應用層的職責
『應用層』算是距離用戶最近的一層了，主機上的一個個的進程就構成了『應用層』。比如你在你的瀏覽器地址欄輸入了 「www.baidu.com」，你的瀏覽器在應用層會做哪些事情呢？
首先瀏覽器會使用 DNS 協議返回域名「www.baidu.com」所對應的 IP 地址，關於 DNS 我們待會詳細介紹。
接着，應用層決定創建一個『TCP 套接字』，然後將這個請求動作封裝成一個 Http 數據報並推入套接字中。
套接字分爲兩種類型，『TCP 套接字』和『UDP 套接字』，應用層同時可能會有幾十個數據報的發出，而運輸層也會收到所有的響應報文，那麼它該如何區分這些報文到底是誰的響應報文呢？
而套接字就是用於區分各個應用層應用的，往往由端口號和 IP 地址進行標識，運輸層只要查看響應報文的源端口號和 IP 地址就能夠知道該將報文推送給哪個套接字了。
當一個應用層數據報被推動進套接字之後，應用層的所有工作也算是全部完成了，關於後續報文的去向，它已經不用管了。
TCP 和UDP 的本質區別
『TCP 套接字』和『UDP 套接字』兩者本質上的區別在於，前者保證數據報可靠地到達目的地，但是必然耗時，而後者不保證數據報一定能到達目的地，但是速度快，這也是應用層協議在選擇運輸層協議的時候需要考慮的一點。
DNS 原理
首先明確一點的是，DNS 是一個應用層協議，並且它選擇的運輸層協議是 UDP，所以你的域名解析過程一般會很快，但也會經常出現解析失敗的情況，然而刷新一下又好了。
具體原理請參考： 完整的一次 HTTP 請求響應過程（一）https://juejin.im/post/5b10be81518825139e0d8160
問題思考：
HTTP有哪些method
HTTP Method的歷史：
HTTP 0.9 這個版本只有GET方法
HTTP 1.0 這個版本有GET HEAD POST這三個方法
HTTP 1.1 這個版本是當前版本，包含GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT這8個方法
get:客戶端向服務端發起請求，獲得資源。請求獲得URL處所在的資源。
post:向服務端提交新的請求字段。請求URL的資源後添加新的數據。
head:請求獲取URL資源的響應報告，即獲得URL資源的頭部
patch：請求局部修改URL所在資源的數據項
put：請求修改URL所在資源的數據元素。
delete：請求刪除url資源的數據
HTTPS和HTTP的區別
https協議需要到CA申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協 議。
http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
http默認使用80端口，https默認使用443端口
冪等
一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函數，或冪等方法，是指可以使用相同參數重複執行，並能獲得相同結果的函數。這些函數不會影響系統狀態，也不用擔心重複執行會對系統造成改變。例如，“getUsername()和setTrue()”函數就是一個冪等函數.
傳輸層的職責
總述：運輸層的任務就是從應用層的各個進程的套接字那取回來所有需要發送的數據，然後選擇 TCP 或者 UDP 將數據封裝並推給下面的網絡層待發送。
tcp三次握手
第一步：
客戶端向服務端發送一份特殊的 TCP 報文，該報文並不包含應用層的數據，是一份特殊的報文，它的 TCP 首部中 SYN 字段值爲 1 （參見上述報文格式）。
除此之外，客戶端還會隨機生成一個初始序號，填在報文的「序號」字段，代表當前報文的序號是這個，並且我後續的分組會基於這個序號遞增。
然後該報文將會經網絡層、鏈路層、物理層發送到服務端。
第二步：
如果分組丟失了，那麼客戶端會經過某個時間間隔再次嘗試發送。
而如果分組準確的到達服務端了，服務端拆開 TCP 首部會看到，這是一個特殊的 SYN 握手報文，於是爲此次連接分配緩存等資源。
接着服務端開始構建響應報文，SYN 是一個用於同步需要的字段，響應報文中依然會被置爲 1，並且服務端也將隨機生成一個初始序號放置的響應報文的序號字段中。
最後，服務端還會爲響應報文中的確認字段賦值，這個值就是客戶端發過來的那個序號值加一。
整體上的意思就是說，「我同意你的連接請求，我的初始序號爲 xxx，你的初始序號我收到了，我等着你的下一個分組到來」
第三步：
客戶端收到服務端的響應報文，於是分配客戶端 TCP 連接所必須的緩存等資源，於是連接已經建立。
實際上從第三步開始，客戶端就可以攜帶應用層數據向服務端交換報文了，以後的每份報文中，SYN 都爲 0，因爲它只是用於同步初始序號的，這一點需要明確。
思考
1.TCP爲什麼是三次握手，爲什麼不是兩次或者四次
如果兩次，那麼B無法確定B的信息A是否能收到，所以如果B先說話，可能後面的A都收不到，會出現問題 。
如果四次，那麼就造成了浪費，因爲在三次結束之後，就已經可以保證A可以給B發信息，A可以收到B的信息； B可以給A發信息，B可以收到A的信息。
@see TCP爲什麼是三次握手，爲什麼不是兩次或者四次 && TCP四次揮手 https://www.cnblogs.com/zhuzhenwei918/p/7465467.html
tcp四次揮手
整體流程：
因爲一條 TCP 連接會消耗大量的主機資源，不僅僅服務端需要分配各種緩存資源，客戶端也同樣需要分配相應資源。因爲 TCP 是『全雙工通信』，服務端和客戶端兩方其實是一樣的，誰是客戶誰是服務器是相對的。
強調這一點是爲了說明，一條 TCP 連接不是隻有客戶端才能斷開，服務端也同樣可以主動斷開連接，這一點需要清楚。
我們這裏假設客戶端主動發起斷開連接的請求爲例：
第一步：
客戶端構建一份特殊的 TCP 報文，該報文首部字段 FIN 被置爲 1，然後發送該報文。
第二步：
服務端收到該特殊的 FIN 報文，於是響應客戶端一個 ACK 報文，告訴客戶端，請求關閉的報文已經收到，我正在處理。
第三步：
服務端發送一個 FIN 報文，告訴客戶端，我將要關閉連接了。
第四步：
客戶端返回一個 ACK 響應報文，告訴服務端，我收到你剛纔發的報文了，我已經確認，你可以關閉連接了。
當服務端收到客戶端發送的 ACK 響應報文時，將釋放服務端用於該 TCP 連接的所有資源，與此同時，客戶端也會定時等待一定時間後完全釋放自己用於該連接的相關資源。
具體細節：
首先，客戶端發送一個特殊分組，該分組的序號爲 u。發送完成之後，客戶端進入 FIN-WAIT-1 這個狀態，這個狀態下，該 TCP 連接的客戶端不再能發送數據報，但是是可以接受數據報的，它等待着服務端的響應報文。
接着，服務端收到客戶端發送的終止連接報文請求，服務端構建響應報文，告訴客戶端「序號 u+1 以前的分組我都收到了」，並且進入 CLOSE-WAIT 狀態，這個狀態持續時間很短。
服務端會緊接着發送它的 FIN 數據報，通知客戶端我服務端即將關閉連接，並隨即進入 LAST_ACK 狀態等待客戶端響應報文。
一旦客戶端收到這個 FIN 報文，將返回確認報文並進入 TIME-WAIT 狀態，等待 2MSL 時間間隔後完全釋放客戶端 TCP 連接所佔用資源。
與此同時，當服務端收到客戶端最後的確認報文，就將直接斷開服務端連接並釋放相關資源。
常用狀態
常用的三個狀態是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。
TIME_WAIT
TIME_WAIT 是主動關閉鏈接時形成的，等待2MSL時間，約4分鐘。主要是防止最後一個ACK丟失。
CLOSE_WAIT
CLOSE_WAIT是被動關閉連接是形成的。根據TCP狀態機，服務器端收到客戶端發送的FIN，則按照TCP實現發送ACK，因此進入CLOSE_WAIT狀態。但如果服務器端不執行close()，就不能由CLOSE_WAIT遷移到LAST_ACK，則系統中會存在很多CLOSE_WAIT狀態的連接。此時，可能是系統忙於處理讀、寫操作，而未將已收到FIN的連接，進行close。此時，recv/read已收到FIN的連接socket，會返回0。
至於爲什麼最後客戶端需要等 2MSL 時間長度再完全釋放 TCP 相關資源呢？
那是因爲 2MSL 是一份報文存在於網絡中最長的時間，超過該時間到達的報文都將被丟棄，而如果客戶端最後的確認報文於網絡中丟失的話，服務端必將發起超時請求，重新發送第三次揮手動作，此時等待中的客戶端就可隨即重新發送一份確認請求。
這是爲什麼客戶端等待一個最長報文傳輸時間的原因。有人可能好奇爲什麼前面的各次請求都沒有做超時等待而只最後一次數據發送做了超時等待？
其實原因很簡單，相信你也能想到，就是 TCP 自帶計時能力，超過一定時間沒有收到某個報文的確認報文，會自動重新發送，而這裏如果不做等待而直接關閉連接，那麼我如何知道服務端到底收到沒我的確認報文呢。
通過等待一個最長週期，如果這個週期內沒有收到服務端的報文請求，那麼我們的確認報文必然是到達了服務端了的，否則重複發送一次即可。
經典問題
1.當你在瀏覽器地址欄輸入一個URL後回車，將會發生的事情？
整體流程：
域名解析 --> 發起TCP的3次握手 --> 建立TCP連接後發起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶
其他參考：
- 首先嘛，你得在瀏覽器裏輸入要網址:
- 瀏覽器查找域名的IP地址
- 瀏覽器給web服務器發送一個HTTP請求
- facebook服務的永久重定向響應
- 瀏覽器跟蹤重定向地址
- 服務器“處理”請求
- 服務器發回一個HTML響應
- 瀏覽器開始顯示HTML
- 瀏覽器發送獲取嵌入在HTML中的對象
- 瀏覽器發送異步（AJAX）請求
1）這裏着重理解下爲何服務要進行永久重定向響應
1.跟搜索引擎排名有關：如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認爲它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
2.不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存裏出現好幾次。即浪費存儲空間。
@see 當你在瀏覽器地址欄輸入一個URL後回車，將會發生的事情？https://www.jianshu.com/p/c83efcdb97c2
2.http狀態碼
201-206都表示服務器成功處理了請求的狀態代碼，說明網頁可以正常訪問。
200 -請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
300-307表示的意思是：要完成請求，您需要進一步進行操作。通常，這些狀態代碼是永遠重定向的。
300（多種選擇） 服務器根據請求可執行多種操作。服務器可根據請求者 來選擇一項操作，或提供操作列表供其選擇。
301（永久移動） 請求的網頁已被永久移動到新位置。服務器返回此響應時，會自動將請求者轉到新位置。您應使用此代碼通知搜索引擎蜘蛛網頁或網站已被永久移動到新位置。
302（臨時移動） 服務器目前正從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。會自動將請求者轉到不同的位置。但由於搜索引擎會繼續抓取原有位置並將其編入索引，因此您不應使用此代碼來告訴搜索引擎頁面或網站已被移動。
303（查看其他位置） 當請求者應對不同的位置進行單獨的 GET 請求以檢索響應時，服務器會返回此代碼。對於除 HEAD 請求之外的所有請求，服務器會自動轉到其他位置。
304（未修改） 自從上次請求後，請求的網頁未被修改過。服務器返回此響應時，不會返回網頁內容。
如果網頁自請求者上次請求後再也沒有更改過，您應當將服務器配置爲返回此響應。由於服務器可以告訴 搜索引擎自從上次抓取後網頁沒有更改過，因此可節省帶寬和開銷。
305（使用代理） 請求者只能使用代理訪問請求的網頁。如果服務器返回此響應，那麼，服務器還會指明請求者應當使用的代理。
307（臨時重定向） 服務器目前正從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。會自動將請求者轉到不同的位置。但由於搜索引擎會繼續抓取原有位置並將其編入索引，因此您不應使用此代碼來告訴搜索引擎某個頁面或網站已被移動。
4xx（請求錯誤）這些狀態碼錶示請求可能出錯，妨礙了服務器的處理。
400 - 錯誤的請求。 服務器不理解請求的語法。
401 -（未授權）請求要求身份驗證。對於登錄後請求的網頁，服務器可能返回此響應。
403 -對不起，您沒有權限請求此連接！
404 - 未找到。 ·404.0 -（無） – 沒有找到文件或目錄
405 - 用來訪問本頁面的 HTTP 謂詞不被允許（方法不被允許）如設置了get請求而卻用了post
5xx（服務器錯誤） 這些狀態碼錶示服務器在處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
500（服務器內部錯誤） 服務器遇到錯誤，無法完成請求。
@see http statusCode(狀態碼) 200、300、400、500序列 https://www.douban.com/note/218418718/
3.HTTP1.0和HTTP1.1的區別
1、HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理
HTTP 1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理後立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。
HTTP 1.1則支持持久連接Persistent Connection, 並且默認使用persistent connection. 在同一個tcp的連接中可以傳送多個HTTP請求和響應. 多個請求和響應可以重疊，多個請求和響應可以同時進行. 更加多的請求頭和響應頭(比如HTTP1.0沒有host的字段).
在1.0時的會話方式：
1. 建立連接
2. 發出請求信息
3. 回送響應信息
4. 關掉連接
HTTP 1.1的持續連接，也需要增加新的請求頭來幫助實現，例如，Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持連接；Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉連接。HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。
請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。例如：一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。 HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先後順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容。
2.HTTP 1.1增加host字段
在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。
HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。此外，服務器應該接受以絕對路徑標記的資源請求。
3、100(Continue) Status(節約帶寬)
HTTP/1.1加入了一個新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，如果服務器因爲權限拒絕了請求，就回送響應碼401（Unauthorized）；如果服務器接收此請求就回送響應碼100，客戶端就可以繼續發送帶實體的完整請求了。100 (Continue) 狀態代碼的使用，允許客戶端在發request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發request body。
4、HTTP/1.1中引入了Chunked transfer-coding來解決上面這個問題，發送方將消息分割成若干個任意大小的數據塊，每個數據塊在發送時都會附上塊的長度，最後用一個零長度的塊作爲消息結束的標誌。這種方法允許發送方只緩衝消息的一個片段，避免緩衝整個消息帶來的過載。
5、HTTP/1.1在1.0的基礎上加入了一些cache的新特性，當緩存對象的Age超過Expire時變爲stale對象，cache不需要直接拋棄stale對象，而是與源服務器進行重新激活（revalidation）。
HTTP協議與TCP/IP協議的關係
HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。 IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠地傳遞數據包，使得網絡上接收端收到發送端所發出的所有包，並且順序與發送順序一致。TCP協議是可靠的、面向連接的。
什麼是長連接、短連接
在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協議的長連接和短連接。
參考資料：
1.完整的一次 HTTP 請求響應過程（一） https://juejin.im/post/5b10be81518825139e0d8160
2.完整的一次 HTTP 請求響應過程（二）https://juejin.im/post/5b152061e51d4506a269a34f
3.http statusCode(狀態碼) 200、300、400、500序列 https://www.douban.com/note/218418718/
4.計算機網絡漫談：OSI七層模型與TCP/IP四層（參考）模型 https://www.jianshu.com/p/c793a279f698
5.TCP/IP四層模型 http://www.cnblogs.com/BlueTzar/articles/811160.html
