每當提到「網路概念」這幾個字,就會想起以前上計算機概論的時候,一大堆名詞排山倒海而來,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(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 加一個欄位,大家可以放四種動詞之一:
- GET 取得訂單資訊
- POST 訂便當
- DELETE 取消訂單
- PUT 修改訂單
例如說想要訂便當,就是傳這樣一個紙條:
POST
送達時間:第四堂
雞腿飯 5
雞排飯 2
若是想要取消訂單,就是這樣:
DELETE
雞腿飯
這樣千千就能很明確地看出這張紙條到底是想要幹嘛了。
千千的專長之一就是發現問題並且解決它,運用自己的頭腦解決了上面四個棘手的問題,把代訂便當的事業做得愈來愈大。
第二集所對應到的網路概念
從第二集訂便當服務的發展過程當中,我們可以很清楚地知道一件事情。
想要規模化,就要標準化
當你今天只在一個 30 人的班級裡面經營代訂便當服務時,哪來這麼多規則要管?反正人很少,你自己每張紙條都慢慢解讀就好,也花不多少時間。
可是,當千千想把事業擴張到全校 30000 名同學時(人還是不多就是了,畢竟只有狠愛演工作團隊的一半),就必須先把自己的工作流程標準化,因為這是規模化的前置作業。若是沒有標準化,解讀一張紙條可能要花 10 秒,但如果標準化了,可能只要 1 秒,效率是十倍。
這就是為什麼千千要透過不斷地制定規則去約束紙條的內容,因為這樣可以讓解讀紙條這件事變得更快更容易,千千才能處理更多的訂單。
在網路世界也是如此,為什麼要有 Protocol?為什麼要有這些規範?因為網路的封包都是由電腦來解讀的,它跟人腦最大的差別在於它是死的。
例如說「一個便當」、「乙個便當」、「one 個 bento」,對人類來說很輕易能夠看得懂這三個是在指涉同一個東西,但是對電腦來說,只是三個不同的「字串」,是三個不同的詞,它沒辦法知道這三個其實是一樣的。
所以必須制定一套標準,例如說「便當 1」這樣的格式,讓輸入全都符合這一套格式,電腦就只要去解析這一個單一格式就好。
開頭有提到說這個訂便當的服務是建立在《紙條保證傳得到通訊協定》之上,其實除了訂便當以外,還能發展出更多的服務,例如說訂飲料之類的,這些說穿了其實都是「如何應用傳紙條」來建立更多服務。
而這一段故事裡所提到的「訂便當服務」,對應到網路中其實就是我們最常看到的 HTTP(Hypertext Transfer Protocol):
這邊會是我們傳紙條模型的最上層,因為確認如何傳送資料以後,就可以發展出更多實際應用。例如說「用紙條談情說愛」是一種傳紙條的應用,「用紙條訂便當」也是,你想拿來做什麼就可以做什麼。
在前面的故事中,我們可以得出底下的傳紙條守則:
- 標準化內容格式
- 分為 header 跟 body
- 用狀態碼標準化結果
- 用動詞標準化動作
而這四個其實就是 HTTP 通訊協定的內容。
在這邊簡單介紹一下 HTTP,例如說你透過瀏覽器輸入 http://google.com 並按下 Enter 之後,其實背後就是發了一個:
GET(用動詞標準化動作)
的紙條出去
而 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。