前言

之前幾篇文章內提到 IP 位址之後機會就會順便提到 MAC 位址，看起來似乎兩個是綁在一起的，其實兩者並沒有絕對的關係，我們從開放式系統互聯模型(Open System Interconnection Model，簡稱：OSI 模型)可以看出他們分別歸屬在第 3 層-網路層與第 2 層-資料連結層，OSI 模型對筆者來說是一種容易看懂但是很難理解的東西，因為它含括實體的硬體到抽象的資料結構，對筆者這種網路門外漢來說可能會越說越模糊，不過今天要提到路由器，就不得不跟交換器比較一下差異。

前言

在上一篇網路概論(二)我們討論到 IP 位址，其實 IP 的廣播位址不是很重要，會有特定位址(子網路遮罩下的最後一組 IP 位址)是因為在子網路遮罩規則下特意保留的，因為這個 IP 位址不能指派給電腦，所以我們可以安心使用這組 IP 位址，但是廣播(Broadcast)功能最終還是靠交換器。
而交換器地廣播方式就是將目的端 MAC 位址設為 FF:FF:FF:FF:FF:FF，但是其實只要目的端 MAC 位址不存在 MAC Address Table 內就可以觸發廣播，使用 FF:FF:FF:FF:FF:FF 也僅是因為這組 MAC 位址也是保留位址，不會網路設備被拿來使用，所以可以確保廣播功能可以正常觸發。

在網路開始興起的時代，MIS(Management Information System) 這個職務可以說是紅透半邊天(更不用說還有各種可以讓身價翻倍的證照)，因為利用網路來交換電子文件，所帶來的執行效率提升十分顯著，他不僅具備電話的即時性，同時也具備紙本文件的可記錄姓，在規模比較龐大的企業內，MIS 的權力說是隻手遮天也不為過，因為它的功能幾乎等同於公司的心臟。
接下來要說的東西筆者認為它們可以說是讓網路普及化的最大功臣，但是”成也風雲、敗也風雲”，它們也是讓不少公司的 MIS 淪落為廉價電腦維修工(有問題扛責任，沒問題沒價值)的主要原因。

前言

在上一篇網路概論(一)我們討論如何透過 MAC 位址來傳遞資料，這對於小型網路來說沒有太大的問題，但是對於擁有大量使用者的大型網路而言它是不足的，撇開硬體可行性限制，我們假設有一台超級交換器可以把全球的電腦都串接起來，而且它的 MAC Address Table 容量也足以記錄所有的 MAC 位址，使用上會發生什麼問題？只要有一台電腦變更連接埠(例如你帶電腦出差)，相關的資料傳遞在 MAC Address Table 更新前就會以廣播(Broadcast)的方式處理，全球每分鐘都多少裝置在移動，這台交換器絕大多數的時間是在做廣播，我想就算大家都是使用光纖串接也頻寬也不夠用，更不用說大家的電腦每分每秒都在收垃圾資料。

我們知道 MAC 位址是跟著電腦，如果位置(連接埠)不變情況下，交換器確實可以做到點對點的傳送，但是一旦變更，交換器就會不知道資料的派送方式，這種位址是依靠被動的方式來得知顯然有些弊端，因此我們需要一種位址讓網路傳遞設備可以主動知道它的實際地址(連接埠)，這樣就可以直接傳送，避免廣播佔用頻寬，所以我們今天來談論另一種位址-IP位址(Internet Protocol Address，簡稱：IP Address)。

前言

看到最近 FB 上再討論 CORS(Cross-Origin Resource Sharing，跨來源資源共用) 安全性問題，這時突然意識到，其實自己對網路好像不熟，不論是家裡要申請網路還是手機要上網，現在建置網路環境對大部分的人來說都不時太困難的事情，但是資料怎麼傳送？為什麼不會送錯地址？好像似懂非懂，裝防毒軟體跟架設防火牆網路就安全了嗎？這幾天就拜託 Google 大神來蒐集資料。

前言

在上一篇 化繁為簡：06 前端篇(一) 我們把前端的主要的前置作業準備好了，接下來就是直接時做一個產品的維護作業，大致規劃如下圖，這是一個很常見的維護功能，我們會有一個資訊清單列表負責呈現多筆資料，上面僅會顯示重要欄位資訊，另外還有一個維護頁面可以檢視與及編輯完整資訊。

前言

在上一篇 化繁為簡：05 後端篇(四)Controller 我們建立一個 DataController，只要繼承自它的 Controller 就會具有基本的 REST API，接下來我們開始建立前端程式並利用後端 Controller 所提供的 API 來維護資料。

前言

在上一篇 化繁為簡：04 後端篇(三)REST 我們最後建立一個 內含 REST 服務的 ProductsController，但是實務上，一般不會直接透過 GET 將清單資料一次全部下載，因為當資料筆數過大時有可能會被中斷，所以我們需要再提供分批下載的功能，此外對於基本資料的處理來說，一但扣除掉因資料特性而有所差異的商業邏輯，Controller 的程式碼幾乎雷同，所以這一篇我們就嘗試幫 Controller 減肥塑身。

前言

在上一篇 化繁為簡：03 後端篇(二)驗證 我們最後實作了登入驗證，這一篇我們開始談到資料交換，在 MVC(Model–view–controller) 架構下就是 Controller 了，因為筆者前端是採用 Angular 來實作，所以後端就會剩下 Web API，以資料交換為主。

談到 Controller 就很容易想到 商業邏輯層(BLL：Business Logic Layer)及資料存取層(DAL：Data Access Layer)，甚至有更多的切割方式，藉由責任區分來降低耦合度，這邊我們反其道而行，全部塞到 Controller 內處理，我們的重點就擺在如何讓 Controller 方便維護。

前言

在上一篇 化繁為簡：02 後端篇(一) 中，我們最後製作一個可以添加內容安全策略 (Content Security Policy) 的 Middleware，其實還有很多事情我們可以集中到 Middleware 處理，例如操作紀錄，我們在 Controllers 內僅能了解功能面的存取狀況，但是拉到 Middleware 來紀錄時，就可以了解至整個作業面的資料存取是否合理，如果發現異常就可以加入還名單並終止使用者權限(中斷他的請求)，而這些集中化的紀錄還可以拿來分析優化系統，說了這些，我們今天卻不是要實作它，重要的是要說明我們為了加速開發而在弱化整個系統架構時，其實後續事可以逐步強化回來，讓系統回覆該有的嚴謹度，在某種程度上與敏捷式開發有著同樣的目標。

雖著智慧手機的興起，大量的程式設計師透入 App 開發，以往系統間的資料交換首選幾乎都是以嚴謹聞名的 XML 格式，如今雖著 App 的迅速發展，有著輕量化的 JSON 資料格式已經幾乎取代了 XML 的地位，而隨著 JSON 的流行 JWT(JSON Web Tokens) 也變成很普及的身分驗證方式，今天我們就來弱化 JWT。

前言

在上一篇 化繁為簡：01 資料庫篇 中，我們制定一些資料庫的設計規範，雖然會違背了正規理念，但是就開發過程或是後續維護其實對於沒經驗或是寫 Code 不嚴謹的程式設計師(沒錯!說的就是筆者自己)來說會比較友善，接下來我們開始摧殘後端，因為筆者以自己比較常使用 ASP.NET Core 來當範例如何建構一個好 debug 的後端(Web API)，因為網路上已有豐富的資源，所以我們只做重點說明。