GET和POST區別,http和https區別

標籤：

 

在開發中我們需要和後台進行資料的互動,但是咋樣互動呢?通常我們是通過網路請求進行資料的互動,一般使用http/https/tcp/udp等進行資料的互動.

http長串連和短串連

1. HTTP協議與TCP/IP協議的關係

　　HTTP的長串連和短串連本質上是TCP長串連和短串連。HTTP屬於應用程式層協議，在傳輸層使用TCP協議，在網路層使用IP協議。IP協議主要解決網路路由和定址問題，TCP協議主要解決如何在IP層之上可靠的傳遞資料包，使在網路上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有可靠，連線導向的特點。

 

2. 如何理解HTTP協議是無狀態的

　　HTTP協議是無狀態的，指的是協議對於交易處理沒有記憶能力，伺服器不知道用戶端是什麼狀態。也就是說，開啟一個伺服器上的網頁和你之前開啟這個伺服器上的網頁之間沒有任何聯絡。HTTP是一個無狀態的連線導向的協議，無狀態不代表HTTP不能保持TCP串連，更不能代表HTTP使用的是UDP協議（無串連）。

 

3. 什麼是長串連、短串連？

　　在HTTP/1.0中，預設使用的是短串連。也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次串連，但任務結束就中斷串連。如果用戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript檔案、影像檔、CSS檔案等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。

但從 HTTP/1.1起，預設使用長串連，用以保持串連特性。使用長串連的HTTP協議，會在回應標頭有加入這行代碼：

Connection:keep-alive

　　在使用長串連的情況下，當一個網頁開啟完成後，用戶端和伺服器之間用於傳輸HTTP資料的 TCP串連不會關閉，如果用戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的串連。Keep-Alive不會永久保持串連，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長串連要用戶端和服務端都支援長串連。

HTTP協議的長串連和短串連，實質上是TCP協議的長串連和短串連。

3.1 TCP串連

　　當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個串連，當讀寫操作完成後，雙方不再需要這個串連 時它們可以釋放這個串連，串連的建立是需要三向交握的，而釋放則需要4次握手，所以說每個串連的建立都是需要資源消耗和時間消耗的

經典的三向交握：

經典的四次握手關閉圖：

3.2 TCP短串連

　　我們類比一下TCP短串連的情況，client向server發起串連請求，server接到請求，然後雙方建立串連。client向server 發送訊息，server回應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。為什麼呢，一般的server不會回複完client後立即關閉串連的，當然不排除有特殊的情況。從上面的描述看，短串連一般只會在 client/server間傳遞一次讀寫操作

短串連的優點是：管理起來比較簡單，存在的串連都是有用的串連，不需要額外的控制手段

3.3 TCP長串連

　　接下來我們再類比一下長串連的情況，client向server發起串連，server接受client串連，雙方建立串連。Client與server完成一次讀寫之後，它們之間的串連並不會主動關閉，後續的讀寫操作會繼續使用這個串連。

首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為伺服器應用提供，伺服器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得伺服器上保留一個半開放的串連，而伺服器又在等待來自用戶端的資料，則伺服器將應遠等待用戶端的資料，保活功能就是試圖在服務 器端檢測到這種半開放的串連。

如果一個給定的串連在兩小時內沒有任何的動作，則伺服器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一：

1. 客戶主機依然正常運行，並從伺服器可達。客戶的TCP響應正常，而伺服器也知道對方是正常的，伺服器在兩小時後將保活定時器複位。
2. 客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後逾時。伺服器總共發送10個這樣的探測 ，每個間隔75秒。如果伺服器沒有收到一個響應，它就認為客戶主機已經關閉並終止串連。
3. 客戶主機崩潰並已經重新啟動。伺服器將收到一個對其保活探測的響應，這個響應是一個複位，使得伺服器終止這個串連。
4. 客戶機正常運行，但是伺服器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。

 

3.4 長串連短串連操作過程

短串連的操作步驟是：

建立串連——資料轉送——關閉串連...建立串連——資料轉送——關閉串連

