面经——计算机网络
計算機網絡
目錄
注：題目從牛客 Java部門面經整理而來。
2020秋招面經大匯總！（崗位劃分）
1. OSI與TCP/IP各層的結構與功能,都有哪些協議?
學習計算機網絡時我們一般采用折中的辦法，也就是中和 OSI 和 TCP/IP 的優點，采用一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚。
###################################################### 圖片
結合互聯網的情況，自上而下地，非常簡要的介紹一下各層的作用。
1.1 應用層
應用層(application-layer）的任務是通過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通信和交互的規則。對于不同的網絡應用需要不同的應用層協議。在互聯網中應用層協議很多，如域名系統DNS，支持萬維網應用的 HTTP協議，支持電子郵件的 SMTP協議等等。我們把應用層交互的數據單元稱為報文。
域名系統
域名系統(Domain Name System縮寫 DNS，Domain Name被譯為域名)是因特網的一項核心服務，它作為可以將域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。（百度百科）例如：一個公司的 Web 網站可看作是它在網上的門戶，而域名就相當于其門牌地址，通常域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，類似的還有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。
HTTP協議
超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議。所有的 WWW（萬維網） 文件都必須遵守這個標準。設計 HTTP 最初的目的是為了提供一種發布和接收 HTML 頁面的方法。（百度百科）
1.2 運輸層
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。“通用的”是指并不針對某一個特定的網絡應用，而是多種應用可以使用同一個運輸層服務。由于一臺主機可同時運行多個線程，因此運輸層有復用和分用的功能。所謂復用就是指多個應用層進程可同時使用下面運輸層的服務，分用和復用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。
運輸層主要使用以下兩種協議:
1.3 網絡層
在 計算機網絡中進行通信的兩個計算機之間可能會經過很多個數據鏈路，也可能還要經過很多通信子網。網絡層的任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送。 在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，由于網絡層使用 IP 協議，因此分組也叫 IP 數據報 ，簡稱 數據報。
這里要注意：不要把運輸層的“用戶數據報 UDP ”和網絡層的“ IP 數據報”弄混。另外，無論是哪一層的數據單元，都可籠統地用“分組”來表示。
這里強調指出，網絡層中的“網絡”二字已經不是我們通常談到的具體網絡，而是指計算機網絡體系結構模型中第三層的名稱.
互聯網是由大量的異構（heterogeneous）網絡通過路由器（router）相互連接起來的。互聯網使用的網絡層協議是無連接的網際協議（Intert Protocol）和許多路由選擇協議，因此互聯網的網絡層也叫做網際層或IP層。
2. 三次握手和四次揮手
1. TCP 三次握手
所謂三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：
2. 為什么要三次握手？兩次不行么？為什么？
三次握手的目的是建立可靠的通信信道，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。
所以三次握手就能確認雙發收發功能都正常，缺一不可。
如果采用兩次握手，那么只要服務器發送確認數據包就會建立連接，但由于此時客戶端并未響應服務器端請求，那么此時服務器端就會一直在等待客戶端，這樣服務器端就白白浪費了一定的資源。若采用握手，服務器端沒有收到來自客戶端的再次確認，則就會知道客戶端并沒有要求建立請求，就不會浪費服務器的資源。
3. 為什么要傳回 SYN？
接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的信息確實就是你所發送的信號了。
SYN 是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立正常的 TCP 網絡連接時，客戶機首先發出一個 SYN 消息，服務器使用 SYN-ACK 應答表示接收到了這個消息，最后客戶機再以ACK(Acknowledgement[漢譯：確認字符,在數據通信傳輸中，接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤。 ]）消息響應。這樣在客戶機和服務器之間才能建立起可靠的TCP連接，數據才可以在客戶機和服務器之間傳遞。
4. 傳了 SYN，為什么還要傳 ACK？
雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方到接收方的通道沒有問題，但是接收方到發送方的通道還需要 ACK 信號來進行驗證。
5. 四次揮手
四次揮手（Four-Way Wavehand）即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個數據包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程如下圖所示：
由于TCP連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務后，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
6. 為什么要四次揮手
任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就完全關閉了TCP連接。
7. 為什么客戶端最后還要等待2MSL？
MSL（Maximum Segment Lifetime：最長報文段壽命），TCP允許不同的實現可以設置不同的MSL值。
第一，保證客戶端發送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，于是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器。
第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。
8. 為什么建立連接是三次握手，關閉連接確是四次揮手呢？
3. TCP,UDP 協議的區別
UDP 在傳送數據之前不需要先建立連接，遠地主機在收到 UDP 報文后，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時通信），比如： QQ 語音、 QQ 視頻 、直播等等
TCP 提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束后要釋放連接。 TCP 不提供廣播或多播服務。由于 TCP 要提供可靠的，面向連接的傳輸服務（TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完后，還會斷開連接用來節約系統資源），這一難以避免增加了許多開銷，如確認，流量控制，計時器以及連接管理等。這不僅使協議數據單元的首部增大很多，還要占用許多處理機資源。TCP 一般用于文件傳輸、發送和接收郵件、遠程登錄等場景。
使用TCP的協議有哪些？使用UDP的協議有哪些？
運行于TCP協議之上的協議：
運行于UDP協議之上的協議：
4. TCP 協議如何保證可靠傳輸
4.1 ARQ協議
自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送后一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。
停止等待ARQ協議
- 停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認（回復ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發送成功，需要重新發送，直到收到確認后再發下一個分組；
- 在停止等待協議中，若接收方收到重復分組，就丟棄該分組，但同時還要發送確認；
優點： 簡單
缺點： 信道利用率低，等待時間長
1) 無差錯情況:
發送方發送分組,接收方在規定時間內收到,并且回復確認.發送方再次發送。
2) 出現差錯情況（超時重傳）:
停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送過的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協議中若收到重復分組，就丟棄該分組，但同時還要發送確認。連續 ARQ 協議 可提高信道利用率。發送維持一個發送窗口，凡位于發送窗口內的分組可連續發送出去，而不需要等待對方確認。接收方一般采用累積確認，對按序到達的最后一個分組發送確認，表明到這個分組位置的所有分組都已經正確收到了。
3) 確認丟失和確認遲到
- 確認丟失 ：確認消息在傳輸過程丟失。當A發送M1消息，B收到后，B向A發送了一個M1確認消息，但卻在傳輸過程中丟失。而A并不知道，在超時計時過后，A重傳M1消息，B再次收到該消息后采取以下兩點措施：1. 丟棄這個重復的M1消息，不向上層交付。 2. 向A發送確認消息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的確認消息丟失）。
- 確認遲到 ：確認消息在傳輸過程中遲到。A發送M1消息，B收到并發送確認。在超時時間內沒有收到確認消息，A重傳M1消息，B仍然收到并繼續發送確認消息（B收到了2份M1）。此時A收到了B第二次發送的確認消息。接著發送其他數據。過了一會，A收到了B第一次發送的對M1的確認消息（A也收到了2份確認消息）。處理如下：1. A收到重復的確認后，直接丟棄。2. B收到重復的M1后，也直接丟棄重復的M1。
連續ARQ協議
連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位于發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。
優點： 信道利用率高，容易實現，即使確認丟失，也不必重傳。
缺點： 不能向發送方反映出接收方已經正確收到的所有分組的信息。 比如：發送方發送了 5條 消息，中間第三條丟失（3號），這時接收方只能對前兩個發送確認。發送方無法知道后三個分組的下落，而只好把后三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。
4.2 滑動窗口和流量控制
TCP 利用滑動窗口實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。 接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置為 0，則發送方不能發送數據。
4.3 擁塞控制
在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的數據注入到網絡中，這樣就可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發送端發送數據的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 發送方要維持一個 擁塞窗口(cwnd) 的狀態變量。擁塞控制窗口的大小取決于網絡的擁塞程度，并且動態變化。發送方讓自己的發送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。
TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網絡層也可以使路由器采用適當的分組丟棄策略（如主動隊列管理 AQM），以減少網絡擁塞的發生。
- 慢開始： 慢開始算法的思路是當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那么可能會引起網絡阻塞，因為現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。
- 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送方的cwnd加1.
- 快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢復丟失的數據包。沒有 FRR，如果數據包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或復制的數據包被發送。有了 FRR，如果接收機接收到一個不按順序的數據段，它會立即給發送機發送一個重復確認。如果發送機接收到三個重復確認，它會假定確認件指出的數據段丟失了，并立即重傳這些丟失的數據段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的數據包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。
5. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程
總體來說分為以下幾個過程:
1. DNS解析
DNS解析的過程就是尋找哪臺機器上有你需要資源的過程。當你在瀏覽器中輸入一個地址時，例如www.baidu.com，其實不是百度網站真正意義上的地址。互聯網上每一臺計算機的唯一標識是它的IP地址，但是IP地址并不方便記憶。用戶更喜歡用方便記憶的網址去尋找互聯網上的其它計算機，也就是上面提到的百度的網址。所以互聯網設計者需要在用戶的方便性與可用性方面做一個權衡，這個權衡就是一個網址到IP地址的轉換，這個過程就是DNS解析。它實際上充當了一個翻譯的角色，實現了網址到IP地址的轉換。網址到IP地址轉換的過程是如何進行的?
DNS解析是一個遞歸查詢的過程。
上述圖片是查找www.google.com的IP地址過程。首先在本地域名服務器中查詢IP地址，如果沒有找到的情況下，本地域名服務器會向根域名服務器發送一個請求，如果根域名服務器也不存在該域名時，本地域名會向com頂級域名服務器發送一個請求，依次類推下去。直到最后本地域名服務器得到google的IP地址并把它緩存到本地，供下次查詢使用。從上述過程中，可以看出網址的解析是一個從右向左的過程: com -> google.com -> www.google.com。但是你是否發現少了點什么，根域名服務器的解析過程呢？事實上，真正的網址是www.google.com.，并不是我多打了一個.，這個.對應的就是根域名服務器，默認情況下所有的網址的最后一位都是.，既然是默認情況下，為了方便用戶，通常都會省略，瀏覽器在請求DNS的時候會自動加上，所有網址真正的解析過程為: . -> .com -> google.com. -> www.google.com.。
DNS優化
了解了DNS的過程，可以為我們帶來哪些？上文中請求到google的IP地址時，經歷了8個步驟，這個過程中存在多個請求(同時存在UDP和TCP請求，為什么有兩種請求方式，請自行查找)。如果每次都經過這么多步驟，是否太耗時間？如何減少該過程的步驟呢？那就是DNS緩存。
DNS緩存
DNS存在著多級緩存，從離瀏覽器的距離排序的話，有以下幾種: 瀏覽器緩存，系統緩存，路由器緩存，IPS服務器緩存，根域名服務器緩存，頂級域名服務器緩存，主域名服務器緩存。
在你的chrome瀏覽器中輸入:chrome://dns/，你可以看到chrome瀏覽器的DNS緩存。
系統緩存主要存在/etc/hosts(Linux系統)中:
2. TCP連接
瀏覽器獲得域名對應的IP地址以后，瀏覽器向服務器請求建立鏈接，發起三次握手；
3. 發送HTTP請求
其實這部分又可以稱為前端工程師眼中的HTTP，它主要發生在客戶端。發送HTTP請求的過程就是構建HTTP請求報文并通過TCP協議發送到服務器指定端口(HTTP協議80/8080, HTTPS協議443)。HTTP請求報文是由三部分組成: 請求行, 請求報頭和請求正文。
4. 服務器處理HTTP請求并返回HTTP報文
自然而然這部分對應的就是后端工程師眼中的HTTP。后端從在固定的端口接收到TCP報文開始，這一部分對應于編程語言中的socket。它會對TCP連接進行處理，對HTTP協議進行解析，并按照報文格式進一步封裝成HTTP Request對象，供上層使用。這一部分工作一般是由Web服務器去進行。
HTTP響應報文也是由三部分組成: 狀態碼, 響應報頭和響應報文。
5. 游覽器解析渲染頁面
瀏覽器是一個邊解析邊渲染的過程。首先瀏覽器解析HTML文件構建DOM樹，然后解析CSS文件構建渲染樹，等到渲染樹構建完成后，瀏覽器開始布局渲染樹并將其繪制到屏幕上。這個過程比較復雜，涉及到兩個概念: reflow(回流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來之后，瀏覽器便開始繪制內容，這個過程稱為repain。頁面在首次加載時必然會經歷reflow和repain。reflow和repain過程是非常消耗性能的，尤其是在移動設備上，它會破壞用戶體驗，有時會造成頁面卡頓。所以我們應該盡可能少的減少reflow和repain。
瀏覽器在解析過程中，如果遇到請求外部資源時，如圖像,iconfont,JS等。瀏覽器將重復1-6過程下載該資源。請求過程是異步的，并不會影響HTML文檔進行加載，但是當文檔加載過程中遇到JS文件，HTML文檔會掛起渲染過程，不僅要等到文檔中JS文件加載完畢還要等待解析執行完畢，才會繼續HTML的渲染過程。原因是因為JS有可能修改DOM結構，這就意味著JS執行完成前，后續所有資源的下載是沒有必要的，這就是JS阻塞后續資源下載的根本原因。CSS文件的加載不影響JS文件的加載，但是卻影響JS文件的執行。JS代碼執行前瀏覽器必須保證CSS文件已經下載并加載完畢。
6. 連接結束
6. URI和URL的區別是什么?
- URI(Uniform Resource Identifier) 是統一資源標志符，可以唯一標識一個資源。
- URL(Uniform Resource Location) 是統一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明了如何 locate 這個資源。
URI的作用像身份證號一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的信息。
7. HTTP 和 HTTPS 的區別？
- 端口 ：HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。
- 安全性和資源消耗： HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。
- 費用：https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
8. 狀態碼
2XX——表明請求被正常處理了
3XX——表明瀏覽器需要執行某些特殊的處理以正確處理請求
當301,302,303響應狀態碼返回時，幾乎所有的瀏覽器都會把POST改成GET，并刪除請求報文內的主體，之后請求會自動再次發送。
4XX——表明客戶端是發生錯誤的原因所在
5XX——服務器本身發生錯誤
9. HTTP長連接,短連接
在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協議的長連接和短連接。
HTTP長連接、短連接究竟是什么？
10. HTTP是不保存狀態的協議,如何保存用戶狀態?
HTTP 是一種不保存狀態，即無狀態（stateless）協議。也就是說 HTTP 協議自身不對請求和響應之間的通信狀態進行保存。那么我們保存用戶狀態呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是通過服務端記錄用戶的狀態。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了（一般情況下，服務器會在一定時間內保存這個 Session，過了時間限制，就會銷毀這個Session）。
在服務端保存 Session 的方法很多，最常用的就是內存和數據庫(比如是使用內存數據庫redis保存)。既然 Session 存放在服務器端，那么我們如何實現 Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。
Cookie 被禁用怎么辦?
最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。
11. Cookie的作用是什么?和Session有什么區別？
Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式，但是兩者的應用場景不太一樣。
Cookie 一般用來保存用戶信息 比如①我們在 Cookie 中保存已經登錄過得用戶信息，下次訪問網站的時候頁面可以自動幫你登錄的一些基本信息給填了；②一般的網站都會有保持登錄也就是說下次你再訪問網站的時候就不需要重新登錄了，這是因為用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據 Token 值來查找用戶即可(為了安全考慮，重新登錄一般要將 Token 重寫)；③登錄一次網站后訪問網站其他頁面不需要重新登錄。Session 的主要作用就是通過服務端記錄用戶的狀態。 典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了。
Cookie 數據保存在客戶端(瀏覽器端)，Session 數據保存在服務器端。
Cookie 存儲在客戶端中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。
12. HTTP 1.0和HTTP 1.1的主要區別是什么?
這部分回答引用這篇文章 https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A? 的一些內容。
HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用于現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在：
13. 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請求則是沒有大小限制的。
還會補充----------------------
總結
