各個游戲接入都存在一定的掉線問題，而且有的游戲項目的掉線比例還比較高，現在互娛自研游戲的網絡接入基本上都用的是tconnd和ProtocalHandler組件（該組件請參考附件的《TSF4G_ProtocalHandler開發指導手冊》），因此參與其掉線原因分析和研究。

在參與A項目的掉線問題研究分析過程中，tconnd增加了玩家每個連接的流水日志和ProtocalHandler增加了每個連接的Qos上報日志，通過這些日志記錄了每一次連接的斷開原因和相關統計數據，其中包括了連接異常斷開時TCP的底層錯誤碼。

通過對tconnd的流水日志和ProtocalHandler的Qos日志進行統計分析，發現連接異常斷開時TCP的錯誤碼大部分是“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下），單純從錯誤碼本來來說，大家都明白是“網絡被對端重置了”，但究竟什么情況下會導致這種情況呢？因此就對TCP的各種關閉情況做了進一步的測試研究。

一. TCP異常關閉的研究測試

1. 服務器端只Recv消息而不Send消息

1.1 測試方法

服務器程序在接受客戶端的TCP連接后Sleep幾秒鐘，客戶端程序在TCP連接后立即發送很多消息給對端后做相應動作（退出或等待），服務器程序Sleep完后開始Recv消息。

注意：服務器程序測試了Linux和Windows版本，但客戶端只測試了Windows版本，如果是Linux客戶端則有些Case的結果會不一樣。

1.2 測試Case

• 客戶端程序正常運行的情況下，拔掉網線，殺掉客戶端程序
  目的：模擬客戶端死機、系統突然重啟、網線松動或網絡不通等情況。
  結論：這種情況下服務器程序沒有檢測到任何異常，并最后等待“超時”才斷開TCP連接。

• 客戶端程序發送很多數據包后正常關閉Socket并exit進程(或不退出進程)
  目的：模擬客戶端發送完消息后正常退出的情況。
  結論：這種情況下服務器程序能夠成功接收完所有消息，并最后收到“對端關閉”（Recv返回零）消息。

• 客戶端程序發送很多數據包后不關閉Socket直接exit進程
  目的：模擬客戶端程序退出而忘記關閉Socket的情況（比如通過Windows窗口的關閉圖標退出進程，而沒有捕獲相應關閉事件做正常退出處理等）。
  結論：這種情況下服務器程序能夠收到部分TCP消息，然后收到“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）錯誤。

• 客戶端程序發送很多數據包的過程中直接Kill進程
  目的：模擬客戶端程序崩潰或非正常方式結束進程（比如Linux下"kill -9"或Windows的任務管理器殺死進程）的情況。
  結論：這種情況下服務器程序很快收到“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）錯誤。

2.服務器端Recv消息并Send應答消息

2.1 測試方法

服務器程序在接受客戶端的TCP連接后Sleep幾秒鐘，客戶端程序在TCP連接后立即發送很多消息給對端后做相應動作（退出或等待），服務器程序Sleep完后開始Recv和Send消息。

注意：服務器程序測試了Linux和Windows版本，但客戶端只測試了Windows版本，如果是Linux客戶端則有些Case的結果可能會不一樣。

2.2 測試結果

• 客戶端程序發送很多數據包后正常關閉Socket并exit進程（或不退出進程）
  目的：模擬客戶端正常關閉Socket后，服務器端在檢查到TCP對端關閉前向客戶端發送消息的情況。
  結論：這種情況下服務器程序接收和發送部分TCP消息后，在Send消息時產生“32: Broken pipe”（Linux下）或“10053: An established connection was aborted by the software in your host machine”（Windows下）錯誤。

• 客戶端程序發送很多數據包后不關閉Socket直接exit或Kill進程
  目的：模擬客戶端程序退出而忘記關閉Socket、或客戶端程序崩潰或非正常方式結束進程的情況。
  結論：這種情況下服務器程序在Recv或Send消息時產生“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）錯誤。

3. 效果和總結

3.1 總結

TCP發現網絡異常（特別是Linux下的104錯誤或Windows下10054錯誤）的情況很多，比如網絡本身的問題、中間路由器問題、網卡驅動器問題等不可抗拒因素，但下面是應用程序本身可能會導致的問題，也是我們需要進一步研究和解決的情況，特別是程序崩潰導致問題：

