計算機網絡

計算機網絡

概覽&&術語

網絡協議:

計算機之間爲了實現網絡通訊而達成的一種「約定」或者」規則「，有這種約定不一樣廠商的生產設備，以及不一樣操做系統組成的計算機之間，就能夠實現通訊

網卡MAC碼:

全球唯一的一個固定組織來分配的，未經認證和受權的廠家無權生產網卡。
每塊網卡都有一個固定的卡號，而且任何正規廠家生產的網卡上都直接標明瞭卡號.
通常爲一組12位的16進制數。其中前6位表明網卡的生產廠商。後面的位數是設備號。

計算機網絡協議體系:

---

OSI體系結構:應用層,表示層,會話層,傳輸層,網絡層,數據鏈路層,物理層.
TCP/IP體系結構:應用層,傳輸層,網絡層,數據鏈路層,物理層.
TCP/IP體系:
        應用層:DHCP,HTTP,HTTPS,RTMP,P2P,DNS,GTP,RPC
        傳輸層:UDP,TCP
        網絡層:ICMP,IP,OSPF,BGP,IPSec,GRE
        鏈路層:ARP,VLAN,STP
        物理層:網絡跳線.

網絡模型

URL輸入到顯示頁面

DNS解析(將域名解析成IP地址)-->TCP連接(TCP三次握手)-->發送HTTP請求,-->服務器處理請求並返回HTTP報文-->瀏覽器解析渲染頁面-->斷開鏈接(TCP四次揮手).

URL:統一資源定位符

URL:統一資源定位符 scheme://host.domain:port/path/filename
                   協議 服務器域名/ip 服務器端口 資源路徑 查詢參數
Http:// www.baidu.com: 8080 /ncdcd/uc ?\_page=home&\_redirect=1#/home
        scheme:定義因特網服務類型,常見的協議:http,https,ftp,file.
        host:定義域名主機,http的默認主機是www.
        domain: 定義因特網域名,如:baidu.com
        port: 定義主機上的端口號,如http默認端口號是80
        path:定義服務器上的路徑.
        filename:定義文檔/資源的名稱.
查詢參數:
    ? 保留字,標識查詢字符串的開始.
    search=ruby 參數的鍵/值對
    & 保留字 給查詢字符串添加參數時使用
    results=10  參數的鍵/值對
查詢字符串有最大長度,查詢字符串中使用的鍵/值對兒是顯示在 URL 上的。
查詢字符串中沒法使用空格和特殊字符好比`&`它們必須用 URL 編碼代替

DNS解析

DNS 是一個分佈式數據庫，把像http://www.google.com這樣的域名翻譯成 IP 地址，並將請求映射到遠程服務器.
DNS 服務器集羣是分層級的，沒有任何一個單一的 DNS 服務器中包含全部數據。若是一個 DNS 服務器裏沒有一個請求須要的域名，這個 DNS 服務器就會把請求轉發給這個集羣上更上一層節點的 DNS 服務器。最終，這個域名會在某個 DNS 服務器上的數據庫裏被發現，而後它對應的 IP 地址所表明的設備就會來接受這個請求。
經過在瀏覽器地址欄裏敲 IP 地址也能訪問網站。

瀏覽器在使用HTTPS傳輸數據的流程:

整體來講，https屬於混合加密，使用非對稱祕鑰加密密文通訊的對稱祕鑰，使用對稱祕鑰進行密文通訊，保證了通訊的效率。
首先客戶端經過URL訪問服務器創建SSL鏈接。
服務端收到客戶端請求後，會將網站支持的證書信息（證書中包含公鑰）傳送一份給客戶端。
客戶端的服務器開始協商SSL鏈接的安全等級，也就是信息加密的等級。客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。
服務器利用本身的私鑰解密出會話密鑰。服務器利用會話密鑰加密與客戶端之間的通訊。

TCP的三次握手:

先由客戶端(瀏覽器)發送一個請求到服務器.服務器發送請求數據到客戶端,客戶端發送信息服務端.

發送HTTP請求:

TCP三次握手以後,開始發生HTTP請求報文,請求報文由請求行,請求頭.請求體組成.

服務器發送請求並返回HTTP報文:

略

瀏覽器解析渲染頁面:

HTML與CSS同時解析生成HTML結構樹和CSS結構樹,兩樹合合併成渲染樹,渲染樹計算好信息,繪製頁面.

斷開連接:

當數據傳送完畢,須要斷開TCP連接,發送四次揮手.

HTTP協議

---

好比分析 HTTPS，我會用 Wireshark 從創建 TCP 鏈接時就開始抓包，從二進制最底層來分析裏面的 Record、Cipher Suite、Extension，講 ECDHE、AES、SHA384，再畫出詳細的流程圖，作到「盡收眼底」。
在互聯網世界裏，HTTP 一般跑在 TCP/IP 協議棧之上，依靠 IP 協議實現尋址和路由、TCP協議實現可靠數據傳輸、DNS 協議實現域名查找、SSL/TLS 協議實現安全通訊。此外，還有一些協議依賴於 HTTP，例如 WebSocket、HTTPDNS 等。這些協議相互交織，構成了一個協議網，而 HTTP 則處於中心地位。
HTTP歷史:

1. HTTP 協議始於三十年前蒂姆·伯納斯 - 李的一篇論文；
2. HTTP/0.9 是個簡單的文本協議，只能獲取文本資源；
3. HTTP/1.0 確立了大部分如今使用的技術，但它不是正式標準；
4. HTTP/1.1 是目前互聯網上使用最普遍的協議，功能也很是完善；
5. HTTP/2 基於 Google 的 SPDY 協議，注重性能改善，但還未普及；
6. HTTP/3 基於 Google 的 QUIC 協議，是未來的發展方向。

HTTP協議：

超文本傳輸協議,從客戶端發出請求到服務器並等待響應。
關於協議：HTTP 是一個用在計算機世界裏的協議。它使用計算機可以理解的語言確立了一種計算機之間交流通訊的規範，以及相關的各類控制和錯誤處理方式。
關於傳輸：HTTP 是一個在計算機世界裏專門用來在兩點之間傳輸數據的約定和規範。
關於超文本：所謂「超文本」，就是「超越了普通文本的文本」，它是文字、圖片、音頻和視頻等的混合體，最關鍵的是含有「超連接」，可以從一個「超文本」跳躍到另外一個「超文本」，造成複雜的非線性、網狀的結構關係。
無狀態協議.使開發去模擬web應用有狀態的體驗.兩點不侷限在瀏覽器到服務器，也能夠是服務器到服務器,既把服務器作客戶端.
HTTP/1.1版本=HTTP+SSL/TLS，經過 SSL證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊進行加密。

HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範」。

HTTP原理：

基於TCP/IP通訊協議來傳遞數據的協議，傳輸的數據類型爲HTML文件,、圖片文件, 查詢結果等.

HTTP特色：

支持客戶端/服務端模式，也是一種請求/響應模式的協議.
簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。
靈活：HTTP容許傳輸任意類型的數據對象。傳輸的類型由Content-Type加以標記。
無狀態：無狀態是指協議對於事務處理沒有記憶，後續處理須要前面的信息，則必須重傳（瀏覽器cookie能夠解決這個問題）。

HTTP缺點：

請求信息明文傳輸，容易被竊聽截取.
數據的完整性未校驗，容易被篡改.
沒有驗證對方身份，存在冒充危險。

HTTPS:

在HTTP的基礎上增長SSL/TLS協議安全協議，這些協議由加密算法和哈希算法組成。TLS協議是在SSL的基礎上發展起來的更安全的協議.

HTTPS缺點:

HTTPS協議加密中屢次握手，致使頁面的加載時間延長近50%； 
  HTTPS鏈接緩存不如HTTP高效，會增長數據開銷和功耗； 
  申請SSL證書須要錢，功能越強大的證書費用越高。SSL涉及到的安全算法會消耗 CPU 資源，對服務器資源消耗較大。

HTTP和HTTPS的區別:

HTTPS是HTTP協議的安全版本，HTTP協議的數據傳輸是明文的，是不安全的，
 HTTPS使用了SSL/TLS協議進行了加密處理。默認端口不同，http是80，https是443。
 https協議須要到CA申請證書，通常須要花錢獲取，http不須要。

SSL

