http協(xié)議特點(diǎn)

HTTP協(xié)議的主要特點(diǎn)可概括如下:

1.支持客戶/服務(wù)器模式乏德。

2.簡單快速:客戶向服務(wù)器請求服務(wù)時(shí),只需傳送請求方法和路徑啸驯。請求方法常用的有GET、HEAD祟峦、POST罚斗。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單宅楞,使得HTTP服務(wù)器的程序規(guī)模小针姿,因而通信速度很快。

3.靈活:HTTP允許傳輸任意類型的數(shù)據(jù)對象厌衙。正在傳輸?shù)念愋陀蒀ontent-Type(Content-Type是HTTP包中用來表示內(nèi)容類型的標(biāo)識(shí))加以標(biāo)記距淫。

4.無連接:無連接的含義是限制每次連接只處理一個(gè)請求。服務(wù)器處理完客戶的請求婶希,并收到客戶的應(yīng)答后榕暇,即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間喻杈。

5.無狀態(tài):HTTP協(xié)議是無狀態(tài)協(xié)議拐揭。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息奕塑,則它必須重傳,這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大家肯。另一方面龄砰,在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

Http報(bào)文組成部分

對報(bào)文進(jìn)行描述的起始行(start line)、
包含屬性的首部(header)塊换棚,
以及可選的式镐、包含數(shù)據(jù)的主體(body)部分。

http 請求方法
http請求由三部分組成固蚤,分別是:請求行娘汞、消息報(bào)頭、請求正文

1夕玩、請求行以一個(gè)方法符號(hào)開頭你弦,以空格分開,后面跟著請求的URI和協(xié)議的版本燎孟,格式如下:Method Request-URI HTTP-Version CRLF

其中 Method表示請求方法禽作;Request-URI是一個(gè)統(tǒng)一資源標(biāo)識(shí)符;HTTP-Version表示請求的HTTP協(xié)議版本揩页;CRLF表示回車和換行(除了作為結(jié)尾的CRLF外旷偿,不允許出現(xiàn)單獨(dú)的CR或LF字符)。

請求方法(所有方法全為大寫)有多種爆侣,各個(gè)方法的解釋如下:

GET 請求獲取Request-URI所標(biāo)識(shí)的資源
POST 在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)
HEAD 請求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭
PUT 請求服務(wù)器存儲(chǔ)一個(gè)資源萍程,并用Request-URI作為其標(biāo)識(shí)
DELETE 請求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源
TRACE 請求服務(wù)器回送收到的請求信息,主要用于測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢服務(wù)器的性能兔仰,或者查詢與資源相關(guān)的選項(xiàng)和需求

http請求中g(shù)et和post的區(qū)別

GET在瀏覽器回退時(shí)是無害的茫负,而POST會(huì)再次提交請求。
GET產(chǎn)生的URL地址可以被Bookmark斋陪,而POST不可以朽褪。
GET請求會(huì)被瀏覽器主動(dòng)cache,而POST不會(huì)无虚,除非手動(dòng)設(shè)置缔赠。
GET請求只能進(jìn)行url編碼,而POST支持多種編碼方式友题。
GET請求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里嗤堰,而POST中的參數(shù)不會(huì)被保留。
GET請求在URL中傳送的參數(shù)是有長度限制的度宦,而POST么有踢匣。
對參數(shù)的數(shù)據(jù)類型,GET只接受ASCII字符戈抄,而POST沒有限制离唬。
GET比POST更不安全,因?yàn)閰?shù)直接暴露在URL上划鸽,所以不能用來傳遞敏感信息输莺。
GET參數(shù)通過URL傳遞戚哎,POST放在Request body中。

http狀態(tài)碼

1** 信息嫂用,服務(wù)器收到請求型凳,需要請求者繼續(xù)執(zhí)行操作
2** 成功,操作被成功接收并處理
3** 重定向嘱函,需要進(jìn)一步的操作以完成請求
4** 客戶端錯(cuò)誤甘畅,請求包含語法錯(cuò)誤或無法完成請求
5** 服務(wù)器錯(cuò)誤,服務(wù)器在處理請求的過程中發(fā)生了錯(cuò)誤

