---
title: Part 2-1 6.3 通訊協定共同要求事項
tags: 5G 智慧杆系統技術規範
image:
---

# 6.3 通訊協定共同要求事項

## 6.3.1 HTTPS 伺服器端

* a) HTTPS 伺服器端應使用符合 IETF / RFC 5246 規定之 TLS 1.2 或更新版本進行傳輸加密。 若客戶端使用未加密連線時，則應禁止存取。
* b) 應使用憑證機構 (certificate authority, CA) 核發，且未超出期限之有效憑證，存取介面 URI 之域名應能符合憑證登錄項目。
* c) 應對所有連線進行鑑別，未通過鑑別之連線應禁止存取。鑑別方法依後續各節規定。
* d) 通訊協定版本應使用符合 IETF/RFC 2616 規定之 HTTP/1.1 或更新版本,若客戶端使用舊版本連線 (1.0 或更早版本)，則應回應狀態碼 ==**426**== (**upgrade required**)。
* e) 若請求封包標頭內容不符合存取介面 URI 之域名或路徑，則應回應狀態碼 ==**404**== ( **not
found**)。
* f) 其他未指定之錯誤依一般預設方式處理 (例: ==**503**== **service unavailable**)。

**備考:**
HTTPS 客戶端宜具備惡意攻擊偵測能力。若同一 HTTPS 客戶端連續發生相同錯誤，宜限制該客戶端之後續連線。

## 6.3.2 HTTPS 客戶端: 發送請求

* a) HTTPS 客戶端應使用符合 IETF / RFC 5246 規定之 TLS 1.2 或更新版本進行傳輸加密。
* b) 所有連線應包含鑑別資訊，鑑別資訊之格式、內容及鑑別方法，依後續各節規定。
* c) 通訊協定版本應使用 IETF / RFC 2616 規定之 HTTP/1.1 或更新版本，**Host** 標頭欄位應包含連線標的 URI 之域名。
* d) 連線應為非持續性，**Connection** 標頭欄位內容應為 **close**。
* e) 若請求方法為 **POST**，則請求封包應包含請求本體 (body)，內容格式及編碼方式應符合 6.2 規定。封包內應包含 **Content-Type** 標頭欄位，內容應為 **application/json; charset=utf-8**，並使用 **Content-Length** 標頭欄位以標記資料長度。

## 6.3.3 HTTPS 客戶端: 異常及回應處理

* a) HTTPS 客戶端於發送請求封包後，應等候伺服器端回應。若連線逾時、伺服器端逾時未回應或回應不完整，則應重新發送請求封包至相同 URI。逾時時間依實作而定。
* b) 若回應狀態碼為 ==**429**== (**too many requests**)、==**500**== (**internal server error**)、==**502**== (**bad gateway**)、==**503**== (**service unavailable**) 或 ==**504**== (**gateway timeout**)，則應重新發送請求封包至相同 URI。
* c) 若回應狀態碼為 ==**307**== (**temporary redirect**)，則應重新發送請求封包至 **Location** 標頭欄位內容指示之 URI。
* d) 其他回應狀態碼之處理方式依後續各節規定，未指定處理方式之狀態碼應視為異常。發生異常時，應停止重新發送請求，後續處理方式依各依後續各節規定。
* e) 重新發送 HTTPS 請求時，應先等候一段時間，再發送包含相同內容之請求封包。若回應封包內包含 **Retry-After** 標頭欄位，則等候時間應符合 **Retry-After** 標頭欄位內容指示。若未收到回應封包或回應封包內未設定 **Retry-After** 標頭欄位，則可由實作自定等候時間，不宜低於 5 秒。
* f) 重新發送 HTTPS 請求時，若連續發生相同錯誤達一定次數時，則應視為異常。重試次數上限可由實作自定。

**備考 1**
除另有規定外，HTTPS 客戶端不處理回應狀態碼 300 至 305 及 308 之重新導向指示。
**備考 2**
發生異常時，實作宜能顯示或記錄該次異常，以利後續除錯作業。