憶往昔,盡是悔恨淚.
在學校的時候學過,網(wǎng)絡七層,也知道tcp的三次握手.但因為根本沒用在實際開發(fā)中,所以逐漸淡忘.現(xiàn)在就再次理解下三個的區(qū)別與聯(lián)系.
正題
一、網(wǎng)絡分層
物理層屡拨、數(shù)據(jù)鏈路層只酥、網(wǎng)絡層、傳輸層呀狼、會話層裂允、表示層、應用層 七個層次
其中,底層三層:物理層哥艇、數(shù)據(jù)鏈路層绝编、網(wǎng)絡層 是網(wǎng)絡工程師研究的對象。而其它四層,是用戶面向和關心的問題.
HTTP 協(xié)議: 超文本傳輸協(xié)議貌踏，對應于應用層十饥，用于如何封裝數(shù)據(jù).
TCP/UDP 協(xié)議: 傳輸控制協(xié)議，對應于傳輸層祖乳，主要解決數(shù)據(jù)在網(wǎng)絡中的傳輸逗堵。
IP 協(xié)議: 對應于網(wǎng)絡層，同樣解決數(shù)據(jù)在網(wǎng)絡中的傳輸眷昆。
傳輸數(shù)據(jù)的時候只使用 TCP/IP 協(xié)議(傳輸層)蜒秤，如果沒有應用層來識別數(shù)據(jù)內(nèi)容，傳輸后的協(xié)議都是無用的亚斋。
應用層協(xié)議很多 FTP,HTTP,TELNET等作媚，可以自己定義應用層協(xié)議。
web 使用 HTTP 作傳輸層協(xié)議帅刊，以封裝 HTTP 文本信息纸泡，然后使用 TCP/IP 做傳輸層協(xié)議，將數(shù)據(jù)發(fā)送到網(wǎng)絡上赖瞒。
二女揭、HTTP 協(xié)議
http 為短連接：客戶端發(fā)送請求都需要服務器端回送響應.請求結束后蚤假，主動釋放鏈接，因此為短連接田绑。通常的做法是勤哗，不需要任何數(shù)據(jù)，也要保持每隔一段時間向服務器發(fā)送"保持連接"的請求掩驱。這樣可以保證客戶端在服務器端是"上線"狀態(tài)。
HTTP連接使用的是"請求-響應"方式冬竟，不僅在請求時建立連接欧穴，而且客戶端向服務器端請求后，服務器才返回數(shù)據(jù)泵殴。
三涮帘、 TCP和UDP的區(qū)別
TCP/IP 中有兩個具有代表意義的傳輸層協(xié)議, 它們分別是TCP和UDP.
- TCP: TCP是面向連接的, 可靠的流協(xié)議.
流就是指不間斷的數(shù)據(jù)結構, 你可以把它想象成排水管中的水流. 當應用程序采用TCP發(fā)送消息時, 雖然可以保證發(fā)送的順序, 但還是猶如沒有任何間隔的數(shù)據(jù)流發(fā)送給接受端.
TCP為提供可靠性傳輸, 實行
順序控制或重發(fā)控制機制. 此外還具有流控制(流量控制),擁塞控制,提高網(wǎng)絡利用率等眾多功能.
- UDP: 它是不具有可靠性的數(shù)據(jù)報協(xié)議. 細微的處理它會交給上層應用去完成.
在UDP的情況下, 雖然可以確保發(fā)送消息的大小, 卻不能保證消息一定會到達, 因此,應用有時會根據(jù)自己的需要進行重發(fā)處理.
可能有人會認為, 鑒于TCP是可靠的傳輸協(xié)議, 那么它就一定優(yōu)于UDP. 其實不然TCP與UDP的優(yōu)缺點無法簡單地,絕對地去做比較.那么, 對這兩種協(xié)議應該如何加以區(qū)分使用?
TCP 用于在傳輸層有必要實現(xiàn)可靠性的情況. 由于它是面向連接并具備順序控制, 重發(fā)控制等機制的, 所以它可以為應用提供可靠傳輸.
而在一方面, UDP主要用于那些對高速傳輸和實時性有較高要求的通信和廣播通信. 我們舉個通過IP電話進行通話的例子. 如果使用TCP, 數(shù)據(jù)在傳輸途中如果丟失會被重發(fā), 但這樣無法流程地傳輸通話人是聲音, 會導致無法進行正常交流. 而采用UDP, 它會不進行重發(fā)處理. 從而也就不會有聲音大幅度延遲到達的問題. 即使有部分數(shù)據(jù)丟失, 也只是會影響某一小部分通話,
因此, TCP和UDP應該根據(jù)應用的目的按需使用.
四、Socket 連接
要想明白 Socket笑诅，必須要理解 TCP 連接调缨。
TCP 三次握手：握手過程中并不傳輸數(shù)據(jù)，在握手后服務器與客戶端才開始傳輸數(shù)據(jù)吆你，理想狀態(tài)下弦叶，TCP 連接一旦建立，在通訊雙方中的任何一方主動斷開連接之前 TCP 連接會一直保持下去妇多。
Socket 是對 TCP/IP 協(xié)議的封裝伤哺，Socket 只是個接口不是協(xié)議，通過 Socket 我們才能使用 TCP/IP 協(xié)議者祖，除了 TCP立莉，也可以使用 UDP 協(xié)議來傳遞數(shù)據(jù)。
創(chuàng)建 Socket 連接的時候七问，可以指定傳輸層協(xié)議蜓耻，可以是 TCP 或者 UDP，當用 TCP 連接械巡，該Socket就是個TCP連接刹淌，反之。
Socket 原理
Socket 連接,至少需要一對套接字坟比，分為 clientSocket芦鳍，serverSocket 連接分為3個步驟:
(1) 服務器監(jiān)聽:服務器并不定位具體客戶端的套接字，而是時刻處于監(jiān)聽狀態(tài)葛账；
(2) 客戶端請求:客戶端的套接字要描述它要連接的服務器的套接字柠衅，提供地址和端口號，然后向服務器套接字提出連接請求籍琳；
(3) 連接確認:當服務器套接字收到客戶端套接字發(fā)來的請求后菲宴，就響應客戶端套接字的請求,并建立一個新的線程,把服務器端的套接字的描述發(fā)給客戶端贷祈。一旦客戶端確認了此描述，就正式建立連接喝峦。而服務器套接字繼續(xù)處于監(jiān)聽狀態(tài)势誊，繼續(xù)接收其他客戶端套接字的連接請求.
Socket為長連接：通常情況下Socket 連接就是 TCP 連接，因此 Socket 連接一旦建立,通訊雙方開始互發(fā)數(shù)據(jù)內(nèi)容谣蠢，直到雙方斷開連接粟耻。在實際應用中，由于網(wǎng)絡節(jié)點過多眉踱，在傳輸過程中挤忙，會被節(jié)點斷開連接，因此要通過輪詢高速網(wǎng)絡谈喳，該節(jié)點處于活躍狀態(tài)册烈。
很多情況下，都是需要服務器端向客戶端主動推送數(shù)據(jù)婿禽，保持客戶端與服務端的實時同步赏僧。
若雙方是 Socket 連接，可以由服務器直接向客戶端發(fā)送數(shù)據(jù)扭倾。
若雙方是 HTTP 連接淀零，則服務器需要等客戶端發(fā)送請求后，才能將數(shù)據(jù)回傳給客戶端吆录。
因此窑滞，客戶端定時向服務器端發(fā)送請求，不僅可以保持在線恢筝，同時也詢問服務器是否有新數(shù)據(jù)哀卫，如果有就將數(shù)據(jù)傳給客戶端。
TCP和HTTP的區(qū)別
TPC/IP協(xié)議是傳輸層協(xié)議撬槽，主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸此改，而HTTP是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)侄柔。關于TCP/IP和HTTP協(xié)議的關系共啃，網(wǎng)絡有一段比較容易理解的介紹：“我們在傳輸數(shù)據(jù)時，可以只使用（傳輸層）TCP/IP協(xié)議暂题，但是那樣的話移剪，如果沒有應用層，便無法識別數(shù)據(jù)內(nèi)容薪者，如果想要使傳輸?shù)臄?shù)據(jù)有意義纵苛，則必須使用到應用層協(xié)議，應用層協(xié)議有很多，比如HTTP攻人、FTP取试、TELNET等，也可以自己定義應用層協(xié)議怀吻。WEB使用HTTP協(xié)議作應用層協(xié)議瞬浓，以封裝HTTP 文本信息，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡上蓬坡≡趁蓿”
術語TCP/IP代表傳輸控制協(xié)議/網(wǎng)際協(xié)議，指的是一系列協(xié)議屑咳∑谈“IP”代表網(wǎng)際協(xié)議，TCP和UDP使用該協(xié)議從一個網(wǎng)絡傳送數(shù)據(jù)包到另一個網(wǎng)絡乔宿。把
IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口访雪。
TCP和UDP是高速公路上的“卡車”详瑞，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等臣缀。
你應該能理解坝橡，TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協(xié)議精置。雖然TCP和UDP都是用來傳輸其他協(xié)議的计寇，它們卻有一個顯著的不同：TCP提供有保證的數(shù)據(jù)傳輸，而UDP不提供脂倦。這意味著TCP有一個特殊的機制來確保數(shù)據(jù)安全的不出錯的從一個端點傳到另一個端點番宁，而UDP不提供任何這樣的保證。
HTTP(超文本傳輸協(xié)議)是利用TCP在兩臺電腦(通常是Web服務器和客戶端)之間傳輸信息的協(xié)議赖阻〉海客戶端使用Web瀏覽器發(fā)起HTTP請求給Web服務器，Web服務器發(fā)送被請求的信息給客戶端火欧。
五棋电、HTTP協(xié)議的幾個重要概念
1.連接(Connection)：一個傳輸層的實際環(huán)流，它是建立在兩個相互通訊的應用程序之間苇侵。
2.消息(Message)：HTTP通訊的基本單位赶盔，包括一個結構化的八元組序列并通過連接傳輸。
3.請求(Request)：一個從客戶端到服務器的請求信息包括應用于資源的方法榆浓、資源的標識符和協(xié)議的版本號
4.響應(Response)：一個從服務器返回的信息包括HTTP協(xié)議的版本號于未、請求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。
5.資源(Resource)：由URI標識的網(wǎng)絡數(shù)據(jù)對象或服務。
6.實體(Entity)：數(shù)據(jù)資源或來自服務資源的回映的一種特殊表示方法沉眶，它可能被包圍在一個請求或響應信息中打却。一個實體包括實體頭信息和實體的本身內(nèi)容。
7.客戶機(Client)：一個為發(fā)送請求目的而建立連接的應用程序谎倔。
8.用戶代理(Useragent)：初始化一個請求的客戶機柳击。它們是瀏覽器、編輯器或其它用戶工具片习。
9.服務器(Server)：一個接受連接并對請求返回信息的應用程序捌肴。
10.源服務器(Originserver)：是一個給定資源可以在其上駐留或被創(chuàng)建的服務器。
11.代理(Proxy)：一個中間程序藕咏，它可以充當一個服務器状知，也可以充當一個客戶機，為其它客戶機建立請求孽查。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務器中饥悴。一個代理在發(fā)送請求信息之前，必須解釋并且如果可能重寫它盲再。
代理經(jīng)常作為通過防火墻的客戶機端的門戶西设，代理還可以作為一個幫助應用來通過協(xié)議處理沒有被用戶代理完成的請求。
12.網(wǎng)關(Gateway)：一個作為其它服務器中間媒介的服務器答朋。與代理不同的是贷揽，網(wǎng)關接受請求就好象對被請求的資源來說它就是源服務器；發(fā)出請求的客戶機并沒有意識到它在同網(wǎng)關打交道梦碗。
網(wǎng)關經(jīng)常作為通過防火墻的服務器端的門戶禽绪，網(wǎng)關還可以作為一個協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源。
13.通道(Tunnel)：是作為兩個連接中繼的中介程序洪规。一旦激活印屁，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的淹冰。當被中繼的連接兩端關閉時库车，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經(jīng)常使用樱拴。
14.緩存(Cache)：反應信息的局域存儲柠衍。
發(fā)送請求
打開一個連接后，客戶機把請求消息送到服務器的停留端口上晶乔，完成提出請求動作珍坊。
HTTP/1.0 請求消息的格式為：
請求消息=請求行(通用信息|請求頭|實體頭)CRLF[實體內(nèi)容]
請求 行=方法 請求URL HTTP版本號 CRLF
方 法=GET|HEAD|POST|擴展方法
U R L=協(xié)議名稱+宿主名+目錄與文件名
請求行中的方法描述指定資源中應該執(zhí)行的動作，常用的方法有GET正罢、HEAD和POST阵漏。不同的請求對象對應GET的結果是不同的，對應關系如下：
對象 GET的結果
文件 文件的內(nèi)容
程序 該程序的執(zhí)行結果
數(shù)據(jù)庫查詢 查詢結果
HEAD??要求服務器查找某對象的元信息，而不是對象本身履怯。
POST??從客戶機向服務器傳送數(shù)據(jù)回还，在要求服務器和CGI做進一步處理時會用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容叹洲，讓CGI程序處理柠硕。
一個請求的例子為：
GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0 networking.zju.edu.cn/zju/index.htmHTTP/1.0 頭信息又稱為元信息，即信息的信息运提，利用元信息可以實現(xiàn)有條件的請求或應答蝗柔。
請求頭??告訴服務器怎樣解釋本次請求，主要包括用戶可以接受的數(shù)據(jù)類型民泵、壓縮方法和語言等癣丧。
實體頭??實體信息類型、長度栈妆、壓縮方法胁编、最后一次修改時間、數(shù)據(jù)有效期等鳞尔。
實體??請求或應答對象本身掏呼。
發(fā)送響應
服務器在處理完客戶的請求之后，要向客戶機發(fā)送響應消息铅檩。
HTTP/1.0的響應消息格式如下：
響應消息=狀態(tài)行(通用信息頭|響應頭|實體頭) CRLF 〔實體內(nèi)容〕
狀態(tài)行=HTTP版本號 狀態(tài)碼 原因敘述
狀態(tài)碼表示響應類型
1×× 保留
2×× 表示請求成功地接收
3×× 為完成請求客戶需進一步細化請求
4×× 客戶錯誤
5×× 服務器錯誤
響應頭的信息包括：服務程序名，通知客戶請求的URL需要<u>認證</u>莽鸿，請求的資源何時能使用昧旨。
關閉連接
客戶和服務器雙方都可以通過關閉套接字來結束TCP/IP對話
