HTTP協(xié)議

HTTP 協(xié)議簡介

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協(xié)議融师。

HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結果等）。

請求響應模型

image

主要特點

支持客戶/服務器模式牍帚。
簡單快速：客戶向服務器請求服務時腐螟，只需傳送請求方法和路徑悍缠。請求方法常用的有GET脑漫、HEAD秸仙、POST。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同胜榔。由于HTTP協(xié)議簡單胳喷，使得HTTP服務器的程序規(guī)模小，因而通信速度很快夭织。
靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象吭露，通過Content-Type 標記傳輸?shù)臄?shù)據(jù)類型。
無連接：無連接的含義是限制每次連接只處理一個請求尊惰。服務器處理完客戶的請求讲竿，并收到客戶的應答后泥兰，即斷開連接。采用這種方式可以節(jié)省傳輸時間题禀。

早期這么做的原因是 HTTP 協(xié)議產生于互聯(lián)網鞋诗，因此服務器需要處理同時面向全世界數(shù)十萬、上百萬客戶端的網頁訪問迈嘹，但每個客戶端（即瀏覽器）與服務器之間交換數(shù)據(jù)的間歇性較大（即傳輸具有突發(fā)性削彬、瞬時性），并且網頁瀏覽的聯(lián)想性秀仲、發(fā)散性導致兩次傳送的數(shù)據(jù)關聯(lián)性很低吃警，大部分通道實際上會很空閑、無端占用資源啄育。因此 HTTP 的設計者有意利用這種特點將協(xié)議設計為請求時建連接酌心、請求完釋放連接，以盡快將資源釋放出來服務其他客戶端挑豌。

隨著時間的推移安券，網頁變得越來越復雜，里面可能嵌入了很多圖片氓英，這時候每次訪問圖片都需要建立一次 TCP 連接就顯得很低效侯勉。后來，Keep-Alive 被提出用來解決這效率低的問題铝阐。

Keep-Alive 功能使客戶端到服務器端的連接持續(xù)有效址貌，當出現(xiàn)對服務器的后繼請求時，Keep-Alive 功能避免了建立或者重新建立連接徘键。（對于提供靜態(tài)內容的網站來說练对，這個功能通常很有用。但是吹害，對于負擔較重的網站來說螟凭，這里存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能它呀，因為在處理暫停期間螺男，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一臺機器上運行時纵穿，Keep-Alive 功能對資源利用的影響尤其突出下隧。）
無狀態(tài)：是指協(xié)議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態(tài)谓媒。即我們給服務器發(fā)送 HTTP 請求之后淆院，服務器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來篙耗，但是迫筑，發(fā)送完，不會記錄任何信息宗弯。

于是脯燃，兩種用于保持 HTTP 連接狀態(tài)的技術就應運而生了，一個是 Cookie蒙保，而另一個則是 Session辕棚。

HTTP請求響應頭(常規(guī))

請求

host: 客戶端訪問的服務器主機地址。

Method：請求方法

User-Agent:客戶端類型邓厕、客戶端的軟件環(huán)境

Accept：客戶端所能接收的數(shù)據(jù)類型

Accept-Language: 客戶端的語言環(huán)境

Accept-Encoding: 客戶端支持的數(shù)據(jù)壓縮格式
響應

Server: 服務器的類型

Status: 響應狀態(tài)碼

Content-Type：返回數(shù)據(jù)的類型

Content-Length: 返回的數(shù)據(jù)長度

Date:響應的時間

HTTP的3次握手和4次揮手

由于HTTP是基于TCP之上的協(xié)議逝嚎，所以這里先了解一些字段標識。

在TCP 層详恼，有個FLAGS字段补君，這個字段有以下幾個標識：

SYN: 表示建立連接。

FIN：表示關閉連接昧互。

ACK：表示響應挽铁。

