【復習】計算機網絡

網絡模型

OSI

應用層：給應用程序提供統一的接口
表示層：把數據轉換成兼容另一個系統能識別的格式
會話層：負責建立、管理、終止表示層實體之間的通信會話
傳輸層：負責端到端的數據傳輸
網絡層：負責數據的路由、轉發、分片
數據鏈路層：負責數據的封幀和差錯檢測，以及MAC尋址
物理層：負責在物理網絡中傳輸數據幀

TCP/IP模型

應用層：支持HTTP、SMTP等最終用戶進程
傳輸層：處理主機到主機之間的通信
網絡層：尋址和路由數據包
鏈路層：通過網絡的物理電線或無線信道移動比特

TCP在傳輸層；IP在網絡層

應用層

應用層的協議？

HTTP、HTTPS、CDN、DNS、FTP

HTTP報文有哪幾部分？

請求報文：

請求行：請求方法、目標、HTTP版本
請求頭：請求的附加信息（Host、User-Agent…）
空行：請求頭和請求體之間用空行空格
請求體：請求的數據，用于POST請求需要傳輸數據的情況

響應報文：

狀態行：HTTP協議、狀態碼、狀態信息
響應頭：響應的附加信息（Content-Type、Content-Length…）
空行：響應頭和響應體之間用空行空格
響應體：包含響應的數據（服務器返回的HTML、JSON…）

HTTP常用狀態碼

1xx：提示信息，協議處理的中間狀態，還需要后續操作（少用）
2xx：成功，報文已收到并被正確處理（200、204、206）
3xx：資源重定向，資源位置發生變動，需要客戶端重新用新的URL發請求（301、302、304）
- 301 - 永久重定向，說明請求的資源已經不存在了，需要改用新的URL再次訪問
- 302 - 臨時重定向，說明請求的資源還在但是暫時需要用另一個URL訪問
301 和 302都會在響應頭指明后續要跳轉的URL
4xx：客戶端錯誤，請求報文有誤，服務器無法處理（400、403、404、405）
- 404 - 無法找到此頁面
- 405 - 請求的方法類型不支持
5xx：服務器錯誤（500、501、502、503）
- 502 - 服務器執行請求時，從上游服務器接收到無效的響應
- 504 - 服務器執行請求時，未能及時從上游服務器收到響應

nginx是代理服務器，收到客戶端請求后，將請求發到后端服務器；

502：nginx收到無效的響應
503：請求超時（超過了nginx的配置時間）

GET和POST的區別

GET：從服務器獲取資源，請求參數寫在URL位置（URL只支持ASCII且瀏覽器對URL的有限制）

POST：根據body對指定的資源做處理，攜帶的數據寫在body里。

GET是安全、冪等的（只讀），可以對GET數據做緩存，可以緩存到瀏覽器上，也可以緩存到nginx上，在瀏覽器中GET請求可以保存為書簽。

POST是不安全、不是冪等的（寫），瀏覽器一般不會緩存POST請求，也不能把POST請求保存為書簽

實際開發中，也會用POST方法實現查詢數據的請求

HTTP長連接

HTTP協議是“請求-響應”模式，先建立TCP連接，客戶端發起了HTTP請求，服務器收到后就返回響應，然后釋放TCP連接。

HTTP短連接：一次連接只能請求一次資源

HTTP長連接（Keep-Alive）：使用同一個TCP連接來發送和接收多個HTTP請求，避免了連接建立和釋放的開銷。只要任何一段沒有明確提出斷開連接，則保持TCP連接狀態。

HTTP怎么對請求做拆包的？

請求的拆包是通過“Content-Length”頭字段來進行的。該字段指示了請求正文的長度，服務器可以根據該長度來正確接收和解析請求。

客戶端發送HTTP請求，會在請求頭中增加“Content-Length”字段，用來表示請求正文的字節數
瀏覽器根據“Content-Length”字段來確定請求的長度，并從請求中讀取相應數量的字節，直到讀取完整個請求的內容

