快速理解 HTTP協議
應用層：http進行網絡傳輸/FTP/TELNET遠程登錄/SSH/DNS默認端口/pop3/smtp
傳輸層：TCP UDP
網絡層：IP
web訪問過程
1、客戶端用戶在瀏覽器中輸入某個url，形如http://www.baidu.com
2、客戶端操作系統做地址解析，dns解析。獲得目標服務器的ip地址
3、客戶端操作系統打開一個自由端口，向服務器發起連接請求
4、經過三次握手，服務器端確認與客戶端的鏈接，打開一個自由端口與該客戶端通信
5、客戶端開始發送請求數據----以4kb大小的一個又一個的請求數據包，這個過程稱爲HTTP Repuest包
爲什麼只有4k？ 因爲底層傳輸限制
6、服務器開始接收請求數據包，接收完成後，開始處理接收到的數據
這個過程叫做：Repuest handling 事件請求的一個處理
7、處理完成之後，服務器完成請求之後開始向客戶端發送響應數據，發送以4kb爲大小的響應數據
發送HTTP Response
8、響應結束之後，服務器和客戶端會經過4次握手，斷開鏈接，關閉各自的自由端口
HTTP協議
是TCP/IP協議棧/族中"應用層"的一個協議，用於在S(服務器)和C(B)(客戶端)之間傳遞超文本內容,(如HTML、js、css、音視頻),默認端口是80
HTTO1.0和1.1重要區別
HTTP 1.0 Offline 離線模式，表示斷開鏈接。
HTTP 1.1 Connection:Keep-Alive 保持連接一段時間
HTTP 0.9 只支持Get方法，不支持MIME(Multipurpose Internet Mail Extension多用途的互聯網郵件擴展),用於在電子郵件中指定附件文件類型的擴展表達方式
HTTP/1.0+ 支持持久鏈接、虛擬主機、代理連接等新特性，成爲非官方的標準
虛擬主機就是一臺服務器能跑很多的網站。
列舉HTTP協議1.1相較於HTTP/1.0的改進
支持持久連接、虛擬主機、代理連接
常見的 MIME 類型
MIME類型 後綴名是不可靠的
image/jpeg .jpg
image/jpeg .jpeg
text/html .htm
text/html .html
text/html .xhtml
謹記的數據格式
json數據格式：application/json
xml數據格式: application/xml
png:image/png
doc:application/msword
URL
URL語法：
URL完整格式：
😕/:
@:
/
:
js中的encodeURI()函數不會對 😕@;?#進行編碼
encodeURIComponent()函數會進行編碼
各參數詳解:
scheme:方案名/模式名，指定以哪種協議從服務器獲取指定資源；方案名不區分大小寫，常見方案：HTTP HTTPS FTP MAILTO RTSP FILE NEWS等
HOST:主機名，資源所在服務器的IP地址或者域名（需要DNS轉換成IPD地址）
PORT：端口號，沒項服務在服務器上都對應一個監聽端口號
嚴格來講，計算機中對外提供的服務程序可以綁定到任一端口上，從而實現監聽客戶端連接請求的任務
常見協議指定一些默認端口號，應努力避免混用
常見的服務器端口號
用戶名和密碼
USER:用戶名，某些方案訪問資源時需要指定用戶名 默認值爲anonymouse
pwd：密碼，默認爲地址
例如：ftp://admin:123@ip地址/adm/secret.xls
PATH：路徑，服務器上資源的本地名稱，由一個/將其分開
例如：ftp://admin:123@ip地址/admin/secret.xls 這其中的admin是虛擬路徑，虛擬路徑映射爲物理路徑，這個過程稱爲資源映射
PARAMS:參數，某些方案會使用參數來指定輸入參數，每個參數都採用"名/值對"形式，一個URL中可以有多個這樣的"名/值對"，使用分號（；）相隔
QUERY:查詢字符串,某些方案會使用查詢字符串傳遞參數以激活應用程序,使用?與其他組件分割
http://www.baidu.com/s?wd=js&issp=1&f=8 不能有中文不能有空格
FRAG:片段，也稱爲ANCHO（錨點）、TAG（標籤）指一個資源中某一個部分的名字。引用對象時，不用frag字段傳送給服務器，該字段是在客戶端內部
使用，通過#與其它部分分割
http://www.xiaoshuo.com/XiYouJi.html#chapeter8
HTTP協議詳解
請求與響應原理
Message:消息/報文,是在HTTP客戶端與服務器之間傳遞的數據塊 將是將4k 的數據塊進行拆分
HTTP協議規定，消息必須符合特定的格式才能彼此理解
Request Message：客戶端向服務器發送的請求消息
Reponse Message：服務器根據客戶端的請求消息,返回給客戶端的相應消息
消息/報文的組成?
Start Line：消息起始行,必須,消息的基本描述信息
（1）起始行 CRLF
（2）消息頭部/報頭 1CRLF
消息頭部/報頭 2CRLF
消息頭部/報頭 3CRLF
CRLF
（3）消息正文/主體CRLF
Header：消息頭部/報頭，可能有0~n個，消息詳細屬性
Body：消息主體，可選，包含數據主體
起始行和消息頭是純ASCLL字符,每行以CRLF結束
消息主體是一個可選的數據塊，其中的數據可以爲空，或者爲字符數據（如html、css、js等）或者二進制數據（圖片等）
HTTP消息結構概述
RFC：Request For Comment 一項協議在正式的發佈之前的專家制定的意見徵求稿
請求消息的三部分
（1）起始行/請求行
請求方法 空格 請求URI 空格 所用協議 CRLF
（2）消息頭部/請求頭部
（3）消息主體/請求正文
請求方法:指定了客戶端想對指定的資源/服務器做任何操作:可用的請求方法
-
GET 指明客戶端想從客戶端獲取指定的資源
-
POST指明客戶端想發送給服務器的一些數據
-
PUT 指明客戶端想讓服務器保存某個資源
-
DELETE 指明客戶端想讓服務器刪除某個資源
-
HEAD 指明客戶端只想查看指定資源的相應頭部信息,而不是資源本身
-
TRACE 客戶端可以對請求消息的傳輸路徑進行追蹤
-
OPTIONS 客戶端詢問服務器可以提交哪些請求方法
HEAD 只要資源本身,減少資源請求
PUT DELETE 有些服務器直接被禁用的
響應消息的三部分
(1)起始行/相應行
(2)消息頭部/響應頭部
(3)消息主體/響應正文