假設你有一個 VM,你想要讓外面的人可以直接連到這個 VM 的某個 port (通訊埠), 但你又希望有一些網路層的設定或保護。

這時候你就可以用「通訊協定轉送」這個功能。它的作用就是把外部進來的網路流量,按照你設定的規則,轉送到指定的 VM 上面。

目標執行個體 (Target Instance)

當你設定通訊協定轉送的時候, 你需要告訴 GCP「我要把流量轉送到哪裡去」。這個「哪裡」就是你指定的一個 VM 執行個體, 而這個被指定的 VM 在這個情境下就被稱為「目標執行個體」。簡單說, 目標執行個體就是「流量最終要送達的那台 VM」。

假設你有一台 VM 上面跑著一個遊戲伺服器, 這個遊戲使用特殊的網路協定, 不是常見的 HTTP 或 HTTPS。你想要讓玩家可以從網路上連進來,但又想要有一些流量控制。

這時候你就可以設定「通訊協定轉送」,把外部進來的遊戲協定流量轉送到你的 VM 上。在這個設定中,你的這台遊戲伺服器 VM 就是「目標執行個體」。

到底通訊協定轉送長什麼樣子？

「通訊協定轉送」不是一台 VM,它是一個「網路規則」或「轉送設定」。這個轉送設定會指向一台 VM (也就是目標執行個體), 流量是從外部先到這個轉送規則,然後再被轉送到你指定的 VM 上。

用更簡單的比喻:通訊協定轉送就像是一個「郵局轉信服務」。你告訴 GCP「寄到地址 A 的信,都轉寄到地址 B」,這裡地址 B 就是你的 VM(目標執行個體),而這個轉信規則本身就是「通訊協定轉送」。整個過程只有一台 VM,不是兩台。

另一個常見的情況是企業的 VPN 服務。

VPN 通常會用 ESP(一種加密協定)或特定的 TCP/UDP port,這些都不是標準的網頁流量。如果你想在 GCP 上建立 VPN Server,就必須透過 Protocol Forwarding 來接收這些特殊協定的連線。

此外,像是資料庫的直接連線、串流媒體伺服器、或者物聯網裝置的通訊,只要不是走 HTTP/HTTPS,基本上都可能需要用到這個功能。

與其他方案的差異

難道 TCP Proxy LB 或 Network LB 做不到嗎?它們不是針對 「不是 HTTP/HTTPS 的流量」嗎?

Load Balancer 的本質功能

首先要理解,TCP Proxy Load Balancer 和 Network Load Balancer 的核心目的是「負載平衡」。什麼意思呢?就是當你有多台伺服器在背後提供相同的服務時,Load Balancer 會把進來的流量「分散」到這些伺服器上,避免某台伺服器累死、其他伺服器卻閒著。這就像是一個餐廳有多個櫃台,門口的帶位人員會引導客人到比較空的櫃台去排隊。

這些 Load Balancer 雖然可以處理 TCP、UDP 等協定,但它們會「介入」流量的處理。TCP Proxy Load Balancer 會終止(terminate)連線,也就是說,客戶端先連到 Load Balancer,然後 Load Balancer 再重新建立一條新的連線到後端伺服器。Network Load Balancer 雖然是 passthrough 模式,但它仍然會進行流量的檢查和分配,並且需要配置 backend service 和 health check 等複雜的設定。

Protocol Forwarding 的簡單直接

相比之下,Protocol Forwarding 就單純多了。它不做負載平衡,不需要 backend service,也不會終止或檢查你的連線內容。它就像是一個「純粹的轉接頭」,把特定 IP 和 port 收到的流量,直接原封不動地送到指定的目標。這個目標可以是單一台 VM instance,也可以是一組 target pool(但 target pool 的分配邏輯比 Load Balancer 簡單很多)。

這種設計在某些情況下反而是優勢。比如說,你只有一台伺服器,根本不需要負載平衡的功能,只是想要一個固定的外部 IP 位址來接收特定協定的流量。這時候用 Load Balancer 就太複雜了,還要設定一堆用不到的功能。或者,你的應用程式本身對連線非常敏感,不希望中間有任何「代理」介入,Protocol Forwarding 的直接轉送特性就很重要。

