計算機網路面試題（超詳細整理）

計算機網路的體系結構

應用層

應用層用來規定應用行程在通信時所遵循的協議，應用層的許多協議都是基于客戶服務器方式，客戶 (client) 和服務器 (server) 都是指通信中所涉及的兩個應用行程，客戶服務器方式所描述的是行程之間服務和被服務的關系，客戶是服務請求方，服務器是服務提供方，傳輸的是報文，

涉及到的協議：
域名系統 DNS：將域名和 IP 地址相互映射的一個分布式資料庫，能夠使人更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的 IP 數串，
HTTP協議：超文本傳輸協議，所有的萬維網檔案都必須遵守這個標準，設計 HTTP 最初的目的是為了提供一種發布和接收 HTML 頁面的方法，
郵件傳輸協議：SMTP

運輸層

只有位于網路邊緣部分的主機的協議堆疊才有運輸層，和網路層不同，網路層是為主機之間提供邏輯通信，而運輸層為應用行程之間提供通用的資料傳輸服務（端到端的服務），運輸層擁有流量控制（防止過載，即過多的資料注入到網路中），擁塞控制（抑制資料傳輸的速率）等功能，為上層協議提供端到端的可靠和透明的資料傳輸服務,上層服務用戶不必關系通信子網的實作細節，

運輸層主要使用以下兩種協議：

• 傳輸控制協議 TCP：面向連接的協議，提供可靠的資料傳輸服務，
• 用戶資料報協議 UDP：無連接的協議，不提供可靠交付，

運行在TCP協議上的協議：

HTTP（Hypertext Transfer Protocol，超文本傳輸協議）Web服務器傳輸超文本到本地瀏覽器的傳送協議，埠：80
HTTPS（HTTP over SSL，安全超文本傳輸協議）,HTTP協議的安全版本，埠：443
FTP（File Transfer Protocol，檔案傳輸協議），用于檔案傳輸，埠：21
SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議），用來發送電子郵件，埠：25
SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陸用，

運行在UDP協議上的協議：

DNS（Domain Name Service，域名服務），用于完成地址查找，郵件轉發等作業，
SNMP（Simple Network Management Protocol，簡單網路管理協議），用于網路資訊的收集和網路管理，
NTP（Network Time Protocol，網路時間協議），用于網路同步，
DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP地址，

網路層

網路層采用了IP資料報服務：通過IP尋址來建立兩個節點之間的連接，之后把運輸層產生的報文段或用戶資料報封裝成分組和包進行傳送，在發送分組時不需要先建立連接，每一個分組獨立發送，與其前后的分組無關，在這個程序中網路層不提供端到端的可靠傳輸服務，盡最大努力進行交付（由網路的主機中的運輸層負責可靠交付），

網際協議 IP 是 TCP/IP 體系中兩個最主要的協議之一，與 IP 協議配套使用的還有三個協議：

• 地址決議協議 ARP (Address Resolution Protocol)
• 網際控制報文協議 ICMP (Internet Control Message Protocol)
• 網際組管理協議 IGMP (Internet Group Management Protocol)

ARP（Address Resolution Protocol，地址決議協議），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查詢失敗，

資料鏈路層

資料鏈路層：兩臺設備之間的資料傳輸，可以看成是在一條管道上進行的，傳送的資料單位是幀（每一幀包括資料和必要的控制資訊（如同步資訊，地址資訊，差錯控制等）），鏈路層保證被傳輸資料的正確性，

三個問題：

• 封裝成幀 ：就是在一段資料的前后分別添加首部和尾部，然后就構成了一個幀，首部和尾部的一個重要作用就是進行幀定界，
• 透明傳輸：在資料傳輸程序中，如果資料中的某個位元組的二進制代碼恰好和 SOH 或 EOT 一樣，資料鏈路層就會錯誤地“找到幀的邊界”從而導致這些資料都能夠按照原樣沒有差錯地通過這個資料鏈路層，解決透明傳輸問題：字符填充 (插入轉義字符)
• 差錯檢測：在傳輸程序中可能會產生位元差錯：1 可能會變成 0， 而 0 也可能變成 1，在一段時間內，傳輸錯誤的位元占所傳輸位元總數的比率稱為誤碼率 BER (Bit Error Rate)，誤碼率與信噪比有很大的關系，為了保證資料傳輸的可靠性，在計算機網路傳輸資料時，必須采用各種差錯檢測措施，在資料鏈路層傳送的幀中，廣泛使用了回圈冗余檢驗 CRC 的檢錯技術，

