1.TCP連線與HTTP連線的關係

• 在網路分層中，HTTP協議是基於TCP協議的;
• 客戶端向服務端傳送一個HTTP請求時，需要先與服務端建立TCP連線，也就是經典的三次握手（通常對用- 戶來說是很難察覺的），握手成功以後才能進行資料互動;
• HTTP是基於請求響應模式且無狀態的協議,1.1之前只支援短連線，也就是請求響應一次以後連線中斷，下次請求需要重新進行TCP連線，而1.1之後支援持長連線，即進行一次TCP連線以後，客戶端可以傳送多次的HTTP請求給伺服器端。

2.TCP連線與Socket連線的關係

• Socket是應用層與傳輸層之間的同一個抽象層，它是一套介面，所以Socket連線可以基於TCP連線，也有可能基於UDP;
• 我們知道，TCP協議是可靠的，UDP協議是不可靠的，那麼基於TCP協議的Socket連線同樣是可靠的；
• 基於UDP協議的Socket連線是不可靠的，大多數的即時通訊工具都是基於後者實現的。

3.TCP的三次握手和四次分手

TCP建立連線需要經過三次握手，而斷開連線需要經過四次分手，那三次握手和四次分手分別做了什麼和如何進行的。

第一次握手：建立連線。客戶端傳送連線請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認； 第二次握手：伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設定Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要傳送SYN請求資訊，將SYN位置為1，Sequence Number為y；伺服器端將上述所有資訊放到一個報文段（即SYN+ACK報文段）中，一併傳送給客戶端，此時伺服器進入SYN_RECV狀態； 第三次握手

：客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1，向伺服器傳送ACK報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。

完成了三次握手，客戶端和伺服器端就可以開始傳送資料。以上就是TCP三次握手的總體介紹。通訊結束客戶端和服務端就斷開連線，需要經過四次分手確認。

第一次分手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了； 第二次分手

：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求； 第三次分手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入LAST_ACK狀態； 第四次分手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。

可以看到一次tcp請求的建立及關閉至少進行7次通訊，這還不包過資料的通訊，而UDP不需3次握手和4次分手。

4.TCP和UDP的區別

• 1：TCP是面向連結的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連線的可靠性，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連線的可靠性;而UDP不是面向連線的，UDP傳送資料前並不與對方建立連線，對接收到的資料也不傳送確認訊號，傳送端不知道資料是否會正確接收，當然也不用重發，所以說UDP是無連線的、不可靠的一種資料傳輸協議。
• 2：也正由於1所說的特點，使得UDP的開銷更小資料傳輸速率更高，因為不必進行收發資料的確認，所以UDP的實時性更好。知道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸檔案慢了，但並不能說QQ的通訊是不安全的，因為程式設計師可以手動對UDP的資料收發進行驗證，比如傳送方對每個資料包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。

5.Http是什麼

• HTTP協議，即超文字傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和全球資訊網(WWW = World Wide Web)伺服器之間互相通訊的規則，通過因特網傳送全球資訊網文件的資料傳送協議;
• HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型;
• HTTP預設的埠號為tcp 80;
• 瀏覽網頁是HTTP的主要應用，但是這並不代表HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通訊的雙方都遵守這個協議，HTTP就能有用武之地。比如咱們常用的QQ，迅雷這些軟體，都會使用HTTP協議(還包括其他的協議);

6.Http特點

6.1.無連線（TCP短連線）

無連線的含義是限制每次連線只處理一個請求，伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線，請求響應模式。採用這種方式可以節省傳輸時間。

Why? 早期這麼做的原因是 HTTP 協議產生於網際網路，因此伺服器需要處理同時面向全世界數十萬、上百萬客戶端的網頁訪問，但每個客戶端（即瀏覽器）與伺服器之間交換資料的間歇性較大（即傳輸具有突發性、瞬時性），並且網頁瀏覽的聯想性、發散性導致兩次傳送的資料關聯性很低，大部分通道實際上會很空閒、無端佔用資源。因此 HTTP 的設計者有意利用這種特點將協議設計為請求時建連線、請求完釋放連線，以儘快將資源釋放出來服務其他客戶端。

隨著時間的推移，網頁變得越來越複雜，裡面可能嵌入了很多圖片，這時候每次訪問圖片都需要建立一次 TCP 連線就顯得很低效。後來，Keep-Alive 被提出用來解決這效率低的問題。

Keep-Alive 功能使客戶端到伺服器端的連線持續有效，當出現對伺服器的後繼請求時，Keep-Alive 功能避免了建立或者重新建立連線。市場上的大部分 Web 伺服器，包括 iPlanet、IIS 和 Apache，都支援 HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裡存在另外一個問題：雖然為客戶保留開啟的連線有一定的好處，但它同樣影響了效能，因為在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web伺服器和應用伺服器在同一臺機器上執行時，Keep-Alive 功能對資源利用的影響尤其突出。  這樣一來，客戶端和伺服器之間的 HTTP 連線就會被保持，不會斷開（超過 Keep-Alive 規定的時間，意外斷電等情況除外），當客戶端傳送另外一個請求時，就使用這條已經建立的連線。

6.2.無狀態

無狀態是指協議對於事務處理沒有記憶能力，伺服器不知道客戶端是什麼狀態。即我們給伺服器傳送 HTTP 請求之後，伺服器根據請求，會給我們傳送資料過來，但是，傳送完，不會記錄任何資訊。