長串連的操作步驟是：

建立串連——資料轉送...（保持串連）...資料轉送——關閉串連

 

4. 長串連和短串連的優點和缺點

　　由上可以看出，長串連可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長串連。不過這裡存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP串連的存活，屬於比較斯文的做法，遇到惡意的串連時，保活功能就不夠使了。在長連線應用程式情境下，client端一般不會主動關閉它們之間的串連，Client與server之間的串連如果一直不關閉的話，會存在一個問題，隨著用戶端串連越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的串連，這樣可 以避免一些惡意串連導致server端服務受損；如果條件再允許就可以以用戶端機器為顆粒度，限制每個用戶端的最大長串連數，這樣可以完全避免某個蛋疼的用戶端連累後端服務。

短串連對於伺服器來說管理較為簡單，存在的串連都是有用的串連，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和頻寬。

長串連和短串連的產生在於client和server採取的關閉策略，具體的應用情境採用具體的策略，沒有十全十美的選擇，只有合適的選擇。

 

 

5. 什麼時候用長串連，短串連？ 
 　　長串連多用於操作頻繁，點對點的通訊，而且串連數不能太多情況，。每個TCP串連都需要三步握手，這需要時間，如果每個操作都是先串連，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送資料包就OK了，不用建立TCP串連。例如：資料庫的串連用長串連， 如果用短串連頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。 
  
　　而像WEB網站的http服務一般都用短連結，因為長串連對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億用戶端的串連用短串連會更省一些資源，如果用長串連，而且同時有成千上萬的使用者，如果每個使用者都佔用一個串連的話，那可想而知吧。所以並發量大，但每個使用者無需頻繁操作情況下需用短連好。

 

6.HTTPS和HTTP

    http和https概述

   HTTP1.1（Hypertext Transfer Protocol Vertion 1.1）超文字傳輸通訊協定 (HTTP)-版本1.1
它是用來在Internet上傳送超文本的傳送協議。它是運行在TCP/IP協議族之上的HTTP應用協議，它可以使瀏覽器更加高效，使網路傳輸減少。任何伺服器除了包括HTML檔案以外，還有一個HTTP駐留程式，用於響應用使用者請求。您的瀏覽器是HTTP客戶，向伺服器發送請求，當瀏覽器中輸入了一個開始檔案或點擊了一個超級連結時，瀏覽器就向伺服器發送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程式接收到請求，在進行必要的操作後回送所要求的檔案。

 HTTPS（Secure Hypertext Transfer Protocol）安全超文字傳輸通訊協定 (HTTPS)
 它是由Netscape開發並內建於其瀏覽器中，用於對資料進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的完全通訊端層（SSL）     作為HTTP應用程式層的子層。（HTTPS使用連接埠443，而不是象HTTP那樣使用連接埠80來和TCP/IP進行通訊。）SSL使用40 位關鍵字作為RC4流密碼編譯演算法，這對於商業  資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證，如果需要的話使用者可以確認寄件者是誰。

    http和https區別

　　一、https協議需要到ca申請認證，一般免費認證很少，需要交費。 
　　二、http是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。 
　　三、http和https使用的是完全不同的串連方式，用的連接埠也不一樣，前者是80，後者是443。 
　　四、http的串連很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路通訊協定，比http協議安全。

7.POST和GET區別 

1. get是從伺服器上擷取資料，post是向伺服器傳送資料。
2. get是把參數資料隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個欄位一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內各個欄位與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。使用者看不到這個過程。
3. 對於get方式，伺服器端用Request.QueryString擷取變數的值，對於post方式，伺服器端用Request.Form擷取提交的資料。
4. get傳送的資料量較小，不能大於2KB。post傳送的資料量較大，一般被預設為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，post安全性較高。但是執行效率卻比Post方法好。 

建議：
1、get方式的安全性較Post方式要差些，包含機密資訊的話，建議用Post資料提交方式；
2、在做資料查詢時，建議用Get方式；而在做資料添加、修改或刪除時，建議用Post方式；

   

GET和POST區別,http和https區別