1.Web與Gin基礎(chǔ)
1.1 Web基礎(chǔ)
? ? Web是基于互聯(lián)網(wǎng)的信息系統(tǒng),允許用戶通過瀏覽器訪問、瀏覽和分享內(nèi)容。它也是互聯(lián)網(wǎng)的一部分,通過使用HTTP協(xié)議或HTTPS來實現(xiàn)。
1.1.1 Web 原理簡介
? ? 用戶打開瀏覽器,輸入網(wǎng)址(URL)并訪問后,瀏覽器中就會顯示相應(yīng)的內(nèi)容,基本流程如下所示:

1.1.2 HTTP簡介
? ? HTTP(Hyper Text Transfer Protocol,超文本傳輸協(xié)議),是一種無狀態(tài)且由文本構(gòu)成的一種基于請求-響應(yīng)模型的協(xié)議,工作在應(yīng)用層。
? ? HTTP使用客戶端-服務(wù)端架構(gòu)。在日常使用中,瀏覽器充當客戶端,主要與網(wǎng)站服務(wù)器進行通信。在HTTP傳輸過程中,客戶端總是通過建立一個連接,再發(fā)送一個HTTP請求。服務(wù)器不能主動與客戶端聯(lián)系,客戶端和服務(wù)端都可以提前中斷一個連接。如下所示:

HTTP是無狀態(tài)的,同一個客戶端的某次請求和上次請求是沒有對應(yīng)關(guān)系的,HTTP服務(wù)器端也并不知道這兩次請求是否來自于同一客戶端。為解決這個問題,Web程序引入Cookie來維護連接的可持續(xù)性狀態(tài)。
1.1.2.1 URI/URL/URN
- URI(Uniform Resouce Identifier,統(tǒng)一資源標識符):用來標識資源身份
- URL(Uniform Resouce Locator,統(tǒng)一資源定位符):URI的一種,用于描述資源的位置和訪問方式
- URN(Uniform Resouce Name,統(tǒng)一資源名):URI的一種,用于描述資源的名稱,但不指明其位置
? ? 通過URL告訴我們資源在哪里,URN告訴我們資源是什么
1.URI
? ? URI表示的是Web上一種可用的資源。文檔、圖片、視頻等,都是由一個URI來標識。URI通常由三部分組成:
- 資源的訪問機制
- 存放資源的主機名
- 資源自身的名稱
例如:https://www.surpass.net/user/userinfo.html,則可以這樣理解
- 這是一個可以通過https來訪問的資源
- 資源的位置在 www.surpass.net上面
- 通過/user/userinfo.html可以對該資源進行唯一標識
2.URL
? ? URL用于描述網(wǎng)絡(luò)上的資源。URL是URI的一個子集,是URI概念的一種實現(xiàn)方式。通俗來講,URL是互聯(lián)網(wǎng)上描述資源的字符串,主要用在客戶端和服務(wù)端程序上面。URL使用一種統(tǒng)一的格式來描述各種資源,包含文件、服務(wù)器地址和目錄等,格式一般如下所示:
scheme://[username:][passwd@]host[:port]/path/...[?query][#anchor]
其中[]中的內(nèi)容可以省略
3.URN
? ? URN是帶有名稱的網(wǎng)絡(luò)資源。其不依賴于資源的物理位置,因此即使資源的位置發(fā)生變化,URN仍然可以保持有效。
4.三者關(guān)系
? ? 通俗來講,URL和URN是URI的子集。URI屬于對URL的更高層次的抽象,是一種字符串文本標準。
1.1.2.2 HTTP請求
? ? HTTP 是一種基于請求-響應(yīng)協(xié)議,協(xié)議涉及的所有事情都以一個請求開始。其請求都是由一系列文本組成,如下所示:
- 請求行
- 0個或任意多個請求首部(header)
- 一行空白行
- 可選的報文主體(body)
? ? 示例如下所示:
GET /sample.html HTTP/1.1
Host: www.surpassme.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
<空白行>
<請求報文主體>
請求行中第一個單詞為請求方法,后面為統(tǒng)一資源標識符(URI:Uniform Resource Identifier)以及所用到的HTTP 版本。
1.1.2.2.1 HTTP請求方法
? ? 請求方法是請求行中第一個單詞,用以指明客戶端想要對資源執(zhí)行的操作。目前常用的方法如下所示 :
| 方法 | 含義 |
|---|---|
| GET | 從服務(wù)器返回指定資源 |
| HEAD | 與GET類似,但僅用于在不獲取報文主體的情況下,獲取響應(yīng)的首部 |
| POST | 將報文主體的數(shù)據(jù)傳遞給URI指定的資源 |
| PUT | 將報文主體的數(shù)據(jù)傳遞至URI指定的資源,若指定的數(shù)據(jù)已經(jīng)存在,則進行更新替換,若不存在,則進行創(chuàng)建 |
| DELETE | 刪除服務(wù)器上URI指定的資源 |
| TRACE | 返回請求本身,通過該方法,客戶端可以知道在它和服務(wù)器之間的其他服務(wù)器是如何處理請求的 |
| OPTIONS | 獲取服務(wù)器支持的HTTP方法列表 |
| CONNECT | 用于服務(wù)器與客戶端建立網(wǎng)絡(luò)連接,常用于設(shè)置SSL隧道以開啟HTTPS功能 |
| PATCH | 使用報文主體中的數(shù)據(jù)對URI指定的資源進行修改 |
1.1.2.2.2 HTTP請求首部
? ? HTTP 請求方法定義了客戶端想要執(zhí)行的動作,請求首部則記錄了與請求本身相關(guān)的客戶端相關(guān)信息。請求的首部由任意多個使用冒號分隔的純文本鍵值對組成,最后以回車(CR)和換行(LF)結(jié)尾。
大多數(shù)HTTP請求首部都是可選的,而Host首部是HTTP 1.1 唯一強制要求的首部。根據(jù)請求方法的不同,若請求的報文中包含有可選的主體,那么請求的首部還需要攜帶Content-Length和Transfer-Encoding字段。
? ? 常見的首部如下所示:
| 首部字段 | 作用 |
|---|---|
| Accept | 客戶端在HTTP響應(yīng)中能夠接收處理的內(nèi)容類型 |
| Accept-Charset | 客戶端希望服務(wù)器使用的字符集編碼 |
| Authorization | 用于向服務(wù)器發(fā)送基本的身份驗證證書 |
| Cookie | 客戶端需要在首部中把服務(wù)器之前設(shè)置的cookie回傳給服務(wù)器 |
| Content-Length | 請求主體的字節(jié)長度 |
| Content-Type | 當請求報文中包含主體時,用于記錄主體內(nèi)容類型 |
| Host | 請求服務(wù)器的地址和端口號 |
| Referer | 發(fā)起請求時,頁面所在的地址 |
| User-Agent | 發(fā)起請求時的客戶端描述信息 |
1.1.2.3 HTTP響應(yīng)
? ? HTTP響應(yīng)報文是對HTTP請求報文的回復(fù)。與HTTP請求一樣,也是由一系列文本行組成,如下所示:
- 一個狀態(tài)行
- 0個或任意數(shù)量的響應(yīng)首部
- 一行空白行
- 可選的報文主體
? ? 示例如下所示:
HTTP/1.1 200 OK
Date: Sat, 12 Oct 2024 04:06:59 GMT
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
<空白行>
<響應(yīng)報文主體>
HTTP響應(yīng)的第一行為狀態(tài)行,包含一個狀態(tài)碼和相應(yīng)的原因短語。
1.1.2.3.1 HTTP響應(yīng)狀態(tài)碼
? ? HTTP響應(yīng)中狀態(tài)碼表明了響應(yīng)類型,其常見的狀態(tài)碼如下所示:
| 狀態(tài)碼 | 類別 | 作用 |
|---|---|---|
| 1XX | 信息狀態(tài)碼 | 服務(wù)器通過該狀態(tài)碼告知客戶端,已經(jīng)成功接收到請求,正在處理中 |
| 2XX | 成功狀態(tài)碼 | 服務(wù)器通過該狀態(tài)碼告知客戶端,已經(jīng)成功接收到請求,已經(jīng)處理完成 |
| 3XX | 重定向狀態(tài)碼 | 服務(wù)器通過該狀態(tài)碼告知客戶端,已經(jīng)成功接收到請求,但還需要一些附加操作以完成請求 |
| 4XX | 客戶端錯誤碼 | 服務(wù)器通過該狀態(tài)碼告知客戶端,已經(jīng)成功接收到請求,但服務(wù)器無法處理該請求 |
| 5XX | 服務(wù)端錯誤碼 | 服務(wù)器通過該狀態(tài)碼告知客戶端,已經(jīng)成功接收到請求,但服務(wù)器處理出錯 |
1.1.2.3.2 HTTP響應(yīng)首部
? ? 響應(yīng)首部與請求首部一樣,都是由冒號分隔的純文本鍵值對,并且同樣以回車(CR)和換行(LF)結(jié)尾。通過響應(yīng)首部向客戶端傳達更多與響應(yīng)相關(guān)和服務(wù)器的相關(guān)信息。常見的響應(yīng)首部如下所示:
| 首部字段 | 作用 |
|---|---|
| Allow | 服務(wù)器支持的哪些方法 |
| Content-Length | 響應(yīng)主體的字節(jié)長度 |
| Content-Type | 當響應(yīng)報文中包含主體時,用于記錄主體內(nèi)容類型 |
| Date | 以GMT格式記錄當前時間 |
| Location | 僅在重定向時使用,告知客戶端接下來應(yīng)該向哪個URL發(fā)起請求 |
| Server | 返回響應(yīng)服務(wù)器的域名 |
| Set-Cookie | 在客戶端設(shè)置Cookie,一個響應(yīng)里面可以包含多個Set-Cookie首部 |
| WWW-Authenticate | 服務(wù)器通過這個首部告知客戶端,在Authorization請求首部中應(yīng)該提供哪種類型的身份驗證信息 |
1.1.2.4 HTTP 2 簡介
? ? HTTP自創(chuàng)建以來經(jīng)歷了多個版本的發(fā)展,分別是HTTP 0.9、HTTP 1.0、HTTP 1.1、HTTP 2、HTTP 3。目前使用最多的是HTTP 1.1 和 HTTP 2。
? ? HTTP 2 優(yōu)化了性能、而且兼容HTTP 1.1的語義,但也與HTTP 1.1 有一些區(qū)別。比如,它不是文本協(xié)議,而是二進制協(xié)議,而且HTTP頭部信息使用HPACK進行壓縮,支持多路復(fù)用、服務(wù)器推送等功能。
? ? 相比于HTTP 1.1,HTTP 2新增了頭部信息壓縮及推送功能,提高了傳輸效率。
- 頭部信息壓縮:在HTTP 1.1 中,每次發(fā)送請求和返回響應(yīng),HTTP頭部信息都必須是完整,且頭部信息中有很多內(nèi)容,都是以字符串形式保存的,這樣會占用較大的帶寬。HTTP 2 對頭部信息進行壓縮,可以有效減少占用帶寬。
- 推送功能:在HTTP 2 之前,只能是客戶端發(fā)送請求,服務(wù)端返回響應(yīng)??蛻舳耸侵鲃臃?,服務(wù)端永遠是被動方。而在HTTP 2中有了的推送功能,即服務(wù)端可以主動向客戶端發(fā)送一些請求。

