該文章為轉(zhuǎn)載棕洋，如有侵權(quán) 請聯(lián)系本人郵箱：bxf0321@qq.com
說說http協(xié)議的一些特點：
1）無狀態(tài)
http協(xié)議是一種自身不對請求和響應之間的通信狀態(tài)進行保存的協(xié)議，即無狀態(tài)協(xié)議足画。
這種設置的好處是：更快的處理更多的請求事務蔫耽，確保協(xié)議的可伸縮性
不過隨著web的不斷發(fā)展肌蜻，有時候外永，需要將這種狀態(tài)進行保持，隨即勘究，就引入了cookie技術(shù)勘畔，cookie技術(shù)通過在請求和響應報文中寫入cookie信息來控制客戶端的狀態(tài)。
有關(guān)cookie的內(nèi)容后面我們再說荧琼。譬胎。。
2）持久性
正常在發(fā)送http時命锄，都需要建立TCP的連接堰乔，再發(fā)送報文。
如果每次想要發(fā)送http報文都需要經(jīng)過這個過程脐恩，那么時間大部分都會消耗在建立和斷開連接的過程中镐侯。
因此http中使用了connection屬性，用于指定連接的方式驶冒。
當設置成keep-alive苟翻，http就會建立一條持久化的連接，不需要每次都建立連接骗污，再中斷崇猫。
這樣做的好處是：減輕了服務器端的負載，減少開銷的那部分時間需忿，使http請求和響應都能更快的結(jié)束诅炉，相應的，web頁面顯示速度也就相對提升了贴谎。
3）管線化
如果一個http請求汞扎，請求了大量的圖片等大文件季稳，那么其他的http請求怎么辦呢擅这？
現(xiàn)在，管線化技術(shù)的出現(xiàn)景鼠，使得http請求比持久性連接更要快仲翎；特點在于：請求數(shù)越多，時間差越明顯铛漓。
4）內(nèi)容編碼
由于某些報文的內(nèi)容過大溯香，因此在傳輸時，為了減少傳輸?shù)臅r間浓恶，會采取一些壓縮的措施玫坛。
例如上面的報文信息中，Accept-Encoding就定義了內(nèi)容編碼的格式：gzip
有下面幾種方式：
gzip：GNU壓縮格式
compress：UNIX系統(tǒng)的標準壓縮格式
deflate：是一種同時使用了LZ77和哈弗曼編碼的無損壓縮格式
identity：不進行壓縮
5）多部分對象集合
有的時候傳輸?shù)膬?nèi)容包晰，不僅僅是一些字符串湿镀，還有可能是一些圖片炕吸，字符，音樂二進制等混雜的內(nèi)容勉痴。
這就需要使用多部分對象集合赫模，multipart，例如在使用java編寫web上傳文件的代碼時蒸矛，需要在form中指定form的編碼格式瀑罗。
設置form的enctype屬性的值為multipart/form-data。
這是因為默認的情況下form使用的編碼格式是：applicatin/x-www-form-urlencoded雏掠，這種編碼格式會把所有的內(nèi)容進行編碼斩祭，不適合上傳文件這種情況。
這兩種編碼格式的區(qū)別主要是：
multipart/form-data 會以控件為基準磁玉，編碼form中的內(nèi)容停忿。
application/x-www-form-urlencoded 會把form中的內(nèi)容編碼成鍵值對的形式。
6）范圍請求
有些場景下蚊伞，http報文請求一些很大的圖片席赂，但是加載過程很慢。
比如我們登錄一些大圖片的網(wǎng)址时迫，會發(fā)現(xiàn)有時候圖片是一塊一塊加載的颅停。
這就是因為設置了http請求的長度，這樣就可以分塊的加載資源文件掠拳。
在請求報文中使用Range屬性癞揉，在響應報文中使用Content-Type屬性都可以指定一定字節(jié)范圍的http請求。
接下來溺欧，說說幾種http協(xié)議的數(shù)據(jù)傳輸方式
http協(xié)議的傳輸方式有很多種喊熟，處于安全考慮，常用的一般都是GET和POST兩種姐刁，先來介紹下這兩種
1）GET：獲取資源
GET方法用來請求訪問已被URL識別的資源
2）POST：傳輸實體主體
POST方法用來請求服務器傳輸信息實體的主體
GET和POST的區(qū)別：
首先芥牌，使用目標不同：GET方法只是用來查詢，不會對瀏覽器上的信息產(chǎn)生影響聂使，每次GET的方法都是相同的
其次壁拉，大小不同：GET是放在URL首部，因此大小隨著瀏覽器而定柏靶，而POST則是在報文中弃理，只要沒有具體限制，文件的大小是沒限制的
然后屎蜓，安全性不同：GET采用的是明文傳輸痘昌，而POST是放在報文內(nèi)部，無法看到
從使用場景的角度來說，一般像用戶注冊登錄這種信息都是私密的辆苔，采用POST笔诵，而針對查詢等，為了快速姑子，大多采用GET傳輸乎婿。
（關(guān)于關(guān)于GET和POST的區(qū)別，最近重新看了很多別人寫的博客啊資料什么的街佑，發(fā)現(xiàn)上面的解釋比較模糊谢翎，我就在下面的評論區(qū)里面將區(qū)別清晰的描述一下，當然沐旨，后面的博客也會詳細的解釋）
接下來介紹其他幾種數(shù)據(jù)傳輸方式：
3）PUT：傳輸文件
PUT要求在請求報文的主體中包含文件內(nèi)容森逮，然后保存到請求URL指定的位置
處于安全考慮，一般web網(wǎng)站不使用此方法磁携，若配合web的安全驗證機制褒侧，或者架構(gòu)采用REST標準的網(wǎng)站，就可能開放使用此方法
4）HEAD：獲得報文首部
HEAD和GET方法一樣谊迄，只不過不返回報文主體部分闷供，用于確認URI的有效性及資源更新的日期時間等
5）DELETE：刪除文件
DELETE是與PUT相反的方法，是按請求URI刪除指定的資源
處于安全考慮统诺，一般web網(wǎng)站不使用此方法歪脏，若配合web的安全驗證機制，或者架構(gòu)采用REST標準的網(wǎng)站粮呢，就可能開放使用此方法
6）OPTIONS：詢問支持的方法
用來查詢針對請求URI指定的資源支持的方法
7）TRACE：追蹤路徑
是讓web服務器端將之前的請求通信還回給客戶端的方法
發(fā)送請求時婿失，在Max-Frowards首部字段中填入數(shù)值，每經(jīng)過一個服務器端就-1啄寡，當數(shù)值為0時豪硅，停止傳輸，最后收到服務器返回狀態(tài)碼200 OK的響應
但是挺物，這種方法基本很少使用懒浮，而且很容易引起XST（跨站追蹤）攻擊，就更不會用到了姻乓。
8）CONNECT：要求采用隧道協(xié)議連接代理
該方法要求在于代理服務器通信時建立隧道嵌溢，實現(xiàn)用隧道協(xié)議進行TCP通信眯牧，主要使用SSL（安全套接層）和TLS（傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)過網(wǎng)絡傳輸蹋岩。
最后，附上一張http1.1和http1.0版本各自支持的方法学少，另外剪个，注意用大寫。版确。扣囊。乎折。。侵歇。
其中骂澄，LINK和UNLINK已被HTTP1.1廢棄，不再支持惕虑！
