檢視緯育 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 的運作原理。
=== 檔案傳輸協定 (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]]
=== FTP 連線建立與初始互動 ===
* 三方交握 (Three-way Handshake)
** 任何 TCP 連線皆以三方交握起始，前三個封包固定為 SYN、SYN-ACK、ACK。
** 講師指出此流程為 TCP 固定模式，背誦意義不大。
** 封包分析工具常以 Relative Sequence Number（相對序列號）顯示並自 0 開始，便於觀察；實際 Sequence Number 很大，工具為易讀而正規化。
** 交握時雙方互相確認並將序列號加一；交握完成後，邏輯上雙方後續通訊皆自序列號 1 開始。
* 伺服器歡迎訊息
** 三方交握後，伺服器立即發送第四個封包：FTP 歡迎訊息，通常以 220 開頭。
** 該封包 TCP PUSH 旗標為 1，指示接收端應即時顯示內容。
** 220 並非指令，而是代表狀態的約定文字；FTP 客戶端（如 ftp.exe）看見 220 會直接印出。
** 某些客戶端（如微軟 ftp.exe）會在交握完成後自行顯示「已連線到...」，此文字不在封包中，為軟體內部訊息。
=== FTP 使用者認證過程 ===
* 客戶端指令傳輸
** 客戶端會依序送出認證相關指令。例如先送出 OPTS UTF8 ON 以嘗試啟用 UTF-8。
** 伺服器回應 202 UTF-8 is always enabled，表示已預設啟用。
** 之後送出 USER [username]，將使用者輸入帳號（如 PA）轉為指令格式。
** 這些指令封包通常同時帶有 PUSH 與 ACK 旗標，分別用於立即顯示與確認前一封包。
* 伺服器回應與密碼輸入
** 伺服器收到 USER 後回應 331 Password required for [username]，要求密碼；同樣以 PUSH 促使即時顯示。
** 客戶端接著發送 PASS [password]（如 123456）。
** 驗證成功後，伺服器回應 230 Logged on，表示登入成功；一般而言 200 系列多代表完成。
=== FTP 資料傳輸（主動模式 * PORT）===
* 資料傳輸前的準備（PORT 指令）
** 使用者下達需傳輸資料的操作（如 DIR 或 GET）時，客戶端不會立刻送出該操作指令。
** 會先對伺服器控制埠（Port 21）送出 PORT 指令以建立資料通道。
** PORT 參數包含客戶端 IP 與埠號，例如 PORT 192,168,86,201,133。
** 後兩數字（201, 133）用於計算資料埠：201 * 256 + 133 = 51589。
** 伺服器成功受理後回應 200 Command okay。
* 資料傳輸的執行（LIST / RETR 指令）
** 完成 PORT 後，客戶端才送出實際資料操作指令，如 LIST（對應 DIR）或 RETR（對應 GET）。
** 伺服器收到 LIST 或 RETR 後，會自其資料埠（Port 20）主動對客戶端指定的埠（如 51589）發起新的三方交握。
** 資料傳輸前，伺服器在控制連線（Port 21）上送出 150 Opening data channel。
** 資料連線建立後，伺服器透過該連線傳送目錄清單或檔案內容，即 FTP Data。
* 資料傳輸後的連線關閉
** 傳輸完成後，伺服器在資料連線上啟動四次揮手，先送出帶 FIN 的封包。
** 客戶端與伺服器互相確認後，該臨時資料連線（如 Port 51589）關閉。
** 同時，伺服器在控制連線（Port 21）上送出 226 Transfer complete，告知傳輸完成。
=== FTP 連線終止 ===
* QUIT 指令
** 使用者輸入 quit 時，客戶端向控制埠（Port 21）送出 QUIT 指令。
** QUIT 本身不會立即斷線。
* 連線關閉程序
** 伺服器收到後先回應 221 Goodbye。
** 之後雙方於控制連線進行標準 TCP 四次揮手，以 FIN 與 ACK 封包互相關閉，直至連線終止。
** 部分軟體在關閉後可能額外送出 RST（Reset）以確保徹底中斷，屬正常現象。
[[檔案:2026-0317-06.png|800px]]
=== TCP連線分析工具與方法 ===
* 分析工具介紹
** 課程使用預先準備好的Excel檔案記錄TCP連線的詳細資訊。
** 若學員電腦無Excel，可使用如CLC等軟體開啟，或直接參考講師提供的畫面。
** Excel表格將客戶端（Client）與伺服器（Server）的通訊分開記錄，便於追蹤。
* 表格欄位設計
** 表格針對Client與Server各自記錄三個關鍵值：
    1. Sequence Number（序號）: 記錄自身傳送的序號。
    2. Acknowledgment Number（確認號）: 記錄對方的序號已接收到哪裡。
    3. TCP Data大小: 記錄TCP封包中承載的資料長度。
