一、HTTP協議概述

????????HTTP是一個屬于應用層的面向對象協議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統。它于1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。HTTP協議的主要特點可概括如下：
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

二、HTTP請求消息

????????HTTP請求由三部分組成，分別是：請求行、消息報頭、請求正文。

????????當我們在網頁瀏覽器（Web browser）的地址欄中輸入 URL 時，Web 頁面是如何呈現的嗎？

從瀏覽器進程角度分析從輸入URL到頁面顯示發生了什么？

?????????HTTP URL (是一種特殊類型URI，包含了用于查找某個資源的足夠的信息)格式如下：
http://host[":"port][abs_path]
????????HTTP表示要通過HTTP協議來定位網絡資源；host表示合法的Internet主機域名或者IP地址；port指定一個端口號，為空則使用缺省端口80；abs_path指定請求資源URI；如果URL中沒有給出abs_path，那么當它作為請求URI時，必須以“/”形式給出，通常這個工作瀏覽器自動幫我們完成。
eg:
1、輸入：www.guet.edu.cn
瀏覽器自動轉換成：桂林電子科技大學
2、http:192.168.0.116:8080/index.jsp?

?????????當年 HTTP 協議的出現主要是為了解決文本傳輸的難題。由于協議本身非常簡單，于是在此基礎上設想了很多應用方法并投入了實際使用。現在 HTTP 協議已經超出了 Web 這個框架的局限，被運用到了各種場景里。

?????????起始行開頭的GET表示請求訪問服務器的類型，稱為方法（method）。隨后的字符串 /index.htm 指明了請求訪問的資源對象?也叫做請求 URI（request-URI）。最后的 HTTP/1.1即 HTTP 版本號，用來提示客戶端使用的 HTTP 協議功能。

? ????????綜合來看，這段請求內容的意思是：請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源。請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。

三、HTTP報文

? ? ? ?在接收和解釋請求消息后，服務器返回一個HTTP響應消息。HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文。用于 HTTP 協議交互的信息被稱為 HTTP 報文。請求端（客戶端）HTTP 報文叫做請求報文，響應端（服務器端）叫做響應報文。 HTTP 報文本身是由多行（用 CR+LF 作換行符）數據構成的字符串文本。 HTTP 報文大致可分為報文首部和報文主體兩塊。兩者由最初出現的空行（CR+LF）來劃分。通常并不一定要有報文主體。

?????????請求報文和響應報文的首部內容由以下數據組成。請求行包含用于請求的方法，請求 URI 和 HTTP 版本。狀態行包含表明響應結果的狀態碼，原因短語和 HTTP 版本。首部字段包含表示請求和響應的各種條件和屬性的各類首部。一般有 4 種首部，分別是：通用首部、請求首部、響應首部和實體首部。其他可能包含 HTTP 的 RFC 里未定義的首部（Cookie 等）。

?????????HTTP 在傳輸數據時可以按照數據原貌直接傳輸，但也可以在傳輸過程中通過編碼提升傳輸速率。通過在傳輸時編碼，能有效地處理大量的訪問請求。但是，編碼的操作需要計算機來完成，因此會消耗更多的 CPU 等資源。

四、HTTP協議詳解之消息報頭篇

? ? ? HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對于請求消息開始行就是請求行，對于響應消息開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。每一個報頭域都是由名字+“：”+空格+值組成，消息報頭域的名字是大小寫無關的。

1、普通報頭
????????在普通報頭中，有少數報頭域用于所有的請求和響應消息，但并不用于被傳輸的實體，只用于傳輸的消息。eg：
Cache-Control?? 用于指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另一個消息處理的緩存機制），HTTP1.0使用的類似的報頭域為Pragma。
請求時的緩存指令包括：no-cache（用于指示請求或響應消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
響應時的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：為了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序可以編寫如下：response.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache");作用相當于上述代碼，通常兩者//合用
這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cacheDate普通報頭域表示消息產生的日期和時間Connection普通報頭域允許發送指定連接的選項。例如指定連接是連續，或者指定“close”選項，通知服務器，在響應完成后，關閉連接