物理層

物理層考慮的是怎樣才能在連接各種計算機的傳輸媒體上傳輸資料位元流，它的作用是要盡可能地屏蔽掉不同傳輸媒體和通信手段的差異，使上層的資料鏈路層不必考慮網路的具體傳輸介質是什么，傳輸的是位元

物理層的主要任務：確定與傳輸媒體的介面的一些特性（器件的相關特性，電壓范圍，以及對應的功能）

網路協議分層的好處？

• 簡化問題難度和復雜度，由于各層之間獨立，我們可以分割大問題為小問題，
• 靈活性好，當其中一層的技術變化時，只要層間介面關系保持不變，其他層不受影響，
• 易于實作和維護，
• 促進標準化作業，分開后，每層功能可以相對簡單地被描述

TCP與UDP

• TCP/IP即傳輸控制協議，是面向連接的協議，發送資料前要先建立連接，TCP提供可靠的服務，也就是說，通過TCP連接傳輸的資料不會丟失，沒有重復，并且按順序到達，（類似于打電話）
• UDP它是屬于TCP/IP協議族中的一種，是無連接的協議，發送資料前不需要建立連接，是沒有可靠性的協議，因為不需要建立連接所以可以在在網路上以任何可能的路徑傳輸，因此能否到達目的地，到達目的地的時間以及內容的正確性都是不能被保證的，（類似于發微信）

TCP的三次握手

在網路資料傳輸中，傳輸層協議TCP是要建立連接的可靠傳輸，TCP建立連接的程序，我們稱為三次握手，

三次握手的具體細節：客戶端向服務端發送SYN -> 服務端回傳SYN,ACK -> 客戶端發送ACK

• 圖中主機B的TCP 服務器行程先創建傳輸控制塊TCB，準備接受客戶行程的連接請求，
• 第一次握手：主機A 的 TCP 向 主機B 發出連接請求報文段，其首部中的同步位 SYN = 1，并選擇序號 seq = x，表明傳送資料時的第一個資料位元組的序號是 x，
• 第二次握手：主機B 的 TCP 收到連接請求報文段后，如同意，則發回確認，主機B 在確認報文段中應使 SYN = 1，使 ACK = 1，其確認號 ack = x + 1，自己選擇的序號 seq = y，
• 第三次握手：主機A 收到此報文段后向 主機B 給出確認，其 ACK = 1，確認號 ack = y + 1，主機A 的 TCP 通知上層應用行程，連接已經建立，主機B 的 TCP 收到主機 A 的確認后，也通知其上層應用行程：TCP 連接已經建立，
  

三次握手的目的是建立可靠的通信信道，主要的目的就是雙方確認自己與對方的發送與接識訓能正常，

• 第一次握手：客戶什么都不能確認；服務器確認了對方發送正常
• 第二次握手：客戶確認了：自己發送、接收正常，對方發送、接收正常；服務器確認 了：自己接收正常，對方發送正常
• 第三次握手：客戶確認了：自己發送、接收正常，對方發送、接收正常；服務器確認 了：自己發送、接收正常，對方發送接收正常 所以三次握手就能確認雙發收發功能都正常，缺一不可，

如果已經建立了連接，但客戶端出現了故障怎么辦？
保活計時器：用來防止在TCP連接出現長時期的空閑，服務器每收到一次客戶端的請求后都會重新復位一個計時器，時間通常是設定為2小時，若服務器過了2小時還沒有收到客戶的資訊，它就發送探測報文段，若發送了10個探測報文段（每一個相隔75秒）還沒有回應，就假定客戶出了故障，因而就終止該連接，

什么是TCP的四次揮手

資料傳輸結束后，通信的雙方都可釋放連接，我們將釋放連接的程序我們稱為四次揮手：

四次揮手的具體細節

• 第一次揮手：主機A 的應用行程先向其 TCP 發出連接釋放報文段，并停止再發送資料，主動關閉 TCP 連接，主機A 把連接釋放報文段首部的FIN = 1，其序號seq = u，等待 B 的確認（FIN_WAIT_1狀態），
• 第二次揮手：主機B 發出確認，發送一個ACK=1，確認號 ack = u+1，而這個報文段自己的序號 seq = v，TCP 服務器行程通知高層應用行程，從主機A 到主機B 這個方向的連接就釋放了，TCP 連接處于CLOSE_WAIT狀態，此時主機B 若發送資料，主機A 仍要接收，
• 第三次揮手：主機B 確認已經沒有要向主機A 發送的資料，將FIN置1，其應用行程就通知 TCP 釋放連接，
• 第四次揮手：主機A 收到連接釋放報文段后，進入TIME_WAIT狀態，必須發出確認， 在確認報文段中ACK = 1，確認號 ack = w + 1，自己的序號 seq = u + 1，主機B收到后，確認ack后，變為CLOSED狀態，不再向客戶端發送資料，客戶端等待2*MSL（報文段最長壽命）時間后，也進入CLOSED狀態，完成四次揮手，

簡單理解：四次揮手，雙方都確認對方關閉

• 客戶對服務器發送了關閉連接請求，
• 服務器收到客戶的關閉連接請求后，回復一個確認收到的訊息
• 服務器確定不再給客戶發訊息后，對客戶發送，準備關閉連接的訊息
• 客戶收到服務器要關閉連接的訊息給服務器發送：已收到關閉連接的訊息，

為什么不能把服務器發送的ACK和FIN合并起來，變成三次揮手（CLOSE_WAIT狀態意義是什么）？
因為服務器收到客戶端斷開連接的請求時，可能還有一些資料沒有發完，這時先回復ACK，表示接收到了斷開連接的請求，等到資料發完之后再發FIN，斷開服務器到客戶端的資料傳送，

如果第二次揮手時服務器的ACK沒有送達客戶端，會怎樣？
客戶端沒有收到ACK確認，會重新發送FIN請求，

客戶端TIME_WAIT狀態的意義是什么？
兩個問題：

• 主機A 發送的最后一個 ACK 報文段可能沒有到達主機B（丟失）、
• 已失效的連接請求報文段可能出現在本連接中

TIME_WAIT狀態用來重發可能丟失的ACK報文，如果服務端沒有收到ACK，就會重發FIN，如果客戶端在2*MSL的時間內收到了FIN，就會重新發送ACK并再次等待2MSL，防止Server沒有收到ACK而不斷重發FIN，

MSL(MaximumSegment Lifetime)，指一個片段在網路中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間，如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，則結束TCP連接，

TCP 協議如何保證可靠傳輸

• 停止等待：每發完一個分組就停止發送，等待對方確認，在收到確認后再發下一個分組，
• 超時重傳：當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段，如果不能及時收到一個確認，將重發這個報文段；
• 流量控制：TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許另一端發送接收端緩沖區所能接納的資料，這可以防止較快主機致使較慢主機的緩沖區溢位，這就是流量控制，TCP使用的流量控制協議是可變大小的滑動視窗協議，
• 擁塞控制： 當網路擁塞時，可能會造成網路的擁堵，甚至網路癱瘓，TCP會減少資料的發送，
• 資料包校驗：TCP 將保持它首部和資料的檢驗和，這是一個端到端的檢驗和，目的是檢測資料在傳輸程序中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出回應，這時TCP發送資料端超時后會重發資料；
• 對失序資料包重排序：既然TCP報文段作為IP資料報來傳輸，而IP資料報的到達可能會失序，因此TCP報文段的到達也可能會失序，TCP給發送的每一個包進行編號，接收方對資料包進行排序，把有序資料傳送給應用層，
• 應答機制：當TCP收到發自TCP連接另一端的資料，它將發送一個確認，這個確認不是立即發送，通常將推遲幾分之一秒；
• 丟棄重復資料：TCP 的接收端會丟棄重復的資料，

