趁著這個學習的勢頭，將應用層的知識整理下。  在初次學習時，這一塊的知識老師教的是比較的粗略的。現在看來這並不是一個十分明智的決定。  應用層絕不是一個簡單的層次。   只有比較系統的學習應用層的知識，在實踐過程中我們的疑惑才會具有清晰的思路，才會對一個知識點就一定的認識深度！

     應用層：

          每個應用層協議都是為了解決某一類應用問題，而問題的解決又必須通過位於不同主機中的多個應用程式之間的通訊和協同工作來完成的。

          應用層協議應當定義：

           應用程式交換的報文型別，如請求報文和響應報文；

           各種報文型別的語法，如報文中的各個欄位極其詳細含義。

           欄位的語義，即包含在欄位中的含義。

           程序何時，如何傳送報文，以及對報文進行響應的規則。

    域名系統DNS:

            早在ARPANET時代，整個網路上只有數百臺計算機，那時使用一個叫做hosts 的檔案， 列出所有主機名字和相應IP地址。 只要使用者輸入一個主機名，計算機就可以很快的把這個主機名字轉換成極其能夠識別的二進位制IP地址。

             需要注意，DNS在1983年就決定採用了梳妝命名的方式進行命名，這說明了它並不是為了全球資訊網的服務而存在的。  切切， 因為我們經常使用域名去訪問網站，長久以來很容易造成這樣的一個誤區。 此外，能夠通過ping 域名的方式通訊，也證明了這一點。

            在一定程度上，我們可以將域名與IP地址等價。 對於計算機而言，認證的域名與IP具有同等效果。

             因特網的域名系統被設計成一個聯機分散式資料庫系統，並採用客戶-伺服器模式。  DNS使大多數名字都在本地進行解析，僅少量解析需要在因特網上通訊。

              DNS的工作模式：

                 當某一個應用程式需要把主機名解析成IP地址時，該應用程式便呼叫解析程式，併成為DNS的一個客戶，將待解析的域名放在DNS請求中，以UDP的方式法給本地域名伺服器。  本地域名若查詢到域名，便將ip地址放入回答報文。  若找不到，則此域名伺服器就暫時成為另一個域名伺服器的客戶，併發送查詢請求，迴圈這個過程直到完成業務邏輯。 

               需注意，常說的13大根域名伺服器絕不是僅僅由13個機器組成，而是十三套裝置。

  檔案傳送協議FTP：

       網路環境中的一項基本任務就是將檔案從一臺計算機中複製到另一臺計算機中。（對計算機而言，距離是透明的）。 

       檔案傳輸面臨的問題：

             計算機儲存格式的不同；

             檔案的目錄結構和檔案命名的規定不同。

             對於相同的檔案存取功能，作業系統使用的命令不同。

             訪問控制方法不同。

      FTP的工作模式：

           FTP使用客戶伺服器模式。一個FTP伺服器程序可同時位多個客戶程序提供服務。 FTP的服務程序由兩個部分組成： 一個主程序，負責接收新的請求； 另外有若干個重屬程序，負責處理單個請求。

            主程序的工作步驟：  開啟熟知埠21，使得客戶能夠連線上---》 監聽客戶程序發出的連線請求---》 啟動從屬程序來處理客戶程序發出的請求---》 回到監聽狀態。

        當客戶程序向伺服器程序發出建立連線請求的時候，要尋找伺服器的數值埠21，同時告訴伺服器程序自己的另一個埠號碼，用於建立資料傳送連線。   接著，伺服器程序用自己傳送資料的熟知埠20與客戶程序所提供的埠號碼建立資料傳送連線。 因此，資料連線與控制連線採用了不同的端對端鏈路，不會發生混亂。 

遠端終端程式TELNET：

      TELNET簡介： 

                  一個遠端終端協議，也是因特網的正式標準。 使用者使用 TELNET 就可以在所在地的主機通過TCP連線註冊到遠端的一個主機上。 TELNET 將使用者的擊鍵傳到遠地主機，同時將遠端主機的輸出通過TCP連線返回到使用者螢幕。 在PC功能不是很強大的年代，使用的較多。  又被稱為 終端模擬協議。  它的工作模式依然是基於客戶機伺服器模式。

      TELNET針對不同計算機與作業系統適配方案：

          TELNET定義了資料和命令通過因特網的方式----網路虛擬終端NVT（Network Virtual Terminal).類似於調變解調器的功能。