HTTP為什么不安全？

HTTP是基于明文傳輸的，通信鏈路上可以獲取通信內容；其他用戶可以篡改內容；也可以冒充發送方。

HTTPS是在HTTP和TCP層之間引入了SSL/TLS協議，解決了上述風險。

HTTP 和 HTTPS的區別？

HTTP是超文本傳輸協議，存在安全風險；HTTPS解決了HTTP不安全的缺陷，在TCP和HTTP之間加入了SSL/TLS協議
HTTP建立相對簡單，通過TCP三次握手后就可以進行HTTP的報文傳輸；HTTPS在TCP三次握手后還需要建立SSL/TLS的握手才能進行加密報文傳輸
HTTP默認端口80；HTTPS默認端口443
HTTPS需要向CA申請數字證書，來保證服務器的身份是可用的

TLS的四次握手過程？

第一次握手：客戶端向服務器發起加密通信請求（ClientHello），主要發送以下信息：
- 客戶端支持的TLS協議版本
- 客戶端生成的隨機數（后邊用于生成會話秘鑰）
- 客戶端支持的密碼套件列表（RSA加密算法）
第二次握手：服務器收到客戶端請求后，向客戶端發出響應（ServerHello），主要回應以下信息：
- 確認TLS協議版本
- 服務器生成的隨機數（后邊也是用于生成會話秘鑰）
- 確認的密碼套件列表（RSA加密算法）
- 服務器的數字證書
第三次握手：客戶端收到服務器回應后，通過瀏覽器或操作系統里的CA公鑰，確認服務器的數字證書的真實性。整數如果沒有問題，就會從數字證書里取出服務器的公鑰，用它加密報文，向服務器發送以下信息：
- 一個隨機數（會被服務器公鑰加密）
- 加密通信算法改變通知（告知服務器隨后的信息都會用“會話密鑰”加密通信）
- 客戶端握手結束通知（表示客戶端的握手已經結束）
通過這三個隨機數，接著用雙方協商的加密算法，各自生成本次通信的“會話密鑰”
第四次握手：服務器通過協商的加密算法，計算出本次通信的“會話密鑰”，向客戶端回應以下消息：
- 加密通信算法改變通知（告知客戶端隨后的消息都會用“會話密鑰”加密通信）
- 服務器握手結束通知（表明服務器的握手已經結束）

整個TLS的握手全部結束后，服務器與客戶端就會進入加密通信，完全是使用普通的HTTP協議，只不過用“會話密鑰”加密內容

HTTPS如何防范中間人攻擊？

加密：https握手期間會通過非對稱加密方式協商出對稱加密密鑰
身份驗證：客戶端與服務器建立連接后，服務器會將CA證書發送給客戶端，客戶端會去校驗CA整數的合法性。驗證通過后，使用證書中的公鑰來加密數據，并將加密后的數據傳給服務器，服務器用私鑰解密

中間人的攻擊在于冒充服務器與客戶端建立連接，但是中間人拿不到服務器的私鑰，無法正確解密客戶端發過來的數據。同時如果客戶端校驗CA證書后，證書驗證失敗，也會中斷連接。

HTTP1.1 和 HTTP2.0的區別？

頭部壓縮：HTTP2會壓縮頭部，如果發送多個請求，他們的請求頭部是一樣的，協議會幫忙消除重復的部分。

HPACK算法：客戶端和服務器同時維護一張頭部信息表，所有的字段都存入這個表中，并生成一個索引號，以后就不會發送同樣的字段，直接發送索引號即可。

二進制格式：HTTP1.1采用的是純文本形式的報文；HTTP2全面采用了二進制格式。增加了數碼據傳輸的效率
并發傳輸：多個Stream復用在同一條TCP連接上，解決了HTTP1.1隊頭阻塞的問題
服務器主動推送資源：服務器不再是被動的響應，可以主動向客戶端發送消息