1.1.3 Web 程序組成
? ? Web 程序是通過調(diào)用解釋引擎來處理動態(tài)內(nèi)容的。而解釋器引擎是一種用于執(zhí)行源碼或腳本的計算機程序,它逐行讀取和分析代碼,并即時執(zhí)行其中的指令,而不是將整體代碼先編譯成機器語言再運行。解釋引擎通常由 處理器(handler) 和 模板引擎(Template Engine) 組成,其中處理器負責(zé)接收來自客戶端的HTTP請求執(zhí)行邏輯,模板引擎負責(zé)生成動態(tài)網(wǎng)頁內(nèi)容,如下所示:

1.1.3.1 處理器
? ? 在Web程序中,處理器是核心組件,負責(zé)接收和處理客戶端發(fā)來的HTTP請求。通常,處理器會先解析請求的路由(Route),將URL映射到相應(yīng)的控制器(Controller),控制器根據(jù)請求,可能會訪問模型(Model)來獲取或修改數(shù)據(jù),然后調(diào)用模板引擎生成相應(yīng)的視圖(View)。最后處理器將生成的視圖通過HTTP響應(yīng)返回給客戶端。這種模型屬于MVC模型,各個功能如下所示:
- 模型負責(zé)處理與業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù),并可直接訪問數(shù)據(jù)庫
- 視圖負責(zé)展示數(shù)據(jù),一般不包含業(yè)務(wù)邏輯,僅用于呈現(xiàn)內(nèi)容
- 控制器負責(zé)協(xié)調(diào)模型與視圖,處理用戶請求并更新數(shù)據(jù)或顯示相應(yīng)的頁面
? ? 三者關(guān)系如下所示:

MVC模型是一種長期編程經(jīng)驗的總結(jié),并不是唯一的模型,實踐中采用什么模型,需要根據(jù)具體的場景來決定。
1.1.3.2 模板引擎
? ? 模板引擎是為了使用戶界面和業(yè)務(wù)數(shù)據(jù)分離而產(chǎn)生的。它可以生成特定格式的文檔,以便將模板(template)和數(shù)據(jù)(data)組合在一超,最終生成HTML文檔。