全球資訊網WWW：

        本質： 一個大規模的，聯機式的資訊儲藏所。

         解決的問題：

                在因特網範圍內區分全球資訊網文件。

                使用何種協議實現全球資訊網的各種連結。

                不同的全球資訊網文件如何在使用者層面統一標準，並易用。

                 怎樣方便的定位文件。

          問題的解決方式:  分別為： URL，HTTP,HTML，搜尋工具！

      HTTP協議介紹：

          從層次的角度看，HTTP是面向事務的應用層協議，它是全球資訊網上能夠可靠地交換檔案（文字，聲頻，視訊，影象，其它二進位制檔案等）的重要基礎。

          HTTP協議是無狀態的，這簡化了伺服器的設計，使得伺服器更容易支援大量併發的HTTP請求。

          HTTP/1.0版本的協議中，在TCP連線確認的第三個階段傳送請求報文。  連線完成後該TCP連線即斷開。  所謂斷開，指的是銷燬該次連線的快取與變數。   所以當大量併發，並且非持續連線的時候伺服器開銷會增大。

          HTTP/1.1使用了持續連線。 即當一次連線完成後任然在一段時間保持該連線。它有兩種工作模式： 流水線 以及非流水線的方式。  它的作用類似於TCP的連續ARQ 的功能。  。。  注意，這裡的流水概念是針對單條鏈路而言的！！

     代理伺服器：

        代理伺服器是一種網路實體，又稱為 全球資訊網快取記憶體。它將最近的一些請求和響應咱存在本地磁碟中。 當有新的請求與該請求一致，則返回暫存的響應，無需再去因特網上拉取。

     HTTP的報文結構: 

         HTTP有兩類報文結構。請求報文和響應報文！

         HTTP是面向文字的，因此在報文中的每一個欄位都是一些ASCII碼串，因而各個欄位的長度都是不確定的。所以我們應該是可以在請求頭與響應頭中加一些引數的。 並且即使加錯了一些引數，只要對端的伺服器不限制，整個交換過程任然是沒有問題的。

      cookie:

         RFC 2109 對Cookie進行了定義，規定全球資訊網站點可以使用Cookie來跟蹤使用者。  cookie由服務端與客戶端共同提供支援。  通常，cookie的設定是通過伺服器進行的，伺服器在響應報文頭部加一個Set-cookie的首部，瀏覽器收到該響應後，會將該Cookie統一管理。  之後的連線瀏覽器會自覺的在請求報文中帶上Cookie請求頭。 

        由於Cookie涉及到使用者隱私，因此使用者有權利拒絕接收Cookie的自由。  在瀏覽器中使用者可自行接受設定接收Cookie的條件。

     HTML:  關於html最有效的說明莫過於瀏覽器的認識了，我曾今整理的筆記：這裡

電子郵件：

      背景：

                   實時通訊的電話有兩個這樣的缺點： 1是通訊的主叫方和被叫方必須同時在場。  2是有些電話常常打斷人們的工作和休息。 

                 1982年，簡單右鍵傳送協議 SMTP(Simple Transfer Protocol) 和因特網文字報文格式問世，email很快風靡。其只能傳送可列印的7位ASCII碼郵件。

                 1993年，通用因特網郵件擴充MIME(Multipurpose Internet Mail Extensions)聲明瞭郵件的資料型別（如文字，聲音，影象，視訊等）。 在MIME中可以傳送多種型別的資料。

      構成：

            一個電子郵件系統具有三個主要的構件：

                    1.使用者代理。   執行在客戶端的一個程序，如foxmail。 是使用者與email的介面。

                    2.郵件伺服器。 既然是伺服器，這也決定了它必須24小時工作。它的作用是傳送和接收郵件，同時反饋郵件傳送結果。 需要具備郵件傳送協議如SMTP 以及郵件讀取協議 如POP3 的支援。  並且它必須能同時充當某一個協議的客戶端與服務端角色。

                    3.傳送協議SMTP以及 讀取協議POP3（Post Office Protocol郵局協議第三版）。  他們分別對應兩種不同的工作方式。 SMTP客戶端把郵件“推”給SMTP伺服器； POP3客戶端將郵件從POP3服務端“拉”過來。

        電子信箱的構成：

                  由信封和內容兩部分構成。  信封地址的組成方式： 使用者名稱@郵件伺服器域名。

        SMTP的工作概述： 連線建立；  郵件傳送；   連線釋放。

        POP3的工作概述： 使用客戶機-伺服器的方式；  當一個使用者從POP伺服器讀取了郵件，POP伺服器就會把該郵件刪除。 常見的做法是設定儲存時間。  也可以將其持久化。

        基於全球資訊網的電子郵件Webmail：  特點是在使用者代理與郵件伺服器之間的通訊使用HTTP協議而不是SMTP。 

        MIME的組成： MIME標準規定： Content-Type 必須含有兩個識別符號，即內容型別 和 子型別。 中間用 / 隔開。MIME標準最初定義了7個基本型別，15個子型別。

