網絡模塊相關知識總結

http協議以及與https的區別

http概念:超文本傳輸協議,是互聯網上應用最爲普遍的一種網絡協議.

工做原理:

• 首先客戶機與服務器須要創建鏈接,只要單擊某個超級連接,http的工做就開始了
• 創建鏈接後,客戶機發送一個請求給服務器.請求方式的格式:統一資源定位符,協議版本號,後面是MIME的信息
• 服務器接收到請求後,給與響應的響應信息,其格式爲一個狀態行,包括信息的版本號,一個呈貢 或者錯誤代碼.
• 客戶端接收到服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上,而後客戶機和服務器斷開鏈接

注意:若是在以上過程當中的某一步出現錯誤,那麼產生錯誤的信息將返回到客戶端,由顯示屏顯示
複製代碼

http特色

• 簡單快速
• 靈活
• http0.9和1.0使用非持續鏈接
• 無狀態
• 支持B/S和C/S模式

http請求消息

一個請求消息包括:請求行 請求頭 請求主體

http響應消息

一個響應消息包括: 狀態行 響應頭 響應主體

http和https

• Http：超文本傳輸協議（Http，HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。設計Http最初的目的是爲了提供一種發佈和接收HTML頁面的方法。它可使瀏覽器更加高效。Http協議是以明文方式發送信息的，若是黑客截取了Web瀏覽器和服務器之間的傳輸報文，就能夠直接得到其中的信息。

• Https：是以安全爲目標的Http通道，是Http的安全版。Https的安全基礎是SSL。SSL協議位於TCP/IP協議與各類應用層協議之間，爲數據通信提供安全支持。SSL協議可分爲兩層：SSL記錄協議（SSL Record Protocol），它創建在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議（SSL Handshake Protocol），它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

Http與Https的區別

一、https協議須要到CA申請證書，通常免費證書較少，於是須要必定費用。(原來網易官網是http，而網易郵箱是https。)

二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

四、http的鏈接很簡單，是無狀態的。Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。(無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無鏈接的意思是指通訊雙方都不長久的維持對方的任何信息。)

TCP/IP協議(三次握手及緣由/四次揮手)

（1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。

  （2）確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。

  （3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義以下：

  （A）URG：緊急指針（urgent pointer）有效。

  （B）ACK：確認序號有效。

  （C）PSH：接收方應該儘快將這個報文交給應用層。

  （D）RST：重置鏈接。

  （E）SYN：發起一個新鏈接。

  （F）FIN：釋放一個鏈接。
複製代碼

TCP協議是網絡協議中最基本的協議之一,TCP是一種面向鏈接的.可靠的,基於字節流的傳輸層通訊協議.

深刻理解TCP協議

• 因爲TCP是全雙工的，所以在每個方向都必須單獨關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。
• 收到一個FIN只意味着這個方向上沒有數據流動，一個TCP鏈接在接收到一個FIN後仍能發送數據。
• 首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。 TCP協議的鏈接是全雙工鏈接，一個TCP鏈接存在雙向的讀寫通道。簡單來講，是「先關讀，再關寫」 ，總共須要4個階段。以客戶機發起關閉鏈接爲例：
  • 1.服務器讀通道關閉；
  • 2.客戶端寫通道關閉；
  • 3.客戶端讀通道關閉；
  • 4.服務器寫通道關閉。

關閉行爲是在發起方數據發送完畢以後，給對方發出一個FIN（finish）數據段，直到接收到對方發送的FIN,且對方收到了接收確認的ACK以後，雙方的數據通訊徹底結束，過程當中每次都須要返回確認數據段ACK。

三次握手

• 第一次握手:創建鏈接時,客戶端發送syn(同步序列編號)包到服務器,
• 第二次握手:服務器收到syn(同步序列編號)必須確認客戶的syn,同時服務器本身也發送一個syn(syn+ack).
• 第三次握手,客戶端收到服務器的syn+ack包,向服務器發送確認包,確認完畢以後TCP鏈接成功

四次揮手(別名:鏈接終止協議)

• 先由客戶端向服務器端發送一個FIN，請求關閉數據傳輸。

• 當服務器接收到客戶端的FIN時，向客戶端發送一個ACK，其中ack的值等於FIN+SEQ

• 而後服務器向客戶端發送一個FIN，告訴客戶端應用程序關閉。

• 當客戶端收到服務器端的FIN是，回覆一個ACK給服務器端。其中ack的值等於FIN+SEQ

