100 份商用合同！諾基亞達成新的 5G 里程碑

阿新 • • 發佈：2020-10-06

一簡介

1.什麼是網際網路

網際網路=物理連線介質+網際網路協議

2.網際網路建立的目的

資料傳輸打破地域限制，否則的話，想要獲得對方主機上的資料，只能拿著硬碟去對方主機拷貝

3.什麼是上網

使用者上網的過程即瀏覽器向服務端傳送請求，然後將服務端主機的文字檔案下載到本地顯示的過程。而瀏覽器與伺服器之間走的HTTP協議。

前端開發就是為了編排一個文字檔案存放在服務端主機，然後提供給瀏覽器下載顯示的，所以在學習前端開發前，需要先研究HTTP協議

#1.HTTP協議，全稱Hyper Text Transfer Protocol（超文字傳輸協議）
		HTTP協議是用於從（WWW:World Wide Web，簡全球資訊網 ）伺服器傳輸超文字到本地瀏覽器的傳送協議。
		
#2.HTTP協議工作與B/S架構上
		瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB伺服器傳送請求request。
		web伺服器根據接收到的請求後，向客戶端傳送響應資訊response
		
#3.HTTP協議是基於TCP/IP通訊協議來傳遞資料的(HTML檔案，圖片檔案等)，如下圖

注意：客戶端與服務端並沒有建立HTTP的連結，他們之間的HTTP之間通訊是基於TCP連結的傳輸。

3.HTTP/1.1詳解

HTTP/1.1是HTTP協議的第三個版本，是目前主流的HTTP協議版本

HTTP 1.1引入了許多關鍵效能優化：keepalive連線，請求流水線，chunked編碼傳輸，位元組範圍請求

(1) Persistent Connection

#長連線
允許HTTP裝置在事務處理結束之後將TCP連線保持在開啟的狀態，以便未來的HTTP請求重用現在的連線，知道客戶端或服務端決定將其關閉為止。

#HTTP1.1對比HTTP1.0
在HTTP1.0中使用長連線需要新增請求頭 Connection: Keep-Alive，而在HTTP 1.1 所有的連線預設都是長連線，除非特殊宣告不支援（ HTTP請求報文首部加上Connection: close ）

(2) Pipelining(請求流水線)

支援持久連線的客戶端可以“流水線”它的請求（即，傳送多個請求而無需等待每個響應）。伺服器必須按照與收到請求的相同順序來向這些請求傳送響應。

(3) chunked編碼傳輸

#1、介紹
該編碼將實體分塊傳送並逐塊標明長度,直到長度為0塊表示傳輸結束, 這在實體長度未知時特別有用(比如由資料庫動態產生的資料)

#2、傳輸編碼和分塊編碼
當響應頭裡包含Transfer-Encoding: chunked，代表分塊編碼，會把「報文」分割成若干個大小已知的塊，塊之間是緊挨著傳送的，這樣就不需要在傳送之前知道整個報文的大小了，也意味著不需要寫回Content-Length首部了。

#3、分塊傳輸的應用
當使用持久連線時，在伺服器傳送主體內容之前，必須計算出主體內容的大小，然後放到響應頭裡（Content-Length：主體的位元組數）傳送給客戶端。
如果伺服器動態建立內容，可能在傳送之前無法知道主體大小，分塊編碼就是為了解決這種情況：伺服器把主體逐塊傳送，說明每一塊的大小。伺服器再用大小為0的塊作為結束塊。，為下一個響應做準備，此時響應頭裡便不再需要Content-Length了

除非使用了分塊編碼Transfer-Encoding: chunked，否則響應頭首部必須使用Content-Length首部。 摘自HTTP/1.1：https://tools.ietf.org/html/rfc2616

#4、關於Content-Length首部：
如果請求頭包含Accept-Encoding': 'gzip'，則服務端會將內容壓縮後返回，內容的Content-Length長度是壓縮後的長度，
如果請求頭不包含Accept-Encoding': 'gzip'，
伺服器就不會採取gzip壓縮，同時我司伺服器設定也不進行分塊編碼。所以返回響應頭的Content-Length首部是必須的，但是這個值的大小肯定是沒有進行過壓縮的檔案大小。