HTTP進行TCP連接之后，什么情況下會斷開連接？

客戶端或服務器發送一條FIN報文，就會進行四次揮手
發送方發送了一條數據給服務器，服務器超過一段時間沒有響應ACK報文，發送方重傳達到最大次數時，就會斷開TCP連接
HTTP長時間沒有進行請求和響應。

HTTP、SOCKET和TCP的區別？

HTTP：應用層協議，定義了客戶端和服務器之間交換數據的規則；在客戶端和服務器之間傳輸和顯示web頁面
Socket：用于描述通信鏈路的一端，提供了底層的通信接口，可實現不同計算機之間的數據交換
TCP：傳輸層協議，負責在網絡中建立可靠的數據傳輸連接

DNS是什么？

DNS是用來將域名轉化成IP地址的數據庫系統，端口號53。（越靠右層級越高）

根域名服務器
頂級域名服務器
權威域名服務器

DNS底層是基于UDP協議的，因為UDP可以提供低延遲的特性，更適合DNS這種需要快速響應的域名解析服務。

雖然UDP存在丟包和數據包損壞的風險，但是DNS使用一些機制來提高可靠性（超時重傳、請求重試、緩存…）

DNS域名解析流程？

客戶端發送DNS請求，發送給本地域名服務器
本地域名服務器先去查詢緩存，如果查到，直接返回IP地址；如果沒有查到，就進行迭代查詢
- 本地域名服務器去訪問他的根域名服務器，根域名服務器并不會進行域名解析，而是告訴它頂級域名服務器的IP地址
- 本地域名服務器又去訪問頂級域名服務器，頂級域名服務器也不會進行域名解析，而是告訴它權威域名服務器的IP地址
- 本地域名服務器又去訪問權威域名服務器，權威域名服務器是域名解析結果的原出處，將該域名對應的IP地址告訴本地域名服務器，隨后本地域名服務器將IP地址返回給客戶端，成功建立連接。

HTTP是無狀態的嗎？

HTTP是無狀態的，服務器不會在多個請求中保留客戶端狀態的信息，在每個HTTP請求中，服務器不會記住之前的請求和會話狀態，每個請求都是獨立的。

可以通過一些機制來實現狀態保持，例如：使用Cookie和Session來跟蹤用戶的狀態。

通過在客戶端存儲會話信息，服務器可以識別和跟蹤特定用戶的狀態。

攜帶Cookie的HTTP是有狀態的，Cookie是用來在客戶端存儲會話信息和狀態信息的，通過使用Cookie可以實現一定程度的狀態保持功能。

Cookie是HTTP協議簇的一部分，只是無狀態協議下的一種補充，用來在客戶端存儲狀態信息以實現狀態保持。

Cookie和Session的區別

存儲位置：Cookie存儲在客戶端，瀏覽器向服務器發請求時，會自動攜帶Cookie；Session存在服務器，服務器為每個用戶分配一個SessionId，通過Cookie的方式發送給客戶端，客戶端的后續請求都會攜帶SessionId，服務器根據SessionId找到對應的數據
數據容量：單個Cookie大小限制在4KB左右；Session存儲在服務器上，主要受限于服務器內存大小
安全性：Cookie存儲在客戶端，相對不安全；Session存儲在服務器，比Cookie安全
生命周期：Cookie可以設置過期時間，過期后自動刪除，也可以設置會話Cookie，瀏覽器關閉后自動刪除；Session在默認情況下，用戶關閉瀏覽器時Session結束，服務器也可以設置Session的超時時間。

token、session、cookie的區別？

session：存儲在服務器，擁有一個唯一的SessionId，這個SessionId一般存放在Cookie中。服務器收到Cookie后會解析SessionId，再去Session列表中查找，找到對應的Session。
Cookie：類似于一個令牌，裝有SessionId，存儲在客戶端，瀏覽器一般會自動添加
Token：類似一個令牌，無狀態，用戶信息都被加密到Token中，服務器收到Token后解密就可以知道是哪個用戶，需要開發者手動添加。

客戶端如果禁用了Cookie，Session也無法正常使用，因為大部分的服務器都是依賴Cookie來傳遞sessionId。

數據存儲在localStorage和Cookie有什么區別？

存儲容量：Cookie的存儲容量小；LocalStorage的存儲容量通常較大（存儲大量數據時，LocalStorage更合適）
數據發送：Cookie在每次請求時都會自動發送到服務器，適合在服務器和瀏覽器中傳輸數據；LocalStorage不會自動發送數據，只在瀏覽器中存儲數據，更適合于同一個域名下不同頁面之間共享數據
生命周期：Cookie可以設置過期時間；LocalStorage的數據將永遠存在瀏覽器中，除非通過js代碼手動刪除
安全性：Cookie的安全性低，因為Cookie每次請求都會發送給服務器，存在監聽和篡改的風險；LocalStorage的數據只存儲在瀏覽器中，相對更安全。

JWT和傳統方式的區別？

無狀態：JWT時無狀態的令牌，不需要在服務器存儲會話信息。JWT令牌中包含了所有必要的信息。
安全性：JWT使用秘鑰對令牌進行簽名，保證令牌的完整性和真實性。
跨域：JWT令牌可以在不同域之間傳遞，可以實現無需Cookie的跨域身份驗證。

JWT令牌由：頭部、載荷、簽名三部分組成。

頭部、載荷：JSON格式，使用Base64編碼進行序列化

簽名：對頭部、載荷、秘鑰進行簽名后的結果

JWT的缺點？

JWT一旦派發出去，在失效之前都是有效的，沒法即使撤銷JWT

解決：在業務層增加判斷邏輯，比如：添加黑名單機制。使用Redis維護一個黑名單，如果讓某個JWT失效就直接把這個JWT加入黑名單中，每次使用前就判斷這個JWT是否存在黑名單中。

前端如何存儲JWT？

傳統方式：

瀏覽器向服務器發起請求
服務器在當前會話（session）里保存相關數據，并返回一個sessionId
瀏覽器拿到sessionId后會存入Cookie，以后每次發請求都會攜帶Cookie。
服務器拿到Cookie后會解析出sessionId，并通過這個sessionId找到前期保存的數據。

如果是服務器集群情況下，就需要session共享數據，使得每個服務器都可以讀取到session

優化：

服務器不存儲session數據，所有數據都保存在客戶端，每次請求都會發回服務器，客戶端收到服務器返回的JWT后，可以存儲在LocalStorage里，也可以存儲在Cookie里，還可以存儲在SessionStorage里。

存儲在LocalStorage里：提供了較大的存儲空間，不會隨HTTP一起發送給服務器，但是惡意腳本可能可以通過JS代碼訪問到JWT（XSS攻擊）。
存儲在Cookie里：設置HttpOnly標志來防止通過JS訪問，減少XSS攻擊的風險；但是單個Cookie只能存儲4KB，并且每次HTTP請求都會攜帶Cookie
存儲在SessionStorage：當窗口關閉后，數據會被清除；但是用戶的體驗可能會受到影響，每次刷新頁面都需要重新登陸。

HTTP長連接和WebSocket的區別？

TCP協議是全雙工的（HTTP1.1雖然是基于TCP的協議，但是他是半雙工的；HTTP2是全雙工的），HTTP1.1對于大部分需要服務器主動推送到客戶端的場景都不太友好；而WebSocket是全雙工的
HTTP1.1里，只要客戶端不發起請求，服務器就不會給響應。對于服務器和客戶端之間需要頻繁交互的復雜場景，可以考慮webSocket

傳輸層

TCP頭部

