get和post有什么區(qū)別？get和post的區(qū)別：①get是從服務器獲取數(shù)據(jù)，post是向服務器發(fā)送數(shù)據(jù)；②直接通過URL獲取請求，數(shù)據(jù)信息可以直接在URL中看到；post請求放在請求頭中，我們不能

get和post有什么區(qū)別？

get和post的區(qū)別：

①get是從服務器獲取數(shù)據(jù)，post是向服務器發(fā)送數(shù)據(jù)；

②直接通過URL獲取請求，數(shù)據(jù)信息可以直接在URL中看到；post請求放在請求頭中，我們不能直接看到；

③get提交有數(shù)據(jù)大小限制，一般不超過2KB，而post理論上默認為2KB，沒有限制；

4。由于get請求的數(shù)據(jù)參數(shù)暴露在URL中，安全性相對較低；post請求中，請求信息放置在請求頭中，安全性相對較高。

get與post區(qū)別？

發(fā)布和獲取提交數(shù)據(jù)到服務器，并從服務器獲取數(shù)據(jù)。

1. 傳輸方式：get通過地址欄傳輸，post通過消息傳輸。

2. 傳輸長度：get參數(shù)有長度限制（受URL長度限制），post沒有限制

3。get和post之間還有一個重要的區(qū)別。簡而言之，

get生成一個TCP包；post生成兩個TCP包

long，

對于get請求，瀏覽器將發(fā)送http for post，瀏覽器首先發(fā)送頭，服務器響應100 continue，瀏覽器發(fā)送數(shù)據(jù)，服務器響應200 OK。

換句話說，get只需要一輛車就能送貨，而post則需要運行兩次。第一次，去服務器說“嗨，我稍后會發(fā)一批貨，你開門來接我”，然后回去送貨。

因為post需要兩個步驟，而且要花費更多的時間，所以get似乎比post更有效。因此，雅虎團隊建議將post替換為get來優(yōu)化網(wǎng)站性能。但這是個坑！小心地跳進去。為什么？

1. Get和post有自己的語義，所以不能混淆。

2. 研究表明，在良好的網(wǎng)絡環(huán)境下，發(fā)送一個包和發(fā)送兩個包的時間差可以忽略不計。在網(wǎng)絡環(huán)境惡劣的情況下，雙包TCP在驗證數(shù)據(jù)包完整性方面具有很大的優(yōu)勢。

3. 并非所有瀏覽器都會在post中發(fā)送兩次數(shù)據(jù)包，但在Firefox中只發(fā)送一次。

1. get模式的安全性比post模式差。如果包含機密信息，建議使用post數(shù)據(jù)提交模式；

2。在進行數(shù)據(jù)查詢時，建議使用get模式；在進行數(shù)據(jù)添加、修改或刪除時，建議使用post模式；

案例：一般情況下，在登錄時，使用post傳輸，這涉及到密碼傳輸，但是在進行頁面查詢時，例如查詢文章ID的文章時，使用“獲取地址”欄中的鏈接，如下所示：文章.php？id=11，用post查詢地址欄，鏈接為：文章.php，將不顯示傳輸?shù)臄?shù)據(jù)。

GET請求和POST請求的區(qū)別？

從HTTP消息級別，get請求將信息放在URL中，post請求將信息放在請求正文中。這使得get請求攜帶的數(shù)據(jù)量受到限制，因為URL本身的長度是有限的，而post請求的數(shù)據(jù)是以報紙樣式存儲的，因此大小沒有限制。從形式上講，get請求將數(shù)據(jù)放在URL上并不安全，而post請求將數(shù)據(jù)放在請求體中似乎更安全。事實上，post請求的內容很容易獲取，所以兩者在安全性上沒有太大區(qū)別。為了實現(xiàn)安全的信息傳輸，我們必須依賴HTTPS。

從數(shù)據(jù)庫級別來看，get是冪等且安全的，而post不是。這實際上與get/post請求的功能有關。根據(jù)HTTP協(xié)議，get-request用于查看信息，不改變服務器上的信息，post-request用于改變服務器上的信息。正因為get請求只查看信息而不更改信息，所以對數(shù)據(jù)庫執(zhí)行一次或多次操作得到的結果是一致的，這被認為是冪等的。安全性是指數(shù)據(jù)庫操作不改變數(shù)據(jù)庫中的數(shù)據(jù)。

從其他方面來看，get請求可以緩存，get請求可以保存在瀏覽器的瀏覽記錄中，get請求URL可以保存為瀏覽器書簽。這些在post請求中不可用。緩存是get請求被廣泛使用的根本原因。它可以緩存，因為它的冪等性和安全性。除了返回結果外，沒有其他冗余操作。因此，大部分get請求都是由CDN緩存的，這大大減輕了web服務器的負擔。