檢視緯育 2026-0315 的原始碼

== FTP ==
本次講座深入探討了檔案傳輸協定 (FTP) 的運作機制及其與傳輸控制協定 (TCP) 的緊密關聯。內容從電腦作業系統圖形化介面 (UI) 的發展歷史開始，回顧了從施樂 PARC、蘋果到微軟的演進。接著，講座詳細解釋了 FTP 的基本概念、雙埠（命令埠 21 與資料埠 20）架構，以及其兩種核心傳輸模式：主動模式 (Active Mode) 和被動模式 (Passive Mode)。講師通過生動的例子，闡述了這兩種模式在資料傳輸順序上的根本差異，並深入探討了防火牆如何因其「由內而外放行，由外而內阻擋」的原則，影響這兩種模式的運作，這也是為何啟用被動模式常能解決連線問題。<br><br>
此外，講座深入剖析了 TCP 的核心機制，包括建立連線的「三次交握」(SYN, SYN-ACK, ACK) 與終止連線的「四次揮手」(FIN)，並探討了防火牆在不同階段阻擋封包可能產生的不同效果。講師詳細介紹了 TCP 標頭 (Header) 的重要欄位，如來源埠、目的埠、序列號 (Sequence Number)、確認號 (Acknowledgement Number)，以及六個關鍵控制旗標 (URG, ACK, PSH, RST, SYN, FIN) 的功能，強調 TCP 如何透過這些機制確保資料傳輸的可靠性與完整性。講座也解釋了 FTP 的操作指令（如 GET, PUT, CD）與伺服器回覆碼（Reply Code）的意義，將 100 到 500 系列的代碼與網頁瀏覽的 HTTP 狀態碼類比，幫助學員理解。最終目標是讓學員透過實際的封包分析練習，深入理解 FTP 與 TCP 的運作原理。
=== 作業系統圖形化介面的歷史 ===
* UI 的起源與發展
** 圖形化使用者介面 (UI/GUI) 最早由施樂公司 (Xerox PARC) 開發，實現了「所見即所得」。
** 賈伯斯 (Steve Jobs) 在參觀施樂後受到啟發，將 UI 和滑鼠應用於蘋果電腦。
** 早期微軟是一家為其他公司設計 UI 的軟體公司，在看過蘋果的 UI 後，推出了 Windows 系統，引發了「施樂告蘋果，蘋果告微軟」的抄襲爭議鏈。
* 早期電腦操作方式
** 在 UI 普及之前，包括早期的蘋果電腦在內，大部分電腦都是透過輸入指令 (Command-line) 來操作。
=== 檔案傳輸協定 (FTP) 詳解 ===
* FTP 基本概念與學習目標
** FTP (File Transfer Protocol) 是一個古老、開放且簡易的檔案傳輸協定，作為理解 TCP 應用的實例。
** 透過學習 FTP，可以理解為何 TCP 能可靠地傳輸完整資料。
* FTP 協定架構與雙埠機制
** FTP 由客戶端 (Client) 和伺服器 (Server) 組成，必須有伺服器才能提供服務。
** 使用兩個獨立的埠 (Port) 進行通訊：
** 命令埠 (Command Port 21)：用於傳輸指令，如使用者登入 (USER, PASS)、切換目錄 (CD)、請求檔案 (GET) 等。
** 資料埠 (Data Port 20)：用於傳輸實際的資料，包括檔案內容以及目錄列表本身。
* FTP 連線模式
** 主動模式 (Active Mode)：
    1. 客戶端與伺服器的 Port 21 建立命令連線。
    2. 客戶端透過 PORT 指令告知伺服器自己用於接收資料的埠號。
    3. 伺服器從自己的資料埠 (Port 20) 主動連線到客戶端指定的埠號以傳輸資料。
** 被動模式 (Passive Mode, PASV)：
    1. 客戶端與伺服器的 Port 21 建立命令連線。
    2. 客戶端發送 PASV 指令給伺服器。
    3. 伺服器回覆一個自己動態開啟的資料埠號。
    4. 客戶端再從自己的資料埠主動連線到伺服器指定的埠號以取得資料。
