OSI七層模型、五層模型、TCP/IP四層模型

OSI分層（7層）：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。

TCP/IP分層（4層）：網絡接口層、網際層、運輸層、應用層。

五層協議（5層）：物理層、數據鏈路層、網絡層、運輸層、應用層。

每一層的協議如下：

物理層：RJ45、CLOCK、IEEE802.3 （中繼器，集線器）

數據鏈路：PPP、FR、HDLC、VLAN、MAC （網橋，交換機）

網絡層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、（路由器）

傳輸層：TCP、UDP、SPX

會話層：NFS、SQL、NETBIOS、RPC

表示層：JPEG、MPEG、ASII

應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

每一層的作用如下：

物理層：通過媒介傳輸比特,確定機械及電氣規範（比特Bit）

數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）

網絡層：負責數據包從源到宿的傳遞和網際互連（包PackeT）

傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）

會話層：建立、管理和終止會話（會話協議數據單元SPDU）

表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）

應用層：允許訪問OSI環境的手段（應用協議數據單元APDU）

三次握手(爲什麼不是兩次、爲什麼不是四次)

所謂三次握手(Three-way Handshake)，是指建立一個TCP連接時，需要客戶端和服務器總共發送3個包。

三次握手的目的是連接服務器指定端口，建立TCP連接,並同步連接雙方的序列號和確認號並交換 TCP 窗口大小信息.在socket編程中，客戶端執行connect()時。將觸發三次握手。

（1）首先客戶端向服務器端發送一段TCP報文，其中：

標記位爲SYN，表示“請求建立新連接”;序號爲Seq=X（X一般爲1）；
隨後客戶端進入SYN-SENT階段。

（2）服務器端接收到來自客戶端的TCP報文之後，結束LISTEN階段。並返回一段TCP報文，其中：

標誌位爲SYN和ACK，表示“確認客戶端的報文Seq序號有效，服務器能正常接收客戶端發送的數據，並同意創建新連接”（即告訴客戶端，服務器收到了你的數據）；
序號爲Seq=y；
確認號爲Ack=x+1，表示收到客戶端的序號Seq並將其值加1作爲自己確認號Ack的值；隨後服務器端進入SYN-RCVD階段。

（3）客戶端接收到來自服務器端的確認收到數據的TCP報文之後，明確了從客戶端到服務器的數據傳輸是正常的，結束SYN-SENT階段。並返回最後一段TCP報文。其中：

標誌位爲ACK，表示“確認收到服務器端同意連接的信號”（即告訴服務器，我知道你收到我發的數據了）；
序號爲Seq=x+1，表示收到服務器端的確認號Ack，並將其值作爲自己的序號值；
確認號爲Ack=y+1，表示收到服務器端序號Seq，並將其值加1作爲自己的確認號Ack的值；
隨後客戶端進入ESTABLISHED階段。

服務器收到來自客戶端的“確認收到服務器數據”的TCP報文之後，明確了從服務器到客戶端的數據傳輸是正常的。結束SYN-SENT階段，進入ESTABLISHED階段。

在客戶端與服務器端傳輸的TCP報文中，雙方的確認號Ack和序號Seq的值，都是在彼此Ack和Seq值的基礎上進行計算的，這樣做保證了TCP報文傳輸的連貫性。一旦出現某一方發出的TCP報文丟失，便無法繼續"握手"，以此確保了"三次握手"的順利完成。

三次握手建立連接時，發送方再次發送確認的必要性？

主要是爲了防止已失效的連接請求報文段突然又傳到了B,因而產生錯誤。假定出現一種異常情況，即A發出的第一個連接請求報文段並沒有丟失，而是在某些網絡結點長時間滯留了，一直延遲到連接釋放以後的某個時間纔到達B，本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段後，就誤認爲是A又發出一次新的連接請求，於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立了，這樣一直等待A發來數據，B的許多資源就這樣白白浪費了。

四次揮手（爲什麼是四次揮手不是三次）

