1.一條url輸入到瀏覽器最后顯示頁面的過程
- URL解析與處理
瀏覽器解析URL（如https://www.example.com/page）
分離協議（https）、域名（www.example.com）和資源路徑（/page）
檢查HSTS預加載列表強制使用HTTPS
處理特殊字符（如空格轉義為%20）
- DNS域名解析
瀏覽器檢查本地緩存（瀏覽器緩存→系統緩存→路由器緩存）
未命中則向配置的DNS服務器發起遞歸查詢
DNS服務器通過層級解析（根域名→頂級域→權威DNS）獲取IP地址
結果緩存到本地（TTL決定有效期）
- 建立TCP連接
通過操作系統網絡棧向目標IP的80/443端口發起請求
三次握手建立TCP連接：
text
客戶端 → SYN → 服務端
客戶端 ← SYN-ACK ← 服務端
客戶端 → ACK → 服務端
啟用TLS時額外進行SSL/TLS握手（協商加密套件、證書驗證、密鑰交換）
- 發送HTTP請求
組裝HTTP請求報文：
text
GET /page HTTP/1.1
Host: www.example.com
User-Agent: Chrome/…
Accept: text/html,application/xhtml+xml
Cookie: sessionid=…
包含請求行、請求頭、空行和可選的請求體
啟用HTTPS時數據通過TLS記錄協議加密傳輸
- 服務器處理請求
反向代理（如Nginx）接收請求，根據配置路由到應用服務器
應用服務器（如Node.js/Django）執行業務邏輯：
讀取數據庫（MySQL/MongoDB）
調用微服務（gRPC/REST）
渲染模板（Jinja2/JSX）
生成響應：狀態碼+響應頭+響應體
接收HTTP響應
- 瀏覽器接收響應流：
text
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
根據狀態碼處理（301重定向/200成功/404錯誤等）
解壓gzip/brotli壓縮內容
- 關鍵渲染路徑（瀏覽器引擎工作）
DOM構建：邊下載邊解析HTML，生成DOM樹（遇到
CSSOM構建：解析CSS規則，計算層疊樣式
渲染樹：合并DOM+CSSOM，排除不可見元素
布局：計算元素幾何位置（Reflow）
繪制：填充像素到圖層（Paint）
合成：GPU加速合成最終界面
2.DNS域名系統，簡述描述其原理
DNS（Domain Name System）是一種分布式層級數據庫系統，其核心功能是將人類可讀的域名（如 www.example.com）轉換為機器可識別的IP地址（如 192.0.2.1）。其工作原理基于分層查詢和分布式存儲：
- 域名空間結構：
采用樹狀層級結構：根域（.）→ 頂級域（.com, .org）→ 二級域（example）→ 子域名（www）
每級由不同權威服務器管理，實現責任分散
- 解析流程：
本地查詢：瀏覽器首先檢查本地緩存 → 操作系統緩存 → 路由器緩存
遞歸查詢：本地DNS服務器（ISP提供）作為代理發起全流程解析：
查詢根域名服務器（全球13組）獲取頂級域服務器地址
查詢頂級域（.com）服務器獲取二級域授權服務器
查詢二級域（example.com）權威服務器獲取具體主機IP
迭代響應：每級服務器僅返回下一級線索，不直接提供最終答案
- 記錄類型：
A記錄：存儲IPv4地址
AAAA記錄：存儲IPv6地址
CNAME：域名別名（如將 www 指向主域名）
MX記錄：郵件服務器地址
NS記錄：指定域名的權威服務器
- 緩存機制：
各級DNS服務器根據TTL（Time to Live）緩存查詢結果
顯著減少根服務器負載（全球日均萬億次查詢）
緩存過期后自動重新查詢
- 協議特性：
默認使用UDP端口53（快速查詢）
大響應時切換TCP
支持DNSSEC提供數據完整性驗證
3.七層網絡模型是什么、TCP/IP四層網絡模型是什么
- 七層OSI模型（理論參考框架）：
物理層：通過物理介質傳輸比特流（如網線電壓/光纖信號）
數據鏈路層：MAC尋址、幀同步、差錯控制（交換機工作層）
網絡層：IP尋址、路由選擇、分組轉發（路由器工作層）
傳輸層：端到端連接管理（TCP可靠傳輸/UDP快速傳輸）
會話層：建立/維護/終止會話（如RPC調用）
表示層：數據格式轉換、加密/解密（如SSL/TLS）
應用層：用戶接口和網絡服務（HTTP/FTP/SMTP協議）
- 四層TCP/IP模型（實際應用標準）：
網絡接口層：對應OSI物理層+數據鏈路層，處理硬件連接和幀封裝
網際層：對應OSI網絡層，核心IP協議實現跨網絡尋址
傳輸層：與OSI傳輸層完全對應，提供TCP/UDP端到端控制
應用層：合并OSI會話層+表示層+應用層，直接承載HTTP/DNS等協議
4. TCP和UDP有什么區別
- TCP（傳輸控制協議）：
連接導向：通信前需三次握手建立可靠連接（SYN→SYN-ACK→ACK）
可靠傳輸：
數據包排序（序列號機制）
丟失重傳（ACK確認+超時重發）
完整性校驗（校驗和）
流量控制：滑動窗口動態調整發送速率（避免接收方溢出）
擁塞控制：慢啟動→擁塞避免→快速恢復（保障網絡穩定性）
頭部開銷大：20-60字節（含序列號/確認號/控制標志等）
典型應用：網頁（HTTP）、郵件（SMTP）、文件傳輸（FTP）
- UDP（用戶數據報協議）：
無連接：直接發送數據包，無握手過程
不可靠傳輸：
不保證數據包順序
無重傳機制（可能丟失）
僅基礎校驗（校驗和可選）
無流控與擁塞控制：持續以恒定速率發送
頭部開銷小：固定8字節（僅源/目標端口+長度+校驗和）
支持廣播/多播：可同時向多個主機發送數據
典型應用：視頻流（RTP）、DNS查詢、在線游戲、IoT傳感器數據
本質區別：TCP是"電話通話"（有序可靠但延遲敏感），UDP是"寄明信片"（快速投遞但不保證送達）。現代技術如QUIC協議（HTTP/3）正融合兩者優勢，在UDP上實現TCP級可靠性。
5.TCP的三次握手四次揮手的過程，為什么不能是兩次握手，為什么不是三次揮手
- 三次握手建立連接（確保雙向通信可靠）：
客戶端→服務端：發送SYN包（同步序列號，如SEQ=100）
服務端→客戶端：響應SYN-ACK包（確認SEQ=101，自帶SEQ=300）
客戶端→服務端：發送ACK包（確認SEQ=301）
至此連接建立，雙方就初始序列號達成共識。
-
為何不能兩次握手：
若僅兩次握手，服務端無法確認客戶端是否收到自己的SYN-ACK響應。網絡延遲可能導致舊的SYN包突然到達，服務端誤建連接（資源浪費），而客戶端因未發送ACK會拒絕此連接，導致服務端長期等待（資源耗盡）。三次握手通過最后確認徹底排除歷史包干擾。 -
四次揮手終止連接（安全關閉雙工通道）：
主動方→被動方：發送FIN包（請求終止發送）
被動方→主動方：立即響應ACK包（確認收到終止請求）
此時被動方可能仍有數據待發送（半關閉狀態）
被動方→主動方：數據發送完畢后發送FIN包
主動方→被動方：響應最終ACK包（連接完全關閉）
- 為何不是三次揮手：
被動方收到FIN后需先發ACK（快速響應），再繼續處理剩余數據（如未傳完的文件），之后才發FIN。若合并為三次（ACK+FIN一起發送），會強制被動方立即終止所有操作，可能導致：
數據丟失（未傳輸完成即關閉）
資源沖突（FIN過早發送但數據仍在傳輸中）
四次揮手通過分離ACK和FIN，實現連接的安全有序關閉。
關鍵設計哲學：TCP通過三次握手防止"僵尸連接"，四次揮手適應"雙工通道獨立關閉"。這種設計在保證可靠性的同時，完美平衡了效率與資源安全，成為互聯網通信的基石。
6.TIME_WAIT 和CLOSE_WAIT 是什么
- CLOSE_WAIT 狀態
觸發位置：被動關閉方（接收 FIN 包的服務端）
產生場景：
主動關閉方（客戶端）發送 FIN 請求斷開連接
被動關閉方回復 ACK 確認后進入 CLOSE_WAIT 狀態
核心意義：
等待被動關閉方的應用程序處理剩余數據（如未發送完的響應）
風險警示：
大量 CLOSE_WAIT 表明應用程序未正確關閉連接（如未調用 close()）
→ 導致連接泄漏（可通過 netstat 監測）
- TIME_WAIT 狀態
觸發位置：主動關閉方（發起 FIN 的客戶端）
產生場景：
主動關閉方發送最終 ACK 后進入 TIME_WAIT
持續 2MSL（Max Segment Lifetime，通常 60-120 秒）
雙重使命：
確保最后 ACK 送達：若被動方未收到 ACK 會重發 FIN，主動方可響應
清除殘余報文：等待網絡中舊連接數據包消亡，避免污染新連接
設計必要性：
防止歷史數據包被相同四元組（源IP+端口，目標IP+端口）的新連接錯誤接收
7. HTTP是什么，與HTTPS有什么區別
- HTTP（超文本傳輸協議）：
互聯網應用層協議，基于TCP端口80通信
明文傳輸：請求/響應內容未加密，易被竊聽（如密碼泄露）
無身份驗證：無法驗證服務器真實性，存在中間人攻擊風險
數據完整性缺失：傳輸內容可能被篡改（如插入廣告代碼）
- HTTPS（HTTP Secure）：
HTTP的安全升級版，本質是HTTP over TLS/SSL
加密傳輸：通過TLS握手建立安全通道（非對稱加密交換密鑰 + 對稱加密傳輸數據）
身份認證：CA機構頒發數字證書驗證服務器身份（防釣魚網站）
數據完整性保護：HMAC算法防止內容篡改
默認使用TCP端口443，需服務器配置有效證書
本質差異：HTTPS = HTTP + TLS加密層，如同為普通信件（HTTP）添加防彈裝甲和指紋鎖（TLS）。現代瀏覽器已標記HTTP站點為"不安全"，HTTPS成為Web安全基石。
8. GET和POST請求有哪些區別
- GET 請求：
數據位置：參數附加在 URL 后（?key1=value1&key2=value2），暴露在地址欄
設計用途：獲取數據（如加載網頁、查詢信息），不應修改服務器狀態
特性限制：
URL 長度受限（通常 ≤ 2048 字符，瀏覽器差異）
數據僅支持 ASCII 字符
可被緩存/書簽保存/歷史記錄保留
安全性與冪等性：
明文傳輸（無加密）
天然冪等（多次請求結果相同）
- POST 請求：
數據位置：參數封裝在請求體（Request Body）中，地址欄不可見
設計用途：提交數據（如登錄表單、文件上傳），可修改服務器狀態
特性優勢：
支持大數據傳輸（理論無上限，實際受服務器配置限制）
支持二進制數據（如圖片/文件）
不可緩存/書簽保存
安全性與冪等性：
仍依賴 HTTPS 實現加密（Body 本身不加密）
非冪等（重復提交可能產生副作用，如多次下單）
9.HTTP長連接與短鏈接區別
- 短連接（Short-Lived Connections）：
工作模式：每次HTTP請求均需獨立建立TCP連接（三次握手），請求響應后立即斷開（四次揮手）
性能開銷：
高延遲（每次請求重復握手/揮手）
高資源消耗（頻繁開關連接占用CPU/內存）
適用場景：
低頻請求（如傳統網頁瀏覽）
兼容老舊服務器（HTTP/1.0默認）
- 長連接（Persistent Connections / HTTP Keep-Alive）：
工作模式：單次TCP連接處理多個HTTP請求/響應，通過Connection: keep-alive頭部啟用
性能優勢：
減少60%以上延遲（避免重復握手）
降低服務器負載（連接復用減少50%+ TCP開銷）
管理機制：
超時關閉（服務器設置Keep-Alive: timeout=60）
最大請求數限制（max=100）
協議支持：
HTTP/1.1 默認啟用
HTTP/2 基于長連接實現多路復用（Multiplexing）
短連接如 “一次性電話”（每次溝通需重新撥號）
長連接如 “持續通話”（保持線路處理多次對話）
長連接通過復用TCP通道，顯著提升網絡效率，成為現代互聯網基礎設施的核心優化手段。
10.Websocket是什么
WebSocket 是一種基于 TCP 的全雙工通信協議（標準端口 80/443），在單個持久連接上實現客戶端與服務器的實時雙向數據流。其通過 HTTP 協議升級握手建立連接（Upgrade: websocket），之后脫離 HTTP 范式獨立傳輸數據。
誕生背景：
解決傳統 HTTP 的痛點：
輪詢低效：客戶端需反復請求獲取新數據（高延遲）
單向通信：服務器無法主動推送數據（如聊天消息）
11.全雙工與半雙工有什么區別
- 全雙工（Full Duplex）：
核心能力：通信雙方可同時雙向傳輸數據（發送與接收并行）
技術實現：
物理層：使用兩對獨立線路（如網線的發送/接收線對）
協議層：通過頻率分割（FDD）或時間插空（如TDD-LTE）實現并發
類比模型：電話通話——雙方能同時說話且聽到對方聲音
典型應用：
現代電話網絡（4G/5G VoLTE）
WebSocket實時通信
以太網（千兆以上）
- 半雙工（Half Duplex）：
核心限制：通信雙方交替傳輸數據（發送時不能接收，反之亦然）
技術特征：
共享單通道（如Wi-Fi同一頻段）
依賴沖突檢測（CSMA/CD）或請求響應（RTS/CTS）機制
類比模型：對講機對話——按PTT鍵說話時無法收聽，需釋放按鍵接收
典型場景：
傳統對講機系統
早期以太網（10BASE2）
工業總線（CAN協議）
12.什么是跨域問題，有哪些解決辦法
跨域問題本質：
瀏覽器同源策略（Same-Origin Policy）的安全限制，阻止網頁向協議/域名/端口任一不同的目標發起請求。例如：
http://a.com → https://a.com（協議不同）?
http://a.com → http://api.a.com（域名不同）?
http://a.com:80 → http://a.com:8080（端口不同）?
- CORS（跨域資源共享） - 主流方案
服務端設置響應頭：
http
Access-Control-Allow-Origin: * // 允許所有域
Access-Control-Allow-Methods: GET, POST // 允許的HTTP方法
Access-Control-Allow-Headers: Content-Type // 允許的請求頭
預檢請求：復雜請求前自動發OPTIONS探路
- 反向代理 - 前端工程化首選
開發環境：Webpack/Vite配置proxy將/api代理到目標服務器
生產環境：Nginx配置路由轉發
nginx
location /api {
proxy_pass http://target-server.com;
}
13.QUIC協議是什么
QUIC（Quick UDP Internet Connections）是由Google主導設計的基于UDP的現代化傳輸協議，旨在解決TCP的固有缺陷，現已成為HTTP/3的底層標準（RFC 9000）。
關鍵技術創新
- 0-RTT建連：
通過緩存會話密鑰，首次連接需1-RTT，重連實現零握手延遲（比TCP+TLS快3倍）
- 徹底消除隊頭阻塞：
基于UDP實現真正多路復用，單連接內數據流獨立傳輸（某流丟包不影響其他流）
- 無縫連接遷移：
使用連接ID而非IP+端口標識連接，切換網絡（WiFi→5G）無斷連
- 原生加密傳輸：
內置TLS 1.3（協議頭部全部加密），防運營商篡改
- 智能擁塞控制：
改進BBR算法，動態適應網絡波動（尤其提升高丟包環境性能）
14.什么是多路復用
多路復用（Multiplexing） 是一種在單條物理連接上并發傳輸多個獨立數據流的技術，通過共享信道資源大幅提升傳輸效率。其本質是解決"如何讓多個通信流共享同一通道"的問題，避免為每個數據流建立獨立連接的開銷。
關鍵實現方式
- HTTP/2 中的多路復用
突破HTTP/1.1隊頭阻塞：將請求/響應拆分為二進制幀（Frame）
幀標識機制：每個幀攜帶唯一Stream ID，接收方可并行重組
效果：單TCP連接同時處理數十個請求（如圖片/CSS/JS并行加載）
- QUIC協議的多路復用
基于UDP實現真并行：數據流完全獨立（某流丟包不影響其他流）
0-RTT連接復用：加密會話緩存實現瞬時重連
- 硬件層多路復用
頻分復用（FDM）：不同頻率載波傳輸多路信號（如有線電視）
時分復用（TDM）：時間片輪轉分配信道（傳統電話網絡）
)
)
