ICMP 協議

定義

網際控制訊息協定，全稱 Internet Control Message Protocol。主要功能是用來 偵測網路當前的狀況，因為透過 IP 在網路傳遞資料不怎麼可靠，傳遞過程必須經過 多個路由器 轉發才能夠送達目的地，那麼為了確保轉發前能夠安全送達，所以就有了 ICMP 協議。

ARP 協議

定義

位址解析協定，全名 Address Resolution Protocol，位於 網路存取層 與 網路層 (TCP/IP 模型) 中，負責將 32bit IP Address 轉換成 48bit 乙太網地址(MAC Address) 的協議，用來 獲取目的 IP Address 的實體位址，並且藉由添加 Ethernet Header 使用實體網路來傳遞。反之，若是要將 MAC Address 轉換成 IP Address，則是使用 RARP 協議。

ARP 協議只會作用於相同的網路區段下，若是兩台主機處於不同網域，則 ARP 就會直接請求所屬網域內Default Gateway 的實體位址，而不是目標主機的實體位址。

Program

定義

放在二級儲存裝置 (硬碟) 中，沒有被加載到記憶體的一堆 Code ，中文又稱「程式」，可以想像成它是死的。

前言

在關聯式資料庫中，我們肯定會在資料異動的時候使用 Transaction 來確保資料的正確性，透過 ACID 的特性，才得以讓關聯式資料庫有如此穩定的操作，避免種種的問題發生。

本篇文章將會詳細介紹 ACID 的特性，並且分析每個特性的原理和解決方式。

定義

HTTP Status Code 是用來 表示 Server 處理請求的狀態，從 1xx、2xx、3xx、4xx、5xx 開頭分別有其不一樣的意思。

前言

在資料結構中，我們很常使用 Hash Map 來儲存 Key-Value 的資料，但是當我們想使用 for range 將資料一一讀出的時候，就會發現每次執行所讀出來的順序皆不同。

那麼要如何確保讀出值的順序是依照自己的需求呢？本篇文章將會告訴您如何去順序讀取 Hash Map 裡頭的資料。

介紹

眾所周知，如果我們使用 go 關鍵字進行協程的操作時，如果 主協程 沒有等待其他協程的話，直接結束會導致 任務無法完全執行。

範例如下：

1
2
3
4
5
6
7
8

func main(){
  go sayHi(){
    fmt.Println("say hello......")
  }()
  fmt.Println("main groutine....")
}
// 結果
// main groutine....

一般來說，最暴力解的方式就是 讓主協程睡一會，等待子協程完成再來去完成主協程的任務。

1

time.Sleep(3 * time.Second)

但是這樣做非常沒有效率，且 sleep 的期間子協程可能早就已經結束了。

定義

Array 是 Golang 的原生型別，其長度固定。

Slice 是 Golang 中長度可以變動的資料型別，也就是可以隨意修改長度的 Array。

其中，Slice 會包含 Pointer、Capacity、Length，Pointer 負責指向實際底層的 Array 位址；Capacity 則是目前 Slice 的容量；Length 則是目前 Slice 內有多少元素在裏頭的長度。

1
2
3
4
5

type slice struct {
  array unsafe.Pointer
  len   int
  cap   int
}

Goroutine Pool

前言

近期對於 golang 的 goroutine 非常感興趣，因為只要在 func 面前下一個關鍵字 go dosomething()，就能過用同步的方式來達到異步的效果。

然而，goroutine 是額外開啟一個輕量化的執行緒去執行我們的任務，如果需要在一個大量開啟 goroutines 情境下使用的話，系統很容易因為無節制的使用 goroutines 而大規模進行擴充與銷毀，這樣會造成 GC (Garbage Collection) 產生大量的壓力，從而影響我們的系統整體的效能。

並且 runtime 和 GC 都是 goroutine，如果 goroutine 的規模太過於龐大，記憶體無法有效進行調度， Go Scheduler 就會阻塞 goroutine，導致 Processor Local Queue 累積，造成記憶體溢出，最後有可能整個行程直接崩潰。

前言

由於 Docker 讓我們開發者不論是在開發還是上線環境有一個統一的環境可以讓我們執行，導致容器化的部屬方式變得非常熱門。
然而，每次當我們在 Docker 打包 golang 的執行檔時，常常發現鏡像(Docker Image)佔用空間非常大，甚至可能有幾GB的大小這麼多。於是，優化其鏡像大小成為了一個重要的議題。
本篇文章將會將實際專案，從原本1.51GB大小的鏡像縮減至38MB，如果對於本文有更好的建議也歡迎留言提出來。