引言

在現(xiàn)代軟件開(kāi)發(fā)中，HTTP 協(xié)議是應(yīng)用程序與外部服務(wù)交互的核心橋梁。C# 作為 .NET 生態(tài)的主力語(yǔ)言，提供了豐富而成熟的 HTTP 通訊能力。本文將系統(tǒng)介紹 C# 中實(shí)現(xiàn) HTTP 請(qǐng)求的技術(shù)選型、核心概念、常見(jiàn)場(chǎng)景及最佳實(shí)踐，幫助開(kāi)發(fā)者構(gòu)建穩(wěn)定、高效的網(wǎng)絡(luò)通訊模塊。

一、技術(shù)選型：HttpClient 與 HttpWebRequest

C# 中進(jìn)行 HTTP 請(qǐng)求主要有兩種方式，理解它們的差異是正確選型的前提。

1.1 HttpClient（推薦）

HttpClient 是 .NET Framework 4.5 及 .NET Core/.NET 5+ 中官方推薦的 HTTP 客戶端。它基于異步任務(wù)模型設(shè)計(jì)，支持連接池復(fù)用、請(qǐng)求管道定制和取消令牌等現(xiàn)代特性。其最大優(yōu)勢(shì)在于連接復(fù)用——多個(gè)請(qǐng)求可以共享同一個(gè)底層 TCP 連接，顯著減少資源消耗和延遲。
HttpClient 實(shí)例設(shè)計(jì)為可長(zhǎng)期復(fù)用，不應(yīng)為每個(gè)請(qǐng)求創(chuàng)建新實(shí)例。最佳實(shí)踐是在應(yīng)用程序生命周期內(nèi)保持單例或有限數(shù)量的實(shí)例，通過(guò)依賴注入統(tǒng)一管理。

1.2 HttpWebRequest（遺留）

HttpWebRequest 是 .NET 早期版本的 HTTP 客戶端實(shí)現(xiàn)，基于同步編程模型。雖然功能完整，但存在連接無(wú)法復(fù)用、資源釋放不及時(shí)等問(wèn)題。微軟已將其標(biāo)記為遺留 API，新項(xiàng)目應(yīng)優(yōu)先選擇 HttpClient。

二、請(qǐng)求構(gòu)建的核心要素

一個(gè)完整的 HTTP 請(qǐng)求包含多個(gè)可配置維度，掌握這些要素是靈活實(shí)現(xiàn)通訊的基礎(chǔ)。

2.1 HTTP 方法

HTTP 協(xié)議定義了多種請(qǐng)求方法，每種方法對(duì)應(yīng)不同的語(yǔ)義：

• GET：從服務(wù)器獲取資源，請(qǐng)求參數(shù)通常附加在 URL 查詢字符串中。GET 請(qǐng)求是冪等的，多次執(zhí)行結(jié)果應(yīng)一致。
• POST：向服務(wù)器提交數(shù)據(jù)，常用于表單提交、文件上傳或創(chuàng)建新資源。請(qǐng)求體（Body）承載實(shí)際數(shù)據(jù)。
• PUT：完整更新服務(wù)器上的指定資源，通常需要攜帶資源的全部字段。
• PATCH：對(duì)資源進(jìn)行部分更新，僅提交需要修改的字段，相比 PUT 更節(jié)省帶寬。
• DELETE：刪除服務(wù)器上的指定資源。

2.2 請(qǐng)求頭（Headers）

請(qǐng)求頭攜帶了關(guān)于請(qǐng)求的元信息，常見(jiàn)的包括：

• Content-Type：聲明請(qǐng)求體的數(shù)據(jù)格式，如 application/json（JSON 數(shù)據(jù)）、application/x-www-form-urlencoded（表單數(shù)據(jù)）、multipart/form-data（文件上傳）。
• Authorization：攜帶身份認(rèn)證信息，如 Bearer Token 或 Basic 認(rèn)證字符串。
• Accept：聲明客戶端期望的響應(yīng)數(shù)據(jù)格式。
• User-Agent：標(biāo)識(shí)客戶端應(yīng)用程序信息。
• 自定義頭：如 API 版本號(hào)、請(qǐng)求追蹤 ID 等業(yè)務(wù)相關(guān)頭信息。