(4) 位元組範圍請求

HTTP1.1支援傳送內容的一部分。比方說，當客戶端已經有內容的一部分，為了節省頻寬，可以只向伺服器請求一部分。該功能通過在請求訊息中引入了range頭域來實現，它允許只請求資源的某個部分。在響應訊息中Content-Range頭域聲明瞭返回的這部分物件的偏移值和長度。如果伺服器相應地返回了物件所請求範圍的內容，則響應碼206（Partial Content）

二請求Requset

1.請求的URL

#1、什麼是URI？
HTTP使用統一資源識別符號（Uniform Resource Identifiers, URI）來傳輸資料和建立連線。

#2、什麼是URL？
URL是一種特殊型別的URI，包含了用於查詢某個資源的足夠的資訊

URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是網際網路上用來標識某一處資源的地址。

#3、以下面這個URL為例，介紹下普通URL的各部分組成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

一個完整的URL包括以下幾部分：
#1.協議部分：http://
該URL的協議部分為“http：”，在"HTTP"後面的“//”為分隔符。這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等。
===>如果不寫，瀏覽器會自動補全，但必須有

#2.域名部分：www.aspxfans.com
一個URL中，也可以使用IP地址作為域名使用
===>必須有

#3.埠部分：8080
跟在域名後面的是埠，域名和埠之間使用“:”作為分隔符。
===>埠不是一個URL必須的部分，如果省略埠部分，將採用預設埠80

#4.虛擬目錄部分：/news/
從域名後的第一個“/”開始到最後一個“/”為止，是虛擬目錄部分。
===>虛擬目錄也不是一個URL必須的部分。

#5.檔名部分：index.asp
從域名後的最後一個“/”開始到“？”為止，是檔名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”為止，是檔案部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是檔名部分。
===>檔名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔名
(?區分虛擬目錄部分與檔名部分)
#6.引數部分：boardID=5&ID=24618&page=1
從“？”開始到“#”為止之間的部分為引數部分，又稱搜尋部分、查詢部分。引數可以允許有多個引數，引數與引數之間用“&”作為分隔符。
===>引數部分非必須

#7.錨部分：#name
從“#”開始到最後，都是錨部分。
===>錨部分也不是一個URL必須的部分

什麼是URI與URL？

#1.URI,是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源。
Web上可用的每種資源HTML文件、影象、視訊片段、程式等都是一個來URI來定位的
URI一般由三部分組成：
(1)訪問資源的命名機制
(2)存放資源的主機名
(3)資源自身的名稱，有路徑表示，著重強調於資源

#2、URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。
URL是Internet上用來描述資訊資源的字串，主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。
採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成：
(1)協議(或稱為服務方式)
(2)存有該資源的主機IP地址(有時也包括埠號)
(3)主機資源的具體地址。如目錄和檔名等

#3、URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:[email protected]。
URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

2.Request請求

客戶端傳送一個HTTP請求到伺服器的請求訊息格式為：請求行(request list)、
請求頭部(header)、空行和請求資料四個部分組成。

請求行以一個方法GET或POST開頭，以空格分開，後面跟著請求的URI和協議的版本。詳細解釋如下
GET /linhaifeng/p/7278389.html HTTP/1.1
Host: www.cnblogs.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

請求資料...(GET請求型別，所以主體為空)

#第一部分：請求行，用來說明請求型別，要訪問的資源以及所使用的HTTP版本
GET說明請求型別為GET
/linhaifeng/p/7278389.html為要訪問的資源
該行的最後一部分說明使用的是HTTP1.1版本

#第二部分：從第二行起為請求頭部，緊接著請求行(即第一行)之後，用來說明伺服器使用的附加資訊
HOST將指出請求的目的地
User-Agent,伺服器端和客戶端指令碼都能訪問它，它是瀏覽器型別檢測邏輯的重要基礎，該資訊由你的瀏覽器來定義，並且在每個請求中自動傳送等。

