HTTP 協議請求概述

一、創建一個鏈接（TCP三次握手）

HTTP是一個基於TCP協議的應用層協議，由請求和響應構成，另外還有HTTPS，是以安全爲目標的HTTP通道，是HTTP協議加上SSL協議層的安全加密傳輸，另外TLS也是SSL的升級（具體關係不詳細說，有興趣的同窗能夠百度）

那麼咱們在創建一個鏈接的時候須要經歷3個步驟（三次握手）：

（1）Seq序號（sequence number）：佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。

（2）確認號（acknowledgement number）：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。

（3）標誌位（Flags）：共6個，即URG、ACK、PSH、RST、SYN、FIN等。具體含義以下：

URG：緊急指針（urgent pointer）有效。
ACK：確認序號有效。
PSH：接收方應該儘快將這個報文交給應用層。
RST：重置鏈接。
SYN：發起一個新鏈接。
FIN：釋放一個鏈接。

須要注意的是：

不要將確認序號Ack與標誌位中的ACK搞混了。確認方Ack=發起方Seq+1，兩端配對。

三次握手的具體步驟：

　　創建一個TCP鏈接時，須要客戶端和服務器端總共發送3個包。
　　三次握手的目的是鏈接服務器指定端口，創建TCP鏈接，並同步鏈接雙方的序列號和確認號，交換TCP窗口大小信息。在socket編程中，客戶端執行connect()時將觸發三次握手。

　　第一次握手（SYN=1，seq=x）：
　　　　客戶端發送一個TCP的SYN標誌位置1的包，指明客戶端打算鏈接的服務器的端口，以及初始序號X，保存在包頭的序列號（Sequence Number）字段裏。

　　第二次握手（SYN=1，ACK=1，seq=y，ACKnum=x+1）：
　　　　服務器發回確認包（ACK）應答。即SYN標誌位和ACK標誌位均爲1。服務器端選擇本身的ISN序列號，放在seq域裏，同時將確認序號（Acknowledgement Number）設置爲客戶的ISN加1，即X+1。發送完畢後，服務器端進入SYN_RCVD狀態。

　　第三次握手（ACK=1，seq = x+1 ,ACKnum=y+1）：
　　　　客戶端再次發送確認包（ACK=1），SYN標誌位爲0，而且把服務器發來ACK的序號字段+1，放在肯定字段中發送給對方，而且在數據段放 X 的+1。
　　發送完畢後，客戶端進入ESTABLISHED狀態，當服務器端收到這個包時，也進入ESTABLISHED狀態，TCP握手結束，TCP鏈接創建完成。

 

2.請求

 

創建鏈接以後，咱們就要開始向服務端發起請求

HTTP/1.1協議中，客戶端和服務端默認對方支持長鏈接-keepalive，由於 keepalive 在不少狀況下可以重用鏈接，減小資源消耗，縮短響應時間，因此在 HTTP1.1 中缺省就是支持 keepalive 的。

若是響應方不想支持 keepalive，須要在應答報文頭中明確的標識 Connection:close，那麼客戶端設置的 Connection:keep-alive 就失效了，若是客戶端不想支持keepalive,須要在請求報頭中明確標識Connection:close

  設置 HTTP 短鏈接：
  在應答報文頭中設置 Connection:close，則在一次請求/響應以後，就會關閉鏈接。

  設置 HTTP 長鏈接，有過時時間：
  在應答報文頭中設置 Connection:keep-alive 和 Keep-Alive: timeout=60，代表鏈接創建以後，空閒時間超過60秒以後，就會失效。若是在空閒第 58 秒時，再次使用此鏈接，則鏈接仍然有效，使用完以後，從新計數，空閒 60 秒以後過時。

  設置 HTTP 長鏈接，無過時時間：
  在應答報文頭中只設置 Connection:keep-alive，代表鏈接永久有效。

http一次請求的過程大概以下:

• 用戶在瀏覽器輸入www.xxxxx.com
• dns服務器解析/或者本機hosts,路由器hosts對比 得到ip
• 瀏覽器訪問默認端口80,tls,ssl協議端口443,則訪問的tcp地址爲 ip:80
• tcp協議3次握手,創建鏈接
• 發送一個http request請求頭
• 服務器得到http request請求頭,代表該次訪問爲http訪問,解析http請求頭,得到請求類型,請求格式,以及請求數據(cookie,get,post數據)
• 服務器發送response響應數據,主動斷開
• 瀏覽器接收response響應數據,解析響應文本類型,解析數據,斷開鏈接

HTTP請求由三部分組成 ： 請求行，消息報頭，請求正文

請求行

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：

Method Request-URI HTTP-Version CRLF

GET /Chris.jpg HTTP/1.1

Method : 請求方法； Request-URI ：統一資源標識符； HTTP-Version：請求的HTTP協議版本； CRLF：回車和換行

各類請求方法：

HTTP請求方法也被叫作「請求動做」，不一樣的方法規定了不一樣的操做指定的資源方式。服務端也會根據不一樣的請求方法作不一樣的響應。

