Java必知必會-HTTP
HTTP
超文字傳輸協議，用於客戶端和伺服器端之間的通訊，
HTTP與TCP的區別和聯絡
TCP是傳輸層，而http是應用層
http是要基於TCP連線基礎上的，TCP就是單純建立連線，不涉及任何我們需要請求的實際資料，簡單的傳輸。http是用來收發資料，即實際應用上來的。
TCP是底層通訊協議，定義的是資料傳輸和連線方式的規範
HTTP是應用層協議，定義的是傳輸資料的內容的規範
HTTP協議中的資料是利用TCP協議傳輸的，所以支援HTTP也就一定支援TCP
HTTP支援的是www服務
而TCP/IP是協議 ，它是Internet國際網際網路絡的基礎。TCP/IP是網路中使用的基本的通訊協議。
TCP/IP實際上是一組協議，它包括上百個各種功能的協議，如：遠端登入、檔案傳輸和電子郵件等，而TCP協議和IP協議是保證資料完整傳輸的兩個基本的重要協議。通常說TCP/IP是Internet協議族，而不單單是TCP和IP。
TCP
手機能夠使用聯網功能是因為手機底層實現了TCP/IP協議，可以使手機終端通過無線網路建立TCP連線，TCP協議可以對上層網路提供介面，使上層網路資料的傳輸建立在“無差別”的網路之上。
建立起一個TCP連線需要經過“三次握手”：
第一次握手（請求）：客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手（確認）：伺服器收到syn包，必須確認客戶的ACK包（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手（連線）：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主動關閉連 接之前，TCP 連線都將被一直保持下去。斷開連線時伺服器和客戶端均可以主動發起斷開TCP連線的請求，斷開過程需要經過“四次握手”
HTTP
HTTP協議是建立在TCP協議之上的一種應用，是web聯網的基礎
HTTP連線最顯著的特點是客戶端傳送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連線。從建立連線到關閉連線的過程稱為“一次連線”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連線，在處理完本次請求後，就自動釋放連線。
2）在HTTP 1.1中則可以在一次連線中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。
由於HTTP在每次請求結束後都會主動釋放連線，因此HTTP連線是一種“短連線”，要保持客戶端程式的線上狀態，需要不斷地向伺服器發起連線請求。通常的 做法是即時不需要獲得任何資料，客戶端也保持每隔一段固定的時間向伺服器傳送一次“保持連線”的請求，伺服器在收到該請求後對客戶端進行回覆，表明知道客 戶端“線上”。若伺服器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到伺服器的回覆，則認為網路已經斷開。
流程步驟
第一：從傳輸層，先說下TCP連線，我們要和服務端連線TCP連線，需要通過三次連線，包括：請求，確認，建立連線。即傳說中的“三次握手協議”。簡單就是：請求，確認，連線。
第二：TCP建立連線後，HTTP協議就來傳輸資料，也是請求，確認，連線。 總體就是C傳送一個HTTP請求給S，S收到了這個http請求，然後返回給C的http響應，然後C的中介軟體或者說瀏覽器把這些資料渲染成為了網頁，展示在使用者面前。
- 傳送一個http請求給S，這個請求包括請求頭和請求內容：
- 請求頭request header：
- 1.請求的方法是POST/GET,請求的URL，http協議版本
- 2.請求的資料，和編碼方式
- 3是否有cookie和cooies，是否快取等。post和get請求方式的區別是，get把請求內容放在URL後面，但是URL長度有限制。而post是以表單的形勢，適合要輸入密碼之類的，因為不在URL中顯示，所以比較安全。
- 請求體request body：即請求的內容.
- 請求頭request header：
- S收到了http請求，然後根據請求頭，返回http響應。
- response header：包括了1.cookies或者sessions2.狀態嗎3.內容大小等
- response body： 即響應的內容，包括，JS什麼的。
- C收到了以後，就由瀏覽器完成一系列的渲染，包括執行JS指令碼等。
socket
套接字（socket）是通訊的基石，是支援TCP/IP協議的網路通訊的基本操作單元。它是網路通訊過程中端點的抽象表示，包含進行網路通訊必須的五種資訊：連線使用的協議，本地主機的IP地址，本地程序的協議埠，遠地主機的IP地址，遠地程序的協議埠。
應用層通過傳輸層進行資料通訊時，TCP會遇到同時為多個應用程式程序提供併發服務的問題。多個TCP連線或多個應用程式程序可能需要通過同一個 TCP協 議埠傳輸資料。為了區別不同的應用程式程序和連線，許多計算機作業系統為應用程式與TCP／IP協議互動提供了套接字(Socket)介面。應用層可以 和傳輸層通過Socket介面，區分來自不同應用程式程序或網路連線的通訊，實現資料傳輸的併發服務。
建立socket連線
建立Socket連線至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連線過程分為三個步驟：伺服器監聽，客戶端請求，連線確認。
伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連線的狀態，實時監控網路狀態，等待客戶端的連線請求。
客戶端請求：指客戶端的套接字提出連線請求，要連線的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連線的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連線請求。
連線確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連線請求時，就響應客戶端套接字的請求，建立一個新的執行緒，把伺服器端套接字的描述發給客戶 端，一旦客戶端確認了此描述，雙方就正式建立連線。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連線請求。
SOCKET連線與TCP連線
建立Socket連線時，可以指定使用的傳輸層協議，Socket可以支援不同的傳輸層協議（TCP或UDP），當使用TCP協議進行連線時，該Socket連線就是一個TCP連線。
Socket連線與HTTP連線
由於通常情況下Socket連線就是TCP連線，因此Socket連線一旦建立，通訊雙方即可開始相互發送資料內容，直到雙方連線斷開。但在實際網路應用 中，客戶端到伺服器之間的通訊往往需要穿越多箇中間節點，例如路由器、閘道器、防火牆等，大部分防火牆預設會關閉長時間處於非活躍狀態的連線而導 致 Socket 連線斷連，因此需要通過輪詢告訴網路，該連線處於活躍狀態。
而HTTP連線使用的是“請求—響應”的方式，不僅在請求時需要先建立連線，而且需要客戶端向伺服器發出請求後，伺服器端才能回覆資料。
很多情況下，需要伺服器端主動向客戶端推送資料，保持客戶端與伺服器資料的實時與同步。此時若雙方建立的是Socket連線，伺服器就可以直接將資料傳送給 客戶端；若雙方建立的是HTTP連線，則伺服器需要等到客戶端傳送一次請求後才能將資料傳回給客戶端，因此，客戶端定時向伺服器端傳送連線請求，不僅可以 保持線上，同時也是在“詢問”伺服器是否有新的資料，如果有就將資料傳給客戶端。
面試
Http與Https的區別：
- HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭
- HTTP 是不安全的，而 HTTPS 是安全的
- HTTP 標準埠是80 ，而 HTTPS 的標準埠是443
- 在OSI 網路模型中，HTTP工作於應用層，而HTTPS 的安全傳輸機制工作在傳輸層
- HTTP 無法加密，而HTTPS 對傳輸的資料進行加密
- HTTP無需證書，而HTTPS 需要CA機構wosign的頒發的SSL證書
什麼是Http協議無狀態協議?怎麼解決Http協議無狀態協議?
- 無狀態協議對於事務處理沒有記憶能力，缺少狀態意味著如果是後續處理就需要前面的資訊
- 也就是說，當客戶端一次HTTP請求完成以後，客戶端再發送一次HTTP請求，HTTP並不知道當前客戶端是一個”老使用者“。
- 可以使用Cookie來解決無狀態的問題，Cookie就相當於一個通行證，第一次訪問的時候給客戶端傳送一個Cookie，當客戶端再次來的時候，拿著Cookie(通行證)，那麼伺服器就知道這個是”老使用者“。
URI和URL的區別
URI，是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源。
- Web上可用的每種資源如HTML文件、影象、視訊片段、程式等都是一個來URI來定位的
- URI一般由三部組成：
- ①訪問資源的命名機制
- ②存放資源的主機名
- ③資源自身的名稱，由路徑表示，著重強調於資源。
URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。
- URL是Internet上用來描述資訊資源的字串，主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。
- 採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成：
- ①協議(或稱為服務方式)
- ②存有該資源的主機IP地址(有時也包括埠號)
- ③主機資源的具體地址。如目錄和檔名等
URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:[email protected]。
- URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。
在Java的URI中，一個URI例項可以代表絕對的，也可以是相對的，只要它符合URI的語法規則。而URL類則不僅符合語義，還包含了定位該資源的資訊，因此它不能是相對的。
在Java類庫中，URI類不包含任何訪問資源的方法，它唯一的作用就是解析。
相反的是，URL類可以開啟一個到達資源的流。
常用的HTTP方法有哪些？
- GET： 用於請求訪問已經被URI（統一資源識別符號）識別的資源，可以通過URL傳參給伺服器
- POST：用於傳輸資訊給伺服器，主要功能與GET方法類似，但一般推薦使用POST方式。
- PUT： 傳輸檔案，報文主體中包含檔案內容，儲存到對應URI位置。
- HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URI是否有效。
- DELETE：刪除檔案，與PUT方法相反，刪除對應URI位置的檔案。
- OPTIONS：查詢相應URI支援的HTTP方法。
HTTP請求報文與響應報文格式
請求報文包含四部分：
- a、請求行：包含請求方法、URI、HTTP版本資訊
- b、請求首部欄位
- c、請求內容實體
- d、空行
響應報文包含四部分：
- a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語
- b、響應首部欄位
- c、響應內容實體
- d、空行
常見的首部：
- 通用首部欄位（請求報文與響應報文都會使用的首部欄位）
- Date：建立報文時間
- Connection：連線的管理
- Cache-Control：快取的控制
- Transfer-Encoding：報文主體的傳輸編碼方式
- 請求首部欄位（請求報文會使用的首部欄位）
- Host：請求資源所在伺服器
- Accept：可處理的媒體型別
- Accept-Charset：可接收的字符集
- Accept-Encoding：可接受的內容編碼
- Accept-Language：可接受的自然語言
- 響應首部欄位（響應報文會使用的首部欄位）
- Accept-Ranges：可接受的位元組範圍
- Location：令客戶端重新定向到的URI
- Server：HTTP伺服器的安裝資訊
- 實體首部欄位（請求報文與響應報文的的實體部分使用的首部欄位）
- Allow：資源可支援的HTTP方法
- Content-Type：實體主類的型別
- Content-Encoding：實體主體適用的編碼方式
- Content-Language：實體主體的自然語言
- Content-Length：實體主體的的位元組數
- Content-Range：實體主體的位置範圍，一般用於發出部分請求時使用
HTTPS工作原理
- 一、首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；
- 二、客戶端如果校驗通過後，就根據證書的公鑰的有效， 生成隨機數，隨機數使用公鑰進行加密（RSA加密）；
- 三、訊息體產生的後，對它的摘要進行MD5（或者SHA1）演算法加密，此時就得到了RSA簽名；
- 四、傳送給服務端，此時只有服務端（RSA私鑰）能解密。
- 五、解密得到的隨機數，再用AES加密，作為金鑰（此時的金鑰只有客戶端和服務端知道）
一次完整的HTTP請求所經歷的7個步驟
HTTP通訊機制是在一次完整的HTTP通訊過程中，Web瀏覽器與Web伺服器之間將完成下列7個步驟：
- 建立TCP連線
在HTTP工作開始之前，Web瀏覽器首先要通過網路與Web伺服器建立連線，該連線是通過TCP來完成的，該協議與IP協議共同構建 Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網路。HTTP是比TCP更高層次的應用層協議，根據規則， 只有低層協議建立之後才能，才能進行更層協議的連線，因此，首先要建立TCP連線，一般TCP連線的埠號是80。
- Web瀏覽器向Web伺服器傳送請求行
一旦建立了TCP連線，Web瀏覽器就會向Web伺服器傳送請求命令。例如：GET /sample/hello.jsp HTTP/1.1。
- Web瀏覽器傳送請求頭
- 瀏覽器傳送其請求命令之後，還要以頭資訊的形式向Web伺服器傳送一些別的資訊，之後瀏覽器傳送了一空白行來通知伺服器，它已經結束了該頭資訊的傳送。
- Web伺服器應答
- 客戶機向伺服器發出請求後，伺服器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。
- Web伺服器傳送應答頭
- 正如客戶端會隨同請求傳送關於自身的資訊一樣，伺服器也會隨同應答向用戶傳送關於它自己的資料及被請求的文件。
- Web伺服器向瀏覽器傳送資料
- Web伺服器向瀏覽器傳送頭資訊後，它會發送一個空白行來表示頭資訊的傳送到此為結束，接著，它就以Content-Type應答頭資訊所描述的格式傳送使用者所請求的實際資料。
- Web伺服器關閉TCP連線
- 一般情況下，一旦Web伺服器向瀏覽器傳送了請求資料，它就要關閉TCP連線，然後如果瀏覽器或者伺服器在其頭資訊加入了這行程式碼：
Connection:keep-alive
TCP連線在傳送後將仍然保持開啟狀態，於是，瀏覽器可以繼續通過相同的連線傳送請求。保持連線節省了為每個請求建立新連線所需的時間，還節約了網路頻寬。
建立TCP連線->傳送請求行->傳送請求頭->（到達伺服器）傳送狀態行->傳送響應頭->傳送響應資料->斷TCP連線
常見的HTTP相應狀態碼
- 200：請求被正常處理
- 204：請求被受理但沒有資源可以返回
- 206：客戶端只是請求資源的一部分，伺服器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定範圍的資源。
- 301：永久性重定向
- 302：臨時重定向
- 303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
- 304：傳送附帶條件的請求時，條件不滿足時返回，與重定向無關
- 307：臨時重定向，與302類似，只是強制要求使用POST方法
- 400：請求報文語法有誤，伺服器無法識別
- 401：請求需要認證
- 403：請求的對應資源禁止被訪問
- 404：伺服器無法找到對應資源
- 500：伺服器內部錯誤
- 503：伺服器正忙
HTTP1.1版本新特性
- a、預設持久連線節省通訊量，只要客戶端服務端任意一端沒有明確提出斷開TCP連線，就一直保持連線，可以傳送多次HTTP請求
- b、管線化，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應
- c、斷點續傳。實際上就是利用HTTP訊息頭使用分塊傳輸編碼，將實體主體分塊傳輸。
- HTTP從1.1版本起，底層的TCP使用的長連線，之前版本底層的TCP都是短連線
- 新增5種請求方法：OPTIONS PUT DELELTE TRACE CONNECT