如何進行瀏覽器和Web服務器之間的通信？

Question

任何人都可以解釋在瀏覽器和Web服務器之間進行通信的方式嗎？ 我想學習如何

• GET，POST動詞（以及其他）
• 餅干
• 會議
• 查詢字符串

在幕后工作。

Answer 1

超文本傳輸​​協議（HTTP）是一種用於傳輸網頁的協議（就像您現在正在閱讀的那樣）。 協議實際上只是標准的做事方式。 如果你要見到美國總統或一個國家的國王，那么你將需要遵循特定的程序。 你不能只是走路說“嘿老兄”。 將有一種特定的方式來走路，說話，標准問候以及結束對話的標准方式。 TCP / IP堆棧中的協議用於相同的目的。

TCP / IP堆棧有四層：應用程序，傳輸，Internet和網絡。 在每一層都有不同的協議，用於標准化信息流，每一個都是一個計算機程序（在您的計算機上運行），用於在信息向下移動到TCP / IP堆棧時將信息格式化為數據包。 數據包是應用層數據，傳輸層報頭（TCP或UDP）和IP層報頭（網絡層接收數據包並將其轉換為幀）的組合。

應用層

...包含使用網絡傳輸數據的所有應用程序。 它並不關心數據如何在兩點之間獲得，而且它對網絡狀態知之甚少。 應用程序將數據傳遞到TCP / IP堆棧中的下一層，然后繼續執行其他功能，直到收到回復。 應用層使用主機名（如www.dalantech.com）進行尋址。 應用層協議的示例：超文本傳輸​​協議（HTTP -web瀏覽），簡單郵件傳輸協議（SMTP-電子郵件），域名服務（DNS-將主機名解析為IP地址），僅舉幾例。

應用層的主要目的是在不同操作系統上運行的應用程序之間提供通用的命令語言和語法 - 類似於解釋器。 由使用網絡的應用程序發送的數據被格式化為符合幾個設置標准之一。 由於所有網絡應用程序遵循的標准，接收計算機可以理解正在發送的數據，即使它正在運行與發送方不同的操作系統。

傳輸層

...負責為應用程序分配源和目標端口號。 傳輸層使用端口號進行尋址，范圍從1到65,535。 從0到1023的端口號稱為“眾所周知的端口”。 低於256的數字保留用於在應用層運行的公共（標准）服務。 以下是一些：SMTP為25，DNS為53（域解析為udp，區域傳輸為tcp），HTTP為80。 IANA為其銷售的應用程序分配了256到1023的端口號。

1024到65,535之間的端口號用於客戶端應用程序 - 例如，您用來閱讀此頁面的Web瀏覽器。 Windows只會為基於Windows的PC分配最多5000個端口號的端口號。 每個應用程序都有一個由傳輸層分配給它的唯一端口號，以便當傳輸層接收數據時，它知道將數據提供給哪個應用程序。 例如，當您運行多個瀏覽器窗口時。 每個窗口都是您用於瀏覽網頁的程序的單獨實例，每個窗口都分配了一個不同的端口號，因此您可以在一個瀏覽器窗口中訪問www.dalantech.com而該網站不會加載到另一個窗口中瀏覽器窗口。 使用選項卡式窗口的FireFox等應用程序只需為每個選項卡分配一個唯一的端口號

互聯網層

......是將網絡結合在一起的“膠水”。 它允許發送，接收和路由數據。

網絡層

...由您的網絡接口卡（NIC）和連接到它的電纜組成。 它是用於傳輸和接收數據的物理介質。 網絡層使用前面討論的媒體訪問控制（MAC）地址進行尋址。 MAC地址在制造接口時是固定的，不能更改。 有一些例外，例如DSL路由器允許您克隆PC中NIC的MAC地址。

欲了解更多信息：

• 協議
• TCP / IP

Answer 2

您的瀏覽器首先通過DNS將服務器名解析為IP。 然后它打開與Web服務器的TCP連接，並嘗試通過HTTP進行通信。 通常是在TCP端口80上，但您可以指定另一個（ http://server:portnumber ）。

HTTP看起來像這樣：

連接后，它會發送請求，如下所示：

GET /site HTTP/1.0
Header1: bla
Header2: blub
{emptyline}

例如，標頭可能是Authorization或Range 。 請看這里了解更多。

