1.什麼是長連線，什麼是短連線
2.在什麼情況下，遊戲使用長連線或是短連線
3.在使用短連線時，該採用何種網路資料的收發方式
4.在短連線時是否採用http協議
0.起因
前段時間，看到乙個開源的unity客戶端架構，在處理網路層時，該架構採用的方式如下：
var response = await session.call(request)
該方式採用了協程，傳送乙個請求協議，再等待乙個返回協議，這是一種典型的請求-響應的協議設計，類似的如http協議也是這類設計。但遊戲製作畢竟不是網頁響應，初看這段**的時候，對於這個設計框架的作者的思路，表示了懷疑。舉例說明，如果玩家登入遊戲到得到角色列表這一流程，按著這種請求響應的設計思路，該流程如下：
傳送乙個登入協議->收到登入協議的返回，如果結果無誤->傳送角色請求協議->收到角色請求協議的返回資料整個流程在網路層產生了四次資料傳輸。但其實就效能與效率而言，這不是乙個好的設計方案。在設計協議時，我們一般的方案如下：
傳送乙個登入協議，服務端收到登入協議，如結果有誤，向客戶端傳送返回協議，如果結果無誤，不返回結果協議，直拉向db請求資料庫，收到db的資料返回，向客戶端傳送角色資料。對於客戶端來說，他的協議如下：
成功時：傳送乙個登入協議->收到角色列表同步協議
失敗時：傳送乙個登入協議->收到登入協議的出錯協議
整個流程在客戶端與伺服器之間，只產生了兩次資料傳遞。除了減少了資料傳輸之個，這樣設計，還有乙個原因，請求角色這類的協議，直接暴露給客戶端，讓它運算元據庫，是伺服器安全性的乙個弊端。如果客戶端反**送這條協議，會引起不必要的麻煩。
回到網路上來，網路程式設計中，並不是所有協議都有返回協議的，很多廣播協議就並沒有返回協議，也不需要。協議並不是乙個響應，更底層來說，協議是一件事件。
用道具來說明這一流程，如果有兩個道具協議，乙個是刪除道具，乙個是使用道具，在設計協議時，在刪除道具和使用道具成功時，都可以不用傳送返回協議，而是由服務端，傳送乙個道具同步協議，只有在出錯時，傳送出錯提示協議。這樣設計的好處在於，道具的修改會被束在有限的乙個處理點上。
以上，是我當時的想法，但昨天，我對這個認知，產生了一些新的理解。
var response = await session.call(request)
是有必要存在的，但它並不適合所有方案。要深入討論，我們需要從長連線與短連線說起。
1.什麼是長連線，什麼是短連線?
我們說長短連線的時候，真正要說的是，是否需要tcp的三次握手，以及tcp的訊息安全機制。tcp是一種可靠的傳輸，在訊息的底層，它為我們確認了訊息是否有序，訊息是否到達對端，網路傳輸是乙個異常複雜的過程，即使先發a資訊，發再b資訊，但是在對端收到的時候，也有可能是b先於a到達，但因為有tcp，它驗證了順序，保證了上層協議的有序，在上層邏輯處理網路緩衝區時，先取出來一定是a，而不是b。但非tcp連線則不，因為沒有這些安全機制的檢查，所以非tcp連線在一定程式上要快過tcp連線。
2.在什麼情況下，遊戲使用長連線或是短連線
重度的手機遊戲，像rpg類的，moba類的遊戲，都採用的tcp連線。但消消樂這類的遊戲，顯然採用短連線更好一些，因為它並不是時刻與伺服器連線在一起的。
3.在使用長連線與短連線時，該採用何種網路資料的收發方式
既然我們要使用短連線，那麼該以何種方式，來確定這些資訊是傳送到了對端的呢。如果再在邏輯層加一組機制來判斷，那還不如直接使用tcp機制。答案其實很簡單，就是上面的await**，採用請求-響應的協議設計。
4.在短連線時是否採用http協議
我個人認為是不需要的。http是文字協議，對於遊戲來說，如果每次協議來回都要加上http的請求頭與返回頭是很消耗流量的。本來傳送乙個公升級協議，只需要不到4個byte，加上這些頭，來來回回就是50個byte。短連線與http協議不是1對1的關係。
不論使用那種應用層協議，自定義也好http也好。對於底層來說，總有乙個socket通道存在，tcp機制，決定了這個socket通道中的資料，是我們信任的，一定會到達對端的。如果出錯網路錯誤，該通道會被底層關閉，此時，上層邏輯也會收到socket被關閉的訊息。但是乙個非tcp機制，是沒有這樣的檢測條件的。舉例說明，我們刷網頁的時候，如果網路太慢，一直會轉圈，內容得不到顯示。我們鍵入位址回車時，雖然發出了請求指令，但其實上他有沒有到對端，我們是不知道的。只有當顯示出了文字，這個請求看上去被響應了，這個操作被認為是完成了。如果一直得到回應怎麼辦？過一段時間就會超時。
超時是短連線處理網路問題的乙個辦法。為什麼會超時？是因為使用的是請求響應這種協議設計，乙個請求，必須要有乙個響應，沒有響應資料到來，要麼資料可能丟掉了，要麼這個網路也許斷開了。
綜上，如果在遊戲製作過程中，使用非tcp機制的連線，在協議設計上一定要基於請求響應這種設計方案，可以更快檢查出當前網路的狀態。在這種情況下，是否採用http協議，卻並不是必須的。採用google protobuf依然還是首選。
長連線與短連線
通常短連線是這樣 連線 傳輸資料 關閉連線 那什麼是長連線？一般長連線相對短連線而言的，長連線在傳輸完數後不關閉連線，而不斷的傳送包保持連線等待處理下乙個資料報。such as 連線 傳輸資料 保持連線 傳輸資料 關閉連線。那什麼時候用短連線呢？一般長連線用於少數client end to serv...
長連線與短連線
短連線是指通訊雙方有資料互動時，就建立乙個tcp連線，資料傳送完成後，則斷開此tcp連線，一般銀行都使用短連線。比如http的，只是連線 請求 關閉，過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連線。其實長連線是相對於通常的短連線而說的，也就是長時間保持客戶端與服務端的連線狀態。通常的短連...
長連線與短連線
其實長連線是相對於通常的短連線而說的，也就是長時間保持客戶端與服務端的連線狀態。連線 資料傳輸 關閉連線 這就要求長連線在沒有資料通訊時，定時傳送資料報 心跳 以維持連線狀態，短連線在沒有資料傳輸時直接關閉就行了 長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多情況，每個tcp連線都需要三步握...