一、前言

         以下是我自己的學習加理解，分享給大家，同時也算是自己做的筆記吧，俗話說好記性不如爛筆頭，希望來的你能有所幫助，有什麼理解不到位的地方，還請大神些多多指教。

二、網路模型

   OSI 七層模型：我們一般使用的網路資料傳輸由下而上共有七層，分別為物理層、資料鏈路層、網路層、傳輸層、會話層、表示層、應用層。

OSI網路七層模型

TCP/IP模型：TCP/IP 模型分為四層,由下而上分別為網路介面層、網路層、傳輸層、應用層。

TCP/IP網路模型

三、概念

   短連線：

   連線 -> 傳輸資料->關閉連線。就建立一次，但任務結束就中斷連線。 

  長連線：

    連線 -> 傳輸資料 -> 保持連線 -> 傳輸資料。。。-> 關閉連線。是指連線後不管是否使用都保持連線，但安全性較差。

  長連線、短連線用法：

         長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多的情況下。每個TCP連線都需要三步握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理 速度會降低很多，所以每個操作完後都不斷開，次處理時直接傳送資料包就OK了，不用建立TCP連線。例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成Socket錯誤，而且頻繁的Socket建立也是對資源的浪費。

        而像WEB網站的http服務一般都用短連結，因為長連線對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連線用短連線 會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。所以併發量大，但每個使用者無需頻繁操作情況下 需用短連好。

總之，長連線和短連線的選擇要視情況而定。

HTTP

http連線：

http協議即超文字傳送協議，是web聯網的基礎，也是手機聯網常用協議之一，http協議是建立在tcp協議之上的一種應用。

          http連線最顯著的特點是客戶端傳送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連線。從建立連線到關閉連線的過程稱為“一次連線”。

       1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連線，在處理完本次請求後，就自動釋放連線。

        2）在HTTP 1.1中則可以在一次連線中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。

       由於http在每次請求結束後都會主動釋放連線，因此http連線是“短連線”。要保持客戶端程式的線上狀態，需要不斷地向伺服器發起連線請求。通常的 做法是即時不需要獲得任何資料，客戶端也保持每隔一段固定的時間向伺服器傳送一次“保持連線”的請求，伺服器在收到該請求後對客戶端進行回覆，表明知道客 戶端“線上”。若伺服器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到伺服器的回覆，則認為網路已經斷開。

Socket

       套接字(socket)是通訊的基石，是支援TCP/IP協議的網路通訊的基本操作單元。

        應用層通過傳輸層進行資料通訊時，TCP會遇到同時為多個應用程式程序提供併發服務的問題。多個TCP連線或多個應用程式程序可能需要通過同一個 TCP協議埠傳輸資料。為了區別不同的應用程式程序和連線，許多計算機作業系統為應用程式與TCP／IP協議互動提供了套接字(Socket)介面。應用層可以和傳輸層通過Socket介面，區分來自不同應用程式程序或網路連線的通訊，實現資料傳輸的併發服務。

socket

建立socket連線

            建立 Socket 連線至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket，另一個運行於伺服器端，稱為ServerSocket。

            套接字之間的連線過程分為三個步驟：伺服器監聽，客戶端請求，連線確認。

             伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連線的狀態，實時監控網路狀態，等待客戶端的連線請求。

             客戶端請求：指客戶端的套接字提出連線請求，要連線的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連線的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連線請求。

             連線確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連線請求時，就響應客戶端套接字的請求，建立一個新的執行緒，把伺服器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式建立連線。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連線請求。

Socket連線與TCP連線

                建立Socket連線時，可以指定使用的傳輸層協議，Socket可以支援不同的傳輸層協議（TCP或UDP），當使用TCP協議進行連線時，該Socket連線就是一個TCP連線。

Socket連線與HTTP連線

                 由於通常情況下 Socket 連線就是TCP連線，因此 Socket 連線一旦建立，通訊雙方即可開始相互發送資料內容，直到雙方連線斷開。但在實際網路應用中，客戶端到伺服器之間的通訊往往需要穿越多箇中間節點，例如路由器、閘道器、防火牆等，大部分防火牆預設會關閉長時間處於非活躍狀態的連線而導致 Socket 連線斷連，因此需要通過輪詢告訴網路，該連線處於活躍狀態。

                 而HTTP連線使用的是“請求—響應”的方式，不僅在請求時需要先建立連線，而且需要客戶端向伺服器發出請求後，伺服器端才能回覆資料。

                 很多情況下，需要伺服器端主動向客戶端推送資料，保持客戶端與伺服器資料的實時與同步。此時若雙方建立的是Socket連線，伺服器就可以直接將資料傳送給 客戶端；若雙方建立的是HTTP連線，則伺服器需要等到客戶端傳送一次請求後才能將資料傳回給客戶端，因此，客戶端定時向伺服器端傳送連線請求，不僅可以保持線上，同時也是在“詢問”伺服器是否有新的資料，如果有就將資料傳給客戶端。

