1. 程式人生 > >HTTP詳解 1 -工作原理

HTTP詳解 1 -工作原理

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!

               

     

1. HTTP簡介

         HTTP協議(HyperText Transfer Protocol,超文字傳輸協議)是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效,使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件,還確定傳輸文件中的哪一部分,以及哪部分內容首先顯示(如文字先於圖形)等。

         在瞭解HTTP如何工作之前,我們先了解計算機之間的通訊。

2. 計算機相互之間的通訊

        網際網路的關鍵技術就是TCP/IP協議。兩臺計算機之間的通訊是通過TCP/IP協議在因特網上進行的。實際上這個是兩個協議:

        TCP : Transmission Control Protocol 傳輸控制協議和IP: Internet Protocol  網際協議。

        IP:計算機之間的通訊

        IP協議是計算機用來相互識別的通訊的一種機制,每臺計算機都有一個IP.用來在internet上標識這臺計算機。  IP 負責在因特網上傳送和接收資料包。通過 IP,訊息(或者其他資料)被分割為小的獨立的包,並通過因特網在計算機之間傳送。IP 負責將每個包路由至它的目的地。

        IP協議僅僅是允許計算機相互發訊息,但它並不檢查訊息是否以傳送的次序到達而且沒有損壞(只檢查關鍵的頭資料)。為了提供訊息檢驗功能,直接在IP協議上設計了傳輸控制協議TCP.

        

       TCP : 應用程式之間的通訊

       TCP確保資料包以正確的次序到達,並且嘗試確認資料包的內容沒有改變。TCP在IP地址之上引埠(port),它允許計算機通過網路提供各種服務。一些埠號為不同的服務保留,而且這些埠號是眾所周知。

       服務或者守護程序:在提供服務的機器上,有程式監聽特定埠上的通訊流。例如大多數電子郵件通訊流出現在埠25上,用於wwww的HTTP通訊流出現在80埠上。

       當應用程式希望通過 TCP 與另一個應用程式通訊時,它會發送一個通訊請求。這個請求必須被送到一個確切的地址。在雙方“握手”之後,TCP 將在兩個應用程式之間建立一個全雙工 (full-duplex) 的通訊,佔用兩個計算機之間整個的通訊線路。TCP 用於從應用程式到網路的資料傳輸控制。TCP 負責在資料傳送之前將它們分割為 IP 包,然後在它們到達的時候將它們重組。

       TCP/IP 就是TCP 和 IP 兩個協議在一起協同工作,有上下層次的關係。

       TCP 負責應用軟體(比如你的瀏覽器)和網路軟體之間的通訊。IP 負責計算機之間的通訊。TCP 負責將資料分割並裝入 IP 包,IP 負責將包傳送至接受者,傳輸過程要經IP路由器負責根據通訊量、網路中的錯誤或者其他引數來進行正確地定址,然後在它們到達的時候重新組合它們。

 

3. HTTP協議所在的協議層

      HTTP是基於TCP協議之上的。在TCP/IP協議參考模型的各層對應的協議如下圖,其中HTTP是應用層的協議。

     


 

4. HTTP請求響應模型   

       HTTP由請求和響應構成,是一個標準的客戶端伺服器模型(B/S)。HTTP協議永遠都是客戶端發起請求,伺服器回送響應。見下圖:

   

 

       HTTP是一個無狀態的協議。無狀態是指客戶機(Web瀏覽器)和伺服器之間不需要建立持久的連線,這意味著當一個客戶端向伺服器端發出請求,然後伺服器返回響應(response),連線就被關閉了,在伺服器端不保留連線的有關資訊.HTTP遵循請求(Request)/應答(Response)模型。客戶機(瀏覽器)向伺服器傳送請求,伺服器處理請求並返回適當的應答。所有HTTP連線都被構造成一套請求和應答。

 