爲何是四次揮手?

• 確保數據可以完整傳輸。

• 當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方了。

• 但未必被動方全部的數據都完整的發送給了主動方，因此被動方不會立刻關閉SOCKET,它可能還須要發送一些數據給主動方後，

• 再發送FIN報文給主動方，告訴主動方贊成關閉鏈接，因此這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

UDP協議

概念:無鏈接協議，也稱透明協議，也位於傳輸層。

TCP和UDP的區別

• 1） TCP提供面向鏈接的傳輸，通訊前要先創建鏈接（三次握手機制）； UDP提供無鏈接的傳輸，通訊前不須要創建鏈接。
• 2） TCP提供可靠的傳輸（有序，無差錯，不丟失，不重複）； UDP提供不可靠的傳輸。
• 3） TCP面向字節流的傳輸，所以它能將信息分割成組，並在接收端將其重組； UDP是面向數據報的傳輸，沒有分組開銷。
• 4） TCP提供擁塞控制和流量控制機制； UDP不提供擁塞控制和流量控制機制。

UDP協議主要特色：

  1.UDP是無鏈接的，發送數據以前不須要創建鏈接（結束以後天然也不用釋放鏈接），減小了開銷和發送數據的時延

  2.UDP使用盡最大努力交付，即不保證可靠交付，不須要維持複雜的鏈接狀態表

  3.UDP是面向報文的，對應用層交下來的報文，添加首部後直接向下交付爲IP層，既不合並，也不拆分，保留這些報文的邊界。對IP層交上來 UDP用戶數據報，在去除首部後就原封不動地交付給上層應用進程，報文不可分割，是UDP數據報處理的最小單位。

UDP協議優點：

  1.UDP沒有擁塞控制，網絡出現的擁塞不會使源主機的發送速率下降，在容許網絡發生擁塞時丟失一些數據而且維持較低的時延時，UDP符合這種要求

  2.UDP支持一對一，一對多，多對一和多對多的交互通訊

  3.UDP的首部開銷小，只有8個字節，比TCP的20個字節首部要短   

UDP協議應用場景：

  要發送的內容少，一個數據包就能發送所有內容。

  即時通訊（聊天對數據準確性和丟包要求比較低，但速度必須快），在線視頻（ 速度必定要快，保證視頻連續，可是偶爾花了一個圖像幀，人們仍是能接受的），網絡語音電話（VoIP 語音數據包通常比較小，須要高速發送，偶爾斷音或串音也沒有問題）等等。

get和post的區別

• get是從服務器上請求數據,post是發送數據到服務器.
• 事實上,get方法是把數據參數隊列放到一個url裏面,值和表單是一一對應的,在隊列裏面,值和表單用一個&符號分開,空格用+號替換,特殊符號用十六進制轉換
• 隊列的參數就能看到,能夠被記錄或者更改
• get方式還限制字符的大小(256k)
• post方法能夠沒有時間限制的傳遞數據到服務器,用戶在瀏覽器端是看不到這一過程的,因此post方式比較適合發送一個保密或者是比較大的數據到服務器
• get 的方式的安全性較post方式較差一些,包含機密信息的話建議用post方式
• 在作數據查詢的時候,建議使用get方式,可是在作數據的增刪改的時候建議使用post方式

常見的狀態碼

1××：保留
    2××：表示請求成功地接收
    3××：爲完成請求客戶需進一步細化請求
    4××：客戶錯誤
    5××：服務器錯誤
複製代碼

• 200 請求被正常處理
• 204 請求被受理但沒有資源能夠返回
• 206 客戶端只是請求資源的一部分，服務器只對請求的資源執行GET方法，相應報文中 經過Content-Range 指定範圍的資源
• 301 永久性重定向
• 302 臨時重定向
• 303 與302狀態碼有類似的功能，只是它希- 望客戶端應使用GET方法定向獲取請求的資- 源
• 304 發送附帶條件的請求時，條件不知足時- 返回，與重定向無關
• 307 臨時重定向，與302相似，只是強制要求使用post方法
• 400 請求報告語法有誤，服務器沒法識別
• 401 請求須要認證
• 403 請求的對應的資源禁止被訪問
• 404 服務器沒法找到對應的資源
• 410（已刪除）若是請求的資源已永久刪除，服務器就會返回此響應。
• 500 服務器內部錯誤
• 503 服務器正忙

從輸入網址到得到頁面的過程