** 表格還包含欄位記錄Client與Server各自的Port號、初始序號（Initial Sequence Number）以及TCP旗標（SYN、ACK、PSH等）。
=== TCP三向交握（Three-way Handshake）過程分析 ===
* 第一個封包 (Client -&gt; Server)
** 三向交握第一步，由Client發送。
** 旗標（Flag）為SYN，表格中標示為S1。
** Client來源Port為51588。
** 初始Sequence Number為一個特定值（例如：331...），但為了簡化計算可視為0。
** Acknowledgment Number為0，因為這是連線的發起方。
** TCP Data長度為0。
* 第二個封包 (Server -&gt; Client)
** 三向交握第二步，由Server回應。
** 旗標為SYN/ACK，表格中標示為S1, ACK。
** Server來源Port為21。
** Server的Sequence Number也從0開始（其自身初始序號例如226...，計算上視為0）。
** Acknowledgment Number為Client的序號加1，即1。
** TCP Data長度為0。
* 第三個封包 (Client -&gt; Server)
** 三向交握最後一步，由Client回應。
** 旗標為ACK。
** Sequence Number為1（自身上次序號0 + 資料長度0 + SYN旗標1）。
** Acknowledgment Number為1（確認Server的SYN）。
** TCP Data長度為0。
=== TCP資料傳輸過程分析 ===
* 序號與確認號的計算規則
** Sequence Number: 下一個封包的序號 = 上一個自身封包的序號 + 上一個封包的資料長度。
** Acknowledgment Number: 確認號 = 對方上一個封包的序號 + 對方上一個封包的資料長度。
** 講師示範如何參照表格中前一個封包的數值來計算下一個封包的序號與確認號。
* 實際封包分析範例
** 封包4 (Server -&gt; Client): Server傳送1143位元組資料。Seq=1，Ack=1。旗標為PSH/ACK。
** 封包5 (Client -&gt; Server): Client回應，Ack號為1144（1 + 1143）。Client自身也傳送14位元組資料，Seq號維持1。旗標為PSH/ACK。
** 封包6 (Server -&gt; Client): Server回應，Ack號為15（1 + 14）。Server自身傳送64位元組資料，Seq號為1144（1 + 1143）。旗標為PSH/ACK。
** 封包7 (Client -&gt; Server): Client發送純ACK封包，資料長度為0。Seq號為15（1 + 14），Ack號為1208（1144 + 64）。
** 後續封包: 以USER指令、PASS指令等FTP通訊為例，持續演示計算過程，並指出幾乎每個封包都帶有ACK旗標。
=== FTP連線中的多重TCP串流（Stream） ===
* 控制連線與資料連線
** FTP通訊包含控制連線（通常在Port 21）與資料連線（如Port 20）。
** 範例中，51588對21是一個TCP連線。
** 當執行LIST等指令時，會建立新的TCP連線，例如51589對20。
* 分析時的注意事項
** 在Wireshark等工具中，不同連線可能混合顯示。
** 手動分析時必須辨識不同連線（Stream），並為新的連線使用一張新的表格，獨立追蹤其序號與確認號。
** 若不分開處理，會導致計算到一半序號突然歸零的錯亂情況。
[[檔案:2026-0317-07.png|800px]]
== HTTP ==
本次講座系統介紹HTTP協定的歷史演進、報文結構、通訊流程與安全議題，並結合封包分析實作，對比FTP與不同HTTP版本（0.9、1.0、1.1、2、3）的差異與適用場景。內容涵蓋HTTP的請求/回應模式、狀態碼（1xx/2xx/3xx/4xx/5xx）、明文傳輸風險與HTTPS的由來；說明HTTP/1.1的持久連線（Keep-Alive）、快取、管線化，HTTP/2的多路複用與伺服器推送，HTTP/3在QUIC/UDP上的實作與行動環境優勢。<br><br>
以瀏覽器到Web伺服器的實際連線過程（DNS→TCP三方交握→HTTP GET/回應→四次揮手）為主軸，示範如何用Wireshark觀察與重建內容（含PNG匯出）、辨識favicon請求與404處理、理解標頭欄位（Host、User-Agent、Accept、Content-、Connection、DNT等）及其對解析與效能的影響。補充現代瀏覽器自動升級HTTPS、TLS 1.2/1.3握手差異、以及行動網路下基地台切換與IP變更時，QUIC透過連線ID維持會話以改善串流續播體驗。課程最後提供可實作的示範站點（如 taiwango.eu5.net、paiwan-go.eu-5.net）與練習時間，協助學員以封包觀察HTTP/HTTPS行為。
=== HTTP基本概念、歷史與內容型態 ===
* 初衷與演進：自CERN生態推動，強調開放與簡潔；由文字逐步擴展到圖片與影音。
* 靜態與動態內容：靜態檔由Web Server直接傳送；動態內容透過CGI/ASP/PHP等生成；API為常見HTTP應用。
* 協定特性：明文傳輸、無狀態、預設短連線（1.1引入Keep-Alive）。HTTP本身不內建帳密驗證，需由應用層機制實作；需完整性/安全建議用TCP+TLS形成HTTPS。
=== HTTP報文結構與瀏覽器解析 ===
* 請求/回應均由四部分組成：起始行（Request/Status Line）、Headers、空白行、Body。
* 請求行：方法（GET/POST/PUT/DELETE等）+ 路徑 + 版本（HTTP/1.1）。
* 回應行：版本 + 狀態碼（如200/301/404/500）+ 狀態文字。
* Body解析：依Content-Length判斷長度、依Content-Type與charset決定解析與呈現；二進位（如PNG）逐byte重組，文字依編碼解讀。
* 解析痛點：大小寫、空白、標點等格式差異造成相容性負擔；主流瀏覽器核心趨同，User-Agent歷史包袱導致「亂喊」現象影響統計與偵測。
=== 常見Header與用途 ===
* Host：指定目標虛擬主機，必備。
* Connection/Keep-Alive：維持連線以節省握手成本；伺服器可設定timeout/max。
* Accept/Accept-Encoding/Accept-Language：宣告可接受的媒體型別、壓縮（gzip/deflate）、語言偏好（zh-TW/zh）。
* User-Agent：宣告瀏覽器/系統資訊，受歷史相容性影響；資料分析需讀細節。
* Content-Length/Content-Type：標示內容長度與媒體型別（含charset）。
* Date、Server、Last-Modified、ETag：供快取與診斷；瀏覽器可用If-Modified-Since/If-None-Match協商。
* DNT：Do Not Track僅為請求，非強制。
=== 狀態碼與瀏覽器行為 ===
* 1xx資訊、2xx成功（200）、3xx重導（常見301/302升級至HTTPS）、4xx用戶端錯（404）、5xx伺服器錯（500）。
* 現代瀏覽器常預設嘗試以HTTPS連線；若需HTTP/80須明確輸入http://與:80；伺服器通常保留80以回應301/302轉址。
=== HTTP版本差異與效能機制 ===
* HTTP/0.9：僅GET。
* HTTP/1.0：整合早期實作，仍不足以統一。
* HTTP/1.1：方法擴充、Keep-Alive、快取、管線化；瀏覽器為並行載入會開多條TCP連線。
* HTTP/2：多路複用解決1.1串行瓶頸，允許單一連線同時請求多資源並非序回傳；以二進位編碼（含方法等）降低文字解析歧義；可選用伺服器推送主動傳必備資源，應用程式多無需修改，只要伺服器/瀏覽器支援即可受益。
* HTTP/3/QUIC（UDP）：在UDP之上以QUIC提供可靠傳輸、擁塞/順序控制與加密，降低握手延遲並緩解隊頭阻塞；特別適合高延遲、封包遺失、行動環境。
=== 行動環境與QUIC的會話延續 ===
* QUIC連線ID：伺服器分配ID保存會話，行動中基地台切換與IP變更時，客戶端攜帶原ID重連，伺服器識別同一會話並續播，改善高鐵等高速移動中的中斷重置問題。
* 實務採用：YouTube/多數串流採HTTP/3；大量圖片站（Facebook、Yahoo、IG等）多用HTTP/2；體驗例：影片半途關機換地點後重開仍可續播。
=== 連線流程、封包觀察與實作 ===
* 基本流程：DNS解析→TCP三方交握→HTTP請求/回應→連線關閉（四次揮手）。
* Wireshark觀察要點：
** 使用dns.qry.name與http過濾，定位目標主機與請求（如GET /、Host）。
** Follow TCP Stream重建單一連線往返；Export Packet Bytes匯出PNG等檔案。
** 觀察index.html解析後觸發後續GET（如/index.png）、ACK往返、favicon自動請求與可能的404。
** 非加密HTTP可直接讀內容；HTTPS在TCP後插入TLS握手（ClientHello/ServerHello/Certificate/Key Exchange），後續應用資料加密；TLS 1.3握手更精簡。
* 瀏覽器快取與測試：建議無痕模式避免快取干擾；明確使用http://以便觀察明文；多瀏覽器對比User-Agent、DNT、Accept-Language差異對回應的影響。
* 示範站點：taiwango.eu5.net、paiwan-go.eu-5.net（例：IP 185.176.43.98），頁面含index.html與單張圖片，便於封包拆解。
[[檔案:2026-0317-08.png|800px]]