TCP連接就是傳說中的長(zhǎng)連接，有所謂的3此握手來保證消息一定可達(dá)，在java中，TCP傳輸?shù)姆绞綄儆诹鲾?shù)據(jù)傳輸，而流數(shù)據(jù)傳輸?shù)奶攸c(diǎn)就是數(shù)據(jù)到達(dá)的順序是固定的，比如說數(shù)據(jù)A寫入到TCP連接中，數(shù)據(jù)B接著再寫入到TCP連接中，數(shù)據(jù)C再寫入TCP連接，那么在另一端，如果數(shù)據(jù)不丟失，那么A到達(dá)后，B到達(dá)，C再到達(dá)；當(dāng)B丟失了，那么就是A到達(dá)，B丟失，C這時(shí)候也不會(huì)到達(dá)，因?yàn)門CP連接是可靠連接，一定會(huì)確保B到達(dá)了之后才會(huì)再去處理C數(shù)據(jù)，因此要么只收到A，B和C都丟失（TCP連接斷開），要么A收到后過一段時(shí)間重新發(fā)送B和C，然后另一端再接收B，C，最后數(shù)據(jù)接收的順序還是A，B，C，而絕對(duì)不可能出現(xiàn)A，C或者B，C的情況；

TCP數(shù)據(jù)傳輸還存在一個(gè)粘包問題，之所以會(huì)出現(xiàn)數(shù)據(jù)粘包就是因?yàn)門CP數(shù)據(jù)傳輸是流數(shù)據(jù)傳輸，假設(shè)數(shù)據(jù)包A是10個(gè)字節(jié)，數(shù)據(jù)包B是20字節(jié)，數(shù)據(jù)包C是30字節(jié)，那么發(fā)送順序是A，B，C，這時(shí)候TCP連接的流里面就有10+20+30=60個(gè)字節(jié)，但是有可能由于網(wǎng)絡(luò)原因這60個(gè)字節(jié)并不會(huì)一次性都發(fā)出去，有可能先發(fā)了15個(gè)字節(jié)，再發(fā)20個(gè)字節(jié)，再發(fā)30個(gè)字節(jié)，那么在接收端就會(huì)連續(xù)收到三次數(shù)據(jù)，但是接收端必須對(duì)每次接收到的數(shù)據(jù)進(jìn)行處理，第一次接收到了15個(gè)字節(jié)，而A只有10個(gè)字節(jié)，那么多出來的5個(gè)字節(jié)就是B的，這時(shí)候就出現(xiàn)了粘包，就是說數(shù)據(jù)包B的部分?jǐn)?shù)據(jù)粘在的數(shù)據(jù)包A后面了，所以在接收端要截取完整的數(shù)據(jù)包再進(jìn)行處理，把多出來的5個(gè)字節(jié)緩存起來等待接收B數(shù)據(jù)，以此類推UDP就不存在粘包的問題，UDP發(fā)送的數(shù)據(jù)包都是一個(gè)完整的包，因此接收端收到的包也會(huì)是一個(gè)完整的數(shù)據(jù)包，但是UDP每次發(fā)送的數(shù)據(jù)包大小是有限的，最大不超過【UDP中的總長(zhǎng)度字段為2字節(jié) 所能表示的最大數(shù)為65535 UDP協(xié)議頭本身占據(jù)了8字節(jié) 所以所能發(fā)送的最大數(shù)據(jù)長(zhǎng)度是65535-8=65527】，而且UDP在網(wǎng)絡(luò)環(huán)境不好的情況下容易丟失，丟失了也不會(huì)通知到發(fā)送方或者接收方，所以UDP是不可靠連接，但是UDP連接并不會(huì)一直維持一條從發(fā)送放到接收方的連接，發(fā)送方只要把數(shù)據(jù)扔出去就結(jié)束了發(fā)送流程，而接收方只是開一個(gè)指定的端口并監(jiān)聽這個(gè)端口，有數(shù)據(jù)來就處理，沒數(shù)據(jù)就不管，所以UDP連接省資源，在不丟失數(shù)據(jù)的情況下發(fā)送的效率比較高，占用內(nèi)存少，而TCP是時(shí)時(shí)刻刻維持一個(gè)長(zhǎng)連接，比較耗資源，占用較多內(nèi)存