• 在瀏覽器中輸入url(解析url地址)
• 在應用層DNS解析域名
• 應用層客戶端發送http請求
• 傳輸層TCP傳輸報文(3次握手)
• 網絡層IP協議查詢MAC地址
• 數據到達數據鏈路層
• 服務器接收數據
• 服務器響應數據
• 服務器返回響應的文件

計算機分層體系結構

OSI七層參考模型

• （1）物理層（Physical，PH）傳遞信息須要利用一些物理傳輸媒體，如雙絞線、同軸電纜、光纖等。物理層的任務就是爲上層提供一個物理的鏈接，以及該物理鏈接表現出來的機械、電氣、功能和過程特性，實現透明的比特流傳輸。在這一層，數據尚未組織，僅做爲原始的比特流提交給上層——數據鏈路層。
• （2）數據鏈路層（Data-link，D）數據鏈路層負責在2個相鄰的結點之間的鏈路上實現無差錯的數據幀傳輸。每一幀包括必定的數據和必要的控制信息，在接收方接收到數據出錯時要通知發送方重發，直到這一幀無差錯地到達接收結點，數據鏈路層就是把一條有可能出錯的實際鏈路變成讓網絡層看起來像不會出錯的數據鏈路。實現的主要功能有：幀的同步、差錯控制、流量控制、尋址、幀內定界、透明比特組合傳輸等。
• （3）網絡層（Network，N）網絡中通訊的2個計算機之間可能要通過許多結點和鏈路，還可能通過幾個通訊子網。網絡層數據傳輸的單位是分組（Packet）。網絡層的主要任務是爲要傳輸的分組選擇一條合適的路徑，使發送分組可以正確無誤地按照給定的目的地址找到目的主機，交付給目的主機的傳輸層。
• （4）傳輸層（Transport，T）傳輸層的主要任務是經過通訊子網的特性，最佳地利用網絡資源，並以可靠與經濟的方式爲2個端系統的會話層之間創建一條鏈接通道，以透明地傳輸報文。傳輸層向上一層提供一個可靠的端到端的服務，使會話層不知道傳輸層如下的數據通訊的細節。傳輸層只存在端系統中，傳輸層以上各層就再也不考慮信息傳輸的問題了。
• （5）會話層（Session，S）在會話層以及以上各層中，數據的傳輸都以報文爲單位，會話層不參與具體的傳輸，它提供包括訪問驗證和會話管理在內的創建以及維護應用之間的通訊機制。如服務器驗證用戶登陸即是由會話層完成的。
• （6）表示層（Presentation，P）這一層主要解決用戶信息的語法表示問題。它將要交換的數據從適合某一用戶的抽象語法，轉換爲適合OSI內部表示使用的傳送語法。即提供格式化的表示和轉換數據服務。數據的壓縮和解壓縮、加密和解密等工做都由表示層負責。
• （7）應用層（Application，A）這是OSI參考模型的最高層。應用層肯定進程之間通訊的性質以知足用戶的需求，以及提供網絡與用戶軟件之間的接口服務。

TCP/IP四層體系結構

• 應用層
• 運輸層
• 網絡層
• 網絡接口層

五層體系結構(最經常使用)

• 應用層
• 運輸層
• 網絡層
• 數據鏈路層
• 物理層

DNS的工做原理

• 第一步：客戶機提出域名解析請求，並將該請求發送給本地的域名服務器。
• 第二步：當本地的域名服務器收到請求後，就先查詢本地的緩存，若是有該紀錄項，則本地的域名服務器就直接把查詢的結果返回。
• 第三步：若是本地的緩存中沒有該紀錄，則本地域名服務器就直接把請求發給根域名服務器，而後根域名服務器再返回給本地域名服務器一個所查詢域(根的子域) 的主域名服務器的地址。
• 第四步：本地服務器再向上一步返回的域名服務器發送請求，而後接受請求的服務器查詢本身的緩存，若是沒有該紀錄，則返回相關的下級的域名服務器的地址。
• 第五步：重複第四步，直到找到正確的紀錄。
• 第六步：本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時還將結果返回給客戶機。

CDN託管

概念:CDN的全稱是Content Delivery NetWork,即內容分發網絡
複製代碼

• CDN是構建在網絡之上的內容分發網絡
• CDN使用戶就近獲取所需內容,下降網絡擁塞,提升用戶訪問響應速度和命中率
• CDN依靠部署在各地的邊緣服務器,包括中心平臺的負載均衡 內容分發 調度等功能模塊