TCP擁塞控制？

擁塞控制是防止過多的資料注入網路，使得網路中的路由器或者鏈路過載，流量控制是點對點的通信量控制，而擁塞控制是全域的網路流量整體性的控制，發送雙方都有一個擁塞視窗（cwnd），

• 慢開始：最開始發送方的擁塞視窗為1，由小到大遞增，每經過一個傳輸輪次，擁塞視窗cwnd加倍（乘2），當cwnd超過慢開始門限，則使用擁塞避免演算法，避免cwnd增長過長，
• 擁塞避免（演算法）：當cwnd超過慢開始門限，每經過一個往返時間RTT，cwnd就增長1，在慢開始和擁塞避免程序中，一旦發現網路擁塞，就把慢開始門限設定為當前值的一半，并且重新設定cwnd為1，重新慢啟動，
• 快重傳：接收方每收到一個失序的報文段后就立即發出重復確認，發送方只要收到3個重復確認就立即重傳，
• 快恢復：當發送方連續收到三個重復確認，就將慢開始門限減半，將當前的視窗設定為慢開始門限，并采用擁塞避免演算法，（采用快恢復演算法時，慢開始只在建立連接和網路超時時才使用）

什么是Http協議？

HTTP是一個基于TCP/IP通信協議來傳遞資料的協議，HTTP協議作業于客戶端-服務端架構之上，實作可靠性的傳輸文字、圖片、音頻、視頻等超文本資料的規范，格式簡稱為“超文本傳輸協議”，Http協議屬于應用層，用戶訪問的第一層就是http，

特點：

• ①簡單快速：客戶端向服務器發送請求時，只需傳送請求方法和路徑即可，
• ②靈活：HTTP允許傳輸任意型別的資料物件，
• ③無連接：限制每次連接只處理一個請求，服務器處理完客戶請求，并收到客戶應答后，即斷開連接，
• ④無狀態：協議對于事務處理沒有記憶能力，
• ⑤支持B/S及C/S模式，

Http和Https的區別？

• 埠不同：Http是80，Https443
• 安全性：http是超文本傳輸協議，資訊是明文傳輸，https則是通過SSL加密處理的傳輸協議，更加安全，
• 是否付費：https需要拿到CA證書，需要付費
• 連接方式：http和https使用的是完全不同的連接方式（HTTP的連接很簡單，是無狀態的；HTTPS 協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全，）

HTTPS傳輸程序中使用密鑰加密，安全性更高，但是收費，而且多了一層SSL延時也會有所提高，

HTTPS作業原理

• 首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；
• 客戶端如果校驗通過后，就根據證書的公鑰的有效， 生成亂數，亂數使用公鑰進行加密（RSA加密）；
• 訊息體產生的后，對它的摘要進行MD5（或者SHA1）演算法加密，此時就得到了RSA簽名；
• 發送給服務端，此時只有服務端（RSA私鑰）能解密，
• 解密得到的亂數，再用AES加密，作為密鑰（此時的密鑰只有客戶端和服務端知道），

加密演算法

加密演算法：對資訊進行編碼和解碼的技術，編碼是把原來可讀資訊（又稱明文）譯成代碼形式（又稱密文），其逆程序就是解碼（解密），

加密技術的要點是加密演算法，加密演算法可以分為三類：

對稱加密，如 AES
基本原理：將明文分成 N 個組，然后使用密鑰對各個組進行加密，形成各自的密文，最后把所有的分組密文進行合并，形成最終的密文，
優點：演算法公開、計算量小、加密速度快、加密效率高
缺點：雙方都使用同樣密鑰，安全性得不到保證

