主機與伺服器建立連接用什麼協議

⑴ TCP協議解析

主要特點：面向連接、面向位元組流、全雙工通信、通信可靠。

優缺點：

應用場景：要求通信數據可靠時，即 數據要准確無誤地傳遞給對方。如：傳輸文件：HTTP、HTTPS、FTP等協議；傳輸郵件：POP、SMTP等協議

ps：首部的前 20 個位元組固定，後面有 4n 位元組根據需要增加。故 TCP首部最小長度 = 20位元組（最大60個位元組）。

TCP報頭中的源埠號和目的埠號同IP數據報中的源IP與目的IP唯一確定一條TCP連接。

重要欄位：

客戶端與伺服器來回共發送三個TCP報文段來建立運輸連接，三個TCP報文段分別為：
（1）客戶端A向伺服器B發送的TCP請求報段「SYN=1,seq=x」；
（2）伺服器B向客戶端A發送的TCP確認報文段「SYN=1,ACK=1,seq=y,ack=x+1」；
（3）客戶端A向伺服器B發送的TCP確認報文段「ACK=1,seq=x+1,ack=y+1」。

ps：在建立TCP連接之前，客戶端和伺服器都處於關閉狀態（CLOSED）,直到客戶端主動打開連接，伺服器才被動打開連接（處於監聽狀態 = LISTEN）,等待客戶端的請求。

TCP 協議是一個面向連接的、安全可靠的傳輸層協議，三次握手的機制是為了保證能建立一個安全可靠的連接。

通過上述三次握手， 雙方確認自己與對方的發送與接收是正常的，就建立起一條TCP連接，即可傳送應用層數據 。ps：因 TCP提供的是全雙工通信，故通信雙方的應用進程在任何時候都能發送數據；三次握手期間，任何1次未收到對面的回復，則都會重發。

為什麼兩次握手不行呢 ？

結論：防止伺服器接收了 早已經失效的連接請求報文 ，伺服器同意連接，從而一直等待客戶端請求， 最終導致形成死鎖、浪費資源 。

ps：SYN洪泛攻擊：（具體見下文）

為什麼不需要四次握手呢 ？

SYN 同步序列編號(Synchronize Sequence Numbers) 是 TCP/IP 建立連接時使用的握手信號。在客戶機和伺服器之間建立正常的 TCP 網路連接時，客戶機首先發出一個 SYN 消息，伺服器使用 SYN-ACK 應答表示接收到了這個消息，最後客戶機再以 ACK確認序號標志消息響應。這樣在客戶機和伺服器之間才能建立起可靠的 TCP 連接，數據才可以在客戶機和伺服器之間傳遞。

如何來解決半連接攻擊？

如何來解決全連接攻擊？

請注意 ，現在 TCP 連接還沒有釋放掉。必須經過 時間等待計時器 設置的時間 2MSL（MSL：最長報文段壽命）後，客戶端才能進入到 CLOSED 狀態，然後撤銷傳輸控制塊，結束這次 TCP 連接。當然如果伺服器一收到 客戶端的確認就進入 CLOSED 狀態，然後撤銷傳輸控制塊。所以在釋放連接時，伺服器結束 TCP 連接的時間要早於客戶端。

TCP是全雙工的連接，必須兩端同時關閉連接，連接才算真正關閉。 簡言之，客戶端發送了 FIN 連接釋放報文之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端發送還未傳送完畢的數據，傳送完畢之後，伺服器才會發送 FIN 連接釋放報文，對方確認後就完全關閉了TCP連接。

舉個例子：A 和 B 打電話，通話即將結束後，A 說「我沒啥要說的了」，B回答「我知道了」，但是 B 可能還會有要說的話，A 不能要求 B 跟著自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最後 B 說「我說完了」，A 回答「知道了」，這樣通話才算結束。

ps：設想這樣一個情景： 客戶端已主動與伺服器建立了 TCP 連接。但後來客戶端的主機突然發生故障。 顯然，伺服器以後就不能再收到客戶端發來的數據。因此，應當有措施使伺服器不要再白白等待下去。這就需要使用 TCP的保活計時器 。基本原理：

tcp11種狀態及變遷其實基本包含在正常的三次握手和四次揮手中，除開CLOSING。

正常的三次握手包括4中狀態變遷：

伺服器打開監聽(LISTEN)->客戶端先發起SYN主動連接標識->伺服器回復SYN及ACK確認->客戶端再確認即三次握手TCP連接成功。這里邊涉及四種狀態及變遷：

正常的四次握手包含6種tcp狀態變遷，如主動發起關閉方為客戶端：

客戶端發送FIN進入FIN_WAIT1 -> 伺服器發送ACK確認並進入CLOSE_WAIT(被動關閉)狀態->客戶端收到ACK確認後進入FIN_WAIT2狀態 -> 伺服器再發送FIN進入LAST_ACK狀態 -> 客戶端收到伺服器的FIN後發送ACK確認進入TIME_WAIT狀態 -> 伺服器收到ACK確認後進入CLOSED狀態斷開連接 -> 客戶端在等待2MSL的時間如果期間沒有收到伺服器的相關包，則進入CLOSED狀態斷開連接。

CLOSING狀態 ：連接斷開期間，一般是客戶端發送一個FIN，然後伺服器回復一個ACK，然後伺服器發送完數據後再回復一個FIN，當客戶端和伺服器同時接受到FIN時，客戶端和伺服器處於CLOSING狀態，也就是此時雙方都正在關閉同一個連接。