? ? 模板引擎有多種類型,最簡單的為置換型模板引擎。這種模板引擎通過將模板中的特定標記替換為實際數(shù)據(jù),生成最終內(nèi)容。雖然實現(xiàn)起來非常簡單,但效率較低,難以滿足高流量的網(wǎng)站需求。
? ? 為提高性能,后續(xù)還出現(xiàn)了解釋型和編譯型的模板引擎。這些模板引擎不僅能更高效的生成內(nèi)容,還能支持更復(fù)雜的邏輯和功能。模板引擎的主要優(yōu)勢在于將網(wǎng)站的界面與數(shù)據(jù)、業(yè)務(wù)代碼和邏輯代碼分離。大大提高了開發(fā)效率。它使得代碼的復(fù)用更容易。同時將前端頁面與業(yè)務(wù)邏輯分離,便于代碼的維護、閱讀。
1.2 Gin
1.2.1 Gin簡介
? ? Gin是Go語言中一個Web框架,輕量、快速且易于使用。通過其提供的庫和工具,可以快速構(gòu)建Web程序。Gin官網(wǎng)地址:https://gin-gonic.com/

1.2.2 Gin庫和工具
? ? Gin是基于Go語言標準庫構(gòu)建的Web框架,提供了一系列額外的庫和工具,使開發(fā)Web程序和API更加方便。常見的Gin庫和工具如下所示:
- gin-gonic/gin:提供核心功能,如路由管理、中間件和請求處理,是構(gòu)建Web程序和API的基礎(chǔ)
- gin-gonic/contrib/cache:用于緩存Gin路由響應(yīng)的庫,可提升性能
- gin-gonic/gin-testutil:Gin測試工具,方便編寫單元測試
- gin-gonic/gin-jwt:用于支持JWT(JSON Web Token)身份驗證的中間件庫
- swaggo/gin-swagger:能夠根據(jù)OpenAPI規(guī)范自動生成API文檔
- gin-contrib:附加中間件和實用工具的集合,支持身份驗證、速率限制和跨域(CORS)等功能
1.2.3 Gin優(yōu)勢
? ? 使用Gin進行 Web 開發(fā)的優(yōu)勢如下所示:
- 快速:Gin是專為高性能而設(shè)計,專注于提升開發(fā)速度和使用最少的內(nèi)存空間
- 輕量級:不會給開發(fā)者的程序增加不必要的開銷,使其易于開發(fā)和部署
- 易于使用:具有最簡單直觀的API,更易于使用
- 靈活性強:可以輕松地進行自定義以滿足特定的需求,例如添加中間件,使用不同的路由等
- 社區(qū)活躍:社區(qū)提供資源,以幫助開發(fā)者構(gòu)建更好的Web程序
1.2.4 Gin架構(gòu)
? ? Gin 將程序分為三個相互關(guān)聯(lián)的組件:模型、視圖和控制器。
- 模型:負責(zé)程序的數(shù)據(jù)傳輸和業(yè)務(wù)邏輯。在Gin中,模型通常由結(jié)構(gòu)體或接口表示,用于處理數(shù)據(jù)存儲等操作
- 視圖:負責(zé)展示用戶界面或呈現(xiàn)數(shù)據(jù)。在Gin,視圖通過HTML模板或其他模板引擎生成,向用戶展示結(jié)果
- 控制器:負責(zé)處理用戶請求,與模型交互并生成響應(yīng)。在Gin,控制器通常是路由處理程序,定義如何根據(jù)用戶請求執(zhí)行相應(yīng)的操作并返回結(jié)果。
? ? HTTP服務(wù)器監(jiān)聽傳入的請求并將它們傳遞給路由器,路由器將每個請求映射到適當?shù)恼埱筇幚沓绦?,請求處理程序處理請求,與模型交互、并生成響應(yīng)。
1.2.5 示例
? ? Gin安裝命令如下所示:
go get -u github.com/gin-gonic/gin
? ? 示例代碼如下所示:
package main
import "github.com/gin-gonic/gin"
func hello(c *gin.Context) {
c.JSON(200, gin.H{
"message": "Hello world",
})
}
func main() {
r := gin.Default()
r.GET("/hello", hello)
// 默認監(jiān)聽0.0.0.0:8080
r.Run()
}
? ? 在瀏覽器中訪問地址 http://127.0.0.1:8080/hello ,返回結(jié)果如下所示:
