計算機網絡Web應用層與運輸層（HTTP/TCP）

• 應用層協議原理
• Web和HTTP
• DNS:英特網的目錄服務
• 運輸層
• 面向鏈接的運輸：TCP及擁塞原理

 1、應用層協議原理

DNS域名解析：

(用例：www.baidu.com)域名解析是網絡請求的第一步操做，DNS域名解析首先是在瀏覽器緩存中匹配歷史對應域名的IP地址，若是沒有找到就到計算機的網絡訪問緩存中匹配，若是還找不到匹配的IP地址，就會將域名發送到根權威服務器上（com），而後再根權威服務器上匹配到域名（baidu）的服務器IP地址返回發送回客服端上。

網絡鏈接實質上是基於IP地址來創建網絡鏈接，最後實現數據傳送。好比咱們能夠經過控制檯而後使用ping命令查看到www.baidu.com的IP地址，而後能夠直接將IP地址輸入網址欄，照樣能夠獲取到百度的主頁。例如：

 

而後再地址欄輸入：https://119.75.217.109/照樣能夠訪問到百度首頁。

 這裏主要就網絡訪問一些過程作一些說明，後面有對DNS有具體的解析

有了IP地址，至關於才能真正找到服務器，IP做爲每臺網絡計算機的惟一標識。這時候開始嘗試創建網絡通路，實現數據傳輸，也就有了三次握手和四次揮手的環節。網絡應用通訊的實際上進程，web應用是由客戶端的瀏覽器進程和web服務器的進程交換報文。

套字節：即軟件接口向網絡發送報文和從網絡接收報文。套字節是同一臺主機內應用層與運輸層的接口，因爲該套字節是創建網絡應用程序的可編程接口，所以套字節也是應用程序和網絡之間的應用程序編程接口。應用程序開發者能夠控制套字節在應用層端的一切，可是對該套字節的運輸層端幾乎沒有控制權。應用程序開發者對於運輸層的控制權僅限於：1.選擇運輸層協議；2.也許能設定幾個運輸層參數，如最大緩存和最大報文段長度等。(《計算機網絡》59頁)

除了將報文發送到目標服務器，還必須指定運行在接受主機上的接收進程。也能夠說是端口號。一般web服務器端口號用80來標識。

可供應用程序使用的運輸服務：

• 可靠數據傳輸：發送進程只要將其數據傳遞進套字節，就能夠徹底相信該數據將能無差錯地到達接收進程。(數據不丟失)
• 吞吐量：運輸層協議可以以某種特定的速率提供確保的可用吞吐量，使用這種服務可以確保可用吞吐量老是爲至少r比特/秒（帶寬敏感應用：(例)網絡電話）；彈性應用可以根據狀況或多或少地利用可供使用的吞吐量。電子郵件、文件傳輸、以及web傳送都屬於彈性應用。
• 定時：運輸層能提供定時保證(時間敏感)。因特網電話、虛擬環境、電話會議和多方遊戲都須要嚴格的事件限制。
• 安全性：運輸協議可以爲應用程序提供一種或多種安全性服務。（對發送進程傳輸的全部數據加密）

 因特網（通常是TCP/IP網絡）爲應用提供兩層運輸協議，即UDP和TCP。下面是常見應用程序的服務要求：

應用	數據丟失	帶寬	時間敏感
文件傳輸	不能丟失	彈性	不
電子郵件	不能丟失	彈性	不
Web文檔	不能丟失	彈性（幾kbps）	不
因特網電話/視頻會議	容忍丟失	音頻(幾kbps~1Mbps)/視頻(10kbps~5Mbps)	是，100ms
存儲音頻/視頻	容忍丟失	音頻(幾kbps~1Mbps)/視頻(10kbps~5Mbps)	是，幾秒
交互式遊戲	容忍丟失	幾kbps~10kbps	是，100ms
即時通信	不能丟失	彈性	是和不是

TCP服務：1.面向鏈接的服務：在應用層數據報文開始流動以前，TCP讓客戶和服務器相互交換運輸層控制信息。這就是握手過程，這條鏈接是雙工的，即鏈接雙方的進程能夠在此鏈接上同時進行報文收發。當應用程序結束報文發送時，必須拆除該連接，也就是揮手過程。2.可靠的數據服務，也就是數據層的可靠數據傳輸。而後，TCP協議還具備擁塞控制機制，這種服務不必定能爲通訊進程帶來直接好處，但能爲因特網帶來總體好處。當發送方和接受方之間的網絡出現擁塞時，TCP的擁塞控制機制會抑制發送進程(客戶端或服務器)。

