工作了才知道：應該懂得這些網絡知識

Http和Https的區別

HTTP（超文本傳輸協議）被用於在Web瀏覽器和網站服務器之間，以明文方式傳遞信息，不提供任何方式的數據加密，因此使用HTTP協議傳輸隱私信息（如：銀行卡號、密碼等支付信息）非常不安全。
在HTTP的基礎上加入了SSL（Secure Sockets Layer）協議，SSL依靠SSL證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通信加密。從而誕生了HTTPS（安全套接字層超文本傳輸協議）。
簡單來說，HTTPS協議="SSL+HTTP協議"構建的可進行加密傳輸、身份認證的網絡協議，是HTTP的安全版。
HTTPS和HTTP的區別主要如下：

工作層：在OSI網絡模型中，HTTP工作於應用層，而HTTPS工作在傳輸層。
連接端口：HTTP標準端口是80，而HTTPS的標準端口是443。
傳輸方式：HTTP是超文本傳輸協議，信息是明文傳輸，而HTTPS是SSL加密傳輸協議。
工作耗時：HTTP耗時=TCP握手，而HTTPS耗時=TCP握手+SSL握手。
顯示形式：HTTP的URL以http://開頭，而HTTPS的URL以https://開頭。
費用：HTTP無需費用，而HTTPS需要到CA申請證書，一般免費證書較少，需要一定費用。
安全性：HTTP的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

對稱加密與非對稱加密

對稱加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key）。對稱加密有很多種算法，由於它效率很高，所以被廣泛使用在很多加密協議的核心當中。

對稱加密通常使用的是相對較小的密鑰，一般小於256 bit。因爲密鑰越大，加密越強，但加密與解密的過程越慢。如果你只用1 bit來做這個密鑰，那黑客們可以先試着用0來解密，不行的話就再用1解；但如果你的密鑰有1 MB大，黑客們可能永遠也無法破解，但加密和解密的過程要花費很長的時間。密鑰的大小既要照顧到安全性，也要照顧到效率，是一個trade-off。
非對稱加密爲數據的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key）。私鑰只能由一方安全保管，不能外泄，而公鑰則可以發給任何請求它的人。非對稱加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰。比如，你向銀行請求公鑰，銀行將公鑰發給你，你使用公鑰對消息加密，那麼只有私鑰的持有人–銀行才能對你的消息解密。與對稱加密不同的是，銀行不需要將私鑰通過網絡發送出去，因此安全性大大提高。

三次握手

第一次握手：client組裝一個SYN=1,產生序列號J的數據包，發給server，client進入SYN_SENT狀態，等待server確認
第二次握手：server收到client的數據報，組裝一個序列號爲K，SYN=1,ACK=1,ack=J+1數據包，server進入SYN_RCVD.
第三次握手：client收到數據包之後，檢查SYN是否爲1,ACK是否1,ack是否爲J+1,如果正確，clent發送一個ACK置爲1，ack=K+1的數據包。Server檢查ack是否爲K+1，ACK是否爲1，如果正確則鏈接建立成功。Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

爲什麼TCP客戶端最後還要發送一次確認呢？

主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。

如果使用的是兩次握手建立連接，假設有這樣一種場景，**客戶端發送了第一個請求連接並且沒有丟失，只是因爲在網絡結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，**以爲服務器沒有收到，此時重新向服務器發送這條報文，此後客戶端和服務器經過兩次握手完成連接，傳輸數據，然後關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。

如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於服務器收不到確認，就知道客戶端並沒有請求連接。

四次揮手

數據傳輸完畢後，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處於ESTABLISHED狀態，然後客戶端主動關閉，服務器被動關閉。

客戶端沒有數據發送了，發送釋放鏈接的報文。報文的首部FIN=1,seq=u（上一個報文+1）。這時客戶端進入了FIN-WAIT-1階段
服務器接受到報文，發送應答報文，報文的頭部ACK=1,ack=u+1,seq=v，服務器進入了CLOSE_WAIT階段。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
客戶端收到應答報文之後，進入FIN-WAIT-2階段，等待服務端發送釋放的確認報文。這個階段，客戶端還需要接受服務端發送的數據
等服務器發送完了數據之後，要發確認釋放鏈接的報文，報文的頭部ACK=1,ack=u+1,seq=w，FIN=1,此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
客戶端收到報文之後，發送應答報文，報文頭部ACK=1,ack=w+1,seq=u+1,客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

