最近讀了一本書《圖解HTTP》，讀完後在大體上對HTTP協議有了更深層次的瞭解。以下是我以前不懂的問題，透過閱讀此書後，這些問題都有了答案：
問題：
-
URI和URL的區別？
-
cookie到底是什麼？有什麼用？為什麼要有？
-
為什麼下載時可以隨時停止，隨時繼續下載？
-
什麼是內容協商機制？
-
Http協議中響應頭的vary欄位到底是什麼意思？
-
最近讀了一本書《圖解HTTP》，讀完後在大體上對HTTP協議有了更深層次的瞭解。以下是我以前不懂的問題，透過閱讀此書後，這些問題都有了答案：
問題：
- URI和URL的區別？
- cookie到底是什麼？有什麼用？為什麼要有？
- 為什麼下載時可以隨時停止，隨時繼續下載？
- 什麼是內容協商機制？
- Http協議中響應頭的vary欄位到底是什麼意思？
- Cookie的path屬性和domain屬性究竟是什麼？
- 為什麼要有HTTPS？它與HTTP的區別在哪？
- 什麼是SSL和TSL？
- HTTPS的混合加密機制+證書是怎樣的？
- 什麼是WebSocket？為什麼要有WebSocket？
- 什麼是XSS攻擊、CSRF攻擊？
以下是我對問題的理解以及總結上了其他人的理解。
問題：URI和URL的區別？
首先要明確一點，在網路上的所有資源都需要被定位，且它們都會有名稱。這樣才能按需獲取這些資源。
URI就是這些資源的名稱。而URL就是這些資源的位置。但有時候資源的名稱中如果包含了位置，那麼此時URI就和URL一樣了。
因此可以看出URL是URI的子集，當URI中包含了資源位置，那URI就等同於URL。
問題：cookie到底是什麼？有什麼用？為什麼要有？
HTTP協議是無狀態協議，也就是說協議不會去儲存使用者的狀態。那麼在這個情況下假設Web網站是需要登陸的，而進行頁面跳轉之後，使用者的狀態也就消失了。需要重新登陸一次，去獲取使用者狀態。即進行一次頁面跳轉，就要登陸一次。這樣是很繁瑣的。
要解決這種問題，就是把使用者狀態進行儲存，而使用者狀態儲存到Web伺服器也是不現實的，因為當出現很多個使用者狀態時會對Web伺服器造成儲存上的負擔。所以使用者狀態必須儲存到客戶端上。因為客戶端和伺服器的關係是一對多。每個客戶端只需要儲存一個份使用者狀態，這樣就能提高Web伺服器的儲存效能。
所以有了Cookie。使用Cookie，可以把使用者狀態儲存到客戶端上，客戶端每次向伺服器傳送請求時都會帶上Cookie，因此在伺服器上只需要對這個Cookie的內容進行校驗即可。
Cookie通常會搭配Session一起使用，可以維持客戶端與伺服器之間的通訊。只需要把SessionID透過Cookie傳送給客戶端，然後客戶端每次請求伺服器時，都透過Cookie把SessionID發給伺服器，伺服器對SeesionId進行校驗，這樣就能維持客戶端和伺服器之間的通訊了。
問題：為什麼下載時可以隨時停止，隨時繼續下載？
首先，資源在伺服器上是以位元組來進行儲存的。本質上一份資源就是多個0和1的組合。因此下載資源也就是複製這一份0和1的組合。
所以下載時停止了，那麼也就是往客戶端的磁碟上寫這個01組合的動作被停止了。如果此時想要繼續下載，就必須得知道這個01組合寫到哪了，客戶端需要從哪開始繼續寫01組合，也就是說客戶端必須要告訴伺服器一個範圍。從這個範圍開始繼續把資源複製給客戶端。
因此有了range欄位，客戶端在傳送請求時，往請求頭上設定range欄位，就能設定這個範圍。
問題：什麼是內容協商機制？
在單機情況下，一份資源通常只會有一個版本。但是對於一個多語言應用程式，可能需要為每種語言版本單獨建立一個檔案，這些檔案可能會被分別儲存在單機中的不同位置上，這樣在使用時可以根據使用者選擇的語言版本來讀取相應的檔案。因此，可以說在單機情況下，一份多語言資源可能會有多個語言版本。
而在分散式系統中，同一份資源的不同版本可能儲存在不同的伺服器上，由不同的伺服器提供服務。這些伺服器之間可以透過負載均衡或者其他技術來實現對使用者請求的處理。因此，不同國家的使用者請求的資源版本可能來自不同的伺服器。
無論在單機情況下還是分散式系統中都存在一個問題： 客戶端怎麼決定要使用哪一個版本的資源呢？
HTTP的內容協商機制很好的解決了這問題。內容協商機制是指：某一資源，伺服器有多個版本，客戶端告知伺服器自己的偏好，伺服器根據偏好選擇合適的版本響應客戶端的請求。
在內容協商機制中有以下三種方法來決定使用哪個版本資源：
- 客戶端驅動協商（讓客戶端來選擇）： 客戶端發起請求，伺服器傳送資源的可選項列表，客戶端作出選擇後再傳送第二次請求。
- 伺服器驅動協商（讓伺服器來選擇）： 客戶端傳送請求時把需要哪個版本的資源透過請求頭髮送給伺服器，讓伺服器來決定使用哪個版本的資源。
- 透明協商（讓中間代理來選擇）： 使用某個中間裝置（通常是快取代理）來代表客戶端進行協商，可以說是客戶端驅動協商的變種。
問題：Http協議中響應頭的vary欄位到底是什麼意思？
假設整個請求過程是這樣的：客戶端 -> 代理伺服器（具備快取功能） ->web伺服器。
第一個支援gzip壓縮的客戶端向中間代理伺服器傳送請求，代理伺服器轉發該請求，向web伺服器拉取內容，拿到內容後代理伺服器快取該內容（由於請求首部有Accept-Encoding: gzip 所以內容會被壓縮）。
第二個不支援gzip壓縮的客戶端也向中間代理伺服器傳送同一個請求，代理伺服器發現該請求已經被快取了，於是就把壓縮後的內容響應給該客戶端。悲劇了，因為該客戶端根本不支援gzip壓縮，也就沒法解壓。
這種問題出現在透明協商機制中。問題的根源就在於代理把同一份資源響應給了不同的客戶端，而客戶端對份資源是有不同版本的要求的。
為瞭解決這個問題，於是有了vary欄位,vary欄位用於列出一個響應欄位列表，告訴快取伺服器遇到同一個 URL 對應著不同版本檔案的情況時，如何快取和篩選合適的版本。
有了vary欄位之後，代理快取可以為透過單個URL訪問的檔案儲存不同的副本。如果伺服器把它們的決策過程傳給快取，這些代理就能代表伺服器與客戶端進行協商。快取同時也是進行內容轉碼的好地方，因為部署在快取裡的通用轉碼器能對任意伺服器，而不僅僅是一臺伺服器傳來的內容進行轉碼。
更加詳細的介紹可以看這篇文章：https://codeleading.com/article/90534722641/
問題：Cookie的path屬性和domain屬性究竟是什麼？
cookie一定會隨著客戶端傳送的請求而到達伺服器。而伺服器上可能會出現多個域名的情況（伺服器有多個域名的情況通常是因為同一個應用程式需要提供不同的服務或介面）。那麼就有個問題： cookie一定要被伺服器的所有域名識別嗎？我想讓某些域名不能識別這個cookie那怎麼辦？
於是有了domain屬性，domain屬性用於用於指定哪些域名可以接受該Cookie。具體來說，如果設定了該屬性，則只有在該屬性值所指定的域名及其子域名下傳送請求時，瀏覽器才會將該Cookie傳送給伺服器。
舉個例子，假設我們有一個名為“example.com”的域名，並且在其上設定了一個Cookie，domain屬性值為“example.com”。此時，無論是在"ohj.example.com"子域名下，還是在“blog.example.com”子域名下，當瀏覽器傳送請求時，都會將該Cookie附加在請求頭中傳送給伺服器。但如果傳送請求的域名為“test.com”，則瀏覽器不會傳送該Cookie。
需要注意的是，domain屬性的值必須是當前域名或其子域名，否則瀏覽器不會傳送該Cookie。同時，該屬性值不能包含協議名和埠號。
現在Cookie傳送到伺服器的指定域名了，但是又有一個問題： 這個域名上的所有路徑都要使用這個cookie嗎？某些路徑不想使用怎麼辦？
於是有了path屬性，使用path屬性可以指定Cookie可以被哪些路徑使用。舉個例子，cookie的path屬性的值為/head，那麼路徑為/head/ohj/、/head/xxx/都能使用到這個cookie，而/abc/test/路徑都不能使用到這個cookie。
即cookie只會發往path屬性指定的路徑。只有path屬性的路徑與請求URL路徑一致時，cookie才會傳送給伺服器。
總結： domain屬性用於控制cookie能夠傳送給哪些域名，path屬性用於控制cookie在伺服器上哪些路徑可以訪問。
問題：為什麼要有HTTPS？它與HTTP的區別在哪？
首先，HTTP協議是存在安全隱患的，HTTP傳輸內容時，都是明文傳輸，存在被竊聽風險。而HTTP的內容也有可能被修改。
於是有了HTTPS，HTTP+加密+認證+完整性保護=HTTPS。因此使用HTTPS能夠防止竊聽和篡改的風險。
問題：什麼是SSL和TSL？
SSL（安全套接層）和TSL（傳輸層安全協議）是用於保護網路通訊安全的協議，TLS是SSL的繼任者。它們的作用是在應用層和傳輸層之間提供一層安全協議，保護通訊過程中的機密性、完整性和可靠性。
問題：HTTPS的混合加密機制+證書是怎樣的？
先了解一下共享金鑰加密和公開金鑰加密。
共享金鑰加密： 使用一對完全一樣的公鑰來對資料進行加密解密，因此稱為共享金鑰加密。假設有個伺服器A，伺服器A用公鑰加密內容，然後傳送給伺服器B，伺服器B用另一把相同的公鑰進行解密。
公開金鑰加密： 使用一個非對稱的公鑰來對資料進行加密解密，一個金鑰叫公開金鑰，用於到處分享；一個金鑰叫私有金鑰，用於解密資料，不會到處分享。假設有個服務A，它先把公開金鑰發給伺服器B，然後伺服器B用公開金鑰加密內容，然後傳送給伺服器A，伺服器A用私有金鑰進行解密。
在HTTPS協議中使用的是混合金鑰加密，也就是把共享金鑰加密和公開金鑰加密結合結合在一起。
- 公開金鑰加密通常只用於在建立連線時對客戶端和伺服器之間的通訊進行加密。（也就是用公開金鑰加密來確保共享金鑰能夠安全傳輸到客戶端。）
- 共享金鑰對後續的請求和響應進行加密和解密，這種方式也被稱為對稱金鑰加密。
到此，有個問題：客戶端怎麼知道這個公開金鑰就是伺服器發來的呢？
為瞭解決這個問題，必須依賴第三方機構，於是有了證書。使用證書，可以確保這個公開金鑰就是伺服器發來的。
在我的理解中使用HTTPS的客戶端和伺服器之間是這樣從連線-通訊的：
- 伺服器先把自己的公開金鑰在數字證書認證機構中登記，然後獲取公鑰證書。
- 伺服器把認證過的公開金鑰和證書發給客戶端
- 客戶端使用瀏覽器內建的資料證書認證機構的公開金鑰對證書進行認證，認證透過後證明確實是伺服器的公開金鑰。
- 客戶端用這個公開金鑰對客戶端生成的共享金鑰進行加密，然後傳送給伺服器。
- 伺服器用自己的私有金鑰進行解密，得到客戶端傳送的共享金鑰。
- 之後伺服器和客戶端的通訊就只用共享金鑰進行加密。
問題：什麼是WebSocket？為什麼要有WebSocket？
在HTTP協議中有以下缺點：
- 一次連線只能傳送一個請求。
- 請求只能從客戶端開始。客戶端不可以接受除響應意外的指令，也就是伺服器不能主動傳送響應到客戶端。
- 每次請求都會傳輸完整的請求頭，且請求頭都沒有壓縮過，請求頭資訊越多延遲越大。
為了彌補HTTP的缺點，於是有了WebSocket。WebSocket是一種在單個TCP連線上提供全雙工通訊的協議，透過這種協議，Web應用程式可以建立與伺服器的永續性連線，實現實時通訊和資料傳輸。
WebSocket協議是在HTTP協議的基礎上進行升級得到的。在初始連線建立時，客戶端會傳送一份HTTP協議的請求，該請求中包含升級為WebSocket協議的要求。如果伺服器同意升級，則接下來的通訊將採用WebSocket協議進行，這時候HTTP協議就不再使用了。因此，WebSocket協議也被稱為HTTP協議的升級版或擴充套件版。
問題：什麼是XSS攻擊、CSRF攻擊？
XSS（跨站指令碼攻擊）：攻擊者透過注入惡意指令碼程式碼到受害者訪問的網頁上，從而獲取受害者的敏感資訊或者執行惡意操作的一種攻擊方式。XSS攻擊分為儲存型、反射型和DOM型三種形式。 XSS攻擊的共同點為：將一些隱私資料像 cookie、session 傳送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作。
CSRF（跨站請求偽造）：攻擊者透過偽造合法的請求來欺騙使用者執行操作的一種攻擊方式。攻擊者可以利用使用者已經登入的身份，向伺服器傳送請求來執行一些惡意操作。例如，攻擊者可以透過偽造提交表單的請求來更改受害者的賬戶資訊。CSRF攻擊是攻擊者藉助受害者的 Cookie 騙取伺服器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊伺服器，從而在並未授權的情況下執行在許可權保護之下的操作。
-
Cookie的path屬性和domain屬性究竟是什麼？
-
為什麼要有HTTPS？它與HTTP的區別在哪？
-
什麼是SSL和TSL？
-
HTTPS的混合加密機制+證書是怎樣的？
-
什麼是WebSocket？為什麼要有WebSocket？
-
什麼是XSS攻擊、CSRF攻擊？
以下是我對問題的理解以及總結上了其他人的理解。
問題：URI和URL的區別？
首先要明確一點，在網路上的所有資源都需要被定位，且它們都會有名稱。這樣才能按需獲取這些資源。
URI就是這些資源的名稱。而URL就是這些資源的位置。但有時候資源的名稱中如果包含了位置，那麼此時URI就和URL一樣了。
因此可以看出URL是URI的子集，當URI中包含了資源位置，那URI就等同於URL。
問題：cookie到底是什麼？有什麼用？為什麼要有？
HTTP協議是無狀態協議，也就是說協議不會去儲存使用者的狀態。那麼在這個情況下假設Web網站是需要登陸的，而進行頁面跳轉之後，使用者的狀態也就消失了。需要重新登陸一次，去獲取使用者狀態。即進行一次頁面跳轉，就要登陸一次。這樣是很繁瑣的。
要解決這種問題，就是把使用者狀態進行儲存，而使用者狀態儲存到Web伺服器也是不現實的，因為當出現很多個使用者狀態時會對Web伺服器造成儲存上的負擔。所以使用者狀態必須儲存到客戶端上。因為客戶端和伺服器的關係是一對多。每個客戶端只需要儲存一個份使用者狀態，這樣就能提高Web伺服器的儲存效能。
所以有了Cookie。使用Cookie，可以把使用者狀態儲存到客戶端上，客戶端每次向伺服器傳送請求時都會帶上Cookie，因此在伺服器上只需要對這個Cookie的內容進行校驗即可。
Cookie通常會搭配Session一起使用，可以維持客戶端與伺服器之間的通訊。只需要把SessionID透過Cookie傳送給客戶端，然後客戶端每次請求伺服器時，都透過Cookie把SessionID發給伺服器，伺服器對SeesionId進行校驗，這樣就能維持客戶端和伺服器之間的通訊了。
問題：為什麼下載時可以隨時停止，隨時繼續下載？
首先，資源在伺服器上是以位元組來進行儲存的。本質上一份資源就是多個0和1的組合。因此下載資源也就是複製這一份0和1的組合。
所以下載時停止了，那麼也就是往客戶端的磁碟上寫這個01組合的動作被停止了。如果此時想要繼續下載，就必須得知道這個01組合寫到哪了，客戶端需要從哪開始繼續寫01組合，也就是說客戶端必須要告訴伺服器一個範圍。從這個範圍開始繼續把資源複製給客戶端。
因此有了range欄位，客戶端在傳送請求時，往請求頭上設定range欄位，就能設定這個範圍。
問題：什麼是內容協商機制？
在單機情況下，一份資源通常只會有一個版本。但是對於一個多語言應用程式，可能需要為每種語言版本單獨建立一個檔案，這些檔案可能會被分別儲存在單機中的不同位置上，這樣在使用時可以根據使用者選擇的語言版本來讀取相應的檔案。因此，可以說在單機情況下，一份多語言資源可能會有多個語言版本。
而在分散式系統中，同一份資源的不同版本可能儲存在不同的伺服器上，由不同的伺服器提供服務。這些伺服器之間可以透過負載均衡或者其他技術來實現對使用者請求的處理。因此，不同國家的使用者請求的資源版本可能來自不同的伺服器。
無論在單機情況下還是分散式系統中都存在一個問題： 客戶端怎麼決定要使用哪一個版本的資源呢？
HTTP的內容協商機制很好的解決了這問題。內容協商機制是指：某一資源，伺服器有多個版本，客戶端告知伺服器自己的偏好，伺服器根據偏好選擇合適的版本響應客戶端的請求。
在內容協商機制中有以下三種方法來決定使用哪個版本資源：
- 客戶端驅動協商（讓客戶端來選擇）： 客戶端發起請求，伺服器傳送資源的可選項列表，客戶端作出選擇後再傳送第二次請求。
- 伺服器驅動協商（讓伺服器來選擇）： 客戶端傳送請求時把需要哪個版本的資源透過請求頭髮送給伺服器，讓伺服器來決定使用哪個版本的資源。
- 透明協商（讓中間代理來選擇）： 使用某個中間裝置（通常是快取代理）來代表客戶端進行協商，可以說是客戶端驅動協商的變種。
問題：Http協議中響應頭的vary欄位到底是什麼意思？
假設整個請求過程是這樣的：客戶端 -> 代理伺服器（具備快取功能） ->web伺服器。
第一個支援gzip壓縮的客戶端向中間代理伺服器傳送請求，代理伺服器轉發該請求，向web伺服器拉取內容，拿到內容後代理伺服器快取該內容（由於請求首部有Accept-Encoding: gzip 所以內容會被壓縮）。
第二個不支援gzip壓縮的客戶端也向中間代理伺服器傳送同一個請求，代理伺服器發現該請求已經被快取了，於是就把壓縮後的內容響應給該客戶端。悲劇了，因為該客戶端根本不支援gzip壓縮，也就沒法解壓。
這種問題出現在透明協商機制中。問題的根源就在於代理把同一份資源響應給了不同的客戶端，而客戶端對份資源是有不同版本的要求的。
為瞭解決這個問題，於是有了vary欄位,vary欄位用於列出一個響應欄位列表，告訴快取伺服器遇到同一個 URL 對應著不同版本檔案的情況時，如何快取和篩選合適的版本。
有了vary欄位之後，代理快取可以為透過單個URL訪問的檔案儲存不同的副本。如果伺服器把它們的決策過程傳給快取，這些代理就能代表伺服器與客戶端進行協商。快取同時也是進行內容轉碼的好地方，因為部署在快取裡的通用轉碼器能對任意伺服器，而不僅僅是一臺伺服器傳來的內容進行轉碼。
問題：Cookie的path屬性和domain屬性究竟是什麼？
cookie一定會隨著客戶端傳送的請求而到達伺服器。而伺服器上可能會出現多個域名的情況（伺服器有多個域名的情況通常是因為同一個應用程式需要提供不同的服務或介面）。那麼就有個問題： cookie一定要被伺服器的所有域名識別嗎？我想讓某些域名不能識別這個cookie那怎麼辦？
於是有了domain屬性，domain屬性用於用於指定哪些域名可以接受該Cookie。具體來說，如果設定了該屬性，則只有在該屬性值所指定的域名及其子域名下傳送請求時，瀏覽器才會將該Cookie傳送給伺服器。
舉個例子，假設我們有一個名為“example.com”的域名，並且在其上設定了一個Cookie，domain屬性值為“example.com”。此時，無論是在"ohj.example.com"子域名下，還是在“blog.example.com”子域名下，當瀏覽器傳送請求時，都會將該Cookie附加在請求頭中傳送給伺服器。但如果傳送請求的域名為“test.com”，則瀏覽器不會傳送該Cookie。
需要注意的是，domain屬性的值必須是當前域名或其子域名，否則瀏覽器不會傳送該Cookie。同時，該屬性值不能包含協議名和埠號。
現在Cookie傳送到伺服器的指定域名了，但是又有一個問題： 這個域名上的所有路徑都要使用這個cookie嗎？某些路徑不想使用怎麼辦？
於是有了path屬性，使用path屬性可以指定Cookie可以被哪些路徑使用。
舉個例子，cookie的path屬性的值為/head，那麼路徑為/head/ohj/、/head/xxx/都能使用到這個cookie，而/abc/test/路徑都不能使用到這個cookie。
即cookie只會發往path屬性指定的路徑。只有path屬性的路徑與請求URL路徑一致時，cookie才會傳送給伺服器。
總結： domain屬性用於控制cookie能夠傳送給哪些域名，path屬性用於控制cookie在伺服器上哪些路徑可以訪問。
問題：為什麼要有HTTPS？它與HTTP的區別在哪？
首先，HTTP協議是存在安全隱患的，HTTP傳輸內容時，都是明文傳輸，存在被竊聽風險。而HTTP的內容也有可能被修改。
於是有了HTTPS，HTTP+加密+認證+完整性保護=HTTPS。因此使用HTTPS能夠防止竊聽和篡改的風險。
問題：什麼是SSL和TSL？
SSL（安全套接層）和TSL（傳輸層安全協議）是用於保護網路通訊安全的協議，TLS是SSL的繼任者。它們的作用是在應用層和傳輸層之間提供一層安全協議，保護通訊過程中的機密性、完整性和可靠性。
問題：HTTPS的混合加密機制+證書是怎樣的？
先了解一下共享金鑰加密和公開金鑰加密。
共享金鑰加密： 使用一對完全一樣的公鑰來對資料進行加密解密，因此稱為共享金鑰加密。假設有個伺服器A，伺服器A用公鑰加密內容，然後傳送給伺服器B，伺服器B用另一把相同的公鑰進行解密。
公開金鑰加密： 使用一個非對稱的公鑰來對資料進行加密解密，一個金鑰叫公開金鑰，用於到處分享；一個金鑰叫私有金鑰，用於解密資料，不會到處分享。假設有個服務A，它先把公開金鑰發給伺服器B，然後伺服器B用公開金鑰加密內容，然後傳送給伺服器A，伺服器A用私有金鑰進行解密。
在HTTPS協議中使用的是混合金鑰加密，也就是把共享金鑰加密和公開金鑰加密結合結合在一起。
- 公開金鑰加密通常只用於在建立連線時對客戶端和伺服器之間的通訊進行加密。（也就是用公開金鑰加密來確保共享金鑰能夠安全傳輸到客戶端。）
- 共享金鑰對後續的請求和響應進行加密和解密，這種方式也被稱為對稱金鑰加密。
到此，有個問題：客戶端怎麼知道這個公開金鑰就是伺服器發來的呢？
為瞭解決這個問題，必須依賴第三方機構，於是有了證書。使用證書，可以確保這個公開金鑰就是伺服器發來的。
在我的理解中使用HTTPS的客戶端和伺服器之間是這樣從連線-通訊的：
- 伺服器先把自己的公開金鑰在數字證書認證機構中登記，然後獲取公鑰證書。
- 伺服器把認證過的公開金鑰和證書發給客戶端
- 客戶端使用瀏覽器內建的資料證書認證機構的公開金鑰對證書進行認證，認證透過後證明確實是伺服器的公開金鑰。
- 客戶端用這個公開金鑰對客戶端生成的共享金鑰進行加密，然後傳送給伺服器。
- 伺服器用自己的私有金鑰進行解密，得到客戶端傳送的共享金鑰。
- 之後伺服器和客戶端的通訊就只用共享金鑰進行加密。
問題：什麼是WebSocket？為什麼要有WebSocket？
在HTTP協議中有以下缺點：
- 一次連線只能傳送一個請求。
- 請求只能從客戶端開始。客戶端不可以接受除響應意外的指令，也就是伺服器不能主動傳送響應到客戶端。
- 每次請求都會傳輸完整的請求頭，且請求頭都沒有壓縮過，請求頭資訊越多延遲越大。
為了彌補HTTP的缺點，於是有了WebSocket。WebSocket是一種在單個TCP連線上提供全雙工通訊的協議，透過這種協議，Web應用程式可以建立與伺服器的永續性連線，實現實時通訊和資料傳輸。
WebSocket協議是在HTTP協議的基礎上進行升級得到的。在初始連線建立時，客戶端會傳送一份HTTP協議的請求，該請求中包含升級為WebSocket協議的要求。如果伺服器同意升級，則接下來的通訊將採用WebSocket協議進行，這時候HTTP協議就不再使用了。因此，WebSocket協議也被稱為HTTP協議的升級版或擴充套件版。
問題：什麼是XSS攻擊、CSRF攻擊？
XSS（跨站指令碼攻擊）：攻擊者透過注入惡意指令碼程式碼到受害者訪問的網頁上，從而獲取受害者的敏感資訊或者執行惡意操作的一種攻擊方式。XSS攻擊分為儲存型、反射型和DOM型三種形式。 XSS攻擊的共同點為：將一些隱私資料像 cookie、session 傳送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作。
CSRF（跨站請求偽造）：攻擊者透過偽造合法的請求來欺騙使用者執行操作的一種攻擊方式。攻擊者可以利用使用者已經登入的身份，向伺服器傳送請求來執行一些惡意操作。例如，攻擊者可以透過偽造提交表單的請求來更改受害者的賬戶資訊。CSRF攻擊是攻擊者藉助受害者的 Cookie 騙取伺服器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊伺服器，從而在並未授權的情況下執行在許可權保護之下的操作。