動態主機配置協議DHCP：

      背景： IP地址不僅包括主機號，還包括網路號。 當計算機出廠時，無法固化IP。 因此，需要連線到因特網，需要進行協議配置。 DHCP提供一種機制實現即插即用聯網。 DHCP對於執行客戶機與伺服器的計算機都適用。

       動態主機協議的執行過程概述：

          DHCP使用客戶-伺服器方式。 需要IP地址的主機在啟動時就向DHCP伺服器廣播發送  發現報文。（將目的地IP地址全為1，即255.255.255.255），這是該DHCP就成為DHCP客戶。 傳送廣播報文的時候還不知道DHCP伺服器的地址，因此要發現 DHCP伺服器的IP地址。 這個主機目前沒有自己的IP地址，因此它將IP資料報的源IP地址設為全0. 這樣，在本地網路的所有主機都能夠收到這個廣播報文，但是隻有DHCP伺服器才對此廣播進行回答。  DHCP伺服器先在其資料庫中查詢該計算機的配置資訊。 若找到則返回該配置資訊。若找不到，則從伺服器的IP地址池中去一個地址分配給該計算機。 DHCP伺服器的回答報文叫做提供報文，表示“提供”了該IP地址。

          通常情況下，我們不願意每個網路都有一個DHCP伺服器，這樣會使得伺服器數量過多。 因此常用的做法是每一個網路至少有一個DHCP中繼代理（通常是路由器）。 當DHCP中繼收到給廣播報文，就以單播形式向DHCP伺服器轉發該報文，並等待其回答。

          DHCP分配的IP地址是臨時的。 將一個地址被分配期間，稱為租用期。 值得注意的是，DHCP客戶機可以在自己傳送的報文中提出對租用期的要求。

簡單網路管理協議SNMP:

      背景： 

              網路是一個非常複雜的分散式系統。  這是因為網路上有很多不同廠家生產的，執行這多種協議的節點（主要是路由器）。 而這些節點還在相互通訊和交換資訊。 網路的狀態總是不斷變化著。 

      網路管理模型的架構：

            管理站，又稱為管理器，是整個網路管理系統的核心，通常是個有著良好圖形介面的高效能工作站，並由網路管理員直接操作和控制。 

            被管裝置 ， 可以是主機，路由器，印表機，集線器，網橋或者調變解調器等。 

            網路管理代理程式，簡稱代理，用於悲觀裝置與管理站的通訊，執行在被管裝置中。 

            網路管理協議，又稱網管協議。 

        簡單網路管理協議的工作模式：

            管理程式執行SNMP客戶程式， 代理程式執行SNMP伺服器程式。在被管物件上執行的SNMP伺服器程式不停地監聽來管理站的SNMP客戶程式的請求。   SNMP由三個部分組成： SNMP本身，慣例資訊結構SMI，管理資訊庫MIB。、