• OPTIONS：容許客戶端查看服務器的性能。這個方法會請求服務器返回該資源所支持的全部 HTTP 請求方法，該方法會用’*’來代替資源名稱，向服務器發送 OPTIONS 請求，能夠測試服務器功能是否正常。JavaScript 的 XMLHttpRequest 對象進行 CORS 跨域資源共享時，就是使用 OPTIONS 方法發送嗅探請求，以判斷是否有對指定資源的訪問權限。

• HEAD：與GET方法同樣，都是向服務器發出指定資源的請求，可是服務器在響應 HEAD 請求時不會回傳資源的內容部分（即響應實體），這樣咱們在不傳輸所有內容的狀況下，就能夠獲取服務器的響應頭信息。HEAD方法常被用於客戶端查看服務器的性能。

• GET：請求指定的頁面信息，並返回響應實體。通常來講 GET 方法應該只用於數據的讀取，而不該當用於會產生反作用的非冪等的操做中。

• POST：向指定資源提交數據，請求服務器進行處理，如：表單數據提交、文件上傳等，請求數據包含在請求體中。POST 方法是非冪等的方法，由於這個請求可能會建立新的資源或修改現有資源。

• PUT：向指定資源位置上傳其最新內容，PUT 方法是冪等的方法。經過該方法客戶端能夠將指定資源的最新數據傳送給服務器取代指定的資源的內容，經常使用於修改指定資源。

• DELETE：請求服務器刪除所請求 URI 所標識的資源。DELETE 請求後指定資源會被刪除，DELETE 方法也是冪等的。

• TRACE：請求服務器回顯其收到的請求信息，該方法主要用於 HTTP 請求的測試或診斷。

• CONNECT：該方法是 HTTP/1.1 協議預留的，可以將鏈接改成管道方式的代理服務器。一般用於 SSL 加密服務器的連接與非加密的 HTTP 代理服務器的通訊。

• PATCH：出現的較晚，它在 2010 年的 RFC 5789 標準中被定義。PATCH 請求與 PUT 請求相似，一樣用於資源的更新。兩者有如下兩點不一樣：一、PATCH 通常用於資源的部分更新，而 PUT 通常用於資源的總體更新；二、當資源不存在時，PATCH 會建立一個新的資源，而 PUT 只會對已在資源進行更新。

消息報頭

 HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。每個報頭域都是由 名字+:+空格+值 組成，消息報頭域的名字不區分大小寫。

• 普通報頭：普通報頭中有少數報頭域用於全部的請求和響應信息，但並不用於被傳輸的實體，只用於傳輸的消息(如緩存控制，鏈接控制等)，通用頭域包含Cache-Control、Connection等等。既能夠出如今請求報頭，也能夠出如今響應報頭中
• 請求報頭：用於向服務器端傳遞請求的附加信息 ，請求報頭的HTTP報頭結構：通用報頭-請求報頭-實體報頭
• 響應報頭：用於服務器端傳遞附加的響應信息 ， 響應報頭的HTTP報頭結構：通用報頭-響應報頭-實體報頭
• 實體報頭：實體報頭定義了關於實體正文和請求所標識資源的元信息

 

典型的請求頭有：

Host：請求的主機名，容許多個域名同處一個IP地址，即虛擬主機

User-Agent：內容包含發送請求的用戶信息，通常是瀏覽器類型、操做系統等信息

Accept：客戶端可識別的內容類型列表，用於指定客戶端接收那些類型的信息

Accept-Controller-Allow-Origin ：本次請求來自哪一個源，服務器根據該值判斷是否贊成請求，在解決跨域問題上也會用到

Cache-Controller：指定請求和響應的緩存機制。只在當前請求生效

Connection：容許客戶端和服務器指定與請求/響應鏈接有關的選項，例如這是爲Keep-Alive則表示保持鏈接。

Cookie：Cookie分2種，一種是客戶端向服務端發送的，使用Cookie報頭，用來標記。另外一種是服務器發給瀏覽器的，報頭爲set-Cookie。

請求正文和響應正文

消息報頭結束以後，空行 標誌着請求頭結束，請求正文（請求體）的開始
username=aa&password=1234

響應正文就是服務器返回的資源的內容，響應頭和正文之間也必須用空行分隔

 

四次揮手

創建一個鏈接須要三次握手，而終止一個鏈接要通過四次揮手，這是由TCP的半關閉（half-close）形成的。具體過程以下所示。

• 某個應用進程首先調用close，稱該端執行「主動關閉」（active close）。該端的TCP因而發送一個FIN分節，表示數據發送完畢。
• 接收到這個FIN的對端執行 「被動關閉」（passive close），這個FIN由TCP確認。
• 注意：FIN的接收也做爲一個文件結束符（end-of-file）傳遞給接收端應用進程，放在已排隊等候該應用進程接收的任何其餘數據以後，由於，FIN的接收意味着接收端應用進程在相應鏈接上再無額外數據可接收。
• 一段時間後，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這致使它的TCP也發送一個FIN。
• 接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN。 既然每一個方向都須要一個FIN和一個ACK，所以一般須要4個分節。