HTTP連接

HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。 HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng)，在請求結(jié)束后，會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。 1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。 2）在HTTP 1.1中則可以在一次連接中處理多個請求，并且多個請求可以重疊進行，不需要等待一個請求結(jié)束后再發(fā)送下一個請求。 由于HTTP在每次請求結(jié)束后都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態(tài)，需要不斷地向服務(wù)器發(fā)起連接請求。通常 的做法是即時不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時間向服務(wù)器發(fā)送一次“保持連接”的請求，服務(wù)器在收到該請求后對客戶端進行回復(fù)，表明知道 客戶端“在線”。若服務(wù)器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到服務(wù)器的回復(fù)，則認為網(wǎng)絡(luò)已經(jīng)斷開。 SOCKET原理 套接字（socket）概念 套接字（socket）是通信的基石，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過程中端點的抽象表示，包含進行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議，本地主機的IP地址，本地進程的協(xié)議端口，遠地主機的IP地址，遠地進程的協(xié)議端口。 應(yīng)用層通過傳輸層進行數(shù)據(jù)通信時，TCP會遇到同時為多個應(yīng)用程序進程提供并發(fā)服務(wù)的問題。多個TCP連接或多個應(yīng)用程序進程可能需要通過同一個 TCP協(xié)議端口傳輸數(shù)據(jù)。為了區(qū)別不同的應(yīng)用程序進程和連接，許多計算機操作系統(tǒng)為應(yīng)用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口。應(yīng)用層可以和傳輸層通過Socket接口，區(qū)分來自不同應(yīng)用程序進程或網(wǎng)絡(luò)連接的通信，實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。 建立socket連接 建立Socket連接至少需要一對套接字，其中一個運行于客戶端，稱為ClientSocket ，另一個運行于服務(wù)器端，稱為ServerSocket 。 套接字之間的連接過程分為三個步驟：服務(wù)器監(jiān)聽，客戶端請求，連接確認。 服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請求。 客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務(wù)器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號，然后就向服務(wù)器端套接字提出連接請求。 連接確認：當服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時，就響應(yīng)客戶端套接字的請求，建立一個新的線程，把服務(wù)器端套接字的描述發(fā) 給客戶端，一旦客戶端確認了此描述，雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接收其他客戶端套接字的連接請求。 SOCKET連接與TCP連接 創(chuàng)建Socket連接時，可以指定使用的傳輸層協(xié)議，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP），當使用TCP協(xié)議進行連接時，該Socket連接就是一個TCP連接。 Socket連接與HTTP連接 由于通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立，通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開。但在實際網(wǎng) 絡(luò)應(yīng)用中，客戶端到服務(wù)器之間的通信往往需要穿越多個中間節(jié)點，例如路由器、網(wǎng)關(guān)、防火墻等，大部分防火墻默認會關(guān)閉長時間處于非活躍狀態(tài)的連接而導(dǎo)致 Socket 連接斷連，因此需要通過輪詢告訴網(wǎng)絡(luò)，該連接處于活躍狀態(tài)。 而HTTP連接使用的是“請求—響應(yīng)”的方式，不僅在請求時需要先建立連接，而且需要客戶端向服務(wù)器發(fā)出請求后，服務(wù)器端才能回復(fù)數(shù)據(jù)。 很多情況下，需要服務(wù)器端主動向客戶端推送數(shù)據(jù)，保持客戶端與服務(wù)器數(shù)據(jù)的實時與同步。此時若雙方建立的是Socket連接，服務(wù)器就可以直接將數(shù) 據(jù)傳送給客戶端；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端，因此，客戶端定時向服務(wù)器端發(fā)送連接請求， 不僅可以保持在線，同時也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶端。TCP(Transmission Control Protocol)　傳輸控制協(xié)議 TCP是主機對主機層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認建立一個連接: 位碼即tcp標志位,有6種標示:SYN(synchronous建立聯(lián)機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結(jié)束) RST(reset重置) URG(urgent緊急) Sequence number(順序號碼) Acknowledge number(確認號碼) TCP是什么？ TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。 具體的關(guān)于TCP是什么，我不打算詳細的說了；當你看到這篇文章時，我想你也知道TCP的概念了，想要更深入的了解TCP的工作，我們就繼續(xù)。它只是一個超級麻煩的協(xié)議，而它又是互聯(lián)網(wǎng)的基礎(chǔ)，也是每個程序員必備的基本功。首先來看看OSI的七層模型： 我們需要知道TCP工作在網(wǎng)絡(luò)OSI的七層模型中的第四層——Transport層，IP在第三層——Network層，ARP在第二層——Data Link層；在第二層上的數(shù)據(jù)，我們把它叫Frame，在第三層上的數(shù)據(jù)叫Packet，第四層的數(shù)據(jù)叫Segment。 同時，我們需要簡單的知道，數(shù)據(jù)從應(yīng)用層發(fā)下來，會在每一層都會加上頭部信息，進行封裝，然后再發(fā)送到數(shù)據(jù)接收端。這個基本的流程你需要知道，就是每個數(shù)據(jù)都會經(jīng)過數(shù)據(jù)的封裝和解封裝的過程。 在OSI七層模型中，每一層的作用和對應(yīng)的協(xié)議如下： TCP是一個協(xié)議，那這個協(xié)議是如何定義的，它的數(shù)據(jù)格式是什么樣子的呢？要進行更深層次的剖析，就需要了解，甚至是熟記TCP協(xié)議中每個字段的含義。哦，來吧。 TCP頭部 其中 ACK SYN 序號 這三個部分在以下會用到，它們的介紹也在下面。 上面就是TCP協(xié)議頭部的格式，由于它太重要了，是理解其它內(nèi)容的基礎(chǔ)，下面就將每個字段的信息都詳細的說明一下。

