計算機網絡體系結構
在計算機網絡的基本概念中，分層次的體系結構是最基本的。計算機網絡體系結構的抽象概念較多，在學習時要多思考。這些概念對後面的學習很有幫助。
網絡協議是什麼？
在計算機網絡要做到有條不紊地交換數據，就必須遵守一些事先約定好的規則，比如交換數據的格式、是否需要發送一個應答信息。這些規則被稱爲網絡協議。
爲什麼要對網絡協議分層？
- 簡化問題難度和複雜度。由於各層之間獨立，我們可以分割大問題爲小問題。
- 靈活性好。當其中一層的技術變化時，只要層間接口關係保持不變，其他層不受影響。
- 易於實現和維護。
- 促進標準化工作。分開後，每層功能可以相對簡單地被描述。
網絡協議分層的缺點： 功能可能出現在多個層裏，產生了額外開銷。
爲了使不同體系結構的計算機網絡都能互聯，國際標準化組織 ISO 於1977年提出了一個試圖使各種計算機在世界範圍內互聯成網的標準框架，即著名的開放系統互聯基本參考模型 OSI/RM，簡稱爲OSI。
OSI 的七層協議體系結構的概念清楚，理論也較完整，但它既複雜又不實用，TCP/IP 體系結構則不同，但它現在卻得到了非常廣泛的應用。TCP/IP 是一個四層體系結構，它包含應用層，運輸層，網際層和網絡接口層（用網際層這個名字是強調這一層是爲了解決不同網絡的互連問題），不過從實質上講，TCP/IP 只有最上面的三層，因爲最下面的網絡接口層並沒有什麼具體內容，因此在學習計算機網絡的原理時往往採用折中的辦法，即綜合 OSI 和 TCP/IP 的優點，採用一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚，有時爲了方便，也可把最底下兩層稱爲網絡接口層。
四層協議，五層協議和七層協議的關係如下：
- TCP/IP是一個四層的體系結構，主要包括：應用層、運輸層、網際層和網絡接口層。
- 五層協議的體系結構主要包括：應用層、運輸層、網絡層，數據鏈路層和物理層。
- OSI七層協議模型主要包括是：應用層（Application）、表示層（Presentation）、會話層（Session）、運輸層（Transport）、網絡層（Network）、數據鏈路層（Data Link）、物理層（Physical）。
注：五層協議的體系結構只是爲了介紹網絡原理而設計的，實際應用還是 TCP/IP 四層體系結構。
TCP/IP 協議族
應用層
應用層( application-layer ）的任務是通過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通信和交互的規則。
對於不同的網絡應用需要不同的應用層協議。在互聯網中應用層協議很多，如域名系統 DNS，支持萬維網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等。
運輸層
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。
運輸層主要使用一下兩種協議
- 傳輸控制協議-TCP：提供面向連接的，可靠的數據傳輸服務。
- 用戶數據協議-UDP：提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。
| UDP | TCP | |
|---|---|---|
| 是否連接 | 無連接 | 面向連接 |
| 是否可靠 | 不可靠傳輸，不使用流量控制和擁塞控制 | 可靠傳輸，使用流量控制和擁塞控制 |
| 連接對象個數 | 支持一對一，一對多，多對一和多對多交互通信 | 只能是一對一通信 |
| 傳輸方式 | 面向報文 | 面向字節流 |
| 首部開銷 | 首部開銷小，僅8字節 | 首部最小20字節，最大60字節 |
| 場景 | 適用於實時應用（IP電話、視頻會議、直播等） | 適用於要求可靠傳輸的應用，例如文件傳輸 |
每一個應用層（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連接之前先來了解一下TCP報文的頭部結構。
上圖中有幾個字段需要重點介紹下：
（1）序號：seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
（2）確認序號：ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，ack=seq+1。
（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：
- ACK：確認序號有效。
- FIN：釋放一個連接。
- PSH：接收方應該儘快將這個報文交給應用層。
- RST：重置連接。
- SYN：發起一個新連接。
- URG：緊急指針（urgent pointer）有效。
需要注意的是：
- 不要將確認序號ack與標誌位中的ACK搞混了。
- 確認方ack=發起方seq+1，兩端配對。
三次握手
三次握手的本質是確認通信雙方收發數據的能力
首先，我讓信使運輸一份信件給對方，對方收到了，那麼他就知道了我的發件能力和他的收件能力是可以的。
於是他給我回信，我若收到了，我便知我的發件能力和他的收件能力是可以的，並且他的發件能力和我的收件能力是可以。
然而此時他還不知道他的發件能力和我的收件能力到底可不可以，於是我最後回饋一次，他若收到了，他便清楚了他的發件能力和我的收件能力是可以的。
這，就是三次握手，這樣說，你理解了嗎？
第一次握手：客戶端要向服務端發起連接請求，首先客戶端隨機生成一個起始序列號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連接的時間要比客戶端早一些。
常見面試題
爲什麼TCP連接的時候是3次？2次不可以嗎？
因爲需要考慮連接時丟包的問題，如果只握手2次，第二次握手時如果服務端發給客戶端的確認報文段丟失，此時服務端已經準備好了收發數(可以理解服務端已經連接成功)據，而客戶端一直沒收到服務端的確認報文，所以客戶端就不知道服務端是否已經準備好了(可以理解爲客戶端未連接成功)，這種情況下客戶端不會給服務端發數據，也會忽略服務端發過來的數據。
如果是三次握手，即便發生丟包也不會有問題，比如如果第三次握手客戶端發的確認ack報文丟失，服務端在一段時間內沒有收到確認ack報文的話就會重新進行第二次握手，也就是服務端會重發SYN報文段，客戶端收到重發的報文段後會再次給服務端發送確認ack報文。
爲什麼TCP連接的時候是3次，關閉的時候卻是4次？
因爲只有在客戶端和服務端都沒有數據要發送的時候才能斷開TCP。而客戶端發出FIN報文時只能保證客戶端沒有數據發了，服務端還有沒有數據發客戶端是不知道的。而服務端收到客戶端的FIN報文後只能先回復客戶端一個確認報文來告訴客戶端我服務端已經收到你的FIN報文了，但我服務端還有一些數據沒發完，等這些數據發完了服務端才能給客戶端發FIN報文(所以不能一次性將確認報文和FIN報文發給客戶端，就是這裏多出來了一次)。
爲什麼客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP連接？
這裏同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務端沒收到確認ack報文就會重發第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這麼長時間來確認服務端確實已經收到了。
如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？
TCP設有一個保活計時器，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。
什麼是HTTP，HTTP 與 HTTPS 的區別
HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範
| 區別 | HTTP | HTTPS |
|---|---|---|
| 協議 | 運行在 TCP 之上，明文傳輸，客戶端與服務器端都無法驗證對方的身份 | 身披 SSL( Secure Socket Layer )外殼的 HTTP，運行於 SSL 上，SSL 運行於 TCP 之上， 是添加了加密和認證機制的 HTTP。 |
| 端口 | 80 | 443 |
| 資源消耗 | 較少 | 由於加解密處理，會消耗更多的 CPU 和內存資源 |
| 開銷 | 無需證書 | 需要證書，而證書一般需要向認證機構購買 |
| 加密機制 | 無 | 共享密鑰加密和公開密鑰加密並用的混合加密機制 |
| 安全性 | 弱 | 由於加密機制，安全性強 |
常用HTTP狀態碼
HTTP狀態碼錶示客戶端HTTP請求的返回結果、標識服務器處理是否正常、表明請求出現的錯誤等。
狀態碼的類別：
| 類別 | 原因短語 |
|---|---|
| 1XX | Informational（信息性狀態碼） 接受的請求正在處理 |
| 2XX | Success（成功狀態碼） 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態碼） 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態碼） 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態碼） 服務器處理請求出錯 |
常用HTTP狀態碼：
| 2XX | 成功（這系列表明請求被正常處理了） |
|---|---|
| 200 | OK，表示從客戶端發來的請求在服務器端被正確處理 |
| 204 | No content，表示請求成功，但響應報文不含實體的主體部分 |
| 206 | Partial Content，進行範圍請求成功 |
| 3XX | 重定向（表明瀏覽器要執行特殊處理） |
|---|---|
| 301 | moved permanently，永久性重定向，表示資源已被分配了新的 URL |
| 302 | found，臨時性重定向，表示資源臨時被分配了新的 URL |
| 303 | see other，表示資源存在着另一個 URL，應使用 GET 方法獲取資源（對於301/302/303響應，幾乎所有瀏覽器都會刪除報文主體並自動用GET重新請求） |
| 304 | not modified，表示服務器允許訪問資源，但請求未滿足條件的情況（與重定向無關） |
| 307 | temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求 |
| 4XX | 客戶端錯誤 |
|---|---|
| 400 | bad request，請求報文存在語法錯誤 |
| 401 | unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息 |
| 403 | forbidden，表示對請求資源的訪問被服務器拒絕，可在實體主體部分返回原因描述 |
| 404 | not found，表示在服務器上沒有找到請求的資源 |
| 5XX | 服務器錯誤 |
|---|---|
| 500 | internal sever error，表示服務器端在執行請求時發生了錯誤 |
| 501 | Not Implemented，表示服務器不支持當前請求所需要的某個功能 |
| 503 | service unavailable，表明服務器暫時處於超負載或正在停機維護，無法處理請求 |
GET和POST區別
說道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
HTTP2 可以提高了網頁的性能。
在 HTTP1 中瀏覽器限制了同一個域名下的請求數量（Chrome 下一般是六個），當在請求很多資源的時候，由於隊頭阻塞當瀏覽器達到最大請求數量時，剩餘的資源需等待當前的六個請求完成後才能發起請求。
HTTP2 中引入了多路複用的技術，這個技術可以只通過一個 TCP 連接就可以傳輸所有的請求數據。多路複用可以繞過瀏覽器限制同一個域名下的請求數量的問題，進而提高了網頁的性能。
Session、Cookie和Token的主要區別
HTTP協議本身是無狀態的。什麼是無狀態呢，即服務器無法判斷用戶身份。
什麼是cookie
cookie是由Web服務器保存在用戶瀏覽器上的小文件（key-value格式），包含用戶相關的信息。客戶端向服務器發起請求，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶身份。
什麼是session
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 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位
session與token區別
- session機制存在服務器壓力增大，CSRF跨站僞造請求攻擊，擴展性不強等問題；
- session存儲在服務器端，token存儲在客戶端
- token提供認證和授權功能，作爲身份認證，token安全性比session好；
- session這種會話存儲方式方式只適用於客戶端代碼和服務端代碼運行在同一臺服務器上，token適用於項目級的前後端分離（前後端代碼運行在不同的服務器下）
Servlet是線程安全的嗎
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 ServletException
- void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
- void destory()
- java.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，在跨頁過程中手動調用。