從傳紙條輕鬆學習基本網路概念 - Huli – Medium

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

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

希望透過這一系列的傳紙條小故事，可以讓大家理解什麼是TCP/IP，什麼又是HTTP協定，以及這些東西到底是為了什麼而誕生的。

雖然說希望讀者沒有任何相關背景也能看懂，但其實比較適合已經大概知道什麼是TCP/IP以及HTTP的讀者觀看，會比較容易知道這一篇到底在講什麼。

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

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

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

雖然說一堂課大概45分鐘左右，也不會到很長，但有些話就是想立刻跟對方分享，一刻都等不及。

因此，大家都會利用上課時間傳紙條來跟其他人對話（題外話，現在的國高中生是不是都不傳紙條了啊，傳Line就好）。

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

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

傳紙條示意圖原本一切都進行得很順利，他們兩人之間的感情透過一張張的紙條不斷堆疊，越來越熟悉彼此，走得一天比一天近。

而小明心中也慢慢浮現了一個想法：「好像差不多是時候告白，表示我的心意了」。

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

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

除此之外，也要把寄件人寫清楚，才知道紙條回傳的時候要給誰。

其實就跟寄信差不多啦，只要把收件人跟寄件人寫清楚，其他同學就會充當郵差的角色，幫你把紙條傳到對方手上。

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

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

原本小明想繼續等的，但無奈老天爺都為他哭泣，天空抑制不了衝動，落下雨和眼淚，小明只好狼狽地走回家裡。

這樣也好，就跟倒立淚水就不會流出來一樣，只要下雨，就分不清楚臉上的是雨水還是淚水了。

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

咦…該不會對她而言，真的什麼都沒發生吧？於是小明在下課的時候鼓起勇氣去問了小美：「昨天…你怎麼沒有來」，沒想到小美一臉疑惑，說道：「什麼意思？」。

就在這個瞬間，小明知道了一件事：「靠夭，原來我的紙條沒有傳到」。

確保溝通的辦法雙方的溝通如果想要順暢，說穿了就是要確保以下四點：發送方的傳送功能發送方的接收功能接收方的傳送功能接收方的接收功能簡單來講就是雙方的傳送跟接收都必須要正常，否則就會發生遺漏訊息的狀況，例如說A發給B，可是B的接收壞掉了，或者是B回傳給A，可是B的訊息根本發不出去。

那要怎麼樣確保這四個功能都正常呢？可以透過三個打招呼的步驟來確認。

以下直接用小明以及小美來舉例：小明傳給小美：安安，在嗎？小美收到後回覆：在呀，你好小明收到後回覆：收到，太好了如果這三個步驟都能夠順利進行，就代表彼此之間溝通的管道無礙。

不過有一點要注意，這邊先假設一旦某個功能確認正常以後就不會改變，例如說小明的發送功能如果確認正常，就不會突然失效。

以傳紙條的例子來說，就是幫你傳紙條的同學不會無緣無故消失的意思。

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

第一步：小明傳送給小美：「安安，在嗎？」如果小美沒收到這個訊息，那就代表小明的發送或者是小美的接收端有問題，所以就可以確認溝通管道是有問題的。

如果小美收到了這個訊息，從小美的角度來看，就知道兩件事：自己的接收功能是好的（否則收不到訊息）小明的發送功能是好的（否則收不到訊息）第二步：小美傳送給小明：「在呀，你好」小明收到這個訊息以後，就可以知道四件事情：自己的發送功能是好的（因為小美一定有收到之前傳的「安安，在嗎」，才會回傳這個訊息）自己的接收功能是好的（不然收不到訊息）小美的發送功能是好的（不然收不到訊息）小美的接收功能是好的（因為小美有收到之前傳過去的訊息）所以對小明來說，已經可以知道雙方的溝通管道是沒問題的了。

但是對小美來說她還不知道啊，所以還需要最後一個步驟。

第三步：小明傳給小美：「收到，太好了」小美收到訊息以後，就又知道兩件事情：自己的發送功能是好的（因為前一句有發出去，小明才會回這個訊息）小明的接收功能是好的（因為前一句小明有收到）或者也可以參考底下的動圖，代表的是「在接收到訊息時，可以確認的自己的部分」：從以上的推論可以知道，如果這三個步驟都正常地進行，就代表這兩人之間的溝通管道是沒有問題的，傳紙條都不會被漏掉。

