每當提到「網路概念」這幾個字，就會想起以前上計算機概論的時候，一大堆名詞排山倒海而來，OSI 七層網路模型、TCP/IP 四層、三次握手…雖然說有個大概的感覺，但還是不知道那些理論到底在幹嘛。

一直到很後來，我看到一篇利用傳紙條來解釋 HTTPS 原理的文章，才被打通任督二脈，並且察覺到利用「傳紙條」這個很生活化的例子，可以很好地去解釋 TCP/IP、HTTP 或甚至是任何跟網路有關的東西。

希望透過這一系列的傳紙條小故事，可以讓大家理解什麼是 TCP/IP，什麼又是 HTTP 協定，以及這些東西到底是為了什麼而誕生的。雖然說希望讀者沒有任何相關背景也能看懂，但其實比較適合已經大概知道什麼是 TCP/IP 以及 HTTP 的讀者觀看，會比較容易知道這一篇到底在講什麼。

在開始之前，請大家先在腦中想起自己國高中教室的畫面，想起那些課桌椅，想起傳過的紙條，這樣會更融入這個情境，也對故事更有共鳴。

第一集：告白篇

故事的主角是小明跟小美，是一對青梅竹馬，念一樣的幼稚園、一樣的國小，也唸一樣的國中（甚至還同班），甚至連住處都只隔了一個樓梯間而已，就在隔壁。

喔對了，這是一個還沒有手機的年代。

雖然說一堂課大概 45 分鐘左右，也不會到很長，但有些話就是想立刻跟對方分享，一刻都等不及。因此，大家都會利用上課時間傳紙條來跟其他人對話（題外話，現在的國高中生是不是都不傳紙條了啊，傳 Line 就好）。

寫紙條是件非常簡單的事，只要隨意從筆記本上面撕一頁下來，寫完內容之後折一折，在封面寫上「To 小美」，然後把紙條丟給隔壁同學，同學們就會幫你把紙條傳到小美手上。

因為通常會傳紙條給小美的也就只有小明一個人而已，所以也不用寫是誰傳的，大家都知道一定是小明。

原本一切都進行得很順利，他們兩人之間的感情透過一張張的紙條不斷堆疊，越來越熟悉彼此，走得一天比一天近。而小明心中也慢慢浮現了一個想法：「好像差不多是時候告白，表示我的心意了」。

可是天不從人願，沒想到才過了幾天，小美就被轉到最遠的十班去了！原本同在一班的兩人就這樣分隔兩地。

小明不是個會輕言放棄的人，否則對不起自己，因此就買通一班到十班認識的同學，約定好互相幫忙跨班級傳紙條，只要在封面寫上是幾班的誰就好，就可以傳紙條到其他班級去。

除此之外，也要把寄件人寫清楚，才知道紙條回傳的時候要給誰。其實就跟寄信差不多啦，只要把收件人跟寄件人寫清楚，其他同學就會充當郵差的角色，幫你把紙條傳到對方手上。

確認了紙條可以跨班級傳送之後，小明就決定要來告白了，於是傳了一張「我喜歡你！如果你願意答應我的告白，放學後操場榕樹下見」的老派紙條給小美，並且在放學後到榕樹下等著。

等呀等，等呀等，從下午四點等到晚上八點，小美始終沒有出現。

原本小明想繼續等的，但無奈老天爺都為他哭泣，天空抑制不了衝動，落下雨和眼淚，小明只好狼狽地走回家裡。這樣也好，就跟倒立淚水就不會流出來一樣，只要下雨，就分不清楚臉上的是雨水還是淚水了。

隔天到了學校，心灰意冷的小明發現一件奇怪的事情，那就是小美神色自若，好像什麼事情都沒發生一樣。

咦…該不會對她而言，真的什麼都沒發生吧？

於是小明在下課的時候鼓起勇氣去問了小美：「昨天…你怎麼沒有來」，沒想到小美一臉疑惑，說道：「什麼意思？」。就在這個瞬間，小明知道了一件事：「靠夭，原來我的紙條沒有傳到」。

確保溝通的辦法

雙方的溝通如果想要順暢，說穿了就是要確保以下四點：

  1. 發送方的傳送功能
  2. 發送方的接收功能
  3. 接收方的傳送功能
  4. 接收方的接收功能

簡單來講就是雙方的傳送跟接收都必須要正常，否則就會發生遺漏訊息的狀況，例如說 A 發給 B，可是 B 的接收壞掉了，或者是 B 回傳給 A，可是 B 的訊息根本發不出去。

那要怎麼樣確保這四個功能都正常呢？可以透過三個打招呼的步驟來確認。以下直接用小明以及小美來舉例：

  1. 小明傳給小美：安安，在嗎？
  2. 小美收到後回覆：在呀，你好
  3. 小明收到後回覆：收到，太好了

如果這三個步驟都能夠順利進行，就代表彼此之間溝通的管道無礙。

不過有一點要注意，這邊先假設一旦某個功能確認正常以後就不會改變，例如說小明的發送功能如果確認正常，就不會突然失效。以傳紙條的例子來說，就是幫你傳紙條的同學不會無緣無故消失的意思。

那為什麼透過這三個步驟可以確認呢？我們一步一步來分析。

第一步：小明傳送給小美：「安安，在嗎？」

如果小美沒收到這個訊息，那就代表小明的發送或者是小美的接收端有問題，所以就可以確認溝通管道是有問題的。

如果小美收到了這個訊息，從小美的角度來看，就知道兩件事：

  1. 自己的接收功能是好的（否則收不到訊息）
  2. 小明的發送功能是好的（否則收不到訊息）

第二步：小美傳送給小明：「在呀，你好」

小明收到這個訊息以後，就可以知道四件事情：

  1. 自己的發送功能是好的（因為小美一定有收到之前傳的「安安，在嗎」，才會回傳這個訊息）
  2. 自己的接收功能是好的（不然收不到訊息）
  3. 小美的發送功能是好的（不然收不到訊息）
  4. 小美的接收功能是好的（因為小美有收到之前傳過去的訊息）

所以對小明來說，已經可以知道雙方的溝通管道是沒問題的了。但是對小美來說她還不知道啊，所以還需要最後一個步驟。

第三步：小明傳給小美：「收到，太好了」

小美收到訊息以後，就又知道兩件事情：

  1. 自己的發送功能是好的（因為前一句有發出去，小明才會回這個訊息）
  2. 小明的接收功能是好的（因為前一句小明有收到）

或者也可以參考底下的動圖，代表的是「在接收到訊息時，可以確認的自己的部分」：

從以上的推論可以知道，如果這三個步驟都正常地進行，就代表這兩人之間的溝通管道是沒有問題的，傳紙條都不會被漏掉。

有了這一個確認溝通的機制之後，小明鼓起勇氣再一次的告白，而這次終於在榕樹下等到小美了 🎉

傳紙條守則

從以上的故事當中，可以得知三個傳紙條守則：

  1. 寫明來源
  2. 寫明目的地
  3. 經過三次的前置作業，確保雙方都能收發

其實可以把傳紙條這件事情「分層」來看，意思就是把傳紙條分成不同的層級，每一層都只專注於傳紙條的其中一個面向：

最底下一層就是傳紙條，指的就是「傳遞紙條」這個實體的動作，可是如果只有這層的話，你怎麼知道要把紙條傳給誰？所以中間那層是加上收發地址，才能知道要傳給誰嘛。

有了底下兩層，已經可以傳紙條給任何人了，但沒辦法保證收發是正常的。所以最上面那層代表的是「如何傳送資料」，意思是說你可以使用我們上面提到的機制（三個步驟）來傳紙條，就能夠確保收發正常，但你不想要也可以。

第一集故事中所對應到的網路概念

為什麼會用傳紙條來比喻網路？因為這兩者的本質是一樣的，都是「資訊的傳遞」。而故事中的紙條其實就是網路世界的「封包」，承載著要傳遞的資訊。

既然兩者是類似的，我們就可以從上面傳紙條的守則跟分層當中推導出網路的模型，先從傳紙條守則開始：

  1. 寫明來源，在網路世界中其實就是大家常聽到的 IP 位置
  2. 寫明目的地，同上
  3. 經過三次的前置作業，確保雙方都能收發。這個在網路裡是一個叫做「TCP 三次握手」的東西，TCP（Transmission Control Protocol）是一個通訊協定（Protocol），能夠保證雙方收發正常。

通訊協定是甚麼？簡單來說就是一些制定好的規則。

以傳紙條的例子來說，你可以隨意傳，但不能保證對方一定收得到。而為了不讓小明的悲劇重演，我們發明了一個通訊協定叫做《紙條保證傳得到通訊協定》，只要你符合這個協定裡面制定的規則，就能保證紙條的傳遞。

而這個規則就是我們前面所提到的三次前置作業。

所以在傳紙條的時候，你可以選擇亂傳但對方不一定接收的到，也可以選擇遵守《紙條保證傳得到通訊協定》，確保對方一定收得到。

網路也是一樣的，TCP 是一個保證你的封包可以被對方接收到的協定，確保雙方溝通無礙。那要符合什麼規則呢？就是我們前面所提到的三次前置作業，而專有名詞叫做 TCP 三次握手（Three-way handshake）。

會透過三次握手來確保雙方都收發功能都正常，才會開始進行後續的資料交換。

網路的分層

上面提到的紙條分層圖表裡面，可以對應到網路的分層：

以網路來說，最底下一層就是實際傳遞資料，例如說路由器或是海底電纜，是在真實世界傳遞訊號的方式。而收發地址這一層前面不是說過了，是透過 IP 位置嗎？雖然大家常常會簡稱為 IP，例如說查 IP 之類的，但 IP 的全名其實是：Internet Protocol，就是我們前面所提到的「協定」。

在這個協定裡面，有一個東西叫做 IP Address，就是你在網路上的地址。所以加上收發地址的這一層，對應到的網路通訊協定就是 IP。

而「如何傳送資料」那邊，對應到的是 TCP 通訊協定，只要你採用這個協定，就可以保證雙方收發正常。

第一集小結

在第一集裡面，我們用了傳紙條當作生活化的範例，主要是想讓大家知道「傳紙條就跟網路傳封包沒兩樣」，想讓大家把這兩個東西對應起來，在思考網路概念時就會比較有畫面。

而我們也把傳紙條與網路進行了「分層」，分層的好處就是可以很明確看到每一層關注的東西都不同，所以只要處理跟那一層有關的事情就好了。

而第一集最後，我們導入了《紙條保證傳得到通訊協定》（TCP），來確保收發正常。能夠確保傳輸正常以後，就有了更多傳紙條的應用出現。

第二集：便當篇

小明跟小美的故事傳遍了整個校園，大家都知道了傳紙條的威力，紛紛透過類似的方法傳紙條給自己心儀的對象，想要效法他們兩個。

在校園當中，有個食量很大的同學千千卻看到了傳紙條的潛力，認為傳紙條不應該只是談情說愛的工具，它可以做到的事情還多著呢。

例如說：訂便當。

千千在校園中開啟了代訂便當的服務，只要傳紙條給她並說明要訂什麼便當，千千就會回傳訂便當是否成功以及價錢，從中收取 5~10 元不等的手續費：

順帶一提，千千的代訂便當服務是有遵守《紙條保證傳得到通訊協定》的，否則訊息漏掉就糟糕了，就會發生有同學以為自己有訂但其實沒訂到的這種狀況。

在那個還沒有空腹熊貓的年代，代訂便當服務在校園中快速竄紅，吃膩學校營養午餐的人都透過千千來幫忙代訂便當，而千千也從中賺到不少零用錢。

但隨著使用人數愈來愈多，千千發覺到了一些問題。

問題一：數字格式不統一

明明就是訂便當這麼簡單的一件事，卻有一些人很喜歡用不同的數字格式，不寫「一個排骨飯」而是寫「乙個排骨飯」，還有人是晶晶體的愛好者，寫「two 個雞腿飯」，千千只好無奈地以其人之道還治其人之身，回了個「你在公 three 小？」

這些格式的問題讓千千很困擾，因為她必須每一張紙條都很仔細看，才能看出對方到底要幾個便當。為了改善這個問題，千千決定統一格式，紙條一律都要長得像：

排骨飯 2
雞排飯 3
雞腿飯 5

這種格式，就是「品項 數量」，這樣子千千就能夠一目了然，迅速知道同學們到底想要什麼。

問題二：特殊需求

雖然說統一了品項的格式，但有時候同學會有些特殊需求，也是讓千千很苦惱的問題，例如說：

上面的紙條就寫明了要在第四堂送到，並且要加辣。而每個不同的同學都會有各自的特殊需求，這方面一定也要統一格式才行。

於是千千決定把紙條分成兩部分，上半部跟下半部，上半部就叫做 header，下半部叫做 body，靈感來自於人類的頭跟身體。header 的部分放特殊需求，而且要符合一定格式；body 的部分則放真正的訂單內容，如下圖所示：

如此一來，千千就可以很快地掌握這張紙條想要表達的意涵。

問題三：回覆格式

對於每一張紙條，千千在收到之後都要做後續處理並且回覆。

例如說當排骨飯賣完了，就會回說：「排骨賣完了，換一個吧」；或是如果有同學字寫太醜導致千千看不懂，就會回說：「第三行字太醜看不懂」，有時候訂單一多，千千也會挑客人，不接邊緣人的訂單，因為數量太少了沒賺頭，會回說：「一個便當太少了，我不接」。

經過一段時間以後，千千意識到一件事情，那就是會發生的狀況其實都差不多，可能就那五六種而已，但以現在的情形來說，每次都要寫一樣的字，實在是很麻煩的一件事情。

這時候千千有了一個 idea，何不把這些情況變成數字呢？提供大家一張數字代碼對照表，例如說 200 對應到「訂購成功」，這樣只要在紙條上面寫 200，對方就知道有成功了，就可以少寫一大堆字！

於是千千把狀況歸類成這六個，並且把這個回傳代碼對照表發給所有同學：

可是還有一個問題，代碼歸代碼，但有時候除了這些制式化的代碼以外，還要寫一些解釋才行。例如說「400 你紙條內容有錯，我看不懂」，還要明確指出是哪一行有錯，不然對方也不知道怎麼修正。

於是千千也把自己的回覆分成了 header 與 body 兩個部分，利用 header 傳這個代碼，必要時則在 body 說明附加訊息，會長的像這樣：

如此一來，也成功地解決了問題，大部分情形都只要回傳一個數字，不用跟之前一樣寫那麼多字了，真是可喜可賀。

問題四：動作不統一

這是最後一個問題了，就是動作不統一。

什麼是動作不統一呢？除了訂便當以外，還有可能會修改訂單啊！例如說有同學突然想翹課去打咖，就要跟千千說要少訂一份便當，否則多一份很不方便。或者是原本有同學訂了排骨飯，看了雞排妹的影片之後突然很想吃雞排，想改成雞排飯。

這一些東西也應該統一才對，不然對千千來說太累了。

於是千千決定在紙條的 header 加一個欄位，大家可以放四種動詞之一：

  1. GET 取得訂單資訊
  2. POST 訂便當
  3. DELETE 取消訂單
  4. PUT 修改訂單

例如說想要訂便當，就是傳這樣一個紙條：

POST
送達時間：第四堂

雞腿飯 5
雞排飯 2

若是想要取消訂單，就是這樣：

DELETE

雞腿飯

這樣千千就能很明確地看出這張紙條到底是想要幹嘛了。

千千的專長之一就是發現問題並且解決它，運用自己的頭腦解決了上面四個棘手的問題，把代訂便當的事業做得愈來愈大。

第二集所對應到的網路概念

從第二集訂便當服務的發展過程當中，我們可以很清楚地知道一件事情。

想要規模化，就要標準化

當你今天只在一個 30 人的班級裡面經營代訂便當服務時，哪來這麼多規則要管？反正人很少，你自己每張紙條都慢慢解讀就好，也花不多少時間。

可是，當千千想把事業擴張到全校 30000 名同學時（人還是不多就是了，畢竟只有狠愛演工作團隊的一半），就必須先把自己的工作流程標準化，因為這是規模化的前置作業。若是沒有標準化，解讀一張紙條可能要花 10 秒，但如果標準化了，可能只要 1 秒，效率是十倍。

這就是為什麼千千要透過不斷地制定規則去約束紙條的內容，因為這樣可以讓解讀紙條這件事變得更快更容易，千千才能處理更多的訂單。

在網路世界也是如此，為什麼要有 Protocol？為什麼要有這些規範？因為網路的封包都是由電腦來解讀的，它跟人腦最大的差別在於它是死的。

例如說「一個便當」、「乙個便當」、「one 個 bento」，對人類來說很輕易能夠看得懂這三個是在指涉同一個東西，但是對電腦來說，只是三個不同的「字串」，是三個不同的詞，它沒辦法知道這三個其實是一樣的。

所以必須制定一套標準，例如說「便當 1」這樣的格式，讓輸入全都符合這一套格式，電腦就只要去解析這一個單一格式就好。

開頭有提到說這個訂便當的服務是建立在《紙條保證傳得到通訊協定》之上，其實除了訂便當以外，還能發展出更多的服務，例如說訂飲料之類的，這些說穿了其實都是「如何應用傳紙條」來建立更多服務。

而這一段故事裡所提到的「訂便當服務」，對應到網路中其實就是我們最常看到的 HTTP（Hypertext Transfer Protocol）：

這邊會是我們傳紙條模型的最上層，因為確認如何傳送資料以後，就可以發展出更多實際應用。例如說「用紙條談情說愛」是一種傳紙條的應用，「用紙條訂便當」也是，你想拿來做什麼就可以做什麼。

在前面的故事中，我們可以得出底下的傳紙條守則：

  1. 標準化內容格式
  2. 分為 header 跟 body
  3. 用狀態碼標準化結果
  4. 用動詞標準化動作

而這四個其實就是 HTTP 通訊協定的內容。

在這邊簡單介紹一下 HTTP，例如說你透過瀏覽器輸入 http://google.com 並按下 Enter 之後，其實背後就是發了一個：

GET（用動詞標準化動作）

http://google.com

的紙條出去

而 Google 的 Server 在收到這張紙條並處理過後，就會把畫面傳回來，回傳的格式其實就跟千千回傳的格式差不多：

Status: 200（用狀態碼標準化結果）

<html>…..</html>（分為 header 與 body）

所以網頁運作背後其實是透過 HTTP 這個協定，也可以想成就是訂便當這個協定，只是把便當換成了網頁。（或是更廣義來說，把便當換成了「資源（resource）」）。

這樣你在學習 HTTP 這個通訊協定的時候，就不會對 Status code 感到陌生，它就只是傳紙條故事中的「用狀態碼標準化結果」而已；也不會覺得那些 HTTP method 很奇怪，那也只是故事中的「用動詞標準化動作」。

只要你能想起之前訂便當的故事，就能知道為什麼會有這些東西，以及這些東西到底在幹嘛。

第三集：發大財篇

透過代訂便當服務，千千在學生時期就賺到了人生中的第一桶金。但千千的野心並沒有在此而止步，下一個階段，她想讓同班同學們一起發大財。

具體上應該怎麼做呢？

就是發展不同的業務，並且讓每個同學都負責一個獨立的業務，才不會彼此互相干涉。舉例來說，A 同學負責代訂飲料服務，B 同學負責 NBA 即時戰況報導，C 同學負責借籃球等等。

但馬上就碰到一個問題，那就是紙條該傳給誰？

如果傳給 A 同學本人，那 A 同學請假怎麼辦？所以應該是傳到班級就好，並且標注需要的服務，例如說：

From 一班雜魚
To 八班：訂飲料

POST
送達時間：三點前

全糖珍珠奶茶 5
過氣的黃金比例翡翠檸檬 1

在冒號後面接上需要的服務，八班的人自然就會把這個紙條傳給對應到的同學。

這些字寫久了手也是會痠的，於是同學們決定效法之前千千提出的「數字對照表」的概念，把這些服務也換成數字：

這樣子用數字來表示就好，方便很多，大家只要有這個表格就可以來做對照。當八班的同學收到這張紙條以後，就會根據上面的服務轉給負責處理的那一位同學。

而接下來又碰到一個問題，就是格式。千千當初是以訂便當為基礎，才有了現在看到的格式，例如說狀態代碼、動詞以及 header、body 等等的設置。

可是有些服務根本用不到這些啊！

例如說「幫忙借籃球」服務，就只需要知道幾顆就好，不會有修改或是取消的事情發生，根本不需要這麼複雜的格式。

於是借籃球服務就有了自己獨特的格式，只要寫一兩個字就好：

再來呢，原本的傳紙條也都是建立在《紙條保證傳得到通訊協定》之上，每次傳之前都要先經過三次的確認。但有些同學發現「NBA 即時戰況」這個服務並不需要這件事，因為每隔三秒鐘，就會寫一張新的紙條到指定的班級去。

就算中間漏掉兩張紙條，也只損失了六秒鐘的戰況而已，這時間可能比數完全沒有變動！再者，如果少掉了前面三次確認這個前置作業，傳紙條的速度就可以更快，可以更即時地提供戰況訊息。

於是，他們後來就決定不讓 NBA 即時戰況這個服務遵守《紙條保證傳得到通訊協定》，因為根本沒有必要。在這個服務上，不遵守這個協定可以得到更多的好處。

就這樣，千千他們班開發出來的服務愈來愈多元，全校三個年級的學生都是他們的客戶，實現了千千一開始的願景：全班一起發大財。

至於之後千千碰到競爭對手惡意竄改紙條，就是另外一個故事了。

第三集所對應到的網路概念

這一集裡面我們多了許多不同的服務，也產生了對應的服務代碼，這些對應到網路世界裡就是 Port（連線埠，中國翻叫端口）的概念，一台主機上面可以跑很多不同的服務，但你要怎麼區別呢？就是利用 Port（服務代碼）。

