TCP/IP協議,HTTP協議
阿新 • • 發佈：2019-01-11
1. 協議
a. TCP/IP整體構架概述
TCP/IP協議並不完全符合OSI的七層參考模型。傳統的開放式系統互連參考模型，是一種通訊協議的7層抽象的參考模型,其中每一層執行某一特定任務。該模型的目的是使各種硬體在相同的層次上相互通訊。這7層是:物理層、資料鏈路層、網路層、傳輸層、話路層、表示層和應用層。而TCP/IP通訊協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的網路來完成自己的需求。這4層分別為：
i. 應用層：應用程式間溝通的層，如超文字傳送協議（HTTP）、簡單電子郵件傳輸（SMTP）、檔案傳輸協議（FTP）、網路遠端訪問協議（Telnet）等。
ii. 傳輸層：在此層中，它提供了節點間的資料傳送服務，如傳輸控制協議（TCP）、使用者資料報協議（UDP）等，TCP和UDP給資料包加入傳輸資料並把它傳輸到下一層中，這一層負責傳送資料，並且確定資料已被送達並接收。
iii. 互連網路層：負責提供基本的資料封包傳送功能，讓每一塊資料包都能夠到達目的主機（但不檢查是否被正確接收），如網際協議（IP）。
iv. 網路介面層：對實際的網路媒體的管理，定義如何使用實際網路（如Ethernet、Serial Line等）來傳送資料。
b. HTTP協議介紹：
i. HTTP是一種超文字傳送協議（HyperText Transfer Protocol）,是一套計算機在網路中通訊的一種規則。在TCP/IP體系結構中，HTTP屬於應用層協議，位於TCP/IP協議的頂層
ii. HTTP是一種無狀態的的協議，意思是指 在Web 瀏覽器（客戶端）和 Web 伺服器之間不需要建立持久的連線。整個過程就是當一個客戶端向伺服器端傳送一個請求(request)，然後Web伺服器返回一個響應 (response),之後連線就關閉了，在服務端此時是沒有保留連線的資訊。
iii. HTTP 遵循 請求/響應(request/response) 模型的，所有的通訊互動都被構造在一套請求和響應模型中。
iv. 瀏覽WEB時，瀏覽器通過HTTP協議與WEB伺服器交換資訊，Web伺服器向Web瀏覽器返回的檔案都有與之相關的型別,這些資訊型別的格式由MIME定義。
c. 協議的java實現方式
不論是TCP/IP協議也好，還是HTTP協議也好，java都是通過套接字（java.net.Socket）來實現的，可以參考我的另一篇技術部落格：一個專案看java TCP/IP Socket程式設計(1.3版)
2. HTTP報文介面及客戶端和伺服器端互動原理
a. HTTP定義的事務處理由以下四步組成：
i. 建立連線：
例如我在瀏覽器裡輸入 http://cuishen.iteye.com，客戶端請求這個地址時即打開了web伺服器HTTP埠的一個套接字。因為在網路中間作為傳遞資料的實體介質就是網線，資料實質上是通過IO流進行輸出和輸入，這就不難理解我們為什麼在寫一個Servlet的時候要引用 import java.io.*; 的原因 ，包括我們在向客戶端回髮結果的時候要用到PrintWriter物件的println()方法。其實請求的這個地址還要加上埠號80，80可以不寫，是因為瀏覽器預設的埠號是80。
在Java底層程式碼中是這樣實現的，只不過它們已經幫我們做了。
Java程式碼
ii. 客戶端傳送HTTP請求報文（request）
一旦建立了TCP連線，Web瀏覽器就會向Web伺服器傳送請求命令,是一個ASCII文字請求行，後跟0個或多個HTTP頭標，一個空行和實現請求的任意資料。
即報文分四個部分：請求行，請求頭標，空行和請求資料
1）請求行
請求行由三個標記組成：請求方法、請求URL和HTTP版本，中間用空格分開
例如： GET cuishen.iteye.com/blog/242842 HTTP/1.1
HTTP規範定義了8種可能的請求方法：(最常見的就是 GET 和 POST 兩種方法)
GET -- 檢索URI中標識資源的一個簡單請求
HEAD -- 與GET方法相同，伺服器只返回狀態行和頭標，並不返回請求文件
POST -- 伺服器接受被寫入客戶端輸出流中的資料的請求
PUT -- 伺服器儲存請求資料作為指定URI新內容的請求
DELETE -- 伺服器刪除URI中命名的資源的請求
OPTIONS -- 關於伺服器支援的請求方法資訊的請求
TRACE -- Web伺服器反饋Http請求和其頭標的請求
CONNECT -- 已文件化但當前未實現的一個方法，預留做隧道處理
2）請求頭標
請求頭標：由key ：value 健值組成，每行一對。請求頭標用來通知伺服器有關客戶端的功能和標識。
HOST -- 請求的哪一個伺服器端地址，主地址，比如：我的技術blog：cuishen.iteye.com
User-Agent -- 使用者即客戶端可以使用的瀏覽器 ，如： Mozilla/4.0
Accept -- 即客戶端可以接受的MIME 型別列表，如image/gif、text/html、application/msword
Content-Length -- 只適用於POST請求，以位元組給出POST資料的尺寸
3）空行
傳送回車符和退行，通知伺服器以下不再有頭標。
4）請求資料
使用POST傳送資料，最常使用的是Content-Type和Content-Length頭標。
請求報文總結：
我們可以這樣寫出一個標準的 HTTP請求：
POST /blog/242842 HTTP1.1
HOST: cuishen.iteye.com/
User-Agent: Mozilla/4.0
Accpt: image/gif,text/html,application/pdf,image/png...
key=value&key=value&key=value...... (POST()請求的資料)
這上面的一個例子意思是：
我要去訪問的伺服器端的地址是cuishen.iteye.com/ 它下面的資源 /blog/242842
連起來就是： cuishen.iteye.com/blog/242842
這個頁面用的是 HTTP1.1 規範，我的瀏覽器版本是Mozilla/4.0
可以支援的MIME格式為 image/gif,text/html,application/pdf,image/png...等等
這個MIME格式我們在servlet中寫法是：response.setContentType("text/html;charset=gb2312");
或者在jsp中寫法是：<%@ page contentType="text/html;charset=gb2312"%>
或者在html中寫法是：<meta http-equiv="content-Type" content="text/html; charset=gb2312">
GET 和 POST 最直觀的區別就是：GET方法將資料的請求跟在了所請求的URL後面，也就是在請求行裡面我們是這麼樣來做的：
GET /blog/242842?key=value&key=value&key=value......HTTP1.1
實際上用 GET 是這樣傳遞資料的：
http://cuishen.iteye.com/?page=2......
iii.伺服器端響應請求生成結果並回發（response）
Web 伺服器解析請求，定位指定的資源 http://cuishen.iteye.com/blog/242842
1）根據請求時的 GET/POST 對應的用servlet裡的 doGet() / doPost()方法來處理（有可能是一些業務邏輯，也有可能是一些驗證等等，也有可能是一些資料查詢，提交等等）其有效的資料就來源於key=value&key=value&key=value......，以及其它的一些封裝在 request 物件中的資料資源。
2）處理請求之後，由 response 物件得到 java.io.PrintWriter 輸出流物件out，通過 out.println(); 將資料以指定的格式，如按照response.setcontentType("text/html;charset=gb2312");的格式輸出到輸出流。
它的響應報文與請求報文非常類似，其區別就在於：我們在請求階段的請求行被狀態行給替換了，再來看響應報文：
3）一個響應報文由四個部分組成：狀態行、響應頭標、空行、響應資料：
(a).狀態行：
狀態行由三個標記組成：HTTP版本、響應程式碼和響應描述。
HTTP1.1 --- 100 --- continue //繼續追加後繼內容
HTTP1.1 --- 200 --- OK //一切正常
HTTP1.1 --- 301 --- Moved Permanently //請求的文件在其它地方，會自動連線
HTTP1.1 --- 403 --- Forbidden //絕對拒絕你訪問這個資源，不管授權沒有
HTTP1.1 --- 400 --- Bad Request //客戶端請求中的不良語法
HTTP1.1 --- 404 --- Not Found //最常見，絕對是大名鼎鼎的找不到
HTTP響應碼：
1xx：提示性資訊，告訴客戶端應該對某些其它的動作作出響應
2xx：這些就代表了請求成功
3xx：重定向，為了完成請求，必須進一步執行的動作
4xx：客戶端錯誤
500-599: 伺服器端的錯誤
(b).響應頭標：像請求頭標一樣，它們指出伺服器的功能，標識出響應資料的細節。
Date: Sat, 31 Dec 2005 23:59:59 GMT --響應生成的日期和時間
ContentType: 'text/html;charset=gb2312'
Content-Length: 122 --響應中的位元組數，只在瀏覽器使用永久（Keep-alive）HTTP連線時需要。
(c).空行：最後一個響應頭標之後是一個空行，傳送回車符和退行，表明伺服器以下不再有頭標。
(d).響應資料：HTML文件和影象等，也就是HTML本身。out.println("<html>......");寫到客戶端。
Html程式碼
iv. 伺服器端關閉連線，客戶端解析回發響應報文，恢復頁面
1）瀏覽器先解析狀態行，檢視請求是否成功的狀態程式碼--HTTP響應碼：404 400 200 ....
2）解析每一個響應頭標，如：
ContentType: text/html;charset=gb2312
Content-Length: 122 --- 響應中的位元組數，只在瀏覽器使用永久（Keep-alive）HTTP連線時需要。
3）讀取響應資料HTML，根據標籤<html></html>中的內容恢復標準的HTML格式頁面或者其它。
4）一個HTML 文件可能包含其它的需要被載入的資源，瀏覽器會識別，並對這些資源再進行額外的請求，這個過程可以是迴圈的方式一直到所有的資料都按照響應頭標中規定的格式恢復到頁面中。
5）資料傳送完畢，伺服器端關閉連線，即無狀態協議。
3. 總結
a. TCP/IP整體構架概述
TCP/IP協議並不完全符合OSI的七層參考模型。傳統的開放式系統互連參考模型，是一種通訊協議的7層抽象的參考模型,其中每一層執行某一特定任務。該模型的目的是使各種硬體在相同的層次上相互通訊。這7層是:物理層、資料鏈路層、網路層、傳輸層、話路層、表示層和應用層。而TCP/IP通訊協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的網路來完成自己的需求。這4層分別為：
i. 應用層：應用程式間溝通的層，如超文字傳送協議（HTTP）、簡單電子郵件傳輸（SMTP）、檔案傳輸協議（FTP）、網路遠端訪問協議（Telnet）等。
ii. 傳輸層：在此層中，它提供了節點間的資料傳送服務，如傳輸控制協議（TCP）、使用者資料報協議（UDP）等，TCP和UDP給資料包加入傳輸資料並把它傳輸到下一層中，這一層負責傳送資料，並且確定資料已被送達並接收。
iii. 互連網路層：負責提供基本的資料封包傳送功能，讓每一塊資料包都能夠到達目的主機（但不檢查是否被正確接收），如網際協議（IP）。
iv. 網路介面層：對實際的網路媒體的管理，定義如何使用實際網路（如Ethernet、Serial Line等）來傳送資料。
b. HTTP協議介紹：
i. HTTP是一種超文字傳送協議（HyperText Transfer Protocol）,是一套計算機在網路中通訊的一種規則。在TCP/IP體系結構中，HTTP屬於應用層協議，位於TCP/IP協議的頂層
ii. HTTP是一種無狀態的的協議，意思是指 在Web 瀏覽器（客戶端）和 Web 伺服器之間不需要建立持久的連線。整個過程就是當一個客戶端向伺服器端傳送一個請求(request)，然後Web伺服器返回一個響應 (response),之後連線就關閉了，在服務端此時是沒有保留連線的資訊。
iii. HTTP 遵循 請求/響應(request/response) 模型的，所有的通訊互動都被構造在一套請求和響應模型中。
iv. 瀏覽WEB時，瀏覽器通過HTTP協議與WEB伺服器交換資訊，Web伺服器向Web瀏覽器返回的檔案都有與之相關的型別,這些資訊型別的格式由MIME定義。
c. 協議的java實現方式
不論是TCP/IP協議也好，還是HTTP協議也好，java都是通過套接字（java.net.Socket）來實現的，可以參考我的另一篇技術部落格：一個專案看java TCP/IP Socket程式設計(1.3版)
2. HTTP報文介面及客戶端和伺服器端互動原理
a. HTTP定義的事務處理由以下四步組成：
i. 建立連線：
例如我在瀏覽器裡輸入 http://cuishen.iteye.com，客戶端請求這個地址時即打開了web伺服器HTTP埠的一個套接字。因為在網路中間作為傳遞資料的實體介質就是網線，資料實質上是通過IO流進行輸出和輸入，這就不難理解我們為什麼在寫一個Servlet的時候要引用 import java.io.*; 的原因 ，包括我們在向客戶端回髮結果的時候要用到PrintWriter物件的println()方法。其實請求的這個地址還要加上埠號80，80可以不寫，是因為瀏覽器預設的埠號是80。
在Java底層程式碼中是這樣實現的，只不過它們已經幫我們做了。
Java程式碼
- Socket socket = new Socket("cuishen.iteye.com",80);
- InputStream in = socket.getInputStream();
- OutputStream out = socket.getOutputStream();
ii. 客戶端傳送HTTP請求報文（request）
一旦建立了TCP連線，Web瀏覽器就會向Web伺服器傳送請求命令,是一個ASCII文字請求行，後跟0個或多個HTTP頭標，一個空行和實現請求的任意資料。
即報文分四個部分：請求行，請求頭標，空行和請求資料
1）請求行
請求行由三個標記組成：請求方法、請求URL和HTTP版本，中間用空格分開
例如： GET cuishen.iteye.com/blog/242842 HTTP/1.1
HTTP規範定義了8種可能的請求方法：(最常見的就是 GET 和 POST 兩種方法)
GET -- 檢索URI中標識資源的一個簡單請求
HEAD -- 與GET方法相同，伺服器只返回狀態行和頭標，並不返回請求文件
POST -- 伺服器接受被寫入客戶端輸出流中的資料的請求
PUT -- 伺服器儲存請求資料作為指定URI新內容的請求
DELETE -- 伺服器刪除URI中命名的資源的請求
OPTIONS -- 關於伺服器支援的請求方法資訊的請求
TRACE -- Web伺服器反饋Http請求和其頭標的請求
CONNECT -- 已文件化但當前未實現的一個方法，預留做隧道處理
2）請求頭標
請求頭標：由key ：value 健值組成，每行一對。請求頭標用來通知伺服器有關客戶端的功能和標識。
HOST -- 請求的哪一個伺服器端地址，主地址，比如：我的技術blog：cuishen.iteye.com
User-Agent -- 使用者即客戶端可以使用的瀏覽器 ，如： Mozilla/4.0
Accept -- 即客戶端可以接受的MIME 型別列表，如image/gif、text/html、application/msword
Content-Length -- 只適用於POST請求，以位元組給出POST資料的尺寸
3）空行
傳送回車符和退行，通知伺服器以下不再有頭標。
4）請求資料
使用POST傳送資料，最常使用的是Content-Type和Content-Length頭標。
請求報文總結：
我們可以這樣寫出一個標準的 HTTP請求：
POST /blog/242842 HTTP1.1
HOST: cuishen.iteye.com/
User-Agent: Mozilla/4.0
Accpt: image/gif,text/html,application/pdf,image/png...
key=value&key=value&key=value...... (POST()請求的資料)
這上面的一個例子意思是：
我要去訪問的伺服器端的地址是cuishen.iteye.com/ 它下面的資源 /blog/242842
連起來就是： cuishen.iteye.com/blog/242842
這個頁面用的是 HTTP1.1 規範，我的瀏覽器版本是Mozilla/4.0
可以支援的MIME格式為 image/gif,text/html,application/pdf,image/png...等等
這個MIME格式我們在servlet中寫法是：response.setContentType("text/html;charset=gb2312");
或者在jsp中寫法是：<%@ page contentType="text/html;charset=gb2312"%>
或者在html中寫法是：<meta http-equiv="content-Type" content="text/html; charset=gb2312">
GET 和 POST 最直觀的區別就是：GET方法將資料的請求跟在了所請求的URL後面，也就是在請求行裡面我們是這麼樣來做的：
GET /blog/242842?key=value&key=value&key=value......HTTP1.1
實際上用 GET 是這樣傳遞資料的：
http://cuishen.iteye.com/?page=2......
iii.伺服器端響應請求生成結果並回發（response）
Web 伺服器解析請求，定位指定的資源 http://cuishen.iteye.com/blog/242842
1）根據請求時的 GET/POST 對應的用servlet裡的 doGet() / doPost()方法來處理（有可能是一些業務邏輯，也有可能是一些驗證等等，也有可能是一些資料查詢，提交等等）其有效的資料就來源於key=value&key=value&key=value......，以及其它的一些封裝在 request 物件中的資料資源。
2）處理請求之後，由 response 物件得到 java.io.PrintWriter 輸出流物件out，通過 out.println(); 將資料以指定的格式，如按照response.setcontentType("text/html;charset=gb2312");的格式輸出到輸出流。
它的響應報文與請求報文非常類似，其區別就在於：我們在請求階段的請求行被狀態行給替換了，再來看響應報文：
3）一個響應報文由四個部分組成：狀態行、響應頭標、空行、響應資料：
(a).狀態行：
狀態行由三個標記組成：HTTP版本、響應程式碼和響應描述。
HTTP1.1 --- 100 --- continue //繼續追加後繼內容
HTTP1.1 --- 200 --- OK //一切正常
HTTP1.1 --- 301 --- Moved Permanently //請求的文件在其它地方，會自動連線
HTTP1.1 --- 403 --- Forbidden //絕對拒絕你訪問這個資源，不管授權沒有
HTTP1.1 --- 400 --- Bad Request //客戶端請求中的不良語法
HTTP1.1 --- 404 --- Not Found //最常見，絕對是大名鼎鼎的找不到
HTTP響應碼：
1xx：提示性資訊，告訴客戶端應該對某些其它的動作作出響應
2xx：這些就代表了請求成功
3xx：重定向，為了完成請求，必須進一步執行的動作
4xx：客戶端錯誤
500-599: 伺服器端的錯誤
(b).響應頭標：像請求頭標一樣，它們指出伺服器的功能，標識出響應資料的細節。
Date: Sat, 31 Dec 2005 23:59:59 GMT --響應生成的日期和時間
ContentType: 'text/html;charset=gb2312'
Content-Length: 122 --響應中的位元組數，只在瀏覽器使用永久（Keep-alive）HTTP連線時需要。
(c).空行：最後一個響應頭標之後是一個空行，傳送回車符和退行，表明伺服器以下不再有頭標。
(d).響應資料：HTML文件和影象等，也就是HTML本身。out.println("<html>......");寫到客戶端。
Html程式碼
- <html>
- <head>
- <title>Welcome to cuishen's IT blog</title>
- </head>
- <body>
- <!-- 這裡是具體的內容，看到了這裡
- 相信大家對 HTTP 工作原理及客戶端與伺服器互動過程已經很清楚了吧
- -->
- </body>
- </html>
iv. 伺服器端關閉連線，客戶端解析回發響應報文，恢復頁面
1）瀏覽器先解析狀態行，檢視請求是否成功的狀態程式碼--HTTP響應碼：404 400 200 ....
2）解析每一個響應頭標，如：
ContentType: text/html;charset=gb2312
Content-Length: 122 --- 響應中的位元組數，只在瀏覽器使用永久（Keep-alive）HTTP連線時需要。
3）讀取響應資料HTML，根據標籤<html></html>中的內容恢復標準的HTML格式頁面或者其它。
4）一個HTML 文件可能包含其它的需要被載入的資源，瀏覽器會識別，並對這些資源再進行額外的請求，這個過程可以是迴圈的方式一直到所有的資料都按照響應頭標中規定的格式恢復到頁面中。
5）資料傳送完畢，伺服器端關閉連線，即無狀態協議。
3. 總結
不要被高深的名詞和理論嚇到，其實HTTP客戶端和伺服器端的互動原理很簡單：即先是瀏覽器和伺服器端建立Socket無狀態連線，也就是短連線，然後通過IO流進行報文資訊（這個報文是嚴格遵循HTTP報文介面的）的互動，最後會話結束後就關閉連線。對於這些底層的協議和報文的打包解包互動的實現，其實java和瀏覽器早都已經封裝好了，程式設計師只要專注於業務邏輯的實現就行啦，這些都不必關心！！