有了這一個確認溝通的機制之後，小明鼓起勇氣再一次的告白，而這次終於在榕樹下等到小美了🎉傳紙條守則從以上的故事當中，可以得知三個傳紙條守則：寫明來源寫明目的地經過三次的前置作業，確保雙方都能收發其實可以把傳紙條這件事情「分層」來看，意思就是把傳紙條分成不同的層級，每一層都只專注於傳紙條的其中一個面向：傳紙條分層最底下一層就是傳紙條，指的就是「傳遞紙條」這個實體的動作，可是如果只有這層的話，你怎麼知道要把紙條傳給誰？所以中間那層是加上收發地址，才能知道要傳給誰嘛。

有了底下兩層，已經可以傳紙條給任何人了，但沒辦法保證收發是正常的。

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

第一集故事中所對應到的網路概念為什麼會用傳紙條來比喻網路？因為這兩者的本質是一樣的，都是「資訊的傳遞」。

而故事中的紙條其實就是網路世界的「封包」，承載著要傳遞的資訊。

既然兩者是類似的，我們就可以從上面傳紙條的守則跟分層當中推導出網路的模型，先從傳紙條守則開始：寫明來源，在網路世界中其實就是大家常聽到的IP位置寫明目的地，同上經過三次的前置作業，確保雙方都能收發。

這個在網路裡是一個叫做「TCP三次握手」的東西，TCP（TransmissionControlProtocol）是一個通訊協定（Protocol），能夠保證雙方收發正常。

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

以傳紙條的例子來說，你可以隨意傳，但不能保證對方一定收得到。

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

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

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

網路也是一樣的，TCP是一個保證你的封包可以被對方接收到的協定，確保雙方溝通無礙。

那要符合什麼規則呢？就是我們前面所提到的三次前置作業，而專有名詞叫做TCP三次握手（Three-wayhandshake）。

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

網路的分層上面提到的紙條分層圖表裡面，可以對應到網路的分層：紙條與網路的分層以網路來說，最底下一層就是實際傳遞資料，例如說路由器或是海底電纜，是在真實世界傳遞訊號的方式。

而收發地址這一層前面不是說過了，是透過IP位置嗎？雖然大家常常會簡稱為IP，例如說查IP之類的，但IP的全名其實是：InternetProtocol，就是我們前面所提到的「協定」。

在這個協定裡面，有一個東西叫做IPAddress，就是你在網路上的地址。

所以加上收發地址的這一層，對應到的網路通訊協定就是IP。

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

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

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

而第一集最後，我們導入了《紙條保證傳得到通訊協定》（TCP），來確保收發正常。

能夠確保傳輸正常以後，就有了更多傳紙條的應用出現。

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

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

例如說：訂便當。

千千在校園中開啟了代訂便當的服務，只要傳紙條給她並說明要訂什麼便當，千千就會回傳訂便當是否成功以及價錢，從中收取5~10元不等的手續費：訂便當示意圖順帶一提，千千的代訂便當服務是有遵守《紙條保證傳得到通訊協定》的，否則訊息漏掉就糟糕了，就會發生有同學以為自己有訂但其實沒訂到的這種狀況。

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

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

問題一：數字格式不統一明明就是訂便當這麼簡單的一件事，卻有一些人很喜歡用不同的數字格式，不寫「一個排骨飯」而是寫「乙個排骨飯」，還有人是晶晶體的愛好者，寫「two個雞腿飯」，千千只好無奈地以其人之道還治其人之身，回了個「你在公three小？」這些格式的問題讓千千很困擾，因為她必須每一張紙條都很仔細看，才能看出對方到底要幾個便當。

為了改善這個問題，千千決定統一格式，紙條一律都要長得像：排骨飯2雞排飯3雞腿飯5這種格式，就是「品項數量」，這樣子千千就能夠一目了然，迅速知道同學們到底想要什麼。

問題二：特殊需求雖然說統一了品項的格式，但有時候同學會有些特殊需求，也是讓千千很苦惱的問題，例如說：紙條的特殊格式上面的紙條就寫明了要在第四堂送到，並且要加辣。