序列號（seq）：在建立連接時由計算機生成的隨機數作為初始值，每發送一次數據，就累加一次該數據字節的大小。（用來解決網絡包亂序的問題）
確認應答號（ack）：下次“期望”收到的數據的序列號，發送端收到這個說明在這個序列號之前的所有數據都已被正常接收（用來解決丟包問題）
控制位：
- ACK：1 - 確認應答號有效
- RST：1 - TCP連接出現異常時必須強制斷開連接
- SYN：1 - 希望建立連接
- FIN：1 - 希望斷開連接

TCP三次握手

在這里插入圖片描述

第三次握手可以攜帶數據，前兩次握手是不可以攜帶數據的

一旦完成三次握手，雙方都處于established狀態，此時連接就已建立完成，客戶端與服務器就可以互相發送數據了。

為什么TCP需要三次握手？

三次握手主要是為了防止舊的重復連接初始化造成混亂。

客戶端如果連續發送了多個SYN建立連接的報文，

在網絡不好的情況下：“舊的SYN報文（seq = 90）”比“新的SYN報文（seq = 100）”早到達
此時服務器先返回一個SYN+ACK的報文給客戶端，客戶端收到后，發現自己期望收到的應該是（100 + 1 = 101，而不是90 + 1），就返回RST報文。
服務器收到RST報文后就會釋放連接。
等到新的SYN報文（100 + 1）到達后，服務器與客戶端就可以完成三次握手了

如果只有兩次握手無法防止舊的重復連接初始化。

客戶端先后發了兩個SYN報文，服務器收到了舊的SYN報文后，也往客戶端發一個SYN+ACK的報文，如果只有兩次握手，此時雙方都已進入established狀態，連接已建立。（因為需要瀏覽器這里判斷ack和期望的不同，才會發送RST報文。）

TCP三次握手，在第三次握手中，客戶端發送的確認包丟了怎么辦？

因為第三次握手的ACK是針對第二次握手的SYN的確認報文，所以當第三次握手丟失了，如果服務器一直收不到，就會觸發超時重傳機制，直到收到三次握手。如果達到最大重傳次數，服務器就會斷開連接

TCP三次握手，在第一次握手中，客戶端發送SYN報文丟失了怎么辦？

客戶端想和服務器建立連接，向服務器發送SYN報文，如果客戶端一直收不到服務器的響應，就會觸發超時重傳機制，重傳SYN報文（重傳的seq序列號是一樣的）如果達到最大重傳次數，客戶端就不再發送SYN報文，隨后斷開TCP連接

TCP三次握手，在第二次握手中，服務器的SYN + ACK報文丟失了怎么辦？

因為第二次握手的ACK報文代表對第一次握手的確認，如果客戶端沒有收到第二次握手，會認為自己第一次握手的SYN報文丟失，客戶端就會觸發超時重傳機制，重傳SYN報文。如果達到最大重傳次數，客戶端就會斷開連接。
如果第二次握手丟失，服務器收不到第三次握手，服務器這里也會觸發超時重傳機制，重傳SYN+ACK報文，如果達到最大重傳次數，服務器就會斷開連接。

第一次握手，客戶端發送SYN報文，第二次握手，服務器回復SYN+ACK報文，這個過程中服務器做了什么？

第二次握手：服務器收到客戶端的SYN請求后，會把該連接存儲到半連接隊列，并向客戶端發送SYN+ACK

第三次握手：客戶端收到后，會發ACK報文給服務器，服務器收到第三次握手的ACK后，內核會把連接從半連接隊列中移除，然后創建新的完全的連接，并添加到全連接隊列，等待進程調用accept函數把連接從全連接隊列中取出來。

如果有大量的SYN數據包從客戶端發往服務器，會導致服務器那邊的半連接隊列滿了，后續在收到SYN數據包就會丟棄。

TCP四次揮手

在這里插入圖片描述

