應用層，瞭解一下

改變的速度，即對學習來說，最重要的東西是學習的方法，在特定的技術中如何靈活地適應改變，當你在職業生涯中前行時，在新的機會和可能性方面如何保持開放的思想 --Marc Andreessen

應用層

研發網路應用程式的核心是寫出能夠執行在不同的端系統和通過網路彼此通訊的程式

---

程式通訊

• 在作業系統中，進行通訊的實際上是程式（process）而不是程式。一個程式可以被認為是執行在端系統的一個程式

• 當程式執行在相同的端系統上時，它們使用程式間的通訊機制相互通訊。程式間通訊的規則由端系統上的作業系統確定

• 在兩個不同端系統上的程式，通過跨越計算機網路交換報文而相互通訊。傳送程式生成報文併傳送到網路中，接收程式接收這些報文並可能通過將報文傳送回去進行響應

• 定義客戶和伺服器程式：在給定的一對程式之間的通訊會話場景中，發起通訊（即在該會話開始時發起與其他程式的聯絡）的程式被標識為客戶，在會話開始時等待聯絡的程式是伺服器

• 程式間通過套接字（socket）軟體介面向網路傳送或者接收報文

• 套接字是同一臺主機內應用層和傳輸層之間的介面，由於套接字是建立網路應用程式的可程式設計介面，因此套接字也被稱為應用程式和網路之間的應用程式程式設計介面（API）

• 通過 ip（主機地址） 和 port（主機中接收程式識別符號）來標識程式通訊中的接收程式

---

運輸層服務的四個重要屬性

• 包括因特網在內的很多網路提供了不止一種運輸層協議，協議的選取由呼叫它的應用程式的需求來決定，這裡有四個重要屬性：可靠資料傳輸，吞吐量，定時和安全性

• 如果一個協議提供確保資料交付的服務，就認為提供了可靠資料傳輸（reliable data transfer）。當一個運輸協議提供這種服務時，傳送程式只需要將其資料傳遞進套接字，就可以完全相信該資料能夠無差錯地達到接收程式

• 在沿著一條網路路徑上的兩個程式之間的通訊會話場景中，可用吞吐量就是傳送程式能夠向接收程式交付位元的速率

• 由於其他會話將共享沿著該網路路徑的頻寬，並且隨著這些會話的到達和離開，某一會話的可用吞吐量會隨著時間波動。為此，產生一種服務，即運輸層協議能夠以某種特定的速率提供確保的可用吞吐量

• 具有吞吐量要求的應用程式被稱為頻寬敏感應用，與之對應的是彈性應用（能夠根據情況或多或少地利用可供使用的吞吐量）

• 運輸層協議也能提供定時保證，比如：傳送方注入進套接字中的每個位元到達接收方的套接字不遲於100ms

• 運輸層協議能夠為應用程式提供一種或者多種安全性服務，比如：在傳送和接收程式之間提供機密服務（即傳送加密，接收解密），以防該資料在這兩個程式之間直接暴露

---

web && http

• Web 應用的底層協議是超文字傳輸協議（HyperText Transfer Protocol, HTTP），這是 Web 的核心

• Web 頁面由物件組成，一個物件就是一個檔案，該檔案可以是一個 .html檔案，一個 .jpg圖片等等，比如：一個 Web 頁面包含1個 html 基本檔案和2個 css 引用檔案，則這個 Web 頁面包含3個物件

• HTTP 定義了 web客戶與 web伺服器之間進行 http報文交換的方式以及這些報文的結構

• HTTP 使用 TCP 作為它的支撐運輸協議

• HTTP客戶首先通過發起一個與伺服器的 TCP 連線，一旦連線建立，該瀏覽器與伺服器程式就可以通過套接字介面訪問 TCP，然後客戶和伺服器從它的套接字傳送或者接收 HTTP 報文

• 一旦客戶向它的套接字傳送了一個請求報文，該報文就脫離了客戶控制並進入 TCP 控制，由於 TCP 為 HTTP 提供可靠資料傳輸服務，所以在客戶和伺服器交換報文的過程，不必擔心資料丟失

