摘要：三次握手和四次揮手的問題在面試中是最為常見的考點之一。上面有一個非常特殊的狀態(tài)，它是主動關閉的一方在回復完對方的揮手后進入的一個長期狀態(tài)，這個狀態(tài)標準的持續(xù)時間是分鐘，分鐘后才會進入到狀態(tài)，釋放套接字資源。

TCP三次握手和四次揮手的問題在面試中是最為常見的考點之一。很多讀者都知道三次和四次，但是如果問深入一點，他們往往都無法作出準確回答。

本篇嘗試使用動畫來對這個知識點進行講解，期望讀者們可以更加簡單地地理解TCP交互的本質(zhì)。

可分為四個層次：

1、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層和應用層。

2、?在網(wǎng)絡層:有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。

3、在傳輸層:中有TCP協(xié)議與UDP協(xié)議。

4、在應用層:有FTP、HTTP、TELNET、SMTP、DNS等協(xié)議。

TCP和UDP使用IP協(xié)議從一個網(wǎng)絡傳送數(shù)據(jù)包到另一個網(wǎng)絡。把IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等。

TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協(xié)議。雖然TCP和UDP都是用來傳輸其他協(xié)議的，它們卻有一個顯著的不同：TCP提供有保證的數(shù)據(jù)傳輸，而UDP不提供。這意味著TCP有一個特殊的機制來確保數(shù)據(jù)安全的不出錯的從一個端點傳到另一個端點，而UDP不提供任何這樣的保證。

TCP?三次握手就好比兩個人在街上隔著50米看見了對方，但是因為霧霾等原因不能100%確認，所以要通過招手的方式相互確定對方是否認識自己。

相互擁抱

我們看到這個過程中一共是四個動作，招手–點頭微笑–招手–點頭微笑。其中連續(xù)進行了2個動作，先是點頭微笑(回復對方)，然后再次招手(尋求確認)，實際上可以將這兩個動作合一，招手的同時點頭和微笑(syn+ack)。于是四個動作就簡化成了三個動作，招手–點頭微笑并招手–點頭微笑。這就是三次握手的本質(zhì)，中間的一次動作是兩個動作的合并。

我們看到有兩個中間狀態(tài)，syn_sent和syn_rcvd，這兩個狀態(tài)叫著「半打開」狀態(tài)，就是向?qū)Ψ秸惺至耍沁€沒來得及看到對方的點頭微笑。syn_sent是主動打開方的「半打開」狀態(tài)，syn_rcvd是被動打開方的「半打開」狀態(tài)?？蛻舳耸侵鲃哟蜷_方，服務器是被動打開方。

syn_sent:?syn?package?has?been?sent

syn_rcvd:?syn?package?has?been?received

TCP?數(shù)據(jù)傳輸就是兩個人隔空對話，差了一點距離，所以需要對方反復確認聽見了自己的話。

客戶端喊了一句話(data)，接收方聽見了之后要回復自己聽見了(ack)。

如果喊了一句，半天沒聽到對方回復，就認為自己的話被大風吹走了，沒聽見，所以需要重新喊話，這就是tcp重傳。

也有可能是服務端聽到了客戶端的話，但是Server向Client的回復被大風吹走了，以至于Client沒聽見Server的回復。Client并不能判斷究竟是自己的話被大風吹走了還是Server的回復被大風吹走了，Client也不用管，重傳一下就是。

Client可以向Server喊話，同樣Server也可以向Client喊話，因為tcp鏈接是「雙工的」，雙方都可以主動發(fā)起數(shù)據(jù)傳輸。不過無論是哪方喊話，都需要收到對方的確認才能認為對方收到了自己的喊話。

Client可能是個高射炮，一說連說了八句話，這時候Server可以不用一句一句回復，而是連續(xù)聽了這八句話之后，一起向?qū)Ψ交貜驼f前面你說的八句話我都聽見了，這就是批量ack。但是Client也不能一次性說了太多話，Server的腦子短時間可能無法消化太多，兩人之間需要有協(xié)商好的合適的發(fā)送和接受速率，這個就是「TCP窗口大小」。