應用程序跨越網路的通訊：

       背景： 如果我們有一些特定的應用需要因特網的支援，但這些應用又不能直接使用已經標準化的因特網應用協議（如，以上的應用層協議），那麼應當做哪些工作？？  通過系統呼叫 和應用程式程式設計介面。 

                 我的思考： 這說明一個問題： 也就是說，我們所開發的任意一個聯網的應用，在邏輯上跟這些個標準協議是處於同一個重要級別的。  邏輯地位是等價的！！！！

        詳細過程：

           當某個應用程序啟動系統呼叫時，控制權就從應用程序傳遞給了系統呼叫介面。 此介面再把控制權傳遞給計算機的作業系統。 作業系統就把這個呼叫轉給某個內部過程，並執行所請求的操作。 內部過程一旦執行完畢，控制權就又通過系統呼叫介面返回給應用程序。 

            現在的TCP/IP協議軟體已經駐留在作業系統中。 由於TCP/IP協議族被設計成能執行再多種作業系統的環境中，因此TCP/IP標準沒有規定應用程式與TCP/IP協議軟體如何對接的細節，而是允許系統設計者能夠選擇有關API的具體實現細節。  最著名的是美國加利福利亞大學伯克利分校為 Berkeley UNIX 作業系統定義的一種API,它又稱為套接字介面；；  ；  windows 形成了一個稍有不同的WinSock; AT&T為其UNIX定義了一種TLI(transport Layer Interface)的API。

            從另一種角度看，計算機之間的通訊就是本計算機要讀取另一個地點的計算機中的資料，或者要把資料從本計算機寫入到另一個地點的計算機中。 這種“讀取” 以及“寫入” 都需要用到系統呼叫。 

           再討論網路程式設計時，常常把套接字作為應用程式和運輸層協議之間的介面。 現在套接字介面已經成為了作業系統核心的一部分。   注意，在套接字以上的程序是受應用程式控制的，而在套接字以下的運輸層協議軟體則是受計算機作業系統控制。  使用者對套接字以下的運輸層具有很少的控制，如可以選擇運輸層協議，以及一些運輸層引數僅此而已。 

          當應用程式進行網路通訊時，必須首先發出Socket系統呼叫，請求作業系統為其建立一個套接字。  這個呼叫的實際效果就是： 請求作業系統將所需要的一些系統資源（儲存器空間，CPU時間，網路頻寬等）分配給該應用程序。（這也是為什麼在java的finally塊經常要釋放資源的來源吧！！！）。  作業系統為這些資源的總和用一個叫做 套接字描述符 的號碼來表示，然後把這個套接字描述符返回給應用程序。     套接字實際上時應用程序為了獲得網路通訊服務而與作業系統進行互動時使用的一種機制。

        TCP連線建立階段：

              當套接字建立後，它的埠號和IP地址都是空的，因此應用程序呼叫bind 來指明 套接字的本地地址（本地IP和本地埠號）。  客戶端也可以不呼叫bind， 這是作業系統核心會自動分配一個動態埠號（通訊結束後收回）。   伺服器在呼叫bind後，還需呼叫listen將套接字設定為被動方式，一遍隨時接收客戶的服務請求。 

               當一個客戶的請求到來，伺服器中的主服務程序M（就是通常所說的伺服器程序）呼叫accept，就為每個新的連線請求建立一個新的套接字，並把這個新建立的套接字的識別符號返回給發起連線的客戶方。    與此同時，主伺服器程序還要建立一個從屬伺服器程序來處理新建立的連線。  這樣，從屬伺服器程序用這個新建立的套接字和客戶程序建立連線，而主伺服器程序用原來的套接字繼續監聽，接收下一個請求。 

               在已建立的連線上，從屬伺服器程序就使用這個新建立的套接字傳送和接收資料。 資料通訊結束後，從屬伺服器程序就關閉這個新建立的套接字，同時這個從屬伺服器程序也被撤銷。 

               當使用TCP協議的客戶已經呼叫了socket建立了套接字後，客戶程序就呼叫connect， 以便和遠端伺服器建立連線。  在connect系統呼叫中，客戶必須指明遠端地址（包括IP地址和埠號）。 

              我的補充： 注意，這裡有兩個比較容易混淆的概念： 應用程式的埠  以及 Socket描述符。  它們都是邏輯存在的，並且都是用整數表示。 但是二者並沒有一毛錢關係。 

         TCP傳送階段： 

              客戶和伺服器都在TCP連線上使用send系統呼叫傳送資料，使用 recv系統呼叫接收資料。 通常客戶使用send傳送請求，而伺服器使用send 傳送回答。 

               呼叫send 需要三個變數： 資料要傳送的套接字描述符（針對本機而言），要傳送的資料地址（針對本機而言），以及資料的長度。  通常 send呼叫把資料複製到作業系統核心的快取中。 若系統的快取已滿，send就暫時阻塞，知道快取有空間存放新的資料。 

               呼叫recv也需要三個變數： 要使用的套接字描述符（針對本機而言）， 快取的地址以及快取空間的長度（針對本機而言） 。 

            TCP釋放階段：

                 一旦客戶或者伺服器結束使用套接字，就把套接字撤銷。 這時呼叫 close 系統呼叫釋放連線和撤銷套接字。 （抽象的釋放和撤銷）。