2.3 請(qǐng)求體（Body）

POST、PUT、PATCH 等請(qǐng)求通常需要攜帶請(qǐng)求體。C# 中可將多種數(shù)據(jù)類型序列化為請(qǐng)求體：

• JSON 對(duì)象：使用系統(tǒng)內(nèi)置的 JSON 序列化器將對(duì)象轉(zhuǎn)換為 JSON 字符串。
• 表單數(shù)據(jù)：鍵值對(duì)形式的字符串，適用于傳統(tǒng)表單提交場(chǎng)景。
• 文件流：以流的形式上傳文件，支持大文件分塊傳輸。
• 原始字節(jié)：適用于需要精確控制二進(jìn)制數(shù)據(jù)的場(chǎng)景。

2.4 URL 與查詢參數(shù)

請(qǐng)求地址由協(xié)議、主機(jī)、路徑和查詢參數(shù)組成。查詢參數(shù)需要進(jìn)行 URL 編碼，確保特殊字符（如空格、中文、符號(hào)）不會(huì)破壞 URL 結(jié)構(gòu)?，F(xiàn)代 C# 提供了 URI 構(gòu)建器，可安全地拼接路徑和參數(shù)。

三、響應(yīng)處理的關(guān)鍵環(huán)節(jié)

發(fā)送請(qǐng)求后，正確處理響應(yīng)同樣重要。

3.1 狀態(tài)碼解析

HTTP 響應(yīng)狀態(tài)碼分為五類，C# 程序應(yīng)根據(jù)狀態(tài)碼采取不同的處理邏輯：

• 2xx 成功：如 200（OK）、201（Created）、204（No Content），表示請(qǐng)求被正常處理。
• 3xx 重定向：如 301（永久重定向）、302（臨時(shí)重定向），客戶端通常需要自動(dòng)跟隨跳轉(zhuǎn)。
• 4xx 客戶端錯(cuò)誤：如 400（請(qǐng)求參數(shù)錯(cuò)誤）、401（未認(rèn)證）、403（無(wú)權(quán)限）、404（資源不存在），需要檢查請(qǐng)求本身。
• 5xx 服務(wù)器錯(cuò)誤：如 500（內(nèi)部錯(cuò)誤）、502（網(wǎng)關(guān)錯(cuò)誤）、503（服務(wù)不可用），通常需要重試或告警。
  HttpClient 默認(rèn)不會(huì)因非 2xx 狀態(tài)碼拋出異常，開(kāi)發(fā)者需要顯式檢查狀態(tài)碼并決定后續(xù)行為。

3.2 響應(yīng)內(nèi)容讀取

響應(yīng)內(nèi)容通常以字符串或流的形式返回。對(duì)于 JSON 格式的響應(yīng)，可以反序列化為強(qiáng)類型對(duì)象，便于后續(xù)業(yè)務(wù)處理。對(duì)于大文件下載場(chǎng)景，建議使用流式讀取，避免一次性加載到內(nèi)存導(dǎo)致性能問(wèn)題。

3.3 響應(yīng)頭處理

響應(yīng)頭中可能包含重要的元信息，如內(nèi)容類型、內(nèi)容長(zhǎng)度、緩存策略、請(qǐng)求追蹤 ID 等。某些 API 會(huì)將分頁(yè)信息（如總記錄數(shù)、下一頁(yè)鏈接）放在響應(yīng)頭中，需要特別解析。

四、常見(jiàn)業(yè)務(wù)場(chǎng)景的實(shí)現(xiàn)思路

4.1 RESTful API 調(diào)用

現(xiàn)代后端服務(wù)普遍采用 RESTful 架構(gòu)。C# 客戶端需要構(gòu)建符合 REST 規(guī)范的請(qǐng)求，處理 JSON 序列化與反序列化，并管理認(rèn)證令牌的生命周期。對(duì)于需要頻繁調(diào)用的 API，建議封裝為服務(wù)層，統(tǒng)一處理基礎(chǔ) URL、默認(rèn)頭信息和錯(cuò)誤重試邏輯。

4.2 文件上傳與下載

文件上傳通常使用 multipart/form-data 格式，將文件流與表單字段一起打包發(fā)送。需要注意設(shè)置合理的超時(shí)時(shí)間，大文件上傳可能需要分片或斷點(diǎn)續(xù)傳機(jī)制。
文件下載建議采用流式處理，將響應(yīng)流直接寫(xiě)入本地文件系統(tǒng)，避免將整個(gè)文件加載到內(nèi)存。對(duì)于大文件，可以實(shí)現(xiàn)進(jìn)度回調(diào)，向用戶展示下載進(jìn)度。

4.3 身份認(rèn)證集成

常見(jiàn)的認(rèn)證方式包括：

• API Key：在請(qǐng)求頭中攜帶固定密鑰，實(shí)現(xiàn)簡(jiǎn)單但安全性較低。
• Bearer Token：通過(guò) OAuth 2.0 或 JWT 獲取訪問(wèn)令牌，在請(qǐng)求頭中以 Authorization: Bearer 形式發(fā)送。需要處理令牌過(guò)期后的刷新邏輯。
• Basic 認(rèn)證：將用戶名和密碼進(jìn)行 Base64 編碼后放在請(qǐng)求頭中，適用于內(nèi)部系統(tǒng)或開(kāi)發(fā)測(cè)試環(huán)境。
• Cookie 認(rèn)證：自動(dòng)管理會(huì)話 Cookie，適用于傳統(tǒng) Web 應(yīng)用的 API 調(diào)用。

4.4 異步與并發(fā)控制

HttpClient 原生支持異步操作，應(yīng)始終使用 async/await 模式避免阻塞主線程。在高并發(fā)場(chǎng)景下，需要控制同時(shí)發(fā)出的請(qǐng)求數(shù)量，防止對(duì)目標(biāo)服務(wù)器造成過(guò)大壓力或觸發(fā)限流。可以通過(guò)信號(hào)量（Semaphore）或 HttpClient 的連接池配置來(lái)實(shí)現(xiàn)并發(fā)控制。

五、超時(shí)、重試與容錯(cuò)設(shè)計(jì)

網(wǎng)絡(luò)通訊天然不可靠，健壯的客戶端必須考慮各種異常情況。

5.1 超時(shí)配置

HTTP 請(qǐng)求應(yīng)設(shè)置合理的超時(shí)時(shí)間，包括：

• 連接超時(shí)：建立 TCP 連接的最長(zhǎng)等待時(shí)間。
• 請(qǐng)求超時(shí)：從發(fā)送請(qǐng)求到接收完整響應(yīng)的最長(zhǎng)等待時(shí)間。
  超時(shí)時(shí)間應(yīng)根據(jù)業(yè)務(wù)場(chǎng)景調(diào)整，實(shí)時(shí)性要求高的接口設(shè)置較短超時(shí)，批量處理任務(wù)可設(shè)置較長(zhǎng)超時(shí)。

5.2 重試策略

對(duì)于因網(wǎng)絡(luò)抖動(dòng)或服務(wù)器瞬時(shí)過(guò)載導(dǎo)致的失敗，合理的重試機(jī)制可以提高成功率。重試策略應(yīng)考慮：

• 可重試的錯(cuò)誤類型：通常僅對(duì) 5xx 錯(cuò)誤或網(wǎng)絡(luò)連接異常進(jìn)行重試，4xx 錯(cuò)誤重試無(wú)意義。
• 退避算法：采用指數(shù)退避策略，每次重試間隔逐漸延長(zhǎng)，避免對(duì)故障服務(wù)器造成沖擊。
• 最大重試次數(shù)：設(shè)置上限，防止無(wú)限重試導(dǎo)致資源耗盡。

