IP協議簇之TCP問題 探討（待更新）

OSI 七層模型

​

什麼是TCP ？

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議

什麼是面向連接？

面向連接不是指物理層面的電路的連接， 是指通信雙方在通信過程中保持某種狀態，直到通信結束。一條tcp連接的建立，對TCP協議本身而言，實質是意味著通信雙方序列號、錯誤校驗等機制的協商完成。而數據傳輸的途徑，如路由路徑的選擇則是ip層或者說網絡層的事情。 即在已經建立的TCP連接中，路由路徑可能會有變動，但是通信雙方的序列號、錯誤校驗等機制並不會變動，這就像在傳輸層層面確立了一條 “虛電路”，這就是面向連接。

為什麼TCP是可靠的？

1.TCP面向連接，確保通信過程中雙方狀態是可知且不變的，直到通信結束。

2. TCP 的報文有序號機制，確保報文可以按序排列並及時發現數據丟失等異常。

3.TCP 含有差錯校驗機制 ，發送端在發送時候計算校驗和，校驗和的計算覆蓋TCP首部和攜帶信息，在接收端進行檢驗，如果出現差錯，則將會丟棄這段TCP報文並要求重。

4.TCP 報文存在確認應答，發送的報文必須得到確認應答才視為正常達到接收方。

5. TCP 有超時重傳機制，當發送方在一定時間內未收到ACK確認應答，則會進行重傳。

什麼是面向字節流？

TCP面向字節流，在通信建立後，雙方都會建立緩衝區，對應為發送緩衝區和接收緩衝區，類似兩個蓄水池，水池中的水則對應為字節，數據的傳輸就向蓄水池之間水的流動。

（TCP/UDP 區別與比較？面向數據報是什麼？ 待寫 ）

TCP怎麼建立連接？

TCP 的連接過程俗稱三次握手。

第一次 ： 客戶端向服務端發送一個SYN包（同步序列編號，=x），

第二次： 服務端收到客戶端發來的SYN包後，也回應一個不同的SYN（=Y） 包，併發送一個ACK包（確認包，ack=x+1）

第三次： 客戶端收到服務端發來的SYN包，回應一個ACK（=Y+1）包 。之後就可以正式進行通信了。

​

為什麼建立連接要送三次握手？兩次不行嗎

首先，由於TCP連接是全雙工的，在連接時需要確認雙向通道是否都是可用。如果兩次握手就建立連接，很容易因為第二次握手時發送的回覆確認數據包沒有正確到達對方而造成雙方都在等待，形成死鎖。

其次，三次握手可以避免由於已經失效的連接請求報文突然又傳送到了服務器而造成的錯誤。

因為網絡的不確定性，我們假設當有一個TCP客戶端發出的連接請求沒有丟失，只是因為在網絡結點中滯留的時間過長，而由於TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，會重新向服務器發送這條報文，如果此後客戶端和服務器經過兩次握手完成連接，傳輸數據，然後關閉連接。而恰好之前滯留在網絡路由的那一次連接請求，此時剛剛到達服務器。這個報文本該是算作是失效的，但是，兩次握手的機制將會讓服務器打開連接，這將導致不必要的錯誤和資源的浪費。而採用三次握手的話，即使服務器收到了無效的數據包，並且發送一個連接請求給客戶端，但是客戶端並不進行理睬，服務器就會知道這次連接是無效的。

連接建立之後突然斷掉怎麼辦？

在TCP規範之外，大多數的TCP實現中都含有保活計時器選項，即keep Alive。和http協議的keepAlive不同，http協議的保活主要為了延長連接時間。而tcp的keepAlive主要為了探測連接是否異常，在連接空閒兩小時後，一方會主動發送一個探測分組來完成保活功。主要是為服務器應用程序提供的。

保活定時器默認設置是每隔兩小時發送一次報文，每次重發10次，每次75秒超時。

其他定時器？： https://blog.csdn.net/qq_33951180/article/details/60468267 TCP的定時器

TCP連接如何關閉？

TCP連接的關閉過程俗稱“四次揮手”

首先，客戶端進程發出釋放連接的FIN報文，表示我想關閉這個連接。

服務器收到後，會返回客戶端一個ACK報文，表示我知道了，不過我要先確保我這邊要傳給你的數據正常傳輸完。

等服務器所有數據傳輸完了，服務端則關閉這個連接，併發送一個FIN報文，表示 我這邊發送完了，連接我馬上就關。

客戶端收到後，會返回一個ACK 表示，ok 你的數據我全部接收到了，我也待會兒就關。

