gRPC 和 HTTP/2 Streaming

嗨，我是 Cian。
上個月初意外成為了一個前後端各半的半半工程師，過了一個月之後深深覺得這樣的生活不是我想要的，所以之後會回去專注在前端方面。雖然可以專心研究喜歡的前端很開心，但既然起了頭，這篇文章還是想做個收尾。另外，在上一篇文章之後，我才知道原來這 route 專案是官方的教學專案，因此，我決定來看一下補充的內容，以及延續上一篇的內容繼續往剩下的三種方向看，以及提供一些相關的資源給有興趣的同學參考。

# HTTP/2 和 Streaming 傳輸

在上一篇文章中有提到 gRPC 可以擁有 Unary、Client-side Streaming、Server-side Streaming 和 Bidirectional Streaming 四種生命週期，是受惠於 HTTP/2，這是因為在 HTTP/2 中有 Streaming 的技術，另外使用 bytecode 傳輸也是 HTTP/2 的特點。

# HTTP/2 之前——SPDY

在 2009 年， google 發布了一個稱為 SPDY 的實驗性協議。他的主要目標是希望可以解決一些 HTTP/1.1 中的性能限制來縮短網頁載入時間。這個協議的其中一個目標是將頁面加載時間（PLT）減少 50%。
想要讓頁面加載時間（PLT）減少 50%，就得知道什麼對頁面加載時間能造成巨大的影響，其中，SPDY 的創作者之一 Mike Belshe 的一個實驗結果提供了一個方向。

他研究了不同帶寬與延遲對頁面加載時間的影響。在這個實驗中，他發現當流量從 1Mbp 變成 2Mbps 的時候，頁面加載時間確實會減半，但隨後帶寬對加載時間的影響就會急速降低，當可用帶寬超過 5 Mbps 時，這個影響就會變得非常小。從 5 Mbps 升級到 10 Mbps 時，只讓頁面的加載時間縮短了 5%。

相對於帶寬對頁面加載時間的效率遞減狀況，延遲對頁面加載時間的影響影響就十分穩定，是線性的影響。也就是說，如果要對頁面加載時間進行改善，從改善延遲來思考可能會是比較有效率的途徑。

造成延遲的原因很多，像是 TCP 協議每次開始就必須進行的三次握手、丟失表頭會造成的 data packet 阻塞等等。這些都是底層協議的影響，也就是說，如果可以更有效率地利用底層協議，就可以達成這個優化。為了達成這件事，SPDY 引入了一個新的二進制的分流幀層，用來實現 request 和 response 複用、優先級以及壓縮標頭。這使得 TCP 的利用更有效率，從而實現更短的頁面加載時間。

# HTTP/2

在 SPDY 發佈之後，這個協議逐漸被人接受，到了 2012 到了 2012 年，各個大瀏覽器都開始支援這樣技術，在這樣的潮流之下，HTTP 工作組 (HTTP-WG) 決定從中學習，並且提供正式的 HTTP/2 標準。經過許多討論之後，SPDY 規範被採納為新 HTTP/2 協議的起點。

2015 年初，IESG 審查並批准了新的 HTTP/2 標準發布。和 HTTP/1 相比，HTTP/2 可以用更少的 TCP 連結，進行更長時間的傳輸，這網路容量的利用率變高。由於過程中 SPDY 和 HTTP/2 的共同進化使服務器、瀏覽器和站點開發人員可以在新協議開發過程中獲得實際經驗。因此，HTTP/2 標準是在正式發布前經過最廣泛測試的標準之一，幾週之後就在真實世界有了不少實踐。

關於實驗的參考資料在這裡，關於優化 TCP 的資料在這裡，有興趣的朋友可以進一步閱讀。

# Stream 傳輸

HTTP/2 的所有通信都會在一個 TCP 連接上完成，這個連接可以承載任意數量的雙向 byte stream。每一個 byte stream 都會有一個唯一標示符，以及可選的優先級信息。
在這個雙向 byte stream 中，又可以承載複數條 message，每一個 message 都是一個 HTTP message，像是 request 或 response。
在這些 message 中，會包含一系列的 frames。frame 是最小的通信單位，裡面會有特定類型的數據、 HTTP header 以及 payload 等等。
在一個 TCP 通訊中，由於可以同時可以有複數條 streams，所以 frame 中也會帶有 stream 的標示符，屬於不同 stream 的 frames 可以交互傳輸，之後再依據這些標示符重新組裝。

基於這樣新的傳輸結構，在 HTTP/2 上就達成了減少 TCP 連結和可以進行 Streaming 的功能。同時，因為這些傳輸使用 byte stream，gRPC 的開發中也就會需要在發送或接收請求時，進行編碼和解碼。

# Streaming RPC 可能會用上的一些食譜

# 在 Server 發送 stream

Server-side Streaming 是指 Server 收到一個 Client 的 request 時，會開啟一個 Stream 傳輸，並且回傳一個或多個 message response。
在使用 Streaming 之前，可能的做法是讓 Server 去搜尋資料，接著把在範圍內的資料放到一個 response 中回傳給 User，這在數量少的資料中也許還好，但當資料的數量變多，Server 所需要的搜尋時間就會變長，而 Client 需要等待的時間也就越久。
而其中，假設搜尋到第一筆資料只花了三秒，但全部完成搜尋花了一分鐘，所有先搜尋到的結果就必須一起等到搜尋完成，十分浪費時間。
Server-side Streaming 的做法則是每找到一筆資料就進行回傳，可以降低中間乾等的時間，讓 Client 可以更快拿到資料並進行處理。