UDP服務：是一種不提供沒必要要服務的輕量級運輸協議，它僅提供最小服務。UDP是沒法鏈接，兩個進程通訊前沒有握手過程。當進程將一個報文發送進UDP套字節時，UDP協議並不保證該報文將到達接受進程，而且到達接收進程的報文也多是亂序到達。UDP沒有擁塞機制，因此UDP的發送端能夠用選定的任何速率向其下層注入數據(實際端到端吞吐量可能小於這個速率，這多是由於中間鏈路的帶寬受限或由於擁塞而形成的)。

 因特網運輸協議不提供的服務：吞吐量和定時保證，但不意味着因特網電話這樣的時間敏感應用不能運行在因特網上，由於因特網上運行時間敏感應用已經有多年了(之後有機會對多媒體網絡這部分重點分析：)。

流行的因特網引用及其應用層協議和支撐的運輸協議：

應用	用戶層協議	支撐的運輸層協議
電子郵件	SMTP [RFC 5321]	TCP
遠程終端訪問	Telnet [RFC 854]	TCP
Web	HTTP [RFC 2616]	TCP
文件傳輸	FTP [RFC 959]	TCP
流式多媒體	HTTP(如YouTube)	TCP
因特網電話	SIP [RFC 3261]、RTP [RFC 3550]、或專用的（如Skype)	UDP或TCP

 2、Web和HTTP協議

Web的應用層協議是超文本傳輸協議(HyperText Transfer Protocol,HTTP)，它是Web的核心，在[RFC 1945]和[RFC 2616]中進行了定義。HTTP有兩個程序實現：一個客戶端程序和一個服務器程序。客戶程序和服務器程序運行在不一樣的端系統中，經過交換HTTP報文進行會話。HTTP定義了這些報文的結構以及客戶和服務器進行報文交換的方式。由於HTTP服務器並不保存關於客戶的任何信息，假如某個特定的客戶在短短几秒鐘內兩次請求同一個對象，服務器也響應兩次，將同一個對象重複發送給客戶，因此HTTP是一個無狀態協議。

持續鏈接與非持續鏈接：

客戶和服務器在一個至關長的時間範圍內通訊，其客戶發出一系列請求而且服務器對每一個請求進行響應。這一系列的請求能夠以規則的間隔週期性地或者間斷性地一個接一個發出。當客戶與服務的交互時，每一個請求/響應是經單獨的TCP鏈接發送仍是全部請求即響應都是通過相同的一個TCP鏈接發送。每一個單獨的TCP鏈接被稱爲非持續鏈接，通過相同的一個TCP鏈接被稱爲持續鏈接，持續鏈接在必定時間內沒有發生請求HTTP服務器就會關閉鏈接。HTTP可以使用非持續鏈接也能使用持續鏈接，各有優缺點。

每個HTTP請求都須要通過三次握手創建鏈接傳輸文件，這個過程須要兩次往返時間(RTT),會產生必定的網絡延時。持續鏈接能夠在必定程度上減小這種重複的握手鍊接過程，可是多個請求採用一個TCP鏈接須要等待一個一個的傳輸，在必定程度上能夠減小網絡延時，但也產生了等待執行的時間。持續鏈接相對非持續鏈接在很大程度上減小了服務器的壓力，可是性能問題是由多種因素形成的，量化比較持續鏈接和非持續鏈接對於優化性能很是有必要(《計算機網絡》69頁)參考文獻[Heidemann 1997; Nielsen 1997]。

這就是常說的三次握手過程，這個過程咱們須要重點關注的是往返時間（RTT）和傳輸文件的時間，這也是web開發中優化的重要部分。第一次握手：客服端發起TCP鏈接；第二次握手：服務端響應鏈接；第三次握手：客服端請求文件；接下來就是服務端響應文件請求，開始文件傳輸。

 HTTP報文：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent:Mozilla/5.0
Accept-language: fr

報文使用普通的ASCII文本書寫的，上面是個請求報文內容總共就5行代碼，每行由一個回車和換行符結束，最後一行後一行後再附加一個回車換行符。第一行叫作請求行，第二行叫作首部行，Connection表示鏈接方式，User-agent用來指明代理，Accept-language表示想得到對象的語法版本。

