Http請求：

?

?

總的來說：

DNS解析

TCP連接

發(fā)送HTTP請求

服務(wù)器處理請求并返回HTTP報文

瀏覽器解析渲染頁面

連接結(jié)束

【補充】

?

三次握手和四次揮手：

?

第一次握手：建立連接時，客戶端發(fā)送syn包（syn=x）到服務(wù)器，并進入SYN_SENT狀態(tài)，等待服務(wù)器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發(fā)送一個SYN包（syn=y），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=y+1），此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。
?

保證數(shù)據(jù)安全和完整性。坦白來說就是為了雙方的接收和發(fā)送都正常。

打個比方：A是客戶端，B是服務(wù)器端。

A向B寄了一封信，此時A的發(fā)送和接收都不能確定正常。

然后B收到后，回了A一封信，A收到后。此時B的接收正常，A的發(fā)送和接收正常

此時B并不能確定自己的發(fā)送正常，所以A在給B寄一份信說道，你發(fā)的我收到了。

直到這個時候，整個連接才是完整的。

?

1）客戶端進程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，FIN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，FIN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。
2）服務(wù)器收到連接釋放報文，發(fā)出確認報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端就進入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進程，客戶端向服務(wù)器的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。
3）客戶端收到服務(wù)器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
4）服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，FIN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進入了LAST-ACK（最后確認）狀態(tài)，等待客戶端的確認。
5）客戶端收到服務(wù)器的連接釋放報文后，必須發(fā)出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進入CLOSED狀態(tài)。
6）服務(wù)器只要收到了客戶端發(fā)出的確認，立即進入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時間要比客戶端早一些。
?

一樣打個比方。假如說客戶端是老婆，服務(wù)器端是老公。

然后呢，老婆說，我們離婚吧。離婚協(xié)議書。（相當(dāng)于客戶端發(fā)送關(guān)閉請求。FIN）

老公回復(fù)：再說吧。（相當(dāng)于此時服務(wù)器端工作沒有完成。ACK）

然后老公想了想：好的我們離婚吧。老公簽字。（相當(dāng)于服務(wù)器端工作完成，同意結(jié)束。FIN）

然后老婆說好的。老婆簽字。（相當(dāng)于客戶端接收到。ACK）

DNS解析：

?

Tcp狀態(tài)

l? CLOSED：初始狀態(tài)，表示TCP連接是“關(guān)閉著的”或“未打開的”。

l? LISTEN?：表示服務(wù)器端的某個SOCKET處于監(jiān)聽狀態(tài)，可以接受客戶端的連接。

l? SYN_RCVD?：表示服務(wù)器接收到了來自客戶端請求連接的SYN報文。在正常情況下，這個狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態(tài)，很短暫，基本上用netstat很難看到這種狀態(tài)，除非故意寫一個監(jiān)測程序，將三次TCP握手過程中最后一個ACK報文不予發(fā)送。當(dāng)TCP連接處于此狀態(tài)時，再收到客戶端的ACK報文，它就會進入到ESTABLISHED 狀態(tài)。

l? SYN_SENT?：這個狀態(tài)與SYN_RCVD 狀態(tài)相呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)行connect()進行連接時，它首先發(fā)送SYN報文，然后隨即進入到SYN_SENT 狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個報文。SYN_SENT 狀態(tài)表示客戶端已發(fā)送SYN報文。

l? ESTABLISHED?：表示TCP連接已經(jīng)成功建立。

l? FIN_WAIT_1?：這個狀態(tài)得好好解釋一下，其實FIN_WAIT_1 和FIN_WAIT_2 兩種狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET進入到FIN_WAIT_1 狀態(tài)。而當(dāng)對方回應(yīng)ACK報文后，則進入到FIN_WAIT_2 狀態(tài)。當(dāng)然在實際的正常情況下，無論對方處于任何種情況下，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1 狀態(tài)一般是比較難見到的，而FIN_WAIT_2 狀態(tài)有時仍可以用netstat看到。