可以在一個 for loop 中使用 stream.Send(item) 在一個 stream 中回傳多個東西。

func (s *routeGuideServer) ListFeatures(rectangle *pb.Rectangle, stream pb.RouteGuide_ListFeaturesServer) error {
	for _, feature := range s.features {
		if inRange(feature.Location, rectangle) {
      // 使用 stream.Send(feature) 回傳 feature
			if err := stream.Send(feature); err != nil {
				return err
			}
		}
	}
	return nil
}

# Client 想知道 stream 結束的時候

接收 stream 的時候，需要知道什麼時候 stream 結束了。
這時可以使用 io.EOF 來處理。

for { 
  // 這個 serverStream 是 Client 發 request 時接收到的 response，我們放到 serverStream 裡面
  feature, err := serverStream.Recv(){
    if err = io.EOF {
      break
    }

    if err != nil {
      log.Fatalln(err)
    }
  }
}

# Client 發送 stream

Client Side Streaming 是指 Client 不斷回傳 message，而 Server 則在整個 Stream 結束之後，回傳一個 message response。
在範例專案中，使用者將他所經過的點透過 Stream 不斷回傳。而 Server 則在整個 stream 結束之後，回傳一個路徑的總結。

Client 和 Server 端一樣是在 for loop 裡面用 clientStream 發送。

clientStream, err := client.RecordRoute(context.Background())

// 這裡有一些 error handling...

for _, point := range points {
  if err := clientStream.Send(point); err != nil {
    log.Fatalln(err)
  }
}

# Client 結束發送 stream

當 Client 端發送 Stream 的時候我們需要調用 CloseAndRecv() 來關閉這個 stream 以讓 gRPC 知道我們已完成寫入，並且接受來自 Server 的 response。

clientStream, err := client.RecordRoute(context.Background())

// 這裡有一些 Client 發送 Streaming 的 code
// 還有一些 error handling...

//  Streaming 的內容寫完了，要來關掉這個 stream
// 並且我們把 server 最後的回傳值放進 summary 
summary, err := clientStream.CloseAndRecv()
if err != nil {
  log.Fatalln(err)
}
fmt.Println(summary)
  

# Server 接收及結束接收 stream

在 Server 端接收 stream 的寫法基本上和 Client 是差不多的。只是當收到來自 Client 的完成訊息時，Server 端會需要發送一個結束的 response 回去給 Client。這時我們需要使用 SendAndClose() 來完成這件事。

for {
  point, err := stream.Recv()
  if err == io.EOF {
    // 這裡知道 gRPC 結束了，所以要回傳一個 summary
    endTime := time.Now()
    return stream.SendAndClose(&pb.RouteSummary{
      // 這裡是最後的內容們
    })
  }
  if err != nil {
    return err
  }
}

# 計算地球上兩個點的距離

這是一個根據半正矢公式 (Haversine formula) 寫成的函式。
順帶一提，我看到這個函式時，他的來源說這使用了一個開源的內容，但根據內文連結並沒有真正找到那個源。

func toRadians(num float64) float64 {
	return num * math.Pi / float64(180)
}

// calcDistance calculates the distance between two points using the "haversine" formula.
// The formula is based on http://mathforum.org/library/drmath/view/51879.html.
func calcDistance(p1 *pb.Point, p2 *pb.Point) int32 {
	const CordFactor float64 = 1e7
	const R = float64(6371000) // earth radius in metres
	lat1 := toRadians(float64(p1.Latitude) / CordFactor)
	lat2 := toRadians(float64(p2.Latitude) / CordFactor)
	lng1 := toRadians(float64(p1.Longitude) / CordFactor)
	lng2 := toRadians(float64(p2.Longitude) / CordFactor)
	dlat := lat2 - lat1
	dlng := lng2 - lng1

	a := math.Sin(dlat/2)*math.Sin(dlat/2) +
		math.Cos(lat1)*math.Cos(lat2)*
			math.Sin(dlng/2)*math.Sin(dlng/2)
	c := 2 * math.Atan2(math.Sqrt(a), math.Sqrt(1-a))

	distance := R * c
	return int32(distance)
}

# 參考資料

Introduction to gRPC | gRPC
Basics tutorial | Go | gRPC
神奇代码在哪里Go实战#9：gRPC
HTTP/2 简介  |  Web Fundamentals  |  Google Developers
Networking 101: Building Blocks of TCP - High Performance Browser Networking (O'Reilly)
HTTP: Primer on Web Performance - High Performance Browser Networking (O'Reilly)

這篇文章在我工作轉專案、換部署以及第一次在日本搬家的三重夾擊中寫成，內容恐多有不備，但遺憾短期內恐怕也不會有時間來補足。
如果不幸文章有一些錯誤，請不吝指正，我會盡可能將修正意見補進內文中。
非常感謝各位的閱讀，之後會主要寫前端相關內容，也請多多支持！感謝～

全文同步刊載於個人部落格 gRPC 和 HTTP2 Streaming

關於作者

Cian

遊走在各種覺得有趣的知識之間。

分享文章