#電腦頻繁死機怎么辦?#
電腦死機故障是電腦使用中出現的比較多的問題，也是比較難以排查的電腦故障，有時候你把整個硬件換一遍，還是照樣死機。到底是哪里的問題，只有天知道！
一、無規律死機
這種問題誰遇到誰頭疼，因為故障出現毫無規律可循。
1、有的表現為電腦在使用過程中突然鼠標停滯，幾秒后電腦藍屏。而重新啟動電腦有的時候可以正常啟動，有的時候開機還是藍屏，必須重裝系統才能解決問題。
2、有的表現為有時候開機使用一天都沒有問題，兩天也沒有問題，不知道一星期中的哪一天就突然藍屏了。
3、有的表現為春天，秋天，冬天使用都正常，就是天熱的時候容易出現死機問題，但是死機的時候CPU和顯卡還有主板溫度又都是四五十度，完全不是過熱死機。
4、有的死機表現為在客戶家里經常死機，但是把電腦搬到電腦公司使用一天，一個星期都不死機一次。
......
因為這種死機沒有規律 ，你無法按排除法快速查出問題原因，只能先對最有可能死機的硬件進行更換，等待死機出現與否，由此來判斷是否找到故障原因。
經驗分析，容易造成無規律死機的原因有：
1、環境干擾
2、電源干擾
3、接插件或數據線接口氧化引起的接觸不良
4、硬件不穩定隨機故障，這種問題一般與震動或溫度有關。
這類問題維修的難點是如何把無規律的死機故障 ，變成可以找到規律的死機故障，這就需要你有非凡的耐心和不一般的洞察力。
二、有規律死機
不管多麻煩的死機問題，只要有規律我們就可以使替換排除法找到故障原因和故障硬件。
1、開機自檢時死機
自檢時死機說明在自檢時發現比較嚴重的外圍設備錯誤，無法通過才導致的死機我們在排查時重點檢查USB接口和USB接口是否有設備，網絡接口，甚至顯示數據接口也要檢查。因為顯示設備和電腦主機不共地時兩者之間的箱體電壓差有時會通過數據線路放電，從而導致電腦死機。
如果確定外圍設備和外圍端口都沒有問題，那就是可以使用替換法對硬件逐一排查了。
2、進BIOS死機
如果電腦沒有可啟動設備時，開機會自動進入BIOS設置界面。如果電腦開機就進入BIOS界面，并且死機無法操作。這種問題需要使用編程器重新刷寫BIOS，對于GIGA或ASUS主板，可以在進入BIOS后沒有死機之前，按F2看能不能進入BIOS刷寫界面。如果刷寫界面不死機，我們就可以重新刷寫BIOS，看是不是BIOS數據有問題。
當然清除CMOS數據也是必須的操作。刷寫BIOS后仍然死機，那就是主板的問題了。
3、啟動系統時死機
這類故障最常見，WINDOWS的啟動LOGO已經出現，但是長時間停在這個界面無法通過，這種問題一般是硬盤有問題，有可能是硬盤的數據接口有問題，也可能是硬盤有壞塊或壞道，導致讀出的數據無法加載成功。
這類故障我們可以進入安全模式，當加載到某一文件時長時間停滯，那就是這個系統文件損壞了，也可能是對應的硬件有問題無法完成初始化。
4、進入桌面時死機
電腦開機后自檢啟動都正常，當進入桌面后就死機無反應，只有一個鼠標能夠左右移動。這種問題一般是EXPLOER.EXE文件被病毒破壞改動，導致桌面無法正常加載所致。
5、運行某一軟件時死機
這類故障比較容易解決，多數時候是軟件兼容性問題，或者硬件對新版本或老版本的操作系統兼容性不好。這類問題我們可以使用虛擬機，在當前操作系統下安裝虛擬機，再安裝老版本的操作系統，在虛擬機的操作系統中再安裝這個應用軟件。因為虛擬機也可以操作當前硬件，所以就不需要安裝兩套操作系統來回切換了。
6、電腦關機時死機，長時間停留正在關閉計算機
這種問題一般是軟件問題，往往是新安裝了某一個應用軟件或升級了某個驅動，因為這個應用軟件改動了動態鏈接庫文件，導致系統關機時出錯，就長時間停留在關閉中了。這個問題可以進入安全模式，把新安裝的軟件卸載試一試。
7、玩游戲時死機
因為游戲對硬件要求較高，如果電腦玩游戲時死機，有可能CPU或顯卡散熱不良，電源功率不足造成的電腦滿載運行時死機。這類問題重點檢查散熱風扇，散熱器灰塵，導熱硅脂缺失，電源功率是否匹配等。
8、電腦啟動打死機，打印文件時死機
這種問題需要分成軟件和硬件來分析。打印機的USB接口有短路或者接口板有故障 ，也會出現開啟打印機后導致主機死機。只是這種死機我們只要拔下USB數據線后，系統就可以恢復正常。
對于軟件問題，我們可以把打印機驅動程序卸載后，重新到官網下載后再次安裝來排除驅動文件有問題。
9、天氣熱的時候死機
這里的天氣熱的時候死機，天冷的時候就不死機，這說明死機直接與環境溫度有關，那么這類死機也是電腦主機散熱不良導致的。重點檢查CPU散熱器和散熱風扇，還有電腦機箱擺放位置，電源風扇出風口是否距離墻體過近等。
10、開空調的時候死機
電腦整天運行都沒有問題，只要一開空調，電腦馬上就藍屏重啟。進入系統后一會兒就又藍屏，然后再重啟，如此往復，最后系統損壞無法啟動。這類電腦死機是電腦機箱和電源抗干擾能力差，空調開啟后的脈沖干擾通過220V供電線或者近距離輻射竄入電腦，導致電腦死機。
解決這類問題可以加裝抗干擾電源插排，也可以更換一個優質的主機電源，再把電腦換一個房間試試，問題就可以解決了。
11、白天正常晚上死機
這種問題也非常奇怪，白天電腦開機運行都沒有問題，但是晚上開機就頻繁死機。這種問題排查時我們重點觀察周圍環境，白天與晚上有什么變化。這是一個真實的案例，一個小公司白天上班電腦都是正常的，因為晚上沒有人上班，所以之前有沒有問題就不知道了。只是有一 段時間公司晚上加班，一到八點多，辦公室加班的幾臺電腦就都死機了。就是重啟用不了多長時間還是死機，根本無法正常工作。
電腦也抱到電腦公司檢測 了，沒有問題。白天電腦公司也派人過來檢查，也沒有發現問題。這件事情來來回回經歷了一個多月，也沒有查出原因。最后我晚上去這家公司排查時發現，晚上8點多，看門的保安吃過晚飯，就開始給自己的電動車充電，只要他的電動車一開始充電，電腦就開始死機。充電器拔下來，電腦就不再出現死機問題。我看了一下他的充電器，就是在電子城買的二十幾塊的錢的充電器，非常輕，問題就是它了。
我們通過了解TCP各個狀態，可以排除和定位網絡或系統故障時大有幫助。
了解TCP之前，先了解幾個命令：
linux查看tcp的狀態命令：
1) netstat -nat 查看TCP各個狀態的數量
2)lsof -i:port 可以檢測到打開套接字的狀況
3) sar -n SOCK 查看tcp創建的連接數
4) tcpdump -iany tcp port 9000 對tcp端口為9000的進行抓包
網絡測試常用命令;
1）ping:檢測網絡連接的正常與否,主要是測試延時、抖動、丟包率。
但是很多服務器為了防止攻擊，一般會關閉對ping的響應。所以ping一般作為測試連通性使用。
ping命令后，會接收到對方發送的回饋信息，其中記錄著對方的IP地址和TTL。TTL是該字段指定IP包被路由器丟棄之前允許通過的最大網段數量。
TTL是IPv4包頭的一個8 bit字段。例如IP包在服務器中發送前設置的TTL是64，你使用ping命令后，得到服務器反饋的信息，其中的TTL為56，說明途中一共經過了8道路由器的轉發，每經過一個路由，TTL減1。
2）traceroute：raceroute 跟蹤數據包到達網絡主機所經過的路由工具
traceroute hostname
3）pathping：是一個路由跟蹤工具，它將 ping 和 tracert 命令的功能與這兩個工具所不提供的其他信息結合起來，綜合了二者的功能
pathping www.baidu.com
4）mtr：以結合ping nslookup tracert 來判斷網絡的相關特性
5) nslookup:用于解析域名，一般用來檢測本機的DNS設置是否配置正確。
LISTENING：偵聽來自遠方的TCP端口的連接請求.
首先服務端需要打開一個socket進行監聽，狀態為LISTEN。
有提供某種服務才會處于LISTENING狀態，TCP狀態變化就是某個端口的狀態變化，提供一個服務就打開一個端口。
例如：提供www服務默認開的是80端口，提供ftp服務默認的端口為21，當提供的服務沒有被連接時就處于LISTENING狀態。
FTP服務啟動后首先處于偵聽（LISTENING）狀態。處于偵聽LISTENING狀態時，該端口是開放的，等待連接，但還沒有被連接。就像你房子的門已經敞開的，但還沒有人進來。
看LISTENING狀態最主要的是看本機開了哪些端口，這些端口都是哪個程序開的，關閉不必要的端口是保證安全的一個非常重要的方面，服務端口都對應一個服務（應用程序），停止該服務就關閉了該端口，例如要關閉21端口只要停止IIS服務中的FTP服務即可。關于這方面的知識請參閱其它文章。
如果你不幸中了服務端口的木馬，木馬也開個端口處于LISTENING狀態。
SYN-SENT：客戶端SYN_SENT狀態：
再發送連接請求后等待匹配的連接請求:客戶端通過應用程序調用connect進行active open.
于是客戶端tcp發送一個SYN以請求建立一個連接.之后狀態置為SYN_SENT.
The socket is actively attempting to establish a connection. 在發送連接請求后等待匹配的連接請求
當請求連接時客戶端首先要發送同步信號給要訪問的機器，此時狀態為SYN_SENT，如果連接成功了就變為ESTABLISHED，正常情況下SYN_SENT狀態非常短暫。
例如要訪問網站http://www.baidu.com,如果是正常連接的話，用TCPView觀察IEXPLORE.EXE（IE）建立的連接會發現很快從SYN_SENT變為ESTABLISHED，表示連接成功。SYN_SENT狀態快的也許看不到。
如果發現有很多SYN_SENT出現，那一般有這么幾種情況，一是你要訪問的網站不存在或線路不好。
二是用掃描軟件掃描一個網段的機器，也會出出現很多SYN_SENT，另外就是可能中了病毒了，例如中了”沖擊波”，病毒發作時會掃描其它機器，這樣會有很多SYN_SENT出現。
SYN-RECEIVED：服務器端狀態SYN_RCVD
再收到和發送一個連接請求后等待對方對連接請求的確認
當服務器收到客戶端發送的同步信號時，將標志位ACK和SYN置1發送給客戶端，此時服務器端處于SYN_RCVD狀態，如果連接成功了就變為ESTABLISHED，正常情況下SYN_RCVD狀態非常短暫。
如果發現有很多SYN_RCVD狀態，那你的機器有可能被SYN Flood的DoS(拒絕服務攻擊)攻擊了。
SYN Flood的攻擊原理是：
在進行三次握手時，攻擊軟件向被攻擊的服務器發送SYN連接請求（握手的第一步），但是這個地址是偽造的，如攻擊軟件隨機偽造了51.133.163.104、65.158.99.152等等地址。
服務器在收到連接請求時將標志位ACK和SYN置1發送給客戶端（握手的第二步），但是這些客戶端的IP地址都是偽造的，服務器根本找不到客戶機，也就是說握手的第三步不可能完成。
這種情況下服務器端一般會重試（再次發送SYN+ACK給客戶端）并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級（大約為30秒-2分鐘）；
一個用戶出現異常導致服務器的一個線程等待1分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源——數以萬計的半連接。
即使是簡單的保存并遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。
此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱做：服務器端受到了SYN Flood攻擊（SYN洪水攻擊）
ESTABLISHED：代表一個打開的連接。
ESTABLISHED狀態是表示兩臺機器正在傳輸數據，觀察這個狀態最主要的就是看哪個程序正在處于ESTABLISHED狀態。
服務器出現很多ESTABLISHED狀態：netstat -nat |grep 9502或者使用lsof -i:9502可以檢測到。
當客戶端未主動close的時候就斷開連接：即客戶端發送的FIN丟失或未發送。
這時候若客戶端斷開的時候發送了FIN包，則服務端將會處于CLOSE_WAIT狀態；
這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態；
結果客戶端重新連接服務器。
而新連接上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED; 如果客戶端重復的上演這種情況，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。
最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，并顯示ESTABLISHED，但始終無法進入程序代碼。
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
主動關閉(active close)端應用程序調用close，于是其TCP發出FIN請求主動關閉連接，之后進入FIN_WAIT1狀態./ The socket is closed, and the connection is shutting down. 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認 /
如果服務器出現shutdown再重啟，使用netstat -nat查看，就會看到很多FIN-WAIT-1的狀態。就是因為服務器當前有很多客戶端連接，直接關閉服務器后，無法接收到客戶端的ACK。
FIN-WAIT-2：從遠程TCP等待連接中斷請求
主動關閉端接到ACK后，就進入了FIN-WAIT-2
Connection is closed, and the socket is waiting for a shutdown from the remote end. 從遠程TCP等待連接中斷請求
這就是著名的半關閉的狀態了，這是在關閉連接時，客戶端和服務器兩次握手之后的狀態。
在這個狀態下，應用程序還有接受數據的能力，但是已經無法發送數據，但是也有一種可能是，客戶端一直處于FIN_WAIT_2狀態，而服務器則一直處于WAIT_CLOSE狀態，而直到應用層來決定關閉這個狀態。
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
被動關閉(passive close)端TCP接到FIN后，就發出ACK以回應FIN請求(它的接收也作為文件結束符傳遞給上層應用程序),并進入CLOSE_WAIT.
The remote end has shut down, waiting for the socket to close. 等待從本地用戶發來的連接中斷請求
CLOSING：等待遠程TCP對連接中斷的確認
比較少見
Both sockets are shut down but we still don’t have all our data sent. 等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認
被動關閉端一段時間后，接收到文件結束符的應用程序將調用CLOSE關閉連接。這導致它的TCP也發送一個
FIN,等待對方的ACK.就進入了LAST-ACK .
The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原來發向遠程TCP的連接中斷請求的確認
使用并發壓力測試的時候，突然斷開壓力測試客戶端，服務器會看到很多LAST-ACK。
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
在主動關閉端接收到FIN后，TCP就發送ACK包，并進入TIME-WAIT狀態。
The socket is waiting after close to handle
packets still in the network.等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
TIME_WAIT等待狀態，這個狀態又叫做2MSL狀態，說的是在TIME_WAIT2發送了最后一個ACK數據報以后，要進入TIME_WAIT狀態，這個狀態是防止最后一次握手的數據報沒有傳送到對方那里而準備的（注意這不是四次握手，這是第四次握手的保險狀態）。
這個狀態在很大程度上保證了雙方都可以正常結束，但是，問題也來了。
由于插口的2MSL狀態（插口是IP和端口對的意思，socket），使得應用程序在2MSL時間內是無法再次使用同一個插口的，對于客戶程序還好一些，但是對于服務程序，例如httpd，它總是要使用同一個端口來進行服務，而在2MSL時間內，啟動httpd就會出現錯誤（插口被使用）。
為了避免這個錯誤，服務器給出了一個平靜時間的概念，這是說在2MSL時間內，雖然可以重新啟動服務器，但是這個服務器還是要平靜的等待2MSL時間的過去才能進行下一次連接。
詳情請看：TIME_WAIT引起Cannot assign requested address報錯
CLOSED：沒有任何連接狀態
被動關閉端在接受到ACK包后，就進入了closed的狀態。連接結束
The socket is not being used. 沒有任何連接狀態
client/server兩條路線講述TCP狀態遷移路線圖：
這是一個看起來比較復雜的狀態遷移圖，因為它包含了兩個部分—-服務器的狀態遷移和客戶端的狀態遷移，如果從某一個角度出發來看這個圖，就會清晰許多，這里面的服務器和客戶端都不是絕對的，發送數據的就是客戶端，接受數據的就是服務器。
客戶端應用程序的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以后，客戶端就打開了數據交互地連接。
而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以后，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。
服務器的狀態遷移圖
服務器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連接的時候，服務器端是在第三次握手之后才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以后（注意不是第四次）。而關閉以后還要等待客戶端給出最后的ACK包才能進入初始的狀態。
其他狀態遷移
還有一些其他的狀態遷移，這些狀態遷移針對服務器和客戶端兩方面的總結如下
LISTEN->SYNSENT，對于這個解釋就很簡單了，服務器有時候也要打開連接的嘛。
SYN_SENT->SYN收到，服務器和客戶端在SYN_SENT狀態下如果收到SYN數據報，則都需要發送SYN的ACK數據報并把自己的狀態調整到SYN收到狀態，準備進入ESTABLISHED
SYN_SENT->CLOSED，在發送超時的情況下，會返回到CLOSED狀態。
SYN收到->LISTEN，如果受到RST包，會返回到LISTEN狀態。
SYN_收到->FIN_WAIT_1，這個遷移是說，可以不用到ESTABLISHED狀態，而可以直接跳轉到FIN_WAIT_1狀態并等待關閉。
怎樣牢牢地將這張圖刻在腦中呢？那么你就一定要對這張圖的每一個狀態，及轉換的過程有深刻的認識，不能只停留在一知半解之中。
下面對這張圖的11種狀態詳細解析一下，以便加強記憶！不過在這之前，先回顧一下TCP建立連接的三次握手過程，以及關閉連接的四次握手過程。
TCP是一個面向連接的協議，所以在連接雙方發送數據之前，都需要首先建立一條連接。
Client連接Server：
當Client端調用socket函數調用時，相當于Client端產生了一個處于Closed狀態的套接字。
(1)第一次握手：Client端又調用connect函數調用，系統為Client隨機分配一個端口，連同傳入connect中的參數(Server的IP和端口)，這就形成了一個連接四元組，客戶端發送一個帶SYN標志的TCP報文到服務器。
這是三次握手過程中的報文1。connect調用讓Client端的socket處于SYN_SENT狀態，等待服務器確認；SYN：同步序列編號(Synchronize Sequence Numbers)。
(2)第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
(3) 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶器和客務器進入ESTABLISHED狀態，完成三次握手。連接已經可以進行讀寫操作。
一個完整的三次握手也就是：請求—-應答—-再次確認。
TCP協議通過三個報文段完成連接的建立，這個過程稱為三次握手(three-way handshake)，過程如下圖所示。
對應的函數接口：
2)Server
當Server端調用socket函數調用時，相當于Server端產生了一個處于Closed狀態的監聽套接字，Server端調用bind操作，將監聽套接字與指定的地址和端口關聯，然后又調用listen函數，系統會為其分配未完成隊列和完成隊列，此時的監聽套接字可以接受Client的連接，監聽套接字狀態處于LISTEN狀態。
當Server端調用accept操作時，會從完成隊列中取出一個已經完成的client連接，同時在server這段會產生一個會話套接字，用于和client端套接字的通信，這個會話套接字的狀態是ESTABLISH。
從圖中可以看出，當客戶端調用connect時，觸發了連接請求，向服務器發送了SYN J包，這時connect進入阻塞狀態；
服務器監聽到連接請求，即收到SYN J包，調用accept函數接收請求向客戶端發送SYN K ，ACK J+1，這時accept進入阻塞狀態；客戶端收到服務器的SYN K ，ACK J+1之后，這時connect返回，并對SYN K進行確認；服務器收到ACK K+1時，accept返回，至此三次握手完畢，連接建立。
我們可以通過網絡抓包的查看具體的流程：
比如我們服務器開啟9502的端口。使用tcpdump來抓包：tcpdump -iany tcp port 9502
然后我們使用telnet 127.0.0.1 9502開連接:
我們看到 （1）（2）（3）三步是建立tcp：
第一次握手：
14:12:45.104687 IP localhost.39870 > localhost.9502: Flags [S], seq 2927179378客戶端IP localhost.39870 (客戶端的端口一般是自動分配的) 向服務器localhost.9502 發送syn包(syn=j)到服務器》
syn的seq=2927179378
第二次握手：
14:12:45.104701 IP localhost.9502 > localhost.39870: Flags [S.], seq 1721825043, ack 2927179379,
服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包
SYN（ack=j+1）=ack 2927179379 服務器主機SYN包（syn=seq 1721825043）
第三次握手：
14:12:45.104711 IP localhost.39870 > localhost.9502: Flags [.], ack 1,客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1)
客戶端和服務器進入ESTABLISHED狀態后，可以進行通信數據交互。此時和accept接口沒有關系，即使沒有accepte，也進行3次握手完成。
連接出現連接不上的問題，一般是網路出現問題或者網卡超負荷或者是連接數已經滿啦。
紫色背景的部分：
IP localhost.39870 > localhost.9502: Flags [P.], seq 1:8, ack 1, win 4099, options [nop,nop,TS val 255478182 ecr 255474104], length 7
客戶端向服務器發送長度為7個字節的數據，
IP localhost.9502 > localhost.39870: Flags [.], ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 0
服務器向客戶確認已經收到數據
IP localhost.9502 > localhost.39870: Flags [P.], seq 1:19, ack 8, win 4096, options [nop,nop,TS val 255478182 ecr 255478182], length 18
然后服務器同時向客戶端寫入數據。
IP localhost.39870 > localhost.9502: Flags [.], ack 19, win 4097, options [nop,nop,TS val 255478182 ecr 255478182], length 0
客戶端向服務器確認已經收到數據
這個就是tcp可靠的連接，每次通信都需要對方來確認。
由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。
首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉(half-close)造成的，如圖：
（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。
（2）服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。
（4）客戶端A發回ACK報文確認，并將確認序號設置為收到序號加1（報文段7）。
對應函數接口如圖：
調用過程如下：
1) 當client想要關閉它與server之間的連接。client（某個應用進程）首先調用close主動關閉連接，這時TCP發送一個FIN M；client端處于FIN_WAIT1狀態。
2) 當server端接收到FIN M之后，執行被動關閉。對這個FIN進行確認，返回給client ACK。
當server端返回給client ACK后，client處于FIN_WAIT2狀態，server處于CLOSE_WAIT狀態。它的接收也作為文件結束符傳遞給應用進程，因為FIN的接收 意味著應用進程在相應的連接上再也接收不到額外數據；
3) 一段時間之后，當server端檢測到client端的關閉操作(read返回為0)。接收到文件結束符的server端調用close關閉它的socket。這導致server端的TCP也發送一個FIN N；此時server的狀態為LAST_ACK。
4) 當client收到來自server的FIN后 。client端的套接字處于TIME_WAIT狀態，它會向server端再發送一個ack確認，此時server端收到ack確認后，此套接字處于CLOSED狀態。
這樣每個方向上都有一個FIN和ACK。
1．為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；
但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
2．為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？
這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）：
一方面是可靠的實現TCP全雙工連接的終止，也就是當最后的ACK丟失后，被動關閉端會重發FIN，因此主動關閉端需要維持狀態信息，以允許它重新發送最終的ACK。
另一方面，但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處于LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。
TCP在2MSL等待期間，定義這個連接(4元組)不能再使用，任何遲到的報文都會丟棄。設想如果沒有2MSL的限制，恰好新到的連接正好滿足原先的4元組，這時候連接就可能接收到網絡上的延遲報文就可能干擾最新建立的連接。
3、發現系統存在大量TIME_WAIT狀態的連接，可以通過調整內核參數解決：vi /etc/sysctl.conf 加入以下內容：
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_fin_timeout=30
然后執行 /sbin/sysctl -p 讓參數生效。
net.ipv4.tcp_syncookies=1 表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse=1 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle=1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間
兩個應用程序同時執行主動打開的情況是可能的，雖然發生的可能性較低。每一端都發送一個SYN,并傳遞給對方，且每一端都使用對端所知的端口作為本地端口。例如：
主機a中一應用程序使用7777作為本地端口，并連接到主機b 8888端口做主動打開。
主機b中一應用程序使用8888作為本地端口，并連接到主機a 7777端口做主動打開。
tcp協議在遇到這種情況時，只會打開一條連接。
這個連接的建立過程需要4次數據交換，而一個典型的連接建立只需要3次交換（即3次握手）
但多數伯克利版的tcp/ip實現并不支持同時打開。
如果應用程序同時發送FIN，則在發送后會首先進入FIN_WAIT_1狀態。在收到對端的FIN后，回復一個ACK，會進入CLOSING狀態。在收到對端的ACK后，進入TIME_WAIT狀態。這種情況稱為同時關閉。
同時關閉也需要有4次報文交換，與典型的關閉相同。
在TCP層，有個FLAGS字段，這個字段有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.
其中，對于我們日常的分析有用的就是前面的五個字段。
一、字段含義：1、SYN表示建立連接：
步序列編號(Synchronize Sequence Numbers)欄有效。該標志僅在三次握手建立TCP連接時有效。它提示TCP連接的服務端檢查序列編號，該序列編號為TCP連接初始端(一般是客戶端)的初始序列編號。在這里，可以把TCP序列編號看作是一個范圍從0到4，294，967，295的32位計數器。通過TCP連接交換的數據中每一個字節都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個字節的序列編號。
2、FIN表示關閉連接：
3、ACK表示響應：
確認編號(Acknowledgement Number)欄有效。大多數情況下該標志位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1，Figure-1)為下一個預期的序列編號，同時提示遠端系統已經成功接收所有數據。
4、PSH表示有DATA數據傳輸：
5、RST表示連接重置：復位標志有效。用于復位相應的TCP連接。
二、字段組合含義：
其中，ACK是可能與SYN，FIN等同時使用的，比如SYN和ACK可能同時為1，它表示的就是建立連接之后的響應，
如果只是單個的一個SYN，它表示的只是建立連接。
TCP的幾次握手就是通過這樣的ACK表現出來的。
但SYN與FIN是不會同時為1的，因為前者表示的是建立連接，而后者表示的是斷開連接。
RST一般是在FIN之后才會出現為1的情況，表示的是連接重置。
一般地，當出現FIN包或RST包時，我們便認為客戶端與服務器端斷開了連接；
RST與ACK標志位都置一了，并且具有ACK number，非常明顯，這個報文在釋放TCP連接的同時，完成了對前面已接收報文的確認。
而當出現SYN和SYN＋ACK包時，我們認為客戶端與服務器建立了一個連接。
PSH為1的情況，一般只出現在 DATA內容不為0的包中，也就是說PSH為1表示的是有真正的TCP數據包內容被傳遞。
TCP的連接建立和連接關閉，都是通過請求－響應的模式完成的。
如果TCP連接被對方正常關閉，也就是說，對方是正確地調用了closesocket(s)或者shutdown(s)的話，那么上面的Recv或Send調用就能馬上返回，并且報錯。這是由于close socket(s)或者shutdown(s)有個正常的關閉過程，會告訴對方“TCP連接已經關閉，你不需要再發送或者接受消息了”。
但是，如果意外斷開，客戶端（3g的移動設備）并沒有正常關閉socket。雙方并未按照協議上的四次揮手去斷開連接。
那么這時候正在執行Recv或Send操作的一方就會因為沒有任何連接中斷的通知而一直等待下去，也就是會被長時間卡住。
像這種如果一方已經關閉或異常終止連接，而另一方卻不知道，我們將這樣的TCP連接稱為半打開的。
解決意外中斷辦法都是利用保活機制。而保活機制分又可以讓底層實現也可自己實現。
1、自己編寫心跳包程序
簡單的說也就是在自己的程序中加入一條線程，定時向對端發送數據包，查看是否有ACK，如果有則連接正常，沒有的話則連接斷開
2、啟動TCP編程里的keepAlive機制
一、雙方擬定心跳（自實現）
一般由客戶端發送心跳包，服務端并不回應心跳，只是定時輪詢判斷一下與上次的時間間隔是否超時（超時時間自己設定）。服務器并不主動發送是不想增添服務器的通信量，減少壓力。
但這會出現三種情況：
情況1.
客戶端由于某種網絡延遲等原因很久后才發送心跳（它并沒有斷），這時服務器若利用自身設定的超時判斷其已經斷開，而后去關閉socket。若客戶端有重連機制，則客戶端會重新連接。若不確定這種方式是否關閉了原本正常的客戶端，則在ShutDown的時候一定要選擇send,表示關閉發送通道，服務器還可以接收一下，萬一客戶端正在發送比較重要的數據呢，是不？
情況2.
客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端已經判斷出其超時，并主動close，則四次揮手成功交互。
情況3.
客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端的輪詢還未判斷出其超時，在未主動close的時候該客戶端已經重新連接。
這時候若客戶端斷開的時候發送了FIN包，則服務端將會處于CLOSE_WAIT狀態；
這時候若客戶端斷開的時候未發送FIN包，則服務端處還是顯示ESTABLISHED狀態；
而新連接上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED;這時候就有個問題，若利用輪詢還未檢測出上條舊連接已經超時（這很正常，timer總有個間隔吧），而在這時，客戶端又重復的上演情況3，那么服務端將會出現大量的假的ESTABLISHED連接和CLOSE_WAIT連接。
最終結果就是新的其他客戶端無法連接上來，但是利用netstat還是能看到一條連接已經建立，并顯示ESTABLISHED，但始終無法進入程序代碼。
個人最初感覺導致這種情況是因為假的ESTABLISHED連接和CLOSE_WAIT連接會占用較大的系統資源，程序無法再次創建連接（因為每次我發現這個問題的時候我只連了10個左右客戶端卻已經有40多條無效連接）。
而最近幾天測試卻發現有一次程序內只連接了2，3個設備，但是有8條左右的虛連接，此時已經連接不了新客戶端了。
這時候我就覺得我想錯了，不可能這幾條連接就占用了大量連接把，如果說幾十條還有可能。但是能肯定的是，這個問題的產生絕對是設備在不停的重啟，而服務器這邊又是簡單的輪詢，并不能及時處理，暫時還未能解決。
二、利用KeepAlive
其實keepalive的原理就是TCP內嵌的一個心跳包,
以服務器端為例，如果當前server端檢測到超過一定時間（默認是 7,200,000 milliseconds，也就是2個小時）沒有數據傳輸，那么會向client端發送一個keep-alive packet（該keep-alive packet就是ACK和當前TCP序列號減一的組合），此時client端應該為以下三種情況之一：
對于應用程序來說，2小時的空閑時間太長。因此，我們需要手工開啟Keepalive功能并設置合理的Keepalive參數。
全局設置可更改/etc/sysctl.conf,加上:net.ipv4.tcp_keepalive_intvl=20net.ipv4.tcp_keepalive_probes=3net.ipv4.tcp_keepalive_time=60
在程序中設置如下:
在程序中表現為,當tcp檢測到對端socket不再可用時(不能發出探測包,或探測包沒有收到ACK的響應包),select會返回socket可讀,并且在recv時返回-1,同時置上errno為ETIMEDOUT.
經常出現的錯誤：
22：參數錯誤，比如ip地址不合法，沒有目標端口等
101：網絡不可達，比如不能ping通
111：鏈接被拒絕，比如目標關閉鏈接等
115：當鏈接設置為非阻塞時，目標沒有及時應答，返回此錯誤，socket可以繼續使用。比如socket連接