• Source Port和Destination Port:分別占用16位，表示源端口號和目的端口號；用于區(qū)別主機中的不同進程，而IP地址是用來區(qū)分不同的主機的，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連接；
• Sequence Number:用來標識從TCP發(fā)端向TCP收端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的的第一個數(shù)據(jù)字節(jié)在數(shù)據(jù)流中的序號；主要用來解決網(wǎng)絡(luò)報亂序的問題；
• Acknowledgment Number:32位確認序列號包含發(fā)送確認的一端所期望收到的下一個序號，因此，確認序號應(yīng)當是上次已成功收到數(shù)據(jù)字節(jié)序號加1。不過，只有當標志位中的ACK標志（下面介紹）為1時該確認序列號的字段才有效。主要用來解決不丟包的問題；
• Offset:給出首部中32 bit字的數(shù)目，需要這個值是因為任選字段的長度是可變的。這個字段占4bit（最多能表示15個32bit的的字，即4*15=60個字節(jié)的首部長度），因此TCP最多有60字節(jié)的首部。然而，沒有任選字段，正常的長度是20字節(jié)；
• TCP Flags:TCP首部中有6個標志比特，它們中的多個可同時被設(shè)置為1，主要是用于操控TCP的狀態(tài)機的，依次為URG，ACK，PSH，RST，SYN，FIN。每個標志位的意思如下：

URG：此標志表示TCP包的緊急指針域（后面馬上就要說到）有效，用來保證TCP連接不被中斷，并且督促中間層設(shè)備要盡快處理這些數(shù)據(jù)； ACK：此標志表示應(yīng)答域有效，就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中；有兩個取值：0和1，為1的時候表示應(yīng)答域有效，反之為0； PSH：這個標志位表示Push操作。所謂Push操作就是指在數(shù)據(jù)包到達接收端以后，立即傳送給應(yīng)用程序，而不是在緩沖區(qū)中排隊； RST：這個標志表示連接復(fù)位請求。用來復(fù)位那些產(chǎn)生錯誤的連接，也被用來拒絕錯誤和非法的數(shù)據(jù)包； SYN：表示同步序號，用來建立連接。SYN標志位和ACK標志位搭配使用，當連接請求的時候，SYN=1，ACK=0；連接被響應(yīng)的時候，SYN=1，ACK=1；這個標志的數(shù)據(jù)包經(jīng)常被用來進行端口掃描。掃描者發(fā)送一個只有SYN的數(shù)據(jù)包，如果對方主機響應(yīng)了一個數(shù)據(jù)包回來 ，就表明這臺主機存在這個端口；但是由于這種掃描方式只是進行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機器不很安全，一臺安全的主機將會強制要求一個連接嚴格的進行TCP的三次握手； FIN： 表示發(fā)送端已經(jīng)達到數(shù)據(jù)末尾，也就是說雙方的數(shù)據(jù)傳送完成，沒有數(shù)據(jù)可以傳送了，發(fā)送FIN標志位的TCP數(shù)據(jù)包后，連接將被斷開。這個標志的數(shù)據(jù)包也經(jīng)常被用于進行端口掃描。

• Window:窗口大小，也就是有名的滑動窗口，用來進行流量控制；這是一個復(fù)雜的問題，這篇博文中并不會進行總結(jié)的；

