【計算機網絡】2.2 Web和HTTP TCP三次握手詳解及釋放鏈接過程

時間 2019-12-10

標籤計算機網絡 2.2 web http tcp 三次握手詳解釋放鏈接過程欄目 HTML 简体版

原文原文鏈接

第二章第二節 Web和HTTP

這一章中，咱們須要討論5種重要的應用：Web、文件傳輸、電子郵件、目錄服務、P2P；這一節中，咱們將討論Web和它的應用層協議HTTP。css

Outline

Web簡介
HTTP概況
非持續鏈接和持續鏈接
- HTTP請求/相應的步驟
- 非持續鏈接
- 非持續鏈接的串行TCP鏈接、並行TCP鏈接和響應時間
- 持續鏈接
HTTP請求協議
- 請求信息
- Get請求方法
- Post請求方法
- 響應格式
- 響應狀態碼
Cookie
Web緩存

Notes

##Web簡介

Web即World Wild Web（萬維網），由Tim Berners-Lee發明，是由網頁構成，支持網頁互相鏈接。
Web網頁（Web Page）包含多個對象（Objects），如：HTML文件、JPEG圖片、視頻文件、動態腳本等，多數Web頁面包含一個HTML基本文件，其中包含對其餘對象引用的連接。
對象的尋址（adressing）是經過URL（Uniform Resoure Locator）統一資源定位器來進行。
其格式爲：Scheme://hostport/path 如：Http://www.somecompany.com/somePic/pic.png (Http 爲協議名、www.somecompany.com爲 hostname主機、somePic/pic.png爲 pathname路徑名）

## HTTP概況

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端
HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等），鏈接創建後，瀏覽器和服務器進程就能經過套接字接口訪問TCP；
HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。
HTTP是一個無狀態協議，服務器向客戶發送被請求的文件，而不存儲任何關於該用戶的信息

【HTTP特色】html

簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Conten-Type加以標記。
非持續鏈接：無鏈接的含義是限制每次鏈接只處理一個請求、服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
無狀態：無狀態是指對於事務處理沒有記憶能力，服務器向客戶發送被請求的文件，而不存儲任何關於該用戶的信息。缺乏狀態意味着若後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時，它的應答就較快。

## 非持續鏈接與持續鏈接

【HTTP請求/響應的步驟】java

　　HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。android

客戶進程鏈接到Web服務器：一個HTTP客戶進程，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。
發送HTTP請求報文：經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
服務器接受請求並返回HTTP響應：Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
釋放TCP鏈接：若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;
客戶端瀏覽器解析HTML內容：客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

當客戶機/服務器的交互運行於TCP協議上時，應用程序的每一個請求/響應對是經一個單獨的TCP鏈接，則該應用程序使用非持久鏈接，而當應用程序的每一個請求/響應對是經相同的TCP鏈接發送，則該應用程序使用持久鏈接。
HTTP/1.0 使用非持久鏈接。 HTTP/1.1 默認使用持久鏈接

【非持續鏈接】web

示例：在非持續鏈接中，若是打開一個HTML文件和10個內聯圖象對象的網頁時，HTTP就要創建11次TCP鏈接才能把文件從服務機傳送到客戶機。
再假設該節本HTML文件的URL爲：www.yesky.com/sompath/index.html。
- HTTP客戶端與服務器主機www.yesky.com中的HTTP服務器創建一個TCP鏈接。
- HTTP客戶端發送HTTP請求消息。包含/sompath/index.html。
- HTTP服務器接收請求消息，從服務器主機內存或硬盤拿去除對象/sompath/index.html，發出該對象的響應消息。
- HTTP服務器告知TCP關閉這個TCP鏈接(TCP要等客戶收到這個響應消息後，纔會真正終止這個鏈接)。
- HTTP客戶接收響應消息。TCP鏈接終止。該消息標明所拆裝的對象是一個HTML文件。客戶取出文件，分析後發現10個JPEG對象的引用。
- 給每個引用到的JPEG對象重複步驟1~4。

【非持續鏈接的串行TCP鏈接、並行TCP鏈接和響應時間】數據庫