請求行三個字段：方法字段、URL字段、HTTP版本字段。方法字段可取幾種不一樣的值，包括GET、POST、HEAD、PUT和DELETE。URL字段帶有請求對象的標識(page.html)，這裏的版本字段實現的是HTTP/1.1版本。

首部行Host指明瞭對象所在的主機，首部提供的信息是Web代理高速緩存所要求的。其餘的部分再HTTP協議分析博客中具體解析。

請求報文格式：

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，上圖給出了請求報文的通常格式。能夠看到在最後一行有一個請求數據，請求數據也叫作請求的實體主體，這是請求行中使用POST方法請求才會使用該實體。但不能說POST就是惟一的提交請求數據的惟一方法，GET方法請求能夠在URL中輸入數據https://www.baidu.com/baidu?word=Connection；其中的word=Connection就是一組請求數據，固然還可使用&&鏈接多個請求數據。接着咱們再來看前面的請求示例對應的響應報文：

HTTP/1.1 200 OK
Connection: close
Date:tue, 09 Aug 2011 15:44:04 GMT
Server:Apache/2.2.3(CentOS)
Last-Modified:Tue, 09 Aug 2011 15:11:03 GMT
Content-length:6821
Content-Type:text/html

(data data data data data ...)

響應報文的第一行是狀態行，而後是首部(這裏首部共六行)，而後是實體(響應實體)。

狀態行三個字段：協議版本字段、狀態碼字段、相應狀態信息。這裏重點提一下狀態碼和相應狀態信息，而後響應首部到HTTP協議分析博客中具體介紹。下面是一些常見的狀態碼和相關的短語：

• 200 OK:請求成功，信息在返回的響應報文中。
• 301 Moved Permanently:請求的對象已經被永久轉移了，新的URL定義在響應報文的Location:首部中。客戶軟件將自動獲取新的URL。
• 400 Bad Request:一個通用查錯代碼，指示該請求不能被服務器理解。
• 404 Not Found:被請求的文檔不在服務器上。
• 505 HTTP Version Not Supported:服務器不支持請求報文中的HTTP協議。

 最後介紹在window上的網絡請求命令：curl 。這篇博客介紹了curl的用法什麼是curl命令？。

 用戶與服務器的交互：cookie

前面提到HTTP服務器是無狀態的，那同時處理數千計甚至更大的訪問時怎麼識別用戶呢？固然你可使用關係型數據庫記錄的用戶標識，若是你不考慮性能的話能夠這麼作。如今HTTP協議有一種存在請求報文上的識別標識，相對來講就好多了，這就是cookie，cookie是由服務端經過HTTP協議和瀏覽器設置在客戶端的一個標識，這個標識能夠設置一些簡單的信息，還能夠設置它的生命週期。

可是cookie並非最佳選擇，由於cookie不安全並且瀏覽器能夠主動設置屏蔽cookie，因此這時候又有了服務端的session，這已經不在HTTP範疇了，後期相關博客具體介紹cookie和session的使用方法再解析。隨着技術的進步，web基於HTTP的無狀態解決方案也愈來愈多，有機會再詳細介紹。

若是本地緩存了用戶某個站點的cookie信息，在用戶每次登入該站點時HTTP報文頭部都會經過cookie頭部行傳送給服務器，服務器經過Set-cookie響應頭部行設置客戶端的cookie。

 web緩存

web緩存器(Web cache)也叫代理服務器(proxy server)，它是可以表明初始Web服務器來知足HTTP請求的網絡實體。Web緩存器有本身的磁盤存儲空間，並在存儲空間中保存最近請求過的對象的副本，使得用戶全部HTTP請求首先指向Web緩衝器。下面具體描述客戶端經過web緩存器請求資源的所有通過：

• 瀏覽器創建一個到Web緩存器的TCP鏈接，並向Web緩存器中的對象發送一個HTTP請求。
• Web緩存器進行檢查，看看本地是否存儲了該對象副本。若是沒有，Web緩存器就向客戶端瀏覽器用HTTP響應報文返回該對象。
• 若是Web緩存器中沒有該對象，它就打開一個與該對象的初始服務器的TCP鏈接。Web緩存器則在這個緩存器到服務器的TCP鏈接上發送一個對該對象的HTTP請求。在收到該請求後，初始服務器向該Web緩衝器發送具備該對象的HTTP響應。
• 當Web緩存器接收到該對象時，它在本地存儲空間存儲一根副本，並向客戶的瀏覽器用HTTP相應報文發送該副本(經過現有的客戶端瀏覽器和Web緩存器之間的TCP鏈接)。

