服務器推送事件：一種從服務器流式推送事件的簡易方法
哈嘍！昨天我見識到了一種我以前從沒見過的從服務器推送事件的炫酷方法：服務器推送事件server-sent events！如果你只需要讓服務器發送事件，相較于 Websockets，它們或許是一個更簡便的選擇。
我會聊一聊它們的用途、運作原理，以及我昨日在試著運行它們的過程中遇到的幾個錯誤。
問題：從服務器流式推送更新
現在，我有一個啟動虛擬機的 Web 服務，客戶端輪詢服務器，直到虛擬機啟動。但我并不想使用輪詢方式。
相反，我想讓服務器流式推送更新。我跟 Kamal 說我要用 Websockets 來實現它，而他建議使用服務器推送事件不失為一個更簡便的選擇！
我登時就愣住了——那什么玩意？？？聽起來像是些我從來沒見過的稀罕玩意兒。于是乎我就查了查。
服務器推送事件就是個 HTTP 請求協議
下文便是服務器推送事件的運作流程。我-很-高-興-地了解到它們就是個 HTTP 請求協議。
1.客戶端提出一個 GET 請求（舉個例子）https://yoursite.com/events 2.客戶端設置 Connection: keep-alive，這樣我們就能有一個長連接 3.服務器設置設置一個 Content-Type: text/event-stream 響應頭 4.服務器開始推送事件，就比如下文這樣：
event: status
data: one舉個例子，這里是當我借助 curl 發送請求時，一些服務器推送事件的樣子：
$ curl -N 'http://localhost:3000/sessions/15/stream'
event: panda
data: one
event: panda
data: two
event: panda
data: three
event: elephant
data: four服務器可以根據時間推移緩慢推送事件，并且客戶端也能夠在它們到來時讀取它們。你也可以將 JSON 或任何你想要的東西放在事件當中，就比如 data: {'name': 'ahmed'}。
線路協議真的很簡單（只需要設置 event: 和 data:，或者如果你愿意，可設置為 id: 和 retry:），所以你并不需要任何花里胡哨的服務器庫來實現服務器推送事件。
JavaScript 的代碼也超級簡單（僅使用 EventSource）
以下是用于流式服務器推送事件的瀏覽器 JavaScript 的代碼。（我從 服務器推送事件的 MND 頁面 得到的這個范例）
你可以訂閱所有事件，也可以為不同類型的事件使用不同的處理程序。這里我有一個只接受類型為 panda 的事件的處理程序（就像我們的服務器在上一節中推送的那樣）。
const evtSource = new EventSource("/sessions/15/stream", { withCredentials: true })
evtSource.addEventListener("panda", function(event) {
console.log("status", event)
});客戶端在中途不能推送更新
不同于 Websockets，服務器推送事件不允許大量的來回事件通訊。（這體現在它的字眼中 —— 服務器 推送所有事件）。初始的時候客戶端發出一個請求，然后服務器發出一連串響應。
如果 HTTP 連接結束，它會自動重連
使用 EventSource 發出的 HTTP 請求和常規 HTTP 請求有一個很大的區別，MDN 文檔中對此有所說明：
默認情況下，如果客戶端和服務器之間的連接斷開，則連接會重啟。請使用
.close()方法來終止連接。
很奇怪，一開始我真的被它嚇到了：我打開了一個連接，然后在服務器端將其關閉，然后兩秒過后客戶端向我的傳送終端發送了另一條請求！
我覺得這里可能是因為連接在完成之前意外斷開了，所以客戶端自動重新打開了它以防止類似情況再發生。
所以如果你不想讓客戶端繼續重試，你就得通過調用 .close() 直截了當地關閉連接。
這里還有些其它特性
你還能在服務器推送事件中設置 id: 和 retry: 字段。似乎，如果你在服務器推送事件上設置，那么當重新連接時，客戶端將發送一個 Last-Event-ID 響應頭，帶有它收到的最后一個 ID。酷!
我發現 W3C 的服務器推送事件頁面 令人驚訝地容易理解。
在設置服務器推送事件的時候我遇到了兩個錯誤
我在 Rails 中使用服務器推送事件時遇到了幾個問題，我認為這些問題挺有趣的。其中一個緣于 Nginx，另一個是由 Rails 引起的。
問題一：我不能在事件推送的過程中暫停
這個奇怪的錯誤是在我做以下操作時出現的：
def handler
# SSE is Rails' built in server-sent events thing
sse = SSE.new(response.stream, event: "status")
sse.write('event')
sleep 1
sse.write('another event')
end它會寫入第一個事件，但不能寫入第二個事件。我對此-非-常-困-惑，然后放開腦洞，試著理解 Ruby 中的 sleep 是如何運作的。但是 Cass 將我引領到一個與我有著相同困惑的 Stack Overflow 問答帖，而這里包含了讓我為之震驚的回答！
事實證明，問題出在我的 Rails 服務器位于 Nginx 之后，似乎 Nginx 默認使用 HTTP/1.0 向上游服務器發起請求（為啥？都 2021 年了，還這么干？我相信這其中一定有合乎情理的解釋，也許是為了向下兼容之類的）。
所以客戶端（Nginx）會在服務器推送第一個事件之后直接關閉連接。我覺得如果在我推送第二個事件的過程中 沒有 暫停，它繼續正常工作，基本上就是服務器在連接關閉之前和客戶端在爭速度，爭著推送第二部分響應，如果我這邊推送速度足夠快，那么服務器就會贏得比賽。
我不確定為什么使用 HTTP/1.0 會使客戶端的連接關閉（可能是因為服務器在每個事件結尾寫入了兩個換行符？），但因為服務器推送事件是一個比較新的玩意兒，HTTP/1.0 （這種老舊協議）不支持它一點都會不意外。
設置 proxy_http_version 1.1 從而解決那個麻煩。好欸！
問題二：事件被緩沖
這個事情解決完，第二個麻煩接踵而至。不過這個問題實際上非常好解決，因為 Cass 已經建議將 stackoverflow 里另一篇帖的回答 作為前一個問題的解決方案，雖然它并沒有是導致問題一出現的源頭，但它-確-實-解-釋-了問題二。
問題在這個示例代碼中：
def handler
response.headers['Content-Type'] = 'text/event-stream'
# Turn off buffering in nginx
response.headers['X-Accel-Buffering'] = 'no'
sse = SSE.new(response.stream, event: "status")
10.times do
sse.write('event')
sleep 1
end
end我本來期望它每秒返回 1 個事件，持續 10 秒，但實際上它等了 10 秒才把 10 個事件一起返回。這不是我們想要的流式傳輸方式！
原來這是因為 Rack ETag 中間件想要計算 ETag（響應的哈希值），為此它需要整個響應為它服務。因此，我需要禁用 ETag 生成。
Stack Overflow 的回答建議完全禁用 Rack ETag 中間件，但我不想這樣做，于是我去看了 鏈接至 GitHub 上的議題。
那個 GitHub 議題建議我可以針對僅流式傳輸終端應用一個解決方法，即 Last-Modified 響應頭，顯然，這么做可以繞過 ETag 中間件。
所以我設置為：
headers['Last-Modified'] = Time.now.httpdate然后它起作用了！！！
我還通過設置響應頭 X-Accel-Buffering: no 關閉了位于 Nginx 中的緩沖區。我并沒有百分百確定我要那樣做，但這么做似乎更安全。
Stack Overflow 很棒
起初，我全身心致力于從頭開始調試這兩個錯誤。Cass 為我指向了那兩個 Stack Overflow 帖子，一開始我對那些帖下提出的解決方案持懷疑態度（我想：“我沒有使用 HTTP/1.0 啊！ETag 響應頭什么玩意，跟這一切有關系嗎？？”）。
但結果證明，我確實無意中使用 了 HTTP/1.0，并且 Rack ETag 中間件確實給我帶來了問題。
因此，也許這個故事告訴我，有時候計算機就是會以奇怪的方式相互作用，其它人在過去也遇到過計算機以完全相同的奇怪方式相互作用的問題，而 Stack Overflow 有時會提供關于為什么會發生這些情況的答案 : )
我認為重要的是不要隨意從 Stack Overflow 中嘗試各種解決方案（當然，在這種情況下不會有人建議這樣做！）。對于這兩個問題，我確實需要去仔細思考，了解發生了什么，還有為什么更改這些設置會起作用。
就是這樣！
今天我要繼續著手實現服務器推送事件，因為昨天一整天我都沉浸在上述這些錯誤里。好在我學到了一個以前從未聽說過的易學易用的網絡技術，心里還是很高興的。