收到最後一個ACK後，服務端會關閉連接，而客戶端則要等待2MSL 時間後進行關閉。

​

為什麼要等待2MSL?

MSL 是Maximum Segment Lifetime 最大報文存活時間，2MSL 恰好意味著報文來回一趟的最大時間。

第一，為了保證主動關閉方的最後一個ACK報文能夠到達被動關閉方。這個ACK報文段有可能丟失，如果主動方發送完ACK報文段後就立即關閉連接，而最後一個ACK報文又未按時到達被動方，被動方就無法正常關閉。當設立等待2MSL 時間， 被動方如果沒收到最後的ACK報文，會超時重傳自己的上一個FIN+ACK報文段，而主動方就能在2MSL時間內收到這個重傳的FIN+ACK報文段，並也進行重傳最後的ACK報文並重新計時2MSL，這樣，被動方才能更可靠的正常關閉連接。 第二，A在發送完ACK報文段後，再經過2MSL時間，就可以使本連接持續的時間所產生的所有報文段都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求的報文段。

ACK是什麼？ACK的發送機制？

liuTCP協議中，接收方成功接收到數據後，會回覆一個ACK數據包，表示已經確認接收到ACK確認號前面的所有數據。

ACK字段長度為32位，能表示0~2^32-1之間的值。

需要注意的是ACK不是每接收一個包就會發送一個ACK。為了降低網絡流量的消耗，ACK有延遲確認和捎帶確認機制。

捎帶確認： 如果接收方有數據要發送，那麼就會在發送數據的TCP數據包裡，帶上ACK信息。這樣做，可以避免大量的ACK以一個單獨的TCP包發送，減少了網絡流量。

延遲確認 ：一般ACK延遲發送的時間為200ms，但這個200ms並非收到數據後需要延遲的時間。系統有一個固定的定時器每隔200ms會來檢查是否需要發送ACK包。如果200ms內沒有能夠捎帶ACK的數據包，則會將此200ms內的序號最大的ACK發送出去。表明在此序號前的數據包都已經收到。

TCP的數據流分為哪幾種？

分為

交互數據流：主要應用場景為交互性/實時性場景的數據流，特點是會產生很多小分組報文。例如使用Telnet、Rlogin遠程登錄，每敲擊一個鍵就會傳輸一個字符，這個過程會產生四次數據交互，假設我們在本地機器敲擊 q 鍵

1、客戶端產生一個41bit長的報文（20字節的IP首部，20字節的TCP首部，1字節的數據），發送到服務端；

2、服務端發送過來一個40bit的確認報文；

3、服務端發送回顯的字符，報文長為41bit；

4、客戶端發送確認報文，報文長為40bit。

可以看到這些小分組報文中TCP和IP頭部就佔了40字節，真正用於進程的有效數據報文長度非常小，這意味著大量的報文頭部將會佔用相當多的網絡資源。 如果在局域網中，通常不會有什麼麻煩，因為局域網一般不會出現擁塞，但在廣域網中，這些小分組則會增加網絡擁塞出現的可能。為了提高這類數據的發送效率和降低網絡負擔，TCP採用了兩種策略：捎帶ACK和Nagle算法。但要注意的是，Nagle不是必須的，可以禁用。

成塊數據流：對應交互數據流，相比而言對實時性要求不高，不需要發送大量小分組，可以將分組打包成塊發送的數據流。網絡上大部分的數據流都是成塊數據流。

什麼是Nagle算法？

Nagle算法的原則是在建立的TCP連接中，最多隻能有一個未收到ACK確認的小分組報文。 小分組，指的是小於建立連接時協商的MSS（最大報文段長度）尺寸的數據塊。 Nagle算法的規則（可參考tcp_output.c文件裡tcp_nagle_check函數註釋）：

（1）如果包長度達到MSS，則允許發送；

（2）如果該包為緊急數據或包含FIN（即關閉連接的字段），則允許發送；

（3）設置了TCP_NODELAY選項，則允許發送；

（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小於MSS）均被確認，則允許發送；

（5）上述條件都未滿足，但發生了超時（一般為200ms），則立即發送。

不滿足上述發送條件的小分組會和發送緩衝區中新來的分組打包在一起，直到滿足發送條件併發出。

