瞭解通過互聯網流量的TCP/IP分層？

Question

我已經經歷了下面的資源，得到了高層的理解，但是卻無法通過TCP/IP將數據流映射到現實世界中通過互聯網的數據流？

1. TCP/IP layering video
2. HTTP vs TCP/IP, send data to a web server

3. Wiki OSI_model

比方說i型www.google.com並回車，請求和響應如何將流過TCP/IP層

我的超越： -

應用層： -瀏覽器會將請求編碼爲正確格式，以使其在網絡上兼容。同樣，它將解碼瀏覽器的響應 因此瀏覽器是這裏的主角。

傳輸層： -操作系統（OS）將附加本地端口/套接字，以便它可以將響應映射回來。它還將豐富帶有一些標頭的數據並處理基於TCP或UDP等基礎協議的 。同樣，操作系統會將響應映射回正確的端口。可能它也會執行DNS解析並附加IP請求。它還將建立與服務器的連接，以便將更多數據發送到服務器。

像TCP協議（與UDP不同）也可以確保數據包以正確的順序發送並期望從接收方得到確認。如果ack失敗，則重新嘗試。如此可靠。所以，OS是這裏的主角。

網絡層： - ISP將進一步將數據轉發到互聯網骨幹網（IB）。 IB將決定什麼是最短路徑和其他一些可能的東西。 同樣用於響應。 因此ISP和IB是這裏的兩個主要角色。

數據鏈路層： -該層將請求映射到正確的計算機，即MAC地址。所以我認爲它將駐留在互聯網服務提供商的某個地方。其實 我不確定這個層的角色和誰是主角？

物理層： -該層處理物理數據，如電磁波。像光纖//光纜可以成爲這裏的主角。雖然這被描述爲TCP/IP分層上的最後一層 ，但我認爲它是從傳輸層開始的角色。

我的鋪墊是否正確。如果不是，有人可以糾正它明智點？

Answer 1

我會給出一個（基本的？）解釋，省略一些細節。

應用層

在你的例子中的應用層包括：在瀏覽器和服務的web服務器www.google.com，DNS系統和協議和HTTP協議。

每個網絡應用程序編程爲使用特定的傳輸層和網絡層，這意味着你的瀏覽器應用程序和Web服務器的設計和編碼爲使用TCP/IP。應用程序使用通過操作系統（OS）提供的TCP/IP和API。大多數（即使不是全部）情況下的這個API就是所謂的Berkeley Sockets API（從現在起sockets API）。有了這個API的Web服務器可以指示OS偵聽特定端口（80 HTTP或443 HTTPS）客戶端的連接，並建立了新的連接時，操作系統將「通行證」，它給Web服務器應用程序。使用這個相同的API瀏覽器建立到Internet上的遠程Web服務器的新連接併發送和接收數據。

當你輸入www.google.com，瀏覽器需要做的第一件事就是尋找www.google.com的IP地址，因爲在互聯網上不使用主機名通信。這是使用Domain Name System或DNS執行的。省略詳細信息，瀏覽器使用套接字API將使用UDP的DNS查詢發送到配置的DNS服務器IP地址和端口53，以獲取www.google.com的IP地址。 DNS服務器也會使用UDP將回復發送回瀏覽器。

一旦瀏覽器獲得www.google.com的IP地址，它會如果使用HTTPS建立使用套接字API之前獲得的IP地址和端口443新的TCP連接。一旦建立連接，瀏覽器將通過該連接發送HTTP請求到Web服務器，以獲得類似網頁，圖片，音頻等與web服務器資源將發來回覆到使用相同的連接瀏覽器。 HTTP是瀏覽器和Web服務器之間使用的應用程序級協議。

從視聯網點，應用層責任是：

• 翻譯主機名到使用DNS的應用層協議在UDP上使用套接字API IP地址。
• 使用套接字API爲從www.google.com端口443獲得的IP地址建立TCP連接。
• 通過此連接使用HTTP應用程序發送請求並接收響應（通過套接字發送和接收數據）層協議。再次，HTTP是瀏覽器和Web服務器之間用來請求資源（網頁，圖像等）並接收響應的協議。