非對稱加密，如 RSA
基本原理：同時生成兩把密鑰：私鑰和公鑰，私鑰隱秘保存，公鑰可以下發給信任客戶端
私鑰加密，持有私鑰或公鑰才可以解密
公鑰加密，持有私鑰才可解密
優點：安全，難以破解
缺點：演算法比較耗時

不可逆加密，如 MD5，SHA
基本原理：加密程序中不需要使用密鑰，輸入明文后由系統直接經過加密演算法處理成密文，這種加密后的資料是無法被解密的，無法根據密文推算出明文，

一次完整的HTTP請求所經歷幾個步驟?

HTTP協議采用請求/回應模型，客戶端向服務器發送一個請求報文，請求報文包含請求方法、URL、協議版本、請求頭部和請求資料，服務器以一個狀態行作為回應，回應內容包括協議版本、成功或者錯誤的代碼、服務器資訊、回應頭部和回應資料，

Web瀏覽器與Web服務器之間將完成下列7個步驟：

• 建立TCP連接，三次握手
• Web瀏覽器向Web服務器發送請求行
• Web瀏覽器發送請求頭，瀏覽器發送其請求命令之后，還要以頭資訊的形式向Web服務器發送一些別的資訊，之后瀏覽器發送了一空白行來通知服務器，它已經結束了該頭資訊的發送，
• Web服務器應答：客戶機向服務器發出請求后，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼，
• Web服務器發送應答頭：正如客戶端會隨同請求發送關于自身的資訊一樣，服務器也會隨同應答向用戶發送關于它自己的資料及被請求的檔案，
• Web服務器向瀏覽器發送資料：Web服務器向瀏覽器發送頭資訊后，它會發送一個空白行來表示頭資訊的發送到此為結束，接著，它就以Content-Type應答頭資訊所描述的格式發送用戶所請求的實際資料，
• Web服務器關閉TCP連接

什么是http的請求體？
HTTP請求體是我們請求資料時先發送給服務器的資料，畢竟我向服務器拿資料，先要表明我要什么吧，HTTP請求體由：請求行 、請求頭、請求資料組成的，

http的回應報文有哪些？
http的回應報是服務器回傳給我們的資料，必須先有請求體再有回應報文.回應報文包含三部分： 狀態行、回應首部欄位、回應內容物體實作

輸入網址到獲取頁面的程序？

• 瀏覽器搜索自身的DNS快取、搜索作業系統的DNS快取、讀取本地的Host檔案和向本地DNS服務器進行查詢等，
• 對于向本地DNS服務器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則回傳決議結果給客戶機，完成域名決議(此決議具有權威性)；如果要查詢的域名不由本地DNS服務器區域決議，但該服務器已快取了此網址映射關系，則呼叫這個IP地址映射，完成域名決議（此決議不具有權威性），如果本地域名服務器并未快取該網址映射關系，那么將根據其設定發起遞回查詢或者迭代查詢；
• 瀏覽器獲得域名對應的IP地址以后，瀏覽器向服務器請求建立鏈接，發起三次握手；
• TCP/IP鏈接建立起來后，瀏覽器向服務器發送HTTP請求；
• 服務器接收到這個請求，并根據路徑引數映射到特定的請求處理器進行處理，并將處理結果及相應的視圖回傳給瀏覽器；
• 瀏覽器決議并渲染視圖，若遇到對js檔案、css檔案及圖片等靜態資源的參考，則重復上述步驟并向服務器請求這些資源；
• 瀏覽器根據其請求到的資源、資料渲染頁面，最終向用戶呈現一個完整的頁面

http版本的對比

HTTP1.0版本的特性：
早先1.0的HTTP版本，是一種無狀態、無連接的應用層協議，（短連接）
HTTP1.0規定瀏覽器和服務器保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器處理完成后立即斷開TCP連接（無連接），服務器不跟蹤每個客戶端也不記錄過去的請求（無狀態），