而每個不同的同學都會有各自的特殊需求，這方面一定也要統一格式才行。

於是千千決定把紙條分成兩部分，上半部跟下半部，上半部就叫做header，下半部叫做body，靈感來自於人類的頭跟身體。

header的部分放特殊需求，而且要符合一定格式；body的部分則放真正的訂單內容，如下圖所示：看起來清爽一百倍如此一來，千千就可以很快地掌握這張紙條想要表達的意涵。

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

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

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

這時候千千有了一個idea，何不把這些情況變成數字呢？提供大家一張數字代碼對照表，例如說200對應到「訂購成功」，這樣只要在紙條上面寫200，對方就知道有成功了，就可以少寫一大堆字！於是千千把狀況歸類成這六個，並且把這個回傳代碼對照表發給所有同學：訂便當回傳代碼對照表可是還有一個問題，代碼歸代碼，但有時候除了這些制式化的代碼以外，還要寫一些解釋才行。

例如說「400你紙條內容有錯，我看不懂」，還要明確指出是哪一行有錯，不然對方也不知道怎麼修正。

於是千千也把自己的回覆分成了header與body兩個部分，利用header傳這個代碼，必要時則在body說明附加訊息，會長的像這樣：字太醜錯了嗎，QQ如此一來，也成功地解決了問題，大部分情形都只要回傳一個數字，不用跟之前一樣寫那麼多字了，真是可喜可賀。

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

什麼是動作不統一呢？除了訂便當以外，還有可能會修改訂單啊！例如說有同學突然想翹課去打咖，就要跟千千說要少訂一份便當，否則多一份很不方便。

或者是原本有同學訂了排骨飯，看了雞排妹的影片之後突然很想吃雞排，想改成雞排飯。

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

於是千千決定在紙條的header加一個欄位，大家可以放四種動詞之一：GET取得訂單資訊POST訂便當DELETE取消訂單PUT修改訂單例如說想要訂便當，就是傳這樣一個紙條：POST送達時間：第四堂雞腿飯5雞排飯2若是想要取消訂單，就是這樣：DELETE雞腿飯這樣千千就能很明確地看出這張紙條到底是想要幹嘛了。

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

第二集所對應到的網路概念從第二集訂便當服務的發展過程當中，我們可以很清楚地知道一件事情。

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

可是，當千千想把事業擴張到全校30000名同學時（人還是不多就是了，畢竟只有狠愛演工作團隊的一半），就必須先把自己的工作流程標準化，因為這是規模化的前置作業。

若是沒有標準化，解讀一張紙條可能要花10秒，但如果標準化了，可能只要1秒，效率是十倍。

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

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

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

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

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

而這一段故事裡所提到的「訂便當服務」，對應到網路中其實就是我們最常看到的HTTP（HypertextTransferProtocol）：網路與傳紙條的分層這邊會是我們傳紙條模型的最上層，因為確認如何傳送資料以後，就可以發展出更多實際應用。

例如說「用紙條談情說愛」是一種傳紙條的應用，「用紙條訂便當」也是，你想拿來做什麼就可以做什麼。

在前面的故事中，我們可以得出底下的傳紙條守則：標準化內容格式分為header跟body用狀態碼標準化結果用動詞標準化動作而這四個其實就是HTTP通訊協定的內容。

在這邊簡單介紹一下HTTP，例如說你透過瀏覽器輸入http://google.com並按下Enter之後，其實背後就是發了一個：GET（用動詞標準化動作）http://google.com的紙條出去而Google的Server在收到這張紙條並處理過後，就會把畫面傳回來，回傳的格式其實就跟千千回傳的格式差不多：Status:200（用狀態碼標準化結果）…..（分為header與body）所以網頁運作背後其實是透過HTTP這個協定，也可以想成就是訂便當這個協定，只是把便當換成了網頁。

（或是更廣義來說，把便當換成了「資源（resource）」）。

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

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

第三集：發大財篇透過代訂便當服務，千千在學生時期就賺到了人生中的第一桶金。

但千千的野心並沒有在此而止步，下一個階段，她想讓同班同學們一起發大財。

具體上應該怎麼做呢？就是發展不同的業務，並且讓每個同學都負責一個獨立的業務，才不會彼此互相干涉。

