
改變的速度,即對學習來講,最重要的東西是學習的方法,在特定的技術中如何靈活地適應改變,當你在職業生涯中前行時,在新的機會和可能性方面如何保持開放的思想 --Marc Andreessen
應用層
研發網絡應用程序的核心是寫出可以運行在不一樣的端系統和經過網絡彼此通訊的程序css
進程通訊
- 在操做系統中,進行通訊的其實是進程(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/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...

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 將一個報文從發送郵件服務器傳送到接收郵件服務器的過程json
- 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呢?api
- 代理服務器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 服務器發送僞造的回答,誘使服務器在它的緩存中接收僞造的記錄