SSL 的全稱是「Secure Socket Layer」，由網景公司發明，當發展到 3.0 時被標準化，更名爲 TLS，即「Transport Layer Security」，但因爲歷史的緣由仍是有不少人稱之爲SSL/TLS，或者直接簡稱爲 SSL。
SSL 使用了許多密碼學最早進的研究成果，綜合了對稱加密、非對稱加密、摘要算法、數字簽名、數字證書等技術，可以在不安全的環境中爲通訊的雙方建立出一個祕密的、安全的傳輸通道，爲 HTTP 套上一副堅固的盔甲。

HTTP報文組成：

請求報文構成:請求行：包括請求方法、URL、協議/版本 。請求頭(Request Header)。請求正文
響應報文構成：狀態行 響應頭 響應正文
常見響應頭字段:
            User-Agent：告知服務器客戶端的相關信息，好比瀏覽器的類型、版本等。
            Accept-Encoding：告知服務器，客戶端支持的壓縮格式。
            Cookie: 通常都是經過Cookie信息頭封裝在請求的信息頭部分。
            Content-Type：用來告知服務器，所發送的請求主體的數據類型（數據組織格式）。若是是POST方法，則建議必定指定該信息頭。

常見請求方法

GET:獲取資源，請求指定的頁面信息，並返回實體主體。
POST:向服務器建立資源，提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建，或者對已有資源的修改。
HEAD:相似於get請求，只不過返回的響應中沒有具體的內容，只獲取報頭。
PUT:從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE:請求服務器刪除指定的資源。

請求頭部

請求頭部提供更多關於服務器和要獲取的資源的信息。一些有用的請求頭部是:

字段名	描述	舉例
Host	服務器域名	Host:www.reddit.com
Accept-Language	可接受的語言	Accept-Language: en-US，en;q=0.8
User-Agent	一個標識客戶端的字符串	User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML，like Gecko) Chrome/38.0.2125.101 Safari/537.36
Connection	客戶端鏈接的類型	Connection: keep-alive

HTTP響應

服務器返回的原始數據就是所謂的響應
狀態碼+響應頭部

響應狀態碼

訪問一個網頁時，瀏覽器會向web服務器發出請求。此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭用以響應瀏覽器的請求。

狀態碼分類：

1XX- 信息型，服務器收到請求，須要請求者繼續操做。 
2XX- 成功型，請求成功收到，理解並處理。
3XX – 重定向，須要進一步的操做以完成請求。
4XX – 客戶端錯誤，請求包含語法錯誤或沒法完成請求。
5XX – 服務器錯誤，服務器在處理請求的過程當中發生了錯誤。

常見狀態碼：

200 OK – 客戶端請求成功 301 – 資源（網頁等）被永久轉移到其它URL 302 – 臨時跳轉
400 Bad Request – 客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized – 請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
404 – 請求資源不存在，多是輸入了錯誤的URL 500 – 服務器內部發生了不可預期的錯誤
503 Server Unavailable – 服務器當前不能處理客戶端的請求，一段時間後可能恢復正常。

響應頭部

頭部名稱	描述	舉例
Content-Encoding	數據的編碼類型	Content-Encoding: gzip
Server	服務器的名稱	Server:thin 1.5.0 codename Knife
Location	通知客戶端新的資源位置	Location: http://www.github.com/login
Content-Type	響應數據的類型	Content-Type:text/html; charset=UTF-8

有狀態的WEB應用

HTTP 協議是無狀態的。換句話說，在你的各次請求之間，服務器是不會保留你的 「狀態」 信息。
每一次請求都被認爲是一次全新的請求，不一樣的請求之間並不知道對方的存在.這種」 無狀態性 「使得 HTTP 和互聯網都是 「去中心化」 的，不會輕易被人掌控。 但也是由於這種屬性，使得 web 開發者在開發有狀態的 web 應用時十分的困難。主要技術手段有session(會話),Cookies,異步javascript調用(AJAX).

Session

Cookies

AJAX

AJAX 請求就像是普通請求：發送到服務器的請求依然跟普通請求同樣有着一個 HTTP 請求該有的全部組成部分，而且服務器處理 AJAX 請求的方法跟處理普通請求也是同樣的。惟一不一樣就是，不是經過瀏覽器刷新來處理響應，而一般由客戶端的一些 javascript 代碼來處理。