爲什麼客戶端最後還要等待2MSL？

MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯爲“報文最大生存時間”，他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄
第一，保證客戶端發送的最後一個ACK報文能夠到達服務器，因爲這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，於是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，並且會重啓2MSL計時器。

第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

爲什麼建立連接是三次握手，關閉連接確是四次揮手呢？

建立連接的時候，服務器在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。
而關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。

如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。

TCP協議如何來保證傳輸的可靠性

TCP提供一種面向連接的、可靠的字節流服務。其中，面向連接意味着兩個使用TCP的應用（通常是一個客戶和一個服務器）在彼此交換數據之前必須先建立一個TCP連接。在一個TCP連接中，僅有兩方進行彼此通信；而字節流服務意味着兩個應用程序通過TCP鏈接交換8bit字節構成的字節流。可靠性，tcp通過以下方式保證：
數據校驗：檢測數據在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段並且不給出響應，這時TCP發送數據端超時後會重發數據；
應答機制：當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒；
超時重發：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段；
丟失重複消息：對於重複數據，能夠丟棄重複數據；
對失序數據包重排序：既然TCP報文段作爲IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數據進行重新排序，然後才交給應用層；
流量控制：TCP連接的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端發送接收端緩衝區所能接納的數據，這可以防止較快主機致使較慢主機的緩衝區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

客戶端不斷進行請求鏈接會怎樣？DDos(Distributed Denial of Service)攻擊？

服務器端會爲每個請求創建一個鏈接，並向其發送確認報文，然後等待客戶端進行確認

DDos 攻擊

客戶端向服務端發送請求鏈接數據包
服務端向客戶端發送確認數據包
客戶端不向服務端發送確認數據包，服務器一直等待來自客戶端的確認

DDos 預防

限制同時打開SYN半鏈接的數目
縮短SYN半鏈接的Time out 時間
關閉不必要的服務

Get與POST的區別

功能上，GET是從服務器獲取資源，post是向服務器更新資源
REST上來說，GET是冪數操作，每次從服務器獲取的資源一樣;而post，每次請求改變不一定相同。也就說說GET不會改變服務器資源，post會改變
請求參數上，GET請求參數會放到URL上，即數據放在http報文的請求頭上，以?分割URL和傳輸數據，參數之間以&相連。特別地，如果數據是英文字母/數字，原樣發送；否則，會將其編碼爲 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉換爲+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII)；post請求，直接放到http報文的請求體上。
安全性而言，POST的安全性要比GET的安全性高，因爲GET請求提交的數據將明文出現在URL上，而且POST請求參數則被包裝到請求體中，相對更安全。
大小看，GET請求的長度受限於瀏覽器或服務器對URL長度的限制，允許發送的數據量比較小，而POST請求則是沒有大小限制的。

TCP與UDP的區別

tcp和udp屬於傳輸層的協議，它們直接的區別在於：

tcp面向鏈接的，udp面向無鏈接
tcp可靠的，udp不可靠
tcp支持點對點的通信，udp支持一對一，一對多、多對一、多對多的通信模式；
tcp面向直接流的，udp面向報文的
tcp由阻塞機制，而udp沒有，則適合媒體傳輸
TCP首部開銷(20個字節)比UDP的首部開銷(8個字節)要大；

TCP的擁塞處理

擁塞控制就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個全局性的過程，而後者指點對點通信量的控制。擁塞控制的方法主要有以下四種：

慢啓動:一開始不發送大量的數據，而是探測下網絡擁塞程度，然後小到大逐漸增加擁塞窗口的大小;
擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長。經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍
快重傳：收到失序的報文立即發出重複確認，而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期
快恢復：快重傳配合使用的還有快恢復算法，當發送方連續收到三個重複確認時，就執行“乘法減小”算法，把ssthresh門限減半，但是接下去並不執行慢開始算法：因爲如果網絡出現擁塞的話就不會收到好幾個重複的確認，所以發送方現在認爲網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，然後執行擁塞避免算法。

輸入網址到獲得頁面的過程

從輸入網址到頁面呈現這個過程大致可分爲以下這幾個部分：網絡通信、頁面渲染

網絡通信

輸入網址

在瀏覽器輸入http://www.sohu.com,http是超文本協議，www.sohu.com是域名，sohu.com是地址。一個完整的URL包含：協議、服務器地址、端口、路徑

負責域名查詢與解析的DNS服務

DNS協議提供域名查詢ip，或者ip反查域名服務。
DNS查詢過程如下：

