先來一個(gè)講TCP、UDP和HTTP關(guān)系的
1、TCP/IP是個(gè)協(xié)議組，可分為三個(gè)層次：網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。
在網(wǎng)絡(luò)層有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。
在傳輸層中有TCP協(xié)議與UDP協(xié)議。
在應(yīng)用層有FTP、HTTP、TELNET、SMTP、DNS等協(xié)議。
因此，HTTP本身就是一個(gè)協(xié)議，是從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
TCP 是基于 TCP 協(xié)議實(shí)現(xiàn)的網(wǎng)絡(luò)文本協(xié)議,屬于傳輸層。
UDP 是和TCP 對等的，屬于傳輸層，UDP 和 TCP 有重要的區(qū)別。
2、HTTP協(xié)議是建立在請求/響應(yīng)模型上的。首先由客戶建立一條與服務(wù)器的TCP鏈接，并發(fā)送一個(gè)請求到服務(wù)器，請求中包含請求方法、URI、協(xié)議版本以及相關(guān)的MIME樣式的消息。服務(wù)器響應(yīng)一個(gè)狀態(tài)行，包含消息的協(xié)議版本、一個(gè)成功和失敗碼以及相關(guān)的MIME式樣的消息。
HTTP/1.0為每一次HTTP的請求/響應(yīng)建立一條新的TCP鏈接，因此一個(gè)包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。
另外，為了獲得適當(dāng)?shù)膫鬏斔俣?，則需要TCP花費(fèi)額外的回路鏈接時(shí)間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實(shí)際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1提出了可持續(xù)鏈接的實(shí)現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復(fù)地使用它傳輸一系列的請求/響應(yīng)消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。
這里有必要再講一下三次握手的過程:
第一次握手：建立連接時(shí)，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；ACK:確認(rèn)字符(Acknowledgement)
第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1），此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。
3、結(jié)論：雖然HTTP本身是一個(gè)協(xié)議，但其最終還是基于TCP的。不過，目前，有人正在研究基于TCP+UDP混合的HTTP協(xié)議。
Socket是什么呢？
Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。在設(shè)計(jì)模式中，Socket其實(shí)就是一個(gè)門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。
1、HTTP協(xié)議的幾個(gè)重要概念
1.連接(Connection)：一個(gè)傳輸層的實(shí)際環(huán)流，它是建立在兩個(gè)相互通訊的應(yīng)用程序之間。
2.消息(Message)：HTTP通訊的基本單位，包括一個(gè)結(jié)構(gòu)化的八元組序列并通過連接傳輸。
3.請求(Request)：一個(gè)從客戶端到服務(wù)器的請求信息包括應(yīng)用于資源的方法、資源的標(biāo)識符和協(xié)議的版本號
4.響應(yīng)(Response)：一個(gè)從服務(wù)器返回的信息包括HTTP協(xié)議的版本號、請求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。
5.資源(Resource)：由URI標(biāo)識的網(wǎng)絡(luò)數(shù)據(jù)對象或服務(wù)。
6.實(shí)體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個(gè)請求或響應(yīng)信息中。一個(gè)實(shí)體包括實(shí)體頭信息和實(shí)體的本身內(nèi)容。
7.客戶機(jī)(Client)：一個(gè)為發(fā)送請求目的而建立連接的應(yīng)用程序。
8.用戶代理(Useragent)：初始化一個(gè)請求的客戶機(jī)。它們是瀏覽器、編輯器或其它用戶工具。
9.服務(wù)器(Server)：一個(gè)接受連接并對請求返回信息的應(yīng)用程序。
10.源服務(wù)器(Originserver)：是一個(gè)給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。
11.代理(Proxy)：一個(gè)中間程序，它可以充當(dāng)一個(gè)服務(wù)器，也可以充當(dāng)一個(gè)客戶機(jī)，為其它客戶機(jī)建立請求。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個(gè)代理在發(fā)送請求信息之前，必須解釋并且如果可能重寫它。
代理經(jīng)常作為通過防火墻的客戶機(jī)端的門戶，代理還可以作為一個(gè)幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請求。
12.網(wǎng)關(guān)(Gateway)：一個(gè)作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請求就好象對被請求的資源來說它就是源服務(wù)器；發(fā)出請求的客戶機(jī)并沒有意識到它在同網(wǎng)關(guān)打交道。
網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個(gè)協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源。
13.通道(Tunnel)：是作為兩個(gè)連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個(gè)HTTP請求初始化的。當(dāng)被中繼的連接兩端關(guān)閉時(shí)，通道便消失。當(dāng)一個(gè)門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時(shí)通道被經(jīng)常使用。
14.緩存(Cache)：反應(yīng)信息的局域存儲。
2.發(fā)送請求
打開一個(gè)連接后，客戶機(jī)把請求消息送到服務(wù)器的停留端口上，完成提出請求動作。
HTTP/1.0 請求消息的格式為：
請求消息=請求行(通用信息|請求頭|實(shí)體頭)CRLF[實(shí)體內(nèi)容]
請求 行=方法 請求URLHTTP版本號 CRLF
方 法=GET|HEAD|POST|擴(kuò)展方法
URL=協(xié)議名稱+宿主名+目錄與文件名
請求行中的方法描述指定資源中應(yīng)該執(zhí)行的動作，常用的方法有GET、HEAD和POST。不同的請求對象對應(yīng)GET的結(jié)果是不同的，對應(yīng)關(guān)系如下：
對象 GET的結(jié)果
文件 文件的內(nèi)容
程序 該程序的執(zhí)行結(jié)果
數(shù)據(jù)庫查詢 查詢結(jié)果
HEAD——要求服務(wù)器查找某對象的元信息，而不是對象本身。
POST——從客戶機(jī)向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和CGI做進(jìn)一步處理時(shí)會用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容，讓CGI程序處理。
一個(gè)請求的例子為：
GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0
頭信息又稱為元信息，即信息的信息，利用元信息可以實(shí)現(xiàn)有條件的請求或應(yīng)答。
請求頭——告訴服務(wù)器怎樣解釋本次請求，主要包括用戶可以接受的數(shù)據(jù)類型、壓縮方法和語言等。
實(shí)體頭——實(shí)體信息類型、長度、壓縮方法、最后一次修改時(shí)間、數(shù)據(jù)有效期等。
實(shí)體——請求或應(yīng)答對象本身。
3.發(fā)送響應(yīng)
服務(wù)器在處理完客戶的請求之后，要向客戶機(jī)發(fā)送響應(yīng)消息。
HTTP/1.0的響應(yīng)消息格式如下：
響應(yīng)消息=狀態(tài)行(通用信息頭|響應(yīng)頭|實(shí)體頭)CRLF 〔實(shí)體內(nèi)容〕
狀態(tài)行=HTTP版本號 狀態(tài)碼 原因敘述
響應(yīng)頭的信息包括：服務(wù)程序名，通知客戶請求的URL需要認(rèn)證，請求的資源何時(shí)能使用。
#####4.關(guān)閉連接 客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束TCP/IP對話
通常HTTP消息包括客戶機(jī)向服務(wù)器的請求消息和服務(wù)器向客戶機(jī)的響應(yīng)消息。這兩種類型的消息由一個(gè)起始行，一個(gè)或者多個(gè)頭域，一個(gè)只是頭域結(jié)束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號（:）和域值三部分組成。域名是大小寫無關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開始處，使用至少一個(gè)空格或制表符。
————————————————
TCP（Transmission Control Protocol，傳輸控制協(xié)議）是基于連接的協(xié)議，也就是說，在正式收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復(fù)雜，我們這里只做簡單、形象的介紹，你只要做到能夠理解這個(gè)過程即可。我們來看看這三次對話的簡單過程：主機(jī)A向主機(jī)B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)，可以嗎？”，這是第一次對話；主機(jī)B向主機(jī)A發(fā)送同意連接和要求同步（同步就是兩臺主機(jī)一個(gè)在發(fā)送，一個(gè)在接收，協(xié)調(diào)工作）的數(shù)據(jù)包：“可以，你什么時(shí)候發(fā)？”，這是第二次對話；主機(jī)A再發(fā)出一個(gè)數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：“我現(xiàn)在就發(fā)，你接著吧！”，這是第三次對話。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次“對話”之后，主機(jī)A才向主機(jī)B正式發(fā)送數(shù)據(jù)。
UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）是與TCP相對應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過去！
UDP適用于一次只傳送少量數(shù)據(jù)、對可靠性要求不高的應(yīng)用環(huán)境。比如，我們經(jīng)常使用“ping”命令來測試兩臺主機(jī)之間TCP/IP通信是否正常，其實(shí)“ping”命令的原理就是向?qū)Ψ街鳈C(jī)發(fā)送UDP數(shù)據(jù)包，然后對方主機(jī)確認(rèn)收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達(dá)的消息及時(shí)反饋回來，那么網(wǎng)絡(luò)就是通的。例如，在默認(rèn)狀態(tài)下，一次“ping”操作發(fā)送4個(gè)數(shù)據(jù)包（如圖2所示）。大家可以看到，發(fā)送的數(shù)據(jù)包數(shù)量是4包，收到的也是4包（因?yàn)閷Ψ街鳈C(jī)收到后會發(fā)回一個(gè)確認(rèn)收到的數(shù)據(jù)包）。這充分說明了UDP協(xié)議是面向非連接的協(xié)議，沒有建立連接的過程。正因?yàn)閁DP協(xié)議沒有連接的過程，所以它的通信效果高；但也正因?yàn)槿绱耍目煽啃圆蝗鏣CP協(xié)議高。QQ就使用UDP發(fā)消息，因此有時(shí)會出現(xiàn)收不到消息的情況。
tcp協(xié)議和udp協(xié)議的差別
TCP UDP
是否連接 面向連接 面向非連接
傳輸可靠性 可靠 不可靠
應(yīng)用場合 傳輸大量數(shù)據(jù) 少量數(shù)據(jù)
速度 慢 快