安全性

同源策略同源策略（ Same-origin policy ）

它容許來自同一站點的資源進行互相訪問而不受限制，可是會阻止其餘不一樣站點對文檔/資源的訪問。換句話說它能夠阻止另外一個站點經過腳原本操縱本站點的文檔。同源的文檔必須有相同的協議，主機名和端口號。舉個例子，
同源策略涉及的是訪問文件內容，而不是連接，你能夠隨意連接到任何 URL。

跨域資源共享技術 CORS

CORS 是一種機制，容許咱們繞過同源策略，從一個域名向另外一個域名的資源發起請求。CORS 的原理是添加新的 HTTP 頭部，來對一些域名受權，那這些域名就能夠發起對本頁面資源的請求。

會話劫持（Session Hijacking）

會話在維持 HTTP 的狀態上扮演着重要的角色。咱們也知道會話 id 做爲一個惟一的令牌來惟一標識一個會話。一般，會話 id 是做爲 cookie 存儲在計算機上的一個隨機字符串. 會話 id 隨着每個到服務器的請求被送往服務器用於惟一標識這個會話。
攻擊者拿到了這個會話 id ，他就會跟用戶共享這一個會話，同時也就能訪問這個 web 應用了。

會話劫持的對策

*   一個比較流行的會話劫持防範措施是重置會話。也就是對於一個用戶認證系統來講，一次成功的登陸包括驗證舊的會話 id 和生成一個新的會話 id 。完成此步驟後，在下一個請求裏，會要求受害者進行身份驗證。而後會話 id 就會改變，這樣攻擊者就沒法訪問到這個會話了。不少網站都採起這種辦法，當用戶在進行敏感操做的時候保證用戶身份的正確性，好比給信用卡充值或者刪除帳戶的時候。
*   另外一個頗有用的方法是給會話設置過時時間。那些不會過時的會話給了攻擊者太多的時間去假裝成一個合法用戶。若是設置了過時時間，好比 30 分鐘，這樣一來攻擊者就不會那麼從容的進行攻擊了。
*   最後，其實咱們已經講過了，另外一個辦法就是整站使用 HTTPS 把攻擊者能獲得會話 id 的可能性降至最低。

跨站腳本攻擊 (XSS)

當你容許用戶輸入的 HTML 和 javascript 在你本身的網站上直接顯示的時候，就有可能遭受這種攻擊。如輸入評論.

跨站腳本攻擊的解決方案

*   阻止此類攻擊的一個辦法就是老是對用戶輸入的內容作無害處理。消除有問題的輸入，好比\`\`標籤，或者使用一個更安全的輸入格式，好比 Markdown，這樣就能夠阻止 HTML 和 javascript 同時出如今用戶的輸入裏。
*   第二個辦法就是在顯示以前轉義用戶輸入的全部數據.若是你須要用戶可以輸入 HTML 和 javascript 代碼，那麼當你顯示這些輸入內容的時候要確保它們被正確轉義，這樣瀏覽器就不會把它們當作代碼給執行了。

雜症

`

URI和URL的區別:

HTTP使用統一資源標識符URI來傳輸數據和創建鏈接。URI： 統一資源標識符。URL： 統一資源定位符。
URI 是用來標示一個具體的資源，咱們能夠經過 URI 知道一個資源是什麼，是一個抽象的相對概念。
URL 則是用來定位具體的資源的，標示了一個具體的資源位置。屬於URI的一個子集，算是URI在的具體實現方式互聯網上的每一個文件都有一個惟一的URL。

post和get的區別:

都包含請求頭請求行，post多了請求body。
get多用來查詢，請求參數放在url中，不會對服務器上的內容產生做用。post用來提交，如把帳號密碼放入body中。
GET是直接添加到URL後面的，直接就能夠在URL中看到內容，而POST是放在報文內部的，用戶沒法直接看到。
GET提交的數據長度是有限制的，由於URL長度有限制，具體的長度限制視瀏覽器而定。而POST沒有。
安全性（冪等性），安全的方法屬於冪等的，get屢次請求，服務端狀態不會改變，屬於冪等，POST執行屢次，每次都會改變服務端狀態，不具有冪等性。