注意： Nagle可以被禁用，只需設置TCP_NODELAY選項。 Nagle算法完全由TCP協議的ACK機制決定，這會帶來一些問題，比如如果對端ACK回覆很快的話，Nagle事實上不會拼接太多的數據包，雖然避免了網絡擁塞，網絡總體的利用率依然很低。但在網絡資源有限的情況下是十分有效減少網絡帶寬的佔用。 Nagle算法只允許一個未被ACK的包存在於網絡，它並不管包的大小，因此它事實上就是一個擴展的停-等協議，只不過它是基於包停-等的，而不是基於字節停-等的。

TCP的流量控制機制？

滑動窗口協議。TCP發送數據需要規定窗口大小，在起初的TCP實現中，窗口的大小是固定的，現在則是滑動窗口，即窗口大小會隨著網絡狀況而進行動態變化。

在發送端，我們將數據報文分為四類，1.已發送且被確認 2.已發送未被確認3.可發送但尚未發送4.不可發送

發送端的窗口內包含已發送但未被確認的數據和可發送但尚未發送的數據。窗口大小會隨著接收方返回的ACK包中的通告窗口字段的大小而變化。該值實質上表示的是接收方緩存區可用空間。當窗口內已發送數據被確認，窗口將會進行移動以確保窗口內的數據都是沒有被確認，並會調整窗口大小開始發送數據。當發送方收到的ACK中 窗口大小為0，則會停止發送。直到接收方返回窗口大小大於0的ACK包。

如果對方一直沒有返回ACK呢？TCP會有零窗口探測機制 零窗口探測定時器

為什麼要進行流量控制？

雙方在通信的時候，發送方的速率與接收方的速率是不一定相等，如果發送方的發送速率太快，會導致接收方處理不過來，這時候接收方只能把處理不過來的數據存在緩存區裡（失序的數據包也會被存放在緩衝區裡）。

如果緩衝區滿了發送方還在瘋狂著發送數據，接收方只能把收到的數據包丟掉，大量的丟包會極大著浪費網絡資源，因此，我們需要控制發送方的發送速率，讓接收方與發送方處於一種動態平衡才好。

對發送方發送速率的控制，我們稱之為流量控制。

什麼是緊急數據？

在許多傳輸層中有帶外數據

注意：UDP未實現此機制

TCP 中的擁塞控制機制？

擁塞機制是為了防止在時間段內向網絡發送太多數據包導致網絡路由或鏈路過載，導致阻塞、丟包等問題。

TCP的擁塞機制主要分為四個部分：慢開始 、 擁塞避免、快重傳 、 快恢復 。

1.慢開始 ： 在建立連接後，由於不清楚網絡的負載，如果一開始就發送大量數據包極易造成阻塞。更合適的做法是由小到大逐步試探可以發送的擁塞窗口cwnd的大小，每收到一個ACK，cwnd加一。.不同TCP版本的實現中慢開始的初始值還不同，這裡我們以 cwnd=1（ 1個最大報文短長度 MSS ） 開始。

第一輪： cwnd=1 發送一個數據 ， 收到一個ACK返回

第二輪 ： cwnd =1+1=2 發送兩個數據， 之後收到兩個ACK

第三輪 ：cwnd=2+2=4 發送四個數據，之後收到 四個ACK

第四輪 ：cwnd =4+4=8

..........

可以看出慢開始窗口增長速率是以 2**n 的指數級別進行增長， 慢開始的慢並不是指發送窗口增長速率慢，而是單單指初始值很小，很慢。

由於指數級別的增長實在太快，到最後幾乎無法避免阻塞。 因此，還需要設置一個閾值 ssthresh 來 防止窗口增長過快。並且僅當窗口小於此閾值的時候才允許以慢開始的方式進行發包。 當擁塞窗口大於此閾值時，TCP就會啟用另一種算法：擁塞避免

2. 擁塞避免：

擁塞避免並不是指完全避免擁塞，更像是指讓避免擁塞來得太快。其核心思想是讓擁塞窗口cwnd緩慢的增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1 。

經過慢開始和擁塞避免兩個算法，窗口還是在增大，只是增大速率變慢了，遲早還是會到達阻塞。

無論是在哪個階段發生了阻塞，ssthresh 都要變為擁塞前的一半，而窗口則又從1 開始，即又進行慢開始算法。

​

在發生阻塞時，接收方由於緩存溢出會產生丟包，會產生失序報文。 TCP的重傳定時器會在某個數據包在規定時間內未收到ACK而進行重傳，這導致確認阻塞的過程將比較耗時。為了解決這個問題，TCP又引入快速重傳和快速恢復機制。

3. 快速重傳

快速重傳規定接收方如果發現報文失序，需要立即連續發送三次重複確認，且無需等待捎帶和計時。

