TCP/IP協議、UDP協議、 Http協議

 

開放式系統互聯通信參考模型（Open System Interconnection Reference Model，縮寫為 OSI），簡稱為OSI模型（OSI model），一種概念模型，由國際標准化組織提出，一個試圖使各種計算機在世界范圍內互連為網絡的標准框架。定義於ISO/IEC 7498-1。

OSI七層網絡模型(從下往上)：

  

第1層 物理層

物理層（Physical Layer）在局部局域網上傳送數據幀（data frame），它負責管理計算機通信設備和網絡媒體之間的互通。包括了針腳、電壓、線纜規范、集線器、中繼器、網卡、主機接口卡等。

 

第2層 數據鏈路層

數據鏈路層（Data Link Layer）負責網絡尋址、錯誤偵測和改錯。當表頭和表尾被加至數據包時，會形成幀。數據鏈表頭（DLH）是包含了物理地址和錯誤偵測及改錯的方法。數據鏈表尾（DLT）是一串指示數據包末端的字符串。例如以太網、無線局域網（Wi-Fi）和通用分組無線服務（GPRS）等。

分為兩個子層：邏輯鏈路控制（logical link control，LLC）子層和介質訪問控制（media access control，MAC）子層。

 

第3層 網絡層

 網絡層（Network Layer）決定數據的路徑選擇和轉寄，將網絡表頭（NH）加至數據包，以形成分組。網絡表頭包含了網絡數據。例如:互聯網協議（IP）等。

 

第4層 傳輸層

傳輸層（Transport Layer）把傳輸表頭（TH）加至數據以形成數據報。傳輸表頭包含了所使用的協議等發送信息。例如:傳輸控制協議（TCP）等。

 

第5層 會話層

會話層（Session Layer）負責在數據傳輸中設置和維護計算機網絡中兩台計算機之間的通信連接。

 

第6層 表達層

 表達層（Presentation Layer）把數據轉換為能與接收者的系統格式兼容並適合傳輸的格式。

 

第7層 應用層

應用層（Application Layer）提供為應用軟件而設的接口，以設置與另一應用軟件之間的通信。例如: HTTP，HTTPS，FTP，TELNET，SSH，SMTP，POP3.HTML.等。

 

    

 

                                                       

 

 

 

TCP/IP四層模型

 

 

TCP/IP是一組協議的代名詞，它還包括許多協議，組成了TCP/IP協議簇。 TCP/IP協議簇分為四層，IP位於協議簇的第二層(對應OSI的第三層)，TCP位於協議簇的第三層 (對應OSI的第四層)。TCP/IP通訊協議采用了4層的層級結構，每一層都呼叫它的下一層所提供 的網絡來完成自己的需求。這4層分別為：

 

應用層：應用程序間溝通的層，如簡單電子郵件傳輸（SMTP）、文件傳輸協議（FTP）、 網絡遠程訪問協議（Telnet）等。

傳輸層：在此層中，它提供了節點間的數據傳送服務，如傳輸控制協議（TCP）、 用戶數據報協議（UDP）等，TCP和UDP給數據包加入傳輸數據並把它傳輸到下一層中， 這一層負責傳送數據，並且確定數據已被送達並接收。

網絡互連層：負責提供基本的數據封包傳送功能，讓每一塊數據包都能夠到達目 的主機（但不檢查是否被正確接收），如網際協議（IP）。

主機到網絡層：對實際的網絡媒體的管理，定義如何使用實際網絡 （如Ethernet、Serial Line等）來傳送數據。

 

 

TCP/UDP區別講解

1）IP地址

 

 

 DNS（Domain Name System）域名系統是互聯網的一項服務。它作為將域名和IP地址相互映射的一個分布式，能夠使人更方便地訪問互聯網。DNS使用TCO和UDP端口53。當前，對於每一級域名長度的限制是63個字符，域名總長度則不能超過253個字符。

為什么要有DNS呢，IP地址（一長串數字）是給計算機使用的，人腦存儲的記憶比數據庫差太多。舉個例子，電話簿，是記名字方便，還是記號碼方便，答案顯然易見。

當你在電腦輸入https://www.google.com/，然后敲回車。電腦會根據你輸入的域名解析IP。

1.如果你的電腦配置了Host文件，電腦會優先查詢Host文件是否有對應的記錄，如果有，直接拿到該記錄的IP就結束。

2.如果Hsot文件沒有該記錄，電腦會看是否設置域名服務器。

2.1如果沒有設置的話，瀏覽器會直接報錯，域名無法解析。

2.2如果設置了，電腦會向該域名服務器發送域名查詢的請求，等待域名服務器的響應。

2.2.1如果無回應，域名還是無法解析。