2、請求報頭
????????請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
常用的請求報頭
Accept請求報頭域用于指定客戶端接受哪些類型的信息。eg：Accept：image/gif，表明客戶端希望接受GIF圖象格式的資源；Accept：text/html，表明客戶端希望接受html文本。
Accept-Charset請求報頭域用于指定客戶端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域，缺省是任何字符集都可以接受。
Accept-Encoding請求報頭域類似于Accept，但是它是用于指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.如果請求消息中沒有設置這個域服務器假定客戶端對各種內容編碼都可以接受。
Accept-Language請求報頭域類似于Accept，但是它是用于指定一種自然語言。eg：Accept-Language:zh-cn.如果請求消息中沒有設置這個報頭域，服務器假定客戶端對各種語言都可以接受。
Authorization請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。
Host（發送請求時，該報頭域是必需的）請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的，eg：
我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html
瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：
Host：www.guet.edu.cn
此處使用缺省端口號80，若指定了端口號，則變成：Host：www.guet.edu.cn:指定端口號
User-Agent
我們上網登陸論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息。User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。不過，這個報頭域不是必需的，如果我們自己編寫一個瀏覽器，不使用User-Agent請求報頭域，那么服務器端就無法得知我們的信息了。
請求報頭舉例：
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)

3、響應報頭
響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關于服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。
常用的響應報頭
Location響應報頭域用于重定向接受者到一個新位置。Location響應報頭域常用在更換域名時候。
Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是Server響應報頭域的一個例子：
Server：Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate響應報頭域必須被包含在401（未授權的）響應消息中，客戶端收到401響應消息時候，并發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。eg：WWW-Authenticate:Basic realm="Basic Auth Test!"? //可以看出服務器對請求資源采用的是基本驗證機制。

4、實體報頭
請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但并不是說實體報頭域和實體正文要在一起發送，可以只發送實體報頭域。實體報頭定義了關于實體正文（eg：有無實體正文）和請求所標識的資源的元信息。
常用的實體報頭
Content-Encoding實體報頭域被用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應的解碼機制。Content-Encoding這樣用于記錄文檔的壓縮方法，eg：Content-Encoding：gzip
Content-Language實體報頭域描述了資源所用的自然語言。沒有設置該域則認為實體內容將提供給所有的語言閱讀者。eg：Content-Language:da
Content-Length實體報頭域用于指明實體正文的長度，以字節方式存儲的十進制數字來表示。
Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。eg：
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified實體報頭域用于指示資源的最后修改日期和時間。
Expires實體報頭域給出響應過期的日期和時間。為了讓代理服務器或瀏覽器在一段時間以后更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載，縮短響應時間和降低服務器負載)的頁面，我們可以使用Expires實體報頭域指定頁面過期的時間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客戶端和緩存必須將其他非法的日期格式（包括0）看作已經過期。eg：為了讓瀏覽器不要緩存頁面，我們也可以利用Expires實體報頭域，設置為0，jsp中程序如下：response.setDateHeader("Expires","0");

四、HTTP 協議瓶頸

????????在 Facebook 和 Twitter 等 SNS 網站上，幾乎能夠實時觀察到海量用戶公開發布的內容，這也是一種樂趣。當幾百、幾千萬的用戶發布內容時，Web 網站為了保存這些新增內容，在很短的時間內就會發生大量的內容更新。為了盡可能實時地顯示這些更新的內容，服務器上一有內容更新，就需要直接把那些內容反饋到客戶端的界面上。雖然看起來挺簡單的，但 HTTP 卻無法妥善地處理好這項任務。使用 HTTP 協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。如果服務器上沒有內容更新，那么就會產生徒勞的通信。若想在現有 Web 實現所需的功能，以下這些 HTTP 標準就會成為瓶頸。

五、HTTP協議相關技術補充

??? 1、基礎：
??? 高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等
中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)，一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過 URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，并且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一個中介(例如：防火墻等)或者是中介不能識別消息的內容時，通道經常被使用。
???? 代理(Proxy)：一個中間程序，它可以充當一個服務器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的服務器中。一個代理在發送請求信息之前，必須解釋并且如果可能重寫它。代理經常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。
網關(Gateway)：一個作為其它服務器中間媒介的服務器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源服務器；發出請求的客戶機并沒有意識到它在同網關打交道。
網關經常作為通過防火墻的服務器端的門戶，網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。
??? 通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。

2、協議分析的優勢—HTTP分析器檢測網絡攻擊
????????以模塊化的方式對高層協議進行分析處理，將是未來入侵檢測的方向。
HTTP及其代理的常用端口80、3128和8080在network部分用port標簽進行了規定