100 繼續(xù)往弓,客戶端應(yīng)繼續(xù)其請求
101 切換協(xié)議疏唾。服務(wù)器根據(jù)客戶端的請求切換協(xié)議。只能切換到更高級的協(xié)議亮航,例如荸实,切換到HTTP的新版本協(xié)議
200 OK,請求成功缴淋。一般用于GET與POST請求
201 已創(chuàng)建准给。成功請求并創(chuàng)建了新的資源
202 已接受。已經(jīng)接受請求重抖,但未處理完成
203 非授權(quán)信息露氮。請求成功。但返回的meta信息不在原始的服務(wù)器钟沛,而是一個(gè)副本
204 無內(nèi)容畔规。服務(wù)器成功處理,但未返回內(nèi)容恨统。在未更新網(wǎng)頁的情況下叁扫,可確保瀏覽器繼續(xù)顯示當(dāng)前文檔
205 重置內(nèi)容。服務(wù)器處理成功畜埋,用戶終端(例如:瀏覽器)應(yīng)重置文檔視圖莫绣。可通過此返回碼清除瀏覽器的表單域
206 部分內(nèi)容悠鞍。服務(wù)器成功處理了部分GET請求
300 多種選擇对室。請求的資源可包括多個(gè)位置,相應(yīng)可返回一個(gè)資源特征與地址的列表用于用戶終端(例如:瀏覽器)選擇
301 永久移動(dòng)咖祭。請求的資源已被永久的移動(dòng)到新URI掩宜,返回信息會(huì)包括新的URI,瀏覽器會(huì)自動(dòng)定向到新URI么翰。今后任何新的請求都應(yīng)使用新的URI代替
302 臨時(shí)移動(dòng)牺汤。與301類似。但資源只是臨時(shí)被移動(dòng)浩嫌』哿觯客戶端應(yīng)繼續(xù)使用原有URI
303 查看其它地址戴已。與301類似。使用GET和POST請求查看
304 未修改锅减。所請求的資源未修改,服務(wù)器返回此狀態(tài)碼時(shí)伐坏,不會(huì)返回任何資源怔匣。客戶端通常會(huì)緩存訪問過的資源桦沉,通過提供一個(gè)頭信息指出客戶端希望只返回在指定日期之后修改的資源
305 使用代理每瞒。所請求的資源必須通過代理訪問
306 已經(jīng)被廢棄的HTTP狀態(tài)碼
307 臨時(shí)重定向。與302類似纯露。使用GET請求重定向
400 客戶端請求的語法錯(cuò)誤剿骨,服務(wù)器無法理解
401 請求要求用戶的身份認(rèn)證
402 保留,將來使用
403 服務(wù)器理解請求客戶端的請求埠褪,但是拒絕執(zhí)行此請求
404 服務(wù)器無法根據(jù)客戶端的請求找到資源(網(wǎng)頁)浓利。通過此代碼,網(wǎng)站設(shè)計(jì)人員可設(shè)置"您所請求的資源無法找到"的個(gè)性頁面
405 客戶端請求中的方法被禁止
406 服務(wù)器無法根據(jù)客戶端請求的內(nèi)容特性完成請求
407 請求要求代理的身份認(rèn)證钞速,與401類似贷掖,但請求者應(yīng)當(dāng)使用代理進(jìn)行授權(quán)
408 服務(wù)器等待客戶端發(fā)送的請求時(shí)間過長,超時(shí)
409 服務(wù)器完成客戶端的 PUT 請求時(shí)可能返回此代碼渴语,服務(wù)器處理請求時(shí)發(fā)生了沖突
410 客戶端請求的資源已經(jīng)不存在苹威。410不同于404,如果資源以前有現(xiàn)在被永久刪除了可使用410代碼驾凶,網(wǎng)站設(shè)計(jì)人員可通過301代碼指定資源的新位置
411 服務(wù)器無法處理客戶端發(fā)送的不帶Content-Length的請求信息
412 客戶端請求信息的先決條件錯(cuò)誤
413 由于請求的實(shí)體過大牙甫,服務(wù)器無法處理,因此拒絕請求调违。為防止客戶端的連續(xù)請求窟哺,服務(wù)器可能會(huì)關(guān)閉連接。如果只是服務(wù)器暫時(shí)無法處理翰萨,則會(huì)包含一個(gè)Retry-After的響應(yīng)信息
414 請求的URI過長(URI通常為網(wǎng)址)脏答,服務(wù)器無法處理
415 服務(wù)器無法處理請求附帶的媒體格式
416 客戶端請求的范圍無效
417 服務(wù)器無法滿足Expect的請求頭信息
500 服務(wù)器內(nèi)部錯(cuò)誤,無法完成請求
501 服務(wù)器不支持請求的功能亩鬼,無法完成請求
502 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時(shí)殖告,從遠(yuǎn)程服務(wù)器接收到了一個(gè)無效的響應(yīng)
503 由于超載或系統(tǒng)維護(hù),服務(wù)器暫時(shí)的無法處理客戶端的請求雳锋。延時(shí)的長度可包含在服務(wù)器的Retry-After頭信息中
504 充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器黄绩,未及時(shí)從遠(yuǎn)端服務(wù)器獲取請求
505 服務(wù)器不支持請求的HTTP協(xié)議的版本,無法完成處理

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末玷过,一起剝皮案震驚了整個(gè)濱河市爽丹,隨后出現(xiàn)的幾起案子筑煮,更是在濱河造成了極大的恐慌,老刑警劉巖粤蝎,帶你破解...
    沈念sama閱讀 216,997評論 6 502
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件真仲,死亡現(xiàn)場離奇詭異,居然都是意外死亡初澎,警方通過查閱死者的電腦和手機(jī)秸应,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,603評論 3 392
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來碑宴,“玉大人软啼,你說我怎么就攤上這事⊙幽” “怎么了祸挪?”我有些...
    開封第一講書人閱讀 163,359評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長贞间。 經(jīng)常有香客問我贿条,道長,這世上最難降的妖魔是什么榜跌? 我笑而不...
    開封第一講書人閱讀 58,309評論 1 292
  • 正文 為了忘掉前任闪唆,我火速辦了婚禮,結(jié)果婚禮上钓葫,老公的妹妹穿的比我還像新娘悄蕾。我一直安慰自己,他們只是感情好础浮,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,346評論 6 390
  • 文/花漫 我一把揭開白布帆调。 她就那樣靜靜地躺著,像睡著了一般豆同。 火紅的嫁衣襯著肌膚如雪番刊。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,258評論 1 300
  • 那天影锈,我揣著相機(jī)與錄音芹务,去河邊找鬼。 笑死鸭廷,一個(gè)胖子當(dāng)著我的面吹牛枣抱,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播辆床,決...
    沈念sama閱讀 40,122評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼佳晶,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了讼载?” 一聲冷哼從身側(cè)響起轿秧,我...
    開封第一講書人閱讀 38,970評論 0 275
  • 序言:老撾萬榮一對情侶失蹤中跌,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后菇篡,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體漩符,經(jīng)...
    沈念sama閱讀 45,403評論 1 313
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,596評論 3 334
  • 正文 我和宋清朗相戀三年驱还,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了陨仅。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,769評論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡铝侵,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出触徐,到底是詐尸還是另有隱情咪鲜,我是刑警寧澤,帶...
    沈念sama閱讀 35,464評論 5 344
  • 正文 年R本政府宣布撞鹉,位于F島的核電站疟丙,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏鸟雏。R本人自食惡果不足惜享郊,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,075評論 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望孝鹊。 院中可真熱鬧炊琉,春花似錦、人聲如沸又活。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,705評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽柳骄。三九已至团赏,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間耐薯,已是汗流浹背舔清。 一陣腳步聲響...
    開封第一講書人閱讀 32,848評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留曲初,地道東北人体谒。 一個(gè)月前我還...
    沈念sama閱讀 47,831評論 2 370
  • 正文 我出身青樓,卻偏偏與公主長得像复斥,于是被迫代替她去往敵國和親营密。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,678評論 2 354