5. HTTP工作過程      

     一次HTTP操作稱為一個事務,其工作整個過程如下:

     1 ) 、地址解析,

     如用客戶端瀏覽器請求這個頁面:http://localhost.com:8080/index.htm

     從中分解出協議名、主機名、埠、物件路徑等部分,對於我們的這個地址,解析得到的結果如下:
     協議名:http
     主機名:localhost.com
     埠:8080
     物件路徑:/index.htm

      在這一步,需要域名系統DNS解析域名localhost.com,得主機的IP地址。


    2)、封裝HTTP請求資料包

     把以上部分結合本機自己的資訊,封裝成一個HTTP請求資料包


     3)封裝成TCP包,建立TCP連線TCP的三次握手

       在HTTP工作開始之前,客戶機(Web瀏覽器)首先要通過網路與伺服器建立連線,該連線是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網路。HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之後才能,才能進行更層協議的連線,因此,首先要建立TCP連線,一般TCP連線的埠號是80。這裡是8080埠

     4)客戶機發送請求命令

       建立連線後,客戶機發送一個請求給伺服器,請求方式的格式為:統一資源識別符號(URL)、協議版本號,後邊是MIME資訊包括請求修飾符、客戶機資訊和可內容。

     5)伺服器響應

     伺服器接到請求後,給予相應的響應資訊,其格式為一個狀態行,包括資訊的協議版本號、一個成功或錯誤的程式碼,後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。

        實體訊息是伺服器向瀏覽器傳送頭資訊後,它會發送一個空白行來表示頭資訊的傳送到此為結束,接著,它就以Content-Type應答頭資訊所描述的格式傳送使用者所請求的實際資料

     6)伺服器關閉TCP連線

     一般情況下,一旦Web伺服器向瀏覽器傳送了請求資料,它就要關閉TCP連線,然後如果瀏覽器或者伺服器在其頭資訊加入了這行程式碼

    Connection:keep-alive

   TCP連線在傳送後將仍然保持開啟狀態,於是,瀏覽器可以繼續通過相同的連線傳送請求。保持連線節省了為每個請求建立新連線所需的時間,還節約了網路頻寬。

 

 

6. HTTP協議棧中各層資料流      

             首先我們看看客戶端請求的時候,資料在各層協議的資料組織如下圖:

        

            而伺服器解析客戶機請求就是反向操作的過程,如下圖:

          
       

       客戶機發起一次請求的時候:

       客戶機會將請求封裝成http資料包-->封裝成Tcp資料包-->封裝成Ip資料包--->封裝成資料幀--->硬體將幀資料轉換成bit流(二進位制資料)-->最後通過物理硬體(網絡卡晶片)傳送到指定地點。

       伺服器硬體首先收到bit流....... 然後轉換成ip資料包。於是通過ip協議解析Ip資料包,然後又發現裡面是tcp資料包,就通過tcp協議解析Tcp資料包,接著發現是http資料包通過http協議再解析http資料包得到資料。



6. HTTPS實現原理    

             HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL。其所用的埠號是443。

         SSL:安全套接層,是netscape公司設計的主要用於web的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。通過證書認證來確保客戶端和網站伺服器之間的通訊資料是加密安全的。

      有兩種基本的加解密演算法型別:

      1)對稱加密(symmetrcic encryption):金鑰只有一個,加密解密為同一個密碼,且加解密速度快,典型的對稱加密演算法有DES、AES,RC5,3DES等;

       對稱加密主要問題是共享祕鑰,除你的計算機(客戶端)知道另外一臺計算機(伺服器)的私鑰祕鑰,否則無法對通訊流進行加密解密。解決這個問題的方案非對稱祕鑰。

      2)非對稱加密:使用兩個祕鑰:公共祕鑰和私有祕鑰。私有祕鑰由一方密碼儲存(一般是伺服器儲存),另一方任何人都可以獲得公共祕鑰。

      這種金鑰成對出現(且根據公鑰無法推知私鑰,根據私鑰也無法推知公鑰),加密解密使用不同金鑰(公鑰加密需要私鑰解密,私鑰加密需要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密演算法有RSA、DSA等。

   下面看一下https的通訊過程:

   

        過程大致如下:         1) SSL客戶端通過TCP和伺服器建立連線之後(443埠),並且在一般的tcp連線協商(握手)過程中請求證書。               即客戶端發出一個訊息給伺服器,這個訊息裡面包含了自己可實現的演算法列表和其它一些需要的訊息,SSL的伺服器端會迴應一個數據包,這裡面確定了這次通訊所需要的演算法,然後伺服器向客戶端返回證書。(證書裡面包含了伺服器資訊:域名。申請證書的公司,公共祕鑰)。                         2)Client在收到伺服器返回的證書後,判斷簽發這個證書的公共簽發機構,並使用這個機構的公共祕鑰確認簽名是否有效,客戶端還會確保證書中列出的域名就是它正在連線的域名。        3)  如果確認證書有效,那麼生成對稱祕鑰並使用伺服器的公共祕鑰進行加密。然後傳送給伺服器,伺服器使用它的私鑰對它進行解密,這樣兩臺計算機可以開始進行對稱加密進行通訊。