暫時需要的信息有： ACK ： TCP協(xié)議規(guī)定，只有ACK=1時有效，也規(guī)定連接建立后所有發(fā)送的報文的ACK必須為1 SYN(SYNchronization) ： 在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應(yīng)在響應(yīng)報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。 FIN （finis）即完，終結(jié)的意思， 用來釋放一個連接。當 FIN = 1 時，表明此報文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接。 三次握手的過程： 多么清晰的一張圖，當然了，也不是我畫的，我也只是引用過來說明問題了。

第一次握手：建立連接。客戶端發(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進入SYN_SEND狀態(tài)，等待服務(wù)器的確認；

第二次握手：服務(wù)器收到SYN報文段。服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務(wù)器進入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務(wù)器端都進入ESTABLISHED狀態(tài)，完成TCP三次握手。

完成了三次握手，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。以上就是TCP三次握手的總體介紹。 那四次分手呢？ 當客戶端和服務(wù)器通過三次握手建立了TCP連接以后，當數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。

第一次分手：主機1（可以使客戶端，也可以是服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number，向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了；

第二次分手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關(guān)閉請求；

第三次分手：主機2向主機1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機2進入LAST_ACK狀態(tài)；

第四次分手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關(guān)閉連接；此時，主機1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機1也可以關(guān)閉連接了。

至此，TCP的四次分手就這么愉快的完成了。當你看到這里，你的腦子里會有很多的疑問，很多的不懂，感覺很凌亂；沒事，我們繼續(xù)總結(jié)。 為什么要三次握手 在謝希仁著《計算機網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤”。在另一部經(jīng)典的《計算機網(wǎng)絡(luò)》一書中講“三次握手”的目的是為了解決“網(wǎng)絡(luò)中存在延遲的重復(fù)分組”的問題。 在謝希仁著《計算機網(wǎng)絡(luò)》書中同時舉了一個例子，如下： “已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接。” 這就很明白了，防止了服務(wù)器端的一直等待而浪費資源。 為什么要四次分手 那四次分手又是為何呢？TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議。TCP是全雙工模式，這就意味著，當主機1發(fā)出FIN報文段時，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機1告訴主機2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)；當主機2返回ACK報文段時，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了，但是主機2還是可以發(fā)送數(shù)據(jù)到主機1的；當主機2也發(fā)送了FIN報文段時，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態(tài)變化。

• FIN_WAIT_1: 這個狀態(tài)要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)。而當對方回應(yīng)ACK報文后，則進入到FIN_WAIT_2狀態(tài)，當然在實際的正常情況下，無論對方何種情況下，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常常可以用netstat看到。（主動方）
• FIN_WAIT_2：上面已經(jīng)詳細解釋了這種狀態(tài)，實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動方）
• CLOSE_WAIT：這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢？當對方close一個SOCKET后發(fā)送FIN報文給自己，你系統(tǒng)毫無疑問地會回應(yīng)一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態(tài)。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以 close這個SOCKET，發(fā)送FIN報文給對方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動方）
• LAST_ACK: 這個狀態(tài)還是比較容易好理解的，它是被動關(guān)閉一方在發(fā)送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態(tài)了。（被動方）
• TIME_WAIT: 表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FINWAIT1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動方）
• CLOSED: 表示連接中斷。

實例: TCP的作用是流量控制，主要是控制數(shù)據(jù)流的傳輸。下面以瀏覽網(wǎng)頁為例，根據(jù)自身理解來解釋一下這個過程。（注：第二個ack屬于代碼段ack位） 握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。 第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認； 第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)； 第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。 握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主 動關(guān)閉連接之前，TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“四次握手”（過程就不細寫了，就是服務(wù)器和客 戶端交互，最終確定斷開） 對應(yīng)的實例 IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836 IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837 IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1 第一次握手：192.168.1.116發(fā)送位碼syn＝1,隨機產(chǎn)生seq number=3626544836的數(shù)據(jù)包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立聯(lián)機; 第二次握手：192.168.1.123收到請求后要確認聯(lián)機信息，向192.168.1.116發(fā)送ack number=3626544837,syn=1,ack=1,隨機產(chǎn)生seq=1739326486的包; 第三次握手：192.168.1.116收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1,以及位碼ack是否為1，若正確，192.168.1.116會再發(fā)送ack number=1739326487,ack=1，192.168.1.123收到后確認seq=seq+1,ack=1則連接建立成功。

?

轉(zhuǎn)載于:https://www.cnblogs.com/ziqian9206/p/7159044.html

總結(jié)

以上是生活随笔為你收集整理的TCP协议的三次握手和四次分手的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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