推薦閱讀更多精彩內(nèi)容

  • 引言 HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議目锭,由于其簡捷评汰、快速的方式纷捞,適用于分布式超媒體信息系統(tǒng)。它于1990年...
    Amom_dong閱讀 6,087評論 1 3
  • (原話)談?wù)剬TTP協(xié)議的理解:超文本傳輸協(xié)議,應(yīng)用于OSI網(wǎng)絡(luò)模型中的應(yīng)用層惨缆,是用于服務(wù)器傳輸超文本到本地瀏覽...
    24_yu閱讀 885評論 0 1
  • 深入淺出HTTP協(xié)議(WEB開發(fā)和面試必備) 1.基礎(chǔ)概念篇 a.簡介 HTTP是Hyper Text Trans...
    半世韶華憶闌珊閱讀 1,221評論 0 7
  • API定義規(guī)范 本規(guī)范設(shè)計(jì)基于如下使用場景: 請求頻率不是非常高:如果產(chǎn)品的使用周期內(nèi)請求頻率非常高糜值,建議使用雙通...
    有涯逐無涯閱讀 2,539評論 0 6
  • http協(xié)議有http0.9,http1.0坯墨,http1.1和http2三個(gè)版本寂汇,但是現(xiàn)在瀏覽器使用的是htt...
    一現(xiàn)_閱讀 1,863評論 0 3