HTTP 是一個無狀態協議，這意味著每個請求都是獨立的，Keep-Alive 沒能改變這個結果。

缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

HTTP 協議這種特性有優點也有缺點，優點在於解放了伺服器，每一次請求“點到為止”不會造成不必要連線佔用，缺點在於每次請求會傳輸大量重複的內容資訊。

客戶端與伺服器進行動態互動的 Web 應用程式出現之後，HTTP 無狀態的特性嚴重阻礙了這些應用程式的實現，畢竟互動是需要承前啟後的，簡單的購物車程式也要知道使用者到底在之前選擇了什麼商品。於是，兩種用於保持 HTTP 連線狀態的技術就應運而生了，一個是 Cookie，而另一個則是 Session。

Cookie可以保持登入資訊到使用者下次與伺服器的會話，換句話說，下次訪問同一網站時，使用者會發現不必輸入使用者名稱和密碼就已經登入了（當然，不排除使用者手工刪除Cookie）。而還有一些Cookie在使用者退出會話的時候就被刪除了，這樣可以有效保護個人隱私。

Cookies 最典型的應用是判定註冊使用者是否已經登入網站，使用者可能會得到提示，是否在下一次進入此網站時保留使用者資訊以便簡化登入手續，這些都是 Cookies 的功用。另一個重要應用場合是“購物車”之類處理。使用者可能會在一段時間內在同一家網站的不同頁面中選擇不同的商品，這些資訊都會寫入 Cookies，以便在最後付款時提取資訊。

與 Cookie 相對的一個解決方案是 Session，它是通過伺服器來保持狀態的。

當客戶端訪問伺服器時，伺服器根據需求設定 Session，將會話資訊儲存在伺服器上，同時將標示 Session 的 SessionId 傳遞給客戶端瀏覽器，瀏覽器將這個 SessionId 儲存在記憶體中，我們稱之為無過期時間的 Cookie。瀏覽器關閉後，這個 Cookie 就會被清掉，它不會存在於使用者的 Cookie 臨時檔案。

以後瀏覽器每次請求都會額外加上這個引數值，伺服器會根據這個 SessionId，就能取得客戶端的資料資訊。

如果客戶端瀏覽器意外關閉，伺服器儲存的 Session 資料不是立即釋放，此時資料還會存在，只要我們知道那個 SessionId，就可以繼續通過請求獲得此 Session 的資訊，因為此時後臺的 Session 還存在，當然我們可以設定一個 Session 超時時間，一旦超過規定時間沒有客戶端請求時，伺服器就會清除對應 SessionId 的 Session 資訊。

7.Http中的倆種請求型別

7.1.http Get

• 第一部分：請求行，用來說明請求型別,要訪問的資源以及所使用的HTTP版本. GET說明請求型別為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本;
• 第二部分：請求頭部，緊接著請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊; 從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,伺服器端和客戶端指令碼都能訪問它,它是瀏覽器型別檢測邏輯的重要基礎.該資訊由你的瀏覽器來定義,並且在每個請求中自動傳送等等;
• 第三部分：空行，請求頭部後面的空行是必須的; 即使第四部分的請求資料為空，也必須有空行;
• 第四部分：請求資料也叫主體，可以新增任意的其他資料; 這個例子的請求資料為空;

7.2.http Post

• 第一部分：請求行，第一行明瞭是post請求，以及http1.1版本；
• 第二部分：請求頭部，第二行至第六行；
• 第三部分：空行，第七行的空行；
• 第四部分：請求資料，第八行；

7.3.Http Response

一般情況下，伺服器接收並處理客戶端發過來的請求後會返回一個HTTP的響應訊息。 HTTP響應也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文。

第一部分： 狀態行，由HTTP協議版本號， 狀態碼， 狀態訊息 三部分組成。

第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態訊息為（ok）

第二部分： 訊息報頭，用來說明客戶端要使用的一些附加資訊

第二行和第三行和第四行為訊息報頭， Date:生成響應的日期和時間；Content-Type:指定了MIME型別的HTML(text/html),編碼型別是ISO-8859-1

第三部分：空行，訊息報頭後面的空行是必須的。

第四部分：響應正文，伺服器返回給客戶端的文字資訊。

空行後面的html部分為響應正文。

8.HTTP連線與Socket連線

• HTTP 1.1之前是短連線，基於TCP協議的Socket連線是長連線，雖然HTTP1.1開始支援長連線，但不像Socket連線一旦建立，除非一方主動斷開，否則連線狀態一直保持。
• 基於TCP的Socket可能是短連線，也可能是長連線，長連線可能需要通過心跳等一些手段來維持，各自有不同的應用場景。而不是簡單的"基於TCP協議的Socket連線是長連線"。後在網上查找了相關資料，有這麼一句："在TCP連線保持期間，如果沒有資料包傳送，定時傳送資料包(心跳)，以維持連線狀態。
• 用HTTP：雙方不需要時刻保持連線，客戶端只是通過一個個HTTP請求來獲取伺服器的特定資源。如通過get/post請求獲取網頁、圖片、JSON或者XML資料，還有常用的檔案上傳、小檔案下載等。用Socket：大部分即時通訊應用（知乎上說QQ有部分功能是基於TCP，因為TCP每次都需要三次握手，雖然可靠但是網路不好的時候就慘了）、聊天室（基於UDP+訊息廣播的方式）、大檔案傳輸等。

9.Thanks