[服務端與網路]http協議與http狀態碼

http協議

建立在tcp/ip網路協議(傳輸層)上的應用層協議

1.1後 具有keep-alive,即從客戶端第一次開啟網頁時所建立的tcp連線為一個有狀態和時間的長連線。

而http之所叫無狀態的短連線是因為每次瀏覽器發起請求都會建立一個新的tcp連線，根據這個連線通道來進行資料的請求傳輸，每次請求完成後即關閉該連線。當連線關閉後，伺服器的記憶體中對應的程式（用來記憶一些資訊）即被關閉，即狀態的釋放，即無狀態。

TCP連線的三次握手（連線建立）四次揮手（連線釋放）

三次握手

個人理解就是：

1. 客戶端（一群要去執行任務的人，需要連線資訊部的人提供一些需要的資訊資料）說： hi，能聽到嗎，收到請回復（電波發射，biubiubiu）
2. 服務端耳麥裡收到這段電波（程式被動開啟），辨識了下電波的ip（熟人，可以回覆），說：能（電波發射，biubiubiu）
3. 客戶端耳麥裡傳來能的電波，通知夥計們可以幹活了（主動開啟上層程式），然後對服務端說：ok，收到

  在這個過程中，通訊雙方的狀態如下圖，其中CLOSED：關閉狀態、LISTEN：收聽狀態、SYN-SENT：同步已傳送、SYN-RCVD：同步收到、ESTAB-LISHED：連線已建立

至此，TCP連線就建立了，客戶端和伺服器可以愉快地玩耍了。只要通訊雙方沒有一方發出連線釋放的請求，連線就將一直保持。

四次揮手

個人理解：

1. 客戶端本次需要的資訊資料全部接受完畢，開始收工，說： 好了，這事基本完了我不再問你了，剩餘的事你說我聽就行了，並關閉了自己這邊的麥克風（電波發射，biubiubiu）
2. 服務端耳麥裡收到這段電波，冷漠的回道：哦。收到。（電波發射，biubiubiu）然後服務端繼續逼逼傳資訊資料（繼續傳送電波）
3. 服務端檢查了一會，夥計們說都ok了（程式提示服務端斷開本次連線），於是服務端說：我說完了，拜
4. 客戶端耳麥聽到後，說：好，收到（發出確認電波），經過2msl的時間後，本次連線通訊正式結束。

 在這個過程中，通訊雙方的狀態如下圖，其中：ESTAB-LISHED：連線建立狀態、FIN-WAIT-1：終止等待1狀態、FIN-WAIT-2：終止等待2狀態、CLOSE-WAIT：關閉等待狀態、LAST-ACK：最後確認狀態、TIME-WAIT：時間等待狀態、CLOSED：關閉狀態

解釋幾個問題：

1、在握手與揮手的過程中，往復的ack與seq有什麼含義？

這是通訊雙方在通訊過程中的一種確認手段，確保通訊雙方通訊的正確性。例如小時候模仿電視劇裡無線電呼叫的過程：“土豆土豆，我是地瓜，你能聽到嗎？”“地瓜地瓜，我是土豆，我能聽到”。 若客戶端的報文請求號為“土豆”，則伺服器端就將返回確認號“土豆+1”（標誌土豆已收到），是一種通訊雙方的確認手段。

2、在結束連線的過程中，為什麼在收到伺服器端的連線釋放報文段之後，客戶端還要繼續等待2MSL之後才真正關閉TCP連線呢？

這裡有兩個原因：第一個是：需要保證伺服器端收到了客戶端的最後一條確認報文。假如這條報文丟失，伺服器沒有接收到確認報文，就會對連線釋放報文進行超時重傳，而此時客戶端連線已關閉，無法做出響應，就造成了伺服器端不停重傳連線釋放報文，而無法正常進入關閉狀態的狀況。而等待2MSL，就可以保證伺服器端收到了最終確認；若伺服器端沒有收到，那麼在2MSL之內客戶端一定會收到伺服器端的重傳報文，此時客戶端就會重傳確認報文，並重置計時器。

第二個是：存在一種“已失效的連線請求報文段”，需要避免這種報文端出現在本連線中，造成異常。

這種“已失效的連線請求報文段”是這麼形成的：假如客戶端發出了連線請求報文，然而伺服器端沒有收到，於是客戶端進行超時重傳，再一次傳送了連線請求報文，併成功建立連線。然而，第一次傳送的連線請求報文並沒有丟失，只是在某個網路結點中發生了長時間滯留，隨後，這個最初傳送的報文段到達伺服器端，會使得伺服器端誤以為客戶端發出了新的請求，造成異常。

3、若通訊雙方同時請求連線或同時請求釋放連線，情況如何？

這種情況雖然發生的可能性極小，但是是確實存在的，TCP也特意設計了相關機制，使得在這種情況下雙方僅建立一條連線。雙方同時請求連線的情況下，雙方同時發出請求連線報文，並進入SYN-SENT狀態；當收到對方的請求連線報文後，會再次傳送請求連線報文，確認號為對方的SYN+1，並進入SYN-RCVD狀態；當收到對方第二次發出的攜帶確認號的請求報文之後，會進入ESTAB-LISHED狀態。 雙方同時請求釋放連線也是同樣的，雙方同時發出連線釋放報文，並進入FIN-WAIT-1狀態；在收到對方的報文之後，傳送確認報文，並進入CLOSING狀態；在收到對方的確認報文後，進入TIME-WAIT狀態，等待2MSL之後關閉連線。需要注意的是，這個時候雖然不用再次傳送確認報文並確認對方收到，雙方仍需等待2MSL之後再關閉連線，是為了防止“已失效的連線請求報文段”的影響。 過程圖如下：

http與tcp中大部分內容轉載自部落格園貳拾肆樵

http狀態碼