第一章概述

1.TCP/IP協議簇一共分爲七層

  應用層：Http  Ftp 等等

 表示層：

 會話層：

 傳輸層: TCP   UDP

 網絡層:IP協議, ICMP協議,  IGMP協議

 鏈路層:設備驅動程序以及接口卡

 物理層:

既然協議簇命名爲:Tcp/Ip 核心就是TCP和IP

IP協議：是無鏈接的網絡協議，主要是處於網咯層的IP協議提供傳輸方式不可靠的,它只承諾儘量地將數據報發送出去,但不保證發送的數據報可以成功的抵達目的地。IP協議不可靠性還體如今它不能檢測數據在傳輸過程當中是否發生改變.

TCP協議:創建在網絡層之上的傳輸層解決網絡層這兩個問題; 是基於一個鏈接的傳輸協議，數據交換雙方在進行報文傳輸以前須要創建鏈接，報文傳輸結束以後就關閉鏈接。

TCP 利用"接收確認"和"超時重傳"機制確保數據可以成功抵達目的地.

 

HTTP :"超文本傳輸協議"是TCP/IP協議簇一部分;這是以前分紅七層處於應用層，因爲在傳輸層之上因此HTTP天然提供可靠數據傳輸的保障。

   IP協議利用IP地址定位數據報發送的目的地，而利用域名系統(DNS)能夠實現域名與IP地址之間的轉換;TCP協議利用端口(Port)標識應用程序,因此兩個應用程序在使用TCP協議進行通訊的時候必須肯定雙方的IP地址(或者域名)和端口號；

  HTTP默認端口:80

  HTTPS默認端口:443

 

2.web 資源

      媒體類型：數據處理必須依賴於一種已知的格式，因此將資源的形態以一種標準化的方式肯定下來顯得尤其重要，這個描述資源格式的標準稱爲媒體類型(MIME);

     幾種經常使用的媒體類型爲： 

        text/html:HTML格式的文本

       text/xml(application/xml):XML格式的文本

　　text/json(application/json):JSON格式的文本

　　image/gif(image/jpeg,image/png):GIF(JPEG,PNG)格式的圖片

　　audio/mp4(audio/mpeg,audio/vnd.wave):MP4(MPEG,WAVE)格式的音頻文件

　　video/mp4(video/mpeg,video/quicktime):mp4(MPEG,QUICKTIME)格式的視頻文件

 

　　MPEG：動態圖像專家組

　　QuickTime:是一款擁有強大的多媒體技術的內置媒體播放器

 

 

　　URI 和URL ，URN

　　URI:"統一資源標識"，標識可操做的資源應該具備一個或多個惟一的標識；

　　URL:"統一資源定位符"，包含了標識符，還有具備定位的功能，能夠用於描述資源的位置；一個完整的URL包含協議名稱，主機名(ip地址或者域名),端口號，路徑，查詢字符串5個部分

　　URN:"統一資源定位名稱"，它與資源位置無關，資源位置改變了其標誌符依然不改變。

 

   HTTP 響應狀態:

　　100-199: 信息狀態碼

　　200-299：成功狀態碼

　　300-399：重定向狀態碼，表明須要客戶端採起進一步的操做才能完成請求

　　400-499:客戶端錯誤代碼，表明因客戶端發生錯誤而妨礙了服務的處理

　　500-599:服務端錯誤狀態碼，表明服務器在處理請求的過程當中有錯誤或者異常發生。

 

 HTTP 報文

　　客戶端和web服務器在一次HTTP事務交換的消息稱爲HTTP報文；報文有三部分組成：

　　起始行：表明HTTP報文的第一行文字，請求報文利用起始行標識採用的HTTP方法，請求URL和採用的HTTP的版本

　　　　　　例如： GET  http://www.micosoft.com/en-us/       HTTP/1.1

　　　　　　HTTP方法是：GET

　　　　　　目標資源： http://www.micosoft.com/en-us/  

　　　　　　協議版本：HTTP/1.1

　　報頭集合：HTTP報頭的起始行後能夠包含零個或多個報頭字段；每一個報頭表現爲一個鍵值對。　　

　　　　報頭得到主機名稱(Host)

　　　　採用的緩存策略(Cache-ControI)

　　　　瀏覽器相關信息(Uscr¨Agent)

　　　　客戶端支持的媒體類型(Accept)

　　　　編碼方式(Accept-Encoding)

　　　　語言(AGcept-Language)

　　　　字符集(Aooept-Charset)

　　主體內容：表明報頭集合結束標誌的空行以後就是HTTP報文的主體部分；

 

　　RESTful Wen APi

　　　　REST不是一個標準，而是一個架構風格，與之對應的是傳統的web service 採用的RPC架構風格。

　　　　若是說RPC是一種面向操做的架構風格的話，REST就是一種面向資源的架構風格。

 

使用標準的HTTP方法

　　GET：用於獲取所須要的資源，服務器通常將對應的資源置於響應的主體部分返回客戶端。

　　HEAD：請求通常不是爲了獲取目標資源自己的內容，而是但願獲得描述資源的元數據信息。服務器通常將對應資源的元數據置於響應的報頭集合返回給客戶端，因此這樣的響應通常不具備主體部分。

　　OPTIONS：請求通常是一種」探測「請求，其目的在於肯定針對某個目標地址的只是請求應該具備這樣的約束（好比應該採用怎樣的HTTＰ方法或者必須攜帶怎樣的自定義報頭），而後根據其約束髮送符合條件的請求。

　　POST和PUT：都可以請求添加一個新的資源，可是二者的不一樣之處在於：前者通常不能決定標識添加資源最終採用的URL，即服務端最終爲成功添加的資源指定URI；然後者，最終標識添加資源的URI是能夠由請求者控制的。若是PUT提供的資源不存在，則作添加操做，不然作修改操做。　

　　PATCH：若是須要進行＂局部＂修改，由於語義上講是打補丁的意思。

　　ＤＥＬＥＴＥ：刪除

 

　　GET，ＨＥＡＤ，ＯＰＴＩＯＮＳ均被認爲是安全的方法，也被視爲冪等方法。

　　冪等性（indemoptent）是一個數學上的概念，在這裏標識發送一次或屢次請求引發的邊界效應是一致的。