• 這也體現了分層體系的最大優點：HTTP 協議不必擔心資料丟失，也不必瞭解 TCP 從網路的資料丟失和亂序故障中恢復的細節

• HTTP 伺服器不會儲存關於客戶的任何資訊，所以 HTTP 是無狀態協議，這意味著伺服器不會因為剛剛為該使用者提供了物件就不再響應，而是會重新傳送該物件

• RTT指往返時間（Round-Trip Time），該時間指一個短分組從客戶到伺服器然後再返回客戶所花費的時間，RTT 包括分組時延，分組在中間路由器和交換機上的排隊時延以及分組處理時延

• 大致上說，一次 HTTP 請求/響應時間等於兩次 RTT 加上伺服器檔案傳輸檔案的時間

• 客戶到伺服器的每個請求/響應是經單獨的 TCP 連線傳送，則該應用程式使用非持續連線（non-persistent connection）,每個 TCP 連線在伺服器傳送一個物件後關閉，即每個 TCP 連線只傳輸一個請求報文和一個響應報文

• 由此可見，非持續連線的缺點在於：其一，必須為每一個請求物件建立和維護一個全新的連線，對於每個這樣的連線，在客戶和伺服器都要分配 TCP 的緩衝區和保持 TCP 變數；其二，每個物件都要經受兩倍 RTT 的交付時延

• 客戶到伺服器的所有請求/響應是經相同的 TCP 連線傳送，即伺服器在傳送響應後保持該 TCP 連線開啟，在相同的客戶與伺服器之間的後續請求和響應報文能夠通過相同的連線進行傳輸

• HTTP 在其預設方式下使用持續連線

POST http://172.17.2.42/api/task/list-task-for-applicant http/1.1
Host: 172.17.2.42
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3390.0 Safari/537.36
Accept-Language: zh-CN,zh;q=0.9 
複製程式碼

• ☝HTTP 請求報文的通用格式：請求行，首部行，空行，實體主體

  • HTTP 請求報文的第一行叫做請求行（request line），其後繼的行叫做首部行（header line）

  • 請求行包含三個欄位：請求方法，URL，HTTP版本

  • 首部行 Host 指明瞭物件所在的主機，該欄位提供的資訊是 Web 代理快取記憶體所要求的

  • 首部行 Connection 告訴伺服器是否需要持續使用該連線，可取值 keep-alive 或者 close

  • 首部行 User-Agent 用來指明使用者代理，即向伺服器傳送請求的瀏覽器型別

  • 首部行 Accept-Language 表示使用者想要得到該物件的語言版本

  • 使用 GET 方法時，實體主體為空，使用 POST 方法時，才使用實體主體

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Sun, 08 Apr 2018 08:47:04 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
Last-Modified: Sun, 08 Apr 2018 08:46:04 GMT

entity body data...
複製程式碼

• ☝HTTP 響應報文的通用格式：狀態行，首部行，空行，實體主體

  • 狀態行包含三個欄位：協議版本，狀態碼和相應的狀態資訊

  • 首部行 Server 指示該報文是由 nginx/1.10.1 伺服器產生的

  • 首部行 Date 指示伺服器從它的檔案系統找到該物件，插入到響應報文，並且傳送該響應報文的日期和時間

  • 首部行 Content-Type 指示了實體主體中的物件型別

  • 首部行 Connection 告訴客戶是否需要持續使用該連線，可取值 keep-alive 或者 close

  • 首部行 Last-Modified 最後修改日期和時間，對於本地客戶和代理伺服器上的物件快取來說很重要

  • 實體主體是響應報文的主要部分，它包含了所請求的物件本身

• cookie 可以在無狀態的 HTTP 之上建立一個使用者會話層，允許站點對使用者進行跟蹤

• cookie 技術包含四個元件：

  • 在 HTTP 響應報文中有一個 cookie 首部行

  • 在 HTTP 請求報文中有一個 cookie 首部行

  • 在使用者端系統中保留一個 cookie 檔案，並由使用者的瀏覽器進行管理

  • 位於 Web 站點的一個後端資料庫

• Web 快取器也叫代理伺服器，它是能夠代表初始 Web 伺服器來滿足 HTTP 請求的網路實體