• 當TCP連接的進程在忘記關閉Socket而退出、程序崩潰、或非正常方式結束進程的情況下
  （Windows客戶端），會導致TCP連接的對端進程產生“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）錯誤。

• 當TCP連接的進程機器發生死機、系統突然重啟、網線松動或網絡不通等情況下
  -（Windows客戶端），連接的對端進程可能檢測不到任何異常，并最后等待“超時”才斷開TCP連接。

• 當TCP連接的進程正常關閉Socket時，對端進程在檢查到TCP關閉事件之前仍然向TCP發送消息
  （Windows客戶端），則在Send消息時會產生“32: Broken pipe”（Linux下）或“10053: An established connection was aborted by the software in your host machine”（Windows下）錯誤。

3.2 效果

針對A項目的掉線問題，通過問卷調查和聯系個別玩家等方法，發現掉線的情況很大部分是客戶端程序直接退出了，因此推動項目組實現了客戶端的Qos上報功能，最后通過客戶端的Qos上報的統計數據得出客戶端程序的崩潰比例比較高，占了總掉線的很大比率，當然其它情況也存在，但比例相對比較小。

因此，A項目首先應該解決客戶端程序的崩潰問題，如果該問題解決了，也就解決大部分掉線問題。

二. TCP異常關閉的進一步研究測試

1. 背景

B項目游戲在跨服跳轉時的掉線比例比較高，經過分析ProtocalHandler和tconnd的日志，發現掉線出現的情況是：tconnd發送了跨服跳轉消息后立即關閉了Socket，客戶端進程在接收到跨服跳轉消息之前發送消息后收到Windows 10054錯誤，然后做斷線重連失敗。

B項目實現跨服跳轉的流程是GameSvr給客戶端程序下發的跨服跳轉命令的同時攜帶了Stop請求，也就是說tconnd在向客戶端轉發跨服跳轉消息后立即就會關閉當前的Socket連接，而且B項目的客戶端程序會定期不斷地向服務器上報消息。這又怎么會導致客戶端程序收到10054錯誤而呢？鑒于此，對TCP的連接做進一步的場景測試分析。

2. TCP異常進一步測試研究

2.1 測試方法

客戶端和服務器端程序建立TCP連接，服務器程序在TCP緩沖區中有消息或沒有消息的情況下關閉Socket，客戶端在對端Socket已經關閉的情況下繼續Send和Recv消息。

注意：服務器端只測試了Linux版本，但客戶端測試了Windows和Linux兩個版本。

2.2 測試結果

• 服務器端已經close了Socket，客戶端再發送數據
  目的：測試在TCP對端進程已經關閉Socket時，本端進程還未檢測到連接關閉的情況下繼續向對端發送消息。
  結論：第一包可以發送成功，但第二包發送失敗，錯誤碼為“10053: An established connection was aborted by the software in your host machine”（Windows下）或“32: Broken pipe，同時收到SIGPIPE信號”（Linux下）錯誤。

• 服務器端發送數據到TCP后close了Socket，客戶端再發送一包數據，然后接收消息
  目的：測試在TCP對端進程發送數據后關閉Socket，本端進程還未檢測到連接關閉的情況下發送一包消息，接著接收消息。
  結論：客戶端能夠成功發送第一包數據（這會導致服務器端發送一個RST包 <已抓包驗證>），客戶端再去Recv時，對于Windows和Linux程序有如下不同的表現：
  Windows客戶端程序：Recv失敗，錯誤碼為“10053: An established connection was aborted by the software in your host machine”。
  Linux客戶端程序：能正常接收完所有消息包，最后收到正常的對端關閉消息（這一點與Window下不一樣，RST包沒有被提前接收到）。

• 服務器端在TCP的接收緩沖區中還有未接收數據的情況下close了Socket，客戶端再收包
  目的：測試在TCP的接收緩沖區中還有未接收數據的情況下關閉Socket時，對端進程是否正常。
  結論：這種情況服務器端就會向對端發送RST包，而不是正常的FIN包（已經抓包證明），這就會導致客戶端提前（RST包比正常數據包先被收到）收到“10054: An existing connection was forcibly closed by the remote host”（Windows下）或“104: Connection reset by peer”（Linux下）錯誤。

3 效果和總結

3.1 總結

