1.0 HTTP協議

關于協議

對于應用層開發人員，接觸最多的網絡協議通常都是傳輸層的TCP，為什么這么說，因為再往上的應用層協議，如：HTTP、HTTPS、POP3、SMTP、RPC、FTP、TELNET等等都是基于TCP傳輸層協議。但對于IP協議，對于應用程序員來說更多的印象還是IP地址這個東西，實際上IP協議是位于TCP協議之下的網絡層，對于應用層程序員來說很難直接接觸

IP協議： IP的責任就是把數據從源傳送到目的地。它不負責保證傳送可靠性，流控制，包順序和其它對于主機到主機協議來說很普通的服務

TCP協議：TCP(Transmission Control Protocol 傳輸控制協議)是一種面向連接的、可靠的、基于字節流的傳輸層通信協議

HTTP協議：HTTP 是基于 TCP/IP 協議的應用層協議。它不涉及數據包(packet)傳輸，主要規定了客戶端和服務器之間的通信格式，默認使用80端口

1.1 TCP協議的3次握手

在我們獲得頁面數據之前，客戶端需要與服務器端進行三次握手的"問候"

簡單來說：

1， 客戶端向服務器發起問候，攜帶編號number

2， 服務器如果收到客戶端的問候，回復問候，攜帶其他編號number

3，客戶端確認連接成功，回復服務器收到返回的數據

687474703a2f2f6f6f327239726e7a702e626b742e636c6f7564646e2e636f6d2f3630363537332d32303137303331373139313333363933322d313635343735313132332e706e67.png

為什么是3次握手？

這個問題的本質是, 通信不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什么信息, 三次通信是理論上的最小值

• 已失效的連接請求報文段的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。
• 本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。
• 假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。
• 但server卻以為新的運輸連接已經建立，并一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。
• 采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接
• 4次分手怎么回事
• TCP協議是一種面向連接的、可靠的、基于字節流的運輸層通信協議。
• TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；
• 但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；
• 當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之后彼此就會愉快的中斷這次TCP連接。
• 如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態變化

2.0 請求報文

在結束協議的連接之后，客戶端向服務器正式發起請求

發起請求的時候，需要具體介紹當前的請求情況，方便服務器做出快速響應

請求報文的常見格式

請求報文包含 請求行--請求頭--請求體

請求行

請求方式 + 空格 + 請求路徑 + 空格 + HTTP協議版本

=> GET /demo.php HTTP/1.1

請求頭

Host 請求的主機

Cache-Control 控制緩存(例如：max-age=60 緩存60秒)

Accept 客戶端想要接收的文檔類型，逗號分隔

User-Agent 標識什么客戶端幫你發送的這次請求

Referer 這次請求的來源

Accept-Encoding可以接受的壓縮編碼

Cookie 客戶端本地的小票信息

請求體

客戶端需要向服務端發送的內容

• get請求，會把基本的參數拼接到url的后面，所以基本使用不上請求體
• post請求使用請求體會比較頻繁

3.0 請求樣式文件

請求css文件

雖然要請求的是css文件，但是link的是php文件

由于php是后臺文件，最終是在php中返回內容給瀏覽器，并且可以設置當前的文件類型

在css.php中書寫的代碼<?php // 設置響應頭的類型 header("Content-Type:text/css;charset=utf-8;"); echo "body{background:red;}";?>

eader方法發送重定向操作

頁面跳轉點擊重定向在data.php中完成跳轉<?php // 立馬做出跳轉 // header("Location:01-getsmt.php"); // 在指定的時間之后跳轉 header("refresh:3;url=01-getsmt.php");?>

header方法實現下載功能

<?php // 實現當前頁面的自動下載 header("Content-Type:application/octet-stream"); // 指定文件名稱, 自動下載，設置下載名稱 header("Content-Disposition:attachment;filename=tmp.php"); ?>

設置請求頭制作圖片防盜鏈

<?php // 獲取請求報文數據 // print_r(getallheaders()); $refer = getallheaders()["Referer"]; echo $referer; // http:127.0.0.1/day04/03-test.html // 獲取url中各個部分的值 print_r(parse_url($referer)); /* Array( [scheme] => http [host] => 127.0.0.1 [path] => /day04/03-test.html ) */?>

4.0 HTTP協議無狀態

HTTP會話

客戶端打開與服務器的連接發出請求到服務器響應客戶端請求的全過程稱之為會話

HTTP無狀態

HTTP協議，本來是進行共享多個計算機之間的文件而產生的文件傳輸協議

而請求的時候，服務器沒有記錄當前的信息

就比如，去火車站取票，刷身份證拿到票之后，整個會話結束，不會有任何記錄

==============

動態網站的出現，表單提交，購物車的DOM操作，付款的跳轉...

有了交互的需要，需要攜帶一些數據在不同頁面之間跳轉，無憑無據的，可如何是好

5.0 Cookie

關于cookie的描述

• 因為HTTP協議是無狀態的，即服務器不知道用戶上一次做了什么，這嚴重阻礙了交互式Web應用程序的實現。在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅干和兩瓶飲料。最后結帳時，由于HTTP的無狀態性，不通過額外的手段，服務器并不知道用戶到底買了什么，所以Cookie就是用來繞開HTTP的無狀態性的“額外手段”之一。服務器可以設置或讀取Cookies中包含信息，借此維護用戶跟服務器會話中的狀態。
• 在剛才的購物場景中，當用戶選購了第一項商品，服務器在向用戶發送網頁的同時，還發送了一段Cookie，記錄著那項商品的信息。當用戶訪問另一個頁面，瀏覽器會把Cookie發送給服務器，于是服務器知道他之前選購了什么。用戶繼續選購飲料，服務器就在原來那段Cookie里追加新的商品信息。結帳時，服務器讀取發送來的Cookie就行了。
• Cookie另一個典型的應用是當登錄一個網站時，網站往往會請求用戶輸入用戶名和密碼，并且用戶可以勾選“下次自動登錄”。如果勾選了，那么下次訪問同一網站時，用戶會發現沒輸入用戶名和密碼就已經登錄了。這正是因為前一次登錄時，服務器發送了包含登錄憑據(用戶名加密碼的某種加密形式)的Cookie到用戶的硬盤上。第二次登錄時，如果該Cookie尚未到期，瀏覽器會發送該Cookie，服務器驗證憑據，于是不必輸入用戶名和密碼就讓用戶登錄了。

cookie小結

cookie是一個文件，用來存儲當前的一些信息和服務器保持交流

在前端介紹的sessionStorage和localStorage也是類似的功能

使用cookie

總結

以上是生活随笔為你收集整理的java后台http请求完成之后怎么setcookie_关于HTTP的那些事和cookie的全部內容，希望文章能夠幫你解決所遇到的問題。

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