l? FIN_WAIT_2?：上面已經(jīng)解釋了這種狀態(tài)的由來，實際上FIN_WAIT_2狀態(tài)下的SOCKET表示半連接，即有一方調(diào)用close()主動要求關(guān)閉連接。注意：FIN_WAIT_2 是沒有超時的（不像TIME_WAIT 狀態(tài)），這種狀態(tài)下如果對方不關(guān)閉（不配合完成4次揮手過程），那這個?FIN_WAIT_2 狀態(tài)將一直保持到系統(tǒng)重啟，越來越多的FIN_WAIT_2 狀態(tài)會導(dǎo)致內(nèi)核crash。

l? TIME_WAIT?：表示收到了對方的FIN報文，并發(fā)送出了ACK報文。?TIME_WAIT狀態(tài)下的TCP連接會等待2*MSL（Max Segment Lifetime，最大分段生存期，指一個TCP報文在Internet上的最長生存時間。每個具體的TCP協(xié)議實現(xiàn)都必須選擇一個確定的MSL值，RFC 1122建議是2分鐘，但BSD傳統(tǒng)實現(xiàn)采用了30秒，Linux可以cat?/proc/sys/net/ipv4/tcp_fin_timeout看到本機的這個值），然后即可回到CLOSED 可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對方同時帶FIN標(biāo)志和ACK標(biāo)志的報文時，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（這種情況應(yīng)該就是四次揮手變成三次揮手的那種情況）

l??CLOSING?：這種狀態(tài)在實際情況中應(yīng)該很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)一方發(fā)送FIN報文后，按理來說是應(yīng)該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING 狀態(tài)表示一方發(fā)送FIN報文后，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現(xiàn)此種情況呢？那就是當(dāng)雙方幾乎在同時close()一個SOCKET的話，就出現(xiàn)了雙方同時發(fā)送FIN報文的情況，這是就會出現(xiàn)CLOSING 狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。

l? CLOSE_WAIT?：表示正在等待關(guān)閉。怎么理解呢？當(dāng)對方close()一個SOCKET后發(fā)送FIN報文給自己，你的系統(tǒng)毫無疑問地將會回應(yīng)一個ACK報文給對方，此時TCP連接則進入到CLOSE_WAIT狀態(tài)。接下來呢，你需要檢查自己是否還有數(shù)據(jù)要發(fā)送給對方，如果沒有的話，那你也就可以close()這個SOCKET并發(fā)送FIN報文給對方，即關(guān)閉自己到對方這個方向的連接。有數(shù)據(jù)的話則看程序的策略，繼續(xù)發(fā)送或丟棄。簡單地說，當(dāng)你處于CLOSE_WAIT 狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。

l? LAST_ACK?：當(dāng)被動關(guān)閉的一方在發(fā)送FIN報文后，等待對方的ACK報文的時候，就處于LAST_ACK 狀態(tài)。當(dāng)收到對方的ACK報文后，也就可以進入到CLOSED 可用狀態(tài)了。

?

?常見面試題
【問題1】為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？

答：因為當(dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當(dāng)Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

【問題2】為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

答：雖然按道理，四個報文都發(fā)送完畢，我們可以直接進入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復(fù)所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

【問題3】為什么不能用兩次握手進行連接？

答：3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認。

???????現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機S和C之間的通信，假定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā) 送了確認應(yīng)答分組。按照兩次握手的協(xié)定，S認為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組。可是，C在S的應(yīng)答分組在傳輸中被丟失的情況下，將不知道S 是否已準(zhǔn)備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分 組，只等待連接確認應(yīng)答分組。而S在發(fā)出的分組超時后，重復(fù)發(fā)送同樣的分組。這樣就形成了死鎖。

【問題4】如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個保活計時器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認為客戶端出了故障，接著就關(guān)閉連接。

部分摘自：https://blog.csdn.net/qq_38950316/article/details/81087809

總結(jié)

以上是生活随笔為你收集整理的大剑无锋之HTTP连接、Tcp三次握手四次挥手、Tcp状态的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。