TCP的連接的拆除需要發送四個包，因此稱爲四次揮手(four-way handshake)。客戶端或服務器均可主動發起揮手動作，在socket編程中，任何一方執行close()操作即可產生揮手操作。

（1）首先客戶端想要釋放連接，向服務器端發送一段TCP報文，其中：

標記位爲FIN，表示“請求釋放連接“；
序號爲Seq=U；
隨後客戶端進入FIN-WAIT-1階段，即半關閉階段。並且停止在客戶端到服務器端方向上發送數據，但是客戶端仍然能接收從服務器端傳輸過來的數據。

注意：這裏不發送的是正常連接時傳輸的數據(非確認報文)，而不是一切數據，所以客戶端仍然能發送ACK確認報文。

（2）服務器端接收到從客戶端發出的TCP報文之後，確認了客戶端想要釋放連接，隨後服務器端結束ESTABLISHED階段，進入CLOSE-WAIT階段（半關閉狀態）並返回一段TCP報文，其中：

標記位爲ACK，表示“接收到客戶端發送的釋放連接的請求”；序號爲Seq=V；
確認號爲Ack=U+1，表示是在收到客戶端報文的基礎上，將其序號Seq值加1作爲本段報文確認號Ack的值；
隨後服務器端開始準備釋放服務器端到客戶端方向上的連接。客戶端收到從服務器端發出的TCP報文之後，確認了服務器收到了客戶端發出的釋放連接請求，隨後客戶端結束FIN-WAIT-1階段，進入FIN-WAIT-2階段

前"兩次揮手"既讓服務器端知道了客戶端想要釋放連接，也讓客戶端知道了服務器端了解了自己想要釋放連接的請求。於是，可以確認關閉客戶端到服務器端方向上的連接了

（3）服務器端自從發出ACK確認報文之後，經過CLOSED-WAIT階段，做好了釋放服務器端到客戶端方向上的連接準備，再次向客戶端發出一段TCP報文，其中：

標記位爲FIN，ACK，表示“已經準備好釋放連接了”。注意：這裏的ACK並不是確認收到服務器端報文的確認報文。
序號爲Seq=W；
確認號爲Ack=U+1；表示是在收到客戶端報文的基礎上，將其序號Seq值加1作爲本段報文確認號Ack的值。

隨後服務器端結束CLOSE-WAIT階段，進入LAST-ACK階段。並且停止在服務器端到客戶端的方向上發送數據，但是服務器端仍然能夠接收從客戶端傳輸過來的數據。

（4）客戶端收到從服務器端發出的TCP報文，確認了服務器端已做好釋放連接的準備，結束FIN-WAIT-2階段，進入TIME-WAIT階段，並向服務器端發送一段報文，其中：

標記位爲ACK，表示“接收到服務器準備好釋放連接的信號”。
序號爲Seq=U+1；表示是在收到了服務器端報文的基礎上，將其確認號Ack值作爲本段報文序號的值。
確認號爲Ack=W+1；表示是在收到了服務器端報文的基礎上，將其序號Seq值作爲本段報文確認號的值。

隨後客戶端開始在TIME-WAIT階段等待2MSL

爲什麼等待2MSL？

當客戶端發出最後的ACK確認報文時，並不能確定服務器端能夠收到該段報文。所以客戶端在發送完ACK確認報文之後，會設置一個時長爲2MSL的計時器。

爲什麼四次揮手

建立連接的時候，服務器在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。

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

保活計時器

目的：主要是爲了防止兩個TCP連接出現長時間的空閒。當客戶端與服務器端建立TCP連接後，很長時間內客戶端都沒有向服務器端發送數據，此時很有可能是客戶端出現故障，而服務器端會一直處於等待狀態。保活計時器就是解決這種問題而生的。
工作原理：每當服務器端收到客戶端的數據時，都將保活計時器重新設置（通常設置爲2小時）。過了2小時後，服務器端如果沒有收到客戶端的數據，會發送探測報文段給客戶端，並且每隔75秒發送一個，當連續發送10次以後，仍沒有收到對端的來信，則服務器端認爲客戶端出現故障，並會終止連接。

