Your SlideShare is downloading. ×
networking
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

networking

533

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
533
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 3: Transport Layer 3a- 第三章 : 傳輸層 章節目標: 了解傳輸層所提供的服 務之背後原理: 多工傳輸 / 分工傳輸 可靠的資料傳輸 流量控制 擁塞控制 在網際網路上舉例說明 以及實做 章節概要: 傳輸層的服務 多工傳輸 / 分工傳輸 無連接傳輸模式: UDP 可靠的資料傳輸原理 連接導向傳輸: TCP 可靠的資料傳輸 流量控制 連接管理 擁塞控制原理 TCP 擁塞控制
  • 2. 3: Transport Layer 3a- 傳輸服務及協定 提供在不同的主機上執行 的應用程序一種邏輯式的 通訊方式 傳輸層是在每個末端主機 上運行 傳輸層 vs 網路層服務: 網路層: 資料是在主機與 主機間做傳輸 傳輸層: 資料是在程序與 程序間作傳輸 必須依賴網路層服務 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physicalnetwork data link physical logicalend-end transport
  • 3. 3: Transport Layer 3a- 傳輸層通訊協定 網際網路傳輸服務: 可靠的 , 按照順序的單撥 (unicast) 傳輸 : TCP 擁塞 流量控制 連線設定 不可靠的 ( 最省力式 “ best -effort”), 不按照 順序的單撥或多撥 (multicast) 傳輸: UDP 不可用的服務: 即時服務 頻寬保證 可靠的多撥 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physicalnetwork data link physical logicalend-end transport
  • 4. 3: Transport Layer 3a- application transport network M P2 application transport network 多工傳輸 / 分工傳輸 回想: 資料段 – 在傳輸層 實體間作交換的資料單 元 aka TPDU: 傳輸層資 料單元 接收者 Ht Hn 分工傳輸: 傳送收到的資料段 到正確的應用層程序中 segment 資料段 M application transport network P1 M M M P3 P4 資料段 標頭 應用層資料
  • 5. 3: Transport Layer 3a- 多工傳輸 / 分工傳輸 多工傳輸 / 分工傳輸: 以傳送者、接收者的連接埠 號、 IP 位置為基準 每個資料段中,傳送者、接 收者的連接埠號 回想:特定的應用軟體具 有廣為了解的埠號 從不同的應用程序中收集資料 ,由標頭將資料包住 ( 之後將 用於分工傳輸 ) 來源端埠號 目的地端埠號 32 bits 應用程式 資料 ( 訊息 ) 其他標頭區域 TCP/UDP 資料段格式 多工傳輸:
  • 6. 3: Transport Layer 3a- 多工傳輸 / 分工傳輸:範例 主機 A 伺服器 B 來源埠 : x 目的地埠 : 23 來源埠 :23 目的地埠 : x 使用的埠 : 簡易遠端登入應用程式 網路客戶端主機 A 網路 伺服器 B 網路客戶端主機 C 來源 IP: C 目的地 IP: B 來源埠 : x 目的地埠 : 80 來源 IP: C 目的地 IP: B 來源埠 : y 目的地埠 : 80 使用的埠 : 網路伺服器 來源 IP: A 目的地 IP: B 來源埠 : x 目的地埠 : 80
  • 7. 3: Transport Layer 3a- UDP: 用戶資料訊息協定 [RFC 768] “no frills,” “bare bones” 網 路傳輸協定 “ 最省力式” 服務 , UDP 資料 段可能形式為: 易遺失的 傳送不按照順序排列的資 料段給應用程式 非連線導向式: UDP 傳送者與接收者之間 沒有互相交換控制訊息 每個 UDP 資料段自己獨 立地操作 為什麼會有 UDP ? 無需建立連線 ( 建立連 線可能會增加 delay) 簡單: 沒有連線狀態記 錄在傳送者與接收者上 資料段標頭欄很小 沒有擁塞控制: UDP 可以如同疾風般地快速 散撥資料段
  • 8. 3: Transport Layer 3a- UDP: 更多資訊 通常用於多媒體資料串流應 用程式上 能容忍資料段遺失 對速率相當敏感 其他 UDP 的使用 ( 為什麼要用 UDP?): DNS 網域名稱系統 SNMP 簡易網路管理協 定 在 UDP 上做可靠傳輸: 在應用層增加可靠度 特殊應用程式錯誤回復 ! 來源端埠號 目的地端埠號 32 bits 應用程式 資料 ( 訊息 ) UDP 資料段格式 長度 加總檢查 長度 , 在 UDP 資料段中是 以位元組計 算 , 包含 標頭欄
  • 9. 3: Transport Layer 3a- UDP 加總檢查 傳送者: 將資料段中的內容看成 連續的 16 位元整數 加總檢查:將資料段中 內容相加 (1’s complement sum) 傳送者將加總檢查值放 入 UDP 加總檢查欄中 接收者: 計算收到資料段的加總檢查 查看是否算出來的值跟加總檢 查欄中的值相同: NO – 偵測到錯誤 YES – 沒有偵測到錯誤 . 但是可能仍然有錯誤 ? 接 下來繼續討論 … . 目標:偵測傳送後的資料段中的”錯誤” (e.g., 錯誤位元 )
  • 10. 3: Transport Layer 3a- 可靠資料傳輸原理 在應用、傳輸、連結層具有很大的重要性 前十大重要的網路論題 ! 不可靠的頻道之特性 , 將會決定可靠資料傳輸協定 (rdt) 的複雜 度。
  • 11. 3: Transport Layer 3a- 可靠資料傳輸:開端 傳送端 接收端 rdt_send(): 由上層呼叫 , (e.g., 由應用層 ). 使資料通過並傳送到接收 端的上層 udt_send(): 由 rdt 呼叫 , 利用不可靠的頻道傳送封包給接 收端 rdt_rcv(): 當封包到達接收端的頻 道時被呼叫 deliver_data(): 由 rdt 呼叫來傳送資料給上層
  • 12. 3: Transport Layer 3a- 可靠資料傳輸:開端 我們將會: 漸增地開發傳送端與接收端的可靠資料傳輸協定 (rdt) 考慮只有單向的資料傳輸 但是控制資訊將會雙向傳送 ! 利用有限狀態機 (FSM) 來詳細說明傳送端與接收 端 狀態 1 狀態 2 造成狀態轉變的事件 狀態轉變時所要做的動作 狀態 : 當身處於這個 ” 狀態”時 , 接下來將進入 哪個狀態只能由下一 個發生事件來決定 事件 動作
  • 13. 3: Transport Layer 3a- Rdt1.0: 在可靠頻道上作可靠傳輸 底層的頻道絕對可靠 沒有位元錯誤 沒有封包遺失 分開討論傳送端與接收端的有限狀態機 : 傳送端將資料送入底層的頻道 接收端從底層的頻道讀取資料
  • 14. 3: Transport Layer 3a- Rdt2.0: 利用錯誤位元的頻道 底層的頻道可能會使封包中的位元發生錯誤 回想: UDP 加總檢查去偵測錯誤位元 問題 : 如何從錯誤中回復 : 認可 (ACKs): 接收端會明確地告訴傳送端封包已接收完成 否定認可 (NAKs): 接收端會明確地的告訴傳送端封包有錯誤 在接收到否定認可之後,傳送端會重新傳送封包 人類的劇本也是有認可跟否定認可嗎 ? rdt2.0 的新機制 (beyond rdt1.0): 錯誤偵測 接收端回饋 : 控制訊息 ( 認可 , 否定認可 ) 接放端 -> 傳送端
  • 15. 3: Transport Layer 3a- rdt2.0: 詳述有限狀態機 傳送端的有限狀態機 接收端的有限狀態機
  • 16. 3: Transport Layer 3a- rdt2.0: 運作中的情形 ( 沒有錯誤發 生 ) 傳送端的有限狀態機 接收端的有限狀態機
  • 17. 3: Transport Layer 3a- rdt2.0: 運作中的情形 ( 有錯誤發生 ) 傳送端的有限狀態機 接收端的有限狀態機
  • 18. 3: Transport Layer 3a- rdt2.0 有一個潛在的缺點 ! 假如 ACK/NAK 發生毀損 會發生什麼 ? 傳送端並不知道接收端發生 什麼情況 ! 不是僅僅重送 : 可能造成重 覆 What to do? 傳送端 認可 / 否定 接收端的 ACK/NAK? 如果傳送端的 ACK/NAK 遺失該怎麼辦 ? 重送 , 但是可能造成正確被 接收的封包再一次重送! 處理重複的封包: 傳送端加入 順序編號 到每 一個封包 假如 ACK/NAK 毀損,則傳 送端重傳現在的封包 接收端丟棄 (doesn’t deliver up) 重覆的封包 傳送端送出一個封包,然後 等待接收端的回應 停下並等待
  • 19. 3: Transport Layer 3a- rdt2.1: sender, handles garbled ACK/NAKs
  • 20. 3: Transport Layer 3a- rdt2.1: receiver, handles garbled ACK/NAKs
  • 21. 3: Transport Layer 3a- rdt2.1: 討論 傳送端 : 在封包中加入順序號碼 兩個順序號碼 (0,1) 足夠 嗎?為什麼 ? 必需確定是否收到的錯 誤的 ACK/NAK 狀態數目的兩倍 狀態必需”記住””現在”的順 序號碼是 0 還是 1 接收端 : 必需確定是否收到重覆 的封包 狀態會指示預期的順序號 碼是 0 或是 1 注意 : 接收端不知道它 上次發送的 ACK/NAK 是否成功的送達傳送端
  • 22. 3: Transport Layer 3a- rdt2.2: a NAK-free protocol 某些函式如 rdt2.1 只使 用 NAKs 接收端傳送 ACK 表示成 功收到最後一個封包, 而不用 接收端必需清楚的將表示 所回覆的封包順序號碼 傳送端收到重覆的 ACK 會做出和收到 NAK 相同 的反應 : 重送現在的封 包 sender FSM !
  • 23. 3: Transport Layer 3a- rdt3.0: 有錯誤和遺失的頻道 新的假設 : 基礎的頻道也 可能遺失封包 ( 資料或 是 ACKs) 加總比對方法 , 順序號 碼 , ACKs, 重新傳送,都 有幫助,但並不足夠 Q: 如何處理遺失 ? 傳送端等待,直到有些資 料或是 ACK 遺失再傳新 傳送 缺點 ? 方法 : send 傳送端等待 ACK ,持續一段”合理”的 時間 如果在這段時間內都沒有收到 ACK ,則開始重傳 如果封包 ( 或 ACK) 只是延遲 了 ( 不是遺失了 ): 重傳會造成重覆的封包,但 是利用順序號碼已經可以處 理這個問題 接受端必需註明 ACK 是在回 應哪個順序號碼的封包 需要有倒數計時器
  • 24. 3: Transport Layer 3a- rdt3.0 sender
  • 25. 3: Transport Layer 3a- rdt3.0 in action
  • 26. 3: Transport Layer 3a- rdt3.0 in action
  • 27. 3: Transport Layer 3a- Performance of rdt3.0 rdt3.0 可行,但效果不張 例子 : 頻寬 1 Gbps, 點對點傳輸延遲 15 ms, 封包大小 1KB: Ttransmit = 8kb/pkt 10**9 b/sec = 8 microsec 效能 = U = = 8 microsec 30.016 msec 傳送端真的在傳送 資料所佔的比例 = 0.00015 每微秒送30個1KB大小的封包msec -> 則在頻寬為1 Gbps 的連結上的吞吐量為33kB/秒 網路的通訊協訂限制了物理層的資源!
  • 28. 3: Transport Layer 3a- 加入管線觀念的協定 管線觀念 : send 傳送端允許多個”正在傳送中”但還末被 回覆 ACK 的封包 必需增加順序號碼的範圍 暫存在傳送端或是接收端 兩種使用管線觀念的協定 : go-Back-N, selective repeat
  • 29. 3: Transport Layer 3a- Go-Back-N 傳送端 : 在封包的標頭內包含了k個位元的順序號碼 “ 視窗” 內最多允許有連續 N 個尚末被回覆 ack 的封包 ACK(n): 回覆的 ACKs 所加註的順序號碼最多到 n - “ 累計的 ACK” 可能收到重覆的 ACKs ( 端看傳送端 ) 為那些正在傳送中的封包設置一個計時器 超時 (n): retransmit 重傳順序號碼為 n 的封包及視窗內所有順序號碼大於 n 的封包
  • 30. 3: Transport Layer 3a- GBN: sender extended FSM
  • 31. 3: Transport Layer 3a- GBN: receiver extended FSM 簡單的接收端 : ACK-only: 總是回覆現在依照順序成功收到的封包裡,順序號 碼最大的封包 可能產生重覆的 ACKs 只需要記住預期的順序號碼 失序的封包 : 丟棄 ( 不需要暫存 ) -> 不需要接收端去暫存 ! 只需要回覆有照順序中最大號碼的封包
  • 32. 3: Transport Layer 3a- GBN in action
  • 33. 3: Transport Layer 3a- Selective Repeat 接收端分別對所以正確接收的封包一一回覆 為了要能將封包照順序的傳送給上層,需要暫存封包 傳送端只要重送沒有收到回覆的封包 傳送端會幫每個還未收到 ACK 得封包計時 傳送端的視窗 N 個連續的順序號碼 再一次限制最多可以有多少沒有收到 ACK 的封包可以傳送
  • 34. 3: Transport Layer 3a- Selective repeat: sender, receiver windows
  • 35. 3: Transport Layer 3a- Selective repeat 來自上層的資料 如果有可用的順序號碼,則 將封包發送出去 超時 (n): 重新傳送封包 n, 並將計時器 重新啟動 ACK(n) in [sendbase,sendbase+N]: 標記封包 n 收到了 如果 n 小於最小一個還未收 到回覆的封包號碼,則將視 窗的下限值增加到下一個還 未覆的順序號碼 傳送端 封包的順序號碼落在 [rcvbase, rcvbase+N-1] send ACK(n) 失序的 : 暫存起來 照順序的 : 傳送 ( 暫存起來 中也有照順序的封包也傳送 出去 ), 調整視窗到下一個還 沒收到的封包 封包的順序號碼落在 [rcvbase- N,rcvbase-1] ACK(n) 其他 : 忽略 接收端
  • 36. 3: Transport Layer 3a- Selective repeat in action
  • 37. 3: Transport Layer 3a- Selective repeat: dilemma Example: seq #’s: 0, 1, 2, 3 window size=3 兩種情景下 接收端 感覺不出差異 ! in (a) 不正確地傳送 同一份資料做為新的 Q: seq # 和 window size 有什麼樣的關 係 ?
  • 38. 3: Transport Layer 3a- TCP: 概觀 RFCs: 793, 1122, 1323, 2018, 2581 全雙工資料 : 同一個連線的雙向資料流 MSS: 最大分節大小 ( 最 大 segment size) 連線導向 : handshaking ( 交換控制訊 息 ) 在資料交換前初始化 傳送端 , 接收端 獎態 流量控制 : 傳送端 不會把 接收端 的 緩衝區 灌滿 點對點 : 一個 傳送端 , 一個 接收端 可靠的,順序的 位元組 序列 : 無 “ message boundaries” pipelined: TCP 壅塞和流量控制決定 window size 送 & 收 緩衝區 s s o c k e t d o o r T C P s e n d b u f f e r T C P r e c e iv e b u f f e r s o c k e t d o o r s e g m e n t a p p lic a t io n w r it e s d a ta a p p lic a t io n r e a d s d a t a
  • 39. 3: Transport Layer 3a- TCP 節區架構 source port # dest port # 32 bits application 資料 (variable length) sequence number acknowledgement number rcvr window size ptr urgent 資料checksum FSRPAU head len not used Options (variable length) URG: urgent 資料 ( 一般來說不會用到 ) ACK: ACK # valid PSH: push 資料 now ( 一般來說不會用到 ) RST, SYN, FIN: 連線建立 ( 建立、解除命令 ) 接收端 想要收的 位元組 數量 以資料的 位元組 數計算 ( 不是節區 !) Internet checksum (as in UDP)
  • 40. 3: Transport Layer 3a- TCP seq. #’s and ACKs Seq. #’s: 節區資料裡首位元的 位元組流數目 ACKs: 另一邊預期的下一個 位元組的 seq # 累進的 ACK Q: 接收端 如何處理順序顛 到的節區呢 ? A: TCP 規格書未明 載–由實作者決定 主機 A 主機 B Seq=42, ACK=79, 資料 = ‘C’ Seq=79, ACK=43, 資料 = ‘C’ Seq=43, ACK=80 使用者輸入 ‘C’ 主機收到回應的 ACKs ‘C’ 主機收到 ACKs ‘C’, 回應 ‘ C’ 時間 簡易的 telnet 場景
  • 41. 3: Transport Layer 3a- TCP: 可靠的資料傳輸 精簡化 傳送端 , 假設 wait for event 等待事件 事件 : 應用程式接收資料 事件 : 計時器等待 segment with seq # y 逾時 事件 : 收到 ACK # y 的 ACK 建位,送出 segment 重送 segment ACK 處理 •單向資料傳送 •無流量和壅塞控制
  • 42. 3: Transport Layer 3a- TCP: 可靠的 資料 傳輸 00 傳送 base = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: 資料 接收 d from application above 06 create TCP segment with sequence number nextseqnum 07 start 時間 r for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length( 資料 ) 10 event: 時間 r 逾時 for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new 逾時 interval for segment y 13 restart 時間 r for sequence number y 14 event: ACK 接收 d, with ACK field value of y 15 if (y > 傳送 base) { /* 累進的 ACK of all 資料 up to y */ 16 cancel all 時間 rs for segments with sequence numbers < y 17 傳送 base = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs 接收 d for y 21 if (number of duplicate ACKS 接收 d for y == 3) { 22 /* TCP fast retransmit */ 23 re 傳送 segment with sequence number y 24 restart 時間 r for segment y 25 } 26 } /* end of loop forever */ 精簡化的 TCP 傳送端
  • 43. 3: Transport Layer 3a- TCP ACK 產生 [RFC 1122, RFC 2581] 事件 依序排列的 segment 來到 , 無 gaps, 其它的都已經 ACKed 依序排列的 segment 來到 , 無 gaps, 一個延遲的 ACK 未決 亂序的 segment 來到 , 比預期大的 seq. # 偵測到 gap 部分或完全充滿 gap 的 segment 來到 TCP 接收端動作 延遲 ACK. 等待下一個 segment 至多 500ms. 如果沒有下一個 segment,  送出  ACK 立即送出單一的累進 ACK 送出複製的 ACK, 表示下一個預期的位元組 的 seq. # 如果 segment 在 gap 較底端 開始,立即 ACK
  • 44. 3: Transport Layer 3a- TCP: 重傳 場景 s 主機 A Seq=92, 8 位元組 資料 ACK=100 loss 逾時 時間 遺失 ACK 場景 主機 B X Seq=92, 8 位元組 資料 ACK=100 主機 A Seq=100, 20 位元組 資料 ACK=100 Seq=92逾時時間 過早 逾時 , 累進的 ACKs 主機 B Seq=92, 8 位元組 資料 ACK=120 Seq=92, 8 位元組 資料 Seq=100逾時 ACK=120
  • 45. 3: Transport Layer 3a- TCP 流量控制 接收端 : 明確地通知   傳送端空的緩衝區 大小 ( 動態地改變 ) TCP segment 裡的 RcvWindow  欄 傳送端 : 保持傳送的總 數 , 未 ACK 的資料 少於最近接收的 RcvWindow 傳送端不會因為 傳送太多、太快而超過 接收端的緩衝區 流量控制 接收端緩衝區 RcvBuffer = 大小或 TCP 接收的緩衝區 RcvWindow = 空的緩衝區總數
  • 46. 3: Transport Layer 3a- TCP Round Trip 時間 and 逾時 Q: 如何設定 TCP 逾 時 值 ? 較 RTT 值大 注意 : RTT 會變 太短 : 過早逾時 不必要重傳 太長 : 對於 segment 遺 失反應較慢 Q: 如何估計 RTT? SampleRTT: 接受 ACK 之前從 segment 傳輸所測量到的時間 忽略重傳 , 累進地 ACK segments SampleRTT 會變 , 希望估計的 RTT “ 較平穩” 使用一些最近的測量值 , 而不只 是目前的 SampleRTT
  • 47. 3: Transport Layer 3a- TCP Round Trip Time 及逾時 EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT Exponential weighted moving average influence of given sample decreases exponentially fast 典型的 x 值 : 0.1 設定逾時時間 EstimtedRTT 加上 “ safety margin” EstimatedRTT 大的改變 -> 較大的 safety margin 逾時 = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
  • 48. 3: Transport Layer 3a- TCP 連線管理 Recall: TCP 傳送端 , 接收端 在交換資料 segments 前建 立 “連線” 初始化 TCP 變數 : seq. #s 緩衝區 , 流量控制資訊 (e.g. RcvWindow) 客戶端 : 連線初始者 Socket ClientSocket = new Socket(“hostname","port number"); 伺服器 : 由客戶端聯絡 Socket ConnectionSocket = welcomeSocket.accept(); Three way handshake: Step 1: 客戶端系統傳送 TCP SYN 控制 segment to 伺服器 指明起始的 seq # Step 2: 伺服端系統接收 SYN, 回應 SYNACK 控制 segment ACKs 接收 SYN 配置緩衝區 指明伺服器 -> 接收端起始的 seq. #
  • 49. 3: Transport Layer 3a- TCP 連線管理 (cont.) Closing a 連線 : 客戶端關閉連線 : ClientSocket.Close(); Step 1: 客戶端系統傳送 TCP FIN segment 到伺服器 Step 2: 伺服器 接收 FIN, 回應 ACK. 關閉連線 , 傳送 FIN. 客戶端 FIN 伺服器 ACK ACK FIN 關閉 關閉 關閉 時間等待
  • 50. 3: Transport Layer 3a- TCP 連線管理 (cont.) Step 3: 客戶端 , 接收 FIN, 回應 ACK. 進入 “時間等待” – 為接收 到的 FINs 回應 ACK Step 4: 伺服器 , 接收 ACK. 連線關閉 . Note: 稍做修改即可處理 同時產生的 FINs 客戶端 FIN 伺服器 ACK ACK FIN 關閉 關閉 關閉 時間等待 關閉
  • 51. 3: Transport Layer 3a- TCP 連線管理 (cont) TCP 客戶端 生命週期 TCP 伺服器 生命週期
  • 52. 3: Transport Layer 3a- Principles of 壅塞 控制 壅塞 : 非正式說法 : “ 太多來源端傳送太多資料或太快以致  於網路無法處理” 不同於流量控制 ! 表現形式 : 遺失封包 ( 路由器的緩衝區滿溢 ) 有長 delays ( 在路由器緩衝區的 queuing) 一個前十名的問題 !
  • 53. 3: Transport Layer 3a- Causes/costs of 壅塞 : 場景 1 兩個傳送端 , 兩個 接收端 一個路由器 , 無限 緩衝區 無重傳 當壅塞時有大 delay 最大可達的產量 ( throughput )
  • 54. 3: Transport Layer 3a- 壅塞的起因 / 花費 : 場景 2 一個路由器 , 有限的緩衝區 傳送端重傳遺失的封包
  • 55. 3: Transport Layer 3a- Chapter 3: Summary 在傳輸層服務背後的原則 : 多工 / 解多工 可靠的資料傳輸 流量控制 擁塞控制 在 Internet 上的例子與實作 UDP TCP 下一步 : 離開網路的 “邊緣” ( 應用 傳輸層 ) 進入網路的 “核心”

×