5.3 熔斷與降級(jí)

在微服務(wù)架構(gòu)中，當(dāng)依賴服務(wù)持續(xù)不可用時(shí)，客戶端應(yīng)啟動(dòng)熔斷機(jī)制，快速失敗而非持續(xù)等待，避免級(jí)聯(lián)故障。同時(shí)可以準(zhǔn)備降級(jí)方案，如返回緩存數(shù)據(jù)或默認(rèn)值。

六、代碼實(shí)現(xiàn)

6.1 Post請(qǐng)求

/// <summary>
/// HTTP POST請(qǐng)求
/// </summary>
/// <param name="url">請(qǐng)求地址</param>
/// <param name="value">參數(shù)</param>
/// <param name="timeout">超時(shí)時(shí)間,默認(rèn)5秒</param>
/// <returns></returns>
public JObject Post(string url, string value, int timeout = 10)
{
    JObject result = new JObject();
    result["code"] = 99;
    result["message"] = "請(qǐng)求失敗";
    try
    {
        HttpClient client = new HttpClient();
        HttpContent content = new StringContent(value);
        content.Headers.ContentType = new MediaTypeHeaderValue("application/json");
        // 數(shù)據(jù)轉(zhuǎn)化為 key=val 格式
        //var content =  new FormUrlEncodedContent(value);
        //默認(rèn)希望響應(yīng)使用Json序列化(內(nèi)容協(xié)商機(jī)制，我接受json格式的數(shù)據(jù))
        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        client.Timeout = new TimeSpan(0, 0, timeout);
        // 發(fā)送請(qǐng)求
        var response = client.PostAsync(url, content);
        // 獲取數(shù)據(jù)
        string message = response.Result.Content.ReadAsStringAsync().Result.ToString();
        result["code"] = 0;
        result["message"] = message;
    }
    catch (Exception ex)
    {
        result["code"] = 1;
    }
    return result;
}

6.2 Get請(qǐng)求

/// <summary>
/// HTTP Get請(qǐng)求
/// </summary>
/// <param name="url">請(qǐng)求地址</param>
/// <param name="timeout">超時(shí)時(shí)間,默認(rèn)5秒</param>
/// <returns></returns>
public JObject Get(string url, int timeout = 10)
{
    JObject result = new JObject();
    result["code"] = 99;
    result["message"] = "請(qǐng)求失敗";
    try
    {
        HttpClient client = new HttpClient();
        client.Timeout = new TimeSpan(0, 0, timeout);
        // 發(fā)送請(qǐng)求
        var response = client.GetAsync(url);
        // 獲取數(shù)據(jù)
        string message = response.Result.Content.ReadAsStringAsync().ToString();
        result["code"] = 0;
        result["message"] = message;
    }
    catch (Exception ex)
    {
        result["code"] = 1;
    }
    return result;
}

6.3 DELETE請(qǐng)求

/// <summary>
/// HTTP DELETE請(qǐng)求
/// </summary>
/// <param name="url">請(qǐng)求地址</param>
/// <param name="timeout">超時(shí)時(shí)間,默認(rèn)5秒</param>
/// <returns></returns>
public JObject Delete(string url, int timeout = 10)
{
    JObject result = new JObject();
    result["code"] = 99;
    result["message"] = "請(qǐng)求失敗";
    try
    {
        HttpClient client = new HttpClient();
        client.Timeout = new TimeSpan(0, 0, timeout);
        // 發(fā)送請(qǐng)求
        var response = client.DeleteAsync(url);
        // 獲取數(shù)據(jù)
        string message = response.Result.Content.ReadAsStringAsync().ToString();
        LogHelperUtility.Info(string.Format("[Delete]請(qǐng)求返回參數(shù):{0}", message));
        result["code"] = 0;
        result["message"] = message;
    }
    catch (Exception ex)
    {
        result["code"] = 1;
    }
    return result;
}