TCP中的四個計時器包括重傳計時器、堅持計時器、保活計時器、時間等待計時器

確認應答機制（ACK）

TCP通過確認應答機制實現可靠的數據傳輸。在TCP的首部中有一個標誌位——ACK，此標誌位表示確認號是否有效。接收方對於按序到達的數據會進行確認，當標誌位ACK=1時確認首部的確認字段有效。進行確認時，確認字段值表示這個值之前的數據都已經按序到達了。而發送方如果收到了已發送的數據的確認報文，則繼續傳輸下一部分數據；而如果等待了一定時間還沒有收到確認報文就會啓動重傳機制。

滑動窗口

發送窗口：在任意時刻，發送發都維持一組連續的允許發送的幀的序號，稱爲發送窗口。
接收窗口：發送窗口用來對發送方進行流量控制，而發送窗口的大小 W 代表在還沒有收到對方確認信息的情況下發送方最多還可以發送多少個數據幀。

在接收端設置接收窗口是爲了控制可以接受哪些數據幀而不可以接收哪些幀。在接收方只有當收到的數據幀的序號落入接收窗口內才允許將該數據幀手下。若接收到的數據幀落在了接收窗口之外，則一律將其丟棄。

在發送端，每收到一個確認幀，發送窗口就向前滑動一個幀的位置，當發送窗口內沒有可以發送的幀（即窗口內全部是已發送，但未接收到確認的幀），發送方就會停止發送，直到收到接收方發送的確認幀使窗口移動，窗口內有可以發送的幀，之後纔開始繼續發送。

滑動窗口的分類

停止等待、後退N幀、選擇重傳。他們之間主要的區別就是：發送窗口和接收窗口大小的區別。

停止等待協議：發送窗口大小 = 1，接收窗口大小= 1
後退N幀協議：發送窗口大小 > 1，接收窗口大小 = 1
選擇重傳協議：發送窗口大小 > 1，接收窗口大小 > 1

停止等待協議

規則：源站發送單個幀後就必須等待確認，在目的站的回答到達源站之前，源站不能發送其他的數據幀

在停止等待協議中，除了數據丟失的問題，還有可能存在以下兩種差錯：

1.到達目的站的數據幀可能遭到破壞。

解決辦法：源站在發送一個幀後，就爲這個幀裝一個計時器，在一個幀發送之後，源站等待確認，如果在計時器時間到達時未收到確認，則再次發送相同的幀。

2.數據幀正確，但是卻認真沒有收到

此時接收方已經收到了正確的數據幀，但是發送方收不到卻認真，因此發送方會重傳已經被接收的數據幀，接收方收到同樣的數據幀就會丟棄該幀，並重傳一個該幀對應的卻認真。

【總結】

【1】接收方收到相同的數據：發送方超時重傳
【2】發送方收到相同的確認幀：發送方發送了重複的數據
【3】接收窗口大小 = 1，發送窗口大小 = 1

後退N幀

發送方不需要在收到上一幀的ACK後才能開始發送下下一幀，而是可以連續發送幀。當接收方檢測出失序的信息幀之後，要求發送方重發最後一個正確信息幀之後的所有未被確認的幀；或者當發送方發送了N個幀之後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認信息，則該幀被判定爲出錯或者丟失，此時發送方就不得不重傳該出錯幀及之後的N個幀。

注意：接收方只允許按照順序接受幀。

爲了減少開銷，後退N幀協議還規定接收端不一定每收到一個正確的數據幀就必須立即發回一個卻認真，而是可以在連續收到好幾個正確的數據幀後，纔對最後一個數據幀發送確認信息，或者可以在當自己有數據要發送的時候纔將對以前正確收到的幀加以捎帶確認。

選擇重傳

只重傳出現差錯的數據幀或者是計時器超時的數據幀。每一個發送緩衝區對應一個計時器，當計時器超時的時候，緩衝區的幀就會重傳。另外，該協議使用了比上述其他協議更有效的差錯處理策略，即一旦接收方懷疑幀出錯，就會發送一個否定幀NAK給發送方，要求發送方對NAK中制定的幀進行重傳。