(1)?第一次握手：建立連接時，客戶端A發(fā)送SYN包(SYN=j)到服務器B，并進入SYN_SEND狀態(tài)，等待服務器B確認。

(2)?第二次握手：服務器B收到SYN包，必須確認客戶A的SYN(ACK=j+1)，同時自己也發(fā)送一個SYN包(SYN=k)，即SYN+ACK包，此時服務器B進入SYN_RECV狀態(tài)。

(3)?第三次握手：客戶端A收到服務器B的SYN＋ACK包，向服務器B發(fā)送確認包ACK(ACK=k+1)，此包發(fā)送完畢，客戶端A和服務器B進入ESTABLISHED狀態(tài)，完成三次握手。

完成三次握手，客戶端與服務器開始傳送數(shù)據(jù)。

TCP斷開鏈接的過程和建立鏈接的過程比較類似，只不過中間的兩部并不總是會合成一步走，所以它分成了4個動作，Client揮手(fin)——Server傷感地微笑(ack)——Server揮手(fin)——Client傷感地微笑(ack)。

之所以中間的兩個動作沒有合并，是因為tcp存在「半關閉」狀態(tài)，也就是單向關閉。Client已經(jīng)揮了手，可是人還沒有走，只是不再說話，但是耳朵還是可以繼續(xù)聽，Server呢繼續(xù)喊話。等待Server累了，也不再說話了，超Client揮了揮手，Client傷感地微笑了一下，才徹底結束了。

上面有一個非常特殊的狀態(tài)time_wait，它是主動關閉的一方在回復完對方的揮手后進入的一個長期狀態(tài)，這個狀態(tài)標準的持續(xù)時間是4分鐘，4分鐘后才會進入到closed狀態(tài)，釋放套接字資源。不過在具體實現(xiàn)上這個時間是可以調(diào)整的。

它就好比主動分手方要承擔的責任，是你提出的要分手，你得付出代價。這個后果就是持續(xù)4分鐘的time_wait狀態(tài)，不能釋放套接字資源(端口)，就好比守寡期，這段時間內(nèi)套接字資源(端口)不得回收利用。

它的作用是重傳最后一個ack報文，確保對方可以收到。因為如果對方?jīng)]有收到ack的話，會重傳fin報文，處于time_wait狀態(tài)的套接字會立即向?qū)Ψ街匕l(fā)ack報文。

同時在這段時間內(nèi)，該鏈接在對話期間于網(wǎng)際路由上產(chǎn)生的殘留報文(因為路徑過于崎嶇，數(shù)據(jù)報文走的時間太長，重傳的報文都收到了，原始報文還在路上)傳過來時，都會被立即丟棄掉。4分鐘的時間足以使得這些殘留報文徹底消逝。不然當新的端口被重復利用時，這些殘留報文可能會干擾新的鏈接。

4分鐘就是2個MSL，每個MSL是2分鐘。MSL就是maximium?segment?lifetime——最長報文壽命。這個時間是由官方RFC協(xié)議規(guī)定的。至于為什么是2個MSL而不是1個MSL，我還沒有看到一個非常滿意的解釋。

四次揮手也并不總是四次揮手，中間的兩個動作有時候是可以合并一起進行的，這個時候就成了三次揮手，主動關閉方就會從fin_wait_1狀態(tài)直接進入到time_wait狀態(tài)，跳過了fin_wait_2狀態(tài)。

由于TCP連接是全雙工的，因此每個方向都必須多帶帶進行關閉。這個原則是當一方完成它的數(shù)據(jù)發(fā)送任務后就能發(fā)送一個FIN來終止這個方向的連接。收到一個?FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進行關閉的一方將執(zhí)行主動關閉，而另一方執(zhí)行被動關閉。

