簡單的說呢，http協議是建立在tco/ip的基礎上的，想要了解http先了解一下tcp

TCPP協議族里重要的一點就是分層。TCPP協議族按層次分別分為以下4層:應用層、傳輸層、網絡層和數據鏈路層。
應用層
應用層決定了向用戶提供應用服務時通信的活動。TCPP協議族內預存了各類通用的應用服務。比如,FTP(FileTransfer Protocol,文件傳輸協議)和DNS( Domain Name System,域名系統)服務就是其中兩類HTP協議也處于該層。
傳輸層
傳輸層對上層應用層,提供處于網絡連接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不同的協議:TCP( Transmission ControlProtocol,傳輸控制協議)和UDP( User Data Protocol,用戶數據報協議)。

網絡層(又名網絡互連層)
網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了通過怎樣的路徑(所謂的傳輸路線)到達對方計算機,并把數據包傳送給對方。與對方計算機之間通過多臺計算機或網絡設備進行傳輸時,網絡層所起的作用就是在眾多的選項內選擇一條傳輸路線。
鏈路層(又名數據鏈路層,網絡接口層)
用來處理連接網絡的硬件部分。包括控制操作系統、硬件的設備驅動、NC( Network Interface Card,網絡適配器,即網卡),及光纖等物理可見部分(還包括連接器等一切傳輸媒介)。硬件上的范疇均在鏈路層的作用范圍之內。

與HTTP關系密切的協議:IP、TcP和DNS

IP( Internet Protoco)網際協議

按層次分,IP( Internet Protoco)網際協議位于網絡層。 internetProtocol這個名稱可能聽起來有點夸張,但事實正是如此,因為幾乎所有使用網絡的系統都會用到IP協議。TCPP協議族中的IP指的就是網際協議,協議名稱中占據了一半位置,其重要性可見一斑。可能有人會把“IP”和“P地址”搞混,“IP”其實是一種協議的名稱。IP協議的作用是把各種數據包傳送給對方。而要保證確實傳送到對方那里,則需要滿足各類條件。其中兩個重要的條件是IP地址和MAC地址( Media Access Control Address)IP地址指明了節點被分配到的地址,MAC地址是指網卡所屬的固定地址。IP地址可以和MAC地址進行配對。P地址可變換,但MAC地址基本上不會更改。

TCP協議

為了準確無誤地將數據送達目標處,TCP協議采用了三次握手( three-way handshaking)策略。用TCP協議把數據包送出去后,TCP不會對傳送后的情況置之不理,它一定會向對方確認是否成功送達。握手過程中使用了TCP的標志(fag)—SYN( synchronize)和ACKacknowledgement發送端首先發送一個帶SYN標志的數據包給對方。接收端收到后,回傳一個帶有 SYN/ACK標志的數據包以示傳達確認信息。最后,發送端再回傳一個帶ACK標志的數據包,代表“握手”結東若在握手過程中某個階段莫名中斷,TCP協議會再次以相同的順序發送相同的數據包

負責域名解析的DNs服務

DNS( Domain Name System)服務是和HTP協議一樣位于應用層的協議。它提供域名到IP地址之間的解析服務。計算機既可以被賦予IP地址,也可以被賦予主機名和域名。比如www.hackr.jpo用戶通常使用主機名或域名來訪問對方的計算機,而不是直接通過IP地址訪問。因為與IP地址的一組純數字相比,用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。但要讓計算機去理解名稱,相對而言就變得困難了。因為計算機更擅長處理一長串數字。為了解決上述的問題,DNS服務應運而生。DNS協議提供通過域名查找P地址,或逆向從IP地址反查域名的服務

進入正題

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的一般格式。

客戶端請求：

GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi

服務端響應:

HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain

HTTP 請求方法
根據 HTTP 標準，HTTP 請求可以使用多種請求方法。

HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序號方法描述

1	GET	請求指定的頁面信息，并返回實體主體。
2	HEAD	類似于 GET 請求，只不過返回的響應中沒有具體的內容，用于獲取報頭
3	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的頁面。
6	CONNECT	HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。
7	OPTIONS	允許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求，主要用于測試或診斷。
9	PATCH	是對 PUT 方法的補充，用來對已知資源進行局部更新 。

HTTP 響應頭信息
HTTP請求頭提供了關于請求，響應或者其他的發送實體的信息。

在本章節中我們將具體來介紹HTTP響應頭信息。

應答頭說明