web緩存器經過使用內容分發網絡(Content Distri-bution Network, CDN)實現，CDN公司在因特網上安裝了許多地理上分散的緩衝器，於是使大流量實現本地化。

通過上面的過程描述，web緩存器在響應客戶端請求時就是一個服務器，而在向初始服務器發送請求時就是一個客戶端。這樣的網絡響應方式確定是能夠很大程度的提升響應效率，具體能夠了解(《計算機網絡》75頁)。可是這樣的網絡響應就會存在一個問題，怎麼確保web緩存的副本是最新的最新的資源呢？何時更新web緩存器的副本？

在Web緩存器上，HTTP協議有一種機制，容許緩存器證明它的對象是最新的。這種機制就是get方法，若是請求報文使用get方法，而且請求報文中含有「If-Modified-since:」首部行，那麼這個請求報文就是一個條件get請求報文。下面是是一對Web緩存器的HTTP請求和響應報文：

GET /fruit/kiwi.gif HTTP/1.1
Host:www.exotiquecuisine.com
If-Modified-since:web, 7 Sep 2011 09:23:24
//初始服務器響應
HTTP/1.1 304 Not Modified
Date: Sat, 15 Oct 2011 15:39:29
Server: Apache/1.3.0 (Unix)

(empty entity body)

 3、DNS:因特網的目錄服務

DNS( Domain Name System)是「域名系統」的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統，它用於TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換爲IP地址的工做。俗話說，DNS就是將網址轉化爲對外的IP地址。

• 第一步：瀏覽器將會檢查緩存中有沒有這個域名對應的解析過的IP地址，若是有該解析過程將會結束。瀏覽器緩存域名也是有限制的，包括緩存的時間、大小，能夠經過TTL屬性來設置。
• 第二步：若是用戶的瀏覽器中緩存中沒有，操做系統會先檢查本身本地的hosts文件是否有這個網址映射關係，若是有，就先調用這個IP地址映射，完成域名解析。
• 第三步：若是hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，若是有，直接返回，完成域名解析。
• 第四步：若是hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/ip參數中設置的首選DNS服務器，在此咱們叫它本地DNS服務器，此服務器收到查詢時，若是要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具備權威性。
• 第五步：若是要查詢的域名，不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具備權威性。
• 第六步：若是本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，若是未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來受權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，若是本身沒法解析，它就會找一個管理.com域的下一級DNS服務器地址給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找域名域服務器，重複上面的動做，進行查詢，直至找到域名對應的主機。
• 第七步：若是用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器若是不能解析，或找根DNS或把轉請求轉至上上級，以此循環。無論是本地DNS服務器用是是轉發，仍是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。

這部分直接拷貝別人的了，對於DNS不是三言兩語就能解釋清楚的，前期學習也不會有太多接觸，有機會在重點解析。有興趣能夠先了解一下這篇文章，我這篇博客的DNS部分的內容也是從這裏拷貝的。一次DNS緩存引起的慘案

 4、運輸層/TCP、UDP

 一個Web請求通過了HTTP請求到DNS域名解析後就到了向服務器發起正式的資源請求了，HTTP報文通過套字節向網絡發送請求報文，這時候就開始基於TCP協議來進行網絡運輸層的資源交互響應了。

 運輸層概述

運輸層協議爲運行在不一樣主機上的應用進程之間提供邏輯通訊，從應用程序的角度看，經過邏輯通訊，運行不一樣進程的主機好像直接鏈接同樣。簡單的說就是經過運輸層協議將兩個不一樣的主機和不一樣的進程經過邏輯處理，讓它們相互鏈接進行報文段交付和數據傳輸。

