本文轉載於 SegmentFault 社區
作者：哈基石
在計算機網絡的基本概念中，分層次的體系結構是最基本的。計算機網絡體系結構的抽象概念較多，在學習時要多思考。這些概念對後面的學習很有幫助。
網絡協議是什麼？在計算機網絡要做到有條不紊地交換數據，就必須遵守一些事先約定好的規則，比如交換數據的格式、是否需要發送一個應答信息。這些規則被稱為網絡協議。
網絡協議分層的缺點：功能可能出現在多個層裡，產生了額外開銷。
為了使不同體系結構的計算機網絡都能互聯，國際標準化組織 ISO 於1977年提出了一個試圖使各種計算機在世界範圍內互聯成網的標準框架，即著名的開放系統互聯基本參考模型 OSI/RM，簡稱為OSI。
OSI 的七層協議體系結構的概念清楚，理論也較完整，但它既複雜又不實用，TCP/IP 體系結構則不同，但它現在卻得到了非常廣泛的應用。TCP/IP 是一個四層體系結構，它包含應用層，運輸層，網際層和網絡接口層（用網際層這個名字是強調這一層是為了解決不同網絡的互連問題），不過從實質上講，TCP/IP 只有最上面的三層，因為最下面的網絡接口層並沒有什麼具體內容，因此在學習計算機網絡的原理時往往採用折中的辦法，即綜合 OSI 和 TCP/IP 的優點，採用一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚，有時為了方便，也可把最底下兩層稱為網絡接口層。
四層協議，五層協議和七層協議的關係如下：
註：五層協議的體系結構只是為了介紹網絡原理而設計的，實際應用還是 TCP/IP 四層體系結構。
應用層( application-layer ）的任務是通過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通信和交互的規則。
對於不同的網絡應用需要不同的應用層協議。在網際網路中應用層協議很多，如域名系統 DNS，支持全球資訊網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等。
運輸層運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。
運輸層主要使用一下兩種協議
傳輸控制協議-TCP：提供面向連接的，可靠的數據傳輸服務。用戶數據協議-UDP：提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。每一個應用層（TCP/IP參考模型的最高層）協議一般都會使用到兩個傳輸層協議之一：
運行在TCP協議上的協議：
HTTP（Hypertext Transfer Protocol，超文本傳輸協議），主要用於普通瀏覽。HTTPS（HTTP over SSL，安全超文本傳輸協議）,HTTP協議的安全版本。FTP（File Transfer Protocol，文件傳輸協議），用於文件傳輸。POP3（Post Office Protocol, version 3，郵局協議），收郵件用。SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議），用來發送電子郵件。TELNET（Teletype over the Network，網絡電傳），通過一個終端（terminal）登陸到網絡。SSH（Secure Shell，用於替代安全性差的TELNET），用於加密安全登陸用。運行在UDP協議上的協議：
BOOTP（Boot Protocol，啟動協議），應用於無盤設備。NTP（Network Time Protocol，網絡時間協議），用於網絡同步。DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP位址。運行在TCP和UDP協議上：
DNS（Domain Name Service，域名服務），用於完成地址查找，郵件轉發等工作。網絡層的任務就是選擇合適的網間路由和交換結點，確保計算機通信的數據及時傳送。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，由於網絡層使用 IP 協議，因此分組也叫 IP 數據報 ，簡稱數據報。
網際網路是由大量的異構（heterogeneous）網絡通過路由器（router）相互連接起來的。網際網路使用的網絡層協議是無連接的網際協議（Intert Prococol）和許多路由選擇協議，因此網際網路的網絡層也叫做網際層或 IP 層。
數據鏈路層(data link layer)通常簡稱為鏈路層。兩臺主機之間的數據傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協議。
在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。
在接收數據時，控制信息使接收端能夠知道一個幀從哪個比特開始和到哪個比特結束。
一般的web應用的通信傳輸流是這樣的：
發送端在層與層之間傳輸數據時，每經過一層時會被打上一個該層所屬的首部信息。反之，接收端在層與層之間傳輸數據時，每經過一層時會把對應的首部信息去除。
在物理層上所傳送的數據單位是比特。物理層(physical layer)的作用是實現相鄰計算機節點之間比特流的透明傳送，儘可能屏蔽掉具體傳輸介質和物理設備的差異。使其上面的數據鏈路層不必考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來說，這個電路好像是看不見的。
TCP/IP 協議族在網際網路使用的各種協議中最重要和最著名的就是 TCP/IP 兩個協議。現在人們經常提到的 TCP/IP 並不一定是單指 TCP 和 IP 這兩個具體的協議，而往往是表示網際網路所使用的整個 TCP/IP 協議族。
網際網路協議套件（英語：Internet Protocol Suite，縮寫IPS）是一個網絡通訊模型，以及一整個網絡傳輸協議家族，為網際網絡的基礎通訊架構。它常被通稱為TCP/IP協議族（英語：TCP/IP Protocol Suite，或TCP/IP Protocols），簡稱TCP/IP。因為該協定家族的兩個核心協定：TCP（傳輸控制協議）和IP（網際協議），為該家族中最早通過的標準。
劃重點：
TCP（傳輸控制協議）和IP（網際協議） 是最先定義的兩個核心協議，所以才統稱為TCP/IP協議族
TCP的三次握手四次揮手TCP是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，在發送數據前，通信雙方必須在彼此間建立一條連接。所謂的「連接」，其實是客戶端和服務端保存的一份關於對方的信息，如ip地址、埠號等。
TCP可以看成是一種字節流，它會處理IP層或以下的層的丟包、重複以及錯誤問題。在連接的建立過程中，雙方需要交換一些連接的參數。這些參數可以放在TCP頭部。
一個TCP連接由一個4元組構成，分別是兩個IP位址和兩個埠號。一個TCP連接通常分為三個階段：連接、數據傳輸、退出（關閉）。通過三次握手建立一個連結，通過四次揮手來關閉一個連接。
當一個連接被建立或被終止時，交換的報文段只包含TCP頭部，而沒有數據。
在了解TCP連接之前先來了解一下TCP報文的頭部結構。
上圖中有幾個欄位需要重點介紹下：
（1）序號：seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
（2）確認序號：ack序號，佔32位，只有ACK標誌位為1時，確認序號欄位才有效，ack=seq+1。
（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：
URG：緊急指針（urgent pointer）有效。需要注意的是：
三次握手的本質是確認通信雙方收發數據的能力
首先，我讓信使運輸一份信件給對方，對方收到了，那麼他就知道了我的發件能力和他的收件能力是可以的。
於是他給我回信，我若收到了，我便知我的發件能力和他的收件能力是可以的，並且他的發件能力和我的收件能力是可以。
然而此時他還不知道他的發件能力和我的收件能力到底可不可以，於是我最後回饋一次，他若收到了，他便清楚了他的發件能力和我的收件能力是可以的。
這，就是三次握手，這樣說，你理解了嗎？
第一次握手：客戶端要向服務端發起連接請求，首先客戶端隨機生成一個起始序列號ISN(比如是100)，那客戶端向服務端發送的報文段包含SYN標誌位(也就是SYN=1)，序列號seq=100。第二次握手：服務端收到客戶端發過來的報文後，發現SYN=1，知道這是一個連接請求，於是將客戶端的起始序列號100存起來，並且隨機生成一個服務端的起始序列號(比如是300)。然後給客戶端回復一段報文，回復報文包含SYN和ACK標誌(也就是SYN=1,ACK=1)、序列號seq=300、確認號ack=101(客戶端發過來的序列號+1)。第三次握手：客戶端收到服務端的回覆後發現ACK=1並且ack=101,於是知道服務端已經收到了序列號為100的那段報文；同時發現SYN=1，知道了服務端同意了這次連接，於是就將服務端的序列號300給存下來。然後客戶端再回復一段報文給服務端，報文包含ACK標誌位(ACK=1)、ack=301(服務端序列號+1)、seq=101(第一次握手時發送報文是佔據一個序列號的，所以這次seq就從101開始，需要注意的是不攜帶數據的ACK報文是不佔據序列號的，所以後面第一次正式發送數據時seq還是101)。當服務端收到報文後發現ACK=1並且ack=301，就知道客戶端收到序列號為300的報文了，就這樣客戶端和服務端通過TCP建立了連接。四次揮手的目的是關閉一個連接
比如客戶端初始化的序列號ISA=100，服務端初始化的序列號ISA=300。TCP連接成功後客戶端總共發送了1000個字節的數據，服務端在客戶端發FIN報文前總共回復了2000個字節的數據。
第一次揮手：當客戶端的數據都傳輸完成後，客戶端向服務端發出連接釋放報文(當然數據沒發完時也可以發送連接釋放報文並停止發送數據)，釋放連接報文包含FIN標誌位(FIN=1)、序列號seq=1101(100+1+1000，其中的1是建立連接時佔的一個序列號)。需要注意的是客戶端發出FIN報文段後只是不能發數據了，但是還可以正常收數據；另外FIN報文段即使不攜帶數據也要佔據一個序列號。第二次揮手：服務端收到客戶端發的FIN報文後給客戶端回復確認報文，確認報文包含ACK標誌位(ACK=1)、確認號ack=1102(客戶端FIN報文序列號1101+1)、序列號seq=2300(300+2000)。此時服務端處於關閉等待狀態，而不是立馬給客戶端發FIN報文，這個狀態還要持續一段時間，因為服務端可能還有數據沒發完。第三次揮手：服務端將最後數據(比如50個字節)發送完畢後就向客戶端發出連接釋放報文，報文包含FIN和ACK標誌位(FIN=1,ACK=1)、確認號和第二次揮手一樣ack=1102、序列號seq=2350(2300+50)。第四次揮手：客戶端收到服務端發的FIN報文後，向服務端發出確認報文，確認報文包含ACK標誌位(ACK=1)、確認號ack=2351、序列號seq=1102。注意客戶端發出確認報文後不是立馬釋放TCP連接，而是要經過2MSL(最長報文段壽命的2倍時長)後才釋放TCP連接。而服務端一旦收到客戶端發出的確認報文就會立馬釋放TCP連接，所以服務端結束TCP連接的時間要比客戶端早一些。因為需要考慮連接時丟包的問題，如果只握手2次，第二次握手時如果服務端發給客戶端的確認報文段丟失，此時服務端已經準備好了收發數(可以理解服務端已經連接成功)據，而客戶端一直沒收到服務端的確認報文，所以客戶端就不知道服務端是否已經準備好了(可以理解為客戶端未連接成功)，這種情況下客戶端不會給服務端發數據，也會忽略服務端發過來的數據。
如果是三次握手，即便發生丟包也不會有問題，比如如果第三次握手客戶端發的確認ack報文丟失，服務端在一段時間內沒有收到確認ack報文的話就會重新進行第二次握手，也就是服務端會重發SYN報文段，客戶端收到重發的報文段後會再次給服務端發送確認ack報文。
為什麼TCP連接的時候是3次，關閉的時候卻是4次？因為只有在客戶端和服務端都沒有數據要發送的時候才能斷開TCP。而客戶端發出FIN報文時只能保證客戶端沒有數據發了，服務端還有沒有數據發客戶端是不知道的。而服務端收到客戶端的FIN報文後只能先回復客戶端一個確認報文來告訴客戶端我服務端已經收到你的FIN報文了，但我服務端還有一些數據沒發完，等這些數據發完了服務端才能給客戶端發FIN報文(所以不能一次性將確認報文和FIN報文發給客戶端，就是這裡多出來了一次)。
為什麼客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP連接？這裡同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務端沒收到確認ack報文就會重發第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這麼長時間來確認服務端確實已經收到了。
如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？TCP設有一個保活計時器，客戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，伺服器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連接。
HTTP 是一個在計算機世界裡專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範
HTTP狀態碼表示客戶端HTTP請求的返回結果、標識伺服器處理是否正常、表明請求出現的錯誤等。
狀態碼的類別：
說道GET和POST，就不得不提HTTP協議，因為瀏覽器和伺服器的交互是通過HTTP協議執行的，而GET和POST也是HTTP協議中的兩種方法。
HTTP全稱為Hyper Text Transfer Protocol，中文翻譯為超文本傳輸協議，目的是保證瀏覽器與伺服器之間的通信。HTTP的工作方式是客戶端與伺服器之間的請求-應答協議。
HTTP協議中定義了瀏覽器和伺服器進行交互的不同方法，基本方法有4種，分別是GET，POST，PUT，DELETE。這四種方法可以理解為，對伺服器資源的查，改，增，刪。
GET：從伺服器上獲取數據，也就是所謂的查，僅僅是獲取伺服器資源，不進行修改。POST：向伺服器提交數據，這就涉及到了數據的更新，也就是更改伺服器的數據。PUT：英文含義是放置，也就是向伺服器新添加數據，就是所謂的增。DELETE：從字面意思也能看出，這種方式就是刪除伺服器數據的過程。GET和POST區別
Get是不安全的，因為在傳輸過程，數據被放在請求的URL中；Post的所有操作對用戶來說都是不可見的。但是這種做法也不時絕對的，大部分人的做法也是按照上面的說法來的，但是也可以在get請求加上 request body，給 post請求帶上 URL 參數。Get請求提交的url中的數據最多只能是2048位元組，這個限制是瀏覽器或者伺服器給添加的，http協議並沒有對url長度進行限制，目的是為了保證伺服器和瀏覽器能夠正常運行，防止有人惡意發送請求。Post請求則沒有大小限制。Get限制Form表單的數據集的值必須為ASCII字符；而Post支持整個ISO10646字符集。Get執行效率卻比Post方法好。Get是form提交的默認方法。GET產生一個TCP數據包；POST產生兩個TCP數據包。對於GET方式的請求，瀏覽器會把http header和data一併發送出去，伺服器響應200（返回數據）；
而對於POST，瀏覽器先發送header，伺服器響應100 continue，瀏覽器再發送data，伺服器響應200 ok（返回數據）。
對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；
而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發布，但私鑰只有自己知道。發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息後，使用自己的私鑰進行解密。
由於非對稱加密的方式不需要發送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，非常的慢
HTTP2 可以提高了網頁的性能。
在 HTTP1 中瀏覽器限制了同一個域名下的請求數量（Chrome 下一般是六個），當在請求很多資源的時候，由於隊頭阻塞當瀏覽器達到最大請求數量時，剩餘的資源需等待當前的六個請求完成後才能發起請求。
HTTP2 中引入了多路復用的技術，這個技術可以只通過一個 TCP 連接就可以傳輸所有的請求數據。多路復用可以繞過瀏覽器限制同一個域名下的請求數量的問題，進而提高了網頁的性能。
Session、Cookie和Token的主要區別
HTTP協議本身是無狀態的。什麼是無狀態呢，即伺服器無法判斷用戶身份。
cookie是由Web伺服器保存在用戶瀏覽器上的小文件（key-value格式），包含用戶相關的信息。客戶端向伺服器發起請求，如果伺服器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給伺服器。伺服器檢查該Cookie，以此來辨認用戶身份。
session是依賴Cookie實現的。session是伺服器端對象
session 是瀏覽器和伺服器會話過程中，伺服器分配的一塊儲存空間。伺服器默認為瀏覽器在cookie中設置 sessionid，瀏覽器在向伺服器請求過程中傳輸 cookie 包含 sessionid ，伺服器根據 sessionid 獲取出會話中存儲的信息，然後確定會話的身份信息。
cookie與session區別
存儲位置與安全性：cookie數據存放在客戶端上，安全性較差，session數據放在伺服器上，安全性相對更高；存儲空間：單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，session無此限制佔用伺服器資源：session一定時間內保存在伺服器上，當訪問增多，佔用伺服器性能，考慮到伺服器性能方面，應當使用cookie。Token的引入：Token是在客戶端頻繁向服務端請求數據，服務端頻繁的去資料庫查詢用戶名和密碼並進行對比，判斷用戶名和密碼正確與否，並作出相應提示，在這樣的背景下，Token便應運而生。
Token的定義：Token是服務端生成的一串字符串，以作客戶端進行請求的一個令牌，當第一次登錄後，伺服器生成一個Token便將此Token返回給客戶端，以後客戶端只需帶上這個Token前來請求數據即可，無需再次帶上用戶名和密碼。
使用Token的目的：Token的目的是為了減輕伺服器的壓力，減少頻繁的查詢資料庫，使伺服器更加健壯。
Token 是在服務端產生的。如果前端使用用戶名/密碼向服務端請求認證，服務端認證成功，那麼在服務端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位
session與token區別
Servlet不是線程安全的，多線程並發的讀寫會導致數據不同步的問題。
解決的辦法是儘量不要定義name屬性，而是要把name變量分別定義在doGet()和doPost()方法內。雖然使用synchronized(name){}語句塊可以解決問題，但是會造成線程的等待，不是很科學的辦法。
注意：多線程的並發的讀寫Servlet類屬性會導致數據不同步。但是如果只是並發地讀取屬性而不寫入，則不存在數據不同步的問題。因此Servlet裡的只讀屬性最好定義為final類型的。
Servlet接口中有哪些方法及Servlet生命周期探秘在Java Web程序中，Servlet主要負責接收用戶請求HttpServletRequest，在doGet()，doPost()中做相應的處理，並將回應HttpServletResponse反饋給用戶。Servlet可以設置初始化參數，供Servlet內部使用。
Servlet接口定義了5個方法，其中前三個方法與Servlet生命周期相關：
void init(ServletConfig config) throws ServletExceptionvoid service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOExceptionjava.lang.String getServletInfo()ServletConfig getServletConfig()Web容器加載Servlet並將其實例化後，Servlet生命周期開始，容器運行其init()方法進行Servlet的初始化；
請求到達時調用Servlet的service()方法，service()方法會根據需要調用與請求對應的doGet或doPost等方法；
當伺服器關閉或項目被卸載時伺服器會將Servlet實例銷毀，此時會調用Servlet的destroy()方法。
init方法和destory方法只會執行一次，service方法客戶端每次請求Servlet都會執行。Servlet中有時會用到一些需要初始化與銷毀的資源，因此可以把初始化資源的代碼放入init方法中，銷毀資源的代碼放入destroy方法中，這樣就不需要每次處理客戶端的請求都要初始化與銷毀資源。
如果客戶端禁止 cookie 能實現 session 還能用嗎？Cookie 與 Session，一般認為是兩個獨立的東西，Session採用的是在伺服器端保持狀態的方案，而Cookie採用的是在客戶端保持狀態的方案。
但為什麼禁用Cookie就不能得到Session呢？因為Session是用Session ID來確定當前對話所對應的伺服器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當於失去了Session ID，也就得不到Session了。
假定用戶關閉Cookie的情況下使用Session，其實現途徑有以下幾種：
手動通過URL傳值、隱藏表單傳遞Session ID。用文件、資料庫等形式保存Session ID，在跨頁過程中手動調用。點擊左下角閱讀原文，到 SegmentFault 思否社區 和文章作者展開更多互動和交流。