1.0 HTTP協(xié)議

關(guān)于協(xié)議

對(duì)于應(yīng)用層開發(fā)人員，接觸最多的網(wǎng)絡(luò)協(xié)議通常都是傳輸層的TCP，為什么這么說，因?yàn)樵偻系膽?yīng)用層協(xié)議，如：HTTP、HTTPS、POP3、SMTP、RPC、FTP、TELNET等等都是基于TCP傳輸層協(xié)議。但對(duì)于IP協(xié)議，對(duì)于應(yīng)用程序員來說更多的印象還是IP地址這個(gè)東西，實(shí)際上IP協(xié)議是位于TCP協(xié)議之下的網(wǎng)絡(luò)層，對(duì)于應(yīng)用層程序員來說很難直接接觸

IP協(xié)議： IP的責(zé)任就是把數(shù)據(jù)從源傳送到目的地。它不負(fù)責(zé)保證傳送可靠性，流控制，包順序和其它對(duì)于主機(jī)到主機(jī)協(xié)議來說很普通的服務(wù)

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

HTTP協(xié)議：HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議。它不涉及數(shù)據(jù)包(packet)傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口

1.1 TCP協(xié)議的3次握手

在我們獲得頁面數(shù)據(jù)之前，客戶端需要與服務(wù)器端進(jìn)行三次握手的"問候"

簡(jiǎn)單來說：

1， 客戶端向服務(wù)器發(fā)起問候，攜帶編號(hào)number

2， 服務(wù)器如果收到客戶端的問候，回復(fù)問候，攜帶其他編號(hào)number

3，客戶端確認(rèn)連接成功，回復(fù)服務(wù)器收到返回的數(shù)據(jù)

687474703a2f2f6f6f327239726e7a702e626b742e636c6f7564646e2e636f6d2f3630363537332d32303137303331373139313333363933322d313635343735313132332e706e67.png

為什么是3次握手？

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

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

2.0 請(qǐng)求報(bào)文

在結(jié)束協(xié)議的連接之后，客戶端向服務(wù)器正式發(fā)起請(qǐng)求

發(fā)起請(qǐng)求的時(shí)候，需要具體介紹當(dāng)前的請(qǐng)求情況，方便服務(wù)器做出快速響應(yīng)

請(qǐng)求報(bào)文的常見格式

請(qǐng)求報(bào)文包含 請(qǐng)求行--請(qǐng)求頭--請(qǐng)求體

請(qǐng)求行

請(qǐng)求方式 + 空格 + 請(qǐng)求路徑 + 空格 + HTTP協(xié)議版本

=> GET /demo.php HTTP/1.1

請(qǐng)求頭

Host 請(qǐng)求的主機(jī)

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

Accept 客戶端想要接收的文檔類型，逗號(hào)分隔

User-Agent 標(biāo)識(shí)什么客戶端幫你發(fā)送的這次請(qǐng)求

Referer 這次請(qǐng)求的來源

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

Cookie 客戶端本地的小票信息

請(qǐng)求體

客戶端需要向服務(wù)端發(fā)送的內(nèi)容

• get請(qǐng)求，會(huì)把基本的參數(shù)拼接到url的后面，所以基本使用不上請(qǐng)求體
• post請(qǐng)求使用請(qǐng)求體會(huì)比較頻繁

3.0 請(qǐng)求樣式文件

請(qǐng)求css文件

雖然要請(qǐng)求的是css文件，但是link的是php文件

由于php是后臺(tái)文件，最終是在php中返回內(nèi)容給瀏覽器，并且可以設(shè)置當(dāng)前的文件類型

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

eader方法發(fā)送重定向操作

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

header方法實(shí)現(xiàn)下載功能

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

設(shè)置請(qǐng)求頭制作圖片防盜鏈

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

4.0 HTTP協(xié)議無狀態(tài)

HTTP會(huì)話

客戶端打開與服務(wù)器的連接發(fā)出請(qǐng)求到服務(wù)器響應(yīng)客戶端請(qǐng)求的全過程稱之為會(huì)話

HTTP無狀態(tài)

HTTP協(xié)議，本來是進(jìn)行共享多個(gè)計(jì)算機(jī)之間的文件而產(chǎn)生的文件傳輸協(xié)議

而請(qǐng)求的時(shí)候，服務(wù)器沒有記錄當(dāng)前的信息

就比如，去火車站取票，刷身份證拿到票之后，整個(gè)會(huì)話結(jié)束，不會(huì)有任何記錄

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

動(dòng)態(tài)網(wǎng)站的出現(xiàn)，表單提交，購物車的DOM操作，付款的跳轉(zhuǎn)...

有了交互的需要，需要攜帶一些數(shù)據(jù)在不同頁面之間跳轉(zhuǎn)，無憑無據(jù)的，可如何是好

5.0 Cookie

關(guān)于cookie的描述

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

cookie小結(jié)

cookie是一個(gè)文件，用來存儲(chǔ)當(dāng)前的一些信息和服務(wù)器保持交流

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

使用cookie

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。