2.2.2如果回應了，可以根據根據域名服務器的應答信息，得到該ip地址。

 

 

2）端口

1. 用於區分不同的應用程序

2. 端口號的范圍為0-65535，其中0-1023未系統的保留端口，我們的程序盡可能別使用這些端口！

3. IP地址和端口號組成了Socket，Socket是網絡運行程序間雙向通信鏈路的終結點， 是TCP和UDP的基礎！

4. 常用協議使用的端口：HTTP:80，FTP：21，TELNET：23

 

 

3）TCP協議與UDP協議的比較：

 

TCP協議流程詳解:

首先TCP/IP是一個協議簇，里面包括很多協議的。UDP只是其中的一個。之所以命名為TCP/IP協議， 因為TCP,IP協議是兩個很重要的協議，就用它兩命名了。

下面我們來講解TCP協議和UDP協議的區別：

TCP（Transmission Control Protocol，傳輸控制協議）是面向連接的協議，即在收發數據錢 ，都需要與對面建立可靠的鏈接，TCP的三次握手以及TCP的四次揮手！

 

TCP的6種標志位的分別代表：

SYN(synchronous建立聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼) (ack)

 

各個狀態的意義如下：
LISTEN - 偵聽來自遠方TCP端口的連接請求；
SYN-SENT -在發送連接請求后等待匹配的連接請求；
SYN-RECEIVED - 在收到和發送一個連接請求后等待對連接請求的確認；
ESTABLISHED- 代表一個打開的連接，數據可以傳送給用戶；
FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認；
FIN-WAIT-2 - 從遠程TCP等待連接中斷請求；
CLOSE-WAIT - 等待從本地用戶發來的連接中斷請求；
CLOSING -等待遠程TCP對連接中斷的確認；
LAST-ACK - 等待原來發向遠程TCP的連接中斷請求的確認；
TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認；
CLOSED - 沒有任何連接狀態；

 

 

三次握手： 建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立， 在Socket編程中，這一過程由客戶端執行connect來觸發，具體流程圖如下：

 

• 第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，並將該數據包發送給Server， Client進入SYN_SENT狀態，等待Server確認。
• 第二次握手：Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位 SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求 ，Server進入SYN_RCVD狀態。
• 第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK 置為1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則 連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client與Server之間可以 開始傳輸數據了。

 

 

四次揮手： 終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。 在Socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，具體流程圖如下：

 

• 第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入 FIN_WAIT_1狀態
• 第二次揮手：Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同， 一個FIN占用一個序號），Server進入CLOSE_WAIT狀態。
• 第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK 狀態。
• 第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。 另外也可能是同時發起主動關閉的情況：

 

另外還可能有一個常見的問題就是：為什么建立連接是三次握手，而關閉連接卻是四次揮手呢？ 答：因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里 發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還 能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些 數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會 分開發送。

 

UDP協議詳解：

UDP(User Datagram Protocol)用戶數據報協議，非連接的協議，傳輸數據之前源端和終端不 建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並盡可能快地把它扔到網絡上。 在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬 的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。 相比TCP就是無需建立鏈接，結構簡單，無法保證正確性，容易丟包。

 

 

Http協議

 

Http(超文本傳輸協議)是用於傳輸諸如HTML的超媒體文檔的應用層協議。它被設計用於Web瀏覽器和Web服務器之間的通信，但它也可以用於其他目的。 HTTP遵循經典的客戶端-服務端模型，客戶端打開一個連接以發出請求，然后等待它收到服務器端響應。HTTP是無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。

Http1.0協議，客戶端與web服務器建立連接后，只能獲得一個web資源！

Http1.1協議，允許客戶端與web服務器建立連接后，在一個連接上獲取多個web資源！

前面講過了三次握手，再看一下Http操作的一個流程了：

• 用戶點擊瀏覽器上的url(超鏈接)，Web瀏覽器與Web服務器建立連接
• 建立連接后，客戶端發送請求給服務器，請求的格式為: 統一資源標識符(URL)+協議版本號(一般是1.1)+MIME信息(多個消息頭)+一個空行
• 服務端收到請求后，給予相應的返回信息，返回格式為: 協議版本號 + 狀態行(處理結果) + 多個信息頭 + 空行 + 實體內容(比如返回的HTML)
• 客戶端接收服務端返回信息，通過瀏覽器顯示出來，然后與服務端斷開連接；當然如果中途 某步發生錯誤的話，錯誤信息會返回到客戶端，並顯示，比如：經典的404錯誤！

 

Http的幾種請求方式

實際開發中我們用得較多的方式是Get和Post，但是實際開發可能還會用到其他請求方式。

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

 

Get和Post的對比

