應用程序體系結構：
C-S結構：即客戶端-服務器結構（client-server architecture），由一個總是打開的服務器和任意多個提交請求的客戶端組成，通常服務器由多個數據中心組成，一個數據中心可能由數十萬臺服務器（硬件）組成，所以那些大公司要新建一個服務器就會去找一個山清水秀的地方，重點是要有河，先建一座電站，再在旁邊建數據中心，因爲很耗電。
P2P結構：（P2P architecture），應用程序在間斷連接的主機間直接通信，主機指用戶使用的各種終端，這些終端稱爲對等方。具有很好的自擴展性，不需要大型服務器集羣，成本友好，但也有缺點也不少。
應用程序
進程通信：用戶在使用分佈在各種終端系統中的應用程序進行通信時，其實是應用程序（中的進程）在通信，與計算機中的進程通信一樣，只不過通信的信號是通過網絡傳遞的。
套接字：進程要使用網絡進行通信，就要使用套接字軟件接口向網絡發送報文和從網絡接收報文，套接字也稱爲網絡與應用程序之間的應用程序編程接口。
進程尋址：網絡進程通過ip地址找到主機，通過端口號定位通信目標進程。
運輸服務
可供應用程序選擇的運輸服務有以下四類：傳輸可靠性、吞吐量、定時和安全性。
傳輸可靠性：應用程序是否需要可靠數據傳輸，如微信轉賬，肯定需要可靠數據傳輸，否則你轉100元，傳輸過去少了個0，變成了10，這肯定不行啊，但有的傳輸，如圖片，少了一些比特還是能看的，也許你根本看不出來。
吞吐量：應用程序需要多少吞吐量，如微信視頻時，需要有一定的吞吐量保證。
定時：應用程序是否需要提供定時（實時）保證，即是否需要實時傳輸數據，如網絡遊戲LOL就需要保證實時，否則對面都噴他kill了你還在那滑太空步。
安全性：應用程序是否需要保證數據傳輸的安全性，如用戶賬號密碼需要保證安全性，網絡共享圖片之類的就不需要。
運輸層提供的服務：
因特網運輸層只提供了可靠數據傳輸、安全性保證，沒有提供定時和吞吐量這兩種需求服務。運輸層協議有兩種：TCP和UDP。
TCP：面向連接服務、連接全雙工、可靠數據傳輸、擁塞控制機制（TCP試圖限制每個TCP連接，使它們達到公平的網絡帶寬共享）。
SSL：安全套接字層（secure sockets layer）是TCP的加強版，能實現TCP的所有功能，在此之外還提供了安全性服務，包括加密、數據完整性和端點鑑別。SSL不是UDP和TCP之外的第三個運輸層協議，而是TCP的加強版，雖然它有自己獨立的API。SSL並不總是需要，在不需要安全性保證的傳輸中，可以直接用TCP而不用SSL。
UDP： UDP提供了最小服務，它是一種不提供不必要服務的輕量級運輸協議，UDP幾乎只有傳輸功能，除此之外的可靠數據連接、擁塞控制、安全性等等都不提供。它的優點是快。
應用層協議：定義了交換報文的類型（如請求報文和響應報文），報文語法（即報文段的各個字段），字段語義，進程如何接收報文以及如何響應。應用層協議包括多種，HTTP、SMTP、DNS等。
HTTP
HTTP：超文本傳輸協議（HyperText Transfer Protocol），是傳輸web頁面組成對象的協議，包括html基本文件和其他對象（如圖片，css文件，JavaScript文件等）。HTTP由兩部分組成，客戶端和服務器，服務器存儲了所有web所需的資源，客戶端通過URL來向服務器請求資源。
URL：統一資源定位符（uniform resource locator），由兩部分組成，服務器主機名和資源路徑。
無狀態： HTTP是無狀態協議，它不保存用戶信息，用戶第二次向服務器發送請求時服務器並不認識它。爲了實現HTTP狀態存儲，引入了cookie。
非持續連接：假設使用TCP協議進行傳輸，每個請求/響應對通過單獨的TCP連接的HTTP通信方式。由於TCP連接有三次握手四次揮手，非持續連接將消耗大量的時間。
持續連接：所有請求/響應對通過同一個TCP連接進行的HTTP通信。
HTTP報文：包括請求報文和響應報文兩種。
請求報文：一個 請求行，多個首部行，請求行由三個字段組成：方法字段、URL字段和HTTP版本字段。首部行數目不定，由通信時的環境決定。
GET /somedir/page.html HTTP/1.1
Host:www.baidu.com
Connection:close
……
響應報文：一個狀態行、多個首部行、一個實體行。狀態行包括3個字段：協議版本字段、狀態碼、相應狀態信息。首部行數目不定，由通信時的環境決定。實體行是報文主體，包括相應的對象。
HTTP/1.1 200 OK
Connection:close
Date: Tue, 09 Aug 2017 15:44:03 GMT
……
cookie： cookie是爲保存HTTP狀態而出現的。客戶端首次訪問服務器，服務器放回一個帶有set-cookie：id的字段，提示客戶端在本地cookie文件中添加一行（服務器主機名和發送過來的id），服務器也將用戶的信息（可以是用戶賬號密碼、訪問記錄、購買記錄之類的具有商業價值的東西，也可以是一些其他信息）和對應id存儲到cookie數據庫中。第二次訪問，請求報文中將包含一個cookie：id字段，服務器可以通過該id查詢數據庫找到請求客戶端的信息並作出相應的操作（如自動登錄、購買推薦等）。
web緩存： web緩衝器（web cache）也叫代理服務器，如果所有web請求都直接向主服務器請求，那麼當訪問量過大時主服務器將負擔過重，而且遠距離的請求速度也很慢，代理服務器是設置在一個公司、或學校或者一個地區的一個web緩衝器，它緩存這個地方用戶請求的內容一段時間，當用戶在此請求相同資源時，就可以直接從這獲得而不必要向主服務器請求。
條件GET：使用代理服務器可以減少網絡帶寬壓力，同時提高訪問速度，但有時候代理服務器上的內容過於陳舊，需要向主服務器請求新內容，這時就可以用條件GET方法進行請求，如通過在首部中加入“if-modified-since:時間”字段，告訴代理服務器，如果這個請求的文件在給定時間之後修改過才返回，否則不用返回。除此之外，還有很多條件GET相關的字段，如”if-unmodified-since”（通過時間進行匹配），”if-range”“if-match”“if-none-match”（通過實體標記Etag進行標記）等，可以去看《圖解HTTP》這本書，該書上詳細介紹了HTTP的各種首部字段。
一個大致的圖示，我盡力了：
HTTP狀態碼：
可以參考：百度百科
2開頭表示成功，3開頭表示重定向，4開頭表示客戶端錯誤，5開頭表示服務器端錯誤。
200：OK
204：no content（只要狀態行和首部行，沒有內容）
206：Partail content（客戶端只請求部分資源）
400：bad request
403：forbidden
404：not found
FTP
FTP:文件傳輸協議（file transfer protocol），與HTTP類似，都是在兩個終端（主機）之間傳輸文件且都使用TCP進行傳輸，不同的是，FTP傳輸文件需要兩個並行的TCP連接進行傳輸，一個控制連接，一個數據連接。
控制連接：用於向連接對象發送控制信息，如用戶名、密碼、改變目錄、查看目錄文件列表、put、get文件等。在Linux環境中使用FTP連接，可以參看博文：點擊鏈接
數據連接：用於put和get時傳輸文件實體。
郵件傳輸協議SMTP
郵件系統：由用戶代理（user agent），郵件服務器（mail server）、簡單郵件傳輸協議SMTP（simple mail transfer protocol）組成。用戶代理我的理解就是一個用戶的client端，郵件服務器包含各個用戶對應的郵箱，郵件服務器互聯。整個系統的郵件傳輸運行於SMTP協議上。
SMTP：簡單郵件傳輸協議，客戶端運行SMTP協議的應用程序默認通過25端口進行通信。
爲什麼要將郵件先傳輸到發送方郵件服務器再傳傳輸到接收方郵件服務器呢？
主要是如果沒有郵件服務器做中轉，接收方若未開機，郵件將不可達，而郵件服務器可以暫存郵件報文，如果接收方服務器未打開，發送方服務請將暫存郵件報文，並一段時間內持續（如每30分鐘一次）向接收方服務器發送直到其服務器打開。
與HTTP的比較：都使用持續連接的TCP進行通信，都是從一個主機向另一個主機發送文件，區別是：
SMTP是一個“推協議”，且報文必須以7bit的ASCII字符編碼，就算圖片等文件也是，當處理一個有圖片的文檔時，SMTP將所有文件對象放在一個報文中。SMTP在兩個郵件服務器之間直接傳輸報文，不經過任何的中間服務器，就算他們距離很遠（來自《計算機網絡——自頂向下第六版》）。
HTTP傾向一個“拉協議”，報文沒有7bit限制，當處理一個有圖片的文件時，HTTP將對象封裝到它自己的報文中，HTTP可以有代理服務器。
郵件報文格式：必須包含from：和to：首部行，還有其他可選字段如subject：首部行。
From:[email protected]
To:[email protected]
Subject:searching for ght meaning of life
...
[空行]
[報文體data data data......]SMTP客戶與SMTP服務器通信：真的是向兩個人在對話一樣。
...TCP連接...
S:220 lx.edu
C:HELO test.edu
S:250 Hello test.edu,pleased to meet you
C:MAIL FORM:<alice@someschool.edu>
S:250 alice@someschool.edu
C:RCPT TO:<boo@someschool.edu>
S:250 boo@someschool.edu ... sender ok
C:DATA
S:354 Enter mail,end with "." on a line by itself
C:Do you love me?
C:.
S:250 Message accepted for delivery
C:QUIT
S:221 lx.edu closing connection郵件訪問協議
郵件訪問協議： POP3、IMAP以及HTTP，當郵件到達接受方郵件服務器時，由於SMTP是推協議（即SMTP只負責往外送資源，不負責向外部請求資源），所以客戶端不能使用SMTP 主動訪問服務器郵件，在這種情況下引入了郵件訪問協議。
POP3：第三版郵件協議（post office protocol version 3）是一個很簡單的郵件訪問協議，它的工作流程包括：特許（即用戶驗證）、事務處理（刪查郵件）、更新（更新用戶操作）。
客戶端連接POP3服務器： POP3郵件服務器對每個命令作出回答，但回答只有兩種：+OK（後面跟服務器回覆客戶端的數據）和-ERR（後面跟錯誤信息），郵件服務器的默認端口爲110，假設我們使用Telnet登錄名爲“mailserver”的POP3郵件服務器：
Telnet mailserver 110
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged onPOP3服務器事務處理：連接成功之後，用戶可以通過以下四個命令（應該還有其他命令）對郵件進行操作：list（列出）、retr（retrieve取回）、dele（delete刪除）、quit（退出），POP3服務器在連接斷開之後並不保存用戶狀態（僅在連接狀態下保存用戶標記爲刪除的那些郵件信息，僅此而已），所有POP3應該算是無狀態協議吧，下面一個簡單例子：
...telnet登錄...
C：list //列出所有郵件
S：1 123 //郵件1
S：2 456 //郵件2
S：. //結束
C：retr 1 //取回郵件1
S：（data ...... data） //郵件1
S：. //結束
C：dele 1 //將郵件1標記爲刪除，並不立即刪除
C：retr 2
S：（data ... data）
S：.
C：dele 2
C：quit //退出
S：+OK POP3 server signing off //斷開連接，服務器將標記爲刪除的郵件刪除IMAP：因特網郵件訪問協議（Internet mail access protocol）相對POP3要複雜的多，相應的，提供的服務也很多。在POP3服務器中，所有郵件都是存儲在一起的，沒有分類，沒有狀態，這使得用戶很不方便，所以IMAP協議運營而生，下面是一些重要特性：
IMAP服務器把每個郵件與一個文件夾聯繫起來，用戶可以通過命令來管理文件夾以及其中的郵件。
IMAP維護了郵件狀態，如郵件與其關聯的文件夾。
IMAP允許用戶獲取郵件報文組件的一個部分，如只獲取報文頭，這是一個很有用的特性特別是那些有大附件的郵件，有時用戶只希望獲取郵件的列表，而不關心郵件的內容和附件內容，就只需要獲取報文頭就行了。
基於web的郵件： 20世紀90年代中期Hot-mail引入了基於web的郵件，現在越來越多的郵件都可以通過web瀏覽器進行管理，用戶通過瀏覽器發送郵件到郵件服務器，通過瀏覽器向郵件服務器請求郵件，使用的都是HTTP協議而不再試SMTP，但郵件服務器之間的互聯仍然使用的是SMTP。
主機標識：主機名和IP地址。IP地址和主機名是一種映射關係，可以使多對多，用於表示網絡中的端系統（即主機）。
主機名：由一系列易於人類理解的ASCII碼按照一定的格式組成個，如www.baidu.com，其優點是可讀性強，但是計算機和路由器並不擅長處理這些字符串，尤其是在通過這個字符串來進行路由的時候，它更喜歡定長、有層次結構的IP地址。
IP地址：就是易於計算機處理的一個32位（4字節）的數字，它有很嚴格的層次結構，如192.168.1.1，通過這些層次結構，可以很方便地找到路由出口（下一跳要跳到哪）。
主機名和IP地址分別適用於人類和計算機，但是人要和計算機打交道，就得把主機名和IP地址進行轉換，DNS就是幹這個工作的一個系統。
DNS：域名系統（domaim name system）其實就是一個存儲主機名與ip地址映射關係的分佈式數據庫，當你輸入主機名時，DNS通過查詢這些分佈式數據庫來講對應的ip地址返回給你，這樣計算機就可以用這個ip地址來進行路由了。
通過ip地址訪問網站：我們在瀏覽某個網站的時候我們一般會輸入主機名來進行訪問，其實，我們也可以使用ip地址來訪問的，如你可以輸入下面的ip地址來訪問百度：
111.13.101.208
123.125.114.144
220.181.57.217
但是我們更喜歡用www.baidu.com來訪問百度，因爲它好記。
運行於UDP上： DNS協議運行於UDP上，也就是說主機與路由器、與DNS服務器、與主機之間傳輸DNS查詢報文在運輸層是通過UDP協議進行傳輸的，不需要建立連接，這樣加快了查詢速度，也不需要可靠傳輸（TCP），因爲傳輸失敗之後可以再次請求，也不需要保密傳輸（SSL），因爲DNS數據是在整個網絡共享的。
端口： DNS協議默認使用53端口進行數據傳輸。
是應用層協議： DNS協議運行於應用層，其一，它使用C-S模式運行，其二，它使用運輸層協議UDP傳輸DNS報文（所以它得在應用層，否則就不能使用UDP了）。
功其他應用層協議使用： DNS協議不是面向用戶的，而是面向應用程序的，相當於在應用層和運輸層之間加了一個DNS層（只是這麼理解，但DNS是應用層的），當應用程序需要域名轉換時，就將主機名（或ip地址）發送給DNS，DNS將通過運輸層發送查詢，將結果返回給應用程序。
當用戶通過一個url發送http請求時：基本流程如下（SMTP/FTP等請求也一樣）
> 瀏覽器抽取URL中的主機名部分傳送給運行在用戶主機上的DNS應（如在Unix機器上應用程序可以調用gethostbyname()函數來調用DNS服務）；
> DNS查詢本地數據庫，看是否有需要的映射關係，若有，直接返回給瀏覽器，若沒有，向DNS服務器（或代理）發送一個請求報文。
> DNS服務器收到請求，查詢數據庫，若找到，則返回結果，給DNS應用，再返回給瀏覽器，若爲找到，返回“未找到”（也許還有向其他服務器查詢的步驟，簡單起見，就這查一次好了）。
>瀏覽器收到ip地址，向ip地址發起TCP連接。若未收到ip地址，則告訴用戶該主機不存在。
DNS時延： DNS服務爲我們提供了域名查詢服務，但也增加了時延，如向一個遠地址發送請求時可能DNS查詢的時延會很大，所以我們可以將這種主機名與ip地址的映射關係緩存在附近的服務器中。如你第一次向美國發送一個訪問請求需要10秒，第一次查詢之後將映射緩存起來，第二次也許只用1秒。
單點部署：所有DNS服務器部署在一個地方，爲全球所有查詢提供響應。這樣部署有很多缺點，如單點故障，整個互聯網將崩潰；遠距離查詢時延高；流量需求大；維護困難等。
分佈式部署： DNS服務器按層次結構分佈在全球不同地方，沒有一臺服務器上擁有全球所有的主機-ip映射關係。按照層次結構大致分爲以下幾類：
根DNS服務器：整個因特網有13個DNS服務器，大部分分佈在北美洲，爲了提供安全性和可靠性，每個服務器又由多個服務器主機組成。
頂級域DNS服務器（top-level domain， TLD）：維護所有的頂級域名如com、org、net、edu等，以及所有的國家頂級域名如uk、ca、jp、cn等。每個域名服務器由不同公司維護，如Educause公司維護edu頂級域的TLD服務器。
權威DNS服務器：有各個組織機構實現並維護的DNS服務器，如大學、公司等。
本地DNS服務器：嚴格來說它不屬於DNS服務器結構層次，有地方ISP（因特網提供商）維護。
DNS查詢方式：假設A爲用戶主機，BCDE分別爲DNS服務器，A需要DNS查詢。
遞歸查詢：上一層查詢結果返回給下一層，再層層返回直到源主機A。
迭代查詢：每一層查詢結果都直接返回給源主機A，所有請求都有主機A發起。
實際應用中：有主機A向本地DNS服務器的查詢是遞歸的，其他查詢是迭代的。
DNS緩存：爲了改善時延性能減少因特網中傳輸的DNS報文數量，引入了DNS緩存，DNS服務器緩存經過它們的所有映射關係，保留一段時間後丟棄，這樣當第二次請求時，如果緩存還在，就不必要再次向根服務器請求了。本地DNS服務器也能緩存TLD服務器的ip地址，所以可以繞過TLD服務器的請求（翻牆？）。
資源記錄（resource record - RR）：以一個四元式存儲所有的主機-ip映射關係，（Name,Value,Type,TTL）,TTL是生存時間。
name和value的類型取決於type的值：