客戶端主動關閉連接，發送FIN報文，代表客戶端已經不會發送數據了，客戶端進入FIN_WAIT_1狀態
服務器收到SYN報文，回復ACK確認報文，此時服務器進入CLOSE_WAIT狀態
此時服務器如果有數據要發送，就需要發送完數據才能關閉連接；如果沒有數據要發送，就可以直接關閉連接。
服務器發完剩余的數據后，發送FIN報文，代表服務器也不會發送數據，此時服務器進入LAST_ACK狀態
客戶端收到FIN報文后，發送ACK確認報文給服務器，客戶端此時進入TIME_WAIT狀態
服務器收到ACK確認后，也進入CLOSE狀態
客戶端經過2MSL時間后，也進入CLOSE狀態

為什么四次揮手中間兩次不能變成一次？

因為服務器收到客戶端的FIN報文時，需要立馬響應ACK，但是此時服務器可能還有數據沒有發完，所以不能馬上發送FIN報文。因此四次揮手時，服務器的ACK和FIN一般都是分兩次發送的。

第二次和第三次揮手之間，客戶端不能發送數據，但是可以接收服務器還沒發完的數據

斷開連接時客戶端FIN包丟失（第一次揮手不成功），服務器的狀態是什么？

客戶端向服務器發送FIN報文，如果發送的FIN報文丟失，客戶端收不到服務器的ACK確認，就會觸發超時重傳機制，重傳FIN報文，如果達到最大重傳次數，客戶端就會直接進入CLOSE狀態，而服務器還是established狀態。

為什么四次揮手要等2MSL？

MSL是報文最大生存時間，超過這個時間報文會被丟棄，因為TCP報文是基于IP協議，IP頭有一個TTL字段（是IP數據包可以經過的最大路由跳數）

MSL的單位是時間，TTL是經過路由跳數，所以MSL應該大于等于TTL消耗為0的時間，保證報文已經被自然消亡。

等待2MSL，主要是因為網絡中可能存在發送方的報文，這些發送方的數據包被接收方處理后，又會向對方發送響應。（一來一回需要等待2倍時間）

如果服務器沒有收到客戶端最后的ACK報文，那么就會觸發服務器的超時重傳，服務器會重新發送FIN報文，一來一回正好2MSL（相當于至少允許報文丟失一次）

TCP和UDP的區別？

TCP面向連接，UDP無連接
TCP一條鏈路只能由兩個端點；UDP支持一對一、一對多、多對多
TCP可靠交付數據；UDP盡最大努力交付（基于UDP傳輸協議實現一個可靠的傳輸協議：QUIC協議）
TCP有流量控制和擁塞控制；UDP沒有，即使網絡擁堵，也不會影響UDP的發送速率
TCP首部較長（20字節），長度不固定；UDP首部只有8字節，固定不變，開銷小。
TCP是流式傳輸，沒有邊界，但是要保證順序和可靠；UDP是一個個包發送，有邊界，可能會出現丟包和亂序。

TCP為什么可靠傳輸？

連接管理：三次握手、四次揮手建立可靠連接
序列號：既能保證可靠性，又能防止數據丟失，還能避免數據重復。
確認應答：接收方收到數據后，會發送ACK確認報文，報文中也會攜帶此次確認的序列號，如果未發送確認報文，就會觸發超時重傳機制。
超時重傳：
- 數據包丟失：指定時間內，發送方未收到確認應答，就會啟動超時重傳
- 確認包丟失：接收方收到重復數據時丟棄，并重新回傳ACK確認報文
流量控制：根據接收方處理能力，來決定發送發的發送速度（在TCP報文首部維護一個滑動窗口實現）
擁塞控制：當網絡擁堵時需要減少數據發送（通過發送端維護一個擁塞窗口實現）

TCP粘包問題？

粘包問題主要是不知道用戶消息的邊界在哪，如果知道邊界在哪，就可以通過邊界來劃分出有效的用戶信息。

固定長度的消息【少用】：每個用戶消息都是固定的（比如規定消息的長度是64字節，當接收方收到64個字節的數據，就會認為這個內容是一個完整的消息）
特殊字符作為邊界：在兩個用戶的消息之間插入一個特殊字符，接收方收到數據后，讀取到這個特殊字符，就認為已經讀到了一個完整的消息。