PSH：表示有DATA數(shù)據(jù)傳輸。當發(fā)送端將PSH置為1時敞掘，TCP會立即創(chuàng)建一個報文并發(fā)送叽掘，接受端收到PSH為1的報文后就立即將接受緩沖區(qū)內數(shù)據(jù)向上交付給應用程序，而不是等待緩沖區(qū)滿后再交付玖雁。

RST：表示連接重置更扁。

URG：緊急標識位。

seq (sequence number): 表示的是我方（發(fā)送方）這邊赫冬，這個packet的數(shù)據(jù)部分的第一位應該在整個data stream中所在的位置浓镜。（注意這里使用的是“應該”。因為對于沒有數(shù)據(jù)的傳輸劲厌，如ACK竖哩，雖然它有一個seq，但是這次傳輸在整個data stream中是不占位置的脊僚。所以下一個實際有數(shù)據(jù)的傳輸相叁，會依舊從上一次發(fā)送ACK的數(shù)據(jù)包的seq開始）。

ack(acknowledge number)：表示的是期望的對方（接收方）的下一次sequence number是多少辽幌。

日常分析有用的就是前五個增淹。其中ACK可與SYN，F(xiàn)IN同時使用乌企。

3次握手

(1)：Client發(fā)送SYN=1虑润，隨機產生seq number=x的數(shù)據(jù)包到服務器，Server有SYN=1知道需要建立連接加酵；

(2)：Server收到請求后需要確認連接信息拳喻，向Client 發(fā)送ack number =x+1 (client的seq+1)哭当，SYN=1，ACK=1冗澈，隨機產生seq=y的包钦勘。

(3)：Client收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1亚亲，以及位碼ack是否為1彻采，若正確，Client會再發(fā)送ack number=y+1(Server的seq+1)捌归，ACK=1肛响，Server收到確認seq值和ACK=1則建立連接。

此時惜索，Client向Server發(fā)出確認后特笋，Client的TCP通知上層應用進程，連接已建立巾兆。Server收到Client的確認后雹有，也通知上層，TCP已連接臼寄。后面就可以進行數(shù)據(jù)傳輸了霸奕。

4次揮手

(1)：Client發(fā)出釋放連接的請求，F(xiàn)IN=1吉拳，其序列號為seq=u（等于前面已經傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1）质帅，此時，客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)留攒。 TCP規(guī)定煤惩，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號炼邀。

(2)：Server收到連接釋放報文魄揉，發(fā)出確認報文，ACK=1拭宁，ack=z+1洛退，并且?guī)献约旱男蛄刑杝eq=v，此時杰标，Server端就進入了CLOSE-WAIT（關閉等待）狀態(tài)兵怯。TCP服務器通知高層的應用進程，Client端向服務器的方向就釋放了腔剂，這時候處于半關閉狀態(tài)媒区，即客戶端已經沒有數(shù)據(jù)要發(fā)送了，但是服務器若發(fā)送數(shù)據(jù)，客戶端依然要接受袜漩。這個狀態(tài)還要持續(xù)一段時間绪爸，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

(3)：Client端收到服務器的確認請求后宙攻，此時奠货，Client端就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待Server發(fā)送連接釋放報文（在這之前還需要接受服務器發(fā)送的最后的數(shù)據(jù)）粘优。Server將最后的數(shù)據(jù)發(fā)送完畢后仇味，就向客戶端發(fā)送連接釋放報文呻顽，F(xiàn)IN=1雹顺，ack=z+1，由于在半關閉狀態(tài)廊遍，服務器很可能又發(fā)送了一些數(shù)據(jù)嬉愧，假定此時的序列號為seq=w，此時喉前，服務器就進入了LAST-ACK（最后確認）狀態(tài)没酣，等待客戶端的確認。

(4)：客戶端收到服務器的連接釋放報文后卵迂，必須發(fā)出確認裕便，ACK=1，ack=w+1见咒，而自己的序列號是seq=u+1偿衰，此時，客戶端就進入了TIME-WAIT（時間等待）狀態(tài)改览。注意此時TCP連接還沒有釋放下翎，必須經過2??MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后宝当，才進入CLOSED狀態(tài)视事。