• 運輸層協議是在端系統中而不是在路由器中實現(也就是你的客戶主機或者服務器主機)。
• 在發送端，運輸層將從發送應用程序進程接收到的報文轉換成運輸層分組(報文段)，實現的方法是將應用報文劃分紅較小的塊，併爲每塊加上一個運輸層首部生成運輸層報文段。
• 而後，在發送端系統中，運輸層將這些報文段傳遞給網絡層，網絡層將其封裝成網絡層分組(數據報)並向目的地發送。
• 網絡路由僅做用於該數據報的網絡層字段；即他們不檢查封裝在數據報的運輸層報文段的字段。
• 在接收端，網絡層從數據報中提取運輸層報文段，並將該報文段向上交給運輸層。
• 運輸層則處理接收到的報文段，使該報文段中的數據爲接收應用進程使用。

整個運輸層就是從發送端的進程接收報文而後轉換成報文段，而後再將報文段交給網絡層發送到目的地，而後接收端的運輸層拿到報文段交給對應的應用程序進程。這個過程裏面有一個問題值得探討，就是運輸層如何從進程拿到報文，拿到報文後轉換成報文段作了什麼。接收端的運輸層接收到報文段又是如何將報文段交給應用程序進程的。咱們知道一臺主機會有不少個應用程序進程，運輸層如何分辨，將報文段準確無誤的交給對應的應用程序進程。這就是咱們接下來要介紹的：運輸層多路複用與多路分解。

上面咱們介紹了運輸層是在端系統上進行邏輯處理來實現兩個端系統的進程鏈接，那麼就有必要來了解運輸層協議究竟是如何進行邏輯處理的。

• 運輸層的多路複用與多路分解，將兩個端系統間IP的交付服務擴展未運行在端系統上的進程交付服務。
• 每一個運輸層報文段中具備幾個字段，在接收端運輸層檢查這些字段，標識出接收套字節，進而將報文段定向到該套字節，這就是多路分解，也是接收端的運輸層邏輯。
• 在源主機(客戶主機)從不一樣套接字中收集數據塊，併爲每一個數據塊封裝上首部從而生成報文段，而後將報文段傳送到網絡層，這就是多路複用。

上面的運輸層實套接字有些是目的IP地址和目的端口號組成的二元組標識，有些會多包含有源端口IP地址和源端口號的四元組標識，這其中的區別就是下面要解釋的無鏈接和有連接的多路複用和多路分解。

無鏈接的多路複用與多路分解：UDP套接字是由二元組來標識的，因此UDP是無鏈接運輸協議。

有連接的多路複用與多路分解：CTP套接字是由四元組來表示的，因此CTP是有連接運輸協議。

下面是一個TCP運輸的Web請求過程：

• TCP服務器應用程序有一個「welcoming socket」,它在12000號端口上等待來自TCP客戶的鏈接創建請求。
• TCP客戶使用下面的代碼建立一個套接字並發送一個鏈接創建請求報文段：clientSocket = socket(AF_INET, SOCK_STREAM);clientSocket.connect((serverName,12000))
• 一條鏈接創建請求只不過是一個目的端口號爲12000，TCP首部的特定「鏈接位置」置位的TCP報文段，這個報文段也包含一個客戶選擇的源端口號。（後面有具體的解析）
• 當運行服務器進程的計算機的主機操做系統接收到了具備目的端口12000的入鏈接請求報文段後，它就定位服務器進程，該進程正在端口號12000等待接收鏈接。該服務器進程建立一個新的套接字：connectionSocket, addr = serverSocket.accept()
• 該服務器的運輸層還注意到鏈接請求報文段中的下列四個值：1.該報文段中的源端口號；2.源主機IP地址；3.該報文段中的目的端口號;4.自身的IP地址。新建立的鏈接套接字經過這4個值來標識。全部後續到達的報文段，若是他們的源端口號、源主機IP地址、目的端口號和目的IP地址與這4個值匹配，則被分解到這個套字節。隨着TCP鏈接完成，客戶和服務器能夠開始互相發送數據了。（服務器主機支持不少並行的TCP套接字，每一個套接字與一個進程相聯繫，並由其四元組來標識每一個套接字，全部4個資源被用來將報文段定向（分解）到響應的套接字）

 無鏈接的運輸：UDP/面向鏈接的運輸：TCP

 因爲運輸層的內部機制和實現原理篇幅很多，並且有很是重要，同時也爲了方便之後查閱，特將這部份內容分別獨立儲出去做爲兩個博客內容，下面是這兩篇博客的鏈接：

 無鏈接運輸的UDP、可靠數據傳輸原理、面向鏈接運輸的TCP