TCP與UDP的區別

          TCP：面向連線、傳輸可靠(保證資料正確性,保證資料順序)、用於傳輸大量資料(流模式)、速度慢，建立連線需要開銷較多(時間，系統資源)。

          UDP：面向非連線、傳輸不可靠、用於傳輸少量資料(資料包模式)、速度快。

TCP三次握手：指建立一個TCP連線時，需要客戶端和伺服器總共傳送3個包。

          第一次握手：客戶端傳送一個TCP的SYN標誌位置1的包指明客戶打算連線的伺服器的埠，以及初始序號X,儲存在包頭的序列號(Sequence Number)欄位裡。

          第二次握手：伺服器發回確認包(ACK)應答。即SYN標誌位和ACK標誌位均為1同時，將確認序號(Acknowledgement Number)設定為客戶的序列號加1以，即X+1。

           第三次握手：客戶端再次傳送確認包(ACK) SYN標誌位為0，ACK標誌位為1。並且把伺服器發來ACK的序號欄位+1，放在確定欄位中傳送給對方.並且在資料段放寫序列號的+1。

tcp三次握手

QQ、微信為什麼是UDP而不是TCP:

           像騰訊QQ之類的大規模即時通訊軟體，經常性的是幾千萬使用者同時線上 如果都採用長連線的方式。豈不是要伺服器的硬體防火牆監控數千萬個連線了，就算分散式服務端能承受這麼多使用者 閘道器也受不了，而且有理由相信伺服器也受不了 。所以對於大規模即時通訊，尤其是使用者數量眾多 肯定不能用TCP常連線的方式，這種方式只適合於小規模的即時通訊，如區域網，公司內部的即時通訊等 對於大規模的，使用者數量眾多的C/S軟體 應當採用UDP協議進行資料傳輸，閘道器就不停收發資料包就可以了。 

           使用TCP協議和客戶端進行短命連線，用了就關 比如客戶登陸請求好友列表，我們就和他建立TCP連線發給他好友列表，然後關掉連線 當用戶要給另外一個客戶發信心我們再建立連線，資料傳完我們又關掉連線 這種方式，無疑伺服器可以承載更多的使用者登陸。但是缺點也是非常明顯的 一般情況下我們接收的資料都不大，每次發一點點訊息都要建立連線 TCP本來就比較消耗網路資源，這樣毫無規律的斷斷連連 連連斷斷，加上本來這種方式就有較高的延遲 也不適合大規模的即時通訊

           事實上，在Internet上傳輸的UDP包從A傳送給B 它完整地到達機率一般情況下還是相當之高的。我們開發一個多使用者的即時通訊軟體 採用UDP傳輸訊息的時候，報文被劃分成包 一個UDP包究竟是多大？經過我的瞭解一個UDP使用者包最大大小是64KB 根據網路狀況，實際在傳輸包的時候可能把包劃成若干個分片 一個分片的最大大小是1640B 可以儲存好幾百個漢字。UDP協議提供資料報機制傳輸資訊 如果報文比較長，比如一個檔案，一個圖片 要被劃分成若干個資料包，由於對於一般的文字訊息和其它指令都是比較小的 它們會被放在一個包裡面，由於UDP是無連線的 不可靠的，如果發生丟包，不會重傳 所以不能保證資料包能完整並準確地到達目的地，但是對於我們的即時通訊軟體來說 一般的聊天資訊比較小，比如我們給一個好友傳送一條聊天資訊“今天我很高興”，會不會伺服器轉發的時候只收到“今天我很高”，再傳給好友的時候變成了“今天”，答案是不會發生這種情況的 UDP雖然描述是不可靠，不過依然在資料包中包含了頭資訊描述了包的大小等資訊，在包進行轉發的過程中 如果資料不完整，是會被網路裝置發現的，比如中途一個轉發這個包的路由器發現了一個不完整的UDP包會直接丟棄，如果是TCP 當有包被丟棄了會進行重傳，對於UDP 包在傳輸過程中由於資料的缺失被丟棄不會進行重傳 我們頂多就是一條資訊傳送失敗了，而這種概率一般情況下是非常低的 。

開發時到底選擇TCP還是UDP:

        如果是由客戶端間歇性的發起無狀態的查詢，並且偶爾發生延遲是可以容忍，那麼使用HTTP/HTTPS吧。

        如果客戶端和伺服器都可以獨立發包，但是偶爾發生延遲可以容忍（比如：線上的紙牌遊戲，許多MMO類的遊戲），那麼使用TCP長連線吧。

        如果客戶端和伺服器都可以獨立發包，而且無法忍受延遲（比如：大多數的多人動作類遊戲，一些MMO類遊戲），那麼使用UDP吧。

基本TCP客戶—伺服器程式設計基本框架

tcp

基本UDP客戶—伺服器程式設計基本框架流程圖

udp

總結

    其中知識還有很多，我只是寫出了我暫時的理解，班門弄斧，見笑。雙擊666，老鐵沒毛病，哈哈哈。

作者：Uncle鵬 連結：https://www.jianshu.com/p/092b700f601b 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。