• 在 Internet 上部署代理伺服器的兩個原因：

  • 代理伺服器可以大大減少對客戶請求的響應時間

  • 代理伺服器可以大大減少一個機構的接入鏈路到 Internet 的通訊量

• HTTP 協議有一種機制，允許代理伺服器證實它的物件是最新的，這種機制就是條件GET方法

• 條件GET方法實現要求

  • 請求報文使用 GET 方法

  • 請求報文中含有 If-Modified-Since 首部行

• 代理伺服器在儲存響應物件的同時，也對其響應報文的 Last-Modified 值進行儲存，當同一物件再次被請求時，代理伺服器會在請求報文中新增 If-Modified-Since 欄位，且其值等於之前儲存的 Last-Modified 的值，通過該條件GET方法告訴伺服器，僅當自指定日期之後該物件被修改過，才傳送此物件

• 如果響應物件未被修改，則 Web 伺服器還是會向代理伺服器傳送響應報文，但是該響應報文中不包含所請求的物件，並且最後響應報文中，狀態行為 304 Not Modified

---

FTP 檔案傳輸協議

• 使用者首先提供遠端主機的主機名，使本地主機的 FTP客戶程式建立一個到遠端主機 FTP伺服器程式的 TCP 連線

• 隨後，該使用者提供使用者標識和口令，作為 FTP 命令的一部分在該 TCP 連線上傳送

• 一旦該伺服器向該使用者授權，使用者可以將存放在本地檔案系統中的檔案與遠端檔案系統檔案進行傳輸

• FTP 使用兩個並行的 TCP 連線來傳輸檔案，一個是控制連線（control connection），一個是資料連線（data connection）

• 控制連線用於在兩主機之間傳輸控制資訊，如使用者標識，口令以及檔案操作命令

• 資料連線用於實際傳送一個檔案

• 當使用者主機與遠端主機發起一個 FTP 會話時，FTP客戶首先與FTP伺服器發起一個用於控制的 TCP 連線（即控制連線），當 FTP伺服器從該連線上接收到一個檔案傳輸的命令後，就會發起一個到 FTP客戶的 TCP 資料連線

• 對 FTP 傳輸而言，控制連線貫穿整個會話期間，但是資料連線是非持續連線，會話中每一次檔案傳輸都需要建立一個新的資料連線

• FTP伺服器必須在整個會話期間追蹤使用者的狀態，將使用者賬戶與控制連線關聯，這就大大地限制了 FTP 同時維持的會話總數

---

E-mail

• Internet 郵件電子郵件系統的構成：使用者代理（user-agent）、郵件伺服器（mail server）和簡單郵件傳輸協議（Simple Mail Transfer Protocol, SMTP）

• SMTP 使用 TCP 可靠資料傳輸服務

• SMTP 用於從傳送方的郵件伺服器傳送報文到接收方的郵件伺服器

• SMTP 將一個報文從傳送郵件伺服器傳送到接收郵件伺服器的過程

  • SMTP客戶（執行在傳送郵件伺服器上）建立一個到SMTP伺服器（執行在接收郵件伺服器上）的 TCP 連線

  • 如果伺服器未開機，客戶會繼續嘗試連線

  • 一旦連線建立，客戶與伺服器執行某些應用成握手，在 SMTP 握手階段，SMTP客戶指示傳送方和接收方的郵件地址

  • SMTP客戶傳送報文，如果客戶有另外的報文要繼續傳送到該伺服器，則會在同一 TCP連線上繼續傳送，否則，客戶指示 TCP連線關閉

• SMTP 和 HTTP 的區別

  • HTTP 主要是一個拉協議（pull protocol），即在方便的時候，有些人在 Web伺服器上裝在資訊，使用者使用 HTTP 從該伺服器上拉取這些資訊，特別是 TCP連線是由想接收檔案的機器發起的

  • SMTP 主要是一個推協議（push protocol），即傳送郵件伺服器把檔案推向接收郵件伺服器，特別是TCP連線是由要傳送該檔案的機器發起的

  • SMTP 強制要求每個報文使用 7 byte 的 ASCII 編碼，HTTP 資料則不受這種限制

  • 對待含有引用的檔案物件，HTTP 把每個物件封裝在自己的 HTTP響應報文中，而 SMTP 則會把所有報文物件放在一個報文裡面