就像千千班上一樣，有訂便當、訂飲料還有借籃球，要把紙條傳到「八班：3000」才是訂飲料這個服務。網路也是如此，一台主機上有很多服務，你一定要傳到「Server IP：80」才是 HTTP 伺服器這個服務。

每一種服務都有預設的 Port，例如說 HTTP 是 80，FTP（File Transfer Protocol）是 21，所以你會發現在使用瀏覽器的時候沒有輸入 Port，因為預設就是 80，所以不用特別填寫。

這可以對應到我們之前的圖表，在最上面一層「實際應用」，可以有不同的應用，例如說訂便當跟訂飲料。網路世界的話則是 HTTP 跟 FTP 這兩個不同的通訊協定。

除此之外，第二集裡面我們以訂便當做基礎，發展出了一堆格式，而這些格式其實都只是為了更方便訂便當，對其他的服務不一定適用。

舉例來說，「借籃球」就不適用，而且還造成反效果，增添了複雜度。或是故事中的 NBA 即時戰況也一樣，甚至連第一集尾聲的《紙條保證傳得到通訊協定》都不適用，因為漏掉訊息根本沒差，更重要的是傳輸的即時性。

這邊對應到網路的話，就是說不同服務可以有不同的內容格式，不一定都要遵照同一個。而 NBA 即時戰況那個案例告訴我們說，可以不遵守《紙條保證傳得到通訊協定》。

在傳輸資料的時候有很多種協定可以選擇， TCP 是一種，就是我們故事中的《紙條保證傳得到通訊協定》，還有另外一種叫做 UDP（User Datagram Protocol），就是上面提到的「漏掉訊息沒差，重要的是傳輸即時性」的通訊協定。

在「如何傳送資料」這一層裡面，有可以保障收發正常的 TCP，也有不能保障但是效能較好的 UDP，而上層的實際應用可以選擇任何一種。

這邊的圖可能有點小誤導所以要特別說明，圖片並不是說 FTP 建立在 UDP 之上，只是想表達應用這一層有 HTTP 「與」 FTP，傳輸這層有 TCP「與」UDP，而 HTTP 與 FTP 事實上都選擇了以 TCP 作為傳輸方式。

舉例來說，HTTP 就像訂便當一樣，為了保證訊息收發正常，就選擇了 TCP（不過最新的 HTTP/3 又是另一個故事了，這個先跳過）；而通常那種即時通話或是視訊的通訊協定都會選擇 UDP，因為少掉幾個封包根本沒有差，比較重要的是傳輸的速度，就像 NBA 即時戰況一樣。

總結

在上面連續三集的故事裡面，我們透過傳紙條這個實際案例，去想像會碰到的困難以及解決方法，每一種優化方法都其來有自，絕對不是憑空產生的。

而傳紙條的這個模型，其實就是俗稱的 TCP/IP 四層模型：

這個模型會把網路分成四層，每一層都關注不同的面向，例如說傳輸層指的就是「你要以什麼方式來傳送資料？」，而應用層是最貼近我們的一層，就是實際應用。這四層關注的對象也可以透過傳紙條的例子來看，會清楚很多。

對我來說，與其去思考「為什麼會有 HTTP？」、「為什麼要這樣分層？」，不如先從傳紙條的例子開始慢慢去想，去想說當服務變大的時候該怎麼辦，當格式不統一的時候該做些什麼，這時候就會發現這些問題的解答，就是 Protocol 出現的原因。

傳紙條的故事可以直接對應到網路相關的例子，而這樣子的對應我認為很能幫助大家對於網路相關知識的理解。

希望這一篇對大家有幫助，能夠更理解 TCP/IP 以及 HTTP 這些通訊協定。

這篇的文章內容其實最早出自線上課程：[NET101] 網路基礎概論（搭配 JS 實作練習）的前幾個單元，有興趣的可以去看一下。不過課程中最精彩的部分就在這篇文章裡了，而且是修正過的版本，內容要比影片再豐富一點。

備註：有關於三次握手，其實不是為了確保雙方都能夠收發，更詳細的解釋可以參考：为什么 TCP 建立连接需要三次握手 · Why’s THE Design?

想持續關注的話可以 follow 一下，單純手癢想按按鈕也可以按個 follow，或是考慮一下關注 Lidemy 粉絲專頁。想看更多文章可以參考我的 Medium 文章列表：https://aszx87410.github.io/blog/medium。