十個JPEG對象，能夠經過串行的TCP鏈接方式前後取到；咱們也能夠經過並行的TCP同時取到對象，縮短響應時間
客戶端請求一個基本HTML文件，要耗時2個RTT(Round Trip Time)加上服務器服務器
- RTT：一個短分組從客戶端到服務端在返回客戶所花費的時間
- 創建瀏覽器和Web服務端的TCP鏈接，須要通過「三次握手」過程(關於三次握手請參考TCP三次握手詳解及釋放鏈接過程)
- 第一次握手發起TCP鏈接，第三次握手請求文件

TCP的缺點
- 每一個鏈接，TCP得在客戶端和服務端分配TCP緩衝區，並維持TCP變量。對於同時爲來自數百個不一樣客戶的請求提供服務的web服務器來講，這會嚴重增長其負擔。
- 每一個對象有2個RTT
- 每一個對象都遭受TCP緩啓動，由於每一個TCP鏈接都起始於緩啓動階段。

【持續鏈接】（關於持續鏈接、非持續鏈接請參考HTTP協議：持久鏈接、非持久鏈接）後端

持續鏈接：服務器在發送響應後，保持該TCP鏈接打開。在相同的客戶機與服務器之間的後續請求和響應報文經過相同的鏈接進行傳送。不須要再次創建tcp鏈接
不帶流水線(without pipelining)：客戶只在收到前一個請求的響應後，才發出新的請求。
- 與非持續鏈接的2個RTT延遲相比，不帶流水線每一個引用到的對象各有1個RTT的延遲
帶流水線(with pipelining)：HTTP客戶每碰到一個引用就當即發送一個請求，即HTTP客戶能夠一個接一個挨着發送各個引用對象的請求。服務器收到這些請求後，也能夠一個接一個的發送各個對象的響應。
- 帶流水線的持久鏈接中服務器空等請求的時間較少，全部引用到的對象一共只經歷1個RTT的延時。

## HTTP請求協議

HTTP協議包括：請求消息與響應消息瀏覽器

【請求信息】緩存

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出了請求報文的通常格式。服務器

HTTP請求報文的第一行叫作請求行(request line)，請求行由 方法字段、URL字段 和 HTTP協議版本字段 3個字段組成，它們用空格分隔。
- HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
後繼的行叫作請求頭部行：
- 請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號「:」分隔。請求頭部通知服務器有關於客戶端請求的信息，典型的請求頭有：
- User-Agent：產生請求的瀏覽器類型。
- Accept：客戶端可識別的內容類型列表。
- Host：請求的主機名，容許多個域名同處一個IP地址，即虛擬主機。
- Connection：告訴服務器是否須要持續鏈接
空行：最後一個請求頭以後是一個空行，發送回車符和換行符，通知服務器如下再也不有請求頭。
- 回車符：cr；換行符：lf；空格：sp

【Get請求方法】

　　最多見的一種請求方式，當客戶端要從服務器中讀取文檔時，當點擊網頁上的連接或者經過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給客戶端。使用GET方法時，請求參數和對應的值附加在URL後面，利用一個問號（「?」）表明URL的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind,這樣經過GET方式傳遞的數據直接表示在地址中，因此咱們能夠把請求結果以連接的形式發送給好友。(轉自：http://www.javashuo.com/article/p-kiyvktgz-da.html) 下例爲請求打開本博客中莫伊照片的請求方法頭：

GET /images/upup.gif HTTP/1.1 Host: static.cnblogs.com
Connection: keep-alive
If-Modified-Since: Sun, 17 Dec 2017 20:47:09 GMT
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Accept: image/webp,image/apng,image/*,*/*;q=0.8 Referer: https://www.cnblogs.com/bundles/blog-common.css?v=PX31qVjOE47mNaZI9JUSFK-ajuzMnpXA9PeteRNR1Qw1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7

地址中」?」以後的部分就是經過GET發送的請求數據，咱們能夠在地址欄中清楚的看到，各個數據之間用」&」符號隔開。顯然，這種方式不適合傳送私密數據。另外，因爲不一樣的瀏覽器對地址的字符限制也有所不一樣，通常最多隻能識別1024個字符，因此若是須要傳送大量數據的時候，也不適合使用GET方式。
HTTP默認的請求方法就是GET
- 沒有請求體
- 數據量有限制！
- GET請求數據會暴露在瀏覽器的地址欄中
GET請求經常使用的操做：
- 在瀏覽器的地址欄中直接給出URL，那麼就必定是GET請求
- 點擊頁面上的超連接也必定是GET請求
- 提交表單時，表單默認使用GET請求，但能夠設置爲POST
請求頭：

一、Host：請求的web服務器域名地址
二、User-Agent：HTTP客戶端運行的瀏覽器類型的詳細信息。經過該頭部信息，web服務器能夠判斷出http請求的客戶端的瀏覽器的類型。
三、Accept：指定客戶端可以接收的內容類型，內容類型的前後次序表示客戶都接收的前後次序
四、Accept-Lanuage：指定HTTP客戶端瀏覽器用來展現返回信息優先選擇的語言
五、Accept-Encoding：指定客戶端瀏覽器能夠支持的web服務器返回內容壓縮編碼類型。表示容許服務器在將輸出內容發送到客戶端之前進行壓縮，以節約帶寬。
而這裏設置的就是客戶端瀏覽器所可以支持的返回壓縮格式。
六、Accept-Charset:HTTP客戶端瀏覽器能夠接受的字符編碼集
七、If-modified-since：記錄網頁最後更新的時間，以容許緩存器證實它的對象是否是最新的
七、Content-Type: 顯示此HTTP請求提交的內容類型。通常只有post提交時才須要設置該屬性
有關Content-Type屬性值有以下兩種編碼類型：
（1）「application/x-www-form-urlencoded」： 表單數據向服務器提交時所採用的編碼類型，默認的缺省值就是「application/x-www-form-urlencoded」。
     然而，在向服務器發送大量的文本、包含非ASCII字符的文本或二進制數據時這種編碼方式效率很低。
（2）「multipart/form-data」： 在文件上載時，所使用的編碼類型應當是「multipart/form-data」，它既能夠發送文本數據，也支持二進制數據上載。
當提交爲表單數據時，可使用「application/x-www-form-urlencoded」；當提交的是文件時，就須要使用「multipart/form-data」編碼類型。

【Post請求方法】

使用POST方法能夠容許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，能夠傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，並且也不會顯示在URL中。下例爲登錄郵箱時請求方法頭：

POST /contacts/call.do?uid=hithongming@163.com HTTP/1.1
Host: mail.163.com
Connection: keep-alive
Content-Length: 36
Origin: https://mail.163.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Content-type: application/x-www-form-urlencoded
Accept: */*
Referer: https://mail.163.com/js6/main.jsp?sid=rAraHhmcZFpASRsJRyccJovqsYPSLZYL&df=mail163_letter
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7

【響應格式】

　　通常狀況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。

　　HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

HTTP/1.1 200 OK 
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT 
Server: Apache/1.3.0 (Unix) 
Last-Modified: Mon, 22 Jun 1998 ...... 
Content-Length: 6821 
Content-Type: text/html

(data data data data……)

第一部分：狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成。
- 第一行爲狀態行，（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）
第二部分：消息報頭，用來講明客戶端要使用的一些附加信息

Date:生成響應的日期和時間；
Content-Type:指定了MIME類型的HTML(text/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

【GET與POST請求的區別】（參考：https://blog.csdn.net/javandroid/article/details/29884033）

## Cookie

因爲HTTP協議無狀態，沒法知道客戶的相關信息，使得一些應用難以實現，如網上購物（你須要掌握好客戶端的狀態）,故引入Cookie技術來解決這個問題。
Cookie是在遠程瀏覽器端存儲數據並以此跟蹤和識別用戶身份的機制，即Cookie是存儲在客戶端的一小段數據，瀏覽器（即客戶端）經過HTTP協議和服務器端進行Cookie的交互。
cookie容許站點對用戶進行跟蹤。
Cookie技術有4個組件：
- 在HTTP響應報文中的一個cookie首部行
- 在HTTP請求報文中的一個Cookie首部行
- 在用戶端系統中保留有一個Cookie文件，並由用戶的瀏覽器進行管理
- 位於web站點的一個後端數據庫

栗子：