• 郵件報文格式需要由包含環境資訊的首部行，首部行和報文實體通過換行分隔，每個首部必須含有一個 From: 首部行，一個 To: 首部行

• 使用者代理A ---> (SMTP) ---> 郵件伺服器A ---> (SMTP) ---> 郵件伺服器B ---> (POP3,IMAP,HTTP) ---> 使用者代理B

• 這這個過程中，使用者代理A是 SMTP客戶，郵件伺服器A即是 SMTP伺服器也是 SMTP客戶，郵件伺服器B是 SMTP伺服器

• 實際上，SMTP 被設計成將電子郵件從一臺主機推到另一臺主機

• 為什麼使用者代理A要通過郵件伺服器A作為中繼，而不是直接將郵件推送給郵件伺服器B呢？

  • 代理伺服器A將沒有任何辦法到達一個不可達的目的地接收伺服器

  • 如果郵件伺服器A不能將郵件交付給郵件伺服器B，郵件伺服器A會在一個報文列隊中保持該報文並在以後嘗試再次傳送，如果一定時間後仍不能成功，郵件伺服器A就會刪除該報文，並且以郵件形式通知使用者代理A

• 使用者代理B從郵件伺服器B上取報文是一個拉操作，而 SMTP 協議是一個推協議，因此需要引入郵件訪問協議來解決難題，包括 POP3（Post Office Protocol-Version 3）、IMAP（Internet Mail Access Protocol）以及 HTTP

• POP3 按照三個階段進行工作：特許，事務處理，更新

  • 特許階段，使用者通過明文形式傳送使用者名稱和口令認證使用者

  • 事務處理階段，使用者可以進行一系列操作，比如獲取郵件的統計資訊，標記刪除報文，取回報文等

  • 更新階段，在使用者發出 quit 命令之後，目的是結束 POP3 會話，此時，郵件伺服器會刪除被標記刪除的報文

• 在使用者代理與郵件伺服器之間的 POP3 會話期間，POP3伺服器會保留一些狀態資訊，特別是記錄被標記刪除的報文，然而，POP3伺服器並不在POP3會話過程中攜帶狀態資訊，這大大簡化了 POP3 服務的實現

• IMAP伺服器將每個報文與資料夾聯絡起來，為使用者提供建立遠端資料夾併為報文指派資料夾的方法

• IMAP協議為使用者提供在郵件伺服器新建資料夾，移動郵件，閱讀郵件，刪除郵件等命令

• 與 POP3 不同，IMAP伺服器維護了 IMAP會話的使用者狀態資訊

• IMAP協議的另一個重要特性就是它具有允許使用者代理獲取獲取報文元件的命令

---

DNS 因特網的目錄服務

• 主機名和IP地址是識別主機的兩種方式，人們喜歡主機名的標記方式，而路由器則更喜歡定長的，有著層次結構的IP地址，為此，我們需要一種能進行主機名到IP地址轉換的目錄服務，這就是域名系統（Domain Name System, DNS）

• DNS 是一個由分層的 DNS伺服器實現的分散式資料庫；是一個使得主機能夠查詢分散式資料庫的應用層協議

• DNS 協議執行在 UDP 之上，使用53埠

• DNS 提供的一些重要服務

  • 主機名到IP地址的轉換

  • 主機別名（區別於規範主機名），有著複雜主機名的主機能擁有一個或者多個別名

  • 郵件伺服器別名

  • 負載分配，比如一個訪問頻繁的站點冗餘分佈在多個伺服器上，因此一個規範主機名與IP地址集合對應，DNS資料庫中儲存著這些IP集合，當客戶對對映到某地址集合的名字發出一個 DNS 請求，該伺服器用IP地址集合進行響應，但是在每次回答中迴圈這些地址次序。由於客戶總數項IP地址集合排在最前面的伺服器傳送請求，所以 DNS 就在所有這些冗餘的伺服器之間迴圈分配了負載