然后服務器響應如下：

200 OK
Header3: foo
Header4: bar

content following here...

例如，標題可能是Date或Content-Type 。 請看這里了解更多。

有關此協議的更多信息，請查看Wikipedia for HTTP 。

Answer 3

問題各方面的規格鏈接如下：

• GET，POST動詞（以及其他） - HTTP規范詳盡地討論了HTTP通信的所有方面（Web服務器和瀏覽器之間的通信協議）。 它解釋了請求消息和響應消息協議。

• Cookie - 通過將Set-Cookie HTTP標頭附加到HTTP響應來設置。

• QueryStrings - 是第一次出現“？”后HTTP請求中URL的一部分。 字符。 鏈接規范適用於URI規范的3.4節。

• 會話 - HTTP是一種同步的無狀態協議。 可以通過以下方式創建會話或狀態幻覺：（1）使用cookie將狀態數據作為純文本存儲在客戶端的計算機上，（2）傳遞URL中的數據值和請求的查詢字符串，（3）提交POST具有可以指示狀態的值的集合的請求，以及（4）通過由會話密鑰檢索的服務器端持久性機制來存儲狀態信息（會話密鑰是從cookie，URL / Querystring或POST值中解析的）采集。

對HTTP的解釋可以持續數天，但我試圖提供簡明但概念上完整的答案，並包括適當的鏈接以進一步閱讀官方規范。

Answer 4

您的瀏覽器位於TCP / IP之上，因為網絡基於標准，通常是端口80，當您輸入地址時會發生什么，例如google.com，運行瀏覽器的計算機，創建的數據包根據OSI標准封裝在每一層的數據（考慮到不同大小的包絡，打包到下一個大小的每個包絡中），OSI定義了7層，其中一個包含源地址和目的地址（即網站）以二進制編碼。

當它到達第一層時，在OSI術語中，它通過媒體發射器（例如電纜，DSL）傳輸。

如果你通過ISP連接，分層信封包被傳送到ISP，ISP的網絡系統，通過相反的順序解碼透過分層信封包查找地址，然后ISP檢查他們的域名系統數據庫找出他們是否有到該地址的路徑（緩存在內存中，如果有，它會通過互聯網網絡轉發 - 再次分層包裝信封）。

如果沒有，ISP會詢問頂級DNS服務器說'嘿，告訴我你提供的地址路由，即。 然后，頂級DNS服務器將路由傳遞給ISP，然后將其存儲在ISP的服務器內存中。

在成功路由數據包之后，網站服務器發送和接收分層包裝信封（將路由視為到達服務器的路線的路標），這反過來解包分層信封包，提取源地址和說'啊哈，那對我來說，對，我知道目的地地址（就是你，瀏覽器），然后服務器將網頁打包成一個打包的分層信封並發回（通常是反向路線，但並非總是案件）。

您的瀏覽器不會收到打包的信封並解壓縮每個信封。 然后，您的計算機會對數據進行解擾，您的瀏覽器會在屏幕上顯示這些頁面。

我希望這個答案足以讓你理解。

Answer 5

這是來自瀏覽器 - 服務器通信

Answer 6

這取決於Web服務器，但如果你想知道它從客戶端看起來是什么樣的，只需為firefox安裝Live Headers和Firebug 。 隨着firebug中的網絡標簽和實時標題打開，應該清楚兩者如何相互作用。

要更深入地查看來回的實際數據，請使用wireshark 。

Answer 7

有一個帶有趣徽標的商業產品，可以讓您查看名為charles的服務器和客戶端之間的所有流量。

另一個開源工具包括： Live HttpHeaders ， Wireshark或Firebug 。

Answer 8

瀏覽器和網絡服務器之間的通信發生在很多層面，幾乎無法回答這個問題。 HTTP發揮作用，但沒有TCP，HTTP就沒有意義，沒有IP就毫無意義，沒有它發送的物理網絡就毫無意義。 然后，有POST和GET請求相似但足夠不同以保證特殊的討論。 有時，HTTP請求需要進行身份驗證，有時需要進行身份驗證。 應該提到啞劇類型。 然后，如果有代理，瀏覽器會發送不同的請求。 然后編碼也起作用。 所以，我想，對這類問題最簡潔的答案是：瀏覽器向服務器詢問數據，服務器將所請求的數據提供給瀏覽器。