#第三部分：空行，請求頭部後面的空行是必須的
即使第四部分的請求資料為空，也必須有空行。

#第四部分：請求資料也叫主體，可以新增任意的其他資料。
這個例子的請求資料為空。只有POST方法才有請求體，可以用瀏覽器登入一個網站，輸錯賬號密碼來抓取POST請求

3 HTTP請求方法

#1、Http協議定義了很多與伺服器互動的方法（瞭解）
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

#2、瞭解下各個方法的大致意義
GET     請求指定的頁面資訊，並返回實體主體。
HEAD     類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
POST     向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT     從客戶端向伺服器傳送的資料取代指定的文件的內容。
DELETE      請求伺服器刪除指定的頁面。
CONNECT     HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
OPTIONS     允許客戶端檢視伺服器的效能。
TRACE     回顯伺服器收到的請求，主要用於測試或診斷。

#3、一個URL地址用於描述一個網路上的資源，而HTTP中最基本的四個方法GET, POST, PUT, DELETE就對應著對這個資源的查，改，增，刪4個操作。

#4、 我們最常見的就是GET和POST了。GET一般用於獲取/查詢資源資訊，而POST一般用於更新資源資訊.

GET與POST的區別

#1、區別1: 引數的組織方式不同
GET提交的資料會放在URL之後，以?分割URL和傳輸資料，引數之間以&相連，
例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果資料是英文字母/數字，原樣傳送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進製表示的ASCII。

POST方法是把提交的資料放在HTTP包的Body中.
因此，GET提交的資料會在位址列中顯示出來，而POST提交，位址列不會改變

#2、區別2：傳輸資料大小限制
首先宣告：HTTP協議沒有對傳輸的資料大小進行限制，HTTP協議規範也沒有對URL長度進行限制。

而在實際開發中存在的限制主要有：
GET:特定瀏覽器和伺服器對URL長度有限制，例如 IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系 統的支援。
因此對於GET提交時，傳輸資料就會受到URL長度的限制。

POST:由於不是通過URL傳值，理論上資料不受 限。但實際各個WEB伺服器會規定對post提交資料大小進行限制，Apache、IIS6都有各自的配置。

可以簡單總結為：
GET提交的資料大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的資料沒有限制.
GET方式需要使用Request.QueryString來取得變數的值，而POST方式通過Request.Form來獲取變數的值。

#3、區別3：安全性
POST的安全性要比GET的安全性高。比如：通過GET提交資料，使用者名稱和密碼將明文出現在URL上，因為(1)登入頁面有可能被瀏覽器快取；(2)其他人檢視瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了，除此之外，使用GET提交資料還可能會造成Cross-site request forgery攻擊(4)post是將使用者名稱和密碼放入HTTP請求中的請求資料部分進行了加密，在URL上是看不見的

三 HTTP協議之響應Response

伺服器接收並處理客戶端發過來的請求後會返回一個HTTP的響應訊息Response
HTTP響應也由四個部分組成，分別是：狀態列、訊息報頭、空行和響應正文。

#第一部分:狀態行，由HTTP協議版本號，狀態碼，狀態訊息三部分組成
第一行為狀態行，(HTTP/1.1)表明HTTP版本為1.1版本，狀態碼為200，狀態訊息為(ok)

#第二部分:訊息報頭，用來說明客戶端要使用的一些附加資訊
Date:生成響應的日期和時間
Content-Type:指定了MIME型別的HTML(text/html),編碼型別時UTF-8

#第三部分:空行，訊息報頭後面的空行是必須的

#第四部分:響應正文，伺服器返回給客戶端的文字資訊
空行後面的html部分為響應正文

狀態程式碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示資訊--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：伺服器端錯誤--伺服器未能實現合法的請求
常見狀態碼：

200 OK                        //客戶端請求成功
400 Bad Request               //客戶端請求有語法錯誤，不能被伺服器所理解
401 Unauthorized              //請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用 
403 Forbidden                 //伺服器收到請求，但是拒絕提供服務
404 Not Found                 //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error     //伺服器發生不可預期的錯誤
503 Server Unavailable        //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常
更多狀態碼http://www.runoob.com/http/http-status-codes.html

