04 成為看起來很強的後端：網路是如何運作的－從瀏覽器到伺服器
瀏覽器（Google 的 Chrome或 Apple 的 Safari…等）是用來執行 HTML 、 CSS 的軟體，英文稱為 Browser 。
電腦版有瀏覽器、手機也有瀏覽器，兩者不一定相容，有一些網站在電腦版跑得起來、手機版不一定，畢竟是不同團隊寫出來。
瀏覽器外面是電腦，輸入網址按下 Enter 會把訊號發出去。
而電腦要能夠連上網路，透過插網路線或用 WiFi。
接著會經過路由器（Router）。
如果有住宿舍的經驗，宿舍房間可能會放很多個分享器讓室友可以收到網路。
而宿舍後面也有一個路由器，因此如果從同一個宿舍連出去 IP (Internet Protocol address) 就會長一樣。
我們在瀏覽器輸入的是一個網址（URL），網址需要知道對應的 IP 是什麼。
因此會經過一個叫做 DNS (Domain Name System, 域名系統) 的東西來進行 URL 到 IP 的翻譯。
URL 是我們平常輸入的 xxxx.com 這樣的網址。
IP 指得是實際網路上的位置。
KK 老師舉的例子是，寄信的時候我們會在信封上寫上地址，而郵局透過經緯度得到這個位置。
而 DNS 就會像郵局做這樣的轉換工作。
這樣我們的 URL 就能找到我們想要的特定伺服器（Server）。
伺服器處理完再把資料傳回去。
Server 長怎樣呢？
後面這個框框就是我們常講的「後端」，進入 Server 都是後端在處理的。
當很多請求（Request）來到伺服器的時候，需要一個調節的地方，也就是 Load Balance（附載平衡，感覺應該是 Load Balancer?）。
有了 Load Balancer 之後就可以把後面分成好幾台的伺服器。
KK 老師舉例，像是排隊結帳有三個櫃檯，有人在前面引導顧客去不同櫃檯一樣。
各種 Request 會透過 Load Balancer 到某台特定的 Server。
這邊要注意一個點，就是 Server 是一個很摸稜兩可的詞。
Server 的原意，就是在講伺服器那台機器本人。
有了一台硬體的 Server 機器之後，才能在上面起一個軟體 Web Server。
Web Server 就是一個軟體程式，後端工程師通常在實作這塊。
常見的 Web Server有哪些？
寫 Python 的話
寫 Node.js 的話：
寫 PHP 的話：
KK 老師白板上只有寫上面那個，然後另外一個唸起來像 call interger。
快速查一下 Laravel alternatives 之後，猜測是 CodeIgniter。
(Source: https://www.g2.com/products/laravel/competitors/alternatives)
KK 老師再次強調：以上這些都是用來實作 Web Server ，不是 Server 一台硬體機器。
一個 Request 進來有幾種做法。
第一種是讓 Web Server 直接接收，直接處理，然後給一個 Response 回去。
前面有提到，URL 會經過 DNS 轉成一個 IP 位置，有可能是 Load Balancer 也可能是某一台 Server。
那如果現在比較窮（只有一台機器），同時想要跑很多個程式要怎麼辦？
KK老師接下來舉例窮人版（什麼都沒有），說明不用擔心被打爆因為什麼都沒有。
如果想做形象官網、活動網站、課程網站…等，就在同一台硬體 Server 裡面多開幾個 Web Server 。
此時出現可愛貓叫聲（點這裡去看 YouTube ）。
聽起來沒什麼問題，但是 DNS 把 URL 轉成 IP 沒沒辦法知道你要去哪。
此時如果有一個網站叫做 www.test.com 和 course.test.com 和 ticket.test.com。
而這台 Server 的 IP 位置是 1.2.3.4。
這個時候要怎麼分辨要去哪個 Web Server 呢？
這邊就有一個機制叫做 Port （埠號）。
就像是船在入港，你載黃金到到幾號、木材到幾號、棉花到幾號…這種概念。
因此我們就能在 1.2.3.4 的 IP 位置後面加上 :8080 或 :8081 這樣的 port 。
DNS 只能幫你轉 IP 而不能幫你把 port 加上去，因此需要一個新的角色。
就像是航空公司有個中控台會去告訴飛機要到幾號跑道。
這東西就叫做 Reverse Proxy（反向代理）。
以前面的網址為例，Reverse Proxy 會把進來的 Request，根據網址內容送去不同的 Web Server。
用 Reverse Proxy 代理有什麼好處？
第一個是只有一台 Server 也可以實作。
第二個是可以把一些快取（Cache）放在 Reverse Proxy 上面，不用丟給 Server 運算，加快 Response 速度。
第三個是HTTP憑證問題，KK 未來會談到，可以掛在 Reverse Proxy 上面。
第四個是有一些靜態檔案(圖片、影片、檔案…等)存在硬碟裡面，透過反向代理就能直接拿到檔案。
有 Reverse Proxy 也就有 Proxy
既然有反向代理，就會有代理（Proxy）。
Reverse Proxy 是在伺服器端做代理角色，而 Proxy 會在 Router 出去的地方有個 Proxy Server。
中間有不少 Routing 的節點連過去，而 Proxy 在這邊也會做代理的事情。
如果你遇到別人的網頁被更新而你的還沒，那就有可能是 Proxy 上面存的資料還沒有被更新。
宿舍網路跟校園網路也會透過 Proxy 來防止惡意攻擊。
影片最後就是把 URL 到渲染出來的過程再重跑一次。
05 成為看起來很強的後端：網路是如何運作的－TCP/IP四層模型
KK老師前面跟我們描述了 URL 到 Server 的路徑，而背後的運作這邊會做更詳細的介紹。
舉例來說：你要寄一封信，可以買各種不同顏色的信封、買郵票，然後拿去給郵局的窗口。
此時就會在後面做配送、給郵差、送去物流中心、再靠郵差送去給對方。
網路模型有比較舊的 OSI model 七層架構 (https://en.wikipedia.org/wiki/OSI_model) 和現在比較常見的 TCP/IP 四層架構 (https://en.wikipedia.org/wiki/Internet_protocol_suite)
第一層：應用層
網頁上制定好的各種協議、應用。
不同的網站會用到不同的技術，例如串流應用可能就會用 RTSP 這樣的協議，或是網路 HTTP 或 檔案傳輸 FTP 。
前面舉例寄信用的各種信封，可以類比成這一層的應用層。
第二層：傳輸層
選好信封之後，要怎麼寄呢？
平信、掛號還是包裹呢？
傳輸層通常用兩種方式，TCP 和 UDP。
通常一般情況會用 TCP 為主。
TCP 有一些底層保證，例如三次握手，確保傳輸不會漏掉，會傳得比較慢。
類似掛號，郵差要確保有人來領信。
而 UDP 比較像是平信或明信片，掉了就算了。
語音或視訊這一類高速度應用，你有幾秒或是一小段掉了，比較不影響。
應用層的 HTTP 和 FTP 通常會走 TCP，而 RTSP 這種就會走 UDP。
第三層：網路層
這一層就是我們前面講的 IP 了。
類比來說就是收件者的位置（誰收、住址在哪裏）。
第四層：連階層
這邊就可以想成郵差或是郵局，用的是腳踏車還是汽車去運輸，我們不會知道。
有些可能走光纖、海底電纜…等實體連接方式。
有寄件就有收件
上圖左手邊就是我們的寄件者，右手邊是我們的收件者。
KK老師舉例我們寄掛號信到美國，美國的郵差再根據地只看要送到哪裡去。
再確認是不是掛號信或平信決定要不要簽名，最後看是什麼樣的信封，送給對方。
這一整段就是 URL 點下去到 Server 封包從寄件者封裝到收件者的解封裝。
每一層各自分工，應用層知道怎麼使用想要的協議、傳輸層處理資料傳輸是否要保證、網路層確保地址找得到、連階層確保東西可以傳。
一層一層的包起來，送過去再一層層的解開。
06 成為看起來很強的後端：網路是如何運作的－常見的應用層協議
KK老師現在要介紹的是各種常見應用層協議。
HTTP(HyperText Transfer Protocol Secure)/HTTPS(HyperText Transfer Protocol Secure)
多一個 S 是因為搭配了 SSL 的機制，KK說之後資訊安全的部分會再做說明。
HTTP 為目前網站最常見的協議。
FTP/SFTP
KK說有 S 通常代表有多做簽章 SSL 的部分。
（不過在查詢之後發現應該有 SSH 和 SSL 的差別，影片後面也有提到。）
FTP 主要處理檔案的傳輸，例如大學裡面有計算機中心會提供空間，可以利用 FTP 的方式傳輸。
常見的工具是 FileZilla 。https://filezilla-project.org/
Telnet
現在常看到的應用是用來上bbs，如：ptt 就會用 telnet://ptt.cc。
SMTP/POP3
SMTP主要用來寄信、POP3用來收信。
如果你想要處理 email 收發可以去 Google 這些關鍵字。
不過這個學問比較複雜，會碰到退信機制的處理或是防止信件掉到垃圾信件裡，會需要花比較多心思。
WS/WSS
WebSocket和 WebSocket over SSL。
WebSocket 跟 HTTP 最大的差異在，HTTP 使用的是「短連接」 Request-Response 模型。
這個圖省略了很多上一支影片有的細節。
而WebSocket是屬於「長連接」，兩邊會建立起一個通道，從頭到尾都不會斷。
就像是兩個國家串起運河，因此速度會非常快，網頁遊戲常用這個技巧。
WebSocket 這麼棒為什麼不所有網站都用呢？
因為要維護一個專屬通道，會有成本。
你的一個 Server 出入口有限，只要他跟某個 Client 建立 WebSocket，這個口就會被佔掉。
有越多 Client 就會佔掉越多，伺服器能乘載的有限，就需要開更多的伺服器。
因此這種「長連結」通常用在遊戲服務上。
SSH
通常是用來連進伺服器來用的協議(Protocol)，基於 SSL 技術去用公、私鑰的方式，從 Client 連到 Server。
所以如果你聽到有人說「給我 SSH 金鑰」或「我要用 SSH 連到某個地方」，意思就是想要進到某一台 Server 要如何處理。
RTSP(Real-Time Streaming Protocol)/RTMP(Real-Time Messaging Protocol)
主要用來處理串流。
如果是使用 HLS(HTTP Live Streaming)和 .mp4 檔案就會走 RTSP 協議。
如果是使用 .flv 檔案就會走 RTMP 這個協議。
都是用在處理即時串流的技術，會把影片切成很多小段，分別傳輸。
跟 HTTP 一包傳輸的方式是不一樣的。
07 成為看起來很強的後端：網路是如何運作的－HTTP協定
KK老師接下來特別來細講 HTTP 協定。
上面是 Header ，下面是 Body。
Header 是什麼？
Header 裡面會有HTTP的「動詞」。
常見的有 GET / POST / PUT / DELETE ，主要是為了識別這個 HTTP 請求是要做什麼的目的。
通常 GET 用來拿資料、 POST 和 PUT 用來更改資料、 DELETE 用來刪除資料。
KK 之後會介紹這些和更多動詞。
Header 裡面也會有「路徑（PATH）」和 「HOST」。
路徑就是我們常看到的網址裡面斜線「/」後面的東西。
以 https://google.com/search 後面的 search 就是路徑，前面的 google.com 就是 HOST。
而這一整段 URL 是有一個格式的，最前面描述 Protocol，接一個 hostname和 port。
Protocol://hostname:port
Hostname也可以使用 IP ，這樣 DNS 就不用解析，不然平常看到的 google.com 這種 domain 也是可以的。
而 port (埠號) 後面會接一個 path 跟一個 ?search。
舉例來說 Protocol://hostname:port/path?search 後面可能網址會看到 ?q=123&x=5，這就是拿來做 filter 用的（根據條件篩選）。
Header 裡面還會放來源（Origin） ，這樣伺服器才能辨認是從哪個 IP 或 URL 打過來的。
以寄信的例子來說，就是寄件者的地址。
那寄件者的名字呢？就是 User-Agent。
透過 User-Agent 就能知道使用者用什麼瀏覽器，或這個使用者是不是爬蟲。
不過， User-Agent 是可以偽造的，後面資訊安全的章節， KK老師會再多做介紹。
Header裡面也有權限、快取、cookie相關的東西，之後會介紹。
而這些請求的基本資料，我們通通稱為 meta 的 information。
Body 是什麼？
Body指的是 Request 希望伺服器去拿的內容，因此如果使用 GET 通常就不會有 Body 的資訊。
不過如果要透過 POST 給伺服器資料，就可能會用到 Body 。
格式有很多種，很常見的一個是 JSON 格式。
KK 說，不知道 JSON 格式的同學，可以 Google 一下。
或是如果大家敲碗，未來 KK 也可以錄影片介紹
除了 JSON 格式之外，我們也可以傳一個檔案出去，就是 multipart 的格式，也可以傳 text 。
Body 帶什麼樣的內容，也需要在 Header 裡面告訴伺服器，伺服器才知道用什麼格式來解析。
這就稱為 Content-Type，用來指定格式，是圖片、form、純文字還是 .csv 等等。
這樣伺服器才知道怎麼回你。
KK 最後補充，通常 HTTP 得 Header 如果一個字習慣用 CamelCase 樣的寫法，兩個字就是用中間一個 dash 。
現在大部分的套件（express, flask, django）都會自動處理掉，但如果各位適用 Ｃ或是 Java，伺服器可能會看不懂，要特別注意喔。