https://blog.csdn.net/xiaojie_570/article/details/87904328

超時重傳機制（去重機制、快重傳）

當報文發出後在一定的時間內未收到接收方的確認，發送方就會進行重傳（通常是在發出報文段後設定一個鬧鐘，到點了還沒有收到應答則進行重傳）

未收到確認不一定就是發送的數據包丟了，還可能是確認的ACK丟了：

當接收方接收到重複的數據時就將其丟掉，重新發送ACK。而要識別出重複的數據，就要用到序列號了，利用序列號很容易就可以做到去重的效果。
重傳時間的確定：報文段發出到收到應答中間有一個報文段的往返時間RTT，顯然超時重傳時間RTO會略大於這個RTT，TCP會根據網絡情況動態的計算RTT，即RTO是不斷變化的。在Linux中，超時以500ms爲單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍。其規律爲：如果重發一次仍得不到應答，就等待2*500ms後再進行重傳，如果仍然得不到應答就等待4*500ms後重傳，依次類推，以指數形式遞增，重傳次數累計到一定次數後，TCP認爲網絡或對端主機出現異常，就會強行關閉連接。

流量控制

如果發送者發送數據過快，接收者來不及接收，那麼就會有分組丟失。爲了避免分組丟失，控制發送者的發送速度，使得接收者來得及接收，這就是流量控制。流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。

在TCP報文段首部中有一個16位窗口長度，當接收端接收到發送方的數據後，在應答報文ACK中就將自身緩衝區的剩餘大小，放入16窗口大小中。這個大小隨數據傳輸情況而變，窗口越大，網絡吞吐量越高，而一旦接收方發現自身的緩衝區快滿了，就將窗口設置爲更小的值通知發送方。如果緩衝區滿，就將窗口置爲0，發送方收到後就不再發送數據，但是需要定期發送一個窗口探測數據段，使接收端把窗口大小告訴發送端。

注意：窗口大小不受16位窗口大小限制，在TCP首部40字節選項中還包含一個窗口擴大因子M，實際窗口大小是窗口字段的值左移M位。

擁塞控制（慢啓動、擁塞窗口）

TCP的四種擁塞控制算法
1.慢開始
2.擁塞控制
3.快重傳
4.快恢復

TCP可靠性保證的機制

檢驗和
序列號
確認應答機制（ACK）
超時重傳機制
連接管理機制：即TCP建立連接時的三次握手和斷開連接時的四次揮手。
流量控制
擁塞控制

https://blog.csdn.net/xuzhangze/article/details/80490362

TCP與UDP的區別

	UDP	TCP
是否連接	無連接	面向連接
是否可靠	不可靠傳輸，不使用流量控制和擁塞控制	可靠傳輸，使用流量控制和擁塞控制
連接對象個數	支持一對一，一對多，多對一和多對多交互通信	只能是一對一通信
傳輸方式	面向報文	面向字節流
首部開銷	首部開銷小，僅8字節	首部最小20字節，最大60字節
適用場景	適用於實時應用（IP電話、視頻會議、直播等）	適用於要求可靠傳輸的應用，例如文件傳輸

TCP向上層提供面向連接的可靠服務，UDP向上層提供無連接不可靠服務。
雖然 UDP 並沒有 TCP 傳輸來的準確，但是也能在很多實時性要求高的地方有所作爲
對數據準確性要求高，速度可以相對較慢的，可以選用TCP

Post與get區別

它們的本質都是 TCP 鏈接，並無區別。但是由於 HTTP 的規定以及瀏覽器/服務器的限制，導致它們在應用過程中可能會有所不同。

GET在瀏覽器回退時是無害的，而POST會再次提交請求。

GET產生的URL地址可以被Bookmark，而POST不可以。

GET請求會被瀏覽器主動cache（緩存），而POST不會，除非手動設置。

GET請求只能進行url編碼，而POST支持多種編碼方式。

GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

GET請求在URL中傳送的參數是有長度限制的，而POST麼有。