在進入CLOSING狀態後，只要收到了對方對自己發送的FIN的ACK，收到FIN的ACK確認就進入TIME_WAIT狀態，因此，如果RTT(Round Trip Time TCP包的往返延時)處在一個可接受的范圍內，發出的FIN會很快被ACK從而進入到TIME_WAIT狀態，CLOSING狀態持續的時間就特別短，因此很難看到這種狀態。

我們知道網路層，可以實現兩個主機之間的通信。但是這並不具體，因為，真正進行通信的實體是在主機中的進程，是一個主機中的一個進程與另外一個主機中的一個進程在交換數據。IP協議雖然能把數據報文送到目的主機， 但是並沒有交付給主機的具體應用進程 。而 端到端的通信才應該是應用進程之間的通信 。

應用場景 ：UDP協議比TCP協議的效率更高，TCP協議比UDP協議更加安全可靠。

下面主要對 數據傳輸出現錯誤/無應答/堵塞/超時/重復 等問題。

注意：TCP丟包：TCP是基於不可靠的網路實現可靠傳輸，肯定會存在丟包問題。如果在通信過程中，發現缺少數據或者丟包，那邊么 最大的可能性是程序發送過程或者接受過程中出現問題。

總結：為了滿足TCP協議不丟包，即保證可靠傳輸，規定如下：

注意：TCP丟包有三方面的原因，一是網路的傳輸質量不好，二是安全策略，三是伺服器性能瓶頸

先理解2個基礎概念：發送窗口、接收窗口

工作原理：

注意點：

關於滑動窗口的知識點：

滑動窗口中的數據類型：

ARQ解決的問題：出現差錯時，讓發送方重傳差錯數據：即 出錯重傳

類型：

流量控制和擁塞控制解決的問題：當接收方來不及接收收到的數據時，可通知發送方降低發送數據的效率：即 速度匹配

流量控制 ：

注意：

擁塞控制 ：

慢開始與擁塞避免 ：

快重傳和快恢復 ：

補充：流量控制和擁塞控制的區別

什麼情況造成TCP粘包和拆包？

解決TCP粘包和拆包的方法：

傳輸層無法保證數據的可靠傳輸 ，只能通過應用層來實現了。實現的方式可以參照tcp可靠性傳輸的方式，只是實現不在傳輸層，實現轉移到了應用層。

最簡單的方式是在應用層模仿傳輸層TCP的可靠性傳輸。 下面不考慮擁塞處理，可靠UDP的簡單設計。

https://www.jianshu.com/p/65605622234b
http://www.open-open.com/lib/view/open1517213611158.html
https://blog.csdn.net/dangzhangjing97/article/details/81008836
https://blog.csdn.net/qq_30108237/article/details/107057946
https://www.jianshu.com/p/6c73a4585eba

⑵ FTP協議是什麼

FTP協議其實是文件傳輸協議，是TCP協議組中的協議之一，值得一提的是FTP協議包含兩個部分，一個是FTP伺服器，另一個是FTP客戶端，我們在日常生活中使用的時候一定要學會區分才行，希望每個人都能夠認識到這一點，同時我們需要注意的是在日常生活中，電子信息行業發展是非常的迅速的，我們在日常生活中一定要學會使用電腦才行，只有這樣才可以讓我們的生活更加的美好。

個人建議：

同時我們需要注意的是，在學習電腦的過程中，一定要學會不恥下問，只有這樣才可以讓我們的能力有一個更加快速的提升，希望每個人都能夠認識到這一點，對於一些專業名詞來說，我們可以查閱相關的資料就可以解決了。

(2)主機與伺服器建立連接用什麼協議擴展閱讀：

FXP傳送出錯時，本地的用戶進程還留在FTP伺服器中，並沒有退出，如此時再次連接FTP伺服器，可能會因用戶線程超過允許，FTP伺服器提示客戶已登陸並拒絕客戶端的連接，直至伺服器中的傀儡進程因超時或其他原因被FTP伺服器殺死後，才能再次連接FTP伺服器。

要連上 FTP 伺服器（即「登陸」），必須要有該 FTP 伺服器授權的帳號，也就是說你只有在有了一個用戶標識和一個口令後才能登陸FTP伺服器，享受FTP伺服器提供的服務。

FTP協議的任務是從一台計算機將文件傳送到另一台計算機，它與這兩台計算機所處的位置、聯接的方式、甚至是是否使用相同的操作系統無關。假設兩台計算機通過ftp協議對話，並且能訪問Internet，

你可以用ftp命令來傳輸文件。每種操作系統使用上有某一些細微差別，但是每種協議基本的命令結構是相同的。

FTP的傳輸有兩種方式：ASCII傳輸模式和二進制數據傳輸模式。

⑶ SSL協議的工作原理是什麼

SSL協議的工作原理如下：

1）握手協議：這個協議負責被子用於客戶機和伺服器之間會話的加密參數。當一個SSL客戶機和伺服器次開始通信時，它們在一個協議版本上達成一致，選擇加密演算法和認證方式，並使用公鑰技術來生成共享密鑰。

2）記錄協議：這個協議用於交換應用數據。應用程序消息被分割成可管理的數據塊，還可以壓縮，並產生一個MAC（消息認證代碼），然後結果被加密並傳輸。接受方接受數據並對它解密，校驗MAC，解壓並重新組合，把結果提供給應用程序協議。

3）警告協議：這個協議用於每時示在什麼時候發生了錯誤或兩個主機之間的會話在什麼時候終止。SSL協議通信的握手步驟如下：