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: user@email.com
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