• 從使用者主機上呼叫應用程式的角度看，DNS 是一個提供簡單直接的轉換服務的黑盒子。實際上，DNS 是由分佈於全球的大量 DNS 伺服器以及定義了 DNS 伺服器與查詢主機通訊方式的應用成協議組成

• DNS 一種集中式設計是指，在 Internet 中只使用一個 DNS 伺服器，它包含了所有的對映。儘管這種設計很簡單，但是它並不適用，原因如下：

  • 單點故障（a single point of failure），如果該 DNS 伺服器崩潰，則整個 Internet 隨之癱瘓

  • 通訊容量（traffic volume），單個 DNS 伺服器必須處理所有的 DNS 查詢

  • 遠距離的集中式資料庫（distant centralized database），在全球化的 Internet 環境中，單個 DNS 伺服器不可能臨近所有地區

  • 維護（maintenance），單個 DNS 伺服器必須為所有的主機保留記錄，這回讓其變得難以維護

• 為此，DNS 採取了分散式的設計方案，在 Internet 上實現分散式資料庫

• 為了處理擴充套件性問題，DNS 使用了大量的 DNS 伺服器，它們以層次方式組織，並且分佈在全世界範圍內，並且沒有一臺 DNS 伺服器擁有 Internet 的所有主機的對映

• 大致來說，有三種型別的 DNS 伺服器：

  • 根DNS伺服器

  • 頂級域（Top-Level Domain, TLD）DNS伺服器

  • 權威DNS伺服器

• 此外，還有一類重要的 DNS 伺服器，為本地DNS伺服器（local DNS server）,本地DNS伺服器嚴格來說並不屬於分散式DNS伺服器的結構層次，但是其對於 DNS 層次結構是重要的。當主機發出 DNS 請求時，該請求被髮往本地 DNS 伺服器，它起著代理的作用，並將該請求轉發到 DNS 伺服器層次結構中

• 為了改善時延效能並減少在 Internet 上傳輸的 DNS 報文數量，大量使用了 DNS快取（DNS caching）。例如，本地DNS伺服器能夠快取權威DNS伺服器某主機/IP的對映，並且在一段時間將丟棄快取資訊

• 共同實現 DNS 分散式資料庫的所有 DNS 伺服器儲存了資源記錄（Resource Record，RR），RR 提供了主機名到 IP 地址的對映。而每個 DNS 響應報文包含了若干條資源記錄

• 資源記錄是一個4元組，包含 Name, Value, Type, TTL 四個欄位，TTL 是該資源記錄的生存時間，它決定了資源記錄應該從快取中刪除的時間。Name 和 Value 的值取決於 Type

  • Type 為 A，則 Name 為主機名，Value 為 IP 地址

  • Type 為 NS，則 Name 為個域，Value 為該域中主機IP地址的權威DNS伺服器的主機名，這個記錄用於沿著查詢鏈來路由 DNS 查詢

  • Type 為 CNAME，則 Name 為主機別名，Value 為別名為 Name 的主機所對應的規範主機名

  • Type 為 MX，則 Value 是個別名為 Name 的郵件伺服器的規範主機名

• DNS 只有兩種報文：DNS查詢報文和DNS回答報文，兩種報文格式相同，包含五個區域

  • 首部區域，包含識別符號，標誌，問題數，回答RR數，權威RR數，附加RR數

  • 問題區域，查詢的名字和型別欄位

  • 回答區域，對查詢的響應中的RR

  • 權威區域，權威伺服器的記錄

  • 附加區域，可被使用的附加“有幫助的”資訊

• 通過本地主機向DNS伺服器傳送 DNS查詢報文，win-r-cmd操作後，控制檯輸入 nslookup，呼叫 nslookup 程式，然後輸入 Web 站點即可

• DDoS 通過向每個 DNS 伺服器傳送大量分組，使得大多數合法的 DNS 請求得不到回答

• 中間人攻擊，攻擊者截獲來自主機的請求並返回偽造的回答

• DNS毒害攻擊，攻擊者向一臺 DNS 伺服器傳送偽造的回答，誘使伺服器在它的快取中接收偽造的記錄