如果消息里正好有這個字符，需要對消息里的字符做轉義

自定義消息結構（包頭 + 數據）：包頭大小固定，包頭里有個字段是用來說明隨后的數據有多大。接收方收到包頭后，先解析包頭的內容，得到數據的長度，然后接下來就繼續讀取數據，直到讀滿數據長度。

TCP的擁塞控制？

在網絡出現擁堵的情況，如果發送大量的數據包，會導致數據包丟失，這時TCP就會觸發重傳機制，導致網絡的負擔更重，就會進入惡性循環。

擁塞控制就是避免發送方的數據填滿整個網絡。

發送方會維護一個擁塞窗口，擁塞窗口會根據網絡的擁塞程度動態變化。

發送窗口= min(擁塞窗口, 接收窗口)

擁塞控制的四個算法：

慢啟動：發送方每收到一個ACK，擁塞窗口 + 1（指數增加）
- 當擁塞窗口達到慢啟動門限，就會使用擁塞避免算法
擁塞避免：發送方每收到一個ACK，擁塞窗口 + 1/擁塞窗口（線性增長）
擁塞發生：當網絡出現擁塞時（發生數據包重傳時），就會觸發重傳機制
- 超時重傳：慢啟動門限設置為當前擁塞窗口的一半，擁塞窗口直接設置為1
- 快重傳：擁塞窗口設置為原來的一半，慢啟動門限等于當前擁塞窗口，進入快恢復
快恢復（一般和快重傳同時使用）

網絡場景

打開百度首頁后發生了什么

解析URL：檢查URL中是否出現了非法字符，對非法字符進行轉義后處理
緩存判斷：判斷請求的資源是否在緩存里，如果在緩存里且沒有失效，就會直接使用；如果失效會進行DNS解析
DNS解析：如果資源不在緩存里，就進行DNS解析，先查詢本地域名服務器，如果本地域名服務器能找到對應的ip地址，就返回；如果找不到，本地域名服務器就會分別迭代查詢頂級域名服務器、根域名服務器、權威域名服務器，最后在權威域名服務器中找到ip地址返回
獲取MAC地址：當瀏覽器得到ip地址后，數據傳輸還需要直到主機的MAC地址。
- 因為應用層數據會往下傳遞給傳輸層
- 在傳輸層又會下發給網絡層
- 網絡層會將本機地址作為源地址，獲取的ip地址作為目的地址，然后下發給數據鏈路層
- 數據鏈路層需要得到雙方的MAC地址，本機的MAC地址作為源地址，目的MAC地址需要分兩種情況：
  - 如果源ip地址和目的ip地址在同一個子網下，可以使用ARP協議直接獲取到目的主機的MAC地址
  - 如果源ip地址和目的ip地址不在同一個子網下，就將請求交給網關，由網關代為轉發，也是通過ARP協議獲取網關的MAC地址，此時目的MAC地址就是網關的MAC地址
建立TCP連接：
- 使用目標IP地址和目標MAC地址發送SYN報文，請求建立TCP連接
- 然后由路由器轉發到目標服務器后，目標服務器恢復SYN_ACK報文
- 客戶端收到后，發送ACK包，表示收到服務器的確認，TCP連接建立完成
如果使用的是HTTPS協議，在TCP三次握手之前，還存在TLS的四次握手
發送數據：瀏覽器會向服務器發送HTTP請求
服務器響應數據：服務器收到請求后，會根據請求的內容做處理后響應數據
瀏覽器結束后，主動發送FIN報文，隨后進入四次揮手。
- 瀏覽器主動發送FIN報文，表示要斷開連接
- 服務器收到后，先返回ACK，表示收到瀏覽器的斷開請求
- 服務器繼續發送剩余的數據，發送完畢后，服務器也發送一個FIN報文，表示服務器這里也發完了，也斷開連接
- 瀏覽器收到服務器的斷開請求后，發送ACK報文，表示已收到，四次揮手結束。