應用層構建應用層協議消息或數據，並通過套接字API與傳輸層交互。使用此API，應用程序指示TCP建立與遠程主機和端口的新連接，並且還向連接另一端的應用程序發送數據或從連接另一端的應用程序接收數據。

傳輸層

在你的實施例中的傳輸層包括UDP，並在源與目的地主機上運行的，但不包括中間宿主TCP協議。

傳輸層用於在兩個之間發送數據（在廣播的情況下或以上，但在這裏不適用）在互聯網中的一些特殊主機上​​運行的具體應用。傳輸層也有其他責任，你提到：在TCP的情況下，連接建立和拆除，錯誤檢測和重傳，有序傳送，流量控制和擁塞控制等.TCP報頭中的一些字段是用於這些目的。

TCP和UDP將應用程序數據（在這種情況下，將DNS或HTTP請求和響應）封裝到包括具有包括源端口號和目的端口號的字段的報頭中，並將它們傳遞到IP層以傳遞目的IP地址。

網絡層

在您的示例網絡層包括，除了其他東西，IP協議在源和目的地主機上運行的，而且在沿途到最終每一跳的IP協議層運行目的地。這些中間跳是用於連接互聯網內不同網絡的路由器。

IP協議是用於在Internet內兩臺特定主機之間發送數據包的無連接，盡力而爲型傳送（不重傳，無錯誤更正，無重複檢測）協議。

網絡層與傳輸層有不同的責任，其主要目的是在互聯網絡中的主機間通過路由器在不同的鏈路層技術之間路由數據包，並由不同的組織管理。網絡層隱藏較低級別的網絡細節，並在主機與傳輸層之間提供分組傳送服務。

本例中的網絡層數據包（IP數據報）包含一個包含源IP地址和目的IP地址的報頭，用於將數據包路由到Internet內的正確主機。該層的部分是路由器，專用網絡設備互連的不同物理網絡和使用目的地址在它們之間路由分組和路由表內置動態使用路由交換協議，如OSPF和BGP

IP封裝TCP段成IP數據報包括包含協議= TCP（該字段被目標IP層用來將數據報的內容傳遞給TCP或UDP），源IP地址和目的IP地址等字段的頭部，並將它們傳遞給鏈路層以傳遞給沿着到目的地的路徑的下一跳。

鏈路層

在你的榜樣，鏈路層可以包括多個協議。在您的本地網絡（可能是WI-FI（IEEE 802.11）和/或以太網（IEEE 802.3））中，還包括您的家庭和ISP之間使用的鏈路層協議，位於ISP的不同網絡內以及廣域網用於到達目標ISP或公司，最終到達目標主機。您可能還使用的一些鏈路層協議是：PPP和Frame Relay。

鏈路層只在主機連接的本地網段（鏈路）上運行，鏈路層數據包不會路由到其他網絡。該層的責任是使用連接到同一網絡的兩臺主機之間的物理層傳輸數據。 該層是實際在兩臺不同機器之間傳輸比特的唯一層。

鏈路層將IP數據報封裝成幀，包括一個包含EtherType = IP（這個字段被目標鏈路層用來將幀內容傳送到適當的網絡層的字段）的字段的幀，源鏈路層地址和目的地鏈路層地址（例如MAC地址）。

物理層

在你的榜樣物理層可以包括多個協議。在您的本地網絡中，可能是某些Ethernet physical layers，但還包括在您的家庭和您的ISP之間使用的物理層協議，如DSL，位於您的ISP的不同網絡內以及用於到達目標ISP或公司的廣域網內，目的地主機。在廣域網中，最常用的物理層是SDH or SONET

使用不同的digital modulation methods將物理層變換成電信號或光脈衝，並通過物理介質（銅線，微波或光纖）傳輸這些信號。物理層包括連接器，電線，設備，天線，中繼器等所需的各種硬件，以構建網絡。

一個具體的例子

