TCP/IP協(xié)議場(chǎng)景
說(shuō)道TCP/IP協(xié)議想起了計(jì)算機(jī)網(wǎng)絡(luò)書(shū)中舉了一個(gè)紅藍(lán)軍的通訊的問(wèn)題。其場(chǎng)景如下：
紅藍(lán)軍需要聯(lián)手干掉山坡下敵人埂软，雙方約定某個(gè)時(shí)間一起進(jìn)攻。
紅軍 <-------------> 藍(lán)軍
-----A:下午5點(diǎn)進(jìn)攻-->
<---A+ack：收到消息---
-----A+ack+ack：----
由于任何一次通信都可能中斷所灸，通訊次數(shù)越多概率越大炫七。于是在通訊可靠性和時(shí)間上做了一個(gè)折中，根據(jù)理論計(jì)算至少需要3次握手概率才達(dá)到比較滿(mǎn)意的水平侠驯。
TCP協(xié)議本質(zhì)上解決是不可靠信道上需要可靠傳輸信息的需求
如果信道是可靠的那么奕巍，那么不需要建立連接直接發(fā)送數(shù)據(jù)包也能夠確保到達(dá)。但是實(shí)際網(wǎng)絡(luò)中信道是不可靠的檩坚，需要通過(guò)3次握手來(lái)確定一條比較可靠的信道诅福。
所以TCP連接建立后，都是沿同一條鏈路發(fā)送消息么赂乐？
連接釋放為什么需要4次握手
通過(guò)4次握手的目的是確保通信雙方都釋放了連接咖气，這樣都不在發(fā)送數(shù)據(jù)包（防止網(wǎng)絡(luò)上有大量的無(wú)用數(shù)據(jù)包，會(huì)增加網(wǎng)絡(luò)的擁塞）浅役。
TCP 序列號(hào)和確認(rèn)號(hào)詳解
TCP 通訊涉及到 客戶(hù)端 client 和服務(wù)端 server悯舟，我們根據(jù)建立連接、發(fā)送數(shù)據(jù)奋救、釋放連接 3個(gè)階段來(lái)描述序列號(hào)和確認(rèn)號(hào)生成過(guò)程反惕。
連接建立階段大體上是，確認(rèn)號(hào)=對(duì)方的序列號(hào)+1背亥，序列號(hào)(除了第一次)=對(duì)方的確認(rèn)號(hào)
客戶(hù)端 服務(wù)端
序列號(hào)J | 確認(rèn)號(hào)0 |置SYN標(biāo)識(shí) ---->
<---- 序列號(hào)k | 確認(rèn)號(hào)J+1 | 置SYN和ACK標(biāo)識(shí)
序列號(hào)J+1| 確認(rèn)號(hào) k+1 | 置ACK標(biāo)識(shí) ---->
數(shù)據(jù)傳輸階段大體上是,確認(rèn)號(hào)=對(duì)方序列號(hào) + 數(shù)據(jù)報(bào)文長(zhǎng)度，序列號(hào)= 對(duì)方確認(rèn)號(hào)
TCP 協(xié)議的狀態(tài)遷移
TCP建立連接一般是服務(wù)器啟動(dòng)服務(wù)進(jìn)行監(jiān)聽(tīng)娄徊，處理客戶(hù)端發(fā)過(guò)來(lái)的請(qǐng)求盾戴。
其狀態(tài)流轉(zhuǎn)是：
client：close -> SYN-SEND -> ESTABLISH
server: close -> LISTEN -> SYN-RECV -> ESTABLISH
連接釋放尖啡，我們以客戶(hù)端主動(dòng)斷開(kāi)連接為例。
客戶(hù)端 服務(wù)端
發(fā)送報(bào)文 FIN_WAIT1 --> 此時(shí)服務(wù)器 CLOSE_WAIT(被動(dòng)關(guān)閉)
FIN_WAIT2 <-- 服務(wù)器 ACK到客戶(hù)端
TIME_WAIT (接收到最后確認(rèn)后衅斩，客戶(hù)端進(jìn)入TIME——WAIT) <--- 再一次確認(rèn) LASTACK
當(dāng)客戶(hù)端等待2MSL后 發(fā)送ack 到服務(wù)端 --> close狀態(tài)了
實(shí)際連接釋放可以分為兩個(gè)階段畏梆，第一階段：半連接 ，第二階段：服務(wù)端也釋放具温。
第一階段：
客戶(hù)端 發(fā)送fin報(bào)文 ---> 服務(wù)端
FIN_WAIT2 <---- ACK 報(bào)文
FIN_WAIT2 狀態(tài)就是半連接的狀態(tài)铣猩，表示客戶(hù)端已經(jīng)斷開(kāi)連接茴丰，服務(wù)端還有一些數(shù)據(jù)要發(fā)送。
第二階段：
過(guò)了一段時(shí)間峦椰，服務(wù)端沒(méi)有數(shù)據(jù)要發(fā)送了汰规。
此時(shí)：
TIME_WAIT <--- 服務(wù)端發(fā)送FIN 報(bào)文 進(jìn)入LAST_ACk狀態(tài) （服務(wù)端在發(fā)送了FIN后等待 MSL如果沒(méi)有收到ACK則會(huì)重傳FIN消息）
客戶(hù)端發(fā)送 ACK ---> 服務(wù)端
客戶(hù)端發(fā)出ACK后，等待ACK到達(dá)對(duì)方的超時(shí)時(shí)間MSL滔金，等待FIN重傳時(shí)間也是MSL茂嗓，所以如果客戶(hù)端2MSL時(shí)間段內(nèi)沒(méi)有收到FIN報(bào)文表示 服務(wù)端已經(jīng)收到了ACK報(bào)文（已經(jīng)關(guān)閉了）。
用概率來(lái)衡量不確定的東西
從“背景”那里分析忿族，握手次數(shù)越多越好概率越高。但是實(shí)際情況下是可靠性和時(shí)效性之間的折中错英。而對(duì)于這些不確定的事情隆豹，我們最好的思路是以概率的方式來(lái)思考（而不是強(qiáng)迫癥似的想100%）。
同樣在微服務(wù)框架中簿煌，通過(guò)兩臺(tái)機(jī)器提供負(fù)載均衡鉴吹。這樣系統(tǒng)可用性為 p = 1-p1*p1,p1為系統(tǒng)宕機(jī)的概率。
思想的運(yùn)用
TCP/IP 會(huì)有超時(shí)重傳的機(jī)制夺荒，每發(fā)一段報(bào)文的時(shí)候會(huì)設(shè)置一個(gè)超時(shí)時(shí)間良蒸，如果超時(shí)會(huì)重發(fā)報(bào)文。
在我們的支付系統(tǒng)中剿吻，系統(tǒng)與系統(tǒng)之間的交互也是類(lèi)似的思想串纺。拿下單來(lái)舉例：
網(wǎng)關(guān) client .................... server 銀行（比如支付寶）
ewallet 下單 ---> 發(fā)報(bào)文到銀行
<--- 同步返回/或者異步通知 (ack) 纺棺，如果client timeout內(nèi)沒(méi)有接收到ack報(bào)文，則通過(guò)定時(shí)任務(wù)掃描網(wǎng)關(guān)中非success 的訂單祷蝌，調(diào)用查詢(xún)接口（查詢(xún)狀態(tài)）巨朦。
---> response.write("success") (ack+ack) ，同樣罪郊，如果server沒(méi)有收到ack+ack 報(bào)文悔橄，則會(huì)重傳 ack報(bào)文（即重新異步通知）腺毫。
參考：
http://www.cnblogs.com/chenboo/archive/2011/12/19/2293327.html