客戶端A發(fā)送一個FIN，用來關閉客戶A到服務器B的數(shù)據(jù)傳送(報文段4)。

服務器B收到這個FIN，它發(fā)回一個ACK，確認序號為收到的序號加1(報文段5)。和SYN一樣，一個FIN將占用一個序號。

服務器B關閉與客戶端A的連接，發(fā)送一個FIN給客戶端A(報文段6)。

客戶端A發(fā)回ACK報文確認，并將確認序號設置為收到序號加1(報文段7)。

TCP狀態(tài)轉(zhuǎn)換是一個非常復雜的過程，本文僅對一些簡單的基礎知識點進行了類比講解。關于TCP的更多知識還需要讀者去搜尋相關技術文章進入深入學習。如果讀者對TCP的基礎知識掌握得比較牢固，高級的知識理解起來就不會太過于吃力。

最近作為面試管在面試的時候，發(fā)現(xiàn)很多人框架很強，java基礎的時候就有些薄弱了，很多童鞋們對于HTTP、TCP、UDP以及SOCKET的概念不是很清楚，傻傻的分不清楚，這里我們也簡單的提一下

HTTP(超文本傳輸協(xié)議)是利用TCP在兩臺電腦(通常是Web服務器和客戶端)之間傳輸信息的協(xié)議。客戶端使用Web瀏覽器發(fā)起HTTP請求給Web服務器，Web服務器發(fā)送被請求的信息給客戶端。

HTTP協(xié)議是建立在請求/響應模型上的。首先由客戶建立一條與服務器的TCP鏈接，并發(fā)送一個請求到服務器，請求中包含請求方法、URL、協(xié)議版本以及相關的MIME樣式的消息。服務器響應一個狀態(tài)行，包含消息的協(xié)議版本、一個成功和失敗碼以及相關的MIME式樣的消息。

HTTP/1.0為每一次HTTP的請求/響應建立一條新的TCP鏈接，因此一個包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。

另外，為了獲得適當?shù)膫鬏斔俣?，則需要TCP花費額外的回路鏈接時間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1提出了可持續(xù)鏈接的實現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息，

因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。

雖然HTTP本身是一個協(xié)議，但其最終還是基于TCP的。

Socket是應用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把復雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。

Socket?接口是TCP/IP網(wǎng)絡的API，Socket接口定義了許多函數(shù)或例程，用以開發(fā)TCP/IP網(wǎng)絡上的應用程序。

這是為了實現(xiàn)以上的通信過程而建立成來的通信管道，其真實的代表是客戶端和服務器端的一個通信進程，雙方進程通過socket進行通信，而通信的規(guī)則采用指定的協(xié)議。socket只是一種連接模式，不是協(xié)議,tcp,udp，簡單的說（雖然不準確）是兩個最基本的協(xié)議,很多其它協(xié)議都是基于這兩個協(xié)議如，http就是基于tcp的，用socket可以創(chuàng)建tcp連接，也可以創(chuàng)建udp連接**，這意味著，用socket可以創(chuàng)建任何協(xié)議的連接，因為其它協(xié)議都是基于此的。

綜上所述：需要IP協(xié)議來連接網(wǎng)絡;TCP是一種允許我們安全傳輸數(shù)據(jù)的機制，使用TCP協(xié)議來傳輸數(shù)據(jù)的HTTP是Web服務器和客戶端使用的特殊協(xié)議。HTTP基于TCP協(xié)議，但是卻可以使用socket去建立一個TCP連接。

Android插件包換膚(高仿網(wǎng)易云音樂換膚)

Android中Application是單例，正確嗎？

Android App瘦身新姿勢——Android App Bundle

關于Java中的不可變性

最后如果對技術比較感興趣，歡迎關注我的微信公眾號：終端研發(fā)部，id：codeGooger，一起進階技術