HTTP1.1版本新特性（長連接）：
默認持久連接節省通信量，只要客戶端服務端任意一端沒有明確提出斷開TCP連接，就一直保持連接，可以發送多次HTTP請求管線化，客戶端可以同時發出多個HTTP請求，而不用一個個等待回應斷點續傳原理

HTTP2.0版本的特性：

• 二進制分幀（采用二進制格式的編碼將其封裝）
• 首部壓縮（設定了專門的首部壓縮設計的HPACK演算法，）
• 流量控制（設定了接收某個資料流的多少位元組一些流量控制）
• 多路復用（可以在共享TCP鏈接的基礎上同時發送請求和回應）
• 請求優先級（可以通過優化這些幀的交錯和傳輸順序進一步優化性能）
• 服務器推送（就是服務器可以對一個客戶端請求發送多個回應，服務器向客戶端推送資源無需客戶端明確的請求，（重大更新））

常用HTTP狀態碼是怎么分類的，有哪些常見的狀態碼？

HTTP狀態碼表示客戶端HTTP請求的回傳結果、標識服務器處理是否正常、表明請求出現的錯誤等，狀態碼的類別：

常用狀態碼：
200： 請求被正常處理
204： 請求被受理但沒有資源可以回傳
301： 永久性重定向
302： 臨時重定向
304： 已快取
400： 請求報文語法有誤，服務器無法識別
403： 請求的對應資源禁止被訪問
404： 服務器無法找到對應資源
500： 服務器內部錯誤
503： 服務器正忙

HTTP協議中的請求方式

• GET：用于請求訪問已經被URI（統一資源識別符號）識別的資源，可以通過URL傳參給服務器
• POST：用于傳輸資訊給服務器，主要功能與GET方法類似，但一般推薦使用POST方式，
• PUT： 傳輸檔案，報文主體中包含檔案內容，保存到對應URI位置，
• HEAD：獲得報文首部，與GET方法類似，只是不回傳報文主體，一般用于驗證URI是否有效，
• PATCH： 客戶端向服務器傳送的資料取代指定的檔案的內容(部分取代)
• TRACE： 回顯客戶端請求服務器的原始請求報文，用于"回環"診斷
• DELETE： 洗掉檔案，與PUT方法相反，洗掉對應URI位置的檔案，
• OPTIONS： 查詢相應URI支持的HTTP方法，

GET方法與POST方法的區別

• 功能上： GET一般用來從服務器上獲取資源，POST一般用來更新服務器上的資源；
• 安全性： GET是不安全的，因為GET請求提交的資料將明文出現在URL上（請求頭上），可能會泄露私密資訊；POST請求引數則被包裝到請求體中，相對更安全，
• 資料量： Get傳輸的資料量小，因為受URL長度限制，但效率較高； Post可以傳輸大量資料，所以上傳檔案時只能用Post方式；

Session 與 Cookie 的對比

cookie：cookie是由Web服務器保存在用戶瀏覽器上的檔案（key-value格式），可以包含用戶相關的資訊，客戶端向服務器發起請求時，會攜帶服務器端之前創建的cookie，服務器端通過cookie中攜帶的資料區分不同的用戶，

session：session 是瀏覽器和服務器會話程序中，服務器會分配的一塊儲存空間給session，服務器默認會為客戶瀏覽器的cookie中設定 sessionid，這個sessionid就和cookie對應，瀏覽器在向服務器請求程序中傳輸的cookie 包含 sessionid ，服務器根據傳輸cookie 中的 sessionid 獲取出會話中存盤的資訊，然后確定會話的身份資訊，

• 安全性：cookie資料存放在客戶端上，安全性較差，session資料放在服務器上，安全性相對更高
• 大小限制：cookie有大小限制，單個cookie保存的資料不能超過4K，session無此限制，理論上只與服務器的記憶體大小有關；
• 服務器資源消耗：Session是保存在服務器端上會存在一段時間才會消失，當訪問增多，對服務器性能有影響
• 實作機制：Session的實作常常依賴于Cookie機制，通過Cookie機制回傳SessionID；

HTTP協議本身是無法判斷用戶身份，所以需要cookie或者session