tcp

從開始到結束，當你在瀏覽器中輸入URL時會發生什麼事情 HTTP協議 我僅分析URL請求 與macOS / Linux相關的事情 DNS查找階段 gethostbyname TCP請求握手 發送請求 請求行 請求標頭 請求主體 響應 解析HTML 本文描述了瀏覽器如何使用HTTP/1.1協議進行頁面請求 如果你曾經參加過面試，可能會被問到：“當你在Google搜索框中輸入內容並按下Enter鍵時會發生什麼”. 這是一個最常問的問題之一。人們只是想看看你是否能解釋一些相當基本的概念，以及你是否對互聯網的工作原理有任何了解。 在這篇文章中，我將分析當你在瀏覽器的地址欄中輸入URL並按下Enter鍵時會發生什麼。 這是一個非常有趣的主題，我可以在單獨的文章中深入探討其中的許多技術。 這項技術很少更改，並且為人類所建造的最複雜和最廣泛的生態系統之一提供動力。 HTTP協議 首先，我特別提到HTTPS，因為使用HTTPS連接的情況有所不同。 我僅分析URL請求 現代瀏覽器具有知道你在地址欄中輸入的是實際URL還是搜索詞的能力，如果不是有效的URL，它們將使用默認搜索引擎。 我假設你輸入的是實際URL。 當你輸入URL並按下Enter鍵時，瀏覽器首先構建完整的URL。 如果你只輸入了一個域名，例如flaviocopes.com，瀏覽器默認會在前面添加 HTTP://，使用預設的HTTP協議。 與macOS / Linux相關的事情 只是提一下。Windows可能會略有不同。 DNS查找階段 瀏覽器開始進行DNS查找以獲取服務器的IP地址。 域名對於我們人類來說很方便，但互聯網根據IP地址對服務器的精確位置進行組織，IP地址是一組類似 222.324.3.1（IPv4）的數字。 首先，它檢查DNS本地緩存，看看域名最近是否已被解析。 Chrome有一個方便的DNS緩存可視化工具，你可以在chrome://net-internals/#dns查看。 如果在那裡找不到任何內容，瀏覽器將使用DNS解析器，使用gethostbyname POSIX系統調用檢索主機信息。 gethostbyname gethostbyname首先在本地主機文件中查找，該文件在macOS或Linux中位於/etc/hosts，以查看系統是否在本地提供該信息。 如果這沒有提供有關該域的任何信息，系統將向DNS服務器發送請求。 DNS服務器的地址存儲在系統首選項中。 下面是兩個常用的DNS服務器： 8.8.8.8：Google公共DNS服務器 1.1.1.1：CloudFlare DNS服務器 大多數人使用由其網絡提供商提供的DNS服務器。 瀏覽器使用UDP協議執行DNS請求。 TCP和UDP是計算機網絡的兩個基礎協議。它們處於相同的概念層級，但TCP是面向連接的協議，而UDP是無連接的協議，更加輕量級，用於以較小開銷發送消息。 如何進行UDP請求不在本教程的範圍內 DNS服務器可能在緩存中有域的IP。如果沒有，它將向樹狀DNS服務器發送請求。這是一個由13台實際服務器（分佈在全球各地）組成的系統，該系統驅動整個互聯網。 DNS服務器不知道地球上每個域名的地址。它只知道頂級DNS解析器的位置。頂級域是域名的擴展名：.com，.it，.pizza等。 一旦根DNS服務器收到請求，它會將請求轉發給頂級域（TLD）DNS服務器。假設你正在尋找flaviocopes.com，根域DNS服務器會返回.com TLD服務器的IP。 現在我們的DNS解析器將緩存該TLD服務器的IP，所以它不需要再次向根DNS服務器請求。 TLD DNS服務器將具有我們正在查找的域的權威名稱服務器的IP地址。 如何做到的？當你購買一個域名時，域名註冊商會向相應的TDL發送名稱服務器。當你更新名稱服務器（例如，當你更換主機提供商時），你的域名註冊商將自動更新此信息。 這些是主機提供商的DNS服務器。通常有不止1個，以作為備份。 例如： ns1.dreamhost.com ns2.dreamhost.com ns3.dreamhost.com DNS解析器從第一個開始，並嘗試查詢你正在查找的域名（包括子域名）的IP。 這是IP地址的終極真相來源。 現在我們有了IP地址，可以繼續我們的旅程。 TCP請求握手 有了服務器的IP地址後，瀏覽器現在可以與服務器建立TCP連接。...

對傳輸控制協定（TCP）的高層次概述 TCP 代表傳輸控制協定，它是 Web 和其他應用程序（如郵件）的基礎。 TCP 在 1981 年的 RFC 793 中被定義，是互聯網最古老的支柱之一。 TCP 位於網際網路協定（IP）之上，建立了一個基礎系統，供應用層協定如 HTTP、FTP、IMAP 等使用。 與 IP 和 UDP 相反，TCP 是面向連接的。 在 TCP 上傳輸之前，必須建立連接。數據以小包的形式發送，並在通信結束時關閉連接。 在使用 TCP 傳輸數據時，有一個相對複雜的流程稱為握手必須發生。 我不會在這裡詳細介紹，但這個握手允許端對端的連接，並確保 TCP 提供其獨特的功能之一：可靠性。使用 TCP，我們始終可以知道發送者發送的封包是否被接收者正確接收。 如果封包丟失，協議能夠處理它並重新發送封包。 在 IP 協議中，連接由電腦到電腦進行。在 TCP 中，連接是從進程到進程的，使用了埠的概念。 與 IP 位址相關聯的埠用於唯一標識計算機上的進程，例如： localhost:8080 或 google.com:1234 每個應用層協定都有一個默認的埠。例如，HTTP 的默認埠是 80，HTTPS 的默認埠是 443，FTP 的默認埠是 21。這就是為什麼您通常不需要在瀏覽器中指定埠。 程序不需要使用默認值，這就是為什麼在本地計算機上啟動新應用程序時，您可能會看到類似 1313 或 8080 的埠。 埠號範圍從 1 到 65535（埠號是一個 16 位無符號數，對應於 2^16 個可能值）。

對User Datagram Protocol（UDP）的高層次概述 UDP（User Datagram Protocol）是一種傳輸協議，是TCP的一個替代方案。 它與TCP的主要區別是它是無連接的。 這意味著它更快，每個發送的數據包更輕量級，因為它不包含TCP中所需的所有信息，並且它具有更輕量級的握手過程。 缺點是UDP不像TCP那樣可靠。 在TCP中，如果一個數據包丟失，協議能夠處理它並重新發送該數據包。 在UDP中，這並未內建於協議中，必須在較高層級（在其上構建的協議）進行處理。沒有內建的檢查來控制是否接收到數據包以及是否正確接收到數據包。 UDP在1980年的RFC 768中被定義。 一些最著名依賴UDP層的應用協議包括DNS和DHCP，更重要的是HTTP的下一個版本：HTTP/3的基礎層。 UDP協議使用端口允許進程之間進行通信，就像TCP一樣。