實際場景的選擇

再舉個具體例子:假設你要架設一個 IPsec VPN Server。VPN 連線通常使用 ESP(IP Protocol 50)或特定的 UDP port,而且連線的狀態非常重要。如果用 TCP Proxy Load Balancer,它會終止連線並重建,這可能會破壞 VPN 協定的運作。如果用 Network Load Balancer,雖然可以運作,但你需要設定 health check、backend service 等,而且如果你只有一台 VPN Server,這些設定都是多餘的。

這時候 Protocol Forwarding 就很適合,你只需要建立一個 Forwarding Rule,指定「所有到這個 IP 的 ESP 協定流量都轉送到我的 VPN Server」,就完成了。設定簡單,流量處理也最直接。當然,如果你後來需要多台 VPN Server 並做負載平衡,那時候再改用 Network Load Balancer 也不遲。

總結差異

所以簡單來說,TCP Proxy Load Balancer 和 Network Load Balancer 確實可以處理非 HTTP/HTTPS 流量,但它們是為了「多台伺服器的負載分配」而設計的,功能複雜、設定繁瑣。Protocol Forwarding 則是為了「單純的流量轉送」,當你不需要負載平衡,只想要一個乾淨、直接的流量入口時,它就是最佳選擇。這就是為什麼 GCP 會同時提供這些不同的方案,讓使用者根據實際需求來選擇最適合的工具。

你可能會想,為什麼不直接讓伺服器對外開放就好?

確實可以這樣做,但 Protocol Forwarding 提供了一層額外的管理和保護。

透過 Forwarding Rule(轉送規則),你可以統一管理哪些 IP 位址和 port 可以接收流量,而不需要在每台伺服器上個別設定防火牆規則。這樣的架構讓你的網路設計更有彈性,也更容易維護。

為什麼保護 Protocol Forwarding 有保護的功能？

Forwarding Rule 本身並不是用來「阻擋」流量的,它比較像是「開通一條路」。當你建立一個 Forwarding Rule,你是在說「我要讓這個 External IP 的這個 port(或協定)可以接收流量,並且把這些流量轉送到指定的目標」。但這不代表「沒有設定 Forwarding Rule 的 port 就會被擋下來」,因為 Forwarding Rule 根本不管其他 port 的事。

舉個例子來說明:假設你有一台 VM,它的內部 IP 是 10.0.0.5。你申請了一個 External IP 是 34.80.0.100,然後建立一個 Forwarding Rule,把 34.80.0.100:8080 的流量轉送到 10.0.0.5:8080。這時候,外面的人可以透過 34.80.0.100:8080 連到你的 VM。但如果有人試圖連 34.80.0.100:3306(假設你沒設定這個 port 的 Forwarding Rule),會發生什麼事呢?

防火牆規則才是真正的守門員

答案是:這個連線會失敗,但不是因為 Forwarding Rule 擋住它,而是因為根本就「沒有路可以通」。

Forwarding Rule 只負責「有設定的 port」,沒設定的 port 就不會被轉送,流量會直接被丟棄或回應連線失敗。從這個角度來看,Forwarding Rule 確實有「只開放特定 port」的效果,但它的本質是「開通」而不是「防禦」。

真正的防火牆功能還是要靠 Firewall Rules 來做。Firewall Rules 才是那個會主動「檢查」並「決定要不要放行」的機制。

即使你設定了 Forwarding Rule 把流量轉到 VM,如果 VM 的 Firewall Rules 沒有允許那個 port,流量還是會被擋下來。

所以完整的流程是:

External IP 的流量 → Forwarding Rule 決定要不要轉送 → Firewall Rules 決定要不要放行 → 最後才到達 VM。

兩者的互補關係

所以正確的理解應該是:Forwarding Rule 是「入口管理」,它決定哪些流量可以進入你的 GCP 架構;Firewall Rules 是「存取控制」,它決定流量能不能到達特定的資源。

兩者是互補的,不是替代的關係。Forwarding Rule 確實讓你不用在每台伺服器上都開放對外 port,但你還是需要 Firewall Rules 來做更細緻的安全控制。這樣的設計讓你的網路架構既有彈性,又有足夠的安全保護。