發送方一連收到三個重複確認後判定網絡可能發生阻塞，因為失序報文也可能是單純地在網絡路由中傳送太久，並未發生阻塞。

4 快速恢復

收到三個重複確認後，網絡只是可能阻塞，為了儘量不降低網絡傳輸效率，不應該立即從cwnd=1開始執行慢開始。快速恢復採用將ssthresh 和cwnd設為原先擁塞窗口的一半，並開始執行擁塞避免，這樣就實現了快速恢復的效果。

​

TCP的定時器 （待更新）

以下內容也待更新

什麼是UDP ？

UDP 是User Datagram Protocol的簡稱， 中文名是用戶數據報協議，是一種面向無連接的簡單不可靠的信息傳送服務。UDP報文沒有可靠性保證、順序保證和流量控制字段等，可靠性較差。但是正因為UDP協議的控制選項較少，在數據傳輸過程中延遲小、數據傳輸效率高。

UDP傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘可能快地把它扔到網絡上

TCP和UDP的區別 ？

TCP面向連接，可靠，基於字節流，而UDP不面向連接，不可靠，基於數據報。

TCP保證數據按序發送，按序到達。UDP只負責最大限度快速向網絡路由中發送數據包，不保證是否到達，如何到達。

TCP面向連接，所以只能一對一。UDP面向無連接，可以一對一，一對多

TCP有擁塞控制和流量控制，UDP沒有，UDP只會盡力去保證發送的速率。

在傳輸相同大小的數據時，TCP首部開銷20字節；UDP首部開銷8字節，

5. 什麼是http 協議？

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。

HTTP是一個基於TCP/IP通信協議來傳遞數據的屬於應用層的協議。

HTTP協議工作於客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

6.http協議有什麼特點？

1、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。

2、靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

3.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

5、支持B/S及C/S模式。

7.什麼是B/S 模式 什麼是C/S模式

C/S 架構是一種典型的兩層架構，其客戶端包含一個或多個在用戶的電腦上運行的程序，而服務器端有兩種，一種是數據庫服務器端，客戶端通過數據庫連接訪問服務器端的數據；另一種是Socket服務器端，服務器端的程序通過Socket與客戶端的程序通信。

它的主要特點是交互性強、具有安全的存取模式、網絡通信量低、響應速度快、利於處理大量數據。

BS（Browser/Server）：瀏覽器----服務器結構，是目前應用系統的發展方向。在這種結構下，通過瀏覽器來進入工作界面，主要事務邏輯在服務器端（Server）實現使得客戶端電腦負荷大大簡化，減輕了系統維護、升級的支出成本。

8. C/S 模式和B/S模式的特點與區別？

（1）C/S 用戶固定，一般只應用於局域網中，要求擁有相同的操作系統，如果對於不同操作系統還要相應開發不同的版本，並且對於計算機電腦配置要求也較高。

優點：------------

●能充分發揮客戶端PC的處理能力，很多工作可以在客戶端處理後再提交給服務器，所以CS客戶端響應速度快。

　　●操作界面漂亮、形式多樣，可以充分滿足客戶自身的個性化要求。

　　●C/S結構的管理信息系統具有較強的事務處理能力，能實現複雜的業務流程。

　　●安全性能可以很容易保證，C/S一般面向相對固定的用戶群，程序更加註重流程，它可以對權限進行多層次校驗，提供了更安全的存取模式，對信息安全的控制能力很強。一般高度機密的信息系統採用C/S結構適宜。

●需要專門的客戶端安裝程序，分佈功能弱，針對點多面廣且不具備網絡條件的用戶群體，不能夠實現快速部署安裝和配置。

缺點：--------------

　　●兼容性差，對於不同的開發工具，具有較大的侷限性。若採用不同工具，需要重新改寫程序。

　　●開發、維護成本較高，需要具有一定專業水準的技術人員才能完成，發生一次升級，則所有客戶端的程序都需要改變。。

　　●用戶群固定。由於程序需要安裝才可使用，因此不適合面向一些不可知的用戶，所以適用面窄，通常用於局域網中。

（2）B/S 要求有操作系統和瀏覽器就行，與操作系統平臺無關（可以實現跨平臺），對客戶端的計算機電腦配置要求較低。

優點：--------

●分佈性強，客戶端零維護。只要有網絡、瀏覽器，可以隨時隨地進行查詢、瀏覽等業務處理。

　　●業務擴展簡單方便，通過增加網頁即可增加服務器功能。

　　●維護簡單方便，只需要改變網頁，即可實現所有用戶的同步更新。

　　●開發簡單，共享性強。

