TCP/IP、HTTP、socket 這些，你真的瞭解嗎？

前方高能！！！

因爲協議自己比較枯燥，本篇文章原理概述內容可能會比較多，若是感到不適請繞行(〃'▽'〃)

TCP/IP

概述

TCP/IP是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。

TCP/IP 定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標準。協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的協議來完成本身的需求。

通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求從新傳輸，直到全部數據安全正確地傳輸到目的地。而IP是給因特網的每一臺聯網設備規定一個地址。

TCP/IP協議不是單純的兩個協議，是一組不一樣層次上的多個協議的組合，常稱爲TCP/IP協議簇或者互聯網協議簇。

TCP/IP層次組合很難用OSI的七層模型來套用，它是OSI模型的濃縮，將原來的七層模型合併爲四層協議的體系結構，自頂向下分別是應用層、傳輸層、網絡層和網絡接口層，沒有OSI參考模型的會話層和表示層，通常認爲TCP/IP的會話和表示功能是在傳輸層或應用層上完成的。

下面的圖表試圖顯示不一樣的TCP/IP和其餘的協議在最初OSI模型中的位置：

層數	名稱	舉例
7	應用層	HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP
6	表示層	XDR、ASN.一、SMB、AFP、NCP
5	會話層	ASAP、TLS、SSH、ISO 8327 / CCITT X.22五、RPC、NetBIOS、ASP、Winsock、BSD sockets
4	傳輸層	TCP、UDP、RTP、SCTP、SPX、ATP、IL
3	網絡層	IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、 X.25
2	數據鏈路層	以太網、令牌環、HDLC、幀中繼、ISDN、ATM、IEEE 802.十一、FDDI、PPP
1	物理層	線路、無線電、光纖、信鴿

TCP/IP不是一個單獨的協議，而是一個協議簇，是一組不一樣層次上的多個協議的組合。上面給出了OSI與TCP/IP模型對比、TCP/IP不一樣層次的協議。

• 網絡接口層：有時也稱做數據鏈路層或鏈路層，一般包括操做系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一塊兒處理與電纜（或其餘任何傳輸媒介）的物理接口細節。在TCP/IP協議簇中，鏈路層的協議比較多，它決定了網絡形態，但不少都不是專門爲TCP/IP設計的。經常使用的鏈路層協議包括：以太網協議、PPP協議、幀中繼協議、ATM等。
• 網絡層：IP層有時也稱做互連網層，處理分組在網絡中的活動，在底層通訊網絡的基礎上，完成路由、尋徑功能，提供主機到主機的鏈接。IP是盡力傳送的、不可靠的協議。在TCP/IP協議簇中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互連網控制報文協議），ARP/RARP（地址解析/反向地址解析協議），以及IGMP協議（Internet組管理協議）。
• 傳輸層：主要爲兩臺主機上的應用程序提供端到端的通訊。在TCP/IP協議簇中，有兩個不一樣的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議），它們分別承載不一樣的應用。TCP協議提供可靠的服務，UDP協議提供不可靠可是高效的服務。
• 應用層：這一層負責具體的應用，好比HTTP訪問、FTP文件傳輸、SMTP/POP3郵件處理等等。幾乎各類不一樣的TCP/IP實現都會提供下面這些通用的應用程序：遠程登陸（Telnet）、文件傳輸協議（FTP）、簡單郵件傳輸協議（SMTP）、簡單網絡管理協議（SNMP）。

嚴格來說，分層模型的動機就是將各層的功能儘可能獨立，每層的功能對另外一層來講是透明的，只對通訊的另外一端負責，爲編程和診斷提供良好的層次隔離，然而實際狀況並不是如此，首先軟件編程上徹底按照分層模型來作編程效率會下降，與其分層，不如按功能實現來模塊化。其次，對於許多功能實現來講，必須實現兩層子間的交互，這又違背了當初的出發點，好比鏈路層在成幀時須要接收端的物理地址，該地址必須由網絡層處理ARP地址解析才行，簡單地將ARP放在那一層都有些牽強。因此說，分層模型對於理解網絡的抽象性是有益處的，它有助於指導網絡入門，但並非網絡的精髓，只有結合具體的系統分析纔有實際意義。

提到TCP就不得不說說TCP創建鏈接的三次握手了(～￣▽￣)～

TCP是面向鏈接的傳輸層協議，所謂面向鏈接就是在真正的數據傳輸開始前要完成鏈接創建的過程，不然不會進入真正的數據傳輸階段。

TCP的鏈接創建過程一般被稱爲三次握手（three-way handshake），過程以下：

