【轉載】瀏覽器與服務器通訊的過程

時間 2019-11-11

標籤轉載瀏覽器服務器通訊過程欄目瀏覽器简体版

原文原文鏈接

首先當用戶在瀏覽器的地址欄中敲入了網站的網址 ( 好比: alibaba.com ) ,這時瀏覽器會首先經過訪問的域名來定位到IP (DNS) 從而找到去哪裏獲取資源, 這時, 瀏覽器會依次進行以下查找:css

1. 瀏覽器緩存 :html

瀏覽器首先會在本身的緩存中查找有沒有對應的域名 – IP匹配, 若是好運的話, 這裏就能夠直接嘗試去訪問資源了, 若是運氣平平則往下走吧.前端

2. 系統緩存 :算法

瀏覽器緩存中沒有命中, 瀏覽器會告訴操做系統:」嘿, 我在我本身口袋裏沒找到, 可能丟了, 我得去你那看看」, 而後, 一個系統進程(?)調取系統中的DNS緩存進行查詢, 重複上一條的運氣判斷…數據庫

3. 路由器緩存 :瀏覽器

走到這, 運氣還真不太好啊, 操做系統也沒轍了, 那怎麼辦呢, 向路由去要要看吧… 重複運氣判斷…緩存

4. ISP DNS緩存 :服務器

好吧, 真不知道說運氣好仍是運氣很差了, 不廢話, 去ISP (網絡提供商) 的DNS緩存服務器中尋找了, 通常狀況下, 在ISP端的緩存中都能找到相應的緩存記錄了, 不應這麼背了, 或者… 您的ISP有夠菜…網絡

5. 遞歸搜索…網站

最無奈的狀況發生了, 在前面都沒有辦法命中的DNS緩存的狀況下, ISP的DNS服務器開始從root域名服務器開始進行遞歸, 順序是從.com頂級域名服務器到alibaba的域名服務器, 再沒找到…好吧, 您認爲您要去的網站真的公開存在麼…?

兩個KEY POINT:

首先咱們想一想，咱們要和接線員通話是否是要約定一個你們都能聽得懂的語言，不然我說中文他說英語，這樣就誰也聽不懂誰的話，也不會完成通話，那麼這個約定的語言是什麼呢？那就是HTTP協議。