在移動(dòng)開發(fā)中，IM一般采用TCP長(zhǎng)連接，TCP長(zhǎng)連接會(huì)遇到一下幾個(gè)問題 :

耗資源，增加app的耗電量；占內(nèi)存，增加app的運(yùn)行內(nèi)存，提升了在手機(jī)休眠情況下app被系統(tǒng)殺死的概率，導(dǎo)致TCP連接斷開，消息無法即時(shí)收到

IM開發(fā)中一般有一個(gè)心跳包的概念，為什么要心跳包呢？因?yàn)榫W(wǎng)絡(luò)運(yùn)營(yíng)商中有一個(gè)NAT超時(shí)，大部分移動(dòng)無線網(wǎng)絡(luò)運(yùn)營(yíng)商都在鏈路一段時(shí)間沒有數(shù)據(jù)通訊時(shí)，會(huì)淘汰NAT【(Network Address Translation，NAT)。簡(jiǎn)單的說運(yùn)營(yíng)商的網(wǎng)關(guān)需要維護(hù)一個(gè)外網(wǎng)IP、端口到內(nèi)網(wǎng)IP、端口的對(duì)應(yīng)關(guān)系，以確保內(nèi)網(wǎng)的手機(jī)可以跟Internet的服務(wù)器通訊】表中的對(duì)應(yīng)項(xiàng)，造成鏈路中斷。NAT超時(shí)是影響TCP連接壽命的一個(gè)重要因素(尤其是國(guó)內(nèi))，所以客戶端自動(dòng)測(cè)算NAT超時(shí)時(shí)間，來動(dòng)態(tài)調(diào)整心跳間隔

android設(shè)備的一個(gè)bug，從網(wǎng)上查到的，DHCP租期到了不會(huì)主動(dòng)續(xù)約并且會(huì)繼續(xù)使用過期IP，這會(huì)導(dǎo)致TCP連接編程無效連接，參考網(wǎng)上資料DHCP租期

最近碰到一個(gè)問題就是app開一個(gè)TCP連接成功連到服務(wù)器，然后手機(jī)鎖屏休眠，過一段時(shí)間后（可能是幾個(gè)小時(shí)）會(huì)發(fā)現(xiàn)這條TCP連接變成無效連接了，我從后臺(tái)服務(wù)器查看手機(jī)設(shè)備的TCP連接確實(shí)是斷開了，但是手機(jī)app代碼檢測(cè)TCP連接中Socket連接卻顯示連接正常，并且連接也沒有任何中斷異常，然后手機(jī)發(fā)送數(shù)據(jù)也是正常write成功，但是實(shí)際上服務(wù)器根本沒有收到手機(jī)發(fā)送過來的數(shù)據(jù)，也就是說手機(jī)app的連接判斷都是錯(cuò)誤的，這種情況下TCP連接判斷都是正常的，但是這條TCP連接確實(shí)無效不可用的，只有把這條TCP連接主動(dòng)斷開重新連接才能正常收發(fā)數(shù)據(jù)，服務(wù)器才能重新顯示設(shè)備的TCP連接成功，我估計(jì)這個(gè)很有可能就是3造成的，有可能DHCP租期到了，但是沒有繼續(xù)續(xù)約，而采用過期IP，那么手機(jī)到運(yùn)營(yíng)商的網(wǎng)關(guān)的網(wǎng)絡(luò)是通的，而由于目標(biāo)服務(wù)器的IP已經(jīng)過去，導(dǎo)致網(wǎng)關(guān)無法幫手機(jī)app路由消息

關(guān)于TCP連接狀態(tài)的判斷，在java里面是提供了isClosed()和isConnected()判斷的是本地的狀態(tài)，想要判斷TCP連接是否真的有效： socket.sendUrgentData(0xff)，這個(gè)是立即發(fā)送一個(gè)字節(jié)數(shù)據(jù)，如果服務(wù)端的Socket沒有開啟setOOBInline(true)的話是會(huì)默認(rèn)忽略這個(gè)收到的字節(jié)的，所以如果字節(jié)數(shù)據(jù)發(fā)送成功就說明連接可用，如果字節(jié)數(shù)據(jù)發(fā)送不成功就會(huì)拋出異常，說明連接不可用