缺點：

個性化特點明顯降低，無法實現具有個性化的功能要求。

　　●在跨瀏覽器上，BS架構不盡如人意。

　　●客戶端服務器端的交互是請求-響應模式，通常動態刷新頁面，響應速度明顯降低（Ajax可以一定程度上解決這個問題）。無法實現分頁顯示，給數據庫訪問造成較大的壓力。

　　●在速度和安全性上需要花費巨大的設計成本。

　　●功能弱化，難以實現傳統模式下的特殊功能要求。

9.HTTP請求的組成？

請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

10. htttp狀態碼？

1xx：指示信息--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操作

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現

5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態碼：

200 OK //客戶端請求成功

302 //重定向

400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用

403 Forbidden //服務器收到請求，但是拒絕提供服務

404 Not Found //請求資源不存在，eg：輸入了錯誤的URL

500 Internal Server Error //服務器發生不可預期的錯誤

503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

10. HTTP 請求方法？

GET 請求指定的頁面信息，並返回實體主體。

HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。

DELETE 請求服務器刪除指定的頁面。

CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。

OPTIONS 允許客戶端查看服務器的性能。

TRACE 回顯服務器收到的請求，主要用於測試或診斷。

11. GET POST區別？

首先，最直觀的區別就是GET把參數包含在URL中，POST通過request body傳遞參數。

因此，GET請求只能進行url編碼，而POST支持多種編碼方式。

GET請求參數會被完整保留在瀏覽器歷史記錄裡，而POST中的參數不會被保留。

GET請求在URL中傳送的參數是有長度限制的，而POST沒有。

對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

GET請求是明文，不安全

其次，GET和POST都是HTTP協議內的請求方法，本質上都是基於TCP/IP連接的數據包，因為HTTP的規定和服務器的限制，在應用中有不同的方向。

差距主要是GET只發送一次TCP包，而POST發送兩次

對於GET方式的請求，瀏覽器會把請求頭和請求數據一併發送出去，服務器響應200 OK（返回數據）；

而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送請求，服務器響應200 ok（返回數據）。

（在網絡狀況好的情況下，發一次包和兩次包，影響不大，但是在網絡狀況不好的時候，兩次包對於確保數據的完整性有著很大的優勢。）

（並不是所有瀏覽器發送POST請求時都會發送兩個TCP包，Firefox 只發送一次）

11. 什麼是HTTPS協議

HTTPS協議實在在HTTP協議的基礎上使用了SSL安全協議的數據傳輸協議。

12.HTTP和HTTPS的區別

HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭

HTTP 是不安全的，而 HTTPS 是安全的

HTTP 標準端口是80 ，而 HTTPS 的標準端口是443

在OSI 網絡模型中，HTTP工作於應用層，而HTTPS 的安全傳輸機制工作在傳輸層

HTTP 無法加密，而HTTPS 對傳輸的數據進行加密

HTTP無需證書，而HTTPS 需要CA機構wosign的頒發的SSL證書

13 在瀏覽器輸入網址回車後，發生了什麼

https://www.cnblogs.com/wupeixuan/p/8747918.html

首先，如果輸入的是網址不是IP地址，則需要先進行DNS解析。

瀏覽器先從自身的DNS緩存中尋找對應網址的緩存條目，找不到則在操作系統的緩存裡尋找，然後再去hosts文件中尋找。再沒找到的話，瀏覽器會將解析域名的請求發送給專門的DNS服務器，讓服務器幫忙解析，以此來得到網址對應的IP地址。

得到IP地址之後，開始建立TCP三次握手，建立連接，發送http請求，得到對應的html代碼。

得到html代碼後，瀏覽器進行解析並對html代碼中的資源進行請求，並對頁面進行渲染，最終呈現給用戶一個網頁界面。

14. icmp 協議

icmp 協議用來確定網絡是否可達，設計初衷是為ip減輕負擔。 即先幫ip判斷網絡是否正常連通，如果確定連通ip再開始

15. ftp等應用程序的工作流程

應用程序去調用DNS解析把域名轉成ip，然後要求tcp建立連接，tcp開始封包給ip，ip查路由表判斷直連非直連，然後判斷到底解析哪個ip地址，然後發送arp的二層廣播包，所有網絡裡的主機都會搜到這個包，只有一個主機發現自己的ip地址正好是對方要的，它就會回覆一個ARP的二層單播包給發送方，發送方現在有地址了，有映射了，可以發包了

閱讀更多 迂腐的老學究 的文章

關鍵字: 更新 協議 探討