七、性能優(yōu)化要點(diǎn)

7.1 連接池管理

HttpClient 內(nèi)部維護(hù)連接池，復(fù)用 TCP 連接可大幅減少握手開(kāi)銷。但連接池有數(shù)量上限，高并發(fā)場(chǎng)景下可能需要調(diào)整最大連接數(shù)配置。

7.2 壓縮傳輸

啟用請(qǐng)求和響應(yīng)的 Gzip 壓縮，可顯著減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量?，F(xiàn)代服務(wù)器和 HttpClient 均默認(rèn)支持，只需確?？蛻舳寺暶鹘邮軌嚎s編碼。

7.3 請(qǐng)求管道定制

HttpClient 支持通過(guò)消息處理器（Delegating Handler）構(gòu)建請(qǐng)求管道，可在管道中統(tǒng)一實(shí)現(xiàn)日志記錄、認(rèn)證注入、重試邏輯等橫切關(guān)注點(diǎn)，避免在每個(gè)請(qǐng)求中重復(fù)編碼。

7.4 DNS 緩存與刷新

長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序可能遇到 DNS 變更問(wèn)題。HttpClient 默認(rèn)會(huì)緩存 DNS 解析結(jié)果，對(duì)于需要頻繁切換后端節(jié)點(diǎn)的場(chǎng)景，可能需要配置 DNS 刷新策略。

八、安全注意事項(xiàng)

8.1 敏感信息保護(hù)

API 密鑰、訪問(wèn)令牌等敏感信息不應(yīng)硬編碼在源代碼中，應(yīng)通過(guò)配置文件、環(huán)境變量或密鑰管理服務(wù)（如 Azure Key Vault）獲取。日志中應(yīng)避免輸出完整的認(rèn)證頭信息。

8.2 HTTPS 強(qiáng)制使用

生產(chǎn)環(huán)境必須使用 HTTPS 協(xié)議，確保數(shù)據(jù)傳輸?shù)募用苄院屯暾?。?duì)于自簽名證書(shū)的開(kāi)發(fā)環(huán)境，需要謹(jǐn)慎配置證書(shū)驗(yàn)證策略，避免將不安全的驗(yàn)證邏輯帶入生產(chǎn)代碼。

8.3 請(qǐng)求偽造防護(hù)

如果客戶端同時(shí)作為 Web 應(yīng)用運(yùn)行，需要注意防范 CSRF（跨站請(qǐng)求偽造）攻擊。雖然純 C# 客戶端程序通常不受 CSRF 影響，但在混合應(yīng)用場(chǎng)景中仍需保持警惕。

九、總結(jié)

C# 提供了成熟而強(qiáng)大的 HTTP 通訊能力，HttpClient 作為現(xiàn)代首選方案，通過(guò)異步設(shè)計(jì)、連接復(fù)用和管道擴(kuò)展，能夠滿足絕大多數(shù)業(yè)務(wù)場(chǎng)景的需求。在實(shí)際開(kāi)發(fā)中，開(kāi)發(fā)者應(yīng)關(guān)注請(qǐng)求構(gòu)建的規(guī)范性、響應(yīng)處理的完整性、異常場(chǎng)景的容錯(cuò)性以及安全傳輸?shù)膹?qiáng)制性。將 HTTP 通訊邏輯封裝為可復(fù)用的服務(wù)組件，結(jié)合依賴注入和配置化管理，可以構(gòu)建出既靈活又穩(wěn)健的網(wǎng)絡(luò)通訊層，為應(yīng)用程序與外部世界的交互提供可靠保障。

以上就是C#中實(shí)現(xiàn)HTTP請(qǐng)求通訊的操作指南的詳細(xì)內(nèi)容，更多關(guān)于C#實(shí)現(xiàn)HTTP請(qǐng)求通訊的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論