HTTP響應狀態碼

四 HTTP協議完整工作流程

HTTP協議定義Web客戶端如何從Web伺服器請求Web頁面，以及伺服器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向伺服器傳送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求資料。伺服器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤資訊、響應頭部和響應資料。

以下是HTTP請求/響應的步驟：

1.客戶端連線到web伺服器

一個HTTP客戶端，通常是瀏覽器，與web伺服器的HTTP埠(預設80)建立一個TCP套接字連線。

2.傳送HTTP請求

通過TCP套接字，客戶端向web伺服器傳送一個文字的請求報頭，一個請求報文由請求行、請求頭部、空行和請求資料4部分組成。

3.伺服器接收請求並返回HTTP響應

web伺服器解析請求，定位請求資源。伺服器將資源副本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應資料4部分組成。

4.釋放TCP連線

若connection 模式為close，則伺服器主動關閉TCP連線，客戶端被動關閉連線，釋放TCP連線;若connection 模式為keepalive，則該連線會保持一段時間，在該時間內可以繼續接收請求。

5.客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看錶明請求是否成功的狀態程式碼。然後解析每一個響應頭，響應頭告知以下為若干位元組的HTML文件和文件的字符集。客戶端瀏覽器讀取響應資料HTML，根據HTML的語法對其進行格式化，並在瀏覽器視窗中顯示。

例如：在瀏覽器位址列鍵入URL，按下回車之後會經歷以下流程：

1、瀏覽器向 DNS 伺服器請求解析該 URL 中的域名所對應的 IP 地址;

2、解析出 IP 地址後，根據該 IP 地址和預設埠 80，和伺服器建立TCP連線;

3、瀏覽器發出讀取檔案(URL 中域名後面部分對應的檔案)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料傳送給伺服器;

4、伺服器對瀏覽器請求作出響應，並把對應的 html 文字傳送給瀏覽器;

5、釋放 TCP連線;

6、瀏覽器將該 html 文字接收並顯示內容; 　　

五 HTTP協議的關鍵性總結

#1.簡單快速
客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有get、head、post。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。

#2.靈活
HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。

#3.無連線
http無連結說的是：當某個客戶機在短時間多次請求同一個資源，伺服器並不能區分是否已經響應過使用者的請求。於是我們每次傳送http請求，都需要事先發起一個到伺服器的TCP請求，經歷“三次握手”的過程。這針對大流量的伺服器來說，開銷是相當大的。這是http無連結帶來的缺點。

針對http無連線，人們設計了非持久連線和持久連線。實際上關於http協議非持久連線和持久連線是針對tcp協議的。當客戶機/伺服器的互動運行於TCP協議上時，應用程式的每個請求/響應對是經不同的TCP連線時，則該應用程式使用非持久連線，而當應用程式的每個請求/響應對是經相同的TCP連線傳送，則該應用程式使用持久連線。
    非持久連線
    請求一個HTTP請求/響應需要的總時間=客戶端請求建立連線+發出請求報文+伺服器傳輸HTML檔案的時間

    持久連線
    伺服器在傳送響應後，保持該TCP連線開啟。在相同的客戶機與伺服器之間的後續請求和響應報文通過相同的連線進行傳送。不需要再次建立tcp連線。
    
#4.無狀態
所謂http是無狀態協議，言外之意是說http協議沒法讓服務端儲存客戶機資訊
優點:
	在伺服器不需要先前資訊時它的應答較快
缺點:
	缺少狀態意味著如果後續處理需要前面的資訊，則伺服器必須重傳。這樣可能導致每次傳送的資料量大
	
關於http無狀態阻礙了互動式應用程式的實現。比如記錄使用者瀏覽哪些網頁、判斷使用者是否擁有許可權訪問等。於是，兩種用於保持HTTP狀態的技術就應運而生了，一個是Cookie，而另一個則是Session。

#5、支援B/S及C/S模式