3、HTTP協議Content Lenth限制漏洞導致拒絕服務攻擊
????????使用POST方法時，可以設置ContentLenth來定義需要傳送的數據長度，例如ContentLenth:999999999，在傳送完成前，內存不會釋放，攻擊者可以利用這個缺陷，連續向WEB服務器發送垃圾數據直至WEB服務器內存耗盡。這種攻擊方法基本不會留下痕跡。
http://www.cnpaf.net/Class/HTTP/0532918532667330.html

4、利用HTTP協議的特性進行拒絕服務攻擊的一些構思
????????服務器端忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱作：服務器端受到了SYNFlood攻擊（SYN洪水攻擊）。
而Smurf、TearDrop等是利用ICMP報文來Flood和IP碎片攻擊的。本文用“正常連接”的方法來產生拒絕服務攻擊。
????????19端口在早期已經有人用來做Chargen攻擊了，即Chargen_Denial_of_Service，但是！他們用的方法是在兩臺Chargen 服務器之間產生UDP連接，讓服務器處理過多信息而DOWN掉，那么，干掉一臺WEB服務器的條件就必須有2個：1.有Chargen服務2.有HTTP 服務
方法：攻擊者偽造源IP給N臺Chargen發送連接請求（Connect），Chargen接收到連接后就會返回每秒72字節的字符流（實際上根據網絡實際情況，這個速度更快）給服務器。

5、Http指紋識別技術
?? Http指紋識別的原理大致上也是相同的：記錄不同服務器對Http協議執行中的微小差別進行識別.Http指紋識別比TCP/IP堆棧指紋識別復雜許多,理由是定制Http服務器的配置文件、增加插件或組件使得更改Http的響應信息變的很容易,這樣使得識別變的困難；然而定制TCP/IP堆棧的行為需要對核心層進行修改,所以就容易識別.
????? 要讓服務器返回不同的Banner信息的設置是很簡單的,象Apache這樣的開放源代碼的Http服務器,用戶可以在源代碼里修改Banner信息,然后重起Http服務就生效了；對于沒有公開源代碼的Http服務器比如微軟的IIS或者是Netscape,可以在存放Banner信息的Dll文件中修改,相關的文章有討論的,這里不再贅述,當然這樣的修改的效果還是不錯的.另外一種模糊Banner信息的方法是使用插件。
常用測試請求：
1：HEAD/Http/1.0發送基本的Http請求
2：DELETE/Http/1.0發送那些不被允許的請求,比如Delete請求
3：GET/Http/3.0發送一個非法版本的Http協議請求
4：GET/JUNK/1.0發送一個不正確規格的Http協議請求
Http指紋識別工具Httprint,它通過運用統計學原理,組合模糊的邏輯學技術,能很有效的確定Http服務器的類型.它可以被用來收集和分析不同Http服務器產生的簽名。

6、其他

????????為了提高用戶使用瀏覽器時的性能，現代瀏覽器還支持并發的訪問方式，瀏覽一個網頁時同時建立多個連接，以迅速獲得一個網頁上的多個圖標，這樣能更快速完成整個網頁的傳輸。
HTTP1.1中提供了這種持續連接的方式，而下一代HTTP協議：HTTP-NG更增加了有關會話控制、豐富的內容協商等方式的支持，來提供
更高效率的連接。

六、利用telnet觀察http協議通訊過程

??? 利用MS的telnet工具，通過手動輸入http請求信息的方式，向服務器發出請求，服務器接收、解釋和接受請求后，會返回一個響應，該響應會在telnet窗口上顯示出來，從而從感性上加深對http協議的通訊過程的認識。

??? 實驗步驟：

1、打開telnet
1.1 打開telnet
運行-->cmd-->telnet

1.2 打開telnet回顯功能
set localecho

2、連接服務器并發送請求
2.1 open?www.guet.edu.cn?80? //注意端口號不能省略

??? HEAD /index.asp HTTP/1.0
??? Host:www.guet.edu.cn
????
?? /*我們可以變換請求方法,請求桂林電子主頁內容,輸入消息如下*/
??? open?www.guet.edu.cn?80?
???
??? GET /index.asp HTTP/1.0? //請求資源的內容
??? Host:www.guet.edu.cn??

2.2 open?www.sina.com.cn?80? //在命令提示符號下直接輸入telnet?www.sina.com.cn?80
??? HEAD /index.asp HTTP/1.0
??? Host:www.sina.com.cn
?