讓我們假設，谷歌的Web服務器的IP地址爲10.0.0.1 =和您的主機的IP地址爲20.0.0.1 =。另外假定Google的一些網絡管理員使用www.google.com的條目將映射到10.0.0.1的DNS服務器設置爲。同時假定您的主機配置爲使用IP = 30.0.0.1的DNS服務器。

Google Web服務器使用套接字API偵聽IP 10.0.0.1和端口443上來自客戶端（瀏覽器）的連接。Web服務器主機操作系統會將每個新的TCP連接轉發到Web服務器應用程序的10.0.0.1:443。

您在IP地址爲20.0.0.1的主機上的瀏覽器中鍵入www.google.com。

使用套接字API的瀏覽器將使用UDP向目標IP = 30.0.0.1和目標端口= 53發送DNS查詢。偵聽該主機和端口的DNS服務器將接收該查詢並將其轉發給某些其他DNS服務器，直到谷歌DNS服務器（域名google.com的權威）被聯繫，並回應DNS迴應，告知www.google.com在10.0.0.1。請參閱下面的詳細信息以瞭解如何使用UDP將這些查詢傳遞到DNS服務器應用程序，並將響應發送迴應用程序，與UDP的詳細級別的唯一區別在於在發送數據之前沒有建立連接。

您的瀏覽器再次使用套接字API將建立到目標IP = 10.0.0.1和目標端口= 443的TCP連接。您的操作系統將爲此連接分配一個隨機本地端口，可以說端口= 10000.現在我們有一個由本地和目標端點標識的TCP連接，這是我們的例子（20.0.0.1:10000,10.0.0.1:443）。

在獲取www.google.com的IP地址後，瀏覽器再次使用套接字API將發送請求index.html的HTTP請求以及屬於該頁面的所有資源。套接字API將把應用程序數據發送到TCP層。

在您的主機上運行的TCP層將封裝應用程序數據到本地端口= 10000和目標端口= 443的段中，並要求IP層將這些段發送到目標IP = 10.0.0.1。

在主機上運行的IP層將使用本地路由表和目標IP地址找到這些數據報的下一跳。下一跳將成爲您的主機中配置的默認網關。

在您的主機上運行的IP層將使用名爲ARP的協議找到下一跳（默認網關）的MAC地址。該協議用於爲位於同一本地網絡中的給定目標IP地址查找MAC地址。

IP層將封裝TCP片段與協議= TCP，源IP = 20.0.0.1和目的IP = 10.0.0.1的IP數據報，並且將詢問鏈路層到這些IP數據報發送到下一跳。

下一跳IP地址映射到您的機器上安裝的網絡接口。因此，鏈路層會將IP數據報封裝成EtherType = IP，源MAC =（映射本地網絡接口的MAC地址）和目的MAC =（使用ARP獲得的默認網關的MAC地址）的幀，並通過正確的網絡接口發送。

默認網關（路由器）和沿途的所有其它路由器將重複這一過程：

• 鏈路層將接收註定的一些本地網絡接口的MAC地址的幀。
• 鏈路層將檢查幀字段EtherType，因爲值是IP將數據報傳遞到IP層。
• IP層將檢查目標IP地址，並且由於目標IP地址不是任何本地IP地址，所以它將使用本地路由表等找到此數據報的下一跳，直到最終目標主機。

終宿主（運行谷歌的Web服務器）會做同樣的步驟，但由於現在的目標IP地址匹配該主機的本地IP地址之一，IP層將檢查IP數據報的協議字段和因爲它將TCP傳遞給TCP層。 TCP層將檢查TCP段中的目標端口（本例中爲443），並將應用層數據通過套接字API傳遞到偵聽端口443（本例中爲Google Web服務器）的應用程序。請記住，此套接字綁定到特定的遠程IP和端口（20.0.0.1:10000），所以當Web服務器通過此套接字發回響應時，該過程將重複，但現在使用源IP = 10.0.0.1，源端口= 443，目的地IP = 20.0.0.1，目的地端口= 10000.