超文本傳輸協議(HTTP，HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。

咱們能夠把它理解成一種瀏覽器和服務器都遵循的一種語法規範，全部的信息都是經過這種語法規範傳輸的，這樣瀏覽器和服務器均可以正確的理解。

瀏覽器和服務器通常並非直接鏈接上的，而是須要經過中間的網絡設備，就像咱們的聲音並非直接傳到接線員的耳朵裏，而是要經過電話線經過電波傳送同樣，瀏覽器和服務器所發送的遵循HTTP協議的信息也要經過網絡設備的傳遞才能被對方所接收。而這就須要一種在網絡設備（網線）上傳輸數據的一種通用的語法規範（協議）。這樣的協議使用最多的有2種：TCP協議和UDP協議

下面讓咱們來看看咱們瀏覽網頁的時候發生了什麼吧。

１．首先咱們在地址欄上輸入咱們想要打開的網址，而後咱們一般會按下回車。這樣一個請求就由瀏覽器以一種知足http協議的請求報文的形式發往服務器，請求報文中包含了要請求的頁面地址，請求的文件類型等一系列信息。

２．在請求報文傳遞至客戶端得網絡設備的時候，網絡設備把請求報文包裝在一個知足TCＰ協議的數據中，經過網線傳向服務器的網絡設備。

３．服務器的網絡設備接收到數據後，使用特殊的算法將數據解譯，從新恢復成瀏覽器發出知足http協議的請求報文的形式，而後傳向服務器軟件。

４．服務軟件獲得請求報文後，根據請求報文所請求的頁面地址在服務器的數據庫中找到相應的頁面，而後生成知足http協議的響應報文發向瀏覽器。響應報文中包括了響應報文頭和被請求頁面的代碼（響應報文體）。

５．一樣的，響應報文經過服務器的網絡設備，被包裝在一個知足TCＰ協議的數據，經過網線傳向客戶端的網絡設備。

６．客戶端的網絡設備將響應報文解析，而後傳給瀏覽器軟件，瀏覽器在將響應報文解析，這樣咱們就在瀏覽器上看到了想要看到的網頁。

B/S（Browser/Server）結構就是瀏覽器/服務器結構，它是隨着Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶工做界面是經過WWW瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，可是主要事務邏輯在服務器端（Server）實現，造成所謂三層3-tier結構。本文將主要講解瀏覽器和服務器通訊的過程。

瀏覽器和服務器之間的通信並非看上去那麼簡單，裏面仍是有着許多的門道的。想要簡單理解瀏覽器和服務器之間的通信，咱們能夠打一個簡單的比方：

設想咱們本身就是瀏覽器，服務器就是10086語音服務檯，咱們如今想要和10086服務檯取得聯繫（好比說想騷擾接線員MM），咱們該怎麼辦呢？

固然，大多數人都應該想到，那就是要有部電話。是這樣的，這就引出了咱們的第一個概念：套接字(Socket)。

套接字在百度百科上的解釋是：

多個TCP鏈接或多個應用程序進程可能須要經過同一個 TCP協議端口傳輸數據。爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP／IP協議交互提供了稱爲套接字(Socket)的接口。

這個解釋太學術了，咱們能夠簡單把套接字理解成一個電話，咱們能夠從中發送信息和獲取信息。

好了，電話有了，咱們該給10086服務檯打電話了。等等，咱們是否是忘了一點，給10086打電話是否是要保證10086服務檯也要有一部電話來等待咱們的來電呢？對的，那麼就是說服務器端也要有一個套接字，專門接受瀏覽器的請求。通常當一個服務器啓動服務後就會開啓一個監聽鏈接的套接字，專門等待瀏覽器鏈接，接受瀏覽器請求。

接下來咱們要開始打電話了。大多數人都應該有給10086服務檯打電話的經驗吧，接通後並非立刻由接線員MM來接聽你的電話的，而是根據語音提示選擇你想要的服務。當你選擇了語音服務之後，系統纔會自動給你安排一個接線員MM來接聽你的電話。那麼這個過程是否是又生成了一個套接字呢？是的，沒錯，咱們能夠把呼叫系統（也就是給你語音提示，讓你選擇服務的系統）當成專門接受瀏覽器的請求的那個套接字，當瀏覽器發送了一個請求後系統自動生成一個專門和你的瀏覽器通訊的套接字，這樣咱們就能夠和接線員MM通話了，瀏覽器也就能夠和服務器通訊了。

固然這遠遠不是B/S結構的所有，咱們還須要進一步深化：

仍是先來看百度百科上的解釋：

咱們就能夠把它理解成一種瀏覽器和服務器都遵循的一種語法規範，全部的信息都是經過這種語法規範傳輸的，這樣瀏覽器和服務器均可以正確的理解。

TCP---傳輸控制協議,提供的是面向鏈接、可靠的字節流服務。當客戶和服務器彼此交換數據前，必須先在雙方之間創建一個TCP鏈接，以後才能傳輸數據。TCP提供超時重發，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另外一端。

UDP---用戶數據報協議，是一個簡單的面向數據報的運輸層協議。UDP不提供可靠性，它只是把應用程序傳給IP層的數據報發送出去，可是並不能保證它們能到達目的地。因爲UDP在傳輸數據報前不用在客戶和服務器之間創建一個鏈接，且沒有超時重發等機制，故而傳輸速度很快。

無論使用哪一種方法，總之這樣網絡設備間也有了一套傳輸的協議，這樣一來，瀏覽器和服務器才能真正的實現通訊。

下面讓咱們來看看咱們瀏覽網頁的時候發生了什麼吧。

２．在請求報文傳遞至客戶端得網絡設備的時候，網絡設備把請求報文包裝在一個知足TCＰ協議的數據中，經過網線傳向服務器的網絡設備。

３．服務器的網絡設備接收到數據後，使用特殊的算法將數據解譯，從新恢復成瀏覽器發出知足http協議的請求報文的形式，而後傳向服務器軟件。

５．一樣的，響應報文經過服務器的網絡設備，被包裝在一個知足TCＰ協議的數據，經過網線傳向客戶端的網絡設備。

６．客戶端的網絡設備將響應報文解析，而後傳給瀏覽器軟件，瀏覽器在將響應報文解析，這樣咱們就在瀏覽器上看到了想要看到的網頁。

以上只是瀏覽器與服務器之間通訊的最簡單的形式，實際使用中，一個網頁每每包含着html代碼，js代碼，css樣式表，圖片等等多種數據，而這些數據並非一次性由服務器傳給瀏覽器的，而是存在着必定的順序。首先服務器收到瀏覽器的請求後會將html代碼發給瀏覽器，瀏覽器收到響應後會解析響應報文，發現html代碼中包含着js代碼和css樣式表，而瀏覽器端並無這些數據，因此瀏覽器會再次發送請求，向服務器請求js代碼或css樣式表數據（注意一次只能請求一種類型的數據），服務器收到請求後，會根據瀏覽器的請求再次找到數據庫中的js文件或css樣式表，將其發送到瀏覽器端。當網頁中包含圖片的時候也是同理。就這樣循環往復，通過屢次瀏覽器的請求和服務器的響應，當瀏覽器發現本身已經有了全部須要的數據後，會中止發送請求，這樣一個完整的網頁就呈如今咱們眼前了。