3 實驗結果：

3.1 請求信息2.1得到的響應是:

HTTP/1.1 200 OK????????????????????????????????????????????? //請求成功
Server: Microsoft-IIS/5.0??????????????????????????????????? //web服務器
Date: Thu,08 Mar 200707:17:51 GMT
Connection: Keep-Alive?????????????????????????????????
Content-Length: 23330
Content-Type: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private

//資源內容省略

3.2 請求信息2.2得到的響應是:

HTTP/1.0 404 Not Found?????? //請求失敗
Date: Thu, 08 Mar 2007 07:50:50 GMT
Server: Apache/2.0.54 <Unix>
Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
ETag: "6277a-415-e7c76980"
Accept-Ranges: bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-Cache: MISS from zjm152-78.sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
X-Cache: MISS from th-143.sina.com.cn
Connection: close
失去了跟主機的連接，按任意鍵繼續...

4 .注意事項：

????????出現輸入錯誤，則請求不會成功。報頭域不分大小寫。更深一步了解HTTP協議，可以查看RFC2616，在http://www.letf.org/rfc上找到該文件。開發后臺程序必須掌握http協議。

七、HTTP和HTTPS區別

????????HTTP（Hypertext Transfer Protocol）和HTTPS（Hypertext Transfer Protocol Secure）是用于在 Web 瀏覽器和服務器之間傳輸數據的協議。它們之間的主要區別如下：

安全性：HTTPS 是由 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）協議加密的 HTTP。這意味著通過 HTTPS 傳輸的數據在傳輸過程中是加密的，因此更安全。而 HTTP 不加密數據，信息在傳輸過程中容易被竊聽、篡改和偽造。
端口號：HTTP 默認使用端口號80進行通信，而 HTTPS 默認使用端口號443。這意味著在瀏覽器地址欄不指定端口號的情況下，訪問網站時，如果使用 HTTP，則會默認使用端口號80，如果使用 HTTPS，則會默認使用端口號443。
證書：HTTPS 需要使用 SSL/TLS 證書來進行身份驗證，確保與服務器建立的連接是可信的。這樣用戶可以驗證服務器的身份，并確保其與目標網站進行加密通信。而 HTTP 不需要證書，通信過程沒有對服務器進行身份驗證的機制。

????????總的來說，HTTPS 比 HTTP 更加安全，適用于需要保護敏感信息（如個人資料、信用卡信息等）的網站。因此，許多網站選擇使用 HTTPS 來確保數據的保密性和完整性。

那現在有了https還有使用http的場景嗎

是的，雖然 HTTPS 提供了更高的安全性和數據保護，但仍然存在一些使用 HTTP 的場景。以下是一些可能繼續使用 HTTP 的情況：

非敏感數據傳輸：對于不涉及敏感信息或用戶隱私的簡單信息傳輸場景，如新聞網站、博客等，使用 HTTP 可以提供更快的訪問速度和較低的消耗。
非公開頁面或內部網絡：在某些情況下，內部網絡或非公開頁面可能不需要進行加密傳輸，因為傳輸內容已經受到其他安全措施的保護。
資源鏈接：當網頁上存在指向非加密資源（如圖片、CSS 文件、JavaScript 文件等）的鏈接時，這些資源可能仍然使用 HTTP。這是因為瀏覽器會阻止通過 HTTPS 網頁加載非加密資源，稱為 "混合內容"，因為這可能會降低 HTTPS 的安全性。

????????盡管如此，隨著互聯網安全意識的提高，越來越多的網站正在轉向使用 HTTPS 來保護用戶隱私和確保數據的機密性。大多數網站都會選擇全面采用 HTTPS，以提供更安全的用戶體驗。

SDK是什么，SDK和api有什么區別

SDK（Software Development Kit）是一種開發工具包，通常由軟件開發公司或平臺提供，用于幫助開發人員構建、測試和集成特定平臺或軟件的應用程序。SDK 包含一系列的庫、工具、示例代碼和文檔，旨在簡化開發過程并提供所需的資源和功能。

API（Application Programming Interface）是一組定義了不同軟件組件之間交互方式的規范和接口。API 允許不同的應用程序之間相互通信和數據交換。它定義了請求和響應的消息格式、數據結構和協議規則，以便應用程序可以通過 API 發送請求并獲得所需的響應。

區別如下：