• 請求端（一般稱爲客戶）發送一個SYN段指明客戶打算鏈接的服務器的端口，以及初始序號（ISN）。這個SYN段爲報文段1。
• 服務器發回包含服務器的初始序號的SYN報文段（報文段2）做爲應答。同時，將確認序號設置爲客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將佔用一個序號。
• 客戶必須將確認序號設置爲服務器的ISN加1以對服務器的SYN報文段進行確認（報文段3）。 這三個報文段完成鏈接的創建。

斷開鏈接：一個TCP鏈接是全雙工（即數據在兩個方向上能同時傳遞），所以每一個方向必須單獨進行關閉。當一方完成它的數據發送任務後就發送一個FIN來終止這個方向鏈接。當一端收到一個FIN，它必須通知應用層另外一端已經終止了那個方向的數據傳送。因此TCP終止鏈接的過程須要四個過程，稱之爲四次握手過程。

HTTP

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網經常使用的協議之一，HTTP協議是創建在TCP協議之上的一種應用。

HTTP鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

http的請求

http請求由三部分組成，分別是：請求行、消息報頭、請求正文

一、請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下:

Method Request-URI HTTP-Version CRLF

• Method表示請求方法
• Request-URI是一個統一資源標識符
• HTTP-Version表示請求的HTTP協議版本
• CRLF表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。

請求方法（全部方法全爲大寫）有多種：

• GET： 請求獲取Request-URI所標識的資源
• POST： 在Request-URI所標識的資源後附加新的數據
• HEAD： 請求獲取由Request-URI所標識的資源的響應消息報頭
• PUT： 請求服務器存儲一個資源，並用Request-URI做爲其標識
• DELETE： 請求服務器刪除Request-URI所標識的資源
• TRACE： 請求服務器回送收到的請求信息，主要用於測試或診斷
• CONNECT： 保留未來使用
• OPTIONS： 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

應用舉例：

GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源

eg：GET /form.html HTTP/1.1 (CRLF)

POST方法要求被請求服務器接受附在請求後面的數據，經常使用於提交表單。

eg：POST /reg.jsp HTTP/ (CRLF)

Accept:image/gif,image/x-xbit,... (CRLF)

...

HOST:www.guet.edu.cn (CRLF)

Content-Length:22 (CRLF)

Connection:Keep-Alive (CRLF)

Cache-Control:no-cache (CRLF)

(CRLF) //該CRLF表示消息報頭已經結束，在此以前爲消息報頭

user=jeffrey&pwd=1234 //此行如下爲提交的數據

HEAD方法與GET方法幾乎是同樣的，對於HEAD請求的迴應部分來講，它的HTTP頭部中包含的信息與經過GET請求所獲得的信息是相同的。利用這個方法，沒必要傳輸整個資源內容，就能夠獲得Request-URI所標識的資源的信息。該方法經常使用於測試超連接的有效性，是否能夠訪問，以及最近是否更新。

http的響應

在接收和解釋請求消息後，服務器返回一個HTTP響應消息。

HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文

一、狀態行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。

狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示信息--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操做

4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現

5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態代碼、狀態描述、說明：

200 OK //客戶端請求成功

400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用

403 Forbidden //服務器收到請求，可是拒絕提供服務

404 Not Found //請求資源不存在，eg：輸入了錯誤的URL

500 Internal Server Error //服務器發生不可預期的錯誤

503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

eg：HTTP/1.1 200 OK （CRLF）

http的報頭

HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。

HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。 每個報頭域都是由名字+「：」+空格+值 組成，消息報頭域的名字是大小寫無關的。

一、普通報頭

在普通報頭中，有少數報頭域用於全部的請求和響應消息，但並不用於被傳輸的實體，只用於傳輸的消息。

eg：

• Cache-Control 用於指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另外一個消息處理的緩存機制），HTTP1.0使用的相似的報頭域爲Pragma。
• 請求時的緩存指令包括：no-cache（用於指示請求或響應消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
• 響應時的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

eg：爲了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序能夠編寫以下：

response.sehHeader("Cache-Control","no-cache");

//response.setHeader("Pragma","no-cache");//做用至關於上述代碼，一般二者合用

這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cache

• Date普通報頭域表示消息產生的日期和時間
• Connection普通報頭域容許發送指定鏈接的選項。例如指定鏈接是連續，或者指定「close」選項，通知服務器，在響應完成後，關閉鏈接

二、請求報頭

請求報頭容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。

Accept

Accept請求報頭域用於指定客戶端接受哪些類型的信息。

eg：Accept：image/gif，代表客戶端但願接受GIF圖象格式的資源；

Accept：text/html，代表客戶端但願接受html文本。

Accept-Charset

• Accept-Charset請求報頭域用於指定客戶端接受的字符集。
• eg：Accept-Charset:iso-8859-1,gb2312.若是在請求消息中沒有設置這個域，缺省是任何字符集均可以接受。

Accept-Encoding