對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

GET比POST更不安全，因爲參數直接暴露在URL上，所以不能用來傳遞敏感信息。

GET參數通過URL傳遞，POST放在Request body中。

GET和POST都是TCP鏈接。GET產生一個TCP數據包；而POST會產生兩個TCP數據包。

http與https

Http：超文本傳輸協議（Http，HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。設計Http最初的目的是爲了提供一種發佈和接收HTML頁面的方法。它可以使瀏覽器更加高效。Http協議是以明文方式發送信息的，如果黑客截取了Web瀏覽器和服務器之間的傳輸報文，就可以直接獲得其中的信息。

Http原理：

① 客戶端的瀏覽器首先要通過網絡與服務器建立連接，該連接是通過TCP 來完成的，一般 TCP 連接的端口號是80。建立連接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是 MIME 信息包括請求修飾符、客戶機信息和許可內容。

② 服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是 MIME 信息包括服務器信息、實體信息和可能的內容。

HTTPS是以安全爲目標的Http通道，是Http的安全版。Https的安全基礎是SSL。SSL協議位於TCP/IP協議與各種應用層協議之間，爲數據通訊提供安全支持。

Https原理：

① 客戶端將它所支持的算法列表和一個用作產生密鑰的隨機數發送給服務器；

② 服務器從算法列表中選擇一種加密算法，並將它和一份包含服務器公用密鑰的證書發送給客戶端；該證書還包含了用於認證目的的服務器標識，服務器同時還提供了一個用作產生密鑰的隨機數；

③ 客戶端對服務器的證書進行驗證（有關驗證證書，可以參考數字簽名），並抽取服務器的公用密鑰；然後，再產生一個稱作 pre_master_secret 的隨機密碼串，並使用服務器的公用密鑰對其進行加密（參考非對稱加 / 解密），並將加密後的信息發送給服務器；

④ 客戶端與服務器端根據 pre_master_secret 以及客戶端與服務器的隨機數值獨立計算出加密和 MAC密鑰（參考 DH密鑰交換算法）；

⑤ 客戶端將所有握手消息的 MAC 值發送給服務器；

⑥ 服務器將所有握手消息的 MAC 值發送給客戶端。

https協議需要到CA （Certificate Authority，證書頒發機構）申請證書，一般免費證書較少，因而需要一定費用。(原來網易官網是http，而網易郵箱是https。)
http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
http的連接很簡單，是無狀態的。Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。(無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無連接的意思是指通信雙方都不長久的維持對方的任何信息。)

https://blog.csdn.net/qq_38289815/article/details/80969419

http常見返回碼

1XX信息性狀態碼（Informational）服務器正在處理請求
2XX成功狀態碼（Success）請求已正常處理完畢
3XX重定向狀態碼（Redirection）需要進行額外操作以完成請求
4XX客戶端錯誤狀態碼（Client Error）客戶端原因導致服務器無法處理請求
5XX服務器錯誤狀態碼（Server Error）服務器原因導致處理請求出錯

2XX成功

200 OK 表示請求被服務器正常處理
204 No Content 表示請求已成功處理，但是沒有內容返回（就應該沒有內容返回的狀態）
206 Partial Content 表示服務器已經完成了部分GET請求

3XX 重定向

301 Moved Permanently 永久重定向，表示請求的資源已經永久的搬到了其他位置
302 Found 臨時重定向表示請求的資源臨時搬到了其他位置
303 See Other 表示請求資源存在另一個URI,應該使用GET定向獲取請求資源
304 Not Modified 表示客戶端發送附帶條件的請求（GET方法請求報文的），條件不滿足

4XX客戶端錯誤

400 Bad Request 表示請求報文存在語法錯誤或參數錯誤，服務器不理解
401 Unauthorized 表示發送的請求需要有HTTP認證或者認證失敗了
403 Forbidden 表示請求資源的訪問被服務器拒絕了
404 Not Found 表示服務器找不到你請求的資源了

5XX服務器錯誤

