有沒有想過點擊連結時會發生什麼事？ ？ 《互聯網如何運作》將帶您深入數位世界的幕後，將複雜的技術分解為簡單的見解。從資料包到伺服器等，探索為您的線上體驗提供動力的魔力！ （在 AI 的幫助下寫的 Hook，因為我不會：D）
讓我解釋一下實體鍵盤操作和作業系統中斷。當您按下“g”鍵時，瀏覽器會註冊該事件，觸發自動完成功能。根據您的瀏覽器演算法以及您處於常規模式還是私人/隱身模式，URL 欄下方的下拉式選單中會顯示各種建議。
這些建議通常會根據您的搜尋記錄、書籤、cookie 和流行的網路搜尋等因素進行優先排序和排序。當您繼續輸入“google.com”時，許多進程會在背景運行，並建議會隨著每次按鍵而完善。在您完成輸入之前，瀏覽器甚至可能會預測「google.com」。
瀏覽自動完成序列
「輸入」鍵觸底
為了建立一個起點，讓我們考慮鍵盤上的 Enter 鍵到達其行程範圍的底部時的情況。此時，專用於 Enter 鍵的電路閉合（機械地或電容式地），允許小電流流入鍵盤的邏輯電路。此電路掃描每個按鍵開關的狀態，濾除開關快速閉合（去抖）產生的電噪聲，並將操作轉換為鍵碼（在本例中為整數 13）。然後鍵盤控制器對該鍵碼進行編碼以進行傳輸到電腦。如今，這幾乎總是透過通用序列匯流排 (USB) 或藍牙連接完成，儘管舊系統使用 PS/2 或 ADB。
如果是 USB 鍵盤：
序列圖如果是虛擬鍵盤（例如在觸控螢幕裝置上）：
描述相同內容的序列圖對於非 USB 鍵盤，例如使用傳統連接（例如 PS/2）的鍵盤，鍵盤透過其中斷請求線 (IRQ) 發出中斷訊號。此 IRQ 由系統的中斷控制器對應到中斷向量（整數）。 CPU 查閱中斷描述符表 (IDT)，該表將每個中斷向量連結到由作業系統核心提供的對應函數（稱為中斷處理程序）。
當中斷被觸發時，CPU使用中斷向量索引到IDT並執行適當的中斷處理程序。此過程會導致 CPU 轉換到核心模式，從而允許作業系統管理按鍵事件。
按下 Enter 鍵時，人機介面裝置 (HID) 傳輸會將按鍵按下事件傳遞給 KBDHID.sys 驅動程序，該驅動程式將 HID 使用資料轉換為掃描碼。本例中，掃描碼為VK_RETURN（0x0D），代表回車鍵。然後，KBDHID.sys 驅動程式與 KBDCLASS.sys 驅動程式（鍵盤類別驅動程式）進行通信，後者安全地管理所有鍵盤輸入。在繼續之前，訊號可能會通過系統上安裝的任何第三方鍵盤過濾器，儘管這也會發生在內核模式下。
接下來，Win32K.sys 發揮作用，透過呼叫 GetForegroundWindow() API 來確定目前處於活動狀態的視窗。此函數會擷取活動應用程式的視窗句柄（hWnd），例如瀏覽器的網址列。此時，Windows「訊息泵」呼叫SendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam)。 lParam 參數包含一個位元掩碼，提供有關按鍵的附加信息，包括：
SendMessage API 對特定視窗句柄的訊息進行排隊。隨後，指派給視窗（hWnd）的系統主訊息處理函數（稱為WindowProc）會擷取並處理佇列中的消息。
本例中的活動視窗是一個編輯控件，它的 WindowProc 函數有一個回應 WM_KEYDOWN 事件的訊息處理程序。處理程序檢查SendMessage 傳遞的第三個參數（wParam），識別出該值為VK_RETURN，從而確定使用者按下了Enter 鍵。這會觸發應用程式的適當回應。
當在 OS X 上按下某個鍵時，中斷訊號會觸發 I/O Kit 鍵盤驅動程式（核心擴充或「kext」）中的事件。此驅動程式將硬體訊號轉換為按鍵代碼。然後關鍵程式碼被傳遞到WindowServer，它管理圖形使用者介面。
WindowServer 透過 Mach 連接埠 發送按鍵事件到適當的應用程式（例如活動或偵聽的應用程式），並在其中將其放入事件中佇列。具有適當權限的應用程式可以透過呼叫 mach_ipc_dispatch 函數來存取此事件佇列。
大多數應用程式透過 NSApplication 主事件循環來處理此過程，該循環負責處理使用者輸入。當事件是按鍵時，它表示為 NSEventTypeKeyDown 類型的 NSEvent。然後，應用程式讀取此事件並做出相應回應，根據收到的按鍵代碼觸發與按鍵操作相關的任何代碼。
當使用 X 伺服器在圖形環境中按下按鍵時，X 伺服器會使用 evdev（事件裝置）驅動程式來擷取按鍵事件。然後，使用 X 伺服器特定的鍵盤映射和規則將實體鍵盤中的鍵碼重新映射到 掃描碼。
映射完成後，X 伺服器將產生的 掃描碼轉送到視窗管理器（例如 DWM、Metacity、i3 等）。視窗管理器又將字元或按鍵事件傳送到目前對焦的視窗。聚焦視窗的圖形 API 處理此事件，並根據按下的鍵使用正確的字體在適當的欄位中顯示相應的符號。
此流程確保角色在活動應用程式的介面中正確呈現，完成從硬體到圖形輸出的按鍵互動。
當瀏覽器解析URL（統一資源定位器）時，它會提取以下元件：
每個元件都幫助瀏覽器解釋並從網路取得所需的資源。
當未提供協議（例如「http」）或有效網域名稱時，瀏覽器會將網址列中的文字解釋為潛在的搜尋字詞。瀏覽器不會嘗試將其解析為 URL，而是將文字轉發到其預設的網路搜尋引擎。
在大多數情況下，瀏覽器會在搜尋查詢後附加一個特殊標識符，表示該請求源自瀏覽器的 URL 欄。這使得搜尋引擎能夠相應地處理這些搜尋並確定其優先級，從而根據上下文提高結果的相關性。
此流程可協助瀏覽器決定是否應該嘗試直接導航至網站或根據輸入的文字提供搜尋結果。
瀏覽器首先檢查其預先載入的HSTS（HTTP 嚴格傳輸安全）列表，其中包含明確請求僅透過HTTPS存取的網站。
如果在此清單中找到要求的網站，瀏覽器會自動使用 HTTPS 而不是 HTTP 發送請求。如果網站不在 HSTS 清單中，則初始請求將透過 HTTP.
發送要注意的是，網站仍然可以實作 HSTS，而不包含在預先載入清單中。在這種情況下，使用者發出的第一個 HTTP 請求將傳回一個回應，指示瀏覽器僅透過 HTTPS 發送後續請求。但是，此初始 HTTP 請求可能會使使用者遭受降級攻擊，攻擊者可能會攔截該請求並強制其保持未加密狀態。此漏洞就是為什麼現代 Web 瀏覽器包含 HSTS 清單的原因，透過首先防止建立不安全的連線來增強使用者的安全性。
瀏覽器透過檢查網域是否已存在於其快取中來開始 DNS 查找過程。 （要查看 Google Chrome 中的 DNS 緩存，請導航至 chrome://net-internals/#dns。）
如果快取中沒有找到域名，則瀏覽器呼叫gethostbyname庫函數（具體函數可能因作業系統不同而不同）進行主機名稱解析。
本地主機檔案檢查：
DNS 伺服器請求：
DNS 伺服器的 ARP 流程：
這種系統方法可確保瀏覽器有效地將網域名稱解析為 IP 位址，從而能夠建立與所需網站的連線。透過先檢查緩存，使用本地主機文件，最後查詢 DNS 伺服器，瀏覽器最大限度地減少了主機名稱解析所花費的時間。
序列圖
為了發送 ARP（位址解析協定）廣播，網路堆疊庫需要兩個關鍵資訊：需要尋找的目標 IP 位址和將用於發送的介面的 MAC 位址發出 ARP 廣播。
先檢查 ARP 快取中是否有與目標 IP 位址對應的條目。如果條目存在，則函式庫函數以下列格式傳回結果：
目標 IP = MAC.
如果該條目不在 ARP 快取中：
如果沒有目標IP位址的條目，則執行以下步驟：
網路庫建構並傳送第 2 層（OSI 模型的資料鏈結層）ARP 請求，格式如下： ARP 請求：
根據電腦和路由器之間的硬體設置，ARP 要求的行為會有所不同：
如果電腦直接連接到路由器，路由器將回應 ARP 回應（請參閱下文）。
如果電腦連接到集線器，集線器將從其所有其他連接埠廣播 ARP 請求。如果路由器連接到同一條“線路”，它將用 ARP 回復進行回應（見下文）。
如果電腦連接到交換機，交換器將檢查其本機 CAM/MAC 表以識別哪個連接埠有正在查詢的 MAC 位址。如果交換器沒有該 MAC 位址的條目，它將向所有其他連接埠重新廣播 ARP 請求。如果交換器的 MAC/CAM 表中有條目，它將僅向具有相應 MAC 位址的連接埠發送 ARP 請求。
ARP 回覆將採用以下格式：
寄件者 MAC: 目標:mac:位址:此處
寄件者 IP: target.ip.goes.here
目標 MAC: 介面:mac:位址:此處
目標IP：interface.ip.goes.here
現在網路庫已經取得了 DNS 伺服器或預設閘道的 IP 位址，它可以恢復其 DNS 流程：
瀏覽器收到目標伺服器的 IP 位址後，會將其與 URL 中指定的連接埠號碼結合（其中 HTTP 預設為連接埠 80，HTTPS 預設為連接埠 443）。然後瀏覽器呼叫名為socket的系統函式庫函數，使用AF_INET或AF_INET6和SOCK_STREAM請求TCP套接字流。
此時，資料包已準備好透過以下方法之一傳輸：
對於大多數家庭或小型企業互聯網連接，資料包將從您的電腦傳遞，可能透過本地網絡，然後透過數據機（調製器/解調器）。此數據機將數位 1 和 0 轉換為適合透過電話、電纜或無線電話連接傳輸的類比訊號。在連接的另一端，另一個調製解調器將類比訊號轉換回數位數據，以供下一個網路節點處理，其中將進一步分析起始位址和目標位址。
相較之下，較大的企業和一些較新的住宅連接將使用光纖或直接乙太網路連接，從而使資料保持數位化並直接傳遞到下一個網路節點進行處理。
最終，封包將到達管理本地子網路的路由器。從那裡，它將繼續前往自治系統 (AS) 的邊界路由器，遍歷其他 AS，最後到達目標伺服器。沿途的每個路由器從 IP 標頭中提取目標位址，並將其路由到適當的下一跳。對於每個處理它的路由器，IP 標頭中的生存時間 (TTL) 欄位會減一。如果 TTL 欄位達到零或目前路由器佇列中沒有空間（這可能是由於網路擁塞而發生），則封包將被丟棄。
此傳送和接收程序依照 TCP 連線流程發生多次：
將（客戶端 ISN 1）複製到其 ACK 欄位並新增 ACK 標誌以指示它正在確認收到第一個資料包。
客戶端透過傳送以下資料包來確認連線：
資料傳輸：資料傳輸如下：
關閉連線：關閉連線：
開啟套接字：序列圖
此握手程序在客戶端和伺服器之間建立安全連接，確保透過連接傳輸的資料不會被竊聽和篡改。
有時，由於網路擁塞或不穩定的硬體連接，TLS 封包可能會在到達最終目的地之前被丟棄。在這種情況下，發送者必須決定如何反應。管理此回應的演算法稱為 TCP 擁塞控制。具體實作可能因發送者而異，最常見的演算法是較新作業系統上的 Cubic 和許多其他作業系統上的 New Reno。
這種擁塞控制機制有助於優化網路效能和穩定性，確保資料能夠高效傳輸，同時最大限度地減少丟包的影響。
如果使用的網頁瀏覽器是由 Google 開發的，它可能會嘗試與伺服器協商從 HTTP 到 SPDY 協定的“升級”，而不是發送標準 HTTP 請求來檢索頁面。
如果客戶端使用的是HTTP協定且不支援SPDY，則會依照下列格式向伺服器傳送請求：
GET / HTTP/1.1 Host: google.com Connection: close [other headers]
這裡，[其他標頭]指的是一系列以冒號分隔的鍵值對，這些鍵值對按照 HTTP 規範格式化，並以單一換行符分隔。這假設 Web 瀏覽器不存在違反 HTTP 規範的錯誤，而且它正在使用 HTTP/1.1。如果它使用不同的版本，例如 HTTP/1.0 或 HTTP/0.9，它可能不會在請求中包含 Host 標頭。
HTTP/1.1 為發送方定義了「關閉」連線選項，以表示回應完成後將關閉連線。例如：
Connection: close
不支援持久連線的 HTTP/1.1 應用程式必須在每個訊息中包含「關閉」連線選項。
發送請求和標頭後，Web 瀏覽器會向伺服器發送空白換行符，表示請求內容已完成。
伺服器隨後使用表示請求狀態的回應代碼進行回應，其結構如下：
200 OK [response headers]
後面跟著一個換行符，然後是包含 www.google.com 的 HTML 內容的有效負載。伺服器可以關閉連接，或者，如果客戶端發送的標頭請求，則保持連接開啟以便在進一步的請求中重複使用。
If the HTTP headers sent by the web browser contained sufficient information for the web server to determine whether the version of the file cached by the web browser has been unmodified since the last retrieval (for example, if the web browser included an ETagheader), the server may instead respond with:
304 Not Modified [response headers]
This response will have no payload, and the web browser will retrieve the HTML from its cache.
After parsing the HTML, the web browser (and server) repeats this process for every resource (image, CSS, favicon.ico, etc.) referenced in the HTML page. In these cases, instead of GET / HTTP/1.1, the request will be structured as:
GET /$(URL relative to www.google.com) HTTP/1.1
If the HTML references a resource on a different domain than www.google.com, the web browser returns to the steps involved in resolving the other domain, following all steps up to this point for that domain. The Host header in the request will be set to the appropriate server name instead of google.com.
The HTTPD (HTTP Daemon) server is responsible for handling requests and responses on the server side. The most common HTTPD servers include Apache and Nginx for Linux, as well as IIS for Windows.
By following these steps, the HTTPD server efficiently processes incoming requests and returns the appropriate responses to the client.
The primary functionality of a browser is to present the web resources you choose by requesting them from a server and displaying them in the browser window. The resource is typically an HTML document but may also include PDFs, images, or other types of content. The location of the resource is specified by the user using a URI (Uniform Resource Identifier).
The way a browser interprets and displays HTML files is defined by the HTML and CSS specifications, which are maintained by the W3C (World Wide Web Consortium), the standards organization for the web.
Browser user interfaces share many common features, including:
The components of a browser can be broken down as follows:
每個元件協同工作以創建無縫的瀏覽體驗，使用戶能夠有效地存取網路資源並與之互動。
渲染引擎開始從網路層檢索所請求文件的內容，通常以 8 kB 區塊的形式檢索。 HTML 解析器的主要職責是將 HTML 標記轉換為稱為解析樹的結構化表示。
輸出樹，稱為“解析樹”，由 DOM（文檔物件模型）元素和屬性節點的層次結構組成。 DOM 用作 HTML 文件的物件表示，為 HTML 元素提供與外部腳本（例如 JavaScript）互動的介面。這棵樹的根是「Document」對象，在任何腳本操作之前，DOM 與原始標記保持幾乎一一對應。
由於多種因素，使用傳統的自上而下或自下而上的解析器無法有效地解析 HTML：
解析完成後，瀏覽器將繼續取得連結到頁面的外部資源，例如 CSS 樣式表、圖片和 JavaScript 檔案。此時，瀏覽器將文件標記為互動式，並開始解析處於「延遲」模式的腳本，這表示這些腳本將在文件完全解析後執行。然後文檔狀態設定為“完成”，並觸發“載入”事件。
重要的是，瀏覽器不會為 HTML 頁面產生「無效語法」錯誤。相反，它們會自動更正任何無效內容並繼續處理文檔，確保使用者可以在最小幹擾的情況下查看網頁。
CSS解釋的過程涉及幾個關鍵步驟：
透過這種解釋，瀏覽器可以全面了解如何將樣式應用於 DOM 中的 HTML 元素，從而促進網頁呈現出預期的視覺呈現效果。
網頁的渲染過程涉及幾個結構化步驟：
該影像也是由 GPU 渲染的
渲染過程完成後，瀏覽器執行由各種事件觸發的 JavaScript 程式碼，例如計時機制（如 Google Doodle 動畫）或使用者互動（例如，在搜尋框中輸入查詢並接收建議）。
以上是互聯網如何運作？第 1 部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！