Get產生一個TCP數據包；Post產生兩個TCP數據包。
對於GET方式的請求，瀏覽器會把http header和data一並發送出去，服務器響應200（返回數據）；
對於POST，瀏覽器先發送header，服務器響應100（continue），然后再發送data，服務器響應200（返回數據）；

 

Http狀態碼合集

當然，這些狀態碼只是要給參考，實際上決定權在服務器端(后台的)手上，一種方案是請求后， 服務器返回給我們的是狀態，或者另一種，在應用不用弄多語言版本的時候最好用，直接返回 一串結果信息的Json給我們，我們直接顯示就好，這樣可以偷懶不少！下面列下狀態碼合集，參考 下就好：

• 100~199 : 成功接受請求，客戶端需提交下一次請求才能完成整個處理過程
• 200: OK，客戶端請求成功
• 300~399：請求資源已移到新的地址(302,307,304)
• 401：請求未授權，改狀態代碼需與WWW-Authenticate報頭域一起使用
• 403：Forbidden，服務器收到請求，但是拒絕提供服務
• 404：Not Found，請求資源不存在，這個就不用說啦
• 500：Internal Server Error，服務器發生不可預期的錯誤
• 503：Server Unavailable，服務器當前不能處理客戶端請求，一段時間后可能恢復正常

 

HTTP Request Header請求頭信息對照表:

Header	解釋	示例
Accept	指定客戶端能夠接收的內容類型	Accept: text/plain, text/html
Accept-Charset	瀏覽器可以接受的字符編碼集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。	Accept-Encoding: compress, gzip
Accept-Language	瀏覽器可接受的語言	Accept-Language: en,zh
Accept-Ranges	可以請求網頁實體的一個或者多個子范圍字段	Accept-Ranges: bytes
Authorization	HTTP授權的授權證書	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定請求和響應遵循的緩存機制	Cache-Control: no-cache
Connection	表示是否需要持久連接。（HTTP 1.1默認進行持久連接）	Connection: close
Cookie	HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。	Cookie: $Version=1; Skin=new;
Content-Length	請求的內容長度	Content-Length: 348
Content-Type	請求的與實體對應的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	請求發送的日期和時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	請求的特定的服務器行為	Expect: 100-continue
From	發出請求的用戶的Email	From: [e-mail]
Host	指定請求的服務器的域名和端口號	Host: www.zcmhi.com
If-Match	只有請求內容與實體相匹配才有效	If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since	如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變	If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range	如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也為Etag	If-Range: "737060cd8c284d8af7ad3082f209582d"
If-Unmodified-Since	只在實體在指定時間之后未被修改才請求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通過代理和網關傳送的時間	Max-Forwards: 10
Pragma	用來包含實現特定的指令	Pragma: no-cache
Proxy-Authorization	連接到代理的授權證書	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只請求實體的一部分，指定范圍	Range: bytes=500-999
Referer	先前網頁的地址，當前請求網頁緊隨其后,即來路	Referer: http://blog.csdn.net/coder_pig
TE	客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息	TE: trailers,deflate;q=0.5
Upgrade	向服務器指定某種傳輸協議以便服務器進行轉換（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的內容包含發出請求的用戶信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中間網關或代理服務器地址，通信協議	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	關於消息實體的警告信息	Warn: 199 Miscellaneous warning

 

 

 

HTTP Responses Header 響應頭信息對照表：

Header	解釋	示例
Accept-Ranges	表明服務器是否支持指定范圍請求及哪種類型的分段請求	Accept-Ranges: bytes
Age	從原始服務器到代理緩存形成的估算時間（以秒計，非負）	Age: 12
Allow	對某網絡資源的有效的請求行為，不允許則返回405	Allow: GET, HEAD
Cache-Control	告訴所有的緩存機制是否可以緩存及哪種類型	Cache-Control: no-cache
Content-Encoding	web服務器支持的返回內容壓縮編碼類型	Content-Encoding: gzip
Content-Language	響應體的語言	Content-Language: en,zh
Content-Length	響應體的長度	Content-Length: 348
Content-Location	請求資源可替代的備用的另一地址	Content-Location: /index.htm
Content-MD5	返回資源的MD5校驗值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整個返回體中本部分的字節位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回內容的MIME類型	Content-Type: text/html; charset=utf-8
Date	原始服務器消息發出的時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	請求變量的實體標簽的當前值	ETag: "737060cd8c284d8af7ad3082f209582d"
Expires	響應過期的日期和時間	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	請求資源的最后修改時間	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	用來重定向接收方到非請求URL的位置來完成請求或標識新的資源	Location: http://blog.csdn.net/coder_pig
Pragma	包括實現特定的指令，它可應用到響應鏈上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出認證方案和可應用到代理的該URL上的參數	Proxy-Authenticate: Basic