500 internal Server Error 表示服務器執行請求的時候出錯了
503 Service Unavailable 表示服務器超負荷或正停機維護，無法

http請求的過程

對www.baidu.com這個網址進行DNS域名解析，得到對應的IP地址
根據這個IP，找到對應的服務器，發起TCP的三次握手
建立TCP連接後發起HTTP請求
服務器響應HTTP請求，瀏覽器得到html代碼
瀏覽器解析html代碼，並請求html代碼中的資源（如js、css圖片等）（先得到html代碼，才能去找這些資源）
瀏覽器對頁面進行渲染呈現給用戶

注：

1.DNS域名解析採用的是遞歸查詢的方式，過程是，先去找DNS緩存->緩存找不到就去找根域名服務器->根域名又會去找下一級，這樣遞歸查找之後，找到了，給我們的web瀏覽器

2.爲什麼HTTP協議要基於TCP來實現？ TCP是一個端到端的可靠的面相連接的協議，HTTP基於傳輸層TCP協議不用擔心數據傳輸的各種問題（當發生錯誤時，會重傳）

3.最後一步瀏覽器是如何對頁面進行渲染的？

a）解析html文件構成 DOM樹，

b）解析CSS文件構成渲染樹，

c）邊解析，邊渲染，

d）JS 單線程運行，JS有可能修改DOM結構，意味着JS執行完成前，後續所有資源的下載是沒有必要的，所以JS是單線程，會阻塞後續資源下載

怎麼防止http請求的攻擊

在前端服務器通過同一網絡連接將多個請求轉發到後端服務器的情況下會出現HTTP請求走私漏洞，並且用於後端連接的協議存在兩個服務器不同意關於兩者之間邊界的風險要求。防止HTTP請求走私漏洞的一些通用方法如下：

禁用後端連接的重用，以便通過單獨的網絡連接發送每個後端請求。
使用HTTP / 2進行後端連接，因爲此協議可防止請求之間的邊界模糊不清。
爲前端和後端服務器使用完全相同的Web服務器軟件，以便他們就請求之間的界限達成一致。
在某些情況下，可以通過使前端服務器規範化模糊請求或使後端服務器拒絕模糊請求並關閉網絡連接來避免漏洞。然而，這些方法可能比上面確定的通用緩解更容易出錯。

對稱加密與非對稱加密

對稱加密

client 用來加密的 password 和 server 用來解密的 password 相同，所以叫對稱加密。

優點：加密簡單，效率高。
缺點：不夠安全，如果 client 的 password 被盜竊，就沒有安全性了，例如 APP 中使用對稱加密，APP 是可以被反編譯的，就能拿到 password 了。

所以，對稱加密適合在後端服務接口調用時使用，不適合在對外暴露的客戶端中使用。常用的加密方式有 DES、AES。

非對稱加密

client 用來加密的 password 和 server 用來解密的 password 不同，所以叫非對稱加密。分爲一對密鑰（公鑰 public key、私鑰 private key 的組合），使用公鑰加密，必須使用私鑰解密。

使用步驟：

開發人員生成一對密鑰，server保存私鑰，公鑰給client。

Client 保存公鑰，使用公鑰加密。

Server 保存私鑰，使用私鑰解密。

優點：安全性極高。
缺點：加密複雜度高，效率低。

所以，非對稱加密適合使用在 APP 中，還有對安全性要求極高的支付、金融場景。常用的加密方式主要是 RSA。

cookie是Web服務器發送給瀏覽器的信息。瀏覽器會在本地文件中給每一個Web服務器存儲cookie。以後瀏覽器在給特定的Web服務器發請求的時候，同時會發送所有爲該服務器存儲的cookie。

下面列出了session和cookie的區別：

無論客戶端瀏覽器做怎麼樣的設置，session都應該能正常工作。客戶端可以選擇禁用cookie，但是，session仍然是能夠工作的，因爲客戶端無法禁用服務端的session。

在存儲的數據量方面session和cookies也是不一樣的。session能夠存儲任意的Java對象，cookie只能存儲String類型的對象。

java面試（四） 計算機網絡