Allow	服務器支持哪些請求方法（如GET、POST等）。
Content-Encoding	文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
Content-Length	表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStream，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容。
Content-Type	表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。
Date	當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。
Expires	應該在什么時候認為文檔已經過期，從而不再緩存它？
Last-Modified	文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。
Location	表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。
Refresh	表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader(“Refresh”, “5; URL=http://host/path”)讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的＜META HTTP-EQUIV=“Refresh” CONTENT=“5;URL=http://host/path"＞實現，這是因為，自動刷新或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是"N秒之后刷新本頁面或訪問指定頁面”，而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV=“Refresh” …＞。注意Refresh頭不屬于HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。
Server	服務器名字。Servlet一般不設置這個值，而是由Web服務器自己設置。
Set-Cookie	設置和頁面關聯的Cookie。Servlet不應使用response.setHeader(“Set-Cookie”, …)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。
WWW-Authenticate	客戶應該在Authorization頭中提供什么類型的授權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。注意Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問（例如.htaccess）。

HTTP狀態碼
HTTP狀態碼分類
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：

分類分類描述

1**	信息，服務器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收并處理
3**	重定向，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤，服務器在處理請求的過程中發生了錯誤

狀態碼狀態碼英文名稱中文描述

100	Continue	繼續。客戶端應繼續其請求
101	Switching	Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200	OK	請求成功。一般用于GET與POST請求
201	Created	已創建。成功請求并創建了新的資源
202	Accepted	已接受。已經接受請求，但未處理完成
203	Non-Authoritative Information	非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本
204	No Content	無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔
205	Reset Content	重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域
206	Partial Content	部分內容。服務器成功處理了部分GET請求
300	Multiple Choices	多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇
301	Moved Permanently	永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替
302	Found	臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
303	See Other	查看其它地址。與301類似。使用GET和POST請求查看
304	Not Modified	未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
305	Use Proxy	使用代理。所請求的資源必須通過代理訪問
306	Unused	已經被廢棄的HTTP狀態碼
307	Temporary Redirect	臨時重定向。與302類似。使用GET請求重定向
400	Bad Request	客戶端請求的語法錯誤，服務器無法理解
401	Unauthorized	請求要求用戶的身份認證
402	Payment Required	保留，將來使用
403	Forbidden	服務器理解請求客戶端的請求，但是拒絕執行此請求
404	Not Found	服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面
405	Method Not Allowed	客戶端請求中的方法被禁止
406	Not Acceptable	服務器無法根據客戶端請求的內容特性完成請求
407	Proxy Authentication Required	請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權
408	Request Time-out	服務器等待客戶端發送的請求時間過長，超時
409	Conflict	服務器完成客戶端的 PUT 請求時可能返回此代碼，服務器處理請求時發生了沖突
410	Gone	客戶端請求的資源已經不存在。410不同于404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411	Length Required	服務器無法處理客戶端發送的不帶Content-Length的請求信息
412	Precondition Failed	客戶端請求信息的先決條件錯誤
413	Request Entity Too Large	由于請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414	Request-URI Too Large	請求的URI過長（URI通常為網址），服務器無法處理
415	Unsupported Media Type	服務器無法處理請求附帶的媒體格式
416	Requested range not satisfiable	客戶端請求的范圍無效
417	Expectation Failed	服務器無法滿足Expect的請求頭信息
500	Internal Server Error	服務器內部錯誤，無法完成請求
501	Not Implemented	服務器不支持請求的功能，無法完成請求
502	Bad Gateway	作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應
503	Service Unavailable	由于超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504	Gateway Time-out	充當網關或代理的服務器，未及時從遠端服務器獲取請求
505	HTTP Version not supported	服務器不支持請求的HTTP協議的版本，無法完成處理

HTTP content-type

常見的媒體格式類型如下：

text/html ： HTML格式
text/plain ：純文本格式
text/xml ： XML格式
image/gif ：gif圖片格式
image/jpeg ：jpg圖片格式
image/png：png圖片格式
以application開頭的媒體格式類型：

application/xhtml+xml ：XHTML格式
application/xml： XML數據格式
application/atom+xml ：Atom XML聚合格式
application/json： JSON數據格式
application/pdf：pdf格式
application/msword ： Word文檔格式
application/octet-stream ： 二進制流數據（如常見的文件下載）
application/x-www-form-urlencoded ： 中默認的encType，form表單數據被編碼為key/value格式發送到服務器（表單默認的提交數據的格式）
另外一種常見的媒體格式是上傳文件之時使用的：

multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式

通信數據的轉發程序：代理、網關、隧道

代理
代理是一種有轉發功能的應用程序,它扮演了位于服務器和客戶端“中間人”的角色,接收由客戶端發送的請求并轉發給服務器,同時也接收服務器返回的響應并轉發給客戶端
網關
網關是轉發其他服務器通信數據的服務器,接收從客戶端發送來的請求時,它就像自己擁有資源的源服務器一樣對請求進行處理。有時客戶端可能都不會察覺,自己的通信目標是一個網關。
隧道
隧道是在相隔甚遠的客戶端和服務器兩者之間進行中轉,并保持雙方通信連接的應用程序

http的優缺點
1通信使用明文可能會被竊聽
2不驗證通信方的身份就可能遭遇偽裝
3無法證明報文完整性,可能已遭簑改

http+加密+認證+完整性保護=https
1htp加上加密處理和認證以及完整性保護后即是https
2https是身披ssl外殼的http
3相互交換密鑰的公開密鑰加密技術
4證明公開密鑰正確性的證書
5https的安全通信機制

奇奇怪怪的知識

總結

以上是生活随笔為你收集整理的http——基础知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。