JavaWeb~搞定基礎HTTP協議相關的內容(URL、格式、方法、狀態碼、Header)

理解HTTP協議的用途

• 操作系統內利用TCP和IP協議將數據信息進行客戶端和服務器的互相傳輸 但並不是傳送到就行 還需要對其進行客戶端協議的解析讓用戶知道信息的內容是什麼
• 所以HTTP是應用層協議
• 就好比我們買手機 快遞公司和賣家只負責將新手機送到用戶手裏就行了 但是對於用戶這就夠了嗎? 顯然是不夠的 還需要手機的說明書來方便我們去體驗手機
• 所以，我們把數據從A端傳送到B端， TCP/IP 解決的是快遞公司的功能，而兩端還要對數據進行加工處理或者使用，所以我們還需要一層協議，不關心通信細節，關心應用細節
• 雖然我們說, 應用層協議是我們程序猿自己定的.
• 但實際上, 已經有大佬們定義了一些現成的, 又非常好用的應用層協議, 供我們直接參考使用. HTTP(超文本傳輸協議)就是其中之一

全雙工與半雙工

• 全雙工: 雙向通信 藉助一個socket對象 既可以發送數據 還可以接受數據
• 半雙工: 單向通信 要麼只能讀 要麼只能寫
• TCP就是一個全雙工通信 而 HTTP協議就是基於TCP而來的

初識URL

• 平時我們俗稱的 “網址” 其實就是說的 URL
• 我以我的一篇博客的網址簡單講解
  
  

初識urlencode和urldecode

• 首先看個例子
  
• 但是如果我們將網址複製出來就會成這樣
  
• 上面的過程就是一個urlencode過程 那反過來就是一個urldecode過程
• 那爲什麼要這樣呢?
  因爲像 / ? : 等這樣的字符, 已經被url當做特殊意義理解了. 因此這些字符不能隨意出現.比如, 某個參數中需要帶有這些特殊字符, 就必須先對特殊字符進行轉義.
• 轉義的規則如下:
  將需要轉碼的字符轉爲16進制，然後從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%，編碼成%XY
  格式

HTTP協議格式

• 爲了方便理解課藉助fiddler抓包工具進行抓包練習學習

HTTP請求格式

首行: [方法] + [URL] + [版本]
Header(協議頭): 請求的屬性, 冒號加空格分割的鍵值對;每組屬性之間使用\n分隔;遇到空行表示Header部分結束
Body: 空行後面的內容都是Body. Body允許爲空字符串. 如果Body存在, 則在Header中會有一個ContentLength屬性來標識Body的長度;

HTTP響應格式

首行: [版本號] + [狀態碼] + [狀態碼解釋]
Header: 請求的屬性, 冒號加空格分割的鍵值對;每組屬性之間使用\n分隔;遇到空行表示Header部分結束
Body: 空行後面的內容都是Body. Body允許爲空字符串. 如果Body存在, 則在Header中會有一個ContentLength屬性來標識Body的長度; 如果服務器返回了一個html頁面, 那麼html頁面內容就是在body中.

HTTP的方法

( 1）GET方法：獲取資源
GET方法是用來請求URL指定的資源。指定資源經服務器端解析後返回響應內容。

（2）POST方法：傳輸實體主題
POST方法用來傳輸實體的主體

（3）PUT方法：傳輸文件
PUT方法用來傳輸文件。像FTP協議的文件上傳一樣，要求在請求報文主體中包含文件的內容，然後保存到請求URL指定的位置。不太常用。

（4）HEAD方法：獲取報文首部
HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URL的有效性及資源更新的日期時間等。

（5）DELETE方法：刪除文件
DELETE方法用來刪除文件，是PUT的相反方法。DELETE方法按請求URL刪除指定的資源。也不常用。

（6）OPTIONS方法：詢問支持的方法
OPTIONS方法用來查詢針對請求URL指定的資源支持的方法。

• GET與POST的區別
  唯一區別就是GET一般將數據放到URL中 POST一般將數據放到BODY中
  所以關於網上一些其他說法比如 get是用於服務器獲取資源 POST是用於給服務器提交資源 還有get傳輸的數量較小POST傳輸的數量較大 這是設計者的初衷 但是發展到如今2020年這些早就不是問題了 目前最新版本的HTTP協議的URL可以達到幾個M 雖然還是沒有POST的大 但是足夠了
  還有一些說post安全 其實不然 這只是對小白而言 即使是post方法 隨便抓個包還是容易知道內容

HTTP的狀態碼

• 最常見的狀態碼(來自百度百科)

100 Continue
客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。
200 OK
請求已成功，請求所希望的響應頭或數據體將隨此響應返回。出現此狀態碼是表示正常狀態。
201 Created
請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨Location 頭信息返回。假如需要的資源無法及時建立的話，應當返回 ‘202 Accepted’。
202 Accepted
服務器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。
302 Move Temporarily
請求的資源臨時從不同的 URI響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應纔是可緩存的。
400 Bad Request
1、語義有誤，當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重複提交這個請求。
2、請求參數有誤。
403 Forbidden
服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是一個 HEAD 請求，而且服務器希望能夠講清楚爲何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然服務器也可以返回一個404響應，假如它不希望讓客戶端獲得任何信息。
404 Not Found
請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因爲某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底爲何請求被拒絕或者沒有其他適合的響應可用的情況下。出現這個錯誤的最有可能的原因是服務器端沒有這個頁面。
501 Not Implemented
服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。
502 Bad Gateway
作爲網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
504 Gateway Timeout
作爲網關或者代理工作的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。
注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤

• 重定向狀態碼就好比打電話的電話轉接

HTTP常見Header

Content-Type: 數據類型(text/html等)
Content-Length: Body的長度(字節)
Host: 客戶端告知服務器, 所請求的資源是在哪個主機的哪個端口上;
User-Agent: 聲明用戶的操作系統和瀏覽器版本信息;
referer: 當前頁面是從哪個頁面跳轉過來的;
location: 搭配3xx狀態碼使用, 告訴客戶端接下來要去哪裏訪問;
Cookie: 用於在客戶端存儲少量信息. 通常用於實現會話(session)的功能

• Cookie簡單理解就是一個字符串 因爲HTTP協議的特點就是無狀態(任意多個HTTP協議請求之間 沒什麼關聯關係) 所以要簡化業務的時候就需要使用Cookie來j建立聯繫 就是將某個字符串保存在瀏覽器中 (這個字符串是ton過服務器返回響應的Set-Cookie字段來的 後序再訪問服務器時 就會自動帶上Cookie字段)
• 舉個簡單例子說就是 當我們登錄上淘寶後 後續再訪問淘寶的其他頁面的時候就不需要再次登錄
• 注意瀏覽器是按照域名來區分Cookie的 比如百度和CSDN的Cookie是相互獨立的 不衝突的