• Accept-Encoding請求報頭域相似於Accept，可是它是用於指定可接受的內容編碼。
• eg：Accept-Encoding:gzip.deflate.若是請求消息中沒有設置這個域服務器假定客戶端對各類內容編碼均可以接受。

Accept-Language

• Accept-Language請求報頭域相似於Accept，可是它是用於指定一種天然語言。
• eg：Accept-Language:zh-cn.若是請求消息中沒有設置這個報頭域，服務器假定客戶端對各類語言均可以接受。

Authorization

• Authorization請求報頭域主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

Host（發送請求時，該報頭域是必需的）

• Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的
• eg：

咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html 瀏覽器發送的請求消息中，就會包含Host請求報頭域： Host：www.guet.edu.cn 此處使用缺省端口號80，若指定了端口號，則變成：Host：www.guet.edu.cn:指定端口號

User-Agent

咱們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息。User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。不過，這個報頭域不是必需的，若是咱們本身編寫一個瀏覽器，不使用User-Agent請求報頭域，那麼服務器端就沒法得知咱們的信息了。

請求報頭舉例：

• GET /form.html HTTP/1.1 (CRLF)
• Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,/ (CRLF)
• Accept-Language:zh-cn (CRLF)
• Accept-Encoding:gzip,deflate (CRLF)
• If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
• If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
• User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
• Host:www.guet.edu.cn (CRLF)
• Connection:Keep-Alive (CRLF)
• (CRLF)

三、響應報頭

響應報頭容許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。

Location

• Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域經常使用在更換域名的時候。

Server

• Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的，例如：
• Server：Apache-Coyote/1.1
• WWW-Authenticate
• WWW-Authenticate響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
• eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //能夠看出服務器對請求資源採用的是基本驗證機制。

四、實體報頭

請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。實體報頭定義了關於實體正文（eg：有無實體正文）和請求所標識的資源的元信息。

• Content-Encoding

Content-Encoding實體報頭域被用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，於是要得到Content-Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content-Encoding：gzip

• Content-Language

Content-Language實體報頭域描述了資源所用的天然語言。沒有設置該域則認爲實體內容將提供給全部的語言閱讀 者。eg：Content-Language:da

• Content-Length

Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示。

• Content-Type

Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。

eg：Content-Type:text/html;charset=ISO-8859-1

Content-Type:text/html;charset=GB2312

• Last-Modified

Last-Modified實體報頭域用於指示資源的最後修改日期和時間。

• Expires

Expires實體報頭域給出響應過時的日期和時間。爲了讓代理服務器或瀏覽器在一段時間之後更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載，縮短響應時間和下降服務器負載)的頁面，咱們可使用Expires實體報頭域指定頁面過時的時間。

eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

socket

網絡上的兩個程序經過一個雙向的通訊鏈接實現數據的交換，這個鏈接的一端稱爲一個socket。

創建網絡通訊鏈接至少要一對端口號(socket)。socket本質是編程接口(API)，對TCP/IP的封裝，TCP/IP也要提供可供程序員作網絡開發所用的接口，這就是Socket編程接口；HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網絡通訊的能力。

套接字（socket）是通訊的基石，是支持TCP/IP協議的網絡通訊的基本操做單元。它是網絡通訊過程當中端點的抽象表示，包含進行網絡通訊必須的五種信息：鏈接使用的協議，本地主機的IP地址，本地進程的協議端口，遠地主機的IP地址，遠地進程的協議端口。

應用層經過傳輸層進行數據通訊時，TCP會遇到同時爲多個應用程序進程提供併發服務的問題。多個TCP鏈接或多個應用程序進程可能須要經過同一個 TCP協議端口傳輸數據。爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP／IP協議交互提供了套接字(Socket)接口。應 用層能夠和傳輸層經過Socket接口，區分來自不一樣應用程序進程或網絡鏈接的通訊，實現數據傳輸的併發服務。

創建socket鏈接

創建Socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket ，另外一個運行於服務器端，稱爲ServerSocket 。

套接字之間的鏈接過程分爲三個步驟：服務器監聽，客戶端請求，鏈接確認。

• 服務器監聽：服務器端套接字並不定位具體的客戶端套接字，而是處於等待鏈接的狀態，實時監控網絡狀態，等待客戶端的鏈接請求。

• 客戶端請求：指客戶端的套接字提出鏈接請求，要鏈接的目標是服務器端的套接字。爲此，客戶端的套接字必須首先描述它要鏈接的服務器的套接字，指出服務器端套接字的地址和端口號，而後就向服務器端套接字提出鏈接請求。

• 鏈接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的鏈接請求時，就響應客戶端套接字的請求，創建一個新的線程，把服務器端套接字的描 述發給客戶端，一旦客戶端確認了此描述，雙方就正式創建鏈接。而服務器端套接字繼續處於監聽狀態，繼續接收其餘客戶端套接字的鏈接請求。