查找瀏覽器緩存，
查詢hosts文件和本地DNS解析器緩存
本地DNS服務器（TCP/IP參數中設置的首選DNS服務器，具有權威性），如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具有權威性
如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(baidu.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找baidu.com域服務器，重複上面的動作，進行查詢，直至找到www.baidu.com主機。
如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。
從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。

應用層客戶端發送HTTP請求報文

HTTP報文包括：報文首部（請求行+各種首部字段+其他）、空行、報文主體（應被髮送的數據）通常並不一定要有報文主體

傳輸層確保傳輸報文可靠性的TCP協議

位於傳輸層的TCP協議爲傳輸報文提供可靠的字節流服務。爲了方便傳輸，將大塊的數據分割成以報文段爲單位的數據包進行管理，併爲它們編號，方便服務器接收時能準確地還原報文信息。TCP協議通過“三次握手”等方法保證傳輸的安全可靠。

網絡層負責傳輸的IP協議

IP協議的作用是把TCP分割好的各種數據包傳送給接收方。而要保證確實能傳到接收方還需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一對應的關係，一個網絡設備的IP地址可以更換，但是MAC地址一般是固定不變的。ARP協議可以將IP地址解析成對應的MAC地址。當通信的雙方不在同一個局域網時，需要多次中轉才能到達最終的目標，在中轉的過程中需要通過下一個中轉站的MAC地址來搜索下一個中轉目標

鏈路層傳輸數據的硬件部分

在網絡層找到對方的MAC地址後，就將數據發送到數據鏈路層傳輸。至此請求報文已發出，客戶端發送請求的階段結束

服務器接收報文

接收端服務器在鏈路層接收到數據後，刪除該層的首部信息並向網絡層傳遞，網絡層將接收的數據向傳輸層傳遞，在傳輸層會將傳輸的數據按序號從組請求報文並傳送給應用層。當數據傳輸到應用層才能算真正接收到由客戶端發送過來的HTTP請求
#####頁面渲染
瀏覽器解析並渲染視圖

Session、Cookie

Cookie和Session都是客戶端與服務器之間保持狀態的解決方案，具體來說，cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。

Cookie
Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，而客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器，服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
Session
會話狀態也可以保存在服務器端。客戶端請求服務器，如果服務器記錄該用戶狀態，就獲取Session來保存狀態，這時，如果服務器已經爲此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用；如果客戶端請求不包含sessionid，則爲此客戶端創建一個session並且生成一個與此session相關聯的sessionid，並將這個sessionid在本次響應中返回給客戶端保存。保存這個sessionid的方式可以採用 cookie機制 ，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器；若瀏覽器禁用Cookie的話，可以通過 URL重寫機制將sessionid傳回服務器
Session 與 Cookie 的對比

實現機制：Session的實現常常依賴於Cookie機制，通過Cookie機制回傳SessionID；
大小限制：Cookie有大小限制並且瀏覽器對每個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關；
安全性：Cookie存在安全隱患，通過攔截或本地文件找得到cookie後可以進行攻擊，而Session由於保存在服務器端，相對更加安全；
服務器資源消耗：Session是保存在服務器端上會存在一段時間纔會消失，如果session過多會增加服務器的壓力。

SQL 注入

SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

實例

用戶名： ‘or 1 = 1 –
密碼：
從理論上說，後臺認證程序中會有如下的SQL語句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，當輸入了上面的用戶名和密碼，上面的SQL語句變成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL語句我們知道，
username=‘ or 1=1 這個語句一定會成功；然後後面加兩個-，這意味着註釋，它將後面的語句註釋，讓他們不起作用

應對方法

參數綁定
？：目前許多的ORM框架及JDBC等都實現了SQL預編譯和參數綁定功能，攻擊者的惡意SQL會被當做SQL的參數而不是SQL命令被執行
mybatis：mapper文件中，對於傳遞的參數我們一般是使用#和$來獲取參數值。當使用#時，變量是佔位符，就是一般我們使用javajdbc的PrepareStatement時的佔位符，所有可以防止sql注入；當使用$時，變量就是直接追加在sql中，一般會有sql注入問題。

XSS攻擊

XSS是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

危害

盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
盜竊企業重要的具有商業價值的資料
非法轉賬
強制發送電子郵件
網站掛馬
控制受害者機器向其它網站發起攻擊

原因解析
主要原因：過於信任客戶端提交的數據！

解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理然後方可進行下一步的操作。

進一步分析細節：客戶端提交的數據本來就是應用所需要的，但是惡意攻擊者利用網站對客戶端提交數據的信任，在數據中插入一些符號以及javascript代碼，那麼這些數據將會成爲應用代碼中的一部分了，那麼攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數據！！！
　　
3. XSS 攻擊分類
(1). 反射性XSS攻擊 (非持久性XSS攻擊)

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息顯示的時候將會彈出警告窗口！

(2). 持久性XSS攻擊 (留言板場景)

<input type=“text” name=“content” value=“這裏是用戶填寫的數據”>

非正常操作流程是攻擊者在value填寫:

並將數據提交、存儲到數據庫中；當其他用戶取出數據顯示的時候，將會執行這些攻擊性代碼。

修復漏洞方針
漏洞產生的根本原因是太相信用戶提交的數據，對用戶所提交的數據過濾不足所導致的

TCP和UDP分別對應的常見應用層協議

tcp協議：FTP（21），Telnet（23），SMTP（25），POP3（110），HTTP
udp協議：DNS（53），SNMP（簡單網絡管理協議，使用161號端口，是用來管理網絡設備）、TFTP(Trival File Transfer Protocal 簡單文件傳輸協議，69）

ARP協議

網絡層的ARP協議完成了IP地址與物理地址的映射。首先，每臺主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址的對應關係。當源主機需要將一個數據包要發送到目的主機時，會首先檢查自己ARP列表中是否存在該IP地址對應的MAC地址：如果有，就直接將數據包發送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求數據包裏包括源主機的IP地址、硬件地址、以及目的主機的IP地址。網絡中所有的主機收到這個ARP請求後，會檢查數據包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數據包；如果相同，該主機首先將發送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經存在該IP的信息，則將其覆蓋，然後給源主機發送一個ARP響應數據包，告訴對方自己是它需要查找的MAC地址；源主機收到這個ARP響應數據包後，將得到的目的主機的IP地址和MAC地址添加到自己的ARP列表中，並利用此信息開始數據的傳輸。如果源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

IP地址的分類

IP地址是指互聯網協議地址，是IP協議提供的一種統一的地址格式，它爲互聯網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分爲A、B、C、D、E五類，其中A、B、C是基本類，D、E類作爲多播和保留使用，爲特殊地址。

每個IP地址包括兩個標識碼（ID），即網絡ID和主機ID。同一個物理網絡上的所有主機都使用同一個網絡ID，網絡上的一個主機（包括網絡上工作站，服務器和路由器等）有一個主機ID與其對應。A~E類地址的特點如下：

A類地址：以0開頭，第一個字節範圍：0~127；
B類地址：以10開頭，第一個字節範圍：128~191；
C類地址：以110開頭，第一個字節範圍：192~223；
D類地址：以1110開頭，第一個字節範圍爲224~239；
E類地址：以1111開頭，保留地址

http常見狀態碼

1xx:請求處理中
2xx:請求成功
3xx：重定向
4xx：請求錯誤
5xx：服務器錯誤

OSI網絡體系結構與TCP/IP協議模型

物理層：實現2個計算機節點的透明傳輸，並儘可能地屏蔽掉傳輸介質和物理設備的差異，使其上層不必上層（數據鏈路層）關心傳輸的介質
數據鏈路層：接受來之於物理層的位流形式的數據封裝成幀，傳送給上一層;同樣，將上層的數據，拆裝爲位流的形式傳送給物理層。這一層在物理層提供的比特流的基礎上，通過差錯控制、流比量控制方法，使有差錯的物理線路變爲無差錯的數據鏈路，即提供可靠的通過物理介質傳輸數據的方法。
網絡層：將網絡地址翻譯成物理地址，並通過路由選擇算法爲分組通過通信子網選擇最適當的路徑。
傳輸層：在源端和目的端之間提供可靠透明的傳輸，使上層服務用戶不必關心通信子網的細節。
會話層：是用戶應用程序和網絡之間的接口，負責在網絡中的兩節點之間建立、維持和終止通信。
表示層：它對來自應用層的命令和數據進行解釋，以確保一個系統的應用層所發送的信息可以被另一個系統的應用層讀取。
應用層：爲用戶的應用進程提供網絡通信服務

TCP的三次握手與四次揮手
 從輸入網址到頁面呈現都發生了什麼?
面試/筆試第一彈 —— 計算機網絡面試問題集錦