以下整理一張完整的功能比較表,讓你能清楚看出這四種方案的差異。

GCP 流量轉送方案功能比較表

表格重點說明

這張表格從上到下,逐漸從「功能豐富但複雜」走向「功能簡單但直接」。Application Load Balancer 功能最完整,可以看懂 HTTP 內容並根據網址或 Header 來分配流量,但也最複雜。TCP Proxy Load Balancer 則退一步,不看內容,只處理 TCP 連線,但仍保有全球負載平衡的能力。

Network Load Balancer 更進一步簡化,它是 passthrough 模式,不會終止連線,所以效能最好,但只能在單一區域內運作。最後的 Protocol Forwarding 則是最純粹的,它幾乎不做任何處理,就是把流量轉過去而已,所以設定最簡單,適合那些「我只想要一個入口」的需求。

選擇哪一種方案,關鍵在於你的需求:如果需要根據內容智慧分配流量,選 ALB;如果需要全球分布的 TCP 服務,選 TCP Proxy LB;如果需要高效能且保留原始 IP,選 Network LB;如果只是簡單轉送不需要複雜功能,選 Protocol Forwarding。這樣的設計讓你可以根據實際情況,選擇最符合成本效益的方案。

詳細介紹可以參考通訊協定轉送總覽，設定方法可以參考設定通訊協定轉送。

關於更多 GCP 負載平衡的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post 通訊協定轉送 (Protocol Forwarding) 是什麼？何時會用到？ first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

結果想要用自己的 SSL 憑證，一直測試失敗，

最後才赫然發現，Cloud Run 根本能不用自己的憑證啊啊！

說明文件在這裡：

看來必須使用 Load Balancer 了，

這裡做一個簡單的 Apache 和 PHP 網頁

vim index.php

<?php
echo "Hello World from web1 Dongdong";
?>

vim Dockerfile

# Use the official PHP image
FROM php:7.4-apache

# Copy the PHP file to the Apache document root
COPY index.php /var/www/html/

# Change the default Apache port to 8080
RUN sed -i 's/80/8080/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf

# Expose port 8080
EXPOSE 8080

# Set the ServerName to suppress warnings
RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf

資料夾內只要這兩個檔案：

ls -l

先在 Arfitact Registry 建立 php 這個 Repository

建立 Docker Image

docker build -t asia-east1-docker.pkg.dev/dong-dong-gcp-3/php/web001 .

測試一下，用 8080 Port 看一下：

成功看到網頁了！

快速用 gcloud 部署，指令如下：

gcloud run deploy web001 \
  --image asia-east1-docker.pkg.dev/dong-dong-gcp-3/php/web001 \
  --platform managed \
  --region asia-east1 \
  --port 8080 \
  --allow-unauthenticated \

看一下 Cloud Run 主頁：

點擊 web001

再點 URL，看到網頁了。

接下來去保留一個固定 IP，準備給 Load Balancer 用

取一下名字，我們用 Global IP

取得 IP 了。

去建立 Load Balancer

選擇 Application Load Balancer

公開的 Load Balancer (Public Facing)

選 Best for global

選 Global External ALB

再按 Create

先取個名字 lb-1, 也給 Frontend 取名字 fe-1, 然後 Protocol 選 HTTPS

IP 可以選擇剛剛建立的 IP

然後在憑證的部份，選擇 Create a new Certificate

取個名字 cert-web001，然後上傳自己做好的憑證檔案。

這兩個憑證檔案是使用 Letsencrypt 去申請的：

Certificate 使用 ssl_fullchain001.pem 這個檔案

Private Key 使用 ssl_privkey001.pem 這個檔案。

上傳格式如果正確，會看到 GCP 有針對到憑證的資訊，

沒問題就可以按 Create

你會看到憑證建立成功

它還可以讓你把 HTTP 轉到 HTTPS，勾選後按下 Done

接下來點擊後端，建立一個 Backend Service

取名字 bk-1， 重要的是 Backend type 要選 Serverless Network Endpoint Group：

然後在 New backend 選擇那個 Cloud Run