舉例來說，A同學負責代訂飲料服務，B同學負責NBA即時戰況報導，C同學負責借籃球等等。

但馬上就碰到一個問題，那就是紙條該傳給誰？如果傳給A同學本人，那A同學請假怎麼辦？所以應該是傳到班級就好，並且標注需要的服務，例如說：From一班雜魚To八班：訂飲料POST送達時間：三點前全糖珍珠奶茶5過氣的黃金比例翡翠檸檬1在冒號後面接上需要的服務，八班的人自然就會把這個紙條傳給對應到的同學。

這些字寫久了手也是會痠的，於是同學們決定效法之前千千提出的「數字對照表」的概念，把這些服務也換成數字：服務代碼一覽表這樣子用數字來表示就好，方便很多，大家只要有這個表格就可以來做對照。

當八班的同學收到這張紙條以後，就會根據上面的服務轉給負責處理的那一位同學。

而接下來又碰到一個問題，就是格式。

千千當初是以訂便當為基礎，才有了現在看到的格式，例如說狀態代碼、動詞以及header、body等等的設置。

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

於是借籃球服務就有了自己獨特的格式，只要寫一兩個字就好：超級簡潔再來呢，原本的傳紙條也都是建立在《紙條保證傳得到通訊協定》之上，每次傳之前都要先經過三次的確認。

但有些同學發現「NBA即時戰況」這個服務並不需要這件事，因為每隔三秒鐘，就會寫一張新的紙條到指定的班級去。

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

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

在這個服務上，不遵守這個協定可以得到更多的好處。

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

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

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

就像千千班上一樣，有訂便當、訂飲料還有借籃球，要把紙條傳到「八班：3000」才是訂飲料這個服務。

網路也是如此，一台主機上有很多服務，你一定要傳到「ServerIP：80」才是HTTP伺服器這個服務。

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

這可以對應到我們之前的圖表，在最上面一層「實際應用」，可以有不同的應用，例如說訂便當跟訂飲料。

網路世界的話則是HTTP跟FTP這兩個不同的通訊協定。

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

舉例來說，「借籃球」就不適用，而且還造成反效果，增添了複雜度。

或是故事中的NBA即時戰況也一樣，甚至連第一集尾聲的《紙條保證傳得到通訊協定》都不適用，因為漏掉訊息根本沒差，更重要的是傳輸的即時性。

這邊對應到網路的話，就是說不同服務可以有不同的內容格式，不一定都要遵照同一個。

而NBA即時戰況那個案例告訴我們說，可以不遵守《紙條保證傳得到通訊協定》。

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

不同傳送資料的方式在「如何傳送資料」這一層裡面，有可以保障收發正常的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’sTHEDesign?想持續關注的話可以follow一下，單純手癢想按按鈕也可以按個follow，或是考慮一下關注Lidemy粉絲專頁。

想看更多文章可以參考我的Medium文章列表：https://aszx87410.github.io/blog/medium。

MorefromHuliFollow重度拖延症患者，興趣是光想不做，有很多想做的事，卻一件都沒有執行。

無聊的時候喜歡寫文章，發現自己好像有把事情講得比其他人清楚的能力。

相信分享與交流可以讓世界更美好。

Medium文章列表請參考：https://aszx87410.github.io/blog/mediumLovepodcastsoraudiobooks?Learnonthegowithournewapp.TryKnowableGetstartedHuli10.4KFollowers重度拖延症患者，興趣是光想不做，有很多想做的事，卻一件都沒有執行。

無聊的時候喜歡寫文章，發現自己好像有把事情講得比其他人清楚的能力。

相信分享與交流可以讓世界更美好。

Medium文章列表請參考：https://aszx87410.github.io/blog/mediumFollowRelatedShowbizCheatSheetofferscinephilesaplacetosupportfilmsthathavebeensnubbed?CREOENGINE:APLATFORMWITHLIMITLESSPOSSIBILITIESFORGAMMERSHowKajoCanActuallyEmpowerAnyoneinthePaymentIndustryVisualizingmyexperience|AmalAcademyBackin2021,IwasfortunateenoughtohaveaninternshipatNovatexLimited.Itwasduringthosetimes,IwastoldaboutAmalAcademyby…HelpStatusWritersBlogCareersPrivacyTermsAboutKnowable