* 防火牆對 FTP 模式的影響
** 防火牆基本原則：通常允許所有由內向外的連線，但阻擋所有從外部主動發起的連線。
** 主動模式的衝突：在主動模式下，伺服器（外部）需主動連線到客戶端（內部），此連線會被客戶端側的防火牆阻擋，導致使用者能登入但無法接收檔案或目錄列表（畫面卡住）。
** 被動模式的解決方案：在被動模式下，所有連線（命令和資料）均由客戶端發起，符合防火牆「由內向外」的放行規則，因此能成功傳輸資料。這也是為何 FTP 軟體中啟用「被動模式」通常能解決連線問題。
* FTP 操作指令與回覆碼
** 操作方式：可透過 Telnet 發送原始指令 (如 CWD, RETR)，但更實用的是使用作業系統內建的輔助工具 (ftp.exe)，其標準指令 (如 CD, GET) 在 Windows, Linux, Mac 等平台通用。
** 回覆碼 (Reply Code)：伺服器使用三位數代碼回應客戶端請求，概念與 HTTP 狀態碼相似。
** 100 系列：處理中 (如 150 File status okay; about to open data connection.)
** 200 系列：成功 (如 220 Service ready for new user. 或 230 User logged in, proceed.)
** 300 系列：需要更多資訊 (如 331 User name okay, need password.)
** 400 系列：客戶端錯誤 (如密碼錯誤或 404 Not Found，代表請求的資源不存在)。
** 500 系列：伺服器端錯誤 (表示伺服器內部發生問題，客戶端刷新無效)。
=== 傳輸控制協定 (TCP) 詳解 ===
* TCP 與 FTP 的關係
** FTP 是基於 TCP 的應用層協定，因此其連線過程完全遵循 TCP 的規範。
* TCP 連線建立：三方交握 (Three-way Handshake)
  1. SYN：客戶端發送一個 SYN 封包給伺服器，請求建立連線。
  2. SYN-ACK：伺服器回覆一個 SYN-ACK 封包，表示同意連線並確認收到請求。
  3. ACK：客戶端再發送一個 ACK 封包，確認收到伺服器的回應。連線至此建立，雙方可開始傳輸資料。
* TCP 連線終止：四方揮手 (Four-way Handshake)
** 使用 FIN 旗標來正常地終止 TCP 連線。雙方各發送一個 FIN 並由對方 ACK 確認，共需四個步驟。
** 若無法正常終止，最終可能發送 RST 封包強制中斷。
* TCP 標頭 (Header) 與控制旗標 (Flags)
** 主要欄位：
** Source/Destination Port：來源與目的埠號。
** Sequence Number (SEQ)：標示該封包資料的起始位元組編號，用於排序。
** Acknowledgement Number (ACK Number)：告知對方期望收到的下一個位元組的編號，用於確認。
** Window Size：接收緩衝區的大小，用於流量控制。
** 六大控制旗標：
** SYN (Synchronize)：用於發起連線請求。
** ACK (Acknowledgement)：表示確認號欄位有效，用於確認收到封包。
** FIN (Finish)：表示資料傳輸完畢，請求終止連線。
** RST (Reset)：強制中斷或拒絕連線。
** PSH (Push)：告知接收方將緩衝區中的資料立即提交給應用程式處理。
** URG (Urgent)：表示封包中包含需優先處理的緊急資料（罕用）。
* TCP 的特性：可靠傳輸
** 優點：透過序號、確認號與重送機制，確保資料能完整、按順序地送達。適用於網頁瀏覽、檔案傳輸等不容許資料遺失的場景。
** 缺點：交握、揮手及確認過程使其效率較 UDP 慢，且標頭較大 (20 bytes vs UDP 8 bytes)，不適用於直播、網路電話等強調即時性的應用。
[[檔案:2026-0317-05.png|800px]]