為 Serverless NEG 取名字

其他地方就保持預設，按下 Create

再按下 ok

Routing Rules 看一下，因為前端進來只到一個後端，

所以不用再設定。

再看一下 Review and finalize 檢查設定

如果都沒問題就按下 Create。

但是還沒完喔，我們要去設定 DNS

DNS 不一定在 GCP 上喔，這裡指的是你註冊 DNS (購買網域) 的地方，

你可能用的是 Hinet 的 DNS，或是國外的 GoDaddy 或 Namecheap 等等。

像我是在 GoDaddy 註冊 DNS 的，但是我已經轉移管理權限到 Cloud DNS 了。

我就點進我的網域：

然後再點 Add Standard

然後輸入要解析的子網域 web001，

使用 A Record，然後輸入 Load Balancer 使用的 IP，

再按下 Create。

完成後去 Google Admin Toolbox，

確認 Google 的解析結果有沒有設定正確，

看起來會像這樣：

那接下來就等待 Load Balancer 生效並且解析成功。

同時我們也看一下 Load balancer 頁面有兩個

上面那個是幫你把 HTTP 轉到 HTTPS 的

我們點下面 lb-1 進去看，

看到有 SSL 憑證，再點進去

會看到憑證是有效的，還有它的到期日。

最後我們在瀏覽器輸入網址 https://web001.dongdonggcp.com/

我們也開無痕模式，輸入 http://web001.dongdonggcp.com

也看到 http 成功轉 https 了

整個步驟機關很多，如果你做完發現一直都看不到網頁，

你可以從 Load Balancer 一層一層點擊到 Cloud Run，

如果秀不出 Cloud Run 的頁面，表示你可能有接錯服務。

在各個環境多檢查一下，

多點耐心就能設定成功喔！

官方文件可參考這裡。

The post [Cloud Run 教學] Cloud Run 如何使用自己的憑證？必須要接到 Load Balancer first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

如下：

1.Cloud DNS 依權重解析到不同 IP (超簡單)

2.Google App Engine 不同版本分流 (超簡單)

3.Cloud Function 不同版本分流 (超簡單)

4.Cloud Run 不同版本分流 (超簡單)

5.Nginx 設定檔 (非GCP但也很簡單)

6.HTTP(S) Load Balancer 依權重分流

偏偏 Load Balancer 是最複雜的，

明明就很單純的功能，

不知道 GCP 為什麼要搞得這麼複雜？

這裡快速分享一下步驟。

目標：依照 70%，30%的權重，分配流量到2個後端。

為了簡化，我在後端都用非代管執行個體群組，

各自接到一台 VM，hello-world-a 和 hello-world-b

Load Balancer 部分，

前端通訊協定就用 HTTP，

接2個後端，分別接到2個非代管執行個體群組。

架構圖如下：

一、上述建立主機、執行個體群組的部分省略，兩張網頁呈現如下：

vm: hello-world-a

vm: hello-world-b

二、接下來要建立負載平衡了，要注意，

前端先不要建，建立兩個後端，接到兩個執行個體群組。

完成如下：

三、接下來要打指令了，

分流的關鍵物件叫做 urm-map

先寫好一個 YAML 檔，我取名 map，

紅色部分請各位自行替換。

為了方便大家複製貼上，我就貼在這裡，語法我就不解釋了。

defaultService: https://www.googleapis.com/compute/v1/projects/dong-dong-gcp-2-bigquery/global/backendServices/bk-a
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/dong-dong-gcp-2-bigquery/global/backendServices/bk-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /
    priority: 2
    routeAction:
        weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/dong-dong-gcp-2-bigquery/global/backendServices/bk-a
          weight: 70
        - backendService: https://www.googleapis.com/compute/v1/projects/dong-dong-gcp-2-bigquery/global/backendServices/bk-b
          weight: 30

四、YAML 檔準備好，用指令來建立 url-map：

gcloud beta compute url-maps import web-map-http –source map –global

五、再來建立 target-http-proxies

gcloud beta compute target-http-proxies create http-lb-proxy-adv –url-map=web-map-http

六、在建立前端之前，先保留一個靜態 IP