TCP應用程序某些看是正常的行為下也可能會導致對端接收到異常，比如當TCP接收緩沖區中還有未收數據的情況下關閉Socket，則會導致對端接收到異常關閉而不是正常關閉；反過來說，當TCP檢測到異常關閉時并不一定表示業務上出問題了，因為很可能就是業務正常結束了。下面是本次測試的主要結論：

• 當TCP連接的對端進程已經關閉了Socket的情況下，本端進程再發送數據時，第一包可以發送成功（但會導致對端發送一個RST包過來）：之后如果再繼續發送數據會失敗，錯誤碼為“10053: An established connection was aborted by the software in your host machine”（Windows下）或“32: Broken pipe，同時收到SIGPIPE信號”（Linux下）錯誤；之后如果接收數據，則Windows下會報10053的錯誤，而Linux下則收到正常關閉消息。

• TCP連接的本端接收緩沖區中還有未接收數據的情況下close了Socket，則本端TCP會向對端發送RST包，而不是正常的FIN包，這就會導致對端進程提前（RST包比正常數據包先被收到）收到“10054: An existing connection was forcibly closed by the remote host”（Windows下）或“104: Connection reset by peer”（Linux下）錯誤。

3.2 效果

B項目跨服跳轉的掉線問題有相當一部分的種情況是tconnd向客戶端轉發跨服跳轉消息后立即關閉Socket連接，而此時剛好客戶端向tconnd發送了數據包：

• 第一種情況：tconnd在關閉Socket的時刻其TCP的接收緩沖區中有未收的消息，這就使得tconnd進程的TCP向客戶端發送的是RST包而不是正常結束的FIN包，所以客戶端程序就會提前收到RST包（RST包會比正常數據提前收到），而不會先收完跨服跳轉消息后再接收到正常結束消息，這就導致客戶端收到網絡異常斷線而做重連，但之前的連接是tconnd主動關閉的，所以不可能重連成功，從而導致掉線。

• 第二種情況：tconnd已經關閉了Socket后，客戶端在接收到跳轉消息和檢測到TCP關閉之前向tconnd發送了消息，這就會導致客戶端程序收到異常斷線而做重連并失敗。

最后，與B項目項目組一起討論，改進了大部分跨服跳轉的業務流程后，掉線比例j減少了很多，當然還是存在一定比例的掉線，但這應該就是其它一些原因了（網絡異常問題原因很多，國內當前的網絡環境下，掉線問題是不可能完全避免的）。

三.結束語

通常情況下，向TCP的Socket發送完數據后關閉Socket，大家認為這樣很正常的方式肯定沒有問題，對端應該正確收完數據后收到TCP的關閉消息，但實際上在某些情況下并非如此：當TCP本端的接收緩沖區中有未收的數據時關閉Socket，這會導致對端收到RST的異常關閉消息；當對端在本端已經關閉Socket的情況下再次發送消息時，也會導致對端收到異常關閉消息；還有為了避免TIME_WAIT而設置了SO_LINGER選項的話，也會導致連接提前夭折使對端收到RST異常關閉消息。

有些時候業務流程對是否引起掉線也很重要（特別是連接關閉流程），比如前面的B項目的跨服跳轉掉線問題很大部分就是因為GameSvr請求關閉連接導致的。建議各個游戲項目的關閉流程（包括跨服跳轉的原連接的關閉）最好都由客戶端發起關閉，這樣就一定程度上避免上述問題的發生（因為客服端發起關閉的時候，一般業務流程都走完了，服務器端也不會再向客戶端發送消息了）。

程序收到網絡異常的情況很多（最多的就是Linux下的104錯誤和Windos下的10054/10053錯誤）：有網絡本身的問題、也有應用使用不當的問題；有運營商之間的跨網絡問題、網絡中間路由器問題、玩家機器硬件（比如網卡及其驅動）問題和操作系統、殺毒軟件、防火墻等軟件問題，還有玩家的上網設備和路由器等中間設備問題等，但客戶端程序崩潰問題有可能會占掉線的很高比例，這也是值得我們注意和改進的地方。還有種情況值得我們注意，有些TP-LINK的路由器，當UDP包大小超過其MTU值時會導致用戶機器的網絡斷開，從而引起掉線（這個問題在某些項目的個別玩家中已經出現過）。

網絡異常關閉引起掉線是當前游戲中普遍存在的問題，區別只在于掉線的比例多少，特別是國內各運營商之間跨網絡訪問更是不太順暢，要將其完全消除是不可能的，但我們的目標是將其控制在較小的可接受范圍內。