https通訊的優點:

1)客戶端產生的金鑰只有客戶端和伺服器端能得到;

2)加密的資料只有客戶端和伺服器端才能得到明文;

3)客戶端到服務端的通訊是安全的。




7. HTTP各種長度限制   


1. URL長度限制

在Http1.1協議中並沒有提出針對URL的長度進行限制,RFC協議裡面是這樣描述的,HTTP協議並不對URI的長度做任何的限制,伺服器端必須能夠處理任何它們所提供服務多能接受的URI,並且能夠處理無限長度的URI,如果伺服器不能處理過長的URI,那麼應該返回414狀態碼。     雖然Http協議規定了,但是Web伺服器和瀏覽器對URI都有自己的長度限制。
伺服器的限制:我接觸的最多的伺服器型別就是Nginx和Tomcat,對於url的長度限制,它們都是通過控制http請求頭的長度來進行限制的,nginx的配置引數為large_client_header_buffers,tomcat的請求配置引數為maxHttpHeaderSize,都是可以自己去進行設定。
瀏覽器的限制:每種瀏覽器也會對url的長度有所限制,下面是幾種常見瀏覽器的url長度限制:(單位:字元) IE : 2803 Firefox:65536 Chrome:8182 Safari:80000 Opera:190000
對於get請求,在url的長度限制範圍之內,請求的引數個數沒有限制。

2. Post資料的長度限制

Post資料的長度限制與url長度限制類似,也是在Http協議中沒有規定長度限制,長度限制可以在伺服器端配置最大http請求頭長度的方式來實現。

3. Cookie的長度限制

Cookie的長度限制分這麼幾個方面來總結。
(1) 瀏覽器所允許的每個域下的最大cookie數目,沒有去自己測試,從網上找到的資料大概是這麼個情況 IE :原先為20個,後來升級為50個 Firefox: 50個 Opera:30個 Chrome:180個 Safari:無限制
當Cookie數超過限制數時瀏覽器的行為:IE和Opera會採用LRU演算法將老的不常使用的Cookie清除掉,Firefox的行為是隨機踢出某些Cookie的值。當然無論怎樣的策略,還是儘量不要讓Cookie數目超過瀏覽器所允許的範圍。
(2) 瀏覽器所允許的每個Cookie的最大長度
Firefox和Safari:4079位元組 Opera:4096位元組 IE:4095位元組
(3) 伺服器中Http請求頭長度的限制。Cookie會被附在每次http請求頭中傳遞給伺服器,因此還會受到伺服器請求頭長度的影響。

4. Html5 LocalStorage

Html5提供了本地儲存機制來供Web應用在客戶端儲存資料,儘管這個並不屬於Http協議的一部分,但是隨著Html5的流行,我們可能需要越來越多使用LocalStorage,甚至當它普及的時候跟它打交道就會同今天我們跟Cookie打交道一樣多。
對於LocalStorage的長度限制,同Cookie的限制類似,也是瀏覽器針對域來限制,只不過cookie限制的是個數,LocalStorage限制的是長度:
Firefox\Chrome\Opera都是允許每個域的最大長度為5MB 但是這次IE比較大方,允許的最大長度是10MB

 

           

給我老師的人工智慧教程打call!http://blog.csdn.net/jiangjunshow

這裡寫圖片描述