gcloud compute addresses create lb-ipv4     –ip-version=IPV4     –global

七、確認取得 IP

gcloud compute addresses describe lb-ipv4     –format=”get(address)”     –global

八、建立 forwarding-rules

gcloud beta compute forwarding-rules create http-content-rule     –load-balancing-scheme EXTERNAL_MANAGED     –address=lb-ipv4-2     –global     –target-http-proxy=http-lb-proxy-adv     –ports=80

建立過程截圖如下：

接下來點網頁看看，

會發現很多次是 v1，有幾次是 v2。

想多打一點流量進去，使用 siege，

在 Cloud Shell 安裝 siege：

sudo apt-get install siege

開始測試，例如打個200下：

siege -c 10 -r 2- -d1 http://34.49.24.227

然後 Load Balancer 監控頁面可以看到分流的圖：

我們去 Cloud Logging 去看結果，

看到2個後端接收 Request 的次數比較，

包含我最初手動點擊網頁的次數，和 siege 200 次，

2個後端分別收到 209 次和 91次，大概是69.67%：30.30%，

如果打更多次，比例會更接近 70%：30%。

也可以從 Cloud Monitoring 看到兩個後端接收 Reuqest 的圖表：

以上分享。

來源可參考這份文件：

https://codelabs.developers.google.com/externalhttplb-adv#4

順便置入一下，關於更多 GCP 負載平衡的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 線上課程] GCP 負載平衡依照權重分流 Load Balancer weight-based traffic splitting first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

剛開始通常經費不足，

但還是必須要架設一個網站，

來宣傳你的服務和內容。

如果你是資訊背景，可以自行架設網站的話，

使用 GCP 架設網站是最划算的。

為什麼？

以下分四點說明 GCP 的功能、架構和好處：

1. 費用節省

GCP 是 Pay-as-you-go 依照使用量計費，

剛開始流量不大，

你可以建立最小規格的機器 – N1系列的 f1-micro，

每月費用大約 5~6 美金，折合台幣不到200元，

如果不用機器時，可以直接刪掉，

那根本就不會有費用發生。

不覺得超便宜嗎？

網站流量還不高時，用這個最划算。

當然這裡必須提醒一下，

因為它是共用核心，和其他機器共用同一個 CPU，

所以它的效能會有突發 (Burst) 效果，

代表有時候可以免費用到”額外”的CPU資源。

反過來說，效能有時候突然會「非常好」，

但大多數時間還是原有的效能。

如果要避免效能不穩定，

那還是建議選用例如 e2-medium 的機器，

(2 vCPU 和 4 GB 記憶體)

每月費用約 26 美金，約台幣 800 元左右(也不算太貴)。

2. 使用 Cloud Storage 減輕主機負載

通常網頁會有大量圖片或影片，

每當使用者存取網頁時，

Client 端對網頁讀取，會造成主機很大的負擔。

其實你可以把圖片和影片放在 Cloud Storage (GCS)，

而網頁 HTML 的圖片和影片超連結指向 GCS 公開網址，

這樣主機只要負責載入純文字的 HTML 和相關網頁原始碼，

負擔直接少減 90% 以上，

你也就省下很多維護主機、調校效能的時間。

3.免費自動更新的 SSL 憑證

自架網站通常也要處理憑證的問題，

到期還要手動更新，很麻煩。

但如果搭配 Google Load Balancer，

除了防禦大流量的 DDoS 攻擊之外，

免費自動更新的憑證，非常方便。

4. 加速媒體發佈的 Cloud CDN

除此之外，在 Load Balancer 上可一鍵勾選 CDN 功能，

除了幫你把媒體暫存在靠近使用者的位置，

加速媒體發佈以外，

也能更進一步減輕主機負擔，

因為 Client 端就不用去源頭主機拉圖片和影片了，

尤其是以影音串流的網站來說，更是必備的工具。

以上分享 4 個使用 GCP 的好處，

希望可以對 IT 自媒體創業者有所幫助。

順便置入一下，關於更多 GCP VM、Cloud Storage、Load Balancer 的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 線上課程] GCP – 對 IT 自媒體最友善的雲端平台 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.